OpenDaylight bekommt durch Open Source SDN-Controller ONOS Konkurrenz

ONOS von ON.Lab ist ein SDN-Controller, der mehr Skalierbarkeit als OpenDaylight bietet. Der Konkurrenzkampf droht den Markt zu fragmentieren.

Open Networking Lab (ON.Lab) hat letzten November einen neuen Open Source SDN-Controller vorgestellt, der OpenDaylight herausfordert. ON.Lab beschreibt das Open Networking Operating System (ONOS) als SDN-Controller auf Carrier-Niveau, der frei von Anbieter-Einflüssen sei. Im Gegensatz dazu wird OpenDaylight von verschiedenen Anbietern vorangetrieben.

Viele Anwender in der Branche begrüßen einen offenen Konkurrenzkampf zwischen OpenDaylight und ONOS. Allerdings müssen beide Projekte auch Schnittmengen finden, um eine weitere Fragmentierung des Marktes zu verhindern.

ON.Lab hat zwei Jahre lang an ONOS gearbeitet, sagt Guru Parulkar. Er ist Mitbegründer und geschäftsführender Direktor des Anbieters. Projektleiter werden versuchen, den verteilten SDN-Controller ONOS bei Netzwerk-Service-Providern einzusetzen. Es gibt aber auch Bestrebungen, die Technologie später bei Cloud-Providern und Unternehmen einzuführen.

„Wir wollen die Netzwerk-Welt von heute verändern, in der Anbieter proprietäre Router-Betriebssysteme einsetzen, um mehr Hardware zu verkaufen. Unser Ziel ist ein offenes SDN, mit dem man sich Services auf jeder Hardware skalieren lassen, inklusive White Boxes.“, sagt Parulkar.

Der ONOS-Controller im Überblick

ONOS ist ein modularer, skalierbarer und elastischer Open Source SDN-Controller, den Netzwerk-Betreiber auf mehreren x86-Servern installieren können, sagt Ram Appalaraju, strategische Berater des ONOS-Projekts. Der Controller kann derzeit eine Million Pfad-Operationen pro Sekunde verarbeiten und auf ein Netzwerkereignis in zehn Millisekunden reagieren.

„Es ist ein verteilten Kern, der auf mehreren Servern läuft“, erklärt Appalaraju. „Jede Instanz ist dabei identisch und sie arbeiten zusammen wie ein einzelnes Systeme. Brauchen Sie mehr Kapazitäten auf der Kontrollebene, fügen Sie einfach weitere Server hinzu. Auch Hochverfügbarkeit ist gegeben. Sobald eine Instanz ausfällt, wird die Workload nahtlos auf die anderen Systeme verteilt“, fügt er hinzu.

Mit dem Application Intent Framework wollen wir erreichen, dass Administratoren spezifizieren können, was sie tun möchten.

Ram Appalaraju, Strategischer Berater des ONOS-Projekts

ONOS bietet außerdem Persistenz auf Carrier-Niveau. Der Status der kompletten Kontrollschicht wird stetig auf jeder Instanz gespeichert, was sogenannte Hitless Updates ermöglicht.

Wie OpenDaylight verwendet die Southbound-Abstraktionsschicht bei ONOS mehrere Protokolle, um mit der Netzwerk-Infrastruktur zu kommunizieren. Dazu gehört unter anderem OpenFlow. Es kann das Netzwerk erkennen, zuweisen, konfigurieren und kontrollieren. Auf der Northbound-Seite verfügt ONOS über ein Application Intent Framework, um Richtlinien durchzusetzen, Konflikte zu lösen und andere Operationen auszuführen.

„Mit dem Application Intent Framework wollen wir erreichen, dass Administratoren spezifizieren können, was sie tun möchten. Dabei sollen sie sich keine Gedanken über das wie machen müssen“, sagt Appalaraju. „Wenn Sie Provisioning für eine 10-Gb-Leitung von einem Data Center zu einem anderen betreiben wollen, können Sie das auf einer hohen Ebene spezifizieren. Das Framework kommuniziert das Vorhaben dann zur Infrastruktur.“

Die Abstraktion des Application Intent Framework auf dieser Ebene könnte für ONOS den Unterschied ausmachen, sagt Eric Hanselman, leitender Analyst bei 451 Research LLC. Viele Projekte versuchen genau das zu erreichen. Dazu gehören auch OpenDaylight und OpenStack.

„Im Endeffekt wollen wir eine Umgebung, die das Netzwerk komplett integriert und auf die Bedürfnisse der Applikationen eingeht, die diese Kapazitäten konsumieren“, sagt Hanselman.

ONOS versus OpenDayLight: Skalierbarkeit und Anbieterunabhängigkeit

OpenDaylight ist bereits auf dem Markt und die Mehrzahl der Netzwerkanbieter ist darin involviert. Somit stellen sich einige die Frage, warum die Welt einen weiteren Open Source SDN-Controller benötigt. Andere wiederum begrüßen die Konkurrenz.

„Konkurrenz belebt das Geschäft“, sagt Nick Buraglio, Netzwerktechniker bei einem globalen Forschungsnetzwerk. „OpenDaylight war das erste richtig große System. Ich mag OpenDaylight und es ist einfach zu benutzen. Allerdings würde ich es niemals in meinem WAN einsetzen. Es basiert auf Java und ich bin mir nicht sicher, ob OpenDaylight derzeit die notwendige Skalierbarkeit aufweist“, fügt Buraglio hinzu.

