DNS und Loadbalancing in der Edge-Architektur einordnen

TL;DR

DNS, Anycast-Erreichbarkeit und Loadbalancing lösen unterschiedliche Aufgaben. Eine erfolgreiche DNS-Auflösung beweist noch keine erreichbare Anwendung; eine erreichbare Edge beweist wiederum nicht, dass ein Backend gesund ist. Für die Fehlerdiagnose muss die gesamte Kette getrennt betrachtet werden: DNS-Antwort, Edge-Erreichbarkeit, Protokollverarbeitung und Backend-Verteilung.

Einleitung

Viele Störungen werden vorschnell als „Loadbalancing-Problem“ bezeichnet, obwohl der Fehler bereits bei der DNS-Auflösung oder beim Routing zur Edge liegt. Umgekehrt kann ein Dienst technisch korrekt über DNS und Anycast erreichbar sein, während die eigentliche Anwendung wegen eines fehlerhaften Backends nicht antwortet. Diese Schichten haben unterschiedliche Zuständigkeiten, Messpunkte und Ausfallbilder. DNS liefert eine Auflösungsentscheidung, Anycast bringt den Traffic zur Edge und das Loadbalancing verteilt ihn auf geeignete Backends. Im Betrieb ist deshalb entscheidend, die Kette nicht als eine einzige Funktion zu behandeln. Wer die Ebenen systematisch trennt, verkürzt die Fehlersuche und vermeidet unnötige Änderungen an einer funktionierenden Architekturkomponente.

1. DNS-Auflösung ist der erste, aber nicht der einzige Prüfpunkt

Bei einer Anfrage beginnt der Ablauf typischerweise mit der DNS-Auflösung des öffentlichen Namens. Der Resolver des Clients fragt die autoritativen DNS-Strukturen ab und erhält die für den Dienst vorgesehene Erreichbarkeitsinformation. In einer Edge-Architektur kann Anycast DNS dafür sorgen, dass DNS-Anfragen über eine verteilte Struktur beantwortet werden. Multi-Provider-DNS kann zusätzlich die Abhängigkeit von einer einzelnen DNS-Infrastruktur reduzieren.

Für die Diagnose ist zunächst relevant, ob überhaupt eine gültige Antwort vorliegt, ob sie zum erwarteten Dienst gehört und ob unterschiedliche Resolver konsistente Ergebnisse liefern. Ein Timeout beim DNS-Lookup, eine fehlende Delegation oder veraltete Einträge liegt auf einer anderen Fehlerdomäne als ein späterer HTTP-Fehler. Auch ein negativer DNS-Cache kann dazu führen, dass eine Korrektur nicht sofort bei allen Clients sichtbar wird.

Eine erfolgreiche Auflösung sagt jedoch nur, wohin ein Client verbinden soll. Sie sagt nicht, ob die Edge erreichbar ist, ob TLS funktioniert oder ob ein Backend Anfragen verarbeiten kann.

2. Anycast-Erreichbarkeit und Edge-Routing getrennt prüfen

Nach der DNS-Auflösung baut der Client eine Verbindung zu der veröffentlichten Adresse auf. Anycast sorgt dabei dafür, dass dieselbe Adresse über mehrere Netzpfade erreichbar sein kann. Das Routing entscheidet, an welchem verfügbaren Edge-Punkt der Traffic angenommen wird. Diese Ebene ist weder DNS noch Backend-Loadbalancing: Sie bestimmt zunächst, ob der Datenverkehr die Edge-Infrastruktur erreicht.

Ein typisches Fehlerbild ist eine erfolgreiche DNS-Auflösung mit anschließendem Verbindungs-Timeout. Dann sollte geprüft werden, ob TCP-Verbindungen aufgebaut werden können, ob die erwartete Zieladresse erreicht wird und ob das Problem aus bestimmten Netzen oder Regionen auftritt. Ein selektiver Ausfall kann auf Routing- oder Erreichbarkeitsprobleme hindeuten, während ein globaler Fehler eher eine übergeordnete Konfiguration oder einen Dienstzustand betrifft.

Die ayedo Edge Cloud nutzt eine eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System. Für die Betriebsanalyse bleibt die Schichtentrennung trotzdem entscheidend: Die Edge kann erreichbar sein, ohne dass ein konkretes Backend gesund ist. Umgekehrt kann ein Backend fehlerfrei arbeiten, ohne dass Clients die Edge erreichen.

3. Layer-4- und Layer-7-Loadbalancing unterscheiden

Erreicht eine Verbindung die Edge, beginnt die eigentliche Verarbeitung des Traffics. Layer-4-Loadbalancing verteilt Verbindungen anhand von Transportmerkmalen wie IP-Adresse und Port. Es ist relevant für TCP- oder UDP-basierte Dienste, bei denen die Edge nicht zwingend die Anwendungsebene interpretieren muss. Fehler zeigen sich hier häufig als abgelehnte Verbindungen, Timeouts oder fehlende Weiterleitung.

