Choisir sa topologie : mirror, RAIDZ1/2/3, dRAID¶
Pour des disques de VM, la réponse par défaut est un pool de mirrors (RAID10) ; RAIDZ2 se réserve aux volumes de données froides et aux datastores de sauvegarde, dRAID aux très grands pools. Cette règle découle d'un fait simple : un vdev RAIDZ offre à peu près les IOPS aléatoires d'un seul disque.
Les topologies comparées¶
| Topologie | Disques min. par vdev | Pannes tolérées par vdev | Capacité (n disques) | IOPS aléatoires d'un vdev | Resilver | Usage typique |
|---|---|---|---|---|---|---|
| Mirror 2 voies | 2 | 1 | n / 2 | Écriture : 1 disque. Lecture : 2 disques | Rapide (copie d'un disque) | VM, bases de données |
| Mirror 3 voies | 3 | 2 | n / 3 | Écriture : 1 disque. Lecture : 3 disques | Rapide | VM critiques, gros disques |
| RAIDZ1 | 3 | 1 | n - 1 | ≈ 1 disque | Lent, lit tout le vdev | Petits SSD, données non critiques |
| RAIDZ2 | 4 | 2 | n - 2 | ≈ 1 disque | Lent | Fichiers, archives, datastore PBS |
| RAIDZ3 | 5 | 3 | n - 3 | ≈ 1 disque | Lent | Très gros HDD, archivage |
| dRAID1/2/3 | 2 / 3 / 4 (doc PVE) | 1 / 2 / 3 + spares distribués | Selon la géométrie | Comparable à RAIDZ | Très rapide vers les spares distribués | Pools de plus de 10 à 15 disques |
Les performances d'un pool s'additionnent par vdev : un pool de 4 mirrors (8 disques) offre environ 4 fois les IOPS en écriture d'un disque ; un RAIDZ2 de 8 disques, environ 1 fois.
flowchart TB
Q1{"Usage principal ?"} -- "Disques de VM, bases" --> M["Mirrors (RAID10)<br/>2 voies, 3 voies si gros disques"]
Q1 -- "Fichiers, archives, datastore PBS" --> Q2{"Combien de disques ?"}
Q2 -- "4 à 10" --> Z2["RAIDZ2, un ou plusieurs vdevs"]
Q2 -- "Plus de 10 à 15" --> Q3{"Resilver rapide indispensable ?"}
Q3 -- oui --> DR["dRAID2 avec spare distribué<br/>(validation MSP)"]
Q3 -- non --> Z2N["Plusieurs vdevs RAIDZ2<br/>de 6 à 10 disques"]Notions clés¶
Largeur de vdev. Restez entre 4 et 10 disques par vdev RAIDZ. Plus large, le resilver s'allonge et le padding des petits blocs augmente.
RAIDZ et zvols. Les disques de VM sont des zvols à volblocksize fixe (16 Kio par défaut avec OpenZFS 2.2 et suivants). En RAIDZ, chaque bloc est complété pour respecter la géométrie : un RAIDZ2 de 6 disques n'offre pas 4/6 de la capacité brute pour des zvols. Le calcul exact est sur la page Sizing ZFS.
dRAID. Les spares sont distribués sur tous les disques : la reconstruction écrit sur tout le vdev en parallèle, d'où sa rapidité. En contrepartie, la largeur de bande est fixe (8 disques de données par défaut) : avec des secteurs de 4 Kio, l'allocation minimale est de 32 Kio, ce qui pénalise les petits blocs et la compression. La documentation Proxmox réserve dRAID aux pools de plus de 10 à 15 disques. La GUI exige un disque de plus que le minimum, car elle prévoit un spare.
Ce qui se change après coup.
| Opération | Possible ? |
|---|---|
Ajouter un vdev au pool (zpool add) |
Oui, irréversible si le pool contient un vdev RAIDZ |
Ajouter un disque à un mirror (2 → 3 voies, zpool attach) |
Oui |
| Ajouter un disque à un vdev RAIDZ (extension, OpenZFS 2.3, PVE 9) | Oui, voir Agrandir un pool |
| Passer de RAIDZ1 à RAIDZ2, ou de RAIDZ à mirror | Non : recréer le pool et restaurer |
Changer l'ashift |
Non |
Recommandations MSP¶
| Architecture livrée | Pool système | Pool de VM recommandé |
|---|---|---|
| Mono-nœud ZFS | rpool en mirror 2 SSD | Mirrors de SSD entreprise (RAID10) |
| ZFS répliqué 2 nœuds + QDevice | rpool en mirror sur chaque nœud | Même pool tank en mirrors, même nom sur les deux nœuds |
| PBS local | rpool en mirror | RAIDZ2 de HDD + special vdev SSD en mirror, ou RAIDZ2/mirrors de SSD |
- RAIDZ1 est exclu avec des disques de 8 To ou plus : une seconde panne pendant un resilver de plus de 24 h détruit le pool.
- Tous les disques d'un vdev ont la même taille et la même technologie. Pas de disques SMR.
- Prévoyez un disque de rechange sur site plutôt qu'un hot spare permanent dans un petit pool.
- Toute topologie hors de ces standards (dRAID, RAIDZ3, special vdev) se valide avec l'avant-vente MSP.
Pièges vus en support
- RAIDZ2 de 6 HDD pour 40 VM : latences de plusieurs dizaines de millisecondes dès que les sauvegardes démarrent. Un vdev RAIDZ ne fait pas plus d'IOPS qu'un disque.
- Capacité attendue « 4 disques sur 6 » en RAIDZ2 et pool plein bien avant : le padding des zvols n'avait pas été compté.
- Un disque ajouté seul avec
zpool adddans un pool de mirrors : le pool dépend désormais d'un disque sans redondance. - RAIDZ1 de gros HDD choisi pour la capacité : perte du pool lors du resilver après la deuxième panne.
Testez-vous¶
-
Vous avez 8 SSD pour héberger 30 VM Windows. Quelle topologie proposez-vous et pourquoi ?
Réponse
4 vdevs mirror de 2 SSD (RAID10). On obtient environ 4 fois les IOPS en écriture d'un SSD et 8 fois en lecture, contre environ 1 fois pour un RAIDZ2 de 8 disques. La capacité est de 50 % du brut.
-
Combien de disques peut perdre un pool composé de deux vdevs RAIDZ2 de 6 disques ?
Réponse
Jusqu'à 2 disques par vdev, soit 4 au total si les pannes se répartissent sur les deux vdevs. Une troisième panne dans le même vdev détruit le pool.
-
Pourquoi RAIDZ1 est-il déconseillé avec des disques de 16 To ?
Réponse
Le resilver doit lire tous les autres disques du vdev pendant de longues heures, souvent plus de 24 h. Pendant ce temps, le vdev n'a plus de redondance : une seconde panne ou des secteurs illisibles entraînent une perte de données.
-
Dans quel cas dRAID a-t-il un intérêt ?
Réponse
Sur de grands pools (plus de 10 à 15 disques) où la durée de reconstruction est critique. Les spares distribués permettent un resilver beaucoup plus rapide. Sur un pool de 6 disques de VM, il n'apporte rien et pénalise les petits blocs.