Was ist globale Serverlastverteilung?
Globale Serverlastverteilung leitet Clients an Endpunkte in verschiedenen geografischen Regionen weiter. Entscheidungen können den Zustand der Endpunkte, Latenz, Kapazität, Richtlinien oder den Standort der Nutzer berücksichtigen.
So funktioniert globale Serverlastverteilung
Globale Serverlastverteilung (GSLB) ist eine Bezeichnung von Anbietern und kein Protokoll. RFC 3568 beschreibt dieselbe Aufgabe als Anfrage-Routing und unterteilt die bekannten Mechanismen in DNS-Verfahren sowie Verfahren auf Transport- und Anwendungsschicht. Die DNS-Variante ist verbreitet, weil jeder Client ohnehin Namen auflöst: Ein autoritativer Nameserver beantwortet denselben Namen je nach Richtlinie, Messungen oder beidem mit unterschiedlichen Adressen. Die zurückgegebene Adresse ist oft eine virtuelle IP-Adresse vor einem regionalen Pool, der seinen eigenen lokalen Lastenausgleich durchführt. Die anderen Verfahren greifen später ein. Anycast kündigt eine Adresse von mehreren Standorten aus an und überlässt die Standortwahl dem Netzwerk-Routing. Ein Load-Balancer auf Anwendungsschicht leitet den Client entweder um, etwa mit HTTP 302, oder fungiert als Proxy für die Anfrage und wählt für jede Anfrage eine Region aus. DNS-Load-Balancer und Load-Balancer auf Anwendungsschicht können Netzwerknähe oder Latenz, Last und Kapazität, Ergebnisse von Zustandsprüfungen sowie Regeln wie geografische Vorgaben oder Gewichtungen berücksichtigen. Anycast allein folgt ausschließlich dem Netzwerk-Routing: RFC 3568 weist darauf hin, dass Routing-Protokolle üblicherweise nicht auf die Auslastung reagieren und die Serverlast nicht berücksichtigt wird. Ein Standort empfängt so lange Datenverkehr, wie seine Route angekündigt wird. Deshalb bezeichnet RFC 4786 es als wünschenswert, die Ankündigung an die Verfügbarkeit des Dienstes zu koppeln.
Wichtige Fakten
- Wie schnell verlagert DNS-basiertes GSLB den Datenverkehr weg von einer ausgefallenen Region? Schrittweise, nicht auf einmal. Zuerst muss der Ausfall erkannt werden. Das hängt vom Prüfintervall und davon ab, wie viele aufeinanderfolgende fehlgeschlagene Prüfungen der Load-Balancer voraussetzt (Route 53 nennt dies die Ausfallschwelle). Nachdem sich die autoritative Antwort geändert hat, erhalten Abfragen, die nicht aus einem Cache bedient werden, die neue Antwort. Ein Resolver, der die alte Antwort zwischengespeichert hat, verwendet sie dagegen möglicherweise für die verbleibende TTL weiter. Die neue Antwort nennt eine Region, die ihre Prüfungen besteht, sofern es eine solche gibt. Besteht keine Region ihre Prüfungen, gilt die Ausweichregel des Load-Balancers. Route 53 gibt beispielsweise den primären Eintrag zurück, wenn beide Einträge eines Failover-Paars als nicht funktionsfähig gelten. Die TTL legt fest, wie lange ein Resolver eine zwischengespeicherte Antwort nutzen darf, bevor er erneut nachfragen muss. Der Load-Balancer kann eine bereits ausgegebene Antwort nicht zurückrufen. Eine kürzere TTL verkleinert das Zeitfenster und erhöht das Abfragevolumen auf den DNS-Servern. Eine Antwort kann dennoch über ihre TTL hinaus genutzt werden: RFC 3568 weist darauf hin, dass viele DNS-Implementierungen die TTL nicht beachten. RFC 8767 erlaubt einem Resolver, weiterhin eine abgelaufene Antwort auszuliefern, wenn sein Versuch, sie zu aktualisieren, fehlschlägt. Das k8gb-Projekt berichtet von einer Ausfallzeit, die ungefähr der DNS-TTL entspricht, wenn ein Dienst hinter seinem GSLB ausfällt. Das ist die Beobachtung eines einzelnen Projekts und keine Obergrenze. Eine Änderung der DNS-Antwort verlagert auch keine bereits offenen Verbindungen: AWS weist für sein DNS-basiertes Failover zwischen Regionen darauf hin, dass bestehende Verbindungen je nach Client-Verhalten und Wiederverwendung von Verbindungen Zeit benötigen, bis sie abgeschlossen sind. Cloudflare nennt langsameres Failover als Einschränkung seines reinen DNS-Lastenausgleichs im Vergleich zum Proxy-Modus.
- Wessen Standort nutzt eine DNS-basierte Entscheidung? Den des rekursiven Resolvers, sofern dieser nicht die Option EDNS Client Subnet sendet. Amazon Route 53 dokumentiert beide Fälle: Unterstützt der Resolver die Option nicht, wird seine Quell-IP-Adresse verwendet; andernfalls eine verkürzte Form der Nutzeradresse. RFC 7871, das die Option beschreibt, empfiehlt, sie aus Datenschutzgründen standardmäßig zu deaktivieren. Ein Balancer, der als Proxy arbeitet, ermittelt den Standort des Clients dagegen anhand dessen eigener Verbindung.
- Was beweist ein erfolgreicher Healthcheck? Nur das, was er abfragt. In Route 53 ist ein TCP-Healthcheck erfolgreich, sobald eine Verbindung hergestellt wurde. Ein HTTP- oder HTTPS-Healthcheck erfordert einen Statuscode der Klasse 2xx oder 3xx, und ein Healthcheck mit Textabgleich erfordert zusätzlich einen vorgegebenen Text im Antwortkörper; die HTTPS-Healthchecks validieren das Zertifikat nicht. Eine Region, deren Frontend Verbindungen annimmt, während die dahinterliegende Anwendung ausfällt, besteht einen TCP-Healthcheck. Den Healthcheck auf eine URL zu richten, die die von Ihren Nutzern benötigten Abhängigkeiten tatsächlich anspricht, ist Ihre Architekturentscheidung. Der Balancer leitet das nicht selbst ab.
- Anycast oder DNS-Steuerung? Bei Anycast wählt das Routingsystem den Standort. Die Auswahl hängt daher nicht von zwischengespeicherten DNS-Antworten ab, doch der Betreiber hat nur begrenzten Einfluss: RFC 4786 beschreibt die Lastverteilung zwischen Anycast-Knoten als im Allgemeinen ungleichmäßig und erklärt, dass die Routingentscheidung länger als eine Transaktion stabil bleiben muss, da eine Client-Server-Interaktion normalerweise von Anfang bis Ende beim selben Knoten bleiben muss. Das ist für langlebige Datenflüsse wie Massendownloads und Medienstreaming relevant. DNS-GSLB kann je nach Richtlinie unterschiedliche Adressen zurückgeben und unterliegt den oben beschriebenen Einschränkungen durch Caching. Beide Verfahren werden auch kombiniert, etwa indem die DNS-Server zur Anfrageweiterleitung selbst eine Anycast-Adresse erhalten.
Wann globale Serverlastverteilung wichtig ist
GSLB wird wichtig, sobald ein Dienst in mehr als einer Region läuft und eine Regel dafür benötigt, welche Region jeder Client nutzt und was beim Ausfall einer Region passiert. Der gewählte Mechanismus bestimmt, wie schnell Datenverkehr umgeleitet wird und wie genau sich Clients lokalisieren lassen: DNS-Antworten werden zwischengespeichert, und standortbasierte DNS-Richtlinien sehen die Adresse des Resolvers, sofern dieser nicht einen Teil der Clientadresse weitergibt. Ein Balancer, der als Proxy arbeitet, entscheidet dagegen für jede Anfrage einzeln, muss aber auch jede Anfrage durchleiten.
Quellen
- RFC 3568: Bekannte Mechanismen zur Anfrageweiterleitung in Content Networks (CN)
- RFC 1034: Domainnamen, Konzepte und Funktionen (TTL und Caching, Abschnitt 3.6)
- RFC 8767: Bereitstellung veralteter Daten zur Verbesserung der DNS-Ausfallsicherheit (geänderte TTL-Definition, Abschnitt 4)
- RFC 7871: Client-Subnetz in DNS-Anfragen
- RFC 4786: Betrieb von Anycast-Diensten
- Amazon Route 53: Auswahl einer Routingrichtlinie
- Amazon Route 53: Standortschätzung für Nutzer mit EDNS0
- Amazon Route 53: Kriterien für einen erfolgreichen Healthcheck
- Amazon Route 53: Auswahl von Einträgen bei konfigurierten Healthchecks (alle Einträge als nicht funktionsfähig eingestuft)
- Amazon Application Recovery Controller: Informationen zur Routingsteuerung (bestehende Verbindungen beim Failover)
- Cloudflare Load Balancing: Proxystatus (Schicht 7 mit Proxy gegenüber reinem DNS)
- k8gb-Issue 134: Ausfallzeit beim Failover ungefähr gleich der DNS-TTL