Les technologies du Cloud Computing

Les vacances sont finies et les affaires reprennent avec plus d’open source et de cloud computing. Lors d’un précédent article, nous avons essayé de trouver une définition à peu près convenable du cloud computing de manière générale. Ceci s’est avéré relativement complexe et hasardeux. J’ai finalement choisi de conserver la définition proposée par Wikipedia en Anglais.

A défaut de réussir à définir conceptuellement le cloud computing, nous allons essayer de le définir technologiquement. Cet exercice devrait être largement plus simple que le précédent car les ressources abondent sur ce plan. Comme vous vous en doutez déjà, il existe de nombreux types d’infrastructures physiques et applicatives placées sous la dénomination de cloud computing. Nous essayerons de faire une sélection des technologies réccurentes.

La virtualisation

Lorsqu’est évoqué la notion de cloud computing, la notion de virtualisation n’est pas bien loin. La montée en popularité du cloud computing coïncide largement avec la monte en popularité des plate-formes de virtualisation. Bien qu’il existe de nombreux types de virtualisation, la virtualisation de systèmes d’exploitation est la plus fréquente, de loin. Nous pouvons affirmer de manière relativement sûre que la base essentielle du cloud computing est la virtualisation de systèmes d’exploitation.

La virtualisation de système d’exploitation n’est cependant pas un phénomène récent. Les premières applications de VMWare datent de 1998. L’amélioration des processeurs x86 n’est certainement pas étranger à ce phénomène avec la multiplication et la densification des coeurs de calcul. La montée du cloud computing est sans aucun doute liée avec la montée en puissance des applications d’automatisation des plate-formes de virtualisation. Cette automatisation permet une flexibilité exceptionnelle et une réactivité dans l’évolution du cloud.

La place de l’open source

Alors que l’on pourrait croire que l’acteur le plus populaire dans ce domaine est VMWare, la réalité ne confirme pas cette intuition. L’open source joue un rôle essentiel dans le domaine du cloud computing à travers l’hyperviseur Xen. Le cloud publique d’Amazon est basé sur le projet Xen tout comme l’offre de serveur virtuel privé de Gandi. Cette adoption massive peut probablement s’expliquer par la nature open source de l’hyperviseur ayant permis le développement des outils d’automatisation mais aussi par la faible perte de performance. Bien que le projet KVM ait été intégré dans le noyau Linux et choisi par différentes distributions, ceci signifie en aucun cas la fin du projet Xen.

Dans le cas du déploiement de grands clouds publiques, l’utilisation des plate-formes de virtualisation propriétaires telles que VMWare ou Hyper-V ne semblent pas viables financièrement. Les licences VMWare sont exceptionnellement coûteuses, de même pour les licences Windows 2008 Server. Un grand cloud public basé sur ces technologies rendrait l’offre particulièrement peu compétitive. De plus, l’hébergeur dépendrait totalement de l’éditeur pour les fonctionnalités qu’il peut implémenter et n’aura que peu de marge pour innover. L’utilisation des outils propriétaires peut être viable financièrement dans le cadre de clouds privés de taille modeste bien que la gratuité de XenServer de Citrix ne facilite pas l’adoption.

La mise en réseau du stockage

Tandis que les deux premières technologies sont visibles par les utilisateurs des clouds, le troisième l’est nettement moins. Traditionnellement, les unités de stockage de masse sont connectées directement sur les serveurs. Concrètement, cela se traduit par la connexion des disques dur directement sur le bus ATA ou SCSI de chaque serveur. Cette forme de stockage a comme avantage d’être particulièrement simple mais a comme désavantage d’être très peu flexible.

La mise en réseau des éléments de stockage à travers le SAN (Storage Area Network) a permis de s’affranchir de nombreuses contraintes. Cette flexibilité exceptionnelle a permis aux clouds de pouvoir s’automatiser rapidement avec notament l’utilisation des techniques de snapshots ou de déduplication. De plus, le réseau de stockage a permis d’augmenter massivement les performances des IO permettant de pouvoir centraliser les données. Cette centralisation a rendu possible les techniques de migration automatique à chaud et de répartition de charge dynamique entre différents hyerviseurs.

Au final, les technologies du cloud computing sont plus simples à cibler que le concept global. J’aurais l’occasion d’évoquer et de traiter les réseaux de stockage en détail ultérieurement. Ces trois technologies sont des technologies « centrales » autour desquelles peuvent en orbiter de nombreuses autres.

De la différenciation hyperviseur type 1 / type 2

