Navigation ↓
  |  Laurent Denel

Stockage en mode bloc, fichier ou objet : petite histoire de l’évolution des systèmes de stockage informatique

Read the English version

Block Storage, File System et Object Storage sont trois façons de stocker des données et d’y accéder. On les présente souvent comme trois paradigmes concurrents, qui ont chacun leurs avantages et leurs inconvénients. Ce n’est pas inexact, mais c’est insuffisant pour appréhender les différences fondamentales entre ces trois approches et, le cas échéant, choisir la plus adaptée en fonctions de ses besoins.

C’est pourquoi je vous propose un détour par l’histoire de l’informatique, fortement influencée ces dernières décennies par le développement de la bureautique, l’apparition du web et des applications distribuées, trois phénomènes concordant avec l’évolution des systèmes de stockage.

Un peu de spéléologie dans les couches basses des systèmes informatiques

L’histoire des supports de stockage, depuis la carte perforée jusqu’aux tentatives récentes de stocker de l’information dans des brins d’ADN, est largement documentée. Disquettes, disques ZIP, CD-ROM, DVD, mémoire flash, disques SATA, SSD ou NVMe… chacun ou presque a déjà tenu entre les mains l’un ou l’autre des vestiges de cette évolution, qui d’ailleurs n’a pas encore abouti à un transfert intégral des données vers le « cloud », en témoigne la persistance de l’archivage sur bandes magnétiques, dont on a trop tôt annoncé la disparition (sa volumétrie continue à augmenter). L’histoire parallèle des modes de stockage, du block storage à l’object storage, est plus méconnue. Elle est sans doute, aussi, plus difficile à raconter. Car elle puise ses racines dans les couches basses de l’informatique. Tant de couches d’abstraction ont été ajoutées au fil des ans entre le hardware et le software que l’exercice peut s’apparenter à de la spéléologie. Qu’à cela ne tienne, tentons ensemble cette exploration en profondeur.

Au commencement était le bloc, soit la plus petite unité de stockage au sein d’un système informatique, avec une taille originelle de 4 kio (kibloctet), soit 4096 octets et autant de zones mémoire équivalentes à 0 ou 1, grâce auxquelles on peut stocker une information sous forme numérique. Initialement, le stockage ne pouvait être dissocié du serveur. Un disque dur contient les informations lues et écrites localement par la machine, par l’intermédiaire de la carte mère d’un point de vue physique, et à travers le système d’exploitation d’un point de vue logique. Basique. Sauf que la taille des fichiers manipulés par les ordinateurs va connaître une croissance continue. Lorsque les premiers micro-ordinateurs furent développés dans les années 1970, le disque souple de 8 pouces était considéré comme un dispositif de stockage à « haute vitesse » et il pouvait contenir l’intégralité d’un système d’exploitation !

Étape 1 : dissocier le système de stockage du serveur

Les ordinateurs personnels sont, depuis toujours, majoritairement dotés d’un disque dur unique. Les serveurs, quant à eux, ont rapidement été pensés pour accueillir plusieurs disques, ceci pour augmenter les capacités de stockage, puis pour des questions de protection des données (avec l’apparition du RAID, dont le concept a été défini pour la première fois à la fin des années 1980) et éventuellement de performance. Toutefois, ce redimensionnement vertical (scale-out) atteint tôt ou tard ses limites : celle du châssis du serveur.

La première rupture technologique consista donc à désagréger le stockage du serveur, en lui permettant de consommer d’autres disques que ceux placés à l’intérieur de son propre châssis. C’est l’apparition du DAS (Direct Attached Storage), soit la possibilité pour un ordinateur d’accéder à un disque raccordé à la machine en tant que périphérique. Puis est apparu le SAN (Storage Area Network), un système de disque dur en attachement réseau permettant à une machine d’accéder à un espace de stockage via le protocole Fibre Channel, en mode client/serveur. Il devint alors possible de partager un espace de stockage entre plusieurs serveurs. Mais pas encore de lire ou écrire simultanément depuis plusieurs machines, en raison de la difficulté de gérer les écritures concurrentes. La désagrégation du stockage constitua néanmoins une avancée considérable : il fut possible de concevoir les premières architectures « complexes », destinées à assurer la haute disponibilité des applications. Concrètement : la base de données est hébergée sur un stockage partagé entre une machine maître et une machine esclave, prête à prendre le relais en cas d’indisponibilité. Ce mode actif/passif sera rapidement optimisé avec l’actif/passif croisé : les deux machines travaillent simultanément, et peuvent prendre le relais l’une de l’autre en cas de problème, en absorbant temporairement la charge de l’autre (à condition d’en avoir la capacité, puisque la charge est alors doublée). Ainsi, on évite de maintenir une machine en sommeil, qui au mieux ne servira que quelques minutes par an. Et l’utilisation de deux serveurs à 50 % de leur capacité permet de mieux encaisser d’éventuels pics de charge.

