Alta Disponibilidade em Correio Eletrônico

Deives Michellis "thefallen"
Revisão: $Id: palestra-há-mail.t2t,v 1.2 2006/11/17 17:37:14 thefallen Exp thefallen $

 

 

Introdução

Nesta palestra, vamos conhecer algumas técnicas muito úteis e configurações de ambientes que contribuem para formar um ambiente de correio com alta disponibilidade e carga balanceada. Não se trata de um Workshop, mas de uma abordagem aos conceitos e softwares que nos ajudam a montar um ambiente melhor para o funcionamento do correio.

As técnicas tentarão ser exploradas ao máximo em seu carater genérico, evitando particularidades de sistemas de correio específicos como Postfix, Qmail, Sendmail, Exim, etc. No entando, alguns exemplos precisarÃo ser baseados em um sistema específico, e o escolhido é o Postfix.

1. Balanço de Carga no Recebimento do Email (MTA)

A Primeira parte da tarefa de produzir um ambiente de correio mais estavel e confiavel consiste em ser capaz de receber emails a qualquér tempo, e em face de qualquér contratempo. Esse tipo de disponibilidade pode ser facilmente implementado com alguns metodos e ferramentas bastante conhecidos da maioria dos administradores de sistema. Trata-se do balanco de carga dos Mail eXchangers que recebem as mensagens vindas da Internet.

Se eu puder ter mais de um servidor capaz de receber a mensagem, consigo enfrentar o contratempo de ter 1 ou mais dos servidores parados para manutenção ou com problemas, e continuar recebendo minhas mensagens normalmente.

As maneiras mais simples de se fazer isso são as seguintes:

1.1. Com Múltiplos registro MX

Na hora de criar o registro MX no DNS, basta colocar diversos deles, com pesos ou prioridades diferentes ou iguas (para sistema de contingencia ou balanco de carga, respectivamente), e todos os servidores da Internet que tentarem mandar email para seu dominio já estarao sabedores do fato que você dispoe de múltiplos recebedores. Assim, se um deles estiver fora do ar, o servidor remoto que esta tentando te enviar a mensagem vai automaticamente usar outro de seus recebedores.

As melhores práticas pra esse tipo de ambiente sugerem que se tenha os MX hospedados em links de provedores com backbones distintos, para garantir que você não fique fora do ar caso de algum problema na conexão de ser provedor/hosting. Por exemplo, poderiamos ter o MX no.1 conectado por um link Embratel, o MX no.2 em um link Telefonica, um 3o. MX conectado pela Brasil Telecom, e assim por diante. Esse tipo de ambiente geralmente não reflete a realidade das empresas, que não dispoe ou não desejam alocar recursos financeiros para tantos links "concorrentes", que afinal de contas, fazem o mesmo trabalho de um único.

Exemplos:

  [email protected]:~ $ dig -t mx yahoo.com
  (...)
  ;; ANSWER SECTION:
  yahoo.com.		7158	IN	MX	1 a.mx.mail.yahoo.com.
  yahoo.com.		7158	IN	MX	1 b.mx.mail.yahoo.com.
  yahoo.com.		7158	IN	MX	1 c.mx.mail.yahoo.com.
  yahoo.com.		7158	IN	MX	1 d.mx.mail.yahoo.com.
  yahoo.com.		7158	IN	MX	1 e.mx.mail.yahoo.com.
  yahoo.com.		7158	IN	MX	1 f.mx.mail.yahoo.com.
  yahoo.com.		7158	IN	MX	1 g.mx.mail.yahoo.com.
  yahoo.com.		7158	IN	MX	5 h.mx.mail.yahoo.com.
  (...)

  ;; ADDITIONAL SECTION:
  a.mx.mail.yahoo.com.	1758	IN	A	209.191.118.103
  b.mx.mail.yahoo.com.	1758	IN	A	66.196.97.250
  c.mx.mail.yahoo.com.	1758	IN	A	216.39.53.3
  d.mx.mail.yahoo.com.	1758	IN	A	216.39.53.2
  e.mx.mail.yahoo.com.	1758	IN	A	216.39.53.1
  f.mx.mail.yahoo.com.	1758	IN	A	209.191.88.247
  f.mx.mail.yahoo.com.	1758	IN	A	68.142.202.247
  g.mx.mail.yahoo.com.	1758	IN	A	206.190.53.191
  g.mx.mail.yahoo.com.	1758	IN	A	209.191.88.239
  h.mx.mail.yahoo.com.	1758	IN	A	66.196.97.250
  h.mx.mail.yahoo.com.	1758	IN	A	209.191.118.103
  (...)

