Des VMs comme des poupées russes

 

Certains d'entre vous connaissent peut être le test de pureté du langage perl : êtes vous un geek perl et à quel point ? La partie de ce test qui m'a le plus interpelée concerne la fonction « eval » de perl qui permet d'évaluer à la volée du code perl qui n'est pas analysé à la compilation du code. Ce test pose la question : Avez-vous écrit des evals qui modifient leur propre contenu? Pas souvent mais oui ! Puis : Avez-vous imbriqué un eval dans un eval ? Je dois reconnaître que oui très rarement. Et enfin : Avez-vous imbriqué plus de cinq evals ? Alors là je me suis dit : zut, je n'y avais même pas pensé ! Pourquoi faire des eval récursifs ? En fait je ne le sais toujours pas. Mais lorsque que je pense à d'autres domaines, je me demande parfois s'il n'y aurait pas un intérêt pour mettre cet objet dans ce même objet, dans ce même objet et ainsi de suite un peu comme les poupées russes. C'est avec les machines virtuelles que ce concept m'est apparu viable et même intéressant...
 
En effet avec la virtualisation de socle (hyperviseur de type ESX, Hyper-V, Xen-Server...) ou d'application (ThinApp, App-V, Jail...) nous mettons déjà des machines virtuelles (VMs) dans des machines physiques ou des bulles applicatives dans des bulles systèmes. Aujourd'hui nous n'en sommes encore qu'à un seul niveau d'imbrication (version officielle et supportée des logiciels). C'est-à-dire que nous mettons des VMs dans des Hyperviseurs, mais pas des VMs dans des VMs et encore moins des VMs dans des VMs dans des VMs.
 
 
 
Néanmoins, on peut bien voir que ça et là émergent des structures à deux niveaux comme dans le cas de faire tourner des VMs dans un ESX lui même dans une VM Workstation. Pourquoi seulement deux niveaux ? Pour plusieurs raisons mais surtout parce que les fonctionnalités de gestion d'accès multiples au processeur (intel VT ou AMD-V) ne sont plus disponibles après la première couche d'hyperviseur. En effet, c'est toujours le choix d'un gestionnaire unique qui fonctionne le mieux aujourd'hui en ce qui concerne les ressources processeur et mémoire. On ne peut pas gouverner à deux. Les mécanismes « distribués » sont encore très complexes et donc très couteux. Les hyperviseurs paravirtualisés peuvent plus facilement permettre d'envisager des structures à plus de deux niveaux d'inclusion car personne n'est entre l'OS et le processeur. Les drivers sont encore un frein important à la virtualisation de machines virtuelles. Mais de nouveaux types de drivers arrivent qui ne fonctionnent plus directement avec le matériel (mode superviseur) mais interagissent avec le noyau via des APIs standardisées (mode utilisateur), un peu comme le font les matériels avec le bus USB.
En fait on le voit très clairement dans l'évolution des architectures de virtualisation. D'abord les VMs sur un serveur physique. Puis des VMs sur des serveurs physiques qui sont confinées dans un « enveloppe » de capacité (Resource Pool pour VMware) et qui peuvent se déplacer d'une machine physique à une autre (vMotion, Live Migration). Puis comme c'est le cas avec des produits comme LabManager, des ensembles de VMs qui se meuvent sur des serveurs physiques avec leur stockage, leur réseau, leurs ACL, leurs règles firewall au sein d'un même Datacenter. Et maintenant plus récemment, ces ensembles de ressources virtuelles qui peuvent se déplacer sur d'autres lieux géographiques ou d'autres providers dans le monde entier grâce au Cloud Computing. 

Nous savons combien la gestion des univers physiques est beaucoup plus contraignante que celle des univers virtuels. On a vu apparaître depuis déjà quatre ans le concept d'Appliance Virtuelle. Aujourd'hui directement intégré dans la dernière version de vCenter, elle facilite énormément la mise à disposition d'environnement « prêt à l'emploi ». Avec LabManager il est possible d'aller encore plus loin et d'exporter des ensembles de VMs d'un seul coup. Si le virtuel est si rapide à déployer et si on peut même en faire du « prêt à l'emploi », alors l'étape suivante sera de faire des Systèmes d'Informations complets « prêt à l'emploi » avec leurs réseaux prédécoupés et configurés, leur stockage et leur qualité de service dimensionnés, leurs applications métiers déployées: annuaire, serveurs de fichier, serveurs web, emails, firewall, monitoring, gestion du parc, gestion des incidents, relation client, comptabilité gestion et bien sur leurs postes clients. Des "tout en un" déjà pré-configurés prêt à l'emploi avec différents niveaux de gammes. Des "SI sur étagère". 
Bien sur on peut imaginer de poser tout cela directement sur les machines physiques d'une société. Mais aujourd'hui l'heure est à la centralisation et aux super-Datacenter. Et l'on voit bien l'intérêt de consolider tous ces environnements multi-VMs « prêt à l'emploi » dans d'autres VMs conteneurs lorsque l'on perçoit toute la puissance des clones-liés ou de ladéduplication. Ces SI complètement structurés et autonomes (cpu, ram, disque, réseau, drivers, sécurité) seraient disponibles en quelques minutes. 

Permettre de faire des VMs dans des VMs (avec une couche d'hyperviseur entre chaque) offre la possibilité la plus aboutie pour créer tous les univers possibles d'architecture et de méta-organisation. Chacune des ressources d'une VM pouvant être actuellement modifiée à chaud, cela voudrait dire que chacun des univers serait ajustable à souhait tout en conservant les intérêts de la mutualisation des  ressources et de leur étanchéité vis-à-vis des ressources physiques ou des autres univers virtuels. De plus le standard OVF est suffisamment riche pour rendre cette structure compatible avec tous les fournisseurs de ressources. Il ne manque donc plus grand-chose au niveau de la gestion du matériel pour que la VM devienne plus qu'un OS mais un conteneur universel.
Blogger Anonymous

-