Linux-VServer : Nouvelle version stable, nouveau site Web

Posté par (page perso) . Modéré par Nÿco.
0
6
sept.
2006
Noyau
Le 3 septembre 2006, le projet Linux-VServer a publié une nouvelle version stable de son patch noyau : la 2.0.2.

Elle apporte notamment le support des "Bind Mount Extensions"[1], une meilleure prise en charge du système de fichier JFS, une amélioration du "kernel helper"[2] et nombre d'autres petites améliorations. Cette nouvelle version corrige également beaucoup de bogues (Voir annonce complète et en anglais dans les liens ci-dessous).

Parallèlement, le projet a également annoncé le lancement d'un nouveau site web. Celui-ci est maintenant basé sur MediaWiki et son design a été entièrement refait. Il a remplacé l'ancien wiki le 5 septembre et la migration de la documentation est en cours d'achèvement . En outre, un FTP anonyme, des archives, un dépôt subversion et l'espace web des utilisateurs ont été ajoutés à l'infrastructure publique. Notes :

[1] Bind Mount Extensions : Ajout au noyau de code permettant de réaliser des "bind mounts" avec des options différentes du point de montage d'origine, par exemple "mount -o bind,ro ...". En d'autres termes, il est donc maintenant possible de passer des options "normales" à un "mount -o bind ".

[2] Kernel helper : Dispositif permettant de gérer en espace utilisateur des événements spécifiques à un contexte, sans devoir implémenter de gestion de politique de sécurité particulière dans le noyau. Cas d'école : La commande "reboot" (ou "halt") est tapée dans un système invité, on ne doit bien sûr rebooter que celui-ci, et pas le serveur hôte ni un autre invité. L'appel est donc intercepté par le noyau, redirigé en espace utilisateur vers Vshelper qui se charge des actions à entreprendre. C'est semblable au fonctionnement de Hotplug.

Qu'est-ce que Linux-VServer ?

Linux-VServer est une solution de virtualisation pour GNU/Linux. Contrairement à d'autres solutions, la séparation est ici accomplie par l'isolement au niveau du kernel; ainsi, les machines virtuelles (aussi appelées "contextes") partagent le même noyau, économisant les ressources tout en garantissant un niveau de sécurité élevé. Les processus virtualisés ont bel et bien l'impression de tourner dans leur propres machine réelle, et il est possible d'installer une distribution différente pour chaque système invité.

Gestion de "fermes" de vservers

Il existe quelques projets d'interfaces d'administration de vservers. Hasard du calendrier, le projet OpenVCP a publié, le 4 septembre, une release-candidate de la version 0.2.

OpenVCP (Open-Source VServer Control Panel) qui propose une interface web de gestion de ferme de vservers.

On peut, de celle-ci, construire (installer) et contrôler les serveurs virtuels, surveiller le trafic, etc... Cette dernière version corrige bien sûr quelques bugs et rajoute des fonctionnalités (gestion des utilisateurs/réseaux, support de TLS...)

