Red Hat Cluster Suite: Configurando e Administrando um Cluster | ||
---|---|---|
Anterior | Apêndice C. Informações Suplementares de Software | Próxima |
Causas Comuns: Comutador de energia serial desconectado do membro controlador. Comutador de energia de rede desconectado da rede.
Comportamento Esperado: Membros controlados pelo comutador de energia não poderão ser desligados ou reiniciados. Neste caso, se o membro ficar pendente, os serviços não serão transferidos de nenhum membro controlado pelo comutador de energia em questão.
Verificação: Execute clustat para verificar se os serviços ainda estão marcados como running no membro, mesmo que estejam inactive de acordo com a associação.
Causas Comuns: A maioria dos membros do cluster (ex.: 3 de 5 membros) ficam offline
Teste: Num cluster de 3 membros, pare o software do cluster em dois membros.
Comportamento Esperado: Todos os membros sem comutadores de energia reiniciam automaticamente. Todos os serviços param imediatamente e seus estados não são atualizados na mídia compartilhada (ao rodar clustat, os blocos de estado do serviço podem apresentar que o serviço está rodando). Administradores do serviço fecham. Bloqueios do cluster são perdidos e tornam-se indisponíveis.
Verificação: Rode clustat em um dos membros ainda ativos.
Causas Comuns: Perda total da conectividade com os outros membros.
Teste: Desconecte todos os cabos de rede de um membro do cluster.
Comportamento Esperado: Se o membro não tem comutadores de energia controladores, reinicia automaticamente. Caso contrário, tenta parar os serviços o mais rápido possível. Se existir um quorum, o conjunto de membros do quorum do cluster controlarão o membro.
Teste: killall -KILL clumembd
Comportamento Esperado: Reinicialização do sistema.
Teste: killall -STOP clumembd
Comportamento Esperado: Reinicialização do sistema pode ocorrer se o clumembd ficar pendente por um período maior que (failover_time - 1) segundos. Acionado externamente pelo timer watchdog.
Teste: killall -STOP clumembd
Comportamento Esperado: Reinicialização do sistema pode ocorrer se o clumembd ficar pendente por um período maior que (failover_time) segundos. Acionado internamente pelo clumembd.
Teste: killall -KILL cluquorumd
Comportamento Esperado: Reinicialização do sistema.
Teste: killall -KILL clusvcmgrd
Comportamento Esperado: cluquorumd re-gera o clusvcmgrd, que roda a fase de parada de todos os serviços. Os serviços que são parados são iniciados.
Verificação: Consulte os registros do sistema e procure por uma mensagem de alerta do cluquorumd.
Teste: killall -KILL clulockd
Comportamento Esperado: cluquorumd re-gera o clulockd. Os bloqueios podem estar indisponíveis (evitando transições de serviço) por um curto período de tempo.
Verificação: Consulte os registros do sistema e procure por uma mensagem de alerta do cluquorumd.
Causas Comuns: Qualquer cenário notório que cause uma reinicialização do sistema.
Teste: reboot -fn; pressionando o reset.
Comportamento Esperado: se um comutador de energia controla o membro sendo reinicializado, o sistema também será controlado (geralmente tendo seus serviços transferidos) se houver um quorum do cluster.
Teste: Parar os serviços do cluster (service clumanager stop) em todos os membros.
Comportamento Esperado: Quaisquer serviços remanescentes são parados de forma 'suja'.
Verificação: Procure por mensagens de alerta nos registros do sistema.
Comportamento Esperado: Os serviços do membro que foi controlado são iniciados em algum outro membro do cluster, se possível.
Verificação: Verifique se os serviços foram, de fato, iniciados após o membro ser controlado. Isto deve levar apenas alguns segundos.
Causas Comuns: Comutador de energia retornou estado de erro ou está inacessível.
Teste: Desconecte o comutador de energia controlando um membro e rode reboot -fn no membro.
Comportamento Esperado: Os serviços de um membro que falha em ser controlado não são iniciados em nenhum outro membro do cluster. Se o membro se recuperar, os serviços do cluster são reiniciados. Como não há maneira de determinar o estado do membro com acuracidade, assume-se que agora ainda está rodando mesmo se os heartbeats pararem. Assim, todos os serviços devem ser reportados como ativos (running) no membro caído.
Verificação: Rode clustat para verificar se os serviços ainda estão marcados como ativos (running) no membro, mesmo que este esteja inativo de acordo com a associação. As mensagens serão registradas afirmando que o membro agora está no estado PANIC.
Teste: Rode dd para gravar zeros na partição compartilhada.
dd if=/dev/zero of=/dev/raw/raw1 bs=512 count=1 |
shutil -p /cluster/header |
Comportamento Esperado: O evento é registrado. Os dados da partição compartilhada boa são copiados para a partição que retornou erros.
Verificação: Uma segunda leitura dos mesmos dados não deve produzir uma segunda mensagem de erro.
Causas Comuns: Mídia compartilhada está inacessível ou ambas partições estão corrompidas.
Teste: Desconecte o cabo SCSI ou Fibre Channel de um membro.
Comportamento Esperado: O evento é registrado. Ação configurada é executada para resolver a perda do acesso ao armazenamento compartilhado (reboot/halt/stop/ignore). A ação default é reinicializar (reboot).