Application-Aware, Controlled, Centric, Software-Defined … Networking

Kommentieren Drucken

Offene SDN-Diskussion: aus einem US-Blog von Markus Nispel auf SDNcentral, hier ins Deutsche übersetzt

Es ist sehr interessant zu sehen, wie Ciscos „Insieme”-Announcement letzten Herbst die Diskussion über die verschiedenen Aspekte der Application-Awareness im Netz und des Software-Defined Networking erneut angestoßen hat.

Es geht um die Applikation, oder? Das war so und wird auch immer so bleiben. Um die beste „User-Experience” zu liefern, muss das Netzwerk auf die Applikationen zugeschnitten sein. Hört sich einfach an, doch wie erreicht man das? Ein valider Punkt des Cisco Application-Centric Infrastructure (ACI)-Announcements ist ganz klar, dass nicht alles virtuell werden wird. Man muss eine gemischte Infrastruktur, teils virtuell, teils physikalisch, unterstützen. Dies führt dazu, dass spezielle Anforderungen an die Architektur (wie spezielle Funktionen) in das physikalische Netzwerk gebracht oder dort behalten werden müssen, da nur hier Dienste für alle Applikationen, Nutzer und Geräte in einer flächendeckenden, hochperformanten und agilen Art und Weise erbracht werden können.
Aber dazu muss das Netzwerk wissen, welche Applikationen es gibt und was diese benötigen.

Der Knackpunkt ist aber, dass Applikationen nicht genug über das Netzwerk wissen (sollten sie auch nicht), wie mir in Diskussionen über die Abstraktionsebene für die richtige NBI (Northbound Interface – API) im Rahmen der SDN-Architektur aufgefallen ist. Aber ein gewisses Maß an Netzwerk-Awareness für Applikationen ist nötig, um einen zuverlässigen Service zu liefern.

Die richtige Abgrenzung – und damit die Struktur der API – ist der Schlüssel zum Erfolg. Die Netzwerkdienste werden für die Applikationen bereitgestellt, ohne dass diese zu viel Details wissen müssen. Wenn man dies richtig umsetzt, erhält man Agilität, Automatisierung und Orchestrierung sowie einen besseren Applikationservice. All dies sind die wichtigsten Vorteile einer SDN Architektur.

Aber reicht das aus? Wahrscheinlich nicht. Auch im ACI-Announcement liest man über verschiedene Varianten der Data Plane – und das ist auch meine Sichtweise. Um sicherzustellen, dass Application-Awareness auch in der Data Plane vorhanden ist (und nicht nur in der Control Plane via NBI) muss man weiter gehen als es heutige SDN-Architekturen zulassen. Denn diese haben sich hauptsächlich auf die großen Cloud Data Center und nicht auf Enterprise-Netze fokussiert – und die dafür benötige Data Plane bietet nicht die benötigte Granularität, um mit einer großen Anzahl an einzelnen und dynamischen Applikations-Flows fertig zu werden. Diese Lösung erreicht somit schnell ihr Limit in Sachen Potenzial und Skalierbarkeit.

In einem Enterprise-Netzwerk kann dies aber eine äußerst wichtige und kritische Funktion sein – verglichen mit einem Service Provider-Netzwerk, welches oft nur Konnektivität zur Verfügung stellt. Maßgeschneiderte, Flow-basierte ASICs überwinden dieses Limit und sind der Schlüssel zu einer wahren „application-aware” Architektur auf allen Ebenen. In einem meiner vorherigen Blogs auf SDN Central habe ich über diese Thematik bereits geschrieben, dieser Blog wurde sogar als ein „Must Read” aufgeführt: Flows and the data plane for SDN.

Aber es gibt noch mehr zu beachten, um eine Application-Awareness auf der Data Plane-Ebene zu erreichen. DPI und Policies spielen eine signifikante Rolle in einer solchen Architektur. Man kann zwar sagen, dass diese Funktion entweder lokal in einem virtuellen Switch (Performance?), in einem flow-basierten Switch (Performance!) oder irgendwo auf der Kontrollebene in einem Switch (virtuell oder physikalisch) vorhanden sein muss, aber der Schlüssel ist und bleibt die Möglichkeit, Applikationen innerhalb eines Netzwerks zu klassifizieren und dann die entsprechende Policy anzusetzen. Und wie diese Policy genau aussieht, ist dann wieder abhängig von der Applikation und den Arbeitsabläufen und -prozessen, die typischerweise außerhalb des Netzwerks und der IT ihren Ursprung haben. Und so spielt am Ende alles wieder zusammen in einer soliden Architektur.

