¶ Cours : TrueNAS comme unité de stockage & technologie ZFS
¶ Vidéo
Truenas Community peut être téléchargé ici: https://www.truenas.com/truenas-community-edition/
¶ Partie 1 — TrueNAS comme unité de stockage
¶ 1.1 Introduction à TrueNAS
TrueNAS (anciennement FreeNAS) est un système d'exploitation open source développé par iXsystems, spécialement conçu pour le stockage réseau (NAS — Network Attached Storage). Il repose sur FreeBSD (TrueNAS CORE) ou Linux (TrueNAS SCALE) et utilise le système de fichiers ZFS comme fondation.
TrueNAS est utilisé dans les environnements :
- PME et entreprises comme serveur de fichiers
- Homelab pour le stockage personnel
- Infrastructure de sauvegarde
- Stockage pour machines virtuelles et conteneurs
¶ 1.2 Hiérarchie des concepts de stockage dans TrueNAS
Disques physiques
↓
vDev(s)
↓
Pool
↓
Dataset(s)
↓
Share(s)
Chaque niveau a un rôle précis. Il est crucial de comprendre ces distinctions avant de configurer TrueNAS.
¶ 1.3 Le Pool
¶ Définition
Un Pool est l'unité de stockage de plus haut niveau dans TrueNAS. Il représente l'ensemble du stockage disponible, constitué d'un ou plusieurs vDevs (virtual devices). C'est l'équivalent d'un volume logique ou d'un groupe de disques.
¶ Caractéristiques
- Un pool est créé une seule fois et peut être étendu par ajout de vDevs
- Il hérite des propriétés ZFS : compression, déduplication, checksums
- Le pool dispose d'une capacité totale et d'un espace utilisable selon le niveau de redondance
- Un pool est identifié par un nom unique (ex. :
tank,data,backup)
¶ Exemple
Un pool nommé tank composé de 4 disques de 4 To en RAID-Z1 offrira environ 12 To d'espace utilisable (3 disques utiles, 1 en parité).
⚠️ Important : La configuration de redondance est définie au niveau du vDev, pas du pool lui-même.
¶ 1.4 Le vDev (Virtual Device)
¶ Définition
Un vDev (Virtual Device) est le bloc de construction fondamental d'un pool ZFS. Il regroupe des disques physiques selon un niveau de redondance spécifique.
¶ Niveaux de redondance des vDevs
| Type de vDev | Disques min. | Redondance | Capacité utilisable |
|---|---|---|---|
| Stripe | 1+ | Aucune (risque élevé) | 100 % de la capacité totale |
| Mirror | 2 | 1 panne tolérée | 50 % (avec 2 disques) |
| RAID-Z1 | 3 | 1 disque en panne | (n-1) disques |
| RAID-Z2 | 4 | 2 disques en panne | (n-2) disques |
| RAID-Z3 | 5 | 3 disques en panne | (n-3) disques |
| dRAID | 2+ | Reconstruction rapide | Variable |
¶ Types de vDevs spéciaux
- Cache vDev (L2ARC) : SSD utilisé pour accélérer les lectures (cache de second niveau)
- Log vDev (SLOG/ZIL) : SSD utilisé pour accélérer les écritures synchrones
- Spare vDev : Disque de remplacement automatique en cas de panne
- Special vDev : Stocke les métadonnées ZFS (améliore les performances)
- Dedup vDev : Stocke les tables de déduplication
¶ Points clés à retenir
- Plusieurs vDevs peuvent composer un pool
- Les vDevs d'un pool sont mis en stripe automatiquement (les données sont distribuées)
- Un vDev ne peut pas changer de type une fois créé (ex. : impossible de passer de RAID-Z1 à RAID-Z2)
- La performance globale du pool est limitée par le vDev le plus lent
¶ 1.5 Le Dataset
¶ Définition
Un Dataset est une unité logique de stockage créée à l'intérieur d'un pool. C'est l'équivalent d'un dossier avec des propriétés ZFS indépendantes. Il permet d'organiser les données et d'appliquer des politiques spécifiques.
¶ Caractéristiques
- Hérite des propriétés du pool parent (mais peut les surcharger)
- Chaque dataset peut avoir ses propres paramètres : compression, quotas, snapshots, permissions, etc.
- Les datasets peuvent être imbriqués (hiérarchie de datasets)
- Ils apparaissent comme des répertoires dans le système de fichiers
¶ Propriétés configurables par dataset
| Propriété | Description |
|---|---|
| Compression | lz4, zstd, gzip, off — compresse les données à la volée |
| Quota | Limite l'espace utilisable par ce dataset |
| Reservation | Garantit un espace minimum pour ce dataset |
| Snapshot | Copie instantanée en lecture seule de l'état du dataset |
| Atime | Met à jour l'horodatage d'accès (désactiver pour les perfs) |
| Dedup | Active/désactive la déduplication |
| Case sensitivity | Sensibilité à la casse des noms de fichiers |
| Recordsize | Taille des blocs (défaut 128K, à ajuster selon l'usage) |
¶ Exemple de hiérarchie
tank/
├── tank/documents ← Dataset pour les docs, compression zstd
├── tank/media ← Dataset pour les médias, compression off
│ ├── tank/media/films
│ └── tank/media/musique
└── tank/vm ← Dataset pour les VM, recordsize 64K
¶ Dataset vs zvol
Un zvol (ZFS Volume) est une alternative au dataset pour des usages nécessitant un périphérique bloc brut (ex. : iSCSI, disques de VM). Un dataset est un système de fichiers ; un zvol est un volume bloc.
¶ 1.6 Les Shares (Partages réseau)
¶ Définition
Un Share expose un dataset (ou un dossier à l'intérieur d'un dataset) au réseau pour permettre l'accès par les clients. TrueNAS supporte plusieurs protocoles de partage.
¶ Protocoles disponibles
| Protocole | Usage principal | OS compatibles |
|---|---|---|
| SMB | Partage Windows (CIFS) | Windows, macOS, Linux |
| NFS | Partage Unix/Linux | Linux, macOS, FreeBSD |
| iSCSI | Stockage bloc réseau (pour VMs, bases de données) | Tous (via initiateur iSCSI) |
| AFP | Partage Apple (déprécié dans TrueNAS SCALE) | macOS (ancienne génération) |
| WebDAV | Accès web via HTTP/HTTPS | Tous les navigateurs |
¶ Points importants
- Un dataset peut avoir plusieurs partages simultanés (ex. : SMB et NFS en même temps)
- Les permissions sont gérées à deux niveaux : au niveau du dataset (ZFS ACLs ou POSIX) et au niveau du partage lui-même
- SMB est recommandé pour les environnements mixtes Windows/macOS
- NFS est préféré dans les environnements Linux/Unix et pour les VMs (ESXi, Proxmox)
- iSCSI est utilisé pour les workloads nécessitant un accès bloc (bases de données, VMs haute performance)
¶ 1.7 Tableau récapitulatif : Pool vs vDev vs Dataset vs Share
| Concept | Niveau | Rôle | Configuré dans |
|---|---|---|---|
| Pool | Physique | Agrège les vDevs, capacité totale | TrueNAS → Storage → Pools |
| vDev | Physique | Groupe de disques avec niveau de redondance | Lors de la création du pool |
| Dataset | Logique | Organisation des données, politiques ZFS | TrueNAS → Storage → Datasets |
| Share | Réseau | Expose un dataset sur le réseau | TrueNAS → Sharing |
¶ 1.8 Bonnes pratiques TrueNAS
- Ne jamais mettre de données sur le pool racine — créer toujours des datasets
- Utiliser RAID-Z2 minimum pour les données de production (tolérance à 2 pannes)
- Ajouter un SLOG (SSD) si beaucoup d'écritures synchrones (bases de données, VMs)
- Configurer des snapshots automatiques sur chaque dataset critique
- Séparer les datasets par type d'usage (médias, sauvegardes, VMs) pour appliquer des politiques différentes
- Monitorer la santé des disques avec les scrubs ZFS réguliers (hebdomadaires recommandés)
- Respecter la règle des 80 % — ne jamais dépasser 80 % de capacité d'un pool ZFS
¶ Partie 2 — La technologie ZFS
¶ 2.1 Introduction à ZFS
ZFS (Zettabyte File System) est un système de fichiers et gestionnaire de volumes créé par Sun Microsystems en 2001, rendu open source en 2005. Il est aujourd'hui maintenu par le projet OpenZFS, qui supporte FreeBSD, Linux, macOS et d'autres systèmes.
ZFS n'est pas seulement un système de fichiers : c'est une combinaison d'un gestionnaire de volumes logiques (LVM) et d'un système de fichiers en une seule couche, ce qui lui confère des capacités uniques.
ZFS a été conçu avec un objectif simple : ne jamais perdre de données, même en cas de panne matérielle ou logicielle.
¶ 2.2 Les piliers fondamentaux de ZFS
¶ 2.2.1 Copy-on-Write (CoW)
ZFS n'écrase jamais les données existantes. Lorsqu'un fichier est modifié :
- Les nouvelles données sont écrites dans un nouvel emplacement sur le disque
- Les pointeurs (métadonnées) sont mis à jour pour pointer vers les nouvelles données
- L'ancien emplacement est libéré seulement après la confirmation de la nouvelle écriture
Avantage : Si le système tombe en panne pendant une écriture, les anciennes données sont toujours intactes. Le système de fichiers ne peut jamais se retrouver dans un état incohérent — pas besoin de fsck.
AVANT modification :
[Bloc A] ← Pointeur
PENDANT modification (CoW) :
[Bloc A] [Bloc B (nouvelle version)]
↑ Pointeur (mis à jour atomiquement)
APRÈS :
[Bloc B] ← Pointeur
[Bloc A] (libéré)
¶ 2.2.2 Checksums et intégrité des données
Chaque bloc de données ZFS possède un checksum cryptographique (SHA-256, SHA-512, Skein, etc.) stocké dans les métadonnées du bloc parent.
Lors de chaque lecture, ZFS vérifie le checksum. Si le checksum ne correspond pas :
- ZFS détecte la corruption silencieuse (bit rot)
- Sur un pool avec redondance, ZFS corrige automatiquement les données via les copies miroir ou de parité
- Sans redondance, ZFS signale l'erreur
C'est la protection contre le silent data corruption, une faiblesse majeure de systèmes de fichiers traditionnels comme ext4 ou NTFS.
¶ 2.2.3 Snapshots
Un snapshot ZFS est une copie instantanée et en lecture seule de l'état d'un dataset à un instant T. Grâce au CoW :
- Les snapshots sont créés instantanément (en millisecondes)
- Ils n'occupent aucun espace supplémentaire au moment de leur création
- Ils n'occupent de l'espace que progressivement, au fur et à mesure que les données originales sont modifiées
# Créer un snapshot
zfs snapshot tank/documents@2024-01-15
# Lister les snapshots
zfs list -t snapshot
# Restaurer depuis un snapshot
zfs rollback tank/documents@2024-01-15
# Cloner un snapshot (créer un dataset modifiable à partir d'un snapshot)
zfs clone tank/documents@2024-01-15 tank/documents-clone
Usages pratiques :
- Sauvegardes quasi-instantanées avant une mise à jour
- Récupération de fichiers supprimés accidentellement
- Base pour la réplication ZFS (
zfs send / zfs receive)
¶ 2.2.4 RAID-Z (redondance)
ZFS implémente sa propre gestion de la redondance RAID, sans dépendre des contrôleurs RAID matériels. Le RAID-Z résout des problèmes fondamentaux du RAID 5 traditionnel :
¶ Le problème du RAID 5 classique : Write Hole
En RAID 5 classique, si le système tombe en panne pendant une écriture partielle, les données de parité peuvent devenir incohérentes → corruption. ZFS évite ce problème grâce au CoW : les nouvelles données sont écrites avant de mettre à jour les pointeurs.
¶ RAID-Z vs RAID classique
| Critère | RAID 5 classique | RAID-Z1 ZFS |
|---|---|---|
| Write hole | Oui (risque réel) | Non (CoW élimine le risque) |
| Détection de corruption | Non | Oui (checksums) |
| Correction automatique | Partielle | Oui (si redondance) |
| Dépendance matérielle | Contrôleur RAID requis | Logiciel uniquement |
| Stripe size | Fixe | Variable (optimisé) |
¶ 2.2.5 ARC — Adaptive Replacement Cache
ZFS utilise la RAM disponible comme cache de lecture intelligent appelé ARC (Adaptive Replacement Cache).
- L'ARC remplace le page cache du noyau pour les données ZFS
- Il garde en cache aussi bien les données récemment accédées que les données fréquemment accédées (algorithme hybride LRU + LFU)
- L2ARC : extension de l'ARC sur un SSD (second niveau de cache)
Lecture d'un fichier :
ARC (RAM) → L2ARC (SSD) → Disques (spinning ou NVMe)
Plus TrueNAS dispose de RAM, plus l'ARC est grand et plus les lectures répétées sont rapides. La règle générale : 1 Go de RAM par To de stockage (minimum).
¶ 2.2.6 ZIL — ZFS Intent Log
Le ZIL (ZFS Intent Log) gère les écritures synchrones (opérations qui doivent être confirmées comme écrites sur disque avant de retourner à l'application).
- Par défaut, le ZIL est stocké sur le même pool que les données
- Un SLOG (Separate Log — un SSD rapide dédié) peut remplacer le ZIL sur disque pour des performances accrues
- Sans SLOG, les écritures synchrones sont limitées par la vitesse des disques du pool
Workloads bénéficiant d'un SLOG :
- Bases de données (PostgreSQL, MySQL)
- VMs avec
sync=always - NFS avec synchronisation activée
¶ 2.2.7 Compression
ZFS peut compresser les données à la volée avant de les écrire sur disque. La compression est transparente pour les applications.
| Algorithme | Ratio typique | Vitesse | Recommandation |
|---|---|---|---|
lz4 |
Moyen | Très rapide | Par défaut — recommandé pour tout |
zstd |
Élevé | Rapide | Données compressibles (docs, logs) |
gzip-1 |
Élevé | Moyen | Archivage |
gzip-9 |
Très élevé | Lent | Archivage froid |
off |
Aucun | Maximum | Médias déjà compressés (MP4, JPEG) |
La compression
lz4est souvent activée par défaut sur TrueNAS et peut en réalité accélérer les transferts en réduisant les I/O disque.
¶ 2.2.8 Déduplication
La déduplication ZFS détecte les blocs identiques et n'en stocke qu'une seule copie, avec des pointeurs vers cette copie unique.
- Avantage : Énorme gain d'espace pour les données très redondantes (VMs similaires, sauvegardes)
- Inconvénient majeur : Très gourmande en RAM (la table de déduplication doit tenir en RAM)
- Estimation : ~5 Go de RAM par To de données dédupliquées
- Alternative recommandée : La compression
zstdoffre un bon ratio sans le coût en RAM
¶ 2.3 Le Scrub ZFS
Un scrub est une vérification complète de l'intégrité de toutes les données du pool. ZFS lit chaque bloc et vérifie son checksum, corrigeant automatiquement les erreurs si la redondance le permet.
# Lancer un scrub
zpool scrub tank
# Voir le statut d'un scrub en cours
zpool status tank
Fréquence recommandée : Hebdomadaire (configuré automatiquement dans TrueNAS).
¶ 2.4 La réplication ZFS : zfs send / zfs receive
ZFS permet de répliquer des datasets entiers (avec leur historique de snapshots) vers un autre système, localement ou via réseau. C'est la base de la sauvegarde 3-2-1 avec TrueNAS.
# Envoyer un snapshot vers un autre pool (local)
zfs send tank/documents@2024-01-15 | zfs receive backup/documents
# Réplication incrémentale (seules les différences sont envoyées)
zfs send -i tank/documents@ancien tank/documents@nouveau | zfs receive backup/documents
# Réplication réseau via SSH
zfs send tank/documents@snap | ssh user@remote zfs receive tank2/documents
Avantage : La réplication est efficace (seules les modifications depuis le dernier snapshot sont transférées) et atomique (le dataset de destination est toujours dans un état cohérent).
¶ 2.5 Résumé des avantages de ZFS
| Fonctionnalité | Bénéfice concret |
|---|---|
| Copy-on-Write | Pas de corruption lors d'une coupure de courant |
| Checksums | Détection et correction du bit rot (corruption silencieuse) |
| Snapshots | Sauvegardes instantanées, récupération rapide |
| RAID-Z | Redondance sans contrôleur matériel, sans write hole |
| ARC / L2ARC | Cache intelligent qui exploite toute la RAM disponible |
| Compression | Moins d'espace, souvent plus rapide qu'un FS non compressé |
| Réplication (send/recv) | Sauvegarde réseau efficace et cohérente |
| Self-healing | Correction automatique des erreurs si redondance disponible |
¶ 2.6 Limites et contraintes de ZFS
- RAM requise : ZFS est gourmand en RAM. Minimum 8 Go recommandé, plus la RAM = meilleures performances ARC
- ECC RAM fortement recommandée : Pour éviter que la RAM corrompue n'écrase des données saines (ZFS ne peut pas protéger contre une RAM défaillante)
- Pas d'ajout de disques à un vDev existant (avant OpenZFS 2.2 qui introduit l'expansion de vDev)
- Pas de réduction d'un pool : on peut ajouter des disques mais pas en retirer facilement
- Déduplication coûteuse en RAM — à utiliser avec précaution
- Non recommandé sur un système principal avec peu de RAM (< 4 Go)
¶ Conclusion
TrueNAS, appuyé sur ZFS, offre une solution de stockage robuste, flexible et orientée intégrité des données. La compréhension des quatre niveaux — pool, vDev, dataset, share — permet de concevoir une infrastructure de stockage efficace et adaptée aux besoins. ZFS, de son côté, est une technologie de premier plan qui allie gestion de volumes, système de fichiers et protection des données dans une solution unifiée.
*Cours rédigé pour le Cégep Ahuntsic par son excellence Pablo The God