Infrastrukturarchitektur: Container schaffen eine vierte Ebene

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

In herkömmlichen Netzwerkinfrastrukturen gibt es im Allgemeinen drei Architekturebenen: die Daten-, die Steuerungs- und die Verwaltungsebene.

Die genauen Definitionen können je nach Art und konkreter Implementierung der Infrastruktur variieren, doch die grundlegenden Modelle treffen auf die meisten Netzwerkinfrastrukturen weitgehend zu.

• Datenebene
  
  • In der modernen Terminologie wird die Datenebene manchmal auch als Datenpfad bezeichnet. Sie ist der Pfad, über den Pakete (Daten) übertragen werden. Die Datenebene ist dafür zuständig, Pakete anzunehmen und an das richtige Ziel weiterzuleiten.
• Steuerungsebene
  
  • Im Allgemeinen bestimmt die Steuerungsebene, wohin Daten weitergeleitet werden. Routingprotokolle sind gute Beispiele für Funktionen der Steuerungsebene, ebenso wie übergeordnete Entscheidungsprozesse, die heutzutage dynamischer sein können. Die konkrete Implementierung variiert und kann von der Übergabe von Daten durch die Datenebene an die Steuerungsebene zur Entscheidungsfindung bis hin zur transparenten Beobachtung der Daten durch die Steuerungsebene und dem Reagieren auf bestimmte Auslöser reichen. Steuerungsebenen sind häufig auch dafür verantwortlich, den Zustand von Geräten zu überwachen und Statistiken zu erfassen.
• Management-Ebene
  
  • Die Managementebene ist die sichtbarste der drei Ebenen, da wir über sie mit der Steuerungsebene interagieren. Herkömmliche Managementebenen verwenden CLI (Befehlszeilenschnittstellen), während moderne Managementebenen API (Programmierschnittstellen) bevorzugen. Unabhängig von der verwendeten Methode ermöglicht die Managementebene den Betreibern, Richtlinien festzulegen, die von der Steuerungsebene durchgesetzt werden. Dazu gehören Konfigurationsoptionen wie Lastausgleichsalgorithmen sowie Zulassungs- und Sperrrichtlinien, die auf Merkmalen wie IP-Adresse und Gerätetyp basieren.

Doch im Hintergrund ist noch eine andere Art der Orchestrierung am Werk, die für die Betreiber weitgehend unsichtbar bleibt. Sie hat nichts mit Management zu tun, außer dass sie einige Aufgaben übernimmt, die bislang von menschlichen Betreibern wahrgenommen wurden.

Der Unterschied besteht hier darin, dass die Aktionen automatisch durch Änderungen an der Umgebung während der Ausführung ausgelöst werden und nicht durch ein Bereitstellungsereignis. Die Information darüber, was sich geändert hat, ist jedoch unerlässlich und muss daher irgendwoher bezogen werden.

In einem traditionellen Betriebsmodell stammen diese Informationen in der Regel aus Änderungstickets oder -anfragen. Bei modernen Betriebsmodellen und insbesondere bei Containern stammen diese Informationen über einen Discovery-Mechanismus aus Service-Registrys.

Dienstregistrierungen und Diensterkennung

Containerumgebungen basieren unter anderem auf der Annahme, dass IP-Adressen für die Anwendungsumgebung praktisch keine Rolle spielen. Für die Infrastruktur sind sie jedoch durchaus relevant, da Daten weiterhin von Gerät zu Gerät geroutet und weitergeleitet werden müssen, um den Weg zwischen dem Client und der Anwendung zurückzulegen. In modernen Umgebungen existieren diese IP-Adressen häufig nur für kurze Zeit (für die Lebensdauer eines Containers/Dienstes).

Betrachten Sie diese Erkenntnisse von DataDog (Hervorhebung hinzugefügt):

Die rasche Verbreitung von Orchestratoren (siehe Fakt 4) scheint die Lebensdauer von Containern weiter zu verkürzen, da das automatisierte Starten und Stoppen von Containern zu einer höheren Fluktuationsrate führt. In Unternehmen, die einen Orchestrator einsetzen, beträgt die typische Lebensdauer eines Containers etwa 12 Stunden. In Unternehmen ohne Orchestrierung beträgt die durchschnittliche Lebensdauer eines Containers sechs Tage.