SDN: Wer macht die Programmierung? Welches Level an Abstraktion wird benötigt?
Unsere Branche hat damit begonnen, die Haupteigenschaften einer Software-Defined Networking-Architektur zusammenfließen zu lassen. In einem meiner Blogs auf blogs.enterasys.com und sdncentral.com bin ich bereits auf diese Eigenschaften eingegangen und es gibt auch eine Reihe von Artikeln zu diesem Thema, wie beispielsweise bei der Network Computing, welcher eine gute Beschreibung darüber liefert.

Wenn ich mir die Eigenschaften und Versprechen von SDN ansehe, dann sehe ich als Hauptbestandteile:

  • Zentralisiertes Management & Kontrolle
  • Programmierbarkeit eines Netzwerkes
  • Herstellerinteroperabilität und Möglichkeiten von Integrationen

Das zentrale Management und die Kontrolle können durch einen einzelnen, zentralisierten Controller oder durch eine zentrale Management Plane mit einer verteilten Controller-Architektur umgesetzt werden: einen zentralen und programmierbaren Zugang in die Netzwerkinfrastruktur. Zur Programmierung und Integration selbst braucht man dann natürlich eine offene und zugängliche API.
Und wahrscheinlich braucht man sogar mehr: Netzwerk-Abstraktion. Die Art und der Grad der Abstraktion hängt davon ab, was man erreichen möchte. Wenn man nur die gesamte Konfiguration aller Geräte dort „1:1” durchreicht bzw. auch nichts von der Komplexität der Netzwerk-Topologie abstrahiert, dann hat man nichts gewonnen. Das ist oft der Fall bei vielen Controller-Ansätzen, die OpenFlow nutzen: Man muss einfach sehr viel über das Netzwerk wissen, um die richtigen Entscheidungen zu treffen. Und wer außerhalb des Netzwerks kann dies wirklich?

Andererseits hat SDN für mich auch mit organisatorischen Änderungen und Prozessen zu tun – man übergibt die Kontrolle an Geschäftsbereiche außerhalb des Netzwerkteams, vielleicht sogar außerhalb der IT – das ergibt Agilität. Das Wissen über das Netzwerk mag in diesen Gruppen nahezu Null sein und sie sollten sich auch nicht damit befassen – es sollte einfach funktionieren. Aber selbst wenn man sich außerhalb des Netzwerks oder der IT befindet und ohne den Netzwerkadministrator Applikationen und Arbeitsabläufe in einer automatisierten und orchestrierten Art und Weise konfiguriert – das typische SDN-Fallbeispiel im Data Center – stellt sich eine Frage: Was muss und will der Systemadministrator über das Netzwerk wissen? Und was müssen die Applikationen über das Netzwerk wissen, in dem sie aufgesetzt werden? „Nichts” ist keine gute Antwort, da man sich mit den Herausforderungen und Problemen auseinandersetzen muss, die Overlay-Technologien heute mit sich bringen. Und „alles” ist auch keine gute Antwort, da man gegenüber dem alten Setup nichts gewinnt.

Die Einfachheit einer SDN-Lösung, die Umsetzung im Unternehmen sowie auch der Erfolg der Hersteller, die SDN-Lösungen anbieten, wird davon abhängen, wie gut man diese Balance findet. Mögen die Spiele beginnen…

SDN und die Data Plane – ist Flow gleich Flow?
Es geht um Software, oder? Alles dreht sich – wie der Name Software-Defined Networking schon sagt – um die Software-Komponenten, APIs und die Möglichkeit, Applikationen zu integrieren.

Nun aber möchte ich den Fokus auf einen Bereich legen, der oft vernachlässigt wird: Die Data Plane. Während es eine Frage der Architektur ist, ob und wie die Control- und Data Plane auseinandergehalten werden oder wie ein hybrider Ansatz aussieht, ist es wichtig, die Idee eines Flows – ein Schlüsselkonzept von SDN – sowie die Funktionsweise der Data Plane in einer SDN-Architektur zu verstehen. Allgemein gesagt bezeichnet ein „Flow” die Kommunikation zwischen Endpunkten durch das Netzwerk. Die Definition eines Flows muss sowohl in der Data- als auch in der Control Plane existieren, um diesen entsprechen zu managen.

