Software Defined Networking: nur weil VMware technisch versagt?

3 Kommentare Drucken

Software Defined Networking (SDN) wird momentan in den USA als die Zukunft der Netzwerke dargestellt. In der Tat gibt es Gründe über die Architektur und Qualität unserer bestehenden Netzwerke und insbesondere das Versagen im schnellen Einführen neuer Lösungen nachzudenken. Tatsächlich aber ist für viele Anwender der durch Virtualisierung von Servern kreierte Bedarf die Hauptmotivation für SDN, erlaubt SDN doch eine Netzwerk-neutrale Mandantenfähigkeit und die Ausdehnung von L2-Netzen über beliebige Infrastrukturen hinweg. Aber wird hier das Pferd nicht von hinten aufgezäumt? Nur weil VMware und die anderen Virtualisierungsanbieter unfähig sind ihre Systemkommunikation auf L3 umzustellen, sollen ganze Architekturen geändert werden?

Fangen wir noch mal von vorne an: ja es gibt gute Gründe an der Qualität und dem technischen Status bestehender Netzwerke zu zweifeln. Technische Weiterentwicklungen dauern einfach zu lange (gutes Beispiel SPB und TRILL) und die Komplexität der Bertriebssysteme unserer Switches hat ein Ausmaß erreicht, das nicht mehr akzeptabel ist. Betrachten wir den Status Quo im aktuellen Software Design und die Leistungsfähigkeit moderner Bedienoberflächen, dann sind die Konfigurationsoberflächen der Switches in der Steinzeit stehen geblieben. Und die Kunden haben keine Chance, sie sind auf Gedeih und Verderb den Herstellern ausgeliefert. Und diese sind Hardware-lastig, ihre Software wird offenbar von Entwicklern entworfen, die den Anwender und seinen Bedarf nicht wirklich kennen.

Gleichzeitig ist die Zeit Hersteller-spezifischer ASICs vorbei. Es ist wichtig, die Bedeutung dieser Aussage zu erkennen. Die historische Daseinsberechtigung der Switch-Hersteller liegt in ihrer Fähigkeit, eine bessere Hardware als die Konkurrenz zu entwickeln. Aber das ist vorbei. Wir haben mehrere gute spezialisierte ASIC-Anbieter, die heute in der Lage sind, ASICs der absoluten Spitzenklasse zu extrem guten Preisen herzustellen. Damit erinnert die ganze Situation sehr an das Ende des Mainframes. IBM hat seine Marktmacht verloren als es Alternativen in der Hardware gab und dann die passende Software in offener Form dazu entwickelt wurde. Genau an diesem Punkt stehen wir theoretisch mit Netzwerken. Die Hardware ist frei verfügbar, die Frage ist also ob wir eine andere Software brauchen und wie diese aussehen sollte. Und diese Frage ist sowohl wichtig als auch sehr berechtigt.

