RAID : performances, redondance et faux sentiment de sécurité

Le RAID est à l’infrastructure de stockage ce que l’armure est au chevalier : il peut absorber certains coups, améliorer ses chances de rester debout et donner une impression rassurante de robustesse.

Mais une armure ne protège ni contre l’incendie du château, ni contre une erreur stratégique, ni contre le chevalier lui-même décidant de sauter volontairement dans les douves.

Pour le RAID, c’est exactement pareil.

RAID désigne un ensemble de techniques permettant de combiner plusieurs périphériques de stockage afin d’obtenir :

• davantage de performances ;
• davantage de capacité ;
• une tolérance à certaines pannes ;
• ou une combinaison de ces objectifs.

Mais retenez immédiatement la règle qui mérite d’être gravée sur chaque baie de stockage :

RAID n’est pas une sauvegarde.

Un RAID peut survivre à la panne d’un disque.

Il ne peut pas forcément survivre à :

• une suppression accidentelle ;
• un ransomware ;
• une corruption logique ;
• une mauvaise commande administrative ;
• un incendie ;
• un vol ;
• la destruction de toute la baie ;
• ou un administrateur suffisamment motivé équipé de rm -rf.

Que signifie RAID ?

On développe aujourd’hui généralement RAID comme :

Redundant Array of Independent Disks

soit :

ensemble redondant de disques indépendants.

Petite curiosité historique : dans le célèbre article universitaire qui popularisa RAID à la fin des années 1980, le terme signifiait :

Redundant Arrays of Inexpensive Disks

Le principe était alors d’utiliser plusieurs petits disques relativement peu coûteux plutôt qu’un seul énorme disque très cher.

Le mot :

Inexpensive

est progressivement devenu :

Independent

dans l’usage industriel.

La facture des infrastructures de stockage modernes ayant parfois atteint des niveaux intéressants, cette évolution lexicale possède également une certaine élégance.

Le principe général

Prenons quatre disques :

Disque A
Disque B
Disque C
Disque D

Un mécanisme RAID peut les présenter au système comme un stockage logique unique :

Disque A ─┐
Disque B ─┼── RAID ── Volume logique
Disque C ─┤
Disque D ─┘

Selon le niveau choisi, les données seront :

• réparties ;
• dupliquées ;
• accompagnées d’informations de parité ;
• ou réparties et dupliquées à la fois.

RAID travaille sous le système de fichiers

Dans une architecture classique :

Disques physiques
      ↓
RAID
      ↓
Périphérique logique
      ↓
Partition éventuelle
      ↓
Système de fichiers
      ↓
Fichiers

Par exemple sous Linux :

/dev/sdb ─┐
/dev/sdc ─┼── RAID MD ── /dev/md0 ── ext4 ── /srv/data
/dev/sdd ─┘

Le système de fichiers voit essentiellement :

/dev/md0

et n’a pas nécessairement besoin de connaître tous les détails de la disposition physique derrière.

Les notions à connaître avant les niveaux RAID

Array

L’array est l’ensemble RAID.

Member / membre

Un disque membre est un périphérique participant à l’ensemble.

Stripe

Une :

stripe

correspond à un ensemble de données réparties horizontalement sur plusieurs membres selon l’organisation du RAID.

Chunk

Un :

chunk

est une unité de données placée sur un membre avant que le placement continue sur un autre.

On peut imaginer :

Chunk A → disque 1
Chunk B → disque 2
Chunk C → disque 3
...

Mirror

Un miroir conserve plusieurs copies des mêmes données sur des périphériques différents.

Parity

La parité contient des informations mathématiques permettant de reconstruire certaines données lorsqu’un membre disparaît.

Degraded

Un RAID redondant est :

degraded

lorsqu’un ou plusieurs membres nécessaires à son état normal sont absents ou défaillants, mais que l’ensemble peut encore fonctionner.

Rebuild

Le :

rebuild

est la reconstruction des données redondantes vers un disque de remplacement.

Hot spare

Un :

hot spare

est un disque de réserve déjà disponible dans le système et pouvant être utilisé lorsqu’un membre actif tombe en panne.

Capacité : une formule avant tout

Pour simplifier les exemples suivants, supposons :

N = nombre de disques
S = capacité utilisable du plus petit disque

Les capacités théoriques classiques deviennent :

RAID	Capacité théorique
RAID 0	N × S
RAID 1 classique	S
RAID 5	(N - 1) × S
RAID 6	(N - 2) × S
RAID 10 conventionnel	(N / 2) × S

Ces formules supposent notamment des disques de même taille ou une organisation utilisant une capacité commune équivalente.

Pourquoi le plus petit disque est important

Prenons :

Disque 1 : 8 To
Disque 2 : 8 To
Disque 3 : 8 To
Disque 4 : 4 To

Dans de nombreuses implémentations RAID traditionnelles, le petit disque peut limiter la portion exploitable des autres membres.

Selon la technologie utilisée, une partie de la capacité des disques de 8 To peut donc rester inutilisée.

Mélanger des disques de tailles très différentes est possible dans certains systèmes, mais les formules RAID classiques ne permettent pas nécessairement d’en exploiter intelligemment chaque octet.

RAID 0 : striping sans parachute

RAID 0 utilise le :

striping

Les données sont réparties entre plusieurs disques.

Avec deux membres :

Données :
A B C D E F G H

Disque 1 :
A   C   E   G

Disque 2 :
  B   D   F   H

Caractéristiques

• Minimum classique : 2 disques
• Redondance : aucune
• Tolérance garantie : 0 panne
• Capacité : environ N × S
• Objectif : capacité et performances

Pourquoi RAID 0 peut être rapide

Plusieurs disques peuvent participer à une opération.

Une lecture suffisamment grande peut par exemple être distribuée :

Disque A ─┐
          ├── lecture parallèle
Disque B ─┘

De même pour les écritures.

Le gain réel dépend néanmoins :

• du type de stockage ;
• de la taille des opérations ;
• de la profondeur de file d’attente ;
• de la taille des chunks ;
• du contrôleur ;
• du système de fichiers ;
• de l’interface disponible ;
• du type de charge.

Deux SSD NVMe en RAID 0 ne garantissent donc pas automatiquement :

2 × performance dans toutes les applications

Le problème du RAID 0

Une partie des données se trouve sur chaque disque.

Si un seul membre disparaît :

Disque 1 : OK
Disque 2 : MORT

une partie des blocs du volume entier manque.

L’ensemble est alors généralement inutilisable comme volume cohérent.

RAID 0 multiplie les disques nécessaires au fonctionnement sans ajouter la moindre redondance.

Quand utiliser RAID 0 ?