_{Quelle: <https://www.datadoghq.com/docker-adoption>}

Stellen Sie sich vor, Sie müssten als Betreiber alle sechs Tage oder sogar alle zwölf Stunden die Routingtabellen oder Load-Balancing-Pools aktualisieren. Sie kämen kaum noch zu etwas anderem. Das Risiko von Fehlkonfigurationen wäre erheblich und würde wahrscheinlich weiter steigen, je länger Sie gezwungen wären, die Änderungen in einem Container-Cluster manuell zu verwalten.

Eine Service-Registry wie Consul wird zu einer entscheidenden Komponente Ihrer Container-Bereitstellung. Service-Registries erfassen Instanzen und Services sowie die zugehörigen IP-Adressen. In dieser Hinsicht lassen sie sich mit einem „DNS für Container und Services“ vergleichen.

Die Service Registry verfolgt also die aktuellen Eigenschaften der Container im Cluster. Bei der Service Discovery wird eine Verbindung zur Service Registry hergestellt (über eine API oder durch das Abonnieren einer Nachrichtenwarteschlange), um passende Instanzen den entsprechenden IP-Adressen zuzuordnen.

Das bedeutet, dass eine Infrastruktur, die Datenverkehr an einen bestimmten Dienst oder eine bestimmte Instanz innerhalb eines Container-Clusters weiterleiten muss, in der Lage sein muss, eine IP-Adresse abzurufen. Denn auch wenn Container das Netzwerk vor der Anwendung verbergen, sind sie dennoch darauf angewiesen, um Daten von einem Ort zum anderen zu übertragen.

Die vierte Ebene: Orchestrierung

Dadurch wird eine neue Architekturschicht in die Infrastruktur eingeführt, die mit Umgebungen zur Container-Orchestrierung interagiert. Diese Schicht – die Orchestrierungsschicht – ist in die Container-Umgebung integriert und nutzt Funktionen wie die Serviceerkennung, um Dienste und Instanzen automatisch zu erkennen. So kann ein Load Balancer die Mitglieder eines Pools automatisch ermitteln und den Pool bei Änderungen in der Umgebung fortlaufend aktualisieren. Dies entlastet den IT-Betrieb von der manuellen Aktualisierung der Load-Balancing-Pools – eine zunehmend mühsame Aufgabe, wenn Container im Durchschnitt weniger als eine Woche bestehen.

Diese Ebene ist nicht für die Interaktion mit Administratoren vorgesehen. Konfiguration, Überwachung und Betrieb erfolgen weiterhin über eine Managementebene. Der Speicherort einer Service Registry wird über die Managementebene konfiguriert, aber von der Orchestrierungsebene verwendet, um eine Verbindung zur Steuerungsebene herzustellen und Änderungen an diese zu übermitteln.

Wir können die Orchestrierungsebene wie folgt definieren.

• Die Orchestrierungsebene ist eine der am wenigsten sichtbaren Ebenen der Infrastrukturarchitektur. Die Interaktion mit ihr erfolgt über die Verwaltungsebene, deren Hauptaufgabe darin besteht, die Orchestrierungsebene auf die entsprechende Dienstregistrierung zu verweisen. Die Orchestrierungsebene ist dafür verantwortlich, dynamische Komponenten in der Steuerungsebene zu aktualisieren, um die ordnungsgemäße Weiterleitung und Verfügbarkeit containerisierter Ressourcen sicherzustellen.

Es bleibt weiterhin die Frage, ob diese Ebene zusammen mit der Steuerungs- und Datenebene in das Gerät integriert werden sollte oder ob sie lediglich eine über die Verwaltungsebene gelegte Schicht darstellt, die auf der Verwaltungsebene aufsetzt (wodurch sich unser Diagramm geringfügig ändern würde, die Interaktion zwischen den Ebenen und Komponenten ansonsten jedoch unberührt bliebe). Viele herkömmliche Geräte unterstützen diese neu entstehende Ebene bereits durch Erweiterungen, die sich in Containerumgebungen integrieren und Änderungen über die Verwaltungsebene vornehmen. Dies ist ein gutes Beispiel dafür, wie sich herkömmliche Architekturen durch Refactoring um Funktionen für moderne Umgebungen erweitern lassen. Letztlich ist dies jedoch möglicherweise nicht die ideale Lösung.

Warum ist das wichtig?

Auf den ersten Blick mag die Einführung einer vierten Ebene für die Infrastruktur unbedeutend erscheinen. Schließlich besteht ihre Funktion darin, den Betreibern einen Teil der Verantwortung für mühsame Aufgaben abzunehmen. Das kann doch nicht schlecht sein.

Das ist zwar nicht schlecht, aber es ist wichtig zu verstehen, dass dieser Wechsel von einer statischen zu einer dynamischen Konfiguration Auswirkungen auf einige der wichtigsten Funktionen der Steuerungsebene hat. Die Diensterkennung wird dadurch so kritisch, dass ihre Verfügbarkeit und Sicherheit zwingend gewährleistet sein müssen. Sie wird faktisch zum zentralen Ausfallpunkt, von dem Ihre gesamte Anwendungsinfrastruktur abhängt.

Service-Registrys basieren auf denselben Grundannahmen wie die meisten modernen Anwendungen: Sie sind darauf ausgelegt, Ausfälle zu bewältigen. So kann es vorkommen, dass die gerade ermittelte IP-Adresse nicht mehr verfügbar ist, bevor der Datenverkehr an die zugehörige Instanz weitergeleitet werden kann. Die meisten Infrastrukturen können die Übertragung in diesem Fall wiederholen, doch dieser Vorgang kostet Zeit. In der digitalen Wirtschaft zählen Mikrosekunden. Daher wirken sich herkömmliche Einstellungen wie Zeitüberschreitungen und Erkennungsintervalle auf moderne Architekturen aus, die auf Service Discovery angewiesen sind. Auch das Monitoring gewinnt erheblich an Bedeutung, denn die Fähigkeit, Zustand und Verfügbarkeit so schnell wie möglich zu ermitteln, kann darüber entscheiden, ob ein Benutzer zufrieden ist oder sich abwendet. Beides sind geschäftliche Belange, deren sich alle Beteiligten in einem modernen Unternehmen bewusst sein und die sie in ihre eigenen Kennzahlen und Erwartungen einbeziehen sollten.

Die Implementierung der Orchestrierungsebene in Ihrer Infrastruktur sowie die Wahl des Service-Registers werden zu wichtigen Faktoren bei der Entscheidung darüber, welche Technologie Sie einsetzen. Wägen Sie Ihre Optionen sorgfältig ab, da sie sowohl die Verfügbarkeit als auch die Leistung von Anwendungen beeinflussen, die über containerbasierte Architekturen bereitgestellt werden.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie