Corosync 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/

Cluster Proxmox VE, v6 cette fois ci !

Tue, 20 Aug 2019 11:45:00 +0000

Proxmox VE

Et oui, avec la sortie de Proxmox VE 6, je vous avais prévenu : il va y avoir pas mal d’articles là dessus, même si quelques articles sur Kubernetes sont en cours d’écriture aussi ;-).

Fin juillet, j’avais écris un article sur des playbooks Ansible que j’ai écris pour faciliter le déploiement de cluster Proxmox VE. Malheureusement, comme cet article traînait dans mes brouillons, les playbooks ne géraient pas la version 6 (qui venait de sortir) de PVE.

C’est aujourd’hui de l’histoire ancienne puisque, pour tester la v6, j’ai forcément du adapter les playbooks ;-).

Point important, je vais partir du principe que vous n’avez pas la possibilité d’installer Proxmox VE directement avec l’ISO. C’est souvent le cas souvent avec les hébergeurs de serveurs dédiés pas chers (OneProvider par exemple) ou de VMs (OVH, Scaleway, etc).

Car si vous avez la main, le plus simple est bien sûr d’installer l’ISO directement ! Cependant, ce tuto reste utile pour toute la partie mise en VPN et configuration du cluster.

Les prérequis

Dans l’article précédent, pour gagner du temps pour ceux qui veulent juste tester, j’avais mis à disposition un playbook permettant de générer des VMs chez le cloud provider Scaleway (et notamment tirer parti de l’inventaire dynamique proposé par le module développé par Scaleway pour Ansible).

Ici, je met volontairement de côté cette partie qui n’apporterait rien de plus. Si vous voulez voir comment ça fonctionne je vous invite à (re)lire l’article précédent, la procédure est la même.

Le seul prérequis pour ce tutoriel sont donc d’avoir idéalement 3 machines* (ou plus) sous Debian 10 (la raison pour laquelle je n’avais pas pu le faire avec Scaleway qui ne propose pas encore Debian Buster) accessibles en depuis votre station de travail.

*Mais si vous voulez juste installer Proxmox, une seule suffit mais vous n’aurez évidemment pas un cluster. A partir de 2, on peut faire un cluster mais il sera instable dès que vous perdrez une seule des 2 machines (ce qui est dommage) à moins d’ajouter un device pour permettre d’avoir le quorum (ce que nous verrons dans un autre article).

Installer Ansible et récupérer les playbooks

Des fois que n’auriez pas Ansible, installez le (pour git, c’est juste plus simple de cloner le dépôt mais vous pouvez le télécharger autrement si vous ne voulez pas installer git)

apt-get install git ansible
git clone https://github.com/zwindler/ansible-proxmoxve
cd

Ensuite, on créé un fichier d’inventaire pour Ansible (ce qui n’étais pas nécessaire avec Scaleway puisque, je le rappelle, il y a un module d’inventaire dynamique). Ici on se contente juste de lister les serveurs qui nous intéressent.

cat pve_inventory.yml
all:
children:
proxmoxve:
hosts:
proxmox1.myexample.org:
proxmox2.myexample.org:
proxmox3.myexample.org:

Vous ne reconnaissez peut être pas le format de cet inventaire Ansible. En effet, l’inventaire est ici stocké au format YAML et non au format plat. Très peu de gens utilisent ce format (qui existait au début, puis a été retiré pour être de nouveau supporté depuis la 2.4 je crois).

Étant habitué aux inventaires parfois un peu hétéroclites, je préfère largement ce format YAML, qui permet de rajouter de manière beaucoup plus lisibles des variables à des groupes ou mêmes des hôtes directement (sans passer par une arborescence complète avec groups_vars et hosts_vars). De plus, je trouve les dépendances entre groupes plus claires que lorsque nous avions à déclarer les :children du groupe père (mais c’est subjectif).

Notez par contre qu’il faut :

que mes hôtes soient résolvables par DNS (sinon il faut ajouter une variable ansible_host avec l’IP pour chacun)
que vous n’oubliez surtout par le “:” à la fin de chaque hostname, sans quoi vous aurez une erreur de syntaxe.

