Cluster Node com Configurações TCP/IP Corrompidas

Por: Fernando Lanner Cardoso

Há alguns dias trabalhamos em um caso bastante interessante em termos de troubleshooting. Decidimos por escrever este artigo não somente por ser um problema curioso mas também por entender que este pode ser enfrentando em soluções semelhantes. A fim de tornar este artigo mais interessante, iniciaremos com a descrição do problema para só então passarmos para o desenrolar do caso.

Tratava-se de uma configuração típica de Failover Cluster. Basicamente o ambiente era composto de um de 2 nodes Windows Server 2003 Enterprise (x86), SQL Server 2005, TSM (Tivoli Storage Manager) instalado em cluster e Symantec Endpoint Protection. Os dois nodes conectados à um shared storage. Quorum configurado no shared storage (shared bus). Rede interna do cluster consistindo de somente um cabo conectando ambas as máquinas.

Obs.: As capturas de tela que que temos neste artigo foram todas tomadas de um ambiente de laboratório configurado para simular o problema. Os nomes de servidores, domínio, endereços IPs não são os do caso real. De qualquer forma as capturas são reprodução fiel do problema em si.

Problema inicial

O problema inicial reportado era que não era possível trazer recursos do cluster para online.

Sintomas/Troubleshooting

Identificamos que não era possível trazer somente recursos IP Address para online. Os demais problemas com outros recursos ocorriam somente com recursos que dependiam do IP Address. Praticamente todos os demais.

O fato do recurso IP Address não vir para online aponta para rede como sendo causa do problema. Passamos então a direcionar nosso foco para questões de rede. E encontramos uma série de sintomas, que descrevemos a seguir.

Ao executar um ping contra a próprio host, desde o node 1 para ele mesmo, os pacotes eram disparados contra o endereço de loopback:

Pinging cluster01.acme.com [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Eventualmente, durante o troubleshooting ocorreu uma situação específica onde a mensagem retornada era:

Ping request could not find host cluster01. Please check the name and try again.

Primeira suspeita, resolução de nome. A resolução de nome estava ok. O nslookup retornava o endereço IP correto da máquina, endereço IP da interface pública do cluster. Por via das dúvidas ainda verificamos o arquivo hosts, que também não nos apontou para a solução do problema.

Outros sintomas de problemas com o TCP/IP que estávamos enfrentando eram

Ipconfig não mostrava qual o default gateway que estava configurado para a interface. Estava em branco.

Ainda, verificando via Status da interface, percebemos que as informações de configuração estavam todas em branco:

Isso ocorria com todas as interfaces da máquina.

Ao verificar as configurações de TCP/IP da máquina, verificamos que esta estava configurada para utilizar DHCP. O que com certeza não deveria ser o caso desta máquina, por ser um node de um cluster.

E finalmente o sintoma que provavelmente mais causou estranheza entre todos, o hostname do node 2 trocou. Passou a ter o mesmo hostname do node 1.

Neste momento já estava bastante claro que o problema era relacionado com o fato das configurações TCP/IP não estarem corretas ou não serem mantidas uma vez corretamente configuradas.

No caso da configuração TCP/IP, conseguíamos refazer normalmente. Mas ao reiniciar a máquina, os problemas voltavam a ocorrer. Conseguíamos reconfigurar tudo após um reset de configuração TCP/IP. No caso específico do default gateway tínhamos que reiniciar o valor da chave de registry correspondente.

Reiniciando o node, porém, os problemas todos voltavam.

Foi então que descobrimos que o problema estava relacionado ao Cluster Service. Trazendo o cluster online, o problema retornava. Mais adiante identificamos que não bastava trazer o cluster para online, tínhamos que trazer o grupo do TSM para online. Colocando somente o Cluster Group não enfrentávamos o problema.

Só então finalmente o problema se esclareceu quando descobrimos que estávamos indicando uma registry key errada na configuração de um generic service utilizado pelo TSM.

Por não ser uma aplicação cluster-aware, a configuração do TSM exige que Generic Services sejam utilizados. Ainda por não ser uma aplicação cluster-aware, na maioria das vezes é necessário que se indique no Generic Service em questão que chaves de registry necessitam ser replicadas entre os nodes do cluster para garantir a funcionalidade da aplicação em cluster.

O documento que descreve este processo de configuração é:

Checklist: Installing a Generic Service resource

Este documento indica que temos que temos que informar o nome da chave de registry dentro da chave Services que queremos replicar. Na solução estávamos indicando a chave em si.

Melhor ilustrando:

O fato de que tínhamos essa chave indicada nesta configuração explica porque o comportamento das configurações IP se apresentava completamente errático. O que estava acontecendo na verdade é que configurações particulares de um node estavam sendo replicadas para o outro node. Gerando toda a série de problemas que estávamos enfrentando.

Somente como exemplo, dentro da chave Services temos uma entrada para o hostname da máquina:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Hostname

Conclusão

Indicando essa chave e reiniciar o serviço de cluster, os problemas acima ocorrerão imediatamente. O cluster não funciona com esta configuração. Tudo nos leva a crer que esta configuração estava errada há tempos mas ainda não havia sido ativada por um reinicio do serviço.

Corrigida esta chave, conforme documentação do cliente que indicava a chave correta que o TSM necessita que seja replicada, e reajustadas as configurações TCP/IP tudo se normalizou.