Journal La virtualisation en production

Posté par  (site web personnel) .
Étiquettes : aucune
10
13
fév.
2009
Bonjour à tous.

Au départ je pensais écrire dans le forum pour poser une question mais après réflexion j'ai pensé qu'il pouvait être intéressant de mettre cette ancienne question (maintenant réflexion) dans un journal.

Le but de ce journal est d'avoir des retours d'expériences et des témoignages sur des situations réelles et en productions de systèmes virtualisé via Xen ou tout autres solutions.

Le détail technique du fichier de configuration n'est pas forcement intéressant. Je pense qu'il faut voir cette solution dans son global et sur la méthode choisi pour l'intégrer à l'existant.

ATTENTION : je parle de virtualisation de serveur et non d'émulation de plusieurs os sur un poste utilisateur !

Quelques questions pour orienter le journal :
  • Nombres d'utilisateurs ?
  • Combien de DomU ?
  • Quelles fonctions des DomU ?
  • Combien de serveurs ont été remplacés par la virtualisation ?
  • Combien de serveurs utilisés pour la virtualisation ?
  • Méthode d'intégration à l'existant ?
  • Choix de la solution logiciel ?
  • Choix de la solution matériel ?
  • Est-ce stable en production ?
  • Délai d'étude et de mise en production ?

Bien sûr toute les questions ne sont pas obligatoires, mais je rappel qu'il ne sera pas question de trouver une réponse à un problème mais d'avoir une approche basé sur les expériences de chacun.

