Contents

  1. Vocabulaire de base
  2. Opérations de routine
    1. lister les instances
      1. niveau réseau : liste de ip utilisés par instance
    2. Démarrer et arrêter
      1. Empêcher le redémarrage d'une instance
    3. Créer une VM
      1. création de vm sur le cluster interne
      2. création d'instance sur le cluster chez openface
        1. Créer une instance avec un volume ZFS
      3. ... avec puppet2 pre-installed
        1. si ca échoue
      4. ... avec plusieurs ip
      5. ... sur un autre VG
      6. création de vm sur le cluster du bureau
        1. création de vm avec d'autre OS / Version de debian
    4. Modifier une vm
      1. Réinstall de l'OS
      2. RAM
      3. core | vcpu
      4. Ajouter une interface réseau
        1. Ajouter une interface réseau privée à une instance
        2. Assigner/changer une IP à une interface réseau qui n'en a ou pas
      5. Changer la taille des disques
      6. Autres options
    5. Détruire
    6. Déplacer une VM vers une autre node
  3. Autres opérations
    1. Gestion de node
      1. ajouter un node
      2. Changer le master du cluster
      3. Fermer/rebooter une node pour maintenance
        1. sans drdb
        2. avec drbd
      4. Retirer un serveur de l'allocation
        1. Lister les serveurs retirés de l'allocation
      5. Pour retirer une node du cluster (par exemple on veut réutiliser le matériel à d'autres fins)
      6. Rajouter des OS
    2. Gestion des réseaux (pools d'IPs)
      1. Création et activation d'un réseau sur le cluster
      2. Lister les réseaux sur le cluster
      3. Lister l'utilisation des IPs dans le réseau
      4. Réservations d'IPs de manière externe
        1. Réserver des IPs hors ganeti
        2. Retirer des IPs réservées
    3. Importer un VPS de Xen legacy
    4. État du cluster : niveau d'utilisation
    5. Simuler combien d'instances on peut crammer dans un cluster
    6. Renommer un cluster
    7. Changer la politique d'instance
    8. Geler une instance temporairement
  4. Débugging
    1. Outils de vérification
  5. Messages d'erreurs
    1. sur les nodes
      1. too many open files
      2. le cluster ne se reconnait pas
      3. SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
    2. sur les instances
      1. un instance est paused et ne démarre pas
      2. une instance ne revient pas en ligne
      3. unmount: target is busy / Logical volume data/...disk0 is used by another device

Vocabulaire de base

Dans Ganeti, on utilise le vocabulaire suivant:

`node`
une machine physique (généralement) contrôlée par ganeti et qui offre de l'espace de stockage, de la ram et des CPUs pour pouvoir y rouler des instances.
`cluster`

un ensemble de nodes

`master`

node d'où on contrôle le cluster

`instance`
une VM sur un node

Toutes les opérations sont faites sur le master, donc on se loggue rarement sur les nodes direct. Voir GanetiCluster#Listes_des_clusters pour connaître les noms des clusters: quand on se connecte sur le nom d'un cluster, on arrive toujours sur le master.

Opérations de routine

lister les instances

Avec les éléments suivants en plus :

# gnt-instance list -o name,os,status,pnode,vcpus,be/maxmem,disk.size/0,disk.size/1,ip 
Instance                 OS                  Status  Primary_node           ConfigVCPUs ConfigMaxMem Disk/0 Disk/1 NicIP/0
aegir0.koumbit.net       debootstrap+stretch running virachocha.koumbit.net           8        16.0G 400.0G   8.0G 199.58.80.29
aegir3.koumbit.net       debootstrap+jessie  running vengeance.koumbit.net            8        10.0G 399.0G   1.0G 199.58.80.39
alternc-dev.koumbit.net  debootstrap+stretch running virachocha.koumbit.net           2         2.0G  18.0G   2.0G 199.58.80.90
apps.koumbit.net         debootstrap+default running vengeance.koumbit.net            4         2.0G  39.0G   1.0G 199.58.80.115
....

niveau réseau : liste de ip utilisés par instance

# gnt-instance list -o pnode,name,nic.ips
Primary_node         Instance                    NIC_IPs
artemis.koumbit.net  aapq.symbiotic.coop         199.58.81.165
vania.koumbit.net    ada.glocal.coop             199.58.81.158
veles.koumbit.net    agecvm.koumbit.net          199.58.81.156
venus.koumbit.net    alternc3.koumbit.net        199.58.81.152
minerve.koumbit.net  artengine.koumbit.net       None

Démarrer et arrêter

gnt-instance startup $instance

Pour un équivalent de xm create -c dans ganeti, simplement faire:

gnt-instance startup $instance ; gnt-instance console $instance

gnt-instance shutdown $instance

Si l'instance ne veut pas fermer ou encore est gelé... utiliser le paramêtre --timeout pour la fermer immédiatement:

 gnt-instance shutdown --timeout=1 $instance

Sur la nouvelle version de ganeti, c'est arrivé que cette commande avec un timeout de 0 n'ait aucun effet. Si on est vraiment mal pris et qu'une job de shutdown est jammée dans l'état "running" dans la file de jobs de ganeti (voir avec gnt-job list) et que la vm veut pas se fermer, on peut ssh sur la node à partir du master du cluster et ensuite utiliser xl destroy $instance pour forcer la VM à se fermer. Ensuite, dépendant si le watchdog décide de ne pas repartir la VM (attendre qq secondes et lister l'instance avec ganeti pour voir son état), on peut la repartir normalement avec gnt-instance start $instance.

Empêcher le redémarrage d'une instance

Une fois qu'une VM a été fermée, on peut la marquer comme étant "offline" pour s'assurer qu'elle ne repartira pas automatiquement quand on redémarre une node avec toutes ses instances.

En premier, il faut que la l'instance soit fermée (donc voir point parent).

Une fois que l'instance est fermée, on change son état:

gnt-instance modify --offline $instance

Après la commande au dessus, quand la VM est fermée on devrait voir l'état ADMIN_offline dans la liste des instance -- ce qui nous permet de voir facilement quelles VMs ne redémareront pas. Par exemple:

gnt-instance list | grep ADMIN_offline
vm1234.koumbit.net     xen-pvm    debootstrap+default victoria.koumbit.net ADMIN_offline      -

Pour inverser cette action, on peut utiliser l'option inverse -- ça va permettre ensuite de redémarrer l'instance:

gnt-instance modify --online $instance

Créer une VM

Attention ici, on a plusieurs cluster ganeti, voir la liste ici: GanetiCluster On devrait probablement faire la documenation de création d'instance dans la page du cluster à la place d'avoir de quoi de générale ici.

Le DNS doit être configuré correctement sinon la commande va échouer.

La première étape c'est de réserver l'IP pour le serveur en créant une entrée DNS dans le domaine koumbit.net et l'entrée reverse pour l'IP choisie.

1. Choisir une adresse IP

Pour voir dans quel range d'IPs il faut placer la VM, utiliser la commande:

gnt-network list

Si vous avez ce message d'erreur:

Unable to get a free IP for NIC 0 from the address pool

Il n'a plus d'ip de disponible dans le pool d'ip pour le cluster client, mais ça veut pas dire que tous les ips ont été allouées! Voir sur homere pour l'allocation d'ip. On doit ajouter un ip au pool avant la création de la vm, avec la commande: gnt-network modify --remove-reserved-ips=199.58.81.XXX colo2-arin01.koumbit.net

Plus de détails sur la gestion des ip dans la section plus loin. GanetiMaintenance#Gestion_des_pools_d.27IP

Si jamais les clients spécifient qu'ils veulent un hostname qui n'est pas dans le domaine koumbit.net, alors il faut utiliser --no-ip-check et --no-name-check dans la commande plus bas pour contourner la vérification et allouer une IP au hasard. On doit configurer l'entrée reverse correctement pour l'IP avant la création de la VM.

Pour créer la VM, faire juste cette commande magique. Changer évidemment les paramètres selon les forfaits et autrement suivre la procédure PratiquesCréationServeur!!

Attention, sur gnt0 (cluster interne), les réseaux ne sont pas les même (vous remplacez par def0-arin00.koumbit.net ; utilisez gnt-network list pour voir les raizos). voir l'exemple plus bas.

Pour créer des VMs avec wheezy, il faut utiliser -o debootstrap+default. Pour créer des VMs avec jessie plutôt que stretch, il faut utiliser -o debootstrap+jessie.

Nano en buster

gnt-instance add -d -o debootstrap+buster -t plain \
 --disk 0:size=14G --disk 1:size=1G -B memory=1G,vcpus=1 \
 --net 0:ip=pool,network=colo1-arin01.koumbit.net \
 ganetiinst1.koumbit.net

Chiquito en buster

gnt-instance add -d -o debootstrap+buster -t plain \
 --disk 0:size=28G --disk 1:size=2G -B memory=2G,vcpus=1 \
 --net 0:ip=pool,network=colo1-arin01.koumbit.net \
 ganetiinst1.koumbit.net

Mediano en buster

gnt-instance add -d -o debootstrap+buster -t plain \
 --disk 0:size=56G --disk 1:size=4G -B memory=4G,vcpus=2 \
 --net 0:ip=pool,network=colo1-arin01.koumbit.net \
 ganetiinst1.koumbit.net

Gordo en buster

gnt-instance add -d -o debootstrap+buster -t plain \
 --disk 0:size=112G --disk 1:size=8G -B memory=8G,vcpus=4 \
 --net 0:ip=pool,network=colo1-arin01.koumbit.net \
 ganetiinst1.koumbit.net

Spécifications résultantes du dernier:

Nom

ganetiinst1.koumbit.net

Mémoire
8G
Disque
112G
Swap
8G
CPUs
4
IP

assignée du pool colo2-arin01.koumbit.net

OS

Debian Wheezy 7.x (default)

Une fois la VM créée, on peut utiliser le script /opt/bin/documentVM.sh pour générer le contenu de la page wiki pour la VM.

Après, le password root de la machine est dans: /var/log/ganeti/os/add-debootstrap+default-ganetiinst1.koumbit.net-2015-01-02_17_58_35.log. Noter aussi que plusieurs partitions peuvent être ainsi assignées à la machine. La première est pour l'OS, la seconde pour la swap et les autres sont inutilisées par défaut, mais peuvent être utilisées par la VM.

Puisque la machine est créée seulement sur une des nodes du cluster, il faut rouler cette commande sur tout le cluster pour trouver le mot de passe root:

gnt-cluster command grep 'root.*password' /var/log/ganeti/os/*ganetiinst1.koumbit.net*

Pour se connecter en root avec le mot de passe on peut utiliser la commande suivante:

gnt-instance console somevps.koumbit.net


# ctrl+] pour quitter la console

Il est possible de forcer l'utilisation d'une machine quelconque pour créer les VMs avec l'option -n venus.koumbit.net

Pour créer une machine avec une redondance DRBD, utiliser: -t drbd au lieu de -t plain. Si on utilise le flag -n, il faut spécifier les deux machines, exemple -n venus.koumbit.net:veles.koumbit.net.

Il n'y a pas de réseau dédié pour DRBD, ce qui rend son opération non-sécurisée. Voir 16331 pour le suivi à ce niveau.

création de vm sur le cluster interne

gnt-instance add -d -o debootstrap+buster -t plain \
 --disk 0:size=18G --disk 1:size=2G -B memory=2G,vcpus=2 \
 --net 0:ip=pool,network=def0-arin00.koumbit.net \
 --net 1:ip=192.168.0.<ip>,network=internal.koumbit.net \
 vps-interne.koumbit.net

création d'instance sur le cluster chez openface

Bien sur faire les vérifications préalable pour l'allocation d'ip.

gnt-instance add -n badbrains.koumbit.net \
 -o debootstrap+buster -t plain \
 --disk 0:size=246G --disk 1:size=4G -B memory=4G,vcpus=2 \
 --net 0:ip=pool,network=colo-openface \
 instance14.koumbit.net

Créer une instance avec un volume ZFS

Cette opération là est présentement seulement possible sur la machine chez openface. L'opération dépend de la configuration zfs pour ganeti.

La commande plus bas créé bien les volumes zfs, installe bien l'OS dedans, mais ensuite le hook grub plante en disant "Unknown disk type". Mais si on patch le hook grub, on peut faire fonctionner l'installation!

root@badbrains:/etc/ganeti/instance-debootstrap/hooks# diff -burN grub  ~/grub.zfs 
--- grub        2019-08-18 01:00:14.812730551 -0400
+++ /root/grub.zfs      2019-08-18 01:01:26.513726137 -0400
@@ -22,6 +22,8 @@
 
 if [[ $BLOCKDEV == /dev/drbd* ]]; then
     DISKTYPE=drbd
+elif [[ $BLOCKDEV == /dev/zvol* ]]; then
+    DISKTYPE=zfs
 elif dmsetup info $BLOCKDEV > /dev/null 2>&1; then
     DISKTYPE=lvm
 else
@@ -58,7 +60,7 @@
         echo "(hd0) $MAPPERDEV" > $TARGET/boot/grub/device.map
         chroot "$TARGET" grub-install $LODEV
         ;;
-    drbd)
+    drbd|zfs)
         chroot "$TARGET" grub-install $BLOCKDEV
         ;;
 esac
@@ -76,7 +78,7 @@
     lvm)
         chroot "$TARGET" grub-install $LODEV
         ;;
-    drbd)
+    drbd|zfs)
         chroot "$TARGET" grub-install $BLOCKDEV
         ;;
 esac

TODO: s'arranger pour que puppet déploie le hook patché et se débarrasser de la patch dans le wiki.

gnt-instance add -o debootstrap+buster \
 -t ext --disk 0:size=50G,provider=zfs,zfs=BELUGA \
 --disk 1:size=1G,name=swap,provider=zfs,zfs=BELUGA \
 -B memory=2G,vcpus=1 --net 0:ip=pool,network=colo-openface \
 instance42.koumbit.net

... avec puppet2 pre-installed

Vous devriez pouvoir ajouter  -O puppet2=yes  sur tout les clusters. Puppet va s'installer tout seul sur

Vous pouvez alors afficher la clef avec  gnt-cluster command grep 'LOCAL KEY' /var/log/ganeti/os/*ganetiinst666.koumbit.net* 

si ca échoue

Ca se peut que le daemon puppet meure pas quand vient le temps de démonter le $TARGET, ca va dire "cant umount /tmp/tmp.747743743 ".

Faut aller sur la machine ou ca a pêté et faire:

lsof | grep /tmp/tmp.asdfasfd 
kill 2233 # tuer le process puppet collé sur le répertoire
umount /tmp/tmp.asdfasdf
lsblk -i # trouver le disque qui fini par .disk0-1, faut passer le parent de ca
kpartx -d -p- /dev/mapper/data-aslkdfjakdsjf;aksjf;lksajdf.disk0 

Après ca ca devient possible de gnt-instance remove patatepoil sur le master.

... avec plusieurs ip

Voici la commande par exemple pour ajouter 3 ip.

# gnt-instance add -d -n venus.koumbit.net -o debootstrap+default -t plain \
--disk 0:size=56G --disk 1:size=4G -B memory=4G,vcpus=2 \
--net 0:ip=199.58.81.XXX,network=colo2-arin01.koumbit.net \
--net 1:ip=199.58.81.XXX,network=colo2-arin01.koumbit.net \
--net 2:ip=199.58.81.XX,network=colo2-arin01.koumbit.net \ 
FQDN.koumbit.net

... sur un autre VG

Et pour ne pas utiliser le VG par défaut, utiliser:

--disk 0:vg=ganeti-ssd,size=10G

source

création de vm sur le cluster du bureau

gnt-instance add -d -o debootstrap+buster -t plain \
 --disk 0:size=14G --disk 1:size=1G -B memory=1G,vcpus=1 \
 --net 0:ip=pool,network=local.office.koumbit.net \
 vps-interne.office.koumbit.net

création de vm avec d'autre OS / Version de debian

Modifier une vm

Un cluster ganeti vient avec une "politique d'instance" qui dicte certains minimums et maximums. Si on tente d'allouer plus de ressources que la politique à une VM en particulier, on obtiendra l'erreur suivante:

root@artemis:~# gnt-instance modify -Bmaxmem=8192M,minmem=8192M,vcpus=10 carotte.koumbit.net
Failure: prerequisites not met for this operation:
error type: wrong_input, error details:
Instance allocation to group {'name': 'default', 'tags': [], 'ipolicy': {}, 'serial_no': 4, 'ndparams': {}, 'diskparams': {}, 'mtime': 1415918128.467249, 'alloc_policy': 'preferred', 'networks': {'aa0bcc08-0c68-4d2b-a291-10c8462b8e12': {'link': 'br0', 'mode': 'bridged', 'vlan': ''}}, 'uuid': '41eb4c9e-b7af-49e1-a8c5-a15b077db97b'} (default) violates policy: cpu-count value 10 is not in range [1, 8]

Ici, la politique a un maximum de 8 vcpus et ne permet donc pas d'augmenter à 10.

La politique est soit au niveau du cluster, soit au niveau du groupe de nodes. Voir la section sur le cluster pour des commandes qui modifient la politique.

On peut forcer une modification malgré la politique d'instance. Ça permet d'allouer plus de ressources à une seule VM sans pour autant permettre aux autres d'augmenter autant. Pour faire ça, on ajoute un argument à la commande de modification, --ignore-ipolicy. Par exemple, pour allouer 10 CPUs malgré le maximum de 8:

gnt-instance modify --ignore-ipolicy -Bvcpus=10 asdf.koumbit.net

Réinstall de l'OS

# gnt-instance stop client-e.koumbit.net
# gnt-instance reinstall client-e.koumbit.net
# gnt-instance start client-e.koumbit.net

Hésitez pas a faire un gnt-node info pi a faire un  lvcreate --size 30G --snapshot --name client-e-snap data/666666666-6666-6666-6666-666666666.disk0  ; c'est mieux de faire ca que de passer la journée à gratter les 1 pi les 0 du fond du bit bucket.

RAM

Pour tout ce qui est cpu/ram, on peut modifier la config de xen via

confirmer la quantité de mémoire alloué.

# gnt-instance info asdf.koumbit.net | grep mem
    maxmem: 1024
    memory: default (1024)
    minmem: 1024

on fait la modification maintenant.

gnt-instance modify -Bmaxmem=4096M,minmem=4096M asdf.koumbit.net

Après ca, faut rebooter l'instance pour que la config de xen soit regénérée:

gnt-instance shutdown asdf.koumbit.net
gnt-instance start asdf.koumbit.net

core | vcpu

Si on veut changer la quantité de core alloué une instance.

On peut vérifier la quantité de core alloué avant de lancer la commande de modification:

# gnt-instance info asdf.koumbit.net | grep vcpus
    vcpus: X

on fait la modification maintenant.

gnt-instance modify -Bvcpus=X asdf.koumbit.net

X=le nombre de core qu'on désire allouer à l'instance.

Ajouter une interface réseau

Premièrement, assurez-vous de connaître le nom du réseau et de choisir une IP de libre dans ça.

gnt-instance modify --net -1:add,ip=192.168.0.123,network=internal.koumbit.net wpdev0.koumbit.net

Vous devez repartir l'instance si vous voulez que les changements soient pris en compte.

Ajouter une interface réseau privée à une instance

En gros, c'est juste d'allouer une ip sur le réseau interne (192.168.x.y)

Une fois l'IP choisie, voir #Ajouter une interface réseau pour la procédure à suivre.

Assigner/changer une IP à une interface réseau qui n'en a ou pas

C'est cette commande qui peut-être utilisé pour changer un ip principale d'une instance. (Notez que vous devez aller faire le modification à l'intérieur d'instance le fichier /etc/network/interface et /etc/hosts)

Comme considération préalable, on doit vérifier que la node qui contient l'instance concernée est bien dans le groupe de nodes nommé "default", ou bien que le groupe de nodes est connecté au réseau. Pour savoir dans quel groupe une node se trouve, on peut utiliser la commande:

gnt-node list -o +group

On veut d'abord retirer la réservation externe de l'IP sur le réseau, voir #Retirer des IPs réservées.

On peut ensuite assigner l'adresse IP à l'interface réseau avec une commande très similaire à l'ajout d'interface (on modifie l'interface au lieu d'en ajouter une):

gnt-instance modify --net 0:modify,ip=199.58.80.115,network=def0-arin00.koumbit.net apps.koumbit.net

Changer la taille des disques

Pour changer la taille des disques, voir la page GanetiStorageMaintenance

Autres options

D'autres options peuvent être changées (avec l'option -B pour toutes) mais on le fait moins souvent. Pour voir la liste des options, consulter man gnt-instance sous la section ADD.

Détruire

Attention: ceci va détruire la machine et toutes ses données. Arrêter la machine avant et laisser un peu de temps pour voir si personne crie. Suivre PratiquesDestructionServeur.

gnt-instance remove "$instance"

If you get:

Fri Sep 23 16:07:55 2016  - WARNING: Could not remove disk XX on node YYY, continuing anyway: Can't lvremove: exited with exit code 5 -   Logical volume ZZZZZ is used by another device.\n
Failure: command execution error:

do:

ssh YYYYYYY
kpartx -d /dev/ZZZZZZ

Another way to do deal with this error:

  1. (run on node) Get detailed info:

    dmsetup info -c | grep XX
    • example result:

      data-e041a516--b9d5--4039--988d--0032153671e4.disk0       253  14 L--w    1    1      0 LVM-jnpcaAmhjA3sJgEhcJvd0ium5SITKPs0LmfsJY97HnoedsO1xvVxdL5YprTBVPne
      data-e041a516--b9d5--4039--988d--0032153671e4.disk0p1     253  41 L--w    0    1      0 
  2. (run on node) The lvm disk0p1 seems to be a side-effect of our disk resize procedure; however, it seems to block destruction. It can be forcibly removed:

    dmsetup remove data-e041a516--b9d5--4039--988d--0032153671e4.disk0p1 
  3. (run on ganeti master)

    gnt-instance remove $instance

Déplacer une VM vers une autre node

Pour déplacer une VM instance.koumbit.net vers un autre serveur physique nouvelle-node.koumbit.net, on utilise la commande:

gnt-instance move -n nouvelle-node.koumbit.net instance.koumbit.net

Noter que cette opération vous demandera la configuration pour fermer l'instance avant de procéder au transfert. Une fois le transfert réalisé, l'instance demeure fermé, vous devez la démarrer.

Pour faire un transfert sans downtime, il faut utiliser DRBD.

Autres opérations

Ces opérations sont moins fréquentes...

Gestion de node

ajouter un node

Les étapes préalables sont plus complète ici: GanetiConfiguration#Ajouter_la_node_au_cluster

La commande la plus simple

# gnt-node add veles.koumbit.net

Sur le cluster interne, c'est moins simple....

Note: j'ai éditer le /etc/hosts pour éviter la résolution sur l'ip privé pour le host.

Ouin, c'était pas une super idée, on a maintenant des nodes avec le ip secondaire dans réseau publique et d'autres dans le réseau privé. Entécas.

De plus, il a des groupes, c'est bon de les lister avant d'aller plus loin.

# gnt-group list
Group   Nodes Instances AllocPolicy NDParams
2ips        1        17 preferred   ovs=False, ssh_port=22, ovs_link=, spindle_count=1, exclusive_storage=False, cpu_speed=1, ovs_name=switch1, oob_program=
default     4        20 preferred   ovs=False, ssh_port=22, ovs_link=, spindle_count=1, exclusive_storage=False, cpu_speed=1, ovs_name=switch1, oob_program=

la différence reste nébuleuse... entécas, en cas de doute mettre dans "default"

# gnt-node add -g default -s 192.168.0.135 athena.koumbit.net                                                                                                      
-- WARNING -- 
Performing this operation is going to replace the ssh daemon keypair
on the target machine (athena.koumbit.net) with the ones of the current one
and grant full intra-cluster ssh root access to/from it

The authenticity of host 'athena.koumbit.net (199.58.80.13)' can't be established.
ED25519 key fingerprint is 3d:e8:ae:77:8e:b8:da:de:b0:42:b2:c5:eb:e9:cf:65.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'athena.koumbit.net' (ED25519) to the list of known hosts.
2017-04-25 15:26:15,571: The certificate differs after being reencoded. Please renew the certificates cluster-wide to prevent future inconsistencies.
Tue Apr 25 15:26:22 2017  - INFO: Node will be a master candidate

Changer le master du cluster

On peut basculer de master avec la commande suivante en la roulant sur la node qu'on désire voir comme master.

# gnt-cluster master-failover
# # Aviser les autres admins du changement, parce que les fingerprints ssh changent sur l'ip du master!

  • Chaque cluster a un ip mobile qui se configure automatiquement sur le master. On n'a pas à changer d’enregistrement dns si on change le master.

Voir la documentation à ce sujet pour plus d'information sur ces rôles. Normalement, le failover est automatique, mais on voudra faire cette opération quand le master doit tomber en maintenance, par exemple.

Fermer/rebooter une node pour maintenance

On veut éviter de fermer/redémarrer le master d'un cluster à moins d'être dans un cluster avec juste une node. :)

On veut déménager la master vers la node qui restera en ligne quitte a le redéménager après la maintenance.

Le changement de master est une opération bien simple et qui va normalement bien.

Applicable autant avec ou sans drbd.

sans drdb

On doit fermer tous les instances de la lanode.koumbit.net

gnt-instance stop --node lanode.koumbit.net

Si on démarre tous les instances de la node.koumbit.net

gnt-instance start --node lanode.koumbit.net

avec drbd

Dans le meilleur des cas, une node peut être fermée sans downtime pour les instances. Pour faire celà il faut que toutes les instances sur la node utilisent DRBD et aient une node secondaire de configurée (ce qui n'est *PAS* le cas présentement). On évacue alors le serveur:

gnt-node evacuate moo.koumbit.net

Parfois, evacuate ne veut pas bien jouer, on peut migrer les instances "live" avec la commande

gnt-instance migrate <nom de l'instance>

Dans le cas où certaines (voir toutes les) instances n'utilisent pas DRBD, il faut faire une autre opération qui aura comme effet d'avoir un downtime pour les instances. Soit:

fermer manuellement les instances via le master avec:

gnt-instance shutdown --node moo.koumbit.net

OU déplacer les instances ailleurs (ici sur baa.koumbit.net) si notre but est de décommissionner le serveur ou le mettre offline pour une période prolongée. Il faut faire cette commande pour chaque instance. On peut également spécifier --submit comme argument pour ne pas attendre après la commande et simplement soumettre une job à ganeti:

gnt-instance move --submit -n baa.koumbit.net instance.koumbit.net

Après ça on peut fermer ou rebooter la machine. Lorsqu'elle est revenue online, on peut alors, si on veut, restransférer les instances sur cette node-ci avec gnt-instance failover. Il faut par contre se souvenir quelles nodes il faut failover parce qu'il n'y a pas de commande magique pour tout ramener comme avant. Une commande utile pour trouver les instances qui étaient précédemment sur la node en question est de lister les instances qui ont cette node comme node secondaire:

gnt-instance list --filter '"moo.koumbit.net" in snodes'

Retirer un serveur de l'allocation

Pour empêcher les nouvelles machines d'être créées sur un serveur, on le marque à drained avec -D yes:

gnt-node modify -D yes veles.koumbit.net

Mettre à no quand on veut recommencer à y mettre des machines, évidemment. source

Il faut noter que cette opération arrête la création de nouvelles VMs sur la machine mais ne touche pas les instances qui y roulent. Pour faire une maintenance sur le matériel physique, voir la commande gnt-node evacuate ou bien gnt-instance migrate (une condition pour ces deux commandes n'est présentement pas encore remplie: il faut que les instances utilisent DRBD).

Lister les serveurs retirés de l'allocation

Pour savoir quelles machines sont retirées de l'allocation pour les nouvelles VMs, on peut ajouter un champs dans la liste des nodes:

root@artemis:~# gnt-node list -o +drained
Node                 DTotal  DFree MTotal MNode MFree Pinst Sinst Drained
artemis.koumbit.net  696.5G 180.5G  24.0G  749M  976M     7     0 N
eros.koumbit.net       1.1T 627.2G  32.0G  749M  4.9G    10     0 N
minerve.koumbit.net    1.3T 116.9G  32.0G  749M  7.0G    10     0 Y
vania.koumbit.net    947.2G 342.2G  48.0G  749M  7.6G    15     0 N
veles.koumbit.net    231.8G  66.8G  16.0G  749M  4.0G     5     0 Y
venus.koumbit.net    947.2G 338.2G  48.0G  749M  8.6G    11     0 N
victoria.koumbit.net 947.2G 797.2G  48.0G  749M 38.6G     3     0 N

La colonne "Drained" indique une valeur de "Y" lorsque la machine est retirée de l'allocation.

Pour retirer une node du cluster (par exemple on veut réutiliser le matériel à d'autres fins)

Il est impératif de vider la node des instances qu'elle héberge avant d'aller plus loin. Mais si c'est déjà fait, ça va plus vite rouler les commandes quand la node est encore online. Sinon, c'est toujours possible...

root@artemis:~# gnt-node list
Node                 DTotal  DFree MTotal MNode MFree Pinst Sinst
artemis.koumbit.net  696.5G 180.5G  24.0G  749M  976M     7     0
eros.koumbit.net       1.1T 627.2G  32.0G  749M  4.9G    10     0
minerve.koumbit.net    1.3T 217.9G  32.0G  749M  7.0G     9     0
vania.koumbit.net    947.2G 342.2G  48.0G  749M  7.6G    15     0
veles.koumbit.net         ?      ?      ?     ?     ?     0     0
venus.koumbit.net    947.2G 338.2G  48.0G  749M  8.6G    11     0
victoria.koumbit.net 947.2G 632.2G  48.0G  749M 27.6G     8     0

Mettre la node offline

# gnt-node modify -C no -O yes veles.koumbit.net
Mon Jul 11 19:42:27 2016  - INFO: Ignoring request to unset flag master_candidate, already unset
Mon Jul 11 19:42:32 2016  - WARNING: Communication failure to node 4fdf2379-76ad-486a-8eea-eae6e8263ee0: Error 28: Connection timed out after 5092 milliseconds
Mon Jul 11 19:42:35 2016 Failed to stop KVM daemon in node '4fdf2379-76ad-486a-8eea-eae6e8263ee0': Node is marked offline
Modified node veles.koumbit.net
 - drained -> False
 - offline -> True

On retire la node!

# gnt-node remove veles.koumbit.net
Mon Jul 11 19:43:43 2016  - WARNING: Communication failure to node veles.koumbit.net: Error 28: Connection timed out after 5006 milliseconds
Mon Jul 11 19:43:48 2016  - WARNING: Errors encountered on the remote node while leaving the cluster: Error 28: Connection timed out after 5005 milliseconds
root@artemis:~# gnt-node list
Node                 DTotal  DFree MTotal MNode MFree Pinst Sinst
artemis.koumbit.net  696.5G 180.5G  24.0G  749M  976M     7     0
eros.koumbit.net       1.1T 627.2G  32.0G  749M  4.9G    10     0
minerve.koumbit.net    1.3T 217.9G  32.0G  749M  7.0G     9     0
vania.koumbit.net    947.2G 342.2G  48.0G  749M  7.6G    15     0
venus.koumbit.net    947.2G 338.2G  48.0G  749M  8.6G    11     0
victoria.koumbit.net 947.2G 632.2G  48.0G  749M 27.6G     8     0

Si la node est toujours présente fait la commande

# gnt-cluster verify

Rajouter des OS

La config par défaut se trouve dans /etc/default/ganeti-instance-debootstrap

Les variantes sont dans /etc/ganeti/instance-debootstrap

De la doc minimale est disponible à:https://nsrc.org/workshops/2014/bdnog1/raw-attachment/wiki/Track3Agenda/ex-ganeti-instance-debootstrap.htm

Ca implique gnt-os

J'ai pas réussi à faire installer le kernel + grub automagiquement, je l'ai fait à bras la dernière fois. Voir GanetiMaintenance#Monter_les_disques_d.27un_domU_dans_le_dom0

Y'a de la shit dans /usr/share/debootstrap/scripts

Gestion des réseaux (pools d'IPs)

Documentation incomplète, voir la documentation de gnt-network pour plus d'informations.

À noter aussi que l'on considère utiliser snf-network, voire même carrément Synnefo au complet, voir 16330 pour le suivi de ce projet.

Un pool d'IPs, nommé réseau dans ganeti, doit correspondre à un sous-réseau tel que découpé dans AllocationIp#ARIN. Plusieurs réseaux peuvent être connectés à un groupe de nodes pour permettre d'avoir plus d'IPs de disponibles.

Création et activation d'un réseau sur le cluster

Pour ajouter le pool d'IPs à un cluster, nous avons utilisé cette commande:

gnt-network add --network 199.58.81.128/25 --gateway 199.58.81.193  colo2-arin01.koumbit.net

Ceci ajoute 199.58.81.128/25 avec le gateway 199.58.81.193, sous le nom colo2-arin01.koumbit.net. D'autres blocs peuvent être alloués lorsque celui-ci est plein. Le nom du réseau dans ganeti doit correspondre au nom du réseau dans AllocationIp#ARIN.

Pour activer le réseau dans le cluster, on doit connecter le réseau à un groupe de nodes. On utilise généralement le groupe de nodes nommé "default". On doit bien prendre soin d'avoir le bon nom pour le bridge (on utilise généralement br0 pour le bridge principal et br1 pour le bridge secondaire)

gnt-network connect -N link=br0 colo2-arin01.koumbit.net default

Ensuite, on peut vérifier la configuration avec les commandes : gnt-network list et gnt-network info colo2-arin01.koumbit.net

Lister les réseaux sur le cluster

Pour voir la liste des réseaux qui sont disponibles sur un cluster:

# gnt-network list
Network                 Subnet         Gateway     MacPrefix GroupList                Tags
def0-arin00.koumbit.net 199.58.80.0/25 199.58.80.1 -         default (bridged, br0, )

Lister l'utilisation des IPs dans le réseau

gnt-network info

Les IPs marquées comme réservées de manière externe ont été manuellement réservées. Voir #Réservations d'IPs de manière externe. Les autres IPs sont assignées à des instances par ganeti soit lors de la création, soit en étant ajoutées à des instances après la création.

Réservations d'IPs de manière externe

gnt-network permet de marquer certaines IPs comme réservées pour que celles-ci soient retirées de la gestion automatisées (donc pour que ganeti ne puissent pas les allouer à des instances). Ça peut être utile pour marquer les IPs de l'équipement réseau, les machines physiques ou les IPs réservées pour du DHCP au autre cas similaire.

Réserver des IPs hors ganeti

Pour ajouter des IPs à la liste qui ne peuvent pas être utilisées par Ganeti pour des instances, on peut marquer les IPs comme étant réservées de manière externe dans le réseau concerné:

gnt-network modify --add-reserved-ips=199.58.81.129  colo2-arin01.koumbit.net

Pour en réserver plusieurs en même temps, l'argument à --add-reserved-ips peut être une liste d'IPs séparée par des virgules. Par exemple: gnt-network modify --add-reserved-ips=199.58.81.129,199.58.81.130  colo2-arin01.koumbit.net

Retirer des IPs réservées

À l'inverse, on peut retirer une IP des réservations externes pour la rendre disponible à l'utilisation de ganeti:

gnt-network modify --remove-reserved-ips=199.58.81.196 colo2-arin01.koumbit.net

De la même manière que pour l'ajout d'IPs, l'argument à --remove-reserved-ips peut être une liste séparée par des virgules (voir l'exemple dans l'ajout d'IPs)

Importer un VPS de Xen legacy

Pour importer les anciens nodes, il faut d'abord que le node soit master:

gnt-cluster master-failover

Le script d'importation, plus bas, va vérifier si le node est bien master avant de procéder (voir ce post pour la source).

Il faut ensuite s'assurer que Puppet ne gère plus les VPS, en retirant les définitions virtual::xen::domain::xenu de nodes.pp pour chaque node importé.

Finalement, on peut importer les nodes, un à la fois.

Avant de commencer la procédure ici il est important de vérifier que chaque VM a bien un kernel linux d'installé, sans quoi elle va refuser de booter à la fin du script d'import.

ssh apps.koumbit.net -- 'dpkg -l | grep linux-image'

Le script utilise des variables d'environnement pour spécifier le VG et le nom du 2eme bridge (ou 0 s'il n'y en a pas).

Il est important de réviser la valeur de ces deux variables d'environnement à chaque VM et de corriger s'il y a lieu.

root@cereales:~# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   749     8     r----- 4432635.6
apps.koumbit.net                            10  2048     4     -b---- 1763916.0
filet.koumbit.net                           25  2048     4     -b----     17.0
log.koumbit.net                             27  3068     4     -b----    261.8
pad0.koumbit.net                            17   512     1     -b---- 259463.2
postgres1.koumbit.net                       20  4089     4     -b---- 565412.1
rt.koumbit.net                              21  2041     4     -b---- 242391.3
scanner.koumbit.net                         22  1020     1     -b----  91101.8
root@cereales:~# export LVM_VG=data
root@cereales:~# export SECOND_BRIDGE=br1
root@cereales:~# # dans la commande suivante les arguments au script sont: nom du domU, RAM, nombre de VCPUs
root@cereales:~# /usr/local/sbin/gnt-xm-import apps.koumbit.net 2048     4
shutting down instance apps.koumbit.net
Domain apps.koumbit.net terminated
All domains terminated
mounting disk
overriding grub config
mkdir: impossible de créer le répertoire « /mnt/boot/grub »: Le fichier existe
editing fstab in place
diff --git a/fstab b/fstab
index b694c0f..a38c25d 100644
--- a/fstab
+++ b/fstab
@@ -2,6 +2,6 @@
 # <file system> <mount point>   <type>  <options>       <dump>  <pass>
 proc            /proc           proc    defaults        0       0
 devpts          /dev/pts        devpts  rw,noexec,nosuid,gid=5,mode=620 0  0
-/dev/xvda1 none swap sw 0 0
-/dev/xvda2 / ext4 errors=remount-ro 0 1
+/dev/xvdb none swap sw 0 0
+/dev/xvda / ext4 errors=remount-ro 0 1

diff --git a/hosts.deny b/hosts.deny
index a3e0f3d..f5f1228 100644
--- a/hosts.deny
+++ b/hosts.deny
[...]
importing into ganeti
Tue Aug 25 17:22:57 2015  - INFO: No-installation mode selected, disabling startup
Tue Aug 25 17:22:58 2015 * disk 0, size 39.0G
Tue Aug 25 17:22:58 2015 * disk 1, size 1.0G
Tue Aug 25 17:22:58 2015 adding instance apps.koumbit.net to cluster config
Tue Aug 25 17:23:00 2015  - INFO: Waiting for instance apps.koumbit.net to sync disks
Tue Aug 25 17:23:00 2015  - INFO: Instance apps.koumbit.net's disks are in sync
starting instance
Waiting for job 3844 for apps.koumbit.net ...
removing old configs
all done
use:
gnt-instance console apps.koumbit.net
... to inspect the machine

Notez bien comment des changements non-reliés peuvent apparaitre dans le diff. Il est possible que vous deviez appuyer sur q pour passer à la prochaine étape là où vous voyez [...] ci-haut.

Présentement, le script créé des machines avec deux interfaces réseau, sur br0 et br1. Il n'est pas possible de changer ce comportement sans éditer le script.

État du cluster : niveau d'utilisation

Avant d'aller créer des vm, on peut facile savoir l'état d'utilisation du cluster avec la command 'hscan -p' sur le serveur primaire du cluster.

root@artemis:~# hscan -p
Name  Nodes  Inst BNode BInst  t_mem  f_mem t_disk f_disk      Score
LOCAL     7    59     0     0 253826  75471   6293   2589 18.32974921
 F Name                 t_mem n_mem i_mem x_mem f_mem r_mem t_dsk f_dsk pcpu vcpu pcnt scnt p_fmem p_fdsk r_cpu   lCpu   lMem   lDsk   lNet
   artemis.koumbit.net  24570   749 22528   317   976     0   697   180    8   23    7    0 0.0397 0.2592  2.88  7.000  7.000  7.000  7.000
   eros.koumbit.net     32762   749 26624   418  4971     0  1151   627    8   25   10    0 0.1517 0.5448  3.13 10.000 10.000 10.000 10.000
   minerve.koumbit.net  32762   749 28576   354  3083     0  1372   116    8   29   10    0 0.0941 0.0852  3.63 10.000 10.000 10.000 10.000
   vania.koumbit.net    49119   749 39936   640  7794     0   947   372   24   46   15    0 0.1587 0.3930  1.92 15.000 15.000 15.000 15.000
   veles.koumbit.net    16378   749 11264   218  4147     0   232    66    8   14    5    0 0.2532 0.2883  1.75  5.000  5.000  5.000  5.000
   venus.koumbit.net    49116   749 38912   639  8816     0   947   338   24   43   11    0 0.1795 0.3571  1.79 11.000 11.000 11.000 11.000
   victoria.koumbit.net 49119   749  2048   638 45684     0   947   887   24   25    1    0 0.9301 0.9367  1.04  1.000  1.000  1.000  1.000

Exemple de résultat au 15 avril 2016

Une autre commande plus compacte peut aussi être utilisée. Elle donne moins d'information mais ça indique combien de disque et de ram libre il y a sur chaque node:

root@artemis:~# gnt-node list
Node                 DTotal  DFree MTotal MNode MFree Pinst Sinst
artemis.koumbit.net  696.5G 180.5G  24.0G  749M  976M     7     0
eros.koumbit.net       1.1T 627.2G  32.0G  749M  4.9G    10     0
minerve.koumbit.net    1.3T 116.9G  32.0G  749M  3.0G    10     0
vania.koumbit.net    947.2G 372.2G  48.0G  749M  7.6G    15     0
veles.koumbit.net    231.8G  66.8G  16.0G  749M  4.0G     5     0
venus.koumbit.net    947.2G 338.2G  48.0G  749M  8.6G    11     0
victoria.koumbit.net 947.2G 887.2G  48.0G  749M 44.6G     1     0

Simuler combien d'instances on peut crammer dans un cluster

On peut très bien calculer le nb d'instances qu'on peut continuer de créer sur un cluster, mais c'est pas mal de travail. A la place, on peut demander à Ganeti de faire la simulation pour nous!

Sur le master du cluster, on peut par exemple calculer combien d'instances chiquito (30Gb de disque, 2Gb de RAM, 1 vcpu) on serait capable de créer sur le cluster:

hspace -L --standard-alloc 30G,2G,1

La simulation respecte les règles d'allocation configurées dans Ganeti, et aussi les contraintes qu'on aurait pu instaurer par le "iallocator". Ça peut simuler aussi l'espace disque utilisé sur les nodes pour un autre type de stockage, du genre 'drbd' donc doubler l'espace disque mais en calculant exactement l'espace utilisé sur chaque node.

Renommer un cluster

Quand on renomme un cluster, il faut tout d'abord s'assurer que le hostname qu'on veut utiliser existe bien dans le DNS et pointe vers l'IP virtuelle du cluster avec un A record, que le PTR de l'IP virtuelle pointe bien sur le nouveau host, et imporant qu'il n'y ait pas d'entrée dans /etc/hosts qui rentre en conflit (par exemple si l'ancien nom du cluster est inscrit là, ganeti ne voudra pas renommer le cluster ou bien va faire des choses vraiment étranges).

Ceci va renommer un cluster:

gnt-cluster rename gntX.koumbit.net

Il faut que le DNS pour le nouveau nom pointe vers l'IP virtuelle du cluster avant de faire le changement.

Changer la politique d'instance

Un cluster a une politique d'instance qui défini un maximum pour certaines ressources. On ne peut pas allouer plus de ressources à une seule instance que ce que la politique décrit.

Pour voir les valeurs de la politique, on utilise gnt-cluster info et on cherche les valeurs suivantes (à la fin de l'output):

Instance policy - limits for instances: 
  bounds specs: 
    - max/0: 
        cpu-count: 8
        disk-count: 16
        disk-size: 1048576
        memory-size: 32768
        nic-count: 8
        spindle-use: 12
      min/0: 
        cpu-count: 1
        disk-count: 1
        disk-size: 1024
        memory-size: 128
        nic-count: 1
        spindle-use: 1
  std: 
    cpu-count: 1
    disk-count: 1
    disk-size: 1024
    memory-size: 128
    nic-count: 1
    spindle-use: 1
  allowed disk templates: plain, drbd
  vcpu-ratio: 4
  spindle-ratio: 32

On peut voir ici qu'on a entre autres un maximum de:

La commande suivante nous montre la même information mais dans un format plus facile ensuite pour faire des modifcations:

# gnt-cluster show-ispecs-cmd                                                                                                                         
gnt-cluster init --ipolicy-std-specs  \
  cpu-count=1,disk-count=1,disk-size=1024,memory-size=128,nic-count=1,spindle-use=1 \
  --ipolicy-bounds-specs \
min:cpu-count=1,disk-count=1,disk-size=1024,memory-size=128,nic-count=1,spindle-use=1/ \
max:cpu-count=8,disk-count=16,disk-size=1048576,memory-size=32768,nic-count=8,spindle-use=12 \
 commune.koumbit.net

Si on veut allouer plus de ressources à une seule VM, on peut changer cette politique. Ganeti (2.11.6) demande que l'on spécifie toutes les valeurs maximales de la politique en même temps. Par exemple pour agrandir les valeurs maximum (ici on pousse le nombre de CPUs à 12):

La commande suivante donne un erreur comme quoi la valeur nic-count n'existe pas, mais se plaint quand elle est manquante. C'est donc pratiquement impossible de modifier la politique d'instance.

gnt-cluster modify --ipolicy-bounds-specs max:cpu-count=12,max:disk-count=16,max:disk-size=1048576,max:memory-size=32768,max:nic-count=8,max:spindle-use=12

Il est avisé de mettre le min et le max quand on fait des changements, ici on veut passe le max d'espace disque à 2TB.

gnt-cluster modify --ipolicy-bounds-specs min:cpu-count=1,disk-count=1,disk-size=1024,memory-size=128,nic-count=1,spindle-use=1/max:cpu-count=8,disk-count=16,disk-size=2048576,memory-size=32768,nic-count=8,spindle-use=12

Geler une instance temporairement

/!\ C'est pas vraiment un service qu'on offre /!\

Hint: faut que les backups de la node soient configurés.

 dd if=/dev/SSDdata/ka.koumbit.net-disk bs=4096 | pv | gzip | ssh backup-minerve@alexandrie.koumbit.net 'tee > ka.koumbit.net.bin.gz' 

Débugging

Outils de vérification

Ganeti comporte plusieurs outils de vérification, exemple:

gnt-cluster verify
gnt-cluster verify-disks

etc.

Messages d'erreurs

sur les nodes

too many open files

Erreur sur un nouveau cluster en ganeti/kvm

root@b7:/var/log/ganeti# tail -f monitoring-daemon.log
ganeti-mond: /proc/sys/kernel/random/uuid: openFile: resource exhausted (Too many open files)
ganeti-mond: /proc/sys/kernel/random/uuid: openFile: resource exhausted (Too many open files)
ganeti-mond: /proc/sys/kernel/random/uuid: openFile: resource exhausted (Too many open files)
ganeti-mond: /proc/sys/kernel/random/uuid: openFile: resource exhausted (Too many open files)
ganeti-mond: /proc/sys/kernel/random/uuid: openFile: resource exhausted (Too many open files)
ganeti-mond: /proc/sys/kernel/random/uuid: openFile: resource exhausted (Too many open files)

[13/Jun/2018:20:30:59 -0400] got exception in httpAcceptFunc: accept: resource exhausted (Too many open files)
[13/Jun/2018:20:30:59 -0400] got exception in httpAcceptFunc: accept: resource exhausted (Too many open files)
[13/Jun/2018:20:30:59 -0400] got exception in httpAcceptFunc: accept: resource exhausted (Too many open files)
[13/Jun/2018:20:30:59 -0400] got exception in httpAcceptFunc: accept: resource exhausted (Too many open files)
[13/Jun/2018:20:30:59 -0400] got exception in httpAcceptFunc: accept: resource exhausted (Too many open files

Référence: 26995

On a la solution documenté dans la page GanetiConfiguration

le cluster ne se reconnait pas

Si tu fais ganeti instance console, et que ca se plaint parce que tu as changé la config de ssh, en fait, c'est pas la config de root qui est appliquée, c'est celle propre à ganeti.

genre: ssh-keyscan -t ecdsa phoque.koumbit.net >> /var/lib/ganeti/known_hosts

SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small

Mon Feb 27 21:34:14 2017 disk/0 failed to send data: Exited with status 1 (recent output: socat: E SSL_connect(): error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small\ndd: dd: error writing 'standard output': Broken pipe\ndd: error writing 'standard output': Broken pipe\n2+0 records in\n1+0 records out\n1114112 bytes (1.1 MB) copied, 10.0763 s, 111 kB/s)

Le bug et le workaround ainsi que le commit dans les versions plus récente: https://code.google.com/p/ganeti/issues/detail?id=1104#c8

sur le master:

# openssl dhparam -out dhparams.pem 2048
# cat dhparams.pem >> /var/lib/ganeti/server.pem

Ensuite, copier le nouveau fichier sur tous les nodes...

Pour vérifier qu'on a bien le même fichier partout maintenant:

gnt-cluster command md5sum /var/lib/ganeti/server.pem

c'est pas nécessaire de faire un restart du service ça l'air.

Référence de bug interne 22594

sur les instances

un instance est paused et ne démarre pas

$ xl list | grep alternc-dev
alternc-dev.koumbit.net                    158  2048     1     --p---       0.0

normalement, si un instance est en pause, on peu le démarrer avec xl unpause alternc-dev.koumbit.net, mais il se peut que d'autres choses arrivent.

Checker le log, /var/log/xen/xl-alternc-dev.koumbit.net.log, il se peut que c'est dans un loop de reboot:

Domain 182 has shut down, reason code 3 0x3
Action for shutdown reason code 3 is restart
Domain 182 needs to be cleaned up: destroying the domain
Done. Rebooting now
Waiting for domain alternc-dev.koumbit.net (domid 183) to die [pid 6905]
Domain 183 has shut down, reason code 3 0x3
Action for shutdown reason code 3 is restart
Domain 183 needs to be cleaned up: destroying the domain
Done. Rebooting now
Waiting for domain alternc-dev.koumbit.net (domid 184) to die [pid 6905]
Domain 184 has shut down, reason code 3 0x3
Action for shutdown reason code 3 is restart
Domain 184 needs to be cleaned up: destroying the domain
Done. Rebooting now
Waiting for domain alternc-dev.koumbit.net (domid 185) to die [pid 6905]
Domain 185 has shut down, reason code 3 0x3
Action for shutdown reason code 3 is restart
Domain 185 needs to be cleaned up: destroying the domain
Done. Rebooting now

En remontant dans un vieux log, il se peut que c'est lié à un fuck de lvm:

Domain 65 needs to be cleaned up: destroying the domain
Done. Rebooting now
libxl: error: libxl_device.c:310:libxl__device_disk_set_backend: Disk vdev=sda failed to stat: /var/run/ganeti/instance-disks/alternc-dev.koumbit.net:0: No such file or directory
Parsing config from /etc/xen/alternc-dev.koumbit.net
  1. Arrêter avec la force l'instance Xen:

    gnt-instance shutdown --force alternc-dev.koumbit.net
    • J'ai trouvé que ça peut prendre quelque reprises.
  2. Verifier que l'instance est bien down:

    ssh node.k.n xl list
    # L'instance de devrait pas être présent dans le output
  3. Fermer les disques de l'instance:

    gnt-instance deactivate-disks alternc-dev.koumbit.net
    • Verifier que la commande a roulé dans /var/log/ganeti/jobs.log / commands.log
  4. Start it back up:

    gnt-instance start alternc-dev.koumbit.net
  5. Checker node-daemon.log sur le noeud qui héberge l'instance voir qu'est ce qui roule.

@TODO: Ceci arrive pas a réparer le loop de reboot. Plus d'investigation nécessaire

une instance ne revient pas en ligne

En console, on a ce message :

[    2.073447] blkfront: xvda: flush diskcache: enabled
[    2.519662]  xvda: unknown partition table
[    2.520549] blkfront: xvdb: flush diskcache: enabled
[    2.529244]  xvdb: unknown partition table

La solution a été de fermer l'instance et la redémarrer.

unmount: target is busy / Logical volume data/...disk0 is used by another device

Le problème provient probablement du script d'installation de puppet avec ganeti.

Les messages d'erreur

  1. Lors de l'installation
    Mon Nov 26 11:23:19 2018 * running the instance OS create scripts...
    2018-11-26 11:29:44,941: gnt-instance add pid=19442 cli:2713 ERROR Error during command processing   ...
    ...
    eading state information...
    0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
    Fingerprint asked but no certificate nor certificate request have yet been issued
    PUPPET INSTALLED LOCAL KEY IS:
    Stopping puppet agent.
    setting root account password to: luther5urban$rank2flight+Bank
    in hook!
    stretch !
    E: Can not write log (Is /dev/pts mounted?) - posix_openpt (2: No such file or directory)
    done setting up security sources kernel
    Setting up swapspace version 1, size = 4194300 KiB
    no label, UUID=670a3acc-6138-4f0c-8507-a30571ad0467
    umount: /tmp/tmp.IRH9QPOtmM: target is busy
            (In some cases useful info about processes that
             use the device is found by lsof(8) or fuser(1).)
    umount: /tmp/tmp.IRH9QPOtmM: target is busy
            (In some cases useful info about processes that
             use the device is found by lsof(8) or fuser(1).)
  2. En essayant d'effacer la VM:
     # gnt-instance remove solidarity-us.koumbit.net
    This will remove the volumes of the instance solidarity-us.koumbit.net
    (including mirrors), thus removing all the data of the instance.
    Continue?
    y/[n]/?: y
    Mon Nov 26 11:44:50 2018  - WARNING: Could not remove disk 0 on node valerie.koumbit.net, continuing anyway: Can't lvremove: exited with exit code 5 -   Logical volume data/5a93efae-73fb-432e-b867-cf28a36918e7.disk0 is used by another device.\n
    Failure: command execution error:
    Can't remove instance's disks

Solution: Trouver le mount qui est resté collé, kill le process, et supprimer le device map.

On peut maintenant effacer la vm et recommencer, ou faire faire des manipulations sur le disque.


CategoryMaintenance

GanetiMaintenance (last edited 2019-08-18 00:02:24 by gabriel)