¶ Introduction
Dans cette documentation nous allons voir ensemble comment configurer le quorum dans un cluster Proxmox avec deux nœuds.
Elle fait suite à la documentation concernant la création d'un Cluster Proxmox avec deux nœuds sans HA ni Qdevice.
Puisque cette architecture est fragile en raison de l’absence d’arbitrage et de haute disponibilité, l’objectif ici sera donc de corriger ces faiblesses en :
- ajoutant un QDevice (serveur de quorum externe)
- activant et configurant le HA (High Availability)
l'architecture ciblée après la configuration sera celle-ci :
- Nested-Cluster1-Prox9-01 : nœud du cluster - vote = 1
- Nested-Cluster1-Prox9-01 : nœud du cluster - vote = 1
- qdevice : vote externe - vote = 1
Soit un total de votes égal à 3 et un quorum égal à 2.
L'environnement Proxmox que j'utilise pour faire cette documentation est un environneent virtuel.
C'est à dire que les serveurs Proxmox que je vais utiliser sont des VMs cependant la procédure reste identique avec du matériel physique.
¶ Prérequis
- Avoir une infrastructire similaire à celle indiquée dans cette documentation.
- Avoir accès en SSH à Proxmox.
- Avoir une machine Linux dédiée à l'installation du qdevice. Dans mon cas ce sera une Debian 13.
- Avoir accès en SSH à la machine du qdevice.
- Un compte ayant suffisament de droits pour effectuer les manipulations.
¶ Installation du serveur Qdevice
- Se connecter en SSH sur la machine Linux externe qui sera utilisée comme Qdevice.
Taper la commande suivante :
apt install corosync-qnetd
Valider la demande d'installation en tapant "o" (ou "y" si l'OS est en anglais) lorsque ce sera demandé.
- Activer et démarrer le service.
systemctl enable corosync-qnetd && systemctl start corosync-qnetd
- Vérifier l'état du service "corosync-qnetd"
systemctl status corosync-qnetd
Le service doit être à l'état "active (running)".
Si ce n'est pas le cas vous avez un problème qu'il faudra corriger.
- Vérifier que le service est bien en écoute.
Par défaut le service écoute sur le port 5403/TCP.
ss -tulnp | grep 5403
¶ Installation côté cluster PVE
Nous allons devoir faire les manipulations suivantes sur les deux serveurs PVE qui composent actuellement le Cluster.
- Installation du service "corosync-qnetd"
apt install corosync-qdevice
Valider la confirmation des packages en tapant soit "o" soit "y" selon la langue de l'OS.
¶ Configuration du QDevice dans le cluster PVE
¶ Ajout automatique via "pvecm"
- Depuis le premier serveur Proxmox du Cluster taper la commande suivante :
pvecm qdevice setup <IP_QDEVICE>
Valider par yes puis entrer le password root du Qdevice
Cette commande effectue plusieurs actions importantes :
- Génère des certificats dans /etc/corosync/
- Configure automatiquement Corosync
- Ajoute la section QDevice dans /etc/pve/corosync.conf
- Synchronise la configuration sur tous les nœuds
¶ Vérification du fichier "corosync.conf"
Nous allons à présent vérifier le fichier "corosync.conf" et s'assurer que tout est en order.
Ouvrir le fichier "corosync.conf"
cat /etc/pve/corosync.conf
Après l'ajout du service dans le cluster Proxmox le fichier devrait comporter ces lignes :
Pour information : Cette section indique que le cluster utilise un vote externe.
¶ Vérification globale du cluster
Pour vérifier la configuration globale du Cluster il faudra taper cette commande :
pvecm status
Nous devrions avoir ce résultat :
- Expected votes: 3
- Highest expected : 3
- Total votes: 3
- Quorum: 2
- Flags : Quorate Qdevice
¶ Vérification des certificats
Les certificats sont stockés dans :
/etc/corosync/qdevice/net/
Ils permettent l’authentification entre les nœuds et le QDevice.
¶ Tests de fonctionnement du quorum
¶ Simulation de panne
Pour simuler une panne je vais éteindre le premier serveur Proxmox du Cluster.
shutdown now
Puis, depuis le second serveur Proxmox, je vais vérifier l'état du Cluster.
pvecm status
Si tout c'est correctement passé le quorum doit être maintenu grâce au QDevice.
Rallumer le premier serveur Proxmox.
¶ Test de perte réseau
Pour tester le réseau et vérifier que tout fonctionne correctement en cas de panne nous allons simuler une coupure réseau vers un nœud.
Depuis le premier serveur Proxmox taper la commande suivante :
ip link set vmbr1 down
Si tout se passe correctement, le Cluster fonctionne toujours.
¶ Activation et configuration du HA
¶ Services HA
- Sur chaque nœud, activer les services suivants :
systemctl enable pve-ha-lrm
systemctl enable pve-ha-crm
systemctl start pve-ha-lrm
systemctl start pve-ha-crm
¶ Vérification
- Sur chaque nœud, vérifier le status des services :
systemctl status pve-ha-lrm
systemctl status pve-ha-crm
Les services doivent être actifs.
¶ Fichiers de configuration HA
Tous les fichiers du HA sont dans le répertoire /etc/pve/ha/
- Fichier resources.cfg :
/etc/pve/ha/resources.cfg
Ce fichier définit :- Les VM gérées en HA
- Leur comportement
- Fichier manager_status :
/etc/pve/ha/manager_status
Ce fichier contient l’état interne du cluster HA (Il ne pas modifier manuellement)
¶ Configuration du HA sur une VM
Je n'ai pas créé de VM pour cette documentation, je ne ferai donc pas de carpture d'écran.
Je me contenterai de donner les commandes en exemple
- Ajout du HA sur une VM
ha-manager add vm:100
- Vérification du HA sur une VM
ha-manager status
- Modification des paramètres
ha-manager set vm:100 --max_restart 5 --max_relocate 2
¶ Fonctionnement interne du HA
-
CRM (Cluster Resource Manager)
- Lit /etc/pve/ha/resources.cfg
- Décide où démarrer les VM
-
LRM (Local Resource Manager)
- Exécute les actions localement
- Démarre/arrête les VM
Ces composants communiquent via Corosync.
¶ Vérifications avancées
- Logs Corosync
journalctl -u corosync
- Logs HA
journalctl -u pve-ha-lrm
journalctl -u pve-ha-crm
- État QDevice
corosync-qdevice-tool -s