Vous êtes sur la page 1sur 8

kokou Agbedanou

Gestion du stockage
Le stockage (storage) est géré par le module Cinder pour la partie stockage en mode bloc et par le module
Swift pour le stockage en mode objet.

Cinder permet d’exploiter les typologies de stockage classique (SAN ou NAS) et les typologies de
stockage distribué (Ceph).

1. Typologie du stockage

a. Stockage classique SAN/NAS

Le stockage classique est constitué d’éléments bien connus et robustes basés sur des baies fournies par
des constructeurs. Il peut s’agir de SAN (Storage Area Network) en cas de création d’un réseau dédié au
stockage (fiber channel, iSCSI), indépendant du réseau data ou de simples baies NAS (Network Storage
Area) pour du stockage de fichiers. Le SAN est indispensable pour héberger les VM d’un IaaS et pour
traiter des problématiques de sauvegarde et d’archivage de données.

b. Stockage distribué Ceph

Le stockage distribué a tout son sens dans l’esprit cloud computing où le besoin de disposer rapidement
(et parfois de façon temporaire) d’espace important de stockage de données est primordial. Devant le
coût parfois prohibitif des baies de stockage propriétaires et devant la disponibilité du 10 Gb/s en matière
de réseau, de nombreuses tentatives de logiciels open source de stockage distribué ont vu le jour depuis
2012 : GlusterFS, MooseFS, Lustre, GFS2 ou Ceph dans le monde du libre. Dans le monde propriétaire, des
produits sont également présents comme par exemple : Castor de Caringo ou Ring de Scality.

Ceph est un moteur libre de stockage distribué, basé sur l’algorithme CRUSH.

Le produit Ceph est issu de recherches de l’Université de Californie à Santa Cruz puis du travail de Sage
Weil qui a créé la société Inktank Storage en 2012 afin de fournir du support sur Ceph. C’est Red Hat qui a
récemment racheté Inktank Storage en avril 2014. La

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -1-
kokou Agbedanou

dernière version majeure de Ceph appelée Giant est sortie le 29 octobre 2014.

Le principe est d’utiliser un cluster de serveurs en tant que commodités pour le stockage des données
plutôt que des baies traditionnelles. Les disques des serveurs sont agrégés pour fournir un espace de
stockage.

Les avantages sont nombreux (coût moindre, indépendance matériel/logiciel du constructeur de baie).
Ceph permet le déploiement du mode bloc et du mode objet. Les données sont toujours répliquées sur
plusieurs nœuds.

Les principaux concepts sont les suivants :

ˇ
API Librados : l’API de Ceph permet aux applications externes d’accéder au stockage Ceph
appelé Rados et composé des objets de stockage distribués. L’accès se fait via une
programmation possible en C/C++/Java, Python et PHP.
ˇ
Passerelle RadosGW : passerelle REST permettant de fournir du stockage Ceph compatible
Amazon S3, OpenStack Swift...
ˇ
Module RBD (Rados Block Device) : RBD permet de fournir du stockage bloc Ceph pour le
système d’exploitation.
ˇ
Ceph FS : système de fichiers de Ceph, compatible POSIX. Ceph FS peut être monté depuis le
kernel Linux d’un client.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -2-
kokou Agbedanou

Schéma de la stack Ceph

Ceph peut être utilisé indépendamment d’OpenStack.

 Site de téléchargement : http://ceph.com/resources/downloads/

2. Modules de stockage sous OpenStack

a. Le mode bloc avec Cinder

Introduction

Le module de stockage bloc d’OpenStack s’appelle Cinder. Il permet de fournir des volumes de stockage
réseau (des "vrais" disques qu’il faut formater) qui peuvent être montés dans les machines virtuelles.

Principes

Les grands principes de Cinder sont les suivants :

ˇ
Création de volume, suppression et attachement vers des instances.
ˇ
Création de snapshots, qui peuvent être restaurés ou tout simplement utilisés pour la création
de nouveaux volumes.
ˇ
Boot sur volume distant.
ˇ
Présence d’une API REST.
ˇ
Utilisation du stockage simple d’un serveur Linux.
ˇ
Présence d’un support de stockage unifié pour de nombreuses plates-formes de stockage, y
compris Ceph, NetApp, Nexenta, SolidFire et Zadara.

Architecture

Cinder est composé des éléments suivants :

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -3-
kokou Agbedanou

ˇ
cinder-api : c’est le point visible des autres services d’OpenStack. Il interroge le composant
Cinder-volume.
ˇ
cinder-volume : il contient les informations sur les volumes. La commande cinder list
affiche la liste des volumes créés :

# cinder list
+ ------------------------------------+-----------+------+------
-------------+----------+-------------+
| ID | Status | Display Name
| Size | Volume Type | Bootable | Attached to |
+ ------------------------------------+---+-------+------+------
-------------+----------+-------------+
| 30fe62d3-aa7f-435a-80b7-351e254422ec | available | demo-volume3
| 5 | None | false | |
+ ------------------------------------+-----------+-------+-----
-------------+----------+-------------+

