🧱 Storage Systems — Chapitre 6 : RAID et protection locale des données

Vocabulaire technique indispensable

Métriques à suivre avant de choisir un niveau RAID

RAID logiciel : avantages modernes

# Lire l'état global
cat /proc/mdstat

# Détails d'un array
mdadm --detail /dev/md0

# Scanner les arrays
mdadm --examine --scan

Pourquoi ZFS préfère voir les disques bruts

ZFS veut maîtriser l'intégrité de bout en bout. Un contrôleur RAID matériel peut cacher les erreurs, remapper les disques et empêcher ZFS de comprendre précisément l'état physique. La pratique recommandée est souvent HBA/IT mode + disques exposés individuellement.

Pièges classiques à éviter

• Fake RAID / BIOS RAID : souvent moins robuste qu'un vrai contrôleur ou mdadm.
• Write-back sans protection : très performant, mais dangereux sans BBU/flash-backed cache.
• Contrôleur unique : une baie peut perdre tous ses volumes si la carte RAID tombe et qu'aucune carte compatible n'est disponible.
• Firmware hétérogène : disques identiques mais firmwares différents peuvent produire des comportements incohérents.
• Monitoring absent : le RAID dégradé pendant plusieurs semaines est une bombe à retardement.

Quand RAID 0 est acceptable

• Cache temporaire reconstructible.
• Scratch disk vidéo/IA/HPC sans données uniques.
• Benchmark ou lab.
• Volume avec réplication applicative forte au-dessus.

Procédure de remplacement conceptuelle

• Disques système de serveurs.
• Petits NAS 2 baies.
• Volumes logs critiques à taille modérée.
• Environnements où la simplicité prime sur le rendement capacité.

La pénalité d'écriture RAID 5

Une petite écriture implique souvent lecture ancienne donnée, lecture ancienne parité, calcul nouvelle parité, écriture donnée, écriture parité.

• Rebuild lit massivement tous les disques survivants.
• Une URE pendant reconstruction peut rendre le volume irrécupérable.
• Un second disque mort pendant rebuild est fatal.
• Plus le disque est grand et lent, plus la période de risque augmente.

Usages encore acceptables avec prudence

• Petits ensembles de SSD entreprise avec backup solide.
• Données peu critiques et facilement restaurables.
• Volumes lecture majoritaire avec faible pression d'écriture.

Rebuild : attention à la fenêtre de stress

• Le rebuild sollicite tous les disques, parfois pendant très longtemps.
• Les disques restants sont souvent du même âge et du même lot.
• Le système peut devenir lent : throttle de rebuild à ajuster.
• Un patrol read/scrub régulier réduit la surprise au moment critique.

• NAS/SAN avec gros HDD.
• Stockage backup local.
• Archives actives.
• Volumes lecture majoritaire.

RAID 10 peut perdre plusieurs disques si ceux-ci ne sont pas dans la même paire miroir. Il peut aussi être perdu avec seulement deux pannes si les deux disques d'une même paire tombent.

• Base de données OLTP.
• Datastores de machines virtuelles.
• Journaux transactionnels.
• Workloads mixtes lecture/écriture.
• Applications qui exigent basse latence et rebuild rapide.

Dans Ceph ou object storage

• Les fragments sont placés sur des OSD/nœuds différents.
• La CRUSH map ou politique de placement évite les corrélations de panne.
• EC est intéressant pour données volumineuses et froides.
• Pour petits objets ou workloads random write, réplication 3× peut être plus simple et plus rapide.

# Exemple conceptuel Ceph
ceph osd erasure-code-profile set ec-profile k=6 m=3 crush-failure-domain=host
ceph osd pool create data-ec erasure ec-profile

Coûts cachés

• CPU pour encoder/décoder.
• Réseau pour récupérer plusieurs shards.
• Latence supérieure à une réplication simple.
• Complexité d'exploitation en cas de cluster dégradé.
• Moins adapté aux petits objets très modifiés.

Scrubbing / patrol read

Le scrub relit périodiquement les données pour détecter les erreurs latentes avant qu'un rebuild critique ne les rencontre. ZFS/Btrfs vérifient les checksums logiques, tandis que beaucoup de contrôleurs parlent de patrol read ou consistency check.

Bit rot et corruption silencieuse

• Cosmic rays, usure NAND, défaut média, firmware, câble, RAM non-ECC.
• Sans checksum end-to-end, une corruption peut être sauvegardée et répliquée.
• Les systèmes COW à checksum sont conçus pour détecter ces anomalies.

# ZFS scrub
zpool status
zpool scrub tank
zpool status -v tank

# Btrfs scrub
btrfs scrub start -Bd /data
btrfs scrub status /data

# mdadm consistency check
echo check > /sys/block/md0/md/sync_action
cat /proc/mdstat

# SMART
smartctl -a /dev/sda
smartctl -t long /dev/sda

Calcul simplifié

Ce modèle simplifié illustre l'ordre de grandeur. En production, il faut aussi tenir compte de l'âge des disques, des vibrations, de la température, du firmware, de la charge, de la qualité contrôleur et des secteurs déjà réalloués.

Réduction du risque

• Éviter RAID 5 sur gros HDD critiques.
• Préférer RAID 6, RAID 10, RAID-Z2/Z3 ou stockage distribué.
• Scrubbing régulier pour détecter les erreurs latentes avant panne.
• Hot spare ou cold spare disponible immédiatement.
• Monitoring SMART et seuils prédictifs.
• Backup restaurable testé, pas seulement existant.

BBU / Flash-backed write cache

La batterie ou le supercondensateur protège les écritures en cache pendant une coupure. Les contrôleurs modernes peuvent transférer le cache vers une mémoire flash interne.

