Meilleure configuration Proxmox pour homelab en 2026 : matériel, NIC, architecture de stockage et efficacité énergétique

Objectifs de conception pour un homelab 2026

Une « meilleure » configuration dépend du contexte. L’astuce est de choisir des contraintes qui vous empêchent d’aller dans le fossé.

Objectif 1 : latence prévisible, pas les meilleurs scores

La plupart des homelabs ne tombent pas parce qu’ils sont lents en absolu ; ils échouent parce que la latence devient imprévisible. ZFS qui resilver. Un NVMe grand public qui throttle thermiquement. Une carte i225 qui a une mauvaise journée. Une VM sur un « SSD rapide » qui se trouve en réalité sur un disque QLC sans espace réservé.

Objectif 2 : confinement des pannes

Concevez pour qu’une seule défaillance de disque, un seul coup de pompe PSU, ou un seul mauvais changement de configuration ne fasse pas tout tomber. C’est là que le boot mirroring, les pools séparés et une topologie réseau ennuyeuse rapportent.

Objectif 3 : efficacité énergétique sans sacrifier la fiabilité

Chasser les watts à l’arrêt peut vous pousser vers des plateformes de type laptop avec un I/O fragile. Vous voulez « suffisamment efficace » avec des drivers stables, ECC si possible, et un châssis qui refroidit sans hurler.

Objectif 4 : maintenabilité sous contrainte légère

Si vous ne pouvez pas remplacer un disque sans sortir toute la machine du rack, vous n’avez pas un serveur. Vous avez une boîte à énigmes.

Une citation (idée paraphrasée) : Gene Kim répète souvent que la fiabilité vient d’un feedback rapide et de petits changements, pas d’exploits héroïques.

Blague #1 : RAID n’est pas une sauvegarde ; c’est juste vos disques qui acceptent de tomber en panne selon un calendrier que vous n’avez pas choisi.

Faits intéressants et brève histoire (pourquoi les choses en sont là)

• Fait 1 : ZFS a été conçu chez Sun avec des checksums end-to-end comme caractéristique centrale, explicitement pour détecter la « corruption silencieuse » que les RAID traditionnels vous renverraient comme des données valides.
• Fait 2 : Les premiers SSD grand public rendaient TRIM optionnel ; les systèmes de fichiers modernes et le firmware des SSD supposent son existence pour des performances soutenues, surtout sur le NAND QLC.
• Fait 3 : Le 1GbE était « assez rapide » jusqu’à ce que la virtualisation rende le trafic est-ouest normal. La migration de VM, les sauvegardes et la réplication de stockage ont transformé les réseaux en nouveau bus disque.
• Fait 4 : iSCSI et NFS semblent simples jusqu’à ce que la latence apparaisse ; la plupart des tickets « le stockage est lent » sont en réalité des tickets « la gigue réseau est mauvaise » avec un meilleur emballage.
• Fait 5 : L’ARC de ZFS (cache en RAM) a fait de « plus de mémoire » une caractéristique de performance bien avant qu’il soit à la mode de l’appeler « accélération en mémoire ».
• Fait 6 : Le 2.5GbE grand public a décollé surtout parce que les fabricants de cartes mères voulaient un différenciateur sans payer pour des PHY 10GbE ni leur consommation.
• Fait 7 : NVMe n’a pas seulement augmenté la bande passante ; il a réduit la latence des commandes en supprimant les piles stockage héritées conçues pour des disques rotatifs.
• Fait 8 : La montée de Proxmox suit une tendance plus large : la commodité opérationnelle bat souvent la pureté théorique. « Une seule interface » compte quand on est fatigué.

Choix matériels qui ne gâcheront pas votre week-end

Point d’équilibre 2026 : un nœud performant ou trois nœuds plus petits

En 2026, vous pouvez vous permettre d’exécuter Proxmox dans deux formes sensées :

• Un nœud « gros » unique : le plus simple, le moins cher, moins de consommation, moins de points de défaillance. Inconvénient : la maintenance implique une interruption sauf si vous concevez autour.
• Cluster à trois nœuds : mieux pour expérimenter HA, la migration à chaud et les mises à jour progressives. Inconvénient : plus de consommation, plus de réseau, et vous finirez par déboguer le quorum à 1h du matin.

CPU : priorisez l’efficacité, les fonctionnalités de virtualisation et les lanes I/O

Vous voulez un CPU moderne avec :

• Virtualisation matérielle (AMD-V/Intel VT-x) et IOMMU (AMD-Vi/VT-d) pour le passthrough PCIe.
• Assez de lanes PCIe pour NVMe et une vraie NIC sans partage de lanes gênant.
• Faible consommation à l’arrêt. Beaucoup d’homelabs sont plus souvent à l’état idle qu’en pic.

