Quelle: Eigene Darstellung
Wer an dem Tag an der RWTH war oder versuchte sich von unterwegs per VPN zu verbinden, hat es zu spüren bekommen: Am 21. November 2024 ab ca. 10 Uhr wollten zahlreiche unserer IT-Services nicht mehr so, wie wir wollten. Sowohl RWTH-E-Mail, Eduroam, VPN, RWTHmoodle als auch der gesamte RWTH Single Sign-On, also der Login für einen Großteil der Services an der RWTH, funktionierten nicht mehr – all das ging zurück auf eine Störung unseres F5-Load Balancers. In diesem Blogbeitrag stellen wir transparent dar, wie es zu dieser massiven Störung kommen konnte.
Was ist der F5-Load Balancer?
Standardmäßig führen Anfragen von einem Client direkt zu einem Server. Mithilfe eines Load Balancers werden Anfragen des Clients anhand vorab definierter Kriterien in einem Server-Pool verteilt. Der Load Balancer ist somit ein Vermittler, der dafür sorgt, dass bspw. die Last des Datenverkehrs auf die verschiedenen Server so aufgeteilt wird, dass Auslastung und Geschwindigkeit optimiert werden. Am IT Center der RWTH nutzen wir zurzeit einen Load Balancer der Firma F5 Inc. Hinter dem Load Balancer hängt insbesondere unser Login-Verfahren RWTH Single Sign-On. Ohne RWTH Single Sign-On ist der Zugriff auf viele weitere Services wie RWTHonline, RWTHmoodle, Selfservice etc. nicht mehr möglich.
Wie ist unser F5-Load Balancer abgesichert?
Wenn an einem Gerät so viele wichtige Services hängen, ist die oberste Regel Redundanz. Die Redundanz ist auf mehrfache Weise implementiert: Geräte- und Standortredundanz. Zwei Geräte an zwei Standorten mitsamt Kreuzverkabelung, um auch die Leitungen vor Ausfällen abzusichern. Zudem gibt es einen direkten Link zwischen den Geräten, um bspw. auch einen Ausfall der Datenverbindung erkennen zu können und im Falle eines Schwenks einen Verbindungsausfall zu verhindern. Beide Geräte besitzen eigenständige Uplinks zu zwei Datacenter-Standorten. Bei den Leitungen handelt es sich um Glasfaserverbindungen, welche mit Transceivern, sogenannten SFP (Small Form-factor Pluggable), verbunden sind. Sollte ein Gerät oder eine Leitung oder sogar ein gesamter Standort ausfallen, würde dank der Redundanz die Arbeit an der RWTH wie gewohnt stattfinden können und die Nutzenden würden hiervon nichts weiter bemerken.
Was war nun am 21. November 2024 passiert?
Um ein redundantes System auszuhebeln, muss nicht nur ein Problem auftreten, sondern es müssen schon mehrere Fehler zusammenkommen. Genau das ist am Donnerstag, dem 21. November 2024, passiert. Es lag ein Hardware-Fehler eines SFP auf einer Leitung zwischen zwei Gebäuden vor. Dieser wurde jedoch nicht bemerkt und hatte aufgrund der vorliegenden Redundanz der Systeme auch keine Auswirkungen. Im Laufe des Vormittags wurde ein standardmäßiges Software-Update bei der Hardware an dem nicht aktiv für die Dienste genutzten Gerät (aka Stand-by) durchgeführt, was im Normalfall im Betrieb nicht bemerkt worden wäre. Das Software-Update beeinflusste jedoch auch die Nutzung des SFP auf der gebäudeinternen Leitung – zusammen mit dem unbekannten Hardware-Fehler des SFP der anderen Leitung kam es zu einer Störung des gesamten Geräts. Leider hat das gestörte Gerät, anstatt seinen Dienst einfach nur einzustellen, einen Fehlerstatus an das funktionstüchtige Gerät am anderen Standort gesendet. Dieses Gerät hat wiederum reagiert und sich in den Stand-by-Status geschaltet, der Schwenk ging dann wieder automatisch auf das defekte Gerät. Dieses Ping-Pong-Verhalten hat dazu geführt, dass an dem Nachmittag die Logins und Services minutenweise wieder funktioniert haben, bevor sie erneut gestört waren.
Die Fehlerquellen, wie wir sie in diesem Blogbeitrag skizzieren, waren uns während der konkreten Störung selbstverständlich nicht bekannt, sodass die Analyse und Störungsbehebung einige Zeit in Anspruch genommen haben. Mithilfe eines Technikers des Herstellers sowie dem Einspielen eines Hotfix konnte das Ping-Pong-Verhalten glücklicherweise gestoppt werden, sodass wir gegen 16:45 Uhr den Datenverkehr auf dem einen, funktionstüchtigen Gerät halten konnten. Durch die nun wieder vorliegende stabile Dienste-Bereitstellung konnten wir dann den durch die Software fehlerhaft unterstützten SFP ausfindig machen und austauschen, ein Software-Downgrade des gestörten Geräts durchführen und letztlich die Redundanz des Systems wiederherstellen.
Wie können wir so einen Ausfall künftig verhindern?
Letztendlich sind wir angewiesen auf Hardware, die immer Störungen unterliegen kann. Ein umfassender Ausschluss von Fehlfunktionen für die Zukunft kann somit nicht seriös versprochen werden. Unser Ziel muss es jedoch sein, die Eintrittswahrscheinlichkeit einer solchen Störung weiter zu minimieren. Konkret bedeutet dies für uns, dass wir vor einem Software-Update alle Verbindungen auf ihre Verfügbarkeit hin überprüfen. Erst danach wird ein Update gestartet. Zusätzlich prüfen wir, neben der Anschaffung von weiteren Load Balancer/Proxy-Paaren, welche Komponenten von dem besser performenden Hardware-Setup losgelöst und in einem anderen Setup betrieben werden können.
Verantwortlich für die Inhalte dieses Beitrags sind Bernd Kohler, Susanne Kubiak und Nils Neumann.
Schreibe einen Kommentar