Un cluster Proxmox VE avec seulement 2 machines !

Posted by

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 clsuter, 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 <QDEVICE-IP> 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).

Pour ceux qui ne connaissent pas Medieval Ops, j’avais envie de le placer parce que c’est drôle.

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/


Vous aimez ce blog ? Partagez-le avec vos amis !   Twitter Facebook Linkedin email

Vous pouvez également soutenir le blog financièrement :
Tipeee

11 comments

  1. Salut,

    Sympa l’article, j’aurais une question, est ce que un raspberry peut faire tourner le serveur quorum?

    Merci!

  2. J’avais enfin de répondre avec enthousiasme « mais oui bien sûr, sans aucun souci », mais avec un bémol quand même, il faut que le package soit disponible sur la plateforme ARM (car le package x86 ne sera pas compatible avec le CPU du raspberry).

    après une recherche rapide, a priori c’est le cas (cf https://packages.debian.org/search?keywords=corosync-qnetd)

    Sinon, niveau puissance, oui ça suffira largement; moi le processus tourne sur une VM avec 1vCPU qui fait fonctionner plein d’autres choses. Ça ne consomme presque rien.

  3. Bonjour,
    Bravo pour tous ces posts bien utiles. J’ai l’impression de comprendre pour une fois.
    Par contre j’aurai besoin de petits conseils.
    J’ai installé 2 petits serveurs avec chacun un ssd et proxmox.
    Ils sont desormais mis en cluster
    Le premier est pas tres puissant mais sur lequel j’ai 4 VM (pihole, jeedom, mosquito+influxdb+grafana, et yunohost pour nextcloud avec un disque physique dédié.
    Le deuxieme est en cours d’installation, il sera dédié prod pour le stockage avec un bond reseau deja en place et plutot performant.
    J’ai deja pu testé une vm win10 et 1 VM catalina mais c’etait pour le fun.
    J’ai commandé plusieurs disques sata pour les stockages
    J’en viens donc a mes questions ;)
    Je voudrais migrer nextcloud sur le 2e cluster, comment faire? Evidement je ne veux pas de pertes data.
    J’ai vu pas mal de posts sur Ceph, je suis tenté . Comment le mettre en oeuvre.
    La conf finale serait
    Cluster1: 1ssd system, 4 sata
    Cluster2: 1ssd system, 8 sata
    Merci d’avance pour les idees

  4. Vu ce que tu m’expliques, je pense deviner que les deux serveurs sont sur un même réseau local. C’est un bon point pour la suite (et les clusters en général).
    Quand on parle de migrer, on parle de quoi ? Si c’est juste une migration oneshot, Proxmox fait ça très bien à froid. On éteint la VM, on la migre, ça copie les disques sur le LAN. C’est juste un peu long.
    Un peu plus efficace, c’est de passer par des pools ZFS. Avec ZFS on peut avoir de la réplication asynchrone, ce qui réduit fortement la période de coupure car ZFS sait gérer le delta entre les deux sto. C’est ce que je fais personnellement en tant que PRA.
    Ceph, c’est plus compliqué. D’abord c’est du stockage actif actif, donc un cluster de plus (au sens logiciel du terme, on peut bien sûr avoir Ceph sur les mêmes machines que le cluster Proxmox). Il faut des machines physiques sur le même LAN (sauf à bidouiller mais pour l’avoir fait c’est pénible). Certes Proxmox facilite un peu l’usage de Ceph mais c’est quand même pas fou. Et c’est sans compter que Ceph c’est plutôt à partir de 3 nodes (pour des raisons de majorité).
    L’équipe de Proxmox est très pénible avec l’usage des clusters et encore plus avec Ceph. Si tu sors du cadre, l’UI te bloque et il faut bidouiller.
    Du coup, dans ton cas je déconseille Ceph, même si c’est une techno super cool que j’apprécie par ailleurs.

  5. Merci pour ton retour.
    Oui, les 2 machines sont sur le meme reseau.
    Je comptais utiliser Ceph pour sa capacité d’auto reparation. Certes cela utilise plus de place disque mais ca a l’air super secur (sur le papier). Du coup, les migrations semblent simplifiées (sur le papier aussi). Ce que tu remets en cause. Ok, je vais regarder les pools zfs.
    Du coup, pour la sécurité tu me conseilles de rester sur un bon vieux RAID?
    Pour la migration, ma crainte n’est pas de migrer la VM elle meme, mais de perdre le montage du disque de data Nextcloud. En plus, je veux transférer au final les datas sur un nouveau pool. Et tout ca sans trop perturber les utilisateurs de Nextcloud (meme si c’est la famille!)

  6. Ah mais c’est sûr que les migrations seront simplifiées, tu seras en actif/actif au niveau bloc, donc seul la VM migrera (a chaud), pas les data qui seront déjà répliquées.
    Et oui Ceph c’est top, toute la synchro data et le placement des replicats sur les disques est géré de manière transparente. Je remet pas ça en cause.
    Mais du Ceph sur 2 nodes, c’est pas du tout conseillé, c’est tout ce que je dis ;-)
    Niveau sécurité des data, un RAID seul suffit pas, non. Soit avoir des backup régulières en plus (et les tester) te suffisent. Moi je met en plus de la réplication asynchrone (avec ZFS) en plus des backups.

    Pour la question sur Nextcloud, migrer la VM migrera aussi les disques virtuels. Donc sauf si tu fais des trucs un peu exotiques, ça sera transparent pour toi (et au pire, si la migration se passe mal, le disque virtuel source est toujours disponible pour un retour arrière sur le serveur de départ)

  7. En fait, je pense que j’ai encore du mal a passer du reel au virtuel ;).
    Mon disque data est physiquement sur le cluster 1. A terme je veux basculer, toujours en physique, sur un autre disque de cluster 2.
    Mais si je comprends, en creant des disques virtuels ca devient transparent.
    Je vais reviser un peu plus proxmox je crois avant de lancer la migration.
    Encore merci pour ta patience

  8. Bonjour et merci beaucoup pour ton excellent tuto.
    Je viens de le mettre en place sur une plateforme de test composée de trois micro server HP proliant gen8. Un noeud PVE1 sur l’un, un noeud PVE2 sur l’autre et une distri OMV sur le troisième pour le partage NFS et le quorum.
    Au final ça fonctionne bien quand je perds le noeud 2, la VM qui tournait dessus est migrée sur le noeud 1 après la phase de fencing.
    Par contre si la VM est sur le noeud 1 et que je le perds, là c’est le drame, le quorum est perdu. Tout se passe comme si le noeud 2 ne voyait pas le qdevice ?
    A noter que quand je fais un pvecm status sur le noeud 1, j’obtiens ça :

    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 192.168.100.37 (local)
    0x00000002 1 NR 192.168.100.38
    0x00000000 1 Qdevice

    Par contre la même commande sur le noeud 2 donne le résultat suivant :

    Votequorum information

    Expected votes: 3
    Highest expected: 3
    Total votes: 2
    Quorum: 2
    Flags: Quorate

    Membership information

    Nodeid Votes Qdevice Name

    0x00000001 1 A,V,NMW 192.168.100.37
    0x00000002 1 NR 192.168.100.38 (local)
    0x00000000 0 Qdevice (votes 1)

    Ce qui semble confirmer un soucis entrel e noeud 2 et le serveur de quorum ?

    Tu aurais une idée de ce qui peut causer ça ?

    A noter que dans un premier temps j’ai lancé la commande pvecm qdevice setup x.x.x.x depuis le noeud 1 et pas le 2. Sans trop y croire j’ai tenté de la lancer aussi depuis le noeud 2 mais j’ai une erreur m’indiquant que la config était déjà faite … ce qui est assez logique à la réflexion …

    merci d’avance pour tes bonnes idées.

  9. Je te confirme bien que pour les deux nodes, j’ai le même retour (sauf pour le flag « local », of course)

    Votequorum information
    ----------------------
    Expected votes:   3
    Highest expected: 3
    Total votes:      3
    Quorum:           2  
    Flags:            Quorate Qdevice 
    
    Membership information
    ----------------------
        Nodeid      Votes    Qdevice Name
    0x00000002          1    A,V,NMW x.x.x.2
    0x00000003          1    A,V,NMW x.x.x.3 (local)
    0x00000000          1            Qdevice
    

    Il te manque donc un vote sur le 2ème nœud, ce qui explique que le cluster parte en cacahuète quand tu coupes le 1.

    C’est pas la première fois que je vois/j’ai des soucis dans les votes alors qu’on croit que tout est correctement configuré. Dans des cas comme ça, je démonte le qdevice proprement et je recommence jusqu’à ce que ce soit bon partout, avec le bon nombre de votes (3).

    Attention, les commandes que je te donne, je ne maîtrise pas trop les impacts… à lancer avec prudence.

    A lancer sur un des deux nodes pour réinitialiser le qdevice (avec X.Y.Z.W l’IP de ton qdevice)

    pvecm qdevice remove
    pvecm qdevice setup X.Y.Z.W -f
    

    Si jamais pour une raison ou pour une autre, la commande échoue pour des histoire de base NSS, tu peux aussi nettoyer toute trace des précédentes instances du qdevice avec ces commandes, à lancer sur le serveur 3 (qui porte le qdevice)

    rm /etc/corosync/qnetd/nssdb -r
    systemctl restart corosync-qnetd.service
    
  10. Je viens de tenter ta solution et ça a fonctionné parfaitement.
    Je ne sais pas ce qui a posé problème la première fois mais là c’est bon.
    Merci beaucoup !

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.