„Beim ONOS-Projekt hat man sich Gedanken über Skalierbarkeit und Security gemacht“, erklärt der Netzwerktechniker. „Ich komme aus dem WAN-Bereich und da ist es ein Problem, wenn keine hohe Skalierbarkeit möglich ist. Man muss extrem kampferprobt und gerüstet sein, um geografische Redundanz zu garantieren.“

Bei OpenDaylight ist eine Menge Massenträgheit involviert.

Joe Skorupa, Analyst, Gartner

ON.Lab verweist zudem darauf, dass OpenDaylight ein von Anbietern getriebenes Projekt ist. ONOS wird auf der anderen Seite von Technikern entwickelt, die den optimalen SDN-Controller erschaffen möchten. Hier interessiert man sich nicht dafür, Business-Modelle zu bewahren. Stattdessen setzt ONOS auf Mitarbeit und Partnerschaften mit Service-Providern. NTT Communications und AT&T sind bereits an Bord, sagt Appalaraju von ONOS.

„Service-Provider haben ebenfalls eine Agenda“, sagt Buraglio. „Sie bewegen sich in die Richtung, die für sie am Besten ist und was die nötige Hardware-Unterstützung bietet. Es muss für Anbieter XYZ perfekt sein, da sie sich dafür verpflichtet haben. Zudem liegt die Aufsicht für OpenDaylight bei der Linux Foundation. Natürlich können Anbieter versuchen, es für eigene Zwecke zu benutzen, aber es bleibt Open Source.“

OpenDaylight und ONOS werden in vielen Punkten übereinstimmen, wenn man es aus Sicht der Mitwirkenden und Unterstützer sieht. AT&T hat fünf Millionen über fünf Jahre in ONOS investiert, um bei der Entwicklung der Plattform zu helfen. Allerdings ist das nicht das einzige SDN-Projekt, das AT&T unterstützt.

„AT&T arbeitet eng mit OpenDaylight zusammen, sowie mit einigen anderen Gruppen, die sich mit SDN und NFV beschäftigen. Dazu gehören OPNFV, OpenStack und ETSI ISG NFV“, schreibt AT&T in einer Stellungnahme. „Das Ziel ist, das gesamte Ökosystem anzutreiben, damit sich die besten Lösungen herauskristallisieren.“

Konkurrenz bei SND-Controllern ist gut, Fragmentierung ist schlecht

Da es innerhalb der Branche nun zwei Open Source SDN-Projekte gibt, ist die Gefahr von Fragmentierung größer denn je.

Viele Netzwerkbetreiber wollen eine offene SDN-Plattform, die ihnen alle Freiheiten lässt. Sie möchten von einem Anbieter zu einem anderen umsteigen können und Abstraktionen auf hoher Ebene migrieren. Das gilt auch für den Umzug von Northbound-SDN-Applikationen von einem Controller zu einem anderen. OpenDaylight hat viele verschiedene Anbieter an einen Tisch gebracht. 

Nur wenige davon haben allerdings ein kommerzielles Konzept, das es Kunden erlaubt, von einem Controller zu einem anderen zu wechseln. Da nun ONOS im Spiel ist, könnte die Fragmentierung zunehmen.

„Es besteht die Gefahr, dass wir bei zwei komplett unterschiedlichen Northbound-Schnittstellen enden und der Markt sich fragmentiert, so dass wir keine kritische Masse hinter eines der Projekte bekommen“, sagt Joe Skorupa, Vice President und Analyst bei Gartner. „Damit ONOS wichtig genug wird, müssen die Entwickler die gleichen Northbound APIs aktiv unterstützen und eng mit OpenDaylight zusammenarbeiten, damit die Applikationen portabel werden. 

Egal ob Sie ein Unternehmen oder ein Service Provider sind, ist der größte Störfaktor, wenn Sie eine Applikation wegen Inkompatibilitäten mit dem neuen Controller austauschen müssen. Es ist die SDN-Applikation, die in die betrieblichen Richtlinien und Prozeduren integriert wird.“

ON.Lab glaubt möglicherweise, dass sie OpenDaylight das Wasser abgraben. Das liegt laut Skorupa daran, dass viele Netzwerkbetreiber OpenDaylight bescheinigen, noch nicht am Ziel oder fertig zu sein. Weil ONOS im Moment der robustere Controller ist, entscheiden sich Projektleiter vielleicht dafür, OpenDaylight zu verdrängen und nicht aktiv kooperieren zu wollen.

„Bei OpenDaylight ist eine Menge Massenträgheit involviert“, sagt Skorupa. „Was würde passieren, wenn zwei oder drei involvierte Anbieter OpenDaylight plötzlich ganz oben auf die Agenda setzen und den schlechten Code mit etwas ersetzen, das eine Million Transaktionen pro Sekunde verarbeiten kann?“

In diesem Fall hätten wir ein offenes Rennen zwischen zwei starken Open-Source-Projekten. Kooperation wäre nach Skorupas Meinung der wesentlich schlauere Ansatz.

Folgen Sie SearchNetworking.de auch auf Facebook, Twitter und Google+!

Erfahren Sie mehr über Software-defined Networking

ComputerWeekly.de

Close