tech-presentation-2A travers cet article, je souhaiterais exposer et argumenter mon point de vue sur les appellations d’hyperviseur qui fleurissent un peu partout sur Internet. Ceux qui suivent régulièrement ce blog doivent avoir une petite idée de mon avis sur cette appellation. Je vais essayer d’exposer mon point de vue de manière équilibrée et argumentée. Il s’agit donc ici d’un billet d’opinion.

Vous avez surement dû voir sur divers sites web l’appellation hyperviseur type 1 et hyperviseur type 2. Je ne connais pas l’origine des ces termes. Je soupçonne cependant fortement que ces deux termes soit d’origine marketing.

Note : Cet article a été publié sur le blog Orange Business Service Virtualisation le 3 Novembre 2009.

Qu’est ce qu’un hyperviseur ?

Tout d’abord, je vais m’attacher à exposer les différentes définitions de la notion d’hyperviseur. Wikipedia France nous donne la définition suivante.

En informatique, un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de travailler sur une machine physique en même temps.

Cette définition semble particulièrement large. Elle implique l’équivalence entre hyperviseur et application de virtualisation. Je définirais un « composant de virtualisation » en tant que n’importe quel composant applicatif permettant d’exécuter plusieurs systèmes d’exploitation sur une même machine physique. Il y a donc bien équivalence entre les deux définitions.

Qu’est ce qui définit techniquement un hyperviseur ?

Comme vous le savez, il existe de nombreuses techniques de virtualisation. Toutes ces techniques de virtualisation proposent une diversité assez large. Il me semble donc assez réducteur des les regrouper toutes sous le nom d’hyperviseur d’autant plus que l’appellation « composant de virtualisation » existe déjà.

La définition technique d’un hyperviseur est mieux illustrée à travers le fonctionnement de la paravirtualisation. Dans le cas de la paravirtualisation, l’hyperviseur est l’interface primaire et exclusive des ressources physiques principales. La notion d’hyperviseur se justifie par le fait que le noyau est historiquement le « superviseur ». Cette notion de « superviseur » est issue du mode « superviseur » des processeurs x86 car il s’agit du noyau qui va gérer les interruptions en mode superviseur. En toute logique, nous avons donc l’hyperviseur qui gère les superviseurs.

Dans le cas de la virtualisation de systèmes d’exploitation non modifiées, le « composant de virtualisation » se situe au dessus d’un système d’exploitation et donc d’un noyau. Nous avons donc une contradiction au niveau des appellations vu que l’hyperviseur va être géré par le « superviseur », à savoir, le noyau. Il y a donc une incohérence. Je vous remets, pour rappel, le schéma comparant paravirtualisation et virtualisation totale.

virtus

Quid des types d’hyperviseur

Afin de palier à cette contradiction, une différenciation a été faite et l’appellation « hyperviseur type 1 » et « hyperviseur type 2 » a vu le jour. Cette appellation ne répond cependant pas à la contradiction soulevée précédemment.

Pour rappel, un hyperviseur de « type 1 » est un hyperviseur s’exécutant directement sur la plateforme matérielle, comme dans le cas de la paravirtualisation. Un hyperviseur de « type 2 » est un hyperviseur s’exécutant par dessus un système d’exploitation invité.

Pour résumer cet article, je pense que l’appellation d’hyperviseur n’est pas adaptée aux solutions de virtualisation s’exécutant au dessus d’un système d’exploitation invité. Je pense que l’appellation « application de virtualisation » serait plus adaptée et correspondrait plus à la réalité. Je tiens également à soulever la question essentielle de cet article, peux-t’on considérer un couple système d’exploitation et application de virtualisation en tant qu’hyperviseur ? A partir de quel seuil un couple OS/application de virtualisation peut-il être considéré en tant qu’hyperviseur ?

Nouvelle classification des types de virtualisation

tech-presentation-2J’ai déjà eu l’occasion de proposer une classification des différents types de virtualisation lors d’un précédent article sur ce blog. Lors de ce précédent article, je m’étais attaché à classifier les solutions de virtualisation de systèmes d’exploitation. Je propose par le biais de cet article de re-préciser cette classification en y intégrant d’autres types de virtualisation et en reprenant en partie le précédent.

Tout d’abord, il sera essentiel de s’interroger sur ce que nous allons virtualiser car il est possible de virtualiser bon nombre de composants applicatifs. J’utiliserais le terme de composant applicatif pour désigner tout ce qui n’est pas matériel. Ce terme inclura donc les systèmes d’exploitation en globalité ou en partie aussi bien que les applications spécifiques. Ensuite, je proposerais un arbre de classification complété par rapport à la première version de cet article. Je rappellerais au passage les appellations correspondantes aux différents types de virtualisation.

