Hintergrund: RZ Bern Ausfall von gestern

[Daniel Baumann]

Hallo zusammen

Hier unser Bericht zum RZ Ausfall von gestern fuer die technisch
Interessierten und fuer uns zur Dokumentation.


1. Kurzfassung (Management summary)
===================================

  * zur Ausgangslage bzgl. des Ausfalls vom Montag des Cisco Nexus
    Switches siehe vorherige Mail:


https://lists.bfh.science/pipermail/bfh-linux-announce/2022-March/000164.html

  * Als gestern um 10 Uhr der Leih-Nexus mit dem noch verblieben Nexus
    verbunden wurde, wurde:

    - weil unvollstaendige Backup/Restore der Konfiguration,

    - verbunden mit der Altlast des verwendeten legacy
      High-Availability Modus der Nexus-Switches,

    alle VLANs im Cage-B automatisch dekonfiguriert worden.

  * Dadurch war das gesamte BFH.ch RZ im Cage-B offline. Ab 11 Uhr
    waren alle VLANs wieder konfiguriert, die meisten Systeme liefen
    wieder. Da einige VMs noch manuell ueberprueft/rebootet wurden,
    waren alle Dienste ab 13 Uhr wieder uneingeschraenkt nutzbar.


2. Hintergrund
==============

2.1 Vorbemerkungen
=-=-=-=-=-=-=-=-=-

2.1.1 Cisco vPC
---------------

  * Wenn man (wie bei uns) zwei Cisco Nexus Switches hat, moechte man
    dass diese redundant/high-available sind, so dass wenn ein Geraet
    ausfaellt, das andere uebernimmt und es zu keine Netzwerkunterbruch
    oder -ausfall kommt (so geschehen am Montag).

  * Bei Nexus Switches wird dies ueber "Cisco virtual Port Channel
    (vPC)"-Feature implementiert (Nexus unterstuetzen weder Stacking
    noch Virtual Switching System (VSS) und sind diesbezueglich im
    Cisco-Portfolio etwas "speziell").

  * Cisco vPC ist ein Modus, bei dem "nur" die globale Konfiguration der
    Switches zwischen den zwei Geraeten ueber einen dezidierten Link
    (MLAG) hin und her synchronisiert wird, ansonsten verhalten sich
    die Switches als normale, einzelne Systeme (das im Gegensatz zu
    VSS oder Stacking, wo sich das Gesamtsystem wie ein einzelnes
    grosses System mit einer einzigen Gesamtkonfiguration verhaelt).

  * vPC hat zwei Betriebsmodi:

    - primary/secondary (legacy): jedes Geraet hat eine eigene
      lokale Konfiguration-"Instanz", jedoch ist ein Geraet bzgl. der
      globalen Konfiguration der primary und ueberschreibt die
      Konfiguration auf dem anderen Geraet.

    - active/active (normal): beide Geraete haben zusammen nur eine,
      gemeinsame globale Konfiguration-"Instanz".


2.1.2 Cisco Konfigurations-Scope
--------------------------------

  * Alle Cisco Switches haben eine ensprechende Konfiguration. Dort
    sind alle Einstellungen des Geraetes enthalten, einerseits globale
    Einstellung als auch die per-Interface (d.h. pro Netzwerkport)
    spezifischen Einstellungen.

  * Bei Cisco Nexus Switches ist dies etwas anderst, es gibt
    grundsaetzlich drei verschiedene "Hierarchien" innerhalb der
    Konfiguration:

    - globale Einstellungen
    - VLAN Einstellungen
    - Interface Einstellungen

  * Im Falle von vPC werden werden nur globale Einstellungen und VLAN
    Einstellungen synchronisiert. Die lokalen Interface Einstellungen
    werden (korrekterweise) nicht synchronisiert, da die ja bei beiden
    Geraeten unterschiedlich sind.


