Decrypt

Système de stockage orienté objet en anneaux

Frédéric Faure,

14 février 2012

Des solutions de stockage suivant les même idées directrices que celles que l’on peut trouver dans les grands Cloud publics sont apparues depuis déjà quelques temps maintenant, et je me suis intéressé particulièrement à une solution de stockage orienté objet basée sur un système en anneaux. Cette solution de Scality nommée Ring Organic Storage, propose un système de stockage peu coûteux avec des fonctionnalités similaires à celles que l’on peut trouver sur S3. Il permet d’associer à une URL un objet stocké sous forme de binaire. On note que ce principe d’anneau est le même que l’on trouve sur des bases comme Cassandra, sauf que dans notre cas il s’agit de stockage orienté objet. Je me suis donc intéressé au fonctionnement de cette solution déjà déployée dans des productions chez des hébergeurs et des fournisseurs de service.

Cible
Il est indispensable, dans un premier temps, de prendre conscience que cette solution permettant de mettre en place un des composants d’un Cloud privé est réservée à des sociétés ayant un volume de données suffisamment important (à partir de 100To) ou rencontrant des problématiques de performances (quelques dizaines de To avec d’importants IOs). Il faut dans tous les cas atteindre une masse critique dans son infrastructure pour utiliser ce genre de produit, comme n’importe quel composant de Cloud Computing que l’on souhaite déployer en privé.

Architecture
L’architecture du système de stockage en anneaux est constituée d’un anneau primaire permettant de servir les requêtes vers les objets définis comme accédés les plus fréquemment (performance privilégiée) et d’un ou plusieurs autres anneaux servant de stockage sur le long terme servant pour la reprise d’activité en cas de problèmes (disaster recovery). Cette réplication peut s’effectuer en off-site sur un autre data center ou bien même sur des services de stockage sur des Cloud publics type… Mmmh… Disons S3 ! :o)

Cette architecture privilégie la disponibilité et la durabilité des données via un surcoût en disques durs puisque le principe est de redonder la donnée entre plusieurs noeuds de stockage écrivant sur des sets de disques différents. Ce choix est basé sur le fait que le disque dur n’est pas un composant très coûteux dans la mise en place d’une infrastructure.

Les noeuds fonctionnent sur un système de peer-to-peer, il n’y a donc pas de SPOF (Single Point Of Failure) ou d’engorgement et un load-balancing naturel s’effectue.

A noter que la cohérence de ce système est configurable de manière à ce que l’on puisse atteindre une cohérence forte ou une cohérence à terme : à vous de définir votre niveau de cohérence ou quorum. Par exemple, si W+R > N, alors le jeu d’écritures et le jeu de lectures se recouvrent toujours et l’on peut garantir une cohérence forte, avec :

N = le nombre de nœuds qui stockent les répliques des données
W = le nombre de répliques qui doivent accuser réception de la mise à jour avant que celle-ci ne soit complétée
R = le nombre de répliques qui sont contactées quand un objet de données est consulté via une opération de lecture

La gestion des clés
La répartition des données s’effectue sur l’anneau via une clé unique (20 octets) définie soit par vos applications elles-même, soit par le système qui se base sur un ensemble d’éléments. Chaque noeud s’occupant d’un range de clés bien défini, la donnée est donc inscrite sur le noeud correspondant, puis répliquée sur d’autres noeuds définis par algorithme : par exemple dans le cas où on choisit de répliquer 2 fois la donnée (donc de la stocker en 3 exemplaires), une donnée stockée sur un noeud x le sera également sur les noeuds x + Pi/3 et x + 2Pi/3.

En plus, les voisins directs d’un noeud dans l’anneau peuvent reprendre la responsabilité des données de leur voisin si il « venait à disparaître » de l’anneau afin de proxyfier les requêtes vers les données redondées (via l’algorithme).

Le but est de pouvoir accéder aux données que l’on cherche à partir de n’importe quel point d’entrée (c’est-à-dire à partir de n’importe quel noeud de l’anneau) en un minimum de sauts. Par exemple pour ce système, le nombre de sauts annoncé est de :

3 pour 100 noeuds,
5 pour 1000 noeuds,
7 pour 10000 noeuds,
…

Pour accéder au noeud contenant la donnée cherchée, on y arrivera donc en moins de log(n) sauts (avec n le nombre de noeuds). A noter que pour de meilleurs temps d’accès (diminution du nombre de sauts), la topologie de l’anneau est cachée au niveau des connecteurs (cf. accès aux données) au fur et à mesure de sa découverte.