Note : Cet article a été publié le 28 Octobre dans une version simplifiée sur le blog Virtualisation d’Orange Business ServiceS.

On virtualise quoi ?

Tout d’abord, il est essentiel de se poser la question « Que virtualise-t’on ? ». Il est possible de virtualiser beaucoup de choses de nos jours. Un début de liste comporterait des routeurs, des switchs, des applications, des systèmes d’exploitation, de l’espace disque et ainsi de suite.

Nous allons distinguer trois familles de virtualisation : réseaux, systèmes d’exploitation et processus. Ces trois types constitueront le premier étage de notre arbre de classification.

On virtualise comment ?

Nous avons donc effectué une première discrimination basée sur le composant applicatif que nous allons virtualiser afin d’établir le premier étage de notre arbre de classification. Nous allons ensuite établir le second étage de cet arbre.

Nous allons ensuite associer à chaque composant applicatif les différents types de virtualisation correspondants. En ce qui concerne les systèmes d’exploitation, nous ajouterons une distinction importante qui est la modification ou non du système d’exploitation invité. Un système d’exploitation invité est un système d’exploitation qui s’exécute par dessus une couche de virtualisation spécifique.

Voici donc l’arbre de classification que je propose :

schema_classification_small

Le premier type de virtualisation présent dans cet arbre est la virtualisation d’équipements réseaux. Il aurait été possible d’inclure la virtualisation de réseaux. Ceci a été exclu de cette classification car il ne s’agit que d’un mécanisme de commutation spécifique. Ce type de virtualisation permet de créer des environnements réseaux spécifiques et cloisonnés de bout en bout. Les solutions existantes dans ce domaine sont les produits Nexus de Cisco et le futur switch virtuel de Citrix.

Dans la catégorie des systèmes d’exploitation, nous avons choisi de distinguer les systèmes d’exploitation modifiées et non modifiées. Les modifications en question sont les modifications du noyau nécessaire à l’exécution du système d’exploitation par dessus une couche de virtualisation spécifique.

La virtualisation de système d’exploitation modifiés est la paravirtualisation. Ce terme a tendance à être utilisé de nombreuses manières différentes. La paravirtualisation est la virtualisation de systèmes d’exploitation dont le noyau a été modifié pour communiquer avec la couche de virtualisation au lieu de communiquer avec le matériel physique. Pour résumer, la système d’exploitation va avoir conscience d’être virtualisé et sera adapté à cet effet. L’ajout de simple drivers spécifique n’implique pas forcément paravirtualisation. Les solutions existantes dans ce domaine sont les produits XenServer de Citrix, xVM de Sun, XenSource voire Hyper-V de Microsoft. VMWare commence à se lancer dans cette technologie prudemment. Si vous souhaitez en savoir plus sur la paravirtualisation, je vous laisse consulter l’article sur la paravirtualisation.

En ce qui concerne les systèmes d’exploitation non-modifiés, nous distinguerons deux types de virtualisation : la virtualisation totale et la virtualisation matériel assistée. La virtualisation totale est la virtualisation « primitive » qui consiste à émuler le matériel physique ainsi que son comportement. Il s’agit de l’approche la plus couteuse mais la plus simple à mettre en oeuvre. La virtualisation matériel assisté est une extension du principe de virtualisation totale. Cette extension se matérialise par l’utilisation des extensions processeur spécifiques à la virtualisation (AMD-V et Intel-VT). Ces extensions permettent d’accélérer la virtualisation par différents mécanismes. Les solutions utilisant cette technologie sont VMWare, Virtualbox de Sun, Virtual PC de Microsoft, QEMU et bien d’autres.

Au niveau de la virtualisation de processus, nous retrouvons deux types de virtualisation : la virtualisation au niveau du système d’exploitation et la virtualisation d’application. La virtualisation au niveau du système d’exploitation consiste à faire croire à plusieurs jeux de processus qu’ils s’exécutent dans différents systèmes d’exploitation alors que ce n’est pas le cas. Les solutions utilisant cette technique sont les zones Solaris, les chroot Linux, les jails BSD, OpenVZ et bien d’autres. La virtualisation d’application consiste à livrer des applications non installées sur un poste par un serveur. Les solutions utilisant cette technique sont XenApp de Citrix ou VMWare Thinapp.

Au final, je pense que cette classification est plus complète que la précédente que j’avais eu l’occasion de présenter. Elle inclut notamment la virtualisation d’application et la virtualisation d’équipements réseaux. Cette classification reste une proposition et il est tout à fait possible de proposer une classification sous un autre angle.

La configuration réseau de Xen

