C.3. Comportamentos Comuns do Cluster: Geral

Perda de conectividade a um comutador de energia ou falha em controlar um membro

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.

Dissolução do quorum do cluster

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.

Membro perde estado participatório no quorum do cluster, mas não fica pendente

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.

problemas com o clumembd

Teste: killall -KILL clumembd

Comportamento Esperado: Reinicialização do sistema.

clumembd pendente, watchdog em uso

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.

clumembd fica pendente, nenhum watchdog em uso

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.

cluquorumd com problemas

Teste: killall -KILL cluquorumd

Comportamento Esperado: Reinicialização do sistema.

clusvcmgrd com problemas

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.

clulockd com problemas

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.

Reinicialização inesperada do sistema sem o desligamento limpo dos serviços do cluster

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.

Perda do quorum durante o desligamento limpo

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.

Operação de controle STONITH bem-sucedida

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.

Operação de controle do membro do cluster mal-sucedida

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.

Erro ao ler uma das partições compartilhadas

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.

Erro ao ler as duas partições compartilhadas

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).