Quorum on Zwindler's Reflection

Un cluster Proxmox VE avec seulement 2 machines !

Fri, 11 Oct 2019 06:40:55 +0000

Depuis le temps que je vous parle de clusters et de Proxmox (en gros, depuis 2015), ou même de clusters tout court, j’ai pu vous en mettre des tartines sur le fait qu’il ne faut pas faire des clusters avec un nombre pair de machines (ou tout autre cas défavorable dans lequel deux moitiés d’un cluster peuvent se retrouver isolées l’une de l’autre). Le split brain, c’est pas bon pour votre Karma, croyez moi sur parole (ou allez voir vous même).

Ça me rappelle la fois où un “““architecte””” de chez Datacore était venu nous expliquer que sa solution de stockage à 2 pattes ne POUVAIT PAS avoir de split brain (alors que si, les ingés du support ont du repasser par derrière pour nous dire que “oui désolé vous avez évidemment raison c’est un cas possible” #LOL).

Bref, et donc à force d’en parler, il fallait bien quand même que je donne un jour la solution pour le faire quand même, mais proprement. Sans trop de surprise, Corosync, la librairie qui gère les clusters Linux depuis qu’on a arrêté de faire des horreurs avec heartbeat (ou pire : cman+rgmanager, achevez moi), gère évidemment les deux possibilités :

Gérer soit même le membre prioritaire en cas de split brain avec un poids (ça on va pas en parler mais sachez que c’est possible)
Ajouter un vote externe pour obtenir un quorum (comme tous les vrais logiciels qui font du clustering un peu sérieux quoi)

Limitations du “Corosync External Vote” dans PVE

La petite déception du jour viendra surtout du fait que, si la documentation de Proxmox VE indique clairement que l’option est supportée, en réalité, le support se limite aux fonctions natives de corosync, et encore pas toutes.

Pas moyen de voir notre vote externe dans l’interface de Proxmox VE par exemple. A priori, le support des quorum disk n’est plus assuré non plus depuis la version 4 de PVE.

Ensuite, il faut aussi savoir que pour l’instant, seul l’utilisation d’une IP pour renseigner le quorum serveur est possible. On ne peut pas utiliser un FQDN, ce qui me parait dingue comme limitation en 2019, mais bon…

Ces deux points mis de côté, vous allez voir, ce n’est pas sorcier. La procédure est en bonne partie détaillée dans la documentation.

Prérequis

Pour ce tutoriel, vous allez donc avoir besoin de 2 machines (a minima), déjà en cluster. Si vous ne les avez pas déjà, je vous invite à regarder les moults tutoriels précédents, en particulier celui sur la mise en place d’un cluster Proxmox VE 6 (le plus récent).

Vous allez aussi avoir besoin d’un serveur tiers (un bout de VM ou de container quelque part, en dehors de vos 2 (ou tout autres quantité de machines étant localisées dans 2 endroits distincts dont il existe un risque qu’ils puissent subitement “ne plus se voir”, d’un point de vue réseau, induisant le fameux split brain tant redouté).

Fun fact, il y a une page de wiki pour faire la même chose à la main avec un RPi.

Ce serveur tiers n’a pas besoin de faire fonctionner Proxmox (c’est même plutôt mieux d’ailleurs car PVE n’a aucune plus-value ici). Ça doit juste être une distrib linux capable d’installer un démon corosync qnetd. Ce serveur, nous l’appellerons “quorum”, par abus de langage grossier ;-).

Configuration

Sur le serveur quorum, installer corosync qnetd. Sur une Debian like, vous avez de la chance, il existe un package présent dans les dépôts par défaut, et il faut simplement faire un :

sudo apt install corosync-qnetd

Ensuite, sur tous les serveurs Proxmox VE de notre cluster, on va installer le package corosync-qdevice, qui va leur permettre d’interroger le quorum.

sudo apt install corosync-qdevice

Sur le serveur quorum de nouveau, ajouter la clé SSH d’un des serveurs PVE (un seul suffit). Une fois que c’est fait, connecter le cluster au quorum.

Cela va sans dire, mais faire la commande depuis le serveur dont on vient d’ajouter la clé, pas l’autre hein ;-p. Et remplacez par l’IP du serveur quorum !

pvecm qdevice setup <QDEVICE-IP>
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
The authenticity of host 'x.x.x.x' can't be established.
ECDSA key fingerprint is SHA256:LPaaaaaaaaaaaaaaaaaPZjaIg.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
(if you think this is a mistake, you may want to use -f option)

Je met volontairement une grosse partie de la trace car comme ça on peut parler de ce que fait la commande pvecm qdevice setup x.x.x.x.

Comme vous pouvez le constater, cette commande semble assez similaire à celle pour créer manuellement le cluster. A savoir, elle commence déjà par copier les clés SSH sur le serveur distant, histoire que tout le monde puisse discuter ensemble en SSH.

INFO: initializing qnetd server
Certificate database (/etc/corosync/qnetd/nssdb) already exists. Delete it to initialize new db
INFO: copying CA cert and initializing on all nodes
node 'pve01': Creating /etc/corosync/qdevice/net/nssdb
password file contains no data
node 'pve01': Creating new key and cert db
node 'pve01': Creating new noise file /etc/corosync/qdevice/net/nssdb/noise.txt
node 'pve01': Importing CA
[...]

Ensuite, on initialise, sur tous les nodes du cluster, le qdevice, qui va permet au node de communiquer avec le quorum. Là j’élude un peu car ça parle beaucoup de certificats et de clés qui sont échangées.

INFO: copy and import pk12 cert to all nodes<br>INFO: add QDevice to cluster configuration
INFO: start and enable corosync qdevice daemon on node 'pve01'...
Synchronizing state of corosync-qdevice.service with SysV service script with /lib/systemd/systemd-sysv-install.

Normalement, si tout se passe bien, vous devriez en arriver là, une fois que tout le monde s’est bien échangé ses certificats, clés et autres joyeusetés crytographiques.

Une petite commande pour vérifier l’état du bazar :

$ pvecm status
Quorum information
------------------
Date: Mon Aug 26 14:49:14 2019
Quorum provider: corosync_votequorum
Nodes: 2
Node ID: 0x00000002
Ring ID: 1/1271796
Quorate: Yes
Votequorum information
----------------------
Expected votes: 3
Highest expected: 3
Total votes: 3
Quorum: 2
Flags: Quorate Qdevice
Membership information
----------------------
Nodeid Votes Qdevice Name
0x00000001 1 A,V,NMW 10.0.0.1
0x00000002 1 A,V,NMW 10.0.0.2 (local)
0x00000000 1 Qdevice

Ça, c’est le genre de choses que j’attends d’un logiciel de clustering digne de ce nom. D’une simple commande, on peut avoir

le nombre de nodes
l’ID du node courant
le nombre de votes actuels, attendus, et minimum pour que le cluster soit “QUORATE”
et enfin l’état de tout le cluster.

Ici, avec 2 nodes + le quorum, on a bien 3 votes. Tant qu’on a 2 votes, on a le quorum, CQFD.

Dans ce cas de figure, si on perd un nœud OU le quorum, on a toujours 2 votes et le cluster doit continuer à fonctionner “normalement”.

Et c’est ce qu’on va vérifier !

On casse un nœud, pour voir

Normalement, si on a pas le serveur quorum, tout devrait être brisé (comme dirait Medieval Ops).

En gros les VMs doivent continuer à tourner, mais toute opération (démarrage de VM, modification quelconque) doit être bloquée (pour éviter de démarrer la même VM à 2 endroits et pleurer pour recoller les morceaux).

Or ici dès que l’hôte n’est plus joignable, le nœud survivant le détecte, et comme le quorum ne voit plus lui non plus qu’un seul nœud, indique au dernier qu’il peut continuer sa vie comme si de rien n’était (c’est glauque…).

$ pvecm status
Quorum information
------------------
Date: Thu Aug 29 11:10:31 2019
Quorum provider: corosync_votequorum
Nodes: 2
Node ID: 0x00000002
Ring ID: 1/1271820
Quorate: Yes
Votequorum information
----------------------
Expected votes: 3
Highest expected: 3
Total votes: 2
Quorum: 2
Flags: Quorate Qdevice
Membership information
----------------------
Nodeid Votes Qdevice Name
0x00000002 1 A,V,NMW 10.0.0.2 (local)
0x00000000 1 Qdevice

Le nombre de vote passe bien à 2 (mais comme on est toujours égal à quorum c’est bon) et le node 1 a bien disparu :

Et la petite déception, pas de visualisation en console du vote du quorum, malgré la mention “Quorate”

Mais bon, c’est quand même cool que ça marche, et en vrai c’est bien l’essentiel ;)

