OpenNebula

Description g´en´erale

La syst`eme OpenNebula [OpenNebula] voit le jour en 2005 `a l’universit´e Com- plutense de Madrid dans le cadre du projet europ´een open source RESERVOIR [87]. Son objectif dans le cadre de ce projet est l’administration des IaaS virtualis´es. Autrement dit, il fournit des services permettant de d´eployer et d’ex´ecuter dans un environnement mat´eriel virtualis´e des VM. Notons qu’une version commerciale d’OpenNebula (OpenNebulaPro) est disponible depuis 2010.

Dans sa version actuelle, OpenNebula est capable de prendre en compte simul- tan´ement dans l’IaaS des hyperviseurs Xen [23], kvm [97] et VMware [VMware.org]. Il organise l’IaaS sous forme de clusters et de VLAN (r´eseaux virtuels). Un cluster contient un ensemble de machines physiques tandis qu’un VLAN est d´efini pour un ensemble de VM. Lors de la cr´eation d’une VM, le client choisit la machine et le VLAN dans lequel il souhaite l’ex´ecuter. Notons que dans l’esprit du cloud, il ne revient pas au client de choisir la machine sur laquelle il souhaite ex´ecuter sa VM.

Toutes les op´erations d’administration sont coordonn´ees `a partir d’une unique machine de l’IaaS appel´ee Frontend. Son fonctionnement est r´egi par cinq processus et une base de donn´ees (figure 7.3) :

– Virtual Machine Manager (VMM) Driver : il g`ere les API d’interfa¸cage avec les diff´erents hyperviseurs pr´esents dans l’IaaS. Pour cela, il d´eploie sur toutes les machines de l’IaaS les scripts d’interfa¸cage avec l’hyperviseur sur la machine. – Transfert Manager (TM) Driver : il g`ere le transfert des images de VM dans

diff´erentes situations : avant leur ex´ecution (du serveur de stockage vers la machine d’ex´ecution de la VM) ; pendant leur ex´ecution (migration de VM d’une machine `a une autre) ou apr`es leur ex´ecution (suppression ou sauvegarde de l’image).

– Information Manager (IM) Driver : il fournit les sondes de monitoring et g`ere les informations que celles-ci obtiennent de l’ex´ecution des VM. Il d´eploie sur toutes les machines de l’IaaS une sonde (en fonction de l’hyperviseur utilis´e) charg´ee de collecter les informations li´ees aux VM en cours d’ex´ecution sur la machine.

– Scheduler : Il g`ere les politiques de consolidation des VM dans l’IaaS.

– Oned : Il configure, d´emarre et orchestre l’ex´ecution des processus pr´ec´edents. C’est le point d’entr´ee et de ralliement de l’ensemble de ces processus.

– DB : C’est la base de donn´ees qui contient toutes les informations concernant l’´etat de l’IaaS et de ses utilisateurs. Elle correspond au SR de notre mod`ele de SAA.

Interop´erable

OpenNebula fournit plusieurs moyens de communication avec l’ext´erieur. Ces moyens sont bas´es sur un ensemble d’API de bas niveau (utilisables par des d´eve- loppeurs d’extension `a OpenNebula) et une interface de ligne de commandes. Cette derni`ere est essentiellement r´eserv´ee aux acteurs humains du cloud. Les interfaces de Syst`eme d’administration autonome adaptable : application au Cloud

7.2. SAA POUR LE CLOUD 75

Figure 7.3 – Composition d’OpenNebula

bas niveau et l’interface de ligne de commandes sont utilis´ees pour l’ex´ecution des commandes d’administration de base (r´eservation de VM, d´emarrage, arrˆet de VM, etc.). OpenNebula ne fournit aucun support permettant aux entreprises de facilement d´eployer et administrer leur applications dans l’IaaS. Cependant, ses API peuvent ˆetre exploit´ees par un SAA de niveau entreprise afin d’automatiser les op´erations de r´eservation et de monitoring des VM d’une entreprise. Par contre, en dehors de la communication avec les plateformes Amazon EC2 [61] et ElasticHost [ElasticHosts] (deux plateformes payantes de cloud), OpenNebula ne dispose d’aucun autre moyen de l’adapter pour l’initiation de la collaboration avec d’autres plateformes de cloud.

Auto-r´eparable

OpenNebula g`ere deux types de pannes : pannes de machines et pannes de VM. Dans les deux cas, l’administrateur d´efinit au d´emarrage de Oned, les politiques de r´eparation qu’il d´esire appliquer en cas de pannes. OpenNebula utilise le m´ecanisme d’´ev´enement-action (qu’il appelle Hook ). Un ´ev´enement correspond `a la variation de l’´etat d’une machine (physique ou VM). L’´etat de la machine est r´eguli`erement renseign´e par les sondes de l’IM Driver.

L’ex´ecution des actions associ´ees `a un ´ev´enement est locale (sur la machine d’ex´e- cution de Oned ) ou distante (sur la machine o`u la panne a ´et´e d´etect´ee). Cette ex´e- cution est donc limit´ee `a une seule machine. Il revient `a l’administrateur de d´efinir le lieu d’ex´ecution des actions de r´eparation. De plus, les Hook d’OpenNebula ne permettent pas de prendre en compte les pannes concernant ses propres serveurs. En effet, ne faisant pas partie des pr´eoccupations d’OpenNebula, aucune sonde n’est pr´evue pour leur surveillance. La panne d’un serveur DNS par exemple ne pourra ni ˆetre d´etect´ee ni ˆetre r´epar´ee par OpenNebula.

