TESTE DE UM DISPOSITIVO DE CERCA

A vedação é uma parte fundamental da infra-estrutura do Red Hat Cluster e, portanto, é importante validar ou testar se a vedação está funcionando corretamente.

Use o seguinte procedimento para testar um dispositivo de cerca.

1. Use ssh, telnet, HTTP, ou qualquer protocolo remoto que for usado para conectar ao dispositivo para fazer o login e testar manualmente o dispositivo de cerca ou ver qual saída é dada. Por exemplo, se você estiver configurando uma cerca para um dispositivo habilitado para IPMI, então tente fazer o log in remotamente com ipmitool. Tome nota das opções usadas ao fazer o login manualmente, pois essas opções podem ser necessárias ao usar o agente de vedação. Se você não conseguir entrar no dispositivo de cerca, verifique se o dispositivo é "pingável", não há nada como uma configuração de firewall que esteja impedindo o acesso ao dispositivo de cerca, o acesso remoto está habilitado no dispositivo de cerca e as credenciais estão corretas. 2. Executar o agente de vedação manualmente, usando o roteiro do agente de vedação. Isto não

requer que os serviços de cercado estejam sendo executados, portanto, você pode executar esta etapa antes que o dispositivo seja configurado no cercado. Isto pode garantir que o dispositivo de cerca esteja respondendo corretamente antes de prosseguir.

NOTA

Os exemplos nesta seção utilizam o script fence_ipmilan fence agent para um dispositivo iLO. O verdadeiro agente de cerca que você usará e o comando que chama esse agente dependerá do hardware de seu servidor. Você deve consultar a página de manual do agente de cerca que você está usando para determinar quais opções especificar. Você normalmente precisará saber o login e a senha do dispositivo de cerca e outras informações relacionadas ao dispositivo de cerca. O exemplo a seguir mostra o formato que você usaria para executar o script fence_ipmilan fence agent com o parâmetro -o status para verificar o status da interface do dispositivo de cerca em outro nó sem realmente cercar o mesmo. Isto permite que você teste o dispositivo e o faça funcionar antes de tentar reiniciar o nó. Ao executar este comando, você especifica o nome e a senha de um usuário iLO que tem permissão para ligar e desligar o dispositivo iLO.

# fence_ipmilan -a ipaddress -l username -p password -o status

O exemplo a seguir mostra o formato que você usaria para executar o script fence_ipmilan fence agent com o parâmetro -o reboot. A execução deste comando em um nó reinicia o nó gerenciado por este dispositivo iLO.

# fence_ipmilan -a ipaddress -l username -p password -o reboot

Se o agente da cerca falhou em fazer uma ação de status, desligado, ligado ou reinicialização, você deve verificar o hardware, a configuração do dispositivo da cerca e a sintaxe de seus comandos. Além disso, você pode executar o script do agente de cerca com a saída de debug habilitada. A saída de depuração é útil para alguns agentes de cercas para ver onde na

seqüência de eventos o script do agente de cercas está falhando ao efetuar login no dispositivo de cercas.

# fence_ipmilan -a ipaddress -l username -p password -o status -D /tmp/$(hostname)- fence_agent.debug

Ao diagnosticar uma falha que tenha ocorrido, você deve se certificar de que as opções especificadas ao fazer o login manualmente no dispositivo de cerca são idênticas ao que você passou para o agente de cerca com o roteiro do agente de cerca.

Para agentes de cerca que suportam uma conexão criptografada, você pode ver um erro devido à falha na validação do certificado, exigindo que você confie no host ou que você use o

parâmetro ssl-insecure do agente de cerca. Da mesma forma, se o SSL/TLS estiver desabilitado no dispositivo alvo, você pode precisar prestar contas disso ao definir os parâmetros SSL para o agente de cerca.

NOTA

Se o agente de vedação que está sendo testado é um fence_drac, fence_ilo, ou algum outro agente de vedação para um dispositivo de gerenciamento de

