Sur une installation de Ganeti (logiciel qui permet de monter un agrégat d'hyperviseurs GNU/Linux), nous avions un Volume Group (VG) LVM qui contient toutes nos machines virtuelles (VM) existantes :
$ sudo gnt-cluster info | grep -E "lvm|metavg"
lvm volume group: vg0
lvm reserved volumes: (none)
metavg: vg0
Ce stockage s'effectue sur des SSD. Désormais, nous avons également des disques dur de grande capacité dans nos hyperviseurs et nous voulons les utiliser avec Ganeti, au cas par cas, en fonction des VM. Nous avons créé le VG « vg_vpsstockage ».
Si l'on suit la documentation qui correspond à notre version de Ganeti ainsi que la documentation pour manipuler plusieurs VG avec Ganeti, la commande suivante devrait créer une VM dans le VG stocké sur nos disques durs :
$ sudo gnt-instance add -t drbd --no-wait-for-sync -disk 0:size=10G,vg=vg_vpsstockage,metavg=vg_vpsstockage -B memory=1024MB -o debootstrap+stretch --no-start <nom>
Mais ce n'est pas le cas :
Can't compute nodes using iallocator 'hail': Request failed: Group default (preferred): No valid allocation solutions, failure reasons: FailDisk: 2
Le problème ne vient pas de DRBD puisqu'un sudo gnt-instance add -t plain -disk 0:size=10G,vg=vg_vpsstockage,metavg=vg_vpsstockage -B memory=1024MB -o debootstrap+stretch --no-start <nom>
échoue tout autant.
Si nous spécifions l'hyperviseur sur lequel créer la VM (-n hyperviseur1.domain.example
), cela fonctionne, quel que soit l'hyperviseur utilisé. Ganeti est donc capable d'utiliser le nouveau VG sur chaque hyperviseur.
Si nous utilisons DRBD en spécifiant le couple d'hyperviseurs à utiliser (sudo gnt-instance add -t drbd --no-wait-for-sync -disk 0:size=10G,vg=vg_vpsstockage,metavg=vg_vpsstockage -n hyperviseur1.domain.example:hyperviseur2.domain.example -B memory=1024MB -o debootstrap+stretch --no-start <nom>
), cela fonctionne.
C'est donc l'allocateur dynamique, le bout de logiciel qui aide à la répartition des VM sur les différents hyperviseurs en fonction des ressources (RAM, CPU, etc.) restantes, qui échoue.
Un des tests d'intégrité doit échouer… Mais lequel. Désactivons-les pour voir (sudo gnt-instance add -t drbd --no-wait-for-sync -disk 0:size=10G,vg=vg_vpsstockage,metavg=vg_vpsstockage -B memory=1024MB -o debootstrap+stretch --no-start --ignore-ipolicy <nom>
) : échec, toujours le même message d'erreur. Sans trop de surprise puisque la politique de notre cluster (sudo gnt-cluster info | grep -A 25 "Instance policy"
pour l'afficher) prévoit des valeurs minimales inférieures aux besoins de notre VM de test et des valeurs maximales supérieures à ces mêmes besoins.
Après quelques essais au pif, nous nous redons compte que l'allocateur échoue quand nous commandons la création d’une VM avec un disque dur virtuel d'une capacité supérieure à l'espace disponible dans le VG des SSD. Quand nous commandons une capacité inférieure, la création d'une VM fonctionne. Pourtant, nous sommes formels, Ganeti crée bien le disque dur de la VM dans le VG des disques durs… Pourquoi son allocateur vérifie-t-il le VG des SSD ? Mystère.
Nous n'avons pas trouvé d'autre solution que de changer les paramètres globaux du cluster, de créer notre VM, puis de rétablir les paramètres globaux du cluster (utilisation du stockage SSD par défaut). Cela se fait de cette manière :
$ gnt-cluster modify --vg-name vg_vpsstockage -D drbd:metavg=vg_vpsstockage > /dev/null
$ gnt-instance add -t drbd --no-wait-for-sync -disk 0:size=10G -B memory=1024MB -o debootstrap+stretch --no-start <nom>
$ gnt-cluster modify --vg-name vg0 -D drbd:metavg=vg0 > /dev/null
Comme nous utilisons un script pour créer nos VM Ganeti, toute cette tambouille n'est pas gênante. Note : nous utilisons trap "gnt-cluster modify --vg-name vg0 -D drbd:metavg=vg0 > /dev/null" EXIT
afin d'être sûr que la commande de rétablissement des paramètres globaux du cluster sera bien exécutée, quelle que soit l'embranchement de sortie du script.