Network Functions Virtualization braucht eine neue Art des Netzwerk-Managements

NFV erfordert ein neues Management-Modell, das auf struktureller oder funktionaler Ebene angesiedelt sein muss. Bisher ist noch keine Lösung in Sicht.

Ende 2012 haben sich mehrere wichtige globale Netzwerk-Betreiber zusammengeschlossen und eine Initiative gegründet, die auch unter dem Namen Network Functions Virtualization oder NFV bekannt ist. Das erklärte Ziel ist es, mithilfe von Netzwerk-Virtualisierung bestimmtes Netzwerk-Equipment auf standardmäßige Server, Switche und Storage zu konsolidieren.

Natürlich wollte man damit die Kosten bezüglich der speziell geschaffenen Netzwerk-Ausrüstung verringern. Ein gutes Jahr später hatte sich das Blickfeld dann bereits geweitet und die gleichen Betreiber sind inzwischen der Meinung, dass der Vorteil von NFV ebenso in der Verbesserung der betrieblichen Effizienz liegen könnte, vielleicht sogar auch in der Verbesserung von Service-Agilität oder –Flexibilität.

Das war eine tiefgreifende Änderung in der Stoßrichtung von NFV, weil der Erfolg von NFV nun von der betrieblichen Effizienz abhängt. Das wiederum macht ein verändertes Modell des Netzwerk-Managements nötig, weg von einem Geräte-fokussierten Modell und hin zu einem Orchestrierungs-Modell, das sowohl herkömmliche Netzwerk-Komponenten als auch virtuelle Ressourcen mit einschließt.

Virtuelle Netzwerk-Funktionen lassen sich nicht wie traditionelle Netzwerk-Geräte managen

Die Herausforderung für NFV liegt darin, als neues Betriebsmodell die Effizienz für einen kompletten Service bereitstellen zu müssen. Damit muss das Management-Modell also über das reine Hosten virtueller Funktionen auf Servern als spezielle Geräte hinausgehen.

Worauf die ETSI NFV Industry Specification Group (ISG) offenbar hinauswill ist die Etablierung eines neuen Management-Modells für Netzwerke, das sich in die derzeitigen Netzwerk-Management-Systeme “einklinkt”, in dem neue Management-Schnittstellen für NFV-Prozesse  und –Elemente zur Verfügung gestellt werden.

Das bedeutet, dass eine virtuelle Netzwerk-Funktion oder ein Geflecht aus solchen Funktionen, die das Verhalten einer physischen Appliance (wie zum Beispiel einer Firewall) emulieren, eine virtuelle Form dieses physischen Geräts wäre. Damit würde es sich auch genau so verwalten lassen.

Diese Herangehensweise würde zwar das ausgegebene Ziel von der bestmöglichen Ausnutzung von Virtualisierung erreichen. Allerdings bedeutet das auch, dass sich die allgemeine Bereitstellung und die bisherigen Management-Modelle durch NFV wenig verändern würden. Somit wäre es schwierig, die tiefgreifenden Änderungen bezüglich der betrieblichen Effizienz oder Service-Agilität zu garantieren.

Wie man das Netzwerk-Management-Modell im Hinblick auf NFV ändern sollte

Es gibt zwei Möglichkeiten für ein neues Management-Modell. Einerseits könnte man eine intelligentere Schicht entwickeln, die über NFV liegt. Andererseits bestünde die Möglichkeit, aus dem virtuellen NFV-Gerät etwas komplett anderes zu machen und sich nicht an physischen Geräten zu orientieren.

Die Verbindungen zwischen virtuellen Netzwerk-Funktionen innerhalb eines virtuellen NFV-Geräts könnten bereits etablierte Netzwerk-Komponenten involvieren, beispielsweise diverse virtuelle Funktions-Komponenten wie virtuelle Maschinen oder Container für das Hosting. Im Endeffekt ist jedes virtuelle NFV-Gerät in Wirklichkeit ein System aus kooperierenden Elementen, dessen kollektive Funktionalität durch die Management-Informations-Basis reflektiert werden muss, die das virtuelle Gerät für sämtliche Management-Systeme oder OSS/BSS-Elemente sichtbar macht.

Ist der Umfang eines virtuellen Geräts sehr gering und auf das Emulieren einer einzelnen echten Appliance limitiert, würden sich die Systeme und Praktiken bei der Einführung von NFV nur wenig ändern. Erweitert man das virtuelle Gerät aber und schließt mehr herkömmliche Netzwerk-Komponenten mit ein, könnte man ein NFV-“Gerät“, das einen kompletten Endpunkt-zu-Endpunkt-Service bereitstellt, visualisieren. Es wären sowohl virtuelle als auch herkömmliche Elemente enthalten. In diesem Fall würde das Ausmaß der Agilität und der betrieblichen Effizienz anhand dessen festgelegt, wie man die NFV-Services einführt und innerhalb der Grenzen des virtuellen Geräts verwaltet.

