Balanceamento de carga no Exchange Server

Balanceamento de carga no Exchange 2016 e posterior compilação na plataforma de alta disponibilidade e resiliência de rede da Microsoft entregue no Exchange 2013. Quando isso é combinado com a disponibilidade de soluções de balanceamento de carga de terceiros (hardware e software), há várias opções para implementar o balanceamento de carga em sua organização do Exchange.

As alterações de arquitetura do Exchange introduzidas no Exchange 2013 trouxeram as funções de servidor de Caixa de Correio e servidor de Acesso ao Cliente. Compare isso com o Exchange 2010, em que o Acesso ao Cliente, a Caixa de Correio, o Transporte do Hub e as Mensagens Unificadas são executados em servidores separados.

Usando funções mínimas de servidor, o Exchange 2016 e 2019 entrega:

• Implantação simplificada com o servidor mailbox executando serviços de Acesso ao Cliente e funções de servidor de Transporte de Borda.

• Fluxo de email gerenciado no pipeline de transporte, que é a coleção de serviços, conexões, filas e componentes que encaminham mensagens para o categorizador de serviço de transporte no servidor da caixa de correio.

• Alta disponibilidade implantando balanceadores de carga para distribuir o tráfego do cliente.

O padrão de protocolo HTTP introduzido com o Exchange 2013 significa que a afinidade de sessão não é mais necessária no Exchange 2016 e no Exchange 2019. A afinidade de sessão permite uma conexão persistente para serviços habilitados para mensagens para que um usuário não precise reentradar seu nome de usuário e senha várias vezes.

Anteriormente, o Exchange 2007 e o Exchange 2010 dão suporte ao RPC por HTTP para Outlook Anywhere. O Exchange 2013 introduziu o MAPI por HTTP, embora não estivesse habilitado por padrão. Agora está habilitado por padrão no Exchange 2016 e no Exchange 2019.

Com o protocolo HTTP em uso, todos os clientes nativos se conectam usando HTTP e HTTPs em Exchange Server. Esse protocolo padrão remove a necessidade de afinidade, que antes era necessária para evitar uma nova solicitação de credenciais de usuário sempre que o balanceamento de carga redirecionava a conexão para um servidor diferente.

Funções de servidor no Exchange Server

O número reduzido de funções de servidor para o Exchange 2016 e o Exchange 2019 simplifica os requisitos de implementação e hardware do Exchange. O número de funções de servidor no Exchange 2016 e 2019 diminui de sete para dois: o servidor mailbox e o servidor de Transporte de Borda. A função de servidor da caixa de correio inclui serviços de Acesso ao Cliente, enquanto o servidor do Edge Transport fornece fluxo de email seguro no Exchange 2016 e no Exchange 2019, assim como fez em versões anteriores do Exchange.

No Exchange 2013, a função de servidor de Acesso ao Cliente garantiu que, quando um usuário tentasse acessar sua caixa de correio, o servidor proxieu a solicitação de volta para o servidor mailbox atendendo ativamente a caixa de correio do usuário. Isso significava que serviços como Outlook na Web (anteriormente conhecidos como Outlook Web App) eram renderizados para o usuário na própria Caixa de Correio, removendo qualquer necessidade de afinidade.

A mesma funcionalidade permanece no Exchange 2016 e no Exchange 2019. Se dois servidores de caixa de correio hospedarem caixas de correio diferentes, eles poderão fazer proxy de tráfego um para o outro quando necessário. O servidor de caixa de correio que hospeda a cópia ativa da caixa de correio serve ao usuário que o acessa, mesmo que o usuário se conecte a um servidor de caixa de correio diferente.

Leia mais sobre as alterações de função do servidor no Exchange Server no artigo, Exchange Server arquitetura.

Embora não seja necessário, o servidor de Transporte de Borda fica na rede de perímetro, como nas versões anteriores do Exchange, para fornecer fluxo de email de entrada e saída seguro para sua organização do Exchange.

Leia mais sobre o serviço de transporte no artigo, Entendendo o serviço de transporte em servidores de Transporte de Borda.

Protocolos em Exchange Server

A partir do Exchange 2016, todos os clientes nativos do Exchange usam o protocolo HTTP para se conectar a um serviço designado, com cookies HTTP fornecidos ao usuário no logon criptografados usando o certificado SSL dos serviços de Acesso ao Cliente. Um usuário conectado pode retomar a sessão em um servidor de caixa de correio diferente executando serviços de Acesso ao Cliente sem reautenticar. Os servidores que usam o mesmo certificado SSL podem descriptografar o cookie de autenticação do cliente.

