Partilhar via

Entendendo o failover de SMTP e o balanceamento de carga em transporte

  • Artigo

 

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2016-11-28

Quando você tem vários servidores de Transporte de Hub em sua organização, o Exchange automaticamente distribui o tráfego de mensagens. A distribuição da carga ocorre com êxito quando feita de maneira uniforme quando todos os servidores estão disponíveis. Entretanto, quando um ou mais servidores estão indisponíveis, a distribuição da carga pode se tornar desigual entre os servidores, especialmente se a sua organização estiver distribuída entre vários sites do Active Directory.

No Microsoft Exchange Server 2010 Service Pack 1 (SP1), inúmeras melhorias foram feitas no mecanismo de tomada de decisões para distribuir a carga entre os servidores de Transporte de Hub.

Procurando tarefas de gerenciamento relacionadas ao roteamento de mensagens? Consulte Gerenciando Roteamento de Mensagens.

Conteúdo

Comportamento do Exchange Server 2010 RTM

Aprimoramentos do Exchange 2010 SP1

Balanceamento de Carga de Rede do Windows ou soluções de balanceamento de carga de terceiros com servidores de transporte

Comportamento do Exchange Server 2010 RTM

Na versão RTM do Exchange 2010, quando um servidor de transporte precisa rotear diversas mensagens para o mesmo destino, o servidor inicialmente determina o próximo salto para essas mensagens. Se houver vários servidores de destino para esse próximo salto, ele balanceará a carga da conexão usada para entregar as mensagens igualmente entre os servidores de destino usando o modo round robin fornecido pelo DNS aprimorado. Por exemplo, considere uma topologia na qual você tem dois sites do Active Directory com três servidores de Transporte de Hub em cada um (como mostrado na figura seguinte). Quando um servidor de Transporte de Hub no Site A (por exemplo, Hub02) precisa enviar mensagens ao Site B, o próximo salto para essa mensagem é o Site B. Há três destinos possíveis no próximo salto: Hub04, Hub05 e Hub06. O servidor distribuirão o número de conexões uniformemente entre esses três destinos, como mostra a figura a seguir. A ação resulta em uma distribuição uniforme das mensagens entre as conexões com o tempo.

Balanceamento de carga no Exchange Server 2010 RTM

Da mesma forma, os servidores de Transporte de Hub no Site B distribuirão o número de mensagens enviadas aos destinatários no Site A uniformemente entre os Hub01, Hub02 e Hub03. Além disso, como Edge01 está registrado no Site A, os destinos do próximo salto de mensagens enviadas à Internet são Hub01, Hub02 e Hub03.

Surgirá um problema se um ou mais dos servidores estiverem indisponíveis no próximo salto. Por exemplo, considere que o Hub04 no Site B está indisponível para manutenção programada. Os servidores no Site A não mantêm o status de disponibilidade de cada servidor no Site B. Os servidores no Site A distribuirão a carga destinada para o Site B entre os três servidores de Transporte de Hub nesse site. Entretanto, aproximadamente um terço dessas conexões será enviada ao Hub04, mas falharão. Ocorrerá o failover dessas conexões para o próximo servidor disponível, e um dos servidores de Transporte de Hub no Site B processará muito mais carga do que o outro servidor, como indicado na figura a seguir.

Balanceamento de carga desigual

Esse comportamento indesejado poderá ocorrer sempre que houver um servidor indisponível no próximo salto que geralmente tem mais de dois destinos. O próximo salto poderá ser outro site do Active Directory, como mostrado no exemplo anterior, ou um conector que tem vários servidores de Transporte de Hub listados como o servidor de origem (por exemplo, o conector de Envio para o servidor de Transporte de Borda registrado na topologia mostrada nas figuras anteriores).

Isso não é um problema relativo aos envios de mensagens dos servidores de Caixa de Correio. O serviço de envio de mensagens detectará os servidores de Transporte de Borda indisponíveis em um site e não tentará entregar mensagens a esses servidores. No exemplo mostrado anteriormente, embora um dos servidores de Transporte de Hub do Site B possa ter uma carga mais pesada do tráfego entre sites, a carga gerada pelos servidores de Caixa de Correio do Site B será dividida uniformemente entre Hub05 e Hub06.

Comportamento do Exchange Server 2010 RTM

Aprimoramentos do Exchange 2010 SP1

