Les informations contenues dans les sections suivantes peuvent vous aider dans la gestion de la configuration logicielle d'un cluster (aussi appelé grappe).
Un cluster utilise plusieurs mécanismes de communication internes afin de garantir l'intégrité des données et le bon comportement du cluster lors d'une défaillance. Le cluster utilise ces mécanismes pour :
Contrôler lorsqu'un système peut devenir un membre du cluster
Déterminer l'état des systèmes du cluster
Surveiller le comportement du cluster lors d'une défaillance
Les mécanismes de communication du cluster sont les suivants :
Partitions Quorum (partagées)
Périodiquement, chaque système du cluster écrit un horodatage (aussi appelé timestamp) et un statut du système dans la partition primaire et la partition masquée (aussi appelée shadow partition), qui sont des partitions brutes placées en stockage partagé. Chaque membre du cluster lit le statut et l'horodatage du système écrits par les autres membres et détermine si les informations sont à jour. Les membres essaient de lire ces informations à partir de la partition Quorum primaire. Si cette dernière est corrompue, les membres lisent alors les informations à partir de la partition Quorum masquée et simultanément réparent la partition primaire. La cohérence des données est maintenue grâce à des sommes de contrôle et toute irrégularité entre les partitions est immédiatement corrigée.
Si un membre redémarre mais ne peut écrire dans les deux partitons Quorum, le système ne pourra pas joindre le cluster. De plus, si un membre existant ne peut plus écrire dans les deux partitons, il se retire du cluster en s'arrêtant.
Les partitions partagées ne servent que de mécanisme de communication dans des clusters composés de deux membres dans lesquels le disjoncteur du réseau est désactivé.
Surveillance des interrupteurs distants
De temps à autre, chaque membre contrôle la santé de la connexion de l'interrupteur distant, s'il y en a un. Le membre utilise ces informations pour déterminer le statut de l'autre membre. La défaillance totale du mécanisme de communication de l'interrupteur n'entraîne pas automatiquement une procédure de failover. Si un interrupteur ne réussit pas à prendre le relais d'un système suspendu (aussi qualifié de hung), aucune procédure de failover n'est amorcée étant donné que l'infrastructure du cluster n'est pas en mesure de garantir l'état de ses membres actuels.
Pulsations Ethernet
Les membres sont connectés entre eux à l'aide de lignes Ethernet ou série point-à-point. Périodiquement, chaque membre envoie des pings (heartbeat pings) sur ces lignes. Le cluster utilise ces informations pour déterminer le statut des membres et pour assurer que le cluster fonctionne correctement. La panne totale du mécanisme de communication par pulsations n'amorce pas automatiquement une procédure de failover.
Si un membre établit que l'horodatage Quorum d'un autre membre n'est pas à jour, il vérifiera le statut des pulsations. Si ces dernières sont toujours émises en direction du membre, le logiciel de cluster ne prendra aucune mesure. Si un membre cluster ne met pas son horodatage à jour pendant un certain temps et ne répond pas aux pings de pulsations, il sera considéré comme étant hors fonctionnement.
Le cluster reste opérationnel tant qu'un système du cluster peut écrire sur les partitions partagées, même si tous les autres mécanismes de communication sont défaillants.
Il convient de remarquer ici qu'une partiton est seulement utilisée comme partition de secours dans certaines configurations de cluster à deux membres. L'algorithme d'appartenance au réseau représente le premier élément déterminant les membres du cluster qui sont actifs et ceux qui ne le sont pas. Dans ce genre de configuration, un membre qui ne met pas à jour son horodatage ne peut jamais engendrer une procédure de failover à moins que clumembd n'établisse que le membre est défaillant.
Précédent | Sommaire | Suivant |
Numéros d'identification SCSI | Niveau supérieur | Scénarios de failover et récupération |