O HTTP possibilita o uso de verificações de integridade de serviço ou aplicativo em sua rede do Exchange. Dependendo da solução do balanceador de carga, você pode implementar investigações de integridade para verificar diferentes componentes do sistema.

O efeito do acesso somente HTTP para clientes é que o balanceamento de carga também é mais simples. Se você quisesse, poderia usar o DNS para balancear o tráfego do Exchange. Você forneceria ao cliente o endereço IP de cada servidor da Caixa de Correio e o cliente HTTP lidaria com as tarefas. Se um servidor exchange falhar, o protocolo tentará se conectar a outro servidor. No entanto, há desvantagens para o balanceamento de carga para DNS, discutido na seção a seguir Opções de balanceamento de carga no Exchange Server.

Leia mais sobre HTTP e Exchange Server no artigo MAPI sobre HTTP em Exchange Server.

Opções de balanceamento de carga no Exchange Server

No exemplo mostrado aqui, vários servidores configurados em um DAG (grupo de disponibilidade de banco de dados) hospedam os servidores da caixa de correio que executam os serviços de Acesso ao Cliente. Isso fornece alta disponibilidade com uma pequena pegada de servidor do Exchange. O cliente se conecta ao balanceador de carga em vez de diretamente aos servidores do Exchange. Não há nenhum requisito para pares de balanceador de carga, no entanto, recomendamos implantar em clusters para melhorar a resiliência da rede.

Esteja ciente de que os DAGs usam os Serviços de Clustering da Microsoft. Esses serviços não podem ser habilitados no mesmo servidor que o NLB (Balanceamento de Carga de Rede do Windows). Assim, o Windows NLB não é uma opção ao usar DAGs. Nesse caso, há soluções de software e dispositivo virtual de terceiros.

O uso do DNS é a opção mais simples para balancear o tráfego do Exchange. Com o balanceamento de carga DNS, você só precisa fornecer aos seus clientes o endereço IP de cada servidor de caixa de correio. Depois disso, o round robin DNS distribui esse tráfego para seus servidores de caixa de correio. O cliente HTTP é inteligente o suficiente para se conectar a outro servidor caso um servidor do Exchange falhe completamente.

A simplicidade tem um preço, no entanto, nesse caso, o round robin DNS não está realmente equilibrando o tráfego, porque não há uma maneira programática de garantir que cada servidor obtenha uma parte justa do tráfego. Além disso, não há monitoramento de nível de serviço para que, quando um único serviço falhar, os clientes não sejam redirecionados automaticamente para um serviço disponível. Por exemplo, se Outlook na Web estiver no modo de falha, os clientes verão uma página de erro.

O balanceamento de carga DNS requer mais endereços IP externos quando você publica externamente. Isso significa que cada servidor exchange individual em sua organização exigiria um endereço IP externo.

Há soluções mais elegantes para balancear o tráfego, como o hardware que usa a Camada de Transporte 4 ou a Camada de Aplicativo 7 para ajudar a distribuir o tráfego do cliente. Os balanceadores de carga monitoram cada serviço voltado para o cliente do Exchange e, se houver uma falha no serviço, os balanceadores de carga poderão direcionar o tráfego para outro servidor e deixar o servidor com problemas offline. Além disso, algum nível de distribuição de carga garante que nenhum servidor de caixa de correio único esteja proxy da maioria do acesso ao cliente.

Os serviços de balanceamento de carga podem usar Camada 4 ou Camada 7, ou uma combinação, para gerenciar o tráfego. Há benefícios e desvantagens em cada solução.

• Os balanceadores de carga da camada 4 funcionam na camada Transporte para direcionar o tráfego sem examinar o conteúdo.

  Como eles não examinam o conteúdo do tráfego, os balanceadores de carga da camada 4 economizam tempo em trânsito. No entanto, isso vem com compensações. Os balanceadores de carga da camada 4 conhecem apenas o endereço IP, o protocolo e a porta TCP. Sabendo apenas um único endereço IP, o balanceador de carga pode monitorar apenas um único serviço.

  Os benefícios de balanceamento de carga da camada 4 incluem:

  • Requer menos recursos (sem exame de conteúdo).

  • Distribui o tráfego na camada Transporte.

    O risco com uma solução de Camada 4 é que, se um serviço falhar, mas o servidor ainda estiver disponível, os clientes poderão se conectar ao serviço com falha. Isso significa que uma implementação resiliente da Camada 4 requer vários endereços IP configurados com namespaces HTTP separados por serviço, por exemplo, owa.contoso.com, eas.contoso.com, mapi.contoso.com, o que permite o monitoramento em nível de serviço.

