Netzwerk der Zukunft: Auf die Absicht kommt es an Moderne Netzwerkplanung mit Intent-Based Networking

Fehler, die beim Aufbau von Netzwerken passieren, beginnen mit der Entscheidung, ein Problem von der unteren Ebene aus anzugehen. Der bessere Ansatz besteht darin, von einer höheren Ebene aus zu starten – und genau hier setzt Intent-Based Networking an.

Eine Netzwerkumgebung gilt es, mit Blick auf die Zukunft zu entwerfen und laufend zu optimieren, damit sie auch zukünftigen Anforderungen gerecht wird. Intent-Based Networking stellt Dienste, Kombinationen von Features und Infrastrukturfähigkeiten in einer hierarchischen Struktur von Intent-, also Absichts- oder Zielmodellen dar. Intent-Modelle bieten eine Möglichkeit, eine Anwendung, ein Funktionsmerkmal, ein Netzwerk oder eine Ressource so zu abstrahieren, dass die Absicht offenliegt, die Implementierung jedoch verborgen bleibt. Das bedeutet, dass sich jede Implementierung, die einer bestimmten Absicht entspricht, durch eine andere Implementierung ersetzen lässt. Hersteller- und Technologieunabhängigkeit, sogar Partnerschaften zwischen Anbietern sind damit erstmals nahtlos in der Netzwerkwelt umsetzbar.

In Levels unterteilte Abstraktionsskala

Ein serviceorientiertes, absichtsbasiertes Netzwerkbetriebssystem modelliert Dienste auf einer gleitenden Abstraktionsskala, die vom höchsten Retail- bis zum untersten Infrastruktur-Level reicht. Jedes einzelne Level ist ein lokales Intent-Modell, das eine implizite Anfrage darstellt. Ein Beispiel wäre: „Diese 100 Endpunkte zu einem VPN verbinden“. Da die Absicht, die das Modell beschreibt, auf verschiedene Weise realisierbar ist und die Integrationen bei den unterschiedlichen Herstellern differieren, gibt es für jedes Modellelement Referenzdesigns. Diese beschreiben eine bestimmte Art der Realisierung der Absicht und die Richtlinien, welche davon zu verwenden sind. Physische und virtuelle Elemente finden in Referenzdesigns Unterstützung und lassen sich nach Bedarf kombinieren.

Die Referenzdesigns enthalten alle Parametrisierungs- und Initialisierungsschritte, die für die Einrichtung der Dienste auf den Zielinfrastrukturelementen erforderlich sind. Für jede alternative Implementierung ist ein vollständiger Satz verfügbar. Die Auswahl eines Referenzdesigns basiert auf Richtlinien und Analysen, sodass die Bereitstellung der Dienste auf der Grundlage der aktuellen Bedingungen erfolgt. Wenn etwas passiert, das einen Wechsel von einer gerätebasierten zu einer gehosteten Implementierung erfordert, stehen beide Ansätze als alternative Implementierungen des übergeordneten Absichtsmodells zur Verfügung. Das Ersetzen des Einen durch den Anderen hat keinerlei Auswirkungen auf den Rest des Dienstes.

Auf jedem Level beschreibt jedes Modellelement auch die Erwartungen. Dies sind die Eigenschaften des Erfolgs oder des SLA (Service Level Agreement). Hinzukommt der Status, also die aktuellen Bedingungen und wie sie von den Management-Probes ermittelt werden. Jedes Level ist ein selbstverwaltetes, sich selbst organisierendes oder autonomes System. Dieses ist für die Erfüllung seines eigenen SLA verantwortlich.

Was passiert, wenn dies nicht der Fall ist? Wenn irgendein Modell-Level die Erwartungen nicht erfüllt, ist dies in einer Anomalie-Policy definiert. Auf jedem Level kann ein Modellelement ein Netzwerkelement oder ein Rechenzentrumselement, eine Cloud-Anwendung oder eine Netzwerkfunktion in beliebiger Mischung darstellen. Es ist auf die Zukunft ausgerichtet, mit dem Rechenzentrum im Blick, und auch auf die gegenwärtigen Netzwerkdienste anwendbar.

Analytik und Wissen sind nur die halbe Miete

Analytik und das Wissen rund um das Netzwerk können den Betrieb effizienter und die Kunden zufriedener machen. Das ist wahr, aber nur zur Hälfte. Wissen ist nur dann Macht, wenn das Wissen aktuell ist und im Kontext interpretiert wird, um die Beziehung zwischen Bedingungen und Erwartungen zu verstehen. Angenommen, eine Leitung ist überlastet oder ein Host im Rechenzentrum ist ausgefallen. Ist das vor fünf Minuten passiert, als die letzte Abfrage erfolgte, oder stimmt das auch genau jetzt? Hat sich das Problem auf die Erwartungen von hundert spezifischen Diensten ausgewirkt, oder war die Ressource völlig unbeteiligt? Letzteres, der Kontext, verbindet die Bedingungen, unter denen die Analytiker die Anforderungen mit den Bedingungen und Abhängigkeiten vergleichen können. Mit diesem Satz von Dingen müssen automatisierte Antworten beginnen.

