blog.bressure.net

Le chantier de passage de mes VM en conteneur docker commencé en mai touche à sa fin. Il ne me reste qu’une seule VM à migrer. Pour rappel, je me contrains à réellement migrer en conteneur et je n’utilise pas d’outils de conversion VM vers conteneur afin d’avoir réellement des images minimales offrant uniquement le service attendu. Le résultat obtenu début juillet était déjà probant. Dans ce billet j’enfonce le clou graphique munin à l’appui.

Réduction de l’enveloppe mémoire de VM et de la mémoire alloué sur l’hôte

Les 15 VM occupaient initialement 18-19 Go de RAM avant que ne me lance dans la migration avec uniquement un production. Au début de la migration en conteneur docker, l’enveloppe mémoire avait fait un bon puisque j’ajoutais 2 VM : une production et un pré-production puis au fil des migrations l’enveloppe mémoire sur l’hôte s’était mise à chuter rapidement. Actuellement j’ai doublé le nombre de services (une prod et une pré-prod) et réduit l’enveloppe mémoire à 15 Go. 30 Services pour 15 Go là où la virtualisation prenait 18-19 Go pour 15 services !

Mutualisation efficace par over-commit

Du point de vu de l’hôte la mémoire alloué à sensiblement diminuée passant de 45 Go à 33 Go. Tout cela doit être vu avec la perspective du doublement du nombre de service. Cela est rendu possible par la mutualisation au sein d’une même VM (un seul OS) de tous les services. L’OS a alors le choix d’allouer intelligemment les ressources limitées par l’enveloppe de la VM. Dans mon cas ma VM de prod occupe 7 Go de RAM. Idem pour la pré-pod. Pour ce faire le noyaux linux à recours à la surréservation (over-commit). Ici la machine de production:

La machine de pré-production certes moins sollicitée est également en over-commit:

Bien que la sur-réservation mémoire est normale car par empirisme les applications allouent la mémoire sans vraiment en avoir besoin tout le temps ce qui a conduit Linux à prendre en comportement par défaut l’over-commit. Cependant si jamais toutes les applications veulent accéder en même temps à la mémoire qui leur avait été promise, le système va planter sauf si on met suffisamment de fichier d’échange pour amortir le choc. Dans mon cas je me fixe comme limite de commit la quantité de mémoire virtuelle disponible (RAM 7 Go + SWAP 7 Go = 14 Go). Quand l’over-commit s’approche de cette limite, une alerte munin est rémontée !

Je ne triche pas avec le Swap

On pourrait croire que le swap est un moyen de tricher. Et non, il n’est là que pour amortir le cas improbable où tous les services voudraient leur mémoire promise. D’ailleurs on voit bien sur les graphiques que les VM ne « swappent » pas.

Et l’usage disque supplémentaire pour le swap ? C’était déjà la cas avec chacune des 15 VM du départ. Chacune ayant entre 1 Go et 4 Go de swap. Avec docker j’ai 15 services qui tiennent avec 7 Go de swap.

Docker (ou une solution de conteneurisation) est vraiment une avancée dans l’usage raisonné des ressources. Il offre en plus l’avantage de garantie d’une exécution dans des environnements à l’identique en terme de dépendance. Ces 2 points me permettent d’avoir une pré-prod représentative de ma prod aussi bien en terme d’installation (dépendances) et de taille (sans que cela ne coûte trop cher)