Proxmox et Ceph : construire un cluster de virtualisation qui ne s'arrête pas

Quand un client nous demande une infrastructure serveur « qui ne tombe pas », la réponse n’est plus un gros serveur relié à une baie SAN. C’est un cluster de machines identiques qui partagent leur stockage et se relaient automatiquement. Cette architecture, longtemps réservée aux grands comptes, est aujourd’hui à la portée d’une PME grâce à Proxmox VE et Ceph, deux logiciels libres éprouvés en production.

Le sujet est devenu très concret depuis l’évolution des licences VMware vers des abonnements : beaucoup d’entreprises au Maroc, en Afrique et en Europe réexaminent leur plateforme de virtualisation au moment du renouvellement. Voici l’architecture que nous déployons le plus souvent, les choix qui la font tenir et les erreurs que nous voyons régulièrement.

Le principe : plus de pièce unique

Dans un cluster Proxmox VE avec Ceph, chaque nœud apporte à la fois du calcul (processeurs, mémoire) et des disques. Ceph agrège tous ces disques en un seul stockage distribué et réplique chaque bloc de données sur plusieurs nœuds. On parle d’architecture hyperconvergée.

Deux mécanismes travaillent ensemble :

• Le cluster Proxmox surveille l’état des nœuds. Si un serveur disparaît, il est isolé automatiquement (fencing), puis ses machines virtuelles protégées par la haute disponibilité redémarrent sur les nœuds restants, en quelques minutes et sans intervention humaine.
• Ceph garantit que les disques de ces machines sont toujours accessibles, puisque leurs données existent déjà en plusieurs exemplaires sur les autres nœuds.

Il n’y a ni baie SAN à racheter, ni contrôleur unique dont dépend tout le reste. Et pour la maintenance planifiée (mise à jour, remplacement d’une barrette mémoire), les machines sont déplacées à chaud vers un autre nœud, sans interruption pour les utilisateurs.

Le dimensionnement qui compte

• Trois nœuds minimum. Le cluster a besoin d’une majorité de votants (le quorum) pour prendre des décisions : avec trois nœuds, il la conserve si l’un tombe. Ceph fonctionne de la même manière avec ses moniteurs, déployés sur trois nœuds.
• Quatre ou cinq nœuds pour plus de confort. Avec trois nœuds et trois copies, la perte d’un serveur laisse le stockage en mode dégradé jusqu’à son retour. À partir de quatre nœuds, Ceph peut recréer lui-même la copie manquante sur un autre serveur. Plus de nœuds répartissent aussi mieux la charge.
• Un réseau dédié à Ceph, 10 GbE au minimum, 25 GbE ou plus dès que les disques sont en NVMe. C’est l’erreur la plus courante : faire passer la réplication sur le réseau des utilisateurs.
• Un lien séparé pour le cluster (Corosync), idéalement doublé. Ce trafic est léger mais très sensible à la latence : s’il est noyé dans le trafic de stockage, les nœuds peuvent se croire isolés.
• Des SSD entreprise avec protection contre les coupures de courant, NVMe de préférence, pour les OSD (les disques gérés par Ceph). À budget contraint, des SSD SATA entreprise avec la base de données et le journal de Ceph (DB/WAL) placés sur un NVMe.
• Des disques présentés directement, sans contrôleur RAID matériel : Ceph gère lui-même la redondance, un RAID en dessous ne fait que la gêner.
• Réplication ×3 par défaut, avec au moins deux copies disponibles pour continuer à écrire. L’erasure coding économise de l’espace mais coûte en latence et demande davantage de nœuds : nous le réservons aux archives.

Architecture type pour une PME

Composant	Choix recommandé	Pourquoi
Nœuds	3 serveurs identiques, 4 ou plus si budget	Quorum, trois copies sur trois hôtes, reconstruction automatique à partir de 4
Réseau Ceph	Lien dédié 10 GbE minimum, 25 GbE avec NVMe	La réplication et la reconstruction passent par là
Réseau cluster	Lien séparé, idéalement redondant	Stabilité du quorum, pas de faux basculements
Réseau utilisateurs	Interfaces distinctes, en agrégation	Le trafic des machines virtuelles n’entre pas en concurrence avec le stockage
Disques	SSD entreprise avec protection coupure, NVMe de préférence	Performances et intégrité des écritures
Pools Ceph	Réplication ×3, deux copies minimum pour écrire	Survie à la perte d’un nœud sans perte de données
Remplissage	Garder une large marge libre	Ceph alerte par défaut à 85 % et doit pouvoir absorber la perte d’un nœud
Sauvegarde	Proxmox Backup Server ou Veeam, copie hors site	Protection contre l’erreur humaine et le rançongiciel