La lente évolution des disques durs

Les progrès des disques durs à plateaux magnétiques (HDD), nés il y a plus de 60 ans, ont consisté à augmenter leur capacité, via un accroissement de leur densité. Il aura fallu attendre l’arrivée de la technologie Flash, récemment démocratisée avec les disques SSD et NVMe, pour constater une véritable rupture en termes de latence (temps d’accès à la donnée) et de débit, avec pour conséquence une plus grande réactivité des machines et un nombre d’opérations par secondes démultiplié (IOPS).

Étape 2 : la généralisation du système de fichiers

Poussé par le développement des usages bureautiques, et la nécessité de collaborer en partageant et en éditant simultanément des documents et dossiers, le système de fichiers se démocratisa. Le stockage en mode fichier (ou « basé sur des fichiers ») est sans doute le plus simple à comprendre. Son principe est exactement celui que l’on peut imaginer face à un explorateur de fichiers (ou Finder pour les adeptes de Mac OS). Les données sont stockées au sein de dossiers et sous-dossiers, l’ensemble formant une arborescence. On accède alors aux données par un chemin d’accès plus ou moins long, suivant la profondeur de l’arborescence. Ce mode de stockage « hiérarchique » est, aujourd’hui encore, le plus répandu pour les systèmes de stockage direct et en réseau — les NAS (Network attached storage).

Corolaires du système de fichiers, de nouveaux protocoles ont fait leur apparition pour organiser la communication entre les serveurs et les espaces de stockage partagés : NFS (Network File System), développé par Sun Microsystems en 1984, puis SMB (Server Message Block) initialement créé en 1985 par IBM avant d’être popularisé par Microsoft, qui l’intégra comme système par défaut de partage de fichiers sous Windows, avant de le renommer en CIFS (Common Internet File System) en 1996, et de lui rendre son appellation initiale en 2006 : SMB. Samba, l’implémentation open source du protocole SMB, dont la première version publique est apparue en 1997, est la plus connue et utilisée en entreprise. Pour les usages naissants du web, et notamment le téléversement de fichiers, c’est le FTP (File Transfer Protocole) qui s’est imposé, couplé à l’usage du NAS. Celui-ci répondait parfaitement au besoin de disposer d’un stockage back-end partagé entre plusieurs serveurs pour créer des applications web n-tiers. C’est ce qui fit le succès de solutions telles que celles développées par NetApp, entreprise américaine qui connut un développement fulgurant dans les années 2000, jusqu’à devenir la deuxième entreprise dans le secteur du stockage de données, entre les mastodontes Dell et HP.

Le système de fichiers, qui crée virtuellement une arborescence, est une couche d’abstraction qui se superpose au « block device » (gestion de l’écriture des blocs au niveau du kernel). C’est un progrès évident, pour les raisons évoquées plus haut, mais le file system n’a pas pour autant tué le stockage en mode bloc. Et pour cause : l’ajout d’une couche d’abstraction entraîne mécaniquement une baisse de performance en termes d’IO, induite par les calculs liés à la présentation et à la maintenance de cette arborescence, ainsi que par le système de gestion des écritures concurrentes, qui permet d’accéder aux données depuis plusieurs postes/serveurs. De ce fait, le stockage en mode bloc continue d’exister, notamment pour le stockage de grosses bases de données accédées et modifiées de manière intensive, ou encore pour le système de fichier de machines virtuelles haute performance.