2.1.3 Nexus Konfigurations-Backup
---------------------------------

  * Bei allen Switches aus gesamten Cisco Palette kann mit dem Kommando
    "show running-config" die gesamte Konfiguration angezeigt werden.

  * Bei allen Cisco Geraeten an der BFH wird die Konfiguration bei
    Aenderung automatisch und (unabhaengig von allfaelligen Aenderungen)
    alle 3 Stunden automatisch in ein Git Repository gebackupt. So
    koennen wir bei einem Ausfall jeweils auf die letzte aktuelle
    Konfiguration zurueckgreifen.

  * Im Gegensatz zu allen anderen Cisco Switches, sind die Nexus
    Switches auch hier wieder einzigartig: Es gibt kein Kommando mit dem
    man die Gesamtkonfiguration anzeigen kann - es wird jeweils nur die
    globale Konfiguration und die Interface Konfiguration ausgegeben,
    nicht aber die VLAN Konfiguration(!).

  * Einzige Moeglichkeit, die Gesamtkonfiguration zu erhalten, ist durch
    das Dumpen der Konfiguration auf eine Datei auf dem Switch, und
    diese dann "manuell" wegzukopieren.


2.2 Was ist gestern genau passiert?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

2.2.1 Konfigurations-Backup/Restore Fail
----------------------------------------

  * Wir haben dem externen Cisco-Engineer die letzte Konfiguration des
    ausgefallen Nexus-Switches gegeben um diese auf dem Leih-Nexus zu
    restoren.

  * Der im Cisco-Umfeld einzigartige Umstand der Nexus Switche mit
    unvollstaendigen Konfigurations-Backups (wenn basierend auf
    "show running-config") hat dazu gefuehrt, dass das Backup nur die
    globale und Interface-Konfiguration, nicht aber die VLAN
    Konfiguration enthaelt.

  * Der Restore der Konfiguration auf dem Leih-Nexus hat damit dazu
    gefuehrt, dass der Switch *keine* VLANs konfiguriert hatte.

  * Haetten wir die Konfiguration (~1700 Zeilen) vor dem Restore noch
    kontrolliert, waere es vielleicht aufgefallen, dass darin nicht
    enthalten waren :/


2.2.2 vPC Fail
--------------

  * Nachdem der Leih-Nexus gestern eingebaut wurde, hat der externe
    Cisco-Engineer die beiden Nexus wieder miteinander verbunden.

  * Die Nexus Switches wurden damals (2011) initial aufgesetzt,
    abgesehen von einem Firmware-Update in 2014 und 2020 nie mehr
    angefasst/weiterentwickelt - sie befinden sich, konfigurativ,
    immer noch im urspruenglichen Ausgangssetup von damals.

  * Abweichend von Best Practise (= "active/active") und aus
    wohl aus historischen Gruenden wurden die Switches damals im
    "primary/secondary" vPC-Modus aufgesetzt, das laut Cisco immer
    wieder zu Problemen fuehrt und (schon lange) nicht mehr benutzt
    werden sollte.

  * Das dadurch bei einem Wiederaufbau eines zuvor unterbrochenen vPC-
    Konstruktes der eine Switch die Konfiguration des anderen
    ueberschreibt, ist uns (damals von anderen Externen durchgefuehrten)
    seit dem im Dezember 2020 durchgefuehrten Firmware-Update und den
    damit erlebten Komplikationen bekannt:


https://lists.bfh.science/pipermail/bfh-linux-announce/2020-December/000093.html

  * Wir haben den externen Cisco-Engineer nur "lose" bei dessen Arbeit
    begleitet und sind davon ausgegangen sind, dass er den Umstand des
    "primary/secondary statt active/active" bzgl. vPC beachten wird.

  * Leider war der ausgefallene Nexus der primary, so dass der Leih-
    Nexus nach dem Konfigurations-Restore (ohne VLAN Konfugration)
    dem anderen, noch funktionierenden secondary Nexus die Konfiguration
    ueberschrieben hat und dort alle VLANs dekonfiguriert hat.

  * Nachdem das ganze BFH.ch RZ offline war, hat der externe Cisco-
    Engineer praktisch sofort erkannt was das Problem war (Respekt!)
    und die VLANs manuell nochmal nachkonfiguriert.

  * Da durch den Unterbruch VMware (Virtualisierungsplattform) von
    NetApp (Storage) getrennt war, mussten nach Wiederherstellung der
    Netzwerk-Verbindungen noch einige VMs rebootet werden.


