Bernard Ourghanlian, directeur technique de Microsoft France
Les enjeux de la virtualisation (1ere Partie)

lundi 17 décembre 2007

20071217_07 Dans cet entretien consacré aux enjeux de la virtualisation, Bernard Ourghanlian, directeur technique de Microsoft France détaille les atouts de la plateforme de virtualisation de sa société. Cet entretien, divisé en trois parties, traite successivement des enjeux de la virtualisation et des atouts d'Hyper-V l'hyperviseur de Microsoft désormais disponible en version bêta, de ce que doit recouvrir un Datacenter dynamique et brosse enfin les grandes lignes du futur de Windows ; enfin affranchi grâce à la virtualisation des lourdeurs d'un héritage de deux décennies.

Ce premier volet traite des nouveaux scénarios rendus possibles grâce à la virtualisation ainsi que des caractéristiques d'Hyper-V, l'hyperviseur que Microsoft développe pour Windows Serveur 2008.

Propos recueillis par Hugo Lunardelli

La virtualisation est un sujet sur lequel Microsoft est perçu comme essayant combler son retard par rapport à d'autres éditeurs. Windows Server 2008 arrive dans peu de temps et apporte Windows Server Virtualization, récemment baptisé Hyper-V, dans ses bagages. Comment peut-on comparer cette nouvelle offre par rapport à l'offre VMware notamment ?

Bernard Ourghanlian : Je vais répondre à cette question mais je vais auparavant faire un détour. La virtualisation, même s'il ne s'agit pas d'une nouvelle technologie en soi, est probablement l'innovation majeure depuis les quinze dernières années en informatique. La virtualisation est apparue chez IBM avec VM qui doit en être au-delà de sa quarantième année d'existence. Ce qui me paraît aujourd'hui être l'élément le plus important c'est la conjonction de tout un tas de facteurs qui viennent apporter de nouvelles solutions. Ces facteurs comprennent notamment l'évolution du hardware qui fait qu'aujourd'hui la virtualisation devient accessible à tous. On assiste à la démocratisation de la virtualisation que l'on constate aujourd'hui du côté des serveurs, mais la vraie révolution à mon sens se fera au niveau des postes de travail.

En entreprise ou pour le particulier ?

B.O : Partout, pour un certain nombre de raisons sur lesquelles je vais revenir.

Quand on regarde l'évolution du hardware, on fait face un phénomène extrêmement important qui représente probablement le phénomène le plus capital depuis au moins quarante ans, depuis l'énonciation originelle de la loi de Moore. Ainsi, si cette loi n'est pas remise en cause, la perspective de voir la fréquence d'horloge des processeurs augmenter régulièrement n'est plus devant nous. On ne sait plus dissiper la quantité de chaleur créée à la surface des composants. On sait désormais que les prochaines perspectives d'évolution ne reposent plus sur l'augmentation indéfinie des Gigahertz. On restera très probablement dans les prochaines années autour des 3-4 Ghz et on devrait assister à des progrès dans le domaine des économies d'énergies.

On assiste aujourd'hui à l'apparition de processeurs multi-cœurs qui sont en train de se généraliser. On voit des stations de travail avec deux fois des quadri cœurs. Il est difficile aujourd'hui d'acheter un portable qui ne soit pas double cœur. Dans un avenir proche on aura des machines dotées de 32, voire de 64 cœurs de manière banale. Ce qui est intéressant dans ce contexte c'est que dans un premier temps cela représente un challenge absolument gigantesque parce que pour être capable d'utiliser « n » processeurs, il va falloir paralléliser les logiciels de telle façon que l'on puisse exécuter « n » threads en parallèle sur ces « n » cœurs et faire en sorte que le temps total d'exécution soit diminué. Le problème c'est que l'on ne sait pas écrire les logiciels en mode parallèle en dehors de cas particuliers comme certains logiciels scientifiques, par exemple dans les domaines du calcul de structures, ou de la dynamique des fluides. Le fait est qu'aujourd'hui on a très peu de capacité de traitement en parallèle pour des logiciels courants. On peut se poser la question de savoir comment paralléliser un logiciel comme Word. Il y a des voies d'amélioration, mais si on est raisonnable, on n'aura jamais un Word qui sera capable d'utiliser dix, vingt ou trente processeurs sauf à imaginer de changer fondamentalement l'interface entre l'homme et la machine et donc d'utiliser beaucoup plus la puissance de calcul pour être capable d'avoir de nouvelles façons de saisir des informations. Typiquement on peut penser à de la reconnaissance de la parole, à l'écriture manuscrite, à des agents intelligents, etc.