1.2. Com Múltiplos endereços para um mesmo host

É possivel também definirmos múltiplas respostas para um hostname que faça parte de nossos MX's. Isso em si não colabora para a disponibilidade do sistema, mas ajuda a distribuir melhor a carga entre diversos servidores, uma vez que quando tempos múltiplos registros "A" para um host, a sequencia de envio é aleatoria, e qualquér um pode ser o "escolhido" pelo servidor remoto para a conexão.

Isso não colabora para a disponibilidade dos MX porque, quando um servidor tenta mandar email, ele vai "rodar" em todos os MX até achar um que funcione, mas não vai tentar TODOS os registros "A" de um MX até achar um que funcione. Ficou confuso? Vamos tentar de novo!

Tenho um dominio que apresenta a seguinte configuração de MX:

  dominio.com.br.       300     IN      MX      10 mail0.dominio.com.br.
  dominio.com.br.       300     IN      MX      10 mail1.dominio.com.br.
  dominio.com.br.       300     IN      MX      10 mail2.dominio.com.br.

O mail0.dominio.com.br responde pelos seguintes IPs:

  mail0.dominio.com.br.       300     IN      A    200.200.200.1
  mail0.dominio.com.br.       300     IN      A    200.200.200.2
  mail0.dominio.com.br.       300     IN      A    200.200.200.3
  mail0.dominio.com.br.       300     IN      A    200.200.200.4
  mail0.dominio.com.br.       300     IN      A    200.200.200.5

  mail1.dominio.com.br.       300     IN      A    200.200.200.6
  mail1.dominio.com.br.       300     IN      A    200.200.200.7
  mail1.dominio.com.br.       300     IN      A    200.200.200.8
  mail1.dominio.com.br.       300     IN      A    200.200.200.9
  mail1.dominio.com.br.       300     IN      A    200.200.200.10

  mail2.dominio.com.br.       300     IN      A    200.200.200.11
  mail2.dominio.com.br.       300     IN      A    200.200.200.12
  mail2.dominio.com.br.       300     IN      A    200.200.200.13
  mail2.dominio.com.br.       300     IN      A    200.200.200.14
  mail2.dominio.com.br.       300     IN      A    200.200.200.15

Quando o servidor smtp.lerolero.com tentar enviar um email para O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo., vai acontecer mais ou menos assim:

Servidor lerolero: Quais os MX do dominio dominio.com.br? DNS: mail2.dominio.com.br, mail0.dominio.com.br, mail1.dominio.com.br Servidor lerolero: Hmmm, ok. Escolhi o mail1.dominio.com.br. Qual o IP para o hostname mail1.dominio.com.br? DNS: mail1.dominio.com.br tem os IPs: 200.200.200.8 200.200.200.10 200.200.200.6 200.200.200.9 200.200.200.7 Servidor lerolero: Ok, vou usar o 200.200.200.9

Servidor lerolero: Vou me conectar no 200.200.200.9! Erm... Conexão recusada. Droga, ta fora do ar. Servidor lerolero: DNS, qual o host de um outro MX mesmo? DNS: mail0, mail2 e mail1.dominio.com.br Servidor lerolero: Me da um IP pro hmmm.... mail2.dominio.com.br DNS: 200.200.200.12 200.200.200.11 200.200.200.14 200.200.200.15 200.200.200.13 Servidor lerolero: Ta, vou usar o 200.200.200.12

Note que o servidor lerolero não tenta mais conectar outros possiveis IPs para o host mail1, e procura conexão no próximo MX.