Lancer le playbook d’installation de Proxmox VE 6

Nous y voilà. Normalement vous pouvez accéder en SSH à l’ensemble de vos machines. Pour installer Proxmox VE 6 sur une debian 10, il faut donc simplement lancer la commande suivante :

ansible-playbook -i pve_inventory.yml proxmox_prerequisites.yml -u root

Normalement, le playbook vous promptera pour répondre à quelques questions basiques (votre domaine, est ce que les machines commencent par test plutôt que proxmox dans le hostname, …) et à l’issue, un reboot sera effectué (pour basculer sur le noyau Linux de PVE et pas celui de debian Buster).

Mise en réseau privé virtuel avec Tinc

Cette étape n’est pas forcément nécessaire. Si vous travaillez sur des machines qui sont dans un même réseau local, il vaut mieux s’en passer.

En revanche, dans le cas où comme moi vous louez des serveurs chez un provider et qu’il ne vous met pas à disposition un moyen de simuler un réseau privé (RPN chez Online, Rack quelque chose chez OVH je crois), il sera préférable de monter un VPN entre les différentes machines du cluster.

Je dis préférable et pas nécessaire, car jusqu’à la version 6 de Proxmox (et Corosync v3), il était nécessaire également de faire passer du multicast entre les machines pour faire fonctionner le cluster. Ce n’est aujourd’hui plus le cas et on peut donc très bien imaginer un cluster Proxmox avec des machines sur des LAN distincts. Cependant, pour activer des fonctionnalités comme Ceph (et probablement d’autre), il est toujours nécessaire d’avoir un LAN.

Pour se faire, j’utilise Tinc plutôt qu’OpenVPN, qui a l’avantage d’être simple à configurer et surtout multipoint (pas de notion de serveur maitre et de clients connectés dessus). Ce n’est pas le cas avec OpenVPN, dont la structure client/serveur complexifie beaucoup l’implémentation si on veut éviter un SPOF (en gros il faut un serveur sur toutes les machines, et que l’ensemble des serveurs soient tous clients les uns des autres, en toile d’araignée). Vous pouvez quand même jeter un oeil sur mes premières tentatives ici, si ça vous intéresse.

Comme j’automatise tout avec Ansible, j’ai donc aussi créé un playbook qui permet d’installer et configurer Tinc sur toutes nos machines et de les mettre en réseau sur un VPN dédié.

ansible-playbook -i pve_inventory.yml tinc_installation.yml -u root

A partir de là, vous avez donc 3 machines Proxmox VE 6, connectés ensembles sur un VPN avec l’adresse 10.10.10.0/24

Le réseau c’est compliqué ?

Un point pas forcément évident avec Proxmox est que la configuration du réseau dépend beaucoup de comment vos machines sont connectées en réseau.

Les différentes configurations conseillées sont détaillées dans un article dédié sur le wiki de Proxmox. J’aurais vraiment aimé connaître cette page lorsque M4vr0x et moi avons fait nos premières expériences avec PVE car nous avons beaucoup tâtonné…

Dans mon cas précis, j’ai des machines hostées par un provider. Je n’ai donc aucunement la main sur le réseau et je ne souhaite pas acheter d’IP supplémentaires.

Dans ce cas là, le plus simple est donc de créer un bridge Linux, qui portera un réseau virtuel interne à chaque serveur et dont le trafic externe sera routé.

L’inconvénient de cette solution est qu’on ne peut pas utiliser l’interface graphique pour faire ces modifications, et aussi qu’en cas d’erreur, vous n’aurez plus accès à votre serveur…

Configuration réseau pour des machines dédiées chez un Provider type OneProvider

Nous voilà donc dans les premières bidouilles manuelles. Connectez vous en SSH à votre (vos) serveurs, et modifier le fichier /etc/network/interfaces.

Je me suis basé sur la section “Masquerading (NAT) with iptables”