Mon avis : favorisez une plateforme serveur-ish (ou workstation prosumer) qui supporte ECC et a des mises à jour firmware stables. Pas parce que l’ECC est magique, mais parce que les cartes qui le supportent tendent à prendre au sérieux le training mémoire et le routage PCIe.

RAM : achetez plus que vous pensez, puis limitez l’ARC intentionnellement

Pour une virtualisation avec ZFS, la RAM a trois rôles : mémoire invité, cache ARC, et métadonnées. Pour un nœud unique qui exécute quelques VMs et conteneurs, 64 Go est le palier « arrêtez de vous inquiéter ». Pour un nœud orienté stockage ou un cluster 3 nœuds avec réplication, 128 Go est confortable.

Ne laissez pas l’ARC dévorer la machine si vous exécutez des bases de données gourmandes. Limitez-le.

Carte mère et plateforme : l’ennuyeux gagne

Cherchez :

• IPMI ou équivalent de gestion à distance si possible. Ce n’est pas juste pour redémarrer ; c’est pour voir les erreurs hardware quand l’OS est absent.
• Deux slots PCIe utilisables (x8 électrique idéalement). Un pour une NIC, un pour un HBA ou un NVMe supplémentaire.
• Assez de slots M.2 avec dissipateurs qui touchent vraiment le disque.
• Options BIOS pour régler ASPM et les états C sans casser des périphériques.

Boîtier et refroidissement : vous voulez « silencieux en charge », pas « silencieux au repos »

Le flux d’air est une caractéristique de fiabilité. Un boîtier qui accepte des ventilateurs appropriés et qui dirige un flux vers les disques évitera que les SSD ne throttlent et les HDD ne cuisent. Et : les disques chauds meurent de façon ennuyeuse, ce qui est le pire genre de mort parce qu’on ne remarque pas avant qu’un scrub ne hurle.

Alimentation : l’efficacité et la tenue aux transitoires comptent

Achetez une alimentation de qualité. Pas pour « plus de watts », mais pour une alimentation stable sous charges transitoires. Les CPU modernes (et GPU) peuvent provoquer des variations de charge rapides. Une bonne unité 80 Plus Platinum économise parfois quelques watts au repos et se comporte mieux quand l’onduleur est instable.

NIC, commutation et gestion VLAN

Choisissez une NIC comme vous choisissez un système de fichiers : pour les drivers, pas pour l’esthétique

En 2026, le réseau homelab par défaut est 2.5GbE. C’est bon marché et suffisant pour un nœud unique avec stockage local. Mais si vous faites l’un de ces scénarios, passez au 10GbE :

• Proxmox Backup Server récupérant de gros backups chaque nuit
• Réplication ZFS entre nœuds
• Stockage partagé (NFS/iSCSI) ou Ceph
• Migrations fréquentes de VM

10GbE : SFP+ reste la meilleure option

SFP+ dispose de l’écosystème : câbles DAC, faible consommation et moins de « PHY mystères ». Le 10GbE RJ45 fonctionne, mais il chauffe plus, consomme en général plus au repos, et vous pouvez involontairement construire un radiateur d’espace qui exécute aussi Linux.

Topologie recommandée

• Gestion : un VLAN (ou port physiquement séparé) pour l’interface Proxmox, IPMI, et les switches.
• VM/Conteneur : un ou plusieurs VLAN selon les frontières de confiance.
• Stockage : si vous faites réplication ou stockage partagé, pensez à un VLAN et une NIC dédiés.

Configuration de bridge : restez simple

Le bridge Linux en mode VLAN-aware fonctionne bien. Évitez les astuces genre ponts imbriqués sauf si vous aimez déboguer des tempêtes de broadcast générées par votre propre optimisme.

Blague #2 : Le réseau le plus rapide du monde ne réparera pas un VLAN tagué au mauvais endroit. Les paquets ne lisent pas vos intentions.

Agencement SSD/HDD : pools ZFS, vdevs spéciaux et modes de défaillance

Commencez par la charge de travail, pas par le type de disque

Votre homelab a probablement trois motifs de stockage :

• Démarrage VM et I/O aléatoire : sensible à la latence, adore les mirrors NVMe.
• Média / stockage en masse : séquentiel, coût par To faible, parfait sur RAIDZ.
• Sauvegardes : rafales d’écritures, rétention importante, veut une capacité bon marché et des temps de restauration prévisibles.

Agencement de base recommandé (nœud unique)

• Boot : 2 × petit SSD (SATA ou NVMe) en miroir pour Proxmox OS. Séparez-le. Traitez-le comme remplaçable.
• Pool VM : 2 × NVMe en miroir (ou mirror 3 voies si vous tenez moins à vous aimer qu’à la disponibilité). C’est ici que résident les disques VM.
• Pool bulk : 4–8 × HDD en RAIDZ2 (ou mirrors si vous voulez IOPS plutôt que To). C’est média, archives et tout ce qui n’est pas sensible à la latence.
• Destination sauvegarde : idéalement une machine séparée (PBS) avec son propre pool. Si c’est local, utilisez un dataset séparé avec quotas et rétentions sensées.

