Wartung ohne Fenster: Wie Multi-Region-Betrieb geplante Downtimes eliminiert

In der klassischen IT-Welt sind Wartungsfenster ein notwendiges Übel. Meist finden sie nachts oder am Wochenende statt, um den Betrieb so wenig wie möglich zu stören. Doch in der Welt der Kritischen Infrastrukturen (KRITIS), wo Systeme 24/7 zur Verfügung stehen müssen, gibt es keine “gute Zeit” für einen Stillstand. Jede geplante Downtime ist ein Sicherheitsrisiko und ein Compliance–Problem.

Eine Multi-Region-Architektur verändert dieses Paradigma grundlegend. Wartung wird hier nicht mehr um die Verfügbarkeit herum geplant, sondern sie wird durch die Architektur selbst unsichtbar gemacht.

Das Problem: Die Risiko-Spirale bei Single-Site-Systemen

Wenn eine Plattform nur an einem Standort läuft, führt jede größere Wartung (z. B. ein Kubernetes–Upgrade oder das Patchen des Betriebssystems) zu einem Dilemma:

1. Reduzierte Redundanz: Selbst wenn man “rolling updates” nutzt, läuft das System während der Wartung mit weniger Kapazität. Fällt in diesem Moment eine Komponente aus, droht der Totalausfall.
2. Angst vor Veränderungen: Da Wartungsfenster riskant und mühsam zu koordinieren sind, werden Patches oft aufgeschoben. Das Ergebnis ist eine veraltete Infrastruktur, die anfällig für Sicherheitslücken wird.
3. Koordinations-Overhead: Kunden müssen vorab informiert werden, SLAs müssen ausgesetzt werden, und Bereitschaftsteams stehen unter enormem Stress.

Die Lösung: Das “Traffic-Shifting”-Modell

Mit einer Multi-Region-Infrastruktur verliert das Wort “Wartungsfenster” seinen Schrecken. Da beide Regionen (Aktiv/Aktiv) den gesamten Traffic übernehmen können, wird die Wartung zu einem Routineprozess am helllichten Tag.

1. Standort-Isolation auf Knopfdruck

Bevor die Wartung in Region A beginnt, wird der gesamte eingehende Datenverkehr über das Anycast-Routing oder den Load Balancer auf Region B umgeleitet. Für die Nutzer ändert sich nichts – sie werden lediglich zu dem anderen, voll funktionsfähigen Standort geleitet.

2. Wartung unter Laborbedingungen

Region A ist nun völlig frei von Live-Traffic. Das Operations-Team kann Kubernetes–Cluster aktualisieren, Datenbank-Migrationen testen oder Hardware austauschen, ohne Angst vor direkten Auswirkungen auf die Endnutzer. Sollte etwas schiefgehen, bleibt die Produktion in Region B unberührt.

3. Progressive Validierung

Nach der Wartung wird der Traffic langsam wieder auf Region A zurückgeführt (Canary Deployment). Erst wenn die Monitoring-Systeme bestätigen, dass alles stabil läuft, übernimmt der aktualisierte Standort wieder seinen vollen Anteil der Last. Danach wiederholt sich der Prozess für Region B.

Fazit: Agilität durch Resilienz

Die Möglichkeit, Wartungsarbeiten rollierend über Regionen hinweg durchzuführen, ist ein Gamechanger für den Betrieb kritischer Systeme. Es erhöht nicht nur die tatsächliche Verfügbarkeit auf nahezu 100 %, sondern verbessert auch die Sicherheit, da Updates zeitnah und ohne organisatorische Hürden eingespielt werden können. Aus “geplanter Downtime” wird so “kontinuierliche Modernisierung”.

FAQ

Merken die Nutzer etwas von der Umleitung während der Wartung? Bei einer sauberen Implementierung von Anycast-Routing oder Global Server Load Balancing (GSLB) erfolgt die Umleitung im Millisekundenbereich. Bestehende Verbindungen werden kurz neu aufgebaut, was moderne Applikationen automatisch und für den Nutzer unmerklich im Hintergrund erledigen.

Kann man so auch radikale Architektur-Änderungen testen? Ja, das ist einer der größten Vorteile. Man kann eine völlig neue Version der Plattform in Region A aufbauen, während Region B auf dem alten Stand weiterläuft. So lassen sich technologische Sprünge mit einem extrem niedrigen Risiko-Profil realisieren.

Gilt das auch für Datenbank-Upgrades? Datenbank-Upgrades sind komplexer, da die Datenreplikation zwischen den Versionen kompatibel bleiben muss. Dennoch ermöglicht das Multi-Region-Setup auch hier Strategien (wie z. B. Blue-Green-Deployments auf Datenbankebene), die deutlich sicherer sind als In-Place-Upgrades an einem Einzelstandort.

Ist dieser Ansatz mit der NIS-2-Regulatorik vereinbar? Absolut. NIS-2 fordert explizit Maßnahmen zur Aufrechterhaltung des Betriebs. Die Eliminierung von Wartungsfenstern durch Georedundanz ist ein Paradebeispiel für “Business Continuity by Design” und wird von Auditoren sehr positiv bewertet.