• Os balanceadores de carga da camada 7 funcionam na camada aplicativo e podem inspecionar o conteúdo do tráfego e direcioná-lo de acordo.

  Os balanceadores de carga da camada 7 abandonam os benefícios brutos de desempenho do balanceamento de carga da Camada 4 para a simplicidade de um único namespace, por exemplo, mail.contoso.com e monitoramento por serviço. Os balanceadores de carga da camada 7 entendem o caminho HTTP, como /owa ou /Microsoft-Server-ActiveSync ou /mapi, e podem direcionar o tráfego para servidores que trabalham com base em dados de monitoramento.

  Os benefícios de balanceamento de carga da camada 7 incluem:

  • Precisa de apenas um único endereço IP.

  • Inspeciona o conteúdo e pode direcionar o tráfego.

  • Fornece a notificação do serviço com falha que pode ser retirado offline.

  • Manipula o término do SSL do balanceador de carga.

  • Distribui o tráfego na camada do aplicativo e entende a URL de destino.

O SSL deve ser encerrado no balanceador de carga, pois oferece um local centralizado para corrigir ataques SSL.

As portas que precisam ser balanceadas de carga incluem algumas, como as para IMAP4 ou POP3, que podem nem ser usadas em sua organização do Exchange.

Cenários de implantação de balanceamento de carga em Exchange Server

O Exchange 2016 introduziu flexibilidade significativa para seu namespace e arquitetura de balanceamento de carga. Com muitas opções para implantar o balanceamento de carga em sua organização do Exchange, do DNS simples à solução sofisticada de terceiros Camada 4 e Camada 7, recomendamos que você examine todas elas à luz das necessidades da sua organização.

Os seguintes cenários vêm com benefícios e limitações e entender cada um deles é fundamental para implementar a solução que melhor se encaixa na sua organização do Exchange:

• Cenário A Namespace único, nenhuma afinidade de sessão: Camada 4 ou Camada 7

• Cenário B Namespace único, sem afinidade de sessão: Camada 7

• Cenário C Namespace único com afinidade de sessão, Camada 7

• Cenário D Vários namespaces e nenhuma afinidade de sessão, Camada 4

Cenário A Namespace único, nenhuma afinidade de sessão: Camada 4 ou Camada 7

Neste cenário de Camada 4, um único namespace, mail.contoso.com, é implantado para os clientes do protocolo HTTP. O balanceador de carga não mantém a afinidade da sessão. Como essa é uma solução de camada 4, o balanceador de carga está configurado para verificar a integridade de apenas um único diretório virtual, pois não consegue distinguir Outlook na Web solicitações de solicitações RPC.

Na perspectiva do balanceador de carga neste exemplo, a integridade é por servidor e não por protocolo para o namespace designado. Os administradores terão que escolher qual diretório virtual eles querem direcionar para a investigação de integridade; recomendamos que você escolha um diretório virtual muito usado. Por exemplo, se a maioria dos usuários usar Outlook na Web, escolha o Outlook na Web diretório virtual na investigação de integridade.

Enquanto a resposta da investigação de integridade Outlook na Web estiver saudável, o balanceador de carga mantém o servidor de caixa de correio de destino no pool de balanceamento de carga. No entanto, se a investigação de integridade Outlook na Web falhar por qualquer motivo, o balanceador de carga removerá o servidor de caixa de correio de destino do pool de balanceamento de carga para todas as solicitações associadas a esse namespace. Isso significa que, se a investigação de integridade falhar, todas as solicitações de cliente para esse namespace serão direcionadas a outro servidor, independentemente do protocolo.

Cenário B Namespace único, sem afinidade de sessão: Camada 7

Neste cenário de Camada 7, um único namespace, mail.contoso.com, é implantado para todos os clientes de protocolo HTTP. O balanceador de carga não mantém a afinidade da sessão. Como o balanceador de carga está configurado para a Camada 7, há o término do SSL e o balanceador de carga conhece a URL de destino.

Recomendamos essa configuração para o Exchange 2016 e o Exchange 2019. O balanceador de carga é configurado para verificar a integridade dos servidores de caixa de correio de destino no pool de balanceamento de carga e uma investigação de integridade é configurada em cada diretório virtual.

