Noções Básicas do Balanceamento de Carga no Exchange 2010
Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Tópico modificado em: 2016-11-28
O balanceamento de carga é uma maneira de gerenciar quais servidores recebem tráfego. O balanceamento de carga proporciona redundância de failover a fim de garantir que os usuários continem a receber o serviço do Exchange em caso de falha do computador. Ele também habilita a implantação para lidar com mais tráfego do que um servidor consegue processar, ao mesmo tempo que oferece um nome único de host para seus clientes.
Além do balanceamento de carga, o Microsoft Exchange Server 2010 fornece uma série de soluções para redundância de alternância e failover. Essas soluções incluem o seguinte:
Alta disponibilidade e resiliência de site Você pode implantar dois sites do Active Directory em localidades geográficas separadas, manter os dados de caixa de correio sincronizados entre os dois e fazer com que um dos sites receba toda a carga se o outro falhar. O Exchange 2010 usa os DAGs (grupos de disponibilidade do banco de dados) para manter múltiplas cópias das caixas de correio em servidores sincronizados diferentes.
Movimentação de caixa de correio online Em uma movimentação de caixa de correio online, os usuários finais podem acessar suas contas de email durante a movimentação. O usuário é impedido de acessar a conta apenas durante um breve período no final do processo, quando a sincronização final ocorre. As movimentações de caixa de correio online são suportadas entre os bancos de dados do Exchange 2010 e entre o Exchange Server 2007 Service Pack 3 (SP3) ou uma versão mais atual do Exchange 2007 e de bancos de dados do Exchange 2010. Você pode realizar movimentações de caixa de correio online entre florestas ou na mesma floresta.
Redundância de sombra A redundância de sombra protege a disponibilidade e a capacidade de recuperação das mensagens enquanto estão em trânsito. Com a redundância de sombra, a exclusão de uma mensagem do banco de dados de transporte é atrasada até que o servidor de transporte confirme que todos os próximos saltos da mensagem tenham sido concluídos. Se qualquer um dos próximos saltos falhar antes de relatar sucesso na entrega, a mensagem será reenviada para entrega para o próximo salto que não foi concluído.
Sumário
Visão geral do balanceamento de carga
Noções básicas sobre as cargas de tráfego do Exchange 2010
Noções básicas sobre as opções de balanceamento de carga
Recomendações de balanceamento de carga
Opções de afinidade
Visão geral do balanceamento de carga
O balanceamento de carga tem duas finalidades principais. Ele reduz o impacto da falha de um único servidor de Acesso para Cliente em um de seus sites do Active Directory. Além disso, o balanceamento assegura que a carga em seu servidor de Acesso para Cliente e nos computadores de Transporte de Hub seja distribuída uniformemente.
Alterações de arquitetura no balanceamento de carga do Exchange 2010
Uma série de alterações no Exchange 2010 faz do balanceamento de carga algo importante para sua organização. O serviço de Acesso para Cliente RPC do Exchange e o serviço de Catálogo de endereços do Exchange na função de servidor de Acesso para Cliente aprimoram a experiência do usuário durante os failovers da Caixa de Correio, movendo os pontos de extremidade de conexão do acesso de caixa de correio do Outlook e de outros clientes MAPI para a função de servidor de Acesso para Cliente, em vez de mover para a função de servidor de Caixa de Correio. Nas versões anteriores do Exchange, o Outlook se conectava diretamente ao servidor de Caixa de Correio hospedando a caixa de correio do usuário, e as conexões de diretório eram intermediadas por proxy por meio da função de servidor de Caixa de Correio ou então indicadas diretamente para um servidor de catálogo global do Active Directory em particular. Agora que estas conexões são manipuladas pela função de servidor de Acesso para Cliente, tanto as conexões externas e internas do Outlook devem ter a carga balanceada por toda a matriz de servidores de Acesso para Cliente em uma implantação para obter tolerância a falhas.
Recomenda-se uma matriz de servidores de Acesso para Cliente com carga balanceada para cada site do Active Directory e para cada versão do Exchange. Não é possível compartilhar uma matriz de servidores de Acesso para Cliente com carga balanceada para múltiplos sites do Active Directory, nem combinar versões diferentes do Exchange ou de service packs do Exchange, dentro da mesma matriz.
Quando você instala o Exchange 2010 em sua organização existente e configura um namespace herdado para coexistir com versões antigas do Exchange, seus clientes se conectarão automaticamente ao serviço de Acesso para Cliente do Exchange 2010 ou a uma matriz de servidores. O servidor de Acesso para Cliente do Exchange 2010 ou a matriz de servidores de Acesso para Cliente farão a intermediação por proxy ou redicionarão as solicitações de clientes de caixas de correio em versões antigas do Exchange para servidores front-end do Exchange 2003 ou para servidores de Acesso para Cliente do Exchange 2007 que correspondam às versões de caixa de correio. Para mais informações, consulte Noções Básicas de Atualização para o Exchange 2010.
Dica
Você pode combinar QFEs (Quick Fix Engineering) com pacotes cumulativos de atualizações ao aplicá-los em toda uma matriz ou somente em algumas partes dela. Recomendamos que você aplique QFEs e pacotes cumulativos de atualizações em todos os computadores de uma matriz.
A configuração de balanceamento de carga afetará diretamente os nomes de host que seus clientes usam para se conectarem e os certificados SSL (Secure Sockets Layer) que você utiliza. Para mais informações sobre os certificados do Exchange 2010, consulte Noções Básicas Sobre Certificados Digitais e SSL.
Configuração da matriz de servidor de Acesso para Cliente
Você pode configurar uma matriz de servidor de Acesso para Cliente por site do Active Directory. Assim que a matriz de servidor de Acesso para Cliente tiver sido configurada, você poderá configurar o banco de dados de Caixa de Correio para utilizar essa matriz como o ponto de extremidade MAPI, em vez de um servidor específico de Acesso para Cliente.
Para mais informações sobre a matriz de servidor de Acesso para Cliente e sobre como configurar o banco de dados de Caixa de Correio para usar essa matriz para o site do Active Directory específico, consulte Noções Básicas Sobre o Acesso para Cliente RPC.
Noções básicas sobre as cargas de tráfego do Exchange 2010
Antes de configurar o balanceamento de carga, você precisa de noções básicas sobre as cargas que são colocadas em um servidor de Acesso para Cliente do Exchange 2010. Um servidor de Acesso para Cliente do Exchange 2010 recebe os três tipos de tráfego a seguir:
Tráfego de clientes externos
Tráfego de clientes internos
Tráfego de proxy de outros servidores de Acesso para Cliente
O tráfego de proxy vindo de outros servidores de Acesso para Cliente é um tráfego enviado originalmente por um cliente externo ou interno para um servidor de Acesso para Cliente que, no entanto, foi intermediado por proxy para outro servidor de Acesso para Cliente. Isto pode ocorrer por diversas razões, mas geralmente ocorre porque o cliente original não conseguiu se conectar diretamente ao servidor de Acesso para Cliente de destino. Isto pode ocorrer quando um usuário está tentando acessar uma caixa de correio pela Internet, mas essa caixa de correio está localizada em um site do Active Directory que não é voltado para Internet. Para obter mais informações sobre proxy, consulte Noções básicas de proxy e redirecionamento.
Todos os tipos de tráfego recebidos pelos servidores de Acesso para Cliente incluem solicitações de uma lista de protocolos e vêm de dispositivos e computadores de clientes com características diferentes. Essas diferenças afetam quais estratégias de balanceamento podem ser usadas.
Voltar ao início
Noções básicas sobre as opções de balanceamento de carga
Há várias diferenças tecnológicas essenciais entre as diferentes soluções de balanceamento de carga.
Desempenho Com quantas solicitações por segundo a solução pode lidar?
Gerenciabilidade Configurar e implantar a solução de balanceamento de carga é simples?
**Detecção e automação de failover ** O balanceamento de carga é inteligente no que diz respeito a detectar quando um servidor de Acesso para Cliente ou serviço falharam?
**Afinidade ** Quais tipos de afinidade entre cliente e servidor de Acesso para Cliente são suportados pelo balanceamento de carga?
Noções básicas sobre afinidade
Quando uma solução de balanceamento de carga proporciona afinidade entre cliente e servidor de Acesso para Cliente, significa que há uma associação de longo prazo entre um cliente em particular e um servidor de Acesso para Cliente também em particular. O cliente pode ser o Outlook sendo executado em um laptop, o Microsoft Exchange ActiveSync sendo executado em um dispositivo móvel, o Microsoft Office Outlook Web App, Serviços Web do Exchange ou outro aplicativo do cliente.
Essa associação de longo prazo, ou afinidade, garante que todas as solicitações enviadas pelo cliente cheguem ao mesmo servidor de Acesso para Cliente. Alguns protocolos do Exchange 2010 exigem afinidade, já outros protocolos do Exchange não exigem.
Balanceamento de carga de rede do Windows
O WNLB (Balanceamento de Carga de Rede do Windows) é o software mais comum de balanceamento de carga usado para servidores do Exchange. Há uma série de limitações associadas à implantação de WNLB com o Microsoft Exchange.
O WNLB não pode ser usado em servidores do Exchange nos quais DAGs de caixa de correio também estão sendo usados, porque o WNLB não é compatível com o clustering de failover do Windows. Se você estiver usando um DAG do Exchange 2010 e deseja utilizar o WNLB, será necessário executar a função de servidor de Acesso para Cliente e a função de servidor de Caixa de Correio em servidores separados.
Por causa de problemas de desempenho, não recomendamos que se coloquem mais que oito servidores de Acesso para Cliente em uma matriz que está tendo a carga balanceada pelo WNLB.
O WNLB não detecta interrupções de serviço. O WNLB detecta apenas interrupções de serviço por endereço IP. Isto significa que se um serviço Web em particular, como o Outlook Web App, falhar, mas o servidor continuar funcionando, o WNLB não detectará a falha e continuará encaminhando solicitações para aquele servidor de Acesso para Cliente. Será necessário intervir manualmente para remover do pool de balanceamento de carga o servidor de Acesso para Cliente que está passando por interrupções.
A configuração do WNLB pode resultar em saturação da porta, o que pode sobrecarregar as redes.
Como o WNLB desempenha a afinidade de cliente usando apenas o endereço IP de origem, esta não é uma solução eficaz quando o pool de IP de origem é pequeno. Isto pode ocorrer quando o pool de IP de origem vem de uma sub-rede remota ou quando sua organização está usando a conversão de endereços de rede.
Recomendações de balanceamento de carga
Há várias opções de balanceamento de carga disponíveis. A opção utilizada depende do tamanho e da configuração de sua rede.
Balanceamento de carga de rede do Windows com afinidade de IP de origem
A primeira opção de balanceamento de carga é o WNLB com afinidade de IP de origem. Esta solução é indicada caso você tenha mais de um servidor de Acesso para Cliente por site do Active Directory, sem exceder oito. Esta solução está integrada ao Windows e não requer computadores adicionais.
Há duas situações em que você não desejará usar o WNLB.
Sua organização possui um servidor de proxy reverso que se comunica diretamente com o servidor de Acesso para Cliente, e não por meio do endereço IP virtual do WNLB. O servidor de proxy reverso oculta os endereços IP do cliente da matriz de servidor de Acesso para Cliente. Portanto, a afinidade de IP de origem não funcionará como esperado. Contudo, você poderá ainda usar o WNLB para balancear a carga do tráfego interno.
A sua organização possui muitos clientes acessando seus servidores de Acesso para Cliente por meio de um conjunto bem pequeno de endereços IP. O WNLB tende a fazer a afinidade de uma subnet de classe C inteira com um servidor de Acesso para Cliente.
Balanceador de carga de hardware
Se você possuir mais de oito servidores de Acesso para Cliente em um único site do Active Directory, sua organização precisará de uma solução mais robusta de balanceamento de carga. 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. Para mais informações sobre as soluções de balanceamento de carga do servidor do Exchange 2010, consulte Implantação do balanceador de carga de hardware da Unificação de Mensagens da Microsoft.
Os balanceadores de carga de hardware suportam taxas de transferência altíssimas e podem ser configurados para balancear a carga de várias maneiras. A maioria dos fornecedores de balanceadores de carga de hardware possuem documentações detalhadas sobre o funcionamento de seus produtos com o Exchange 2010. A maneira mais simples para configurar balanceadores de carga de hardware é criar uma lista de fallback dos métodos de afinidade que serão aplicados pelo balanceador de carga. Por exemplo, o balanceador de carga tentará primeiro a afinidade baseada em cookies, depois a ID de sessão SSL e por fim a afinidade de IP de origem.
Soluções de proxy reverso
Se você tiver uma solução de proxy reverso que consegue desempenhar o balanceamento de carga nos servidores publicados na Internet, como o Microsoft Forefront Threat Management Gateway (TMG) ou o Forefront Unified Access Gateway (UAG), recomendamos sua utilização.
Conforme o tráfego passa pelo servidor de proxy reverso para atingir seus servidores de Acesso para Cliente, o endereço IP original do cliente é substituído pelo endereço IP do servidor de proxy reverso. Isto quebra a afinidade de IP de origem. Estas são maneiras de se resolver este problema, incluindo a configuração do servidor de proxy reverso para ser o gateway padrão da sub-rede para a qual ele está fazendo o proxy.
No entanto, a maioria dos servidores de proxy reverso conseguem balancear a carga dos serviços que eles publicam na Internet. Estes servidores de proxy reverso suportam balanceamento de carga de cookie criado por balanceador de carga dos serviços Exchange que suportam isso. Esta solução é mais confiável do que o balanceamento de carga de IP de origem. Para isso funcionar, o servidor de proxy reverso deve ser capaz de ler e modificar o fluxo de dados HTTP. Se você estiver usando SSL, o servidor de proxy reverso deverá descriptografar o tráfego para ler os conteúdos e criar o cookie no fluxo. A descriptografia não é possível em certas circunstâncias, como quando você está usando autenticação de certificado de cliente, situação em que o cliente se conecta ao servidor de Acesso para Cliente.
Voltar ao início
Opções de afinidade
Diferentes soluções de balanceamento de carga oferecem métodos diferentes para associar clientes com um servidor específico de Acesso para Cliente. Há vários tipos comuns de afinidade disponíveis em diferentes produtos de balanceamento de carga, tanto de hardware quando de software. Nem todos os tipos de afinidade estarão disponíveis para cada opção de balanceamento de carga, como é descrito nos exemplos a seguir:
O WNLB suporta apenas afinidade ou não afinidade de IP de origem.
Um balanceador de carga de software em uma matriz de servidor separado pode usar cookies criados por um balanceador de carga para os protocolos que suportam tais cookies e afinidade de IP de origem para os protocolos restantes.
Os balanceadores de carga de hardware com descarregamento de SSL permitem que você configure comportamentos mais complexos. Por exemplo, você pode configurar um conjunto de cookies já existentes que funcionarão para protocolos que suportam tais cookies, além de um cookie criado por um balanceador de carga, ID de sessão SSL e IP de origem.
Além das opções que são suportadas pelas diferentes soluções de balanceamento de carga, você também pode configurar algumas destas etapas para serem aplicadas apenas em certos protocolos e serviços do Exchange. Uma vez que cada protocolo se comporta de maneira diferente, isto pode ajudar a aprimorar o desempenho.
Cabeçalhos HTTP ou cookies existentes
Usar cabeçalhos HTTP ou cookies existentes é a maneira mais confiável para identificar um cliente e associá-lo a um servidor específico de Acesso para Cliente. Estes cookies e cabeçalhos são criados pelo cliente ou pelo servidor como parte do protocolo de comunicações. Esta opção também não requer que o balanceador de carga modifique o tráfego, ajudando assim o desempenho.
Quando utilizar esta opção de afinidade, esteja atento ao seguinte:
O seu balanceador de carga deve suportar este tipo de afinidade. Atualmente apenas os balanceadores de carga de hardware suportam esta afinidade.
Esta afinidade funciona apenas para protocolos que passam tráfego no HTTP.
Deve haver um cookie ou cabeçalho existente que se mantenha constante durante a sessão do cliente e que seja único para cada cliente específico, ou um pequeno conjunto de clientes, no protocolo.
A solução do balanceador de carga deve ser capaz de ler e interpretar o fluxo de dados HTTP. Se você estiver usando SSL, o balanceador de carga deverá descriptografar o tráfego para ler os conteúdos. Algumas vezes isso resulta em uma carga maior no balanceador de carga. Além disso, a descriptografia não é possível em certas circunstâncias, como quando você usa autenticação de certificado de cliente com sessão SSL, situação em que o cliente se conecta ao servidor de Acesso para Cliente.
Os cabeçalhos HTTP e cookies existentes e compatíveis com o balanceamento de carga que estão disponíves nos protocolos do Exchange 2010 são os seguintes:
Cabeçalho de autorização de autenticação básica HTTP Este cabeçalho funciona quando a autenticação básica HTTP é usada. A autenticação básica é o tipo padrão e normalmente o mais usado para autenticação do Exchange ActiveSync. Este cabeçalho não é comum para outros protocolos e métodos de autenticação. O cabeçalho de autorização de autenticação básica envia todo o tráfego que usa a autenticação básica e que é de um usuário específico para o mesmo servidor de Acesso para Cliente. Este cabeçalho é usado também quando o tráfego do Outlook é transmitido completamente via HTTP, e os clientes estão por trás de um servidor de proxy reverso.
Cookie UserContext HTTP OWA Este cookie funciona com o Outlook Web App, que é o único cliente que o usa. Quando você usa a FBA (Autenticação baseada em formulários) com o Outlook Web App, o que é a configuração padrão, um pequeno conjunto de solicitações é criado no início de uma sessão do Outlook Web App antes do cookie UserContext ser criado. A fim de garantir que tais solicitações usem afinidade para conectarem o cliente ao mesmo servidor de Acesso para Cliente, o que é necessário para que a autenticação baseada em formulários funcione, deve haver uma opção de afinidade de fallback quando você usar o cookie UserContext. Recomendados a utilização de ID de sessão SSL ou de afinidade de IP de origem como fallback a fim de proporcionar afinidade para as solicitações iniciais, antes do balanceador de carga utilizar o cookie UserContext.
Dica
Outlook Web App O UserContext solicita que o uso de logon explícito para acessar uma caixa de correio epecífica resulta no uso de um cookie UserContext com nome e ID diferentes. O cookie começa com , mas uma string que identifica a caixa de correio individual é acrescentada. Isto complica o balanceamento de carga com o cookie UserContext porque o balanceador de carga precisa primeiro encontrar um cookie começando com UserContext. Isso pode resultar na redução do desempenho.
Cookie HTTP Exchange Control Panel msExchEcpCanary Este cookie funciona apenas com o Painel de Controle do Exchange.
Cookie HTTP Outlook 2010 OutlookSession Os balanceadores de carga de hardware suportam o cookie OutlookSession e outros cookies genéricos. A tabela a seguir descreve os requisitos para suporte do cookie do cliente OutlookSession para Outlook RPC/HTTP:
Windows XP
Windows Vista
Windows 7
Outlook 2003
Não suportado
Não suportado
Não suportado
Outlook 2007
Não suportado
Não suportado
Não suportado
Outlook 2007 Pacote de hospedagem (KB2544404)
Não suportado
Suportado
Suportado
Outlook 2010
Não suportado
Suportado
Suportado
Dica
O Microsoft Outlook com Windows XP não suporta o cookie OutlookSession para balanceamento de carga. Neste cenário, recomendamos que você use o balanceamento de carga IP.
Cookie HTTP Remote PowerShell MS-WSMAN Este método funciona apenas com o Remote PowerShell.
Voltar ao início
Cookie criado por balanceador de carga
A segunda maneira mais confiável de se associar uma sessão de cliente a um servidor de Acesso para Cliente é utilizando um cookie criado por um balanceador de carga. O balanceador de carga adiciona um cookie HTTP à conversação de protocolo de cliente/servidor e depois usa este cookie para determinar qual servidor de Acesso para Cliente deve lidar com uma solicitação de entrada. Os aplicativos do Exchange 2010 que suportam este método são Outlook Web App, Painel de Controle do Exchange e o Remote PowerShell. Este tipo de cookie tem várias limitações.
O balanceador de carga deve suportar este tipo de afinidade. Atualmente apenas os balanceadores de carga de hardware e os balanceadores de carga de software que são executados em uma camada separada de servidor.
Este método funciona apenas para protocolos que passam tráfego no HTTP. Esse método não pode ser usado para o serviço de Acesso para Cliente RPC, serviço de Catálogo de endereços do Exchange, POP3 ou IMAP4.
A solução do balanceador de carga deve ser capaz de ler e interpretar o fluxo de dados HTTP. Se você estiver usando SSL, o balanceador de carga deverá descriptografar o tráfego para ler os conteúdos. Algumas vezes isso resulta em uma carga maior no balanceador de carga. Em outros casos, não é possível para o balanceador de carga interpretar o fluxo de dados HTTP, como quando você usa a autenticação de certificado de cliente em um servidor de Acesso para Cliente.
O cliente deve ser capaz de receber cookies arbitrários do servidor e então inclui-los em todas as solicitações futuras enviadas do cliente para o servidor. Isto não é suportado pelos clientes do Exchange ActiveSync, clientes do Outlook Anywhere e alguns clientes de Serviços Web do Exchange, como os dispositivos do Microsoft Office Communications Server 2007.
ID de sessão SSL
O balanceamento de carga baseado em ID de sessão SSL fornece mais detalhes que a afinidade de IP de origem, além de permitir a divisão do tráfego de diferentes clientes, mesmo se eles estão vindo do mesmo endereço IP. O balanceamento de carga de ID de sessão SSL também tem a vantagem de permitir que você balanceie a carga sem descriptografar o tráfego SSL. Isto é necessário quando você usa autenticação de certificado de cliente e quando você finaliza a conexão SSL com servidor de Acesso para Cliente.
A afinidade de ID de sessão SSL não é recomendada nas duas situações a seguir:
Algus clientes, como Internet Explorer 8, recriam sua sessão SSL para cada processo de navegador que é executado no computador do cliente. Isto resulta em uma nova sessão SSL para cada janela do Outlook Web App. Uma vez que isso quebra a afinidade de cliente do Outlook Web App, o Exchange 2010 não suporta a implantação do balanceamento de carga desta maneira. Alguns dispositivos móveis, como o Apple iPhone, também criam novas sessões SSL para algumas partes de sua comunicação do Exchange ActiveSync com o Exchange.
Dica
Quando você usa a autenticação de certificado de cliente, os navegadores usarão a mesma sessão SSL para o mesmo tráfego para um dado nome de host. Desde que a autenticação de certificado de cliente esteja habilitada, a ID de sessão ID será uma opção válida de afinidade para o Outlook Web App e o Painel de Controle do Exchange.
No caso do Outlook Anywhere, os servidores de Acesso para Cliente usarão o componente Proxy RPC a fim de parear as conexões RPC_DATA_IN e RPC_DATA_OUT. Isto pode afetar negativamente o desempenho.
IP de origem
A maneira mais comum de fornecer afinidade entre clientes e os servidores de Acesso para Cliente é utilizando a afinidade de IP de origem. O balanceador de carga examina o endereço IP do cliente e envia todo o tráfego de um IP de origem específico para um servidor específico de Acesso para Cliente. Este é o único tipo de afinidade suportado pelo WNLB. Existem dois aspectos importantes a serem considerados ao se utilizar a afinidade de IP de origem.
A afinidade quebra quando o cliente altera o endereço IP. Isto pode ocorrer quando um laptop muda de uma rede LAN com fio para uma rede Wi-Fi, ou então se move entre redes Wi-Fi diferentes. Há um impacto para o usuário quando o cliente altera o endereço IP. Por exemplo, ao utilizarem o Outlook Web App, os usuários terão de fazer a autenticação toda vez que seu computador obtiver um novo endereço IP.
Caso muitos de seus clientes acessem sua solução de balanceamento de carga com o mesmo endereço IP, a distribuição de carga se tornará desigual. O impacto disso depende de quantos clientes estão mascarados por trás de determinado endereço IP. Por exemplo, se você tem quatro servidores de Acesso para Cliente e 50% de seus clientes acessam o balanceador de carga com o mesmo endereço IP, no mínimo 50% de seu tráfego irá para um servidor de Acesso para Cliente e os outros servidores de Acesso para Cliente manipularão o tráfego restante. Existem duas razões principais que explicam porque a maioria dos clientes acessarão sua organização do Exchange por meio de um único endereço IP.
NATs (Conversão de endereços de rede) ou servidores proxy de saída, como o Microsoft Forefront Threat Management Gateway (TMG). Quando há um NAT ou servidor proxy de saída entre seus clientes e os servidores de Acesso para Cliente, os endereços de IP originais dos clientes são mascarados pelo NAT ou pelo endereço IP do servidor proxy.
Servidor de Acesso para Cliente para o tráfego de proxy do servidor de Acesso para Cliente. Em algumas situações, um servidor de Acesso para Cliente faz a intermediação por proxy do tráfego para outro servidor de Acesso para Cliente. Normalmente isso acontece entre sites do Active Directory, uma vez que o cliente precisa acessar o servidor de Acesso para Cliente no mesmo site do Active Directory usado pela sua caixa de correio. Para obter mais informações sobre proxy, consulte Noções básicas de proxy e redirecionamento.
Sem afinidade
O último tipo de afinidade é sem afinidade. Quando não se usa afinidade, toda solicitação de um cliente é atribuída para um servidor aleatório de Acesso para Cliente. Não recomendamos esta opção para protocolos que exigem afinidade ou para os que têm o desempenho melhorado pela afinidade.
Não é recomendável usar afinidade para protocolos que não precisam de afinidade quando o descarregamento de SSL está configurado.
Voltar ao início
Resumo das opções de balanceamento de carga
A tabela a seguir fornece um resumo das opções de balanceamento de carga que estão disponíveis.
| Solução | Afinidade entre cliente e servidor de Acesso para Cliente | Método failover | Capacidade | Custo |
|---|---|---|---|---|
Balanceador de carga de hardware |
Dependendo do protocolo e do cliente, fallback entre:
|
Failover automático com tempo de inatividade mínimo. Balanceadores de carga de hardware também podem fornecer failover para um protoloco específico. |
++++ |
$$$ |
Balanceador de carga de software em uma camada separada de servidor. Observação: TMG e UAG são as únicas soluções que funcionam com tráfego externo. |
Tanto cookie criado por balanceador de carga ou IP de origem, dependendo do protocolo e do cliente. |
Failover automático com tempo de inatividade mínimo. |
++ |
$$ |
Balanceador de carga de software na mesma camada de servidor que o servidor de Acesso para Cliente (WNLB). |
IP de origem. |
Failover automático com tempo de inatividade mínimo. |
+ |
$ |
Round robin do DNS |
Cada cliente recebe um endereço IP do servidor de Acesso para Cliente aleatório. |
Etapas manuais para detectar problemas e recuperação. O comportamento do navegador e do controlador DNS do sistema operacional pode inibir conexões de clientes mesmo após a recuperação ter sido executada por um administrador. Esta solução quebra a afinidade para vários protocolos, incluindo Acesso para Cliente RPC, Outlook Web App, Serviços Web do Exchange e Painel de Controle do Exchange. |
+++ |
$ |
Sem balanceador de carga |
Nomes do host separados são atribuídos manualmente para cada servidor de Acesso para Cliente. |
Etapas manuais para detectar problemas e failover. Caches de DNS de cliente causam faiolver lento. |
+ |
N/D |
Há diversas vantagens e desvantagens para cada uma dessas opções.
Os balanceadores de carga de hardware normalmente incluem funcionalidades de desempenho e segurança, como o descarregamento de SSL e a inspeção de tráfego.
Os balanceadores de carga de software em uma camada separada de servidor geralmente são incluídos como componentes de pacotes de software maiores, com capacidades de proxy reverso como pré-autenticação, descarregamento de SSL e inspeção extensa de tráfego. Os usuários pré-autenticados pelos balanceadores de carga de sofware não precisarão fazer a reauntenticação caso haja falha no servidor de Acesso para Cliente com o qual eles têm afinidade. No entanto, alguns balanceadores de carga de software solicitam afinidade entre o cliente e o servidor de proxy reverso. Neste caso, será necessário uma camada adicional de balanceamento de carga na frente dos servidores de proxy reverso antes que tais servidores possam desempenhar as tarefas de balanceamento de carga para os servidores de Acesso para Cliente.
© 2010 Microsoft Corporation. Todos os direitos reservados.