Juniper: Kommt QFabric mit SDN und Standard-Switch ASICS?

Kommentieren Drucken

QFabric wird seit zwei Jahren diskutiert, der Verkaufserfolg blieb jedoch bislang aus, wobei der vorsichtig ausgedrückt extravagante Preis sicherlich eine Hauptrolle spielt. Juniper hat Mitte Dezember ein Unternehmen erworben, das SDN Controller baut. Wird damit der Weg zu einer preiswerteren QFabric-Variante mit Standards-Switch-ASICs frei?

Mitte Dezember 2012 hat Juniper das Startup Contrail Systems für 176 Mio. US$ gekauft. Das Ziel von Contrail ist die Entwicklung von SDN-Controllern. Contrail war erst zu Beginn 2012 von Google, Cisco, Juniper und Aruba gegründet worden. CEO Ankur Singlar war vorher CTO und Vizepräsident der Entwicklung bei Aruba, CTO Koreeti Kompella war zuvor CTO und Chef-Architekt des Junos-Betriebssystems bei Juniper. Kompella ist der Verfasser vieler IETF-Drafts und RFCs auf den Bereichen MPLS, IS-IS, L2-VPNs, OSPF und Traffic Engineering. Also, die Herren wissen sicher, was sie tun.

Juniper war von Anfang an mit 10 Mio. US$ an dem Unternehmen beteiligt, welches aber bisher im „Stealth Mode“ operiert hat und sein erstes Produkt, einen verteilten Controller, der sowohl BGP als auch XMPP unterstützt, 2013 vorstellen wird.

Juniper hat schon 2011 verschiedene Experimente mit SDN durchgeführt, hauptsächlich mit dem allgemein verfügbaren NOX-Controller. Allerdings darf man nie vergessen, dass Juniper ein wesentlicher Lieferant für Hochleistungstechnologie und vielfach ein Pionier im Provider- und WAN-Umfeld ist. Offensichtlich reichten die Möglichkeiten des NOX-Controllers nicht wirklich für das aus, was Juniper eigentlich möchte.

Juniper wird seine SDN-Strategie offiziell im Frühjahr 2013 vorstellen. Dennoch können wir uns jetzt schon ansehen, was ein Controller für die Netzwerk-Architektur von Juniper tun kann, denn klar ist schon heute, dass der Controller nicht nur verteilt ist, sondern sich auch auf die Basis-Dienstleistungen von Junos stützt.

Juniper hat mit dem Schritt des Kaufs von Contrail Systems eine relativ fruchtlose Diskussion im Markt beendet, nämlich die, ob QFabric nicht schon ein SDN-System ist.

Da QFabric für das RZ interessant ist, wollen wir uns einmal ansehen, an welchen Punkten SDN sinnvoll eingesetzt werden kann.

Juniper ist historisch gesehen der erste Hersteller, der seit Jahren konsequent den Gedanken der Virtual Chassis verfolgt. Aufgrund der bisher zur Verfügung stehenden Technologie konnten Sie zwar das Betriebssystem JUNOS schon soweit optimieren, dass eine sehr einheitliche und klare Verwaltbarkeit eines großen Netzes gegeben war, und sie konnten auch durch eine starke Flachheit der Gesamtkonstruktion bei den Ausschreibungen für latenzarme Trading Networks punkten, allerdings auch, weil Juniper, einer der führenden Anbieter für komplexe und hoch leistungsfähige Komponenten für Weitverkehrsnetze ist.

Bei „normalen“ Netzen und RZ-Netzen konnten sie ihren konzeptionellen Vorsprung aber nicht so sehr in Verkaufserfolg umsetzen, weil letztlich die Hardware am Ende doch mehr oder minder so aussah wie die des Mitbewerbs.

Mit dem Stratos-Projekt wurde jedoch die QFabric mit einer wirklich revolutionären Architektur möglich. Das gesamte Netz ist eine flache, elastische Fabric, in der alles nur einen Hop entfernt ist. Die Fabric ist skalierbar, ohne dass der Betrieb komplizierter wird.

3 Jahre Entwicklungszeit, 1 Million Mannstunden, mehrere Hundert Millionen US$ Einsatz und 125 Patente haben endlich zum gewünschten Ergebnis geführt. Die Entwicklungsziele lassen sich in drei Ebenen charakterisieren:

  • Management Plane: „N=1“ – Betriebsmodell eines einzelnen Switches
  • Control Plane: „Vereinte Intelligenz“ als einzige Möglichkeit, zu skalieren
  • Data Plane: funktional reichhaltige Netzkanten, simpler Netzkern: alles ist nur einen Hop entfernt

Wie funktioniert das nun ? Sehen wir uns zunächst die Probleme in einem einzelnen Switch an. Auf der Data Plane eines modernen Switches sind alle Ports direkt mit allen anderen verbunden, so dass man nur einen einzigen Lookup braucht. Auf der Control Plane gibt es eine Kontrollinstanz, die zentralisierte gemeinsame Tabellen mit allen Infos verwaltet und eine Management Plane, von der aus alle Ports verwaltet werden. Dieses Modell skaliert nicht richtig. Man kann zwar zu einer Switch Fabric noch weitere Ports hinzufügen, aber das hat seine deutlichen technischen Grenzen. Ist diese erreicht, kann man mit der flachen Netzstruktur nicht mehr weitermachen, sondern muss eine weitere Netzwerkstufe einführen.

