Journal Proxmox-ve

Posté par  (Mastodon) .
Étiquettes :
14
19
août
2009
Face à la montée des prix de certaines solutions de virtualisation propriétaires, j'ai profité des vacances pour tester d'autres solutions et notamment un produit très prometteur: proxmox-ve ( http://pve.proxmox.com/wiki/Main_Page ) actuellement en version 1.3.

Proxmox-ve est une distribution linux basée sur Debian qui propose une interface web permettant de gérer des serveurs virtuels OpenVZ et KVM (qemu). Pour l'installer il faut un serveur x86_64 et VT d'activé pour pouvoir lancer des machines KVM.
Pour l'instant j'ai surtout exploité la partie OpenVZ donc la virtualisation dans un container.

Voici donc mon impression sur la solution.

Les avantages:
- L'installation d'un serveur proxmox se fait en 5 minutes.
- L'interface web simple et convivale permet d'utiliser OpenVZ et KVM très rapidement.
- Le mode cluster permet la migration à chaud d'une VM. (La migration à froid n'occasionne qu'une coupure inférieur à 5 seconde)
- Il faut 10 secondes pour avoir une VM prête qui fonctionne grâce aux templates.
- Les VM sont aussi rapide qu'en natif.
- L'espace disque utilisé est divisé par 10 par rapport à la virtualisation complète car il est mutualisé (1 seul FS pour toute les VM).
- L'utilisation d'un SAN n'est pas indispensable.
- Possibilité d'automatiser la création de dumps de sauvegarde des VM via l'interface web.
- Possibilité de modifier directement les fichiers d'une VM OpenVZ éteinte.
- Grande facilité à scripter plein de chose.
- L'interface web est francisée.

Inconvénient:
- Pas de HA actuellement.
- Confiance partielle en l'isolation des interfaces réseaux.
- La migration à chaud des VM n'est pas possible nativement sur un montage NFS partagé entre les membres du cluster.
- Manque de paramétrage à l'installation (taille du filesystem, ext3 par défaut).
- Pas de répartition automatique de la charge sur les membres du cluster.
- L'isolation des ressources moins fines que chez certaines solutions propriétaire, mais du coup tout va beaucoup plus vite...

En bref un produit très intéressant techniquement.

Les anciens utilisateur de VServer et OpenVZ nous rappellerons qu'ils font tout ça depuis longtemps et je les en félicite ;-) . L'avantage que je vois dans proxmox est qu'il permet d'aborder cette philosophie de la virtualisation très rapidement grâce à une interface conviviale.

Toute la communauté Proxmox attend avec impatience la sortie de la version 2.0

  • # Hop

    Posté par  . Évalué à 1.

    Les VM sont aussi rapide qu'en natif.

    Je n'y crois pas une seule seconde. Qu'on soit proche de la rapidité d'un OS unique sur le même hardware, lorsqu'une seule VM tourne pourquoi pas; mais là, l'interêt consiste à connaître la baisse de perfs, et ou (I/O, CPU, etc..)

    L'espace disque utilisé est divisé par 10 par rapport à la virtualisation complète car il est mutualisé (1 seul FS pour toute les VM).

    Je croyais que c'était openVZ qui faisait ça. Pour KVM, on a encore une image disque?

    La migration à froid n'occasionne qu'une coupure inférieur à 5 secondes

    S'il s'agit d'une migration à froid, le downtime, on s'en fiche, non?

    • [^] # Re: Hop

      Posté par  . Évalué à 2.

      Je n'y crois pas une seule seconde. Qu'on soit proche de la rapidité d'un OS unique sur le même hardware, lorsqu'une seule VM tourne pourquoi pas; mais là, l'interêt consiste à connaître la baisse de perfs, et ou (I/O, CPU, etc..)

      Pour du OpenVZ, il n'y a bien aucune perte, puisque c'est la VM utilise le même noyau que l'hôte. C'est justement l'intérêt d'un tel système, cela permet de n'avoir aucune traduction d'instruction et donc une exécution directe.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Hop

        Posté par  . Évalué à 4.

        Mais le noyau d'openVZ est modifié. Modifié justement pour permettre le lancement de plusieurs instances.
        Donc qu'il tourne _strictement_ aussi vite qu'un noyau normal, ça m'étonne. Quil s'approche nominalement de la vitesse d'un noyau normal OK.

        Mais lorsque je lis''les VMs sont aussi rapides qu'en normal'', bin non. Là, je veux casser du mot de passe, par exemple. Sur ma machine (unique), ça prend du temps:
        20770 pts/2 RN+ 25610:16 ./john passwd
        Alors je vais installer sur ma machine un VZ, puis un cluster de 1000 machines donc j'irais 1000 fois plus vite?

        La virtualisation, c'est bien, c'est plein de qualités, mais un des principes de la virtualisation, c'est de se baser sur le fait que le soft actuel n'utilise pas entièrement la puissance offerte par le hard.
        Dès lors, oui, ''apparement'' on peut faire tourner plusieurs machines qui ont une vitesse ''apparente'' aussi rapide; mais si on commence à creuser, on se rend compte que ce n'est plus vrai du tout...
        J'ai un autre exemple avec du débit réseau qui est au taquet d'une carte gigabit. Sur cette carte gigabit, un hyperviseur qui redistribue trois VM. Pas de chances, mes VM ne bénéficient pas de 3x 1Gbit/s. Quel dommage!

        Et donc, à chaque fois que je lis ''mais si ma solution de virtualisation permet de faire fonctionner à vitesse native 'x' machines'' je râle. La virtualisation, ce n'est pas natif.

        Je rapproche plus la virtualisation au concept du temps partagé d'unix. On est passé d'un système monoprocessus, à un système multiprocessus (multiutilisateur). De manière brute, un processus va plus lentement. De manière générale, l'ensemble des processus va plus vite que s'ils étaient lancés séquentiellement.
        Pour la virtualisation, pareil. Les machines ne fichant rien 70% du temps, il est plus rentable de les coller toutes sur le même hardware. Globalement, on y gagne, même si certains cas limites sont problématiques...

        • [^] # Re: Hop

          Posté par  . Évalué à 3.

          Oui mais non. Je crois que tu n'as pas compris.
          Il n'a pas été dit que _chaque_ VM allait tourner comme sur une machine native à 100%. Bien évidemment que les ressources sont divisées entre les VM.

          Ce qu'on dit c'est que le système qui permet la virtualisation est ici particulièrement léger. Beaucoup moins d'overhead avec OpenVZ qu'avec KVM parce que les types de virtualisation sont différents.

          Avec le confinement type OpenVZ, les pertes sont _presque_ nulles.

          • [^] # Re: Hop

            Posté par  . Évalué à 1.

            Avec le confinement type OpenVZ, les pertes sont _presque_ nulles.

            Et donc tout est dans ce _presque_ .
            Et tous les programmeurs d'hyperviseurs disent: wé, wé, on est vitesse native. Quand on creuse, ça se transforme en ''wé, c'est du presque natif, hein''. L'ennuyeux, c'est ce presque. A combien faut il l'estimer?

            Ensuite, ce ''presque'', c'est une fonction qui dépend du nombre de machines invitées, ou pas? qui dépend de l'utilisation faite de ou des invités (genre I/O plus que CPU ou inversement).

            C'est ce manque de chiffres que je trouve dommage.

            • [^] # Re: Hop

              Posté par  (Mastodon) . Évalué à 2.

              OpenVZ n'a rien à voir avec un hyperviseur pour lequel tu as forcément un empilement de noyaux et des traductions. Le seul Overhead apporté par OpenVZ, c'est le calcul des ressources utilisées afin de gérer les quotas. Quand on parle plus haut de performances natives, il s'agit bien évidemment de comparer ce qui l'est: on a donc
              perfs (N applis / 1 OS / 1 Machine) ≃ perfs (N applis / N VE (nom des instances OpenVZ) / 1 Machine) >> perfs (N applis / N OS / N [kvm|xen|esx|…] / 1 hyperviseur / 1 Machine) >> perfs (N applis / N OS / N [qemu|Vbox|vmware server|vmware wk|…] / 1 OS / 1 Machine)
              et ça sur la même machine bien évidemment ;-)

            • [^] # Re: Hop

              Posté par  . Évalué à 1.

              Tu ne sais visiblement pas de quoi tu parles.

              Openvz, comme vserver ne rajoutent pas d'overhead, pas plus qu'un chroot.
              (C'est un peu moins vrai pour openvz qui est quand même un gros bloat)

              Sauf demande explicite, c'est le scheduler normal du noyau qui fait le travail.
              (Tous les process des machines virtuelles tournent comme des process normaux).

              Si tu veux donner des priorités aux machines virtuelles, ou dire qu'un n'a droit
              qu'a X% du temps cpu, les implémentations sont très simples, typiquement:
              http://linux-vserver.org/CPU_Scheduler dont l'overhead ne doit pas atteindre les 1%.
              De même pour la mémoire, l'espace disque etc...

              Si tu veux des mesures serieuses, les gens de planetlab en ont fait quelques une et
              ont publié les résultats: http://www.cs.princeton.edu/~mef/research/vserver/paper.pdf

        • [^] # Re: Hop

          Posté par  . Évalué à 1.

          Loin d'être un spécialiste de la virtualisation, mais je comprends ça comme ça:
          - avec une solution comme qemu on virtualise tout, et quelque soit les ressources disponibles sur l'hôte, les invités auront toujours des performances en retrait dû au système de virtualisation
          - avec une solution comme OpenVz, SI l'hôte a les ressources qu'il faut pour faire tourner deux OS, alors les deux auront les mêmes performances.

          Donc, non, en mettant 1000 vm avec OpenVz, on aura pas 1000 fois la puissance matériel, mais c'est normal. Pareil pour le réseau.

    • [^] # Re: Hop

      Posté par  (Mastodon) . Évalué à 1.

      Le gain sur l'espace disque d'une solution comme OpenVZ ou Vserver par rapport à une virtualisation complète intervient à 2 niveaux:
      - Dans une VM il n'y a que l'indispensable (pas de noyaux, pas de service inutile), donc une VM prend entre 100 et 500Mo sans les données utilisateurs.
      - En virtualisation classique on réserve un espace de plusieurs giga pour un serveur, ici toutes les VM sont sur le même filesystem.

      • [^] # Re: Hop

        Posté par  . Évalué à 2.

        vserver a aussi un système pour faire des liens symboliques entre les fichiers commun aux machines virtuelles, ce qui peut faire gagner par mal de place et de mémoire.

    • [^] # Re: Hop

      Posté par  . Évalué à 2.

      Proxomox propose les deux systemes:
      * La virtualisation avec KVM donc une image disque (plusieurs formats supporté assez difficile à étendre) et la mémoire alloué est fixe.
      * L'isolation de contexte avec openvz : un gros FS directement accessible depuis le parents, des templates à bases d'archive tar, et la mémoire est finement découpée (mémoire non swapable, mémoire garantie, overbooking) le tout tournant sur le même noyau que le parent. (comme un chroot très évolué)

      C'est vrai que j'ai été un peu surpri par la procédure d'install de proxmox qui est pas très diagonalisable, une interface réseau, un nom de machine un mot de passe et zou ... partitionnement ? sélection de paquets ? non plus tard ... pas le temps là /o\

      Ici on aime bien mettre les vz dans un lv indépendant, des snapshot lvm avant une MEP et on se sent plus serein. avec proxmox il faut faire le snapshot sur toutes les vz en même temps ...

      C'est pas très souple mais c'est tout intégré.

    • [^] # Re: Hop

      Posté par  . Évalué à 6.

      Moi non plus je n'y croyais pas. Et un jour nous avons été coincé par une application écrite en Clarion (application dont le dernière version vient de sortir, rigolez pas, il y a des mauvais partout). Le "serveur" doit être du Windows. Ca rame affreux. Une fois le Windows virtualisé, ça a été très fluide.
      La cause ? Le super programmer en Clarion confonfd flush et sync :-) Il faut dire que c'est indiqué sur le site officiel de Clarion. De là à dire que l'auteur de Clarion est incompétent... je ne l'ai pas dit.
      Virtualisé avec du vmware, ça ne tient pas compte des sync effectués par Windows, donc zou ça roule.

      Nous virtualisons également de grosses machines Windows de production (250 utilisateurs TSE et SQL). Elles utilisent à 100% des technologies Microsoft (.net et SQL server). Elles fonctionnent plus vite en étant virtualisées qu'en natif.
      Et les gains "annexes" sont énormes: sauvegardes hyper faciles, migration d'une machine à l'autre en quelques minutes, copie de machines virtuelles à l'identique pour faire des tests. Que du bon :-)

  • # Install

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

    >Manque de paramétrage à l'installation (taille du filesystem, ext3 par défaut).

    http://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Len(...)

    • [^] # Re: Install

      Posté par  (Mastodon) . Évalué à 1.

      Oui il est possible d'installer les paquets proxmox sur une debian (sur une ubuntu 8.0.4 ça doit fonctionner également) mais du coup ça rallonge un peu la durée de l'installation.

      L'autre solution étant de reformater la partition /var/lib/vz.

  • # vserver

    Posté par  . Évalué à 3.

    Pour ceux que cela intéressent il existe quelques interfaces du même genre pour vserver,
    (qui est tout de même un peu moins bloaté)

    http://www.openvps.org
    http://www.openvcp.org
    https://listes.univ-reims.fr/sympa/d_read/vs-tools

    Le dernier étant uniquement en mode texte mais offre pas mal de possibilités et d'outils de plus haut niveau qu'util-vserver.

    Et peut être un jour http://linux-iscsi.org/index.php/VHACS

    Reste toute de même à installer la distribution :)

Suivre le flux des commentaires

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