In der heutigen digitalen Welt sind schnelle, zuverlässige und skalierbare Content Delivery Networks (CDNs) unverzichtbar für die Auslieferung von Webinhalten an Nutzer auf der ganzen Welt. Ein Anycast CDN, das auf der Anycast-Routing-Technologie basiert, bietet hierbei mehrere Vorteile, vor allem was Ausfallsicherheit und niedrige Latenzzeiten angeht. Obwohl große Unternehmen häufig proprietäre Lösungen nutzen, gewinnt der Aufbau eines eigenen Open Source Anycast CDNs zunehmend an Bedeutung – sowohl als Lernprojekt als auch als praktikable Lösung für kleinere Anbieter. Das Konzept begann im Sommer 2020 mit der Neugier eines jungen Netzwerkbegeisterten, der während der Quarantäne sein eigenes Anycast CDN von Grund auf bauen wollte. Der Fokus lag darauf, praktische Erfahrungen zu sammeln und zum ersten Mal ein funktionierendes Anycast-DNS-System zu erstellen.
Da DNS-Protokolle überwiegend UDP nutzen und damit weniger komplex in der Zustandsverwaltung sind, wurde DNS als Einstiegspunkt gewählt. Die Realisierung begann mit der Beschaffung einer IP-Adress-Range sowie einer Autonomous System Number (ASN). Drei Debian-basierte virtuelle Maschinen wurden aufgesetzt, jeweils mit BIRD als BGP-Routing-Stack und BIND als DNS-Server-Software. Die VMs standen an unterschiedlichen geografischen Standorten und kündigten identische IP-Präfixe an, was die Kernidee von Anycast umsetzte: dieselbe IP-Adresse über verschiedene Orte zu verbreiten, sodass der Nutzer stets den geografisch nächstgelegenen oder am besten erreichbaren Server anfragt. Über ein paar Hundert Zeilen Ansible Playbooks gelang die Automatisierung der Konfiguration von BGP und DNS.
Spannend war vor allem das Experiment, das Routing von einer der Anycast-Knoten abzuziehen und zu beobachten, wie schnell die anderen Knoten die Anfragen übernahmen – ein eindeutiger Beweis für die Effektivität der Anycast-Technologie. Obwohl das Netzwerk stabil lief, wurde schnell klar, dass manuelle DNS-Zonenverwaltung durch Bearbeitung von Dateien unpraktisch ist und nicht skalierbar. Daher entwickelte sich die Architektur weiter und ein Control Plane wurde implementiert. Diese zentrale Steuerebene basierte auf einer Kombination aus Flask API für den Webendpunkt, MongoDB für die Speicherung von DNS-Daten und BeanstalkD als Message Queue zur Orchestrierung der Updates. Änderungen an DNS-Zonen wurden so programmgesteuert angenommen, gespeichert und anschließend an alle Anycast-Knoten verteilt.
Ein wichtiges Designprinzip war dabei, die Interaktion zwischen Control Plane und Knoten so einfach wie möglich zu halten. Anstatt komplexer RPC-Aufrufe wurde auf den Austausch von JSON-Blobs via SSH gesetzt. Dies erhöhte die Sicherheit und reduzierte den Aufwand für Kommunikationsprotokolle. Mit eingeführter Nutzer-Authentifizierung konnten darüber hinaus Freunde und andere Nutzer ihre eigenen Domains auf dem Netzwerk hosten. Nach der soliden Etablierung der DNS-Infrastruktur erfolgte die Ausweitung auf HTTP Caching.
Hierfür wurden die Open Source Produkte Varnish als Cache-System und Caddy als Reverse Proxy verwendet. Der Herausforderung der TLS-Zertifikatsverwaltung wurde besondere Aufmerksamkeit geschenkt, da bei Anycast die Prüfungen von Let’s Encrypt zwangsläufig verteilt und asynchron stattfinden. Der initiale Versuch, das HTTP-01 ACME Verfahren zu automatisieren, erwies sich als zu komplex und fehleranfällig, da der Node, der das Zertifikat beantragte, nicht zwangsläufig auch den Validierungs-Request bedienen konnte. Ein glücklicher Zufall brachte die Entdeckung der DNS-basierten ACME Challenge, die das System erheblich vereinfachte. Die Validierung erfolgt dabei über DNS-TXT-Einträge, die zentral über die eigene DNS API eingepflegt wurden.
Dadurch entfiel die Notwendigkeit, HTTP-Endpunkte an jeder einzelnen Anycast-Edge-Node zu betreiben und zu synchronisieren. Das Netzwerk erweiterte sich geografisch sowie strukturell. Wo zuvor einzelne Bare-Metal-Server oder VMs pro Point of Presence (PoP) betrieben wurden, wurde der Einsatz eines größeren PoP mit mehreren VMs realisiert. Diese waren über BGP mit dem lokalen Router verbunden und verwendeten Equal-Cost Multi-Path (ECMP) Routing zur Lastverteilung der eingehenden Anfragen. Das führte zu einer effizienteren Nutzung von Ressourcen und verbesserte die Skalierbarkeit erheblich.
Mit wachsender Anzahl von BGP-Sessions stieg auch der Aufwand für die Konfiguration und Verwaltung. Die ursprünglichen Ansible Playbooks reichten bald nicht mehr aus, um eine Vielzahl von Peering-Umgebungen mit den entsprechenden Filtern und Sicherheitsmechanismen abzubilden. Als Lösung wurde ein eigener „BIRD Configuration Generator“ (BCG) in Go entwickelt, der basierend auf einer einfachen YAML-, TOML- oder JSON-Config automatisch BIRD-Konfigurationen inklusive RPKI-, IRR- und Max-Prefix-Filter erstellt. Dabei wurde die PeeringDB als Datenquelle genutzt, was erheblich die Automatisierung und Fehlerreduzierung in der Netzwerkverwaltung ermöglichte. Um den Betrieb und Zustand des Netzwerks genau beobachten zu können, kamen unterschiedliche Monitoring-Werkzeuge zum Einsatz.
Ein zentraler Route Collector, der multihop iBGP-Feeds von allen Anycast-Knoten sammelt, verschafft einen Überblick über die tatsächlich annoncierten und empfangenen Routen und deren Attribute, was besonders für das Traffic Engineering wichtig ist. Darüber hinaus wurden Prometheus und Grafana zur Auswertung von Performance-Metriken genutzt, darunter CPU, Bandbreitenauslastung, Status der BGP-Sessions und spezifische Statistiken zu BIND, Varnish und Caddy. Ergänzend kamen Community-basierte Tools wie NLNOG RING und RIPE Atlas zum Einsatz, um von weltweit verteilten Messpunkten aus Routenverläufe, Latenzen und mögliche „scenic routes“ zu identifizieren und zu optimieren. Zur Optimierung wurde zudem ein benutzerdefiniertes Tool entwickelt, mit dem man Pings von mehreren Quell-IP-Adressen ausführen und die Ergebnisse übersichtlich in Tabellenform darstellen kann. So lassen sich Latenzzeiten, Paketverlust und andere Netzwerkparameter verschiedener Anbieter und Leitungen effizient vergleichen.
Das Projekt ist exemplarisch für den Aufbau moderner Infrastrukturen mit Open Source Software, die durch clevere Automatisierung und Monitoring auch mit begrenzten Ressourcen betrieben werden können. Derzeit wird die Steuerungsebene komplett neu in Go entwickelt, darunter auch Features wie DNSSEC-Unterstützung und individuell definierbare Cache-Policies. Parallel entsteht eine hochverfügbare Anycast-Container-Plattform, die die Skalierbarkeit und Flexibilität des Netzwerks noch weiter erhöhen wird. Der Funktionsumfang, die Automatisierung und das Zusammenspiel aus Netzwerkprotokollen und Applikationsebene geben tiefe Einblicke in das, was bei kommerziellen CDNs hinter der Kulisse passiert. Für technisch Interessierte bietet der Quellcode unter GitHub die Möglichkeit, selbst mitzuwirken oder Lösungen an eigene Bedürfnisse anzupassen.
Darüber hinaus gibt es Videos und Vorträge, beispielsweise auf NANOG-Konferenzen, die das gesamte Projekt und die erlernten Lektionen ausführlich dokumentieren. Insgesamt zeigt das Projekt eindrucksvoll, dass Anycast-CDNs nicht nur großen Konzernen vorbehalten sind. Mit fundiertem Wissen, der richtigen Open Source Infrastruktur und viel Leidenschaft lassen sich leistungsfähige, weltweite Netzwerke selbst aufbauen und betreiben. Besonders für kleine Webanbieter und Forscher bietet sich hier eine spannende Möglichkeit, die Mechanismen moderner Kommunikationstechnik zu verstehen und selbst zu gestalten.
