Introduction
Dans le domaine du cloud computing, plusieurs acteurs sont impliqués : les fournisseurs d’offres publiques et ceux proposant le système sous forme de logiciels pouvant être employés en privé. Les solutions du cloud sont ainsi classées en deux grandes catégories : les solutions propriétaires et les solutions open source.
3.1. Les solutions du cloud computing public
Actuellement, trois acteurs potentiels existent sur le marché du cloud computing public. Windows par sa plateforme Azure, Google par sa plateforme de développement d’applications AppEngine et Amazon par ses services EC2 de l’informatique virtuelle.
3.1.1. Windows Azure
Azure est une plateforme de Microsoft pour les services PaaS du cloud computing. Il s’agit d’une plateforme de développement d’applications fournissant les services d’exécution et d’administration d’applications en offrant les outils nécessaires. Elle permet aux développeurs de programmer et de stocker directement leurs applications sur Internet en leur allouant dynamiquement des machines virtuelles de son centre de données (data center). Windows Azure est une plateforme flexible qui supporte plusieurs langages de programmations tels que .Net, C#, Java, PHP, Python, etc. De plus, elle supporte les standards et protocoles tels que SOAP, XML, REST.
L’infrastructure soutenant la plateforme Azure est basée sur la solution de virtualisation Xen (Letaifa et al, 2010).
3.1.2. Google AppEngine
AppEngine est une offre de Google pour les services de type PaaS. Le développement et le déploiement d’applications sur la plateforme de Google sont rendus possibles grâce à un SDK(22) conçu par Google et mis à la disposition des utilisateurs afin de leur permettre de développer en local pour ensuite déployer l’application vers l’Internet. L’idée est de permettre aux utilisateurs d’employer l’infrastructure de Google pour héberger leurs applications avec la possibilité de définir le groupe d’utilisateurs de cette dernière (Zahariev, 2009). Ces applications bénéficient de la haute disponibilité des infrastructures de Google.
3.1.3. La plateforme EC2 d’Amazon
Les services d’Amazon EC2 (Elastic Compute Cloud) concernent l’exposition de machines virtuelles pour les activités telles que l’hébergement, les grilles de calcul ou les tests en réseaux informatiques.
L’utilisation des services d’Amazon est facturée selon le temps d’utilisation des machines louées.
3.2. Les solutions open source
Les solutions open source du cloud computing sont destinées au déploiement de l’architecture en privé pour un usage en interne. Toutefois, les solutions proposées peuvent être utilisées pour fournir les services du cloud public. Les solutions de cloud privé implémentent généralement les services IaaS. Leur rôle consiste à gérer un ensemble de machines physiques et virtuelles dans un réseau local ou une interconnexion de plusieurs réseaux (Sempolinski et Thain, 2010). L’architecture de supervision des nœuds d’exécution des machines virtuelles de ces solutions est généralement composée d’un nœud central appelé cloud controller (CLC), de plusieurs nœuds d’exécution des services du cloud appelés Node controllers et parfois d’un ensemble de nœuds intermédiaires de supervision appelés cluster controllers. Les terminologies utilisées dans les différentes solutions existantes telles que Eucalyptus, OpenNebula, Nimbus et Openstack peuvent varier mais le principe de fonctionnement de ces différents nœuds reste approximativement le même.
Le cloud controller représente le point central de supervision et de gestion de toute l’architecture. Il représente le centre d’administration précédemment vu avec Sun et al (2011) à la section 1.2.1 de ce document.
Le rôle du cluster controller consiste à gérer un ensemble de nœuds regroupés. Il sert d’intermédiaire entre le cloud controller et les différents nœuds d’exécution de services (node controllers). L’intérêt consiste, entre autres, à désengorger le cloud controller dans sa tâche de supervision de toute l’architecture en collectant les informations au niveau des différents nœuds et en les envoyant au cloud controller suivant les requêtes de ce dernier. On peut alors avoir plusieurs cluster controllers dans une architecture de cloud computing mais seulement un unique cloud controller.
Les contrôleurs de nœuds ou en anglais node controllers (NC) représentent les points d’exécution des services du cloud. Ces nœuds sont généralement équipés des outils nécessaires pour la création et l’exécution de machines virtuelles. Dans la représentation de Sun et al (2011), ces nœuds sont localisés dans le centre de ressources du cloud.
3.2.1. Eucalyptus
Eucalyptus est un outil open source issu d’un projet de recherche de l’université de Californie. Il est développé en C, Java, Python et est disponible sous deux licences. Une licence GPL(23) gratuite supportant les hyperviseurs Xen et KVM et une licence commerciale offrant des fonctionnalités avancées telles que le support de VMware. Il permet de construire aussi bien les solutions privées du cloud computing que les solutions publiques. Son grand avantage est qu’il est intégré dans les distributions Ubuntu et Debian. Eucalyptus offre des interfaces compatibles avec les services EC2 d’Amazon. Ce qui lui confère la possibilité d’être employé pour les solutions hybrides de cloud computing. L’architecture d’Eucalyptus est constituée de quatre composants principaux (Nurmi et al, 2008 ; Alrwais, 2011).
– Le contrôleur de nœud (Node controller NC) : contrôle l’exécution, et l’arrêt des machines virtuelles présentes sur le nœud où il est exécuté.
– Le contrôleur de cluster (cluster controller CC) : collecte les informations sur les différents nœuds d’un cluster et planifie l’exécution des machines virtuelles sur chaque nœud.
– Le contrôleur de stockage (Warlus) : c’est le composant qui gère l’accès au service de stockage. Il est souvent intégré au contrôleur du cloud
(CLC).
– Le contrôleur de cloud (CLC): C’est le point d’entrée (Front end) des utilisateurs et administrateurs du système. Il collecte des informations sur les nœuds et planifie leur exécution au travers des contrôleurs de clusters (CCs). Il expose les services du cloud à travers une application Web mais également à travers des interfaces compatibles EC2.
L’annexe E.1 présente le principe de fonctionnement d’Eucalyptus.
Figure 3.1: Architecture d’Eucalyptus (Alrwais, 2011; Naing, 2012).
3.2.2. OpenNebula
Il s’agit d’une plateforme purement open source permettant de déployer des cloud privés, publics et hybrides. Mais l’idée fondamentale de la solution d’OpenNebula(24) est orientée vers une implémentation en privé afin de permettre aux utilisateurs de se connecter aux ressources internes via une interface Web (Sempolinski et Thain, 2010). La solution OpenNebula est rigidement centralisée autour d’un nœud appelé front-end, chargé de la supervision de toute l’architecture. Elle est basée sur un haut niveau de personnalisation en fournissant plusieurs modules configurables et adaptables aux besoins. Cette haute modularité est à la fois un avantage, en ce sens qu’elle permet de construire l’architecture à sa manière, mais aussi un inconvénient parce qu’elle conduit à des difficultés de configuration entrainant des erreurs de mise en oeuvre et des échecs de déploiement des machines virtuelles dans le réseau (Sempolinski et Thain, 2010).
OpenNebula supporte les hyperviseurs XEN, KVM et optionnellement VMware. L’architecture interne d’OpenNebula est constituée de trois couches d’éléments appelées respectivement : tools, core et drivers (Figure 3.2).
– Tools : c’est l’ensemble des outils de gestion de l’architecture. Il est constitué des interfaces de lignes de commandes CLI (Command Line Interface) pour l’interaction avec le système, d’un portail Web d’administration et d’utilisation du cloud, appelé sunstone(25) localisé au niveau du nœud central de l’architecture.
– Core : ce niveau consiste en un ensemble de composants impliqués dans la gestion et le contrôle des nœuds, des utilisateurs et des machines virtuelles de l’architecture. Ces différents composantscommuniquent en utilisant le protocole XML RPC.
– Driver : c’est à ce niveau que se déroulent les processus liés aux transferts de machines virtuelles d’un nœud à un autre.
Ces différentes couches s’observent sur le nœud frontal de l’architecture.
Ce dernier est ensuite relié aux nœuds d’exécution (hosts) par l’intermédiaire d’un réseau local (Figure 3.2). Les nœuds d’exécution (hosts) ne requièrent l’installation d’aucun service d’OpenNebula. Seul le front-end héberge tous les services de supervision et de gestion du cloud ; ce qui rend ce nœud l’unique point de défaillance du système. Le fonctionnement d’OpenNebula est présenté à l’annexe E.2.
Figure 3.2: Les différentes couches d’OpenNebula. (http://opennebula.org/documentation:archives:rel2.0:architecture, et Mahjoub, 2011).
3.2.3. Autres solutions
Plusieurs autres solutions existent dans le domaine du cloud privé. Ce sont Nimbus (annexe E.3), OpenStack(26), Abicloud(27) et Xen cloud plateform(28)(XCP) évoluant toutes dans la même logique que les solutions précédemment présentées. Elles sont cependant très jeunes et moins évoluées dans le domaine du cloud computing, comparées aux solutions comme OpenNebula ou Eucalyptus.
3.2.4. Solution de Naing basée sur Eucalyptus
Les solutions de cloud privé étudiées précédemment adoptent toutes des architectures centralisées de supervision des ressources. Cette centralisation quoique présentant certaines facilités de mise en œuvre pose d’énormes problèmes en termes de disponibilité des services. La moindre rupture des services au niveau du nœud central, point d’entrée du système, bloque à la fois l’administration et l’utilisation des ressources du cloud.
Naing (2012) présente ce problème en proposant une solution basée sur la gestion de la tolérance aux fautes dans l’architecture. Sa solution utilise le système d’Eucalyptus et consiste à créer un gestionnaire de clusters appelé Cluster Controller Manager (CCM). Ce dernier représente un cluster controller (CC) élu parmi les différents CCs du système. Le CC élu (l’actuel CCM) échange des informations de façon régulière avec tous les CCs du réseau de façon similaire au cloud controller. Ainsi, la panne d’un CC est automatiquement perçue par le CCM qui reconfigure le système de façon à assurer la continuité des services de supervision des différents nœuds et machines virtuelles de ce cluster. De même, la panne du CC élu (CCM) est automatiquement perçue par les différents CCs du réseau qui procèdent à l’élection d’un nouveau CCM. En outre, la solution nécessite la réplication des données du cloud controller à trois différents niveaux de l’architecture.
Conclusion partielle
Dans cette partie, nous avons présenté les solutions existantes dans le domaine du cloud computing. Ces solutions se repartissent en deux catégories. Les solutions publiques et les solutions open source pour le cloud computing privé. Nous avons montré particulièrement le fonctionnement de quelques solutions de cloud privé et constaté la gestion centralisée des ressources à leur niveau. Nous avons également montré une approche de solution proposée par Naing (2012) pour la disponibilité des services du cloud en cas de panne des nœuds de supervision. Bien que la solution proposée permette de résoudre le problème au niveau des différents CCs d’Eucalyptus, elle n’aborde pas la question de la disponibilité des services au niveau du cloud controller, qui demeure l’unique point d’entrée dans le système et dont l’arrêt bloquerait les services aux différents utilisateurs.
Dans la partie suivante, nous aborderons la présentation de notre solution qui intègre à la base la notion de la tolérance aux pannes en employant un algorithme de supervision distribué des différents nœuds du système.
22 Software Development Kit : kit de développement de logiciels. Le kit proposé par Google permet de développer en java et python. <http://cloud.google.com/products/?utm_source=google&utm_medium=cpc&utm_campaign=appenginesearch- global>.
23 General Public Licence (GPL) est une abréviation du GNU-General Public Licence GNU-GPL.
24 <http://opennebula.org/> consulté le 12/09/2012
25 http://opennebula.org/documentation:archives:rel2.2:sunstone consulté le 30/08/2012
26 http://www.openstack.org/ consulté le 12/09/2012
27 http://community.abiquo.com/ consulté le 12/09/2012
28 http://wiki.xen.org/ consulté le 12/09/2012