Software-Abstraktion für Service-Provider

Verständlich erklärt: SDN Resource Adapter

| Autor / Redakteur: Eugen Gebhard / Andreas Donner

Konfigurationsmanagement und Provisionierung von Drittanbieterprodukten erfordern auch in SDN-Umgebungen viel Know-how.
Konfigurationsmanagement und Provisionierung von Drittanbieterprodukten erfordern auch in SDN-Umgebungen viel Know-how. (Bild: cronislaw - Fotolia.com)

In den letzten Monaten bewegte vor allem das Thema Network Functions Virtualization (NFV) die Netzwerkbranche. Aktuell rücken nun jedoch Konfigurationsmanagement und Provisionierung von Drittanbieterprodukten in den Vordergrund. Die Herausforderung für Service Provider: die Verknüpfung von Netzwerkdiensten und virtuellen Services über eine gemeinsame Software-Schnittstelle.

Das übliche Vorgehen bei der Produktintegration besteht in der Regel darin, das Handbuch einer Programmiersprache zu lesen und den Anweisungen für die Befehlszeile (CLI) zu folgen. Die Funktionsweise und Befehle einer solchen Sprache zu verstehen, ist keine Schwierigkeit. Probleme tauchen dagegen häufig deshalb auf, weil der Programmierbarkeit enge Grenzen gesetzt sind und sich die Konsolensteuerung als komplex erweist.

Bisher nutzen Netzbetreiber automatisierte Tools für Betriebsunterstützungssysteme (OSS) und Sammlungen von speziellen, selbst geschriebenen CLI-Skripten, um Geräte von Drittanbietern zu konfigurieren. Schon die ersten Skripte sind nicht unbedingt trivial. Nach einiger Zeit kommen weitere Dienste, Funktionen und Software-Updates hinzu. Das hat zur Folge, dass nicht-deterministische Skripte auf tieferen Hierarchieebenen Aktualisierungen benötigen. Dadurch müssen bei Änderungen faktisch alle Skripte überprüft werden, was die Sache zusätzlich kompliziert und zeitaufwendig macht.

Über die Konsole hinaus

Manuelles Anpassen hat sich für Software Defined Networking (SDN) als ungeeignet herausgestellt. Deshalb verwenden einige SDN-Anbieter programmierbare Adapter. Die darin integrierte Software trägt macht sie robuster und funktionaler. Außerdem können die Adapter so direkt mit anderen Geräten kommunizieren und in Echtzeit Befehle ausführen. Die Programmierbarkeit hat aber auch eine Kehrseite. Veränderung am System oder an Funktionen lassen sich nur durch Anpassen des Programmcodes realisieren. Für Service Provider bedeutet das: Änderungen lassen sich nur so schnell einführen, wie auch der SDN-Anbieter in der Lage ist, den Programmcode zu aktualisieren.

Zu einem weiteren Ansatz zählt die modellgetriebene Softwareentwicklung für Netzwerkadapter- und Controller. Dabei lassen sich Änderung während der Laufzeit einfügen. Obwohl dieser Ansatz als flexibel gilt, sind ihm auch Grenzen gesetzt, zum Beispiel bei der Anzahl an unterstützten Funktionen. Außerdem können Befehle auf Basis zustandsorientierter Informationen nicht immer in Echtzeit ausgeführt werden. Ausnahmen lassen sich mit diesem Ansatz eher schlecht verarbeiten.

Die Vorteile einer Resource-Adapter-Architektur

Dynamische Netzwerkumgebungen mit Komponenten mehrerer Anbieter (Multi-Vendor) zu managen, ist anspruchsvoll. Eine Template-getriebene SDN und Resource Adapter Architektur (RA), wie sie zum Beispiel Cienas Blue Planet bietet, kann dabei helfen. Der Resource Adapter enthält eine formale Abstraktionsmethode, die beschreibt, was zu verwalten ist. Außerdem verfügt er über eine einheitliche Schnittstelle (Uniform Interface) oder API. Sie kennzeichnen, wie sich Methoden verwenden lassen.

Die Inhalte aus der Befehlszeile befinden sich im Resource Adapter und führen von dort Funktionen des RAs aus. Um den Anforderungen in Multi-Vendor-Umgebungen zu genügen, kann ein SDN Controller mehrere RAs ausführen. Diese wiederum unterstützen mehrere Anbieter und verschiedene Komponenten. Daraus folgt auch, dass sie mehrere Protokolle unterstützen müssen. Die Hardwareerkennung sollte dabei automatisch ablaufen. Das funktioniert jedoch nur, wenn der jeweils passende Resource Adapter auch mit den darunter liegenden Komponenten kommunizieren kann.

Bei der RA-Steuerung ist es hilfreich, mit Anbietern alter Legacy-Systeme zusammenzuarbeiten, um Programmcode für Drittanbieter-Komponenten erstellen zu können. Viel wichtiger ist es jedoch, die Ziele des Service Provider genau zu kennen, damit eine entsprechende Implementierung realisierbar ist.

Welche Leistungsfähigkeit bei Diensten zur Verfügung steht, zeigen beispielsweise Layer 2 Carrier Ethernet und Layer 3 VPN Services. Anbieter verfügen dabei über sehr hohe Servicedefinitionen, was die Nutzung der Dienste transparent macht. In der Regel sind die Definitionen einfach zu überschauen. Sie beziehen sich zum Beispiel auf die Verbindung und Bandbreite zwischen Endpunkten. Allerdings unterscheiden sich beide Dienste auch. Layer-2-Dienste warten mit Optionen für Leistung und Servicequalität (QoS) sowie Konzepten zum Protection Switching auf. Layer 3 Services dagegen enthalten Funktionen für den Internetzugang, für das Routing und für Discovery-Netzwerkprotokolle.

Software-Abstraktion ermöglicht Multi-Vendor-Support

Keine der Service Provider bieten genau denselben Dienst an oder stellen solche auf die gleiche Art bereit. Deshalb muss die Anpassung beim SDN Controller stattfinden. Dienste und Netzwerkkomponenten ändern sich jedoch ständig. Daher muss der Service Provider in der Lage sein, zügig neue Anforderungen zu integrieren. Er kann es sich nicht leisten, solange zu warten, bis eine neue Software-Version für einen SDN Controller oder von einem Netzwerkausrüster erhältlich ist.

Eugen Gebhard
Eugen Gebhard (Bild: Ciena)

SDN Controller gibt es viele am Markt und sie weisen Kompatibilität zu mehreren Anbietern auf. Trotzdem ist Multi-Vendor-Support keine simple Angelegenheit. Abhilfe können Service-Abstraktionsschichten schaffen. Sie unterstützen Netzwerkbetreiber und Provider dabei, neue Dienste einfach zur Verfügung zu stellen und zu verwalten. Außerdem erlauben sie, benötigte Anpassungen vorzunehmen.

Über den Autor

Eugen Gebhard ist Regional Director Northern & Central Europe Carrier Accounts bei Ciena.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 43887586 / Produkte & Lösungen)