Le stockage en mode bloc (SAN) offre une latence plus faible et davantage d'IOPS pour les bases de données transactionnelles ; le stockage fichier (NAS) sert des dossiers partagés via NFS ou SMB ; le stockage objet (compatible S3) monte en charge jusqu'à l'exaoctet au coût par gigaoctet le plus bas, idéal pour les sauvegardes. Une fiabilité réelle exige toujours la règle du 3-2-1, ou du 3-2-1-1-0 contre les rançongiciels : aucune grappe RAID ne remplace une sauvegarde vérifiée.
Les données croissent plus vite que les budgets. Chaque année, l'organisation moyenne multiplie son volume stocké, et la tentation d'« acheter plus de disque » se heurte vite à un mur de coûts, de latence et de charge de gestion. Concevoir un stockage évolutif ne consiste pas à accumuler de la capacité ; il s'agit de placer chaque donnée sur le bon support, avec le niveau de redondance approprié, selon une trajectoire de croissance qui ne nécessite pas d'interrompre le service. Cet article couvre les trois grandes architectures de stockage — bloc, fichier et objet —, le tiering automatique qui les relie, et les mécanismes de durabilité qui distinguent un stockage réellement fiable d'un stockage qui ne semble fiable que jusqu'à la première panne.
Bloc, fichier et objet : trois modèles, trois cas d'usage
Le stockage en mode bloc (SAN) expose des volumes bruts via des protocoles tels qu'iSCSI ou Fibre Channel. Le système d'exploitation les perçoit comme des disques locaux et y applique son propre système de fichiers. C'est le modèle offrant la latence la plus faible et les IOPS les plus élevés, idéal pour les bases de données transactionnelles et les machines virtuelles. Son point faible : il monte mal en charge horizontalement, et un volume est généralement monté par un seul hôte à la fois.
Le stockage fichier (NAS) sert des hiérarchies de dossiers et de fichiers via NFS ou SMB/CIFS. Plusieurs clients partagent le même système de fichiers, avec des permissions POSIX ou des ACL. C'est le modèle naturel pour les répertoires partagés, les dossiers personnels des utilisateurs et les applications qui attendent un accès par chemin. Il monte mieux en charge que le stockage bloc, mais les métadonnées hiérarchiques deviennent un goulot d'étranglement à grande échelle.
Le stockage objet (compatible avec l'API S3) stocke les données sous forme d'objets plats identifiés par une clé, sans réelle hiérarchie de dossiers, avec des métadonnées riches et un accès via HTTP. C'est le modèle qui sous-tend le cloud : durabilité extrêmement élevée, mise à l'échelle horizontale pratiquement illimitée et faible coût par gigaoctet, en échange d'une latence plus élevée et d'une cohérence éventuelle ou forte selon le fournisseur. Il est idéal pour les sauvegardes, les archives média, les data lakes et les données froides à grande échelle.
Comparaison des architectures de stockage
| Caractéristique | Bloc (SAN) | Fichier (NAS) | Objet (S3) |
|---|---|---|---|
| Unité | Bloc LBA | Fichier dans une arborescence | Objet + clé |
| Protocole | iSCSI, FC, NVMe-oF | NFS, SMB | HTTP / API S3 |
| Latence | Très faible | Faible à moyenne | Moyenne à élevée |
| Mise à l'échelle | Verticale | Horizontale limitée | Horizontale massive |
| Cas d'usage typique | Bases de données, VM | Ressources partagées | Sauvegarde, data lake, média |
| Coût par Go | Élevé | Moyen | Faible |
Tiering automatique : données chaudes en haut, données froides en bas
Toutes les données n'ont pas la même valeur ni la même fréquence d'accès. Le tiering automatique déplace les données entre classes de stockage selon les schémas d'accès. En pratique, plusieurs niveaux coexistent : le niveau chaud sur NVMe/SSD pour ce qui est lu et écrit en ce moment même ; le niveau tiède sur SAS ou S3 standard pour ce qui est consulté occasionnellement ; et le niveau froid/archive sur bande ou classes d'archivage profond pour ce qui n'est presque jamais consulté mais doit être conservé pour des raisons de conformité. Des politiques de cycle de vie automatisent les transitions : un objet qui n'a fait l'objet d'aucune lecture depuis 30 jours descend vers une classe moins coûteuse, et après 180 jours passe en archive.
Les économies sont réelles, mais le tiering exige une conception délibérée : récupérer des données depuis un niveau d'archivage profond peut prendre des heures et entraîner des coûts de récupération. Archiver des données qui pourraient être nécessaires en urgence est une erreur aussi coûteuse que de garder sur NVMe ce que personne ne lit jamais.
Mise à l'échelle horizontale et stockage défini par logiciel
La différence essentielle entre un stockage qui monte en charge et un stockage qui manque de place réside dans le modèle de croissance. La mise à l'échelle verticale (scale-up) ajoute des disques à une baie existante jusqu'à épuiser ses contrôleurs : simple, mais avec un plafond physique et un point de défaillance unique. La mise à l'échelle horizontale (scale-out) ajoute des nœuds à un cluster, en répartissant à la fois la capacité et la performance : chaque nœud apporte du disque, du CPU et du réseau, de sorte que le système croît de manière linéaire sans interruption de service. C'est le modèle utilisé par les systèmes distribués modernes (Ceph, MinIO et les baies scale-out commerciales) et la raison pour laquelle le stockage objet peut atteindre l'échelle de l'exaoctet.
Au-dessus de cela se trouve le Software-Defined Storage (SDS), qui découple la logique de stockage du matériel propriétaire et l'exécute sur des serveurs standards. Le SDS permet de mélanger les fournisseurs, d'automatiser le provisionnement par des politiques et d'orchestrer les volumes de façon déclarative — particulièrement pertinent dans les environnements conteneurisés, où le CSI (Container Storage Interface) de Kubernetes provisionne des volumes persistants à la demande. La contrepartie est que la complexité se déplace du matériel vers le logiciel et vers les personnes qui le gèrent : un cluster distribué mal dimensionné, en particulier avec un réseau interne sous-dimensionné ou un facteur de réplication incorrect, se comporte moins bien qu'une baie traditionnelle bien réglée.
Durabilité : RAID, erasure coding et la règle du 3-2-1
La fiabilité signifie que les données survivent à une panne matérielle. Le RAID protège contre la défaillance d'un disque : le RAID 6 tolère deux pannes de disque simultanées, mais les temps de reconstruction pour les disques de grande capacité sont suffisamment longs pour augmenter significativement la fenêtre de risque. C'est pourquoi le stockage objet moderne utilise l'erasure coding, qui fragmente chaque objet en k fragments de données plus m fragments de parité et les distribue entre les nœuds ; un schéma 10+4 tolère quatre pannes simultanées avec une surcharge de capacité bien inférieure à une triple réplication.
Aucune configuration RAID n'est une sauvegarde. La règle du 3-2-1 reste la référence en matière de fiabilité : trois copies des données, sur deux types de support différents, avec une copie hors site. Contre les rançongiciels, la variante 3-2-1-1-0 s'est généralisée : une copie immuable ou déconnectée du réseau et zéro erreur vérifiée lors des tests de restauration. Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde — c'est un espoir.
Performance : IOPS, débit et latence ne sont pas la même chose
Bien dimensionner le stockage exige de distinguer trois grandeurs fréquemment confondues. Les IOPS (opérations d'entrée/sortie par seconde) mesurent combien de requêtes le système traite ; elles comptent pour les charges de travail avec de nombreuses opérations petites et aléatoires, comme une base de données transactionnelle. Le débit (Mo/s) mesure le volume de données transférées ; il domine pour les charges de travail séquentielles de gros fichiers, comme les sauvegardes ou le streaming vidéo. Et la latence (millisecondes) mesure le temps de réponse de chaque opération individuelle — ce qui est ce que perçoivent réellement les utilisateurs et les applications. Un système peut avoir des IOPS très élevés tout en paraissant lent si sa latence de traîne (percentiles p99) explose sous charge.
L'erreur de dimensionnement la plus coûteuse consiste à optimiser la mauvaise grandeur : acheter des disques à très haut débit pour une base de données qui avait besoin d'IOPS et de faible latence, ou l'inverse. La conception correcte commence donc par caractériser le schéma d'E/S réel de chaque application — taille de bloc, ratio lecture/écriture, caractère aléatoire et charge de pointe — avant de choisir le support. La mise en cache sur SSD/NVMe devant des niveaux plus lents, et la séparation des charges de travail en pools distincts, permettent à la base de données et au dépôt de sauvegarde de coexister sans que l'un prive l'autre de ressources.
Conformité : chiffrement, rétention et RGPD
Un stockage fiable est aussi un stockage conforme. Le RGPD exige le chiffrement des données personnelles au repos et en transit comme mesure de sécurité appropriée, fixe des durées de conservation (les données ne sont pas conservées indéfiniment « au cas où ») et impose la capacité à honorer le droit à l'effacement — ce qui, dans un stockage objet avec versionnage et rétention WORM, exige une conception explicite. L'immuabilité qui protège contre les rançongiciels (Object Lock) peut entrer en conflit avec le droit à l'effacement si la coexistence des deux exigences n'est pas planifiée dès le départ. Les bonnes pratiques de gestion de la sécurité de l'information de la famille ISO/IEC 27001 fournissent le cadre de contrôle pour gouverner tout cela.
Erreurs courantes dans l'architecture de stockage
- Utiliser le stockage objet comme système de fichiers à faible latence. Les caractéristiques de cohérence et de latence ne correspondent pas aux charges de travail transactionnelles.
- Confondre RAID et sauvegarde. Le RAID protège contre la panne de disque, pas contre la suppression, la corruption ou les rançongiciels.
- Ne pas tester les restaurations. L'exigence « zéro erreur » de la règle 3-2-1-1-0 n'existe que si elle est vérifiée.
- Faire du tiering sans mesurer les schémas d'accès. Archiver des données réellement consultées fait grimper les coûts de récupération.
- Négliger le chiffrement au repos. Un disque non chiffré perdu constitue une violation à notifier au titre du RGPD.
Foire aux questions
NAS ou SAN pour une base de données ?
SAN (bloc) pour sa latence plus faible et ses IOPS plus élevés. Le NAS convient mieux à l'accès partagé aux fichiers ; certaines bases de données fonctionnent via NFS, mais le stockage bloc reste l'option de référence pour les charges de travail transactionnelles exigeantes.
Quelle durabilité offre le stockage objet ?
Les fournisseurs cloud annoncent couramment « onze neuf » (99,999999999 % de durabilité annuelle) grâce à la réplication ou à l'erasure coding entre zones de disponibilité. Ce chiffre décrit la probabilité de ne pas perdre un objet en raison d'une panne de support ; il ne supprime pas l'obligation de maintenir des sauvegardes indépendantes.
Qu'est-ce que le tiering automatique, exactement ?
C'est le déplacement des données entre classes de stockage de coût et de performance différents en fonction de leur fréquence d'accès, régi par des politiques de cycle de vie qui appliquent les transitions sans intervention manuelle.
La règle du 3-2-1 est-elle toujours pertinente avec le stockage cloud ?
Oui, et elle s'en trouve renforcée. Le cloud facilite les copies hors site, mais il reste conseillé de conserver au moins une copie immuable et de diversifier les fournisseurs ou les types de support pour éviter toute dépendance à un point de défaillance unique.
Conclusion
Le stockage cesse d'être un problème de capacité et devient un problème de conception dès que les volumes augmentent : la bonne question n'est pas « combien de téraoctets dois-je acheter ? » mais « quelles données vivent sur quel niveau, avec quel niveau de redondance et selon quelle politique de cycle de vie ? ». Un système évolutif combine le stockage bloc pour les charges transactionnelles, le stockage fichier pour les ressources partagées et le stockage objet pour les données à fort volume, avec un tiering qui réduit le coût des données froides sans pénaliser les données chaudes, et une stratégie 3-2-1-1-0 qui survit même aux rançongiciels — le tout chiffré et avec des durées de conservation conformes au RGPD. Chez Summum Sistemas, nous concevons cette architecture à partir des schémas d'accès réels de chaque client, et nous vérifions les restaurations avant d'affirmer que les données sont en sécurité.