Created ri 07 05 2018 perte debora nikita deja down (markdown)

+## État:

+L'infrastructure est rétablie à l'état précédent (`Debora` est up. Nikita est down).

+

+## Administrateurs impliqués :

+Bruno MATEU, Clément COURTEL, Guénolé DELANOE, ainsi que les précieux conseils de @blu et @thaurus

+

+## Description du problème:

+

+Le 06/05/2018, vers 20h, tous les services du Resel héergés au i11 sont tombés en même temps. Il a rapidement été constaté que l'hyperviseur `Debora` ne répondais plus aux ping sur son interface admin.

+L'hyperviseur `nikita` étant en rade depuis 3 jours, toute la stack est tombée d'un coup et nous avons perdu tous les services hébergés dans le cluster proxmox du i11.

+

+## Processus de résolution:

+

+- Seules personnes présentes physiquement à Brest, Clément et Guénolé ont expérimenté des problèmes pour se connecter au KVM de Ronflex, aux dernières nouvelles ils n'ont pas réussi à s'y connecter une seule fois.

+

+ - Bruno s'est connecté à Debora grace à la console virtuelle de la carte iDRAC de `Debora`, et a constaté grace à la commande `ip addr` que toutes les interfaces réseau de `Debora` étaient soit `DOWN`, soit `UNKNOWN`.

+ - L'état de ces interfaces réseau n'a pas évolué en les forcant à être up avec la commande `ip link set <addrName> up`.

+

+Suspectant les switchs, nous avons essayé de nous connecter à ceux du blade (`graou` et `patou`). Plusieurs probèmes ont été rencontrés :

+

+ - `graou` ne répond pas aux pings sur son interface d'administration, il a donc été présumé coupable de l'état des interfaces de Debora

+ - `patou` réponds aux pings, on peut se ssh dessus mais impossible de s'y connecter, le mot de passe du compte `admin` étant inconnu (et le radius étant en rade, comme toute la stack d'hypervision était down, impossible d'utiliser son compte admin).

+

+Graou a été redémarré dans l'espoir d'améliorer la situation mais rien n'a changé.

+

+Bruno a réussi à se connecter à `graou` en série depuis `ronflex` : `racadm connect -m switch-<slot>` en remplacant <slot> par le slot du switch (b1 pour graou).

+Le switch paraissait alors en bon état de fonctionnement, et son interface connectée à `debora` était up.

+

+Un peu de workaround et de lecture du `/etc/network/interfaces` et de recherche a permis de comprendre comment étaient configurées les intrerfaces réseau de Debora, et ainsi de comprendre que `graou` ne servait qu'a faire la connection entre `debora` et `sanizator` (subnet 172.22.5.0/heuuu...24 je pense?)

+Il a aussi été remarqué que cette interface réseau était up. Je ne sais pas si elle l'était depuis le début et que je ne l'ai pas remarqué (la console virtuelle du DRAC étant particulièrement pérave, je n'ai pas été aidé pour lire l'output des commandes), ou si le reboot du switch a corrigé ce problème.

+

+La faute s'est donc retrouvée sur `patou`, dont on ne possède pas le mot de passe root. Un reboot de `patou`, un peu déséspéré, a été tenté, mais suite au reboot la commande `ip link set eth0 up && ip link set vmbr1 up` a cette fois-ci renvoyé un résultat positif, et la machine a été re-connectée au réseau.

+

+La stack d'hypervision s'est progressiement remise en route et quelques heures plus tard tout était à nouveau en bon état de fonctionnement.

+

+

+## Notes importantes:

+

+ - Le mot de passe du compte admin de `patou` est toujours inconnu. Il faut le changer

+ - Le switch `graou` ne réponds toujours pas sur son ip d'administration, et la seule manière pour s'y connecter est depuis le CMC du chassis (`ronflex`)

+ - La seule chose qui se trouve dans les logs du switch est une vingtaine de:

+```

+01:19:58: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected on Gi0/17. A packet filter action has been applied on the interface.

+```

+mais le NTP du switch étant complètement à la ramasse impossible de dire si c'estl ié ou non à la panne, mais le peu de logs dans le switch me fait me demander si le reboot du switch n'a pas wipe les logs.

+ - Du coup on ne sais pas du tout ce qui a causé ce problème.