Déploiement d'un cluster Proxmox HCI avec Ceph

1. Objectif et concepts

1.1 Le principe HCI

Dans une infrastructure classique, on sépare les serveurs de calcul (qui font tourner les VMs) d'un stockage externe dédié (SAN/NAS). Le modèle HCI (Hyper-Converged Infrastructure) fusionne les deux : chaque nœud fait à la fois du calcul et du stockage.

Ce TP construit un cluster à 3 nœuds où :

Proxmox VE assure la couche calcul (hyperviseur, gestion centralisée, migration de VMs).

Ceph assure la couche stockage : chaque donnée est répliquée automatiquement sur plusieurs nœuds (ici : 3 copies, 2 minimum pour continuer à fonctionner).

💡 Pourquoi : la réplication Ceph est ce qui rend la Haute Disponibilité possible : si un nœud tombe, les données de ses VMs existent déjà en copie ailleurs, donc pas besoin de les rapatrier avant de redémarrer la VM sur un autre nœud.

1.2 Objectif final : la Haute Disponibilité (HA)

Le TP se termine par un test de panne : couper brutalement un nœud et vérifier que la VM qui tournait dessus redémarre automatiquement ailleurs, sans intervention humaine et sans perte de données.

2. Environnement de lab

2.1 Pré-requis matériel (VMware Workstation)

⚠️ Note : l'option Virtualize Intel VT-x/EPT est indispensable : sans elle, Proxmox (qui est lui-même un hyperviseur) ne peut pas fonctionner correctement à l'intérieur d'une VM VMware.

2.2 Plan d'adressage

Le TP du prof donnait des IP (192.168.6.x / 192.168.8.x) supposant un réseau local particulier. Le poste utilisé étant sur un Wi-Fi en 192.168.1.x, la carte de management a été basculée en mode NAT, puis le sous-réseau NAT lui-même a été reconfiguré pour correspondre exactement à 192.168.8.0/24.

Gateway NAT : 192.168.8.2 — DNS : 8.8.8.8

3. Étape 1 — Installation de l'OS

Installation standard de Proxmox VE 9 sur les 3 nœuds, sur le disque de 20 Go.

Démarrer la VM sur l'ISO Proxmox VE 9, choisir Install Proxmox VE.

Accepter la licence, sélectionner le disque de 20 Go comme cible (filesystem ext4).

Renseigner pays / fuseau horaire / clavier.

Définir le mot de passe root et un email (peut être fictif en lab).

Configuration réseau : hostname (pve1/pve2/pve3), IP/CIDR et gateway de management.

Lancer l'installation, redémarrer, retirer l'ISO du lecteur virtuel.

💡 Pourquoi : le préfixe réseau (/24) doit être exact dès l'installation — une erreur ici (par ex. /20) casse le calcul du sous-réseau et complique tout le reste.

4. Étape 2 — Configuration des dépôts

Proxmox 9 utilise le format deb822. Il faut désactiver les dépôts Enterprise (payants) et activer les dépôts gratuits No-Subscription et Ceph Squid.

mv /etc/apt/sources.list.d/pve-enterprise.sources /etc/apt/sources.list.d/pve-enterprise.sources.disabled 2>/dev/null mv /etc/apt/sources.list.d/ceph.sources /etc/apt/sources.list.d/ceph.sources.disabled 2>/dev/null cat > /etc/apt/sources.list.d/pve-no-subscription.sources << 'EOF' Types: deb URIs: http://download.proxmox.com/debian/pve Suites: trixie Components: pve-no-subscription Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg EOF cat > /etc/apt/sources.list.d/ceph-no-subscription.sources << 'EOF' Types: deb URIs: http://download.proxmox.com/debian/ceph-squid Suites: trixie Components: no-subscription Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg EOF

Correction spécifique à l'environnement NAT (gateway VMware = .2, pas .1) + DNS :

echo "nameserver 8.8.8.8" > /etc/resolv.conf sed -i 's/gateway 192.168.8.1/gateway 192.168.8.2/' /etc/network/interfaces systemctl restart networking