Le mien ressemble à ça :

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto eth0
#real IP address
iface eth0 inet static
address x.x.x.x
netmask 24
gateway x.x x.1
auto vmbr0
iface vmbr0 inet static
address 192.168.0.1
netmask 255.255.255.0
bridge-ports none
bridge-stp off
bridge-fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE

Le plus important ici pour que tout fonctionne est que vous ne vous trompiez pas sur le nom de l’interface réseau (eth0 dans mon exemple).

Ensuite, une fois que les modifications sont faites, redémarrez le réseau (systemctl restart networking) ou carrément le serveur (c’est ce que Proxmox conseille, même si je ne vois pas bien l’intérêt).

Ici, la configuration est beaucoup plus simple que ce que nous avions imaginé avec M4vr0x dans la série d’articles détaillés sur PVE 5. Et c’est tant mieux car ça suffira amplement à la plupart d’entre vous ;-).

Configuration du cluster Proxmox VE

Ok ! Maintenant tous les prérequis sont en place, on peut donc construire le cluster. Le wizard de la GUI a assez peu évolué depuis la V5 (même s’il y a quelques petites améliorations)

Vous vous connectez sur une des machines
Dans la vue Datacenter, vous sélectionnez Create Cluster, puis vous copiez les informations de connexion pour les autres serveurs.
Sur les autres serveurs, vous rejoignez le cluster en collant les informations des

(Plus de détails dans l’article précédent)

[Tutoriel] Démonter proprement un cluster Proxmox VE

Tue, 19 Sep 2017 11:30:18 +0000

Faire et défaire des clusters Proxmox VE, c’est toujours travailler

Si vous avez lu et appliqué à la lettre mon article précédent sur les clusters Proxmox VE quand on a pas de multicast (ou autre si vous n’êtes pas bridé sur le multicast), vous devriez être l’heureux propriétaire d’un cluster Proxmox VE fonctionnel.

Mille bravo !

Mais personne n’est parfait et n’est à l’abris d’une faute de frappe, d’un oubli ou d’une erreur, et je me suis retrouvé devant un cluster en vrac, complètement bloqué, avec une partie des nœuds fonctionnels et l’autre marqués « failed ».

OK… J’avoue. Je suis un bourrin quand je bidouille. Ça m’est arrivé… plusieurs fois…

Dans cet article, je vais donc vous donner la marche à suivre pour supprimer complètement toute trace des configurations du cluster et ainsi repartir à zéro pour recommencer (sans avoir à tout réinstaller car ça marche aussi mais bon…)

[Aparté]Une fois encore, si vous ne connaissez pas Proxmox VE je vous invite à consulter les articles que M4vr0x et moi avons écris à ce sujet, il commence à y en avoir pas mal[/Aparté]

Sous le capot

D’abord, je voudrais rapidement rappeler que Proxmox VE est un logiciel de virtualisation qui est majoritairement déployé via un ISO contenant une Debian modifiée. Le cœur du clustering dans ProxMox se base sur Corosync (depuis la version 4+), avec l’ajout d’un filesystem distribué maison pour ce qui est gestion de configuration cohérent sur tous les nœuds (pmxcfs).

On peut récupérer beaucoup d’informations sur le cluster simplement en allant consulter les fichiers de configuration présents dans les dossiers de corosync. C’est d’ailleurs comme ça que je m’en suis sorti [quand j’avais tout cassé dans mon article précédent][1].

Sortir proprement un nœud

La documentation officielle donne la marche à suivre dans le cas où vous souhaitez juste sortir un nœud de votre cluster. Si ce n’est pas vraiment notre but ici, ça peut quand même vous servir et surtout, c’est une des étapes dont nous aurons besoin pour la suite.

ATTENTION ! Si je n’ai peut être pas été assez clair (cf les commentaires), je vais écrire en gras maintenant pour qu’il n’y ait plus de doute. Couper les services pve-* ne devrait pas impacter vos VMs (qui continuent à tourner), mais supprimer un nœud du cluster SI (elles tournent toujours, mais ont disparues de l’interface) !

Read carefully the procedure before proceeding, as it could not be what you want or need.