Toujours est-il que pour l'immense majorité des logiciels il y a très peu de logiciels qui sont parallèlisables en utilisant les méthodologies et les langages d'aujourd'hui. Pour ces logiciels, il y a peu de possibilités de bénéficier de cette capacité de calcul qui devient disponible. La raison essentielle tient vraisemblablement à ce que nos processus cognitifs ne sont pas adaptés à la réflexion en parallèle. On a donc du mal à écrire des logiciels parallélisés parce que ce n'est pas un mode de fonctionnement auquel on a l'habitude de faire appel. Il y a également de manière très claire un déficit d'environnements de programmation. On pourrait confier à la machine le soin d'écrire des programmes qu'on aurait préalablement modélisés, ce qui représente un des plus grands défis des prochaines années pour une société comme Microsoft, à savoir l'écriture d'outils de programmation, de langages qui vont permettre de travailler dans des environnements massivement parallèles. Si l'on est réaliste ce sont des problématiques que l'on ne sait pas correctement adresser, ni maintenant ni dans un avenir proche. Il faut donc repenser les outils de développement.

Le système d'exploitation aussi

B.O. : Bien sûr, même si le système d'exploitation est un des composants qui sait le mieux travailler en parallèle. Des progrès sont possibles, par exemple en exprimant mieux le parallélisme. Dans les langages classiques qui sont à notre disposition aujourd'hui, les C#, Java, C++ on ne dispose pas de dispositif intelligent permettant d'exprimer le parallélisme en dehors de la description de sections critiques. Il y a des progrès théoriques et technologiques en cours, comme une gestion transactionnelle de la mémoire (Software Transactional Memory) permettant à « n » threads d'accéder à une zone de données en mémoire tout en garantissant l'intégrité des transactions effectuées sur cette zone de données.

Venons en maintenant à la virtualisation. Avec la généralisation du hardware capable de gérer cette virtualisation et cette incapacité un peu pathétique que l'on a d'utiliser intelligemment tous ces cœurs on a une conjonction intéressante qui consiste à dire : et si on utilisait toute cette puissance de calcul pour faire ce que vraiment cherche à faire la virtualisation ?

On dit un peu tout et n'importe quoi à propos de la virtualisation. On vend la virtualisation en disant que cela va permettre de mieux utiliser les capacités de calcul et que plutôt que d'utiliser des machines à 20 % de leur charge nominale on va pouvoir les utiliser à 80 %. Certes, c'est un usage intéressant : c'est le paradigme de la consolidation de serveurs mais il s'agit d'une vision extraordinairement restrictive de tout ce que permet de faire la virtualisation. L'intérêt majeur de la virtualisation c'est de pouvoir, comme son nom l'indique, virtualiser; c'est-à-dire de pouvoir faire en sorte que, comme on introduit un niveau d'abstraction supplémentaire entre une vision physique des ressources et une vision logique de celles-ci, on puisse imaginer de pouvoir beaucoup plus qu'aujourd'hui isoler les couches logicielles qu'elles soient dans une présence horizontale ou dans une présence verticale sur la même machine.

Ce que cela signifie concrètement, c'est qu'aujourd'hui un des scénarios intéressants de la virtualisation c'est de pouvoir héberger plusieurs versions de la même application sur des machines virtuelles différentes dans une machine physique unique. On pourrait appeler ceci la virtualisation horizontale, plusieurs versions de la même application qui cohabitent sans interférer. C'est l'intérêt de la capacité d'isolation apporté par les machines virtuelles.