Agencement de base recommandé (cluster trois nœuds)

Deux chemins sensés :

• ZFS local + réplication : chaque nœud a un mirror NVMe pour les VMs ; répliquez les VMs critiques vers un autre nœud ; utilisez PBS pour les sauvegardes. Simple et efficace.
• Ceph : seulement si vous voulez apprendre Ceph et pouvez tolérer son overhead. Puissant, mais il se paye en RAM, réseau et temps.

recordsize, volblocksize et pourquoi les valeurs par défaut ne sont pas toujours vos amies

Pour les disques VM stockés comme zvols, volblocksize compte. Pour les datasets, recordsize compte. Ne tunez pas au hasard. Tunez quand vous pouvez décrire le pattern I/O en une phrase.

• zvol VM général : 16K est un bon compromis pour beaucoup de charges.
• Bases de données : souvent avantageuses avec de plus petits blocs, mais testez.
• Datasets média : recordsize 1M est courant parce que les lectures sont larges et séquentielles.

SLOG et L2ARC : cessez d’acheter des pièces avant d’avoir un problème

La plupart des homelabs n’ont pas besoin d’un SLOG. Si vous ne faites pas d’écritures sync via NFS/iSCSI vers ZFS, un SLOG est surtout un talisman coûteux.

L2ARC (cache secondaire sur SSD) peut aider les lectures lourdes qui ne tiennent pas en RAM, mais il consomme la RAM pour les métadonnées. Ce n’est pas gratuit. Si vous pouvez acheter plus de RAM à la place, faites-le d’abord.

vdevs spéciaux : utiles, mais tranchants

Un special vdev pour les métadonnées et petits blocs peut rendre les pools HDD réactifs. Mais si vous perdez le special vdev, vous perdez le pool. Ce n’est pas du drame ; c’est la conception. Si vous utilisez des special vdevs, mettez-les en miroir et surveillez-les comme s’ils étaient les joyaux de la couronne.

Sélection SSD : évitez les promesses « rapides et bon marché »

Pour les pools VM, priorisez le comportement d’écriture soutenue et l’endurance. Un disque qui donne de bons benchmarks pendant 30 secondes puis s’effondre n’est pas « rapide » ; il est « brièvement enthousiaste ». Cherchez :

• cache DRAM ou au moins une bonne implémentation HMB
• bonnes performances d’écriture soutenue (pas seulement des rafales SLC)
• protection contre perte de puissance si vous êtes sérieux (ou au moins un UPS plus des réglages conservateurs)

Sélection HDD : planifier la capacité, c’est planifier la défaillance

Pour RAIDZ2, la capacité est agréable jusqu’à ce que les temps de resilver s’allongent. Les gros disques signifient de longues fenêtres de reconstruction. Planifiez une seconde défaillance pendant la reconstruction. C’est pourquoi RAIDZ2 existe.

Efficacité énergétique : où vont vraiment les watts

La consommation au repos est la facture que vous payez chaque heure

La plupart des homelabs sont au repos 80–95 % du temps. Investissez pour réduire la consommation au repos :

• Privilégiez des CPU et cartes mères efficaces avec un bon comportement au repos.
• Désactivez les contrôleurs inutilisés dans le BIOS (SATA inutilisé, contrôleurs RGB, audio inutilisé).
• Utilisez moins de gros ventilateurs à bas régime plutôt que beaucoup de petits ventilateurs qui hurlent.
• Choisissez SFP+ plutôt que 10GBASE-T si les watts au repos comptent.

Les disques rotatifs sont honnêtes sur la consommation

Les HDD consomment de l’énergie de façon stable et génèrent de la chaleur. Si vous visez une faible consommation, envisagez moins de disques avec plus grande capacité, mais gardez à l’esprit la réalité des fenêtres de reconstruction. Si vous visez le silence, montez correctement les disques et maintenez un flux d’air régulier.

Dimensionnement PSU : ne pas surdimensionner massivement

Une PSU 1200W qui tourne à 60W au repos peut être moins efficace qu’une unité 450–650W dans sa zone de rendement optimal. Achetez de la qualité, dimensionnée pour votre pic réaliste plus une marge.

Tâches pratiques : commandes, sorties et décisions

Voici des vérifications réelles à exécuter sur un hôte Proxmox. Chaque étape inclut ce que la sortie signifie et la décision à prendre. Faites-les dans cet ordre lors de la construction, et encore quand quelque chose paraît « off ».

Task 1: Confirm virtualization extensions and IOMMU

cr0x@server:~$ lscpu | egrep -i 'Model name|Virtualization|Flags'
Model name:                           AMD Ryzen 9 7900
Virtualization:                       AMD-V
Flags:                                ... svm ...

