SolarWinds Head Geek Patrick Hubbard kommentiert Cisco Application Centric Infrastructure – die offenere SDN-Alternative?

Das Internet der Dinge führt zu immer komplexeren Anforderungen an die Netzwerkverwaltung. Lange Zeit waren wirklich offene Software-definierte Netzwerke (SDN) als Betriebsoption für das Internet der Dinge jedoch praktisch gestorben, da die Platzhirsche Cisco und von VMware diese Bedrohung zu eliminieren wussten. Doch ACI bringt Bewegung in das Thema.

Anbieter zum Thema

Dell GmbH

Moxa Europe GmbH

Fujitsu Technology Solutions GmbH

SolarWinds EMEA Headquarters

Nach intensiver Beobachtung des Marktes, der technischen Entwicklungen und deren Akzeptanz gelangte ich widerstrebend zu dem Schluss, dass VMware über kurz oder lang wohl die Vorherrschaft in Rechenzentren übernehmen würde. Damit bliebe außerhalb der VMware-Präsenz nur mehr Platz für ein gewisses Sammelsurium an Cisco-Technologien, „echtes“ SDN würde aus dem Rechenzentrum damit aber verbannt sein. Jüngste Entwicklungen deuten allerdings darauf hin, dass doch noch Hoffnung für kohärente, hinreichend offene, softwareverwaltete und programmierbare Netzwerke besteht.

Die frühen Botschaften von Cisco schienen dagegen schlicht in die entgegengesetzte Richtung zu weisen: ASIC abschotten, „Hardware“ durch „Software“ ersetzen und fertig ist das Hardware-definierte Netzwerk (HDN)! Doch mit der weiteren Entwicklung dieser Strategie von Cisco in der zweiten Hälfte des Jahres 2013 und dem Beginn der Implementierung sah es auf ein mal so aus, als ob sich Cisco im Vergleich zu VMware NSX sogar offener und flexibler erweisen und dabei dennoch die Vertrauenswürdigkeit im Rechenzentrum wahren könnte. Cisco erreichte dies – kurz gefasst – durch die Weiterentwicklung des HDN zur Application Centric Infrastructure (ACI = Anwendungszentrierte Infrastruktur).

Doch damit ist für Cisco noch längst nicht alles in trockenen Tüchern. Das Unternehmen muss zwei schwierige Herausforderungen meistern. Einerseits muss es mit der Bedrohung durch offene SDN-Lösungen auf Basis von Standardkomponenten fertigwerden. Andererseits muss Cisco zugleich seinen „Freundfeind“ VMware daran hindern, von der Festung des Server-Virtualisierungs-Managements aus die Rechenzentren zu erobern. Gleichwohl sieht die Zukunft heute vielversprechender aus als noch vor einem Jahr um diese Zeit.

Neue Hoffnung für alte Tagträume

Vor sehr langer Zeit (in der Ära von VMware ESX4) beschrieb ich meinen Traum vom deklarativen Anwendungs-Netzwerkdienst. Dessen Konfiguration enthält bereits die Netzwerkanforderungen, die er vermutet zu brauchen. Das Netzwerk könnte sich dann mittels einer Kombination aus Tiefentopologie und Selbst-Rückkopplung von Ressourcen entsprechend anpassen, um optimale Dienstbedingungen für die Anwendung bereitzustellen.

So würde die Anwendung den gewünschten Zugang erhalten, aber das Netzwerk würde die Autorität behalten, den von der Anwendung übermittelten Wunsch intelligent zu überschreiben. Schließlich ist das Netzwerk in fast allen Fällen der einzige Punkt, an dem eine optimale, sichere und richtlinienkonforme Konfiguration bereitgestellt werden kann.

ACI scheint diese Definition perfekt zu erfüllen. Zugleich scheint jedoch der Begriff „centric“ (zentriert) ein wenig irreführend zu sein. Der passendere Begriff wäre eigentlich „Application Aware Infrastructure“ (Infrastruktur mit Anwendungs-„Bewusstsein“). „Centric“ wurde dennoch, wie so viele andere Begriffe in der Wirtschaft, schlicht und einfach aus Marketinggründen gewählt. Denn wenn die Anwendung wirklich im Zentrum stünde, würde sie dem Netzwerk ihre Anforderungen einfach diktieren. Als Netzwerkingenieure wissen wir allerdings, dass das unweigerlich Probleme mit sich brächte. Was wir stattdessen benötigen, ist eine neue Automatisierung, die den gleichen Regeln folgt wie wir. Wir setzen nicht jede Änderungsanforderung der Systemadministratoren blindlings um, sondern bringen unsere Fachkenntnis ein, um bessere Lösungen zu finden. Das ist ganz natürlich – und entsprechend funktioniert auch ACI.