Das Problem bei diesem Ansatz ist, dass wir bereits NMS- und OSS-Systeme für die traditionellen Netzwerke und herkömmlichen Komponenten künftiger Netzwerke haben. Sollte aus NFV ein umfassendes Modell werden, wie behandelt dieses Modell dann Service-Komponenten, die keine NFV-Bestandteile haben?

Ein Netzwerk-Management-Modell für integriertes NFV

Eine alternative Herangehensweise bewahrt diese früheren Praktiken, indem ein neues Betriebs-Modell erschaffen wird, das oberhalb der ETSI-NFV-Prozesse sitzt. Dieses Modell würde Services als eine Ansammlung virtueller Elemente definieren. Einige davon implementiert man möglicherweise durch NFV-Prozesse und einige durch normales und übliches Netzwerk-Provisioning und -Management. Die Effizienz bezüglich Service-Agilität und Betrieb würde durch dieses neue Betriebsmodell sichergestellt und man könnte es auch auf Services anwenden, die überhaupt keine NFV-Bestandteile enthalten.

Dabei sollte klar sein, dass sich hierbei das operative Vorgehen an sich gar nicht so sehr verändern würde, sondern viel mehr die Stelle, wo das neue Management-Modell ansetzt. Was man damit also entweder „innerhalb“ oder „auf NFV aufgesetzt“ beschreibt, ist im Grunde ein zweistufiger Orchestrierungs- und Management-Prozess, der im Gegensatz zu den einstufigen Praktiken der heutigen Zeit steht. Das NFV-Betriebsmodell besteht aus einer funktionalen Schicht, in der logische Service-Komponenten in Endkundenangeboten montiert werden, egal wie diese letztlich implementiert sind. Über eine strukturelle Schicht werden die logischen Komponenten schließlich über beteiligte Netzwerk-, Server- und Software-Ressourcen bereitgestellt.

Dieses Modell passt gut sowohl zu den sich entwickelnden NFV-Spezifikationen als auch zur Cloud-Computing-Idee von „DevOps“-Provisioning, da sich beides in der strukturellen Schicht abspielt. Derzeit sind allerdings keine Management-Modelle in Sicht, die auf die funktionale Schicht abzielen, weil nicht ganz klar ist, wo ein solches Modell herkommen könnte.

Wer ist verantwortlich für die Erschaffung eines Management-Modells nach OSS/BSS?

Liegt etwas zwischen OSS/BSS-Systemen und Netzwerken, könnte man es sowohl als logische Erweiterung für OSS/BSS als auch für das Netzwerk betrachten. Das TMF Forum ist die anerkannte Standardisierungs-Gruppe für OSS/BSS. Somit wäre sie ein naheliegender Kandidat, um das funktionale Management-Modell voranzutreiben. Das Problem dabei ist aber, dass ein funktionales Betriebsmodell sehr nach einer Service-Logik aussieht, und dafür wäre das TMF Forum wiederum nicht zuständig.

Auf der Netzwerkseite gibt es dagegen viele mögliche Kandidaten. Dazu gehören die NFV ISG und Cloud-Organisationen wie OpenStack, die Internet Engineering Task Force (IETF), die International Telecommunications Union (ITU), 3GPP und auch die Open Networking Foundation. Ein Netzwerk-seitiges Betriebsmodell läuft somit möglicherweise auf fünf Variationen hinaus, was wiederum eine höhere Instanz verlangen würde, um alle wieder unter einen Hut zu bringen.

Die wahrscheinlichste Lösung für ein NFV-Betriebsmodell ist aller Voraussicht nach, dass sich das TMF um die OSS/BSS-Schicht kümmert oder eine Gemeinschaft aus NFV ISG und der ONF auf der Netzwerk-Seite das Ruder in die Hand nimmt. Diese beiden Organe haben sich bereits darauf geeinigt, miteinander arbeiten zu wollen. Allerdings liegt der Fokus der Kooperation weit unterhalb der funktionalen Schicht und lässt das Management komplett außen vor.

Über den Autor: Tom Nolle ist Präsident von CIMI, einem strategischen Beratungsunternehmen im Bereich Tele- und Datenkommunikation.

Folgen Sie SearchNetworking.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im Mai 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Netzwerk-Design

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close