Comment configurer STONITH dans un cluster de stimulateurs cardiaques linux HA actif / passif à 2 nœuds?

J'essaie de configurer un cluster Linux-HA actif / passif (2 nœuds) avec corosync et pacemaker pour maintenir une base de données PostgreSQL opérationnelle. Il fonctionne via DRBD et un service-ip. Si node1 échoue, node2 devrait prendre le relais. De même si PG s'exécute sur node2 et qu'il échoue. Tout fonctionne bien sauf la chose STONITH.

Entre les nœuds se trouve une connexion HA dédiée (10.10.10.X), j'ai donc la configuration d'interface suivante:

eth0            eth1            host
10.10.10.251    172.10.10.1     node1
10.10.10.252    172.10.10.2     node2

Stonith est activé et je teste avec un agent ssh pour tuer les nœuds.

crm configure property stonith-enabled=true
crm configure property stonith-action=poweroff
crm configure rsc_defaults resource-stickiness=100
crm configure property no-quorum-policy=ignore

crm configure primitive stonith_postgres stonith:external/ssh \
                params hostlist="node1 node2"
crm configure clone fencing_postgres stonith_postgres

crm_mon -1 spectacles:

============
Last updated: Mon Mar 19 15:21:11 2012
Stack: openais
Current DC: node2 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
4 Resources configured.
============

Online: [ node2 node1 ]

Full list of resources:

 Master/Slave Set: ms_drbd_postgres
     Masters: [ node1 ]
     Slaves: [ node2 ]
 Resource Group: postgres
     fs_postgres        (ocf::heartbeat:Filesystem):    Started node1
     virtual_ip_postgres        (ocf::heartbeat:IPaddr2):       Started node1
     postgresql (ocf::heartbeat:pgsql): Started node1
 Clone Set: fencing_postgres
     Started: [ node2 node1 ]

Le problème est: lorsque je coupe la connexion entre les interfaces eth0, cela tue les deux nœuds . Je pense que c'est un problème avec le quorum, car il n'y a que 2 nœuds. Mais je ne veux pas ajouter un 3ème nœud juste pour le calcul du bon quorum.

Y a-t-il des idées pour résoudre ce problème?

Il s'agit d'une question légèrement plus ancienne, mais le problème présenté ici est basé sur une idée fausse sur le fonctionnement et le moment du basculement dans les clusters, en particulier les clusters à deux nœuds.

L'essentiel est le suivant: vous ne pouvez pas effectuer de test de basculement en désactivant la communication entre les deux nœuds. Cela entraînera exactement ce que vous voyez, un scénario à cerveau divisé avec STONITH mutuel supplémentaire. Si vous voulez tester les capacités de clôture, un simple killall -9 corosyncsur le nœud actif fera l'affaire. D'autres façons sont crm node fenceou stonith_admin -F.

D'après la description pas assez complète de votre cluster (où est la sortie de crm configure showet cat /etc/corosync/corosync.conf?), Il semble que vous utilisez les adresses 10.10.10.xx pour la messagerie, c'est-à-dire la communication Corosync / cluster. Les adresses 172.10.10.xx sont vos adresses réseau régulières / de service et vous accéderez à un nœud donné, par exemple en utilisant SSH, par son adresse 172.10.10.xx. DNS semble également résoudre un nom d'hôte de nœud comme node1172.10.10.1.

Vous avez configuré STONITH pour utiliser SSH, ce qui n'est pas une très bonne idée en soi, mais vous êtes probablement en train de tester. Je ne l'ai pas utilisé moi-même mais je suppose que l'agent SSH STONITH se connecte à l'autre nœud et émet une commande d'arrêt, comme ssh root@node2 "shutdown -h now"ou quelque chose d'équivalent.

Maintenant, que se passe-t-il lorsque vous coupez la communication de cluster entre les nœuds? Les nœuds ne voient plus chaque nœud comme vivant et bien, car il n'y a plus de communication entre eux. Ainsi, chaque nœud suppose qu'il est le seul survivant d'un événement malheureux et essaie de devenir (ou de rester) le nœud actif ou principal. C'est le scénario classique et redouté du cerveau divisé .

Cela consiste en partie à s'assurer que l'autre nœud, manifestement et vraisemblablement en panne, est en panne pour de bon, c'est là que STONITH entre en jeu. Gardez à l'esprit que les deux nœuds jouent maintenant le même jeu: essayer de devenir (ou rester) actif et prendre sur toutes les ressources du cluster, ainsi que de tirer sur l'autre nœud dans la tête.

Vous pouvez probablement deviner ce qui se passe maintenant. node1fait ssh root@node2 "shutdown -h now"et node2fait ssh root@node1 "shutdown -h now". Cela n'utilise pas le réseau de communication de cluster 10.10.10.xx mais le réseau de service 172.10.10.xx. Étant donné que les deux nœuds sont en fait bien vivants, ils n'ont aucun problème à émettre des commandes ou à recevoir des connexions SSH, de sorte que les deux nœuds se tirent dessus en même temps. Cela tue les deux nœuds.

Si vous n'utilisez pas STONITH, un cerveau divisé pourrait avoir des conséquences encore pires, en particulier dans le cas de DRBD, où vous pourriez vous retrouver avec les deux nœuds devenant primaires. La corruption des données est susceptible de se produire et le split-brain doit être résolu manuellement.

Je recommande de lire le matériel sur http://www.hastexo.com/resources/hints-and-kinks qui est écrit et maintenu par les gars qui ont contribué (et contribuent toujours) une grande partie de ce que nous appelons aujourd'hui "le Linux HA empiler".

TL; DR : Si vous coupez la communication de cluster entre vos nœuds afin de tester votre configuration de clôture, vous vous trompez . Utilisez killall -9 corosync, crm node fenceou à la stonith_admin -Fplace. La coupure de la communication du cluster entraînera uniquement un scénario de cerveau divisé, qui peut et conduira à une corruption des données.

Vous pouvez essayer d'ajouter auto_tie_breaker: 1dans la section quorum de /etc/corosync/corosync.conf

Lorsque ATB est activé, le cluster peut subir jusqu'à 50% de défaillances des nœuds en même temps, de manière déterministe. La partition de cluster, ou l'ensemble de nœuds qui sont toujours en contact avec le nœud qui a l'ID de nœud le plus bas, restera en quorat. Les autres nœuds seront interrogés.

Essayez de lire le chapitre Quorum et clusters à deux nœuds de la documentation de Pacemaker.

Vérifiez ceci pour le cluster HA à l'aide de Pacemaker: http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html