É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 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.