Les fondamentaux du cloud computing

La virtualisation expliquée

Comment un hyperviseur divise un serveur physique en plusieurs machines virtuelles isolées, la différence entre les hyperviseurs de Type 1 et de Type 2, et pourquoi la virtualisation seule ne suffit pas à faire d'un système un cloud.

Intermédiaire 15 minutes 4 Objectifs d'apprentissage
  1. Expliquer comment un hyperviseur permet à un serveur physique d'exécuter plusieurs machines virtuelles indépendantes
  2. Distinguer les hyperviseurs de Type 1 (bare metal) des hyperviseurs de Type 2 (hébergés)
  3. Relier la virtualisation à la caractéristique de mutualisation des ressources du cloud
  4. Reconnaître pourquoi la virtualisation seule ne suffit pas à faire d'un système un cloud

Une boîte, plusieurs ordinateurs

Entrez dans le centre de données d'un fournisseur cloud et vous trouverez des rangées de serveurs physiques, mais le nombre de machines physiques est très loin du nombre de clients qui les utilisent. Un seul serveur physique peut héberger des dizaines de machines virtuelles totalement séparées en même temps, chacune exécutant son propre système d'exploitation, chacune convaincue de posséder l'ordinateur entier, chacune invisible pour les autres. Cette prouesse, une seule machine physique qui semble être plusieurs machines indépendantes, c'est la virtualisation, et c'est la technologie qui rend physiquement possible le réservoir de ressources partagé du cloud.

L'hyperviseur : le logiciel qui divise un ordinateur

Le logiciel qui rend cela possible s'appelle un hyperviseur. Un hyperviseur se place entre le matériel physique, CPU, mémoire, stockage, réseau, et les machines virtuelles (VM) qui s'exécutent au-dessus, et son rôle est de diviser ce matériel puis d'attribuer à chaque VM sa propre part, quelques cycles CPU, de la RAM, de l'espace disque, selon un calendrier que l'hyperviseur contrôle.

Depuis l'intérieur d'une VM, tout semble normal. Le système d'exploitation invité démarre, voit ce qui ressemble à de la mémoire réelle et à un disque réel, et exécute des applications exactement comme il le ferait sur du matériel physique. Il n'a aucun moyen de savoir que son "matériel" est en réalité une tranche d'une machine bien plus grande partagée avec plusieurs autres VM. Cette illusion, c'est tout l'objectif : l'isolation. Si une VM tombe en panne ou est compromise, les autres continuent de fonctionner sans être perturbées, parce que l'hyperviseur les garde séparées en permanence.

Deux façons d'exécuter un hyperviseur

Les hyperviseurs ne se placent pas tous au même endroit. Il en existe 2 types, et la différence compte selon l'endroit où chacun est utilisé.

Un hyperviseur de Type 1, aussi appelé bare metal, s'installe directement sur le matériel physique et prend la place d'un système d'exploitation traditionnel. Il communique directement avec le CPU et la mémoire, sans intermédiaire. Comme aucun système d'exploitation hôte ne se dispute les ressources, les hyperviseurs de Type 1 sont rapides et sont ceux qu'on retrouve dans les charges de travail de production des centres de données et des plateformes cloud. VMware vSphere, Microsoft Hyper-V et KVM en sont des exemples.

Un hyperviseur de Type 2, aussi appelé hébergé, s'installe comme une application ordinaire au-dessus d'un système d'exploitation classique, de la même façon qu'on installerait un navigateur web. Il doit demander du temps CPU et de la mémoire à ce système d'exploitation hôte plutôt que de communiquer directement avec le matériel, ce qui ajoute une couche de surcharge. Cette surcharge est un compromis raisonnable pour la simplicité : les hyperviseurs de Type 2 sont faciles à installer et à utiliser, ce qui explique pourquoi les développeurs les emploient pour tester des logiciels sur plusieurs systèmes d'exploitation depuis un seul ordinateur portable. VMware Workstation et Oracle VirtualBox en sont des exemples.

Type 1 (Bare Metal)Type 2 (Hébergé)
S'exécute surLe matériel physique directementUn système d'exploitation hôte
PerformancePlus élevée, aucune surcharge de système d'exploitation hôtePlus faible, partage les ressources avec l'hôte
Usage typiqueCentres de données, plateformes cloud, charges de productionOrdinateurs personnels, tests de développeurs, postes virtuels
ExemplesVMware vSphere, Microsoft Hyper-V, KVMVMware Workstation, Oracle VirtualBox

Pourquoi cela a rendu possible le réservoir de ressources du cloud

Revenez à la définition du NIST vue dans la leçon précédente : "un réservoir partagé de ressources informatiques configurables." La virtualisation est le mécanisme qui rend ce réservoir partageable en toute sécurité. Sans elle, un fournisseur devrait attribuer une machine physique dédiée à chaque client, exactement le modèle inefficace d'une machine par client que le cloud a remplacé. Avec elle, un fournisseur peut découper un serveur physique puissant en dizaines de VM, vendre chacune à un client différent, et récupérer puis réutiliser cette capacité dès qu'un client la libère. Le provisionnement rapide, créer une nouvelle VM en quelques minutes, et la mutualisation des ressources, plusieurs clients partageant du matériel en toute sécurité, remontent tous deux à ce seul logiciel.

La frontière : virtualisé n'est pas synonyme de cloud

Voici où il est facile d'aller trop loin. Une entreprise qui installe un hyperviseur de Type 1 sur ses propres serveurs et exécute 10 VM dans son propre centre de données a virtualisé son infrastructure, mais elle n'a pas nécessairement construit un cloud. Si un développeur doit encore déposer un ticket informatique et attendre 2 jours pour qu'une personne crée manuellement une nouvelle VM, cette configuration échoue sur les exigences de "libre-service à la demande" et de "provisionnement rapide" vues dans la leçon précédente, même si la technologie sous-jacente est identique à celle d'un fournisseur cloud.

La virtualisation est nécessaire au cloud computing à l'échelle qu'on connaît aujourd'hui, mais elle ne suffit pas à elle seule. Le cloud ajoute le provisionnement en libre-service, la mesure d'usage et l'élasticité par-dessus le matériel virtualisé. Vous reverrez exactement cette distinction une fois arrivé aux déploiements de cloud privé plus loin dans ce domaine, puisqu'un cloud privé, c'est précisément ce qu'on obtient quand une organisation ajoute ces pièces manquantes à sa propre infrastructure virtualisée.

Ce qui suit

Vous connaissez maintenant le mécanisme derrière le réservoir partagé : un hyperviseur qui découpe du matériel physique en machines virtuelles isolées. La prochaine leçon nomme les 5 traits précis et testables, libre-service à la demande, accès réseau étendu, mutualisation des ressources, élasticité rapide et service mesuré, qui séparent un système simplement virtualisé d'un véritable cloud.