Suite de cluster de Red Hat: Configuration et gestion d'un cluster | ||
---|---|---|
Précédent | Annexe C. Informations logicielles supplémentaires | Suivant |
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.
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.
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.
Jeu d'essais : killall -KILL clumembd
Comportement attendu : Redémarrage du système
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.
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.
Jeu d'essais : killall -KILL cluquorumd
Comportement attendu : Redémarrage du système
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.
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.
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.
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.
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.
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.
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.
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.
Précédent | Sommaire | Suivant |
Scénarios de failover et récupération | Niveau supérieur | Comportements courants : Deux clusters avec un disjoncteur basé sur le disque |