Herausforderung SDN
Monitoring von Software-Defined-Networks
Neben den traditionellen Netzproblemen, gibt es beim Einsatz von Software-Defined-Networks (SDN) eine Reihe neuer Herausforderungen für das Monitoren und Kontrollieren. Diese müssen für den künftigen Betrieb von SDN-Netzen verstanden und das Repertoire in Sachen Fehlersuche gilt es zu erweitern.
Bei SDN-Komponenten werden die Funktionskomponenten „Data-Plane“ und „Control-Plane“ voneinander getrennt. Somit soll SDN die einfachere Verwaltung der Netzressourcen erlauben, indem die unteren Funktionsebenen in virtuelle Services abstrahiert werden. Es entfällt die manuelle Konfiguration der Hardware und die zugehörigen Firewall-Regeln, Netzwerkadressen und virtuelle Netzwerke (VLANs) werden bei jeder Verschiebung auf den physikalischen Servern dynamisch generiert. Somit sorgt SDN für eine programmierbare, zentrale Steuerung des Netzwerkverkehrs, ohne manuell Zugriff auf die einzelnen physischen Netzwerkkomponenten nehmen zu müssen. Die Control-Plane entkoppelt das System, das entscheidet, wohin die Daten geschickt werden, vom darunterliegenden System (Data-Plane), das die Daten zum ausgewählten Bestimmungsort weiterleitet. Laut den Anbieter dieser Systeme soll diese Technologie die Netzadministration vereinfachen und neue Anwendungen ermöglichen, wie die Netzvirtualisierung, bei der die Control-Plane als reine Anwendung realisiert wird.
Es gibt viele Aufgaben und Problembereiche die eine SDN-Technologie nicht beseitigt. Aus diesem Grund müssen auch SDN-Netzwerke überwacht werden. So sind beispielsweise an den physikalischen und logischen Schnittstellen die jeweiligen Warteschlangen zu überprüfen. Werden von einem betreffenden Interface Pakete verworfen, führt dies zwangsläufig zu Datenstaus.
Die SDN-Switches treffen ihre Weiterleitungsentscheidungen auf Basis einer Vielzahl unterschiedlicher Informationen (MAC-Adressen, QoS-Bits und Informationen der Anwendungsebene). Um die Fehler bei der Paketweiterleitung zu dokumentieren, müssen die Switches für jede Weiterleitungsvorschrift die entsprechenden Statistiken und Daten sammeln. Dies ist besonders bei Bandbreitenproblemen von Nutzen, denn Bandbreitennutzung wird über QoS-Warteschlangen geregelt. Dadurch kann der Netzadministrator erkennen, wann eine bestimmte Anwendung oder eine Weiterleitungsdefinition (Forwarding-Klasse) mehr Bandbreite als erwartet benötigt.
Der SDN-Controller ist eine Applikation zur Verwaltung der Datenflüsse. Die meis-ten SDN-Controller basieren auf den Openflow-Mechanismen und steuern damit die Übertragungswege der Datenströme. Ein SDN-Controller entzieht der Netzwerk-Hardware ganz oder teilweise die Kontrolle über die Datenströme und realisiert die Verkehrssteuerung mithilfe von Software. Für das Monitoring liefert ein SDN-Controller sowohl für den Anwendungs- als auch für den Netzwerkadministrator die spezifischen Informationen. Daher erfordern SDN-Systeme die Bereitstellung von Methoden zur Überwachung von zeitkritischen Prozessen. Überschreitet einer der zeitkritischen Prozesse einen festgelegten Schwellwert sollte eine entsprechende Syslog-Nachricht an den Administrator übermittelt werden. Bei den Syslog-Meldungen sollten jedoch sinnvolle Ergänzung den Nachrichten hinzugefügt werden. Der ers-te Teil der Textnachricht sollte aus einer eindeutigen Identifikationskennung (ID) bestehen. Cisco verwendet beispielsweise diese Technik zur eindeutigen Identifizierung der Quelle jeder Nachricht.
Netzadministratoren nutzen sehr unterschiedliche SDN-Werkzeuge. Zum einen muss der Netzbetrieb gesteuert und überwacht werden, zum anderen werden Diagnosefunktionen zur Analyse von Problemen benötigt. Daher wird der Zugang zu den Daten auf der physischen und logischen Ebene offen stehen. Die Diagnose-Tools müssen aufzeigen, welche Wege die jeweiligen Datenströme nehmen und auch die Kriterien darstellen, die zur Auswahl der betreffenden
Übertragungswege geführt haben. Kommunikationsprobleme zwischen den Switches und den Controllern werden sicherlich relativ häufig auftreten. Werden diese inklusive der möglichen Fehlerursachen in einer Liste verzeichnet, dann beschleunigt sich die Fehleranalyse.
Fällt in einem redundant ausgelegten System eine Komponente aus, wird der Ausfall meist nicht bemerkt und daher nicht beseitigt. Zwangsläufig tritt auch irgendwann einmal ein Fehler im redundanten Pfad/System auf. Da das primäre System/der primäre Pfad bereits gestört ist, kommt es jetzt zum Totalausfall des Systems. Eine automatische Benachrichtigung über den Kommunikationsfehler sollte automatisch das Personal des Netzwerkbetriebs über das betreffende Kommunikationsproblem informieren.
In der Praxis führen jedoch nicht alle Netzwerkprobleme zu Totalausfällen. Das Überwachungssystem muss die notwendigen Statistiken über Paketverluste und Sendewiederholungen sammeln und somit die Zuverlässigkeit der Netzwerkverbindungen zwischen den SDN-Elementen dokumentieren. Auch gehören Netzwerkdiagramme, die einen Einblick in die SDN-Steuerungstopologie auf logischer und physikalischer Ebene bieten, zu den nützlichen Dingen für den Betrieb eines SDN-Netzwerks. Besonders am Anfang des Betriebs der neuen Technologie geben diese Netzdarstellungen praktische Hinweise, wo das Netz korrekt arbeitet oder wo Probleme vorliegen.
Das SDN-Steuersystem kann aus einem einzelnen Controller bestehen, aber es können auch mehrere Controller parallel eingesetzt werden. Die Anzahl der genutzten Controller hängt von der Komplexität und der Elastizität des jeweiligen SDN-Sys-tems ab. In einem größeren Netzwerk lässt sich über mehrere Controller-Systeme die Last verteilen. Ein hochverfügbares System benötigt ebenfalls mehrere Controller, denn der Ausfall eines Controllers muss zur Aufrechterhaltung der Verbindungen verhindert werden.
- Monitoring von Software-Defined-Networks
- Architektur des Monitoring-Systems
