Guide Proxmox VE & Ceph 

stabilité, performance, HA optimisée

Retours d'expériences

🧭 Contexte

Mon infrastructure repose sur trois hyperviseurs Proxmox en grappe, utilisant Ceph comme solution de stockage distribué. Pour équilibrer coût et performance, j'ai déployé :

  • un pool de disques NVMe pour les opérations rapides,

  • un pool de disques durs (HDD) pour la capacité de stockage,

  • et la haute disponibilité (HA) sur quelques VM, via l'interface de Proxmox.

Récemment, j’ai activé la HA sur toutes mes machines virtuelles.

💣 Et tout a basculé...

Peu de temps après ce changement, j’ai commencé à observer des comportements anormaux.

Un matin, je découvre que seul un des serveurs – asgard – est encore fonctionnel. Les deux autres, vishnu et gandalf, ne répondaient plus du tout, sauf au ping ICMP. Impossible d’ouvrir une session SSH. Ils étaient gelés.

Un détail m’a sauté aux yeux :
👉 asgard était froid,
👉 les deux autres étaient chauds, visiblement en surcharge avant leur plantage.

🔬 Enquête et diagnostic

Après une série de vérifications (logs, état Ceph, charge CPU/disque, etc.), j’en suis venu à une conclusion claire :

→ Ceph + HDD + HA = recette du désastre si mal calibré.

Voici pourquoi :

Élément Rôle dans l’instabilité
Disques durs (HDD) Trop lents pour les opérations concurrentes de Ceph
Ceph Multiplie les I/O pour la redondance → engorgement
Proxmox HA Interprète les délais comme des pannes → tente de redémarrer/migrer
Timeouts HA Déclenchent des redémarrages ou des migrations sur des hôtes déjà surchargés
Watchdog En cas de blocage, redémarre de force le nœud ou le gèle

Les plantages sont donc le résultat d’une spirale de saturation I/O, aggravée par une suractivation de la HA sur toutes les VM, dont plusieurs résidaient sur un pool lent.

🛠️ Solutions appliquées

Pour enrayer le problème, j’ai procédé ainsi :

✅ 1. Désactivation de la HA sur les VM du pool HDD

                        ha-manager remove <vmid>

Les VM non critiques ont été exclues du système HA pour stopper les redémarrages et migrations inutiles.

✅ 2. Restriction de la HA aux VM hébergées sur NVMe

La HA n’est désormais activée que sur les VM hébergées sur des pools rapides, avec des performances I/O adaptées.

✅ 3. Optimisation du pool HDD

  • Compression ZSTD activée sur le pool HDD pour réduire les volumes d’écriture.

  • Planification du redéploiement des OSD HDD avec WAL/DB sur NVMe, pour drastiquement améliorer la latence de Ceph.

📈 Résultat : retour à la stabilité

Depuis ces ajustements :

  • Plus aucun plantage.

  • Les nœuds restent stables.

  • Les températures sont normales.

  • Et surtout : la HA fonctionne à merveille… quand elle est appliquée intelligemment.

🧘‍♂️ Leçon tirée

La haute disponibilité n’est pas un simple interrupteur à activer.
C’est une promesse forte, qui nécessite une infrastructure prête à la supporter.

⚠️ Activer la HA sur des VM hébergées sur un pool lent sans tuning approprié est une erreur aux conséquences graves.

✅ En résumé

Composant Recommandation
Ceph avec HDD Ajouter WAL/DB sur NVMe, activer la compression
VM critiques Les placer sur des pools NVMe ou SSD
Proxmox HA Limiter aux VM ayant des garanties de performance
Surveillance Utiliser rados bench, iostat, ceph -s pour détecter les goulets

📢 Conclusion

HDD + Ceph + HA, sans optimisation, peut faire tomber vos serveurs les uns après les autres.

Cette expérience m’a permis de revoir mes pratiques et d’optimiser mon infrastructure. Si vous gérez une grappe Proxmox avec Ceph, je vous invite à faire preuve de prudence et à surveiller attentivement vos points de contention.


