Bonjour à tous 🙂

J'aimerai entamer une petite discussion sur proxmox concernant les sujets des machines virtuelles (VM) et des conteneurs (CT).

Voici ma problématiques aujourd'hui : j'aimerai monter un serveur web "isolable" (en gros isoler chaque site web indépendamment des autres) et facilement "transférable" (debian / apache / php / mysql / ...) c'est à dire que je compte commencer sur un hardware à la portée de mon budget actuel (soit une trentaine d'euros par mois environ) mais avoir la capacité de ne pas avoir à tout refaire si un jour mon budget vient à augmenter et donc lors d'un changement de machine.

Je pensais donc monter un serveur dédié sous proxmox et utiliser le système de VM.

Sauf qu'en installant proxmox j'ai donc découvert qu'il était possible de faire sensiblement la même chose qu'en VM mais avec des CT. J'ai donc lu plusieurs sujets afin d'avoir des retours d'expériences mais j'avoue que ce n'est pas encore très clair dans mon esprit et je n'arrive donc pas à me décider sur quoi me lancer.

De ce que je comprends, les VM isolent intégralement l'environnement que l'on y monte dessus, donc je pense que cela correspond tout à fait à mon premier besoin et en plus je pourrais remonter la(es) VM sans "difficultés" sur un autre serveur sans m'amuser à tout reconfigurer (sauf la part hôte qui restera bien évidemment à remettre sur pied). Véritable gros inconvénients de cela selon mes lectures : les ressources consommées par les VM.

Les CT semblent répondre également à mon besoin car isolent à leur manière l'environnement et j'imagine que cela se transfère de la même façon qu'une VM mais j'y vois l’intérêt, par rapport aux VM, de la consommation de ressource qui semble être moindre et donc cela permettrait de pouvoir isoler chaque site web sur un CT sans faire "exploser" rapidement le serveur niveau ressource.

Mais je pense que j'ai loupé une étape dans mes lectures car du coup je ne vois pas bien l’intérêt de montrer une VM par rapport à un CT aujourd'hui. Je pense que, dans mon cas de figure, les CT répondent entièrement à mon besoin actuel autant niveau performance que ressources consommées et isolation.

Concernant les CT j'ai lu en revanche que l'aspect sécurité pêche un peu mais encore une fois j'ai du mal à voir pourquoi étant donné qu'il y a cette notion d'isolement. J'ai cherché plus d'information sur le sujet mais je n'ai pas trouvé de quoi nourrir ma compréhension 🙂.

Donc voilà, si jamais vous avez quelques retours d'expérience à apporter ou des avis sur le sujet je suis preneur.

Merci d'avance à ceux qui auront pris le temps de lire et un grand merci à ceux qui viendront alimenter cette discussion.

Au plaisir !

qo_op a renommé le titre en Recherche avis proxmox VM ou CT.

