Admins impliqués : Guénolé Delanoë, Clément Courtel, Thomas Delaby, Grégoire Petit, Loïc Carr, Alexandre Manoury, Benjamin Somers, Clément Gasquet.
Bascule FAI vers Blue Services
Intro : ce qu'il aurait fallu faire
Le nouvel accès Internet Blue Services ayant été livré le jeudi soir, il a été décidé d'une bascule dans la foulée.
Les opérations requises a priori pour basculer sans souci étaient les suivantes :
- Créer un VLAN entre le port de Blue Services sur Kuma et Zahia/Matahari (le 970 a été choisi)
- Créer l'interface VLAN correspondante dans
/etc/network/interfaces
sur Zahia/Matahari - Copier/coller le fichier
/srv/qos/conf/qos_brest_adista.conf
et remplacer les noms d'interfaces et les adresses IP là où c'était nécessaire - Copier/coller le fichier
/srv/qos/scripts/switch_to_adista.conf
et remplacer les noms d'interfaces et les adresses IP là où c'était nécessaire - Changer les interfaces concernées par un basculement de firewall dans le script
/srv/qos/scripts/node-changed.sh
Ce qui a été fait ... le début des ennuis
Un service networking restart
a été exécuté sur Zahia après avoir configuré la nouvelle interface réseau. En raison d'un renommage des fichiers de configuration QOS en qos_brest_adista.conf.backup
, et à cause de ce redémarrage réseau, il est très probable que :
- keepalived ait basculé temporairement sur matahari
- lorsque zahia est revenue en ligne, un basculement sur zahia s'est produit
- mais la configuration des connexions internet était mauvaise à cause des noms de fichiers, ce qui a poussé le
healthchecker
à basculer sans cesse entre les deux connexions internet
D'autre part, le script node_changed.sh
n'avait pas été correctement modifié, provoquant lors du basculement la remontée de l'interface vers Adista, mais pas de celle vers Blue Services. Le fichier de configuration qos n'était plus disponible à cause du nom qos_brest_adista.conf.backup
.
Il a été observé un basculement intempestif entre matahari et zahia, qui reste à ce jour inexpliqué puisque le lien entre les deux machines via le VLAN997 était toujours fonctionnel.
Afin de solutionner le problème, le port ethernet de Zahia sur Kuma a été désactivé et le trafic est passé sur Matahari.
Le problème avec net-acct
Il a été constaté que net-acct sur Matahari produisait des logs incohérents ou pas de logs du tout.
Ce point a été investigué par @dimtion. La cause première semble être une mauvaise gestion par net-acct des interfaces nommées en eno* (nouvelles versions de Debian).
Résolution des problèmes
Avec l'aide d'Alexandre Manoury "Pika" et Loïc Carr, on a pu se rendre compte que tous les fichiers importants n'avaient pas été correctement modifiés comme écrit dans l'introduction.
Impact utilisateur
Une coupure de service partielle ou totale a eu lieu le samedi 8 septembre entre 11h et 16h. L'impact était limité en raison du Weekend d'Intégration.