Múltiplo MX ou Round-Robin A Record

Question

Qual é melhor e por quê?

Existem dois filtros de e-mail de entrada, eles estão em um cluster com especificações de hardware iguais e podem lidar com a mesma carga. Esta é uma nova configuração e gostaria de saber qual é a melhor maneira de lidar com balanceamento de carga de custo igual de 2 servidores, posso definir ambos para usar o mesmo nome de host (ehlo) e os mesmos certificados, eles atualmente usam um certificado que inclui todos os 3 nomes, sendo o nome comum mx.

Em qualquer um dos cenários, os servidores IP serão tentados novamente no caso de uma interrupção de 1 dos servidores.

Cenário 1

example.com. IN MX 10 mx.example.com.
mx.example.com. IN A 10.0.0.10
mx.example.com. IN A 172.31.0.10

Cenário 2

example.com. IN MX 10 mx1.example.com.
example.com. IN MX 10 mx2.example.com.
mx1.example.com. IN A 10.0.0.10
mx2.example.com. IN A 172.31.0.10

* Suponha que todas as outras variáveis sejam práticas recomendadas (FCrDNS, SPF, ETC)

O Google parece fazer AMBOS.

;;Answer
gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com"
gmail.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. (2015031901 21600 3600 1209600 300)
gmail.com. 345600 IN NS ns1.google.com.
gmail.com. 345600 IN NS ns2.google.com.
gmail.com. 345600 IN NS ns3.google.com.
gmail.com. 345600 IN NS ns4.google.com.
gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 300 IN AAAA 2607:f8b0:4006:80c:0:0:0:1015
gmail.com. 300 IN A 173.194.123.85
gmail.com. 300 IN A 173.194.123.86
gmail-smtp-in.l.google.com. 300 IN AAAA 2607:f8b0:400c:c00:0:0:0:1a
gmail-smtp-in.l.google.com. 300 IN A 74.125.134.26
gmail-smtp-in.l.google.com. 300 IN A 74.125.134.27

    

Answer 1

A solução mais preferível para equilibrar a carga é usar um balanceador de carga real . Se você não estiver comprometido com os caprichos de quão mal determinado MTA implementou os RFCs.

Em um mundo perfeito, qualquer uma dessas soluções que você mencionou seria boa, mas no mundo real você provavelmente verá uma divisão de carga constante de 60/40, na melhor das hipóteses. Isso ocorre porque, embora os RFCs de e-mail e DNS possam ter muitos SHOULDs e MUSTs assustadores em relação à aleatorização durante a seleção do host, permanece o fato de que os programadores são preguiçosos e não há como o servidor rejeitar conexões devido à seleção de hosts preguiçosos. p>

As duas situações que você verá são:

1. Tráfego atingindo o primeiro registro.
2. Tráfego atingindo o primeiro registro após a classificação dos registros disponíveis.

O melhor equilíbrio que consegui atingir foi atribuir os IPs mais altos aos MXes mais baixos. No seu caso, isso significaria:

example.com. IN MX 10 mx1.example.com.
example.com. IN MX 10 mx2.example.com.
mx1.example.com. IN A 172.31.0.10
mx2.example.com. IN A 10.0.0.10

Isso deve ajudar a balancear as coisas, já que o PWM [MTA mal escrito] # 1 preferirá o nome de registro MX mais baixo, enquanto o PWM # 2 preferirá o IP de menor MX.

Mas, como eu disse, você nunca verá um verdadeiro equilíbrio.

Fonte: eu administrei um cluster MX de 10 nós que atende mais de 10.000 domínios. [E aquele com o IP mais baixo ainda tem 30% do tráfego total e acabamos fazendo com que seja uma máquina mais robusta :I ]

    

Answer 2

Ambos funcionarão exatamente da mesma maneira para você. Nos dois casos, você está configurando uma configuração de balanceamento de carga de DNS, permitindo que você utilize os dois servidores listados para responder a solicitações de SMTP. Mesmo olhando para o número de consultas, em ambos os casos, você teria duas consultas DNS (uma para o registro MX, uma para o registro A), portanto, não deveria haver diferença de desempenho.

Por razões de simplicidade, eu ficaria com o primeiro cenário, já que eu precisaria apenas rastrear um registro MX (um registro DNS a menos ... não é grande coisa, mas pelo menos uma parte menos móvel).

Como o google utiliza isso é usar a flexibilidade do balanceamento de carga DNS, juntamente com os recursos de fallback dos registros MX ponderados, que é a única parte da qual você não precisa tirar proveito (pelo menos de acordo com seus cenários).

Portanto, se você observar que o registro MX principal com um peso de 5 é aquele com vários registros A. Então, quando tudo está funcionando corretamente, eles estão dividindo o tráfego nesses endereços. Mas se esses endereços não responderem, eles poderão cair nas prioridades do MX para tentar o próximo registro na linha, e assim por diante.

A maioria das configurações pequenas (pequenas em comparação com o gmail, yahoo, etc.) eu vi não balanceamento de carga (pelo menos não com balanceamento de carga DNS) e em vez disso use MX ponderado para cair através de uma lista de manipuladores SMTP preferidos. Na verdade, tudo se resume à configuração que fornece a flexibilidade de que você precisa.