> son marché de niche ce sont des applis non optimisées HPC sur des tout petits clusters)
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 gvallee . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. É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.