C.3. Comportements de cluster courants : Aperçu général

Perte de connectivité à un interrupteur ou impossibilité d'isoler un membre

Raisons courantes : Interrupteur série déconnecté du membre effectuant le contrôle. Interrupteur réseau déconnecté du réseau.

Comportement attendu : Les membres contrôlés par l'interrupteur ne pourront être arrêtés ou redémarrés. Dans ce cas précis, si le membre est suspendu, les services ne seront pas pris en relais par tout autre membre contrôlé par l'interrupteur en question.

Vérification : Exécutez clustat pour vérifier que les services sont toujours identifiés en tant que running (c'est-à-dire en cours d'exécution) sur le membre, bien que selon les informations d'appartenance au cluster, la réponse soit inactive.

Dissolution du quorum du cluster

Raisons courantes : Une majorité des membres du cluster (par exemple, 3 ou 5 membres) se trouvent soudainement hors-ligne

Jeu d'essais : Dans un cluster composé de 3 membres, arrêtez le logiciel de cluster sur deux membres.

Comportement attendu : Tous les membres qui ne disposent pas d'interrupteurs de contrôle redémarrent immédiatement. Tous les services s'arrêtent immédiatement et leur état n'est pas mis à jour sur le support partagé (lors de l'utilisation de clustat, il est possible que les blocs de statut du service affiche que ce dernier est en cours d'exécution). Les gestionnaires de services s'arrêtent. Les verroux du cluster sont perdus et ne sont plus disponibles.

Vérification : Exécutez clustat sur l'un des membres toujours actifs.

Membre perd son statut de participation au quorum du cluster mais n'est pas suspendu

Raison courante : Perte de connectivité totale avec les autres membres.

Jeu d'essais : Décnnectez tous les câbles réseau d'un membre du cluster.

Comportement attendu  Si le membre ne dispose pas d'interrupteurs de contrôle, il redémarre immédiatement. Sinon, il essaie d'arrêter les services aussi rapidement que possible. Si un quorum existe, l'ensemble des membres composant le quorum du cluster isoleront le membre.

clumembd plante

Jeu d'essais : killall -KILL clumembd

Comportement attendu : Redémarrage du système

clumembd en suspens, chien de garde utilisé

Jeu d'essais : killall -STOP clumembd

Comportement attendu : Système redémarrera probablement si clumembd est en suspens pour une durée supérieure à quelques secondes (failover_time - 1). Amorcé de manière externe par l'horloge chien de garde.

clumembd en suspens, aucun chien de garde utilisé

Jeu d'essais : killall -STOP clumembd

Comportement attendu : Système redémarrera probablement si clumembd est en suspens pour une durée supérieure à quelques secondes (failover_time - 1). Amorcé de manière interne par clumembd.

cluquorumd plante

Jeu d'essais : killall -KILL cluquorumd

Comportement attendu : Redémarrage du système

clusvcmgrd plante

Jeu d'essais : killall -KILL clusvcmgrd

Comportement attendu : cluquorumd lance à nouveau clusvcmgrd, qui exécute la phase d'arrêt de tous les services. Les services qui sont arrêtés sont redémarrés.

Vérification : Consultez les journaux du système et vérifiez s'ils contiennent un message d'avertissement provenant de cluquorumd.

clulockd plante

Jeu d'essais : killall -KILL clulockd

Comportement attendu : cluquorumd relance clulockd. Il se peut que les verroux ne soient pas disponibles (empêchant ainsi la transition des services) pour une courte durée.

Vérification : Consultez les journaux du système et vérifiez s'ils contiennent un message d'avertissement provenant de cluquorumd.

Redémarrage du système inattendu sans arrêt propre des services du cluster

Raisons courantes : Tout scénario qui provoque le redémarrage du système.

Jeu d'essais : reboot -fn ; appuyez sur le bouton de réinitialisation.

Comportement attendu : Si un interrupteur contrôle le membre qui redémarre, le système sera également isolé (généralement pris en relais) si un quorum de cluster existe.

Perte du quorum durant un arrêt propre

Jeu d'essais : Arrêt des services du cluster (service clumanager stop) sur tout les membres.

Comportement attendu : Tous les services tournant encore sont arrêtés de manière non propre.

Vérification : Consultez les journaux du système pour tout message d'avertissement.

Opérations d'isolement STONITH réussies

Comportement attendu : Les services sur le membre qui a été isolé sont lancés dans un autre endroit du cluster, dans la mesure du possible.

Vérification : Vérifiez que les services sont, en fait, lancés une fois le membre isolé. Cette opération ne devrait prendre que quelques secondes.

Opérations d'isolement non réussies sur le membre du cluster

Raisons courantes : L'interrupteur a renvoyé un statut d'erreur ou n'est pas joignable.

Jeu d'essais : Déconnectez l'interrupteur qui contrôle un membre et exécutez reboot -fn sur le membre.

Comportement attendu : Les services sur un membre qui n'arrive pas être isolé ne sont pas lancés ailleurs dans le cluster. Si le membre récupère, les services sur le cluster sont redémarrés. Vu qu'il n'existe aucune méthode pour déterminer exactement l'état du membre, il est supposé toujours être en cours d'exécution même si les pulsations se sont arrêtées. Ainsi, tous les services devraient apparaître comme étant en cours d'exécution sur le membre hors service.

Vérification : Exécutez clustat pour vérifier que les services sont toujours identifiés comme étant en cours d'exécution sur le membre, même si il est inactif selon son statut d'appartenance. Les messages indiquant que le membre est maintenant dans un état qualifié de PANIC seront journalisés.

Erreur de lecture de l'une des partitions partagées

Jeu d'essais : Exécutez dd pour écrire des zéros dans la partition partagée.

	    
dd if=/dev/zero of=/dev/raw/raw1 bs=512 count=1
shutil -p /cluster/header

Comportement attendu : L'évènement est enregistré. Les données de la bonne partition partagée sont copiées sur la partition qui renvoie des erreurs.

Vérification : Une deuxième lecture des mêmes données ne devrait pas produire un deuxième message d'erreur.

Erreur de lecture des deux partitions partagées

Raisons courantes : Le média partagé n'est pas joignable ou les deux partitions sont corrompues.

Jeu d'essais : Débranchez le câble SCSI ou Fibre Channel du membre.

Comportement attendu : L'évènement est enregistré. Une action configurée est prise pour répondre à la perte d'accès au stockage partagé (reboot/halt/stop/ignore). L'action par défaut consiste à redémarrer.