Comment configurer Stonith dans un cluster actif / Pacemaker Linux Ha-Pacemaker à 2 nœuds?
J'essaie de configurer un cluster actif/passif (2 nœuds) Linux-ha avec COROSYNC et PACEMAKER pour contenir une base de données PostgreSQL et en cours d'exécution. Cela fonctionne via DRBD et une adresse IP de service. Si Node1 échoue, Node2 devrait prendre la relève. La même chose si pg s'exécute sur Node2 et elle échoue. Tout fonctionne bien à l'exception de la chose de Stonith.
Entre les nœuds est une connexion HA dédiée (10.10.10.x), donc j'ai 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 des 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 ]
problème est: lorsque je coupe la connexion entre les interfaces ETH0, il 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 noeud juste pour calculer le quorum droit.
Y a-t-il des idées pour résoudre ce problème?
C'est une question légèrement plus âgée, mais le problème présenté ici est basé sur une idée fausse sur la manière et le suivi des grappes, en particulier des grappes à deux nœuds, fonctionne.
Le gist est: Vous ne pouvez pas faire de tests de basculement en désactivant la communication entre les deux nœuds. Cela entraînera exactement ce que vous voyez, un scénario cérébral de scission avec supplémentaire, mutuelle Stonith. Si vous souhaitez tester les capacités d'escrime, un simple killall -9 corosync sur le nœud actif fera. D'autres manières sont crm node fence ou stonith_admin -F.
De la description non assez complète de votre cluster (où est la sortie de crm configure show et cat /etc/corosync/corosync.conf?) Il semble que vous utilisiez 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/services et vous accéderiez à 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 node1 au 172.10.10.1.
Vous avez Stonith configuré pour utiliser SSH, ce qui n'est pas une très bonne idée en soi, mais vous ne faites probablement que des tests. Je ne l'ai pas utilisée moi-même mais je suppose que l'agent SSH Stonith se connecte dans l'autre noeud 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 grappes entre les nœuds? Les nœuds ne voient plus chaque noeud comme vivant et bien, car il n'y a plus de communication entre eux. Ainsi, chaque nœud suppose que c'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 classique et redouté scénario cérébral divisé.
Une partie de ceci est de Assurez-vous L'autre, évidemment et probablement en échec de l'échec de l'autre, ce qui est là où Stonith entre en tête. Gardez à l'esprit que les deux Les nœuds sont en train de jouer Le même jeu: Essayer de devenir actif et de prendre en charge toutes les ressources du cluster, ainsi que de tirer sur l'autre nœud de la tête.
Vous pouvez probablement deviner ce qui se passe maintenant. node1 Est-ce que ssh root@node2 "shutdown -h now" et node2 Est-ce que 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 services 172.10.10.xx. Étant donné que les deux nœuds sont en fait vivants et puits, ils n'ont pas de problèmes d'émission de problèmes ni de recevoir des connexions SSH, de sorte que les deux nœuds se tirent en même temps. Cela tue les deux nœuds.
Si vous n'utilisez pas Stonith, un cerveau de scission pourrait avoir des conséquences encore pires, en particulier en cas de DRBD, où vous pourriez vous retrouver avec les deux nœuds devenant primordial. La corruption des données est susceptible de se produire et le cerveau fractionné 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) un gros morceau de quoi Nous appelons aujourd'hui "la pile de Linux ha".
TL; DR : Si vous coupez la communication de cluster entre vos nœuds afin de tester votre configuration de clôture, , vous le faites mal . Utilisation killall -9 corosync, crm node fence ou stonith_admin -F au lieu. La communication de la grappe de coupe n'entraînera qu'un scénario cérébral de scission, qui peut et entraînera une corruption de données.
Vous pouvez essayer d'ajouter auto_tie_breaker: 1 dans la section du quorum de /etc/corosync/corosync.conf.conf
Lorsque ATB est activé, le cluster peut souffrir jusqu'à 50% des nœuds échouant en même temps, de manière déterministe. La partition de cluster, ou l'ensemble de nœuds toujours en contact avec le nœud qui a le nodeID le plus faible restera quorer. Les autres nœuds seront enseignés.
Vérifiez ceci pour HA Cluster à l'aide de PACEMAKER: http://clusterlabs.org/doc/en-us/pacemaker/1/html/clusters_from_scratch/index.html
Essayez de lire les clusters clusters de quorum et à deux nœuds Chapitre de la documentation du stimulateur.