A vos clavier.
Philippe.
  • # plop

    Posté par  . Évalué à 6.

    Ca fait deux ans que je fais de la virtualisation en production et ce dans 3 environnements. 2 gros et un petit. Celui qui me plait le plus c'est le petit. D'une part parce qu'il est entièrement de ma responsabilité et d'autre part parce qu'il est exclusivement basé sur du LL.

    * Nombres d'utilisateurs ? 150 boites mails 20 domaines des blogs du web (dollibar principalement), environ 2Mbs de traffic en journée. Des applis en php ou en ruby pas de java.
    * Combien de DomU ? 24
    * Quelles fonctions des DomU ? imap smtp http jabber dns mysql
    * Combien de serveurs ont été remplacés par la virtualisation ? aucun
    * Combien de serveurs utilisés pour la virtualisation ? 2
    * Méthode d'intégration à l'existant ? aucune pas d'existant
    * Choix de la solution logiciel ? ubuntu server + xen puis kvm
    * Choix de la solution matériel ? la moins chere - core duo intel 2go RAM
    * Est-ce stable en production ? oui aucun soucis en 2ans
    * Délai d'étude et de mise en production ? pas longtemps

    le second environnement est plus consistant :

    * Nombres d'utilisateurs ? beaucoup je ne saurais dire combien. Le service rendu est utilisé par une grande majorité de fournisseurs de téléphonie mobile dans le monde
    * Combien de DomU ? 200+
    * Quelles fonctions des DomU ? Principalement des web services java
    * Combien de serveurs ont été remplacés par la virtualisation ? aucun
    * Combien de serveurs utilisés pour la virtualisation ? 20+
    * Méthode d'intégration à l'existant ? aucune pas d'existant
    * Choix de la solution logiciel ? VMware ESX + RH4
    * Choix de la solution matériel ? IBM xSeries. Je n'en pense que du mal vraiment. Dans cette gamme hp est bien mieux avec sa gamme DL.
    * Est-ce stable en production ? Apres quelques mois de rodage oui. Mais l'admin est très lourde et demande beaucoup de dev d'outils
    * Délai d'étude et de mise en production ? 6mois d'étude et 8 de mise en production.

    Le dernier environnement est un peu différent car pas très abordable. AIX sur pSeries. Alors la c'est la rolls .... des usines à gaz. Ca marche vraiment très bien y'a rien à dire. Mais par contre c'est tres cher et tres complexe à mettre en place. Pour un resultat identique à kvm ou xen. La seule chose kvm c'est simple :).

    Une derniere chose. KVM ne permet pas l'ajout de disque a chaud et c'est vraiment vraiment dommage.
    • [^] # Re: plop

      Posté par  (site web personnel) . Évalué à 1.

      Merci pour ton témoignage.

      Il me semble que KVM émule matériel, alors qu'avec Xen l'invité a directement accès aux matériels du serveur ce qui, toujours d'après ce que j'ai lu, permet d'avoir de meilleure performance.

      Born to Kill EndUser !

      • [^] # Re: plop

        Posté par  . Évalué à 2.

        je t'invite à lire la page de wikipedia sur le sujet (kvm et paravirtualisation). Avec virtio ce n'est plus le cas.
    • [^] # Re: plop

      Posté par  . Évalué à 6.

      Je ne peux pas laisser dire "Pour un resultat identique à kvm ou xen. La seule chose kvm c'est simple :).". Une solution VMWare ESX est plus complexe à intégrer et exploiter ?
      Il faudrait un peu élargir le débat. On parle de production avec des contraintes plus fortes pour :
      - Disponibilité
      - Exploitation
      - Support
      ....

      J'ai donc des questions ?
      Quelle est la solution pour exploiter un environnement virtualisé avec KVM ? Est-ce qu'il y'a un équivalent du VirtualCenter de VMWare ? Est-ce que les outils de sauvegarde (Legato NetWorker, Netbackup, NetVault, TimeNavigator,...) savent sauvegarder en natif des VM KVM (avec et sans interruption (système de snapshot) ) ? ...
      Au niveau du support, je ne vois pas chez Sun, IBM,.. un support KVM ? Je ne vois pas de support KVM/Linux au niveau des constructeurs de DataStorage (HDS, LSI, ...) ? Rien qu'au niveau de VMWare, j'ai un support sur le matériel. (y'a donc un support coté OS et coté constructeur) C'est tout de même ennuyeux.

      On ne peut pas dire "VMWare" c'est proprio/complexe, "KVM" c'est libre/simple.. Pour moi ça dépend vraiment des contraintes et du contexte de la production. Ce n'est pas si simple. On doit toujours répondre à des besoins.
      • [^] # Re: plop

        Posté par  . Évalué à 3.

        ok, il aime vmware, mais ce n'est pas une raison pour le inutiliser comme ça.

        Il pose de vrais questions
      • [^] # Re: plop

        Posté par  . Évalué à 3.

        KVM est trop récent pour avoir du support, certification, etc.
        Mais il y a un gros boulot sur KVM actuellement pour l'amener au niveau de Xen et évidemment le dépasser (sinon pourquoi passer à KVM).

        Qui fournit du support pour Xen ?
        - Xensource
        - Red Hat
        - Novell
        - etc

        Presque tout le monde en fait.
        Pour KVM rien ou presque. Mais comme Red Hat abandonne Xen, il faudra bien que Red Hat supporte KVM rapidement. Puis, ou en même temps, Novell, IBM, etc.
        Maintenant ce n'est presque qu'une question de temps.

        > On ne peut pas dire "VMWare" c'est proprio

        On peut le dire. VMWare est proprio.
        • [^] # Re: plop

          Posté par  . Évalué à 3.

          Je ne suis pas spécialement pro-vmware. J'utiliserais KVM quand je pourrais avoir des "garanties". (Pour de la production. Pour de la plate-forme test ou dev, cela ne pose pas de problèmes. Je l'utilise)

          Une problèmatique sur la solution KVM: C'est toujours assez complexe de gérer les disques FC sous Linux/KVM (RDAC, EMC Powerpath, multipathd,...).
          Si j'ai une interface graphique (ou une ligne de commande ou une API) et qu'il me suffit de faire "scan disk device" pour découvrir mes disques (LUN ID et/ou LDEV), ce serait du bonheur. (Bien sûr, le masking et le zoning est OK. Sinon ça ne va pas marcher)

          Il faudra donc du temps pour KVM. Au début, on n'imaginait pas utiliser VMWare pour de la production. J'espère que KVM suivra son chemin et répondra aux besoins d'une plate-forme de production (plate-forme avec toujours ce "foutu" existant ;) )

          Enfin, il faut garder une chose en tête, VMWare fait surtout son CA sur ses produits d'administration et non sur l'hyperviseur. Cela veut bien dire qu'il y'a vraiment un besoin au niveau de cette administration.
      • [^] # Re: plop

        Posté par  (site web personnel) . Évalué à 2.

        Je suis d'accord avec toi rhys. L'environnement de production a des contraintes plus complexe que nos petites plate-forme de test. Je suis ok pour le support aussi, mais je vois sur d'autres machines/logiciels j'ai du support que je paye une fortune et qui franchement très loin d'un bon rapport qualité/prix.

        Donc oui pour du support mais du genre, c'est pas notre logiciel c'est la faute à l'autres.

        Born to Kill EndUser !

        • [^] # Re: plop

          Posté par  . Évalué à 2.

          s/mais du genre/mais pas du genre/
      • [^] # Re: plop

        Posté par  . Évalué à 4.

        allez hop je me lance :

        Est-ce qu'il y'a un équivalent du VirtualCenter de VMWare ?

        => non et c'est très bien. Je suis contre les interfaces graphique n'importe quel incompétent peut toucher. Ca m'évite des nuits blanches derrières. (je me souviendrais toute ma vie de ma première install de linux en 96. Après des journées de travail enfin elle et installé. Je me loggue ... et là j'ai un curseur blanc qui clignote ... quoi faire ? :) Lire la doc.

        Est-ce que les outils de sauvegarde (Legato NetWorker, Netbackup, NetVault, TimeNavigator,...) savent sauvegarder en natif des VM KVM (avec et sans interruption (système de snapshot) ) ?

        => autant que n'importe quel linux installé sur une machine physique.

        Le support ...

        => ok ca rassure mon boss. Dans la réalité ? Une seule fois le support m'a sortie du caca dans lequel je m'étais mis. Ça a été au bout de 3 jours et beaucoup de parlote avec HP. Mais oui pour rassurer le client, le support c'est important. Redhat le fournira en Redhat 6.

        On doit toujours répondre à des besoins.

        => oui et comme le dit la page A3 sur la porte de mon bureau. Le client exprime le besoin, JE mets en place la solution qui va bien. Dans 99% des cas quand le client vient avec sa solution technique c'est n'importe quoi. Je viens de mettre en place Veritasfs .... Mon dieu au secours. Dire que gfs2 existe et en plus est dans la redhat ...

        On ne peut pas dire "VMWare" c'est proprio/complexe, "KVM" c'est libre/simple

        => si on peut le dire et je le dis. Je pense que 2ans de sueur sur le sujet me permet de le faire. Vmware pour un admin unix c'est complexe et vraiment pas souple. Il faut beaucoup trop travailler pour industrialiser vmware et ce sans garantie de pérennité. Avec kvm l'industrialisation est native et pérenne. Je parle bien sur de gros parcs qui grossissent vite.
  • # Université Rennes 2

    Posté par  . Évalué à 8.

    Bonjours, à l'université rennes nous nutilisons Xen depuis un bon moment déjà. La tendance est à la virtualisation maximale (1 service -> 1 serveur virtuel)

    * Nombres d'utilisateurs ?
    17500 étudiants et 1800 personnels environ
    * Combien de DomU ?
    Entre 50 et 60 DomU
    * Quelles fonctions des DomU ?
    Essentiellement des applis web, javad toute la chaine d'authentification cas, shibboleth, bientot ldap, ainsi que les base de données mysql et oracle
    * Combien de serveurs ont été remplacés par la virtualisation ?
    Peu a vrai dire, on a boosté nos vieux blades bl20p avec de la ram et on les a reliés à une baie NAS par fibre optique pour les disques (même les espaces disques sont virtuels).
    * Combien de serveurs utilisés pour la virtualisation ?
    20 Dom0 (environ hein) principalement des blades bl20p.
    * Méthode d'intégration à l'existant ?
    La plupart sont des nouveaux services, mais en général on fait de la bascule lors des moments creux (vacances scolaires)
    * Choix de la solution logiciel ?
    On a testé vserver et xen, l'utilisation de xen déjà intégré dans le kernel nous a convaincu.
    * Choix de la solution matériel ?
    On est resté dans la continuité de ce qu'on avait en privilégiant la ram, les liaisons fibres ainsi que les interfaces réseau (plusieurs vlan dont un pour le management)
    * Est-ce stable en production ?
    Quelques probleme au démarrage de nouveau serveurs mais très stable pour ceux en exploit
    * Délai d'étude et de mise en production ?
    Je ne m'en souvient pas vraiment Mais l'étude a été très rapide pour nous convaincre. Et la mise en prod a été très progressive et nous continuons encore.
  • # Xen

    Posté par  (site web personnel) . Évalué à 4.

    Je bosse au Cemagref de Clermont-Ferrand, nous avons un serveur Xen qui a 7 Dom-U. Principalement des services web : une passerelle SSH, un serveur trac, deux serveurs jboss, des serveurs web divers sur apache+sgbd, et un serveur qui assure le backup avec le contrôleur de sauvegarde qui est sous windows.
    Ce premier serveur a été mis en place il y a un an. Il n'y a pas forcément beaucoup d'utilisateurs (en tout cas pas en même temps), mais j'en suis très content.
    J'attends un nouveau serveur plus costaud (miam) pour ajouter d'autres services. On a opté pour un quadri-pro six-cores, 150Go de RAM avec des disques SAS 15000 tpm en raid5.

    Au centre de Lyon, les collégues qui nous assiste ici ont généralisé, ont toute leur parc serveur sur Xen, pour 200 utilisateurs. Il y a quelques infos sur la configuration là : http://www.cemagref.fr/Informations/MobiliteConcours/Mobilit(...)

    En résumé, Raid 5 (matériel) + LVM + Debian + Xen, c'est sans soucis, c'est vraiment génial :-)
  • # Conteneurs

    Posté par  . Évalué à 4.

    Comme je l'avais écrit dans un nourjal, je suis sous OpenVZ et VServer.

    * Nombres d'utilisateurs ?

    Très peu : c'est pour chez moi... outre l'accès à quelques fichiers via le conteneur SFTP, il n'y a pour ainsi dire que moi...


    * Combien de DomU ?

    "Conteneurs"... :p ... sinon, entre 20 et 30 (pour l'instant... mes plans de scientifique fou en prévoient entre 50 et 60).


    * Quelles fonctions des DomU ?

    Un service, un conteneur (sauf pour des trucs comme le MySQL de MythTV ou celui de SqueezeCenter, qui sont posés dans le même conteneur que l'appli qui les utilise)... en vrac, SMTP-auth, IMAPS, SFTP, MlDonkey, Tor, CUPS, SANE, NFS, NUT, MythTV, SqueezeCenter, DNS, CFEngine, LDAP (en cours), et j'en passe une bonne racée... plein, plein, plein de choses.


    * Combien de serveurs ont été remplacés par la virtualisation ?
    * Combien de serveurs utilisés pour la virtualisation ?

    Aucun... ou tous... au choix. Avant, je chrootais à la mimine tout ce qui était destiné à être accessible en public, sur une machine, et je laissais le reste sous une même arborescence, sur une autre machine... c'était chiant, et sale.

    Maintenant, mes deux serveurs sont devenus des routeurs/étagères à conteneurs... et c'est merveilleux.


    * Méthode d'intégration à l'existant ?

    Test dans un Qemu/Virtualbox, puis, basculage sauvage avec réinstallation (je ne suis sous Linux "que" depuis ~5 ans... aussi, avant mon utilisation des conteneurs, mes serveurs souffraient d'erreurs de ma jeunesse sur la banquise - j'en profite pour repartir sur des bases saines).


    * Choix de la solution logiciel ?

    OpenVZ/Vserver, comme je l'ai dit. J'ai tendance à préférer OpenVZ (plus drastique sur la gestion du matos, je préfère la syntaxe de "vzctl" que celle de "vserver", routage plutôt que des "liens" IP).

    Toujours pas eu le courage de basculer le VServer vers OpenVZ... peut-être après la sortie de Lenny :D


    * Choix de la solution matériel ?

    C'est ça, qui est bien : de vieilles babasses, à base d'Athlon XP (2Gio et 3Gio de RAM... et j'ai moult marge). Pas d'instruction de virtualisation, pas de RAM bouffée par plein de noyals, accès très simple au périphs (deux imprimantes, un scanner, quatre cartes DVB-T) : nickel.


    * Est-ce stable en production ?

    Très (pour OpenVZ, il y a eu des problèmes il y a quelques mois ; pas directement à cause du patch OpenVZ, mais plutôt à cause de Linux Vanilla - ce que le patch OpenVZ mettait en évidence en hardlockant la machine - mais bon, c'est réglé depuis un moment, et puis, Lenny ne sort officiellement que demain, a priori).


    * Délai d'étude et de mise en production ?

    Vu que c'est pour chez moi (pas spécialement de lien à l'informatique dans mon boulot : en ce moment, je gratte même tellement d'équations sur le papier que je ne prends même pas le temps d'allumer l'ordi au boulot), à mon rythme.

    Mais c'est quand même 'achement accessible.


    Bref : vivent les conteneurs (aussi) !
    • [^] # Re: Conteneurs

      Posté par  . Évalué à 2.

      Question de gros néophyte (bon j'ai l'article de wikipedia sous les yeux, mais c'est bien de causer un peu) :

      Est-ce qu'on peut dire qu'OpenVZ est la solution la plus économe en terme de consommation ressources (et donc d'énergie ?).

      Je voudrais me refaire une machine plus économe/écolo, mais suffisamment puissante pour m'héberger des vm (qui seraient très souvent en idle, voir même une majorité éteintes puisque pour tests).
      • [^] # Re: Conteneurs

        Posté par  (site web personnel) . Évalué à 4.

        Il est possible que je me trompe mais OpenVZ n'est pas une machine virtuelle a proprement parlé. En fait tu tourne sur le même kernel que la machine hôte et dont tu as aucune perte en terme de performance.

        En gros c'est comme si tu dupliquais ton système dans un répertoire et que ça devenait une nouvelle machine vu de l'extérieur. De l'interrieur cette machine n'a accès qu'a elle même malgré que le kernel soit le même donc les même avantage qu'une machine virtuel de ce point de vu là. Après tu peux avoir un compte root différent pour chaque instance (pratique pour de l'hébergement) et il me semble que l'on peut depuis la machine principal, déployer un logiciel sur une ou plusieurs instance et une instance peut installer des logiciels de manière autonome.
        • [^] # Re: Conteneurs

          Posté par  . Évalué à 5.

          En effet, le principe des conteneurs (jail BSD, OpenVZ, VServer) est d'avoir des sortes de super-chroots, qui utilisent tous le même kernel (en fait, ils n'ont pas accès à toutes les fonctions de celui-ci : par exemple, pour accéder à des périphs ou à l'interface réseau de l'hôte, il faut leur donner accès à des capacités spéciales du kernel), tout en étant isolés les uns des autres.

          Après, est-ce que c'est moins consommateur d'énergie ? Je ne sais pas : peut-être un peu moins, vu que les instructions de virtualisation ne sont pas sollicitées. Mais à mon avis, l'avantage est surtout en ce que, n'ayant pas besoin de ces instructions, peu ou prou n'importe quel proc (x86 ou AMD64 - ça reste des patchs maintenus en dehors de Vanilla, même si, aussi bien pour VServer qu'OpenVZ, il y a pas mal de contribution au kernel de base, pour en venir un jour à supporter les conteneurs nativement) peut faire l'affaire, pourvu qu'il y ait assez de RAM sur la bête (en modifiant un poil le debootstrap de base, ie en n'utilisant syslog-ng au lieu de rsyslog, j'arrive à faire tourner des VM qui n'allouent pas plus de 5Mio de RAM... évidemment, ça gonfle selon les services utilisés).

          Après, il y a sans doute un peu d'overhead, dû à la séparation, mais, c'est peu ou prou invisible, même sur mes vieilles machines.

          Sinon, pour l'installation des softs, je me méfie comme la peste du contrôle de la VM directement à partir du shell de l'hôte (il peut y avoir des problèmes d'inaccessibilité des VT et cie... et c'est très chiant)... Par contre, une fois dans le conteneur (par SSH, par exemple, ou, sous OpenVZ, en faisant "vzctl enter ID_DE_LA_MACHINE, ce qui lance un sous-shell de l'invité sur l'hôte), pas de problème : au /dev (atrophié et statique : ce que je trouve très bien), et aux capacités du noyau près (ce qui inclue le réseau, sauf si, sous OpenVZ, on donne accès à la conf réseau en utilisant une interface virtuelle plus avancée), ça fonctionne exactement comme une machine courante. L'un de mes conteneurs est d'ailleurs un approx qui sert de cache/miroir deb local à toutes mes machines (oui, je suis très Debian) - on installe ce qu'on veut, il y a un init tout ce qu'il y a de plus classique, ... c'est transparent.
          • [^] # Re: Conteneurs

            Posté par  . Évalué à 2.

            Est-ce que l'approche « un serveur par service » n'est pas un peu lourde à administrer ? Par exemple pour faire un serveur LAMP cela veut dire un serveur pour Apache et un autre pour MySQL. Quand il y a une mise à jour il faut se farcir le SSH sur tous les serveurs pour appliquer cette mise à jour ? Ou alors ai-je raté quelque principe important de la virtualisation ?
            • [^] # Re: Conteneurs

              Posté par  . Évalué à 3.

              > Est-ce que l'approche « un serveur par service » n'est pas un peu lourde à administrer ?

              Oui, et non : d'un côté, si je mets, par exemple, MythTV et SqueezeCenter sur la même "machine", ils vont se partager MySQL, et il y aura plus de risques que tout tombe si l'un des deux borke la base de données... Trop de bordel, ce n'est pas forcément souhaitable...

              ... après, certes, au final, ça multiplie pas mal le nombre de machines, et donc, ça multiplie la charge d'administration.

              D'ailleurs, en ce moment, je suis en train de rationaliser tout ça, en me servant de CFEngine : idéalement, j'aimerais stocker les classes et des variables dans un LDAP, pour tout éditer à partir d'une même interface. Pour les mises à jours, je suis aussi en train de trifouiller des scripts qui font une simulation d'un "aptitude full-upgrade", qui m'envoient le résultat par mail (chiffré), auquel je réponds par un autre, signé - si la signature est bonne, le full-upgrade se fait sans mon intervention (ça marche pas mal, mais c'est encore un peu rugueux).

              Après, ça dépend de ce qu'on veut faire : pour MythTV et SqueezeCenter, comme je le disais, ils ont chacun leur MySQL... Pour OpenLDAP, je compte juste en avoir un que j'édite, plus un autre en esclave (je ne suis pas chaud du tout pour mettre un annuaire, même partiel, dans chaque conteneur qui en aura besoin - même si, a mon grand dam, je n'arrive pas à trouver de serveur DNS qui va chercher ses infos dans LDAP, et qui me satisfasse : PowerDNS n'accepte l'authentification à l'annuaire que par mot de passe, et DLZ-Bind, même s'il accepte Kerberos, que je n'aime pas tellement, ne gère pas l'authentification sur un certificat - j'en suis donc à me dire que le plus propre serait peut-être d'avoir une réplique partielle de mon annuaire, juste pour les noms d'hôtes, dans un conteneur, avec DLZ-Bind)...

              Cela dit, les possibilités offertes sont telles que c'est justement l'occasion d'organiser son réseau comme on le souhaite. Tout dépend des compromis que l'on cherche...
            • [^] # Re: Conteneurs

              Posté par  . Évalué à 4.

              Il faut comprendre "service" dans le sens "service rendu aux utilisateurs".
              Par exemple:
              - Wiki = 1 serveur LAMP dans une machine virtuelle (VM)
              - messagerie = une VM avec Postfix, Cyrus, SpamAssassin,....
              - Webmail = une autre VM avec LAMP et Horde
              - ...
    • [^] # Re: Conteneurs

      Posté par  . Évalué à 4.

      J'utilise aussi vserver, mes besoins sont quasi nuls donc je n'en parlerais pas ici (pas tres pertinent). Par contre, il est clair que si ces solutions sont moins hype que xen ou kvm, elles sont pas pour autant a négliger (pour peu que ton dsi ne lise pas 01net!)

      Je m'explique:
      - Vserver ou équivalent existait bien avant xen, dans le genre éprouvé tu auras pas mieux.

      - Au niveau de la consommation de ressource et de l overhead, c'est aussi très intéréssant pour la bonne raison que tu ne relance pas de nouveau noyau dont les IO ne seront pas natives (passant par le noyau hête): Avec Xen tu peux vite te retrouver a traverser 10 couches quand tu n'en traverse qu'une ou 2 en temps normal.

      - Les vservers et openvz sont aussi tres proches d'unix, dans le sens ou c'est un chroot++, mais aussi que tu peux regler tes priorités a coup de nice ou ulimit.

      - Enfin, vserver (openvz) intègre de petites fonctions simpas pour économiser un peu de disque et de ram. Par exemple, tu as un système qui remplace les fichiers de tes ververs par des liens en dur. Du cout, le syslogd (c'est un exemple) n'est chargé qu'une seule fois en ram.

      En conclusion, vserver est vraiment bien, et si le but est d'avoir quelque chose d'économe c'est vraiment une solution à ne pas négliger. Cela ne colle pas à tout les besoins (parfois avoir un noyau que le responsable du domU puisse bricoler est bien), c'est bien moins fashion que Xen mais je ne saurais que trop t'encourager à regarder.

      Sinon, pourquoi diantre, passer de vserver à openvz (c est une vrai question) ?
      • [^] # Re: Conteneurs

        Posté par  . Évalué à 2.

        > Sinon, pourquoi diantre, passer de vserver à openvz

        Comme je l'ai dit, je préfère la manière de gérer le réseau à-la-OpenVZ... Je suis aussi sous VServer depuis Etch, et je n'ai pas trop aimé le fait qu'il n'y ait techniquement pas de loopback dans celui(ci (même si on m'a dit qu'il y était dans la version plus récente de Lenny).

        Il y aussi la gestion plus rigoureuse des ressources (pas moyen d'espérer faire tourner OpenVZ en spécifiant globalement plus de ressources qu'il n'y en a dans la machine - il faut faire ça avec un strict minimum d'application) : du coup, ça force à être rigoureux, ce que j'aime bien.

        Mais malgré tout, je ne dis pas que VServer est mauvais, bien au contraire : les deux sont très bien, et VServer est sans aucun doute plus éprouvé et utilisé qu'OpenVZ ;)
        • [^] # Re: Conteneurs

          Posté par  . Évalué à 3.

          Pour le réseau, il est vrai que l'absence de loopback est assez désagréable au début.

          Avec le temps on trouve rapidement les petites bidouilles pour le contourner,
          comme utiliser une interface dummy à cet effet ou modifier le /etc/hosts
          (faire pointer localhost sur 192.169.0.X)

          Effectivement, les versions récentes de vserver offrent bien une interface loopback pour
          les vserver


          Pour les ressources, il y a bien des manières de les limiter la plupart sont un peu permissives, c'est d'ailleurs souhaité (par exemple pour la ram). Etant moins strict tu es plus souple, tu laisse le systeme distribuer au mieux.

          Si tu veux une limitation hard tu peux utiliser cpuset pour dedier un cpu + x MO de ram a un processur ou a un vserver precis

          En passant il y a t-il d'autres trucs que tu apprécies dans openvz et qui ne sont pas dans vserver ?
          • [^] # Re: Conteneurs

            Posté par  . Évalué à 3.

            > faire pointer localhost sur 192.169.0.X

            C'est ce que je faisais ;)


            > En passant il y a t-il d'autres trucs que tu apprécies dans openvz et qui ne sont pas dans vserver ?

            Au niveau de la configuration réseau, OpenVZ est très puissant : soit on laisse l'hôte gérer le réseau des VM en leur donnant un périph virtuel venet (~analogue à VServer)...

            ... soit on donne à la VM une interface réseau plus avancée (veth), permettant de lui déléguer la conf réseau (conf classique, iptables, routes, ...).

            J'avoue ne pas avoir cherché plus loin que ça si c'était possible dans VServer, cela dit.

            Il y a aussi que le partage de périphs entre l'hôte et la VM se fait dans le fichier de conf, plutôt qu'en faisant un "cp -a" de ce qu'il y a dans le "/dev" : je trouve ça plus propre (même s'il peut y avoir des problèmes avec udev, comme avec mon imprimante laser et mon scanner qui ont besoin de charger un firmware - m'enfin, ça se règle avec de petits scripts udev sur l'hôte, et c'est la même chose, que ce soit avec VServer ou OpenVZ).

            Par contre, niveau doc, OpenVZ poutre vraiment bien : le manuel officiel est un gros PDF bien touffu, et plutôt exhaustif.

            À côté, la "flower page" et le wiki de VServer sont plutôt légers, m'est avis... et ça pèse pas mal dans la balance, en ce qui me concerne.

            Si ça t'intéresse, voilà le lien vers le journal que j'avais fait : http://linuxfr.org/~Aefron/27379.html ... même si c'est long, ça n'a pas pour but d'être exhaustif, mais juste d'être un retour d'expérience (et une anti-sèche occasionnelle :p), de la part d'un non-professionnel.



            Cela dit, je le répète, j'utilise VServer depuis ~1,5 ans, et même si j'ai une petite préférence pour OpenVZ, les deux sont vraiment très bien ;)

            D'ailleurs, vu la jeunesse d'OpenVZ sous Debian (ma distro préférée), si je devais en choisir un pour quelque chose de vraiment sérieux, ce serait probablement VServer.

            Quoi qu'il en soit, pour moi qui n'ai d'instructions de virtualisation que sur mes desktops (mes serveurs sont mes vieux desktops d'il y a pas mal d'années ; et j'espère qu'ils continueront à me servir encore plein de temps), les conteneurs sont une solution bien plus praticable que la virtualisation complète, forme de solution que je pense continuer à utiliser, même quand il faudra changer les serveurs : et pour ça, je suis reconnaissant aussi bien envers une solution que l'autre.
      • [^] # Re: Conteneurs

        Posté par  (site web personnel) . Évalué à 2.

        vserver est intéressant mais par exemple si j'ai besoin d'une config kernel particulière sur une machine virtuelle et d'une autre config sur une autre machine virtuelle, ça coince :( Je te l'accorde c'est un cas extrême que je doute rencontrer dans ma salle mais je préfère prévoir le pire.

        Born to Kill EndUser !

        • [^] # Re: Conteneurs

          Posté par  . Évalué à 1.

          Tout dépend de ce que tu entends pas une config particulière:

          J'ai vu des admins dire que mysql ne marchaient bien qu'avec un noyau un peu optimisé,j'avoue que j'y crois moyennement. Mais peut être que dans certains cas très rares cela se justifie.

          Par contre vserver possède une commande nommée vsysctl, je te laisse deviner à quoi cela peut bien servir ;)

          Bref, si le problème que tu soulève n'est pas à négliger , je ne suis pas sûr qu'il soit si important. Il est vrai par contre que tu trouveras parfois de gros déploiements de vserver
          avec a coté une ou deux machines xen pour répondre a ces besoins bien spécifiques mais nécessairement plus couteux (temps/ressources/matériel...).
  • # Presque rien à voir

    Posté par  . Évalué à 3.

    Presque rien à voir pour moi par rapport aux commentaires précédents. Mes besoins sont faibles.
    J'utilise la virtualisation pour le développement. Pour la production c'est "remonté" sur EC2 d'Amazon. Une CentOS et une Fedora actuellement.
    Par contre, je ne fais pas une machine virtuelle par service. Si tout tient sur un serveur et que c'est cohérent, je n'utilise qu'un serveur. Sur un serveur il peut y avoir (et il y a) web, base de donnée, DNS, mail, etc. Nb: SeLinux est activé sur mes machines virtuelles ce qui limite les risques lorsqu'on a plusieurs services sur une même machine. Les backups sont sur S3 d'amazon (qui offre une (haute) garantit de service ; idem pour EC2 depuis quelques semaines).
    Notons que sur EC2 on paye par machine virtuelle. C'est aussi pour ça que je ne multiple pas les machines virtuelles. La creation d'une machine virtuelle plus la restauration des données se fait en 1 heure environ. On a donc une très bonne disponibilité. Si un serveur plante (à cause des disques ; nb: on peut faire du raid) l'indisponibilité n'est que d'une heure.
    L'intérêt :
    - souplesse (on peut créer autant de machines qu'on veut dans la minute)
    - la puissance de calcul fournie n'est pas partagée (donc le service n'est pas ralentit par d'autres machines virtuelles).
    - l'administration. On peut presque dire qu'il n'y en a pas. Pas besoin d'acheter un serveur, des disques, de trouver de la place, de s'occuper du réseau, etc.

    Je ne dis pas que c'est mieux, mais c'est une autre approche qui a ses atouts. En fait ici on se fout de la virtualisation :-) On a un service.
    Pour info, EC2 utilise Xen.

    S'il faut chercher un point faible, c'est l'installation de l'OS. En effet, on ne peut pas installer l'OS sur EC2. C'est un petit problème. Je l'installe sur une machine virtuelle de ma bécane de développement puis je remonte sur EC2.

    EC2 est beaucoup utilisé en cluster (montée en charge) et c'est surtout son domaine d'utilisation.
  • # Nombreux sites

    Posté par  . Évalué à 4.

    Chez nous c'est une trentaine de serveurs physiques répartis sur une trentaine de sites. Les besoins par site sont très faibles, par conséquent les machines sont surdimensionnées: pour 700 € on a un double coeur avec 4 Go de mémoire, du RAID 1 + sauvegarde, le tout dans un boîtier très solide, très ventilé et relativement silencieux (nos sites sont bien cracra, non climatisés et le matériel informatique commun sert parfois d'étagère ou de cale-porte pour donner une idée de l'ambiance). Faire moins puissant économiserait peut-être 100 €, aucun intérêt car ça bloque toute possibilité d'évolution des besoins (ou alors il faut se déplacer, coût bien plus élevé).

    * Nombres d'utilisateurs ?
    Entre 2 et 100 par serveur.

    * Combien de DomU ?
    1 ou 2 par serveur.
    Nos machines supportent beaucoup plus mais un site n'a besoin que d'une ou deux machines virtuelles, donc c'est limité par le besoin.

    * Quelles fonctions des DomU ?
    Erh... serveurs Windows :-)
    A noter qu'un serveur Windows "bare metal" fonctionne moins vite que le même sous vmware.

    * Combien de serveurs ont été remplacés par la virtualisation ?
    Quelques uns arrivant en fin de vie. Le but n'était pas de diminuer le nombre de serveurs (puisqu'il y en a un par site, on ne peut pas faire moins).

    * Combien de serveurs utilisés pour la virtualisation ?
    Dito.

    * Méthode d'intégration à l'existant ?
    Tournevis, patience.

    * Choix de la solution logiciel ?
    Debian Etch + vmware + logiciels maison

    * Choix de la solution matériel ?
    Machines assemblées de chez pas cher point com.

    * Est-ce stable en production ?
    Excepté les inévitables problèmes matériels/électriques/réseau, nous n'avons *jamais* eu de problème.
    2 problèmes de mémoire, 1 problème de carte-mère, 2 problèmes de disques sur 18 mois. Nos serveurs HP très chers et pas plus puissants tombent en pannes aussi souvent... mais ils ne sont que 2. Ils sont partis à la poubelle il y a 2 semaines (remplacés par une seule machine, moins puissante, Debian Etch + vmware + 2xWindows).

    * Délai d'étude et de mise en production ?
    Etude: environ 2 mois (tests Xen->poubelle, puis tests très intensifs vmware).
    Mise en prod d'un nouveau serveur: une fois que la machine physique est branchée, environ 40 minutes. Plus 2 ou 3 heures réparties dans les semaines suivantes pour garder un oeil sur le fonctionnement (sauvegardes, charge, etc).
    • [^] # Re: Nombreux sites

      Posté par  . Évalué à 2.

      Pourquoi Xen->poubelle ? (c'est une vraie question, pas un début de troll).
      • [^] # Re: Nombreux sites

        Posté par  . Évalué à 2.

        Nous faisons fonctionner du Windows virtualisé. Xen plante plantait en quelques secondes lors des transferts disques et réseau un peu soutenus.

        Le forum officiel de Xen n'a été d'aucune aide (allant de RTFM sans explication à "ain't for Windows"). Google n'a rien donné.
        C'était il y a 18 mois environ.
  • # retour sur 3 ans

    Posté par  . Évalué à 1.

    * Nombres d'utilisateurs ?
    40 utilisateurs

    * Combien de DomU ?
    2 domU

    * Quelles fonctions des DomU ?

    - 1 redhat RHEL3, puis migration en 4 (BDD + JAVA)
    - 1 Windows TSE 40 users


    * Combien de serveurs ont été remplacés par la virtualisation ?
    1

    * Combien de serveurs utilisés pour la virtualisation ?

    2 , le but etant de faire de la Haute disponibilté avec HeartBeat + vmware


    * Méthode d'intégration à l'existant ?
    client lourds + serveur lourds -> clients legers + serveur virtualisé

    * Choix de la solution logiciel ?
    vmware (c'était il y a 3 ans)


    * Choix de la solution matériel ?
    serveurs assemblés, pas de pannes sur 3 ans


    * Est-ce stable en production ?
    des ralentissements la première années du a la jeunesse de Windows 2003 + vmware


    * Délai d'étude et de mise en production ?
    2 mois

Suivre le flux des commentaires

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