Sens : Vous voulez svm (AMD) ou vmx (Intel). Si Virtualization est « none », c’est une option BIOS ou un problème de plateforme.

Décision : Si absent, activez SVM/VT-x et IOMMU/VT-d dans le BIOS avant d’avancer.

Task 2: Check IOMMU groups (passthrough readiness)

cr0x@server:~$ find /sys/kernel/iommu_groups/ -type l | head
/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/2/devices/0000:00:02.0

Sens : Des groups existent ; les devices sont isolés au moins en partie. Si le répertoire n’existe pas, IOMMU n’est pas activé.

Décision : Si vous avez besoin de passthrough GPU/NIC/HBA, validez la séparation des groups maintenant, avant d’acheter une carte qui regroupe tout.

Task 3: Inventory storage devices and link speed

cr0x@server:~$ lsblk -o NAME,MODEL,SIZE,ROTA,TYPE,TRAN
NAME        MODEL                    SIZE ROTA TYPE TRAN
nvme0n1     Samsung SSD 990 PRO      1.8T    0 disk nvme
nvme1n1     Samsung SSD 990 PRO      1.8T    0 disk nvme
sda         ST12000VN0008-2YS101    10.9T    1 disk sata
sdb         ST12000VN0008-2YS101    10.9T    1 disk sata

Sens : ROTA 0 = SSD/NVMe, 1 = HDD. TRAN indique le bus. Si votre « NVMe » apparaît comme SATA, quelque chose cloche.

Décision : Confirmez que vous avez bien les médias prévus. Cela détecte des M.2 mal positionnés ou fonctionnant sur moins de lanes.

Task 4: Check NVMe health, temperature, and endurance counters

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep 'temperature|percentage_used|data_units_written'
temperature                             : 41 C
percentage_used                         : 1%
data_units_written                      : 218,445

Sens : Température sous contrôle, usure faible. Températures élevées ou usure rapidement croissante signifient throttling ou écritures excessives (souvent swap, logs ou mauvais réglages de cache).

Décision : Si les températures sont hautes, améliorez le flux d’air ou ajoutez des dissipateurs. Si l’usure monte vite, déplacez les charges d’écriture ou revoyez les paramètres ZFS et logging.

Task 5: Verify NIC driver and link state

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
enp3s0           UP             3c:ec:ef:12:34:56
enp4s0           UP             3c:ec:ef:65:43:21

Sens : Les interfaces sont UP. Vérifiez maintenant la vitesse/duplex.

Décision : Si un port est DOWN et doit transporter du trafic VM, arrêtez-vous et corrigez-le avant d’accuser le stockage.

Task 6: Check negotiated link speed (spot a 10G link running at 1G)

cr0x@server:~$ sudo ethtool enp4s0 | egrep 'Speed|Duplex|Link detected'
Speed: 10000Mb/s
Duplex: Full
Link detected: yes

Sens : Vous êtes bien en 10GbE. Si vous voyez 1000Mb/s, il y a un problème de câble/transceiver/port switch.

Décision : Réglez la couche physique d’abord. Il n’existe pas de réglage logiciel qui rende un cuivre défaillant performant.

Task 7: Validate VLAN-aware bridges in Proxmox networking

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto enp4s0
iface enp4s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.10.20/24
        gateway 192.168.10.1
        bridge-ports enp4s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes

Sens : Un bridge propre avec VLAN-awareness activée. Si vous faites du trunking, c’est la forme souhaitée.

Décision : Si vous voyez des bridges imbriqués ou des hacks post-up aléatoires, simplifiez. La stabilité bat la sophistication.

Task 8: Confirm ZFS pool topology (are you really mirrored?)

cr0x@server:~$ sudo zpool status
  pool: fast
 state: ONLINE
config:

        NAME          STATE     READ WRITE CKSUM
        fast          ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            nvme0n1p3 ONLINE       0     0     0
            nvme1n1p3 ONLINE       0     0     0

errors: No known data errors

Sens : Le mirror est sain. Si vous voyez un vdev disque unique, vous êtes à une défaillance d’une mauvaise journée.

Décision : Si la topologie est incorrecte, corrigez-la avant d’ajouter des données. Migrer après est douloureux et implique généralement une interruption.

Task 9: Check ashift (did you align for 4K sectors?)

cr0x@server:~$ sudo zdb -C fast | egrep 'ashift'
            ashift: 12

Sens : ashift=12 signifie secteurs 4K, correct pour la plupart des SSD et HDD modernes.

Décision : Si vous avez construit un pool avec ashift=9, recréez le pool maintenant. Ce n’est pas un réglage qu’on change plus tard ; c’est un choix de vie.

Task 10: Check ZFS dataset properties for VM storage