Il peut avoir du sens pour :

• scratch space ;
• cache reconstructible ;
• fichiers temporaires ;
• calcul scientifique avec données reproduisibles ;
• montage vidéo lorsque les originaux existent ailleurs ;
• certaines charges où la performance prime totalement sur la disponibilité.

Pour les photos uniques de naissance du premier enfant :

peut-être pas.

RAID 1 : le miroir

RAID 1 conserve des copies identiques des données.

Avec deux disques :

Disque A : A B C D E F
Disque B : A B C D E F

Caractéristiques classiques à deux membres

• Minimum : 2 disques
• Capacité : celle d’un seul membre
• Tolérance : perte d’un des deux membres
• Principe : mirroring

RAID 1 avec plus de deux copies

RAID 1 n’est pas obligatoirement limité à deux membres dans toutes les implémentations.

On peut conceptuellement avoir :

Disque A : DATA
Disque B : DATA
Disque C : DATA

Si les trois membres possèdent une copie complète et valide, l’ensemble peut théoriquement continuer tant qu’une copie intacte reste disponible.

La capacité reste alors proche de celle d’un seul disque.

L’efficacité de stockage devient :

2 copies → 50 %
3 copies → 33,3 %
4 copies → 25 %

La disponibilité adore ce principe.

Le service achats beaucoup moins.

Performances du RAID 1

Les écritures doivent parvenir à toutes les copies concernées.

Le débit d’écriture n’est donc pas simplement multiplié par le nombre de disques.

Les lectures peuvent en revanche être distribuées entre plusieurs membres par certaines implémentations.

Un RAID 1 peut ainsi améliorer :

• les lectures concurrentes ;
• les IOPS de lecture ;
• la disponibilité.

Les gains exacts dépendent du contrôleur ou du logiciel RAID.

RAID 5 : striping avec parité distribuée

RAID 5 combine :

données
+
striping
+
parité distribuée

Il nécessite classiquement au moins :

3 disques

Disposition conceptuelle

Avec quatre disques :

Stripe 1 :
A1   A2   A3   P1

Stripe 2 :
B1   B2   P2   B3

Stripe 3 :
C1   P3   C2   C3

Stripe 4 :
P4   D1   D2   D3

La parité change de membre selon les stripes.

Elle n’est donc pas réservée à un unique « disque de parité » dans le RAID 5 classique.

La parité n’est pas une copie

RAID 5 ne stocke pas :

Donnée A
+
copie de A

Il stocke les informations permettant de reconstruire un bloc manquant à partir des autres blocs de la stripe.

Conceptuellement, avec XOR :

A XOR B = P

Si B disparaît :

A XOR P = B

Le principe réel appliqué à une baie complète est naturellement plus structuré, mais cette opération illustre l’idée fondamentale.

La parité n’est pas un checksum de données

C’est un point essentiel.

Il est tentant d’écrire :

« RAID 5 ajoute un checksum. »

Mais ce n’est pas vraiment la fonction de la parité RAID.

Elle sert principalement à :

reconstruire une information manquante

Si un bloc est silencieusement corrompu sans qu’il soit clairement identifié comme mauvais, la relation de parité peut révéler une incohérence dans certains scénarios, mais le RAID traditionnel ne possède pas nécessairement assez d’informations pour savoir :

« Lequel des blocs est le bon ? »

C’est une différence majeure avec des systèmes disposant de checksums de données de bout en bout.

Caractéristiques du RAID 5

• Minimum : 3 disques
• Capacité : (N - 1) × S
• Tolérance : 1 disque
• Lecture : généralement performante
• Écriture : coût supplémentaire lié à la parité

Exemple de capacité RAID 5

Avec :

4 × 8 To

on obtient théoriquement environ :

(4 - 1) × 8
= 24 To

avant les autres considérations de formatage et de présentation des unités.

RAID 5 et petites écritures

Une petite modification peut nécessiter plusieurs opérations.

Dans un mécanisme classique de :

read-modify-write

le système peut devoir :

1. lire l’ancienne donnée ;
2. lire l’ancienne parité ;
3. calculer la nouvelle parité ;
4. écrire la nouvelle donnée ;
5. écrire la nouvelle parité.

Les écritures aléatoires de petite taille peuvent donc être beaucoup moins avantageuses que de grosses écritures séquentielles.

RAID 5 dégradé

Supposons :

Disque A : OK
Disque B : OK
Disque C : MORT
Disque D : OK

L’ensemble peut encore fonctionner.

Mais lorsque les données du disque C sont nécessaires, elles doivent être reconstruites à partir des informations restantes.

L’array est alors :

DEGRADED

La redondance disponible contre une seconde panne est épuisée.

Une seconde panne pendant la dégradation

En RAID 5 :

1 disque perdu
→ RAID encore disponible

2e disque perdu avant reconstruction
→ données de l'array perdues/inaccessibles

C’est la faiblesse fondamentale du RAID 5 pour les grandes configurations exigeant une forte disponibilité.

RAID 6 : double protection par parité

RAID 6 étend le principe en conservant deux informations de parité indépendantes.

On rencontre souvent les termes conceptuels :

P
Q

La seconde parité utilise des mathématiques plus élaborées qu’un simple second XOR identique.

Caractéristiques

• Minimum : 4 disques
• Capacité : (N - 2) × S
• Tolérance : 2 disques
• Lecture : généralement bonne
• Écriture : coût de parité supérieur au RAID 5

Exemple de capacité RAID 6

Avec :

6 × 12 To

la capacité théorique est :

(6 - 2) × 12
= 48 To

Pourquoi RAID 6 existe

Lorsqu’un disque tombe, la reconstruction d’un ensemble volumineux peut prendre :

• des heures ;
• parfois beaucoup plus selon la charge et le matériel.

Pendant cette période, RAID 5 n’a plus aucune marge contre la perte d’un deuxième membre.

RAID 6 permet :

1 disque en panne
+
encore une panne tolérable

ce qui offre beaucoup plus de marge opérationnelle.

RAID 6 n’est pas nécessairement « lent »

Dire simplement :

« RAID 6 = lent »

est trop vague.

Ses performances dépendent :

• du contrôleur ;
• du CPU ;
• du cache ;
• du nombre de disques ;
• du type de stockage ;
• de la taille des écritures ;
• du niveau de parallélisme.

La double parité impose davantage de travail, particulièrement sur certaines écritures.

Mais une baie correctement dimensionnée peut néanmoins fournir des performances considérables.

RAID 10 : striping de miroirs

Le RAID 10 conventionnel combine :

RAID 1
+
RAID 0

Il est aussi appelé :

RAID 1+0

