Pardon, j'avais débordé largement du cadre du HPC pour parler de la virtualisation d'une manière générale.
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 entr0p1e . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. É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.