2.3 Was haette man besser machen koennen? (Lessons learned)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  * Wir haben fuer uns folgende Schluesse gezogen/Massnahmen umgesetzt:

    - fuer den Fall, dass wir bis zur Abschaltung der Nexus Switches
      am 30.6.22 nochmals auf externe Cisco-Engineers in Anspruch nehmen
      wuerden, so ist eine vorgaengige, detailiertere Besprechung als
      auch eine engere, pro-aktivere Begleitung des externen Cisco-
      Engineers notwendig.

      Das ist besonders wichtig weil das Cisco-Netz historisch gewachsen
      ist und die meisten Geraete-Konfigurationen und -Setups sehr
      uneinheitlich sind (jedes System ist eine einzigartige und
      manuelle "Perle", statt automatisiert und standartisiert).

    - vollstaendiges Backup (inkl. VLAN Konfiguration) der Nexus-
      Switches ist essenziell.


3. Schlussbemerkungen
=====================

  * Wir haben zwei gleich alte, identisch lang laufende Nexus Switches
    im Einsatz. Wenn einer davon ausfaellt, ist die Wahrscheinlichkeit
    gross, dass der zweite auch kurzum ausfallen kann/wird.

  * Im Gegensatz zum neuen Netz (wo wir aus diversen Gruenden, u.a.
    Performance aber auch Resillience) eine Netzwerk-Architektur mit
    (fuer die kritischen Systeme) 4facher und (allgemein) verteilter,
    dezentraler Redundanz aufgebaut haben, ist das alte Netz sehr
    anfaellig fuer den Ausfall von einzelnen Systemen.

  * Waere der zweite Nexus ausgefallen, haetten wir einen mehrtaegigen
    bis mehrwoechigen Totalausfall des Gesamt-Netzwerkes gehabt.

  * Wenn also beim zentralen RZ Switch keine Redundanz mehr gegeben
    ist und der noch laufende Switch schon "angezaehlt" ist, gilt es zur
    Risikominimierung und Abwendung einer solchen Totalkatastrophe
    unverzueglich zu handeln.

  * Deshalb haben die IT-Services am Montag Abend entschieden, die
    Inbetriebnahme des Leih-Nexus nicht auf eine Randzeit aufzuschieben,
    sondern unmittelbar am naechsten Morgen vorzunehmen. Die Risiko-
    Abwaegung zwischen Totalausfall in Kauf nehmen vs. ggf.
    Komplikationen beim Austausch fiel zu Gunsten des Austausches aus.

    Ausserdem war der naechste moegliche Termin mit dem Cisco-Engineer
    erst Donnerstag/Freitag moeglich - was im gegeben Kontext sehr lange
    ist und das daraus resultierende Risiko nicht uebernommen werden
    konnte.

  * Trotz all der Unannehmlichkeiten und Aufwaende des Ausfalls bei den
    Nutzenden in den Departementen und auch unseren Kolleginnen und
    Kollegen innerhalb der IT-Services (grosses Dankeschoen an alle
    Teams der ITS!), sind wir insgesamt nochmal mit einem "blauen Auge"
    davon gekommen.

  * Wir entschuldigen uns bei allen Betroffenen und freuen uns,
    bis im Sommer die komplette RZ Netzwerk-Architektur migriert zu
    haben, bei welchen wir solche (und andere) "Schwierigkeiten"
    von Beginn weg konzeptionell ausgeschlossen haben.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
Services / IT-Services
Daniel Baumann
Teamleiter Linux & Infrastructure Services
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science