Usando um balanceador de carga para aumentar a capacidade e a disponibilidade

Tópico modificado em: 2009-01-22

Um único servidor executando o Communicator Web Access (versão 2007 R2) pode manipular aproximadamente 5.000 conexões simultâneas. Caso você precise oferecer suporte a um número de usuários maior do que esse, precisará de mais de um servidor do Communicator Web Access. Nesse caso, provavelmente será melhor implantar um balanceador de carga de hardware para ajudar a garantir a distribuição equitativa da carga de trabalho entre esses servidores.

Observação:

Além de aumentar a capacidade global da infraestrutura do Communicator Web Access, usando uma matriz de servidores e um balanceador de carga, você pode aumentar a confiabilidade e a disponibilidade do Communicator Web Access. Caso ocorra falha em um servidor, o balanceador de carga poderá rotear as solicitações de conexão de entrada automaticamente para os servidores que ainda estiverem funcionando.

O Communicator Web Access exige afinidade de sessão, um requisito que tem impacto direto sobre o balanceamento de carga. A afinidade de sessão significa apenas que uma dada sessão do Communicator Web Access deve ocorrer em um único servidor. O Communicator Web Access não permite que uma sessão de mensagens instantâneas comece em um servidor e de alguma forma seja transferida para outro. Se um usuário estiver conectado ao Servidor A no início de uma sessão do Communicator Web Access, ele continuará usando esse servidor durante toda a sessão. Se o Servidor A apresentar falha, a sessão do usuário será encerrada. (Esse usuário poderá entrar novamente e o balanceador de carga o roteará para um servidor que ainda esteja em execução.) No entanto, os usuários conectados ao Servidor B ou ao Servidor C não terão suas sessões interrompidas em caso de falha no Servidor A.

Isso explica por que é necessário usar o balanceamento de carga de hardware com o Communicator Web Access. O balanceamento de carga de software também pode distribuir as solicitações de conexão de forma equilibrada entre os servidores. Porém, se ocorrer falha no Servidor A, um balanceador de carga de software redistribuirá todas as conexões de clientes, inclusive os clientes do Servidor B e do Servidor C. Como resultado, não apenas os usuários do Servidor A perderão suas conexões, mas o mesmo acontecerá com muitos usuários do Servidor B e do Servidor C.

Observação:
Conforme observado, não há suporte para o balanceamento de carga de software no Communicator Web Access. Além disso, o Communicator Web Access não oferece suporte a nenhum tipo de cenário de balanceamento de carga que envolva adaptadores de rede multihomed ou computadores equipados com mais de um adaptador de rede e mais de um gateway padrão.

O Communicator Web Access oferece suporte à maior parte dos balanceadores de carga de hardware, desde que o balanceador:

• Permita que você defina o tempo limite ocioso do TCP como 1.800 segundos (30 minutos). Esse valor representa o tempo que o servidor aguardará pelas informações durante uma sessão. Se você estiver usando um servidor de proxy reverso (como o Microsoft Internet Security and Acceleration Server), o tempo limite ocioso do TCP nesse computador também deverá ser definido como 1.800 segundos.
• Permita que você use um pool SNAT (conversão de endereço de rede de origem) se precisar manipular mais de 65.000 conexões simultâneas. O SNAT foi projetado para “ocultar” vários servidores por trás de um único endereço IP (isto é, diversos servidores podem ser acessados por meio de um único endereço IP). Com um pool SNAT, os servidores podem ficar ocultos por trás de vários endereços IP.
• Permita que você use a persistência de cookie ao configurar a afinidade de sessão. Com a persistência de cookie, as informações sobre o servidor do Communicator Web Access que está sendo realmente usado para uma sessão são armazenadas em um cookie da Internet no computador cliente. Ao configurar o perfil de persistência de sessão do balanceador de carga, é recomendável utilizar “HTTP Cookie Insert”. Com esse método de configuração, as informações sobre o servidor ao qual o cliente está conectado são inseridas no cabeçalho da resposta HTTP proveniente desse servidor na forma de um cookie.

O Communicator Web Access também oferece suporte à aceleração SSL no balanceador de carga. Com a aceleração SSL, o balanceador de carga descriptografa as transmissões HTTPS antes de enviar esse tráfego descriptografado ao servidor do Communicator Web Access. Como o servidor é liberado da necessidade de executar a descriptografia SSL, seu desempenho pode melhorar consideravelmente.

O Communicator Web Access deve ter sempre um balanceador de carga dedicado. Não é recomendável compartilhar um balanceador de carga entre o servidor do Office Communications Server e o servidor do Communicator Web Access.