sistemas que continua a falhar, então volte a tentar fence_ipmilan. A maioria dos cartões de gerenciamento de sistemas suporta o login remoto IPMI e o único agente de vedação suportado é fence_ipmilan.

3. Uma vez que o dispositivo de cerca tenha sido configurado no aglomerado com as mesmas opções que funcionaram manualmente e o aglomerado tenha sido iniciado, teste a cerca com o comando pcs stonith fence de qualquer nó (ou mesmo várias vezes de diferentes nós), como no exemplo a seguir. O comando pcs stonith fence lê a configuração do cluster a partir do CIB e chama o agente de cerca como configurado para executar a ação de cerca. Isto verifica se a configuração do aglomerado está correta.

# pcs stonith fence node_name

Se o comando pcs stonith fence funcionar corretamente, isso significa que a configuração da cerca para o conjunto deve funcionar quando ocorrer um evento de cerca. Se o comando falhar, isso significa que o gerenciamento do cercado não pode invocar o dispositivo de cercado através da configuração que ele recuperou. Verifique as seguintes questões e atualize sua configuração de cercas conforme necessário.

Verifique a configuração de sua cerca. Por exemplo, se você tiver usado um mapa do host, você deve assegurar-se de que o sistema possa encontrar o nó usando o nome do host que você forneceu.

Verifique se a senha e o nome de usuário do dispositivo incluem algum caractere especial que possa ser mal interpretado pela concha do bash. Certifique-se de digitar senhas e nomes de usuário rodeados de aspas que possam resolver este problema.

Verifique se você pode se conectar ao dispositivo usando o endereço IP exato ou o nome do host que você especificou no comando pcs stonith. Por exemplo, se você der o nome do host no comando stonith mas testar usando o endereço IP, este não é um teste válido. Se o protocolo que seu dispositivo de cerca usa for acessível a você, use esse protocolo para tentar se conectar ao dispositivo. Por exemplo, muitos agentes usam ssh ou telnet. Você deve tentar conectar-se ao dispositivo com as credenciais que você forneceu ao configurar o dispositivo, para ver se você recebe um prompt válido e pode fazer o login no dispositivo.

Se você determinar que todos os seus parâmetros são apropriados, mas ainda tiver problemas de conexão com seu dispositivo de cerca, você pode verificar o registro no próprio dispositivo de cerca, se o dispositivo fornece isso, o que mostrará se o usuário se conectou e qual comando o usuário emitiu. Você também pode procurar no arquivo

/var/log/messages por casos de pedraria e erro, o que poderia dar alguma idéia do que está

acontecendo, mas alguns agentes podem fornecer informações adicionais.

4. Uma vez que os testes do dispositivo de vedação estejam funcionando e o conjunto esteja em funcionamento, teste uma falha real. Para isso, tomar uma ação no aglomerado que deve iniciar uma perda simbólica.

Desmontar uma rede. A maneira como você toma uma rede depende de sua configuração específica. Em muitos casos, você pode fisicamente puxar a rede ou os cabos de energia para fora do host. Para informações sobre como simular uma falha de rede, veja Qual é a maneira adequada de simular uma falha de rede em um Cluster RHEL?

NOTA

Desabilitar a interface de rede no host local em vez de desconectar fisicamente a rede ou os cabos de energia não é recomendado como um teste de vedação, pois não simula com precisão uma falha típica do mundo real.

O seguinte exemplo bloqueia a corosync, assumindo que a porta padrão corosync é usada,

firewalld é usado como firewall local, e a interface de rede usada pela corosync está na

zona padrão do firewall:

# firewall-cmd --direct --add-rule ipv4 filter OUTPUT 2 -p udp --dport=5405 -j DROP

# firewall-cmd --add-rich-rule='rule family="ipv4" port port="5405" protocol="udp" drop'

Simule um acidente e entre em pânico com sua máquina com sysrq-trigger. Note, entretanto, que desencadear um pânico no núcleo pode causar perda de dados; é recomendável que você desative seus recursos de cluster primeiro.

# echo c > /proc/sysrq-trigger