Catégories
Application Paramétrage

kvm – ajouter de l’espace disque à chaud

En train d’importer un blog avec 36000 entrées à partir d’un fichier de WRX de 54 Mo, je voyais l’espace disque se remplir à vue d’oeil ! à 92% munin commençait à m’envoyer des mails d’alerte.

Pas de panique, comme j’utilise kvm et lvm, l’ajout d’espace disque peut se faire à chaud. La difficulté était que je devais tout faire en shell distant.

J’ai ainsi réussi à sauver mon processus d’import en ajoutant un disque et augmenter le volume logique mais le disque virtuelle était au mauvais format: 20 Go virtuel et 20 Go sur l’hôte même si il était vide.

Finalement voici la méthode pour ajouter à chaud de l’espace sur une VM en train de saturer.

Créer un nouveau disque

Se mettre sur l’hôte et en tant que root en remplaçant staging-2.qcow par ce que vous voulez:

qemu-img create -f qcow2 /var/lib/libvirt/images/staging-2.qcow2 20G

Ne pas utiliser les option de preallocation

Attacher le disque à la VM

C’est là que réside la subtilité pour que la VM croire avoir à faire à un disque de 20G même si le fichier ne fait que quelques centaines de kilos. La commande qemu-img info permet de voir les propriétés du disque virtuel.

/var/lib/libvirt/images# qemu-img info staging-2.qcow2
image: test.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false



On va attacher le disque à la VM en précisant bien le driver qcow2

# virsh attach-disk staging /var/lib/libvirt/images/staging-2.qcow2 vdb --driver qemu --subdriver qcow2 --targetbus virtio --persistent --config --live

Remplacer vdb par un identifiant de device disponible dans la VM qui s’appelle ici staging.

En tant que root sur le VM, vérifier la présence du disque et qu’il a la bonne taille

# fdisk -l

Disque /dev/vdb : 20 GiB, 21474836480 octets, 41943040 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Ajouter le disque /dev/vdb dans le volume group à étendre., ici staging-vg

# vgextend staging-vg /dev/vdb

Ajouter tout l’espace au volume logique, ici /dev/staging-vg/root

# lvm lvextend -l +100%FREE /dev/staging-vg/root

Redimensionner le système de fichier qui se trouve ici dans /dev/mapper/staging--vg-root

resize2fs -p /dev/mapper/staging--vg-root

Catégories
Application Paramétrage

Docker – résultat de migration VM vers conteneurs

Les premiers resultats se confirment: le passage aux conteneurs docker me permet de faire de economies drastiques de ressources !

Avec 15 VM (soit 15 applications) qui occupaient 17 Go de RAM mon systeme hôte montrait des signes de saturation. J’ai déjà migré 7 applications et cela se traduit par un du nombre de service (conteneur docker) consequent car une application est constituée par exemple d’un service wordpress et d’un service de base de données. Actuellement pour 7 applications j’ai 17 conteneurs mais qui tiennent dans 4 Go de RAM.

Ceci me permet d’avoir une prod et une preprod. J’ai 14 applications dans 2 VM pour 8 Go de RAM totale.

Réduction du nombre de VM

Si au démarrage du projet j’ai ajouté 2 VM pour accueillir la production et la préproduction. La transformation progressive des anciennes VM de prod en conteneur à porté ses fruits.

La capture suivante montre bien l’empreinte mémoire des VM diminuer au fur et à mesure de leur disparition. Actuellement les VM occupent 14 Go contre 17 Go avant. Le gain semble faible en réalité il est très important…. car j’ai aujourd’hui le double d’application: une prod et une preprod. Je suis donc virtuellement passé de 34 Go à 14 Go !

Multiplication des conteneurs

Quand on observe le contenu de la VM de production, on voit que la transformation de 7 application qui tenaient dans 8 VM à cause d’une VM dédié à Elasricsearch pour un dzq blog, a donné naissance à 16 conteneurs. Il faut ajouter le gitlab-runner pour effectuer les déploiements.

On remarque que les conteneurs consomment à peine 300 Mo chacun sauf celui d’Elasticsearch. On comprend alors la gabegie d’avoir une VM dédiée par application.

Charge mémoire de l’hôte

La gestion de la mémoire des VM est telle que une VM ne rend jamais à l’hôte la mémoire allouée. On peut par une action manuelle diminuer la taille de la mémoire mais cela ne rend pas la mémoire au système. Donc ce qui est alloué au bénéfice de l’overcommit finira par générer du swap. L’extinction des VM au fur et à mesure montre bien la diminution de la charge mémoire.

Charge mémoire de la VM docker

La VM de prod avec 4 Go exécute sans broncher tous les conteneurs au prix d’un overcommit important. Toutefois puisque les services ne sont pas utilisés en même temps, le swap n’a pas encore eu lieu mais le système est à sa limite. Je ne vais pas pouvoir décemment rester avec 4 Go de RAM par VM.

Catégories
Application Paramétrage

Docker – premier résultats de migration VM vers conteneurs

Le 23 mai dernier je me lançais dans la transformation de mes VM en conteneurs docker. Cette migration est un changement de paradigme et j’ai voulu de plus mettre en oeuvre de l’integration et du deploiement continu comme fondations de ma nouvelle infrastructure.

Ces prérequis ont un peu retardé les resultats visibles que cette transformation avait comme promesse:

  1. moins de VM
  2. moins d’empreinte mémoire

Souvenez-vous je partais de 15 VM qui offraient differents services (blog….) consommant 17Go de RAM en total et un système hôte qui était en overcommit avec du swap.

Nombre de VM

J’ai ajouté 2 VM: une production et une production. A ce jour j’ai dockerisé 5 VM donc le nombre total de VM est en baisse: -3. Mais il faut bien voir que je gagne également en terme de « robustesse » car j’ai une preprod qui n’existait pss avant. Dès la 2e VM dockerisée j’étais à l’équilibre.

Pour comparer réellement c’était comme si j’avais 15×2 VM (prod et prepod) et que maintenant j’ai ajouté 2 VM et retiré 5×2 VM. Donc au final j’ai virtuellement fait -8 en nombre de VM. Avec une préprod avant j’aurais été à l’équilibre dès la 1er VM dockerisée.

Empreinte memoire

Les 2 VM de prod et preprod consomment chacune 4 Go de RAM tandis que les 5 VM supprimées utilisaient au total 8 Go. Donc je suis à l’équilibre.

Je dispose, avec la même quantité de mémoire, d’une préprod pour mes 5 services conteneurisés.

On remarque que l’overcommit du système hôte a baissé dès que les 8Go de VM ont été enlevés. En revanche dans la VM de production qui héberge les 5 applications (ex-VM) sous forme de services dockers, les 4 Go sont bien remplis et semblent être juste

On voit de overcommit mais pas vraiment de swap. Ce résultat est encourageant et montre bien que la conteneurisation permet de mieux partager les ressources sans le gaspillage lié à la multiplication des OS dans le paradigme du tout virtualisé.

Je vais donc poursuivre l’expérience de mise sous docker et voir quand la VM de prod va craquer.