cr0x@server:~$ sudo zfs get -o name,property,value compression,atime,recordsize fast
NAME  PROPERTY     VALUE
fast  compression  zstd
fast  atime        off
fast  recordsize   128K

Sens : Compression activée (bien), atime off (bon pour beaucoup de charges). recordsize concerne les datasets, pas les zvols.

Décision : Gardez la compression activée sauf raison spécifique. Si vous stockez des images VM comme fichiers dans un dataset, adaptez recordsize selon l’I/O.

Task 11: Check zvol blocksize for a VM disk

cr0x@server:~$ sudo zfs get -o name,property,value volblocksize fast/vm-101-disk-0
NAME                PROPERTY      VALUE
fast/vm-101-disk-0   volblocksize 16K

Sens : Raisonnable pour des disques VM généralistes.

Décision : Ne changez pas le volblocksize après coup sauf si vous êtes prêt à recréer le zvol. Planifiez-le tôt pour des charges spéciales.

Task 12: Watch real-time I/O latency (find storage pain fast)

cr0x@server:~$ sudo iostat -x 1 5
Device            r/s   w/s  r_await  w_await  aqu-sz  %util
nvme0n1         120.0  85.0     1.2     2.0    0.30   35.0
nvme1n1         118.0  83.0     1.1     1.9    0.28   33.0
sda               2.0  45.0    12.0    28.0    1.40   90.0

Sens : Latence NVMe basse. Les écritures HDD ont des await plus élevés et une utilisation importante, ce qui peut être acceptable ou constituer le goulot.

Décision : Si les disques VM résident sur HDD et que w_await est élevé, déplacez-les sur NVMe ou repensez le pool.

Task 13: Check ZFS ARC size and memory pressure

cr0x@server:~$ arc_summary | egrep 'ARC Size|ARC Max Size|Memory Throttle'
ARC Size:                               28.3 GiB
ARC Max Size:                           48.0 GiB
Memory Throttle Count:                  0

Sens : L’ARC est actif mais ne bride pas. Si le compteur de throttle augmente, vous avez une pression mémoire.

Décision : Si la pression mémoire est réelle, ajoutez de la RAM ou limitez l’ARC. Ne « optimisez » pas en affamant les invités.

Task 14: Identify top CPU consumers and steal time (VM scheduling pain)

cr0x@server:~$ top -b -n 1 | head -20
top - 11:22:19 up 12 days,  3:10,  1 user,  load average: 5.21, 4.88, 4.31
Tasks: 312 total,   2 running, 310 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.2 us,  4.1 sy,  0.0 ni, 77.1 id,  0.2 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem : 128000.0 total,   8200.0 free,  60200.0 used,  59600.0 buff/cache

Sens : Un wa élevé suggère une attente I/O. Un st élevé dans un environnement VM peut indiquer une contention d’hôte ; sur du bare metal il devrait être proche de zéro.

Décision : Si wa est élevé, passez aux vérifications de stockage. Si la charge est élevée mais le CPU idle, suspectez l’I/O ou une contention de locks.

Task 15: Check Proxmox storage configuration sanity

cr0x@server:~$ pvesm status
Name        Type     Status    Total     Used    Available
local       dir      active    98.0G     7.2G       90.8G
fast        zfspool  active     1.7T   420.0G        1.3T
bulk        zfspool  active    43.5T    12.1T       31.4T

Sens : Vous voyez où l’espace est utilisé. Si les disques VM atterrissent sur local (root), vous allez bientôt remplir votre disque de boot.

Décision : Assurez-vous que les images VM et les rootfs des conteneurs vivent sur le bon pool, pas sur le disque OS.

Task 16: Validate backup health (PBS or vzdump results)

cr0x@server:~$ ls -lh /var/lib/vz/dump/ | tail -5
-rw-r----- 1 root root  22G Dec 28 02:10 vzdump-qemu-101-2025_12_28-02_00_01.vma.zst
-rw-r----- 1 root root 1.2G Dec 28 02:14 vzdump-lxc-103-2025_12_28-02_12_10.tar.zst

Sens : Les sauvegardes existent et sont récentes. La taille semble plausible. Si vous attendiez 200 Go et obtenez 2 Go, vous avez sauvegardé la mauvaise chose (ou la compression a caché vos torts—rare).

Décision : Testez une restauration. Un backup réussi sans test de restauration n’est qu’un journal optimiste.

Feuille de diagnostic rapide (trouver le goulot d’étranglement vite)

Voici l’ordre qui fait gagner du temps. Le but est d’arrêter de deviner et de commencer à réduire le champ.

Première étape : décider s’il s’agit de contention CPU, latence stockage, ou réseau

• Suspicion CPU : utilisation élevée du CPU hôte, symptômes « ready time » des VM, UI lente sous charge.
• Suspicion stockage : attente I/O élevée, démarrage VM long, gel pendant les backups, corrélation avec scrub/resilver ZFS.
• Suspicion réseau : copies de fichiers inconsistantes, réplication lente, pics de latence, comportement « rapide parfois ».

