Multi-PoP-Aktiv-Aktiv: Verfügbarkeit richtig planen

TL;DR

Multi-PoP-Aktiv-Aktiv erhöht die Verfügbarkeit nicht allein durch mehrere Standorte. Entscheidend sind konsistente Traffic-Verteilung, belastbare Health Checks, klar definierte Failover-Regeln und ausreichend dimensionierte Backends. Die ayedo Edge Cloud verbindet dafür Anycast, verteilte PoPs, Aktiv-Aktiv-Betrieb und Backend-Failover – ersetzt aber keine Kapazitäts- und Abhängigkeitsplanung.

Einleitung

Eine Multi-PoP-Aktiv-Aktiv-Architektur wird häufig mit hoher Verfügbarkeit gleichgesetzt. Das ist ein gefährlicher Kurzschluss: Mehrere aktive PoPs verteilen den Traffic, lösen aber weder überlastete Backends noch fehlerhafte Health Checks oder unklare Failover-Zustände. Verfügbarkeit entsteht erst durch das Zusammenspiel von Edge, Routing, Prüfmechanismen und Compute-Kapazität. Wer nur die Anzahl der PoPs betrachtet, plant die sichtbare Infrastruktur, nicht den tatsächlichen Service. Deshalb muss die Verfügbarkeitsplanung von der Anfrage bis zur Anwendung reichen – einschließlich Zustandsabhängigkeiten, Wiederanlaufverhalten und Kapazitätsreserven.

1. Aktiv-Aktiv beginnt mit einer klaren Traffic-Verteilung

In einer Aktiv-Aktiv-Architektur sind mehrere PoPs gleichzeitig in der Lage, Anfragen zu verarbeiten. Bei Anycast wird eine IP-Adresse über mehrere Netzwerkstandorte angekündigt. Das Routing führt Clients typischerweise zu einem geeigneten Netzpfad, ohne dass die Anwendung selbst mehrere öffentliche Endpunkte verwalten muss. Für Layer-7-Traffic kann die Edge zusätzlich Routing- und Verteilungsentscheidungen auf Anwendungsebene treffen.

Diese Architektur reduziert die Abhängigkeit von einem einzelnen Standort, verteilt Last aber nicht automatisch gleichmäßig. Routingpfade, Client-Netze, TCP-Verbindungen und unterschiedliche Anfrageprofile beeinflussen die tatsächliche Verteilung. Auch langlebige Verbindungen können dazu führen, dass ein PoP stärker belastet bleibt als andere.

Für die Planung braucht es deshalb messbare Annahmen: Welche Traffic-Anteile werden je PoP erwartet? Wie verändert sich die Last beim Ausfall eines Standorts? Und welche Verteilung ist für die Backends zulässig? Anycast und die eigene Netzwerk-Infrastruktur der ayedo Edge Cloud schaffen die technische Basis für diese Verteilung. Die Kapazitätsplanung muss dennoch die reale Lastverteilung berücksichtigen, nicht nur die theoretische Gesamtleistung.

2. Health Checks müssen den richtigen Fehler erkennen

Health Checks sind die Grundlage jeder automatisierten Failover-Logik. Ein einfacher TCP-Check beantwortet lediglich, ob ein Port erreichbar ist. Ein HTTP-Check kann zusätzlich prüfen, ob ein Endpoint antwortet. Für die Verfügbarkeitsplanung ist jedoch entscheidend, ob der geprüfte Zustand tatsächlich etwas über die Nutzbarkeit des Dienstes aussagt.

Ein Endpoint kann HTTP 200 liefern, obwohl eine abhängige Datenbank nicht verfügbar ist oder neue Transaktionen nicht verarbeitet werden können. Umgekehrt kann ein einzelner fehlerhafter Checkpunkt einen gesunden Service vorübergehend aus dem Traffic nehmen. Checks müssen daher zur Fehlerdomäne passen: Sie sollten relevante Anwendungspfade prüfen, aber keine unnötigen Abhängigkeiten einbeziehen, die zu Fehlentscheidungen führen.

Wichtig sind außerdem Ausfall- und Wiederanlaufkriterien. Wie viele fehlgeschlagene Prüfungen lösen ein Failover aus? Wie schnell wird ein Backend wieder zugeschaltet? Gibt es Hysterese, damit instabile Systeme nicht ständig zwischen aktiv und inaktiv wechseln? Die ayedo Edge Cloud unterstützt Backend Health Checks und Failover. Die fachliche Definition eines aussagekräftigen Checks bleibt jedoch eine Aufgabe der Service- und Plattformverantwortlichen.

3. Failover verändert die Lastverteilung und die Betriebsrisiken

Ein Failover entfernt normalerweise keine Last, sondern verschiebt sie. Fällt ein PoP aus, müssen andere PoPs und die dahinterliegenden Backends zusätzliche Anfragen übernehmen. Wird ein Backend aus dem Pool genommen, verteilt sich dessen Traffic auf verbleibende Systeme. Ohne Reserve kann ein korrekt ausgelöstes Failover eine Überlastungskaskade auslösen.

