Se você estiver realmente migrando de um ambiente de servidor único para um cluster com balanceamento de carga de 10, esse conjunto de avisos será ativado instantaneamente para mim. Eu tenho um monte de perguntas que você provavelmente já descobriu, mas vou apontá-las de qualquer maneira e, em seguida, fornecer algumas considerações genéricas.
Como você chegou ao número 10? Por que você não está escalando para 2 ou 3 e adicionando mais conforme necessário?
Por que você vai carregar o balanceamento em primeiro lugar? Por exemplo, você está indo para alta carga, alta disponibilidade ou ambos? Existe uma necessidade imediata, ou isso é uma necessidade preditiva?
Se você está sobrecarregado agora e tentando escalar para resolvê-lo, uma grande pergunta que eu faria seria se você realmente identificou o gargalo. Você menciona que está usando o .NET e o SQL para estado de sessão, portanto, eu acho que você também está trabalhando com um aplicativo com suporte a SQL. Você também está equilibrando o servidor SQL? O SQL Server pode lidar com 10x as conexões que você tem agora?
Se você está procurando disponibilidade, você considerou todos os outros pontos de falha? Você tem redundância no seu balanceador de carga? Você tem redundância em seu (s) servidor (es) de banco de dados? Você tem redundância no seu uplink (considere todos os pontos: cabo único, switch único, etc)? Para disponibilidade, você é tão seguro quanto 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 ficar inativo.
Na maior parte do tempo, o gargalo será o seu servidor de banco de dados. Se for esse o caso, não importa quantos front ends você tenha.
-
Se você estiver usando SSL, existem dois modos típicos em que os balanceadores de carga operam, o que afeta a maneira como o SSL funciona:
- Camada 4: este é o nível TCP. O SSL é tratado 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 manipula a 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 é geralmente HTTP. Às vezes, isso é chamado de "descarga de SSL" e normalmente é útil se o balanceador de carga for eficiente e você não quiser que o servidor de aplicativos manipule a sobrecarga de criptografia do SSL (por exemplo, seu aplicativo usa muita CPU).
-
Certifique-se de que seu balanceador esteja configurado para remover os servidores quando eles caírem e testar essa funcionalidade. Você deve conseguir servidores inativos sem afetar o restante dos servidores. Observe as verificações de tempo de resposta do PING vs HTTP vs. (Ping não significa que o HTTP está respondendo)
-
Carregue o teste do seu ambiente. Você pode não ser capaz de fazer o full-out, mas você deve ser capaz de carregar pelo menos alguns servidores (com apenas os dois no balanceador).
-
Execute um ambiente de preparação. Isso pode não ser 10 servidores, mas deve ser suficiente para replicar o sistema de produção para testes de implantação.
-
Tenha um script de implantação automatizado e seja muito rigoroso em relação ao gerenciamento de origem e ao gerenciamento de configuração. O ideal é que tudo TUDO (incluindo arquivos de configuração) esteja em um sistema de controle de origem e você tenha compilações automatizadas para criar tudo diretamente no seu instalador / script.
-
Obtenha uma ferramenta que monitore seu site externo e todos os servidores internos. Se um servidor morre, nada realmente muda da perspectiva do mundo externo, mas você quer saber e consertar o servidor de qualquer maneira. Se você começar a ter problemas com desempenho ou disponibilidade, o que você não quer encontrar é que três servidores ficaram inativos por um mês e o restante está lutando com a carga extra.