Mise à jour et redémarrage :

apt update && apt dist-upgrade -y reboot

💡 Pourquoi : sans cette correction de gateway, les paquets sortaient bien du bridge local mais n'atteignaient jamais Internet (download.proxmox.com), bloquant toute mise à jour.

À répéter à l'identique sur pve1, pve2 et pve3.

5. Étape 3 — Réseau privé (backbone vmbr1)

Objectif : isoler le trafic Cluster (Corosync) et Ceph du trafic de management, sur un pont dédié (vmbr1) branché sur la seconde carte réseau (nic1).

cat >> /etc/network/interfaces << 'EOF' auto vmbr1 iface vmbr1 inet static address 10.10.10.1X/24 bridge-ports nic1 bridge-stp off bridge-fd 0 EOF

ifreload -a ip

addr show vmbr1

(remplacer X par 1, 2 ou 3 selon le nœud) — pas de gateway sur ce réseau : c'est un réseau fermé, uniquement pour le trafic inter-nœuds.

Il faut le faire sur tout les pve

💡 Pourquoi : ce réseau privé isolé garantit que le trafic de réplication Ceph (souvent volumineux) ne sature pas le lien de management, et que le heartbeat du cluster (Corosync) reste stable même si le réseau public est chargé.

⚠️ Note : l'interface web ne proposait pas toujours nic1 dans la liste déroulante du formulaire (bug d'affichage) — la création en ligne de commande donne un résultat strictement identique.

6. Étape 4 — Création et jonction du cluster

Sur le premier nœud (pve1) — création

pvecm create HCI-Cluster --link0 10.10.10.11 pvecm status

Sur les autres nœuds (pve2, pve3) — jonction

On copie le lien de jonction pour ajouter les autres pve au cluster(Cas : interface graphique)

On part sur pve2 et pv3 pour les ajouter au cluster

A faire aussi sur pv3

Ligne de commande

pvecm add 10.10.10.11 --link0 10.10.10.12 # sur pve2

pvecm add 10.10.10.11 --link0 10.10.10.13 # sur pve3

(mot de passe root de pve1 demandé à chaque jonction)

Vérification finale

pvecm status

Résultat attendu : 3 nœuds listés, Quorate: Yes.

💡 Pourquoi : le quorum (majorité de nœuds vivants, ici 2 sur 3) protège contre le split-brain : si le réseau se coupe entre nœuds, seul le groupe majoritaire continue à opérer.

⚠️ Note : cette étape a nécessité plusieurs corrections : hostnames uniques (pve1/pve2/pve3 au lieu de pve partout), cohérence de /etc/hosts, régénération des certificats SSL, nettoyage des résidus de configuration. Voir le journal d'incidents en fin de document.

7. Étape 5 — Ajout du disque de 100 Go

Simulation d'un ajout matériel (Hot Plug) pour préparer le stockage Ceph.

Éteindre les 3 VMs proprement (shutdown -h now).

Dans VMware : VM Settings > Add > Hard Disk > SCSI > 100 GB, pour chaque VM.

On fait la meme chose sur tout les pve

Rallumer les 3 VMs.

Vérifier la détection du disque :

lsblk

On verifie sur les deux autres pve

Le disque doit apparaître (généralement /dev/sdb) sans aucune partition dessus.

💡 Pourquoi : Ceph a besoin d'un disque brut, non partitionné et non formaté, pour créer un OSD — c'est lui qui gère directement le stockage bas niveau.

8. Étape 6 — Déploiement de Ceph

6A — Installation du logiciel

Sur chaque nœud : [Nœud] > Ceph > Install Ceph. L'assistant détecte les dépôts configurés à l'Étape 2 et installe Ceph Squid (19.x).

On l'avait deja fait donc normallement vous devriez voir Install ceph

6B — Configuration réseau + Monitors

Lors de la première installation (sur pve1), l'assistant réseau se lance automatiquement :

Public Network IP/CIDR : 10.10.10.11/24

Cluster Network : Same as Public Network

First Ceph monitor : pve1