Bonus : Erreur insserv: FATAL: service corosync has to be enabled

Si vous rencontrez l’erreur suivante :

insserv: FATAL: service corosync has to be enabled to use service corosync-qdevice

Allez supprimer le fichier d’init SysV corosync sur tous les hôtes

rm /etc/init.d/corosync-qdevice
systemctl enable corosync-qdevice
systemctl start corosync-qdevice

Source : https://forum.proxmox.com/threads/setting-up-qdevice-fails.56061/

Best Practices pour Quorum Redhat Cluster Suite

Mon, 31 Mar 2014 13:51:11 +0000

Si vous avez déjà installé un cluster RHCS, vous saurez sûrement qu’il y a un certain nombre de paramètres qui semblent un peu arbitraires, et qui sont surtout assez mal définis chez Redhat. Je parle du totem token, du quorum_dev_poll et surtout de comment ils dépendent les uns avec les autres. Ces différentes valeurs correspondent à des durées de timeout sur les différents composants qui régissent le cluster.

C’est pourtant d’autant plus important à comprendre que, si vous laissez les valeurs initiales, vous pourrez avoir de vilaines surprises en cas de bascule multipath d’un chemin.

Personnellement, j’ai eu le cas sur un cluster hébergé chez un prestataire. Celui ci a réalisé des opérations sur son SAN, normalement transparentes, qui ont eu la fâcheuse conséquence de mettre en carafe toute l’infrastructure.