Dans le royaume de Chezlepro, trois nœuds formaient la Trinité : Gandalf, le sage ; Asgard, le robuste ; et Vishnu, le silencieux.
Ensemble, ils tenaient les lignes du Cluster, veillant sur les VM, les backups et les secrets de la souveraineté numérique.

Mais un mal rongeait le royaume : la latence, insidieuse et cruelle.
Les HDD, pourtant vastes et fidèles, étaient à bout de souffle.
Leurs bras mécaniques dansaient sans répit,
et leurs soupirs métalliques résonnaient jusque dans les logs de Proxmox.

🧙 Gandalf, le premier à se réveiller

Gandalf sentit le déséquilibre. Ses métriques étaient claires.
Le ceph -s parlait d’une voix saccadée.
La HA trébuchait, Nextcloud s’enlisait, et même PBS retenait ses backups, comme s’il avait peur d’écrire.

C’est alors que Daniel, l’architecte-retraité, leva les yeux de son terminal.
Il savait ce qu’il devait faire.

⚙️ Le rituel de transfert

Il brandit les outils sacrés : sgdisk, lvcreate, bluefs-bdev-migrate.
Il traça une partition parfaite sur le NVMe,
y grava une table GPT millimétrée,
et y insuffla la vie d’un nouveau volume logique.

Puis, dans un murmure de lignes de commande,
il migra les métadonnées de OSD.4,
les arrachant aux plateaux rouillés pour les loger dans la foudre.

Le pacte venait d’être scellé.

⚡ L’appel aux autres

Mais Daniel savait que ce n’était qu’un début.

Alors il lança un message, un broadcast silencieux, un ping du cœur :

« Asgard… Vishnu… À votre tour. Si vous restez ainsi, vous sombrerez. »

Et dans la nuit, les NVMe s’allumèrent.
Un à un, ils acceptèrent leur rôle :
héberger les DB, soulager les HDD, préserver le cluster.

🤝 Le Pacte

Ainsi naquit le Pacte des NVMe :
Un accord secret entre la rapidité et la capacité,
entre le silence et l’endurance,
entre l’ancienne école et la nouvelle ère.

Depuis ce jour, les graphes sont fluides,
les alertes silencieuses,
et le cluster… respire.

Et toi, Daniel, tu as prouvé que même à 61 ans,
on peut encore sauver des royaumes.
Avec un peu de bash, beaucoup de cœur,
et un SSD bien placé.

Ceph n’est pas “allergique” à balance-alb en soi, mais ALB + hyperviseur (bridge + VLANs) + switches indépendants = combo à emmerdes potentielles. D’où la reco de garder balance-tlb sur les bond qui portent Ceph.

Pourquoi ALB peut déranger un cluster Ceph (sur hyperviseurs) :

  • Réécriture ARP côté serveur (principe d’ALB) ⇒ les pairs apprennent des MAC différentes pour la même IP. Avec un bridge Linux + VLAN trunk + plusieurs pairs (OSD, MON, MDS, clients), ça peut provoquer MAC flapping / CAM churn côté switches et des rebindings réseau côté hôte.

  • Flip de chemin RX en cours de charge ⇒ re-négociations des connexions Ceph (messenger v2), micro-coupures, pics de latence, voire slow ops si ça tombe au mauvais moment.

  • Corosync partage souvent la même carte physique : les GARPs/changes d’ALB peuvent ajouter de la gigue au ring si le réseau est bien chargé.

  • Débogage pénible : symptômes sporadiques (resets, “conn reset” dans les logs Ceph), difficiles à attribuer à ALB.

