đŸ Storage Systems / Le stockage â Chapitre 1
Introduction générale : définitions, usages, grandes familles, critÚres fondamentaux et cycles chaud / tiÚde / froid / archive.
Objectif courant pour S3, Azure Blob LRS et classes Glacier : 99,999999999% de durabilité annuelle.
NVMe local en microsecondes, NAS/SAN en sous-millisecondes Ă millisecondes, archive en minutes/heures.
Backblaze a publié un parc 2025 de plus de 344 000 disques analysés pour ses statistiques de fiabilité.
Capacité, coût, latence, IOPS, débit, sécurité, disponibilité, scalabilité : aucun stockage n'optimise tout.
DĂ©finition du stockage informatique
Stockage primaire, secondaire, cache, sauvegarde, archive, mémoire persistante. Clarification entre mémoire, disque, objet et conservation long terme.
PrimarySecondaryArchiveGrands usages du stockage
OS, bases de données, fichiers utilisateurs, applications web, logs, sauvegardes, IA, data lakes, vidéo, objets, containers.
DBAIContainersGrandes familles
DAS, NAS, SAN, Object Storage, Cloud Storage, Distributed Storage, Software-Defined Storage : quand les utiliser, quand les Ă©viter.
NASSANS3CritĂšres fondamentaux
Capacité, latence, débit, IOPS, endurance, disponibilité, durabilité, sécurité, coût, scalabilité. La grille de décision d'architecte.
IOPSRPO/RTOTCOHot, Warm, Cold, Archive
Classes d'accÚs et cycle de vie : données actives, semi-actives, historiques, réglementaires. Optimiser coût, performance et restauration.
HotColdLifecycleChecklist de conception
Questions à poser avant de choisir un stockage : charge, SLA, volumétrie, croissance, sécurité, backup, gouvernance, migration, réversibilité.
DesignRunbookRisquesVision globale
Le stockage informatique n'est pas seulement un disque ou un bucket cloud. C'est un systÚme complet qui absorbe les écritures, restitue les lectures, protÚge la donnée, l'organise, la chiffre, la réplique, la sauvegarde, l'archive et la rend exploitable dans le temps.
Les trois questions qui pilotent tout
- AccĂšs : la donnĂ©e doit-elle ĂȘtre lue en microsecondes, millisecondes, secondes, minutes ou heures ?
- Protection : combien de perte acceptable ? RPO zéro, quelques secondes, quelques heures, ou restauration manuelle ?
- Ăconomie : quel coĂ»t total par To utile, incluant rĂ©seau, sauvegarde, rĂ©plication, licences, Ă©nergie et exploitation ?
Diagramme d'orientation rapide
| Besoin | Famille naturelle | Exemple |
|---|---|---|
| Ultra-faible latence | DAS / NVMe local | Base transactionnelle, cache, WAL DB |
| Partage fichiers | NAS | Home directories, documents, média interne |
| Bloc partagé entreprise | SAN | VMware, Oracle, SQL Server, clusters |
| Ăchelle massive | Object storage | Images, vidĂ©os, backups, data lake |
| Cloud natif | Managed cloud storage | S3, Azure Blob, GCS, OVH Object Storage |
| Plateforme distribuée | SDS / Distributed | Ceph, vSAN, Nutanix, MinIO |
Définition opérationnelle
Le stockage informatique est l'ensemble des technologies qui permettent de conserver une information numérique, de la retrouver, de la modifier, de la protéger, de la déplacer et de prouver son intégrité. Il couvre le média physique, le protocole d'accÚs, la couche logique, la redondance, le chiffrement, la supervision et les procédures de restauration.
Un stockage doit répondre à quatre fonctions
- Ăcrire : absorber la donnĂ©e sans la perdre, mĂȘme pendant les pics, les coupures ou les incidents.
- Lire : restituer rapidement et correctement la donnée demandée.
- Préserver : résister aux pannes, corruptions, erreurs humaines, cyberattaques et vieillissement.
- Administrer : suivre capacité, performance, coûts, droits, cycles de vie et conformité.
Table de vocabulaire
| Terme | Sens | Exemples |
|---|---|---|
| Stockage primaire | Donnée directement utilisée par les applications en production. | Volume NVMe, LUN SAN, disque VM, tablespace DB |
| Stockage secondaire | Donnée moins active, souvent mutualisée ou répliquée. | NAS fichiers, partage documentaire, volume de logs |
| Sauvegarde | Copie restaurable, conçue pour revenir en arriÚre. | Veeam, snapshots exportés, backup S3 immutable |
| Archive | Conservation longue durée, accÚs rare, objectif légal ou historique. | Glacier, bande LTO, archive froide cloud |
| Cache | Copie temporaire pour accélérer les accÚs. | Redis, SSD cache, CDN edge cache |
| MĂ©moire persistante | MĂ©dia proche de la mĂ©moire mais conservant les donnĂ©es aprĂšs arrĂȘt. | NVDIMM, persistent memory, journaux DB optimisĂ©s |
Le stockage est une pile, pas un composant isolé
HDD, SSD SATA, SSD SAS, NVMe, bande, mémoire persistante. C'est la couche physique avec endurance, latence et taux de panne propres.
RAID, HBA, firmware SSD, contrÎleur SAN, carte réseau RDMA. Il gÚre l'ordonnancement et la protection locale.
SATA, SAS, NVMe, NVMe-oF, iSCSI, Fibre Channel, NFS, SMB, S3 API.
Bloc, fichier, objet. L'abstraction détermine comment l'application adresse la donnée.
Snapshots, réplication, chiffrement, compression, déduplication, tiering, immutabilité.
Droits, audit, rétention, conformité, classification, lifecycle, coûts.
Volatil, persistant, durable
| CatĂ©gorie | Conservation aprĂšs arrĂȘt | Usage |
|---|---|---|
| RAM | Non | Calcul, buffers, cache applicatif |
| Cache disque | Variable | Accélération, write-back risqué sans batterie |
| SSD/HDD | Oui | Stockage persistant primaire |
| Objet répliqué | Oui + redondance | Durabilité cloud, data lake, backup |
| Archive immuable | Oui + rétention | Conformité, cyber-résilience, conservation longue |
Persistance â sauvegarde
Un disque persistant peut trÚs bien conserver une erreur, une suppression accidentelle, un chiffrement ransomware ou une corruption logique. La sauvegarde apporte une capacité de retour à un état antérieur, idéalement isolée, testée et immuable.
Confusions fréquentes à éliminer dÚs le début
| Erreur | Pourquoi c'est faux | Bonne formulation |
|---|---|---|
| RAID = backup | RAID protÚge surtout contre la panne d'un disque, pas contre suppression, malware, corruption logique ou incendie. | RAID = disponibilité locale ; backup = restauration temporelle. |
| Object storage = filesystem | Un objet n'est pas modifié en place comme un fichier ; il est adressé par clé, metadata et API. | Objet = excellent pour masse, web, archive, data lake ; moins adapté au POSIX strict. |
| Cloud = automatiquement moins cher | Le coĂ»t dĂ©pend des classes, requĂȘtes, egress, snapshots, rĂ©plication, API, restauration et gouvernance. | Cloud = Ă©lasticitĂ© et services managĂ©s ; TCO Ă modĂ©liser. |
| SSD = toujours rapide | Endurance, contrÎleur, QoS, write amplification et saturation du cache SLC changent fortement le comportement. | SSD = faible latence, mais profil d'écriture et endurance à vérifier. |
| DurabilitĂ© = disponibilitĂ© | La donnĂ©e peut ĂȘtre durablement conservĂ©e mais indisponible temporairement. | DurabilitĂ© protĂšge l'intĂ©gritĂ© longue durĂ©e ; disponibilitĂ© protĂšge l'accĂšs immĂ©diat. |
Un mĂȘme datacenter utilise plusieurs stockages simultanĂ©ment
| Usage | Profil I/O | Stockage naturel | Point de vigilance |
|---|---|---|---|
| SystÚme d'exploitation | Petites lectures/écritures aléatoires | SSD local, volume bloc cloud | Snapshots, patch rollback, chiffrement |
| Base OLTP | IOPS fortes, latence faible, fsync | NVMe, SAN performant, volume bloc provisionné | WAL/redo logs, write latency, endurance |
| Fichiers utilisateurs | Mix séquentiel + metadata | NAS SMB/NFS | Droits, verrouillage, quota, antivirus |
| Application web | Assets, uploads, sessions, cache | Object storage + CDN + bloc pour runtime | Egress, invalidation CDN, lifecycle |
| Logs | Ăcriture sĂ©quentielle massive | Disque local, object storage, plateforme log | Rotation, compression, recherche, rĂ©tention |
| IA / data lake | Lecture parallĂšle, gros fichiers, metadata | Object storage, distributed FS | Throughput, coĂ»t requĂȘtes, petits fichiers |
| Vidéo / média | TrÚs gros objets, streaming | Object storage + CDN | Débit, transcodage, coût sortie |
| Containers | Images immuables + volumes persistants | Registry objet, CSI bloc/fichier | StatefulSets, snapshots, restauration |
Bases de données : le stockage le plus exigeant
Une base transactionnelle est sensible Ă la latence d'Ă©criture, au flush disque, Ă la cohĂ©rence et aux pics d'IOPS. Les journaux transactionnels doivent ĂȘtre traitĂ©s comme une voie critique.
Bonnes pratiques
- Séparer si possible données, journaux et backups pour éviter les contentions.
- Mesurer p95/p99 de latence, pas seulement la moyenne.
- Tester les restaurations PITR, pas seulement la création des backups.
- Surveiller queue depth, fsync latency, write amplification et saturation cache.
Exemples de charges
| Type DB | Profil stockage | Architecture fréquente |
|---|---|---|
| OLTP MySQL/PostgreSQL | Aléatoire, faible latence | NVMe / bloc cloud performant + réplication |
| Oracle / SQL Server entreprise | IOPS + débit + snapshots | SAN, ASM, volumes dédiés, backup enterprise |
| Data warehouse | Scan séquentiel massif | Object storage + compute séparé |
| NoSQL | Partitionné, horizontal, write-heavy | Disques locaux rapides + réplication logicielle |
Applications web modernes
Une application web typique découple le runtime, les uploads et les assets statiques. Le stockage objet est souvent préféré pour les images, piÚces jointes, exports, médias et sauvegardes, car il s'intÚgre facilement avec CDN, lifecycle et permissions.
| Composant | Stockage | Exemple |
|---|---|---|
| Code | Image container / disque VM | Docker image, AMI |
| Uploads | Object storage | S3, GCS, Blob, MinIO |
| Cache | MĂ©moire / SSD local | Redis, memcached |
| Sessions | Redis / DB / cookie signé | Session store |
| Assets | Object storage + CDN | CSS, JS, images optimisées |
IA, data lakes et vidéos
Les workloads IA et data lake utilisent souvent de gros volumes d'objets et des lectures parallĂšles. Les problĂšmes ne sont pas seulement la capacitĂ© : le nombre de petits fichiers, la latence metadata, le coĂ»t des requĂȘtes et la bande passante deviennent critiques.
Logs, sauvegardes et archives : le stockage défensif
| Usage | Objectif | Architecture recommandée | Erreur dangereuse |
|---|---|---|---|
| Logs applicatifs | Debug, audit, sécurité | Rotation locale + centralisation + rétention | Garder les logs seulement sur le serveur compromis |
| Backups | Restauration aprÚs erreur ou panne | 3-2-1, immutabilité, tests réguliers | Ne jamais tester la restauration |
| Archive | Conformité, historique, preuve | Classe froide, WORM, catalogue | Archiver sans index ni procédure de restitution |
| Snapshots | Rollback rapide | Snapshots courts + export vers backup | Confondre snapshot local et sauvegarde indépendante |
Matrice de comparaison des familles
| Famille | Unité adressée | Protocoles | Forces | Limites |
|---|---|---|---|---|
| DAS | Bloc local | SATA, SAS, NVMe | Latence basse, simplicité, coût direct | Partage limité, HA à construire au-dessus |
| NAS | Fichier | NFS, SMB | Partage, droits, fichiers utilisateurs | Metadata, verrouillage, performance selon réseau |
| SAN | Bloc distant | FC, iSCSI, NVMe-oF | Performance entreprise, clusters, virtualisation | Complexité, coût, zoning/multipath |
| Object Storage | Objet + metadata | S3 API, Swift, Blob | Ăchelle, durabilitĂ©, lifecycle, web | Pas POSIX natif, latence metadata, petits fichiers |
| Cloud Storage | Bloc / fichier / objet managĂ© | EBS, S3, EFS, Blob, GCS... | ĂlasticitĂ©, services, multi-zone | Egress, dĂ©pendance fournisseur, coĂ»ts variables |
| Distributed Storage | Bloc/fichier/objet distribué | Ceph, Gluster, MinIO, HDFS | Scale-out, résilience logicielle | Opérations complexes, réseau critique |
| SDS | Abstraction logicielle | Dépend solution | Découple matériel et services | Design et support à maßtriser |
Direct Attached Storage : disques connectés directement au serveur. TrÚs efficace pour DB locale, cache, VM single host, workloads à faible latence.
Network Attached Storage : serveur de fichiers partagé. Idéal pour utilisateurs, exports, documents, répertoires communs, NFS applicatif.
Storage Area Network : volumes bloc distants vus comme des disques par les serveurs. Fréquent en virtualisation et bases entreprise.
PiĂšges d'architecture
- DAS performant mais non partagé : il faut penser réplication applicative ou cluster.
- NAS pratique mais parfois mauvais pour bases de données transactionnelles si latence et locking sont mal gérés.
- SAN puissant mais demande multipathing, zoning, queue depth, firmware et procédures strictes.
Object Storage
Le stockage objet adresse une donnée par une clé, dans un bucket/conteneur, avec metadata. Il est trÚs adapté aux grands volumes non structurés : images, vidéos, backups, exports, logs, datasets, archives.
| Aspect | Objet | Fichier classique |
|---|---|---|
| Adresse | Bucket + clé | Chemin hiérarchique |
| Modification | Souvent rĂ©Ă©criture objet | Ăcriture dans fichier |
| Metadata | Native et riche | DĂ©pend FS |
| Ăchelle | TrĂšs Ă©levĂ©e | LimitĂ©e par FS/NAS |
Cloud Storage managé
Les clouds fournissent plusieurs modÚles : bloc pour VM/DB, fichier partagé managé, objet durable, archive froide, snapshots, réplication régionale et lifecycle. Amazon indique que S3 est conçu pour dépasser 99,999999999% de durabilité et stocke par défaut les données de façon redondante sur au moins trois zones de disponibilité.
Distributed Storage & Software-Defined Storage
Le stockage distribuĂ© agrĂšge plusieurs nĆuds et disques pour produire un service logique rĂ©silient. La redondance est assurĂ©e par rĂ©plication ou erasure coding. Le SDS ajoute une couche logicielle qui dĂ©couple le service de stockage du matĂ©riel sous-jacent.
| Technologie | Type | Usage | Point critique |
|---|---|---|---|
| Ceph | Bloc / objet / fichier | Cloud privé, OpenStack, Kubernetes | Réseau, OSD, placement groups |
| MinIO | Objet S3-compatible | Data lake privé, backup, AI datasets | Erasure coding, disques homogÚnes |
| VMware vSAN | SDS hyperconvergé | Virtualisation entreprise | Design cluster, cache, fault domains |
| Nutanix | HCI / SDS | Plateforme VM/applications | Licences, intégration, montée en charge |
Les quatre métriques de performance
| MĂ©trique | DĂ©finition | Quand c'est critique |
|---|---|---|
| Latence | Temps de réponse d'une opération I/O. | DB OLTP, journal, cache, VM interactives |
| IOPS | Nombre d'opérations par seconde. | Petites lectures/écritures aléatoires |
| Débit | Volume transféré par seconde. | Backup, vidéo, analytics, migration |
| Queue depth | Nombre d'I/O en attente ou parallÚles. | Saturation contrÎleur/disque/réseau |
Comparaison indicative
Ce graphique est volontairement qualitatif : il sert à visualiser les compromis, pas à remplacer un benchmark réel.
Disponibilité, durabilité, RPO, RTO
| CritÚre | Question | Exemple de mécanisme |
|---|---|---|
| Disponibilité | Le service de stockage répond-il maintenant ? | Cluster HA, multipath, multi-AZ, failover |
| Durabilité | La donnée restera-t-elle intacte dans le temps ? | Réplication, checksum, erasure coding, scrubbing |
| RPO | Combien de données peut-on perdre ? | Réplication synchrone, log shipping, backups fréquents |
| RTO | Combien de temps pour restaurer ? | Standby, snapshots, automation restore |
| ImmutabilitĂ© | Peut-on empĂȘcher modification/suppression ? | Object Lock, WORM, retention policy |
Sécurité du stockage
- Chiffrement au repos : clés managées fournisseur ou KMS/HSM client.
- Chiffrement en transit : TLS, IPsec, FC zoning, réseau privé.
- IAM et ACL : moindre privilÚge, séparation admin/data, audit.
- Immutabilité : protection ransomware et conformité.
- Classification : PII, secrets, données réglementées, logs d'audit.
Coût réel : TCO
| Poste | Souvent oublié |
|---|---|
| Capacité utile | RAID, réplication 3x, erasure coding, snapshots |
| Performance | Provisioned IOPS, SSD premium, cache, contrĂŽleurs |
| Transfert | Egress cloud, inter-région, migration initiale |
| Opérations | Monitoring, patching, remplacement disques, support |
| Restauration | Frais de retrieval, temps humain, tests DR |
Scorecard de décision rapide
| CritĂšre | Question de design | Score 1-5 | Preuve attendue |
|---|---|---|---|
| Capacité | Volumétrie actuelle + croissance 36 mois ? | Courbe, seuils, marge | |
| Latence | p95/p99 maximal accepté ? | Benchmark fio/applicatif | |
| IOPS | Lecture/écriture, random/séquentiel ? | Mesure réelle ou sizing | |
| RPO/RTO | Perte et indisponibilité acceptables ? | Runbook de restauration | |
| Sécurité | Chiffrement, IAM, audit, immutabilité ? | Politique validée | |
| Coût | TCO incluant egress/retrieval/support ? | Simulation 12/36 mois | |
| Scalabilité | Comment ajouter 10x capacité ? | Architecture scale-up/scale-out |
Température = fréquence d'accÚs + urgence de restauration
| Classe | AccĂšs | Latence attendue | Exemples | Objectif |
|---|---|---|---|---|
| Hot | TrÚs fréquent | Immédiat | DB active, fichiers récents, VM, cache | Performance |
| Warm | RĂ©gulier mais modĂ©rĂ© | ImmĂ©diat ou quasi immĂ©diat | Documents rĂ©cents, logs 30-90 jours | Ăquilibre coĂ»t/perf |
| Cold | Rare | Secondes à minutes selon solution | Backups anciens, exports, datasets historiques | Réduction coût |
| Deep archive | Exceptionnel | Minutes à heures | Conformité, archives légales, patrimoine | Coût minimal et rétention |
Exemples de classes cloud
| Provider | Hot | Warm/Cold | Archive |
|---|---|---|---|
| AWS | S3 Standard | Standard-IA, One Zone-IA | Glacier Instant/Flexible/Deep Archive |
| Google Cloud | Standard | Nearline, Coldline | Archive |
| Azure | Hot | Cool, Cold | Archive |
| OVH / Scaleway | Object Storage standard | Cold archive selon offre | Archive cloud / Glacier-like selon service |
Lecture Ă©conomique
Plus la donnée devient froide, plus le coût de conservation baisse, mais plus le coût d'accÚs, le délai de restauration, les contraintes de durée minimale ou les frais d'opération peuvent augmenter.
Policy lifecycle : automatiser le déplacement
Le lifecycle Ă©vite de garder Ă©ternellement des donnĂ©es froides dans un stockage chaud. Il doit ĂȘtre alignĂ© sur la valeur mĂ©tier, les obligations lĂ©gales, les temps de restauration et les coĂ»ts de retrieval.
Example policy logic: IF object_age > 30 days AND access_count = 0 THEN move_to_warm IF object_age > 180 days THEN move_to_cold IF object_age > 365 days AND legal_hold = false THEN archive_or_delete IF ransomware_protection = true THEN enable_immutability
| Ătape | ContrĂŽle |
|---|---|
| Classer | Identifier données actives, sensibles, réglementées. |
| Mesurer | Observer accÚs, taille, croissance, coût. |
| Simuler | Calculer économie et coût de restauration. |
| Automatiser | RĂšgles lifecycle, tags, expiration. |
| Auditer | ContrÎle périodique, exceptions, legal hold. |
Risques classiques du tiering
| Risque | Impact | Prévention |
|---|---|---|
| Restaurer trop lentement | RTO non tenu | Tester retrieval et documenter délais réels |
| Archiver sans index | Donnée introuvable | Catalogue, metadata, tags, moteur de recherche |
| Coût de sortie surprise | Facture élevée | Simulation egress/retrieval avant migration |
| Lifecycle trop agressif | Performance dégradée | Analyse des accÚs, exceptions par application |
| Suppression non conforme | Risque légal | Rétention, legal hold, validation métier |
Questions Ă poser avant de choisir
| Domaine | Questions | Livrable |
|---|---|---|
| Volumétrie | Capacité actuelle, croissance mensuelle, taille moyenne objet/fichier, nombre d'objets ? | Courbe 36 mois |
| Performance | IOPS, dĂ©bit, latence p95/p99, pics, fenĂȘtre batch ? | Benchmark + SLA |
| Disponibilité | Maintenance possible ? HA locale ? multi-site ? multi-zone ? | Architecture failover |
| Protection | RPO/RTO, immutabilité, backup hors site, tests de restauration ? | Plan DR |
| Sécurité | Droits, chiffrement, logs, audit, données sensibles ? | ModÚle IAM |
| Coût | Capacité utile, réplication, egress, retrieval, licences, support ? | TCO 12/36 mois |
| Exploitation | Monitoring, alerting, patch, remplacement, runbooks ? | Runbook N1/N2/N3 |
| Réversibilité | Comment sortir les données et à quel coût ? | Plan de migration |
| Terme | DĂ©finition courte |
|---|---|
| Bloc | Unité bas niveau lue/écrite par un systÚme de fichiers ou une base. |
| Fichier | Donnée nommée dans une hiérarchie, avec droits et metadata filesystem. |
| Objet | Donnée adressée par une clé dans un bucket, souvent avec metadata riche et API HTTP. |
| IOPS | Input/Output Operations Per Second. |
| Throughput | Débit transféré par seconde, souvent en MB/s ou GB/s. |
| Latency p99 | Temps de rĂ©ponse sous lequel 99% des requĂȘtes se terminent. |
| RPO | Quantité maximale de données que l'on accepte de perdre. |
| RTO | DĂ©lai maximal pour restaurer un service. |
| Erasure coding | Technique qui découpe et encode les données pour tolérer des pertes avec moins de surcoût qu'une réplication complÚte. |
| Immutability | CapacitĂ© Ă empĂȘcher modification ou suppression pendant une durĂ©e dĂ©finie. |
Liens de référence pour enrichir les chapitres suivants
- AWS S3 Storage Classes â classes S3, durabilitĂ©, stockage multi-AZ.
- AWS S3 Glacier Storage Classes â archive, retrieval, deep archive.
- Google Cloud Storage â Availability and Durability â distinction disponibilitĂ©/durabilitĂ©.
- Google Cloud Storage Classes â Standard, Nearline, Coldline, Archive.
- Azure Storage redundancy â LRS, ZRS, GRS, durabilitĂ©.
- Backblaze Drive Stats 2025 â statistiques terrain sur les disques durs.