🖥️ Storage Systems — Chapitre 7 : DAS, Direct Attached Storage

• Serveur PostgreSQL avec SSD NVMe locaux.
• Hyperviseur Proxmox standalone avec ZFS mirror local.
• Serveur backup avec shelf SAS 12 × HDD en RAID 6.
• Nœud Ceph avec disques locaux, mais cluster partagé au-dessus.

DAS est très utilisé dans les petits environnements virtualisés : ESXi local datastore, Proxmox ZFS local, Hyper-V local. C'est simple et performant, mais la mobilité live des VM et la HA automatique sont limitées sans couche partagée ou distribuée.

• Cache CDN local sur NVMe.
• Scratch IA/ML ou rendu vidéo.
• TempDB SQL Server sur SSD local.
• Cache de build CI/CD.
• Zone de staging ETL avant chargement data warehouse.

Ceph, MinIO, Cassandra, Elasticsearch, Kafka ou Kubernetes Local Persistent Volumes consomment souvent des disques DAS. Le partage et la résilience ne sont plus fournis par le disque local, mais par le cluster logiciel au-dessus.

• Choix complet du filesystem : XFS, ext4, ZFS, NTFS, ReFS.
• Choix du RAID : matériel, mdadm, ZFS, Storage Spaces.
• Contrôle fin kernel : scheduler, queue depth, read-ahead.
• Maintenance isolée par serveur.
• Benchmark local plus facile à interpréter qu'un SAN partagé saturé.

Un serveur avec DAS ne subit pas directement la charge E/S d'autres hôtes sur une baie commune. Cette isolation est précieuse pour appliances, bases critiques autonomes, ou environnements edge.

• Chaque serveur a son propre stockage à inventorier.
• Les remplacements disques sont moins centralisés.
• Les firmwares peuvent diverger.
• La capacité inutilisée est piégée localement si non agrégée.
• Le backup doit couvrir chaque hôte.

• Les disques passent-ils par le même expandeur/backplane ?
• Le contrôleur est-il single point of failure ?
• Le serveur a-t-il assez de lanes PCIe ?
• Le monitoring sait-il mapper /dev/sdX vers slot physique ?

• Dual-port et expandeurs.
• Gestion enterprise : LED slot, enclosure services.
• Très adapté aux shelves externes.

nvme list
nvme smart-log /dev/nvme0
lspci -tv

DAS + HBA IT mode est une combinaison fréquente pour ZFS : le serveur voit chaque disque, ZFS gère redondance, checksums, scrub, compression, snapshots et resilver.

zpool create tank mirror /dev/disk/by-id/disk1 /dev/disk/by-id/disk2
zpool status tank
zpool scrub tank

• Write-back contrôleur seulement si BBU/supercap OK.
• SSD enterprise avec PLP pour bases et VM critiques.
• UPS utile, mais ne remplace pas PLP/BBU.

• Limiter les jobs batch.
• Surveiller température et erreurs.
• Vérifier backup avant remplacement.

Augmenter la profondeur de queue augmente souvent le débit, mais peut exploser la latence. Pour une base transactionnelle, une latence p99 stable vaut souvent mieux qu'un débit maximal de benchmark.

• Un NVMe attaché au socket CPU 1 peut être moins performant pour un process piné sur CPU 0.
• Les cartes PCIe partagent parfois lanes et switches.
• Le throttling thermique peut réduire brutalement la performance.

lscpu
numactl --hardware
lspci -tv
cat /proc/interrupts | grep -i nvme

iostat -x 1
pidstat -d 1
vmstat 1
nvme list
nvme smart-log /dev/nvme0
fio --name=randread --filename=/data/fio.test --size=8G --rw=randread --bs=4k --iodepth=32 --numjobs=4 --direct=1 --time_based --runtime=60 --group_reporting

• DRBD peut répliquer un volume bloc entre deux serveurs.
• Utile pour clusters actifs/passifs.
• Attention au split-brain : fencing obligatoire.
• La latence réseau devient une partie du chemin d'écriture en synchrone.

vSAN, Ceph, Storage Spaces Direct ou Longhorn agrègent des disques locaux pour présenter un stockage distribué. Les disques restent DAS physiquement, mais la résilience est fournie par la couche software-defined.

Pour une DB, le p99 d'écriture synchrone est souvent plus important que le débit maximal.