Esse tipo de setup é bastante comum em grandes provedores de email, como yahoo, hotmail, uol, bol, terra, e outros gigantes. Ajuda a distribuir a carga entre dezenas, até centenas de servidores.

1.3. Com regras de firewall/iptables

Podemos distribuir carga de correio usando regrinhas de redirecionamento/NAT dentro do iptables ou qualquér que seja o firewall utilizado. Pode-se estabelecer um sistema de rotação dos servidores, em que a cada X minutos, um servidor diferente receba as novas conexões.

Esse recurso é bastante interessante quando se tem alta carga de email a ser filtrado/analisado, mas não dispomos de mais IPs "validos" na Internet para distribuir a carga. Assim, um script simples de IPTables agendado no cron faz a rotação de regras automaticamente.

Um exemplo:

  #!/bin/sh

  # Precisa criar uma nova "chain" chamada ROTACAO e colocar uma regra
  # que desvie o trafego da porta 25 pra essa chain.

  SEGUNDOS=`date +%S`

  iptables -t nat -F ROTACAO
  if [ $SEGUNDOS -lt 30 ]; then
  	iptables -t nat -I ROTACAO -j DNAT --to 192.168.0.10
  else
  	iptables -t nat -I ROTACAO -j DNAT --to 192.168.0.20
  fi

2. Balanço de Carga na Retirada/Visualização do Email via IMAP4/POP3 (MRA)

Uma vez que já dispomos de metade da nossa solução, um sistema capaz de receber emails mesmo com servidores fora do ar, precisamos passar a 2a parte de nossa missão, fazer com que o usuário também possa le-los mesmo com servidores desligados.

Podemos, por exemplo, bolar um sistema em que partes dos usuários estejam em servidores especificos. Pensando num grande site de email, com muitos milhares de contas, manter todas as caixas num único local seria impraticavel. Assim, podemos colocar, por exemplo, os usuários que comecam com a letra "a" até a letra "f" no servidor caixa0.dominio.com.br e usuários de "g" até "z" no caixa1.dominio.com.br.

Pensando em outra situação, posso querer ter diversos servidores com copias das caixas, de forma que qualquér um que caia, os outros tenham condições de atender a seus usuários.

Ainda nessa idéia, podemos ter um ou mais servidores em stand-by, replicando as alterações do servidor mestre, aguardando o momento deste cair para que eles possam assumir seu papel.

2.1. Distribuindo Entre Múltiplos Servidores de Caixa

A distribuição das caixas entre múltiplos servidores, separando cada usuário em seu respectivo servidor, acontece primeiramente no servidor de correio (MTA) e não no IMAP/POP. O MTA deve encaminhar o email para o servidor certo, e os usuários devem ser informados do endereco do servidor a que devem se conectar.

Existem algumas ferramentas que podem ajudar, fazendo com que todos os servidores do sistema de email "saibam" em qual servidor esta cada caixa. Assim, podemos ter uma "malha" de servidores IMAP ou POP que distribuem entre si as conexões de acordo com uma tabela.

 

Por exemplo, caixas comecando com "a" até "e" vão para o servidor mail0, caixas comecando com "f" até "m" vão para o mail1, "n" até "z" para o mail2. Cada um dos servidores, mail0, mail1 e mail2, contem uma tabela com essa distribuição, de forma que um usuário que se conecte ao servidor mail0 mas que tem sua caixa hospedada no mail2, seja automaticamente "proxyado" para o servidor correto. Igualmente, poderiamos distribuir as caixas de acordo com a localidade. Emails da filial de SP caem no mbox-sp.dominio.com.br, emails do RJ caem no mbox-rj.dominio.com.br.

Numa situação destas, um usuário do RJ poderia vir para São Paulo e se conectar no mesmo servidor que todos os paulistas, mas o servidor iria consultar sua tabela e abrir uma segunda conexão com o servidor do RJ, como o diagrama abaixo.

    +------------+      +-------------+      +-------------+
  	|	Usuário RJ |----->| Servidor SP |----->| Servidor RJ |
    +------------+      +-------------+      +-------------+

    +------------+      +-------------+
  	| Usuário SP |----->| Servidor SP |
  	+------------+      +-------------+