Möchte man das grundsätzlich ändern, muss man die beschriebene einfache Struktur aufgeben oder das Skalierungsmodell ändern. Dafür gibt es unterschiedliche Möglichkeiten, aber Juniper geht folgenden Weg:

      die Line Cards werden von der Fabric getrennt
      alle Verbindungen werden mit Glasfaser statt mit Kupfer hergestellt
      direkt auf dieser Ebene gibt es duplizierte Geräte für die Redundanz

Damit kann man die Data Plane schön skalieren, wenn man gleichzeitig dafür sorgt, dass letztlich wieder alle Ports mit allen anderen verbunden sind und wieder nur ein einziger Lookup notwendig ist. Bleiben die Leitungen kurz, erreicht Juniper eine Latenz von 3,71 µs über das gesamte Netz hinweg, das ist schneller als bei allen bisher bekannten Ethernet Chassis Switches.

Hinsichtlich der Control Plane sind Intelligenz und Statusinformationen über die Fabric hinweg vereint und verteilt. Services für Kontrolle und Management nutzen ein gemeinsames skalierbares Modell. Letztlich wird dadurch das ganze Netz als einzelner Switch verwaltet.

Und genau hier ist der Ansatzpunkt. Möchte Juniper sein System z.B. für die Einbringung von Automationsmechanismen oder weiteren Werkzeugen zu Netzwerk-Kontrolle- und Administration öffnen, nützt ihnen bei dieser Konstruktion ein zentraler Controller rein gar nichts. Gefragt ist ein verteilter Controller, dessen einzelne Elemente so zusammenarbeiten, dass bei der Nutzung die Perspektive auf einen virtuellen singulären Controller entsteht.

Juniper entwickelte in der Vergangenheit traditionell eher eigene Switch-ASICs, auch wenn in Einzelfällen Standardprodukte wie der Broadcom Trident+ eingesetzt wurden. Es ist durchaus im Bereich einer positiven Wahrscheinlichkeit, dass Juniper das nunmehr aus wirtschaftlichen Gründen ändert. QFabric wurde trotz seiner enormen Leistungsfähigkeit vom breiteren Markt nicht wirklich akzeptiert, was einzig und alleine auf den Preis zurückzuführen ist und keinesfalls auf Qualität oder Konzept. Die neuen speicherbasierten Switch-ASICs bieten heute durchaus die Leistungsklasse, die Juniper in QFabric benötigt. Also können sie die teure Eigenentwicklung in diesem Fall einstellen und die Switch-Chips tatsächlich mit einem passenden Treiber in Verbindung mit einer verteilten Controller-Software steuern. Dadurch könnte der Endverbraucherpreis dramatisch gesenkt werden. Der Treiber wird allerdings nicht OpenFlow sein. Ankur Singla hat schon gesagt, dass mit dem Netzwerk-Orchestrierungs-System von Contrail Netzwerk-Virtualisierung und Netzwerkdienste implementiert werden können, ohne in einer virtuellen oder physikalischen Ebene OpenFlow benutzen zu müssen. Insgesamt sei man der Ansicht, dass OpenFlow „aus verschiedenen Gründen“ in einer Data Center Switching Hardware keinen Sinn macht.

Was ein Juniper-VB vor RZ-Kunden in seiner Präsentation gar nicht sagt, ist, dass Juniper eigentlich gar kein spezifisches RZ-Netz-System entworfen hat, sondern, um es respektlos zu sagen, ein hochqualitatives Provider-Netz in den Trockner geworfen hat. Sowohl das JUNOS Betriebssystem als auch alle anderen Komponenten wären auch für Netze großer Ausdehnung mit extremen Sicherheitsanforderungen und ebenso extremer Benutzertrennung geeignet. Auf diesem Bereich gehört Juniper seit vielen Jahren zu den führenden Anbietern und auch Terabit-DWDM-Netze sind ihnen durchaus wohl vertraut.

Und letztlich produzieren Abertausende Endbenutzer an einem Provider-Netz größenordnungsmäßig das gleiche Chaos wie Tausende VMs und wenn es mobile Benutzer sind, wandern sie auch. Es ist nicht wirklich so, dass die Virtualisierung das Problem neu erfunden hätte.

Gelingt es Juniper, einen verteilten SDN-Controller so zu designen, dass er Standard-ASICs, die deutlich preiswerter sein können als die bisher selbst entwickelten, so antreibt, dass die bisherige Struktur und Leistung von QFabric erhalten bleiben, aber der Preis durch die Änderungen dramatisch sinkt, bekommen wir eine echte Win-Win-Situation für diesen Hersteller und seine (möglichen neuen) Kunden!

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.

*

.