Deuxième étape : vérifier la couche physique et les débits négociés

Avant de toucher aux tunings ZFS, confirmez que votre NIC ne négocie pas en 1GbE, n’a pas de pertes de paquets, ou n’est pas en flapping.

Troisième étape : isoler la charge

Identifiez quelle VM/conteneur cause le problème. Dans les homelabs, c’est souvent :

• un client torrent mal configuré qui thrash la métadonnée
• une vacuum/compaction de base de données sur HDD
• un job de backup qui sature le pool en heure de pointe
• une situation de surallocation RAM provoquant des tempêtes de swap

Quatrième étape : chercher du travail de maintenance ZFS

Scrubs, resilvers et suppression massive de snapshots peuvent transformer un système sain en un système saccadé. C’est normal. La solution est de planifier et dimensionner la capacité, pas de chercher un coupable.

Cinquième étape : vérifier les thermiques et le throttling

Le throttling thermique ressemble à de la « lenteur aléatoire ». Ce n’est pas aléatoire. C’est de la physique.

Trois mini-histoires d’entreprise dont tirer des leçons

Incident causé par une mauvaise hypothèse : « Les mirrors sont rapides, donc tout mirror suffit »

Une entreprise moyenne exploitait un cluster de virtualisation avec des SSD en miroir par hôte. Ils ont supposé qu’« un mirror SSD » signifiait « assez rapide pour tout ». C’était vrai—jusqu’à ce que ça ne le soit plus.

Le problème a commencé par des pauses occasionnelles de VM pendant la fenêtre de sauvegarde nocturne. Rien de dramatique. Puis une VM base de données a commencé à timeout en heures ouvrées, et l’équipe a chassé la configuration DB parce que c’est ce que font les gens quand ils sont effrayés et caféinés.

La vraie cause : le mirror était composé de drives consumer QLC avec petits caches SLC. Pendant les sauvegardes et le churn de snapshots, les écritures soutenues ont dépassé le cache et les drives sont tombés d’un cliff de performance. La latence a explosé. L’hyperviseur avait l’air coupable parce que c’était lui qui attendait.

Ils avaient du monitoring, mais il mesurait le throughput, pas les percentiles de latence. Les graphiques semblaient « corrects » pendant que les utilisateurs souffraient. La correction a été ennuyeuse : remplacer les disques par des modèles à écritures soutenues stables, et déplacer la mise en scène des backups hors du pool principal VM.

Leçon : « mirror SSD » n’est pas une garantie de performance. Le comportement d’écriture soutenue compte plus que l’étiquette.

Optimisation qui a mal tourné : « Ajoutons L2ARC pour accélérer les lectures »

Une autre équipe avait un grand pool ZFS et voulait accélérer les lectures d’un workload fichier. Ils ont ajouté un gros SSD L2ARC et ont immédiatement célébré car les benchmarks s’amélioraient pendant une semaine.

Puis le système a commencé à se comporter étrangement : pressions mémoire, redémarrages de services occasionnels, et baisses de performances ressemblant à des pauses GC. Ils ont accusé le kernel. Puis l’application. Puis chacun s’est accusé mutuellement, ce qui est la voie d’escalade traditionnelle.

La cause était subtile mais classique : l’overhead des métadonnées L2ARC a consommé de la RAM, réduisant l’efficacité de l’ARC et augmentant la pression sur le système. Le workload n’était pas assez « read-hot » pour justifier un L2ARC de cette taille, et le churn du cache a empiré les choses. Ils avaient effectivement échangé un cache RAM prévisible contre un cache SSD compliqué mal adapté au pattern d’accès.

La correction a été de supprimer le L2ARC surdimensionné, d’ajouter de la RAM et d’optimiser les patterns d’accès de l’application. Ils ont réintroduit plus tard un L2ARC plus petit avec des limites strictes après avoir mesuré les hit ratios réels.

Leçon : Ajouter du cache peut réduire la performance si cela vole la ressource dont vous aviez réellement besoin (RAM) et ne correspond pas au workload.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « Nous testions les restaurations chaque mois »

Une troisième organisation utilisait Proxmox avec ZFS et un système de backup séparé. Rien de fancy. Ils avaient une habitude presque démodée : chaque mois, ils choisissaient une VM au hasard, faisaient une restauration complète dans un réseau isolé, puis vérifiaient la fonctionnalité applicative.

Un jour, une mise à jour firmware d’un contrôleur de stockage a introduit des resets intermittents sous I/O lourde. Le premier signe n’a pas été un hôte mort ; c’était des disques VM corrompus sur un nœud après un reset particulièrement vil pendant des écritures. ZFS a fait ce qu’il a pu, mais quelques filesystems invités n’étaient pas propres.