Para cuidar do problema descrito na seção anterior, um novo componente chamado Seletor de Servidor Íntegro foi adicionado ao Exchange 2010 SP1. O Seletor de Servidor Íntegro mantém uma lista de servidores indisponíveis. Essa lista é usada pelo DNS aprimorado para filtrar todos os servidores indisponíveis na aplicação da lógica round robin para balanceamento de carga. Para mostrar como o Seletor de Servidor Íntegro ajuda no balanceamento de carga, considere a condição problemática mostrada na figura anterior. No Exchange 2010 SP1, o DNS aprimorado irá primeiro compilar a lista de destinos potenciais no próximo salto, Site B. Em seguida, ele solicitará que o Seletor de Servidor Íntegro filtre a lista. O Seletor de Servidor Íntegro informará que o Hub04 para o Site B do próximo salto não é íntegro. O DNS aprimorado removerá Hub04 da lista de destinos potenciais do Site B do próximo salto e usará o balanceamento round robin somente entre Hub05 e Hub06, como indicado na figura seguinte.

Balanceamento de carga com Seletor de Servidor Íntegro

Seletor de Servidor Íntegro

Em sua forma mais simples, o Seletor de Servidor Íntegro acompanha os servidores considerados não íntegros para que esses servidores não sejam incluídos no balanceamento de carga round robin. A partir da perspectiva de um Seletor de Servidor Íntegro, a definição de um servidor não íntegro é a de que uma tentativa de conexão retorna qualquer código de erro de Windows Sockets (Winsock).

Para cada servidor não íntegro, o Seletor de Servidor Íntegro mantém as seguintes informações:

  • Endereço IP do servidor

  • Contagem de repetições

  • Horário da última tentativa

Comportamento de repetições

Quando um servidor for marcado como não íntegro, o Seletor de Servidor Íntegro assegurará que as conexões para esse servidor específico sejam repetidas novamente para se detectar quando esse servidor fica online. O Seletor de Servidor Íntegro usa as seguintes configurações para determinar com que frequência as conexões serão repetidas para um servidor não íntegro:

  • QueueGlitchRetryInterval e QueueGlitchRetryCount   Essas configurações determinam quantas vezes e em qual intervalo o Seletor de Servidor Íntegro repete as conexões com um servidor específico quando ele é marcado primeiro como não íntegro. Essas configurações são definidas no arquivo EdgeTransport.exe.config. Os valores padrão para essas configurações são 1 minuto e 4 tentativas de repetição. Esses valores indicam que uma conexão com um servidor não íntegro será tentada a cada minuto quatro vezes em uma configuração padrão.

  • TransientFailureRetryInterval e TransientFailureRetryCount   Se um servidor não íntegro ficar indisponível, essas configurações serão usadas pelo Seletor de Servidor Íntegro para determinar a frequência do próximo conjunto de tentativas de repetição. Essas configurações são definidas para cada servidor de transporte. Os valores padrão são 5 minutos (10 minutos em um servidor de Transporte de Borda) e 6 tentativas de repetição. Esses valores indicam que uma conexão com um servidor não íntegro será tentada a cada cinco minutos seis vezes após os primeiros quatro minutos em uma configuração padrão.

  • OutboundConnectionFailureRetryInterval   Se o servidor não íntegro estiver indisponível o Seletor de Servidor Íntegro continuará repetindo a conexão na frequência especificada nesse parâmetro. Essa configuração é definida para cada servidor de transporte. O valor padrão é de 10 minutos (30 minutos em um servidor de Transporte de Borda). Isso significa que uma conexão com um servidor não íntegro será tentada a cada 10 minutos após os primeiros 34 minutos em uma configuração padrão.

Para obter instruções passo a passo sobre como definir essas configurações, consulte Configurar Intervalos de Repetição, Reenvio e Expiração de Mensagens.

Quando for o momento de repetir uma conexão, o Seletor de Servidor Íntegro permitirá apenas uma tentativa de conexão com o servidor não íntegro. Se essa conexão der certo, o componente de saída SMTP notificará o Seletor de Servidor Íntegro que a conexão foi estabelecida. Nesse ponto, o Seletor de Servidor Íntegro remove o servidor da lista de servidores não íntegros..

Seletor de Servidor Íntegro e redundância de sombra

O componente de redundância de sombra de transporte inclui um recurso de pulsação. A pulsação é uma conexão SMTP simples usada para consultar o status das mensagens previamente enviadas a um servidor de destino. A filtragem do Seletor de Servidor Íntegro não impede que o Gerenciador de Redundância de Sombra emita tentativas de conexão de pulsação. Se um servidor tiver mensagens de sombra enviadas a um servidor não íntegro, ele tentará estabelecer conexões de pulsação com esse servidor. Se uma conexão de pulsação for estabelecida com um servidor não íntegro, esse servidor de destino será imediatamente removido da lista de servidores não íntegros pelo Seletor de Servidor Íntegro.

