Choisir le matériel : CPU, RAM ECC, HBA vs RAID, NIC, disques boot¶

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

Un nœud Proxmox VE de production repose sur cinq choix qui ne se rattrapent pas après coup : des CPU homogènes, de la RAM ECC en quantité suffisante, un contrôleur disque en mode HBA (pas de RAID matériel sous ZFS ou Ceph), des SSD entreprise avec protection contre les coupures (PLP) et des cartes réseau redondantes avec un lien dédié à Corosync.

Notions clés¶

CPU¶

Critère	Recommandation	Pourquoi
Virtualisation	Intel VT-x ou AMD-V activé dans le BIOS/UEFI	Obligatoire pour KVM
IOMMU	VT-d ou AMD-Vi activé (« Enabled », pas « Auto »)	Requis pour le PCI passthrough
Homogénéité	Même génération et même fabricant sur tout le cluster	Migration à chaud fiable ; pas de migration garantie entre Intel et AMD
Cœurs	Prévoir 1 à 2 cœurs physiques pour l'hôte, plus Ceph (environ 1 cœur par OSD NVMe à charge)	Ceph et ZFS consomment du CPU (compression, checksums)

Un cluster mixte Intel/AMD impose un type de CPU virtuel générique (par exemple x86-64-v2-AES) et reste fragile en migration à chaud. Voir Créer une VM optimisée.

RAM et ECC¶

Base : au moins 2 Go pour l'OS et les services Proxmox VE, plus la RAM des invités.
ZFS et Ceph : compter environ 1 Go par To de stockage utilisé, en plus. Sur une installation ZFS, l'ARC est plafonné par défaut à 10 % de la RAM, au maximum 16 Go (valeur écrite dans /etc/modprobe.d/zfs.conf).
Ceph : chaque OSD vise par défaut 4 Go de mémoire (osd_memory_target). Un nœud avec 8 OSD réserve donc environ 32 Go à Ceph.
ECC obligatoire en production. ZFS et Ceph détectent la corruption sur disque, mais pas une erreur de bit en mémoire avant écriture. La documentation Proxmox ne l'impose pas ; le MSP l'exige pour tout nœud sous contrat.
Remplir les canaux mémoire de façon symétrique (mêmes barrettes, tous les canaux) : une configuration déséquilibrée réduit la bande passante.

Contrôleur disque : HBA ou RAID¶

Usage	Contrôleur	Commentaire
ZFS (boot ou données)	HBA, ou contrôleur LSI/Broadcom flashé en mode IT	ZFS doit parler directement aux disques
Ceph OSD	HBA ou NVMe direct	Un OSD = un disque physique vu tel quel
LVM / ext4 sur disque local	RAID matériel avec cache protégé (BBU ou flash)	Seul cas où le RAID matériel a du sens
SAN externe	Sans objet pour les données ; boot en miroir ZFS sur HBA	Voir SAN avec Proxmox

La documentation officielle est explicite : ZFS au-dessus d'un RAID matériel n'est pas supporté et peut entraîner une perte de données. Un « RAID0 par disque » ou un mode « JBOD » de contrôleur RAID n'est pas un HBA : le cache et la gestion d'erreurs du contrôleur restent actifs.

Disques¶

SSD entreprise avec PLP pour ZFS (ZIL/SLOG) et Ceph (WAL/DB) : les SSD grand public s'effondrent sur les écritures synchrones.
Endurance : viser au moins 1 DWPD pour du stockage VM, 3 DWPD pour un SLOG ou un DB/WAL Ceph.
Disques boot : deux SSD en miroir ZFS (RAID1), 240 Go ou plus, entreprise. Pas de clé USB, pas de carte SD, pas de module type BOSS en RAID matériel sous ZFS.
Ne pas mélanger boot et données sur les mêmes disques en Ceph HCI.

Réseau¶

Flux	Débit conseillé	Remarque
Management / GUI	1 Gb/s	Peut porter le lien Corosync secondaire
Corosync	1 Gb/s dédié, latence < 5 ms	Sensible à la gigue, pas à la bande passante
Ceph public + cluster	25 Gb/s recommandés, 10 Gb/s minimum	Deux ports en bond ou maillage complet
Migration	10 Gb/s ou plus	Peut partager un réseau de stockage
VM	Selon besoin, en bond LACP	Bridges VLAN-aware

Prévoir également une interface IPMI/iDRAC/iLO accessible au MSP : sans console hors bande, une mise à niveau majeure ou un nœud qui ne redémarre pas devient une intervention sur site.

flowchart LR
    A[Architecture livrée] --> B{Stockage}
    B -->|Ceph HCI 3+ nœuds| C[HBA ou NVMe direct<br/>SSD PLP<br/>2x25 Gb/s Ceph]
    B -->|ZFS répliqué 2 nœuds| D[HBA mode IT<br/>SSD PLP<br/>QDevice externe]
    B -->|SAN externe| E[Boot ZFS miroir<br/>HBA FC ou NIC iSCSI dédiées]
    B -->|Mono-nœud ZFS| F[HBA mode IT<br/>RAM ECC<br/>PBS séparé]

Recommandations MSP¶

Faire valider la nomenclature (BOM) par le MSP avant commande : contrôleur, modèle exact des SSD, NIC, version de firmware.
Nœuds identiques dans un cluster : même CPU, même RAM, mêmes disques. L'hétérogénéité se paie en migrations qui échouent et en équilibrage Ceph difficile.
Garder un disque de spare par modèle sur site pour les architectures ZFS et Ceph.
Mettre à jour BIOS, BMC et firmware des contrôleurs et NIC avant la mise en production, pas après.

Pièges vus en support

Contrôleur RAID en mode « RAID0 par disque » sous ZFS : erreurs de checksum inexpliquées, SMART invisible, remplacement de disque impossible sans reconfiguration du contrôleur.
SSD grand public sans PLP en Ceph : latences d'écriture de plusieurs dizaines de millisecondes, OSD signalés slow ops.
Démarrage sur un module RAID matériel puis ZFS pour les données : deux logiques de remplacement de disque à maîtriser.
IOMMU laissé sur « Auto » dans le BIOS : passthrough impossible alors que le CPU le supporte.
Corosync sur le même bond que Ceph : perte de quorum lors d'une reconstruction Ceph qui sature le lien.

Testez-vous¶

Pourquoi un mode « RAID0 par disque » n'est-il pas acceptable sous ZFS ?

Réponse

Le contrôleur garde son cache et sa propre gestion d'erreurs : ZFS ne voit pas les disques réels, ne lit pas SMART et ne maîtrise pas l'ordre des écritures. Il faut un HBA ou un contrôleur flashé en mode IT.
Un nœud de 256 Go de RAM est installé en ZFS. Quelle limite d'ARC est fixée par défaut ?

Réponse

10 % de la RAM, plafonné à 16 Go : ici 16 Go, dans /etc/modprobe.d/zfs.conf.
Quel lien réseau doit être dédié, même à 1 Gb/s, et pourquoi ?

Réponse

Corosync. Il consomme peu de débit mais exige une latence faible et stable ; un lien saturé par le stockage provoque des pertes de quorum.
Quels SSD utiliser pour un DB/WAL Ceph ?

Réponse

Des SSD ou NVMe entreprise avec protection contre les coupures de courant (PLP) et une endurance élevée (3 DWPD conseillés).