Avec quatre disques :

Paire miroir 1
├── Disque A
└── Disque B

Paire miroir 2
├── Disque C
└── Disque D

       ↓

Striping entre les deux miroirs

Caractéristiques conventionnelles

• Minimum : 4 disques
• Nombre de membres : généralement pair
• Capacité : environ 50 % avec miroirs à deux copies
• Tolérance minimale garantie : 1 panne
• Performances : généralement excellentes en lecture et écriture

La tolérance du RAID 10 dépend de l’endroit où les disques tombent

Prenons :

Paire 1 : A + B
Paire 2 : C + D

Si :

A tombe
C tombe

il reste :

B
D

et chaque paire possède encore une copie.

Le RAID peut survivre.

Mais si :

A tombe
B tombe

la première paire entière est perdue.

L’array ne possède plus les données correspondantes.

RAID 10 peut donc survivre à plusieurs pannes, mais uniquement si elles sont suffisamment bien réparties entre les groupes miroir.

RAID 10 à quatre disques

Il peut donc survivre :

1 panne quelconque

et parfois :

2 pannes

si elles touchent des paires différentes.

Il ne faut donc pas écrire simplement :

Tolérance RAID 10 = 2

ni :

Tolérance RAID 10 = 1 disque par paire quoi qu'il arrive

La topologie exacte des pannes compte.

RAID 10 et Linux MD

Linux MD permet également des organisations RAID 10 plus sophistiquées avec différents layouts.

On rencontre notamment des variantes :

near
far
offset

Le modèle :

deux disques par paire
+
striping des paires

reste néanmoins le meilleur point de départ pédagogique pour comprendre RAID 10 conventionnel.

RAID 10 ou RAID 01 ?

Ces deux noms sont parfois confondus.

RAID 10

miroirs
↓
striping des miroirs

RAID 01

groupes striped
↓
miroir des groupes

Les deux organisations ne réagissent pas de la même manière aux pannes multiples.

RAID 10 est généralement préféré lorsqu’on cherche cette combinaison de mirroring et striping.

Comparatif des principaux RAID

RAID	Minimum classique	Capacité théorique	Tolérance	Usage général
RAID 0	2	N × S	Aucune	Performance / temporaire
RAID 1	2	S	1 sur miroir 2-way	Simplicité / disponibilité
RAID 5	3	(N - 1) × S	1 disque	Capacité + redondance
RAID 6	4	(N - 2) × S	2 disques	Capacité + meilleure marge de panne
RAID 10	4	(N / 2) × S	Dépend de la répartition des pannes	Performances + redondance

Le tableau « +++ de performances » est trompeur

Résumer :

RAID 0  : +++
RAID 1  : +
RAID 5  : ++
RAID 6  : +
RAID 10 : +++

est séduisant.

Mais techniquement trop simpliste.

Il faut préciser :

• lecture ou écriture ?
• séquentiel ou aléatoire ?
• petites ou grosses E/S ?
• HDD ou NVMe ?
• une ou cent requêtes simultanées ?
• cache activé ?
• array dégradé ?

Performance séquentielle

Le striping permet généralement d’exploiter plusieurs membres en parallèle.

Les RAID :

0
5
6
10

peuvent donc offrir un important débit séquentiel lorsqu’ils sont correctement dimensionnés.

Performance aléatoire

Pour de nombreuses petites E/S aléatoires, les caractéristiques changent.

Les écritures de parité des RAID 5 et 6 peuvent coûter davantage d’opérations.

RAID 10 est souvent apprécié pour :

• bases de données ;
• machines virtuelles ;
• charges mixtes ;
• écritures aléatoires nombreuses.

mais il consomme davantage de capacité brute.

Capacité contre performance : aucune magie

À matériel égal :

plus de redondance
→ moins de capacité utile

et :

plus de calcul de parité
→ davantage de travail sur les écritures

Le choix d’un niveau RAID consiste donc à accepter explicitement un compromis.

Exemple avec quatre disques de 8 To

Configuration	Capacité théorique
RAID 0	32 To
RAID 1 à quatre copies	8 To
RAID 5	24 To
RAID 6	16 To
RAID 10	16 To

Ces chiffres représentent la capacité RAID théorique avant les autres niveaux de formatage et les différences d’unités d’affichage.

Exemple avec six disques de 12 To

Configuration	Capacité théorique
RAID 0	72 To
RAID 5	60 To
RAID 6	48 To
RAID 10	36 To

Le rebuild : l’étape où tout le monde regarde les LEDs

Lorsqu’un disque d’un RAID redondant tombe, on remplace généralement le membre défectueux.

Le système doit ensuite reconstruire les données manquantes.

Exemple RAID 5 :

Disque A ─┐
Disque B ─┼── reconstruction ── nouveau disque D
Disque C ─┘

Pour chaque stripe nécessaire, le système relit les données restantes et recalcule ce qui doit être écrit sur le nouveau membre.

Le rebuild peut être long

Sa durée dépend notamment :

• de la capacité des disques ;
• de leurs performances ;
• du nombre de membres ;
• de la charge applicative ;
• du contrôleur ;
• de la priorité attribuée à la reconstruction ;
• d’éventuelles erreurs de lecture.

Une baie de plusieurs dizaines de téraoctets ne se reconstruit pas forcément entre deux cafés.

Le RAID est plus vulnérable pendant certaines reconstructions

En RAID 5 :

état normal
→ tolérance 1 disque

1 panne
→ tolérance restante 0

rebuild
→ toujours 0 jusqu'au rétablissement complet

En RAID 6 :

état normal
→ tolérance 2

1 panne
→ tolérance restante 1

C’est une des raisons pour lesquelles la double parité peut être intéressante sur des ensembles volumineux.

Le rebuild sollicite les autres membres

Reconstruire signifie souvent :

lire énormément de données
+
calculer
+
écrire énormément de données

Les autres disques sont donc fortement sollicités précisément au moment où l’ensemble dépend davantage d’eux.

C’est un peu comme demander aux survivants d’un marathon de déménager un piano avant de pouvoir se reposer.

Une erreur de lecture pendant le rebuild

Un membre restant peut rencontrer :

unreadable sector
medium error
I/O error

pendant la reconstruction.

Les conséquences dépendent :

• du niveau RAID ;
• du nombre de pannes déjà présentes ;
• de l’emplacement de l’erreur ;
• de la capacité de reconstruction restante.

C’est pour cela qu’il faut détecter les problèmes avant qu’un disque entier ne tombe.

Ne transformons pas l’URE en prophétie mathématique

On trouve parfois sur Internet des affirmations comme :

« Avec des disques de X To, un rebuild RAID 5 échouera forcément à cause des URE. »

