Software Defined Networks: Status Quo und Quo Vadis

Für die Umstellung auf SDN gibt es vielfältige Gründe:

• Vorhandene Systeme bieten nicht ausreichend Performance für neue Anwendungen
• Vorhandene Systeme laufen aus dem Hersteller-Support (end-of-service)
• Erhöhung der operationellen Effizienz (OPEX)
• Bessere Skalierung, um verschiedene, schnell wachsende Workloads einfacher zu bedienen
• Erhöhung der Sicherheit im Rechenzentrum (z. B. Micro-Segmentation)
• Steigerung der Flexibilität, um virtualisierte, ortsunabhängige Applikationen zu unterstützen
• Automatisierung und Programmierbarkeit um Cloud-Modelle zu adaptieren
• Vereinfachung der VLAN-basierten Modelle für Zugriffsmechanismen

Die Umstellung auf SDN setzt allerdings auch ein Umdenken der Netzwerkadministratoren voraus – mein Kollege Heinz-Jörg Robert berichtete bereits in seinem Beitrag „Lassen Sie los! Mehr Dynamik mit Software Defined Networking“ darüber. Sie müssen von Ihrer Vorgehensweise im Betrieb loslassen und neue Wege beschreiten. Dazu gehört auch, sich mit Applikationen auseinander zu setzen, und die Verwaltung des Netzwerks einer zentralen Instanz zu überlassen. Diese Punkte behindern oftmals die Einführung von SDN Technologien.

Viele der oben genannten Aspekte können jedoch die Entscheidung beschleunigen, sich von den alten, erfolgreichen Architekturen zu verabschieden und auf neue Mechanismen zu setzen. Die Hersteller haben das erkannt und sind seit etwa vier Jahren mit Produkten auf dem Markt, die nun ihre Kinderkrankheiten überwunden haben. Sie sind in der Lage, mit Stabilität und Performance die Kundenwünsche zu verwirklichen.

Unterschiedliche Herangehensweise der Hersteller

Unterschiede gibt es in der Herangehensweise der Hersteller. Die Einen setzen auf komplett herstellergebundene Strukturen, die einen sehr guten Support ermöglichen. Andere wiederum setzen auf offene Architekturen, die der Community erlauben, viele Besonderheiten zu entwickeln und zu implementieren. Dritte versuchen den goldenen Mittelweg zu finden, der ihnen erlaubt, sowohl dem Kunden möglichst viel Freiheit einzuräumen und andererseits trotzdem ausreichend viel Unterstützung zu liefern. Allen gemein ist der Einsatz von VXLAN als Basis-Technologie, um das Underlay (herkömmliches Switching und Routing) zu verstecken und dem Betreiber es möglichst einfach zu machen, die Landschaft zu verwalten.

Der Support gibt den Ausschlag

Bei herstellergebundenen Implementierungen ist der Kunde auf den entsprechenden Support angewiesen. Die zuständigen SDN-Administratoren verstehen oft die unterliegende Basis nicht mehr und müssen sich auf die fehlerfreie Funktion verlassen. Im Notfall greifen sie auf den Support zurück.
Diese proprietären Lösungen sind herstellerseitig entsprechend gut aufgestellt und können in den
meisten Fällen auch von den spezialisierten Systemhäusern supported werden. Ganz anders jedoch
sieht es bei den Systemen aus, die ausschließlich oder überwiegend auf offene Standards setzen. Hier ist es fast immer notwendig, sehr gute eigene Skills aufzubauen. Unterstützung erhalten Admins dann eher aus frei zugänglichen Communities wie zum Beispiel „Open Networking“. Der Support ist dabei allerdings eher zweitrangig.

Status Quo: SDN Marktdurchdringung noch schwach

Die SDN Marktdurchdringung ist heute in Deutschland noch eher schwach.

Woran liegt das? Meiner Meinung nach begründet es sich an dem konservativen Ansatz vieler Unternehmen. Infrastrukturen sind in jeder Firma ein sensibles Herzstück und haben in der Regel die längste Lebenszeit aller IT-Infrastruktur-Komponenten. Ich beobachte, dass Netzwerk-Architekturen, die zehn Jahre unverändert bleiben, eher die Regel als die Ausnahme sind. Vielerorts erleben Infrastrukturen nur durch Abkündigung des Supports der Hersteller eine Anpassung an moderne Technologien. Hierbei gibt dann auch eher der Preis als die moderne Funktionalität den Ausschlag.

