Juniper OpenContrail oder Cisco ACI: Was ist die bessere SDN-Strategie?

Wer über Software-defined Networking nachdenkt, steht vor der Wahl zwischen OpenContrail und Cisco ACI. Beide Varianten bieten Vor- und Nachteile.

Man sagt oft, dass es bei der Wahl einer SDN-Strategie (Software-defined Networking) nur um die Entscheidung zwischen Cisco oder VMware geht.

Viele Netzwerkspezialisten sehen sich aber auch bei den Netzwerkanbietern ihres Vertrauens nach SDN-Technologie um. Somit könnte hier die Entscheidung auch bei Cisco ACI oder Juniper OpenContrail liegen. OpenContrail verfolgt eine Software-Strategie, die sich auf einen zentralisierten Controller und ein virtuelles Netzwerk-Overlay stützt. Letzteres basiert auf einem physischen Unterbau, ist aber abstrahiert. 

OpenContrail stellt zwei Schlüsselkomponenten eines Software-definierten Netzwerks zur Verfügung: den Open-Source-Netzwerk-Controller und einen Hypervisor-basierten virtuellen Router. 

Der virtuelle Router wird auf einem virtuellen Server-Hypervisor eingesetzt und stellt über Tunneling-Protokolle Verknüpfungen zwischen Servern innerhalb des Hosts und des physischen Unterbaus her. Derzeit werden dafür nur Open-Source-Hypervisoren wie zum Beispiel KVM (Kernel-based Virtual Machine) und Xen vom OpenContrail-Ökosystem unterstützt.

Im Vergleich dazu ist Cisco ACI eine vormontierte Lösung, die Hardware und Software integriert. Es gibt zwar ebenfalls ein virtuelles Overlay, allerdings ist dieses mit dem darunterliegenden physischen Netzwerk enger integriert. 

Das physische Netzwerk besteht aus Switches, die Cisco ACI unterstützen. Die komplette Infrastruktur besteht aus drei Komponenten: dem APIC (Application Policy Infrastructure Controller), Switches aus der Serie Nexus 9000 und Ciscos eigenem Hypervisor-basiertem AVS (Application Virtual Switch). 

AVS ist der angepasste Nexus 1000v, der mit APIC zusammenarbeitet. Aus diesem Grund gibt es auch unternehmenstaugliche Hypervisor-Unterstützung für VMware ESXi, Microsoft Hyper-V und KVM für Cloud-orientierte Unternehmen.

Cisco ACI oder Juniper OpenContrail: Eine Diskussion über Hard- und Software

Eine der hauptsächlichen Fragen in der Diskussion über Vor- und Nachteile von Juniper OpenContrail oder Cisco ACI ist, ob Hardware bei Software-defined Networking eine zentrale Rolle spielen sollte.

Damit Cisco ACI so kosteneffizient wie möglich ist, müssen interessierte Unternehmen in Cisco-Switching investieren. OpenContrail dagegen lässt sich mit jeglicher physischer Infrastruktur implementieren, solange die richtigen Hypervisoren und virtuellen Router im Einsatz sind. Damit sind die Anfangsinvestitionen deutlich geringer. Kritiker prangern allerdings an, dass der Ansatz mit dem Software-Overlay den Zustand des darunterliegenden physischen Netzwerks nicht ausreichend adressiert.

Damit Cisco ACI so kosteneffizient wie möglich ist, müssen interessierte Unternehmen in Cisco-Switching investieren.

Cisco-Anwender wird die Nachricht freuen, dass bestehende Nexus-1000- bis -7000-Serien nachgerüstet werden können, um das neue ACI-Ökosystem zu unterstützen. Bei der Veröffentlichung von ACI war die Nutzung nur mit den neuen Nexus-9000-Switchen möglich – frühere Nexus-Versionen konnten damit nicht umgehen.

Die Möglichkeit eines Upgrades eröffnet also einer breiten Basis von Cisco-Anwendern den Einsatz von Cisco ACI und macht die Technologie für Unternehmen attraktiver. In der offiziellen Dokumentation ist zu lesen, dass ACI nur dann von Erfolg gekrönt sein wird, wenn man es einfach in bestehende Data-Center-Architekturen integrieren kann. Da sind bestehende Cisco-Kunden natürlich die erste Zielgruppe, an die sich Cisco ACI richtet.

