Livre blanc Bearstech sur la virtualisation en logiciel libre

Posté par . Modéré par Benoît Sibaud.
Tags :
0
12
jan.
2008
Technologie
Suite au passage à une architecture de virtualisation cet été pour ses solutions d'hébergement, la société Bearstech publie le résultat de ses recherches sous la forme d'un livre blanc d'une centaine de pages sur l'état des lieux de la virtualisation libre pour les serveurs, et sur ce qu'elle peut apporter aux entreprises.

Dans ce livre blanc vous trouverez une description des différents systèmes de virtualisation existants et des préconisations d'utilisation dépendant de l'usage que l'on veut en faire.
Pour terminer, ce livre blanc décrit les projets disponibles (KVM, Xen, VServer, etc.) avec un comparatif des différentes technologies utilisées.

Cet ouvrage très didactique ne nécessite pas de connaissances préalables sur le sujet. Il peut donc intéresser tous ceux qui veulent en savoir un peu plus sur la virtualisation.

Ce document est diffusé sous la licence CC By-NC-SA 2.0

  • # Bof

    Posté par (page perso) . Évalué à  4 .

    Le comparatif est plutôt léger. Rejetant OpenVZ parce que "trop idéologique" et Linux Vserver parce que trop "difficile pour un administrateur" et pas assez "markété".

    C'est en gros un livre blanc de promotion de Xen, qui est (de mon expérience) pour faire de la virtualisation Linux / Linux le moins performant et le moins stable (par rappart à Linux Vserver , OpenVZ et Vmware), et qui de plus à une pérénité discutable ( rachat par Citrix etc .... ).
    • [^] # Re: Bof

      Posté par . Évalué à  5 .

      Et par ailleurs c'est incohérent de mettre le document sous licence "CC By-NC-SA" quand le document explique qu'il refuse par principe les solutions non-libres.
    • [^] # Re: Bof

      Posté par . Évalué à  -6 .

      Ah la virtualisation.... la fausse bonne idée du siècle (avec d'autres) amha...

      Mais c'est vrai que c'est si bon les SPOF... avoir n serveur tombant en simultané quel bonheur, quel délice !

      Tiens je sens que je vais me faire moinser... Mais je n'exprime que mon humble avis... je préfère avoir n machine en PIII (ou equivalent) qu'une en quad-core de la mort qui fera tourner n serveurs virtuels..... Mais qu'entends-je ? Tiens l'echo de quelques intégristes verts qui vont sous peu me parler de consommation, d'économie... Ok les gars c'est vous qui avez raison et je passerai à ces réductions nécéssaires pour l'environnement quand l'interdiction de peter (notamment pour les vaches) sera effective et votée par notre noble assemblée (ainsi que l'interdiction formelle aux volcans de se mettre en irruption et ce au niveau des instances mondiales)...

      Bon et bien c'était mon troll à deux balles et cher tovarich, je m'en excuse d'avance ;)... J'en resterai jusque preuve du contraire que la virtualisation est une fausse bonne idée en production...
      • [^] # Re: Bof

        Posté par (page perso) . Évalué à  3 .

        J'ai bien vu ton ";)" mais tu pourrais éviter tes commentaires limites insultants sur les utilisateurs de solution virtuelle.

        Ca ne te convient pas ? Ben n'utilise pas ... et ?

        Par contre, ca peut convenir à d'autres personnes (et pour bien d'autre raison que l'écologie). Aujourd'hui nous utilisons vserver dans notre entreprise sur 3 serveurs interne et nous ne reviendront pas en arrière.
        • [^] # Re: Bof

          Posté par . Évalué à  -1 .

          Mon cher GnunuX,

          Si il vous a semblé que je fus insultant dans ce commentaire, veuillez recevoir mes plus plates excuses. Il ne m'avait semblé pourtant n'exprimer que mon humble opinion sur les dangers relatifs en terme de disponibilité et sécurité des solutions de virtualisation. J'avoue ne pas avoir développé sur le sujet car cela serait bien long. En aucun cas je ne dénigre votre choix vers Vserver (je parlais surtout de Xen mais seuls quelques érudits l'auront compris) qui dans certains cas peut s'avérer représenter une solution louable... Ne connaissant pas votre infrastructure, je me garderai bien de juger de vos décisions. Cela fait partie intégrante de mon éducation générale, tout comme le fait d'éviter les single point of failure fait partie de mon 'éducation informatique'. J'exprimais mon opinion, ne vous en déplaise... Mais encore une fois, si vous avez été blessé par mes propos, je vous prie de bien vouloir m'en excuser...
          • [^] # Re: Bof

            Posté par . Évalué à  3 .

            Oui enfin le ton condescendant n'aide pas a faire passer tes propos .... (tu permets que je te tutoies ?)
            • [^] # Re: Bof

              Posté par . Évalué à  -2 .

              Pourquoi pas ?


              Mais j'exprimais juste un avis sur les solutions de virtualisation... Avoir une couche logicielle pour piloter les serveurs virtuels m'emmerde je te l'avoue... J'aimerai que ce soit piloté en hard directement (vt étant amha insuffisant) et que mes serveurs virtuels soient totalement independents...

              Reste ensuite le problème même du hardware et du SPOF... à l'image des combis (j'avoue que cela est réducteur et moindre que le cas qui nous concerne mais bon ca reste une image) télé + magnéto qui lorsque le magneto tombe en panne t'impose de te separer de ton téléviseur.

              C'est une question d'approche et chacun voit midi à sa porte.... mais très sincèrement, je ne peux cautionner l'utilisation d'une couche logicielle (et les problemes inhérents à ce type de configuration) pour la virtualisation c'est tout...

              Maintenant, j'ai peut être tord, et il est dans la nature humaine de se tromper ou d'avoir de fausses idées et c'est probablement mon cas.... C'est l'approche que j'ai eu toutefois et les interrogations que je me suis posées sur ce type de solutions... C'est tout...

              J'avoue être bien souvent de mauvaise foi, d'être souvent condescendant et d'utiliser parfois le vous à ces mêmes fins... Mais bon je suis moi... avec tous mes bugs de la vie, mon caractère de merde, mes idées arrêtés qu'il m'arrive avec intelligence de remettre en question sans l'avouer (cf. mauvaise foi) et tu vois j'avoue même une certaine propension à parler pour ne rien dire (symptomatique des personnes qui se coupent parfois du monde sans vouloir pourtant s'eloigner inconciemment d'un semblant d'humanité)

              Oui tu peux me tutoyer car je ne suis qu'un vieux con de 38 printemps qui à son humble plaisir n'est jamais et n'a jamais voulu sortir de l'adolescence et de ses provocations ... ;)

              Il n'y a pas de bonne ou de mauvaises idées quelque soit le sujet... Il y a juste des approches différentes.... C'est aussi cela qui fait la richesse de l'homme...


              Bien à toi et au plaisir de te lire... ;)
              • [^] # Re: Bof

                Posté par . Évalué à  1 .

                Mais j'exprimais juste un avis sur les solutions de virtualisation... Avoir une couche logicielle pour piloter les serveurs virtuels m'emmerde je te l'avoue... J'aimerai que ce soit piloté en hard directement (vt étant amha insuffisant) et que mes serveurs virtuels soient totalement independents...

                Tu ne rechercherais pas plus une mainframe que de la virtualisation?
        • [^] # Re: Bof

          Posté par (page perso) . Évalué à  3 .

          mais tu pourrais éviter tes commentaires limites insultants sur les utilisateurs de solution virtuelle.


          Rien à voir avec le débat mais j'aime beaucoup la notion de "Solution Virtuelle".

          J'essayerai de le replacer lors de ma prochaine réunion :)
      • [^] # Re: Bof

        Posté par (page perso) . Évalué à  5 .

        Disons que cela dépend de comment tu l'utilises.

        Pour prendre l'exemple d'une plate-forme d'un client qu'on est en train de refaire (l'ancienne a 3 ans et montre ces limites en terme de performances), toute la partie principale (grosso modo l'hébergement des sites soit 7 serveurs) n'est pas virtualisée. On sait qu'on a besoin de beaucoup de ressources et on ne veut pas la déstabiliser avec d'autres services.

        Par contre, on a galéré pendant les 3 ans pour gérer des services annexes répartis sur plusieurs autres serveurs. Certains étaient petits au début et ont trop grossi pour qu'on les laisse perturber les autres services d'une machine. Pour d'autres, on avait prévu large et finalement, ça a vivoté. Du coup, on a pas mal galéré à déplacer les services, les réorganiser...
        On a maintenant 4 machines banalisées pour ces services. Chaque service est dans un VServer et s'il y a besoin de les balader, ça se fera de manière plutôt transparente.
        Le principe du "j'ai un serveur qui tombe, je perds n services" n'est pas forcément pertinent vu qu'on ne peut pas vraiment se permettre de perdre ne serait-ce qu'un service. Donc, les VServers sont doublés sur les 4 machines (ce qui aurait été chiant à faire sinon parce que tous les services auraient été mélangés).

        En l'occurrence, on n'a pas moins de serveurs qu'avant sur la plate-forme. On est passé de 17 à 15 mais juste parce qu'on a supprimé une couche intermédiaire. Par contre, c'est plus propre, on peut la faire évoluer plus facilement et on sera serein sur les démarrages de nouvelles fonctionnalités ou pour l'évolution des anciennes. Pas besoin de prévoir 2 serveurs dès le départ, on monte 1 ou 2 VMs pour les différents services et on attend de voir ce que cela donne.

        Après pour prendre un autre exemple avec de la vraie virtualisation, c'est aussi très pratique sur des machines d'intégration pour avoir plein d'environnements différents.

        Clairement, il y a un gros effet de mode actuellement mais derrière il y a des vrais besoins et cela apporte vraiment quelque chose sur le plan pratique.
        • [^] # Re: Bof

          Posté par . Évalué à  1 .

          Nous sommes d'accord... tout dépend comment la virtualisation est utilisée.... La virtualisation, je peux la concevoir dès lors qu'une redondance est assurée par une autre machine. Sinon, amha, le type se tire une balle dans le pied. :)
          • [^] # Re: Bof

            Posté par (page perso) . Évalué à  3 .

            La virtualisation, je peux la concevoir dès lors qu'une redondance est assurée par une autre machine.

            Je dirai la même chose de la non-virtualisation :).

            Le fait d'avoir un SPOF n'est pas un problème intrinsèque de la virtualisation, juste que ton SPOF est peut-être plus critique. Ca reste une mauvaise idée d'avoir un SPOF. Et la "virtualisation" (j'inclus les containers) peut te permettre de redonder tes services de manière élégante (ie en évitant d'avoir une machine fourre-tout).
            • [^] # Re: Bof

              Posté par . Évalué à  2 .

              Arf... Si vous saviez le nombre de trous du culs (désolé pour l'expression) que j'ai vu redonder sur la meme machine en virtualisation avec de plus une fierté déconcertante et une suffisance effrayante...

              Après, nous sommes d'accord... C'est une question de cout mais il vaut mieux 2 machines minimum même sans virtualisation mais redondées, qu'une seule qui, si elle tombe (panne hardware ou exploit) entrainera une indisponibilité de l'ensemble des services.

              C'était d'ailleurs l'objet de mon premier commentaire car bon nombre de personnes malheureusement virtualisent sans redondance et dans ce cadre mettent en péril la disponibilité de leurs services.

              Nous avons la même approche je pense, peut etre nous sommes nous mal compris (j'avoue avoir quelques problemes pour exprimer ceratines idées parfois ;) )

              Bien à vous,
              • [^] # Re: Bof

                Posté par . Évalué à  1 .

                Nous avons la même approche je pense, peut etre nous sommes nous mal compris (j'avoue avoir quelques problemes pour exprimer ceratines idées parfois ;) )



                Alors soit tu as VRAIMENT de gros problèmes,
                parce que dire "La virtualisation ça sux des mamans des ours" pour dire virtualisation ça peut être bien, faut juste faire attention" c'est énorme, soit tu tro^W fait preuve d'une mauvaise foi incroyable.
                • [^] # Re: Bof

                  Posté par . Évalué à  -1 .

                  on fait d'une pierre deux coups car un sembant de réponse à mes propos se trouve ici -> https://linuxfr.org/comments/897431,1.html

                  Pardonnez moi d'avoir perturbée la sacro-sainte église de la virtualisation encore une fois...
                  • [^] # Re: Bof

                    Posté par . Évalué à  0 .

                    Si ça peut te rassurer, J'en ai strictement rien à foutre de la virtualisation, je sais à peine ce que c'est ;)

                    Comme quoi je trolle mais tu files le bâton pour te faire battre.
                    • [^] # Re: Bof

                      Posté par . Évalué à  -1 .

                      humpfff .... moi aussi je t'avoue puisque je n'y adhère pas... ;)

                      Mais c'est si bon de se faire foutter en public sur le donjon LinuxFR ...

                      Ah OUIIIIIII, j'ai été un mauvais garcon.... Fouette moi encore !!!!!

                      (délire à deux balles)
          • [^] # Re: Bof

            Posté par . Évalué à  5 .

            > Sinon, amha, le type se tire une balle dans le pied. :)

            Refuser de façon butée la virtualisation, c'est aussi se tirer une balle dans le pied.
            Ce n'est pas car il y a des mauvais usages de la virtualisation (comme pour tout) qu'il faut en conclure que la virtualisation est sans intérêt.
            On pourrait facilement donner pleins de cas où 10 machines physique sont utilisées alors que 4 ou 5 suffiraient sans problème (même sans utiliser de virtualisation).
            Trop de virtualisation c'est nul. Trop de machine physique aussi.

            J'utilise actuellement la virtualisation. Je dois faire un site web qui va tourner sur un serveur dédié (virtuel ou réel, qu'importe). Le développement va se faire sur ma station de travail. Elle a une distribution communautaire et donc un support dans le temps trop limité. Il me faut une distribution avec un long support pour ce site web.
            Que faire ?
            Acheter une nouvelle bécane ?
            Non, c'est ridicule.
            Installer l'autre distribution en multi-boot et booter dessus lorsque je veux/dois bosser sur le site ?
            Trop chiant, je perds tout mon environnement.
            Etc...

            La solution pour mon cas (et que ce cas) est d'installer une machine virtuelle avec le distribution qui sera utilisée pour le site web. Et voila. C'est facile, c'est rapide, ça marche très bien. C'est se tirer une balle dans le pied que de ne pas le faire.
      • [^] # Re: Bof

        Posté par . Évalué à  3 .

        Des PIII ?? Tu as ouvert un catalogue informatique depuis combien de temps ? Essaye et tu remarqueras que les machines actuelles sont parfois des monstres vis-à-vis de certains besoins basiques mais vitaux dans un SI. Du coups, plutôt que de laisser des bi-prox quad-coeurs se contenter de distribuer des jetons on isole basiquement des systèmes dessus par la virtualisation et on leur donne plusieurs tâches à faire.
        C'est bête, c'est simple et ça marche.
        • [^] # Re: Bof

          Posté par . Évalué à  1 .

          tu remarqueras que les machines actuelles sont parfois des monstres

          Oui, enfin il suffit de payer moins cher et tu n'auras pas un monstre...
          Si tu as le goût de l'aventure, tu peux même essayer de te concocter un petit serveur économe à base de processeur Via (équivalent à un PIII :-)).
          • [^] # Re: Bof

            Posté par . Évalué à  2 .

            > Oui, enfin il suffit de payer moins cher et tu n'auras pas un monstre...

            Je ne connais pas exactement les caractéristiques du serveur dlfp, mais je ne serais pas étonné qu'au niveau cpu, un cpu grand public (un athlon 64 X2 à 80 €) soit suffisant. Pour 80 € tu as un monstre pour le cpu. Pour 300 € tu as 2 Go de mémoire très très rapide (8 Go/s de bande passante je crois).

            Ça demande presque de faire un effort non justifiable pour chercher du matos moins puissant.

            NB : Ce raisonnement n'est valable qu'en entreprise.
            • [^] # Re: Bof

              Posté par . Évalué à  2 .

              Je ne connais pas exactement les caractéristiques du serveur dlfp, mais je ne serais pas étonné qu'au niveau cpu, un cpu grand public (un athlon 64 X2 à 80 €) soit suffisant

              https://linuxfr.org/stats/web.html/

              Environ 3 pages par seconde en moyenne, donc avec des pics bien au-dessus de ça. Ce sont des pages dynamiques générées en PHP/MySQL, même avec le système de cache de Templeet qui-tue-sa-race je pense qu'il vaut mieux prévoir du matos pas anémique. A mon avis il n'y a pas de quoi héberger plusieurs Linuxfr-like sur le CPU dont tu parles, sauf à accepter de grosses lenteurs.

              Par ailleurs, en entreprise si tu fais un site Web, tu veux qu'il tienne quand il y a des poussées de fréquentation très brusques (genre slashdottage), parce que ce serait quand même bête que le site soit inaccessible juste au moment où il attire beaucoup de clients potentiels. Donc il vaut mieux prévoir de la marge.
              • [^] # Re: Bof

                Posté par . Évalué à  1 .

                > A mon avis il n'y a pas de quoi héberger plusieurs Linuxfr-like sur le CPU dont tu parles

                Je ne parlais pas d'en mettre plusieurs. Mais un seul.
                Je pense que le cpu que j'ai donné doit tenir le "choque" sans trop de problème (pas forcément les doigts dans le nez).
                • [^] # Re: Bof

                  Posté par . Évalué à  1 .

                  Je ne parlais pas d'en mettre plusieurs. Mais un seul.

                  Oui, mais le sujet c'est la virtualisation :-)
          • [^] # Re: Bof

            Posté par . Évalué à  1 .

            Oui, enfin il suffit de payer moins cher et tu n'auras pas un monstre...


            Encore une fois je parle de la vie pro, pas d'un cas personnel. Je n'ai pas besoin d'un serveur de jetons pour moi. Dans un SI les catalogues sont généralement ciblés et limités à certains modèles (contrat passé avec un constructeur). Crois moi, si tu prends la machine la moins chère tu auras tout de même quelque chose de surpuissant pour des besoins basiques. Le fait de chercher à réduire la prolifération de ces bécanes par la virtualisation est extrêmement courant.
        • [^] # Re: Bof

          Posté par . Évalué à  4 .

          Du coups, plutôt que de laisser des bi-prox quad-coeurs se contenter de distribuer des jetons on isole basiquement des systèmes dessus par la virtualisation et on leur donne plusieurs tâches à faire.

          Je plussoie énergiquement. J'ai sur une plate-forme de test un serveur qui ne demande qu'à ce qu'on utilise ses ressources. Plutôt que d'avoir comme souvent un GNU/Linux avec des milliers de services dans tous les sens qui se marchent les uns sur les autres, j'ai plusieurs machines virtuelles soigneusement rangées les unes à côté des autres, avec parfois des durées de vie très limitée. J'utilise Xen pour cela, ça marche très bien, nous sommes plusieurs sur le serveur, et tout le monde est content car chacun gère sa ou ses machines virtuelles. Et pas besoin d'un rack rempli de bécanes pour ça. Franchement, j'ai déjà eu à gérer des situations avec justement plein de de PIII partout, et bien, y'a pas photo.
      • [^] # Re: Bof

        Posté par . Évalué à  6 .

        indice : à force, on sait faire des machines qui tombent plus en panne. ou plutot, en y mettant les moyens nécessaires, une machine peut tomber en panne et une autre prendre le relais sans rien avoir à faire

        indice : tes machines en PIII ou équivalent ca se fait plus et ca a disparu de la circulation. déjà j'aurais du mal à les acheter, même si je voulais

        indice : tes autres bécanes en PII aussi auront vécu et leur alimentation ou leur disque va lacher du jour au lendemain. dans le premier cas ca crame tout, dans le deuxieme il faut se lever tot pour trouver des disques durs de la même classe de taille (genre IDE < 120 Go) et souvent tu t'apercevras qu'il te manque la moitié des affaires pour restaurer cette machine. joie.

        indice : au lieu de surveiller au niveau matériel n machines tu en surveilles juste une ou deux pour le prix de la supervisation des machines virtuelles : si ca te prend moins de temps - ou si tu dors plus tranquille - c'est gagné et puis c'est tout.
      • [^] # Re: Bof

        Posté par . Évalué à  -1 .

        tu pourrais au moins t'intéresser a l'informatique avant de poster .Un troll ça peu être drôle si il y a matière .Mais la c'est un peu dire en 2008 "la terre ronde, c'est pas une bonne théorie". Y a plus de débat la,tu vois ,c'est trop tard...Aller continu de lire des mags info tu finiras bien par comprendre quelques chose et réussir a formuler des opinions qui tiennes la route.Bon courage.
        • [^] # Re: Bof

          Posté par . Évalué à  0 .

          Bon cher ami je t'ai plussé car tu étais à -2 et j'aime pas cà... Mes explications ici -> https://linuxfr.org/comments/897431,1.html .... sinon :

          Je plussoie d'ailleurs en ton sens... Décidement je ne connais rien à l'informatique.... Mon QI est limité, mes neurones ne suivent plus... bref je suis cassé et usé... Tu me proposes de lire des mags mais le problème c'est que je n'ai jamais appris ni à lire ni d'ailleurs à écrire... D'ailleurs je te demande un peu de compassion... Cela ne fait que trois jours que je me suis mis à l'informatique et ne sachant pas lire, cela me cause de gros problèmes....

          Voudrais tu dans ton infime bonté :

          1 - M'apprendre à lire et à écrire
          2 - M'enseigner les rudiments de l'informatique et ainsi faire de moi le professionnel que je rêve d'être c'est à dire à ton image ?

          Merci de ta bienveillance ...
    • [^] # Re: Bof

      Posté par (page perso) . Évalué à  4 .

      Assez d'accord.

      En particulier sur OpenVZ. Pour avoir très sérieusement envisagé de l'utiliser, je n'ai jamais eu l'impression que les gens de Virtuozzo poussaient outre mesure les utilisateurs vers la solution propriétaire, que ce soit dans les forums et sur les mailing-lists où j'ai toujours vu une attitude très constructive pour aider les utilisateurs. Ils maintiennent vraiment OpenVZ comme une solution technique viable et fiable, pas comme une version de développement mal finie de Virtuozzo.
      De plus, ils ont une vraie volonté d'intégrer leurs technos dans le noyau Linux pour que Linux propose enfin en standard une vraie solution de container.
      Le seul truc qui m'a un peu rebuté dans OpenVZ, c'est la gestion des ressources puissantes mais pas spécialement facile à prendre en main. Il est difficile de trouver de la documentation concrète sur le sujet.

      Je n'aurai pas comparé les solutions de containers type VServer et OpenVZ avec les solutions de virtualisation que peuvent être Xen ou KVM. Les usages et les contraintes ne sont pas du tout les mêmes et il faut, AMHA, au moins une solution de chaque.
      Typiquement, quand il s'agit juste d'obtenir un gain de facilité d'administration en compartimentant des services (avec pour objectif d'avoir des services bien identifiés, de pouvoir les rerépartir sur des machines en fonction de leur évolution...), les solutions de container sont clairement devant. Elles sont beaucoup plus souples et offrent en général de meilleures performances.

      Je suis par ailleurs un peu surpris par le fait que VServer soit considéré comme complexe - il est à mon sens plutôt simple à utiliser et les outils sont assez rodés. Je suis par contre on ne peut plus d'accord sur le fait que maintenir des patches sur des trucs aussi complexes peut poser des soucis de maintenabilité à long terme.
      OpenVZ a l'avantage de proposer des patches sur les kernels des distributions (notamment ceux des RHEL), ce qui est plutôt bien pour des serveurs de production. Il me semble qu'il y a des kernels debian aussi mais je n'y mettrai pas ma main au feu.

      Bon, après, c'est probablement un peu facile de critiquer mais je pense qu'il est important d'insister sur le fait que containers ET virtualisation ne répondent pas aux mêmes besoins et qu'il est important d'avoir les deux. Et j'attends avec impatience le jour où il y aura enfin une solution de containers dans les kernels standards.
      • [^] # Re: Bof

        Posté par . Évalué à  2 .

        Bon, après, c'est probablement un peu facile de critiquer mais je pense qu'il est important d'insister sur le fait que containers ET virtualisation ne répondent pas aux mêmes besoins et qu'il est important d'avoir les deux. Et j'attends avec impatience le jour où il y aura enfin une solution de containers dans les kernels standards.

        Tout à fait d'accord, ces deux technologies ne visent pas forcément le même but, mais pour de l'hébergement de serveurs, qui était le but premier de l'étude, les deux conviennent, à mon sens. C'est pour ça que j'ai étudié ces deux technos côte à côte.

        Après, pour isoler de manière quasi-parfaite des systèmes, il faut éviter les conteneurs, alors que pour simplement cloisonner des applis pour éviter qu'elles se "pourrissent" mutuellement, il est plus pertinent d'avoir recours aux conteneurs qu'à une solution à base de machine virtuelle. C'est peut être pas dit aussi clairement dans le document, c'est vrai.
    • [^] # Re: Bof

      Posté par . Évalué à  4 .

      Hmm, non, je fais pas la promotion de Xen, je dis simplement que c'est à l'heure actuelle un des solutions les plus performantes et que nous (ie. Bearstech) avons réussi à l'installer et le configurer très simplement. Arriver à s'en servir assez rapidement et trouver des trucs tous prêts pour ça dans sa distro c'est quand même important. Pour caricaturer, on veut pas se taper des kernels à compiler tous les mois sur nos serveurs.

      À terme, je suis déjà moins confiant pour Xen, avec le rachat par Citrix qui a tout perturbé en pleine rédaction du pavé, et un possible virage vers le proprio (on attend toujours la Xen Foundation...).

      VMware est hors concours pour cette étude, proprio. Il est cependant très performant, c'est certain.

      OpenVZ, je n'aime pas le comportement de la société qui met en avant sa solution proprio partout, même sur le wiki "communautaire" (ce que ne fait pas XenSource, le wiki est certes bordélique, mais ne fait pas de lien vers XenEntreprise Pro machin tous les 3 paragraphes). Si on fait abstraction de ça, cela reste une solution de virtualisation par conteneurs très performante, au même niveau que Linux-VServer (je n'ai pas fait de comparatif très poussé entre ces deux là, je ne me prononce pas plus).
      • [^] # Re: Bof

        Posté par (page perso) . Évalué à  2 .

        OpenVZ, je n'aime pas le comportement de la société qui met en avant sa solution proprio partout, même sur le wiki "communautaire"

        J'ai vraiment l'impression que c'est une fausse idée. J'ai fait pas mal de recherches concrètes sur OpenVZ et beaucoup lu la doc et les forums pour le mettre en place en test et je n'ai vraiment pas eu cette impression.

        Un des trucs qui contredit ce que tu penses, c'est qu'ils fournissent des noyaux patchés pour pas mal de distributions et les maintiennent (ils maintiennent encore le noyau de la RHEL4 par exemple). Ca aide quand même pas mal à l'adoption d'OpenVZ alors qu'ils auraient pu fournir un patch et un kernel vanilla.
        • [^] # Re: Bof

          Posté par . Évalué à  1 .

          hmm, j'ai peut être été un peu dur avec eux alors, vu les réactions observées ici :)
      • [^] # Re: Bof

        Posté par (page perso) . Évalué à  2 .

        > VMware est hors concours pour cette étude, proprio. Il est cependant très performant, c'est certain.

        Je ne suis, mais alors pas d'accord du tout. VMWare est une solution
        lourde disposant certes (en version entreprise) de tout un tas de
        système de gestion poussé. Mais de la à dire qu'il est très performant ....
        Très cher oui, très bien vendu par IBM & co, oui aussi.
        Pour avoir fait des tests basiques de débit réseau sur une interface loopback j'ai eu des résultats ... intéressant ... (7.5Gbps sur la machine, physique, 6,6Gbps sur une VM xen, et 700Mbps dans les bons moments) sans parler des tests réseaux inter VM et/ou mettant en oeuvre une machine externe
  • # Pour les petites entreprises !?!

    Posté par . Évalué à  3 .

    J'ai survolé le libre blanc et me suis attardé sur quelques points.

    Premièrement, et c'est à ne pas à oublier lors de la lecture de la suite du commentaire, c'est un très bon et important travaille. J'en conseille la lecture pour ceux qui veulent se familiariser avec la virtualisation et plus.
    Effectivement, comme certains le disent plus haut il y a toujours à redire. La virtualisation proposent plein de solutions et souvent compliquées. Chaqu'une à ses atouts. Normal de faire quelques erreurs.

    Ce qui m'a "choqué", c'est que le livre blanc est consacré aux "petites entreprises". Ce n'est pas "petites" qui me posse problème, c'est "entreprise".

    Une entreprise (la majorité en tout cas) va prendre une offre complète. Pas un programme/projet où elle doit patcher X ou Y pour que ça marche ni être obligé d'être abonné aux mailing list des développeurs (bien que ça ne soit pas une mauvaise idée).
    J'ai l'impression que le livre blanc avait un certain type de "petites entreprises" en tête.

    Quelles sont les offres ?
    Vmware, Xensource évidemment.
    Il doit aussi y avoir Novell (mais je ne me suis pas documenté).
    Il a aussi Red Hat qui en fait sa première priorité depuis 2 ans (ce qui devrait durer encore de nombreux mois).

    Le problème pour une majorité d'entreprises n'est pas Xen vs Qemu/KVM vs OpenVz. Le problème c'est l'offre (packaging, facilité d'utilisation, support, formation, applis certifiées pour l'environnement virtuelle, etc).
    Xen "nu" ou Qemu/KVM ou autre ne sont pas satisfaisant pour une entreprise (il y a toujours des exceptions pour confirmer la règle). Le livre blanc le dit.

    C'est sous cet angle que je pensais le livre blanc serait fait.

    Un exemple d'offre de virtualisation très intéressant et un peu particulier (Amazon EC2) :
    http://www.amazon.com/b/ref=sc_fe_l_2?ie=UTF8&node=20159(...)

    On peut choisir des images publics, en acheter, les stocker, les "instancier", etc. On peut choisir sa machine virtuelle parmis 3, on paie à l'heure, etc. On trouve des images spécialisées pour Alfresco, etc. Une boite c'est spécialisé dans le support EC2 : http://info.rightscale.com/
    Et qu'importe qu'EC2 utilise Xen ou KVM (pour info, c'est Xen actuellement).

    Il est claire que l'analyse de ses offres est très très compliqué.



    En passant, "Virtual Machine Manager" est virt-manager :
    http://www.virt-manager.org/
    Virt-manager n'est que la partie visible et qu'une application. Le plus important (du moins techniquement) est libvirt :
    http://www.libvirt.org/

    > Il est donc tout à fait envisageable à l’heure actuelle d’utiliser une architecture
    complète de virtualisation constituée uniquement de logiciels libres.

    Pub : http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/(...)
    C'est "une architecture complète de virtualisation constituée uniquement de logiciels libres" et ça utilise libvirt/virt-manager (pas seulement). Mieux, c'est supporté, il y a des formations, pleins de fournisseurs de logiciels (libre et proprio) qui certifient/supportent, etc...

    On n'est pas dans l'"envisageable". C'est du concrêt (sorti début 2007, grosse mise à jour vers novembre 2007).


    Quand à l'avenir de KVM et pour confirmer l'impression de l'auteur du libre blanc, il faut noter que Red Hat va "abandonner" Xen pour se consacrer quasi exclusivement à Qemu/KVM/paravirt_ops (c'est comme ça pour Fedora qui est la base de RHEL).
    Je pense que les solutions de cloisonnement ont aussi un bel avenir.



    Très bon document avec de très bonnes informations. La cible a été un peu ratée :-)
    Pour les solutions 100 % libre pouvant intéresser une majorité d'entreprise, ça se comprend facilement. L'offre est actuellement peu étoffée et manifestement peu visible (vu que le plus gros distributeur "entreprise" est passé inaperçu).
    C'est un domaine en pleine évolution qui méritera un nouveau livre blanc dans quelques mois. Une mise à jour de ce livre blanc ?
    • [^] # Re: Pour les petites entreprises !?!

      Posté par . Évalué à  2 .

      > J'ai survolé le libre blanc et me suis attardé sur quelques points.

      J'ai maintenant tout lu :-)

      > J'ai l'impression que le livre blanc avait un certain type de "petites entreprises" en tête.

      Du livre :
      Le chapitre suivant sera consacré à l’étude des besoins d’une PME spécialisée dans l’hébergement de sites web en matière de virtualisation.

      [...]

      Dans ce livre blanc, nous nous limiterons aux solutions de virtualisation utilisables pour une PME ayant comme principale activité l’hébergement d’applications Web.

      Bref, des entreprises très spécialisées. Pas pour toutes les petites entreprises comme je l'ai cru au début.


      Du livre :
      Gestion des images systèmes
      En ce qui concerne les images systèmes, QEMU se base sur des images disques complètes, avec son propre format de stockage (QCOW — QEMU Copy On Write).
      [...]
      Les images au format QCOW sont « creuses », c’est à dire qu’à la création du fichier, il n’occupe que quelques octets.

      Je crois que ce n'est pas un "format" Qemu. C'est seulement une fonctionnalité qu'on trouve dans vfs du noyau. En tout cas ext3 le supporte, c'est la fonctionnalité "sparse file". Les images Qemu sont "bêtement" des images sans rien de particulier.

      Exemple (utilisant un fichier "creu" créé par libvirt (et non qemu, mais peut être utilisé par qemu)) :
      [root@one ~]# ll system_test.img ; du system_test.img
      -rwxr-xr-x 1 root root 5242880001 jan 13 03:29 system_test.img
      20 system_test.img
      [root@one ~]# mke2fs -j system_test.img
      [...]
      [root@one ~]# mkdir mount_point
      [root@one ~]# mount -o loop system_test.img mount_point
      [root@one ~]# df mount_point/
      Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
      /root/system_test.img
      5039616 141216 4642400 3% /root/mount_point
      [root@one ~]# du system_test.img
      213392 system_test.img
      [root@one ~]# dd if=/dev/zero of=mount_point/zero bs=1M count=1000
      1000+0 enregistrements lus
      1000+0 enregistrements écrits
      1048576000 bytes (1,0 GB) copied, 7,31288 s, 143 MB/s
      [root@one ~]# du system_test.img
      1239160 system_test.img


      Notons bien que c'est spécifique au système de fichier. Si on copie le fichier sans prendre de précaution, il fera 5 Go (mais on peut le copier avec cp --sparse=... pour ne pas qu'il "grossisse", mais le système de fichier de destination doit supporter "sparse file").


      Du livre :
      L’attitude de la société XenSource vis à vis de la communauté est résumée par la phrase suivante, affichée de manière très visible sur leur site web :

      « XenSource is totally committed to the Xen community and the open source process. (XenSource est entièrement impliquée dans la communauté Xen et dans le processus open source.) »
      Ian P RATT, leader du projet Xen


      MMOOUUAAIIFFF...
      Heureusement qu'il n'y a pas Linux dans la phrase...

      En passant, Red Hat (qui n'est *jamais* cité parmis les contributeurs à la virtualisation dans ce livre blanc alors que lwn.net a démontré plus d'une fois que c'était le plus gros contributeur à linux...) en a marre d'avoir à toujours porter Xen sur les différentes versions de Linux et surtout marre que Xen refuse de prendre en compte ce boulot (XenSource reste à Linux 2.6.16) :
      http://berrange.com/personal/diary/2007/11/plan-for-xen-kern(...)
      Faut lire entre ligne :
      For a long time we ported their 2.6.16 tree to 2.6.18. Now we do ports of their 2.6.18 tree to 2.6.21/22/23, etc.
      [...]
      We simply cannot spend more time forward porting Xen kernels.


      Bien que Xen soit la meilleur solution actuelle, ça ne va pas empêcher Red Hat de s'en désengager car ce n'est plus tenable (Red Hat continura de maintenir/porter certaines parties de Xen pour compatibilité avec RHEL5 comme le sous-entend le lien précédent).

      Notons bien XenSource est toujours à la version 2.6.16 de Linux ! (ou alors ça a récemment changé).

      > Un autre aspect négatif du projet Xen est le fait qu’il est externe au projet Linux.

      Et ne fait pas grand chose pour se synchroniser avec Linux...
      Tout ceci peut être compréhensible depuis le rachat par Citrix qui va se concentrer sur Windows, l'embarqué, etc...
      A terme, au moins pour les serveurs ou machines de développement, Qemu/KVM va remplacer Xen sur Linux et ça ne semble pas déranger Citrix.

      Du livre :
      Une fonctionnalité complémentaire au mode snapshot est le mode overlay (surcouche). Avec ce mode de fonctionnement, très similaire au snapshot, les modifications apportées aux fichiers sont stockées dans un fichier supplémentaire, qui ne conserve donc que les éléments différents du fichier image original.

      C'est device-mapper/lvm2 qui fournit la fonctionnalité je crois. Donc on peut le faire avec n'importe quoi. Qemu doit le proposer, je n'ai pas vérifié.

      Du livre :
      Le projet KVM dispose quant à lui de bien moins de solutions de supervision. Il y a toutefois un projet qui mérite d’être mentionné : Virtual Machine Manager.


      Libvirt (qui fournit virsh, virt-manager étant une interface graphique au-dessus de libvirt) peut gérer Qemu/Kvm et Xen. Un support OpenVz a été réalisé récemment je crois. Notons que RHEL (ou Centos...) utilise libvirt au-dessus de Xen. Donc ce n'est pas spécifique à Qemu/KVM.
      • [^] # Re: Pour les petites entreprises !?!

        Posté par . Évalué à  3 .

        La définition de la « cible » n'était peut être pas explicite dès l'intro, c'est pas évident de s'en rendre compte quand on a le nez dedans :)

        Pour les fonctionnalités sparse et overlay, il faut en effet que le kernel le gère, mais je les mentionne parce que la page de man de Qemu en parle, et ça me semblait important de les mettre en avant.
        • [^] # Re: Pour les petites entreprises !?!

          Posté par . Évalué à  1 .

          > Pour les fonctionnalités sparse et overlay, il faut en effet que le kernel le gère

          Ils le gèrent quasiment tous aujourd'hui. Ça existe depuis si longtemps...

          > mais je les mentionne parce que la page de man de Qemu en parle, et ça me semblait important de les mettre en avant.

          Il semble que qemu a effectivement un format qui lui est propre (qcow2). Il est là pour les systèmes qui ne supportnt pas "sparse file" (typiquement Windows). Sous Linux, on n'en a pas besoin.
          • [^] # Re: Pour les petites entreprises !?!

            Posté par . Évalué à  1 .

            Ooops.
            Qemu a effectivement qcow et qcow2 comme format (qui ajoutent les fonctionnalités "compressés", cryptés, snapshot, etc et qui sont gérées par qemu). Mais comme j'ai toujours vu ça fait avec dm/lvm2, je n'avais pas imaginé que qemu avait un format spécifique.
            Sous Linux c'est d'un intérêt très limité, mais qemu en tourne pas que sous Linux.
      • [^] # Re: Pour les petites entreprises !?!

        Posté par (page perso) . Évalué à  1 .

        > Notons bien XenSource est toujours à la version 2.6.16 de Linux ! (ou alors ça a récemment changé).

        2.6.18 et depuis deja quelques temps.
        • [^] # Re: Pour les petites entreprises !?!

          Posté par . Évalué à  1 .

          Salut,

          2.6.20 pour ma part sous Gentoo/Linux 2007.0


          ServVirt1 ~ # uname -ar
          Linux ServVirt1 2.6.20-xen-r6 #12 SMP Fri Dec 14 11:09:56 CET 2007 x86_64 Intel(R) Xeon(R) CPU 5130 @ 2.00GHz GenuineIntel GNU/Linux


          @+,
          Guile.
          • [^] # Re: Pour les petites entreprises !?!

            Posté par (page perso) . Évalué à  2 .

            oui et non ;-)

            Le kernel "officiel" xen est un 2.6.18

            Par contre, certaines distributions telles que redhat, gentoo et surement d'autres "xenifient" elles-même leurs kernel.

            Je crois que c'est une des raisons (le fait de devoir tout le temps xenifier les nouveaux noyaux alors que xensource ne le fait pas) pour lesquelles Redhat souhaite abandonner xen.
          • [^] # Re: Pour les petites entreprises !?!

            Posté par . Évalué à  1 .

            > 2.6.20 pour ma part sous Gentoo/Linux 2007.0

            Pour info, 2.6.21 sous F8. Notons que le noyau sans Xen est un 2.6.23, que F8 va bientot passer à 2.6.24 et le noyau xen rester à 2.6.21. Bref, il y a un problème.
        • [^] # Re: Pour les petites entreprises !?!

          Posté par . Évalué à  1 .

          > 2.6.18 et depuis deja quelques temps.

          Et le 2.6.18 est sorti depuis bien longtemps. Et entre temps le 2.6.19, .20, .21, .22, .23 sont sortis...
          Bref, ça ne change pas grand chose au problème.
          Merci d'avoir corrigé mon commentaire.
          • [^] # Re: Pour les petites entreprises !?!

            Posté par (page perso) . Évalué à  3 .

            Comme je le soulignais, je voulais juste dire que le xen officiel est un 2.6.18.

            Comme precise plus haut, oui, depuis d'autres versions sont sorties et Xen serait gentil de patcher tout seul au lieu d'attendre que d'autres le fassent, on parle quand meme de leur projet. Je rejoins le coup de gueule de RedHat ici, faut pas prendre les libristes pour des cruches.
  • # Quelques imprécisions

    Posté par . Évalué à  4 .

    On peut notamment citer les applications trop vieilles pour s’exécuter sur la dernière génération du système d’exploitation (les anglophones parlent de legacy applications*).


    Dans ce cas, il est rare qu'un processeur récent soit bien exploité par un vieux système d'exploitation. Il est même possible que ce vieux système ne démarre pas. La virtualisation n'est plus possible, il faut émuler !

    Un autre domaine couvert par la virtualisation est l’utilisation de programmes non portés sur la plate-forme cible (architecture PC vs architecture Mac, par exemple).


    Là encore, il y a confusion car la note fait penser à Mac pour PowerPC. Dans ce cas la virtualisation ne fonctionne pas. C'est à nouveau de l'émulation.

    Je n'ai pas trouvé de mention (ok je n'ai pas encore tout lu) que la virtualisation devrait se limiter au partage des ressources CPU et mémoire du matériel mais qu'il vaut mieux éviter les gros accès disque - donc ne pas héberger un serveur de base de données très solicité sur une VM. Cela reste possible avec un SAN par fibre optique mais il faut tester au cas par cas.
    • [^] # Re: Quelques imprécisions

      Posté par . Évalué à  2 .

      Dans ce cas, il est rare qu'un processeur récent soit bien exploité par un vieux système d'exploitation. Il est même possible que ce vieux système ne démarre pas. La virtualisation n'est plus possible, il faut émuler !

      Je faisais principalement référence à de l'émulation pour ce cas de figure (typiquement, un QEMU qui fait tourner un Windows 95/98 sur une machine moderne).

      Pour moi, cela reste de la virtualisation (par le biais d'un émulateur), mais ce n'est clairement pas le même usage qu'un Xen, c'est clair.

      Je n'ai pas trouvé de mention (ok je n'ai pas encore tout lu) que la virtualisation devrait se limiter au partage des ressources CPU et mémoire du matériel mais qu'il vaut mieux éviter les gros accès disque - donc ne pas héberger un serveur de base de données très solicité sur une VM.

      C'est peut être pas dit aussi explicitement, je répète à plusieurs endroits que les E/S sont des opérations très coûteuses sur un système virtualisé.
  • # Merci !

    Posté par . Évalué à  4 .

    Merci Lucas pour ton travail !

    Je suis entrain de me plonger dans l'univers de la virtualisation pour des besoins de particulier (et non d'entreprise). Néanmoins je suis curieux et j'aime bien comprendre les choses.

    Jusqu'ici je n'avais jamais trouvé de document présentant une vue d'ensemble de toutes les technologies utilisées et des sociétés/communautés derrière.

    Très franchement je trouve ton travail remarquable. L'ensemble du document est hyper clair et rend accessible à des néophytes comme moi des concepts qui ne sont pas forcément évidents à appréhender.

    Quand j'aurais assez d'expérience en la matière je serais tenté d'écrire une autre partie à ton document : une étude des solutions de virtualisation pour les particuliers. Je parlerai bien de Virtualbox, Parrallels, Qemu (encore et toujours lui) et autre. Je parlerai bien aussi du support des périphériques vidéo et USB : le support matériel des périphériques (carte graphique, webcam, ipod ...) est assez important pour un particulier.

    Enfin d'ici là le monde de la virtualisation aura bien changé !

    Merci encore pour ce très bon travail et merci de l'avoir partagé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.