Sehr interessant findet silicon.de-Blogger Markus Nispel von Extreme Networks, wie Cisco’s “Insieme” Announcement letzten Herbst die Diskussion über die verschiedenen Aspekte der Application-Awareness im Netz und des Software-Defined Networking erneut angestoßen hat. Und natürlich vertritt Markus Nispel hier eigene Ansichten.
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 ü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 enstprechende Policy anzusetzen. Und wie diese Policy genau aussieht, ist dann wieder abhängig von der Applikation und der Arbeitsabläufe- und prozesse, die typischerweise außerhalb des Netzwerks und der IT ihren Ursprung haben. Und so spielt am Ende alles wieder zusammen in einer soliden Architektur