Ciscos Ansatz, Hardware und Software unter einen Hut zu bringen, hat ohne Zweifel seinen Reiz. Allerdings gibt es in der Geschichte der Informationstechnologie genügend Beispiele dafür, dass überlegenere Technologien links liegen gelassen wurden, weil Anwender günstigeren und einfacher anwendbaren Lösungen den Vorzug gaben.

Juniper OpenContrail liefert keine der darunterliegenden Netzwerkkomponenten aus. Dadurch können Netzwerkadministratoren diese Technologie einfach in existierende Infrastrukturen implementieren. Darauf basierend lassen sich dann virtuelle Hosts und komplette Data Center verbinden.

Das funktioniert aber nur dann, wenn die derzeitige Netzwerkinfrastruktur entsprechend ausgestattet ist. Overlay-Netzwerke stellen zwangsläufig gewisse Anforderungen an existierende Switching- und Routing-Leistungsmerkmale. Viele potenzielle Anwender sorgen sich daher, dass es Probleme geben könnte, wenn die Verbindung zwischen Overlay und Unterbau (Underlay) nicht angemessen ist.

Deswegen ist es vielleicht verständlich, dass Cisco das SDN-Problem lösen wollte, indem die Firma qualitativ hochwertige und moderne Switching-Komponenten als Teil der Lösung gleich mit anbietet. Wenn Sie Software-defined Networking einsetzen wollen, dann muss die Kapazität und Performance der Hardware-Plattform schließlich absolut zuverlässig sein.

Sowohl bei Cisco ACI als auch Juniper OpenContrail fehlen wichtige Fall-Studien

Ist eine Technologie so neu wie SDN, sind Fall-Studien zu so genannten „Early Adoptern“ immer kritisch zu betrachten. Diese frühen Nutzer können die Wahrnehmung des ganzen Marktes beeinflussen.

Wenn Sie Software-defined Networking einsetzen wollen, dann muss die Kapazität und Performance der Hardware-Plattform absolut zuverlässig sein.

Das ist sowohl für Cisco als auch für Juniper ein Problem. Cisco stellt zwar einige nette Videos zur Verfügung, in denen Kunden über ACI sprechen. Allerdings gibt keiner dieser Kunden an, die Technologie bereits in einer produktiven Umgebung einzusetzen. 

Ich glaube schon, dass sich die Nexus-9000- Serie wie warme Semmeln verkauft. Ohne den Einsatz eines APIC und die notwendige Infrastruktur-Änderungen ist es allerdings nur ein leistungsfähiger Switch, den man irgendwann für SDN verwenden könnte. Der Großteil der Anwender braucht aber ganz einfach eine Vorstellung von potenziellen Stolpersteinen und Herausforderungen, denen sie sich stellen müssen.

Bei Juniper OpenContrail sieht es ein bisschen besser aus, wenn auch nicht viel. Hier habe ich lediglich die Referenz-Geschichte eines Kunden/Entwicklers bei einem französischen Storage-Provider gefunden. 

Es gibt Gerüchte, dass im Fernen Osten ebenfalls jemand auf OpenContrail umstellen möchte. Aber auch diese Schwalbe macht noch keinen SDN-Sommer.

Möglicherweise ist das Erstellen von Fall-Studien für Software-defined Networking aber auch schwierig, da bisher wenige Unternehmen auf den Zug aufgesprungen sind. Wer es bereits einsetzt, hat vielleicht alle Hände voll zu tun und keine Zeit, tolle Reviews zu schreiben.

SDN-Ökosystem: Wie wichtig sind Partnerschaften für die Anbieter?

Sowohl Juniper als auch Cisco wollen ein Partner-Ökosystem aufbauen, aus dem Anwendungen für die jeweiligen Controller entstehen sollen. Die Anwendungen sollen unter anderem flexible Layer-4-7-Services und Orchestrierungsfunktionen für das programmierbare Netzwerk zur Verfügung stellen.