Hier kommen jetzt die Virtualisierungshersteller ins Spiel. Die großen Rechenzentren von Amazon, Google und wie sie nicht alle heißen haben die Aufgabe, ihre verteilten Server möglichst optimal und mit guter Antwortzeit auszulasten. Das geht bei der Anzahl betroffener Server und virtueller Maschinen nur automatisch. Alle dafür notwendigen Mechanismen setzen zur Zeit auf Layer 2 auf. Aufgrund der schieren Größe der Rechenzentren entsteht damit auch das Problem, Verbunde von L2-Netzen über Layer 3 hinweg und auch zwischen Standorten zu schaffen. Kombiniert man das mit Mandantenfähigkeit und Sicherheit entsteht eine erhebliche Aufgabe, der bestehende Lösungen bisher nicht gewachsen waren. Im Kern benötigt man etwas, das der Hersteller Nicira (der inzwischen von VMware gekauft wurde) als Overlay-Technik bezeichnet. Dabei wird der Software Switch in den Hypervisorn durch den Open vSwitch ersetzt und der schirmt die physikalischen Netzwerke zum Hypervisor hin ab und generiert virtuelle Netzwerke auf der bestehenden Hardware. Im Prinzip kommen dabei die bekannten Tunnelprotokolle wie CAPWAP und VxLAN zum Einsatz, nur dass ihr Einsatz für den Administrator verborgen bleibt und je nach verfügbarer Netzwerk-Infrastruktur auch ganz verschiedene Protokolle genutzt werden können. Das Nicira-Produkt ist auch sicher ein interessantes Produkt und wird mittlerweile von vielen großen Providern und Cloud-Anbietern eingesetzt oder zumindest getestet. Aber zum einen bedeutet das nicht, dass sowohl Bedarf als auch Lösung auf normal große Unternehmen übertragbar wären. Und es bedeutet auch nicht, dass das viel mit SDN zu tun hat. Nicira hat hier eine besondere Art von Overlay-Technik für virtualisierte Umgebungen geschaffen, aber der einzige Zusammenhang mit SDN ist, dass eine SDN-Architektur zur Konfiguration der OpenvSwitches benutzt wird. Im Endeffekt hat Nicira seine Lösung als SDN-Applikation implementiert. Die Lösung selber hat aber im Kern mit SDN gar nichts zu tun. Diese Verwirrung hat seine Ursache in den Personen hinter Nicira. Speziell Scott Shenker und Nick McKeown werden eben als die Väter von SDN betrachtet. Und natürlich repräsentieren sie mit Berkeley und Stanford auch herausragende wissenschaftliche Einrichtungen. Aber davon sollte man sich nicht irritieren lassen. Der Bedarf virtualisierter Umgebungen kann auch ohne SDN erfüllt werden.

An dieser Stelle muss die Frage erlaubt sein, was die Virtualisierungshersteller eigentlich davon abhält, anstelle von Layer 2 auf Layer 3 zu setzen. Innerhalb einer Layer 2 Zone würde das keinen Unterschied machen. Hinzu kommt, dass die Performance von Layer 3 inzwischen nicht schlechter als die von Layer 2 ist. Zudem setzen die ganzen Tunnelverfahren wie VxLAN ja sowieso auf Layer 3. Auch Nicira setzt für seine Lösung explizit IP-Konnektivität voraus. Warum dann nicht sofort Layer 3 nutzen? Nur weil die bestehenden Virtualisierungslösungen eine Bastel-Historie haben und man irgendwo im Rahmen der erfolgreichen Professionalisierung diesen Punkt vergessen hat? Ich bitte um Kommentare zu dieser Frage.

Aber das bedeutet ja nicht, dass SDN an sich falsch ist. Wir müssen nur sauber trennen und fokussieren, warum wir über SDN reden. SDN hat das Potenzial zu einer völlig anderen Form von Netzwerk zu führen. Aber das ist mit vielen Fragezeichen verbunden. Die „Ablösung“ von IBMs Mainframes durch offenere Architekturen basierte ja nicht nur auf einer neuen Hardware, sie erforderte auch ein „offeneres“ Betriebssystem, in diesem Fall eben MS DOS. Das Betriebssystem war dann die Basis für viele unabhängige Applikationen. Um dieses historische Spiel jetzt zu wiederholen, bräuchten wir ein Netzwerk-Betriebssystem mit genau diesem Potenzial. Das ist auch der Ansatzpunkt von Nicira-Gründer Scott Shenker. Und die Übernahme von Nicira durch VMware hat viel Geld in die Taschen von Martin Casado, Nick McKeown und Scott Shenker gespült. Aber die Schaffung einer neuen Software-Architektur dieser Komplexität ist eine Herausforderung. Netzwerk-Betriebssysteme wie IOS mögen ja viele Altlasten beninhalten, die sie so kompex machen und sie haben keine offene Trennung zwischen Betriebssystem und Applikation, aber es gibt eben auch technische Gründe für die Komplexität.

Kommen wir zu einem ersten Fazit für diesen Artikel. SDN ist eine spannende Entwicklung, da gibt es keine Frage. Aber es darf nicht mit dem Bedarf virtualisierter Umgebungen in einen Topf geworfen werden. Wir sind in der Frühphase der technischen Etwicklung. Aber die tragenden Köpfe haben sowohl Potenzial als auch Geld. Wir müssen diese Entwicklung weiter beobachten. Genau das werden wir auch für sie tun. Beachten sie die Diskussion auf dem ComConsult RZ-Infrastruktur-Redesign Forum 2012 und auch das dazu in Entwicklung befindliche Video von ComConsult Study.tv.

 