• Éviter SSD consumer sans PLP pour journaux critiques.
• Ne pas désactiver fsync pour gagner des benchmarks.
• Aligner filesystem, mount options et recommandations moteur DB.
• Prévoir réplication DB : le DAS local n'est pas HA par magie.

iostat -x 1
pidstat -d 1
iotop -oPa

# PostgreSQL
SELECT * FROM pg_stat_bgwriter;
SELECT * FROM pg_stat_database;

# MySQL/MariaDB
SHOW ENGINE INNODB STATUS\G
SHOW GLOBAL STATUS LIKE 'Innodb_data_fsyncs';

Sur stockage partagé, deux hôtes voient le même datastore. Avec DAS, la VM doit être copiée ou répliquée. Les migrations deviennent plus longues et consomment réseau + disque.

• Backup au niveau hyperviseur vers stockage externe.
• Tester restauration VM complète sur autre hôte.
• Éviter backup stocké uniquement sur le même DAS.
• Ne pas confondre snapshot VM et sauvegarde.

• RAID 10 ou SSD/NVMe pour VM actives.
• RAID 1 pour boot hyperviseur.
• Monitoring usure SSD et latence datastore.
• Plan de restauration sur hôte de secours.

Le DAS est souvent utilisé comme tampon de continuité quand le WAN n'est pas garanti.

• Chiffrement obligatoire.
• Monitoring distant robuste.
• SSD/HDD adaptés à température et vibrations.
• Procédure de remplacement par non spécialiste.

• Linux : LUKS/dm-crypt.
• Windows : BitLocker.
• Self Encrypting Drives.
• ZFS native encryption par dataset.

# NVMe destructive
nvme format /dev/nvme0 --ses=1
nvme sanitize /dev/nvme0 --sanact=2

# ATA destructive
hdparm -I /dev/sdX
hdparm --user-master u --security-set-pass PASS /dev/sdX
hdparm --user-master u --security-erase PASS /dev/sdX

• Ne jamais stocker la clé uniquement sur le même serveur sans protection.
• Documenter procédure de récupération après reboot.
• Prévoir rotation et révocation.
• Pour datacenter sérieux : KMS, HSM ou secrets manager.

smartctl -a /dev/sda
smartctl -H /dev/sda
nvme smart-log /dev/nvme0
nvme error-log /dev/nvme0
lsblk -o NAME,SIZE,MODEL,SERIAL,ROTA,TYPE,MOUNTPOINT
iostat -x 1
dmesg -T | egrep -i 'error|reset|nvme|scsi|ata'

• Lire release notes avant mise à jour.
• Tester sur hôte non critique.
• Éviter update pendant rebuild.
• Aligner firmware backplane, contrôleur et disques.

• Disques compatibles même capacité ou supérieure.
• Câbles SAS/PCIe/USB adaptés.
• Contrôleur RAID/HBA compatible si critique.
• Procédure visuelle de remplacement avec slots.

• Un seul serveur consomme les données.
• La faible latence est prioritaire.
• Le budget doit rester contenu.
• La HA est assurée par l'application ou non nécessaire.
• Le workload est local, edge ou appliance.

• Plusieurs serveurs doivent accéder simultanément aux mêmes données.
• Il faut migration VM instantanée.
• Le serveur ne peut pas être un point unique de panne.
• La capacité doit être partagée dynamiquement entre équipes.

fio --name=rr4k --filename=/data/fio.test --size=16G --rw=randread --bs=4k --iodepth=32 --numjobs=4 --direct=1 --time_based --runtime=120 --group_reporting

fio --name=mix --filename=/data/fio.test --size=16G --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --direct=1 --time_based --runtime=120 --group_reporting

# Lab uniquement
fio --name=raw --filename=/dev/sdX --rw=write --bs=1M --direct=1

• SMART/NVMe health collecté.
• Array degraded alert critique.
• Température disques et throttling surveillés.
• Logs kernel stockage centralisés.
• Mapping disque logique → slot physique documenté.

• Backup distant ou offline/immutable.
• Test restore périodique.
• RPO/RTO mesurés.
• Procédure de restauration sur autre matériel.

• Chiffrement si site non sécurisé ou données sensibles.
• Clés documentées et récupérables.
• Secure Boot / TPM si requis.
• Procédure sanitize avant sortie de parc.

• Schéma stockage du serveur.
• Liste disques : modèle, serial, slot, firmware.
• Contrôleur/HBA : modèle, firmware, mode.
• Volumes : rôle, filesystem, mountpoint.
• Runbook incident disque et incident serveur.