Intent-based Networking
Zielführend vernetzt
RZ-Betreiber benötigen nicht nur die Werkzeuge, die ihnen beim Design und der kontinuierlichen Neukonfiguration des Rechenzentrums helfen, sondern auch die Tools zur Überwachung des Betriebs und zur Erkennung eklatanter wie auch subtiler Fehler. Automatisierungssysteme müssen reaktionsfähig, skalierbar, fehlertolerant und sicher sein und Überlastungen problemlos bewältigen. Dazu reicht es nicht aus, eine Sammlung punktueller Open-Source-Lösungen zusammenzustellen und zu versuchen, sie zum Zusammenspiel zu bringen. Abhilfe versprechen Systeme für das Intent-based Networking (absichtsbasierte Vernetzung).
Die Rechenkapazität eines RZs ist heute nicht mehr wirklich ein limitierender Faktor bei der Bereitstellung von Diensten und Anwendungen. Die Provisionierung der Rechenleistung wird durch eine komplexe Verflechtung von Commodity-Servern und zunehmend austauschbaren Switches erreicht. Die Vielfalt der auf den Switches und Diensten verfügbaren Protokolle und Funktionen macht die RZ-Konfiguration jedoch zu einem zeitaufwendigen Unterfangen. Zudem ist die Konfiguration keine einmalige Aufgabe. Die Notwendigkeit, kontinuierlich neue Server, Switches und Services wie VXLAN-Tunnel inkrementell zu installieren und andere zu entfernen, lässt in jeder Phase bedenkliche Möglichkeiten für Fehler und Ausfälle entstehen.
Eine entscheidende Herausforderung besteht daher in der Bereitstellung einer effizienten, hochverfügbaren Kommunikation, Aufzeichnung und Verarbeitung wichtiger Ereignisse von den untersten Komponentenebenen im RZ über die Echtzeitanalyse und Alarmierung bis hin zu einem zentralen Repository für die detaillierte Nachbearbeitung großer Datenmengen. Dies muss so erfolgen, dass eine geringe Latenz zwischen dem Auftreten kritischer Situationen und der Kommunikation von Operator-Alarmen, wenn nicht sogar eine automatische Korrektur gewährleistet ist.
Die Lösung liegt heute vor allem in der Nutzung eines Systems für Intent-based Networking (IBNS). Ein IBNS überführt das Netzwerk – unabhängig vom Anbieter oder Betriebssystem der Netzwerkgeräte – von einer fragmentierten Knoten-für-Knoten-Verwaltung hin zu einem autonomen Netzwerk. Das System abstrahiert das Netzwerk und arbeitet idealerweise selbstständig: Es justiert und korrigiert sich selbst innerhalb der Parameter der formulierten technischen Ziele.
Diese Ziele bilden die Absicht („Intent“) – eine Deklaration der erwarteten Ergebnisse. Konventionell legen Netzwerk-Ingenieure die Ziele fest. Diese münden schließlich in gerätespezifische Konfigurationen sowie deren manuelle Validierung und in operative Parameter für die Einhaltung von Compliance-Zielen. Ein IBNS nimmt diese Absicht als Input, übersetzt sie zunächst in praktikable Richtlinien für das Netzwerk und führt anschließend gerätespezifische Konfigurationen durch. Es validiert die Ergebnisse und überwacht das Netzwerk aktiv auf die Einhaltung der Absichten. Und es passt die Netzwerkparameter nach Bedarf an, um die Einhaltung der Compliance-Policies, der Konfiguration auf den Switches und der physischen Infrastruktur während des gesamten Lebenszyklus des Netzes zu gewährleisten.
„Intent als deklarative Aussage“ klingt sehr akademisch. Einfacher ausgedrückt besteht der Weg darin, dem IBNS zu erklären, was man vom Netzwerk erwartet, und das System entscheidet, was im Detail zu tun ist. Dies eliminiert die menschliche Schnittstelle, die bei einem manuellen Management die definierte Absicht interpretiert, in ausführbare Konfigurationen übersetzt und dabei schlechtestenfalls Fehler einfügt.
Demgegenüber nutzt ein IBNS die definierten Betriebsanforderungen sowie ein Referenzdesign aus Services und Ressourcen. Es validiert die Anforderungen und erstellt automatisch Konfigurationen, die für einzelne Knoten spezifisch sind. Und schließlich überträgt es in einem weiteren Schritt die Informationen auf die physische Infrastruktur. Um diese Aufgabe zu erfüllen, benötigt das IBNS selbst eine Reihe von Informationen zur Topologie des physischen Netzwerks, zu den Herstellern und Betriebssystemversionen jedes einzelnen Knoten sowie zu den verfügbaren Ressourcen und deren Status. Dieser bidirektionale Informationsfluss dehnt die Funktion des IBNS über die bloße Installation des Netzwerks hinaus auf die Unterstützung während seines gesamten Lebenszyklus aus.
Die Reife eines IBN-Systems lässt sich mittels einer vierstufigen Skala an Aufgaben beurteilen: Basisautomation, Single Source of Truth, Fähigkeit zur Validierung von Änderungen in Echtzeit sowie autonomer Betrieb (Self-Operation). Auf der ersten Stufe kann eine Basis-IBN-Lösung Konfigurationen auf der Grundlage deklarativer Aussagen generieren und an Netzwerkknoten weitergeben. Auch wenn ein aufwärtsgerichteter Informationsfluss stattfindet, so ist dieser im Allgemeinen auf einen einzelnen Hersteller limitiert. Die Information ist eher nachrichten- als datenzentriert, und es mangelt an einer zentralen Informationsinstanz (Single Source of Truth).
Single Source of Truth
Diese Instanz speichert sowohl den deklarierten Intent als auch rekursiv den aktuellen Netzwerkzustand. Sie erlaubt es, jederzeit eine Datenbank – anstelle des Netzwerks – nach einem der beiden Zustände abzufragen. Dies ermöglicht auch die Analyse potenzieller Auswirkungen von Änderungen an einem Gerät für das gesamte Netz. Dazu nutzt man gerne eine grafische Datenbank, da damit die Anforderungen nach Skalierbarkeit, echte Analysefunktionen und Echtzeit-Validierung einfacher möglich sind.
Die Validierung von Änderungen in Echtzeit gleicht kontinuierlich den Netzwerkstatus mit dem Intent ab. Netzwerke unterliegen ständig geplanten wie auch ungeplanten Änderungen. Die Echtzeit-Telemetrie innerhalb eines geschlossenem Regelkreises verifiziert fortlaufend den Netzzustand bis auf die Sekunde. Im schlechtesten Falle muss das Netzwerk Alarm schlagen, wenn die Compliance beeinträchtigt ist. Bestenfalls sollte sich das Netzwerk ohne manuelle Eingriffe selbst justieren. Hier setzt die höchste Stufe eines IBNS ein, der autonome Betrieb.
Netzautonomie
Erst wenn eine IBN-Lösung alle vorhergehenden Ebenen solide unterstützt, bewegt sie sich auf die Stufe der Netzautonomie. Sie ermöglicht es dem Netz, zu lernen und sich an Netzschwankungen anzupassen. Während die vorhergehenden Ebenen die Erfüllung von Absichten ermöglichen, erreicht die letzte Stufe die Zusicherung, dass Absichten umgesetzt werden („Intent Assurance“).
Ein echtes IBN-System besitzt zwei grundlegende Eigenschaften, die es zu mehr als nur einer smarten Konfigurations-Management-Plattform machen: Intent Fulfilment und Intent Assurance. Unter Intent Assurance versteht man die Fähigkeit, den Zustand eines Systems mittels Validierung im geschlossenen Regelkreis bei einer unvermeidlichen Änderung zu beurteilen.
Auf dieser Ebene befreit das selbsttätig arbeitende Netzwerk die operativen Mitarbeiter von einfachen, jedoch fehleranfälligen Aufgaben und versetzt sie in die Lage, das Netzwerk ganzheitlich zu überwachen. Vorgänge, die zuvor Stunden oder Tage dauerten, erfordern jetzt nur Sekunden, sodass ein anpassungsfähiges, agiles Netzwerk entsteht.
Eine Reihe von Herstellern bietet heute eine Vielzahl von Lösungen. Weltweit erreichte der Markt 2017 ein Volumen von 634 Millionen Dollar, bis 2023 soll er den Angaben von MRFR zufolge ein Volumen von knapp fünf Milliarden Dollar erreichen. Die Gründe für dieses enorme Wachstum liegen auf der Hand. Allerdings führen unstrukturierte und fragmentierte Tools mit inkonsistenter API-Architektur, unterschiedlichen Protokollen und Mechanismen zu Insellösungen, die oft reaktiv und langsam sind. Sie haben Schwierigkeiten, die Ursache von Problemen zu erkennen und zeitgerecht zu reagieren, weil sie auf veraltete Daten zurückgreifen, unzureichende Korrelationen oder keine vollständige Data Plane bieten.
Ein modernes IBNS ist weder ein Tool zur Netzwerk-Automation, noch zum Konfigurations-Management. Ebenso wenig ist es lediglich eine Form von SDN (Software-Defined Network), eine Orchestrierungssoftware oder Policy-Engine. Mit leistungsfähigen IBN-Lösungen können RZ-Teams vielmehr eine ganzheitliche, geschlossene Validierungsarchitektur implementieren, die das RZ-Verhalten in Echtzeit anhand definierter Richtlinien analysiert und eine effiziente und zuverlässige Methode zur Veränderung des Netzwerks bietet.
Grenzen des IBNs
Im Grunde lassen sich mit IBN-Systemen alle denkbaren Use Cases realisieren. Im ersten Schritt liegt der Fokus der meisten Hersteller auf dem RZ-Netzwerk, da hier sehr viel Agilität und Anpassung nötig ist. Zudem wird diese Technik andere Anforderungen, etwa die Integration der Zutrittskontrolle ins Netzwerk, Load-Balancer, Campus-Netze, WLAN etc. erfüllen müssen, um ein komplett abstrahiertes Model anbieten zu können.
Es ist derzeit nicht die Frage, ob, sondern bis wann das komplett umgesetzt sein wird. Unternehmen müssen bei der Auswahl ihre Anforderungen deutlich besser kennen, um eine private Cloud aufzubauen.
Vorteile der Abstraktion
Die gewonnen Vorteile der Abstraktion und der Herstellerunabhängigkeit lassen sich nur nutzen, wenn eine vollständige Architektur auf modernen Standards zum Einsatz kommt und keine proprietären Funktionen Verwendung finden.
Auch wenn IBN-Systeme die Unterstützung des kompletten Lifecycles eines RZ-Netzwerks versprechen, so gibt es doch einige Voraussetzungen für den effizienten Einsatz. Smarte Netzwerke entstehen dadurch, dass die Absicht an erster Stelle steht. Wer mit der Auswahl eines bestimmten Hardwareherstellers beginnt und dann das Netzwerk um die Funktionalität diese Herstellers herum entwickelt, wird am Ende nicht die erstrebte Flexibilität erzielen. Die Aufhebung des Vendor-Lock-ins ist vielmehr eines der wesentlichen Ziele und ermöglicht es den Unternehmen, auch neue Technologien wie Open Networking in Betracht zu ziehen.
Umdenken bei den IT-Mitarbeitern
Auch wenn DevOps aus gutem Grunde zu einem gewaltigen Trend geworden ist, so ist es in vieler Hinsicht nicht immer förderlich, auf selbsterstellte Tools zu setzen. Diese Werkzeuge mögen gut konstruiert und angepasst an die Spezifika des Netzwerks sein, aber sie sind es dann nicht mehr, wenn sich das Netzwerk verändert. Es gilt zu berücksichtigen, welchen Aufwand es erfordert, diese Tools an die Veränderungen anzupassen. Ähnliches gilt für Werkzeuge zur Automation.
Und schließlich erfordert der IBNS-Einsatz ein Umdenken bei den IT-Mitarbeitern. Sie sind es gewohnt, einen wesentlichen Teil ihrer Zeit für taktische Operationen – sprich für die Brandbekämpfung – zu verwenden, anstatt ihr Fachwissen für die strategische Planung einzusetzen. Das erfordert gegebenenfalls neue Skills, zumindest aber die Bereitschaft, die eigenen Aufgaben neu zu denken.
Manfred Felsberg ist Sales Director DACH bei Apstra, apstra.com.
Lesen Sie mehr zum Thema
