Geo-Redundant - why Google Cloud LB is great
Intro
Hochverfügbarkeit, Geo-Redundante Ausführung & Resilienz - um einige Begrifflichkeiten aufzuzählen, wie sie ihre Verwendung finden, um die Zuverlässigkeit von Anwendungen zu beschreiben.
Dieser Artikel soll einen Einstieg in die Thematik geben, vor allem dahingehend wie eine geografisch verteilte, hochverfügbare Anwendung mit optimierten (geringen) Zugriffszeiten auf Google Cloud bereitgestellt werden kann und weshalb Google in diesem Zusammenhang so besonders ist.
Tech-Part
Zuerst sehen wir uns an, wie dieses Problem von den meisten Anbietern bzw. Produkten gelöst wird: Nämlich via Geo-DNS.
Geo-DNS
Das Prinzip ist eigentlich nicht schwer zu verstehen. Ein DNS-Eintrag, wie wir ihn täglich verwenden, löst einen Hostname zu einer für den Computer verständlichen Adresse (einer IP) auf. Wie eine Art Telefonbuch, welche Namen und deren zugehörige Nummer bereitstellt. Ein Geo-DNS Eintrag erweitert diese Funktion um eine geografische Komponente. So hat ein Name nun mehrere Nummern bzw. IPs hinterlegt und je nachdem von wo aus die Namensauflösung erfolgt, bekommt der Benutzer die IP mit der kürzesten Distanz retourniert. Vergleichbar mit den Vorwahlen bei Telefonnummern der jeweiligen Länder.
Grafisch veranschaulicht stellt sich dies wie folgt dar:
Das Problem an der Sache entsteht, wenn eine Lokation nicht mehr erreichbar ist, denn DNS ist ein System, welches stark auf Caching basiert und Änderungen in vielen Fällen nicht rasch propagieren kann. Im oben dargestellten Fall wäre dies beim Ausfall des Services mit IP “4.3.2.1” der Fall: Unser Geo-DNS System kann denn Ausfall erkennen und offeriert den Benutzern indessen die Adresse “1.2.3.4” - jedoch kann diese Änderungen in manchen Fällen Stunden in Anspruch nehmen.
“Aber Bernd, du musst doch nur die TTL nach unten setzen!“ – sagst du dir jetzt? NEIN!
Oder besser, fast immer nein.
Wie bereits erwähnt ist DNS so konzipiert, dass es sich auf das Cachen von Einträgen verlässt und so die Last verringert. Dieses Verhalten kann jedoch durch den sogenannten TTL-Wert (Time-To-Live) verändert werden. Setzen wir also den TTL auf unserer Domain auf nur eine Minute (in der Regel ist der Wert im Stundenbereich) so müssten spätestens nach einer Minute alle Benutzer wieder zugreifen können, da ja der Wert erneut abgefragt wird. Im Idealfall Ja, im “echten Leben” jedoch Nein.
Denn das DNS System ist hierarchisch aufgebaut, wie folgende Grafik darstellt:
Quelle: threat.media
Das bedeutet bei geringer TTL wird nach jedem Ablauf eine Vielzahl an Verbindungen hergestellt, um den aktuellen DNS Eintrag richtig auflösen zu können. Das kostet viel Energie und Datenverkehr. Verwendet man einen modernen und sicheren DNS-Resolver , wie wir Nerds & Technik begeisterte es tun, ist das grundsätzlich kein Problem. Aber, und jetzt kommt es.
Der 0815 Benutzer verwendet nun mal den DNS-Resolvers seinen ISPs - der ist schließlich vorkonfiguriert und es funktioniert ja! Die meisten ISPs kämpfen jedoch mit einer hohen Last auf Ihren DNS-Systemen durch Millionen von Anfragen von ihren Benutzern. DNS ist nun mal, wie im Abschnitt zuvor skiziiert, ein System welches auf Caching basiert. Das Problem sind nicht die Geo-DNS Einträge welche auf eine niedrige TTL angewiesen sind, sondern die “Angst” vieler System Admins. “Wenn etwas passiert, kann ich mit einem niedrigen TTL schneller meine Seite umschalten als mit hohen” - lauten die Argumente. Und so werden monatlich aber tausende DNS-Anfragen ohne wirkliche Notwendigkeit abgesetzt und die DNS-Resolver belastet.
Ein detaillierter Thread dazu ist auf Ycombinator nachzulesen, siehe:
Stop using low DNS TTLs
“Was ist die Antwort darauf? Ihr habt es vermutlich geahnt!"
Viele ISPs ignorieren zu niedrige TTLs und überschreiben diese.
Es ist also in vielen Fällen komplett sinnfrei, eine TTL von weniger als 5 Minuten zu setzen. Einige DNS Anbieter verwenden als Werbe-Slogan “TTL von nur 10 Sekunden”. Toll, das kostet mich jedoch maximal einen “Schmunzler” :-).
Gut, nur wie lösen wir das Problem? Richtig, wir bewegen uns ein paar OSI-Layer Schichten nach unten und begegnen dem Problem der geografischen Lastverteilung schon früher.
Für Quereinsteiger als Referenz: OSI-Modell
Anycast-IP
Im konkreten bewegen wir uns von L7 (DNS) zu L3, der Vermittlungsschicht, auf welcher Anycast-IP fungiert.
Durch den Einsatz einer Anycast-IP benötigt man keine Geo-DNS System mehr. Man stellt sein Service mit nur einer einzigen IP bereit, welche jedoch mehrfach an verschiedenen Orten der Welt erreichbar ist. Das ist in einem herkömmlichen Computernetzwerk (Unicast) nicht möglich, da eine IP nur ein einzigen Mal einem einzigen Gerät vergeben werden kann. An dieser Stelle kommt jedoch Anycast ins Spiel, welches durch den Einsatz von iBGP eine IP mehrfach announcen kann. Das Border Gateway Protocol (BGP) bildet das fundament unseres heutigen Internets - es verbindet unterschiedliche Netzwerke und tauscht Routing-Informationen aus. Dadurch können wir Benutzersysteme an anderen Ende der Welt erreichen. Aber eben auch das mehrfache “Announcen” von einer IP ist durch dieses Protokoll möglich.
Die unterschiedlichen Verbindungsmethoden sind nachfolgend ersichtlich:
Quelle: Multicast Routing, Jorma Paananen
“Super, dann nehmen wir doch einfach eine Anycast-IP für unsere Anwendung: Problem erledigt!" Korrekt, nur ist das nicht so einfach!
ASN & /24
Damit Ihr selbst IPv4 Adressen via BGP announcen könnte benötigt man:
- einen RIPE Account
- ein /24 IPv4 Netzwerk
- eine ASN (Autonomous System Number)
- einen Anbieter mit BGP (Transit) Untersützung.
Kurzum: ein /24 Netzwerk zu erwerben kostet hunderte-tausend Euro, bleibt nur die Option einen dieses zu mieten. Aber auch hier bleiben schnell einige hundert Euro monatlich auf der Strecke. Diese Lösung ist zwar technisch spannend, aber nicht wirklich praktikabel.
Referenz: Build your own Anycast Network in Nine Steps, Samir Jafferali
Google Cloud
An dieser Stelle kommt Google Cloud und deren Loadbalancer ins Spiel. In der Dokumentation dazu stolpert man rasch über: “Bietet regionsübergreifendes Load-Balancing und automatisches Failover auf mehrere Regionen. Cloud Load Balancing reagiert sofort auf Änderungen hinsichtlich Nutzern, Traffic, Netzwerk, Back-End-Zustand und anderen damit verbundenen Bedingungen.” Die Kosten belaufen sich auf ungefähr 18$ pro Monat, Datenverkehr kommt extra hinzu.
18$ für eine Anycast-IP sowie globalen LB von Google
“Wow, das ist wirklich genial!"
Alternativen dazu gibt es nur sehr wenige, wie:
Während Google das Service bereits seit Jahren anbietet, zieht Microsoft Azure erst jetzt nach und stellt eine derartige Funktion als Preview bereit. Flyi.IO hingegen ist eine “neuartige” Plattform, welche auf Firecracker-VMs setzt und ebenso Anycast anbietet. Auf Fly.IO möchte ich in meinem nächsten Post näher eingehen.