Layer-7-Loadbalancing verarbeitet dagegen Anwendungsmerkmale, etwa HTTP-Hostnamen, Pfade oder Header. Dadurch können Regeln für HTTP-/HTTPS-Services, TLS Termination oder eine gezieltere Backend-Auswahl greifen. Ein TCP-Verbindungsaufbau kann deshalb erfolgreich sein, während die HTTP-Anfrage anschließend mit einem Fehlerstatus beantwortet wird oder kein passendes Routing findet.

Für das Troubleshooting müssen Verbindungs- und Anwendungsebene getrennt getestet werden: zunächst der TCP-Handshake, danach TLS und schließlich die konkrete HTTP-Anfrage. Backend Health Checks und Failover beeinflussen, ob ein Ziel überhaupt in die Verteilung einbezogen wird. Ein gesund erscheinender Listener bedeutet daher nicht automatisch, dass die Anwendung hinter ihm korrekt antwortet.

4. Backend-Verteilung und Fehlerdomänen im Betrieb

Am Ende der Kette steht die Verbindung zum Backend. Die Edge Cloud verteilt den eingehenden Traffic auf konfigurierte Ziele und kann deren Zustand über Health Checks bewerten. Sind alle Backends aus Sicht der Edge fehlerhaft, kann ein Dienst trotz funktionierendem DNS und erreichbarer Anycast-Adresse nicht nutzbar sein. Einzelne fehlerhafte Ziele erzeugen dagegen oft sporadische Fehler, wenn nur ein Teil der Anfragen betroffen ist.

Für die Eingrenzung helfen Korrelationen: Treten Fehler nur bei bestimmten Verbindungen auf, liegt der Schwerpunkt eher auf Layer 4. Sind nur bestimmte Pfade, Hostnamen oder Methoden betroffen, ist Layer 7 wahrscheinlicher. Antworten mit Backend-spezifischen Statuscodes oder stark schwankendes Verhalten können auf die Verteilung oder den Zustand einzelner Ziele hinweisen.

Backend Cloaking reduziert zusätzlich die direkte öffentliche Sichtbarkeit der eigentlichen Systeme. Dadurch wird die Analyse auf die definierte Edge-zu-Backend-Verbindung konzentriert. In Umgebungen mit ayedo Managed Kubernetes ebenso wie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern bleibt die Verantwortungsgrenze gleich: Die Edge verarbeitet und verteilt den öffentlichen Traffic; der Cluster betreibt die Workloads.

Praxis- und Betriebsszenario

Ein API-Dienst ist nach einer Änderung nicht erreichbar. Der erste DNS-Test liefert die erwartete Adresse. Ein TCP-Test zur Edge ist ebenfalls erfolgreich, während TLS korrekt terminiert. Ein HTTP-Aufruf auf /health funktioniert, Anfragen auf /orders liefern jedoch Fehler.

Die Diagnose beginnt damit nicht beim DNS. Layer 4 und die Edge-Erreichbarkeit sind nach aktuellem Befund intakt. Der Unterschied liegt auf Layer 7 oder im Backend-Routing. Anschließend werden Routing-Regeln, Health-Check-Ergebnisse und die Verteilung auf die Backends geprüft. Zeigt nur ein Backend Fehler, kann ein Failover oder eine Korrektur dieses Ziels die Störung beheben. Ohne diese schrittweise Prüfung würde eine DNS-Änderung die Ursache nicht beseitigen, sondern lediglich eine weitere Variable einführen.

FAQ

Beweist eine erfolgreiche DNS-Auflösung, dass der Dienst verfügbar ist?

Nein. DNS liefert nur die Zielinformation. Erreichbarkeit der Edge, TLS, Protokollverarbeitung und Backend-Zustand müssen separat geprüft werden.

Wann ist Layer 4 statt Layer 7 relevant?

Layer 4 steht im Vordergrund, wenn bereits der TCP- oder UDP-Verbindungsaufbau scheitert. Layer 7 wird relevant, sobald die Anwendungsebene über HTTP, HTTPS oder Routing-Regeln betroffen ist.

Welche Rolle spielen Health Checks bei der Fehlersuche?

Sie zeigen, ob Backends aus Sicht der Edge als verfügbar gelten. Ein Backend kann lokal funktionieren, aber wegen Erreichbarkeits- oder Prüfproblemen aus der Verteilung ausgeschlossen werden.

Fazit

DNS und Loadbalancing sind keine austauschbaren Bausteine, sondern aufeinanderfolgende Schichten mit unterschiedlichen Fehlerbildern. Eine belastbare Betriebsdiagnose prüft zuerst die Namensauflösung, dann Anycast-Erreichbarkeit, Transportverbindung, Anwendungsrouting und schließlich Backend-Zustand. Die ayedo Edge Cloud bündelt diese Funktionen in einer verteilten Edge-Plattform, ohne die Verantwortungsgrenze zum Compute aufzulösen. Genau diese Trennung macht Fehleranalyse und Betrieb nachvollziehbar.