Warum Hochverfügbarkeit heute im Netzwerk beginnt

Ausfälle sind kein Ausnahmezustand. Sie sind ein Architekturprinzip.

Es gibt einen bemerkenswerten Unterschied zwischen klassischer Infrastruktur und moderner Edge-Architektur. Er zeigt sich nicht im Normalbetrieb. Sondern genau in dem Moment, in dem etwas schiefgeht. Vielleicht ist das zunächst eine ungewohnte Perspektive. Schließlich verbringen die meisten Plattformen den überwiegenden Teil ihrer Lebenszeit damit, nicht auszufallen. Genau deshalb liegt der Gedanke nahe, Infrastruktur für den Normalbetrieb zu optimieren. Die Geschichte moderner Plattformen erzählt jedoch etwas anderes. Je größer Systeme werden, desto unwahrscheinlicher wird es, dass sich jederzeit alle ihre Bestandteile im gewünschten Zustand befinden. Festplatten fallen aus. Switches werden neu gestartet. Glasfaserverbindungen werden beschädigt. Router verlieren Peerings. Rechenzentren gehen offline. Hardware wird gewartet. Menschen machen Fehler. Vielleicht besteht die eigentliche Aufgabe moderner Plattformarchitektur deshalb gar nicht darin, Ausfälle zu verhindern. Vielleicht besteht sie darin, so zu entwerfen, dass Ausfälle ihre Besonderheit verlieren.

Viele klassische Hochverfügbarkeitskonzepte folgen einem vertrauten Muster. Es existiert ein aktives System. Und ein passives. Ein primärer Standort. Und ein sekundärer. Ein produktiver Server. Und ein Standby.

           Primär

        +----------+
        | Aktiv    |
        +----------+
             |
             |
             |
        +----------+
        | Passiv   |
        +----------+

       übernimmt im Fehlerfall

Dieses Modell entstand nicht zufällig. Hardware war teuer. Zusätzliche Ressourcen wurden möglichst nur dann verwendet, wenn sie tatsächlich benötigt wurden. Redundanz bedeutete deshalb häufig, Systeme bereitzuhalten, die den größten Teil ihres Lebens warteten. Dieses Modell funktioniert bis heute. Es besitzt jedoch eine interessante Eigenschaft. Der Fehlerfall unterscheidet sich grundlegend vom Normalbetrieb. Plötzlich ändern sich Rollen. Systeme übernehmen neue Aufgaben. Traffic wird umgeschaltet. Abhängigkeiten verändern sich. Genau in dem Moment, in dem ohnehin bereits ein Fehler aufgetreten ist.

Edge-Plattformen verfolgen häufig einen anderen Ansatz. Nicht weil Aktiv-Passiv grundsätzlich falsch wäre. Sondern weil das Netzwerk bereits eine Eigenschaft besitzt, die sich dafür nutzen lässt. Mehrere Points of Presence können dieselben Dienste gleichzeitig bereitstellen. Wenn ohnehin alle Standorte dieselben Präfixe announcen, dieselben Sicherheitsrichtlinien anwenden und dieselben Verantwortlichkeiten besitzen, stellt sich zwangsläufig eine einfache Frage. Warum sollte einer davon warten?

Deshalb arbeiten moderne Edge-Netzwerke meist Aktiv-Aktiv. Nicht als Optimierung. Sondern als Grundprinzip.

                  Internet

                      |

      +---------------+---------------+
      |               |               |

      v               v               v

  +---------+    +---------+    +---------+
  | Hamburg |    |Frankfurt|    | Alsbach |
  +---------+    +---------+    +---------+

      |               |               |

      +---------------+---------------+

              Alle Standorte aktiv

Jeder Point of Presence verarbeitet produktiven Traffic. Jeder terminiert TLS. Jeder führt Sicherheitsprüfungen durch. Jeder verteilt Requests an die Compute-Plattform. Es existiert kein "Ersatzrechenzentrum". Kein kalter Standby. Kein zweiter Platz. Jeder Standort ist jederzeit vollständiger Bestandteil derselben Plattform.

