Aller au contenu

Prérequis non négociables : 3 nœuds min., SSD entreprise PLP, réseau 25 Gb+ dédié

Day 0 · ConcevoirNiveau 2 · OpérerCoursRédigé · à valider en lab

Un cluster Ceph hyperconvergé sur Proxmox VE demande au minimum trois nœuds identiques, des SSD ou NVMe entreprise avec protection contre les coupures de courant (PLP), des contrôleurs HBA sans RAID et un réseau Ceph dédié d'au moins 10 Gb/s, 25 Gb/s recommandé. En dessous, le MSP ne livre pas l'architecture Ceph HCI : on bascule sur ZFS répliqué ou SAN.

Les prérequis et leur raison d'être

Prérequis Minimum Proxmox Standard MSP Pourquoi
Nœuds 3 serveurs, de préférence identiques 3 nœuds pour démarrer, 4 recommandés Quorum de 3 MON ; réplica 3 avec une copie par hôte. Avec 4 nœuds, Ceph peut reconstruire la 3e copie après perte d'un nœud.
OSD Un OSD par disque physique, au moins 12 OSD sur 3 nœuds 4 à 8 OSD par nœud, tailles identiques Répartition des PG, reconstruction parallèle, perte d'un disque ≠ perte d'un nœud.
Disques SSD plutôt que HDD sur les petits clusters SSD SATA/SAS ou NVMe entreprise avec PLP Ceph impose des écritures synchrones (fsync). Sans PLP, chaque écriture attend la mémoire flash : latences de plusieurs ms.
Contrôleur Éviter le RAID, utiliser un HBA HBA ou contrôleur en mode IT/JBOD réel Ceph gère lui-même la redondance ; un cache RAID masque les erreurs et fausse la détection des pannes.
Réseau Ceph 10 Gb/s minimum, dédié à Ceph ; 25 Gb/s et plus pour des performances élevées 25 Gb/s redondé (2 × 25 Gb/s), séparé de Corosync La réplication triple le trafic d'écriture ; une reconstruction peut saturer un lien 10 Gb/s pendant des heures.
Corosync Réseau 1 Gb/s dédié 2 liens Corosync, dont un dédié Corosync supporte mal la latence d'un lien saturé par Ceph : risque de perte de quorum PVE.
RAM 8 Gio par OSD recommandés (4 Gio par défaut pour le démon OSD) 8 Gio par OSD + 2 Gio par MON/MGR + RAM des VMs + 10 % La cible mémoire d'un OSD (osd_memory_target) est de 4 Gio, mais la reconstruction consomme davantage.
CPU Au moins 1 cœur par service Ceph ; 4 à 6 threads par OSD NVMe Réserver les cœurs Ceph dans le sizing des VMs Un OSD NVMe saturé en CPU devient le goulet d'étranglement.
Horloge NTP synchronisé chrony sur tous les nœuds, mêmes sources Un décalage déclenche MON_CLOCK_SKEW et peut perturber le quorum.

Ce que signifie « SSD entreprise avec PLP »

  • Les condensateurs PLP permettent au SSD d'acquitter une écriture synchrone dès qu'elle est dans son cache, sans risque de perte en cas de coupure.
  • Sur la fiche technique : Power Loss Protection, Enhanced Power Loss Data Protection, PLP. Gammes typiques : SSD « Data Center » ou « Enterprise » en mixed-use ou read-intensive.
  • Vérifiez aussi l'endurance (DWPD ou TBW). Pour des VMs générales, 1 DWPD suffit souvent ; 3 DWPD pour des bases de données très écrivantes.
  • Un SSD grand public, même NVMe très rapide en benchmark séquentiel, s'effondre en écriture synchrone 4 K. Le calculateur Ceph le signale en alerte critique.

Vérifier un serveur avant installation

lspci | grep -iE 'raid|sas|nvme'            # contrôleur HBA attendu, pas de RAID
lsblk -d -o NAME,MODEL,SIZE,ROTA,TRAN        # ROTA=0 pour SSD/NVMe
smartctl -i /dev/sdb                         # modèle exact, à comparer à la fiche PLP
ethtool ens1f0 | grep Speed                  # 25000Mb/s attendu sur le réseau Ceph
chronyc tracking                             # décalage de quelques ms au plus
free -g                                      # RAM totale, à comparer au sizing

Recommandations MSP

  • Quatre nœuds plutôt que trois quand le budget le permet : c'est le seul moyen de retrouver trois copies après la perte d'un nœud.
  • Disques de boot séparés (ZFS RAID1 sur deux petits SSD), jamais d'OSD sur le disque système.
  • Même modèle et même taille de disque OSD sur tous les nœuds ; pas de mélange HDD et SSD dans un même pool.
  • Réseau Ceph physique séparé du réseau des VMs, MTU 9000 de bout en bout si le réseau le permet (voir Réseaux Ceph).
  • Faire valider la nomenclature matérielle par le MSP avant commande : c'est inclus dans la phase de conception.

Pièges vus en support

  • Deux nœuds « en attendant le troisième » : Ceph n'a pas de quorum fiable et le réplica 3 est impossible. Choisir ZFS répliqué + QDevice pour deux nœuds.
  • Contrôleur RAID configuré en RAID 0 par disque pour « simuler » un HBA : SMART invisible, cache contrôleur trompeur, pannes mal détectées.
  • Réseau Ceph sur le même bond 10 Gb/s que les VMs et Corosync : à la première reconstruction, perte de quorum PVE et VMs figées.
  • SSD grand public récupérés d'un ancien projet : latence d'écriture de 5 à 20 ms au lieu de moins d'une ms.
  • RAM dimensionnée pour les VMs seulement : les OSD sont tués par l'OOM killer pendant une reconstruction.

Testez-vous

  1. Pourquoi un SSD sans PLP est-il lent sous Ceph alors qu'il est rapide sur un poste de travail ?

    Réponse

    Ceph acquitte les écritures de façon synchrone. Sans PLP, le SSD doit écrire réellement sur la flash avant d'acquitter, ce qui multiplie la latence. Avec PLP, il peut acquitter depuis son cache protégé.

  2. Combien de RAM prévoir pour les OSD d'un nœud portant 6 OSD ?

    Réponse

    Proxmox recommande au moins 8 Gio par OSD, soit 48 Gio, à ajouter à la RAM des VMs, des MON/MGR et du système.

  3. Pourquoi le MSP recommande-t-il 4 nœuds plutôt que 3 ?

    Réponse

    Avec 3 nœuds en réplica 3, chaque nœud porte une copie. Si un nœud tombe, il n'existe aucun autre hôte pour reconstruire la 3e copie : le cluster reste dégradé jusqu'au retour du nœud. Avec 4 nœuds, Ceph reconstruit et revient à active+clean.

  4. Un serveur livré avec un contrôleur RAID : que faire ?

    Réponse

    Le passer en mode HBA/IT si le contrôleur le permet réellement (disques vus directement, SMART accessible), sinon le remplacer par un HBA. Ne pas créer de volumes RAID 0 par disque.

Pour aller plus loin