Ca dépend pas mal des usages. Pour une "machine" qui fait beaucoup d'écriture disque, j'ai eu des perfs lamentables en CT, mais correctes en VM. Dans mon cas, j'avais une base de données postgres avec plusieurs centaines de modifs à la seconde, c'était impossible en container, alors qu'en VM ça passe crème.
Le CT à l'avantage d'être redimensionnable à chaud (cpu, mémoire, disque...), alors que pour la vm, il te faudra probablement rebooter.

  • zer a répondu à ça.

    Salut,

    Les VMs et les CTs sont 2 choses très différentes avec chacuns leurs avantages et inconvénients.

    Je ne vais pas rentrer dans le détail, beaucoup de blogs/sites le font très bien, mais exposer les principales différences:

    Un CT partage le noyau de l'hôte, seuls l'environnement d'exécution et l'application sont virtualisés. Il utilise donc très peu de ressources, mais doit être de la même "famille" que l'hôte (linux pour linux ...)

    Une VM ne partage rien avec l'hôte, elle se contente d'en utiliser les ressources. On peut donc installer le système qu'on souhaite indépendamment de l'hôte. Elle est moins flexible et utilise plus de ressource.

    Concernant la remarque de Merrick, Je n'ai pas remarqué ce genre de comportement (de manière générique, je ne ferai pas de son cas une généralité), toutefois selon l'utilisation finale, un CT peut-être plus efficace qu'un VM et inversement... C'est du cas par cas et il faut faire ces propres tests.

      Merci pour vos retours @Merrick et @zer 🙂.

      En effet j'imagine bien que les performances dépendent beaucoup de l'utilisation et j'imagine même que sur une utilisation identique il peut y avoir une grande similitude en perf et un petit service qui vient plomber l'un vis à vis de l'autre.

      Il est vraiment difficile pour moi de me faire une idée précise mais il est intéressant de savoir que les CT peuvent être redimensionnées "à chaud" contrairement aux VM. C'est un point fort non négligeable.

      Après j'ai lu qu'il était fortement recommandé d'utiliser le type de partitionnement LVM thin pour stocker les images des conteneurs ce qui permet d’allouer l’espace disque lors de l’écriture (pas de préallocation).

      De mes différentes lectures ce qui m'inquiète le plus est surtout l'aspect sécurité. Il semblerait qu'en CT ça ne soit pas folichon de ce côté là mais j'ai vraiment du mal, malgré mes différentes lectures, à comprendre réellement pourquoi.

      Après vous avez tout à fait raison, rien ne vaut une batterie de test 🙂

      • zer a répondu à ça.

        qo_op Après j'ai lu qu'il était fortement recommandé d'utiliser le type de partitionnement LVM thin pour stocker les images des conteneurs ce qui permet d’allouer l’espace disque lors de l’écriture (pas de préallocation).

        Alors non, le "thin provisioning" ne s'utilise JAMAIS en production. En test, en qualif, tu peux, mais jamais en prod.
        Je sais que plein de boites le font, et crois moi, ce sont des boites qui n'ont jamais eu de crash de baies SAN à cause de ça !

        Pour la faire simple, imagine que tu as 100 unités de stockage au total,

        • L'admin a 15 VMs à faire et chacune a besoin de 5 de stockage.
        • Afin d'être tranquille, l'admin provisionne 8 pour chaque VMs en "thin".

        Tout roule: 75 unités de stockage sont utilisés comme prévu et chaque VM dispose d'un peu de marge.
        Pour une raison X ou Y, toutes les VMs s'emballent et saturent leur stockage d'un coup.

        Résultat : L'hyperviseur cherche à utiliser 120 unités de stockage alors qu'il n'en a que 100 à sa disposition.
        Conséquence : le stockage explose et ce met en carafe : toute la prod tombe.

        ça parait extrême, et pourtant c'est un scénario que j'ai déjà rencontré 2 fois dans ma carrière avec des baies SAN entières qui ont explosé (et des admins licenciés à la clé au passage...).

        Bref, il faut faire super gaffe avec ça 🙂

            zer voilà qui a le mérite d'être dissuasif. J'ai même oublié de quoi on parlait .. thin quoi ??? 😛

            Non mais intéressant comme retour et bien évidemment sur les différents blogs que j'ai vu ils vendent pourtant du rêve sur le fonctionnement mais à y réfléchir et vu ton retour d'expérience.. c'est pas glop 🙂

            Cela m'évitera une première bêtise. Merci !

              Alors je vais relativiser un tout peu la réponse de zer, car j'utilise le thin provisioning en production depuis plusieurs années. Tu peux le faire en prod, mais il faut savoir ce que tu fais :

              • soit le thin provisionning est géré par l'hyperviseur (genre vmware qui le fait très bien) : l'hyperviseur va bloquer de lui même toute demande de disque supérieure à la capacité disponible. Ta demande ne sera pas réalisée, mais tu ne casses rien d'autre
              • soit c'est géré par la baie SAN (et j'ai bien SOIT, surtout pas ET, parce que là tu vas au carton direct), et tu peux gérer, avec des règles bien établies (toujours garder X% d'espace disponible, avoir un outil de déploiement qui checke chaque datastore avant de déployer/d'agrandir, etc...), et avec un vrai outil de capacity planning qui va permettre de contrôler les baies régulièrement.

              Bref, jouable, mais on sort du cadre "serveur perso", et ça demande quelques ressources pour gérer ça. Si c'est pour un serveur perso avec un simple esx ou proxmox, ça a assez peu d’intérêt.

                Cette histoire de thin provisionning reste trop obscur de mon point de vue et ne me semble pas appropriée dans mon cas de figure qui est, pour rappel, la mise en place d'un serveur web (php / mariadb / html5 / js / ...) assez basique, devant accueillir un nombre à ce jour indéterminé de site.

                Je me demande donc à aujourd'hui si il est pertinent de faire un conteneur par site OU un conteneur pour plusieurs sites OU une VM par site (là je doute très très fortement au vu de la conso de ressources ...) OU une VM pour plusieurs sites. Sachant que je dois prendre en compte le fait qu'il soit possible que l'hôte soit amené à évoluer (donc changement d'offre en cours d'année pour un serveur hôte avec plus de ram ou cpu plus perf par exemple).

                N'ayant jamais utilisé de conteneur (il va falloir que je me lance pour me faire mon propre avis, c'est sûr), j'ai un gros doute 😅

                Alors j'aurais tendance à dire :

                • si les sites ne nécessitent pas beaucoup d'écriture (genre un site qui n'évolue pas beaucoup, bloc, site informatif) => container
                • si les sites nécessitent beaucoup d'écriture (une base de données mise à jour par plein de users en même temps, genre jeu en ligne) => vm
                  Dans tous les cas, il faut bien comprendre que les containers lxc ne sont pas des containers docker, ils se comportent comme une vm complète, donc niveau administration système, ça ne change (presque) rien.

                Par défaut, je mettrais plusieurs sites par container/vm, avec une gestion des virtualhosts pour gérer l'accès à chaque site (assez simple à mettre en oeuvre, que ce soit pour apache ou nginx), sauf si tu dois assurer que chaque "client" ait des ressourcées dédiées. Tout dépend aussi de la fréquentation des sites, s'il y a un "gros" site qui consomme beaucoup, tu voudras peut être l'isoler, mais tu verras ça à l'usage.

                  Merrick merci beaucoup pour ces infos, notamment en ce qui concerne la différenciation entre les sites sans trop d'accès disque et ceux qui font tout l'inverse.

                  Je n'ai jamais utilisé docker c'est pour cela que l'histoire de "conteneur" de proxmox me rebutait un peu mais comme tu dis, il ne s'agit pas de la même chose donc je vais me lancer dans un test sur un site actuellement en prod sur un dédié (sans proxmox). Cela va me permettra de voir les performances à minima.

                  Après je me pose une autre question concernant les conteneurs de proxmox, au moment de la création il y a une case à cocher "unprivilged container" qui semble indiquer que le conteneur n'aura pas les droits root. C'est une option réellement intéressant car j'imagine que cela limite fortement le champ d'action à l'intérieur du conteneur ? Ou alors j'ai mal compris ce que j'ai lu 🙂.

                    J'utilise en parallèle Proxmox (CT LXC) et Docker, c'est le pied pour un particulier. J'aime bien les CT parce qu'ils sont plus légers et ils se transfèrent tout aussi rapidement qu'une VM, de mon point de vue. Je mets par exemple un CMS en CT et la base de données sous Docker.

                      Aerya du coup si je comprends tu fais de la virtualisation docker dans le CT LXC ?! Ou alors le docker se situe où si ce n'est pas dans le CT LXC ?

                      Je demande ça car dans ma réflexion je me disais qu'il serait peut être pas mal de monter, pour mon projet, un CT LXC "dédié" à être le serveur SQL voire même une VM pour ça vu que selon Merrick la VM serait plus adaptée pour l'écriture (enfin attention je déforme peut être un peu ses propos), plutôt que d'avoir un serveur sql par CT.

                      • Aerya a répondu à ça.

                            Tu ne déformes pas mes propos, c'est moi qui me suis mal exprimé : le LXC gère (à mon goût) assez mal les gros input disque, tu prends plein de latence. Si tu écris raisonnablement, tu n'auras pas ce problème. Après, la limite est difficile à définir...
                            Après, tu peux très bien faire du docker dans lxc, mais il faut dans ce cas créer ton lxc avec une option particulière (que je n'ai plus sous la main, mais google te le dira vite).

                            qo_op J'ai les deux en parallèle, sur l'hôte. Mais tu peux aussi lancer du Docker dans un CT LXC.

                              Pour aller un tout petit peu plus loin dans les perfs LXC :

                              steph@forumtest:~$ df -h                                                                                                                             
Filesystem      Size  Used Avail Use% Mounted on                                                                                                     
/dev/loop4       30G  2.5G   26G   9% /                                                                                                              
[ ... ]                                                                                                               
steph@forumtest:~$ mount                                                                                                                             
/backup/images/102/vm-102-disk-0.raw on / type ext4 (rw,relatime,data=ordered)

                              Le disque / est monté en mode "loop". Voici un test de perf :

                              root@forumtest:~# time sh -c "dd if=/dev/zero of=/test.tmp bs=4k count=200000 && sync"                                                               
200000+0 records in                                                                                                                                  
200000+0 records out                                                                                                                                 
819200000 bytes (819 MB, 781 MiB) copied, 5.87151 s, 140 MB/s                                                                                        
                                                                                                                                                     
real    0m14.978s                                                                                                                                    
user    0m0.033s                                                                                                                                     
sys     0m1.436s

                              Soit 14 secondes pour écrire 780 Mo (avec un TRES grosse latence sur le "sync").
                              Si je lance la même commande sur une VM sur le même hôte, avec les mêmes cpu/ram (et chargée un peu de la même façon) :

                              root@log:~# time sh -c "dd if=/dev/zero of=/test.tmp bs=4k count=200000 && sync"                                                                     
200000+0 records in                                                                                                                                  
200000+0 records out                                                                                                                                 
819200000 bytes (819 MB, 781 MiB) copied, 1,00877 s, 812 MB/s                                                                                        
                                                                                                                                                     
real    0m1,125s                                                                                                                                     
user    0m0,139s                                                                                                                                     
sys     0m0,849s

                              Soit... plus de dix fois plus rapide !
                              Pour finaliser, j'ai mis en place une infra zabbix pour superviser l'hôte et toutes les VM/LXC, et la db mysql était sur un lxc. Au final, j'avais tellement d'IO wait que zabbix ne pouvait pas fonctionner. Dès que j'ai porté la db sur une vm, c'était immédiat.

                              Voici un test avec le CT de mon blog (sur du SSD):

                              df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       49G  4.8G   42G  11% /

mount
/var/lib/vz/images/101/vm-101-disk-0.raw on / type ext4 (rw,relatime,data=ordered)

time sh -c "dd if=/dev/zero of=/test.tmp bs=4k count=200000 && sync"  
200000+0 records in
200000+0 records out
819200000 bytes (819 MB) copied, 0.540632 s, 1.5 GB/s

real	0m2.505s
user	0m0.120s
sys	0m0.426s

                              Je ne suis pas en ssd, cela vient certainement de là...

                              @Merrick

                              Sur CT Proxmox, veuillez modifier la configuration de votre CT depuis votre host Proxmox pour vous amuser sur docker.

                              nano /etc/pve/lxc/XXX.conf

                              --> Rajouter à la fin :

                              lxc.autodev: 1
lxc.hook.autodev: sh -c "mknod -m 0666 ${LXC_ROOTFS_MOUNT}/dev/fuse c 10 229"
lxc.cgroup.devices.allow: c 10:200 rwm
lxc.apparmor.profile: unconfined

                              Redemarrer le CT ...

                              De mon coté, j'ai les memes resultats qu'@Aerya du test de vitesse sur un LXC sur SSD.

                              cd /tmp

time sh -c "dd if=/dev/zero of=/test.tmp bs=4k count=200000 && sync"

200000+0 enregistrements lus
200000+0 enregistrements écrits
819200000 bytes (819 MB, 781 MiB) copied, 0,580235 s, 1,4 GB/s

real    0m1,739s
user    0m0,033s
sys     0m0,555s