Il y a un autre intérêt, tout à fait fondamental également, qui fait que je deviens capable grâce à la virtualisation de faire en sorte que finalement les dépendances par rapport à mon système d'exploitation, les dépendances par rapport à mon middleware en tant que couche intermédiaire deviennent des dépendances qui sont isolées pour moi.

Pour prendre un scénario qui pour le moment est encore de l'ordre de la vision mais qui est un scénario sur lequel Microsoft travaille, on peut imaginer la chose suivante : je suis sur un poste de travail ou un serveur, chaque application est accompagnée d'un manifeste qui est en fait l'équivalent du manifeste que l'on trouve dans l'environnement .NET (aujourd'hui un fichier XML qui va décrire les dépendances ou les présupposés de mon application par rapport au monde qui l'entoure). Imaginons que je suis sur une prochaine version majeure de Windows, Windows 7 ou Windows 8 et que je cherche à activer une application. De deux choses l'une, soit les dépendances que j'ai exprimées dans ce manifeste sont entièrement disponibles dans Windows 7 ou 8 et j'active mon application comme si de rien n'était. Soit ce n'est pas le cas et j'ai donc la nécessité de faire appel à un certain nombre de fonctionnalités anciennes d'un système d'exploitation qui ne sont plus présentes dans Windows 7 ou 8, alors je vais pouvoir dynamiquement et de façon totalement transparente pour l'utilisateur instancier soit une virtualisation applicative (je reviendrai sur cette notion), soit une machine virtuelle telle que l'on la connaît dans un environnement VMware ou Virtual PC pour faire en sorte d'apporter à mon application ce dont elle besoin pour pouvoir fonctionner. Quand je suis dans un environnement tel que celui là je ne suis plus dépendant des versions de système d'exploitation et du middleware associé. Je vais dynamiquement instancier ce dont j'ai besoin pour pouvoir faire fonctionner mon application. Ce qui veut dire en fait que j'utilise la puissance CPU à ma disposition pour utiliser toutes ces machines physiques qui sont présentes sur ces processeurs multi-cœurs pour être capable dynamiquement de créer l'environnement dont mon application a besoin.

Ce qui veut dire que si je suis DSI, responsable d'une ligne applicative métier dans mon entreprise, je ne vais plus avoir besoin de me préoccuper des vicissitudes de l'infrastructure, je vais pouvoir faire évoluer mon application à mon rythme en fonction de ce que j'ai choisi de faire. Si mon application est « en mode maintenance » où plus rien n'évolue, je peux prendre la décision de faire vivre cette application pendant dix ans, sans pour autant solidifier, geler le système d'information qui se trouve en dessous. Je peux donc avoir sur la même machine, qu'elle soit serveur ou qu'elle soit poste de travail plusieurs versions, plusieurs philosophies d'évolution du système d'information qui cohabitent. Je ne suis plus obligé, comme c'est aujourd'hui le cas, si je prends la décision de migrer vers Windows Vista de m'assurer de la compatibilité de toutes mes applications avec le nouveau système. Cela implique aujourd'hui, soit de faire évoluer mes applications, soit de racheter une nouvelle version chez mon fournisseur même si je n'en ai fonctionnellement pas besoin. J'ai transformé une problématique de migration de système d'exploitation vers quelque chose de plus important qui est la question de la gestion du cycle de vie de tout le patrimoine applicatif. L'idée c'est de permettre sur le même environnement de faire cohabiter des versions différentes du système d'information, des vitesses différentes d'évolution du système d'information, de faire en sorte que si je prends la décision de faire évoluer très vite une application et de pouvoir tenir compte des évolutions soit du middleware, soit des OS , je vais pouvoir faire évoluer ces composantes sur la plateforme de base mais je n'aurai pas l'obligation que cela affecte toutes mes applications. Pour moi la vraie promesse de la virtualisation, au-delà de la consolidation de serveurs et au-delà des plans de reprise d'activité, est autour de l'amélioration de l'agilité du système d'information parce que l'on va éliminer les dépendances entre toutes les briques de base constitutives de ce système.

