Rapports-Intervention/10-09-2018-Bascule-FAI,-Onduleurs,-Blade.md
... ...
@@ -1,46 +0,0 @@
1
-**Admins impliqués** : Guénolé Delanoë, Clément Courtel, Thomas Delaby, Grégoire Petit, Loïc Carr, Alexandre Manoury, Benjamin Somers, Clément Gasquet.
2
-
3
-## Bascule FAI vers Blue Services
4
-
5
-### Intro : ce qu'il aurait fallu faire
6
-
7
-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.
8
-
9
-Les opérations requises a priori pour basculer sans souci étaient les suivantes :
10
-
11
-1. Créer un VLAN entre le port de Blue Services sur Kuma et Zahia/Matahari (le 970 a été choisi)
12
-2. Créer l'interface VLAN correspondante dans `/etc/network/interfaces` sur Zahia/Matahari
13
-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
14
-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
15
-5. Changer les interfaces concernées par un basculement de firewall dans le script `/srv/qos/scripts/node-changed.sh`
16
-
17
-### Ce qui a été fait ... le début des ennuis
18
-
19
-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 :
20
-* keepalived ait basculé temporairement sur matahari
21
-* lorsque zahia est revenue en ligne, un basculement sur zahia s'est produit
22
-* 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
23
-
24
-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`.
25
-
26
-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.
27
-
28
-Afin de solutionner le problème, le port ethernet de Zahia sur Kuma a été désactivé et le trafic est passé sur Matahari.
29
-
30
-### Le problème avec net-acct
31
-
32
-Il a été constaté que net-acct sur Matahari produisait des logs incohérents ou pas de logs du tout.
33
-
34
-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).
35
-
36
-### Résolution des problèmes
37
-
38
-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.
39
-
40
-### Impact utilisateur
41
-
42
-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.
43
-
44
-## Investigations onduleurs
45
-
46
-
Rapports-Intervention/ri-10-09-2018-Bascule-FAI,-Onduleurs,-Blade.md
... ...
@@ -0,0 +1,46 @@
1
+**Admins impliqués** : Guénolé Delanoë, Clément Courtel, Thomas Delaby, Grégoire Petit, Loïc Carr, Alexandre Manoury, Benjamin Somers, Clément Gasquet.
2
+
3
+## Bascule FAI vers Blue Services
4
+
5
+### Intro : ce qu'il aurait fallu faire
6
+
7
+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.
8
+
9
+Les opérations requises a priori pour basculer sans souci étaient les suivantes :
10
+
11
+1. Créer un VLAN entre le port de Blue Services sur Kuma et Zahia/Matahari (le 970 a été choisi)
12
+2. Créer l'interface VLAN correspondante dans `/etc/network/interfaces` sur Zahia/Matahari
13
+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
14
+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
15
+5. Changer les interfaces concernées par un basculement de firewall dans le script `/srv/qos/scripts/node-changed.sh`
16
+
17
+### Ce qui a été fait ... le début des ennuis
18
+
19
+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 :
20
+* keepalived ait basculé temporairement sur matahari
21
+* lorsque zahia est revenue en ligne, un basculement sur zahia s'est produit
22
+* 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
23
+
24
+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`.
25
+
26
+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.
27
+
28
+Afin de solutionner le problème, le port ethernet de Zahia sur Kuma a été désactivé et le trafic est passé sur Matahari.
29
+
30
+### Le problème avec net-acct
31
+
32
+Il a été constaté que net-acct sur Matahari produisait des logs incohérents ou pas de logs du tout.
33
+
34
+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).
35
+
36
+### Résolution des problèmes
37
+
38
+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.
39
+
40
+### Impact utilisateur
41
+
42
+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.
43
+
44
+## Investigations onduleurs
45
+
46
+