>> 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.
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 entr0p1e . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. É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!