Bof

• [^]Re: Bof

  Posté par Antoine () le 12/01/2008 à 15:02. (lien). É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 Éric JACQUOT (Jabber id, page perso, ) le 12/01/2008 à 15:08. (lien). É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 GnunuX (Jabber id, page perso, ) le 12/01/2008 à 15:26. (lien). É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 Éric JACQUOT (Jabber id, page perso, ) le 12/01/2008 à 15:45. (lien). É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 benoar (Jabber id, ) le 15/01/2008 à 16:21. (lien). É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 Éric JACQUOT (Jabber id, page perso, ) le 20/01/2008 à 15:19. (lien). É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 briaeros007 () le 20/01/2008 à 23:01. (lien). É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?

            --
            Subete ga wakatta toki…watashi ga anta wo korosu.

    • [^]Re: Bof

      Posté par vieuxshell () le 14/01/2008 à 14:40. (lien). É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 Guillaume Smet (page perso, ) le 12/01/2008 à 15:35. (lien). É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 Éric JACQUOT (Jabber id, page perso, ) le 12/01/2008 à 15:52. (lien). É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 Guillaume Smet (page perso, ) le 12/01/2008 à 15:59. (lien). É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 Éric JACQUOT (Jabber id, page perso, ) le 12/01/2008 à 16:12. (lien). É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 Thomas Douillard () le 13/01/2008 à 18:59. (lien). É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 Éric JACQUOT (Jabber id, page perso, ) le 20/01/2008 à 15:26. (lien). É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 Thomas Douillard () le 20/01/2008 à 16:14. (lien). É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 Éric JACQUOT (Jabber id, page perso, ) le 20/01/2008 à 16:36. (lien). É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 IsNotGood () le 13/01/2008 à 01:35. (lien). É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 tuiu pol (Jabber id, ) le 13/01/2008 à 11:37. (lien). É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 Antoine () le 13/01/2008 à 13:06. (lien). É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 IsNotGood () le 13/01/2008 à 13:22. (lien). É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 Antoine () le 13/01/2008 à 15:21. (lien). É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 IsNotGood () le 14/01/2008 à 10:32. (lien). É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 Antoine () le 14/01/2008 à 13:28. (lien). É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 tuiu pol (Jabber id, ) le 14/01/2008 à 11:45. (lien). É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 Stéphane Davy () le 14/01/2008 à 15:57. (lien). É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 Gniarf () le 13/01/2008 à 15:21. (lien). É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.

    --
    Windows has no users. It has hostages.

  • [+] [^]Re: Bof

    Posté par rcmn () le 14/01/2008 à 17:00. (lien). É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 Éric JACQUOT (Jabber id, page perso, ) le 20/01/2008 à 15:36. (lien). É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 Guillaume Smet (page perso, ) le 12/01/2008 à 15:19. (lien). É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 Lucas Bonnet () le 12/01/2008 à 15:53. (lien). É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 Lucas Bonnet () le 12/01/2008 à 15:49. (lien). É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 Guillaume Smet (page perso, ) le 12/01/2008 à 16:04. (lien). É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 Lucas Bonnet () le 12/01/2008 à 18:13. (lien). É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 -=[ Benoit Plessis ]=- (page perso, ) le 15/01/2008 à 00:46. (lien). É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

    --
    Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libr

Pour les petites entreprises !?!

• [^]Re: Pour les petites entreprises !?!

  Posté par IsNotGood () le 13/01/2008 à 05:07. (lien). É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 Lucas Bonnet () le 13/01/2008 à 10:58. (lien). É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 IsNotGood () le 13/01/2008 à 11:25. (lien). É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 IsNotGood () le 13/01/2008 à 11:31. (lien). É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 FRLinux (page perso, ) le 14/01/2008 à 00:53. (lien). É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 xguardian () le 14/01/2008 à 09:01. (lien). É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 CrEv (page perso, ) le 14/01/2008 à 09:07. (lien). É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 IsNotGood () le 14/01/2008 à 10:34. (lien). É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 IsNotGood () le 14/01/2008 à 10:45. (lien). É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 FRLinux (page perso, ) le 14/01/2008 à 14:42. (lien). É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

• [^]Re: Quelques imprécisions

  Posté par Lucas Bonnet () le 14/01/2008 à 14:48. (lien). É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 !