Move all virtual machines from the node, just use the Central Web-based Management to migrate or delete all VM´s. Make sure you have no local backups you want to keep, or save them accordingly.

Et c’est bien normal : au même titre que Proxmox a réinitialisé la configuration de votre nœud lors de la création du cluster, la même opération est réalisée fait lors de sa sortie. Donc, s’il vous plait, ne jouez pas avec les clusters si vous avez des VMs qui tournent sur vos machines…

Pour la suite de l’article, je vais appeler nœud srv1 le serveur que nous allons garder jusqu’à la fin, et srv2, srv3, etc… tous les autres serveurs du cluster.

Sur le nœud srv1

La première chose à faire est de réduire le nombre de nœuds expected par le cluster corosync. L’idée étant qu’à un moment donné, corosync s’attend à avoir au minimum X nœuds, X étant le nombre de serveurs du cluster. S’il en a moins, le cluster se bloque pour empêcher toute modification dans le cas où on serait en « mode dégradé ». On va donc réduire ce nombre de 1 pour que le cluster ne soit pas trop surpris par la suppression d’un nœud.

Dans mon exemple je n’ai que deux serveurs. Cependant, si on a plus de nœuds, il faudra reproduire la procédure jusqu’à ce qu’il ne reste plus qu’un nœud.

pvecm expected 1
pvecm delnode srv2
Killing node 2

Sur le nœud à supprimer

A partir de maintenant, pour tout le reste du cluster, le nœud srv2 (ou tout autre à supprimer) n’en fait plus parti. Cependant, la procédure n’agit pas (ou pas entièrement) sur le nœud 2 en lui même : il reste quand même du ménage à faire. Et si on ne le fait pas, et qu’on essaye de le réintégrer dans le cluster, il y aura des restes et l’intégration risque d’échouer à nouveau.

Assurez vous que rien de critique ne tourne sur ce nœud avant retrait du cluster.

systemctl stop pvestatd.service
systemctl stop pvedaemon.service
systemctl stop pve-cluster.service
systemctl stop corosync

A noter que dans Proxmox VE, au delà du simple fichier texte présent sur le filesystem, la configuration est également stockée dans une base sqlite. Si on se contente de supprimer la configuration dans les fichiers, elle sera régénérée dès qu’on redémarrera les services. On va donc devoir la vider à la main :

sqlite3 /var/lib/pve-cluster/config.db
SQLite version 3.8.7.1 2014-10-29 13:59:56
Enter ".help" for usage hints.
sqlite> select * from tree where name = 'corosync.conf';
2|0|3|0|1500655311|8|corosync.conf|logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: srv1
nodeid: 1
quorum_votes: 1
ring0_addr: 10.9.0.1
}
node {
name: srv2
nodeid: 2
quorum_votes: 1
ring0_addr: 10.9.0.2
}
}
quorum { provider: corosync_votequorum }
totem {
cluster_name: kimsufi
config_version: 5
ip_version: ipv4
secauth: on
version: 2
interface {
bindnetaddr: 10.9.0.2
ringnumber: 0
}
}
sqlite> delete from tree where name = 'corosync.conf';
sqlite> select * from tree where name = 'corosync.conf';
sqlite> .quit

Maintenant qu’on a supprimé la configuration de corosync de la base sqlite, on peut supprimer la configuration définitivement (ou juste en faire un copie, si on est prudent) :

mv /var/lib/corosync/ /var/lib/corosync.$(date +%y%m%d%H%M)
mkdir /var/lib/corosync
mv /var/lib/pve-cluster/ /var/lib/pve-cluster.$(date +%y%m%d%H%M)
mv /etc/corosync /etc/corosync.$(date +%y%m%d%H%M)

Et enfin redémarrer les services :

systemctl start pvestatd.service
systemctl start pvedaemon.service
systemctl start pve-cluster.service

On a donc un serveur qui a retrouvé son état initial (à savoir un serveur hors d’un cluster) sans avoir à le réinstaller complètement.

Pour la suite, je le rappelle : L’idée ici est donc d’appliquer cette procédure sur tous les nœuds sauf un (le dernier, srv1).