J’ai déjà eu l’occasion d’évoquer la spécificité de la configuration réseau dans le cadre d’une plateforme de virtualisation dans un précédent billet. Je vais traiter ici des différentes configuration réseau possible avec Xen. Bien que cet article s’attachera aux modes présents dans Xen, vous pourrez sans aucun doute retrouver dans d’autres solutions de virtualisation. Si vous souhaitez un rappel de la terminologie Xen qui sera utilisé ici, je vous invite à relire l’article sur la terminologie.

Les trois modes de configuration réseau dans Xen sont : bridge, route et NAT. En Français, nous aurons donc pont, routage et NAT. Ces trois modes répondent à différents besoins en terme de configuration réseau. Le premier critère de choix du mode réseau est la topologie logique du réseau existant. Les éléments de topologie vont inclure les VLAN ainsi que les différents réseaux IP.

Le mode pont

RzoXen-Bridge

Le schéma ci-dessus explique le fonctionnement du mode pont. Il s’agit du mode le plus simple agissant au niveau le plus bas. Les domU sont connectés au dom0 via des interfaces réseau virtuels. Le dom0 ne fait qu’une simple commutation en redirigeant les trames soit vers le bon domaine soit vers le reste du réseau.

L’avantage de ce mode est l’extrême simplicité de la configuration qui permet une transparence par rapport au reste de l’architecture. La configuration des domU est également simple et ne nécessite aucune particularité. Il est possible de superposer n’importe quelle configuration IP en utilisant ce mode. Vous remarquerez que ce mode ne prend pas en compte les VLAN nativement. Nous verrons ultérieurement une possibilité de fonctionnement de ce mode avec la prise en compte des VLAN via 802.1Q.

Le mode routage

RzoXen-Route

Le schéma ci-dessus explique le fonctionnement du mode routage. Il s’agit d’un mode assez peu utilisé. La raison de la faible utilisation de ce mode est lié au fort lien entre topologie physique et topologique logique. Je m’explique. Avec cette configuration, il est pratiquement impossible de migrer des machines virtuelles entre des machines physiques sans modification de routage.

Ce mode est cependant très utile dans le cadre d’un serveur OVH doté d’IP supplémentaires. Ceci est du au fait qu’une bonne partie des serveurs OVH ne supportent pas le mode pont pour un raison inconnue.

Le mode NAT

RzoXen-NAT

Le mode NAT est une évolution du mode routage. Vous avez toujours deux plages d’IP différentes de part et d’autre du dom0 mais les IP des domU ne seront pas visibles sur le réseau public.

Par défaut, ce mode permet un accès au réseau public par les domU mais pas d’accès dans le sens inverse. Vous pourrez mettre en place des accès dans le sens inverse en utilisant iptables.

La paravirtualisation

tech-presentation-2Je vais continuer et finir la série d’articles présentant les différents types de virtualisation. J’ai déjà eu l’occasion de proposer une classification des différents types de virtualisation et de parler de la virtualisation totale ainsi que de la virtualisation matérielle assistée. Je vais continuer en vous parlant de paravirtualisation. J’ai déjà eu l’occasion d’évoquer la notion de paravirtualisation dans la présentation de Xen que j’avais faite il y a quelques temps.

L’idée de base des précédents types de virtualisation était de faire croire au système d’exploitation qu’il s’exécutait sur une machine physique alors que ce n’était pas le cas. Cette technique est la technique la plus évidente lorsqu’on essaye de virtualiser des systèmes d’exploitation principalement propriétaires ce qui est le cas de VMWare par exemple. Il s’agit d’une méthode qui permet de centraliser toutes les fonctionnalités de virtualisation dans un seul endroit, à savoir la couche de virtualisation. L’inconvénient de cette méthode est que la couche de virtualisation devient rapidement très lourde avec la quantité croissante du nombre de fonctionnalités à implémenter.

La paravirtualisation adopte une vision radicalement différente. Au lieu de chercher à faire croire aux systèmes d’exploitation qu’ils s’exécutent sur une machine physique, il est possible d’adapter le système d’exploitation à la couche de virtualisation. Ceci n’aurait bien évidemment pas été possible sans la présence de logiciels libres…

virtus

La paravirtualisation vise donc à modifier les systèmes d’exploitation pour communiquer avec un hyperviseur au lieu de communiquer avec une machine physique. Sur ce blog, je parlerais d’hyperviseur au sens de Xen ou d’Hyper-V. VMWare parle d’hyperviseur à tord et à travers mais il ne s’agit pas, selon moi, d’un vrai hyperviseur. En réalité, il s’agit d’un système d’exploitation hôte déguisé.

