Au bureau, en déplacement ou sur un transat, l’équipe Osones profite de l’été pour vous proposer des “cahiers de vacances” : des retours concis et illustrés de nos conférences favorites durant l’#OpenStackSummit de Boston.

On continue notre tournée estivale avec un focus sur Cinder ! Vous pourrez également retrouver nos focus sur OpenStack-Ansible et Heat.

Qu’est-ce que Cinder ?

Cinder est le service de stockage bloc d’OpenStack. Il virtualise la gestion des périphériques de stockage blocs et fournit aux utilisateurs une API pour demander et consommer des ressources sans se soucier de savoir où leur stockage est effectivement déployé ou sur quel type de périphérique. Cela se fait par l'utilisation soit d'une implémentation de référence (LVM), soit d'un pilote pour un autre stockage.

Cinder : not just for secondary attached storage !

Cette semaine, c’est une conférence présentée par John Griffith de Netapp que nous souhaitons mettre en avant. Travaillant depuis 2011 sur Cinder, John déplore que dans les cas de figure qu’il rencontre, Cinder est encore très souvent vu comme un mode de stockage secondaire rattaché aux instances Nova. Or, si c’était bien le rôle historique de ce service, cantonner Cinder à son rôle de fournisseur de stockage persistant pour les instances serait se priver par la même occasion de nouvelles fonctionnalités intéressantes.

Parmi celles-ci, prenons celle qui consiste à utiliser Cinder comme backend de stockage pour le service Image (Glance) en lieu et place de Swift, souvent utilisé pour cela. Drôle d'idée ? Pas tant que ça si l'on se place dans la nécessité de démarrer les instances sur le principe Boot From Volume (BFV) pour, par exemple, réduire au maximum la consommation d'espace sur les disques locaux des compute nodes.

Avec Glance utilisant un backend Swift, le BFV nécessite un transfert de l'image dont la durée se mesure en minute(s). Avec Glance utilisant un backend Cinder, ce transfert est inutile si l'image est déjà présente sur un volume (et si le backend de stockage supporte cette fonctionnalité). Le bénéfice est immédiat : l'opération qui pouvait durer plus d'une minute ne dure plus qu'une poignée de secondes !

Magnifique me direz-vous, mais il faut tout de même penser à reconfigurer le service cinder-api côté contrôleur avec les paramètres adaptés au backend !

Et pour parler du futur (proche), voici ce que l'on peut trouver dans le product backlog :

• rendre le BFV automatique et définissable comme le comportement par défaut. L'utilisateur n'aurait donc plus à gérer le BFV explicitement (le disque éphémère fait déjà cela mais il disparaît avec l'instance lorsque celle-ci est supprimée)
• introduire le principe au niveau des flavors en leur faisant porter un nouveau "flag"
• introduire la notion de "cinder image backend driver" dans nova

Juste un rappel pour finir : la "live migration" d'instance fonctionne même si celle-ci possède un volume Cinder attaché !

Vous pouvez retrouver la conférence dont sont tirées ces informations sur Youtube :

RDV la semaine prochaine pour un nouvel article de notre série estivale sur l'OpenStack Summit de Boston, et d'ici là sur Twitter !

Vous pourrez également retrouver nos focus sur OpenStack-Ansible et Heat.