Ein absichtsbasiertes Netzwerkbetriebssystem verwendet eine besondere Kombination von Probes/Sondierungen und In-Memory-Datenbanken, um den Zustand der Ressourcen zu erfassen. Es sammelt diese Daten effizient und kontinuierlich, sodass sie immer auf dem neuesten Stand sind. Der Zustand der Ressourcen wird dann durch absichtsorientierte Modellelemente jedes Dienstes in den Dienstkontext reflektiert. Die Sätze von Ressourcenbedingungen sind mit den Erwartungen der Modellelemente verknüpft, die auf diese Ressourcen verweisen.

Autonom und leistungsfähig durch Local-Intent-Konzept

Was dieses System autonom und leistungsfähig macht, ist das Local-Intent-Konzept. Jedes Absichtsmodell, jedes Level einer Dienststruktur ist eine unabhängige Einheit. Sie weist einen eigenen Kontext und Zustand, eigene Erwartungen, Abhilfemaßnahmen und Ausfallstrategien auf. Die Richtlinien bestimmen, worauf sich das Modellelement zur Behebung eines Problems berufen kann und wann es eine Anomalie melden muss. Wenn dies geschieht, erfüllt es nicht die Erwartungen/SLAs des nächsthöheren Elements auf unserer gleitenden Abstraktionsskala. Dieses Element definiert dann die Abhilfe für diesen Fehler. Jedes der Elemente im Absichtsmodell ist eine Art Microservice. Es ist sozusagen eine Black Box, die unter Verwendung ihrer eigenen internen und privaten Mechanismen das tut, was sie verspricht. Sie meldet dem Element des höheren Levels, dem sie das Versprechen gegeben hat, einen Fehler. Dieser einzigartige Ansatz bewirkt eine begrenzte Komplexität des Gesamtmanagements von Services.

Anstelle eines monolithischen Managementprozesses, der jeden Trunk, jedes Gerät und jeden Host überwacht, gibt es eine Reihe verschachtelter Intent-modellierter Domains. Diese erreichen ihre eigenen Leistungsziele. Die Verwaltung der übergeordneten Ziele erfolgt anhand von Absichtsmodellen. Diesen ist es egal, wie die untergeordneten Elemente mit den SLAs übereinstimmen, die sie ihrerseits erhalten haben. Dadurch lassen sich Services in großem Maßstab verwalten. Das Ergebnis dieses Ansatzes ist ein Weg zum Erreichen eines wirklich autonomen oder selbstorganisierenden Netzwerkverhaltens. Es ist zwar auch möglich, menschliche Prozesse einzufügen, wo dies gerechtfertigt scheint. Das absichtsbasierte Netzwerkbetriebssystem ist aber so konzipiert, dass es vollautomatische Betriebsprozesse auf allen Levels schafft. Dies unterstützt die vollständige Automatisierung des Servicelebenszyklus (Life Cycle Management). Damit steht ein direkter Weg bereit, um sowohl die Betriebseffizienz als auch die Serviceagilität zu erreichen, die Netzwerkbetreiber mittel- und langfristig anstreben.

Intent-Based Networking als zukunftssicherer Ansatz

Die Zukunft der Dienste liegt in dem, was im Rechenzentrum gehostet wird. In einer von gehosteten Funktionen und Cloud-Erfahrungen dominierten Zeit ist das Rechenzentrum der Ort, an dem eine zunehmende Komplexität droht. Die Cloud hingegen gilt als „einfach“ und „bequem“. Intent-Modellierung im Rechenzentrum löst das Problem des komplexen Managements im Rechenzentrum, was Intent-Based Networking zum zukunftssicheren Ansatz macht.

Netzwerkbetreiber profitieren dabei von zwei Vorteilen. Erstens haben sie Standorte am Edge, wo sich Rechenzentren einrichten lassen, da bereits Konnektivität verfügbar ist. Zweitens weisen sie eine typischerweise niedrige interne Rendite auf. Daher können sie es sich leisten, Dienste mit einer geringeren Kapitalrendite bereitzustellen, insbesondere in der frühen Phase der Einführung, in der zunächst die Kosten die Einnahmen übersteigen.

Eine Netzwerkinfrastruktur ist eine gewaltige Investition und kann zu einer massiven Kostenfalle werden. Eine Transformation, die von der Verlagerung der Infrastruktur auf eine andere Technologie – wie SDN (Software-Defined Network) oder NFV (Network Functions Virtualization) – abhängt, kann die Dinge nur in einem bestimmten Tempo verändern. Dieses ist vorgegeben durch die Kosten für die Verlagerung der bestehenden Infrastruktur.

Ein CFO eines Netzwerkbetreibers, der in einem Blog der CIMI Corporation zitiert wird, stellte fest: „Ausgangspunkt ist die Annahme, dass sich nur ein Fünftel der Infrastruktur jederzeit verschieben lässt und nur etwa 10 Prozent davon einer Modernisierung durch NFV unterliegen. Dann sind nur zwei Prozent der Infrastruktur in einem Jahr veränderbar. Bei einer zweiprozentigen Veränderung würde es 25 Jahre dauern, um revolutionäre Ausmaße zu erreichen, was kaum als Revolution oder Transformation bezeichnet werden kann.“

Intent-Based Networking ist jedoch eine revolutionäre, transformative Technologie, um die Transformation schneller herbeizuführen.

Über den Autor

Manfred Felsberg ist Regional Sales Manager bei Apstra DACH.

(ID:47041853)