Extensible

La gestion de l’IaaS par OpenNebula repose enti`erement sur l’extension de ses ´el´ements. En effet, il d´emarre l’IaaS sans aucun ´el´ement et attend leur ajout par l’administrateur. C’est ainsi que les clusters de machines, les utilisateurs et les d´efi- nitions de VM lui sont rajout´es pendant son ex´ecution. Il fournit parmi ses API le moyen d’ajouter/retirer des ´el´ements de l’environnement. Cependant, il ne permet pas la modification des ´el´ements pr´ealablement ajout´es. Par exemple, la modifica-

7.2. SAA POUR LE CLOUD 76 tion des caract´eristiques (nom DNS ou adresse r´eseau) d’un VLAN enregistr´e n’est pas possible. De la mˆeme fa¸con, l’ajustement des ressources d’une VM en cours d’ex´ecution dans l’IaaS n’est pas permis.

Programmable

Aucune interface de programmation n’est fournie pour les applications entre- prises. La programmation des politiques d’administration dans OpenNebula se limite uniquement au niveau de l’IaaS. La consolidation de VM est r´ealis´ee par un proces- sus particulier : le Scheduler. Ce dernier s’ex´ecute sur le Frontend et est ind´ependant de l’ex´ecution de Oned. Il s’ex´ecute r´eguli`erement `a la recherche de VM devant ˆetre d´eplac´ees vers des machines plus ad´equates selon la politique de consolidation. Dans son implantation actuelle, le Scheduler d’OpenNebula propose quatre politiques de consolidation : ´eclatement/regroupement de VM suivant leur nombre sur une ma- chine, ´eclatement/regroupement de VM suivant leur consommation CPU. Toutes ces politiques sont utilisables simultan´ement, ce qui peut entraˆıner des contradictions (´eclatement pour certaines VM et regroupement pour d’autres). L’int´egration de nouvelles politiques `a ce Scheduler est impossible. Le seul moyen de l’am´eliorer est son remplacement tout entier. Cependant, il n’est pas pr´evu de support logiciel pour la conception de politique de consolidation. C’est la raison pour laquelle seules des solutions issues de son ´ecosyst`eme (d´eveloppements auxiliaires au projet OpenNe- bula) existent. Il s’agit des schedulers Haizea [89] et Claudia [cla].

Les politiques de consolidation de VM sont associ´ees par le propri´etaire de la VM lors de sa r´eservation. Il semble ´etrange qu’OpenNebula utilise cette strat´egie. En effet, la prise de d´ecision pour la consolidation devra prendre en compte les exigences particuli`eres de chaque VM et non de celui du cloud dans son ensemble. Rappelons que l’objectif de la consolidation dans le cloud est d’optimiser l’utilisation de ses ressources et non de celles des VM. La consolidation est r´ealis´ee dans l’int´erˆet du fournisseur du cloud et non de celui de la VM `a qui des ressources sont allou´ees et garanties.

Adaptable

La construction d’OpenNebula sous forme modulaire le rend enti`erement adap- table. Toutes les tˆaches d’administration sont identifiables et rempla¸cables sans au- cun besoin de connaissance de l’implantation enti`ere d’OpenNebula (`a l’exception du Scheduler ). En effet, il associe `a chacun de ses services un ensemble de scripts d´efinis dans un r´epertoire pr´ecis du Frontend de telle sorte que la modification du service s’effectue `a un unique endroit. Cependant, il n´ecessite de la part de l’admi- nistrateur une expertise vis `a vis des syst`emes Linux. De plus, pour les services les plus basiques, comme le moyen de connexion sur les machines distantes (protocole SSH), il est extrˆemement difficile de les adapter. En effet, son utilisation par tous les services, implique que son adaptation entraˆınera celui de tous les services.

En outre, on pourrait se poser la question de la dynamicit´e de l’adaptabilit´e d’OpenNebula. La modification d’un de ses modules n´ecessite le red´emarrage de l’ensemble de ses serveurs ainsi que des VM en cours d’ex´ecution dans l’IaaS. Syst`eme d’administration autonome adaptable : application au Cloud

7.2. SAA POUR LE CLOUD 77 Langages d´edi´es

OpenNebula ne fournit aucune facilit´e langage pour l’expression des politiques d’administration. L’administrateur doit avoir une bonne comp´etence en program- mation syst`eme Linux et Java.