Auch hinsichtlich der Lizenzierung hat ACI gute Chancen, beim Netzwerkteam zu punkten. Jede „Defined Network“-Technologie benötigt einen Controller an irgendeiner Stelle. Genau diese Funktion möchte VMware wahrnehmen. Dies ermöglicht es dem Unternehmen, sein auf die Anzahl von VMs bezogenes Lizenzierungsmodell mittels VM-Erkennung auf das Netzwerk auszuweiten. Netzwerkingenieure haben jedoch seit jeher für Hardware, Ports und Bandbreite bezahlt. Eine Lizenzierung nach VMs lehnen wir daher ab.

Denn bei der Servicebereitstellung geht es letztlich um Leitungen, nicht um einen sich ständig wandelnden Bestand an virtuellen Maschinen, die wir vom Systemadministratoren-Team beziehen müssen. Bei ACI orientiert sich die Lizenzierung an Infrastrukturmerkmalen und Kapazitäten statt an der Anzahl der virtuellen Maschinen.

Ein weiterer Pluspunkt des ACI-Ansatzes ist, dass er deutlich leichter verständlich ist als das SDN-Konzept, das stellenweise sogar Admins und Einkaufs-Verantwortliche vor Herausforderungen stellt. Denn jede weiß, was eine Anwendung ist, und es ist immer einfacher, eine Rechnung für etwas auszustellen, worunter Manager sich etwas vorstellen können als für abstrakte Szenarios. Oder wie viele vertretbare Nutzungsszenarien für SDN fallen Ihnen unter Rentabilitätsgesichtspunkten spontan ein? Vermutlich nicht so viele…

Weniger Hype, mehr APIs

Das vielleicht Überraschendste an der Entwicklung des ACI-Konzepts von Cisco ist jedoch die relative Offenheit. NSX mag vielleicht eines Tages die raffiniertesten APIs der Welt haben – aber hierfür benötigt man nach wie vor NSX – und das ist nicht kostenlos erhältlich. Durch die Bereitstellung kohärenter APIs auf der Hardware verlagert Cisco die Zuständigkeit für die SDN-Controller an Dritte – darunter Open-Source- und Best-of Breed-Anbieter. Und das ist auch gut so, denn es ist enorm wichtig, dass diese Aufgabe sehr gut erfüllt wird, wenn aus dem Konzept etwas werden soll.

Es verdient Erwähnung, dass Cisco North- und Southbound-XML/JSON- REST-APIs bereitstellt, die verglichen mit der noch allgegenwärtigen, aber angegrauten SNMP-Technologie, klar in einer anderen Liga spielen. Cisco setzt zudem kein SDK voraus und ist damit externen Entwicklern gegenüber offener als Lösungen von Anbietern wie HP. Alle diese Faktoren verschaffen Cisco einen Vorsprung und sollten Netzwerk-Geeks, die sich seit langem für den Traum vom programmierbaren Netzwerk einsetzen, zum Experimentieren und Erkunden ermutigen.

Einzelne Anzeichen bestärken die Zuversicht, dass es Cisco mit der neuen Offenheit tatsächlich ernst meint. So setzt Cisco beim Insieme Nexus 9000 v1 beispielsweise Broadcom-ASICs statt proprietärer Hardwarekomponenten ein und geht damit den gleichen Weg wie Juniper und andere Anbieter. Dies deutet darauf hin, dass Cisco das Rechenzentrum nicht kampflos aufgeben will und bereit ist, auch offene Lösungen ins Spiel zu bringen, falls dies notwendig ist.

Patrick Hubbard

Es scheint fast so, dass Cisco immer erst dann sein Bestes gibt, wenn die Konkurrenz direkt vor der Tür steht.

Über den Autor

Patrick Hubbard gehört zu den Head Geeks von SolarWinds und gilt im Unternehmen als Netzwerk-Evangelist.

(ID:42613749)