2.1.1. Distribuindo o Acesso com Perdition

O Perdition POP/IMAP proxy é a ferramenta ideal para fazer esse tipo de redirecionamento/proxy com caixas e contas. Ele aceita uma boa variedade de fontes, como uma tabela com gdbm, um arquivo de expressoes regulares e até mesmo LDAP, pelo que consta na documentação. No entanto, usar tabelas em regexp ou arquivos indexados é mais do que suficiente para redirecionar, com o auxílio de alguns pequenos shell scripts.

Exemplos:

  /etc/perdition/perdition.conf:
  map_library /usr/lib/libperditiondb_gdbm.so
  map_libray_opt /etc/perdition/popmap.gdbm.db
  server_ok_line
  L 500
  no_lookup
  s 10.1.0.5
  t 300
  q
  domain_delimiter |
  username_from_database
  ssl_cert_file /etc/perdition/certificates/perdition.pem
  ssl_key_file /etc/perdition/certificates/perdition.pem
  ssl_cert_accept_self_signed
  ssl_cert_verify_depth 0
  ssl_no_cert_verify
  ssl_no_cn_verify
  ssl_mode tls_listen

 

  /etc/perdition/popmap:
  fulano:mail-sp.dominio.com.br
  ciclano:mail-rj.dominio.com.br
  beltrano:mail-a.dominio.com.br

2.2. Relicando Entre Múltiplos Servidores de Caixa

Podemos imaginar um modelo alternativo a este em que todos os servidores da "malha" contem todas as mailbox de todos, e portanto, podem atuar como redundancia uns dos outros. Pra fazermos isso, precisamos de algum mecanismo leve e eficiente para replicar as alterações nas caixas entre os diversos servidores.

Existem sistemas que fazem esta réplica direto no dispositivo ou no filesystem. São sistemas normalmente complexos e nem sempre tão funcionais como gostariamos, com muitas customizações de kernel, e modulos e afins.

Uma solução pra esse tipo de complexidade seria um sistema, rodando inteiramente em modo usuário, que pudesse replicar alterações entre os servidores sem comprometer o recebimento ou a disponibilidade do mesmo. Sincronia? Alguns talvez pensem direto no rsync, uma otima ferramenta pra isso. Mas o rsync tem algumas limitações quando a sincronia é feita em ambas as direções, quer dizer, ambos os lados tem alterações a conciliar.

 

Buscando uma solução para esse problema, acabei "esbarrando" numa ferramenta que se propoe exatamente a isso: funcionar como um "rsync", conciliando alterações nos dois lados da réplica/sincronização. Esta ferramenta chama-se "Unison" (de "Uníssono"), e inclusive usa um protocolo baseado no rsync para a propagação de alterações com um mínimo de trafego.

De posse dessa ferramenta, podemos ver a facilidade de replicar caixas se estas estiverem em formato Maildir, uma vez que Maildirs são compostos de muitos pequenos arquivos (cada mensagem corresponde a um arquivo), e basta copiarmos/excluirmos os arquivos quando estes foram escritos ou removidos de um dos outros servidores.

Com as caixas replicadas, podemos usar a idéia de múltiplos IPs para um mesmo hostname, fazendo com que os usuários se conectem a um servidor aleatorio a cada tentativa, ou fazendo isso com scripts de iptables no firewall/gateway da rede (se for o caso).

Por exemplo, podemos ter o hostname "mailbox.dominio.com.br", que é o host que todos os clientes tentarao se conectar. O host "mailbox", ao ser consultado no DNS, resolve para os IPs 192.168.0.10, 192.168.0.11, 192.168.0.30, e assim por diante. Igual ao caso considerado para o MX, a ordem é aleatoria.

2.2.1. Replicando Alterações com o Unison

Para fazermos o Unison replicar as alterações, basta criar um arquivo de configuração no home directory do usuário que vai rodar o unison. Preferencialmente, o usuário usado deve ser desprivilegiado e com acesso somente aos diretórios que vai replicar. Feito isso, crie um arquivo de preferencias dentro do diretório ".unison" no Home Directory do usuário.

