Primär, Sekundär oder Aktiv-Aktiv an der Edge?

TL;DR

Beim öffentlichen Traffic-Eingang ist die Wahl zwischen Primär-Sekundär, Cold-Standby und Aktiv-Aktiv keine reine Verfügbarkeitsfrage. Entscheidend sind Failover-Zeit, Auslastung, Betriebsaufwand, Zustandsmanagement und die Beherrschbarkeit von Fehlerfällen. Aktiv-Aktiv nutzt Ressourcen besser, verlangt aber eine konsistente Architektur und belastbare Betriebsprozesse.

Einleitung

Ein Standby-System, das im Normalbetrieb keinen Traffic verarbeitet, ist nicht automatisch die sicherste Architektur. Es reduziert zwar die Komplexität im Regelbetrieb, bringt aber eigene Risiken mit: unbekannte Fehler im Reservepfad, veraltete Konfigurationen und ein Failover, das erst unter Störung validiert wird. Für den öffentlichen Traffic-Eingang muss deshalb getrennt betrachtet werden, wie Routing, Zustandswechsel, Kapazität und Betrieb zusammenspielen. Ein Primär-Sekundär-Modell kann für bestimmte Anforderungen sinnvoll sein. Eine Cold-Standby-Architektur passt zu anderen Randbedingungen. Aktiv-Aktiv bietet eine andere Balance zwischen Auslastung und Resilienz. Die richtige Entscheidung hängt nicht von einem pauschalen Architekturideal ab.

1. Primär-Sekundär: klare Rollen, kontrollierter Failover

Im Primär-Sekundär-Modell verarbeitet eine aktive Instanz den regulären Traffic. Die sekundäre Instanz bleibt verfügbar, übernimmt aber erst nach einem erkannten Fehler. Diese klare Rollenverteilung vereinfacht Konfiguration, Fehlersuche und Zuständigkeiten. Insbesondere wenn Anwendungen oder Netzwerkpfade nicht problemlos parallel betrieben werden können, kann Primär-Sekundär eine pragmatische Lösung sein.

Der Preis liegt in der ungenutzten Kapazität und im Failover-Risiko. Die sekundäre Umgebung muss regelmäßig mit Konfigurationen, Zertifikaten, Routing-Informationen und Sicherheitsregeln synchronisiert werden. Andernfalls existiert zwar technisch ein Reservepfad, aber kein verlässlich gleichwertiger. Zusätzlich muss definiert sein, wer den Wechsel auslöst, wie DNS- oder Routing-Änderungen propagiert werden und wie ein Rückwechsel erfolgt. Ein Primär-Sekundär-Modell ist daher nur dann robust, wenn Failover-Strategie und Rückführung als wiederholbare Betriebsprozesse behandelt werden.

2. Cold-Standby: geringe laufende Kosten, hohe Umschaltabhängigkeit

Bei Cold Standby ist die Reserve nicht oder nur eingeschränkt aktiv. Ressourcen werden erst im Störungsfall gestartet, hochskaliert oder in den Traffic-Pfad gebracht. Das kann wirtschaftlich attraktiv sein, wenn Ausfälle selten sind und die Anforderungen an Wiederanlaufzeit begrenzt bleiben. Auch für Systeme mit hohen Kapazitätskosten kann dieses Modell nachvollziehbar sein.

Für den öffentlichen Eingang ist Cold Standby jedoch besonders kritisch. Der Ausfall umfasst nicht nur eine einzelne Komponente, sondern potenziell Bereitstellung, Konfiguration, Routing, TLS-Terminierung, Sicherheitsfunktionen und Backend-Erreichbarkeit. Jeder zusätzliche Aktivierungsschritt verlängert die Wiederherstellung und vergrößert die Zahl möglicher Fehlerquellen. Außerdem wird die Reserve im Regelbetrieb nicht vollständig belastet. Defekte oder veraltete Abhängigkeiten bleiben dadurch leichter unentdeckt. Cold Standby eignet sich deshalb vor allem dort, wo ein längerer Failover toleriert, der Aktivierungsprozess automatisiert und regelmäßig getestet werden kann.

3. Aktiv-Aktiv: Auslastung und Resilienz gemeinsam planen

Aktiv-Aktiv bedeutet, dass mehrere Edge-Pfade gleichzeitig produktiven Traffic verarbeiten. Fällt ein Pfad aus, kann der verbleibende Teil weiterarbeiten. Im Normalbetrieb wird die vorhandene Kapazität genutzt, wodurch Investitionen in Reserve-Systeme wirtschaftlich besser ausgelastet werden. Bei verteilten Edge-Architekturen kann Anycast den Traffic an erreichbare Standorte oder Netzwerkpunkte lenken, während Health Checks und Routing-Logik die Erreichbarkeit der Backends berücksichtigen.