Vielleicht wird der eigentliche Unterschied jedoch erst sichtbar, wenn einer dieser Standorte verschwindet. Nehmen wir an, Frankfurt fällt vollständig aus. Nicht geplant. Nicht kontrolliert. Sondern in diesem Moment. Welche DNS-Einträge müssen geändert werden? Keine. Welche IP-Adresse muss angepasst werden? Keine. Welche Anwendung muss neu gestartet werden? Keine. Aus Sicht der Plattform verschwindet lediglich ein Netzwerkknoten.

            Vor dem Ausfall

          203.0.113.42

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

     HAM      FRA      ALS


          Nach dem Ausfall

          203.0.113.42

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

     HAM                     ALS

       Route aus Frankfurt entfernt

Der Frankfurter Point of Presence annonciert seine Präfixe nicht länger. Seine Nachbarn erkennen dies. Routingtabellen werden aktualisiert. Neue Verbindungen erreichen automatisch die verbleibenden Standorte. Nicht weil eine Anwendung darauf reagiert. Nicht weil ein Skript ausgeführt wird. Sondern weil das Internet genau für solche Situationen entwickelt wurde.

Natürlich genügt Routing allein nicht. Nicht jeder Fehler betrifft ein gesamtes Rechenzentrum. Häufiger sind deutlich unspektakulärere Szenarien. Ein Kubernetes-Cluster antwortet noch. Ein Service läuft weiterhin. Die Pods existieren. Und trotzdem ist die Anwendung nicht mehr gesund. Vielleicht steigen die Antwortzeiten plötzlich von zehn Millisekunden auf mehrere Sekunden. Vielleicht liefert ein Backend nur noch HTTP 500. Vielleicht blockiert eine Datenbank. Oder eine Abhängigkeit reagiert nicht mehr. Aus Sicht des Routings wäre dieses System weiterhin erreichbar. Aus Sicht des Benutzers ist es bereits ausgefallen. Genau hier beginnt die zweite Ebene moderner Hochverfügbarkeit. Health Checks.

Health Checks werden häufig auf einfache HTTP-Anfragen reduziert. Tatsächlich sind sie weit mehr. Sie bilden das Gedächtnis einer Plattform. Sie beantworten kontinuierlich Fragen wie:

• Ist dieses Backend erreichbar?
• Antwortet es innerhalb der erwarteten Zeit?
• Liefert es valide Antworten?
• Ist nur ein einzelner Service betroffen oder ein kompletter Standort?
• Soll neuer Traffic noch dorthin geleitet werden?

Die eigentliche Anfrage eines Benutzers muss diese Fragen nicht mehr beantworten. Die Plattform kennt ihre Antwort bereits.

Vielleicht ist genau das der entscheidende Unterschied. Ein klassischer Loadbalancer verteilt Verbindungen. Eine moderne Edge-Plattform bewertet kontinuierlich den Zustand ihrer gesamten Infrastruktur. Sie verbindet Routing mit Gesundheitsinformationen. Sie verbindet Netzwerkentscheidungen mit Anwendungszuständen. Sie verbindet das globale Internet mit lokalen Plattformen. Damit verändert sich auch die Bedeutung von Hochverfügbarkeit. Sie entsteht nicht mehr dadurch, dass irgendwo ein zweites System wartet. Sie entsteht dadurch, dass die Plattform jederzeit weiß,

• welche Teile gesund sind,
• welche Verantwortung sie besitzen,
• und wohin der nächste Request sinnvollerweise geleitet werden sollte.

Vielleicht besteht genau darin die wichtigste Erkenntnis dieses Artikels. Ausfälle sind keine Ausnahme. Sie gehören zum normalen Betrieb jeder größeren Plattform. Die eigentliche Qualität einer Architektur zeigt sich deshalb nicht daran, ob Komponenten ausfallen. Sondern daran, wie wenig Bedeutung dieser Ausfall für den Benutzer am Ende besitzt. Und genau an diesem Punkt beginnt die nächste Frage. Wenn eine Plattform permanent entscheidet, ob und wohin Requests geleitet werden – welche Rolle spielt dann eigentlich DNS noch? Ist DNS wirklich nur das Telefonbuch des Internets? Oder ist es längst selbst Teil moderner Plattformarchitektur? Genau darum wird es im nächsten Teil von Building the Edge gehen.