Uma limitação do Unison é que ele réplica alterações apenas entre dois servidores. Para uma replicação com N servidores, vai ser necessário fazer diversos profiles, cada um replicando com um servidor.

No exemplo a seguir, replicaremos um diretório de Maildirs com o server2, mas apenas as caixas que comecam com as letras "a" a "e". O arquivo fica mais ou menos assim:

  /home/unison/.unison/caixas-a-e.prf
  # Unison preferences file
  root = /diretório/email/
  root = ssh://server2//diretório/email/

  path = Path [abcde]*

  ignore = Name *.log*
  ignore = Name .*

  prefer = newer
  auto = true
  times = true
  log = true
  logfile = /home/unsion/réplica-A-E.log

Agende no cron ou escreve um pequeno shell script que o rode de 1 em 1 minuto, 30 em 30 segundos, a cada hora, tudo depende das suas necessidades. Pra servidores em Stand-by, replicações a cada 1 ou 2 horas são suficientes pra não criar carga no servidor e manter um nivel razoavel de sincrinia. Para casos em que ambas as máquinas estao disponiveis para acesso, vamos precisar de replicas com tempos menores.

Poderiamos usar um shell script assim:

 

  #!/bin/sh

  # Replicador do UNISON

  while true; do
  	unison caixas-a-e
  	sleep 30
  done

Ou uma linha de cron assim:

  */20 * * * * unison caixas-a-e >/dev/null

O script vai re-iniciar a réplica a cada 30 segundos APOS a ultima réplica terminar (se a réplica levar 2 minutos, vai replicar a cada 2 minutos e 30 segundos). Já o cron vai iniciar o unison a cada 20 minutos, independente se a ultima réplica já acabou ou não.

3. Balanço de Carga no WebMail

Uma outra consideração importante sobre a disponibilidade do email e como os usuários vão acessa-lo. Se todos forem ler os emails via POP/IMAP, nosso problema esta resolvido já. No entanto, se forem usar Webmail, tendo ainda mais um pepino pra resolver. Como fazer para que o WebMail também seja capaz de prover serviços em alta disponibilidade e com velocidade?

Se formos colocar o WebMail distribuído em múltiplos web servers, vamos esbarrar no problema das sessoes/logins (imaginando que nosso webmail seja escrito em PHP, talvez até o bem-conhecido Squirrel). As sessoes são locais para o servidor, e não compartilhadas na malha de servidores. E as conexões do usuário "A" para visualizar a lista de Pastas no IMAP, a lista de mensagens no Inbox ou outra pasta qualquér, e pra abrir uma mensagem especifica, cada hora vão cair em um servidor diferente, e, portanto, sem o arquivo de Sessoes do usuário. Vão aparecer aquelas telas chatas pedindo login e senha, ou simplesmente erros.

Assim, uma solução de balanco de carga, contingencia ou alta disponibilidade precisa contemplar esse problema. Uma maneira de resolver isso é tendo um servidor de banco de dados MySQL e fazendo com que o PHP4 guarde as sessoes no banco. É uma alteração simples no PHP e resolve nosso problema de sessoes, mas nos deixa com um novo problema: o ponto único de falha. Se o servidor MySQL der algum problema, todos os webservers param junto com ele.

Podemos compensar essa nossa deficiencia com processos de sincronia e relicação do MySQL, que já parecem razoavelmente estaveis e confiaveis.

3.1. Aceleradores de Login IMAP4

Uma vez resolvido o problema das sessoes compartilhadas, podemos agora pensar em alguns melhoramentos na velocidade de resposta de nosso Webmail conectando no IMAP. Uma maneira de melhorar nossa resposta é com aceleradores de login IMAP.

A causa mais comum de lentidao nos Webmails em grandes sites é o overhead (ou desperdicio de tempo e recursos) que o servidor IMAP tem pra carregar, logar, descarregar o proceso do IMAP da memoria, quando se faz o login, olha as pastas ou mesmo abre uma mensagem.