Aktiv-Aktiv ist allerdings kein automatischer Sicherheitsgewinn. Konfigurationen müssen konsistent verteilt, Zertifikate und Policies synchron gehalten und Zustände korrekt behandelt werden. Stateful-Anwendungen, Session-Bindungen oder asymmetrische Netzwerkpfade können die Architektur erschweren. Zudem müssen Überlastszenarien betrachtet werden: Wenn ein Teil ausfällt, muss die verbleibende Kapazität den zusätzlichen Traffic aufnehmen können. Aktiv-Aktiv verlagert den Aufwand also von der manuellen Umschaltung in Design, Automatisierung, Monitoring und Kapazitätsplanung.

4. Entscheidungskriterien für den öffentlichen Traffic-Eingang

Die zentrale Frage lautet nicht „Aktiv-Aktiv versus Aktiv-Passiv?“, sondern: Welche Fehler können auftreten, wie schnell muss der Traffic weiterlaufen und welche Betriebsprozesse sind beherrschbar? Relevante Kriterien sind Recovery Time Objective, erwartete Ausfallbilder, Kapazitätsreserven, Konfigurationskonsistenz und die Möglichkeit, Failover regelmäßig zu testen. Auch die Trennung von Edge und Compute ist wichtig: Ein aktiver Edge-Pfad kann den Traffic weiterhin annehmen, obwohl ein einzelnes Backend ausgefallen ist. Backend Health Checks und Failover sind deshalb nicht dasselbe wie der Wechsel zwischen zwei Edge-Installationen.

Für Unternehmen mit mehreren Providern oder Kubernetes -Clustern gewinnt außerdem die Entkopplung an Bedeutung. Die Edge sollte den öffentlichen Eingang, TLS-Terminierung, Schutz und Verteilung unabhängig vom Ort der Workloads steuern können. Die ayedo Edge Cloud ist dafür als verteilte Multi-PoP-Plattform mit eigenem Autonomous System und Aktiv-Aktiv-Prinzip ausgelegt. Sie kann Traffic zu ayedo Managed Kubernetes ebenso wie zu eigenen oder extern betriebenen Kubernetes -Clustern führen. Damit wird das Betriebsmodell der Edge nicht an einen einzelnen Compute-Standort gebunden.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt eine API in zwei Kubernetes -Clustern bei unterschiedlichen Providern. Im Primär-Sekundär-Modell führt der normale Traffic ausschließlich zum ersten Cluster. Der zweite Cluster muss synchron gehalten und im Störungsfall über Routing oder DNS aktiviert werden. Bei Cold Standby kommen zusätzlich Start- und Bereitstellungszeiten hinzu.

In einer Aktiv-Aktiv-Architektur nehmen beide Pfade Traffic an. Health Checks entfernen nicht erreichbare Backends aus der Verteilung, während die Edge den öffentlichen Zugang und die Schutzfunktionen zentral hält. Dafür müssen beide Cluster dieselben API-Verträge, Sicherheitsregeln und Kapazitätsannahmen erfüllen. Der Vergleich zeigt: Aktiv-Aktiv reduziert Umschaltabhängigkeiten, erhöht aber die Anforderungen an Konsistenz und Betrieb.

FAQ

Ist Aktiv-Aktiv immer verfügbarer als Primär-Sekundär?

Nein. Aktiv-Aktiv reduziert bestimmte Failover-Abhängigkeiten, kann aber durch inkonsistente Konfigurationen oder unzureichende Restkapazität selbst ausfallen. Entscheidend ist die Qualität der Betriebsprozesse.

Wann ist Cold Standby vertretbar?

Wenn längere Wiederanlaufzeiten akzeptiert werden, der Aktivierungsprozess automatisiert ist und die Reserve regelmäßig getestet wird. Für zeitkritische öffentliche APIs ist das Modell häufig zu träge.

Muss Aktiv-Aktiv auch für die Backends gelten?

Nein. Edge und Compute können unterschiedlich betrieben werden. Die Edge kann aktiv redundant arbeiten, während Backends über Health Checks priorisiert, verteilt oder im Fehlerfall aus dem Traffic-Pfad genommen werden.

Fazit

Die Wahl des Betriebsmodells ist eine Entscheidung über Fehlerverhalten, Kapazitätsnutzung und organisatorische Disziplin. Primär-Sekundär schafft klare Rollen, Cold Standby senkt laufende Reservekosten, Aktiv-Aktiv reduziert Umschaltabhängigkeiten und nutzt Infrastruktur kontinuierlich. Für den öffentlichen Traffic-Eingang ist entscheidend, ob Routing, Schutz, TLS, Health Checks und Backend-Anbindung als zusammenhängender Prozess betrieben werden können. Die ayedo Edge Cloud ordnet diese Aufgaben in einer eigenen, verteilten Aktiv-Aktiv-Edge ein, ohne die Wahl der Compute-Plattform vorzugeben.