Dieser Artikel soll einige Hintergrundinformationen für technisch Interessierte zu den aktuellen Ereignissen (siehe Statushinweise unter https://noc.rub.de/status) im Datennetz liefern.

Zentrale Komponenten des Datennetzes - genauer gesagt unsere Aggregation Switches - werden zur Zeit mit neuer Software versorgt. Die Software-Updates erfordern mehrere Neustarts, die jeweils zu einer Netzwerkunterbrechung führen. Mehrere Neustarts deshalb, weil wir in mehreren Schritten aktualisieren müssen.

Für die anstehenden Software-Updates gibt es mehrere Gründe. Wir haben die betreffenden Switches im Jahr 2018 eingebaut und in Betrieb genommen. Seitdem kämpfen wir mit kleineren und teilweise auch mit nicht ganz so kleinen Problemen. Es gibt inzwischen vielversprechende Software-Updates des Herstellers Cisco (die wir auch bereits getestet haben), so dass sich für uns diese Update-Prozedur lohnen wird.

So ein Switch transportiert ja Daten, also zum Beispiel die E-Mails und Webseiten, die Sie mit Ihren Geräten aufrufen und versenden. Egal, ob es sich um ein Gerät im WLAN oder an einem kabelgebundenen Anschluss handelt. Letztendlich landen die Daten immer in einem Kabel, was runter in den Keller des Gebäudes geht und dort an einem Aggregation Switch angeschlossen ist. Dieses Gerät sammelt die Leitungen aller Verteiler im Gebäude und führt sie zusammen auf einen Router.

Fällt so ein Aggregation Switch aus, funktioniert das Datennetz (auch WLAN und Telefonie) in einem Gebäude nicht mehr. Das wollen wir natürlich vermeiden, weshalb wir mehrere Dinge tun:

Zum Einen werden die Aggregation Switches, die zwischen den Etagen-Switches (Access Switches) und den Routern sitzen, wenn möglich redundant ausgelegt. Die redundante Auslegung ist aber bisher nur in den Neubauten IA, IB und GD realisiert, die Aggregation Switches aller anderen Gebäude und Bereiche sind aus verschiedenen Gründen (meistens praktische Machbarkeit, fehlende oder zu alte Glasfaserverbindungen) nicht redundant vorhanden.

Zum Anderen aktualisieren wir hin und wieder die Software auf den Geräten - wie auch jetzt. Herstellerseitig werden Bugfixes vorgenommen, also Fehler beseitigt (leider manchmal auch neue Fehler eingebaut). Wir handeln hier in der Regel proaktiv, wenn sich ein Problem anbahnt (verdreckte Glasfaserleitung, merkwürdige Beobachtungen was den Speicherbedarf einzelner Prozesse angeht etc.). Wir tauschen dann gegebenenfalls kurzfristig ein Gerät aus oder starten es neu (immer mit Ankündigung).

Wir könnten die Neustarts natürlich auch (wie es z.B. die Telekom durchaus auch bei DSL-Anschlüssen macht) mitten in der Nacht durchführen. Das geht zwar grundsätzlich sogar automatisch (mit Befehlen wie „reload at [Uhrzeit]“), dann müssten wir jedoch zur Sicherheit trotzdem eine Nachtschicht schieben. Es kann ja immer mal was schief gehen, wie beispielsweise neulich im ZEMOS. Der dortige Aggregation Switch wollte einfach nicht neu starten und musste einmal „angeschubst“ werden. Leider lässt die Qualität der Hardware in diesen Belangen in den letzten Jahren deutlich nach - zumindest unserer Beobachtung nach…

Es gibt noch einen weiteren, viel wichtigeren Grund warum wir das lieber früh morgens statt in der Nacht tun: Backups. Viele Lehrstühle betreiben irgendwo Dienste, die nachts automatisch Backups durchführen. Diese wollen wir wenn möglich nicht unterbrechen, weshalb wir uns auf unsere Traffic-Statistiken verlassen und die Zeit wählen, zu der im Datennetz am wenigsten los ist. Das ist in der Regel morgens früh der Fall.

Nun ist es jedoch so, dass wir auch in den Bereichen mit redundant ausgelegtem Aggregation Layer (IA, IB und GD) bisher nicht ohne Netzwerkunterbrechung aktualisieren können, weil die aktuell auf diesen Switches laufende Software-Version das noch nicht unterstützt. Mit dem ersten Update, welches wir aktuell nach und nach auf den Aggregation Switches durchführen, kommt die Unterstützung für sogenannte In-Service Software-Updates (ISSU), sodass folgende Aktualisierungen dort keine Netzwerkunterbrechung mehr zur Folge haben werden. Das haben wir sogar bereits an einem Pärchen getestet - und keiner hat's gemerkt.

Alle weiteren Aggregation Switches werden wir im Anschluss (in ein paar Wochen) noch einmal neu starten müssen, dazu wird es dann wieder separate Ankündigungen geben.

Die Router sind aktuell nicht im Fokus von Software-Updates, das folgt später wieder. Auch hier gilt natürlich, dass wir hin und wieder Software-Aktualisierungen vornehmen. Allerdings sind die Router auf dem kompletten Campus redundant aufgebaut und angeschlossen, d.h. der Ausfall eines Routers - sei es ungeplant wegen eines technischen Problems oder geplant wegen eines Software-Updates - führt in der Regel zu keinerlei Einschränkung des Betriebs.

Anders als bei den Routern sieht das mit der Redundanz in den externen Liegenschaften aus. Dorthin haben wir in der Regel nur eine Verbindung, so dass eine redundante Auslegung des Routers keinen Sinn ergibt, weshalb wir uns das dort sparen. Wir versuchen insbesondere dort immer, die Neustarts in eine nutzungsarme Zeit zu legen.

Die Gebäude auf dem Gelände Mark 51°7 (ehem. Opel-Werk) werden jedoch redundant angebunden werden und auch redundantes Routing bekommen.

Dann wären da noch die Access Switches. Das sind die Switches, die in unseren Netzwerkverteilern auf jeder Etage verbaut sind. Es handelt sich aktuell um knapp 3.000 Geräte. Auch diese benötigen hin und wieder Updates. In der Regel machen wir das häppchenweise so nebenbei (in Absprache mit den Netzbetreuern), wir müssen allerdings demnächst auch in diesem Bereich einmal größere Stückzahlen aktualisieren, dazu wird es dann aber noch einen eigenen Artikel geben.