Ce qui est très intéressant et c'est la raison pour laquelle je pense que la vraie révolution de la virtualisation se manifestera surtout au niveau du poste de travail c'est qu'on se rend compte qu'un des gros problèmes de la plupart de nos clients c'est qu'à chaque fois qu'ils ont à migrer ou à changer une version majeure du système d'exploitation, pour prendre le cas de Vista, ils sont confrontés avant tout au problème de la compatibilité applicative. Si on prend l'exemple de quelques uns de nos clients qui ont un patrimoine de quelques 4 000 applications sur le poste de travail, rien qu'une seule journée passée pour tester les éventuelles régressions apportées par le nouvel système d'exploitation, ça représente 4 000 jours hommes, un investissement énorme. Quand un client à 4 000 applications et qu'il veut en faire évoluer deux, il est obligé de faire évoluer les 3 998 autres au même rythme que les deux autres. Il s'agit évidemment d'un cas extrême. Le gros intérêt de la virtualisation c'est de pouvoir s'affranchir des dépendances entre les applications, les couches middleware et le système d'exploitation et donc de permettre finalement au système d'information d'évoluer à son rythme à chaque fois que cela fait du sens.

Dans cette perspective, la consolidation de serveurs représente un scénario de peu d'ambition par rapport à ce que l'on va pouvoir réaliser dans le futur. Même si la consolidation de serveurs est bien évidemment un sujet important, ne serait-ce que dans une perspective de préservation de l'énergie. De même que l'utilisation de la virtualisation pour construire des plans de reprise d'activité, scénarios encore trop peu utilisés en environnement virtualisé.

Revenons maintenant à la comparaison de VMware par rapport à Windows Server Virtualization ou Hyper-V. Une des choses intéressantes dans Hyper-V sur laquelle on n'a probablement pas communiqué suffisamment, c'est que l'architecture de virtualisation est assez originale. Cette architecture est d'ailleurs partagée de façon assez significative avec celle de Xen, ce qui n'a rien d'étonnant puisque Xen a été pour une large part développé en collaboration avec Microsoft Research à Cambridge. C'est quelque chose que l'on ne sait pas mais il y a eu pas mal de contributeurs de MS Research sur le projet Xen.