Puis ajout des Monitors supplémentaires : [pve1] > Ceph > Monitor > Create → sélectionner pve2, puis pve3.

💡 Pourquoi : comme pour Proxmox, Ceph a besoin de plusieurs Monitors répartis pour garder son propre quorum indépendant.

6C — Création des OSD

Pour chaque nœud : [Nœud] > Ceph > OSD > Create: OSD → sélectionner le disque de 100 Go (/dev/sdb) → Create.

Résultat attendu : 3 OSD, un par nœud, statut Up/In.

6D — Création du pool de stockage

Ceph > Pools > Create :

Name : rbd-data

Size : 3 (nombre de répliques)

Min Size : 2 (minimum pour continuer à fonctionner)

⚠️ Cocher impérativement Add as Storage

💡 Pourquoi : Size 3 / Min Size 2 signifie que chaque donnée existe en 3 exemplaires, et que le cluster continue de fonctionner tant qu'au moins 2 exemplaires restent disponibles — c'est cette marge qui permet d'absorber la panne d'un nœud sans interruption de service.

9. Étape 7 — Haute Disponibilité (HA)

7.1 — Créer le groupe HA

Datacenter > HA > Groups > Create

ID : HA-Group

Nodes : cocher pve1, pve2, pve3

Cette partie c'est pour les anciennes version de promox promox 9 gere ca automatiquement

7.2 — Protéger une VM

Pré-requis : créer une petite VM de test (ex. Alpine Linux) dont le disque est stocké sur rbd-data (pas sur local-lvm, sinon la HA ne peut pas fonctionner).

1. Clique sur 100 (Vm-Test) dans l'arborescence
2. Va dans Hardware
3. Regarde la ligne Hard Disk : le stockage indiqué doit être rbd-data (pas local-lvm)

1. Clique sur Datacenter (racine, en haut de l'arborescence)
2. Dans le menu de gauche, clique sur HA (le mot lui-même, pas "Affinity Rules" ni "Fencing")
3. Tu devrais voir un bouton Add
4. Clique dessus
5. VM : sélectionne 100 (Vm-Test)
6. Max Restart : 1
7. State : Started
8. Add

💡 Pourquoi : la HA ne fonctionne qu'avec un stockage partagé : si le disque de la VM était en local-lvm (propre à un seul nœud), les données disparaîtraient avec le nœud en panne.

Comme il n'y a plus de "Groups" en PVE9, si tu veux explicitement dire "cette VM peut tourner sur pve1, pve2 ou pve3", ça se fait maintenant via Affinity Rules :

1. Clique sur Affinity Rules
2. Add (si l'option existe pour restreindre à des nœuds spécifiques)

Vrai test de panne (failover HA automatique)

Endroit de la VM avant le test

Va sur le nœud où tourne actuellement la VM 100 (disons pve1)

Mets ce nœud en mode maintenance : clique sur pve1 dans l'arborescence → bouton "..." ou clic droit → cherche une option du type "Enter Maintenance Mode" (selon la version) — sinon, option plus brutale : arrête carrément le nœud pve1 (shutdown now en SSH, ou coupe la VM/le serveur physique si c'est un lab)

Emplacement de la VM-test apres simulation

Ça peut prendre 1-2 minutes (le cluster attend une confirmation avant de redémarrer la VM ailleurs, pour éviter le split-brain)

⚠️ Note : pendant le test, ceph -s doit passer en HEALTH_WARN (1 OSD down) mais continuer à servir les données grâce à min_size = 2. Au redémarrage du nœud, le cluster se répare automatiquement.

Annexe — Journal des incidents réseau/cluster rencontrés

Compétences mobilisées

Virtualisation imbriquée et réseau VMware (NAT, Bridged, LAN Segment)

Administration Linux : systemctl, journalctl, configuration réseau bas niveau

Clustering Proxmox : corosync, pmxcfs, quorum, certificats

Stockage distribué Ceph : Monitors, OSD, pools répliqués

Méthodologie de dépannage réseau : tests croisés (ping, tcpdump), lecture de logs