Détruire le cluster entier

Nous avons maintenant un cluster contenant une seule machine : srv1. Nous pouvons reproduire la même procédure que précédemment, à un détail près : pas besoin de réduire le nombre de votes expected, déjà descendu à 1.

Et on peut recommencer à jouer en redémarrer les services suivants sur srv1 :

systemctl start pvestatd.service
systemctl start pvedaemon.service
systemctl start pve-cluster.service
systemctl start corosync

TADAM !!!! Vous pouvez re-tout casser ;-)

Source

forum.proxmox.com/threads/removing-deleting-a-created-cluster.18887/

[Tutoriel] Faire un petit cluster Proxmox chez Kimsufi avec OpenVPN

Tue, 29 Aug 2017 11:40:23 +0000

C’est la rentrée, vous reprendrez bien un petit article sur Proxmox !

Ou plutôt, c’est bientôt la rentrée et il est grand temps que je solde les articles qui trainent dans mes tiroirs car je moi pars bientôt en vacances.

« Et tout le monde s’en fout »

J’ai donc rédigé un tutoriel pas à pas pour vous montrer qu’on peut créer rapidement un petit cluster sous Proxmox avec deux petites machines chez un hébergeur pas cher type Kimsufi (j’avais justement deux machines car j’ai profité d’une promo chez eux), sans que les machines soient dans le même sous réseau IP.

Si vous ne connaissez pas Proxmox, je vous renvoie vers les articles que M4vr0x ou moi avons écris sur le sujet.

Pourquoi un tutoriel pour les clusters Proxmox ?

Vous allez me dire, pourquoi un énième article sur le sujet ? La documentation officielle, même si elle est en anglais, est assez claire et il existe plusieurs tutoriels en Français pour le faire.

Ah ah oui… mais la distinction c’est « faire un cluster de machines Proxmox, sans que les machines soient dans le même sous réseau IP » !

Et à moins que vous ayez une chance de ouf’, il est peu probable que vos deux Kimsufi le soient.

Petit rappel des prérequis pour faire un cluster Proxmox

Deux serveurs physiques (au minimum)
Port 22 accessible au moins dans un premier temps pour configurer le cluster
Que la latence d’un serveur à l’autre soit inférieure à 2ms
Que les deux serveurs soient capables de communiquer en multicast

Et là, c’est le drame !

Jusqu’à ce qu’on arrive à la dernière ligne, nous étions sereins.

Si jamais vous avez deux serveurs chez Kimsufi (ou autre) et que vous essayez de les faire communiquer en multicast, vous allez vite vous rendre compte que le multicast est bloqué !

Impossible donc de faire fonctionner correctement votre cluster Proxmox (basé sur corosync) sans cela. Vous pouvez mettre tous les autres tutos à la poubelle ;-).

Bidouille & compagnie, et les risques encourus

Si vous vous sentez la curiosité de monter quand même un cluster sur votre Kimsufi, on va contourner le problème en montant un VPN entre les deux machines. M4vr0x a déjà détaillé l’utilisation d’OpenVPN avec pfSense sur Proxmox, mais on n’était pas dans le même contexte.

On ne peut pas se baser là dessus dans le cas présent car Proxmox a la fâcheuse manie de réinitialiser toute la configuration lorsqu’on démarre le mode « cluster » .

ATTENTION !!!
Oui, ça veut bien dire que vous ne verrez plus ni vos VMs existantes, ni le stockage que vous avez précédemment configuré…
Les VMs continuent d’exister et sont accessibles tant que vous ne rebootez pas. Le stockage aussi. Ce n’est juste plus visible.

Vous l’avez deviné, c’est du vécu : j’ai flingué ma configuration existante lorsque j’ai initialisé le cluster.

Mise en réseau

Maintenant que vous savez ce que vous risquez, on va donc configurer tout ça à la main, directement en SSH sur les machines Proxmox :

Sur le serveur 1