Le risque d’erreur de lecture est réel.

Mais transformer les taux statistiques annoncés par les constructeurs en certitude absolue pour chaque reconstruction est une simplification excessive.

La bonne conclusion est plutôt :

plus l’ensemble est grand et plus la reconstruction lit de données, plus la qualité des disques, la surveillance, les scrubs, les sauvegardes et le niveau de redondance deviennent importants.

Scrubbing : vérifier la redondance avant la catastrophe

Un array redondant ne devrait pas rester des années sans relire ses données.

Un :

scrub

consiste à parcourir l’ensemble pour vérifier la cohérence des copies ou de la parité.

Pour RAID 1/10 :

les copies peuvent être comparées

Pour RAID 5/6 :

la parité peut être vérifiée

Linux MD : lancer un contrôle

Pour un array :

/dev/md0

on peut demander un contrôle avec :

echo check | sudo tee /sys/block/md0/md/sync_action

Suivre son état :

cat /proc/mdstat

Et examiner le nombre de divergences détectées :

cat /sys/block/md0/md/mismatch_cnt

La valeur doit être interprétée avec les règles de Linux MD : elle ne correspond pas nécessairement directement au nombre exact de fichiers corrompus.

Check et repair ne sont pas identiques

Avec Linux MD :

check

vérifie la cohérence et compte les divergences.

Une action :

repair

peut chercher à les corriger.

On ne lance pas automatiquement :

repair

simplement parce que :

« réparer semble mieux que vérifier ».

Lorsque deux copies diffèrent, déterminer quelle donnée est réellement correcte peut être une question importante.

RAID et corruption silencieuse

Supposons un RAID 1 :

Disque A : valeur X
Disque B : valeur Y

Les deux copies diffèrent.

Le miroir sait :

« Elles ne sont pas identiques. »

Mais si aucune couche supérieure ne possède de checksum fiable, comment déterminer :

« X est correct et Y est corrompu » ?

La redondance seule ne résout pas toujours ce problème.

Checksums de bout en bout

Certains systèmes de stockage et systèmes de fichiers ajoutent des contrôles d’intégrité plus évolués.

Par exemple, selon l’architecture :

• ReFS peut utiliser des fonctions d’intégrité ;
• ZFS utilise des checksums de données et métadonnées ;
• d’autres systèmes peuvent proposer des mécanismes équivalents.

Cela répond à un problème différent de la simple tolérance à la perte physique d’un disque.

RAID ne sait pas que votre fichier est faux

Si une application écrit :

Solde client = 0

alors que le bon montant était :

Solde client = 250000

le RAID protégera très consciencieusement :

0

contre les pannes de disque.

La redondance n’est pas une conscience métier.

Le write hole

Les RAID à parité possèdent historiquement un problème appelé :

write hole

Imaginez une mise à jour nécessitant :

nouvelle donnée
+
nouvelle parité

Si l’alimentation disparaît après l’écriture de l’une mais avant l’autre :

donnée
≠
parité attendue

l’ensemble peut devenir incohérent.

Comment limiter ce problème ?

Les systèmes modernes peuvent employer notamment :

• cache protégé ;
• journal de parité ;
• write-intent bitmap ;
• mécanismes de cohérence spécifiques au contrôleur ;
• alimentation secourue.

Linux MD possède par exemple des mécanismes de journalisation/cache pour RAID 4/5/6 permettant notamment de traiter ce risque.

UPS : utile, mais pas magique

Une alimentation sans interruption :

UPS / onduleur

réduit fortement le risque de coupure brutale.

Elle ne protège pas contre :

• un kernel panic ;
• un firmware défaillant ;
• un câble arraché ;
• un contrôleur qui plante ;
• un administrateur qui appuie sur RESET parce que « ça semblait figé ».

RAID matériel

Un RAID matériel classique utilise un contrôleur dédié.

OS
 ↓
Contrôleur RAID
 ↓
Disques

Le système d’exploitation voit par exemple :

un seul disque logique de 16 To

alors que le contrôleur gère derrière :

4 × 8 To en RAID 10

Avantages possibles du RAID matériel

• abstraction vis-à-vis du système d’exploitation ;
• gestion du boot selon la plateforme ;
• firmware spécialisé ;
• outils d’administration dédiés ;
• cache contrôleur ;
• write-back protégé par batterie ou mémoire flash sur les contrôleurs adaptés.

Le cache write-back

Avec un cache protégé, le contrôleur peut recevoir une écriture :

Application
↓
OS
↓
Cache RAID

puis confirmer rapidement :

écriture reçue

avant de la transférer physiquement aux disques plus tard.

Cette stratégie peut améliorer très fortement les performances.

Le cache doit être protégé

Si un contrôleur affirme :

« L’écriture est terminée. »

alors que les données n’existent qu’en RAM volatile et qu’une panne électrique survient :

nous venons de créer un mensonge très rapide.

Les contrôleurs sérieux peuvent donc utiliser :

• batterie ;
• condensateur ;
• flash-backed write cache ;
• autres mécanismes de persistance.

Force Write Back sans protection : mauvaise idée

Certains contrôleurs permettent de forcer :

Write Back

même lorsque la protection du cache est absente ou défaillante.

Les performances deviennent intéressantes.

Le prochain incident électrique également.

Limites du RAID matériel

Il faut également considérer :

• coût du contrôleur ;
• dépendance au fabricant ;
• format de métadonnées ;
• nécessité éventuelle d’un contrôleur compatible pour récupérer l’array ;
• firmware ;
• outils propriétaires ;
• visibilité limitée de certains détails par le système d’exploitation.

Une panne de contrôleur ne signifie pas automatiquement perte des données

De nombreux contrôleurs enregistrent suffisamment de métadonnées sur les membres pour importer une configuration sur un contrôleur compatible.

Mais cette récupération dépend :

• du constructeur ;
• de la génération ;
• du firmware ;
• du type de contrôleur ;
• de l’état des disques.

Il est donc sage de connaître :

comment remplacer le contrôleur
avant qu'il tombe

plutôt que découvrir la procédure dans une salle serveur à 2 heures du matin.

RAID logiciel

Le RAID peut aussi être géré par le système d’exploitation.

Sous Linux, l’exemple classique est :

MD
+
mdadm

L’architecture devient :

Applications
     ↓
Système de fichiers
     ↓
Linux MD
     ↓
Disques physiques

RAID logiciel moderne : parfaitement sérieux

L’idée :

« Le RAID logiciel est la solution pauvre, le RAID matériel est la solution professionnelle. »

est dépassée.

Les CPU modernes disposent de ressources considérables.