Au fil du temps, les solutions de stockage exploitant le stockage de blocs et le système de fichiers se sont perfectionnées d’un point de vue technologique (gain de performance pour les supports de stockage comme pour les contrôleurs). Surtout, les fournisseurs y ont ajouté des services, relatifs notamment à la protection des données (depuis les différents types de RAID, qui optimisèrent à la fois la redondance et la consommation d’espace, jusqu’aux fonctions avancées de copie de données synchrone ou asynchrone entre deux baies, ou de snapshot d’un volume entier).

L’ajout de ces services à forte valeur ajoutée a contribué à maintenir des coûts élevés : les économies d’échelle, comme celles liées à l’augmentation de la capacité des disques, furent en grande partie absorbées par la sophistication des solutions de stockage. Cette époque fut celle du règne des solutions propriétaires sur le marché du stockage : du hardware spécifique, piloté par des logiciels propriétaires qui sont de véritables boîtes noires pour les utilisateurs. D’ailleurs, au coût élevé des baies de stockage s’ajoutaient les incontournables contrats de maintenance. À vrai dire, en cas de problème, il était quasiment impossible d’intervenir sans l’aide du constructeur. Et les solutions de stockage étaient bien peu flexibles : le tiering de données, notamment, n’était pas possible au sein d’un même système de stockage. Du reste, c’était sans doute une époque bénie : à condition d’en avoir les moyens, il suffisait pour le DSI de choisir sa chapelle. Et avouons-le, ce choix relevait moins des caractéristiques techniques des solutions que des talents des commerciaux envoyés dans les entreprises pour évangéliser…

Étape 3 : l’Object Storage, pour scaler sans limites et déporter l’intelligence dans le logiciel

Tandis que le volume de données a crû sans discontinuer (la courbe est désormais une exponentielle), les limites du file system sont progressivement apparues. Le file system – ou plus précisément le service de synchronisation des lectures/écritures (Distributed Lock Manager) s’avère incapable de gérer la connexion simultanée de milliers de machines. Et, si le volume des données peut atteindre le pétaoctet, le nombre de fichiers n’est, quant à lui, pas illimité. En effet, monter un file system nécessite de mettre en cache l’arborescence en même temps qu’elle est explorée par l’utilisateur. Lorsqu’un file system contient un grand nombre de fichiers, cette mise en cache de l’arborescence s’avère gourmande en RAM et peut affecter sensiblement les performances. Au bout du compte : les systèmes de stockage basés sur du file system atteignent leurs limites avant que leur capacité ne soit pleinement exploitée (la baisse de performance est notable une fois passé les 85 % de remplissage).

Seule solution : démultiplier les systèmes de stockage, autrement dit créer des silos. Ce qui implique de réaliser régulièrement des migrations de données, dès lors qu’un silo se remplit. Des opérations risquées, mobilisant des équipes entières. D’autre part, la majorité des données récemment générées sont des données dites non structurées. Pour faire simple, il s’agit de toutes les informations qui ne s’organisent pas en bases de données : fichiers bureautiques, historiques de messagerie, images, vidéos, logs…

Face à ces nouveaux défis, la rupture technologique consista à transférer l’intelligence du matériel (devenu de plus en plus sophistiqué et coûteux) au logiciel. Le Software Defined Storage est, en quelque sorte, la suite logique du mouvement qui a révolutionné le compute (avec les machines virtuelles) puis le réseau (avec l’approche softwate-defined network), avant de bouleverser le monde du stockage… « Software is eating the world », la fameuse prophétie de Marc Andreesen en 2016, signifiait que toutes les entreprises, peu importe leur domaine d’activité, devaient devenir des éditeurs de logiciel – sans quoi elles étaient menacées d’Ubérisation. Dans les métiers d’infrastructure, l’adage se vérifiait depuis plusieurs années déjà.

L’idée du stockage en mode objet est d’utiliser des serveurs standards (x86 ou ARM) pour créer une structure plate dans laquelle les fichiers sont fragmentés et répartis sur l’ensemble des nœuds du cluster, suivant différentes logiques – la plupart du temps, c’est un algorithme de sharding qui s’en charge, distribuant les données de manière relativement aléatoire, mais d’autres méthodes sont possibles, en témoigne le système de placement intelligent implémenté dans notre solution OpenIO. Chaque objet dispose d’un identifiant unique et de métadonnées. Et c’est à l’aide de cet identifiant et de ces métadonnées que le système récupère les fichiers, en réassemblant les fragments distribués entre plusieurs machines. Ce principe de stockage distribué offre énormément d’avantages : une scalabilité infinie en théorie, une protection des données plus économe (l’erasure coding remplaçant de manière logicielle le travail du contrôleur RAID), la possibilité (théorique, une nouvelle fois) d’exploiter des serveurs standards et du matériel hétérogène, une meilleure répartition de la charge, la possibilité d’exploiter au maximum la capacité des ressources…