Parce qu’ils avaient répété des restaurations, la réponse a été calme. Ils ont mis le nœud en quarantaine, restauré les VMs affectées depuis des backups connus bons, et maintenu l’activité pendant que le fournisseur corrigeait le firmware.

Pas d’héroïsme. Pas de « ça ira ». Juste une récupération pratiquée.

Leçon : Tester les restaurations est un intérêt composé opérationnel. C’est ennuyeux jusqu’au moment où c’est la seule chose qui compte.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: VM boots are slow, but throughput benchmarks look fine

Cause racine : pics de latence causés par exhaustion du cache SSD, pool presque plein, ou activité maintenance ZFS (scrub/resilver/suppression de snapshots).

Correction : gardez les pools ZFS sous une utilisation confortable (ne vivez pas à 90 %), planifiez les scrubs, déplacez les jobs d’écriture hors du pool VM, et utilisez des SSD avec des écritures soutenues stables.

2) Symptom: Network copies plateau at ~110 MB/s on a “10GbE” setup

Cause racine : lien négocié à 1GbE, transceiver/câble défectueux, ou port switch mal configuré.

Correction : vérifiez avec ethtool, changez DAC/transceiver, confirmez la config du switch. Ne tunez pas les buffers TCP pour corriger un problème physique.

3) Symptom: Proxmox host randomly freezes under load

Cause racine : pression mémoire et tempêtes de swap, NVMe thermal throttling, ou alimentation instable.

Correction : vérifiez dmesg pour OOM et erreurs NVMe, ajoutez de la RAM, limitez l’ARC, améliorez le refroidissement, et utilisez une PSU + UPS de qualité.

4) Symptom: ZFS scrub takes forever and system feels sluggish

Cause racine : pool majoritairement HDD avec forte utilisation, ou contention scrub/resilver avec workloads actifs.

Correction : lancez les scrubs en heures creuses, envisagez des mirrors pour les usages IOPS-intensifs, et gardez de la capacité libre. Si vous ne pouvez pas scruber confortablement, vous êtes surchargé.

5) Symptom: Backups “succeed” but restores fail or are incomplete

Cause racine : sauvegarder le mauvais stockage, exclure des volumes montés, ou corruption silencieuse non détectée faute de tests de restauration.

Correction : testez régulièrement les restaurations, vérifiez que le backup inclut bien les bons disques, et stockez les sauvegardes sur du matériel séparé si possible.

6) Symptom: Ceph cluster works until one node is rebooted, then everything crawls

Cause racine : réseau sous-dimensionné, OSDs sur disques de qualité mixte, ou RAM/CPU insuffisants pour l’overhead Ceph.

Correction : ne courez pas Ceph sur du hardware « spare ». Pour HA, faites-le correctement : réseau rapide, disques homogènes, et mémoire suffisante.

7) Symptom: PCIe passthrough is flaky or devices disappear after reboot

Cause racine : mauvais grouping IOMMU, quirks BIOS, partage de lanes, ou problèmes de gestion d’alimentation.

Correction : vérifiez les IOMMU groups, mettez à jour le BIOS, évitez les risers, et désactivez les réglages ASPM problématiques pour les périphériques concernés.

Listes de contrôle / plan étape par étape

Plan étape par étape : nœud unique « homelab sérieux »

1. Choisir la plateforme : carte mère stable, ECC si possible, au moins deux slots PCIe et deux slots M.2.
2. Choisir la mémoire : 64 Go minimum, 128 Go si vous exécutez beaucoup de VMs, ZFS intensif, ou voulez de la marge.
3. Réseau : NIC SFP+ 10GbE si vous répliquez ou exécutez un serveur de sauvegarde ; sinon 2.5GbE peut suffire.
4. Boot mirror : deux petits SSD en miroir ; gardez l’OS séparé du pool VM.
5. Pool VM : NVMe en miroir, priorisez l’endurance et les écritures soutenues.
6. Pool bulk : RAIDZ2 pour la capacité ; mirrors si vous avez besoin d’IOPS plutôt que To.
7. Sauvegardes : PBS séparé si vous tenez à vos données. Sinon, au moins des datasets séparés et des quotas.
8. Monitoring : suivez la latence (disk await), SMART/usure NVMe, l’état des pools ZFS, et la vitesse des liens. Le débit seul ment.
9. Répétition restauration : restauration mensuelle d’une VM aléatoire dans un VLAN isolé.

Plan étape par étape : cluster trois nœuds pour apprendre le HA