Les systèmes d’exploitation possèdent des piles de stockage très évoluées.

Et de nombreuses infrastructures professionnelles reposent précisément sur du stockage défini par logiciel.

Avantages du RAID logiciel

• pas de contrôleur RAID propriétaire obligatoire ;
• coût réduit ;
• grande flexibilité ;
• bonne visibilité depuis l’OS ;
• métadonnées souvent plus facilement transportables entre machines compatibles ;
• intégration avec les outils de supervision système.

Inconvénients possibles

• utilisation de ressources CPU et mémoire ;
• dépendance au système et à sa configuration ;
• gestion du démarrage parfois plus complexe ;
• besoin d’une bonne configuration du cache et des écritures ;
• administration à maîtriser.

Le coût CPU de la parité peut être insignifiant dans certains serveurs et devenir important dans une architecture NVMe extrêmement rapide.

Comme toujours :

mesurez la charge réelle.

Le « Fake RAID » ou firmware RAID

Certaines cartes mères proposent dans le BIOS :

RAID Mode

sans disposer d’un véritable contrôleur RAID matériel autonome comparable aux solutions serveur spécialisées.

Le travail dépend alors souvent fortement :

• du pilote ;
• du firmware ;
• du CPU ;
• du système d’exploitation.

On parle parfois de :

firmware RAID
BIOS RAID
Fake RAID

Ce n’est pas nécessairement inutilisable.

Il faut simplement savoir ce que l’on possède réellement.

RAID Linux avec mdadm

Sous Linux, le pilote :

md

gère notamment :

• RAID 0 ;
• RAID 1 ;
• RAID 4 ;
• RAID 5 ;
• RAID 6 ;
• RAID 10.

L’outil principal d’administration est :

mdadm

Installer mdadm sous Debian

sudo apt update
sudo apt install mdadm

Identifier les disques avant toute création

lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,FSTYPE,MOUNTPOINTS

Ne copiez jamais aveuglément :

/dev/sdb
/dev/sdc
/dev/sdd

depuis un tutoriel.

Les noms correspondent aux périphériques de la machine qui exécute la commande.

Créer un RAID détruit potentiellement les données existantes

Les exemples suivants supposent des périphériques réservés à cet usage et dont le contenu peut être perdu.

Vérifiez plusieurs fois les membres avant :

mdadm --create

Exemple RAID 1

sudo mdadm --create /dev/md0 \
    --level=1 \
    --raid-devices=2 \
    /dev/sdb /dev/sdc

Exemple RAID 5

sudo mdadm --create /dev/md0 \
    --level=5 \
    --raid-devices=3 \
    /dev/sdb /dev/sdc /dev/sdd

Exemple RAID 6

sudo mdadm --create /dev/md0 \
    --level=6 \
    --raid-devices=4 \
    /dev/sdb /dev/sdc /dev/sdd /dev/sde

Exemple RAID 10

sudo mdadm --create /dev/md0 \
    --level=10 \
    --raid-devices=4 \
    /dev/sdb /dev/sdc /dev/sdd /dev/sde

Vérifier la construction

cat /proc/mdstat

Par exemple :

md0 : active raid1 sdc[1] sdb[0]
      976630336 blocks super 1.2 [2/2] [UU]

Le :

[UU]

indique ici deux membres présents et opérationnels.

Un état :

[U_]

signalerait qu’un membre manque.

Afficher les détails

sudo mdadm --detail /dev/md0

Vous pouvez notamment voir :

• niveau RAID ;
• taille ;
• état ;
• nombre de membres ;
• disques actifs ;
• membres défaillants ;
• spares ;
• progression de reconstruction.

Superviser les arrays

mdadm possède un mode de surveillance :

sudo mdadm --monitor --scan

Dans une installation réelle, configurez le mécanisme de supervision fourni par votre distribution afin que :

DISQUE EN PANNE

produise autre chose qu’une ligne dans un journal que personne ne regarde.

Un RAID qui tolère une panne mais que personne ne surveille finit très facilement par devenir un RAID qui attend sa deuxième panne.

Le hot spare

Imaginons :

RAID 5 :
A
B
C

Spare :
D

Le disque D ne participe pas normalement à la capacité utile.

Si B tombe :

B → failed
D → intégré
rebuild vers D

Le spare réduit le temps avant le début de la reconstruction.

Un hot spare n’augmente pas directement le nombre de pannes simultanées tolérées

Un RAID 5 avec :

3 membres actifs
+
1 spare

reste fondamentalement un RAID 5.

Il ne devient pas un RAID tolérant instantanément deux pannes simplement parce qu’un quatrième disque attend à côté.

Le spare doit d’abord être reconstruit et devenir un membre pleinement redondant.

Hot spare ou membre supplémentaire ?

Selon le besoin, on peut se demander s’il vaut mieux :

RAID 5 + spare

ou :

RAID 6

Les deux stratégies ne sont pas équivalentes.

RAID 6 possède déjà les informations nécessaires pour tolérer deux pannes simultanées.

Le spare apporte surtout une capacité de remplacement rapide après défaillance.

RAID sous Windows moderne

Windows possède plusieurs technologies historiques ou modernes de stockage multi-disques.

Les anciens :

Dynamic Disks
Disques dynamiques

savaient notamment créer :

• volumes agrégés ;
• volumes striped ;
• miroirs ;
• certains RAID 5 sur les éditions concernées.

Les disques dynamiques sont désormais dépréciés pour les nouveaux usages

Pour les données exigeant une résilience contre la panne d’un disque, Microsoft recommande aujourd’hui plutôt :

Storage Spaces
Espaces de stockage

Les disques dynamiques restent principalement un héritage à connaître pour administrer les systèmes existants.

Storage Spaces

Storage Spaces permet de créer :

disques physiques
↓
storage pool
↓
virtual disk / storage space
↓
volume

Les modes de résilience comprennent notamment :

• Simple ;
• Two-way mirror ;
• Three-way mirror ;
• Parity ;
• Dual parity selon les environnements supportés.

Simple ressemble au RAID 0

Un espace :

Simple

cherche principalement capacité et performance sans résilience.

La panne d’un périphérique peut entraîner la perte des données du space.

Mirror ressemble au RAID 1

Un :

Two-way mirror

conserve deux copies.

Un :

Three-way mirror

conserve trois copies.

Parity ressemble aux RAID 5/6

Storage Spaces peut également employer des organisations à parité pour obtenir une meilleure efficacité de capacité.

Mais :

Storage Spaces n’est pas simplement un menu permettant de sélectionner RAID 5 ou RAID 6 classiques.

Il possède ses propres mécanismes d’allocation, de résilience et de reconstruction.

