Eine IP-Adresse kann an drei Orten gleichzeitig existieren

Warum Anycast keine Funktion, sondern eine Eigenschaft des Internets ist.

Am Ende des letzten Artikels haben wir das Internet an einem interessanten Punkt verlassen. Wir hatten gesehen, dass das Internet aus tausenden unabhängigen Netzwerken besteht. Dass jedes dieser Netzwerke seine eigenen Routingentscheidungen trifft. Und dass Border Gateway Protocol nicht versucht, den schnellsten Weg zu finden, sondern einen erreichbaren. Genau dort beginnt nun eine neue Frage. Wenn das Internet weder Anwendungen noch Rechenzentren kennt – wie kann dieselbe Anwendung Benutzer aus Hamburg, Frankfurt oder München trotzdem nahezu immer über den nächstgelegenen Point of Presence erreichen? Viele vermuten an dieser Stelle GeoDNS. Andere denken an Loadbalancer. Wieder andere stellen sich eine zentrale Datenbank vor, die anhand des Benutzerstandorts entscheidet, welches Rechenzentrum verwendet werden soll. Keine dieser Annahmen trifft auf Anycast zu.

Betrachten wir zunächst, was der Browser überhaupt weiß. Nachdem DNS seine Arbeit beendet hat, besitzt der Client genau eine Information. Eine einzige IP-Adresse.

https://api.example.de

        │

        ▼

203.0.113.42

Mehr kennt der Browser nicht. Keine Region. Keinen Point of Presence. Keine Cloud. Keine Information darüber, wo diese Adresse tatsächlich betrieben wird. Für ihn existiert lediglich eine Verbindung.

Die meisten Menschen verbinden mit einer IP-Adresse automatisch einen Server. Das erscheint zunächst logisch. Schließlich verbinden wir uns zu einer Adresse und erhalten eine Antwort. Historisch war dieses Modell sogar weitgehend korrekt. Ein Server. Eine Adresse. Eine Anwendung. Heute stimmt dieses Bild jedoch immer seltener. Eine öffentliche IP-Adresse beschreibt längst nicht mehr zwangsläufig einen einzelnen Rechner. Sie beschreibt häufig ein gesamtes Netzwerk. Und genau dort beginnt Anycast.

Stellen wir uns vor, dieselbe Plattform betreibt Points of Presence in Hamburg, Frankfurt und Alsbach. Jeder dieser Standorte annonciert dasselbe Präfix.

             203.0.113.0/24

                  │

      gleichzeitig annonciert

     +----------+----------+----------+
     |          |          |          |
     v          v          v

 Hamburg    Frankfurt   Alsbach

Vielleicht wirkt diese Situation zunächst widersprüchlich. Wie kann dieselbe Adresse gleichzeitig an mehreren Orten existieren? Die Antwort lautet: Weil das Internet nie gelernt hat, dass sie nur an einem Ort existieren dürfte. Aus Sicht von BGP handelt es sich schlicht um mehrere erreichbare Pfade zum selben Präfix. Nicht mehr. Nicht weniger.

Hier geschieht etwas Bemerkenswertes. Der Browser entscheidet nicht, welcher Point of Presence verwendet wird. DNS ebenfalls nicht. Auch die Anwendung besitzt darüber keinerlei Kenntnis. Die Entscheidung entsteht vollständig innerhalb des Routings. Jedes Autonomous System betrachtet die verschiedenen erreichbaren Pfade und wählt anhand seiner Routingrichtlinien den bevorzugten aus. Für einen Benutzer in Norddeutschland kann dies Hamburg sein. Für einen Benutzer im Rhein-Main-Gebiet Frankfurt. Für einen anderen wiederum Alsbach. Alle verwenden dieselbe URL. Alle erhalten dieselbe IP-Adresse. Und dennoch erreichen sie unterschiedliche Standorte. Nicht aufgrund einer Anwendung. Sondern aufgrund der Architektur des Internets selbst.

Vielleicht liegt genau darin das größte Missverständnis rund um Anycast. Oft wird Anycast beschrieben, als wäre es eine Funktion. Fast so, als gäbe es irgendwo einen Dienst, der Benutzer intelligent auf verschiedene Rechenzentren verteilt. Tatsächlich existiert ein solcher Dienst überhaupt nicht. Anycast ist keine Software. Keine Appliance. Kein Loadbalancer. Und auch kein eigenes Netzwerkprotokoll. Es entsteht ausschließlich dadurch, dass mehrere Standorte dieselben Präfixe über dasselbe Autonomous System announcen. Der Rest ist Routing.

An dieser Stelle lohnt sich ein kleines Gedankenexperiment. Stellen wir uns vor, Frankfurt verschwindet. Nicht langsam. Nicht geplant. Sondern in diesem Augenblick. Der Point of Presence fällt vollständig aus. Welche Adresse muss nun geändert werden? Gar keine. Welche DNS-Einträge müssen angepasst werden? Keine. Welche Anwendung muss davon wissen? Ebenfalls keine. Was tatsächlich verschwindet, ist lediglich eine Route. Frankfurt annonciert das Präfix nicht länger. Die benachbarten Netzwerke übernehmen diese Information. Sie aktualisieren ihre Routingtabellen. Neue Verbindungen gelangen automatisch über die verbleibenden Standorte.

             Vorher

          203.0.113.42

      +--------+--------+--------+
      |        |        |
      v        v        v

     HAM      FRA      ALS


            Nachher

          203.0.113.42

      +--------+                 +--------+
      |        |                 |
      v        v                 v

     HAM                     ALS

       Frankfurt withdrawn

Vielleicht erklärt genau dieses Verhalten, weshalb Anycast häufig als besonders fehlertolerant wahrgenommen wird. Nicht weil es Ausfälle verhindert. Sondern weil Ausfälle häufig lediglich dazu führen, dass das Internet einen anderen erreichbaren Pfad verwendet. Die Adresse bleibt identisch. Der Benutzer bemerkt davon im Idealfall überhaupt nichts.

Damit entsteht jedoch sofort eine neue Frage. Woher weiß eine Plattform eigentlich, ob ein Point of Presence noch erreichbar ist? Woher weiß sie, dass ein Backend zwar antwortet, aber bereits viel zu langsam geworden ist? Und wie entscheidet sie, wann Traffic umgeleitet werden muss? Genau an dieser Stelle reicht Routing allein nicht mehr aus. Jetzt beginnt eine zweite Ebene der Architektur. Health Checks. Loadbalancing. Traffic Steering. Und die Frage, warum moderne Hochverfügbarkeit heute weit mehr mit Netzwerkarchitektur als mit zusätzlichen Servern zu tun hat. Genau darum wird es im nächsten Teil dieser Serie gehen.