Ganeti est un logiciel qui permet de monter un cluster de machines virtuelles (VM) sur des hôtes GNU/Linux. Une des fonctionnalités les plus appréciables est la possibilité de migrer à chaud (live migration) des machines virtuelles en cours de fonctionnement d'un hyperviseur à un autre avec quasi 0 interruption de service (la machine est en pause uniquement le temps de transférer le contenu de sa RAM). C'est mega pratique pour mettre à jour les hyperviseurs ou toute autre opération de maintenance. Une autre fonctionnalité appréciable est la possibilité d'utiliser DRBD et donc d'avoir un stockage redondant genre le stockage d'un des hyperviseurs casse ? Pas grave, on migre les VM sur un autre hyperviseur. Ce dernier aura reçu le contenu du stockage de la VM jusqu'au dernier moment donc pas de perte de données à déplorer.
Supposons un cluster composé de deux hyperviseurs : hwhost1 et hwhost2. Si l'on a besoin de mettre à jour Linux sur les deux, on migre d'abord toutes les VM en cours de fonctionnement de hwhost1 sur hwhost2 ( gnt-node migrate hwhost1
), on fait la mise à jour sur hwhost1, on le reboot puis on migre toutes les VM en cours de fonctionnement de hwhost2 sur hwhost1 (gnt-node migrate hwhost2
) et on applique la mise à jour et le reboot.
À ce stade-là, toutes les VMs sont sur hwhost1. Comment faire pour les répartir équitablement entre les deux hwhosts ? Une sur deux, à la mano ? gnt-instance migrate
autorise une et une seule instance en paramètre donc ça passe pour 5-10 VM mais c'est franchement pénible au-delà (lancer une migration, attendre qu'elle se fasse, lancer une autre migration, attendre, etc.).
C'est là qu'intervient hbal qui utilise un algo pour répartir les VMs sur les hyperviseurs le plus intelligemment possible en tenant compte de la quantité de RAM occupée, du nombre de vCPUs, etc.
Utilisation, sur l'hyperviseur master : hbal -L -C -p --no-disk-moves --exclude-instances=XXX,YYY,etc.
-L indique de communiquer direct avec le master, via le protocole Ganeti ;
-C affiche les commandes genre « gnt-instance migrate
-p affiche deux résumés (un avant et un après l'application de la solution proposée) de l'état des hyperviseurs (RAM, vCPUs, etc.) ;
--no-disk-moves : on veut uniquement des migrations d'un hyperviseur à l'autre ;
Si la solution proposée est convenable, on demande à la réaliser en ajoutant « -X » à la commande précédente. \o/
Que du bonheur. :)
ÉDIT DU 02/07/2016 À 20H : on peut même aller plus loin. Supposons que vous ne voulez pas que deux VMs se retrouvent ensemble sur le même hyperviseur en même temps sauf cas exceptionnel (maintenance, panne, etc.). C'est par exemple le cas de deux VM qui assurent un même service comme un serveur VPN ou un serveur DNS (même si c'est un mauvais exemple : un secondaire DNS, ça fait partie des services de secours qui s'hébergent en dehors de votre réseau !) ou comme un-e abonné-e qui a deux VM sur votre infra (ça serait dommage que ses deux VM flanchent si un seul hyperviseur flanche). Pour cela, Ganeti prévoit les exclusions tags.
Le manuel n'est vraiment pas clair sur ce point àmha mais la doc' de riseup l'est : https://we.riseup.net/riseup+tech/ganeti
Exemple reproduit ici :
sudo gnt-instance add-tags <nom_VM> <tag>
sudo gnt-instance add-tags <nom_autre_VM> <tag>
sudo gnt-instance add-tags <nom_encore_une_autre_VM> <tag>
sudo gnt-cluster add-tags htools:iextags:<tag>
hbal tient compte des tags d'exclusion et propose une solution dans laquelle toutes les VM qui portent un même tag d'exclusion ne se retrouvent pas sur le même hyperviseur. FIN DE L'ÉDIT.