Início / server / Perguntas / 738440
Accepted
Jacob Evans
Asked: 2015-11-24 12:35:39 +0800 CST

Multiple MX ou Round-Robin A Record

  • 772

Qual é melhor e por que?

Existem 2 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 o balanceamento de carga de custo igual de 2 servidores, posso configurá-los 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 tentarão novamente ambos os endereços IP 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

*Assuma que todas as outras variáveis ​​são as melhores práticas (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
domain-name-system

2 respostas

  1. Best Answer

    A solução mais preferível para balancear igualmente a carga é usar um balanceador de carga real . Na falta disso, você está em dívida com os caprichos de quão mal qualquer MTA implementou os RFCs.

    Em um mundo perfeito, qualquer uma dessas soluções que você mencionou estaria bem, no entanto, no mundo real, você provavelmente verá uma divisão constante de carga de 60/40, na melhor das hipóteses. Isso ocorre porque, embora os RFCs de e-mail e DNS possam ter muitos DEVEM e DEVEM de aparência assustadora em relação à randomização durante a seleção do host, o fato é que os programadores são preguiçosos e não há como o servidor rejeitar conexões devido à seleção preguiçosa do host.

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

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

    O melhor equilíbrio que consegui encontrar 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 equilibrar 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 MX mais baixo.

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

    Origem: administrei um cluster MX de 10 nós que atende a mais de 10.000 domínios. [E aquele com o IP mais baixo ainda obteve 30% do tráfego geral e acabamos tornando-o uma máquina mais robusta :I]

    • 5

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

    Para simplificar, eu ficaria com o primeiro cenário, pois só precisaria rastrear um registro MX (menos um registro DNS ... não é grande coisa, mas pelo menos uma parte móvel a menos).

    Como o Google utiliza isso é usar a flexibilidade do balanceamento de carga do DNS junto com os recursos de fallback dos registros MX ponderados, que é a única parte da qual você não precisa aproveitar (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 entre esses endereços. Mas se esses endereços não responderem, pode cair nas prioridades MX para tentar o próximo registro na linha, e assim por diante.

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

    • -1

relate perguntas