Aller plus loin

  • # Gains par rapport a Xen/qemu/etc.

    Posté par . Évalué à 7.

    Excusez-moi pour la question qui peut paraitre stupide, mais qu'est-ce que cela apporte par rapport a une virtualisation "de la machine" ? (en dehors de l'aspect multiplateforme bien sûr; puisque je suppose que cette solution fonctionne parfaitement sur toute architecture supportant linux sans la lenteur d'un Bochs, troll outside).
    Y a-t-il par exemple partage "dynamique" de la mémoire ? Les performances sont meilleures ? Qu'en est-il des possibilités en matière de réseaux ? (je ne connais que le fonctionnement de vmware sur le sujet)
    De plus, comment les droits sont-ils gérés ? (je pense à des machines virtuelles dont on voudrait par exemple interdire l'accès à des disques ou ports)
    Cette news n'était sûrement pas le meilleur lieu pour poser ce genre de questions, mais au passage...
    • [^] # Re: Gains par rapport a Xen/qemu/etc.

      Posté par . Évalué à 9.

      Par rapport à une virtualisation de machine, il y est très peu d'overhead.
      Pour te donner un bonne exemple, j'arrive à installer une bonne dizaine de vserver en activité sur un portable P75 sans problème et sans encore latence.
      Après tout dépend de l'activité, mais jusqu'à maintenant, les performances sont au rendez-vous car l'interconnexion et l'activité au sein du kernel a été réduit à une idée simple: le context_id.
      Chaque process/file/handler possède un ctx_id qui (le) spécifie dans un monde parralèle.
      Le main possède le ctx_id 0 et les autres, comme tu veux (ID random ou fixe)
      La gestion de ce ctx_id ne demande presque rien au kenrel et apporte beaucoup en terme de perf et d'évolution future.
      Je résume à mort, bien entendu.
      Après, il y a aussi les features que je te laisse le soin d'appréhender.
      En tout cas, c'est un beau projet je trouve, et la coreteam est toujours dispo pour aider voire débugger si besoin ait. (notamment bertl :)
      • [^] # Re: Gains par rapport a Xen/qemu/etc.

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

        D'après ce que j'ai compris, c'est plutôt le contraire : c'est la virtualisation de machine qui présente de l'overhead sur cette solution, vu que tous les process isolés les uns des autres tournent sur le même noyau.
        • [^] # Re: Gains par rapport a Xen/qemu/etc.

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

          La phrase est ambiguë, mais c'est bien ce qu'il voulait dire.

          « Par rapport à la virtualisation de la machine, c'est mieux parce qu'il y a très peu d'overhead avec vserver »

          ;-)
          • [^] # Re: Gains par rapport a Xen/qemu/etc.

            Posté par . Évalué à 4.

            La phrase est ambiguë en effet, c'est bien cela que je voulais dire ;-)
            Il fallait lire (entre les fautes de syntaxe et d'orthographe) :

            "Par rapport à une virtualisation de machine, [vserver ajoute] très peu d'overhead."
    • [^] # Re: Gains par rapport a Xen/qemu/etc.

      Posté par . Évalué à 4.

      Ah oui, dernière précision, au dernière nouvelle (et sauf si Pascal a pas pété un cable ce week-end et tout réinstallé)
      LinuxFr est sous Vserver ;-)
  • # Bind mount extensions

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

    Pour saurait pas à quoi ça sert (comme moi il y a 5 minutes) :

    Bind est un paramètre permettant le montage d’un répertoire (y compris sur une autre partition) sur un répertoire de l’arborescence.

    cf http://wiki.alionet.org/doku.php?id=partitionnementsimple

    Voilà, parcequ'à moi, ça ne me disait rien du tout...
    Merci pour cette dépêche forte interressante

    Benjamin
    • [^] # Re: Bind mount extensions

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

      Bind est un paramètre permettant le montage d’un répertoire (y compris sur une autre partition) sur un répertoire de l’arborescence.

      Est-ce que par hasard quelqu'un saurait si ce genre d'option ou de technique est disponible sous xBSD (x={Net,Open,Free})?
    • [^] # Re: Bind mount extensions

      Posté par . Évalué à 2.

      En fait c'est une sorte de lien "hard", pas symbolique, de répertoire.
      C'est juste qu'il faut le refaire (dans fstab par exemple) à chaque redémarrage, et que ça peut se faire entre deux partitions différentes, ou via NFS etc...

      Yth.
      • [^] # Re: Bind mount extensions

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

        C'est sacrement utile pour ceux qui utilise un livecd pour reparer une installation endommagé vu que pas mal de programme pete un plomb s'il n'ont pas leur /dev et /proc.
        • [^] # Re: Bind mount extensions

          Posté par . Évalué à 3.

          pour /proc y'a pas besoin de bind (pour /dev je me rappelle plus):
          mount -t proc none /proc
        • [^] # Re: Bind mount extensions

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

          Moi, je m'en sers pour rendre accessible dans un chroot un répertoire situé hors du chroot.

          Par exemple, j'ai un chroot contenant Debian unstable dans le répertoire /usr/local/sid-root. Il arrive que je souhaite travailler sur des images qui sont dans /home/flo/images avec un logiciel qui est installé dans ce chroot (soit parce que le logiciel n'existe pas dans Debian stable, soit parce que je veux utiliser une version assez récente dudit logiciel). Il suffit de faire un :

          # mount --bind /home/flo/images /usr/local/sid-root/home/flo/images

          pour rendre les images accessibles dans /home/flo/images à l'intérieur du chroot. C'est nettement plus pratique (et rapide) que l'alternative consistant à copier les images dans le chroot, travailler dessus, puis les copier à nouveau hors du chroot en écrasant les anciennes versions.
  • # LinuxFR

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

    Sois dit en passant, est-ce que les admins de LinuxFR pourraient nous décrire un peu la manière dont ils utilisent Linux-VServer ? Combien de vservers ils utilisent ? Quelle version du patch noyau ?

    On pourrait aussi parler d'une université française qui utilise quelques centaines de vservers répartis sur quelques dizaines de machines physiques, mais je laisse les intéressés se manifester au besoin ;-).
    • [^] # Re: LinuxFR

      Posté par . Évalué à 2.

      Je souhaite utiliser VServer sur un site à fort trafic, est-ce que les admins de LinuxFR pourraient nous indiquer également la charge supportée / le trafic ?
      • [^] # Re: LinuxFR

        Posté par . Évalué à 2.

        De mon expérience, la prise en compte de la charge supportée est du même acabit que celle d'un serveur classique (sauf paramétrage de limitation vs)
        A noter cependant que - par défaut - un process qui prend 100% de (faux) CPU dans un vserver ne floodera pas le serveur en lui-même ni même ses petits copains.

        Si tu souhaites constater les performances, y'a Lycos Hebergement Mutualisé France (seulement?) qui à l'ensemble de ces "jails" pro-clients en vserver sous Linux. Ainsi qu'Ikse, une boite française qui gère (et développe) dotNode.org, la version libre d'Orkut-Google; JeuxLibre.net, etc...
        Pour les autres : http://linux-vserver.org/VServer_Hosting :-)
    • [^] # Re: LinuxFR

      Posté par . Évalué à 1.

      On pourrait aussi parler de l'académie de la région centre qui équipe le coeur de réseau de tout ses lycées avec des serveurs hôtes qui font tourner plus d'une poignée de vservers. Les vservers facilite bien la télégestion, le déploiement, et les migrations. Ça représente pas loin d'un millier de vservers si tous le objectifs sont atteints.
      • [^] # Re: LinuxFR

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

        Je pense que la core-team de Linux-VServer serait heureuse d'entendre cela... Si elle n'est pas déjà au courant ;-) !
  • # Interface loopback ?

    Posté par . Évalué à 2.

    J'ai eu l'occasion récemment de "jouer" un peu avec des vserveurs pour pouvoir installer plusieurs solutions libres de supervision (une par vserver) sur une même machine physique, pour pouvoir passer facilement de l'un à l'autre lors des tests sans avoir à tout réinstaller.

    Le problème c'est que beaucoup de ces logiciels lancent des connexions vers "127.0.0.1" (pour la base de données, pour tester la machine sur laquelle il tourne, pour communiquer entre les composants). Comme il n'y a pas d'interface loopback séparée de la machine hôte, on est obligés de changer partout dans la configuration l'adresse loopback par l'adresse sur l'interface réseau. Là où ça se corse c'est pour les logiciels avec "127.0.0.1" codé en dur dans le source.

    Du coup je viens de virer les Vservers de cette machine de tests et je commence à regarder du côté de Xen. Quelqu'un sait s'il est prévu un jour de rajouter une interface loopback par serveur virtuel ?




    Question subsidiaire : y'en a qui ont réussi a faire de l'unification avec des vservers ? Si oui, et faire en sorte que lorsqu'on upgrade l'arborescence "de référence" ça fasse un upgrade de tous les vservers ? (le but étant qu'un nouveau vserver prenne le moins possible d'espace disque)
    • [^] # Re: Interface loopback ?

      Posté par . Évalué à 5.

      Heu si, si, y'a bien des interfaces loopback;
      Tu vas dans /etc/vservers/ton_vserver/
      Dans "interfaces", tu crées un répertoire, disons "mon_loopback_cheri"
      à l'interieur, tu crées tout plein de fichier :

      bcast dev ip mask name prefix scope

      Dans le premier (bcast), tu met le broadcast, exemple : 127.255.255.255
      Dans le second (dev), tu met "lo" bien entendu :-)
      Dans le troisième (ip), ... l'adresse ip 127.0.0.1 (ou autres si tu veux)
      Dans le mask, le netmask : 255.0.0.0
      Dans le name, tu places ce que tu veux, généralement le nom du vserver
      Le prefix, c'est générale soit 8, 16, 24 (ou autres suivant votre topologie réseau)
      Et en enfin dans le scope, tu met "host"

      Tu restart le tout, Tadaaaaaaa !


      # vserver monvserveur enter
      # socket -sl 1234

      Sur le main:

      $ telnet localhost 1234
      Trying 127.0.0.1...
      Connected to localhost.localdomain (127.0.0.1).
      Escape character is '^]'.
      • [^] # Re: Interface loopback ?

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

        Il me semble que tu viens juste de démontrer ce que N-Mi disait : il n'y a pas d'interface loopback séparée de la machine hôte

        Je ne connais strictement rien à vserver, mais si j'ai bien compris, il désire avoir dans chaque vserver une appli qui puisse écouter sur 127.0.0.1:1234 et que ce loopback soit propre au vserver où il a été créé/configuré.

        Mais je me trompe peut-être...
        • [^] # Re: Interface loopback ?

          Posté par . Évalué à 4.

          Hmmm, en effet, j'avais pas vu sa question sous cet angle.

          En effet, il n'y a pas de "jailing" de ce type pour l'interface loopback par défaut,
          Cependant, la feature a été codé par la coreteam, mais elle n'a pas été intégré à la version courante du patch principal.

          Voici ce patch : http://vserver.13thfloor.at/Experimental/delta-lo0.05.1.diff

          Il sera intégré dans les versions 2.2 voire 2.3 si tout se passe bien
          • [^] # Re: Interface loopback ?

            Posté par . Évalué à 2.

            En effet c'est bien ce que que je cherchais : une interface loopback en 127.0.0.1/8 propre à chaque vserver pour faire tourner les mêmes services en écoute sur les mêmes port sur plusieurs vservers, sans que ceux-ci puissent communiquer entre eux par l'interface loopback.

            Bon, vais essayer le patch pour voir s'il fonctionne correctement, ou sinon attendre la première version de développement qui l'incluera.

            [plussoiement]

Suivre le flux des commentaires

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