Duas caixas com cargas idênticas que atendem aos mesmos sites tendem a desacelerar e parar de responder ao ping. O ping lento (ou intermitente) faz com que nosso balanceador de carga pense que os servidores estão off-line e os desabilita. Existe um terceiro servidor com conteúdo idêntico que não tem o problema, por isso estou bastante confiante de que não são os sites.
O SO é o Windows Server 2008. A configuração é um pouco especial: como estamos usando o balanceador de carga Barracuda Networks no modo Direct Server Return, tivemos que configurar vários adaptadores de loopback que "falsificam" o IP conforme descrito aqui . O adaptador físico possui o conjunto de encaminhamento ativado como exigido por 2008 para obter o funcionamento dos adaptadores de loopback.
Sintomas:
Pergunta:
Quais possíveis razões existem para isso? O que devo tentar diagnosticar isso? Eu não descartei nada. Configuração de switch, domain / dns server, todas as idéias são bem-vindas.
Infelizmente, tenho muito pouco conhecimento de boa administração de rede, por isso respostas óbvias também são bem-vindas.
EDITAR:
Em resposta a algumas das questões colocadas.
Eu entrei em contato com Barracuda e eles parecem ser da opinião de que o problema está relacionado à rede. Eu acho que eu concordo neste momento.
O IP é atribuído a uma interface física, não compartilhada entre servidores. O ping é feito dentro da mesma sub-rede.
A terceira caixa lida com toda a carga do site quando os outros dois caem e não tem muito problema com isso, mas ocasionalmente também tem problemas. Eu não encontrei um padrão com esse ainda.
Esta noite, sentei-me com outro (mais experiente) cara da rede para examinar algumas das configurações de domínio e servidor. Uma das coisas que ele encontrou foi uma configuração ruim de DNS nos controladores de domínio. Eles foram configurados com servidores de DNS externos como suas alternativas, em vez do outro DC. Nós os trocamos para referenciar um ao outro para o dns, e adicionamos o encaminhamento ao serviço do DNS. Também removemos referências externas de DNS de todos os servidores da web.
EDIT 2:
Com o Wireshark, pude examinar o tráfego ICMP durante um período de inatividade. Comecei este teste porque não consegui acessar uma pasta compartilhada na caixa 2 da caixa 1.
Teste:
Então, de alguma maneira, o tráfego entre as duas caixas está causando a falha da caixa 2 no ICMP por um período de tempo.
Devo observar que a caixa 1 estava funcionando bem durante todo o teste, mas não visualizou solicitações da caixa 2. Durante o ping da caixa 1 da caixa 2, o Wireshark na caixa 2 exibiu uma mensagem "Destino inacessível (Comunicação filtrada administrativamente)" de um IP de origem que eu não reconheci.
Você precisa usar ping ICMP para o seu teste de servidor? As solicitações HTTP são suportadas pela maioria dos balanceadores de carga e geralmente são uma ideia melhor, já que seu servidor da Web pode estar inativo enquanto sua placa de rede ainda está ativa.
Eu verificaria primeiro com a Barracuda Networks. Isso pode ser um problema conhecido. Nós tivemos um problema semelhante que acabou sendo nosso balanceador de carga da Cisco. Uma atualização de firmware corrigiu o problema.
O terceiro servidor está sendo carregado ou é exclusivo dos outros dois de outra maneira?
Sem saber mais, sugiro que você obtenha Wireshark nesses servidores enquanto faz ping e analisa a atividade do ICMP. Minha suspeita (possivelmente infundada) é que esses servidores estão com problemas ARP e enviando pacotes de resposta de volta, mas você nunca os está obtendo.
Com o Wireshark, defina seu filtro como "arp ou icmp" e veja o que ele traz. Você também deve dar uma rápida olhada nos seus logs de eventos do sistema - pode haver algo óbvio lá que atua como adivinhação.
Se você não estiver familiarizado com arp, é o protocolo para traduzir os endereços da camada 3 (IP) para os endereços da camada 2 (MAC). Isso tem que acontecer corretamente ou o quadro da camada 2 contendo o pacote da camada 3 nunca será enviado ou chegará ao destino errado.
Finalmente, as recomendações de velocidade / frente e verso dos outros pôsteres são boas práticas sólidas, embora eu duvido que elas sejam a causa raiz aqui. Observe que, em gigabit ethernet, você não precisa mais se preocupar com a autonegociação.
EDITAR
As alterações de DNS feitas são uma boa ideia, mas é difícil imaginar um cenário em que isso levaria a tempos limite de ICMP. Possivelmente, o aplicativo está bloqueando milhares de consultas DNS e comendo seus recursos de tal forma que não pode responder ao ICMP?
De qualquer forma, se isso não resolver o problema, os rastreamentos de pacotes devem mostrar mais do que está acontecendo.
Uma coisa que descobri ajuda a garantir que a NIC no servidor e a porta no switch ao qual ela está conectada estejam configuradas para as mesmas configurações de velocidade e duplex. Eu tive problemas com "auto negociar" e não negociar muito bem, o que começa a causar muitos erros na porta e na placa de rede.
Tente definir suas interfaces manualmente para uma velocidade e evite usar a negociação automática sempre que possível.
Atualize os drivers de rede em seus servidores para a versão mais recente fornecida pelo seu fornecedor de hardware. Acho que isso às vezes corrige problemas de rede estranhos.
Qual foi o IP de origem que fez a filtragem administrativa? O mais provável é que seja a origem do problema e eu suspeito que seja interno ao Load Balancer