L’hyperviseur au sens de la paravirtualisation est en contact direct avec le matériel physique. Il est l’intermédiaire exclusif entre le matériel et les systèmes d’exploitation. Lorsqu’on se trouve donc dans un système de paravirtualisation, il n’y a plus de notion de système d’exploitation invité et de système d’exploitation hôte. Tous les systèmes d’exploitation sont virtualisés dans le sens où ils disposent d’un noyau adaptés à la couche de virtualisation. Tous les systèmes d’exploitation ne seront pas égaux pour autant, il est possible de donner des accès spécifiques à différents systèmes d’exploitation.

Les systèmes d’exploitation communiquent avec l’hyperviseur via des API de communication. Ces API de communication remplacent les traditionnels appels systèmes. Chaque couche de virtualisation dispose donc de sa propre API. Pour adapter un système d’exploitation à un hyperviseur, il faut donc intégrer son API au noyau. Cela explique en partie le passage en GPL des pilotes Hyper-V de Microsoft.

Au final, la paravirtualisation est une technique particulièrement innovante qui présente une approche plus efficace de la virtualisation. Les avantages de cette technique sont une perte de performance largement réduite par rapport à une virtualisation totale. L’inconvénient majeur est qu’il est nécessaire d’adapter les systèmes d’exploitation pour chaque couche de virtualisation. Afin de résoudre ce problème, il est possible de coupler paravirtualisation et virtualisation matérielle assistée comme dans Xen.

La virtualisation matériel assistée

tech-presentation-2Je vais continuer dans la suite logique des billets précédents. Pour rappel, j’ai précédemment parlé de l’intérêt de la virtualisation, proposé une classification des différents types de virtualisation et puis expliqué plus en détail la virtualisation totale. Je vais donc continuer cette série d’article en vous parlant de virtualisation matériel assistée.

Tout d’abord, le terme de virtualisation matériel assistée semble assez explicite. On comprend bien qu’il s’agit de virtualisation qui va être assistée par une fonctionnalité spécifique du matériel. Les détails du fonctionnement de cette technologie le sont cependant bien moins. Ce terme est une traduction de l’anglais « Hardware Assisted Virtualization ». On peut aussi trouver comme autre traduction « virtualisation assistée par matériel ». Tous ces termes sont cependant équivalents. Cependant, la virtualisation partielle n’a aucun rapport.

HAV

Comme vous pouvez le voir, le schéma d’architecture ne change que très peu par rapport à la virtualisation totale. Avec la virtualisation totale, nous parlions de couche logicielle de virtualisation alors que parlerons plutôt de « Virtual Machine Monitor » ou VMM dans le cas de la virtualisation matériel assistée.

Une extension du jeu d’instructions du processeur

Ensuite, il est important de préciser que la virtualisation matériel assistée n’est pas une technique à part entière. Il s’agit en réalité d’une extension du principe de virtualisation totale. La principale modification qui est apportée est l’ajout d’extensions processeur de virtualisation. Vous en avez surement entendu parlé, je parle bien d’Intel VT et d’AMD-V. Ces instructions ont été implémentées dans les processeurs afin de pouvoir améliorer la virtualisation totale. Ces instructions sont une extension du jeu d’instructions exécutables par le processeur similairement à SSE ou MMX.

Ces instructions apportent plusieurs améliorations. Tout d’abord, elles créent un anneau -1 qui sera l’endroit privilégié de l’exécution d’un hyperviseur. Ceci permet de garder la localisation traditionnelle des anneaux avec le système d’exploitation présent dans l’anneau 0 et les applications dans l’anneau 3. Les autres ne sont jamais utilisé à l’exception de quelques rares cas. J’aurais l’occasion de revenir plus tard sur la notion d’anneau. Le placement du système d’exploitation dans son anneau traditionnel permet de simplifier l’accès à certains instructions et donc de supprimer une partie du travail de la couche de virtualisation.

De plus, elles permettent aux machines virtuelles de gérer leurs propres interruptions et donc changements de contexte. Ceci évite à la couche logicielle de virtualisation de devoir les gérer. Egalement, elles permettent au matériel de gérer directement  les zones de mémoire vive (non forcément linéaires) disponibles au machines virtuelles. Sans les extensions, il était nécessaire que la couche de virtualisation émule et gère des zones.

Si vous souhaitez plus d’informations sur ces instructions, je vous invite à consulter la documentation d’Intel disponible ici ou ici.

Au final, les extensions processeur de virtualisation permettent d’améliorer la technique de la virtualisation totale. Ceci se fait par l’ajout d’un degré d’intelligence au niveau du matériel qui sera conscient de l’utilisation d’une couche de virtualisation. La virtualisation matériel assistée est donc une évolution du principe de virtualisation totale.