Imaginando que estamos usando o SquirrelMail, quando um usuário faz o login, o Squirrel abre uma conexão IMAP e faz o login pra conferir usuário e senha, em seguida redireciona pra outra pagina que faz outro login pra conferir se o usuário ainda esta valido, e abre dois frames, com a lista de pastas e a lista de mensagens, ambos fazendo login no servidor IMAP e pegando as informações. Nesse curto espaco de tempo (cerca de/menos de 1 segundo), nosso servidor IMAP já teve que carregar e descarregar o processo "iampd" 4 vezes, indexar ou carregar a indexação das mensagens, consultar o backend de autenticação se for o caso (MySQL, LDAP, etc). Essas operações consomem valiosos ciclos de CPU e memoria que vai e vem da alocação/desalocação dos recursos.

Se pudermos evitar esse abre-e-fecha, já temos um ganho de performance no resultado final do webmail.

Uma ferramenta bastante indicada para isso chama-se "UP Imap Proxy" disponivel em http://www.imapproxy.org

4. Implementações de Fail-Over/Stand-by

Uma das maneiras mais comuns de implementar alta disponibilidade é usar servidores em Fail-Over ou Stand-by, que ficam apenas aguardando erros no servidor principal, prontos para assumirem seu papel.

Projetar um sistema pensando apenas no Fail-Over pode não ser viavel algumas vezes. Quando se tem alta carga ou muitos acessos, e, portanto, um servidor "parrudo", podemos inviabilizar a aquisição de outro servidor de mesmo porte pra substituir o primario em caso de falha. O que algumas empresas fazem é manter um servidor menor em stand-by, que, em caso de queda do servidor primario, vai assumir a carga com mais lentidao, mas não deixara a empresa parada.

Tendo isso em mente, podemos decidir se vamos partir pra Fail-Over ou um ambiente com réplica. Se optarmos pelo Fail-Over ou mesmo uma mistura de ambos, temos algumas pequenas e uteis ferramentas que fazem a verificação do Status do servidor primario e executam ações caso este saia do ar.

Entre os diversos programas que fazem esse tipo de serviço, um que me chamou especial atenção foi o "UCARP" (Userland CARP), baseado no "CARP" (Common Address Redundancy Protocol) originario do OpenBSD, que, por sua vez, foi baseado no VRRP v2 (Virtual Router Redundancy Protocol) da Cisco.

O que todos esses protocolos tem em comum é a meta de estabelecer um meio rapido e eficiente de prover um IP virtual anexao a um mecanismo de detecção de falhas. Um ponto interessante do UCARP é que ele não necessita de uma rede separada para a verificação de disponibilidade de um dos nós, inclusive com comunicação criptografada entre os diversos nós da malha do UCARP.

Por hora, vamos nos ater a ele, embora existam diversas outras opções de verificação Fail-Over.

4.1. Usando o ucarp

A configuaração do UCARP é bastante simples. Basicamente, só são necessários 2 arquivos: um pra quando a nó assumir o IP virtual e outro para quando o nó ceder o IP virtual. Nesses scripts de Up e Down, normalmente so são necessários os comandos de ifconfig com placa virtual ou, mais "moderno", os comandos do iproute2 para adicionar IPs nas placas. Adicionalmente, pode-se incluir programas a serem executados quando o nó assumir como principal.

Chamaremos os scripts de /etc/ucarp/ip-up e /etc/ucarp/ip-down.

  #!/bin/sh
  # /etc/ucarp/ip-up

  /sbin/ip addr add dev eth0 192.168.0.1

 

  #!/bin/sh
  # /etc/ucarp/ip-down

  /sbin/ip addr delete dev eth0 192.168.0.1

As configurações de rede/ip virtual e demais informações são passadas na própria linha de comando pro ucarp assim:

  ucarp --upscript=/etc/ucarp/ip-up --downscript=/etc/ucarp/ip-down --addr=192.168.0.1 \
  	--srcip=192,168.0.50 --vhid=1 --pass=Slackware --preempt --daemonize

