Rapport d'interventions portant sur le weekend du 8 et 9 septembre 2018 : bascule FAI, configuration d'onduleurs, expériences réseau blade, tests de lames

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 :

  1. Créer un VLAN entre le port de Blue Services sur Kuma et Zahia/Matahari (le 970 a été choisi)
  2. Créer l'interface VLAN correspondante dans /etc/network/interfaces sur Zahia/Matahari
  3. 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
  4. 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
  5. 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.

Investigations onduleurs