Carregar Gateways de Correio de Equilíbrio

Question

No momento, estou tentando encontrar uma maneira de carregar o equilíbrio de nossos quatro gateways de correio (Running Mail Cleaner). Consegui abrir o HAProxy e usar o modo tcp para carregar o saldo sem problemas. O único problema real sendo meu IP de Origem é sempre o servidor HAProxy, então algumas das verificações do meu filtro de correio são inúteis agora porque não consigo verificar se o e-mail está vindo de um relé ruim conhecido.

Existe algum software FLOSS que possa ser usado para lidar com esse tipo de situação? Eu sei que o HAProxy tem essa habilidade se eu tiver o Mail Gateways como o Default Gateway, e compilar alguns módulos adicionais e configurar o iptables. Eu só não quero começar esse caminho se eu estiver perdendo uma solução mais fácil.

    

Answer 1

Fazemos isso simplesmente usando o Servidor Virtual Linux , que faz parte do kernel padrão do Linux para alguns anos agora.

Ele permite o balanceamento de carga baseado em peso e é muito fácil de configurar, estamos fazendo algo assim:

ipvsadm -A -t 192.168.0.3:25 -s wrr
ipvsadm -a -t 192.168.0.3:25 -r 192.168.0.8:25 -g -w 100
ipvsadm -a -t 192.168.0.3:25 -r 192.168.0.9:25 -g -w 100

(onde 192.168.0.3 é seu "IP de serviço" ou "IP virtual" e 192.168.0.8 e 192.168.0.9 são seus "servidores reais" )

O mais importante é saber - o modo de operação. Esta configuração usa o "modo de gateway", no qual a origem e o destino dos pacotes não são alterados. Mas isso tem algumas implicações. O virtual ip tem que ser configurado em todos os "servidores reais". Mas isso pode levar a condições de corrida ARP que você deve evitar por design:

• Seus "servidores reais" estão atrás do balanceador de carga em uma LAN separada
• OU você configura seus servidores reais para não responder ao ARP para o endereço virtual
• OU você está roteando o IP virtual diretamente para seu balanceador de carga, por isso não é ARPed para

Talvez -m - o modo de mascaramento seja um pouco mais fácil de configurar.

E - outra dica aqui: você pode querer usar o keepalived que configura o ipvsadm, monitora seu servidor de e-mail para reachabilty e talvez forneça redundância para o próprio balanceador de carga usando VRRP.

Estamos usando o ipvs para lidar com o balanceamento de carga DNS de 15k do CPS.

(*) pelo menos no debian é chamado assim, mas procurar por ipvs deve ser fácil

    

Answer 2

O SMTP incorporou o balanceamento de carga usando o DNS, de maneira round robin. Isso funciona muito bem para a maioria dos propósitos. Se isso não for suficiente para você, você terá que criar sua própria configuração personalizada, que não é uma tarefa fácil. Então, a menos que você realmente precise, eu ficaria com o que está disponível e amplamente usado.

Estou assumindo que seus servidores de e-mail (MTA) estão no mesmo domínio (digamos example.org). Nesse caso, crie um registro MX para cada MTA separado, com a mesma prioridade. Usar a mesma prioridade garante que cada servidor seja testado de forma round robin, caso contrário, aquele com a maior prioridade (menor número) é sempre tentado primeiro (no caso de MTAs que não estão quebrados, os spammers adoram atingir o servidor com menor prioridade pensando que pode ser um servidor de "fallback" de baixa especificação):

example.org.    IN  MX  10  mx1.example.org.
example.org.    IN  MX  10  mx2.example.org.
example.org.    IN  MX  10  mx3.example.org.
example.org.    IN  MX  10  mx4.example.org.

Certamente, certifique-se de que cada mx * possa ser resolvido:

example.org.    IN      A       192.168.2.1
mx1     IN      A       192.168.2.2
mx2     IN      A       192.168.2.3
mx3     IN      A       192.168.2.4
mx4     IN      A       192.168.2.5

Se você quiser também usar o DNS para "balancear a carga" MTAs para que seus usuários enviem e-mails, você poderá configurar o DNS dessa maneira. Vamos chamar o seu servidor de saída smtp.example.org e pedir aos usuários que enviem e-mails para ele. Eu coloquei "load balance" entre aspas porque isso não evitará conectar-se a um servidor que está abaixo do modo como os MTAs lidam com ele usando registros MX. Nesse caso, o usuário deve tentar novamente uma ou mais vezes para atingir um servidor em funcionamento.

smtp    IN      A       192.168.2.2
smtp    IN      A       192.168.2.3
smtp    IN      A       192.168.2.4
smtp    IN      A       192.168.2.5

Esta é uma solução grosseira, pois dependendo do sistema e da configuração do usuário, eles podem continuar tentando atingir apenas um IP. Mas pelo menos não é "para baixo para todos" e você sempre pode direcioná-los para um servidor em funcionamento. Além disso, se um servidor estiver permanentemente inativo, você poderá removê-lo do DNS e, uma vez armazenado em cache, deve impedir que seus usuários o ataquem. Neste caso, haproxy pode não ser uma solução tão ruim.