Estamos planejando balancear a carga de 10 servidores web .NET 3.5. Estamos usando o servidor de estado de sessão SQL 2008 para gerenciamento de sessões.
O que precisamos para balancear a carga dos servidores web .NET?
Coisas que identificamos até agora:
- o conteúdo da web precisará ser o mesmo.
- o servidor de estado de sessão precisará apontar para o mesmo SQL 2008 para obter informações de estado de sessão.
- a chave da máquina precisa ser a mesma no arquivo web.config.
Responder1
Se você estiver realmente passando de um ambiente de servidor único para um cluster com balanceamento de carga de 10, isso disparará sinais de alerta para mim instantaneamente. Tenho um monte de perguntas que espero que você já tenha resolvido, mas vou apontá-las de qualquer maneira e, em seguida, fornecerei algumas considerações genéricas.
Como você chegou ao número 10? Por que você não está aumentando para 2 ou 3 e adicionando mais conforme necessário?
Por que você vai fazer o balanceamento de carga em primeiro lugar? Por exemplo, você está optando por alta carga, alta disponibilidade ou ambos? Existe uma necessidade imediata ou é uma necessidade preditiva?
Se você está sobrecarregado agora e tentando escalar para resolvê-lo, uma grande pergunta que eu faria é se você realmente identificou o gargalo. Você mencionou que está usando .NET e SQL para o estado da sessão, então acho que também está trabalhando com um aplicativo baseado em SQL. Você também está balanceando o servidor SQL? O servidor SQL pode lidar com 10 vezes mais conexões que você tem agora?
Se você busca disponibilidade, considerou todos os outros pontos de falha? Você tem redundância em seu balanceador de carga? Você tem redundância em seu(s) servidor(es) de banco de dados? Você tem redundância no uplink da sua internet (considere todos os pontos: cabo único, switch único, etc)? Em termos de disponibilidade, você está tão seguro quanto o seu elo mais fraco. Não importa se você tem 10 ou até 100 servidores web front-end, se você tiver apenas um servidor de banco de dados e ele falhar.
Muitas vezes o seu gargalo será o servidor de banco de dados. Se for esse o caso, não importa quantos front-ends você tenha.
Se você estiver usando SSL, há dois modos típicos em que os balanceadores de carga geralmente operam, que afetam o funcionamento do SSL:
- Camada 4: Este é o nível TCP. O SSL é gerenciado por cada servidor e, portanto, o certificado SSL deve ser instalado em cada servidor.
- Camada 7: Este é o nível do aplicativo, também chamado de proxy reverso. O balanceador de carga trata da sessão HTTP e faz uma segunda conexão com o servidor de aplicativos. Nesse modo, o certificado SSL é instalado apenas no balanceador e a conexão com os servidores de aplicativos normalmente é HTTP. Isso às vezes é chamado de "descarregamento de SSL" e normalmente é útil se seu balanceador de carga for poderoso e você não quiser que seu servidor de aplicativo lide com a sobrecarga de criptografia de SSL (por exemplo, seu aplicativo usa muita CPU).
Certifique-se de que seu balanceador esteja configurado para tirar os servidores da rotação quando eles ficarem inativos e teste essa funcionalidade. Você deve conseguir desativar os servidores sem afetar o restante dos servidores. Observe verificações de PING vs HTTP vs tempo de resposta. (Ping não significa que o HTTP está respondendo)
Teste de carga em seu ambiente. Talvez você não consiga fazer o máximo, mas deverá conseguir carregar pelo menos alguns servidores (com apenas esses dois no balanceador).
Execute um ambiente de teste. Podem não ser 10 servidores, mas devem ser suficientes para replicar o sistema de produção para testes de implantação.
Tenha um script de implantação automatizado e seja muito rigoroso quanto ao gerenciamento de origem e de configuração. Idealmente, isso significa que TUDO (incluindo arquivos de configuração) está em um sistema de controle de origem e você tem compilações automatizadas para criar tudo até seu instalador/script.
Obtenha uma ferramenta que monitora seu site externo e todos os servidores internos. Se um servidor morrer, nada realmente muda do ponto de vista do mundo exterior, mas você quer conhecer e consertar o servidor de qualquer maneira. Se você começar a ter problemas de desempenho ou disponibilidade, o que você não vai querer descobrir é que três servidores ficaram inativos por um mês e o restante está lutando com a carga extra.