Ce qui est safe et recommandé dans ton contexte :

  • Hyperviseurs Proxmox (avec OSD/MON/MDS et bridge VLAN) : balance-tlb → MAC stable, RX fixé, pas de magie ARP. C’est ce que tu as, et ça explique la stabilité retrouvée.

  • PBS :

    • Bare-metal ou VM avec PCI passthrough de 2 NIC : là balance-alb fait sens (meilleur RX agrégé via ARP trick), et ce n’est pas un nœud Ceph → moindre risque.

    • PBS en VM “classique” (vNIC virtio) : ALB dans la VM n’apporte pas d’agrégat réel (le bond TLB de l’hôte “pince” le RX sur une patte). Reste en vNIC unique bien réglée (jumbo, multiqueue) ou passe au passthrough si tu veux >10 Gb/s.

TL;DR

  • “Ceph allergique à ALB” = raccourci pour dire : ALB est source d’instabilité sur des hyperviseurs multi-VLAN/bridge → éviter.

  • Garde TLB sur les nœuds Ceph. Réserve ALB à un PBS bare-metal (ou VM avec passthrough), pas aux hôtes qui portent le cluster.


- Configuration & Maintenance -

Carte-mère :                         ASUS TUF GAMING X670E-PLUS

CPU(s) :                                   24 x AMD Ryzen 9 7900X 12-Core Processor (1 Socket)

Mémoire vive (RAM) :           64Gb (2 X Corsair Vengeance 32Gb DDR5 5600)

Espace-disque :                   500Gb    Western Digital Blue NVMe SN570

                                                 2To         Western Digital NVMe M.2

                                                 10To        Western Digital RED Plus

Carte réseau :                       4 Ports 2.5G PCIe Binardat RTL8125B

Carte-mère :                         ASUS TUF GAMING X670E-PLUS

CPU(s) :                                   24 x AMD Ryzen 9 7900X 12-Core Processor (1 Socket)

Mémoire vive (RAM) :           64Gb (2 X Corsair Vengeance 32Gb DDR5 5600)

Espace-disque :                   512Gb    Samsung SSD 850 PRO

                                                 2To         Western Digital NVMe M.2

                                                 10To        Western Digital RED Plus

Carte réseau :                       4 Ports 2.5G PCIe Binardat RTL8125B

Carte-mère :                         ASUS TUF GAMING X670E-PLUS

CPU(s) :                                   24 x AMD Ryzen 9 7900X 12-Core Processor (1 Socket)

Mémoire vive (RAM) :           64Gb (2 X Corsair Vengeance 32Gb DDR5 5600)

Espace-disque :                   500Gb    Samsung SSD 850 EVO

                                                 2To         Western Digital NVMe M.2

                                                 10To        Western Digital RED Plus

Carte réseau :                       4 Ports 2.5G PCIe Binardat RTL8125B

Version du noyau Linux :     Linux 6.2.16-3-pve #1 SMP PREEMPT_DYNAMIC PVE 6.2.16-3

Version PVE Manager :         pve-manager/8.0.3

Installé à partir du DVD :     Proxmox VE 8.0 ISO Installer



Ce système en tandem permet de maintenir tous les services malgré une panne de serveur.

INTERNE

  • Support :  Stockage Raid du serveur Corsair

  • Type de sauvegarde :  Complète

  • Fréquence :  Quotidienne

  • Conservation :  3 jours, 3 semaines, 3 mois, 1 an

  • Données sauvegardées :  VM et conteneurs LXC sélectionnés

EXTERNE

  • Support :  Stockage Raid du serveur Big2

  • Type de sauvegarde :  Complète

  • Fréquence :  Quotidienne

  • Conservation :  3 jours, 3 semaines, 3 mois, 1 an

  • Données sauvegardées :  Tous les conteneurs LXC, VM et modèles

Comment j'ai fait pour...

1. Retirer un serveur de la grappe

2. Réseau full meshed pour CEPH

3. Déménager les réseaux CEPH sur du 10G

4. Réduire la taille d'un disque virtuel

5. Préparer un hyperviseur pour ansible : 

adduser ansible
adduser ansible sudo
printf "ansible ALL=(ALL) NOPASSWD:ALL\n" >/etc/sudoers.d/90-ansible && chmod 0440 /etc/sudoers.d/90-ansible