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

De l'importance d'un parc ondulé et configuré

Il a été constaté a de multiples reprises que si le parc de machines du ResEl est ondulé au i1 et i11, la configuration logicielle des machines n'a pas été faite afin de déclencher une extinction propre en cas de coupure de courant.

Cela a probablement été la cause de nombreuses pannes de disques durs, corruptions de RAID, pannes d'équipements réseau, etc.

Le technopôle subit environ 2 à 3 coupures par an, et à chaque fois, tout le parc se coupe brutalement.

apcupsd

Le logiciel apcupsd s'installe facilement sur Debian et sert justement à surveiller l'état des onduleurs APC à travers un câble USB ou une liaison série. Il est aussi possible d'écouter via le réseau ce qu'un autre apcupsd, ce dernier connecté à un onduleur, raconte à son sujet.

apcupsd n'est configuré correctement sur aucune machine.

Il a été découvert lors des investigations que les deux onduleurs du i11, des SURT3000XL, sont définitivement incompatibles avec apcupsd.

Actions entreprises

Les deux onduleurs du i1, des SmartUPS 750, supportent très bien apcupsd. Un test a été fait sur Kyubey. La commande d'arrêt envoyée par apcupsd entraîne l'arrêt propre de toutes les VM gérées par Proxmox, lorsque le niveau de batterie du SmartUPS atteint un niveau critique.

Les alimentations des machines du i1 ont par ailleurs été disposées à l'équilibre entre les deux onduleurs SmartUPS 750 indépendants.

Propositions pour une extinction automatique au i11

On peut utiliser apcupsd sur Camille, Nikita, Debora en mode "client" : il écouterait le démon qui tourne sur Kyubey. Problème : si le i1 est coupé mais pas le i11, tout le parc s'éteindra quand même. Autre problème : la capacité de batterie au i11 est supposée moindre qu'au i1. Dans ces conditions, apcupsd attendra trop longtemps au i11 par défaut pour lancer la séquence d'extinction.

On peut envisager de modifier au i11 le temps maximum sur batterie pour pallier ce problème. De même, il est possible de personnaliser le script exécuté par apcupsd pour envoyer à des équipements réseau (kuma) une commande d'arrêt (puisque kuma ne supporte pas a priori apcupsd.

Si l'on s'autorise des achats. On peut acheter des cartes Ethernet de supervision pour les vieux onduleurs du i11 qui disposent d'un "Smart Slot". Ils exposeront alors une interface SNMP sur le réseau, que apcupsd sait gérer. Sinon, on peut envisager le remplacement d'un des deux onduleurs (pas du luxe au vu de leur âge), mais cela coûte cher pour avoir des modèles de même puissance (3000VA).

Débat : onduleur ON-line ou IN-line

Je laisse la parole aux experts en génie électrique, mais en gros la problématique est résumée par ce document d'APC : http://www.apc.com/salestools/JSII-5YQSBR/JSII-5YQSBR_R0_FR.pdf

Investigations sur le blade Ronflex