Cette version est basée sur un noyau Linux 2.6.20 donc un noyau plutôt récent. Rappelons que l'un des objectifs de développement de Kerrighed est d'avoir des modules noyaux relativement autonome vis à vis du c½ur Linux et un patch minimaliste afin de simplifier la cohérence et la maintenance de l'ensemble. La principale avancée de cette version est le support des machines SMP, c'est à dire de toutes les machines modernes dont le processeur est multi-coeur. Même si celui-ci n'est pas encore parfaitement stable, il fonctionne bien. Par ailleurs, une version 64 bits est en cours de finalisation.
Cette version introduit également un support complet pour les communications IPC (segment de mémoire partagée, sémaphore, files d'attente de message).
Afin de montrer que cela fonctionne sur plus de deux machines, un cluster Kerrighed de 252 CPU a été monté. Celui-ci comporte 63 n½uds bi-processeur dual-c½ur ayant chacun 1 Go de mémoire. La machine SSI affiche alors une mémoire globale de 63 Go. Les principaux "concurrents" libres de Kerrighed sont :
- Les clusters de type Beowulf avec par exemple BProc. Ce genre de système est plus simple car il ne propose pas réellement de SSI.
- Les machines OpenMosix. Cependant, depuis que son leader Moshe Bar a annoncé son départ (il travaille depuis quelques années sur Xen), le futur de Mosix n'est pas forcément clair. Une version pour Linux 2.6 est toujours en cours de développement (basé sur un noyau 2.6.17).
- Les clusters OpenSSI. Le projet, tout comme OpenMosix a un long historique et développe aussi une version tournant sous des Linux 2.6 (par exemple la version 1.9.2 est basée sur un noyau 2.6.10).
Aller plus loin
- Le site de Kerrighed (70 clics)
- L'annonce de la version 2.2.0 (35 clics)
- Le cluster de 252 coeurs (115 clics)
# Oui mais bon
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Plus sérieusement : quels applications tournent là-dessus ? Vous avez des benchmarks comparatifs avec des gros calculateurs ? Est-ce prévu pour pouvoir faire tourner Apache et MySQL par exemple (faut-il des processus ou des threads) ?
[^] # Re: Oui mais bon
Posté par zeb . Évalué à 2.
[^] # Re: Oui mais bon
Posté par ragoutoutou . Évalué à 9.
ça se programme comme du multithread classique, c'est tout l'intérêt de ce type de technologie. Si ça utilisait du MPI, ce serait juste du beowulf.
[^] # Re: Oui mais bon
Posté par 16aR . Évalué à 0.
[^] # Re: Oui mais bon
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Est-ce que les disques dures sont aussi partagé l'est la RAM ?
Bref par rapport au autres technos, ou cela se situe-t-il ?
"La première sécurité est la liberté"
[^] # Re: Oui mais bon
Posté par lasher . Évalué à 4.
Ça va aussi être le cas pour des machines bien plus modestes à l'avenir, avec l'HyperTransport d'AMD (déjà présent depuis un moment) et le CSI d'Intel d'une part, et l'utilisation sans doute de plus en plus massive de cartes de calcul dédiées (cartes graphiques et « GPU » en tous genres).
[^] # Re: Oui mais bon
Posté par gentildemon . Évalué à 2.
Dans la branche 1.0, il était en effet possible d'utiliser du multi-thread classique. Cette branche, issue d'un projet de recherche, était très instable.
Dans un souci de stabilisation, la branche 2.x a supprimé un certain nombres de fonctionnalité comme la possibilité d'avoir des threads répartis sur plusieurs machines du cluster. La migration d'application multi-threadé fonctionne encore cependant. Il est donc possible d'utiliser des applications multi-thread, celles-ci sont réparties sur le cluster afin d'équilibrer la charge, mais les threads d'une même application resteront sur la même machine.
Comme c'est un cluster, il est toujours possible d'utiliser du MPI en conservant les performances classiques du MPI sur un cluster.
Les fonctions supprimées entre la version 1.0 et 2.0 réapparaîtront petit à petit dans les mois/années à venir.
# ça existe depuis 1984...
Posté par palm123 (site web personnel) . Évalué à 5.
http://en.wikipedia.org/wiki/OpenVMS#Clustering
Un DLM (distributed lock manager), un disque système unique, avec une racine par machine qui boote dessus, par exemple la bécane Alpha1 boote dans la racine SYS0, Alpha2 sur SYS1, etc...
Il y a du bon matériel sur ces sujets sur la home page de Keith Parris
http://www.geocities.com/keithparris/
particulièrement
Long Distance Cluster Performance
http://www.geocities.com/keithparris/decus_presentations/s99(...)
(étude d'un Cluster avec des bécanes séparées de 200 Kms)
Lock Manager performance
http://www.geocities.com/keithparris/decus_presentations/s99(...)
Disaster Tolerant Cluster Technology and Implementation
http://www.geocities.com/keithparris/decus_presentations/f20(...)
Bon c'est pas libre :-(
ウィズコロナ
[^] # Re: ça existe depuis 1984...
Posté par gvallee . Évalué à 2.
Non pas que je veuille sous-entendre que Kerrighed est mieux (tout depend de ce que l'on veut faire), juste que ces deux systemes ne cherchent pas tout a fait a faire la meme chose.
# Robustesse?
Posté par reno . Évalué à 3.
Je crois me souvenir qu'il s'agissait d'une limitation de la version 1.0 ..
[^] # Re: Robustesse?
Posté par gentildemon . Évalué à 4.
Il est maintenant possible d'ajouter un noeud au cluster sans trop de problème. Pour le retrait (demandé par l'administrateur), c'est en relativement bonne voie. Tous les services ne sont cependant pas à jour à ce niveau.
Quant à la gestion de la défaillance d'une machine du cluster, c'est plus délicat. La mise au point risque d'être assez longue.
J'entends par "gestion de la défaillance" le fait que le système soit stable avec les machines restantes. La haute disponibilité des applications, c'est encore un autre défi :-)
[^] # Re: Robustesse?
Posté par ckyl . Évalué à 4.
Ne pas gerer la tolerance aux pannes dans un environment reparti c'est faire un jouet pas un outil.
Autrement tu as des exemples d'applications reelles qui scalent sur du SSI ?
[^] # Re: Robustesse?
Posté par gvallee . Évalué à 3.
C'est bien pour ca que des le debut Kerrighed a ete architecture pour supporter simplement le checkpoint/restart d'applications et aussi l'ajout/retrai de noeuds. Gentildemon parle de quelque chose d'utilisable en production, pas d'un prototype de recherche. Le prototype de recherche de Kerrighed a deja supporte le checkpoint/restart d'applications mais ca n'etait pas utilisable en production (un jouet pour la recherche quoi).
KerLabs et ces collaborateurs tentent justement de passer de l'etat de jouet a celui d'outil. Mais comme pour tout projet, ce passage prend du temps, il faut etre patient.
> Autrement tu as des exemples d'applications reelles qui scalent sur du SSI ?
Si tu veux une reponse, je pense qu'il va te falloir etre plus precis car "applications reelles qui scalent sur du SSI", c'est un peu vague; tu as quelle echelle en tete ? qu'est ce que tu entends par application reelle ? par SSI tu sous-entends utilisant la memoire partagee ?
Un SSI c'est un ensemble de caracteristiques qui peuvent etre combinees/utilisees ou pas. Pour etre plus precis, avec SSI, tu peux utiliser la memoire partagee ou bien utiliser uniquement l'equilibrage de charge et la tolerance aux fautes, ...etc. Une application donnee "va etre interessee" par certains de ces mecanismes et pas par d'autres (ca depend toujours de l'application au final!).
Niveau plate-forme, des clusters de >1000 noeuds? non clairement ce n'est pas pour demain. Clusters de moins de 100 noeuds pour des applications standard SMP (ou legerement tuner), c'est jouable et les derniers tests semblent indiquer cela (dans le temps j'avais fais des tests avec une appli OpenMP qui allait bien, par rapport a un SMP, ca tenait la route jusque 6-8 ce qui normal pour la plupart des applis OpenMP, donc pour ce cas particulier, ca marche).
Sinon une autre solution serait de voir ce que ca donne avec les applications qui tournent sur les machines SGI, avec un reseau haute perf sous le SSI, ca devrait etre interessant.
Ensuite si ta question est de savoir si un SSI peut etre utiliser avec une application en production, a nouveau pour le moment non (enfin pas a ma connaissance). Mais les petits gars de KerLabs travaillent sur le probleme, il faut rester optimiste, je suis sur qu'ils vont bientot nous sortir une version qui va franchement tenir la route. :-)
[^] # Re: Robustesse?
Posté par ckyl . Évalué à 3.
A priori je pense pas que que le SSI soit adapté à de grosse échelles. Disons un petit cluster classique entre 128 et 512 cores avec dans les 1Go de RAM/Core.
> qu'est ce que tu entends par application reelle ?
Souvent le SSI est présenté comme une solution pour faire tourner des applications "classiques". On a une image unique pour tout un cluster. On laisse, plus ou moins, le système gérer seul la distribution. Une application classique serait éffectivement une application avec CPU intensif et memoire partagée.
Si il n'y a que du CPU et des workers stateless, type demon httpd/dns, alors on peut en general faire du loadbalancing sur les processus. Si il n'y a que des gros besoin mémoire alors des solutions types jumbomem fonctionnent aussi. Et enfin quand on veut réellement se soucier d'écrire une application distribuée alors on utilise un middleware adéquat.
Je pense que votre cluster est justement fait pour jouer, donc ce qui sera intéressant ce sont les retours d'éxpérience.
[^] # Re: Robustesse?
Posté par gvallee . Évalué à 3.
Tout d'abord, ca ce n'est pas une grande echelle actuellement. :-) Plus serieusement je pense que ca devrait le faire si l'on a une application qui le permet. Car soyons serieux : connais-tu une application "classique" actuelle qui peut utiliser tant de core a elle toute seule ? Moi non.
L'avantage du SSI dans ce cas est comme pour le SMP : il est simple de voir ce qui se passe, il est simple de lancer des applications, il n'est pas trop dur d'ecrire une application parallele (memoire partagee tout ca tout ca) et si tu executes des applications en meme temps, les resources sont globalement utilisees de maniere transparentes.
A mon avis, tu ne peux pas ca aussi simplement avec les outils standards pour les systemes distribues (par exemple mais a mon avis, un systeme batch est loin d'etre naturel a utiliser).
Donc SVP, si tu as des elements pour dire que ca ne passe pas a cette echelle, peux-tu donner plus de details? Car vu les derniers tests que j'ai pu voir, ca me semble franchement faisable dans le cas d'utilisation que je decris plus haut.
> Une application classique serait éffectivement une application avec CPU intensif et memoire partagée. Si il n'y a que du CPU et des workers stateless, type demon httpd/dns, alors on peut en general faire du loadbalancing sur les processus. Si il n'y a que des gros besoin mémoire alors des solutions types jumbomem fonctionnent aussi. Et enfin quand on veut réellement se soucier d'écrire une application distribuée alors on utilise un middleware adéquat.
Heu mais la tu justifies le SSI!
- loadbalancing: transparent a l'utilisateur, il n'a rien a faire pour cela, le SSI place et deplace les processus entre les processeurs. Pas besoin de systeme de batch ni d'autres outils qui au final ne font qu'etendre de maniere artificielle ce que les systemes de type Unix font tres bien au sein d'un systeme unique.
- gros besoin en memoire : avec la DSM c'est possible et transparent encore une fois. La difference entre jumbomem et une DSM est vraiment minime pour ce que je sais, non?
- utiliser un middleware adequat : oui et alors? le SSI n'empeche pas ca. C'est meme une bonne idee pour avoir des performances.
Ensuite l'avantages du SSI c'est que tu as le choix : tu veux utiliser MPI pour avoir les perfs de la mort qui tue, pas de pbs; tu veux utiliser pthread qui faire un truc vite fait qui tourne sur quelques noeuds, pas de probleme; ...etc. Et bien sur que le SSI je repond pas a TOUS les besoins (aucune solution ne le fait de toute facon).
Bref, le SSI offre plein de possibilites. Pour certaines personnes, ca ne sera pas interessant, pour d'autres ca le sera. Par exemple, le SSI va tres bien avec le concept de "cluster sur ton bureau", i.e., une petite machines assez dense pour tenir sur ton bureau avec plusieurs processeurs/cores a l'interieur. Pour democratiser ce genre de machine, tu dois cacher la distribution des resoruces, le SSI est parfait pour ca.
> Je pense que votre cluster est justement fait pour jouer, donc ce qui sera intéressant ce sont les retours d'éxpérience.
Justement je t'ai deja dis dans le message precedent qu'avec des applications scientifiques "qui vont bien" (OpenMP dans mon cas), ca se passait plutot bien. L'idee dans ce cas est de remplacer les SMP vieillissant qui etaient utilises pour l'execution de ces applis par quelques noeuds (beaucoup moins chers) faisant tourner un SSI.
# Merci pour la dépèche
Posté par 16aR . Évalué à 2.
A priori, c'est ce vers quoi tend toutes les solutions de clusters SSI.
Du coup j'ai appris ca et ca m'intéresse bien.
Merci !
# complément d'information sur M. Moshe Bar
Posté par jlandru . Évalué à 4.
Moshe Bar a quitté Xensource, il y a un petit moment. Il est un des membres fondateurs de la start-up Qumranet, qui est à l'origine de KVM (Kernel based Virtual Machine).
http://web1.qumranet.com/category_page.asp?id=12
KVM est la solution de virtualisation qui a intégré le kernel 2.6.20 au nez à la barbe de Xen en Nov. 2006. C'est actuellement le challenger de la virtualisation face aux ténors (VMWare ESX et XEN)
http://kvm.qumranet.com/kvmwiki
Personnellement j'ai abandonné XEN, pour revenir à QEMU, car KVM s'appuie sur une version modifiée de QEMU. Sur les machines dotées d'un processeur récent intégrant HVM (extensions virtualisation du jeu d'instruction : VMX chez Intel, SVM chez AMD), KVM est vraiment crédible. Coté performances, ça n'a plus rien à voir avec le couple QEMU/KQEMU. KVM bénéficie de toute la souplesse de QEMU, notamment les fichiers rootfs aux formats raw, cow, qcow, qcow2, iso.
L'été dernier Moshe Bar a effectivement annoncé la fin du projet OpenMosix à l'horizon du printemps 2008
http://sourceforge.net/forum/forum.php?forum_id=715406
[^] # Re: complément d'information sur M. Moshe Bar
Posté par Samuel Thibault (site web personnel) . Évalué à 3.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . Évalué à 2.
- KVM est une solution de virtualization de Type-II suivant la classification de Goldberg [1], i.e., l'hyperviseur tourne au dessus du systeme hote (Linux en l'occurence).
- Xen est une solution de Type-I, i.e., l'hyperviseur tourne directement au dessus du materiel, le systeme hote tournant au dessus de l'hyperviseur; l'approche de type-I est generalement concideree comme offrant de meilleures performances.
Du coup il n'est pas etonnant que l'hyperviseur de KVM s'integre mieux et plus simplement dans le noyau Linux, il a ete fait pour cela des le debut. Pour Xen, le probleme se decompose en plusieurs phases : (i) interface pour les machines virtuelles (surtout si l'on souhaite utiliser la para-virtualisation); (ii) interface ente l'hyperviseur et le domaine hote (principalement pour le domaine des drivers. Il est plus honnete de comparer VMWare ESX et Xen si on veut comparer les efforts d'integration dans le noyau Linux.
Pour finir, personnellement j'apprecie de plus en plus lguest [2] : c'est bien plus petit et bien plus "propre" (ce dernier point est bien sur totalement subjectif).
[1] ARCHITECTURE OF VIRTUAL MACHINES, R.P. Goldberg
[2] http://en.wikipedia.org/wiki/Lguest
[^] # Re: complément d'information sur M. Moshe Bar
Posté par jlandru . Évalué à 2.
[1] http://www.qumranet.com/wp/kvm_wp.pdf
[2] https://linuxfr.org///2007/10/10/23088.html
[3] https://ols2006.108.redhat.com/2007/Reprints/harper-Reprint.(...)
[^] # Re: complément d'information sur M. Moshe Bar
Posté par entr0p1e . Évalué à 2.
Alors je comprends bien que la comparaison type1/type2 est très à la mode (surtout dans les équipes marketing), mais elle devient obsolète, un peu comme la différence RISC/CISC il y a quelques années. Les solutions actuelles sont devenues hybrides.
Pour ma part, je pense que KVM va très rapidement enfoncer Xen niveau performances sur la partie HVM, dès que les drivers réseaux/disques paravirtualisés seront terminés. KVM est plus "lean" que Xen et il n'y a pas les A/R entre l'hyperviseur et le Dom0 pour les accès au hardware. Sans compter que des fonctionnalités telles que l'overcommit de mémoire (déjà présentes dans KVM) seront difficiles à intégrer dans Xen afaik.
VMWare ESX a la possibillité d'optimiser cela puisqu'ils ont décidé d'intégrer les drivers dans l'hyperviseur. Bien entendu, cela revient a réinventer la roue et a un coup énorme en matière d'effort de développement/support, mais une société commerciale faisant du closed source n'a pas vraiment d'autre possibilité.
Effectivement, pour le support de VM complètement paravirtualisées (à la Xen sans HVM donc), lguest (aussi appellé KVM-lite par Rusty) est bien plus propre que Xen.
Mes 2 cents.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par lasher . Évalué à 2.
Euh ... Le CISC pose encore pas mal de problèmes pour les programmeurs de bibliothèques de performance... Même s'il y a du RISC derrière les instructions CISC des x86 modernes, ça n'empêche pas le fait que les instructions sont de taille variable, et donc provoquent l'insertion de bulles dans le pipeline à cause du décodeur d'instruction qui est incapable de savoir correctement à l'avance jusqu'à quel point il va devoir décoder, si l'instruction est déjà dans le cache de micro-code, etc...
Au moins en RISC, les instructions font 32 ou 64 bits, et puis c'est tout. Idem sur les VLIW. Bref, CISC reste un gros boulet qu'on se traîne.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par reno . Évalué à 3.
Les MIPS et ARM ont tous les deux une variante de leur jeux d'instruction sur 16bit, ce qui leur permet d'avoir des densité de code équivalente a celle des x86.
Je ne connais pas de RISC du commerce avec des instructions sur 64bit, ça me parait énorme.
Pour la fin: le gain de jusqu'à 20% de performances quand on est passé de 8 à 16 registre pour lors de la transition x86 au x86-64 a bien montré que le x86 c'est de la m.., mais on n'est pas près de l'abandonner..
Et comme Intel a prévu de s'attaquer au marché de l'embarqué, les x86 pourraient bien prends des parts de marché aux ARM/MIPS sur ce terrain.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par lasher . Évalué à 2.
[1] rares, je l'admets.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . Évalué à 3.
Au moins pour ce qui se passe actuellement au niveau recherche, je pense le contraire : la difference entre type-I et type-II a toujours beaucoup de sens et doit etre preservee car les deux approches ne repondent pas aux meme besoins. Pour justifier le type-I, il est par exemple possible d'analyser les besoins associes a l'execution des applications scientifiques et le HPC. Dans ce cas, dire que la distinction type-I et type-II est avant tout marketing est totalement deplace (je donne quelques points plus bas pour illustrer cela).
De plus tu dis que les solutions actuelles sont hybrides, je crois que c'est vraiment faux. Uniquement _quelques_ solutions sont hybrides, ou alors peux-tu me citer ces solutions SVP, car j'ai besoin d'etre eduque sur le sujet si c'est le cas.
> il n'y a pas les A/R entre l'hyperviseur et le Dom0 pour les accès au hardware. Sans compter que des fonctionnalités telles que l'overcommit de mémoire (déjà présentes dans KVM) seront difficiles à intégrer dans Xen afaik.
Pour eviter les A/R entre l'hyperviseur et le Dom0, on sait deja que la notion de "sidecore" est une solution efficace : tu places l'hyperviseur sur un core et tu executes les VMs et le domaine hote sur d'autres cores. C'est simple et tu gagnes beaucoup en performance. Tu peux te reporter aux travaux fait a GATech pour plus de details (entre autre). Ensuite pour l'overcommit de la memoire, tout d'abord je ne vois pas pourquoi tu veux faire ca (au moins dans le cadre des applications scientifiques/HPC) et ensuite la manipulation de la memoire avec une solution de type-I est tres proche du cout de la gestion memoire dans un systeme normal. J'ai fais des tests avec Xen, le cout est entre 0 et 2 %. Le probleme se situe principalement au niveau des entrees/sorties et la, le type-II n'apporte pas forcement quelque chose de plus. A chaque fois, quelque soit la techno selectionnee, il faut acceder au materiel de maniere directe depuis les VMs, avec le partage entre les VMs.
D'un autre cote, si tu vises le HPC, tu tombes sur les problemes suivant : avec une solution de virtualisation, type KVM, le domaine hote doit absoluement etre un Linux. Or si tu prends les plate-forme HPC actuelles type BlueGene ou Cray, c'est rarement le cas. Tu vas me dire que dans ce cas, la solution de type-I ne fonctionne pas plus car le domaine hote doit etre un Linux. C'est vrai mais cela devrait changer dans un avenir proche si tout va bien (plusieurs projets de recherche sur le sujet). :-) L'autre point interessant est de savoir pourquoi l'hyperviseur devrait etre un module du noyau Linux pour faire des choses simples, i.e., seulement manipuler de la memoire. L'inclusion dans le noyau impose de suivre les evolutions du noyau alors que si tu assumes que l'hyperviseur tourne directement sur le materiel, tu devrais tres peu le modifier dans le temps. Du coup, tu peux garder une architecture simple avec un hyperviseur minimal, une interface claire et simple pour les VMs et le domaine hote. Si tu regardes ce qui se fait dans KVM, on commence a etre loin de cette simplicite.
Pour conclure je vais aller dans ton sens : ce qui est actuellement disponible ne pousse pas a faire la distinction entre type-I et type-II _mais_ les projets de recherche autour de la virtualisation et du HPC notamment devrait aboutir a des solutions ou la distinction est importante.
Et au final, chaque solution a son utilite : le type-II est bien plus interessant pour le developpement et le type-I semblent plus interessant pour l'execution efficace d'applications, notamment les applications scientifiques. Mais bon la on touche clairement la recherche alors l'avenir montera peut-etre que j'ai tord.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par entr0p1e . Évalué à 4.
Si tu te cantonnes au HPC, déjà, clairement la solution dépendra du type de contentions créées par le workload (c'est d'ailleurs une des raisons pour laquelle je doute de l'intérêt d'une solution de type SSI, mais tu le dis toi-même en réponse à un autre post, son marché de niche ce sont des applis non optimisées HPC sur des tout petits clusters).
Sur un cluster HPC dont le workload est tel que les contentions se font sur le CPU ou la mémoire, je ne suis pas forcément certain de l'intérêt de la virtualisation, et comme la majeure partie des clusters HPC existants tournent sur du linux, des solutions beaucoup plus légères du type namespace/vserver me paraissent plus adaptées, surtout si tu peux faire du freeze/checkpoint du process pour faire du loadbalancing ou de la reprise en cas de crash du noeud. A la rigueur, quelque chose du type lguest, mais la liste des features qu'il propose est loin d'en faire une solution de production à l'heure actuelle.
> avec une solution de virtualisation, type KVM, le domaine hote doit absoluement etre un Linux. Or si tu prends les plate-forme HPC actuelles type BlueGene ou Cray, c'est rarement le cas. Tu vas me dire que dans ce cas, la solution de type-I ne fonctionne pas plus car le domaine hote doit etre un Linux. C'est vrai mais cela devrait changer dans un avenir proche si tout va bien
Je ne vois pas en quoi la nature de l'hyperviseur intervient. Les points pertinents à mon avis sont:
- est-ce qu'il est opensource (dans le cas où c'est un prérequis, il y a plein de gens qui s'en foutent, que ce soit heureux ou malheureux)
- est-ce qu'il fait bien son boulot et notamment est-ce qu'il utilise une quantité de ressources négligeable (overhead mais aussi taille occupée etc)
- est-ce qu'il est facile à débugger/faire évoluer/manager
Que ton hyperviseur soit un microkernel, un macrokernel, un foo ou un bar, on s'en fiche un peu du moment que l'environnement virtualisé produit par ta solution fonctionne bien et apporte des avantages par rapport à du vrai hardware (et là, malheureusement, j'ai tous les jours la preuve que le déploiement de VMs ne se fait pas toujours pour des raisons pragmatiques).
La force du kernel linux c'est sa flexibilité : il peut être utilisé en embarqué, sur du temps réél, la machine de monsieur tout le monde, etc. Ca me parait un argument de base valable pour s'en servir comme fondation pour un hyperviseur. Réinventer la roue c'est gentil mais c'est coûteux (cf. ma remarque sur ESX dans mon précédent post). Et pour le reste, je suis confiant sur le fait que Linux+KVM puisse être une solution plus efficace que Xen+Dom0. Les seuls vrais concurrents que je verrais seraient les projets a base de L4 réutilisant les drivers linux en les isolant. Mais Linux+KVM a AMHA une longueur d'avance sur eux, sans compter une base de développeurs et d'utilisateurs bien supérieure.
Si on sort du domaine du HPC et qu'on s'intéresse à des clusters composés de noeuds faisant tourner des VMs de type appliances applicatives, alors ESX est la seule solution vraiment de niveau production à l'heure actuelle AMHA.
Ce type de user case est celui de "la consolidation de serveurs". C'est le cas dans lequel l'overcommit de mémoire est important et dans lequel il est impératif de pouvoir faire tourner un guest "non modifié".
Dans une telle solution, comme tous les oeufs sont dans le même panier, comme pour toute solution où la fiabilité, la facilité de diagnostic et la maintenabilité sont importantes, KISS (Keep It Simple Stupid) est la règle de base à mon sens.
La possibilité d'avoir accès au code pour voir comment ça se comporte en vrai sans avoir à dépendre de la documentation (qui est toujours au moins partiellement fausse) est d'ailleurs un des gros avantages de l'Open Source, et c'est pour cela que pour ma part, j'attends beaucoup de la maturation des solutions de virtualisation Open Source.
Cela dit, pour déterminer où ça coince, on a également besoin d'instrumentation, de familiarité avec la plateforme. Et pour cela, encore une fois, plus c'est simple mieux c'est. Encore une fois je pense que c'est un aspect sur lequel Linux+KVM est plus intéressant que Xen. Rien qu'un exemple : on peut facilement tester sans KVM en gardant le reste de l'environnement à l'identique : il suffit de lancer l'émulation avec l'option -no-kvm.
D'autre part, l'instrumentation du "kernel" Xen est à ma connaissance encore très limitée, et de toutes façon il faut encore pouvoir effectuer les diagnostics en tenant compte de ce qui se passe dans Xen mais aussi dans le Dom0. Les niveaux d'encapsulation font que ça revient au même que le débuggage d'une servlet sur un serveur d'application java, et crois moi, je connais beaucoup de sysadmin qui en frémissent (même si sur ce front là il y a eu des progrès).
D'autre part, pour revenir à la problématique de l'hôte, quelque soit son type, oui, à niveau de maturité de code égal et d'effort de développement égal, plus c'est petit et simple (en nombre de LoC) mieux c'est. Et là, encore une fois, il est plus facile de concevoir une solution minimale ("embedded hypervisor") basé sur KVM que l'équivalent sous Xen du fait de la conception des outils userspace et de l'absence de dépendance vis-à-vis d'un Dom0.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . Évalué à 3.
Je ne suis pas du tout d'accord : le HPC est la niche (quelque billion par an et une part de marche qui ne croit pas vraiment), pas l'inverse.
> des clusters HPC existants tournent sur du linux
Le HPC est tres loin de se limiter aux clusters Linux. Par exemple environ la moitie des 10 machines le plus puissantes du top500 n'executent pas Linux sur les noeuds de calcul (BlueGene -> CNK, Cray -> Catamount). C'est a mon avis une erreur de limiter le HPC aux clusters Linux, pour cela que ldans mes posts precedents j'ai pris la peine de citer ces plate-formes. Je pense d'ailleur que c'est _le_ point qui fait que l'on se soit pas totalement d'accord car ton analyse est tres pertinente et en dehors de ce point, je suis globalement d'accord avec toi.
> des solutions beaucoup plus légères du type namespace/vserver me paraissent plus adaptées, surtout si tu peux faire du freeze/checkpoint du process pour faire du loadbalancing ou de la reprise en cas de crash du noeud. A la rigueur, quelque chose du type lguest, mais la liste des features qu'il propose est loin d'en faire une solution de production à l'heure actuelle.
Quand tu n'as pas de Linux, ca ne marche plus. Et il est clair que ces cas la m'interessent. Et meme si les BlueGene et les Cray vont bientot offrir du Linux sur les noeuds de calcul, vu que c'est une version de Linux "epuree", toutes ces solutions ne fonctionneront clairement pas.
> Que ton hyperviseur soit un microkernel, un macrokernel, un foo ou un bar, on s'en fiche un peu du moment que l'environnement virtualisé produit par ta solution fonctionne bien et apporte des avantages par rapport à du vrai hardware
Heu la non, pas tout a fait. Personnellement je ne peux pas justifier n'importe quoi sans prouver que la degradation en terme de perf n'est pas trop importante. Et dans ce contexte, clairement la nature de l'hyperviseur est important. Avec un type-I, on peut faire un domaine hote petit (dans les solutions actuelles ce n'est pas le cas par defaut) et un hyperviseur avec un comportement predictible (pas le cas de Xen dans certains cas) pour l'execution d'applications paralleles. Je ne pense vraiment pas que tu puisse faire la meme chose avec une solution de type-II (et en fait pas non plus avec les solutions de type-II actuellement dispo!).
Dans mon cas, je ne peux justifier qu'au maximum 10% de penalite avec un vrai apport en terme de fonctionnalites. Si tu passes d'un micro-noyau a Linux + virtualisation, c'est quasiment impossible (deja le passage a Linux meme apres optimisation donne une penalite d'environ 25% dans les all-to-all avec des applications MPI lorsque l'on compare a un micro-noyau).
Et je tiens a souligner que les hyperviseurs actuels (e.g., Xen) ne sont pas des micro-noyaux (tu ne l'as pas dis mais c'est quelque chose que je vois souvent et qui est faux). A ma connaissance aucune solution actuelle est fondee sur un micro noyau (certains disent que ESX l'est mais dur de verifier). Par exemple, L4, catamount et CMK sont des micro-noyau; Xen n'en est pas un.
> Et pour le reste, je suis confiant sur le fait que Linux+KVM puisse être une solution plus efficace que Xen+Dom0.
Pour le HPC sur une machine type Cray, non, impossible actuellement. Sur un cluster deja Linux je suis d'accord avec toi. Mais a nouveau ca sort du HPC strict, ca devient "HPC avec cluster Linux", ce qui je te l'accorde concerne beaucoup de gens, mais pas tout le monde. :-) Et puis meme avec Linux je demande a voir. Mes premiers tests avec KVM n'ont pas montres d'interets reels.
Je suis egalement d'accord a 200% avec ton avis sur L4 et ESX.
> Dans une telle solution, comme tous les oeufs sont dans le même panier, comme pour toute solution où la fiabilité, la facilité de diagnostic et la maintenabilité sont importantes, KISS (Keep It Simple Stupid) est la règle de base à mon sens.
Egalement d'accord a 200% avec toi (ce que meme des gens faisant de l'OS oublient parfoit) mais je pousse l'analyse un poil plus loin : Linux est bien trop complexe (desole mais l'architecture de systeme de fichier, je la trouve vraiment trop complexe :-). Pour cela que je prefere "naturellement" les solutions de type-I : ca t'ouvre les portes pour mettre ce que tu veux dans les VMs mais aussi dans le domaine hote; les differents "composants" de la solution de virtualisation sont bien separes; avec une solution de type-II c'est bien plus complexe (imbrications et dependences).
> La possibilité d'avoir accès au code pour voir comment ça se comporte en vrai sans avoir à dépendre de la documentation (qui est toujours au moins partiellement fausse) est d'ailleurs un des gros avantages de l'Open Source, et c'est pour cela que pour ma part, j'attends beaucoup de la maturation des solutions de virtualisation Open Source.
Dans l'absolu je suis bien d'accord. As-tu jeter un coup d'oeil aux projets finances par la NSF autour de la virtualisation? Il y a des idees interessantes (meme si a mon avis il manque des choses parfois). L'un des projets est le suivant, impossible de remettre le main sur le deuxieme (qui est pourtant plus interessant a mon sens car fonde sur l'idee d'un framework pour le developpement de nouvelles solutions de virtualisation) :
http://www.nsf.gov/news/news_summ.jsp?cntn_id=110606&org(...)
> La force du kernel linux c'est sa flexibilité : il peut être utilisé en embarqué, sur du temps réél, la machine de monsieur tout le monde, etc. Ca me parait un argument de base valable pour s'en servir comme fondation pour un hyperviseur. Réinventer la roue c'est gentil mais c'est coûteux
Justement, pourquoi ne pas reprendre des microkernels existant pour mettre en oeuvre une nouvelle solution (un peu l'idee de L4) ? Bien sur ca sera tres specialise pour une plate-forme donnee (toujours le probleme des drivers) mais je pense que cette approche serait bien plus interessante.
> Cela dit, pour déterminer où ça coince, on a également besoin d'instrumentation, de familiarité avec la plateforme. Et pour cela, encore une fois, plus c'est simple mieux c'est. Encore une fois je pense que c'est un aspect sur lequel Linux+KVM est plus intéressant que Xen. Rien qu'un exemple : on peut facilement tester sans KVM en gardant le reste de l'environnement à l'identique : il suffit de lancer l'émulation avec l'option -no-kvm.
Je recupere des resultats de profiling tous les jours en ce moment en utilisant Xen et oprofile, ca marche plutot bien. Par contre, c'est sur que si tu veux debugger ta VM seule, une solution de type-II est bien meilleure (ce que j'ai deja dis auparavant).
A noter que la simplicite dont tu parles est perdue des que tu veux faire ca au sein d'un cluster de taille assez importante (d'un autre cote, une solution open-source qui apporte un bout de solution pour ca devrait bientot etre mise a disposition, permettant aux utilisateurs de passer tres simplement de VMs sur un cluster a un cluster "normal").
> D'autre part, l'instrumentation du "kernel" Xen est à ma connaissance encore très limitée, et de toutes façon il faut encore pouvoir effectuer les diagnostics en tenant compte de ce qui se passe dans Xen mais aussi dans le Dom0. Les niveaux d'encapsulation font que ça revient au même que le débuggage d'une servlet sur un serveur d'application java, et crois moi, je connais beaucoup de sysadmin qui en frémissent (même si sur ce front là il y a eu des progrès).
Non ca se fait tres bien, comme je l'ai dis, je vois des traces au quotidien et avec des scripts simples, on peut recuperer toutes les informations necessaires. Et pas besoin de modifier quoique ce soit, meme avec au sein d'un cluster.
> D'autre part, pour revenir à la problématique de l'hôte, quelque soit son type, oui, à niveau de maturité de code égal et d'effort de développement égal, plus c'est petit et simple (en nombre de LoC) mieux c'est.
Bien d'accord et encore une fois, si tu as du tout Linux, KVM ou lguest sont tres interessants (j'aime bien les idees de simplicite derriere lguest). Je ne tente pas de prouver le contraire.
> Et là, encore une fois, il est plus facile de concevoir une solution minimale ("embedded hypervisor") basé sur KVM que l'équivalent sous Xen du fait de la conception des outils userspace et de l'absence de dépendance vis-à-vis d'un Dom0.
Non je ne suis pas tout a fait d'accord, il est possible d'avoir un hyperviseur petit et modulaire (donc pas Xen), un hostOS petit (donc pas Linux avec les configurations associees aux solutions de virtualisation actuelles), et des VMs avec ce que l'on veut dedans. Avec Linux+KVM, tu t'eloignes tout de suite de ca (overhead de Linux par rapport a des micro-noyaus specialises).
Mais bon, je pense aussi que de toute facon, avec les solutions actuelles, des que tu passes a une plate-forme distribuee (e.g., cluster), tu te prends la tete et pas qu'un peu.
Pour conclure ton analyse est vraiment pertinente, merci pour ca (ca faisait longtemps que je n'avais pas eu une discussion interessante sur LinuxFr!). Le seul bemol que je me permets est que dans mon cas je ne me limite pas a du tout Linux. :-) Ce qui bien sur n'interessera que peu de personnes ici.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par entr0p1e . Évalué à 5.
>Le HPC est tres loin de se limiter aux clusters Linux. Par exemple environ la moitie des 10 machines le plus puissantes du top500 n'executent pas Linux sur les noeuds de calcul (BlueGene -> CNK, Cray -> Catamount). C'est a mon avis une erreur de limiter le HPC aux clusters Linux, pour cela que ldans mes posts precedents j'ai pris la peine de citer ces plate-formes. Je pense d'ailleur que c'est _le_ point qui fait que l'on se soit pas totalement d'accord car ton analyse est tres pertinente et en dehors de ce point, je suis globalement d'accord avec toi.
OK, disons que mon approche se voulait pragmatique et que je me cantonnais à des clusters Linux sur x86. Pourquoi? Parce que même s'il est vrai que sur le papier il existe des solutions bien plus performantes, la réalité est que d'un point de vue pragmatique, elles ne sont que peu viables (je pourrais revenir là dessus si ça t'intéresse mais ça risque d'être long :)).
(et oui, je met de côté MS WCCS)
>> des solutions beaucoup plus légères du type namespace/vserver me paraissent plus adaptées, surtout si tu peux faire du freeze/checkpoint du process pour faire du loadbalancing ou de la reprise en cas de crash du noeud. A la rigueur, quelque chose du type lguest, mais la liste des features qu'il propose est loin d'en faire une solution de production à l'heure actuelle.
>Quand tu n'as pas de Linux, ca ne marche plus. Et il est clair que ces cas la m'interessent. Et meme si les BlueGene et les Cray vont bientot offrir du Linux sur les noeuds de calcul, vu que c'est une version de Linux "epuree", toutes ces solutions ne fonctionneront clairement pas.
Perso je préfère les "sweet spots" :)
>> Que ton hyperviseur soit un microkernel, un macrokernel, un foo ou un bar, on s'en fiche un peu du moment que l'environnement virtualisé produit par ta solution fonctionne bien et apporte des avantages par rapport à du vrai hardware
>Heu la non, pas tout a fait. Personnellement je ne peux pas justifier n'importe quoi sans prouver que la degradation en terme de perf n'est pas trop importante. Et dans ce contexte, clairement la nature de l'hyperviseur est important. Avec un type-I, on peut faire un domaine hote petit (dans les solutions actuelles ce n'est pas le cas par defaut) et un hyperviseur avec un comportement predictible (pas le cas de Xen dans certains cas) pour l'execution d'applications paralleles. Je ne pense vraiment pas que tu puisse faire la meme chose avec une solution de type-II (et en fait pas non plus avec les solutions de type-II actuellement dispo!).
Je suppose que tu voulais dire "les solutions de type-I actuellement dispo". Si c'est le cas, c'est bien mon avis également.
> Dans mon cas, je ne peux justifier qu'au maximum 10% de penalite avec un vrai apport en terme de fonctionnalites. Si tu passes d'un micro-noyau a Linux + virtualisation, c'est quasiment impossible (deja le passage a Linux meme apres optimisation donne une penalite d'environ 25% dans les all-to-all avec des applications MPI lorsque l'on compare a un micro-noyau).
Mmmh je reste très circonspect sur le calcul des % de pénalité, etc... Les benchmarks c'est un domaine TRES difficile. que ce soit en micro analyse ou macro analyse.
(je ne resiste pas à l'envie de dire à ce sujet que les "near natives performances" de Xen étaient vraies pour Xen 2 avec du paravirtualisé et que sur du Xen 3 avec HVM je pense qu'il y aura des décus)
>> Et pour le reste, je suis confiant sur le fait que Linux+KVM puisse être une solution plus efficace que Xen+Dom0.
>Pour le HPC sur une machine type Cray, non, impossible actuellement. Sur un cluster deja Linux je suis d'accord avec toi. Mais a nouveau ca sort du HPC strict, ca devient "HPC avec cluster Linux", ce qui je te l'accorde concerne beaucoup de gens, mais pas tout le monde. :-)
Oui, de la même façon que tout le monde ne conduit pas de Formule 1 pour aller au travail
> Et puis meme avec Linux je demande a voir. Mes premiers tests avec KVM n'ont pas montres d'interets reels.
On en reparle dans 1 an? ;)
>> Dans une telle solution, comme tous les oeufs sont dans le même panier, comme pour toute solution où la fiabilité, la facilité de diagnostic et la maintenabilité sont importantes, KISS (Keep It Simple Stupid) est la règle de base à mon sens.
> Egalement d'accord a 200% avec toi (ce que meme des gens faisant de l'OS oublient parfoit) mais je pousse l'analyse un poil plus loin : Linux est bien trop complexe (desole mais l'architecture de systeme de fichier, je la trouve vraiment trop complexe :-). Pour cela que je prefere "naturellement" les solutions de type-I : ca t'ouvre les portes pour mettre ce que tu veux dans les VMs mais aussi dans le domaine hote; les differents "composants" de la solution de virtualisation sont bien separes; avec une solution de type-II c'est bien plus complexe (imbrications et dependences).
Je pense que sur le papier tu as raison, dans la "vraie vie" la tendance risque de s'inverser :o)
>> La possibilité d'avoir accès au code pour voir comment ça se comporte en vrai sans avoir à dépendre de la documentation (qui est toujours au moins partiellement fausse) est d'ailleurs un des gros avantages de l'Open Source, et c'est pour cela que pour ma part, j'attends beaucoup de la maturation des solutions de virtualisation Open Source.
>Dans l'absolu je suis bien d'accord. As-tu jeter un coup d'oeil aux projets finances par la NSF autour de la virtualisation? Il y a des idees interessantes (meme si a mon avis il manque des choses parfois). L'un des projets est le suivant, impossible de remettre le main sur le deuxieme (qui est pourtant plus interessant a mon sens car fonde sur l'idee d'un framework pour le developpement de nouvelles solutions de virtualisation) :
http://www.nsf.gov/news/news_summ.jsp?cntn_id=110606&org(...)
Chouette de la lecture! Non je ne connaissais pas, j'y jetterais un oeil demain.
>> La force du kernel linux c'est sa flexibilité : il peut être utilisé en embarqué, sur du temps réél, la machine de monsieur tout le monde, etc. Ca me parait un argument de base valable pour s'en servir comme fondation pour un hyperviseur. Réinventer la roue c'est gentil mais c'est coûteux
>Justement, pourquoi ne pas reprendre des microkernels existant pour mettre en oeuvre une nouvelle solution (un peu l'idee de L4) ? Bien sur ca sera tres specialise pour une plate-forme donnee (toujours le probleme des drivers) mais je pense que cette approche serait bien plus interessante.
Parce qu'on va tomber dans un débat micro- vs. macro- ?
> Je recupere des resultats de profiling tous les jours en ce moment en utilisant Xen et oprofile, ca marche plutot bien. Par contre, c'est sur que si tu veux debugger ta VM seule, une solution de type-II est bien meilleure (ce que j'ai deja dis auparavant).
Intéressant, cela a donc notablement avancé depuis que j'ai arretté de lire les MLs de xen et de lire les papiers!
> A noter que la simplicite dont tu parles est perdue des que tu veux faire ca au sein d'un cluster de taille assez importante (d'un autre cote, une solution open-source qui apporte un bout de solution pour ca devrait bientot etre mise a disposition, permettant aux utilisateurs de passer tres simplement de VMs sur un cluster a un cluster "normal").
Un truc sur lequel tu bosses?
> Et là, encore une fois, il est plus facile de concevoir une solution minimale ("embedded hypervisor") basé sur KVM que l'équivalent sous Xen du fait de la conception des outils userspace et de l'absence de dépendance vis-à-vis d'un Dom0.
> Non je ne suis pas tout a fait d'accord, il est possible d'avoir un hyperviseur petit et modulaire (donc pas Xen), un hostOS petit (donc pas Linux avec les configurations associees aux solutions de virtualisation actuelles), et des VMs avec ce que l'on veut dedans. Avec Linux+KVM, tu t'eloignes tout de suite de ca (overhead de Linux par rapport a des micro-noyaus specialises).
C'est vrai, mais tu y gagnes sur le fait que ça existe déjà et c'est déjà bien répandu et donc qu'il est plus facile d'obtenir du support.
> Mais bon, je pense aussi que de toute facon, avec les solutions actuelles, des que tu passes a une plate-forme distribuee (e.g., cluster), tu te prends la tete et pas qu'un peu.
Ca va tout à fait dans le sens de ce que je disais dans mon autre réponse (dur de suivre vu que nos réponses se croisent :))
> Pour conclure ton analyse est vraiment pertinente, merci pour ca (ca faisait longtemps que je n'avais pas eu une discussion interessante sur LinuxFr!). Le seul bemol que je me permets est que dans mon cas je ne me limite pas a du tout Linux. :-) Ce qui bien sur n'interessera que peu de personnes ici.
Je ne me limite pas qu'à Linux pour ce qui est de comprendre/suivre les tendances, mais par contre j'ai une approche plus pragmatique/orientée production que toi, ce qui est bien normal étant donné nos métiers différents!
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . Évalué à 1.
Ce n'est peut etre pas l'endroit mais ca m'interesse clairement d'avoir ton avis. Pour ce qui est de Catamount et CNK, c'est maintenu depuis des annees et ils ne semblent pas avoir de problemes, ca m'interesserait donc de connaitre ton point de vue sur le sujet.
> Je suppose que tu voulais dire "les solutions de type-I actuellement dispo". Si c'est le cas, c'est bien mon avis également.
Oui pardon pour l'erreur. :-)
> Mmmh je reste très circonspect sur le calcul des % de pénalité, etc... Les benchmarks c'est un domaine TRES difficile. que ce soit en micro analyse ou macro analyse.
Je peux t'assurer que les resultats sont pertinents car ceux auxquels je pense viennent de Cray qui veulent pourtant montrer que leur Linux modifie est interessant par rapport a Linux (et il ne savent pas pour le moment comme regler le probleme).
> On en reparle dans 1 an? ;)
Avec plaisir et en fait je serai heureux de voir que les choses ont change dans le bon sens (ca voudra dire qu'on aura moulte choix!).
> Parce qu'on va tomber dans un débat micro- vs. macro- ?
A mon avis il n'y a pas debat, ce n'est pas un micro-noyau et je n'ai jamais vu d'argumentaire qui le montre (oui c'est une reponse facile celle la). :-)
> Un truc sur lequel tu bosses?
Yep (mais avec de l'aide), ca ne resoudra pas tout (j'ai fais ca vite fait pour repondre a certains de mes besoins) mais j'ai de la demande lorsque j'en parle autour de moi. Par contre je n'en ferai pas la pub ici mais si ca t'interesse, je peux te donner plus de details en dehors de LinuxFr.
> Ca va tout à fait dans le sens de ce que je disais dans mon autre réponse (dur de suivre vu que nos réponses se croisent :))
Oui je sais bien, sur ce coup la, c'est moi qui rend les choses un peu confuses.
> Je ne me limite pas qu'à Linux pour ce qui est de comprendre/suivre les tendances, mais par contre j'ai une approche plus pragmatique/orientée production que toi, ce qui est bien normal étant donné nos métiers différents!
Bien resume et se sont ces differences qui rendent la discussion interessante. Ca fait un moment que je me dis qu'il faudrait creer une page quelque part qui presente ces differents points de vue. Meme dans les publis scientifiques, ca manque.
PS : si ca t'interesse je peux tenter de trouver un lien sur le second projet NSF, c'est a mon sens le plus interessant.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par entr0p1e . Évalué à 2.
En fait, le gros problème à ce niveau est la définition de ce que l'on entends par type I et type II. C'est pour cela que je parlais de la version marketing, parce que pour moi les différences pourtant claires à la lecture des quelques articles fondateurs sur la virtualisations sont devenues très floues au fur et à mesure que j'en apprenais plus sur les solutions existantes.
Anthony Liguori (qui a notamment contribué à Xen, Qemu et KVM), a écrit un article là dessus et en parlera bien mieux que moi :
http://blog.codemonkey.ws/2007/10/myth-of-type-i-and-type-ii(...)
A noter que la page wikipedia http://en.wikipedia.org/wiki/Hypervisor classe KVM en type I également.
Voilà, le point important pour moi a ce sujet c'est que finalement, bien malin est celui qui peut dire lequel est le plus performant entre I et II, surtout maintenant que les CPU "grand public" ont des instructions HVM. C'est ce que je résume (peut être maladroitement) en appelant ça un argument marketing.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . Évalué à 2.
D'ailleur il le dit bien : "Many people think the terms "type-1" and "type-2" originated from this paper but that is simply not the case. The paper does mention the concept of recursive virtualization and briefly discusses the requirements to allow one virtual machine to run within another virtual machine." Forcement c'est dans l'autre papier! Il cite le papier de Popek et Goldberg, pas celui de Goldberg seul (celui de sa these). C'est le papier de Goldberg qui presente la classification de maniere precise. Mais c'est une erreur commune que l'on retrouve meme dans les publications scientifiques sur le sujet.
Il dit ensuite " like VMware Workstation, Parallels, VirtualPC, and KVM all rely on kernel modules which means they do have direct access to hardware" et c'est bien ce qui est important : le module _doit_ avoir un systeme hote pour fonctionner, initialiser la memoire et compagnie. Pour une solution de type-I, le VMM boot en premier. Du coup, si tu n'as pas besoin de drivers particulier, tu n'as pas besoin du systeme hote. C'est pourquoi lorsque tu regardes le cycle de vie d'une VM, il n'y a absolument pas besoin d'acceder au domaine hote au moins dans les premiers instants de vie de la VM. Quel interet si on ne peut utiliser de drivers? et bien tu es libre d'utiliser ce que tu veux comme domaine hote plus tard, et non pas seulement Linux (pourquoi pas un OS specialise parfaitement adapte a ta plate-forme, e.g., CNK des BlueGene). C'est completement impossible avec une solution de type-II. Bon d'accord on parle ici de recherche mais comme je l'ai dis des le debut, c'est le contexte qui m'interesse.
A noter aussi qu'il met Xen dans les micro-kernel, ce qui est faux! Ca n'est pas parce que Xen est petit (quoique sur ca aussi il y a discuter), qu'il est un micro-kernel. Un micro-kernel, c'est par exemple L4 et Xen est tres loin d'une architecture de micro-kernel (Xen a un design tres monolithique).
Donc au final, je ne suis pas d'accord avec l'analyse de Anthony Liguori qui a mon avis melange beaucoup de chose dans cet article et oublie les definitions exactes et initiales.
Pour ce qui est Wikipedia, desole je ne fie absoluement pas a Wikipedia pour ce genre de chose : des que l'on aborde des sujets pointus, bien souvent les articles sont de la vulgarisation et non pas un article de reference.
Pour ce qui est de savoir qui est le plus performant, a mon avis la question a peu de sens, il faut preciser avec quelle application et surtout quelle plateforme materielle. Et c'est bien ca que je tente de souligner : dire que les solutions de type-II sont generalement meilleures a peu de sens, comme dire que les solutions de type_i sont meilleures. Pour le HPC, les solutions de type-I _semblent_ meilleures, notamment vu les resultats de differentes equipes de recherche. A noter egalement que le HVM a priori n'ameliore pas les performances (surtout dans le cas d'une solution de Type-I initialement implementee par de la para-virtualisation). Ca simplifie les choses et ouvre des portes, c'est tout.
Ensuite et pour finir, je ne veux pas prouver que ce qui a ete dit est faux, je souhaite juste souligner que la question de la virtualisation n'est pas simple et que les conclusions demandent totalement du contexte. Je tente juste d'expliquer mon point du vue dans le contexte qui m'interesse (recherche en OS pour resumer).
PS : ce fut en tout cas une discussion agreable qui m'a permi de lire des articles/blogs que je n'avais pas lu. Toujours interessant de voir des avis differents lorsque c'est argumente, ce qui devient un peu trop rare a mon gout sur ce site. :-)
[^] # Re: complément d'information sur M. Moshe Bar
Posté par entr0p1e . Évalué à 2.
"les gens" ici égale mon "marketing" :) Il n'était pas évident dans ta contribution que tu te référais bien au sens original, même si bien sûr j'aurais du m'en douter venant de toi. Cela dit, le fait que toi tu utilises ces termes correctement n'enlève rien à ma remarque, qui ne t'était pas forcément adressée.
> A noter aussi qu'il met Xen dans les micro-kernel, ce qui est faux! Ca n'est pas parce que Xen est petit (quoique sur ca aussi il y a discuter), qu'il est un micro-kernel. Un micro-kernel, c'est par exemple L4 et Xen est tres loin d'une architecture de micro-kernel (Xen a un design tres monolithique).
Donc au final, je ne suis pas d'accord avec l'analyse de Anthony Liguori qui a mon avis melange beaucoup de chose dans cet article et oublie les definitions exactes et initiales.
> Ensuite et pour finir, je ne veux pas prouver que ce qui a ete dit est faux, je souhaite juste souligner que la question de la virtualisation n'est pas simple et que les conclusions demandent totalement du contexte.
Je suis parfaitement d'accord avec toi! Je tentais de souligner cette difficulté, qui commence par une utilisation incorrecte de notion précises.
C'est aussi pour cela que l'article d'Anthony est intéressant car oui, il contient des erreurs et approximations, et pourtant il est écrit par quelqu'un qui travaille pour IBM et contribue de près à 3-4 solutions de virtualisations open source.
Que dire de quelqu'un qui n'en a qu'une vue de loin, surtout quand le hype (ou des contraintes mercantiles) s'en mèle?
> Je tente juste d'expliquer mon point du vue dans le contexte qui m'interesse (recherche en OS pour resumer).
Pour ma part, même si l'aspect conceptuel m'intéresse (obviously), j'ai un lourd passif de sysadmin, donc l'aspect production/pragmatisme m'interpelle également!
> D'ailleur il le dit bien : "Many people think the terms "type-1" and "type-2" originated from this paper but that is simply not the case. The paper does mention the concept of recursive virtualization and briefly discusses the requirements to allow one virtual machine to run within another virtual machine." Forcement c'est dans l'autre papier! Il cite le papier de Popek et Goldberg, pas celui de Goldberg seul (celui de sa these). C'est le papier de Goldberg qui presente la classification de maniere precise. Mais c'est une erreur commune que l'on retrouve meme dans les publications scientifiques sur le sujet.
Intéressant, je n'avais pour ma part jamais vu la référence à sa thèse. Il faut dire que je n'avais que survolé les références du papier écrit avec Popek à l'époque où j'avais la possibilité d'accéder aux documents de l'ACM.
Je pense que malheureusement le fait qu'un grand nombre de papiers de références en informatique ne sont disponibles que via des subscriptions est une des raisons pour lesquelles la roue est sans cesse réinventée et les termes galvaudés.
> Il dit ensuite " like VMware Workstation, Parallels, VirtualPC, and KVM all rely on kernel modules which means they do have direct access to hardware" et c'est bien ce qui est important : le module _doit_ avoir un systeme hote pour fonctionner, initialiser la memoire et compagnie. Pour une solution de type-I, le VMM boot en premier. Du coup, si tu n'as pas besoin de drivers particulier, tu n'as pas besoin du systeme hote. C'est pourquoi lorsque tu regardes le cycle de vie d'une VM, il n'y a absolument pas besoin d'acceder au domaine hote au moins dans les premiers instants de vie de la VM. Quel interet si on ne peut utiliser de drivers? et bien tu es libre d'utiliser ce que tu veux comme domaine hote plus tard, et non pas seulement Linux (pourquoi pas un OS specialise parfaitement adapte a ta plate-forme, e.g., CNK des BlueGene). C'est completement impossible avec une solution de type-II. Bon d'accord on parle ici de recherche mais comme je l'ai dis des le debut, c'est le contexte qui m'interesse.
Hum là je dois avouer que tu m'as perdu entre les considérations liées au démarrage du VMM et celles liées au démarrage de la VM. Je serais interessé par un complément d'information/de la clarification!
> Pour ce qui est de savoir qui est le plus performant, a mon avis la question a peu de sens, il faut preciser avec quelle application et surtout quelle plateforme materielle.
Tout à fait d'accord, je mettais d'ailleurs l'accent sur l'importance de cet aspect même en ne considérant uniquement que le monde du HPC, dans lequel il y a déjà une énorme variabilité dans la nature des applications/workload : CPU bound/memory bound/IO bound, sensible à la latence, embarrasingly parallel, massively parallel, etc ...
Personellement, après avoir passé 1 an en temps que sysadmin dans une équipe gérant un cluster de 1500 coeurs faisant tourner des applications "embarrassingly parrallel", je ne suis pas convaincu de l'utilité de la virtualisation sur de telles échelles, à part lorsque la plateforme est partagée (genre planetlab). Et le problèmatiques qui se posent pour des architectures basées sur des images (façon cloud) sont celles du déploiement des images, du stateless etc... Pas si simple!
> A noter egalement que le HVM a priori n'ameliore pas les performances (surtout dans le cas d'une solution de Type-I initialement implementee par de la para-virtualisation). Ca simplifie les choses et ouvre des portes, c'est tout.
Oui, il y a d'ailleurs eu le papier d'ingénieurs de VMWare a ce propos http://www.vmware.com/pdf/asplos235_adams.pdf
Il me semble que le HVM s'améliore de génération en génération (arrivée du NPT par exemple pour les derniers CPU) et il est probable que cela changera la donne. Une fois encore, on en arrive à une situation de type balance entre logique cablée/software.
> PS : ce fut en tout cas une discussion agreable qui m'a permi de lire des articles/blogs que je n'avais pas lu. Toujours interessant de voir des avis differents lorsque c'est argumente, ce qui devient un peu trop rare a mon gout sur ce site. :-)
Merci du compliment :) Je pense que l'essentiel de nos différences viennent du bout de la lorgnette par lequel nous regardons les choses, recherche pour toi, production info pour moi. Effectivement, ça n'enlève rien à la qualité de tes arguments.
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . Évalué à 3.
Il me vient a l'esprit une question : on se connait ? :-)
Pour le papier, je l'avais cite mais tu touches un point interessant : aujourd'hui beaucoup de gens parlent de virtualisation et beaucoup disent n'importe quoi (comme tu le dis un peu plus loin dans ton message).
> C'est aussi pour cela que l'article d'Anthony est intéressant car oui, il contient des erreurs et approximations, et pourtant il est écrit par quelqu'un qui travaille pour IBM et contribue de près à 3-4 solutions de virtualisations open source.
> Que dire de quelqu'un qui n'en a qu'une vue de loin, surtout quand le hype (ou des contraintes mercantiles) s'en mèle?
Ca c'est clair. Depuis un moment on peut lire tout et n'importe quoi. :-(
> l'aspect production/pragmatisme m'interpelle également!
et moi j'avoue que ce domaine n'est pas mon domaine d'expertise (je suis plutot du cote recherche).
> Je pense que malheureusement le fait qu'un grand nombre de papiers de références en informatique ne sont disponibles que via des subscriptions est une des raisons pour lesquelles la roue est sans cesse réinventée et les termes galvaudés.
Bien d'accord. Surtout que cet article est officiellement disponible uniquement si tu achetes le scan (article de 1973, rien que pour ca, ca vaut le coup de le lire). Mais on le trouve aussi sur le net en cherchant un peu. :-) <ma vie> j'ai pour ma part la chance d'avoir un employeur qui paie les souscriptions. </ma vie>
> Hum là je dois avouer que tu m'as perdu entre les considérations liées au démarrage du VMM et celles liées au démarrage de la VM. Je serais interessé par un complément d'information/de la clarification!
C'est vrai que lorsque j'ai relu, je me suis dis que ca n'etait pas clair. Desole. Je peux detaille mais est-ce le bon endroit?
> Personellement, après avoir passé 1 an en temps que sysadmin dans une équipe gérant un cluster de 1500 coeurs faisant tourner des applications "embarrassingly parrallel", je ne suis pas convaincu de l'utilité de la virtualisation sur de telles échelles, à part lorsque la plateforme est partagée (genre planetlab). Et le problèmatiques qui se posent pour des architectures basées sur des images (façon cloud) sont celles du déploiement des images, du stateless etc... Pas si simple!
Je suis d'accord mais mon cote recherche est du coup interesse par ca. Pour ce qui est de la gestion des images que tu cites, tu as raison ce n'est pas simple mais on travaille sur le sujet et quelque chose devrait bientot etre dispo (dans une version un peu simplifier dans un premier temps). Toi qui a un passe de sysadmin, je suis sur que tu apprecieras l'idee que cette solution ouvre la porte a la specification de ce qu'est un environnement d'execution par les admins et les utilisateurs, et que ces contraintes sont ensuite prises en compte pour la creation d'images et leur deploiement au sein de VM ou de machines standards (pas sur que ce soit clair mais un peu dur de resumer en quelques mots).
> Il me semble que le HVM s'améliore de génération en génération (arrivée du NPT par exemple pour les derniers CPU) et il est probable que cela changera la donne. Une fois encore, on en arrive à une situation de type balance entre logique cablée/software.
D'accord encore une fois. As-tu jete un coup d'oeil sur le mecanisme de "nested pages" que AMD a inclus dans les processeurs Barcelona (en gros avoir le shadow au niveau hardware pour etre plus efficace) ? Ce genre d'ameliorations est vraiment interessantes.
> Merci du compliment :) Je pense que l'essentiel de nos différences viennent du bout de la lorgnette par lequel nous regardons les choses, recherche pour toi, production info pour moi. Effectivement, ça n'enlève rien à la qualité de tes arguments.
Et ca permet de se rappeler regulierement que note monde n'est pas le seul a exister (tout le monde a un peu tendance a rester "la tete dans le guidon" sans discussion de ce genre de temps en temps). Et puis personnellement ca me permet de ne pas oublier ces aspects dans ma recherche, meme si ce ne sont pas mes objectifs premiers. Bon j'arrete la je deviens presque mielleux. :-)
[^] # Re: complément d'information sur M. Moshe Bar
Posté par briaeros007 . Évalué à 4.
Voui, pensez aux autres qui vous lisent ;)
[^] # Re: complément d'information sur M. Moshe Bar
Posté par gvallee . É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. :-)
# Parfait
Posté par Snarky . Évalué à 10.
# Pour geoffroy vallee et entr0p1e
Posté par ZeroHeure . Évalué à 2.
La discussion geoffroy vallee - entr0p1e c'est sacrément intéressant. même si on (je) ne comprend pas tout.
Si j'ai bien suivi, vous êtes l'un dans la recherche, l'autre en production, ce qui vous donne des points de vue différents.
Vous ne voulez pas nous faire partager tout ça plus avant ? Un journal, un article, un débat plus complet...
Vous êtes ardus à suivre dans vos propos, mais certains ici pourraient servir de décrypteurs / modérateurs (je pense à Sytoka Mondon, doué pour les explications).
Peut-être que ça peut se faire sur un Wiki, où d'autres auraient la place d'intervenir (et les trolls seraient éliminés), peut-être qu'on pourrait vous poser des questions par avance, peut-être etc.
A moins que le sieur Bodor vous fasse une proposition ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Pour geoffroy vallee et entr0p1e
Posté par gvallee . Évalué à 2.
Apres a nouveau, je n'ai pas beaucoup de temps libre, je ne peux pas garantir que je serai tres tres reactif.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.