9.12. Le fencing se produit au hasard

La cause profonde des fences est toujours un nœud perdant un jeton, cela signifie que celui-ci a perdu la faculté de communiquer avec le reste du cluster et arrêté de retourner la pulsation.

Toute situation résultant en un système ne retournant pas la pulsation dans l'intervalle spécifiée du jeton peut mener à une opération de fencing. Par défaut, l'intervalle du jeton est de 10 secondes. Cet intervalle peut être spécifié en ajoutant la valeur souhaitée (en millisecondes) au paramètre du jeton de la balise totem dans le fichier cluster.conf (par exemple, en paramétrant totem token="30000" pour 30 secondes).

Assurez-vous que le réseau est solide et fonctionne comme prévu.

Assurez-vous que les interfaces utilisées par le cluster pour les communications inter-nœuds ne soient utilisées par aucun autre mode de liaison que les modes 0, 1, ou 2. (Les modes de liaison 0 et 2 sont pris en charge à partir de Red Hat Enterprise Linux 6.4.)

Prenez des mesures pour déterminer si le système est gelé ou s'il y a une panique du noyau. Paramétrez l'utilitaire kdump et voyez si vous trouvez un cœur lors de l'une de ces clôtures.

Assurez-vous qu'il ne s'agisse pas d'un problème attribué par erreur au fencing. Par exemple, lorsque le disque quorum éjecte un nœud dû à un échec du stockage ou à un produit de tierce partie comme Oracle RAC redémarrant un nœud à cause d'une condition externe quelconque. Les journaux des messages sont souvent très utiles pour déterminer de tels problèmes. Lorsque des redémarrages de nœuds se produisent ou lorsque des fences se mettent en place, l'inspection des journaux des messages de tous les nœuds dans le cluster à partir du moment auquel le redémarrage ou le fencing s'est produit devrait être une pratique standard.

Inspectez minutieusement le système pour trouver des défauts de matériel pouvant mener le système à ne plus répondre à la pulsation lorsqu'il le devrait.