Teams, die von einem AWS ALB zu Cloudflare Load Balancing wechseln, konfigurieren oft alles richtig und stoßen dann auf ein Verhalten, das ihr mentales Modell nicht erklären kann: Ein Client erreicht nach dem Ausfall noch Minuten lang den gleichen Ursprung, die Lastverteilung scheint zwischen den Instanzen ungleichmäßig zu sein und das Failover dauert länger, als Gesundheitsprüfungen vermuten lassen. Das Produkt funktioniert, aber es funktioniert anders als erwartet – weil es auf dem DNS und nicht auf der Transport- oder Anwendungsebene arbeitet.
Wie Cloudflare Load Balancing wirklich funktioniert
Cloudflare Load Balancing ist ein Datenverkehrsverteilungsdienst, der bei der Namensauflösung Maßnahmen ergreift. Wenn ein Client eine DNS-Abfrage für die ausgeglichene Domäne durchführt, wertet Cloudflare Authoritative aus, welche Ursprünge fehlerfrei sind, wendet die konfigurierte Steuerungsregel an und gibt die IP des ausgewählten Ursprungs zurück. Ab diesem Zeitpunkt stellt der Client eine direkte Verbindung zur Quelle her – oder zum Cloudflare-PoP, wenn die Registrierung über einen Proxy erfolgt – und alle Anfragen aus dieser Sitzung gehen an dieses Ziel, bis die TTL abläuft und der Client den Namen erneut auflösen muss.
Dies bedeutet, dass die Lastverteilung über die DNS-Auflösung und nicht über eine HTTP-Anfrage erfolgt. Zwei gleichzeitigen Clients, die die Domäne in derselben Sekunde auflösen, können unterschiedliche Ursprünge zugewiesen werden. Ein einzelner Client, der den Namen einmal auflöst und die Verbindung offen hält, bleibt auf unbestimmte Zeit am selben Ursprung. Wenn hinter einem ALB zehn Instanzen laufen, verteilt der ALB bei jeder neuen Anfrage die Anfragen auf diese. Bei Cloudflare LB liegt die Granularität beim Kunden, nicht bei der Anfrage.
Das Integritätsprüfungssystem korrigiert den Pfad, wenn eine Quelle ausfällt. Cloudflare führt aktive Gesundheitsprüfungen von mehreren PoPs – nicht von einem einzigen Punkt – für jeden registrierten Ursprung durch. Wenn der Prozentsatz der Fehler den konfigurierten Schwellenwert überschreitet, wird die Quelle als herabgestuft markiert und aus dem Auflösungspool entfernt. Neue Clients, die ihren Namen nach diesem Tag auflösen, erhalten nicht mehr die IP der problematischen Quelle. Clients, die den Namen bereits aufgelöst haben und deren IP zwischengespeichert ist, versuchen weiterhin, eine Verbindung herzustellen, bis die TTL abläuft. Failover hat daher zwei Latenzkomponenten: die Zeit, die die Gesundheitsprüfung benötigt, um den Fehler zu erkennen und zu markieren, und die verbleibende TTL von Clients, die bereits gelöst wurden.
Das Preismodell und was es abdeckt
Der Cloudflare Load Balancing-Basisplan kostet 5 US-Dollar pro Monat und umfasst zwei Ursprungspools, fünf Ursprünge pro Pool und konfigurierbare Zustandsprüfungen. Die zusätzliche Gebühr von 0,50 US-Dollar pro 500.000 Health-Check-Abfragen gilt für das durch die Checks generierte Volumen – bei 60-Sekunden-Intervallen und der Verteilung auf mehrere PoPs steigt das monatliche Volumen schnell an, liegt aber für Aktiv-Passiv-Setups mit kleinen Pools immer noch in einem vertretbaren Bereich.
Für ein einfaches Aktiv-Passiv-Setup – ein Hauptpool mit zwei Quellen und einem Fallback-Pool – liegt die monatliche Rechnung in den meisten Szenarien unter 10 US-Dollar. Bei ausgefeilteren Architekturen mit mehreren regionalen Pools und granularen Zustandsprüfungen pro PoP steigen die Kosten, bleiben aber im Vergleich zum Betriebsaufwand für die Verwaltung des manuellen Failovers zwischen Regionen wettbewerbsfähig.
Geo Steering: Routing nach geografischer Herkunft des Kunden
Geo Steering ist die Funktionalität, die den Load Balancer in eine echte geografische Routing-Ebene verwandelt. Die Konfiguration ordnet Regionen – bestimmte Kontinente oder Länder – Quellpools zu. Brasilianische Kunden lösen die Domain auf und erhalten die IP des Ursprungs in São Paulo. Europäische Kunden erhalten die IP des Ursprungs in Frankfurt. Cloudflare autorisierend identifiziert den geografischen Standort des Resolvers, der die Abfrage gestellt hat, und gibt die Antwort aus dem entsprechenden Pool zurück.
Wenn der regionale Pool nicht mehr verfügbar ist – alle darin enthaltenen Ursprünge werden als herabgestuft markiert – wechselt Cloudflare automatisch zum konfigurierten globalen Fallback-Pool. Der europäische Kunde, dessen Frankfurter Pool außerhalb liegt, erhält die IP von São Paulo oder einem anderen gesunden Pool, ohne manuellen Eingriff. Dieser automatische Fallback-Mechanismus macht Geo Steering für die geografische Hochverfügbarkeit und nicht nur für die Latenzoptimierung nützlich.
Die Cookie-Sitzungsaffinität ergänzt das geografische Routing in Fällen, in denen dieselbe Instanz denselben Client über mehrere DNS-Auflösungen hinweg bedienen muss. Cloudflare fügt ein Cookie in die HTTP-Antwort ein, das den ausgewählten Ursprung identifiziert, und Load Balancer verwendet dieses Cookie, um den Client bei nachfolgenden Auflösungen zum gleichen Ursprung zurückzubringen, selbst wenn die TTL bereits abgelaufen ist. Für zustandslose Anwendungen ist dies irrelevant; Bei Sitzungen, die den Kontext im Instanzspeicher speichern, ist es der Mechanismus, der eine Unterbrechung der Erfahrung bei normalen TTL-Neuauflösungen verhindert.
Die Unterscheidung, die das Design der Architektur verändert
Ein ALB arbeitet auf Schicht 7. Er empfängt TCP-Verbindungen, prüft HTTP-Header, wendet Pfad- und Header-Routing-Regeln an und verteilt jede einzelne Anfrage an eine Instanz des Backend-Pools. Es sieht jede Anfrage. Sie können pfadbasiertes Routing durchführen – /api geht zu einer Gruppe von Instanzen, /static geht zu einer anderen. Kann Header einfügen oder ändern. Hat Sichtbarkeit über den Anforderungstext, sofern das Protokoll dies zulässt.
Cloudflare LB sieht keine einzelnen Anfragen. Es beantwortet DNS-Anfragen. Es gibt keine Möglichkeit, Pfad /api zu überprüfen, da der Pfad nicht einmal auf der DNS-Ebene existiert – er erscheint erst, nachdem der Client die TCP-Verbindung mit dem Ursprung hergestellt und den HTTP-GET gesendet hat. Dies ist keine zufällige Einschränkung; Dies ist die natürliche Folge des Betriebs mit dem falschen Protokoll für diese Granularitätsebene.
Das Muster, das die beiden kombiniert, löst auf jeder Ebene unterschiedliche Probleme. Cloudflare LB kümmert sich um geografisches Routing und Failover zwischen Regionen: Kunden in Brasilien kommen in São Paulo an, Kunden in Europa kommen in Frankfurt an, und wenn São Paulo ausfällt, wird der Datenverkehr automatisch migriert. Innerhalb jeder Region verteilt ein ALB oder Nginx Anforderungen auf die Poolinstanzen, führt pfadbasiertes Routing durch und verwaltet die Last auf Anforderungsebene. Die beiden koexistieren ohne Konflikte, da sie Probleme auf verschiedenen Ebenen des Stapels lösen.
Was Gesundheitsprüfungen für das Failover-SLA bedeuten
Die Geschwindigkeit des Failovers hängt von drei Variablen ab: dem Integritätsprüfungsintervall, der Anzahl aufeinanderfolgender Fehler, die erforderlich sind, um eine Quelle als beeinträchtigt zu markieren, und der TTL des DNS-Eintrags. Bei Zustandsprüfungen alle 60 Sekunden und zwei aufeinanderfolgenden Fehlern als Schwellenwert liegt der ungünstigste Fall für die Erkennung bei 120 Sekunden. Wenn man die TTL hinzufügt, die für Proxy-Datensätze 60 Sekunden beträgt, beträgt das maximale Failover-Fenster etwa 3 Minuten.
Durch die Verkürzung des Integritätsprüfungsintervalls wird die Erkennung beschleunigt, aber das Volumen der berechneten Abfragen steigt. Der Break-Even-Punkt hängt vom Serviceverfügbarkeits-SLA ab. Für Systeme, bei denen ein Teilausfall von 3 Minuten akzeptabel ist – der tote Ursprung bedient bei der Erkennung keine neuen Clients, Clients mit aktivem Cache versuchen jedoch immer noch, bis zur TTL zu erreichen – ist die Standardkonfiguration ausreichend. Bei Systemen, bei denen eine Umleitung des Datenverkehrs zu einer beeinträchtigten Quelle nicht akzeptabel ist, reduziert die Kombination aus niedriger TTL, kurzer Intervall-Gesundheitsprüfung und mindestens zwei parallelen PoP-Prüfungen das Zeitfenster in der Praxis auf weniger als 2 Minuten.
Der Punkt, den Teams mit ALB-Hintergrund unterschätzen, ist, dass Cloudflare LB keine aktiven Verbindungen bricht, wenn ein Ursprung als beeinträchtigt markiert wird. Diese IP wird in neuen DNS-Auflösungen nicht mehr zurückgegeben. Clients, deren IP bereits zwischengespeichert ist, versuchen es weiter. Das TCP-Verbindungs-Timeout oder der Anwendungsfehler ist das, was der Client erleben wird, bis die TTL abläuft und eine neue Auflösung eine fehlerfreie IP zurückgibt. Die tatsächliche Auswirkung hängt davon ab, welcher Anteil der aktiven Clients zum Zeitpunkt des Fehlers über einen neuen Cache im Vergleich zu einem abgelaufenen Cache verfügt.
Lesen Sie auch
- Cloudflare DNS: Netzwerkinfrastruktur, die weit über die Namensauflösung hinausgeht
- DNS-Proxy vs. nur DNS: Was ändert sich und wann macht jeder Modus Sinn
- DNSSEC mit Cloudflare: Was es schützt, was es nicht schützt und wie man es ohne Probleme aktiviert
- Cloudflare Email Routing: E-Mails auf Ihrer Domain empfangen – und was nicht enthalten ist
- KV vs. R2 vs. Cache-API: Wann die einzelnen Cloudflare-Speicherebenen verwendet werden sollten
- Cloudflare KV: Was bedeutet global verteilt, wenn Sie schreiben müssen