No exemplo acima, "addr" indica o IP virtual que vai ser compartilhado, "srcip" o IP pelo qual serao enviadas as consultas ao resto dos UCARP's, "vhid" o identificador do IP virtual (pode-se ter até 255 IPs virtuals/malhas de UCARP distintos na mesma rede), "pass" a senha para consulta a malha, "preempt" pra tentar assumir o IP virtual assim que possivel e "daemonize" pra ir pro background.

4.2. heartbeat e similares

Uma opção ao UCARP é o HeartBeat, que faz basicamente a mesma função. Na epoca da implementação deste tipo de sistema, tive mais afinidade com a configuração simplificada do UCARP e optei por ele.

5. Configurações Distribuídas

Tão importante quanto replicar as caixas e mensagens numa malha de servidor, é replicar também suas configurações, em especial se você tem algum tipo de restrição aplicada, como por exemplo lista de usuários, palavras proibidas, configurações de quota, ou algo semelhante.

As opções mais comuns para esse problema são por utilizar-se de um servidor central, que mantem os originais dos usuários, e replicar isso nos outros nós. Os métodos mais convencionais pra distribuir essas configurações são: rsync, LDAP e MySQL. Cada uma tem as suas vantagens e desvantagens. Vamos considerar algumas delas a seguir.

5.1. Réplicas com rsync

A réplica de arquivos de configuração com rsync é bastante simples e rapida, mas apresenta o inconveniente de ser de um mestre para os nós, e não permitir alterações nos nós. Exemplo:

  #!/bin/sh

  FILES=`rsync --rsh="ssh -l mailsync -i /root/.ssh/id_dsa" -azbupl --stats "172.17.0.27:/opt/geomail/conf/" --exclude "mydomains*" --recursive /opt/geomail/conf/ | grep "^Number of files transferred" | cut -d: -f 2`

  if [ $FILES -gt 0 ]; then
  	( cd /opt/geomail/conf/ ; for i in *.db; do postmap `basename $i .db`; done )
  	postfix reload 2>/dev/null 1>/dev/null
  fi

5.2. Réplicas LDAP

A réplica com LDAP é, talvez, das mais simples de serem feitas. Basta adicionar uma linha pra réplica no slapd.conf, copiar a base (inicial) manualmente, e o LDAP mantem a réplica atualizada.

  /etc/openldap/slapd.conf:

  (...)
  réplica         host=server2 suffix="o=grupogeo" bindmethod=simple binddn="cn=root,o=grupogeo" credentials="lalala"
  replogfile      /var/lib/openldap/réplica/sync-réplica.log
  (...)

So é necessário restartar o processo slapd e iniciar o processo "slurpd" no servidor mestre.

5.3. Réplicas MySQL

Não estou familiriarizado com os processo de réplica do MySQL, mas parecem já estar bastante avancados. Mais informações podem ser encontradas em http://dev.mysql.com/doc/refman/5.0/en/replication.html

6. Outras Opções pra Arquivos Distribuidos

Alem de replicas especificas pra nossos sistemas de correio, existem algumas outras opções que fazem a replicação praticamente Real-Time de todo um filesystem, alguns inclusive prometendo acessos simultâneos.

Nos testes que fiz com essas opções, não achei nenhuma que fizesse esse tipo de réplica com total confiabilidade e toda a funcionalidade necessária para um sistema de alta disponibilidade. Entre as opções que testei, o que mais chegou próximo foi o CodaFS, com replicação razoavelmente integra dentro de um volume distribuído com todas as partes da malha de servidores fazendo atualizações simultâneas. Abaixo, seguem algumas breves considerações sobre cada um.

6.1. CodaFS/Intermezzo/drbd/EVMS e FileSystems Distribuídos Similares

Nos ensaios de replicação, o CodaFS apresentou operações mais confiaveis, mas falhou no suporte a adição ou subtração de mais servidores no volume distribuído. Uma vez criado o volume, não da pra colocar mais servidores, apenas clientes conectados nestes. Ainda assim, os clientes CodaFS são suficientemente "espertos" pra nem perceber quando um dos servidores "cai fora" do volume, fica indisponivel ou algum outro problema. Automaticamente ele pula pra outro e o processo segue ininterrupto.