Ce qui s’est réellement passé, c’est que le timeout de multipath étant autour des 45 secondes en dur, les valeurs par défaut de perte du quorum était trop courte et le serveur se sabordait, pensant avoir perdu la cohérence du cluster.

Pour s’y retrouver, Redhat a publié un papier qui, à défaut d’expliquer ce à quoi correspond exactement chaque variable, détaille les best practices pour les fixer.

Les règles définies ci-dessous permettent de positionner les différentes variables qui réglementent les différents timeout d’un cluster Redhat Cluster Suite. Ces règles sont tirées du pdf du support Redhat « rhel_cluster_qdisk.pdf »

Règles à respecter

Les valeurs mises en gras sont celles qui sont dépendantes les unes des autres

Variable token du composant Totem

La variable token du composant totem doit respecter la formule suivante

<totem token > 2 * quorumd tko * interval

Donc pour la configuration du quorumd suivante (interval en secondes)

<quorumd label="myQDisk" interval="1" tko="10" min_score="1" votes="1">

On devra avoir totem token (en millisecondes) à

<totem token="21000"/>

Variable quorum_dev_poll de CMAN

La variable quorum_dev_poll de CMAN doit être égale à la variable totem token

cman quorum_dev_poll = totem token

Dans une configuration de base on aura

<cman expected_votes="3" quorum_dev_poll="21000"/>
[…]
<totem token="21000"/>

Variables tko et interval des heuristiques

Le produit de l’interval et du tko d’une heuristique doit être inférieur ou égal au produit de l’interval et du tko-1 du quorumd.

heuristics tko*interval <= quorumd interval*(tko-1)

Dans une configuration de base on aura

<quorumd label="myQDisk" interval="1" tko="10" min_score="1" votes="1">
[…]
<heuristic program="ping -c1 -w1 192.168.2.1" score="1" interval="2" tko="4" />

De plus, une heuristique doit avoir un tko > 1

Variables expected_votes de CMAN

La variable expected_votes de CMAN doit être égale à la formule suivante

Nombre de nœuds du cluster * 2 - 1

Quand on a 2 nœuds, c’est donc 3 votes, quand on a 3 nœuds c’est 5, etc.

Variable votes de quorumd

La valeur de la variable votes du quorumd doit être égale à la formule suivante

Nombre de nœuds du cluster - 1

Quand on a 2 nœuds, c’est donc 1 votes, quand on a 3 nœuds c’est 2, etc.

Règle sur les nœuds

Tous les nœuds du cluster doivent avoir un vote

<clusternode name="node1.example.org" votes="1" nodeid="1">
[…]

Variable two_node de CMAN

Seul cas de doute pour moi, il existe une variable two_nodes de CMAN. Je ne sais pas dire si la Best Practices indique que cette valeur doit valoir 0 ou ne pas être présente…

Configurations fonctionnelles IRL

Exemple de la configuration d’origine pour un cluster à 2 nœuds

<clusternode name="node1.example.org" votes="1" nodeid="1">
[…]
<clusternode name="node2.example.org" votes="1" nodeid="2">
[…]
<quorumd label="myQDisk" interval="1" tko="10" min_score="1" votes="1">
[…]
<heuristic program="ping -c1 -w1 192.168.2.1" score="1" interval="2" tko="4" />
<cman expected_votes="3" quorum_dev_poll="21000"/>
[…]
<totem token="21000"/>

Configuration modifiée pour PowerPath sur un cluster à 2 nœuds