Para saber mais sobre a redundância de sombra e a pulsação, consulte Noções Básicas Sobre Redundância de Sombra.

Informações de diagnóstico

No Exchange 2010 SP1, os logs de conectividade incluem informações de diagnóstico para o Seletor de Servidor Íntegro e os recursos de balanceamento de carga aprimorados. Quando um servidor é adicionado à lista de servidores não íntegros pelo Seletor de Servidor Íntegro, o evento é registrado no log de conectividade. Para localizar esse evento, procure a expressão MarkedUnhealthy no log de conectividade. Na linha que contém essa expressão, você pode encontrar as seguintes informações:

  • Endereço IP do host de destino

  • Nome de domínio totalmente qualificado (FQDN) do host de destino

  • Erro de Winsock recebido

  • Status: MarkedUnhealthy

  • Contagem atual de falhas

  • Horário da próxima tentativa

A partir dessa entrada, você pode identificar o motivo da falha avaliando o código de erro de Winsock. Para obter uma lista completa de códigos de erro de Winsock e suas definições, consulte Windows Sockets Error Codes (Códigos de erro de Windows Sockets; em inglês).

Você pode determinar também quantas tentativas de conexão falharam e a próxima tentativa de repetição programada para o servidor de destino por meio da análise dos campos Current Failure Count e Next Retry Time.

O registro em log deve estar habilitado nos seus servidores de transporte para que seja possível ver essas informações de diagnóstico. O registro em log fica desabilitado por padrão nos servidores de Transporte de Hub e de Transporte de Borda. Para obter mais informações sobre como configurar o registro em log de conectividade, consulte Configurar Log de Conectividade.

Comportamento do Exchange Server 2010 RTM

Balanceamento de Carga de Rede do Windows ou soluções de balanceamento de carga de terceiros com servidores de transporte

Como já foi comentado neste tópico, o Exchange 2010 equilibra automaticamente a carga de todo o tráfego de mensagens dentro da organização entre servidores de Transporte de Borda, Transporte de Hub e Caixa de Correio usando DNS aprimorado. No entanto, essa funcionalidade não cobre o balanceamento de carga de mensagens recebidas de fontes que não sejam o Exchange, como servidores de correio externos, soluções antispam ou antivírus de terceiros, servidores de correio internos fora de sua organização do Exchange, aplicativos de LOB (linha de negócios) e clientes de email baseados em POP ou IMAP.

Se você tiver uma ou mais dessas fontes de correio, pode optar por balancear a carga do tráfego SMTP de entrada usando um namespace SMTP (como smtp.contoso.com) que distribua mensagens de email externas pelos servidores de transporte na organização. O NLB (Balanceamento de Carga de Rede do Windows) ou uma solução de balanceamento de carga de terceiros baseada em hardware são suportados. Para uma lista de balanceadores de carga testados pelo fornecedor e analisados pela Microsoft para atender aos requisitos do Exchange 2010, consulte Implantação de balanceador de carga nas comunicações unificadas da Microsoft.

Importante

Não há suporte ao uso de uma solução de balanceamento de carga para lidar com o tráfego de mensagens entre os servidores do Exchange em sua organização. É necessário excluir o tráfego de mensagens entre os servidores do Exchange de qualquer solução de balanceamento de carga que for implantada em seu ambiente.

Balanceando a carga de mensagens de Internet de entrada entre seus servidores de Transporte de Borda

A situação mais comum é lidar com as mensagens de entrada a partir da Internet. Não é necessário implantar uma solução de balanceamento de carga para distribuir a carga entre seus servidores de Transporte de Borda. Para fazer isso, use round robin de DNS e registros MX que tenham o mesmo valor de preferência, como mostra a figura a seguir.

Balanceamento de carga de mensagens da Internet usando round robin de DNS e registros MX

Se optar por usar o NLB do Windows ou uma solução de hardware de balanceamento de carga para distribuir mensagens de entrada da Internet, você terá que publicar um único registro MX que aponte para sua solução de balanceamento de carga. O balanceador de carga distribuirá as mensagens de entrada para todos os servidores de Transporte de Borda listados em sua configuração, como mostra a figura a seguir.

Distribuindo mensagens da Internet usando uma solução de balanceamento de carga

Balanceando a carga de mensagens que não sejam do Exchange entre seus servidores de Transporte de Hub

O Exchange 2010 usa Conectores de recebimento para aceitar mensagens de entrada. Por padrão, quando um servidor de Transporte de Hub do Exchange 2010 recebe uma mensagem de email via SMTP pela porta TCP 25, ela é processada pelo Conector de recebimento chamado Conector de recebimento padrão.