Por exemplo, enquanto a resposta da investigação de integridade Outlook na Web estiver saudável, o balanceador de carga manterá o servidor de caixa de correio de destino no pool de balanceamento de carga Outlook na Web. No entanto, se a investigação de integridade Outlook na Web falhar por qualquer motivo, o balanceador de carga removerá o servidor de caixa de correio de destino do pool de balanceamento de carga para Outlook na Web solicitações. Neste exemplo, a integridade é por protocolo, o que significa que, se a investigação de integridade falhar, apenas o protocolo de cliente afetado será direcionado para outro servidor.

Cenário C Namespace único com afinidade de sessão, Camada 7

Neste cenário de Camada 7, um único namespace, mail.contoso.com, é implantado para todos os clientes de protocolo HTTP. Como o balanceador de carga está configurado para a Camada 7, há terminação de SSL e o balanceador de carga conhece a URL de destino. O balanceador de carga também está configurado para verificar a integridade dos servidores de caixa de correio de destino no pool de balanceamento de carga. A investigação de integridade é configurada em cada diretório virtual.

No entanto, habilitar a afinidade de sessão diminui a capacidade e a utilização. Isso ocorre porque as opções de afinidade mais envolvidas, o balanceamento de carga baseado em cookie ou a ID de sessão da Camada de Soquetes Seguros (SSL), exigem mais processamento e recursos. Recomendamos verificar com seu fornecedor como a afinidade da sessão afeta sua escalabilidade de balanceamento de carga.

Como no cenário anterior, desde que a resposta Outlook na Web investigação de integridade seja saudável, o balanceador de carga mantém o servidor mailbox de destino no pool de balanceamento de carga Outlook na Web. No entanto, se a investigação de integridade Outlook na Web falhar por qualquer motivo, o balanceador de carga removerá o servidor de caixa de correio de destino do pool de balanceamento de carga para Outlook na Web solicitações. Aqui, a integridade é por protocolo, o que significa que, se a investigação de integridade falhar, apenas o protocolo cliente afetado será direcionado para outro servidor.

Cenário D Vários namespaces e nenhuma afinidade de sessão

Este último cenário com vários namespaces e nenhuma afinidade de sessão oferece verificações de integridade por protocolo e potência de Camada 4. Um namespace exclusivo é implantado para cada cliente de protocolo HTTP. Por exemplo, você configuraria os clientes de protocolo HTTP como mail.contoso.com, mapi.contoso.com e eas.contoso.com.

Esse cenário fornece verificação de integridade por protocolo, sem exigir lógica complexa de balanceamento de carga. O balanceador de carga usa a Camada 4 e não está configurado para manter a afinidade da sessão. A configuração do balanceador de carga verifica a integridade dos servidores de caixa de correio de destino no pool de balanceamento de carga. Nessa configuração, as investigações de integridade são configuradas para direcionar a integridade de cada diretório virtual, pois cada diretório virtual tem um namespace exclusivo. Como ele está configurado para a Camada 4, o balanceador de carga não sabe que a URL está sendo acessada, mas o resultado é como se ele soubesse. Como a integridade é por protocolo, se a investigação de integridade falhar, apenas o protocolo de cliente afetado será direcionado para outro servidor.

Balanceamento de carga e disponibilidade gerenciada no Exchange Server

Monitorar os servidores e serviços disponíveis é fundamental para redes de alta disponibilidade. Como algumas soluções de balanceamento de carga não têm conhecimento da URL de destino ou do conteúdo da solicitação, isso pode introduzir complexidades para as investigações de integridade do Exchange.

O Exchange 2016 e o Exchange 2019 incluem uma solução de monitoramento interna, conhecida como Disponibilidade Gerenciada. A disponibilidade gerenciada, também conhecida como Monitoramento Ativo ou Monitoramento Ativo Local, é a integração de ações internas de monitoramento e recuperação com a plataforma de alta disponibilidade do Exchange.

A Disponibilidade Gerenciada inclui um respondente offline. Quando o respondente offline é invocado, o protocolo afetado (ou servidor) é removido do serviço.

Para garantir que os balanceadores de carga não roteiem o tráfego para um servidor de caixa de correio que a Disponibilidade Gerenciada marcou como offline, as investigações de integridade do balanceador de carga devem ser configuradas para verificar <o virtualdirectory>/healthcheck.htm, por exemplo, <https://mail.contoso.com/owa/healthcheck.htm>.

Leia mais sobre a disponibilidade gerenciada na disponibilidade gerenciada.