Aussi, le fait d’accéder aux données via une API présente l’avantage de simplifier le développement des applications qui vont utiliser les données. Basiquement, tout est faisable avec trois commandes : GET, PUT et DELETE. Et une partie des traitements des données peut être réalisée directement sur le système de stockage, grâce à l’analyse de métadonnées.

Par exemple, dans le cas du stockage de photos en ligne, l’application web peut proposer à l’utilisateur des regroupements dynamiques par collections (par date, par lieu, par type d’appareil photo…), sans gérer elle-même ces opérations de tri et regroupements. Il lui suffit de lancer un appel via l’API pour lister les photos avec tel attribut renseigné dans les métadonnées, et de présenter les photos que le système d’Object Storage aura listées. Pour des usages tels que le Big Data, cette possibilité de générer dynamiquement des collections de données thématiques en fonction de ce que l’on veut étudier est un atout précieux.

Les systèmes distribués, un concept issu du monde de la recherche

Les premiers travaux de recherche à l’origine du concept de l’Object Storage remontent à l’année 1996. Mais l’idée d’exploiter des serveurs bon marché et d’en agréger les capacités grâce à une brique logicielle, chargée de distribuer les tâches sur l’ensemble des nœuds de la grille, est plus ancienne encore. La NASA, comme dans bien des centres de recherche dans le monde, est équipée de supercalculateurs depuis les années 1960 – d’imposantes machines de plusieurs tonnes et d’une valeur de plusieurs millions de dollars. Les plus connus de ces superordinateurs furent les supercalculateurs Cray, qui ont dominé le marché entre les années 1970 et 1990. En 1994, deux ingénieurs de NASA, Thomas Sterling and Donald Becker, ont révolutionné le monde du calcul haute performance en changeant de paradigme. Plutôt que de miser sur un hardware toujours plus performant et coûteux, les deux ingénieurs ont eu l’idée de constituer une grille de calcul composée de nombreux ordinateurs standards, fonctionnant sous des systèmes d’exploitation libres (GNU-Linux en général). Le nom de cette invention ? Le Cluster Beowulf, qui est aujourd’hui couramment utilisé dans le monde de la recherche. Dans un autre domaine, le web, Google a rendu public en 2003 le principe d’un système de fichiers distribué développé pour leur propre usage : Google File System. Cette architecture, qui répondait à un besoin de scalabilité pour le stockage des index de recherche, constitua une première étape vers l’Object Storage. En somme, il manquait alors la méthode d’accès aux données par une clé d’identification unique (ce qui fut appelé le Content Addressed Storage), et des mécanismes de sharding plus sophistiqués pour ventiler les données sur le cluster de la façon intelligente.

Est-on près de voir débarquer, un nouveau paradigme révolutionnant une nouvelle fois la façon de stocker et consommer les données ? Rien n’est moins sûr : les trois paradigmes existants – block storage, file system et object storage – couvrent aujourd’hui l’ensemble des besoins du marché. L’Object Storage, plus récent, est probablement celui qui est promis au plus bel avenir en termes de volume de données. Mais il reste du travail pour tenir toutes les promesses du concept et gagner en simplicité d’utilisation, pour en démocratiser encore l’usage. Block storage et file system, quant à eux, devront suivre la demande toujours accrue de performance…
On a d’ailleurs pu observer, ces dernières années, un retour en arrière, consistant à ré-associer stockage et compute, avec les offres dites « hyperconvergées » (rapprocher les disques au plus près des hyperviseurs pour gagner en latence). Mais, à nouveau, on revient vers la désagrégation, avec le protocole MVMe over Fabric (NVMe-oF), un modèle que Gartner qualifie de « stockage accéléré partagé ». Affaire à suivre !