Lorsqu’on utilise du multipathing ou powerpath pour réduire le nombre de SPOF du cluster, il est nécessaire de s’assurer que la perte et le basculement d’un lien se fait plus rapidement que le temps fixé par le cluster pour déterminer un échec.

Le produit des attributs interval * tko de quorumd doit donc être supérieur au temps nécessaire pour une bascule complète du lien multipath.

Les autres valeurs doivent être ensuite calculées à partir de ces deux attributs et des règles définies plus haut. A priori, on trouve sur les sites de la communauté d’EMC que les chemins peuvent prendre 45 secondes pour basculer. Ces valeurs se vérifient sur mes clusters en production.

Il Je préfère donc donner 50 secondes de battement au quorum disk avant de considérer le quorum comme perdu!

<clusternode name="node1.example.org" votes="1" nodeid="1">
[…]
<clusternode name="node2.example.org" votes="1" nodeid="2">
[…]
<cman expected_votes="3" quorum_dev_poll="101000"/>
[…]
<totem consensus="4800" join="60" token="101000" token_retransmits_before_loss_const="20"/>
<quorumd label="myQDisk" interval="5" tko="10" min_score="1" votes="1">
<heuristic program="ping -c1 -w1 192.168.2.1" score="1" interval="5" tko="9" />
<quorumd>

Démarrage forcé avec moins de la moitié des votes sur Redhat Cluster Suite (split brain my love)

Sun, 07 Jul 2013 21:01:27 +0000

Dans le cas où vous avez mis en place un cluster Redhat Cluster Suite sur votre infrastructure et que vous avez plusieurs salles distantes, vous êtes certainement tombé sur l’expression « split brain » (cf Split Brain sur Wikipedia). Généralement, il est intéressant de pouvoir empêcher deux serveurs en clusters qui ne se voient plus de fonctionner en même temps, c’est pourquoi avec RHCS il est possible sur des clusters 2 nœuds d’ajouter un disque SAN appelé Quorum Disk qui sert d’arbitre.

Cependant, il arrive des fois où les protections du cluster vous empêche de redémarrer, typiquement lorsque vous n’avez qu’une seule salle serveur disponible!

Revenons en arrière et imaginons que comme moi, vous disposez de :

une salle primaire composée d’un nœud du cluster et d’un SAN avec une moitié de miroir et un quorum disk
une salle secondaire composée d’un nœud du cluster et d’un SAN avec une moitié de miroir

Cela vous fait donc 3 votes (2 nœuds, 1 quorum sur le SAN), vous êtes relativement contents. Si l’interconnexion tombe totalement (SAN + LAN), les deux salles seront isolées l’une de l’autre, et la salle secondaire n’ayant pas accès au quorum sera donc coupée par le cluster par manque de votes. La salle primaire fonctionnera toujours avec sa partie du miroir. Si c’est uniquement un des deux serveurs qui tombe en panne, le second et le quorum feront toujours 2 votes, ce qui sera là aussi suffisant.

Imaginons maintenant que la salle primaire a été victime d’une attaque à la batte de baseball (risque relativement courant dans les salles serveurs), il est fort à parier que votre boss sera en train de vous crier dessus pour vous motiver à redémarrer votre infrastructure dans les plus brefs délais sur la salle secondaire.

Pourtant, en l’absence d’un second vote (on se rappelle, le quorum a été ratatiné par une batte), le cluster refusera de démarrer. Et pas la peine d’essayer de tricher en modifier le poids du nœud restant, la commande « ccs_tool update » refusera de mettre à jour un cluster qui a été dissolu et pas proprement reformé (ce qui s’annonce difficile).

La commande suivante vous sauvera la vie en vous permettant de modifier arbitrairement la quantités de votes « attendus » (comprenez nécessaires) par le cluster pour accepter de démarrer. Vous pourrez repartir sur votre salle secondaire. Elle est pas belle la vie ;-) ?

cman_tool expected -e 1

Attention tout de même, si jamais vous veniez à reconstruire le cluster (rétablissement de la liaison entre les deux salles) et que les deux salles ont toutes les deux été actives sur le SAN, votre miroir sera bien évidemment bon à jeter à la poubelle. A utiliser avec parcimonie et connaissance de cause…

Plus d’infos sur cman_tool sur la page man (ou sur le net)

man cman_tool

[Édit]La dernière fois que je l’ai utilisée j’ai du redémarrer d’abord le clusters via lucide PUIS lancer la commande pendant l’initialisation. A ce moment là, il cherche pendant un moment le reste du clusters puis abandonne, ce qui empêche rgmanager de fonctionner correctement. [/Édit]