O Intermezzo promete as operações e configurações mais simplificadas, mas ainda se encontra em desenvolvimento, e não muito utilizavel para aplicações que necessitam de estabilidade. Merece um exame mais profundo, uma vez que promete grandes sucessos para o futuro.

O drbd apresenta um setup mais complexo e as vezes um tanto quanto temperamental, mas no geral, funciona bem naquilo a que se propoe: réplica real-time de dispositivos. Em contra-partida, o drbd admite apenas um único dispositivo montado (alem de ser apenas entre 2 nós), servindo mais para fail-over entre 2 nós.

O EVMS é outro projeto que busca produzir um sistema de Software-RAID incluindo rede.

6.2. NFS/NAS/GFS

Uma opção aos file systems distribuidos são os file systems "centralizados", em que um servidor exporta e disponibiliza dados pra diversas máquinas-cliente. Se a idéia de um ponto único de falha não for muito problematica (com um fileserver "parrudo" e bem configurado), são as soluções que apresentam menos dificuldades na implementação.

NFS - Network File System - velho conhecido da maioria dos administradores Unix/Linux. Se não estiver muito bem configurado e com todos os auxiliares (como sistema de locking de arquivos), torna-se o verdadeiro pesadelo do admin. Não é dos mais rapidos, mas razoavelmente estavel e mais ou menos robusto, o NFS se presta bem a tarefa de exportar um disco ou volume de discos (com RAID, por ex), de um servidor central para diversas estações ou outros servidores pela rede. Note que a segurança das operações sobre NFS é praticamente nula, e pede, portanto, uma rede isolada para a exportação de arquivos.

NAS - Network-Attached Storage - Um sistema, normalmente proprietario, de exportação de dados pela rede. A grande maioria dos sistemas proprietarios usa alguma versão modificada de NFS pra fazer o transporte de dados pela rede. Alguns outros, mais avancados, usam sistemas proprios pra distribuição de dados. Alguns desses podem trafegar os dados por Fibre Channel ou algum outro meio de transporte alternativo ao cabo de rede normal. Suportam operações simultâneas de diversos servidores atualizando a base.

GFS - Global File System - Um projeto um tanto quanto complexo, originalmente da Red Hat, foi "clonado" como OpenGFS. A idéia básica é prover um mecanismo que permita que as máquinas-cliente possam acessar diretamente os dispositivos pela rede, ao inves de falar com um serviço localizado no servidor que conversa com o hardware. A meta básica é prover mecanismos perifericos que controlem o locking sem necessitar de um serviço de locking centralizado.

Conclusão

Vimos muitas opções, e muitas maneiras de melhorar a disponibilidade de sistemas de correio. Espero ter podido, pelo menos, mostrar as opções disponiveis. Cada um deve agora escolher a solução que melhor se encaixa no ambiente e nas aspirações de sua empresa. Qualquér que seja o caminho escolhido, vai requerer tempo e energia até conseguir um ambiente estavel e "redondo" :)

Contato: Deives Michellis "thefallen"

Email: O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo. O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo.

Links e Biografia

Postfix - http://www.postfix.org/

Iptables - http://www.netfilter.org/

Courier IMAP/POP3 - www.courier-mta.org/imap/

Dovecot IMAP/POP3 - http://www.dovecot.org/

Perdition IMAP/POP Proxy - http://www.vergenet.net/linux/perdition/

UP-Imap Proxy - http://www.imapproxy.org/

Unison File Sinchronizer - http://www.cis.upenn.edu/~bcpierce/unison/

Ucarp - http://www.ucarp.org/

heartbeat - http://www.linux-há.org/

rsync - http://samba.anu.edu.au/rsync/

LDAP - http://www.openldap.org/

MySQL - http://www.mysql.com/

CodaFS - http://www.coda.cs.cmu.edu/

Intermezzo - http://www.inter-mezzo.org/

drbd - http://www.drbd.org/

EVMS - http://evms.sourceforge.net/

NFS - http://www.nfsv4.org/

GFS - http://www.opengfs.org/

 

 

Fonte: http://www.unitednerds.org/thefallen/docs/?area=Postfix&tuto=Palestra-HA-Email#toc13

.