Netzwerk-Disaggregation: Es kommt auf die APIs an

Viele Netzwerktechniker meiden die Disaggregation von Netzwerken, weil sie hohen Arbeitsaufwand befürchten; ähnlich zu dem Aufwand, der für das Trennen von Hardware und Software notwendig ist. Bei der Disaggregation werden die einzelnen Komponenten des Netzwerks voneinander entkoppelt, virtualisiert und in einem gemeinsamen Ressourcen-Pool zusammengefasst.

Für die Disaggregation sind beispielsweise folgende Aufgaben zu erledigen:

• Kauf von Hardware, die den Anforderungen an Geschwindigkeit und Datenvolumen/Datendurchsatz genügt.
• Auswahl eines Betriebssystems für das Netzwerk, das die Anforderungen etwa an das Netzwerk-Management oder die Integration in bestehende Prozesse erfüllt.
• Aufbau einer Steuerungsebene (Control Plane), die das Netzwerk-Management meistert und vorhandene Protokolle unterstützt.
• Kauf und Entwicklung der erforderlichen Tools für den Aufbau, die Bereitstellung und Verwaltung von disaggregierten Netzwerken.

Das hört sich nach einer Menge Arbeit an – und es ist auch viel Arbeit. Für eine kleine IT-Abteilung oder eine IT-Abteilung ohne Kenntnisse über Betriebssystem und Tools scheint die Disaggregation fast unmöglich zu sein. Hier ist jedoch ein wichtiger Punkt zu beachten: Firmen müssen das alles nicht alleine umsetzen. Es gibt zwei verschiedene Wege, um den disaggregierten Ansatz zu realisieren.

Erstens: Ein Value-Added Reseller kann Unternehmen beim Wechsel von einem herstellerbasierten, aggregierten oder Appliance-basierten Ansatz zu einem disaggregierten Modell unterstützen. Dies kann eine Herausforderung sein; es gibt nur wenige dieser Reseller auf dem Markt; und deren Geschäftsstrukturen eignen sich in der Regel nicht für diese Art von Beratung.

Zweitens: Die Firma entscheidet sich, nicht alle Komponenten des Netzwerks selbst zu besitzen und zu betreiben. Einer der Vorteile der Netzwerk-Disaggregation ist es, dass Firmen nach dem Aufteilen des Systems in einzelne Komponenten entscheiden können, welche Teile sie besitzen möchten und welche nicht.

Unternehmen sollten sich aus folgenden Gründen für den Eigen-Betrieb von Teilen des Netzwerks entscheiden:

• Sie haben interne Mitarbeiter mit den erforderlichen Fähigkeiten und genügend Zeit, um die Arbeit zu erledigen; oder sie halten es für wichtig, aus geschäftlicher Sicht Mitarbeiter mit diesen Skills zu entwickeln oder zu finden und einzustellen.
• Sie glauben, dass der Return on Investment (ROI) beim Kauf einer bestimmten Hard- oder Software genügend Mehrwert für das Geschäft bringt, um die Entwicklung oder Einstellung der Mitarbeiter zu rechtfertigen, die für den Betrieb dieser Komponenten erforderlich sind.

Wichtig ist, dass es sich hier nicht um technische, sondern um geschäftliche Entscheidungen handelt. Einer der Vorteile des disaggregierten Modells besteht darin, dass diese Entscheidungen in die Hände des Betreibers und nicht des Herstellers gelegt werden. Unternehmen können dadurch granulare Entscheidungen treffen, indem sie, wo immer möglich, die Ressourcen aus dem Pool nutzen und genau die Teile bauen, die sie benötigen, um den Betrieb des Netzwerks zu verbessern.

Es kann sein, dass man mit Hilfe eines Open-Source-Betriebssystems für Netzwerke den Code an ein bestimmtes Datenerfassungssystem anpassen kann; es ist aber auch möglich, Free Range Routing (FRR) direkt aus dem Public Repository zu beziehen. In einem anderen Szenario nutzen Firmen ein kommerzielles Netzwerkbetriebssystem eines Anbieters und erledigen dann bestimmte Dinge in einer eigenen, abgeschlossenen von FRR, um ihr Netzwerk zu optimieren. In beiden Fällen ist die Flexibilität gegeben.

Anzahl der APIs festlegen

Bei der Entscheidung, welche Elemente Firmen auslagern oder selbst betreiben wollen, müssen sie an die APIs zwischen den verschiedenen Komponenten denken. Das zeigt Abbildung 1:

Abbildung 1 zeigt die Komponenten eines disaggregierten Netzwerks. Hier sind vier APIs markiert, die jeweils einen Ansatzpunkt darstellen, an dem Unternehmen eine Komponente auslagern oder selbst betreiben können.

Zum Beispiel könnten Firmen alle Elemente außer der Steuerungsebene auslagern. Das heißt, sie beschäftigen eigene Mitarbeiter, die sich um die Entwicklung von API 1 kümmern. Oder sie kaufen nur die Hardware und entwickeln den Rest selbst mit eigenen Entwicklungsteams für die API 4. Je mehr Firmen inhouse erledigen wollen, desto größer muss das Entwicklungsteam sein.

Es gibt einen zentralen Punkt, der jedoch nicht so offensichtlich ist – weder aus den meisten Diskussionen um die Disaggregation, noch aus dem obigen Diagramm. Wenn Firmen sich entscheiden, welche Elemente sie auslagern möchten und welche nicht, müssen sie darüber nachdenken, für welche API sie programmieren möchten.

Zum Beispiel könnten Unternehmen sich dafür entscheiden, alle Komponenten rund um API 4 selbst zu besitzen und zu betreiben. Dann setzen sie auf einigen Open-Source-Projekten auf und passen den Code entsprechend an ihre geschäftlichen Anforderungen an. Wenn sie jedoch eine API eines Herstellers anpassen wollen (falls das möglich ist), verlieren sie für die Zukunft an Flexibilität bei der Auswahl eines anderen Hardwareanbieters.

Das Gleiche gilt, wenn Firmen die Control Plane selbst entwickeln wollen und für den Rest entweder Open Source oder kommerzielle Software verwenden: Auch dann müssen Sie sich sorgfältig überlegen, für welche API sie schreiben werden. Denn die Entwicklung etwa für die zugrundeliegenden Routing-Informationen von Snaproute unterscheidet sich komplett vom Schreiben von Code auf der Zebra-Schnittstelle. Die API kann einen großen Einfluss darauf haben, inwieweit Firmen in Zukunft noch einen anderen Anbieter mit an Bord holen können oder ein Vendor Lock-in droht.

Mit Hilfe der Disaggregation können Firmen ihr Netzwerk flexibler an ihre Anforderungen anpassen. Aber Sie müssen sich genau überlegen, welche APIs sie wählen, an welchen Stellen im System Flexibilität entscheidend ist und wo sie in Zukunft mit einem einzigen Hersteller als Quelle leben können.

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