Wartung ohne Fenster: Rolling Upgrades durch regionale Entkopplung

In der klassischen IT-Welt sind Wartungsfenster oft ein notwendiges Übel. Updates für das Betriebssystem, Kubernetes-Upgrades oder kritische Datenbank-Patches werden meist nachts oder am Wochenende durchgeführt, um die Beeinträchtigung für die Nutzer zu minimieren. In einer KRITIS-Umgebung, die 24/7-Verfügbarkeit erfordert, ist dieses Modell jedoch ein hohes Risiko: Wenn während der Wartung etwas schiefgeht, steht das System still, und die Redundanz ist während des Prozesses oft aufgehoben.

Durch unsere Multi-Region-Architektur mit getrennten Clustern verwandeln wir das Risiko “Wartung” in einen Standardprozess ohne jede Downtime.

1. Das Konzept der rollierenden regionalen Wartung

Anstatt die gesamte Plattform gleichzeitig zu aktualisieren, nutzen wir die geografische Trennung als Sicherheitsbarriere. Wir behandeln eine komplette Region als eine Einheit, die wir vorübergehend aus dem Verkehr ziehen können.

1. Traffic-Drain: Über das Anycast-Routing oder den Global Load Balancer wird der gesamte eingehende Traffic kontrolliert von Region A nach Region B umgeleitet. Dank der Session-Persistenz (siehe Teil 7) merken die Nutzer diesen Wechsel nicht.
2. Isolierte Wartung: Region A ist nun völlig lastfrei. Das Ops-Team kann in Ruhe tiefgreifende Änderungen vornehmen: Kubernetes-Versionen springen, Nodes neu provisionieren oder Hardware-Komponenten tauschen.
3. Validierung: Bevor der Traffic zurückgeholt wird, durchläuft Region A automatisierte Health-Checks und Smoke-Tests. Erst wenn die Region nachweislich gesund ist, wird sie wieder für den produktiven Verkehr freigegeben.
4. Gegenprüfung: Der Prozess wird anschließend für Region B wiederholt.

2. Risikominimierung durch “Canary-Releases” auf Infrastruktur-Ebene

Ein wesentlicher Vorteil dieser Strategie ist die Fehlerbegrenzung (Blast Radius). Sollte ein neues Update einen subtilen Bug enthalten, der erst unter realer Last auftritt, betrifft dieser Fehler zunächst nur eine Region. Da die zweite Region noch auf dem alten, stabilen Stand läuft, können wir den Traffic innerhalb von Sekunden zurückschwenken. Die Plattform als Ganzes bleibt für die Außenwelt zu 100 % verfügbar, während intern die Ursachenforschung in der betroffenen Region beginnt.

3. Entspannung für das Ops-Team

Wartungsfenster um 3 Uhr morgens führen zu Übermüdung und menschlichen Fehlern. Durch die regionale Entkopplung finden Upgrades während der regulären Arbeitszeit statt.

• Bessere Support-Abdeckung: Sollte ein Problem auftreten, sind alle Spezialisten und auch die Support-Teams der Software-Hersteller (z. B. Cloud-Provider oder Datenbank-Anbieter) im Dienst.
• Keine “Point of no Return”-Angst: Da jederzeit eine voll funktionsfähige Region im Hintergrund bereitsteht, sinkt der Druck auf die Administratoren massiv.

Fazit: Verfügbarkeit als Dauerzustand

Eine moderne KRITIS-Plattform zeichnet sich dadurch aus, dass sie sich im laufenden Betrieb selbst erneuern kann. Die Multi-Region-Architektur macht Wartungsfenster obsolet und erhöht gleichzeitig die Sicherheit bei jedem Update. Für den Kunden bedeutet das: Die Plattform ist einfach immer da - ohne “geplante Unterbrechungen” in der Verfügbarkeitsstatistik.

FAQ

Gibt es während des Traffic-Umschwenkens kurze Verbindungsabbrüche? Bei sauber konfigurierten Load Balancern und Anycast-Routen werden bestehende Verbindungen (“Long-lived connections”) oft noch zu Ende geführt (Connection Draining), während neue Anfragen bereits zur anderen Region fließen. Ein minimaler Paketverlust im Millisekundenbereich ist theoretisch möglich, wird aber von modernen Web-Protokollen wie TCP/QUIC automatisch korrigiert.

Kann eine einzelne Region die gesamte Last aller Kunden tragen? Ja, das ist die Grundvoraussetzung für dieses Modell. Jede Region muss so dimensioniert sein, dass sie im Wartungsfall oder bei einem echten Disaster die 100-Prozent-Last des Gesamtsystems übernehmen kann.

Wie wird sichergestellt, dass die Konfigurationen nach der Wartung noch synchron sind? Hierfür nutzen wir GitOps (z. B. ArgoCD). Die Konfiguration beider Regionen ist im Git-Repository definiert. Nach der Wartung stellt das System automatisch sicher, dass der Zielzustand wieder mit dem Repository übereinstimmt, um “Konfigurations-Drift” zu vermeiden.

Was passiert, wenn eine Applikation ein Datenbank-Schema-Update benötigt? Dies ist der komplexeste Teil. Wir nutzen hierfür Strategien wie “Expand and Contract”. Das Datenbankschema wird so erweitert, dass sowohl die alte als auch die neue Version der Applikation gleichzeitig damit arbeiten können. So kann Region A bereits mit dem neuen Code laufen, während Region B noch den alten nutzt.

Wie unterstützt ayedo bei der Planung von Update-Prozessen? Wir entwickeln gemeinsam mit Ihnen die “Update-Playbooks” und automatisieren die Traffic-Umschaltung. Wir sorgen dafür, dass Ihre Infrastruktur-Upgrades nicht mehr nervenaufreibend sind, sondern zu einem unspektakulären Standardvorgang werden.