Kilo, la version d’OpenStack qui embarque machines physiques et conteneurs

Répondre à des besoins plus hétérogènes

La fonction de gestion des machines physiques, poétiquement nommée Ironic, fait partie des nouveautés de la dernière version Kilo d’OpenStack.

Elle s’accompagne de Magnum, un module qui fait exactement l’inverse d’Ironic : il permet de déployer dans OpenStack des conteneurs, c’est-à-dire des machines virtuelles qui hébergent l’application et ses dépendances (bibliothèques, données, configurations, etc.), mais pas le système d’exploitation sous-jacent.

Les conteneurs, qui partagent en fait l’OS de la machine physique qui les exécute, ont été inventés dans Solaris et sont communément utilisés sur Linux, en particulier par les hébergeurs, qui peuvent ainsi concentrer plus d’instances d’un site web, par exemple, sur un serveur physique.

« Avec Ironic et Magnum, nous avons la volonté de répondre à des besoins plus hétérogènes, pour un public plus large », ajoute Mark Collier. L’OpenStack Summit de Vancouver a par ailleurs été animé de plusieurs débats sur les moyens de faire décoller OpenStack au-delà de la niche des opérateurs télécoms-institutions financières qui constitue la majeure partie de ses utilisateurs

Selon les témoignages de différents participants du salon, il apparaît néanmoins que ce sont bien les opérateurs télécoms qui devraient profiter le plus de l’utilisation des machines physiques, car elle devrait fluidifier en particulier la diffusion des flux vidéo dans leurs services de VOD.

« Pour le reste, il est peu probable que les gens en charge des bases de données physiques dans les entreprises acceptent d’en confier l’administration aux équipes responsables de l’infrastructure », fait remarquer Boris Renski, le cofondateur de Mirantis, l’un des principaux éditeurs d’une distribution OpenStack

L’enjeu des conteneurs débouche sur une guerre des formats

En revanche, l’engouement est inversement proportionnel pour les conteneurs. « Ils présentent l’énorme avantage de faire fonctionner une même application dans n’importe quel Cloud », explique Joseph Fitzgerald, qui dirige la branche Administration chez Red Hat. Pour lui, les conteneurs permettraient par exemple à l’éditeur d’une application SaaS publique d’aller exécuter son service dans le Cloud privé d’une entreprise, faisant ainsi tomber le spectre de la confidentialité des données qui décourage les entreprises de passer au Cloud.

« A l’inverse, une entreprise qui a mis au point en interne une application peut, en cas de pic d’activité, aller l’exécuter dans un Cloud public. Cela revient à faire du Cloud hybride sans pour autant avoir à le configurer », se félicite-t-il.

Problème, les acteurs commerciaux de l’écosystème OpenStack n’ont pas attendu que la fondation Open Source implémente le concept des conteneurs. Si bien que le concept part dans tous les sens.

Avant Magnum, Mirantis avait déjà doté sa distribution de la possibilité d’orchestrer le fonctionnement de conteneurs en grappes Kubernetes. Kubernetes est le dispositif de Google qui lui permet de déployer dans son propre Cloud des clusters de conteneurs, eux-mêmes au format Docker. Et un conteneur Docker est un conteneur Linux - au format LXC - enrichi d’une API pour adapter le conteneur à son environnement, reconfigurer l’application qu’il héberge et définir les règles de répartition de charge.

Red Hat, Cisco, Microsoft et VMware (à moins que ce soit finalement Pivotal, les deux entités étant cousines sous la tutelle d’EMC), proposent également leurs propres implémentations de clusters Docker. Et pour compliquer le tout, Amazon et Canonical proposent même un format alternatif à Docker. LXD, celui de Canonical, revient à un conteneur LXC compressé, de sorte qu’il consommerait 14 fois moins de stockage et de puissance de calcul qu’un Docker.

« Il existe un enjeu viral : les entreprises utilisent tel ou tel format dans leur Cloud privé, de sorte que, lorsqu’elles voudront basculer dans un Cloud public, elles choisiront celui qui utilise les mêmes technologies », commente Craig McLuckie, directeur produit pour la branche Cloud Services de Google.

Mark Shuttleworth, le PDG de Canonical, est quant à lui persuadé de définir un nouveau standard : « 55% des distributions OpenStack en production (Mirantis, RackSpace, HP Helion, etc., ndr) reposent sur notre Linux Ubuntu. Nous guidons les choix techniques », a-t-il déclaré lors d’une séance plénière.

Pour sa part, Magnum, qui passe par un système de baie virtuelle pour empaqueter les conteneurs avec la couche d’orchestration du module Heat, serait compatible avec n’importe quel format. Cependant, dans le monde des datacenters virtuels, Red Hat avec Atomic, Ubuntu avec Snappy, CoreOS et bientôt VMware avec Photon proposent des hyperviseurs ultra-allégés pour condenser encore plus de conteneurs sur une machine physique. On ne sait pas encore comment ces derniers seront pris en charge par OpenStack.

Kilo, 11^e version d’OpenStack

Les autres nouveautés de la version Kilo d’OpenStack sont moins sujettes à polémique. Nova, la couche qui gère les ressources de calcul, permet désormais de changer les caractéristiques d’une machine virtuelle à la volée pour, par exemple, ne pas avoir à redémarrer une base de données quand on met à jour une application.

Swift, pour le stockage objet, apporte plus d’options pour affiner les règles de stockage et de duplication dans un cluster.

Cinder autorise désormais qu’un même volume virtuel de données soit utilisé en mode bloc par plusieurs serveurs virtuels - ce qui se révèle utile en cas de migration, ainsi qu’en cas de sauvegarde/restauration.

La couche réseau Neutron intègre la seconde génération de son module de répartition de charge désormais compatible IPv6, la sécurité d’OpenVSwitch et les commandes MTU.

Le service d’authentification Keystone, enfin, se dote de l’ambitieuse fonction Identity Federation qui, à terme, doit permettre d’étendre un même Cloud sur plusieurs datacenters, voire sur des infrastructures virtuelles externes privées ou publiques.