Red Hat Summit9.5. 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.
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.
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.
NotaOs exemplos nesta seção utilizam o script
fence_ipmilanfence 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_ipmilanfence agent com o parâmetro-o statuspara 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 statusO exemplo a seguir mostra o formato que você usaria para executar o script
fence_ipmilanfence 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 rebootSe 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.debugAo 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-insecuredo 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.NotaSe 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 tentarfence_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.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 fencede qualquer nó (ou mesmo várias vezes de diferentes nós), como no exemplo a seguir. O comandopcs stonith fencelê 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_nameSe o comando
pcs stonith fencefuncionar 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/messagespor casos de pedraria e erro, o que poderia dar alguma idéia do que está acontecendo, mas alguns agentes podem fornecer informações adicionais.
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?
NotaDesabilitar 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.
Bloquear o tráfego corosync tanto na entrada quanto na saída usando o firewall local.
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
