vege - Fotolia
Le SDS moteur du Stockage objet
Économique et polyvalent, le stockage objet est aujourd’hui la forme de Software Defined Storage qui connaît le plus grand succès, en particulier pour les applications de stockage secondaire, de sauvegarde ou d’archivage.
Si le débat autour du Software Defined Storage s’est initialement concentré autour des solutions SAN et NAS, c’est au final une forme totalement nouvelle de stockage qui a le plus profité de la migration du stockage vers le logiciel. Ce constat n’est guère surprenant. Dans le stockage objet, il n’y avait peu ou pas d’existant et il a finalement été relativement facile pour les fournisseurs de convaincre les clients de la pertinence de solution SDS objet.
L’adoption du stockage objet est dopée par l’explosion des volumes de données non structurées et par le désir des entreprises de contenir la progression de leurs coûts de stockage. C’est d’ailleurs sur ce dernier point que la nature SDS du stockage objet fait merveille. Car la séparation entre matériel et logiciel permet de proposer des prix tirés au maximum vers le bas, sans mettre en cause ni la résilience ni l’évolutivité de la plate-forme.
Il existe aujourd’hui de multiples systèmes de stockage objet comme Ring de Scality, ECS d’EMC, HyperStore de Cloudian, HCP de HDS, Cloud Object Storage d’IBM (ex-Cleversafe), Active Archive de Western Digital, WOS de DataDirect Networks, Minio Cloud Storage de Minio, OpenIO de l’éditeur français éponyme, ainsi que des solutions open source comme Swift ou Ceph.
Ces nouveaux systèmes s’appuient sur des protocoles de communication de type RESTful, des protocoles simples d’emploi et souples, que l’on peut intégrer facilement à des applications existantes (backup, archivage analytique, etc.).
Des architectures massivement distribuées
Tous les systèmes de stockage objet du marché ont adopté des architectures distribuées et supportent l’agrégation de dizaines, de centaines, voire de milliers de nœuds pour le stockage des données.
Cette aptitude à supporter des configurations massives permet de faire face sereinement à l’accroissement régulier des besoins en capacité — et en performances — par simples ajouts de nœuds additionnels au cluster existant. La protection des données, est généralement assurée par des mécanismes d’erasure coding, de duplication (chaque objet est écrit plusieurs fois sur des nœuds différents, ce qui permet d’assurer que les objets seront accessibles même en cas de défaillance d’un nœud) ou de réplication géographique (ce qui permet d’accéder aux données avec des performances acceptables depuis plusieurs sites géographiquement distribués).
La nature distribuée des systèmes objet permet aussi d’assurer une grande résilience.
Il est toutefois à noter qu’en fonction des algorithmes de distribution et d’erasure coding mis en œuvre par chaque éditeur du marché, les caractéristiques des systèmes diffèrent en matière de protection de distribution et de performances. Certains systèmes de stockage objet sont ainsi bien adaptés au stockage de grands volumes de petits objets tandis que d’autres sont mieux adaptés au stockage d’objets très volumineux (images, vidéos).
De nouveaux mécanismes d’accès aux données
Alors que sur des systèmes NAS on stocke des fichiers, dans le monde des systèmes objet, on parle de stocker des « objets ». Les systèmes objet n’organisent pas les données dans des hiérarchies structurées (typiquement des arborescences de répertoires) comme le font les serveurs NAS. Les objets sont en général organisés dans un espace d’adressage plat et éventuellement dans des conteneurs de plus haut niveau appelés « buckets » (littéralement des seaux).
Une des caractéristiques intéressantes des systèmes objet est qu’ils associent un ensemble de métadonnées très riches aux objets qu’ils stockent.
Selon les systèmes, les objets peuvent être retrouvés par une recherche sur ces métadonnées, par leur identifiant unique ou par un mécanisme de key/value store.
À aucun moment l’utilisateur n’a à se poser la question de savoir sur quel serveur ou nœud l’objet est stocké (contrairement par exemple à une baie NAS, où il faut connaître le serveur sur lequel se trouve le fichier puis naviguer dans l’arborescence jusqu’à son emplacement).
D’une certaine façon, on peut comparer le stockage objet à un système de consigne. Lorsqu’un client dépose un objet, il reçoit un ticket, mais ne se préoccupe pas de l’endroit où il sera stocké. Sa seule préoccupation est qu’en échange du ticket il pourra retrouver son objet. Et dans certains cas, s’il en a déposé plusieurs dans un panier, il pourra revenir retirer le panier entier ou seulement un des objets du panier.
Des API d’accès aux données de type RESTful
L’accès aux systèmes de stockage objet se fait en général au travers d’API de type RESTful qui s’appuient sur des commandes HTTP pour s’interfacer avec le stockage sous-jacent.
Les commandes basiques sont des commandes de type GET, PUT et DELETE pour lire, écrire et effacer des objets. Mais la sémantique des systèmes objet est bien plus vaste que ces simples commandes.
Aujourd’hui, une API se dégage du lot, celle du service de stockage objet en cloud d’Amazon AWS, S3. Elle sert de plus en plus de ligua franca aux systèmes de stockage objet.
Derrière l’API S3, la seconde API la plus populaire est sans doute l’API Swift, du fait de la montée en puissance d’OpenStack. Ces API sont populaires auprès des développeurs d’applications web. Ces derniers n’ont en effet pas à gérer la complexité des systèmes SAN et NAS et apprécient le fait que les commandes RestFul, basées sur HTTP s’accommodent de la plupart des réseaux.
Des usages de plus en plus généralistes
Si l’usage d’API Restful a contribué au succès des systèmes de stockage objet dans le Cloud, leur adoption dans l’entreprise est aussi dopée par le fait que ces produits ne se limitent plus aux seuls protocoles objets. La plupart des fournisseurs ont ainsi commencé à greffer des interfaces d’accès NAS ou SAN à leurs systèmes, rendant ainsi possible leur utilisation par des applications plus traditionnelles.
La majorité des constructeurs supportent ainsi désormais des accès natifs en mode NFS ou CIFS. Cela permet typiquement à des applications n’utilisant pas (encore) les protocoles objet d’accéder à ses systèmes.
Certains proposent aussi des accès en mode bloc (en général via un support de l’API Cinder d’OpenStack et la fourniture d’un « block driver » pour Linux).
D’autres, enfin, ont intégré leurs plates-formes de stockage avec Hadoop — soit via le support natif de HDFS, soit via un accès en mode S3 (chez Cloudian ou Hitachi, par exemple). Des intégrations de nature à accélérer encore un peu plus l’adoption de ces systèmes en entreprises.