Storage Spaces Direct

Sur Windows Server, :

Storage Spaces Direct
S2D

étend cette logique à des infrastructures distribuées entre plusieurs serveurs.

La notion de :

fault domain

devient alors essentielle.

Le système ne cherche plus uniquement à se protéger contre :

un disque qui tombe

mais peut distribuer les copies afin de survivre selon la configuration à la perte :

• d’un disque ;
• d’un serveur ;
• voire de plusieurs domaines de panne.

Le concept de fault domain

Imaginons douze disques :

Serveur A : 4 disques
Serveur B : 4 disques
Serveur C : 4 disques

Placer trois copies sur :

trois disques du serveur A

protège contre certaines pannes de disque.

Mais la panne complète :

Serveur A

détruirait les trois copies en même temps.

Une infrastructure avancée répartit donc la redondance selon des domaines de panne adaptés :

disque
châssis
serveur
rack
site

selon son architecture.

RAID et panne corrélée

Le modèle RAID suppose souvent implicitement que les périphériques peuvent tomber indépendamment.

Dans la réalité, plusieurs composants peuvent partager :

• la même alimentation ;
• le même contrôleur ;
• le même backplane ;
• le même châssis ;
• la même température ;
• le même lot de fabrication ;
• la même erreur de firmware.

Quatre disques redondants dans une machine détruite par une surtension restent quatre disques dans la même machine détruite par une surtension.

RAID avec SSD et NVMe

Le RAID n’est pas réservé aux disques mécaniques.

On peut combiner :

• SSD SATA ;
• SSD SAS ;
• NVMe ;
• selon la plateforme, différents niveaux de stockage.

Les considérations changent cependant.

Un SSD ne possède pas les mêmes caractéristiques qu’un HDD

On s’intéresse notamment à :

• endurance en écriture ;
• latence ;
• débit ;
• garbage collection ;
• TRIM / discard ;
• protection contre les pertes d’alimentation ;
• firmware ;
• usure des cellules.

Les NVMe peuvent déplacer le goulot d’étranglement

Avec des HDD :

les disques

sont très souvent la limitation.

Avec une grande quantité de NVMe rapides, le goulot peut devenir :

• le CPU ;
• le bus PCIe ;
• le contrôleur ;
• la pile RAID ;
• le réseau ;
• le système de fichiers.

Une carte RAID conçue pour huit disques mécaniques n’est donc pas automatiquement le choix idéal devant huit NVMe extrêmement rapides.

SMART et état des disques

Selon les périphériques, des informations de santé peuvent être récupérées par :

SMART

avec des outils comme :

smartctl

sous Linux.

Par exemple :

sudo smartctl -a /dev/sdb

Mais SMART ne possède pas une boule de cristal.

Un disque peut :

• montrer des signes avant-coureurs ;
• ou tomber brutalement sans alerte suffisamment claire.

Il sert à la surveillance.

Pas à supprimer le besoin de redondance ou de sauvegarde.

Surveillez davantage que « disque OK »

Selon le matériel, examinez notamment :

• erreurs média ;
• secteurs réalloués ou problèmes équivalents ;
• température ;
• endurance SSD ;
• erreurs d’interface ;
• état du contrôleur ;
• état du cache protégé ;
• batterie ou condensateur ;
• état de reconstruction.

Une alerte doit arriver quelque part

Une baie affichant :

DEGRADED

depuis six mois n’est pas un système tolérant aux pannes.

C’est un système qui a déjà consommé une partie de sa tolérance sans que personne ne s’en préoccupe.

Configurez :

• e-mail ;
• SNMP ;
• supervision ;
• monitoring centralisé ;
• alertes constructeur ;
• ou tout autre mécanisme réellement consulté.

RAID n’est pas une sauvegarde

Il faut maintenant revenir au point fondamental.

Supposons un RAID 1 :

Disque A : rapport.docx
Disque B : rapport.docx

L’utilisateur exécute :

Supprimer rapport.docx

Le RAID réplique fidèlement l’état :

Disque A : fichier supprimé
Disque B : fichier supprimé

Le miroir a parfaitement fonctionné.

Votre fichier est parfaitement supprimé deux fois.

Ransomware

Si les fichiers du volume sont chiffrés par un ransomware :

rapport.docx
→ rapport chiffré

le RAID protège ensuite très efficacement les blocs chiffrés contre une panne de disque.

Ce n’était malheureusement pas le type de protection recherché.

Corruption applicative

Une base de données peut écrire de mauvaises données.

Un logiciel peut écraser un fichier.

Un utilisateur peut enregistrer :

document vide

par-dessus :

document important

Le RAID ne possède aucune version précédente vers laquelle revenir sauf mécanisme séparé.

Vol et incendie

Un serveur contenant :

8 disques RAID 6

peut être extrêmement résilient contre deux défaillances de disques.

Si le serveur entier disparaît :

8 - 8 = 0

La double parité ne change pas énormément le résultat.

Erreur administrative

Le RAID ne protège pas contre :

mkfs
diskpart clean
rm
DROP DATABASE
format
mauvaise cible de restauration

La redondance protège contre certaines pannes de composants.

Elle ne protège pas contre une commande parfaitement exécutée sur le mauvais objet.

Ce que protège principalement le RAID

Un RAID redondant sert principalement à améliorer :

la disponibilité
face à certaines pannes matérielles

La sauvegarde sert principalement à améliorer :

la récupérabilité
face à la perte ou l'altération des données

Ce sont deux objectifs complémentaires.

RAID et sauvegardes : ensemble

Une architecture saine peut ressembler à :

Production
    ↓
RAID 6 / RAID 10
    ↓
Sauvegarde locale protégée
    ↓
Sauvegarde séparée
    ↓
Copie hors site / hors ligne / immuable

Une copie branchée en permanence n’est pas forcément une bonne dernière ligne de défense

Un ransomware disposant des droits nécessaires peut rechercher :

• partages de sauvegarde ;
• volumes montés ;
• NAS accessibles ;
• snapshots administrables ;
• identifiants de sauvegarde compromis.

Une stratégie sérieuse peut donc inclure des copies :

• hors ligne ;
• isolées ;
• immutables ;
• hors site.

La règle 3-2-1

Une règle traditionnelle de sauvegarde consiste à viser :

3 copies des données
2 types ou emplacements de stockage
1 copie hors site

Les architectures modernes ajoutent parfois des exigences supplémentaires :

• immutabilité ;
• isolement ;
• tests de restauration ;
• contrôles automatiques ;
• rétention historique.

Le chiffre exact compte moins que le principe :

ne placez pas toutes les possibilités de récupération dans le même domaine de panne ou de compromission.