C'est une architecture fondée sur un concept que l'on appelle généralement la paravirtualisation, à ceci près qu'Hyper-V ne nécessite pas un nouveau noyau pour les machines virtualisées. Ce qui signifie que l'on va architecturer le moyen de faire en sorte que, contrairement à tous les systèmes de machines virtuelles qui existent sur le marché, on puisse admettre qu'il y ait des échanges entre les machines virtuelles. On parle beaucoup de la virtualisation utilisée pour permettre l'isolation entre deux machines virtuelles. Je démarre Windows Server 2003, je lance Virtual Server qui me permet d'instancier une architecture x86 sur laquelle je vais démarrer la machine virtuelle que je cherche à héberger. Il s'agit d'une architecture classique qui ne repose pas sur un hyperviseur, ce qui en soi est un peu obsolète. Hyper-V est fondé sur une technologie de type hyperviseur mais va également reposer sur cette idée de paravirtualisation. Pourquoi est-ce important ? Un hyperviseur en tant que tel c'est une couche logicielle très fine qui va s'exécuter directement sur le hardware et dont l'objectif essentiel est de permettre de multiplexer les ressources entre ressources physiques (les CPU, la mémoire, les IO) et les ressources logiques, soit les différentes machines virtuelles que je vais héberger au dessus de mon hyperviseur. L'hyperviseur instancie l'architecture x86 et au dessus j'instancie « n » machines virtuelles. La différence dans l'architecture d'Hyper-V c'est que au lieu de faire simplement cela, on va, en fait, au dessus de l'hyperviseur, instancier une machine virtuelle un peu particulière que l'on va appeler machine virtuelle parente qui sera unique qui va exécuter un noyau minimal de Windows Serveur 2008 (la version « cœur » de Windows Server 20028 et une version encore plus « fine » avec Windows Server 7 qui s'appelle MinWin) et qui va autoriser l'exécution en parallèle de « n » autres machines virtuelles, appelées machines virtuelles filles et qui pourront être des machines de deux types. Soit des machines virtuelles « standard », soit des machines virtuelles paravirtualisées. Dans le cas d'Hyper-V, nous utilisons une approche que l'on pourrait appeler micro-hyperviseur puisque cette couche logicielle est de très petite taille (moins de 1 MO) contrairement à l'approche de VMware dont l'hyperviseur ESX représente aujourd'hui plus de 30 MO.

L'intérêt d'avoir des machines virtuelles paravirtualisées c'est qu'elles vont autoriser la communication avec d'autres machines virtuelles et en particulier la machine virtuelle parente. L'idée c'est que l'on a tout en bas l'hyperviseur, au dessus une machine virtuelle parente et toute une série de machines virtuelles filles. L'objectif de la communication entre les machines virtuelles filles et parente c'est que la machine virtuelle parente va permettre de résoudre un des problèmes majeurs que connaissent aujourd'hui tous les environnements de virtualisation qui est la pauvreté pathétique en support des entrées sorties. Je veux dire simplement qu'aujourd'hui toutes les entrées sorties se font vers des périphériques émulés. On va ainsi avoir une interface Ethernet, SCSI ou USB mais on ne va pas avoir accès à toute la richesse des périphériques qui est disponible dans l'environnement Windows. L'objectif recherché à travers cette paravirtualisation c'est de faire en sorte qu'à partir du moment où une machine est paravirtualisée, au moyen de l'installation d'une petite couche logicielle (appelée « enlightenment ») sur chacune de ces machines virtuelles, elles vont pouvoir discuter à travers un bus logiciel avec la machine virtuelle parente qui elle va offrir la richesse représentée par les dizaines de milliers de périphériques supportés en standard dans l'environnement Windows. Ca veut dire que l'on peut virtualiser l'interface vers un scanner, une imprimante, ...

Cette capacité n'est offerte aujourd'hui par aucune machine virtuelle. Elle est très intéressante au niveau d'un serveur car elle va permettre un accès natif et direct aux drivers d'un SAN, d'un NAS ou à tous les drivers que l'on peut trouver sur un serveur. Dans une perspective d'utilisation sur un poste de travail, l'importance est encore plus grande. J'ai besoin d'avoir le vrai driver NVIDIA ou ATI, le vrai driver USB ou du scanner, ...

Depuis une machine virtuelle fille, on va pouvoir émettre à travers ce bus logiciel une entrée sortie qui va être redirigée vers le vrai périphérique physique qui va communiquer avec le vrai driver supporté dans Windows. Ça veut donc dire que contrairement au fait de disposer en tout et pour tout d'une dizaine de drivers supportés en mode émulé dans l'environnement, qu'il soit VMware ou Virtual Server aujourd‘hui, on va pouvoir bénéficier de l'accès natif et immédiat à toute la richesse des périphériques présents dans Windows. Cela va permettre de répondre au problème de la pauvreté des périphériques dans un environnement virtualisé. C'est donc un élément fondamental qui différencie Hyper-V de ce qui existe aujourd'hui sur le marché, en dehors de Xen qui partage les mêmes fondements.

Le deuxième élément qui va arriver dans un futur proche c'est l'arrivée au niveau de l'architecture Intel et AMD d'extensions permettant de supporter la virtualisation non plus à travers une assistance concernant essentiellement le CPU et la mémoire comme cela existe aujourd'hui, mais à travers des extensions complémentaires qui vont permettre de faciliter la virtualisation des entrées sorties (extension appelée VT-d chez Intel).

Cela concerne le deuxième point qui à mon sens constitue un point extrêmement faible des architectures de virtualisation et qui est la performance des entrées sorties. Cette absence de performances constitue un frein puisqu'aujourd'hui on travaille uniquement au travers de l'émulation de périphériques et donc on n'a aucune assistance apportée par le hardware et on est obligé de tout faire par le logiciel. L'arrivée de ces extensions va permettre de faire ce que l'on appelle du DMA remapping qui consiste à dire que si je suis dans une machine virtuelle fille et que je cherche à faire une entrée sortie qui va de toute façon devoir être redirigée vers la machine virtuelle parente (c'est elle qui va effectivement avoir accès au périphérique), ce que l'on va faire c'est de lancer mon entrée-sortie dans ma machine virtuelle fille, ce qui revient à envoyer un message à ma machine virtuelle parente pour lui dire se préparer et en même temps je vais avoir une assistance hardware qui va me permettre d'indiquer la fenêtre vers laquelle je veux réaliser mon entrée-sortie dans ma machine virtuelle fille. Je vais la remapper (d'où le nom de DMA remapping) pour correspondre directement à la zone de mémoire physique vers laquelle est mappée le périphérique. Cela veut donc dire que depuis ma machine virtuelle fille, je vais avoir la possibilité de faire l'entrée sortie directement dans la zone mémoire physique qui m'intéresse. Je ne vais pas être obligé comme je le fais aujourd'hui de recopier des buffers entre ma machine virtuelle, la zone système dans laquelle je vais faire mon entrée sortie et ensuite le périphérique. Je vais pouvoir le faire directement sans passer par un quelconque échange. Je vais donc faire mon entrée-sortie dans ma machine virtuelle exactement comme je le ferais dans une machine physique, en dehors de la préparation de l'entrée-sortie à travers ce mécanisme de bus logiciel qui représente un coût extrêmement faible de quelques microsecondes.

Ce qui est très intéressant par rapport à ces extensions qui arrivent dans les chipsets d'Intel et d'AMD, c'est que cela ne concerne pas seulement le CPU mais le chipset que l'on trouve dans la carte mère. La conséquence c'est que cela va permettre d'avoir enfin de bonnes performances d'entrées sorties dans les environnements virtualisés. Aujourd'hui si on cherche à virtualiser un environnement base de données ou messagerie, on est en général assez déçu des performances parce que ces environnements sont très gourmands en entrées-sorties et que cela coûte énormément de puissance CPU que d'émuler ces entrées sorties dans les environnements de virtualisation actuels.

L'arrivée de ces chipsets va permettre d'avoir enfin des entrées sorties performantes dans un contexte de virtualisation. C'est là que toute la puissance de l'architecture d'Hyper-V arrive. On a à la fois le couplage d'un dispositif de virtualisation qui sait s'appuyer sur tous les drivers qui existent dans l'environnement Windows et, qui plus est, on peut enfin les utiliser intelligemment. C'est là ou l'on arrive à voir une approche de la virtualisation qui va permettre de répondre à la plupart des obstacles actuels qui sont les problématiques d'entrées sorties, à la fois parce que la richesse de périphériques virtualisés supportés est extrêmement limitée et d'autre part parce que, de toute façon, on a des performances qui ne sont pas au niveau où on les attendrait.

Voilà les différences qui correspondent à la fois aux évolutions du logiciel et en même temps à l'évolution du hardware. Ces chipsets en question seront disponibles avant la fin de cette année et ils vont être présents dès le début de l'année prochaine dans les premières machines chez les principaux fournisseurs de serveurs dans un premier temps et de PC par la suite.

_____________
_{Hugo Lunardelli est titulaire d'un DEA en économie ainsi que d'un Mastère en Management des Technologies de l'Information. Passionné par les nouvelles technologies, il a occupé différentes fonctions marketing au sein de Microsoft France et de Microsoft Europe avant de démarrer une activité de consultant et journaliste.}