Plan de capacité : quand ajouter un nœud ou des disques¶

Day 2 · ExploiterNiveau 3 · MaîtriserCoursRédigé · à valider en lab

Un cluster Proxmox est plein bien avant 100 % : il l'est dès qu'il ne peut plus absorber la perte d'un nœud. Cette règle, dite N+1, fixe les seuils de RAM, de CPU et de stockage qui déclenchent une commande de matériel. Comme une commande prend plusieurs semaines, l'objectif est de la lancer trois à six mois avant d'atteindre ces seuils.

Notions clés¶

Notion	Définition	Pourquoi c'est important
N+1	Les VMs de N nœuds tiennent sur N-1 nœuds	Maintenance (RB-02) et panne sans arrêt de service
Réserve hôte	RAM consommée par Proxmox lui-même : système, ARC ZFS, démons Ceph	Oubliée, elle provoque swap et OOM killer
ARC	Cache de lecture ZFS en RAM	Par défaut sur une installation récente : 10 % de la RAM, plafonné à 16 Gio
`osd_memory_target`	Cible de RAM par OSD Ceph	4 Gio par défaut, par OSD
nearfull / full	Seuils Ceph par OSD	85 % alerte, 95 % écritures bloquées (RB-04)
Ratio vCPU / cœur	vCPU alloués divisés par les cœurs physiques	La surallocation CPU est normale, dans une limite mesurée

Les seuils de déclenchement¶

Ressource	Vert	Orange : planifier	Rouge : commander ou agir
RAM des VMs (cluster)	Tient sur N-1 nœuds avec 10 % de marge	Tient tout juste sur N-1 nœuds	Ne tient plus sur N-1 nœuds
CPU (moyenne heures ouvrées, par nœud)	Sous 50 %	50 à 65 %	Au-delà de 65 % : la perte d'un nœud saturerait les autres
Ceph (OSD le plus rempli)	Sous 70 %	70 à 75 %	Au-delà de 75 %, ou ne peut plus absorber la perte d'un nœud
ZFS (`zpool list`, colonne CAP)	Sous 70 %	70 à 80 %	Au-delà de 80 % : fragmentation et chute des performances
Datastore PBS	Sous 70 %	70 à 80 %	Au-delà de 80 %, ou rétention non tenable
IO delay (nœud → Summary)	Sous 5 % en continu	Pics réguliers	Élevé en continu : stockage sous-dimensionné

Ces seuils sont des recommandations MSP, prudentes par construction. Les seuils Ceph et ZFS rejoignent ceux des calculateurs.

RAM : le calcul N+1¶

réserve hôte   = 4 à 8 Go (système) + ARC ZFS + nombre d'OSD × 4 Go
RAM utile/nœud = RAM physique - réserve hôte
limite N+1     = (N - 1) × RAM utile/nœud

Exemple : 3 nœuds de 512 Go, 6 OSD par nœud, pas de ZFS hors rpool (ARC limité à 4 Go).

Réserve hôte : 8 + 4 + 6 × 4 = 36 Go ; RAM utile : 476 Go par nœud.
Limite N+1 : 2 × 476 = 952 Go de RAM allouée aux VMs pour tout le cluster, soit environ 62 % de la RAM physique totale.
Au-delà, une maintenance oblige à arrêter des VMs.

Dimensionner l'ARC : la documentation PVE recommande au moins 2 Gio plus 1 Gio par Tio de stockage. Voir RAM et ARC.

pvesh get /cluster/resources --type vm --output-format json | \
  python3 -c "import json,sys; print(sum(v.get('maxmem',0) for v in json.load(sys.stdin))/2**30, 'Gio alloués')"
arc_summary -s arc        # taille actuelle et maximale de l'ARC

Stockage : capacité exploitable, pas brute¶

Ceph, 3 nœuds en réplica 3 : la perte d'un nœud ne peut pas être reconstruite ailleurs. Exploitable ≈ utile × 0,80.
Ceph, 4 nœuds et plus : la reconstruction après perte d'un nœud doit tenir sous nearfull. Exploitable ≈ utile(N-1) × 0,85.
ZFS : prévoir 20 % libres ; en RAIDZ, tenir compte du padding des zvols.
Tendance : relevez la capacité chaque mois (ou via le Metric Server) et projetez la date d'atteinte du seuil orange.