Les snapshots ne sont pas non plus automatiquement des sauvegardes

Un snapshot est excellent pour :

• revenir rapidement à un état précédent ;
• restaurer un fichier ;
• faciliter certaines opérations applicatives.

Mais s’il réside :

sur la même baie
avec les mêmes contrôles administratifs

il peut disparaître avec elle.

Les snapshots sont une excellente couche de récupération.

Pas nécessairement la dernière.

Tester les restaurations

Une sauvegarde affichant :

SUCCESS

signifie :

« Le logiciel pense avoir effectué la sauvegarde. »

Elle ne prouve pas automatiquement :

« Nous savons reconstruire le service complet dans le délai demandé. »

Testez régulièrement :

• restauration d’un fichier ;
• restauration d’un volume ;
• restauration d’une base ;
• reconstruction complète d’un serveur critique.

RAID 5 est-il mort ?

On rencontre souvent l’affirmation :

« RAID 5 ne doit plus jamais être utilisé. »

La réalité est plus nuancée.

RAID 5 reste une technologie valide lorsqu’on accepte :

• la tolérance à une seule panne ;
• le temps de reconstruction ;
• les performances de parité ;
• le niveau de risque correspondant.

Il peut parfaitement convenir à :

• de petits ensembles ;
• des données reconstructibles ;
• des workloads de lecture ;
• des systèmes correctement sauvegardés.

Pour de très gros ensembles contenant des données critiques, RAID 6 ou d’autres stratégies de résilience peuvent être beaucoup plus rassurants.

RAID 6 ou RAID 10 ?

Les deux utilisent souvent une quantité similaire de capacité dans certaines configurations.

Par exemple :

4 × 8 To

RAID 6  → 16 To
RAID 10 → 16 To

Mais leur comportement diffère.

RAID 6

• tolère deux pannes quelconques ;
• parité ;
• bonne efficacité lorsque le nombre de disques augmente ;
• écritures aléatoires plus coûteuses.

RAID 10

• pas de calcul de parité classique ;
• très bonnes performances en écriture ;
• reconstruction généralement plus simple ;
• tolérance aux pannes dépendant des groupes miroir ;
• 50 % de capacité avec miroir deux voies.

Pour une base de données ?

Historiquement, RAID 10 est très apprécié pour :

• fortes IOPS ;
• écritures aléatoires ;
• machines virtuelles ;
• bases transactionnelles.

Mais les performances modernes dépendent tellement :

• du NVMe ;
• du cache ;
• de l’architecture logicielle ;
• du stockage distribué ;

qu’il faut mesurer plutôt que réciter une règle universelle datant de l’époque des disques SCSI 10 000 tours/minute.

Pour des archives volumineuses ?

Une architecture à double parité peut être intéressante lorsque :

• les écritures sont relativement séquentielles ;
• la capacité compte beaucoup ;
• les performances aléatoires maximales ne sont pas prioritaires ;
• la tolérance à deux pannes est souhaitée.

Pour un cache temporaire ?

RAID 0 peut être parfaitement rationnel si :

les données sont jetables
ou
immédiatement reconstructibles

Le mot important n’est pas :

RAID 0

mais :

jetables

RAID n’améliore pas toujours la disponibilité globale

Une baie RAID peut survivre à un disque mort.

Mais le service peut toujours tomber si :

• le contrôleur meurt ;
• le serveur plante ;
• l’alimentation tombe ;
• le système de fichiers est corrompu ;
• le réseau vers le stockage disparaît ;
• le firmware provoque un incident ;
• l’OS ne redémarre pas.

Pour atteindre une véritable haute disponibilité, il faut considérer l’ensemble :

application
serveur
contrôleur
stockage
réseau
alimentation
site

RAID ne signifie pas haute disponibilité

Un serveur unique :

1 serveur
+
12 disques en RAID 6

reste :

1 serveur

La panne de sa carte mère peut interrompre le service même si les douze disques sont parfaitement heureux.

La documentation du RAID fait partie de la sauvegarde opérationnelle

Conservez des informations comme :

• niveau RAID ;
• ordre et emplacement des membres ;
• modèle du contrôleur ;
• version du firmware ;
• configuration du cache ;
• procédure de remplacement ;
• méthode d’import d’une configuration étrangère ;
• contacts constructeur ;
• emplacement des pièces de rechange.

La baie qui tombe n’a aucune obligation de le faire pendant les horaires de présence de l’ingénieur qui l’avait installée.

Ne retirez pas plusieurs disques « pour voir lequel est mort »

Sur un RAID dégradé, chaque membre restant peut être critique.

Retirer :

le mauvais disque

peut faire passer :

DEGRADED

à :

FAILED

avec une efficacité remarquable.

Identifiez les membres à l’aide :

• du numéro de baie ;
• du numéro de série ;
• des LEDs d’identification contrôlées ;
• de l’outil du contrôleur ;
• de la documentation.

Un disque retiré n’est pas forcément immédiatement un déchet

Dans un incident complexe, étiquetez :

disque retiré
emplacement
date
état
numéro de série

avant de le poser avec cinq autres disques sur une table.

La technique :

« Je reconnaîtrai celui qui était dans le slot 7. »

perd rapidement de son efficacité lorsqu’ils sont tous noirs, rectangulaires et identiques.

Ne réinitialisez pas un array dégradé

Face à un RAID qui ne monte plus, évitez immédiatement :

Initialize
Create new array
Clear configuration
Force initialize

tant que vous n’avez pas compris l’état des membres.

Une métadonnée RAID endommagée peut parfois être récupérée.

Une nouvelle configuration écrite par-dessus ajoute une couche d’archéologie numérique dont personne n’avait besoin.

Checklist avant de déployer un RAID

1. Quelles données seront stockées ?
2. Quel niveau de disponibilité est nécessaire ?
3. Combien de pannes simultanées devons-nous tolérer ?
4. Quelle capacité utile est requise ?
5. Quel type de workload : séquentiel ou aléatoire ?
6. Quelle performance en lecture et écriture ?
7. Quel temps de reconstruction est acceptable ?
8. Comment les pannes seront-elles détectées ?
9. Dispose-t-on de pièces de remplacement ?
10. Quelle est la stratégie de sauvegarde ?
11. Les restaurations sont-elles testées ?
12. Quel est le véritable domaine de panne ?

Checklist quotidienne ou régulière

Surveillez :

• état de l’array ;
• membres dégradés ;
• rebuild ;
• erreurs disque ;
• SMART/NVMe health ;
• températures ;
• contrôleur ;
• batterie ou cache protégé ;
• scrubs ;
• capacité libre ;
• alertes de sauvegarde.