Power Loss Protection côté SSD

Les SSD enterprise disposent souvent de condensateurs pour protéger les données en transit dans les buffers internes du SSD. C'est très important pour bases de données et virtualisation.

• Activer write-back uniquement si BBU/supercap est OK.
• Sur alerte BBU défectueuse, basculer en write-through.
• Tester la restauration après coupure contrôlée dans un lab, jamais directement en prod.
• Sur DB critiques, aligner paramètres contrôleur, filesystem, cache DB et politique fsync.

Règle fondamentale : le pool hérite des vdevs

Dans ZFS, un pool est composé de vdevs. Si un vdev est perdu, le pool est perdu. La redondance se définit au niveau du vdev, pas seulement au niveau du pool.

# Status et santé
zpool status -v tank
zpool list
zfs list

# Scrub
zpool scrub tank

# Remplacement
zpool offline tank /dev/disk/by-id/old
zpool replace tank /dev/disk/by-id/old /dev/disk/by-id/new

# Snapshots
zfs snapshot tank/data@before-upgrade
zfs list -t snapshot

• Ne pas mettre ZFS au-dessus d'un RAID matériel opaque.
• Éviter SMR non adaptés aux écritures intensives.
• Planifier RAM ECC si possible.
• Comprendre que l'extension d'un vdev RAID-Z n'est pas la même chose qu'ajouter un vdev.
• Tester les procédures de remplacement de disque avant incident réel.

cat /proc/mdstat
mdadm --detail /dev/md0
mdadm --examine /dev/sdb1
journalctl -u mdmonitor --since today

# Simuler un disque en panne dans un lab
mdadm /dev/md0 --fail /dev/sdb1
mdadm /dev/md0 --remove /dev/sdb1
cat /proc/mdstat

# Préparer le nouveau disque avec même partitionnement
sfdisk -d /dev/sdc | sfdisk /dev/sdb

# Ajouter le nouveau membre
mdadm /dev/md0 --add /dev/sdb1

# Suivre rebuild
watch -n 2 cat /proc/mdstat

# Debian/Ubuntu
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
update-initramfs -u

# fstab avec UUID
blkid /dev/md0
echo 'UUID=xxxx /data xfs defaults,nofail 0 2' >> /etc/fstab

smartctl -a /dev/sda
smartctl -H /dev/sda
smartctl -x /dev/sda
smartctl -t short /dev/sda
smartctl -t long /dev/sda

# Broadcom/LSI storcli examples
storcli /c0 show
storcli /c0 /vall show
storcli /c0 /eall /sall show
storcli /c0 /bbu show
storcli /c0 show events

# MegaCLI legacy style
MegaCli64 -AdpAllInfo -aALL
MegaCli64 -PDList -aALL
MegaCli64 -LDInfo -Lall -aALL

Alertes minimales

• Array degraded : critique immédiat.
• Battery failed / cache disabled : warning sérieux, performance et cohérence impactées.
• SMART health failed : remplacement.
• Pending sectors > 0 : investigation.
• Scrub errors : vérifier fichiers affectés et backup.
• Rebuild started/completed/failed : notifications obligatoires.

• Production critique + HDD : RAID 6 minimum ou RAID 10.
• Production DB : RAID 10 ou stockage flash enterprise.
• Grand NAS : RAID-Z2/Z3 ou RAID 6 selon technologie.
• Stockage distribué : EC ou réplication, pas RAID local seul.
• Tout niveau RAID : backup externe obligatoire.

# Exemple avec loop devices /dev/loop0..3
mdadm --create /dev/mdlab --level=5 --raid-devices=4 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3
watch -n 1 cat /proc/mdstat
mkfs.ext4 /dev/mdlab
mkdir -p /mnt/mdlab
mount /dev/mdlab /mnt/mdlab

fio --name=seqwrite --directory=/mnt/mdlab --size=2G --bs=1M --rw=write --iodepth=16 --numjobs=1 --direct=1
fio --name=randrw --directory=/mnt/mdlab --size=2G --bs=4k --rw=randrw --rwmixread=70 --iodepth=32 --numjobs=4 --direct=1

# Simuler panne
mdadm /dev/mdlab --fail /dev/loop2
mdadm --detail /dev/mdlab

# Retirer puis ajouter un disque
mdadm /dev/mdlab --remove /dev/loop2
mdadm /dev/mdlab --add /dev/loop2
watch -n 1 cat /proc/mdstat

• Suivre pourcentage et vitesse de reconstruction.
• Surveiller latence applicative et erreurs kernel.
• Ne pas lancer de tâches lourdes inutiles.
• Éviter reboot ou firmware update pendant rebuild sauf nécessité absolue.
• Prévenir métiers si la performance est dégradée.

• Confirmer array optimal.
• Lancer scrub/consistency check après stabilisation.
• Vérifier logs contrôleur et SMART des autres disques.
• Remplacer hot spare consommé si nécessaire.
• Mettre à jour inventaire : serial, slot, date, firmware.
• Rédiger post-mortem si incident critique.

• Vérifier état array quotidiennement via monitoring.
• Recevoir alerte sur degraded, predictive failure, BBU failure.
• Planifier scrubbing/patrol read.
• Vérifier température et airflow.
• Observer tendances SMART, pas seulement état binaire OK/FAIL.

• Backup hors machine et hors array.
• Copie immuable ou offline contre ransomware.
• Test de restauration périodique.
• Documentation RTO/RPO réelle mesurée.

• Plan des slots disques avec numéros de série.
• Type contrôleur, version firmware, mode cache.
• Niveau RAID, stripe size, hot spare.
• Procédure remplacement disque.
• Contact support constructeur et contrat.
• Dernier test restore et résultat.