La première chose à faire est simplement d’installer openvpn, ainsi qu’un utilitaire qui s’appelle easy-rsa qui va nous faciliter la tâche de configuration.

apt-get update
apt-get upgrade
apt-get install openvpn easy-rsa

Une fois que c’est fait, on copie les templates de config et les scripts de easy-rsa et on modifie les valeurs par défaut par nos propres valeurs.

cp -ai /usr/share/easy-rsa/ /etc/openvpn/easy-rsa/
cd /etc/openvpn/easy-rsa/
vi vars
[...]
# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="FR"
export KEY_PROVINCE="Aquitaine"
export KEY_CITY="Bordeaux"
export KEY_ORG="mondomaine.tld"
export KEY_EMAIL="key@mondomaine.tld"
export KEY_OU="key"

Sourcez le fichier nouvellement rempli :

. ./vars

Nettoyez les clés provenant d’anciennes itérations de l’outil (pas nécessaire si c’est la première fois mais si vous n’en êtes pas au premier coup, ça peut éviter des erreurs bêtes) :

./clean-all

Et enfin, on génère l’ensemble des clés dont vous aurez besoin (les CA, les clés serveurs, les clés clientes et la diffie helmann) :

./build-ca
./build-key-server serveur1.mondomaine.tld
./build-key serveur2.mondomaine.tld
./build-dh

Normalement tout devrait se passer sans encombre et vous devriez avoir plusieurs certificats nouvellement créés. On va copier les certificats du serveur OpenVPN dans le dossier /etc/openvpn, puis envoyer les certificats du client par SCP :

cp keys/ca.* keys/serveur1.mondomaine.tld.* keys/dh2048.pem /etc/openvpn/
scp keys/ca.crt keys/serveur2.mondomaine.tld.crt keys/serveur2.mondomaine.tld.key serveur2.mondomaine.tld:/etc/openvpn/

Maintenant qu’on a tout, on peut créer le fichier de configuration. Ici rien de bien compliqué à comprendre :

On créé un fichier server.conf qui va monter un VPN sur le port 1194 en UDP via un device de type TAP (j’y reviendrai) et on force le réseau en 10.9.0.0/24
On donne le chemin vers tous les certificats qu’on vient de créer
On ajoute un script « up » et un script « down », avec l’option script-security à « 2 » sinon ça ne fonctionnera pas

cat > /etc/openvpn/server.conf << EOF
# [server.conf]
port 1194
proto udp
#dev tun
dev tap
ca /etc/openvpn/ca.crt
cert /etc/openvpn/serveur1.mondomaine.tld.crt
key /etc/openvpn/serveur1.mondomaine.tld.key
dh /etc/openvpn/dh2048.pem
server 10.9.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
script-security 2
up /etc/openvpn/add_multicast_route
down /etc/openvpn/add_multicast_route
EOF

Bon et qu’est ce qu’il contient ce fameux script ? Et bien pour l’instant il se contente simplement d’ajouter et de supprimer une route sur les serveurs qui va router « à la main » tout le traffic multicast non par vers la gateway, mais vers le VPN ! Et c’est comme ça qu’on va contourner le blocage des flux multicast entre nos deux Kimsufi !

vi /etc/openvpn/add_multicast_route
#!/bin/bash
#
# Add a route to force multicast through VPN
[ "$script_type" ] || exit 0
case "$script_type" in
up)
route add -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
down)
route del -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
esac
chmod +x /etc/openvpn/add_multicast_route

On termine par démarrer (et activer au démarrage) le serveur OpenVPN :

systemctl enable openvpn
systemctl start openvpn

Dans ce cas là, comme on est pas en réel mode client serveur ou l’ensemble du traffic client est routé sur le serveur on a pas besoin de modifier le paramètre kernel « ip_forward » :

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Aparté tun vs tap

Les plus aguerris d’entre vous auront remarqués que j’ai volontairement choisi de ne pas utiliser une interface virtuelle de type tun (par défaut dans OpenVPN) mais une interface de type tap.
Historiquement, ce type d’interface est connu pour ne pas fonctionner correctement en multicast, ce qui est ici notre but principal.

