Cet article fait partie de notre guide: Optimiser les performances de son infrastructure hybride

Comment bâtir un système de stockage Cloud avec OpenStack : les bases

Les composants de stockage d’OpenStack – Cinder et Swift – vous permettent de construire des systèmes de stockage objet et en mode bloc dans votre Cloud privé.

Dans l’évolution vers l’informatique à l’échelle du Web, des tech­nologies essentielles telles que la virtualisation, le passage à l’architecture x86 et l’adoption rapide de la méthodologie DevOps ont transformé l’écosystème informatique. Etant donné que le vol­ume de systèmes déployés dans les services informatiques continue d’augmenter, le prochain défi consistera à orchestrer et gérer les ressources de traitement, de stockage et réseau de la manière la plus rationnelle et efficace, en fournissant des services à ce qui est désor­mais connu sous le nom de Cloud privé.

 

OpenStack est un projet de plateforme de Cloud Open Source, lancé à l’origine par la NASA et Rackspace Hosting dans le cadre d’un co-projet en 2010. Le code source est géré par la Fondation OpenStack et distribué sous licence Apache. Ce qui permet de distribuer et de modifier librement le code, sous réserve de conserver les mentions originales relatives aux droits de reproduction. OpenStack s’est fait connaître en tant que plateforme de déploiement d’applications scale-out ; la plateforme est utilisée par un grand nombre de presta­taires de services pour la mise à disposition de Clouds publics, et par de grandes entreprises cherchant à mettre en oeuvre une infrastruc­ture de Cloud privé. Il est important de souligner que la plateforme OpenStack est conçue pour fonctionner avec les applications scale-out et qu’elle convient peu aux déploiements d’applications mono­lithiques traditionnelles, telles que Microsoft Exchange, ou reposant sur des bases de données telles qu’Oracle.

Le logiciel OpenStack comporte nombre de modules différents qui gèrent les divers aspects d’un environnement Cloud :

SWIFT : stockage objet

CINDER : stockage en mode bloc

NOVA : machines virtuelles (VM)/traitement

NEUTRON : réseau

HORIZON : tableau de bord

KEYSTONE : services de gestion des identités

GLANCE : service d’images

CEILOMETER : télémétrie

HEAT : orchestration

TROVE : base de données as-a-service (DBaaS, DataBase as a Service)

A chaque nouvelle version du code OpenStack (la dernière version étant appelée Kilo), des projets sont créés ou dérivés à partir de projets existants, ou encore lancés comme des projets entièrement nouveaux ; par exemple Ironic pour Bare Metal Provisioning et Sa­hara for Elastic MapReduce, dont la sortie était prévue pour la ver­sion Juno d’OpenStack.

Cinq des composants fournissent les services de données. Swift est le sous-projet qui gère le stockage objet de l’infrastructure OpenStack. Le stockage en mode bloc est pris en charge par Cinder à l’aide de protocoles IP de stockage standard tels que NFS et iSCSI. Glance est un référentiel pour les images VM. Il utilise le stockage sous-jacent d’un système de fichiers de base ou de Swift. Trove fournit les fonc­tionnalités DBaaS, tandis que Sahara offrira les fonctions Elastic Ma­pReduce, également appelées stockage pour clusters Hadoop. Nous nous focaliserons sur Cinder et Swift, les deux principales plateformes de stockage.

Stockage objet et stockage en mode bloc

Les déploiements OpenStack font la distinction entre les systèmes de stockage objet et en mode bloc. Le composant Swift fournit un stockage objet, tandis que Cinder fonc­tionne en mode bloc. Ces deux plateformes peuvent être mises en oeuvre sur du matériel courant ou s’intégrer aux composants des fournisseurs traditionnels.

 

Cinder pour le stockage en mode bloc

Le stockage en mode bloc est un élément essentiel de la mise en oeuvre d’une infrastructure virtuelle et constitue la base du stockage des images VM et des données utilisées par les VM. Avant le dével­oppement de Cinder, introduit en 2012 dans la version Folsom d’OpenStack, les machines virtuelles (VM) étaient temporaires et leur stockage se limitait à leur durée de vie. Cinder prend en charge la gestion du stockage en mode bloc au niveau de la couche de traite­ment (Nova), à l’aide des protocoles iSCSI, Fibre Channel ou NFS, ainsi que d’un certain nombre de protocoles propriétaires offrant une connectivité d’arrière-plan.

L’interface Cinder propose un certain nombre de fonctions standards qui permettent de créer et de connecter des appareils en mode bloc aux VM, telles que « create volume » (créer un volume), « delete volume » (supprimer un volume) et « attach volume » (connecter un volume). Des fonctions plus avancées prennent en charge la capacité d’étendre les volumes, de prendre des instantanés et de créer des clones à partir d’une image VM.