zugeordnete Kategorien: LAN, Virtualisierung
zugeordnete Tags: , , , ,

Sie fanden diesen Beitrag interessant? Sie können



3 Kommentare zu "Software Defined Networking: nur weil VMware technisch versagt?":

  1. Dr.Kauffels schreibt:

    Grundsätzlich stimme ich den Ausführungen zu, bis auf einen Punkt. Es geht hier nicht um technisches Versagen von VMware. Was aktuell passiert, ist das Ergebnis der jahrzehntelangen Ignoranz der Techniken und Bedarfe von Betriebssystemen durch die Netzwerker und vice versa. Eine Software wie VMware kann nur dann ordentlich funktionieren, wenn die Hardware dazu geeignet ist. Das haben wir bei den Speichern gesehen. Gäbe es keine ordentliche Hardwareunterstützung für die Realisierung virtueller Speicher von VMs, würden wir heute gar nicht mehr über VMs sprechen. Genauso verhält es sich mit der Kommunikation. Was für die VM-Kommunikation eigentlich benötigt wird, ist eine Kanalverlängerung, um mal diesen älteren Begriff aus der Host-Welt zu strapazieren. VMware steht jetzt völlig verzweifelt vor der Tatsache, dass der PCIe-Bus nicht weltumspannend ist. Also basteln jetzt beide Seiten, VMware und die Netzwerker, wüst herum, in der Hoffnung, dass es am Ende funktioniert. Obwohl VMware Marktführer ist, würde ich von einer Kommunikationslösung wie in den letzten 50 Jahren üblich verlangen, dass sie herstellerneutral ist. Und jetzt SDN zu bemühen, ist auch eine Verzweiflungstat, weil eben ein Software-Hersteller nur Software herstellen kann, wie der Name schon sagt. Tatsächlich ist es aber multidimensionaler Kokolores, überall wieder Software-Komponenten hineinzuhängen. Auf der einen Seite möchte man keine L3-Kommunikation, weil sie angeblich zu Leistungsengpässen führen könnte, andererseits knallt man wieder Soft-Switches in die Systeme, die mit Sicherheit zu Leistungsengpässen führen werden. Diese Logik muss mir erst einmal jemand erklären. Was mich am meisten an der Diskussion ärgert, ist, dass es bereits eine Lösung gibt, die auch wunderbar funktioniert, über die aber kaum jemand spricht: RDMA auf InfiniBand oder Converged Ethernet. Es gibt Installationen von Mellanox, bei denen die VMs alleine oder in Gruppen mit bis zu 40 Gb kommunizieren können und dabei sowohl in der Kommunikation als auch bei der Wanderung alle anderen Alternativen extrem alt aussehen lassen. Beobachten Sie die Diskussion weiter, es ich wirklich extrem spannend !!

  2. Cornelius Höchel-Winter schreibt:

    Ich verstehe nicht, warum SDN die Architektur oder das Design unserer Netzwerke ändern soll. SDN ist zunächst mal eine Managementlösung zur Steuerung von Switches. Dass es hier zu einer herstellerübergreifenden Lösung kommt, macht in Zeiten, in denen sich die Hardware in den Switches nicht groß unterscheidet, sicherlich Sinn – das wird im Artikel ja auch dargestellt. Eine Steuerungs-Software ändert aber nicht das Netzwerkdesign – sollte sie jedenfalls nicht.

    Ein anderer Aspekt ist die Virtualisierung praktisch aller Anwendungen und die Integration von Cloud-Lösungen: Wenn man vMotion als integralen Bestandteil einer Virtualisierungslösung ansieht und von dieser Technik erwartet, dass Server während ihres Betriebs verschoben werden können, ohne dass sie ihre MAC-Adresse und ihre IP-Adresse ändern und bestehende Verbindungen zur Infrastruktur erhalten bleiben, dann sind wir bei Layer 2. Punkt. Layer 3 nutzt da nichts.

    Layer 3 ist ja keine Alternative zu Layer 2, sondern setzt auf Layer 2 auf! Insofern kann Layer 3 auch keine Layer-2-Probleme lösen. Ein Beispiel? IP-Multipathing kann keinen einzigen Link nutzen, den ein Spanning Tree auf Layer 2 geblockt hat. D.h. Layer 2 ist die eigentliche Basistechnologie in allen Rechenzentren, auch wenn viele dies in ihren (Cisco-lastige) Designs vergessen haben. Mit vMotion werden wir jetzt mit der Nase wieder darauf gestoßen.

    Natürlich ist ein einziges allumfassendes Layer-2-Netz nicht die Lösung. Aber schon normale VLANs können da den einen oder anderen RZ-Betreiber voranbringen. Wie weit, hängt im Wesendlichen von der Größe des RZ-Netzes ab und ob Mandantfähigkeit eine Rolle spielt. Die nächste „Eskalationsstufe“ sind dann die angesprochenen Tunnellösungen. Ob man sich hier für SPB, TRILL, CAPWAP, LISP oder was auch immer entscheidet, kann von allen möglichen Aspekten abhänen, aber doch sicherlich nicht von der eingesetzten Virtualisierungslösung! Ganz im Gegenteil, gerade wenn die Anwendung portal sein soll, darf das verwendete Tunnelprotokoll nicht Teil der Anwendung sein. Wenn wir jetzt aber feststellen, dass solche Tunnellösungen in den meisten Netzen nicht zur Verfügung stehen, ist das doch kein Versagen von VMware, sondern ein Versagen der Switch-Hersteller, die diese Protokolle nicht zeitnah implementieren (können).
    Und damit kommt SDN wieder ins Spiel!

  3. Dr. Jürgen Suppan schreibt:

    „Natürlich ist ein umfassendes Layer 2 Netz nicht die Lösung“ ist der zentrale Satz. Das Mitnehmen von IP-Adressen ist architektonisch einfach falsch. Wir müssen erkennen, dass die bestehende Technologie aus Layer 2 und TCP/IP hier einfach versagt. Wir brauchen also einen neuen und weitergehenden Ansatz. Cisco hat mit LISP im Prinzip ja bereits eingestanden, dass die normale TCP-Adressierung in diesen Umgebungen versagt. Es gibt auch Ansätze aus dem akademischen Bereich von Teemu Kokonen, der eng mit Nick McKeowen und Scott Shenker zusammen arbeitet, die in Richtung einer Namens-basierten Adressierung gehen. Einfach formuliert ist meine Sicht, dass wir eine neue Form der Adressierung und ein Session Layer für TCP/IP brauchen. Zumindest den Bedarf für einen neuen Ansatz sehen auch alle Beteiligten, nur würde eine normale Standardisierung höchstens unsere Enkel beglücken. Hier kommt SDN ins Spiel. SDN ist viel mehr als eine simple Management-Lösung. Der Kern liegt in der neuen und offenen Controller-Architektur, die genau in der aktuellen Situation die Umsetzung neuer Lösungen in sehr kurzer Zeit gestattet. In Kombination mit den großen Forschungseinrichtungen wie Stanford wird ein Schuh daraus. SDN gibt uns das Potenzial die IETF- und IEEE-Blockierer endlich kalt zu stellen und zu einer dynmischeren Entwicklung zu kommen. In diesem Sinne ist SDN auch ein Machtkampf zwischen trägen und selbstgefälligen Normierern der führenden Herstellern und einer deutlich dynamischeren akademischen Welt. Normalerweise würde dies die akademische Welt verlieren. Aber der Bedarf für einen neuen Ansatz ist für die großen Cloud-Provider so groß geworden, dass eine Akzeptanz für den neuen Weg entstehen könnte. Eine Milliarde Dollar für Nicira spricht eine deutliche Sprache.

Anmerkungen, Fragen, Kommentare, Lob und Kritik:

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

*

.