Calculateurs : Ceph · ZFS · PBS · formules.

Disques ou nœud ?¶

flowchart TD
    Q["Seuil orange atteint"] --> R{"Ressource limitante ?"}
    R -- "Stockage seul" --> S{"Baies libres dans les noeuds ?"}
    S -- "Oui" --> D["Ajouter des disques sur tous les noeuds, a l'identique"]
    S -- "Non" --> N["Ajouter un noeud"]
    R -- "RAM" --> M{"Slots memoire libres ?"}
    M -- "Oui" --> RAM["Ajouter de la RAM sur tous les noeuds"]
    M -- "Non" --> N
    R -- "CPU ou plusieurs ressources" --> N

Situation	Choix recommandé	Remarque
Ceph plein, baies libres	Même nombre et même taille de disques par nœud	Des nœuds déséquilibrés limitent la capacité au plus petit
Ceph 3 nœuds proche de 75 %	Ajouter un 4ᵉ nœud	Le cluster peut alors reconstruire après une panne
ZFS plein	Nouveau vdev identique, ou extension RAIDZ	Agrandir un pool ; jamais un disque seul
RAM N+1 dépassée	RAM en priorité si slots libres	Moins cher qu'un nœud, mais même modèle de barrettes
Cluster à 2 nœuds qui grossit	Passage à 3 nœuds	Supprime la dépendance au QDevice

Recommandations MSP¶

Revue de capacité trimestrielle avec le MSP (contrats N2/N3), à partir des relevés de la routine hebdomadaire.
Ajout de disques : le client peut créer des OSD ou remplacer des disques ; les changements de règles CRUSH, de nombre de PG ou l'ajout de nœud au cluster sont faits par le MSP (Ajouter un nœud).
Achetez du matériel identique à l'existant : même classe de SSD (entreprise, avec PLP), même génération de CPU pour la migration à chaud.

Pièges vus en support

Raisonner en capacité brute Ceph : 30 To bruts en réplica 3 donnent 10 To utiles, et environ 8 To exploitables.
Compter la RAM « utilisée » des VMs au lieu de la RAM allouée : une VM peut monter à son maximum au pire moment.
Ajouter un seul gros disque dans un seul nœud Ceph : déséquilibre et OSD nearfull en premier.
Oublier l'ARC et les OSD dans la réserve hôte : swap, puis OOM killer sur une VM.
Constater le seuil rouge le jour où un nœud tombe.

Quand ouvrir un ticket iTop

Seuil orange atteint : ticket P4 « étude de capacité », avec ceph osd df tree ou zpool list, et la RAM allouée. Seuil rouge Ceph : P3, ou P1 si un OSD est full (RB-04).

Ouvrir un ticket iTop

Testez-vous¶

Trois nœuds de 256 Go, réserve hôte de 32 Go par nœud. Combien de RAM pouvez-vous allouer aux VMs en respectant N+1 ?

Réponse

RAM utile : 256 - 32 = 224 Go par nœud. Limite N+1 : 2 × 224 = 448 Go pour tout le cluster.
Pourquoi un cluster Ceph de 3 nœuds en réplica 3 ne doit-il pas dépasser environ 80 % de sa capacité utile ?

Réponse

Avec un domaine de panne host, la perte d'un nœud ne peut pas être reconstruite sur les deux autres : le cluster reste dégradé. Il faut garder une marge pour la croissance et pour rester sous nearfull (85 %) sur l'OSD le plus rempli.
Le pool ZFS tank est à 83 %. Quel est le risque et que faire ?

Réponse

Au-delà de 80 %, la fragmentation dégrade les performances et la réplication peut échouer. Libérer de l'espace (snapshots, disques orphelins) puis ajouter un vdev identique ou étendre le RAIDZ ; ouvrir un ticket d'étude de capacité.
Vos VMs consomment 40 % de RAM en moyenne mais 75 % est alloué. Lequel retenir pour N+1 ?

Réponse

La RAM allouée (75 %) : c'est le maximum que les VMs peuvent réclamer, notamment lors du redémarrage sur un autre nœud.