Software-Defined Networking ermöglicht eine bessere Kontrolle über die Netzwerktopologie und -verwaltung, und wer es noch nicht nutzt, wird feststellen, dass SDN bereits von den im Netz installierten Netzkomponenten unterstützt wird.
Auf einer Podiumsdiskussion erfuhr ich von mehreren Netzwerkverantwortlichen, dass sie über die jüngsten Cloud-Ausfälle sehr besorgt sind. Und warum? Weil jeder dieser Ausfälle durch Netzwerkprobleme verursacht wurde. Vier der fünf Diskussionsteilnehmer gaben zu, dass in ihren eigenen containerisierten Rechenzentren die Probleme häufiger von den Netzwerken als von den Servern ausgingen. Die schnelle Antwort auf diese Frage lautet: Mehr ist nicht besser.
Komplexität ist der Feind eines effizienten Betriebs und Managements. Die schiere Menge an Dingen, die in den Unternehmensnetzen vor sich gehen, kann Managementzentren und deren Managementtools überfordern. Wenn dann noch mehrere Anbieter und verschiedene Technologien etabliert sind, die zu Unterschieden in den Betriebsabläufen führen, wird es sehr unübersichtlich. Aber es sind nicht nur die Größe oder der Technologieumfang, die den Netzwerkbetrieb kompliziert machen, sondern auch die Art und Weise, wie Netzwerke funktionieren.
IP-Netzwerke wurden so konzipiert, dass sie höchst anpassungsfähig sind. Jeder Router ist eine Insel, der seine Identität und Status über alle verfügbaren Leitungen bekannt gibt. Auch hört jeder Router auf die Informationen der anderen Router. Aus all diesen eingehenden Informationen sammeln die Router den Zustand und die Topologie des Netzes zusammen und erstellen aus diesen Informationen die Routing-Tabellen. Regelmäßige Informationsschübe zwischen den Routern halten die Tabellen auf dem neuesten Stand – sozusagen.
Wenn Router A auf einer Verbindungsleitung zu Router B sendet, muss dieser Router seine Status-/Topologie-Ankündigung an die benachbarten Router wiederholen. Jede Änderung der Bedingungen, auch eine scheinbar geringfügige Änderung der Konfiguration, muss über weitergeleitete Informationen (Routing-Updates) verbreitet werden. Dieser Prozess benötigt Zeit und wird als „Konvergenz“ bezeichnet. Dieser Prozess dauert so lange, bis alle Router über die gleichen Informationen verfügen. Während der Konvergenz können Pakete verzögert werden oder sogar verloren gehen, aber das ist nicht das eigentliche Problem. Es ist schwierig, den Betrieb des Netzes zu planen, sowohl unter normalen Bedingungen als auch im Fehlerfall, wenn alles von der Propagierung korrekter Informationen abhängt.
MPLS kann hier helfen (Traffic-Engineering ist der Grund dieser Erfindung), aber die wirkliche Lösung könnte in softwaredefinierten Netzwerken (SDN) liegen. Leider haben wir SDN irgendwie verpfuscht.
Befragt man hundert Netzwerker, worum es bei SDN geht, werden diese sagen: Es geht bei SDN darum, die Kontrollebene und die Datenebene zu trennen. Was soll das heißen? Wenn es jemals eine nutzlosere Definition eines Netzwerkkonzepts gegeben hat, dann fällt sie mir nicht ein. Was zum Teufel bedeutet das, und warum sollte so etwas von Interesse sein?
In Wirklichkeit geht es bei SDN darum, die mehr oder weniger festen Router- bzw. Switch-Verbindungen durch eine adaptive Entwicklung zu ersetzen. Die Steuerungsebene kommt nur ins Spiel, weil der ganze Austausch von Routeninformationen nicht mit Datenpaketen, sondern mit Steuerungspaketen stattfindet.
In SDN-Netzwerken verwaltet ein Controller die Topologie des Netzwerks. Das ist kein großer Aufwand, denn Router und Trunks bewegen sich schließlich nicht viel. Der Controller hält sich über den Zustand der Netzwerkelemente auf dem Laufenden und verfügt über Richtlinien, die darüber entscheiden, wie Router und Trunks zusammengefügt werden sollen, um Routen zu erstellen. Er sendet die Routing-Tabellen an die „Router“ (nach dem Modell der Open Network Foundation unter Verwendung des Openflow-Protokolls).
SDN-Netzwerke haben die absolute Kontrolle über Routen und Routenänderungen. Sie ermöglichen es dem Betrieb, alternative Routing-Topologien auf der Grundlage von Fehleranalysen zu entwickeln oder sie auf der Grundlage von Richtlinien zu berechnen, aber so oder so bekommt jedes Gerät die gleichen Informationen von diesem zentralen Controller zugerufen. Es gibt keine Konvergenzzeit mit einem Haufen inkonsistenter Routen und keine Verwirrung. Da man alternative Ersatz- bzw. Redundanz-Topologien sorgfältig prüfen kann, bevor man diese festlegt, gibt es keine Überraschungen.
Noch immer gibt es große Unsicherheiten im Markt über den Nutzen und die Einsatzbereiche von SDN. Und dies, obwohl es SDN bereits seit anderthalb Jahrzehnte gibt.
Aber es gibt im Markt auch clevere Zeitgenossen, die wissen, wie man große Fragen richtig bearbeitet. Fast unmittelbar nachdem SDN veröffentlicht wurde, begann Google mit der Prüfung der Einführung von SDN in seinem Backbone-Netzwerk, und hat in der Folge diese Technik auch umgesetzt. Da Google nicht ohne Internet agieren kann, mussten Lösungen zur Zusammenarbeit gefunden werden. Google umgab seinen SDN-Kern mit einer Reihe von „BGP-Prozessen“, die sein SDN-Netzwerk wie ein IP-Netzwerk aussehen ließen. Das Ergebnis war ein SDN-basiertes „IP-Intent-Modell“.
SDN und das Google-Beispiel veranschaulichen zwei Möglichkeiten zur Reduzierung der Netzwerkkomplexität.
- Verlassen wir uns auf das deterministisches Verhalten zur Steuerung der Routen. In einem adaptiven Netzwerk weiß man nicht wirklich, worauf die ganzen Routen-Updates hinauslaufen. Man muss warten bis der gesamte Routing-Update-Prozess beendet ist. Beim SDN wird beim Routing-Prozess nur der SDN-Controller kontaktiert.
- Eine hierarchische Struktur kann die Komplexität prinzipiell reduzieren. Wäre das Internet, das aus Hunderttausenden von Routern besteht, ein flaches Netzwerk, das durch unsere Router-Updates miteinander verbunden ist, würde niemals irgendeine Information durchkommen. Stattdessen ist es in Segmente (autonome Systeme oder AS) unterteilt, die erstens zwischen den Segmenten und zweitens innerhalb der Segmente routen, wobei der letztere Prozess auf den zurufenden Routern basiert.
Da die meisten Unternehmen IP-VPNs für das WAN verwenden, konzentriert sich ihr Netzwerkaufbau in der Regel auf das Rechenzentrum und die Verbindung zwischen dem Rechenzentrum und dem VPN. Dies ist ein hervorragender Einsatzort für SDN, da die Konfiguration des Rechenzentrums von entscheidender Bedeutung ist und die Wahrscheinlichkeit gering ist, dass ein Netzwerkausfall den SDN-Controller komplett von einigen Geräten abschneidet, was die Kontrolle des Netzwerks erschweren würde. Ein Unternehmen mit mehreren Rechenzentren kann für jedes RZ ein separates SDN-Segment aufbauen und diese über SDN oder über herkömmliches Routing miteinander verbinden.
Die meisten Router- und Switch-Anbieter unterstützen SDN auf ihren neueren Geräten bereits. Man sollte dabei auf die Unterstützung von Openflow als vorrangiges Protokoll achten und genau prüfen, welche Funktionen in den jeweiligen Komponenten implementiert wurden. SDN-Controller sind ebenfalls bei den großen Router-Anbietern und einem Dutzend anderer Quellen erhältlich.
Bevor man sich für einen Controller entscheidet, sollten man die jeweiligen von einem Controller bereitgestellten Funktionen überprüfen, um die notwendigen Richtlinien erstellen zu können. Hier sollte nicht nur der „normale“ Zustand der Routen, sondern auch die benötigten Ausfallmodi definierbar sein. Man sollte sich auch vergewissern, dass der Controller die vollständige Protokollierung aller Aktivitäten unterstützt, sowohl von Änderungen des Netzwerkstatus als auch von Änderungen, die von Administratoren an den Betriebsparametern des Controllers vorgenommen werden.
Warum die ganze Sorge um Richtlinien und Journale? Wegen der dunklen Seite von SDN. Man kann das Netzwerk dazu bringen, genau das zu tun, was man will, und das bedeutet, dass man es dazu bringen kann, wirklich schlechte Dinge zu tun. SDN beseitigt keine Netzwerkfehler, sondern ermöglicht es dem Netzadministrator lediglich, eine explizitere Planung und Kontrolle in den Konfigurationsprozess einzufügen. Wenn der SDN-Controller den Netzadministrator nicht vor sich selbst schützt, wenn man nicht die Möglichkeit hat, Routen zu validieren, Richtlinien festzulegen und Protokolle zu konsultieren, wenn etwas schiefläuft, kann der Controller den Netzadministrator in die Wüste schicken.
Fazit
SDN bietet die Möglichkeit, die Netzwerke umfassend zu kontrollieren und nicht nur zuzusehen, wie es versucht, sich selbst zu kontrollieren. Es ist an der Zeit, die Netzkonzepte neu zu überdenken. Wir müssen uns nur bewusst werden, dass menschliches Versagen immer noch die größte Quelle für Netzwerkprobleme ist. Aus diesem Grund müssen wir sicherstellen, dass Mensch und SDN koexistieren und kooperieren.