Sowohl Cisco als auch Juniper haben bereits wichtige Partnerschaften mit diversen Host-Anbietern und Entwicklern geschlossen, aber die beiden Ökosysteme könnten sich höchst unterschiedlich entwickeln. Der Grund dafür ist der Open-Community-Aspekt von OpenContrail.

Bei OpenContrail war man damit beschäftigt, Allianzen zu schmieden und Code zu veröffentlichen. Somit ist das Ökosystem bereits gewachsen. Die Zugewinne sind zwar moderat, aber wichtig. So gibt es bereits die funktionierende Integration für häufig eingesetzte Plattformen wie Juniper MX, Cisco ASR, Apache CloudStack und Citrix Cloud Platform.

Der Open-Source-Ansatz von OpenContrail hat dazu geführt, dass sich die Technologie wahrscheinlich in den Händen von mehr Entwicklern und Netzwerkadministratoren befindet als jede andere SDN-Komponente. Ein flüchtiger Blick auf Junipers Github-Repository zeigt, dass sich das Projekt aktiv in der Entwicklung befindet. Die Community ist zwar klein, aber gut besetzt. Ein Teil der Entwickler mag sich aus persönlicher Neugier mit der Software beschäftigen. 

Die OpenContrail-Standards dürften sich trotzdem als eine der bestimmenden SDN-Normen herauskristallisieren. Selbst wenn OpenContrail nie auf breiter Basis installiert werden sollte, dürfte es wahrscheinlich als Software-Grundlage für einen erfolgreichen Nachfolger dienen.

Aber auch Cisco ist natürlich nicht untätig und hat sich schwergewichtige Unternehmen wie Microsoft, F5 oder auch Citrix ins Boot geholt. Solche Kooperationen sind wichtig, allerdings oftmals auch fragil. Häufig ist einer dieser Partner nur eine Akquisition davon entfernt, selbst auf der großen SDN-Bühne mitzuspielen.

In diesem Sinne sind lockere Zusammenschlüsse oftmals flexibler. Sollte ein Schlüssel-Anbieter aussteigen, füllt möglicherweise ein anderer die Lücke. Die vertikale Natur von Cisco ACI bedeutet also, dass das ganze Ökosystem nur so stark wie das schwächste Glied ist. Die Probleme und deren Lösungen bei der Implementation von Cisco ACI können also nur innerhalb eines Unternehmens entstehen und gefunden werden. Mit einem Open-Source-Ansatz, hinter dem ein großer Anbieter steckt, können Anwender bei Problemen dagegen mit einer breit angelegten Unterstützung rechnen.

VMwares Rolle bei der Entscheidung zwischen Cisco ACI oder Juniper OpenContrail

Für beide Plattformen wird VMware die größte Konkurrenz bleiben. Der herstellerunabhängige Ansatz ohne spezielle Hardwareanforderungen von VMware NSX wird beide Lager herausfordern. Hinzu kommt noch, dass VMwares Hypervisor bereits in vielen Data Centern eingesetzt wird.

Das Wachstum von NSX wird möglicherweise durch strenge Lizenzierung und hohe Supportkosten verlangsamt. Sollte sich ein Unternehmen nach einer SDN-Lösung umsehen, glaube ich, dass es immer ein Kopf-an-Kopf-Rennen zwischen zwei Anbietern geben wird. Das ist entweder Cisco gegen VMware oder VMware gegen Juniper OpenContrail. Spannend wird bleiben, wie Cisco und Juniper weitere Partnerschaften entwickeln und wie man die Beziehungen zu VMware pflegt.

Über den Autor:
Glen Kempist Enterprise-Solutions-Architekt beim Services-Provider Fortinet. Er designt und installiert Netzwerk- und Anwendungs-Security-Tools. Dazu gehören Zugriffskontrolle, Remote-Zugriffe, Firewalls und ähnliche Technologien. Zudem hat er Erfahrung als professioneller Service-Consultant. Sie finden seine Blogs unter sslboy undPacket Pushers Podcast. Auf Twitter ist er unter @ssl_boy erreichbar.

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

Artikel wurde zuletzt im Oktober 2014 aktualisiert

Erfahren Sie mehr über Software-defined Networking

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close