Zwei Switche sind noch keine Redundanz
Im Dezember gab es eine geplante Abschaltung. Elektroarbeiten im Gebäude, alles herunterfahren, alles wieder hochfahren. Alles — bis auf einen der beiden SAN-Switches. Der kam nicht wieder. Lüfter auf hundert Prozent, kein Webinterface, Bootschleife.
Das war im Dezember. Als ich im August in die Fernwartung kam, hing er immer noch da.
Vergessen hatte es niemand. Es hatte nur nie Priorität, weil ja alles lief. Die Hosts erreichten ihren Storage, die VMs liefen, die Backups kamen durch. Ein Switch von zweien war tot, und der Betrieb hat acht Monate lang nichts davon gespürt.
Was „es läuft noch" hier bedeutet
Zwei SAN-Switches, zwei Pfade zum Storage. So steht es im Konzept, und so sieht es aus, wenn beide leben. Mit einem toten Switch gibt es noch genau einen Pfad. Ein Netzteil, ein Kabel, ein Firmware-Fehler auf dem verbliebenen Gerät — und drei ESXi-Hosts verlieren gleichzeitig ihren Storage.
Was dann passiert, ist kein sauberer Halt. Die VMs bleiben beim nächsten Schreibzugriff hängen, nach dem Timeout kommen I/O-Fehler, Gast-Dateisysteme schalten auf schreibgeschützt, Datenbanken brechen mitten in einer Transaktion ab. Was danach an Daten übrig ist, ist eine Frage des Glücks.
Ein toter Pfad von zweien ist ein Ausfall, der noch nicht passiert ist. Er verdient denselben Alarm wie der Ausfall selbst. Er bekommt ihn nur nicht, weil das einzige Rote eine Erklärung hatte.
Warum das Rote niemanden alarmiert hat
Der Storage selbst zeigte einen Fehler: „Top Controller Error". Das hätte ein Hinweis sein können. Es wurde als Folge eingeordnet — der Storage hat zwei Controller-Pfade, einer davon hängt am toten Switch, also meldet er einen Fehler und arbeitet weiter. Die Einordnung ist plausibel. Geprüft hat sie niemand. Aber sie hat aus einer Warnung eine Erklärung gemacht, und Erklärungen erzeugen keine Tickets.
Das ist der Mechanismus, der Redundanz so gefährlich macht: Sie funktioniert. Genau dann, wenn eine Hälfte ausfällt, tut die andere Hälfte, wofür sie da ist, und der Betrieb sieht nichts. Ohne ein Monitoring, das die Pfade einzeln überwacht und nicht nur den Datastore als Ganzes, wird aus einem redundanten System ein einfaches — und niemand erfährt es.
Die Diagnose, die erst mal Archäologie war
Bevor irgendetwas diagnostiziert werden konnte, musste die Umgebung rekonstruiert werden.
Zuerst die Transporttechnik: Es war iSCSI mit Direct-Attach-Kabeln, nicht Fibre Channel, wie anfangs angenommen. Das gehört vor jede weitere Überlegung, weil jeder Schritt davon abhängt.
Ein Verkabelungsschema gab es nicht. Die Verkabelung wurde aus Fotos rekonstruiert, die vor Ort gemacht wurden — und anfangs wurde der iSCSI-Switch mit dem normalen Netzwerkswitch daneben verwechselt. Die IP-Adressen stammten aus einer alten Liste eines früheren Kollegen. Der intakte Switch war darüber erreichbar. Der defekte natürlich nicht.
Und das ist der Punkt, an dem eine Fernwartung endet: Ein Gerät in einer Bootschleife sagt einem über das Netz nichts. Was es zu sagen hat, sagt es über den Konsolenport. RS-232, oberhalb des Netzwerkanschlusses, identifiziert — aber niemand vor Ort mit einem Kabel. Alles, was sich aus den äußeren Symptomen recherchieren ließ, waren allgemeine Anleitungen.
Drei Verdachte, keiner bestätigt
Eine Firmware, die beim Abschalten mitten im Update war. Eine Konfiguration, die beim Neustart beschädigt wurde. Oder ein Hardwareschaden, den die Abschaltung nur sichtbar gemacht hat. Zur Bootschleife mit Lüftern auf Anschlag passen die ersten beiden am ehesten.
Ein vierter Gedanke passt zum Symptom nicht, aber zur Umgebung: eine Konfiguration, die vor dem Abschalten nie persistent gespeichert wurde. Ein Switch ohne Startup-Config würde zwar mit Werkseinstellungen durchbooten statt in einer Schleife zu hängen — aber an der Firewall desselben Kunden war genau das kurz vorher aufgefallen. Eine Änderung des früheren Dienstleisters war nie ins persistente Memory geschrieben worden; nach einem Neustart fehlten diverse Freigaben. In dieser Umgebung wäre es also nicht das erste Mal.
Bestätigen lässt sich nichts davon, weil ohne Konsole nichts bestätigt werden kann.
Was vorbereitet wurde
Die Konfiguration des laufenden Switches wurde als Textexport gesichert — als Vorlage für den Wiederaufbau des zweiten, und nebenbei als erste Sicherung überhaupt, die es von diesem Gerät gibt.
Der nächste Schritt ist rein physisch: jemand mit einem Konsolenkabel vor dem Rack. Erst danach entscheidet sich, ob eine Neukonfiguration reicht oder die Firmware neu muss. Für eine saubere Neukonfiguration beider Switches samt VLANs steht grob eine Handvoll Personentage im Raum.
Drei Regeln aus acht Monaten
Nach jeder Änderung an Netzwerk- und Storage-Geräten prüfen, ob sie gespeichert ist. Das ist die Lehre aus der Firewall, nicht aus dem Switch — aber sie gilt für beide. Nicht im Running-State, im persistenten Speicher. Ein Befehl, fünf Sekunden.
Pfade einzeln überwachen, nicht nur das Ergebnis. Ein Datastore, der erreichbar ist, sagt nichts darüber, über wie viele Wege er erreichbar ist. Der Verlust eines Pfades muss ein Alarm sein, sonst ist die Redundanz nur eine Verzögerung des Ausfalls.
Bei Boot-Problemen an Netzwerkhardware zählt nur die Konsole. Alles andere ist Raten. Wer die Fahrt vor Ort scheut, verbringt die Zeit stattdessen mit Recherche, die nichts ergibt.
Der Datastore-Fall aus derselben Fernwartung — die Erweiterung, die nach einem VMware-Bug aussah und ein alter Browser war — steht in Vier Zeichen, die nach einem VMware-Bug aussahen .