Die meisten Hersteller sind nicht in der Lage, skalierbare flow-basierte Systeme zu entwickeln – weder in Bezug auf die Switch- und Systemarchitektur, noch in Bezug auf die benötigte ASIC-Entwicklung für die Data Plane. Zudem hat der „Commodity”-ASIC-Markt dies bisher auch ignoriert, da eine höhere Skalierbarkeit (neben vielen anderen Dingen) auch mehr Speicher benötigt, was wiederum sehr teuer ist. Und höhere Kosten sind kein Ziel eines Netzwerkdesigns. Es hat also heutzutage keiner der großen ASIC-Hersteller etwas im Angebot, was die Skalierbarkeit in Sachen Flows angeht. Und fast alle SDN-Startups konzentrieren sich auf Software- bzw. Controllerlösungen, da die Einstiegskosten sehr viel geringer als im Hardware-Geschäft sind.

Aber warum ist dies überhaupt wichtig? Wenn man ein flow-basiertes System nutzt, kann das erste Datenpaket genutzt werden, um komplexe, Kontext-basierte Entscheidungen in der Software zu treffen. Anschließend werden dann alle Pakete dieses Flows in der Hardware, Data Plane, geswitcht. Das ist also die Basis für all die neuen, fortgeschrittenen und agilen Services, die mit SDN in Verbindung gebracht werden.

Ein SDN Design mit zentralem Controller und Commodity-ASICs wird nur mit Abstrichen in der Lage sein, die Herausforderungen in Sachen Skalierbarkeit zu bewältigen – sowohl auf der Control Plane als auch auf der Data Plane. Es gibt dazu 2 Strategien:

  1. Um in Echtzeit zu arbeiten, muss die Definition eines Flows sehr „grob” sein. Dadurch müssen weniger neue Entscheidungen in der Control Plane getroffen werden und demzufolge müssen weniger Flows in der Data Plane programmiert werden. „Grob” heißt hier, dass anstatt etwas genauer auf Layer 3r und 4 (Applikation) die Flows zu definieren, reduziert man dies auf die MAC- oder IP-Adresse (Subnetze) – Visibilität und Kontrolle werden weniger granular. Das mag für die Konnektivität von Vorteil sein, aber für Visibilität und Kontrolle auf der Applikationsebene nicht, da man wichtige Funktionen wie u.a. Netflow oder ACL auf dieser Ebene verliert.
  2. Die Flows werden vorab in der Data Plane durch den Controller konfiguriert (à la PVCs Permanent Virtual Circuits), so dass der Controller nicht mit neuen Flow-Anfragen überhäuft wird. Das bedeutet aber, dass man vorab wissen muss, wer mit wem spricht. Wie auch im vorherigen Punkt angemerkt, mag dies für die Konnektivität gut sein, aber für nichts weiter. Neue Optionen erlauben die Aggregierung von Flows, was wiederum zu den Abstrichen in Punkt 1 führt.

Über wie viele Flows sprechen wir also? Aus meiner Erfahrung kann man von 30 neuen Layer 4-Flows pro Minute pro Client wie beispielsweise einem Desktop-PC oder einem Tablet ausgehen. Ein Server in einem Enterprise Data Center ist typischerweise 100 bis 1.000 mal so groß bezogen auf Flows pro Minute. Server, die Internetdienste hosten, sind nochmal um ein Vielfaches größer.
Wenn wir uns nun mal ein Standard Enterprise Campus Netzwerk mit 10.000 Mitarbeitern und drei Endgeräten pro User ansehen, bedeutet dies 900.000 neue Flows pro Minute – alles Layer 4. Dies ist wohlgemerkt im Normalzustand – also ohne einen Schutz vor externen Angriffe, ohne Netzwerkausfallsicherung. Diese zusätzlichen Flows müssten dann innerhalb der Geräte programmiert werden oder es müssten Techniken zur Zusammenlegung dieser angewendet werden.

Der Commodity-ASIC-Markt bietet momentan Hochgeschwindigkeits-ASICs mit einem Durchsatz von bis zu 1Tbit/s, welche aber aufgrund der TCAM-Technologie nur maximal 4.000 gleichzeitige Flows bearbeiten können. Ebenso sind die heutigen Controller nicht für Flow-Entscheidungen in Echtzeit ausgelegt. Das Ergebnis ist eine riesige Lücke. Andererseits bieten einige Netzwerkhersteller Systeme, die durch den Einsatz spezieller flow-basierter ASIC-Designs bis hin zu Millionen von Flows skalieren.

Wer also Lösungen vergleicht, sollte den Fokus darauf legen, was der Hersteller auf beiden Seiten – der Control und der Data Plane – zu bieten hat. Ebenso sollte man nach den Zukunftsplänen fragen, so dass man eine gute Entscheidung treffen kann!

zugeordnete Kategorien: LAN
zugeordnete Tags: , , ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.