Checklist lors d’une panne de disque

1. Confirmer que le RAID est réellement dégradé.
2. Identifier précisément le membre défaillant.
3. Vérifier l’état des autres membres.
4. Vérifier les sauvegardes avant toute manipulation importante.
5. Identifier physiquement le bon disque.
6. Utiliser un disque de remplacement compatible.
7. Lancer ou confirmer le rebuild.
8. Surveiller sa progression.
9. Contrôler l’état final de l’array.
10. Analyser pourquoi la panne est survenue si nécessaire.

Quelques idées reçues à éliminer

« RAID = sauvegarde »

Non.

RAID fournit principalement de la redondance et de la disponibilité.

« RAID 1 protège contre toutes les corruptions »

Non.

Une mauvaise donnée peut être fidèlement copiée sur tous les miroirs.

« RAID 5 utilise un checksum »

Il utilise de la parité pour reconstruire les informations manquantes.

Ce n’est pas équivalent à un checksum end-to-end capable d’identifier avec certitude toute corruption silencieuse.

« RAID 10 tolère forcément deux pannes »

Non.

Deux membres de la même paire miroir peuvent suffire à tuer un RAID 10 conventionnel.

« RAID 1 ne tolère qu’une panne »

Avec un miroir à deux copies, oui.

Avec davantage de copies complètes, davantage de membres peuvent disparaître tant qu’une copie valide reste disponible.

« RAID 6 est toujours plus lent que RAID 5 »

Il possède davantage de travail de parité, surtout en écriture.

Mais les performances réelles dépendent de toute l’architecture.

« RAID matériel est toujours meilleur »

Non.

RAID matériel et logiciel répondent à des architectures différentes.

« Le RAID logiciel consomme trop de CPU »

Ce fut une préoccupation importante historiquement.

Sur du matériel moderne, le coût peut être très raisonnable.

Sur des configurations NVMe extrêmes, il peut redevenir pertinent.

Mesurez.

« Un hot spare me donne une panne de plus »

Pas immédiatement.

Il permet surtout de commencer plus vite le remplacement d’un membre défaillant.

« Si le RAID est vert, les données sont bonnes »

Le vert indique principalement que le système RAID considère ses membres et sa redondance comme opérationnels.

Il ne valide pas nécessairement la vérité de chaque donnée applicative.

« Le rebuild est une opération normale donc sans risque »

C’est une opération prévue.

Elle reste une période où l’infrastructure travaille beaucoup et possède souvent moins de marge face à d’autres défaillances.

Choisir rapidement son niveau RAID

Besoin principal	Choix à envisager
Données temporaires, performance maximale	RAID 0
Petit volume simple et redondant	RAID 1
Bon rendement capacité avec une panne tolérée	RAID 5
Bon rendement capacité avec deux pannes tolérées	RAID 6
Fortes IOPS et redondance	RAID 10

Ce tableau n’est pas une ordonnance.

Le workload réel, le nombre de membres, la technologie de stockage et les objectifs de récupération comptent davantage que le nom du RAID.

RAID, filesystem, snapshot et backup : quatre rôles différents

Technologie	Rôle principal
RAID	Tolérance à certaines pannes de stockage et/ou performances
Système de fichiers	Organisation et accès aux fichiers
Snapshot	Retour rapide vers un état antérieur selon la technologie
Sauvegarde	Récupération indépendante après perte ou corruption

Une architecture sérieuse peut utiliser les quatre.

Elles ne sont pas concurrentes.

Le véritable objectif du RAID : disponibilité, pas immortalité

Prenons un serveur de fichiers en RAID 6.

Un disque tombe à 10 h 03.

Le serveur continue à répondre.

Les employés continuent à travailler.

L’administrateur reçoit une alerte.

Le disque est remplacé.

Le rebuild se termine.

Personne dans le service comptabilité n’a même remarqué l’incident.

C’est exactement là que RAID est excellent.

Son rôle n’était pas de :

sauvegarder les fichiers pour toujours

mais de :

continuer à servir les données
malgré une panne matérielle prévue par son modèle

Le paradoxe d’un bon RAID

Lorsqu’il fonctionne correctement, personne ne le remarque.

Un disque meurt.

L’application continue.

La reconstruction commence.

La production reste disponible.

Le seul humain censé s’en apercevoir est celui qui reçoit l’alerte.

Lorsqu’un RAID fonctionne mal, en revanche, toute l’entreprise découvre simultanément l’existence du stockage.

Conclusion : RAID protège contre certaines pannes, pas contre la réalité

RAID reste une technologie fondamentale du stockage.

Il permet de combiner plusieurs périphériques afin d’obtenir :

• plus de débit ;
• plus de capacité ;
• plus de disponibilité ;
• une tolérance définie aux pannes.

Mais chaque niveau possède ses compromis.

RAID 0 maximise la capacité et peut augmenter les performances, mais ne tolère aucune panne.

RAID 1 duplique les données et offre une redondance simple au prix de la capacité.

RAID 5 offre une bonne efficacité de stockage avec une parité simple, mais ne tolère qu’une panne simultanée.

RAID 6 ajoute une deuxième parité et permet de survivre à deux défaillances de membres.

RAID 10 combine mirroring et striping pour obtenir de très bonnes performances, mais sa tolérance aux pannes multiples dépend de leur répartition entre les miroirs.

Retenez surtout :

• la capacité RAID se calcule à partir du layout et souvent du plus petit membre ;
• la parité n’est pas un simple checksum d’intégrité ;
• les performances dépendent du workload et ne se résument pas à des + et des – ;
• un array dégradé doit être traité rapidement ;
• un rebuild est une période sensible ;
• les scrubs et contrôles de cohérence sont importants ;
• un hot spare accélère la réaction mais ne transforme pas un RAID 5 en RAID 6 ;
• RAID logiciel et matériel sont tous deux des solutions professionnelles selon l’architecture ;
• sous Windows moderne, Storage Spaces a largement remplacé l’approche historique des disques dynamiques pour les nouveaux stockages résilients ;
• un RAID doit être surveillé ;
• et surtout, RAID n’est jamais un substitut à une sauvegarde correctement isolée et testée.

Le RAID peut vous sauver d’un disque qui décide soudainement de quitter ce monde.

Il ne peut pas vous sauver d’un :

rm -rf
DROP DATABASE
ransomware
incendie
vol
mauvaise restauration

ni de cette phrase historiquement inquiétante :

« Pas besoin de backup, on a du RAID. »

Lorsque quelqu’un prononce cette phrase en production, vérifiez immédiatement les sauvegardes.

Pas le RAID.

Les sauvegardes.