A priori c’est censé être résolu depuis longtemps, mais chez moi ça n’a pas marché alors que dès que j’ai switché sur tap ça a fonctionné directement. Je vous engage à regarder si ça vous intéresse. J’ai mis un lien vers une discussion à ce sujet sur le forum d’OpenVPN en fin d’article.

Sur le serveur 2

Maintenant que le serveur est configuré, au tour du client. Même topo, à ceci près qu’on ne va pas générer de certificats (c’est déjà fait).

apt-get update
apt-get upgrade
apt-get install openvpn
cat > /etc/openvpn/client.conf << EOF
# [client.conf]
client
#dev tun
dev tap
proto udp
remote @IP_publique_du_serveur1 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca /etc/openvpn/ca.crt
cert /etc/openvpn/serveur2.mondomaine.tld.crt
key /etc/openvpn/serveur2.mondomaine.tld.key
ns-cert-type server
comp-lzo
verb 3
script-security 2
up /etc/openvpn/add_multicast_route
down /etc/openvpn/add_multicast_route
EOF

vi /etc/openvpn/add_multicast_route
#!/bin/bash
#
# Add a route to force multicast through VPN
[ "$script_type" ] || exit 0
case "$script_type" in
up)
route add -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
down)
route del -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
esac
chmod +x /etc/openvpn/add_multicast_route
systemctl enable openvpn
systemctl start openvpn

Facile, hein ?

Sur tous les nœuds

Pour s’assurer que tout fonctionne comme ça devrait (ou pour déboguer), vous pouvez autoriser temporairement la réponse à l’ICMP sur multicast. Un simple ping permettra de s’assurer que les deux serveurs se voient bien :

sysctl net.ipv4.icmp_echo_ignore_broadcasts=0
root@serveur1:/etc/pve# ping 224.0.0.1
PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data.
64 bytes from 10.9.0.1: icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from 10.9.0.2: icmp_seq=1 ttl=64 time=1.07 ms (DUP!)
64 bytes from 10.9.0.1: icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from 10.9.0.2: icmp_seq=2 ttl=64 time=0.672 ms (DUP!)
64 bytes from 10.9.0.1: icmp_seq=3 ttl=64 time=0.020 ms
64 bytes from 10.9.0.2: icmp_seq=3 ttl=64 time=0.619 ms (DUP!)

Les deux serveurs répondent aux pings depuis l’interface du VPN, on est bons ! Du coup vous pouvez re-désactiver la réponse aux broadcasts avec la commande suivante :

sysctl net.ipv4.icmp_echo_ignore_broadcasts=1

Pour faciliter la résolution de noms dans le cluster, vous pouvez ajouter les IPs VPN des serveurs dans le fichier /etc/hosts.

vi /etc/hosts
[...]
10.9.0.1 serveur1-vpn
10.9.0.2 serveur2-vpn

Création du cluster

Sur le nœud 1

En théorie, si on lit la documentation il suffit simplement de faire “pvecm create mycluster” et le tour est joué.

STOOOOP !

Si vous le faite, ça ne fonctionnera pas (et vous pourrez vous en sortir avec cet article). Pourtant tout est correct au niveau des prérequis : les nœuds fonctionnent bien et que le multicast est correctement routé via le VPN. Un coup d’œil au fichier de configuration de corosync nous en apprendra plus :

cat /etc/pve/corosync.conf
logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: serveur2
nodeid: 2
quorum_votes: 1
ring0_addr: serveur2
}
node {
name: serveur1
nodeid: 1
quorum_votes: 1
ring0_addr: serveur1
}
}
quorum {
provider: corosync_votequorum
}
totem {
cluster_name: mycluster
config_version: 4
ip_version: ipv4
secauth: on
version: 2
interface {
bindnetaddr: @IP_publique_du_serveur1
ringnumber: 0
}
}

En fait le problème ici, c’est que l’adresse bindée bindnetaddr: n’est pas bonne. Si vous n’avez pas lu mon gros “STOOOOP”, il faut tout réinitialiser car il est assez compliqué de modifier un cluster existant sous Proxmox (a priori pas possible proprement mais je vous donnerai la tips dans un prochain article).

