Guide des notions fondamentales de Sun Cluster pour SE Solaris

Mécanisme failfast pour la séparation en cas d'échec

On appelle failfast le mécanisme par le biais duquel la structure du cluster s'assure qu'un nœud défectueux ne peut pas redémarrer et commencer à écrire dans le stockage partagé.

Les nœuds membres du cluster activent en permanence un ioctl spécifique, MHIOCENFAILFAST, pour les disques auxquels ils ont accès, notamment les disques de quorum. Cet ioctl est une directive adressée au pilote de disque. Il permet à un nœud de paniquer s'il ne peut pas accéder à un disque réservé par un autre nœud.

L'ioctl MHIOCENFAILFAST provoque la vérification par le pilote de l'erreur renvoyée par toutes les lectures et écritures d'un nœud sur le disque s'il s'agit du code d'erreur Reservation_Conflict . À l'arrière-plan, l'ioctl teste régulièrement le disque pour rechercher le code d'erreur Reservation_Conflict. Les chemins de flux de contrôle au premier plan et à l'arrière-plan paniquent si le code Reservation_Conflict est renvoyé.

Pour les disques SCSI-2, les réservations ne sont pas persistantes ; elles ne survivent pas aux réinitialisations des nœuds. Pour les disques SCSI-3 dotés de la fonction PGR (réservation de groupe persistante), les informations de réservation sont stockées sur le disque et persistent après réinitialisation des noeuds. Le mécanisme failfast fonctionne de la même façon, que vous ayez des disques SCSI-2 ou SCSI-3.

Si un nœud perd la connectivité aux autres nœuds du cluster et qu'il ne fait pas partie d'une partition pouvant atteindre un quorum, il est supprimé de force du cluster par un autre nœud. Un autre noeud faisant partie de la partition pouvant atteindre le quorum effectue des réservations sur les disques partagés. Si le nœud qui ne possède pas de quorum essaie d'accéder aux disques partagés, il reçoit un conflit de réservation et panique du fait du mécanisme failfast.

Après la panique, le noeud peut soit se réinitialiser et tenter de rejoindre le cluster, soit rester sur l'invite de la PROM OpenBootTM (OBP) si le cluster est constitué de systèmes SPARC. L'action entreprise est déterminée par la définition du paramètre auto-boot?. Vous pouvez définir auto-boot? sur eeprom(1M), à l'invite ok de la PROM OpenBoot dans un cluster SPARC. Vous pouvez également configurer ce paramètre avec l'utilitaire SCSI que vous pouvez exécuter après le démarrage du BIOS dans un cluster x86.