lundi 20 février 2012

Le cloud en mal d'interopérabilité

Le 17 février 2012 (08:30) - par Christophe Bardy
 
A l'heure où l'adoption du cloud par les entreprises s'accélère, l'interopérabilité des clouds restent un voeux pieux, avec le risque à terme d'un enfermement dans des approches propriétaires qui pourrait être nuisibles aux objectifs recherchés par les entreprises dans leur migration vers le cloud. LeMagIT fait un état des problèmes et des travaux en cours en matière d'interopérabilité.
Le cloud en mal d'interopérabilité
Depuis l’émergence du cloud, les entreprises utilisatrices se posent la question de l’interopérabilité entre les différents services cloud. Cette préoccupation n’est pas anodine. Pour nombre d’entreprises, il s’agit d’éviter les phénomènes de verrouillage (vendor « lock-in ») que l’on a connu par le passé dans les environnements physiques et de rendre fluide la migration de ressources d’un cloud vers un autre. Pour d’autres, il s’agit de simplifier la constitution d’architectures hybrides visant à mixer ressources internes et ressources cloud. Pour certains, il s’agit d’assurer la portabilité des données d’un cloud à un autre ou du datacenter de l’entreprise vers le cloud et vice-versa. Enfin d'autres encore rêvent de la possibilité de coordonner de façon transparente l’orchestration de ressources distribuées sur de multiples cloud, et donc sur des infrastructures utilisant souvent des APIs très différentes pour permettre leur pilotage.
Un univers en quête de standards
Dès 2009, la DMTF( Distributed Management Task Force) a mis en place un incubateur afin d’effectuer des travaux sur le sujet et de tenter d’élaborer des normes d'interopérabilité pour l’administration de cloud. Le groupe avait il est vrai déjà contribué à améliorer l’interopérabilité des environnements virtualisés en poussant à l’adoption du format OVF (Open Virtualization Format) qui permet de définir et modéliser des chaînes applicatives complexes incluant plusieurs machines virtuelles. OVF est aujourd’hui le format de fait d’échange de machines virtuelles entre plates-formes virtualisées. Pour avoir une idée du défi que représente l’interopérabilité dans le cloud, il suffit de constater qu’après 5 ans d’adoption rapide de la virtualisation, les éditeurs sont toujours incapables de s’accorder sur un format de disque virtuel (un problème tellement sensible que la DMTF ne l’a pas traité dans OVF). Ainsi VMware continue d’utiliser son VMDK tandis que Microsoft et Citrix lui préfèrent le VHD – et bientôt le VHDX dans Windows 8 Server - et que KVM privilégie le format QEMU (qcow2-). Et c’est sans compter avec les problèmes spécifiques qu’introduisent certains cloud comme l’utilisation de formats « propriétaires » comme le format d’image AMI d’Amazon…
Et encore ne parle-t-on ici que des problèmes liés au cloud d’infrastructure. Car si l’on aborde la question du PaaS, le problème devient inextricable. Certes le code applicatif développé pour le cloud X peut en général être porté sans trop d’efforts sur le cloud Y (disons de Heroku à Azure ou de Joyent à Heroku), mais les couches d’administration réseau, de bases de données, de load balancing et d’orchestration sont toutes différentes ce qui rend plus que délicat la migration d’une application déployée sur un PaaS X vers un PaaS Y.
Après 10 ans d’efforts pour standardiser l’exploitation de ressources informatiques dans les datacenters, un effort largement rendu possible par la standardisation d’une large part de la production informatique sur des serveurs x86 et sur un nombre réduit d’OS (comme Windows, Linux et Solaris x86), les entreprises se retrouvent donc une nouvelle fois face à la perspective de devoir gérer de multiples formats, outils et API d’administration et ce, alors qu’elles sont sous pression de la part de leur management pour adopter le cloud.
L’Open Data Center Alliance pousse les fournisseurs à plus d’interopérabilité

