Bon a priori il y a de la demande donc je vais prendre un exemple pour illustrer mon propos et qui reprend la problematique de maniere generale. A nouveau je ne dis pas que ce que je vais decrire n'est pas possible avec une solution de type-II, mais je pense que la mise en oeuvre avec une solution de type-I est plus simple, plus flexible et plus generique (et ouvre la porte a d'autres capacites que je ne detaille pas ici).
Le contexte : on a donc une solution de type-I, quels sont les coups associes ? Tout le probleme vient du fait que les VMs ne peuvent pas executer d'instructions privilegiees au niveau materiel, les VMs doivent deleguees l'execution de ces instructions au VMM (hyperviseur) ou au domaine hote. Pour simplifier, le VMM prend en charge tout ce qui concerne la memoire et le domaine hote tout ce qui concerne les drivers pour le materiel (carte reseau par exemple).
Du coup, on a trois sources de surcout :
1/ lorsque le VMM execute quelque chose pour une VM, en gros des resolutions d'adresse memoire. Les derniers processeurs d'AMD apportent un debut de solution materielle pour ca avec leur mecanisme de "nested-page".
2/ lorsque le domaine hote execute quelque chose pour une VM, par exemple pour effectuer des comms. D.K. Panda et Fabrizio Petrini ont deja montre que l'on peut simplifier ca avec les technos reseau haute perf comme infiniband (cf. papiers dans ICS2006, Usenix2006, cluster2007) : l'initialisation de la comm se fait par le domaine hote qui "map" ensuite la memoire de la carte reso directement dans la VM. Du coup, lorsqu'une VM veut acceder au reseau, tout se fait de maniere quasiment directe (modulo quelques resolutions d'adresses memoire mais qui sont au final peu couteuses). Ca reprend l'idee d'OS bypass mis en oeuvre pour toutes les technos reseau moderne, mais dans le cadre de la virtualisation.
3/ les changements de contexte entre le VMM, les VM et le domaine hote. A nouveau des gens comme Ada Gavrilovska et Karsten Schwan de GATech ont montre qu'en placant chacun d'entre eux sur un core (notion de "sidecore") ont peu ameliorer grandement les choses; d'autant plus que dans un avenir proche, les cores ne vont pas manquer (manycores) et tous les experts tendent a s'accorder pour dire que certains pourront etre utilises par l'OS (au sens large ce qui inclus les VMM et les OS distribues).
Maintenant que le contexte est replace, prenons un exemple plus precis : le boot une machine physique virtualisee avec dans une VM un bout d'application MPI qui utilise un reseau de type infiniband. Dans cas, il se passe les choses suivantes (attention je simplifie un peu les choses pour ne pas entrer dans les details) :
- Le bootloader est charge en memoire, trouve l'adresse du VMM et le charge en memoire. Celui-ci initialise la memoire et le(s) processeur(s) et cores.
- Le VMM, une fois initialiser trouve l'adresse du domaine hote (passer en parametre au bootloader); le domaine hote boot comme un charme, il peut executer des instructions privilegiees. Il en profite aussi pour initialiser le reseau, y compris les differentes "queues" de communication virtuelles.
- L'utilisateur demarre une VM : son image est chargee, le premier instant du boot s'effectue surtout en memoire -> communication avec le VMM, s'executant sur un autre core. On ne change pas de contexte, le VMM tourne sur un autre core donc meme si on doit attendre le reponse, ca n'est pas trop grave.
- La VM initialise ensuite le materiel dont elle a besoin (dans notre cas, principalement le reseau. Dans ce cas, la VM communique avec le domaine hote qui se charge d'initialiser une queue de comm virtuel (le hardware se prete bien pour ca) et de l'"assigner" a la VM. A partir de la, la VM peut acceder directement au hardware sans passer par le domaine hote (on a plus se foutu bridge dans le domaine hote pour toutes les comms).
- L'application MPI s'execute dans la VM. En gros, ca demande de la memoire et des comms; le VMM se charge de resoudre les acces memoires et les comms se font directement en bypassant le domaine hote.
Donc au final on a la situation suivante : le domaine hote est utilise principalement pour initialiser le materiel, il ne rentre pas en concideration lorsque les VMs veulent l'utiliser (le point qui est a mon avis tres important); la repartition des differents composants (VM, VMM, domaine hote) sur differents cores evite les changements de contexte tres couteux; le VMM est efficace grace a des mecanismes materiel pour la gestion memoire des machines virtuelles.
Avec une telle architecture, la penalisation associee a la virtualisation pour l'execution d'une application MPI devrait etre assez faible (ce que les premieres etudes tendent reellement a montrer, ce n'est vraiment pas une supposition gratuite).
Et ne pensez pas que ce que je viens de decrire est de la recherche pure que l'on verra peut-etre appliquee dans 5 ans. On a aujourd'hui tous les elements en main pour mettre en oeuvre une telle solution, il faudrait uniquement avoir quelques bons ingenieurs et chercheurs travaillant ensemble, et un peu de temps (ce qui de nos jours est difficile a avoir, surtout que ca ne vise pas le marche de la consolidation de serveur, le seul qui apporte actuellement de l'argent pour la virtualisation).
De plus cette approche a l'avantage de bien separer les choses, on peut donc a partir de la imaginer des choses comme de la redondance de VMM pour la tolerance aux fautes, chose qui serait beaucoup plus difficile a faire avec uen solution de type-II (mais ca, c'est une discussion legerement differente).
Voila j'espere que je suis maintenant un peu plus clair. :-)
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 3.
Le contexte : on a donc une solution de type-I, quels sont les coups associes ? Tout le probleme vient du fait que les VMs ne peuvent pas executer d'instructions privilegiees au niveau materiel, les VMs doivent deleguees l'execution de ces instructions au VMM (hyperviseur) ou au domaine hote. Pour simplifier, le VMM prend en charge tout ce qui concerne la memoire et le domaine hote tout ce qui concerne les drivers pour le materiel (carte reseau par exemple).
Du coup, on a trois sources de surcout :
1/ lorsque le VMM execute quelque chose pour une VM, en gros des resolutions d'adresse memoire. Les derniers processeurs d'AMD apportent un debut de solution materielle pour ca avec leur mecanisme de "nested-page".
2/ lorsque le domaine hote execute quelque chose pour une VM, par exemple pour effectuer des comms. D.K. Panda et Fabrizio Petrini ont deja montre que l'on peut simplifier ca avec les technos reseau haute perf comme infiniband (cf. papiers dans ICS2006, Usenix2006, cluster2007) : l'initialisation de la comm se fait par le domaine hote qui "map" ensuite la memoire de la carte reso directement dans la VM. Du coup, lorsqu'une VM veut acceder au reseau, tout se fait de maniere quasiment directe (modulo quelques resolutions d'adresses memoire mais qui sont au final peu couteuses). Ca reprend l'idee d'OS bypass mis en oeuvre pour toutes les technos reseau moderne, mais dans le cadre de la virtualisation.
3/ les changements de contexte entre le VMM, les VM et le domaine hote. A nouveau des gens comme Ada Gavrilovska et Karsten Schwan de GATech ont montre qu'en placant chacun d'entre eux sur un core (notion de "sidecore") ont peu ameliorer grandement les choses; d'autant plus que dans un avenir proche, les cores ne vont pas manquer (manycores) et tous les experts tendent a s'accorder pour dire que certains pourront etre utilises par l'OS (au sens large ce qui inclus les VMM et les OS distribues).
Maintenant que le contexte est replace, prenons un exemple plus precis : le boot une machine physique virtualisee avec dans une VM un bout d'application MPI qui utilise un reseau de type infiniband. Dans cas, il se passe les choses suivantes (attention je simplifie un peu les choses pour ne pas entrer dans les details) :
- Le bootloader est charge en memoire, trouve l'adresse du VMM et le charge en memoire. Celui-ci initialise la memoire et le(s) processeur(s) et cores.
- Le VMM, une fois initialiser trouve l'adresse du domaine hote (passer en parametre au bootloader); le domaine hote boot comme un charme, il peut executer des instructions privilegiees. Il en profite aussi pour initialiser le reseau, y compris les differentes "queues" de communication virtuelles.
- L'utilisateur demarre une VM : son image est chargee, le premier instant du boot s'effectue surtout en memoire -> communication avec le VMM, s'executant sur un autre core. On ne change pas de contexte, le VMM tourne sur un autre core donc meme si on doit attendre le reponse, ca n'est pas trop grave.
- La VM initialise ensuite le materiel dont elle a besoin (dans notre cas, principalement le reseau. Dans ce cas, la VM communique avec le domaine hote qui se charge d'initialiser une queue de comm virtuel (le hardware se prete bien pour ca) et de l'"assigner" a la VM. A partir de la, la VM peut acceder directement au hardware sans passer par le domaine hote (on a plus se foutu bridge dans le domaine hote pour toutes les comms).
- L'application MPI s'execute dans la VM. En gros, ca demande de la memoire et des comms; le VMM se charge de resoudre les acces memoires et les comms se font directement en bypassant le domaine hote.
Donc au final on a la situation suivante : le domaine hote est utilise principalement pour initialiser le materiel, il ne rentre pas en concideration lorsque les VMs veulent l'utiliser (le point qui est a mon avis tres important); la repartition des differents composants (VM, VMM, domaine hote) sur differents cores evite les changements de contexte tres couteux; le VMM est efficace grace a des mecanismes materiel pour la gestion memoire des machines virtuelles.
Avec une telle architecture, la penalisation associee a la virtualisation pour l'execution d'une application MPI devrait etre assez faible (ce que les premieres etudes tendent reellement a montrer, ce n'est vraiment pas une supposition gratuite).
Et ne pensez pas que ce que je viens de decrire est de la recherche pure que l'on verra peut-etre appliquee dans 5 ans. On a aujourd'hui tous les elements en main pour mettre en oeuvre une telle solution, il faudrait uniquement avoir quelques bons ingenieurs et chercheurs travaillant ensemble, et un peu de temps (ce qui de nos jours est difficile a avoir, surtout que ca ne vise pas le marche de la consolidation de serveur, le seul qui apporte actuellement de l'argent pour la virtualisation).
De plus cette approche a l'avantage de bien separer les choses, on peut donc a partir de la imaginer des choses comme de la redondance de VMM pour la tolerance aux fautes, chose qui serait beaucoup plus difficile a faire avec uen solution de type-II (mais ca, c'est une discussion legerement differente).
Voila j'espere que je suis maintenant un peu plus clair. :-)