1. Standardiser les nœuds : mêmes NIC, mêmes modèles de disques si possible, mêmes réglages BIOS.
2. Réseau en premier : commutation 10GbE, plan VLAN propre, VLAN dédié stockage/réplication si possible.
3. Décider du modèle de stockage : ZFS local + réplication (recommandé) ou Ceph (si vous voulez gérer Ceph).
4. Conscience du quorum : planifiez le comportement quand un nœud est hors ligne. Ajoutez un qdevice si nécessaire pour des cas à deux nœuds, mais idéalement exécutez trois nœuds réels.
5. Les sauvegardes restent séparées : la réplication n’est pas une sauvegarde. PBS compte toujours.
6. Discipline de mise à jour : mises à jour rolling, un nœud à la fois, avec plan de rollback.

Checklist de construction : ne les sautez pas

• BIOS mis à jour vers une release stable (pas nécessairement la plus récente).
• Virtualisation + IOMMU activés.
• Test mémoire overnight si vous pouvez tolérer le temps.
• Températures NVMe vérifiées sous charge ; pas de throttling.
• Vitesse des liens vérifiée sur l’hôte et le switch.
• Topologie du pool ZFS vérifiée avant d’y déposer des données.
• Horaire de scrub défini et premier scrub observé.
• Sauvegardes configurées et une restauration test effectuée.

FAQ

1) Dois-je exécuter Proxmox sur ZFS ou ext4/LVM ?

Si vous tenez aux snapshots, à l’intégrité et à des opérations prévisibles, utilisez ZFS. Si vous avez besoin du setup le plus simple possible et acceptez moins de garde-fous, ext4/LVM convient. Pour la plupart des homelabs sérieux : ZFS.

2) Miroir ou RAIDZ pour le stockage VM ?

Miroirs pour le stockage VM sauf si votre charge est majoritairement séquentielle et tolérante à la latence. Les mirrors donnent de meilleures IOPS et un comportement de rebuild plus simple. RAIDZ est idéal pour la capacité bulk et le média.

3) Ai-je besoin de mémoire ECC ?

Ce n’est pas obligatoire, mais c’est une bonne idée si vous utilisez ZFS et tenez à l’intégrité. Plus important, les plateformes ECC-capables sont souvent construites moins comme des jouets. Si l’écart de prix est faible, prenez ECC.

4) Le 2.5GbE suffit-il en 2026 ?

Pour un nœud unique avec stockage local, oui. Pour la réplication, le stockage partagé ou des sauvegardes fréquentes, vous le sentirez. 10GbE (SFP+) est le saut propre.

5) Ai-je besoin d’un SLOG pour ZFS ?

Seulement si vous servez des écritures sync (souvent NFS/iSCSI avec sync activé) et que vous avez mesuré que le chemin ZIL est le goulot. Sinon, n’achetez pas un SLOG pour vous sentir productif.

6) Puis-je exécuter Ceph sur trois petits nœuds ?

Vous le pouvez, et vous apprendrez beaucoup—principalement pourquoi Ceph de production aime les réseaux rapides, beaucoup de RAM et des disques cohérents. Pour « je veux que mes services soient ennuyeux », ZFS local + réplication est généralement mieux.

7) Quelle est la meilleure configuration de disque de boot ?

Deux petits SSD en miroir. Gardez l’OS hors de votre drame principal de stockage. Si le mirror de boot meurt, ce doit être une gêne, pas un événement existentiel.

8) Jusqu’à quel niveau puis-je remplir un pool ZFS ?

Ne le traitez pas comme une valise sur laquelle vous vous asseyez pour la fermer. À mesure que les pools se remplissent, la fragmentation et la douleur de performance augmentent. Gardez de l’espace libre significatif, surtout sur les pools VM.

9) Dois-je utiliser des special vdevs sur mon pool HDD ?

Uniquement si vous comprenez le domaine de défaillance : perdre le special vdev entraîne la perte du pool. Si vous le faites, mirrorisez-le et surveillez-le agressivement.

10) Quelle est l’approche de sauvegarde la plus simple et fiable ?

Proxmox Backup Server sur du matériel séparé, sauvegardes nocturnes avec rétentions sensées, plus une copie périodique hors site. Ensuite, testez les restaurations. Cette dernière partie est l’essentiel.

Conclusion : prochaines étapes pratiques

Construisez pour une latence prévisible, une récupération ennuyeuse et une consommation que vous pouvez vivre avec. Le homelab gagnant en 2026 n’est pas celui avec le plus de cœurs ; c’est celui qui ne vous surprend pas.

1. Décidez votre architecture : un nœud solide ou trois nœuds avec réplication.
2. Achetez la NIC et le switch en tenant compte de la stabilité des drivers et de la vérification des débits.
3. Concevez le stockage en séparant les préoccupations : boot mirror, pool VM rapide, pool bulk, et sauvegardes hors hôte si possible.
4. Exécutez les tâches en ligne de commande ci-dessus dès le premier jour. Sauvegardez les sorties. Elles deviennent votre base.
5. Planifiez scrubs, sauvegardes et un test de restauration. Mettez-les au calendrier comme le loyer.