A noter que la répartition des clés s’effectue via un « Consistent Hash » : cela permet lors de l’ajout ou de la suppression d’un noeud de n’affecter que « (1/n) x nb total clés » clés (avec n… toujours le nombre de noeuds ;ob).

On peut aussi utiliser les clés pour identifier le type de données stockées (via un des éléments composant la clé) et les affecter vers des disques (harware) sous-jacents particuliers (SATA, SAS, SSD, …) en fonction des ressources que l’on souhaite affecter à ce type de données. Cela offre des possibilités intéressantes.

A noter également qu’en fonction de la taille des fichiers stockés, il est prévu des optimisations autant pour la manipulation de plein de petits fichiers (écriture en série dans des fichiers/blocs plus importants) que pour la manipulation de fichiers de grande taille (découpage en blocs et parallélisation des lectures/écritures). Il faut penser que pour ce genre d’utilisation, il faudra réfléchir également au niveau des composants hardware : par exemple pour des gros fichiers, il faudra envisager une bande passante suffisante pour permettre un bon débit, de même que pour beaucoup de petits fichiers, il faudra optimiser les IOs et prévoir un ratio disques/serveurs convenable et utiliser des disques adaptés (SAS ou SSD).

L’accès aux données
Les données peuvent être accédées via différentes interfaces (connecteurs) permettant d’émuler des fonctionnalités particulières (cf. schéma d’architecture) :

connecteurs mails (pour des produits comme Zimbra, Dovecot, Cyrus, …) permettant d’aller chercher le contenu (corps, pièces jointes, …) des messages stockés dans l’anneau correspondant aux meta-data (identifiants, objets, …) contenus dans une base de données,
connecteur REST (S3-like) pour accéder aux objets via le protocole HTTP en REST,
connecteur FUSE (Filesystem in Userspace) permettant d’émuler un système de fichiers et d’accéder dans ce mode aux objets stockés pour des programmes nécessitant une telle visibilité (c’est à dire ne permettant pas d’accéder aux objets via des requêtes HTTP),
connecteur de type Gateway (pour des produits comme TwinStrata, CTERA, …) permettant d’accéder à ce que l’on pourrait appeler un Cloud Attached Storage via des protocoles type iSCSI, NFS/CIFS, … (à voir la liste des protocoles actuellement pris en charge par le connecteur de Scality). Cela permet de conserver une partie de ses données dans l’infrastructure locale de son datacenter et de stocker la totalité sur un système distant. On bénéficie alors d’un système de cache sur les données les plus actives et d’une durabilité sur l’ensemble (il est aussi possible de conserver l’ensemble de ses données en local et de ne bénéficier que du backup distant). D’ailleurs, AWS vient de sortir il y a peu le service AWS Storage Gateway, sur le même principe.

En plus du type de connecteur, il est intéressant de voir les fonctionnalités d’authentification qui sont implémentées (pouvant interroger un système local en XML/RPC), les systèmes d’ACLs et les mécanismes de facturation. Tout à fait le genre d’éléments que l’on retrouve dans les Cloud IaaS type AWS.

Conclusion
Il est intéressant de regarder des solutions qui s’offrent à nous pour répondre à des problématiques de stockage en mettant en place des composants de Cloud, mais en privé. La distribution de l’Organic Ring Storage proposé par Scality permet à la solution de présenter un modèle décentralisé peu sensible à la panne, notamment grâce à l’utilisation de ses algorithmes de répartition et de recherche de données. La diversité des connecteurs en font une solution polyvalente, même si réservée à un stockage de données qui se compte en dizaines de To au minimum.

Il est possible de sélectionner le hardware sous-jacent qui servira à stocker un type d’objets en fonction d’éléments composant sa clé de stockage pour optimiser l’accès à ces données. De plus, en fonction de ce que l’on recherche avec ce système (bande passante, IOs ou stockage pur), il faut penser à privilégier les éléments hardware nécessaires.

J’espère que ce sujet vous aura intéressé et n’hésitez pas à nous contacter pour plus d’informations sur ce produit.

Frédéric FAURE @Twitter @Ysance

14 février 2012 | Tags: Cloud Computing, Cloud Hybride, Cloud Privé, IaaS, Organic Ring Storage, Scality | Categories: Architecture, Cloud Computing, Infrastructure, Scalability, Sharding / Partitionnement, Systèmes Distribués | Laisser un commentaire

Archives

Articles récents

Commentaires récents

Système de stockage orienté objet en anneaux

Répondre

Decrypt, Le Forum

Ex