De nombreux fournisseurs proposent une prise en charge de la technologie de bloc avec leurs plateformes matérielles, grâce à l’utilisation d’un pilote Cinder qui convertit l’API Cinder en com­mandes sur le matériel spécifique du fournisseur. Parmi ceux qui offrent une prise en charge Cinder, on compte EMC (avec VMAX et VNX), Hewlett-Packard (3PAR StoreServ et StoreVirtual), Hitachi Data Systems, IBM (sur l’ensemble des plateformes de stockage), NetApp, Pure Storage et SolidFire. Il existe également des solutions logicielles comme celles d’EMC (ScaleIO) et de Nexenta.

En outre, certaines plateformes Open Source permettent de fournir une prise en charge de Cinder, comme Red Hat avec Ceph et Glus­terFS. Ceph a été intégré au noyau Linux. Ce dernier devient ainsi l’un des moyens les plus simples de fournir des fonctions de stockage en mode bloc à un déploiement OpenStack.

En 2013, une prise en charge NFS a été intégrée à la septième version d’OpenStack, appelée Grizzly - bien qu’une prise en charge « à titre expérimental » ait déjà été proposée précédemment dans la ver­sion Folsom. Avec NFS, les volumes sont traités comme des fichiers distincts d’une manière similaire à la méthode utilisée au sein de l’hyperviseur VMware ESXi ou des VHD sur Microsoft Hyper-V. L’encapsulation des volumes VM sous la forme de fichiers permet la mise en oeuvre de fonctions telles que les instantanés et le clonage.

Différentes fonctions de stockage ont été introduites dans Cinder au fil des versions, et des prises en charge par la suite par les fournis­seurs de solutions de stockage. La liste complète disponible sur la page Wiki d’OpenStack traitant des pilotes de stockage en mode bloc OpenStack.

Swift prend en charge le stockage objet

Dans OpenStack, le stockage objet est fourni via Swift. Ce dernier met en oeuvre un magasin d’objets scale-out réparti entre les noeuds d’un cluster OpenStack. Les magasins d’objets stockent les données sous la forme d’objets binaires, sans référence spécifique à un format. Les objets sont stockés dans Swift et en sont extraits à l’aide de sim­ples commandes, telles que PUT ou GET, utilisant le protocole (Web) HTTP, connu également en tant qu’API RESTful.

L’architecture Swift se compose d’un certain nombre de services logiques, comprenant serveurs d’objets, serveurs proxy, serveurs conteneurs et serveurs de compte, qui ensemble sont classés en tant qu’anneau. Les données sont stockées sur les serveurs d’objets avec les autres composants utilisés pour suivre les métadonnées relatives à chaque objet stocké et pour gérer l’accès aux données.

Au sein de Swift, le concept de zones permet de gérer la résilience des données. Une zone représente le sous-composant d’un anneau utilisé pour fournir une copie particulière des données, plusieurs zones servant à stocker les copies redondantes des données appelées « répliques » (avec un minimum de trois par défaut). Dans Swift, une zone peut être représentée par un seul lecteur ou serveur, en tenant compte de la répartition géographique des données entre les datacenters.

A l’instar de nombreux magasins d’objets, Swift se fonde sur l’idée d’une cohérence finale pour mettre en oeuvre la résilience des données.

Cela signifie que les données ne sont pas répliquées de manière synchrone à l’échelle d’un cluster OpenStack, comme cela pourrait être le cas avec un stockage en mode bloc. En effet, les données sont plutôt répliquées entre zones, sous forme d’une tâche en arrière-plan ; une tâche qui peut être suspendue ou qui peut échouer si les systèmes sont soumis à une charge élevée.

En comparaison du stockage en mode bloc, où la réplication syn­chrone est utilisée pour permettre un niveau élevé de disponibilité, la cohérence finale peut sembler quelque peu risquée. Toutefois, un équilibre doit être trouvé entre évolutivité, performances et résil­ience. La cohérence finale permet à une archive d’évoluer beaucoup plus facilement qu’un système reposant sur le stockage en mode bloc ; dans le cas de Swift, les serveurs proxy récupèrent la copie la plus récente des données, même si certains serveurs du cluster sont inaccessibles.

Comme avec tous les projets OpenStack, le développement de Swift se poursuit avec de nouvelles fonctions et améliorations à chaque nouvelle version. OpenStack Grizzly a apporté des contrôles granu­laires des répliques, permettant aux anneaux de disposer d’un nom­bre configurable de répliques. Les performances de lecture des objets ont également été améliorées grâce à l’idée d’un tri basé sur la syn­chronisation et destiné aux serveurs d’objets. Grâce à cette approche, les données sont distribuées par le serveur d’objets qui répond le plus rapidement ; un paramètre important pour une montée en charge sur des réseaux plus étendus.

Etant donné que Swift utilise le protocole HTTP, il serait tout à fait pos­sible d’utiliser des solutions tierces pour le stockage objet dans Open­Stack, comme les produits de Cleversafe et de Scality, ou des Clouds publics tels qu’Amazon Web Services Simple Storage Service.

La partie 2 de ce dossier traitera du choix important entre Swift et Cinder.

Pour approfondir sur Administration et supervision du Cloud

Close