ˇ
cinder-database

La base de données de Cinder est composée de 21 tables (la plus importante étant la table
volumes) :

+ --------------------------+
| Tables_in_cinder |
+ --------------------------+
| backups |
| cgsnapshots |
| consistencygroups |
| encryption |
| iscsi_targets |
| migrate_version |
| quality_of_service_specs |
| quota_classes |
| quota_usages |
| quotas |

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -4-
kokou Agbedanou

| reservations |
| services |
| snapshot_metadata |
| snapshots |
| transfers |
| volume_admin_metadata |
| volume_glance_metadata |
| volume_metadata |
| volume_type_extra_specs |
| volume_types |
| volumes |
+--------------------------+

ˇ
cinder-scheduler : il affecte les requêtes dans une file d’attente et planifie l’exécution des
tâches et l’utilisation des serveurs de block storage pour l’attachement des volumes.

Workflow

Cinder est utilisé par nova-compute en toute fin de chaîne du provisionning de VM. nova-compute
demande à cinder-api l’attachement d’un volume de stockage bloc. cinder-api retourne à nova-compute
l’information du volume, rendant ainsi possible la création de la machine virtuelle.

b. Le mode objet avec Swift

Introduction

Le module de stockage objet d’OpenStack s’appelle Swift. C’est par exemple un concurrent du stockage
objet S3 du pionnier Amazon ou de la solution Castor de Caringo.

Swift, qui permet de créer un cloud storage pour stocker n’importe quel type d’objet (comme des fichiers
de tout type de format), est basé sur le mécanisme de réplicas garantissant la sécurité de la persistance
des données sur plusieurs nœuds. L’accès à un objet s’effectue via le protocole HTTP(S) par un simple
appel REST de type : https://API.swift/account/container/object.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -5-
kokou Agbedanou

Principes

Les grands principes de Swift sont les suivants :

ˇ
Stockage de milliards de fichiers distribués sur du matériel standard.
ˇ
Présence d’une API REST.
ˇ
Absence d’adhérence au hardware.
ˇ
Redondance gérée par Swift et non par le hardware (ce qui est très différent de l’approche de la
technologie RAID).
ˇ
Utilisation de la technologie standard rsync pour la réplication des données.
ˇ
Existence d’une URL unique par objet stocké ; cela permet aux développeurs de pouvoir
interagir avec les objets en utilisant les librairies disponibles pour la plupart des langages
(Java, Python ou Ruby).
ˇ
Scalabilité : on peut ajouter des back-ends pour étendre le cluster Swift.
ˇ
Réplication de chaque objet N fois (par défaut trois fois).
ˇ
Absence de SPOF (Single Point of Failure).

Les cas d’utilisation de Swift sont donc naturellement à destination du stockage de données des
applications web à forte charge mais également à destination du stockage de fichiers.

Architecture

Swift est composé des éléments suivants :

ˇ
Des comptes : les comptes sont vus comme des utilisateurs ; dans chaque compte, il peut y
avoir un ou plusieurs conteneurs.
ˇ
Des conteneurs : les conteneurs sont des objets qui contiennent un ou plusieurs objets de type
fichier. Ils sont vus comme des répertoires ou des buckets (seaux) dans la terminologie du
cloud storage.
ˇ
Des fichiers : ce sont les objets finaux qui permettent le stockage.

Système d’anneau

L’implémentation de Swift passe par l’installation d’un proxy server qui va absorber les requêtes clients
d’interrogation (par exemple, un get d’un objet file). Ce proxy interroge

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -6-
kokou Agbedanou

alors le serveur d’authentification pour vérifier le token client ; si la vérification est valide, le proxy transmet
la requête à un pool de ressources de stockage constitué de n serveurs qui ont des périphériques divers
attachés. Ces serveurs font partie d’un ensemble appelé anneau (dans le sens où les objets file sont
toujours répliqués sur les nœuds).

L’anneau Swift

API swift

Swift est accessible via la commande curl. La syntaxe est la suivante :

# curl -X < commande REST> https://< nom_cluster_swift> / < nom du


compte> / < nom du container> / < nom de l'objet>

Commandes REST

Les commandes REST possibles sont :

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -7-
kokou Agbedanou

Commandes HTTP REST Commentaire

GET Affichage du contenu d’un container ou d’un compte.


Download d’objets.

PUT Création de containers. Upload d’objets.

POST Mise à jour de métadonnées (metadata).

DELETE Suppression d’objets.

HEAD Affichage d’informations sur les headers.

Exemples :

# curl -X PUT https://swift.cloud-


morning.fr/client1/container1/ordonnance18052015_23.pdf

Cette commande permet de stocker le document nommé ordonnance18052015_23.pdf du client 1 dans le


container 1 sur le cluster Swift swift.cloud-morning.fr.

# curl -X GET https://swift.cloud-morning.fr/client1/container1

Cette commande affiche le contenu du container 1 du client 1.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -8-

Vous aimerez peut-être aussi