Voilà la bonne commande à taper :

pvecm create mycluster -bindnet0_addr 10.9.0.1 -ring0_addr serveur1-vpn
Corosync Cluster Engine Authentication key generator.
Gathering 1024 bits for key from /dev/urandom.
Writing corosync key to /etc/corosync/authkey.

Sur le noeud 2

En théorie, là aussi c’est très facile. Il suffit de faire “pvecm add serveur2-vpn” pour que l’hôte serveur2.mondomaine.tld rejoigne le cluster créé sur le noeud serveur1.mondomaine.tld.

Voilà ce qui va se passer si vous le faites :

pvecm add serveur1-vpn
The authenticity of host 'serveur1-vpn (10.9.0.1)' can't be established.
ECDSA key fingerprint is SHA256:VOIH2X7kTzWLUEzRPCl4431hlYnc3HCsDmzXYEs3V+g.
Are you sure you want to continue connecting (yes/no)? yes
root@serveur1-vpn's password:
copy corosync auth key
stopping pve-cluster service
backup old database
Job for corosync.service failed because the control process exited with error code.
See "systemctl status corosync.service" and "journalctl -xe" for details.
waiting for quorum...

Même principe ici. Si l’adresse ring0_addr n’est pas spécifiée explicitement, corosync va tenter de s’abonner sur une IP multicast sur l’IP de l’interface Ethernet principale. Elle ne passera donc pas pas notre VPN et le cluster ne communiquera pas en multicast !

Vous pouvez en lire plus là dessus sur ce lien.

Sur le noeud serveur2, on ajoute donc l’adresse IP (et donc l’interface) que corosync devra emprunter pour communiquer avec serveur1-vpn (via le VPN donc).

pvecm add serveur1-vpn -ring0_addr 10.9.0.2
The authenticity of host 'serveur1-vpn (10.9.0.1)' can't be established.
ECDSA key fingerprint is SHA256:oKkuOYY1pbEa1RrM0y9fWVJfnQabhUvG7la+6fZUnQ4.
Are you sure you want to continue connecting (yes/no)? yes
root@serveur2-vpn's password:
copy corosync auth key
stopping pve-cluster service
backup old database
waiting for quorum...OK
generating node certificates
merge known_hosts file
restart services
successfully added node 'serveur2' to cluster.

A partir de là, tout devrait marcher. Vous devriez avoir sur la même interface vos deux serveurs, et avoir perdu toutes vos VMs si vous n’avez pas bien lu mon avertissement ;-)

A noter : chose qui n’était pas possible entre la version 3 et la version 4 (car les deux composants n’utilisaient pas le même logiciel pour le clustering), il est possible de faire un cluster ProxMox mixant version 4 et version 5 comme le montre cette capture d’écran :

Aller plus loin : les limites d’OpenVPN

On a maintenant un cluster de 2 machines Proxmox. Pour autant, ce n’est pas idéal et ça ne suffira pas pour passer en production, notamment en cas de coupure réseau entre les deux machines (split brain). On va vite vouloir en rajouter au moins une, sinon plus.

Cependant, on sera bloqués. Les limites de cette méthode est que la configuration d’OpenVPN est en mode client-serveur. Si vous avez plus de 2 machines, vous vous rendrez vite compte que vous pouvez communiquer entre les clients et le serveurs, mais pas entre clients.

Et en gros ça ne marche pas, le 3ème noeud ne rejoindra pas le cluster car il ne peut pas joindre l’ensemble des membres et il se mettra en defaut.

Pour bien faire en conservant ce mécanisme, il va falloir monter un service VPN externe aux serveurs Proxmox, qui seront tous clients de ce service, ou alors se créer un réseau de type full mesh, par exemple avec de l’IPSec si vous êtes un maitre en Réseau/Telco.

Autant dire qu’il vaut mieux passer par un hébergeur qui permet le multicast ou qui fourni un service VPN. Ca ira plus vite…