Ein zweistrahliges Flugzeug musste ca. 4 km vor der Landebahn auf einem verschneiten Acker notlanden, weil beide (!) Triebwerke keine ausreichende Leistung mehr brachten. Die anschließende Untersuchung ergab, dass sich in beiden Triebwerken die so genannten Eisschutzpaneele gelöst und verkeilt hatten, so dass nicht mehr genügend Luft angesaugt werden konnte. Die Ursache war fehlerhafte Verklebung dieser Paneele. Ausgelöst wurde der Effekt letztlich durch die Tatsache, dass der Flug zuvor eine außergewöhnlich lange Zeit unter Vereisungsbedingungen durch Wolken führte.
Dieses Problem fällt in die Kategorie „ein Problem betrifft gleichermaßen alle redundanten Komponenten“. Eine andere Kategorie wäre „Defekt wird nicht erkannt, daher scheitert Failover“. Dafür fällt mir gerade kein Beispiel aus der Luftfahrt ein. Daher erzähle ich Ihnen, was ein Kollege neulich bei einem Kunden erlebt hat:
Mitarbeiter des Kunden nutzen Microsoft Outlook und bemängeln dabei immer wieder miserable Performance. Es stellte sich heraus, dass einer von mehreren Domänen-Controllern sporadisch neu startete – es lag offensichtlich ein Hardware-Defekt vor. Aber warum wurde dadurch Outlook beeinträchtigt?
Der Microsoft Exchange Server nutzt den so genannten Globalen Katalog (GC) des Microsoft Active Directory (AD). Typischerweise konfiguriert man im Exchange mehrere Server, die diese Rolle innehaben. Ist der aktive Server nicht erreichbar, wird die Redundanz angesprochen. Im vorliegenden Fall erfolgte jedoch der Wiederanlauf des betroffenen Servers so zügig, dass Exchange regelmäßig den zwischenzeitlichen Ausfall nicht bemerkte.
Leider aber muss der Domänen-Controller nach dem Start zunächst die Konsistenz des Globalen Katalogs per Replikation wiederherstellen. Die entsprechenden Daten standen daher zunächst nicht zur Verfügung, obwohl der Katalog-Dienst bereits erreichbar war. Infolgedessen konnten Anfragen der Anwender nicht beantwortet werden (Anmerkung: Grundsätzlich kann die „Readiness“ des Globalen Katalogs von aktuellen Exchange-Versionen verifiziert werden. Ob dies im vorliegenden Fall nicht eingerichtet oder wirkungslos war, entzieht sich meiner Kenntnis). Die Lösung bestand letztlich darin, den Domänen-Controller herunterzufahren und die entsprechenden Service Records aus dem DNS zu löschen.
Ein ähnliches Beispiel aus dieser Kategorie hatten wir vor Jahren bei einem Kunden, der Network Access Control (NAC) zur Absicherung seiner Switch Ports nutzte. Der entsprechende RADIUS Server nutzte Informationen des Microsoft Active Directory zur Authentisierung von Endgeräten und Anwendern. Auch hier trat der Fall ein, dass Informationen aus dem AD nicht zur Verfügung standen, obwohl der RADIUS Server den entsprechenden Dienst noch erreichen konnte. Die fatale Folge war, dass tausende Anwender aus dem Netz „ausgesperrt“ wurden. Mangels Daten schickte der RADIUS Server alle Clients ins „Quarantäne-VLAN“.
Fazit: Traue keiner Redundanz! Oder anders ausgedrückt: Kontrollieren Sie Ihre Redundanzen genau. Im vorliegenden Fall hätte der Neustart des Servers bereits beim ersten Mal einen Alarm auslösen müssen.
Gerade hier können wir von Luftfahrt lernen. Dort sind zahlreiche Verfahren bei Flugvorbereitung und -durchführung mit dem Ziel etabliert, die einwandfreie Funktion der Redundanzen zu verifizieren. Überlegen Sie, wie Sie das im Einzelnen bei Ihren Redundanzen umsetzen können!