Cliquez pour dérouler
harmoniser la manipulation des objets d'un cloud à un autre
Au cœur de l’interopérabilité du cloud se trouve tout d’abord la possibilité de manipuler de façon standard les différents objets du cloud. Cela commence comme on l’a vu par un minimum de standardisation des images serveurs, mais aussi par une standardisation de la configuration des objets réseau (firewall, configuration réseau…). Il s’agit de répondre à des questions basiques comme comment migrer une application de mon datacenter vers le cloud ou comment migrer une application d’un cloud à un autre.
Aujourd’hui la question reste toujours problématique. Certes il est relativement simple de porter une application physique vers un conteneur virtuel et de migrer ce dernier sur un cloud d’infrastructure. Mais cela se fait toujours au prix de multiples manipulations de conversion ou d’adaptation. Par exemple, une image système destinée à fonctionner sur Hyper-V devra comporter des pilotes différents de ceux d’une image destinée à s’exécuter sur XenServer ou VMware vSphere si elle veut fonctionner de façon optimale (et parfois tout simplement démarrer). Cela contraint les entreprises à maintenir de multiples versions des mêmes images systèmes et à cultiver de vrais savoir-faire en matière de conversion de VM.
La question du paramétrage réseau est encore plus compliquée. Les cloud ont en effet une gestion du réseau assez particulière du fait de leur contrainte d’offrir une infrastructure « multitenant ». Et il est plus que probable qu’un nuage X aura une gestion du réseau différente du nuage Y (et des méthodologies différentes pour piloter les firewall, routeurs, commutateurs et autres services essentiels au bon fonctionnement d’un environnement de production informatique). Ignorer l’existence de ces différences, c’est risquer de mettre les pieds dans un environnement cloud et ne plus pouvoir en sortir (du moins facilement). C’est d’ailleurs la situation dans laquelle se trouvent, de facto, la plupart des entreprises qui ont adopté très tôt la virtualisation et le cloud, leurs efforts s’étant largement concentrés sur un fournisseur unique.
Bataille autour de l’orchestration de clouds d’infrastructure
Ce vendeur, VMware, a perçu très tôt les problèmes d’interopérabilité que pose la migration d’infrastructures entières vers le cloud et leur orchestration. Et il a mis en place un ensemble de mécanismes propriétaires et ouverts (ou en tout cas documentés) pour permettre l’interconnexion transparente de ressources situées au sein de datacenters d’entreprises, avec des ressources situées dans le cloud (via son outil d’orchestration vCloud). Avec vCloud, il est en théorie possible d’opérer un ensemble de datacenter virtuels comme une entité unique quelle que soit leur localisation ou le fournisseur qui les héberge. Cisco a encore un peu plus facilité la gestion réseau d’un cloud distribué entre de multiples datacenters en apportant des technologies de tunneling comme OTV (Overlay Transport Virtualization) dans ses commutateurs Nexus – OTV fait ce que l’on appelle du MAC in IP, c’est-à-dire qu’il permet d’encapsuler un trafic Ethernet de niveau 2 au niveau 3 et permet donc à des infrastructures cloud dans deux datacenters d’être gérées comme une seule entité - et en intégrant dans son commutateur Nexus 1000v le support de technologies comme VXLAN. Ces technologies n’en sont toutefois qu’à leurs débuts ou restent très largement limitées au monde VMware (même si VMware a soumi svCloud à la DMTF dans l'espoir d'en faire la base d'un standard d'interopérabilité).
Leur interopérabilité avec des environnements tiers, par exemple basés sur KVM, Xen ou Hyper-V est pour l’instant... nulle (VXLAN devrait arriver sur Hyper-V 3.0 fin 2012 avec le portage en cours du Nexus-1000v pour l’hyperviseur de Microsoft). VMware contre cet argument en notant qu’il existe de multiples fournisseurs vCloud et que les entreprises ont donc le choix entre de multiples cloud. C’est vrai… À condition toutefois qu’elles standardisent l’orchestration de leur cloud interne sur vCloud. Bref, pour gagner une forme d’interopérabilité dans le monde cloud tel que vu par VMware, il faut déployer les solutions de l’éditeur de bout en bout aussi bien en interne qu’en externe. C’est un peu comme si l’on revenait 30 ans en arrière, où pour être interopérable avec les mainframes IBM, il fallait faire tourner leur OS et leur moniteur transactionnel et c’est pour le moins une curieuse interprétation de la notion d’interopérabilité…
À la décharge de VMware, sa vision du cloud n’est guère différente de celle imaginée pour l’instant par Microsoft, pour lequel le discours sur l’interopérabilité se résume largement à encourager les entreprises à adopter System Center 2012 pour gérer l’ensemble de ses infrastructures virtualisées(SC 2012 supporte la gestion de ressources virtualisées avec XenServer, vSphere et Hyper-V ainsi que la gestion de ressources sur le nuage maison, Azure). Encore une fois, les deux titans de la virtualisation ont des excuses. Le domaine est récent et évolue à une vitesse accélérée. Mais faute de prévoir très tôt l’interopérabilité, les deux sociétés s’exposent à reproduire des erreurs, qui, par le passé, ont toujours fini par leur revenir dans la figure que ce soit avec l’émergence de Linux contre Windows, ou avec les ennuis juridiques liés aux poursuites initiées par différentes agences en charge de la concurrence dans le monde.
Le monde open source en ébullition
Dans un monde où les technologies évoluent à un rythme rapide, l’Open Source s’organise d’ailleurs rapidement et promet de prendre en compte le besoin d’interopérabilité (tant que l’on reste dans le monde libre). Depuis plusieurs années, Red Hat travaille au développement d’une série d’API censées apporter l’interopérabilité entre architectures virtualisées.Son projet Deltacloud est aujourd’hui un projet de premier rang de la fondation Apache, visant à fournir une API unique pour gérer de multiples clouds hétérogènes (et Red Hat a, comme VMware, soumis deltaCloud à la DMTF). Et le moins que l’on puisse dire est que la route risque encore d’être longue pour que deltaCloud répondent aux besoins des entreprises. La partie « compute « de l’API ne supporte en effet que des fonctions basiques d’inventaire, de création, démarrage et arrêt de machines virtuelles sur une dizaine de « cloud » (dont ceux pilotés par les technologies VMware, OpenStack, Amazon EC2, et RHEV-M).

Aucun commentaire:

Enregistrer un commentaire