Auf der anderen Seite sind SDN Implementierungen stark von der Integration in virtuelle Infrastrukturen (meistens vSphere) geprägt, denn sie ermöglichen auch der Mannschaft der Serveradmins, Netzwerkfunktionalität zu nutzen. Das macht durchaus Sinn. Operational können dadurch bereits deutliche Vorteile, besonders durch die agile (schnelle) Bereitstellung, eintreten. Die meisten SDN Infrastrukturen führten zu neuen Geschwindigkeitsklassen im Rechenzentrum: 10G Ethernet sind die Regel, oftmals sogar 40G bis zu Servern oder Storagesystemen. Inzwischen werden 100G Verteilerstrecken zum Verbinden von einzelnen Racks eingesetzt. Erste Systeme mit 400G im Backbone werden ab Herbst 2018 angeboten.

Auch die hardware-unabhängige Implementierung von VMware NSX in virtualisierten Data Centern nimmt stetig zu. Damit erhalten die Admins von vSphere-Umgebungen vollumfänglichen Zugriff auf notwendige Netzwerk-Ressourcen in ihren gekühlten Räumen. Die Hardware spielt in diesem Fall managementseitig nur noch eine untergeordnete Rolle. Einzig die Gesamtbetrachtung von Kosten ist in diesem Fall deutlich schwieriger, weil oft mehrere Abteilungen einbezogen sind.

SDN mit wirklich offenen Standards hingegen sind bisher in Unternehmen kaum implementiert worden, weil der verfügbare Support nicht die Kundenbedarf trifft.
Die eigene Erbringung dieser Leistungen ist nur in großen Unternehmen möglich, die über Ressourcen in der Programmierung verfügen und das sogenannte DevOps-Modell eingeführt haben. Es beinhaltet sowohl die Softwareentwicklung als auch die Systemadministration als einheitliches Modell mit dem Ziel, die Qualität und Agilität des Betriebs zu erhöhen.

Auch Unternehmen, die neue Strukturen möglichst flexibel gestalten möchten, den Zugriff auf externe Public Cloud Provider wünschen und alles unter einem Dach konsolidieren wollen, stoßen hier an die Grenzen im Support.

Carrier sind die Ausnahme

Im Gegensatz hierzu steht das Umfeld der Carrier und Service Provider. Sie haben gänzlich andere Bedürfnisse und sind in Themen wie Standardisierung und Automatisierung viele Schritte voraus. Schon seit Jahren entwickeln sie eigene Lösungen, meist in engem Schulterschluss mit „ihrem“ Hersteller. Auch der Einsatz von Network Funktion Virtualization (NFV) ist bei ihnen schon lange adaptiert. Sie ermöglichen die Optimierung von Netzwerkservices, wie Load Balancing, Firewalls und IPS in Verbindung mit Applikationen und stellen ein variables Betriebsmodell dar.

Quo Vadis Software Defined Networking

Immer mehr Applikationen erzwingen heute die Entscheidung über einzusetzende Architekturen und damit ein Umdenken der zentralen IT-Bereiche. Für die IT-Abteilung sind diese neuen Applikationen vielmals unbekannt in ihrer internen Arbeitsweise und lassen sich deshalb nur teilweise in die vorhandenen Netzwerkarchitekturen einbinden. Hier müssen sich zukünftig die Verantwortlichen (Fachabteilungen und IT-Abteilung) vor der Einführung neuer Tools abstimmen. Zentrale Fragen werden sein: Welche Ergebnisse werden erwartet? Welcher Weg muss hierfür beschritten werden?

Der Wandel hat bereits zögerlich eingesetzt. Man erkennt ihn im Rechenzentrum an der Umsetzung von konvergenten oder auch hyper-konvergenten Lösungen, die Server, Speicher und teilweise Netzwerk beinhalten. Das SDN ist der nächste Schritt in der technologischen Entwicklung und vereinfacht den Betrieb und die Integration von neuen Applikationen erheblich. Manche Firmen beginnen den Weg zum SDN, indem sie bestehende VLAN-Strukturen abbilden (network-oriented) und sukzessive Funktionen in Richtung Mikrosegmentierung und Mandantenfähigkeit als erste Schritte implementieren. Dieses Vorgehen führt zu ersten „belastbaren“ Erfolgen und lässt sich leicht adaptieren. Ich gehe davon aus, dass sich in naher Zukunft mehr Unternehmen für diesen Einstieg in SDN entscheiden werden, weil es keinen radikalen Umbruch darstellt und sich die Vorteile schnell einstellen.

Die Integration von weiteren Services muss dann Fall für Fall abgewogen werden. Garantiert ist, dass sie das Netz in der Handhabung einfacher machen. Natürlich stehen wir unseren Kunden mit Rat und Tat zur Seite und nehmen Interessierte mit auf den Zug in Richtung „software-defined“.