Quando um cliente POP ou IMAP envia uma mensagem de email a um servidor de Transporte de Hub do Exchange 2010, a mensagem é enviada pela porta TCP 587 por padrão. Isso significa que as mensagens de email enviadas a partir de clientes POP ou IMAP são processadas por um Conector de recebimento separado chamado Conector de recebimento cliente padrão.

Caso pretenda posicionar uma solução de balanceamento de carga em frente aos seus servidores de Transporte de Hub, você deve criar um Conector de recebimento separado para esse fim e certificar-se de que apenas tráfego processado por esse conector específico esteja sujeito ao balanceamento de carga. Para fazer isso, inclua um endereço IP adicional no servidor de Transporte de Hub e associe esse endereço IP ao novo Conector de recebimento. Além disso, a opção de Autenticação do Exchange Server deve ser desativada no Conector de recebimento para garantir que tráfego do Exchange não seja encaminhado sobre ele. A figura a seguir mostra uma configuração na qual um balanceador de carga é usado para distribuir as mensagens recebidas de clientes POP3 ou IMAP4 e servidores SMTP que não sejam do Exchange entre dois servidores de Transporte de Hub.

Balanceando a carga de mensagens que não sejam do Exchange entre servidores de Transporte de Hub

Balanceamento de carga de rede do Windows

O NLB (Balanceamento de Carga de Rede) do Windows é o software mais comum de balanceamento de carga usado para servidores do Exchange. Há algumas limitações associadas à implantação do NLB do Windows com servidores de Transporte de Hub do Exchange 2010:

  • O NLB do Windows não pode ser usado em servidores do Exchange nos quais as funções de servidor Transporte de Hub e Caixa de Correio coexistam e o servidor também participe de um DAG (grupo de disponibilidade de banco de dados).

    Isso acontece porque o recurso de NLB do Windows é incompatível com o clustering de failover do Windows. Se você estiver usando um DAG do Exchange 2010 e quiser utilizar o NLB do Windows, será necessário executar a função de servidor Transporte de Hub e a função de servidor Caixa de Correio em computadores separados. Além disso, o NLB do Windows afeta o roteamento de mensagens quando o membro do DAG e a função de servidor Transporte de Hub coexistem no mesmo servidor. Para saber mais, consulte Coexistência de Funções de Servidor de Caixa de Correio e Transporte de Hub ao Usar DAGs.

  • Não recomendamos que se coloquem mais que oito servidores de Transporte de Hub em uma matriz que está tendo a carga balanceada pelo NLB do Windows. Caso precise balancear a carga de mais de oito servidores de Transporte de Hub, implante uma solução baseada em hardware.

  • O NLB do Windows não detecta interrupções de serviço.

    Ele detecta apenas interrupções de serviço por endereço IP. Se o serviço de Transporte do Exchange falhar, mas o servidor continuar funcionando, o NLB do Windows não detectará a falha e continuará encaminhando mensagens de email de entrada para esse servidor de Transporte de Hub. Será necessário intervir manualmente para remover do pool de balanceamento de carga o servidor de Transporte de Hub que está passando por interrupções.

  • A configuração do NLB do Windows pode resultar em saturação da porta, o que pode sobrecarregar as redes.

    Isso acontece porque o NLB do Windows foi projetado de modo a entregar simultaneamente todos os pacotes de cliente de entrada a todas as portas de comutador. Embora esse comportamento permita ao NLB do Windows oferecer uma taxa de transferência muito alta, ele também pode ocupar demais o comutador.

Para obter instruções detalhadas sobre a configuração do NLB do Windows, consulte Configurar balanceamento de carga de rede no Windows para servidores de transporte de hub.

Balanceador de carga de hardware

Caso possua mais de oito servidores de Transporte de Hub para os quais deseje o balanceamento de carga de tráfego de mensagens que não sejam do Exchange, você vai precisar de uma solução de balanceamento de carga mais dimensionável. Embora haja soluções robustas de balanceamento de carga disponíveis, uma solução de balanceamento de carga de hardware proporciona a mais alta capacidade.

Ao contrário do NLB do Windows, que detecta apenas interrupções do servidor por endereço IP, um balanceador de carga de hardware pode ser configurado para detectar a falha do serviço de Transporte do Exchange e pode rotear mensagens de email de entrada para outros servidores de Transporte de Hub sem qualquer intervenção manual.

Para obter instruções detalhadas sobre a configuração de uma solução de balanceamento de carga de hardware, consulte Configurar balanceamento de carga de hardware para servidores de transporte de hub.

 © 2010 Microsoft Corporation. Todos os direitos reservados.