La règle du remplissage est souvent oubliée : si un nœud tombe, ses données sont redistribuées sur les autres. Un cluster déjà plein n’a plus la place de le faire. Nous dimensionnons donc la capacité utile pour qu’elle tienne sur les nœuds restants après une panne.

La migration depuis VMware

Nous commençons par un inventaire : chaque machine virtuelle, son rôle, sa criticité, ses dépendances et le créneau acceptable pour sa bascule. Proxmox VE intègre depuis sa version 8.2 un assistant d’import qui lit directement les machines d’un hôte ESXi, ce qui simplifie beaucoup l’opération.

Nous importons ensuite les machines virtuelles une par une, hors heures de production, avec conversion des pilotes vers VirtIO et désinstallation des outils VMware. Chaque bascule est suivie d’une vérification fonctionnelle avec l’utilisateur concerné. Les serveurs les plus critiques passent en dernier, une fois le cluster éprouvé par les autres. Aucune coupure globale : seulement de courts arrêts planifiés, machine par machine, avec un retour arrière possible tant que l’ancienne plateforme reste en place.

Si vous hésitez encore entre plusieurs plateformes, notre article sur XCP-ng et Xen Orchestra présente une autre alternative open source à VMware.

La sauvegarde reste indispensable

Ceph protège contre la panne matérielle, pas contre l’erreur humaine ni le rançongiciel : une suppression ou un chiffrement malveillant est répliqué fidèlement sur les trois copies. Proxmox Backup Server ou Veeam, avec une copie immuable ou déconnectée hors site, complète l’architecture. Les deux s’intègrent nativement à Proxmox VE ; nous choisissons selon votre parc existant. Nos guides sur la sauvegarde 3-2-1 immuable et les bons réglages Veeam détaillent la démarche.

Le serveur de sauvegarde ne doit pas faire partie du cluster qu’il protège : s’il tombe avec lui, il ne sert à rien.

Les erreurs fréquentes

• Construire un cluster Ceph sur deux nœuds : sans troisième votant, la perte d’un serveur bloque tout.
• Mélanger réplication, cluster et utilisateurs sur le même réseau : les performances s’effondrent au pire moment, pendant une reconstruction.
• Utiliser des SSD grand public : sans protection contre les coupures, ils sont lents en écriture synchrone et s’usent vite sous Ceph.
• Passer les disques par un contrôleur RAID au lieu de les présenter directement à Ceph.
• Remplir le stockage à ras bord : la perte d’un nœud n’a plus la place d’être absorbée.
• Confondre réplication et sauvegarde : trois copies d’une donnée chiffrée par un rançongiciel restent trois copies inutilisables.
• Ne jamais tester la bascule : un cluster haute disponibilité se valide en coupant réellement un nœud, pendant la recette.

Checklist avant la mise en production

• Au moins trois nœuds identiques, avec quorum vérifié.
• Réseau Ceph dédié et lien Corosync séparé, testés en charge.
• SSD entreprise présentés directement à Ceph, pools en réplication ×3.
• Marge de capacité suffisante pour absorber la perte d’un nœud.
• Haute disponibilité activée sur les machines critiques, avec ordre de priorité.
• Test de panne réel : arrêt brutal d’un nœud et vérification du redémarrage des machines.
• Sauvegarde hors du cluster, copie hors site, restauration testée.
• Supervision de l’état de Ceph, des disques et du quorum, avec alertes traitées.

Ce que cela coûte

Proxmox VE est un logiciel libre : pas de licence obligatoire, pas de renouvellement imposé. L’abonnement Proxmox Enterprise, facturé par processeur physique et par an, est optionnel : il donne accès au dépôt de mises à jour stable et au support éditeur. Nous le recommandons pour la production. Le budget se joue donc surtout sur le matériel (serveurs, disques, commutateurs 10 ou 25 GbE) et sur l’exploitation dans la durée.

Comment nous procédons

Nous partons de votre existant : inventaire des machines virtuelles, charge réelle, volumétrie et objectifs de reprise. Nous dimensionnons ensuite le cluster, le réseau et le stockage, nous l’installons, puis nous faisons une recette formelle avec test de panne avant la moindre migration. La bascule se fait par lots, hors heures de production. Une fois en service, le cluster est intégré à notre supervision 24/7, avec prise en charge des incidents critiques en moins de 15 minutes, dans le cadre d’un contrat d’infogérance informatique si vous le souhaitez.

Découvrez notre offre virtualisation et infrastructure serveur, nos pages partenaires Proxmox et Veeam, et un exemple de cluster de virtualisation dans nos réalisations. Pour étudier votre projet, demandez un audit gratuit : nous vous répondons sous 24 h ouvrées.