Deshalb sollte die Planung mindestens zwei Zustände betrachten: den Normalbetrieb und den Fehlerbetrieb. Für jeden relevanten Ausfall – etwa ein nicht erreichbarer PoP, ein Backend-Pool oder ein kompletter Providerpfad – muss bekannt sein, welche Kapazität verfügbar bleibt. Dabei sind nicht nur Requests pro Sekunde relevant. TLS-Verbindungen, Antwortgrößen, Session-Zustände und rechenintensive Endpunkte verändern die tatsächliche Last.

Auch das Failback braucht Regeln. Ein zu frühes Zurückschalten kann Fehler erneut verteilen; ein zu spätes Zuschalten reduziert die verfügbare Kapazität. Automatisierung ist sinnvoll, wenn Zustände, Schwellenwerte und Verantwortlichkeiten dokumentiert sind. Ohne diese Definitionen wird Failover zu einer schwer nachvollziehbaren Betriebsentscheidung statt zu einem kontrollierten Mechanismus.

4. Backend-Kapazität ist Teil der Edge-Verfügbarkeitsplanung

Die Edge kann Traffic annehmen, schützen, terminieren und verteilen. Sie kann jedoch keine fehlende Verarbeitungskapazität im Backend ersetzen. Diese Trennung zwischen Edge und Compute ist für die Architektur entscheidend: Ein verfügbarer Edge-Service bedeutet nicht automatisch, dass die Anwendung hinter ihm ausreichend Kapazität besitzt.

Bei mehreren aktiven PoPs müssen Backends entweder gemeinsam nutzbar oder eindeutig den jeweiligen Traffic-Pfaden zugeordnet sein. Gemeinsame Backends vereinfachen die Verteilung, erhöhen aber Anforderungen an Datenkonsistenz, Sessions und Netzwerkanbindung. Getrennte Backends reduzieren bestimmte Abhängigkeiten, können jedoch zu ungleichmäßiger Auslastung und komplexerem Failover führen.

In die Planung gehören daher Basiskapazität, Spitzenlast, Ausfallreserve und Wiederanlaufkapazität. Ein Backend darf im Normalbetrieb nicht so stark ausgelastet sein, dass der Ausfall eines PoPs unmittelbar zur Überlast führt. Health Checks sollten zudem berücksichtigen, ob ein System noch ausreichend Kapazität besitzt – nicht nur, ob es formal erreichbar ist. Providerunabhängige Nutzung der ayedo Edge Cloud kann dabei helfen, Edge und Compute organisatorisch sowie infrastrukturell getrennt zu planen, ersetzt aber keine Abstimmung zwischen beiden Bereichen.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt eine API hinter mehreren aktiven Edge-PoPs. Im Normalbetrieb werden die Anfragen verteilt; die Backends laufen mit bewusst eingeplanter Reserve. Fällt ein PoP aus, übernehmen die übrigen Standorte den Traffic. Gleichzeitig steigt die Last auf den Backends. Ein TCP-Health-Check würde möglicherweise weiterhin Erfolg melden, obwohl die Anwendung wegen erschöpfter Datenbankverbindungen kaum noch Anfragen verarbeitet.

Eine belastbare Planung kombiniert deshalb einen anwendungsnahen Check mit definierten Schwellenwerten und prüft den Fehlerbetrieb unter kontrollierten Bedingungen. Das Team vergleicht dabei mindestens drei Szenarien: Normalbetrieb, Ausfall eines PoPs und Ausfall eines Backend-Pools. Erst wenn Traffic-Verteilung, Health Checks und Backend-Kapazität in allen Szenarien zusammenpassen, ist Aktiv-Aktiv operativ belastbar.

FAQ

Ist Anycast allein eine Aktiv-Aktiv-Architektur?

Nein. Anycast verteilt Erreichbarkeit über mehrere Netzwerkstandorte. Aktiv-Aktiv erfordert zusätzlich mehrere tatsächlich nutzbare Verarbeitungspfade, geeignete Health Checks, Failover-Regeln und ausreichende Backend-Kapazität.

Muss jedes Backend an jedem PoP erreichbar sein?

Nicht zwingend. Gemeinsame Backends vereinfachen die Verteilung, lokale oder getrennte Backends können Abhängigkeiten reduzieren. Entscheidend sind konsistente Routing-, Zustands- und Failover-Regeln.

Wie wird ein Failover sinnvoll getestet?

Durch kontrollierte Ausfälle einzelner PoPs, Backend-Pools und Abhängigkeiten. Gemessen werden Traffic-Verteilung, Umschaltzeit, Fehlerraten, Backend-Auslastung und das Verhalten beim Failback.

Fazit

Multi-PoP-Aktiv-Aktiv ist keine reine Standortentscheidung, sondern ein Zusammenspiel aus Routing, Prüfmechanismen, Failover und Compute-Kapazität. Die zentrale Frage lautet nicht, wie viele PoPs vorhanden sind, sondern ob der verbleibende Pfad einen Fehlerbetrieb zuverlässig tragen kann. Die ayedo Edge Cloud bietet dafür Anycast, verteilte Aktiv-Aktiv-Infrastruktur und Backend-Failover. Die belastbare Verfügbarkeit entsteht jedoch erst durch eine darauf abgestimmte Architektur- und Betriebsplanung.