Une vérification de disque peut rallonger énormément la durée du redémarrage. Vérifier :

df | awk '/^\/dev/ {print $1}' | xargs -I {} sh -c 'echo {}; tune2fs -l {}' | awk '/^\/dev/ {print $1} /^Filesystem state/ {print $3, " ",$4}'

Ouvrir une action de maintenance sur https://status.chapril.org/ :

• utiliser le modèle reboot cluster ;
• renseigner When is this maintenance scheduled for? ;
• ne pas remplir When did this maintenance complete? ;
• cocher Notifier les abonnés ?.

Envoyer un courriel aux listes :

From: François Poulain <fpoulain@metrodore.fr>
To: chapril@april.org
Subject: [Chapril] Reboot du cluster
Date: Sun, 4 Mar 2018 15:25:18 +0100
Reply-To: chapril@april.org
Sender: chapril-request@april.org
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)

Coucou,

Je vais rebooter le cluster pour tenir compte du dernier upgrade
noyal de sécurité.

François

-- 
François Poulain <fpoulain@metrodore.fr>

À l'aide du compte https://pouet.chapril.org/@chapriladmin :

Nous allons redémarrer les serveurs de notre Chapril https://chapril.org pour tenir compte des mises à jour.

L'opération prendra environ 30 minutes, durée pendant laquelle les services seront indisponibles.

Vérifier qui est présent sur les vm :

cluster_guests='admin bastion dns drop lamp libreoffice mail pad pouet sympa valise xmpp'
for guest in $cluster_guests ;
do
    echo "===== $guest ====="
    cmd='for i in $(ps auxwww|grep "\-bash" | awk '\''{ print $2 }'\'' ); do cat "/proc/$i/environ" ; done 2>/dev/null |strings |grep GIT_AUTHOR_NAME | sort | uniq'
    ssh root@$guest.cluster.chapril.org "$cmd"
done

Pour le cas où un animateur travaillerait sur sa vm sans avoir vu ni le courriel ni status.chapril.org, envoyer un avertissement sur chaque machine.

./do.sh "wall 'Bonjour. Reboot SI Chapril à 13h15. Cpm.'"

• Mettre les hosts concernés en downtime
• Propager les downtimes en questions sur les services des hosts.

Le script suivant peut être utilisé pour couper le monitoring sur les hôtes et propager les downtimes sur les services hébergés. Les identifiants sont définis dans le fichier /etc/icinga2/conf.d/api-users.conf sur la machine admin.cluster.chapril.org, l'utilitaire jo (paquet Debian) est requis.

curl -k -s -S -i -u ${ICINGA_USER}:${ICINGA_PASSWORD} -H 'Accept: application/json' \
 -X POST 'https://icinga.chapril.org:5665/v1/actions/schedule-downtime' \
 -d "$(jo -p \
        pretty=true \
        type=Host \
        filter="match(\"coon*\", host.vars.hote)" \
        all_services=true \
        author="${GIT_AUTHOR_NAME}" \
        comment="Coon upgrade maintenance" \
        fixed=true \
        start_time=$(date +%s -d "+0 hour") \
        end_time=$(date +%s -d "+1 hour"))"

Noter la liste des VM actives pour comparer avec après le redémarrage.

# virsh list

Coon est lié à Maine par DBRD, il y a donc une procédure à suivre pour rebooter proprement.

Arrêter les VM :

cd /etc/libvirt/qemu
for host in $(ls *xml | sed -e 's/.xml//g') ; do virsh shutdown $host ; done; watch virsh list

ou bien :

cd /etc/libvirt/qemu
for host in $(ls *xml | sed -e 's/.xml//g') ; do virsh shutdown $host ; done; sleep 20;
for host in $(ls *xml | sed -e 's/.xml//g') ; do virsh destroy $host ; done

Arrêter DRBD :

umount /var/lib/libvirt/coon
drbdadm disconnect maine
drbdadm secondary coon
drbdadm disconnect coon

Redémarrer :

reboot

Attendre que le système ait fini de démarrer (état à running) :

watch "systemctl status | grep State | head -1"

Démarrer DRBD :

drbdadm primary coon
mount /var/lib/libvirt/coon

Démarrer les VM :

cd /etc/libvirt/qemu
for host in $(ls *xml | sed -e 's/.xml//g'| grep -v modele) ; do virsh start $host ; done

Ne pas s'inquiéter : seuls les machines de coon vont démarrer ; sauf si /var/lib/libvirt/maine est monté, mais ce ne serait pas normal.

virsh list

Et comparer à la liste avant reboot.

Parfois les vm démarre mais en statut « degraded ». Il convient de vérifier par un :

./do.sh "systemctl status | head -2"

Et pour les vm n'ayant pas un statut « running », faire la commande suivante pour identifier le service en souffrance :

systemctl list-units

Si un problème subsiste alors les sondes devraient le faire apparaître dans Icinga. Vérifier que les alertes actives sont acceptables.

Éditer l'action de maintenance :

• Status : sélectionner complete ;
• When did this maintenance complete? : mettre la date et horaire de fin.