Checkliste: Diese 14 Fragen sollten Sie SDN-Anbietern vor dem Kauf stellen

Diese 14 Fragen sollte ein Netzwerk-Administrator dem Anbieter stellen, wenn er den Einsatz von SDN (Software-defined Networking) in Betracht zieht.

Bei SDN (Software-defined Networking) handelt es sich um eine neue Technologie, die sich für eine ganze Reihe von möglichen Anwendungsfällen eignet. Aus diesem Grund ist es eine Herausforderung, sich für die richtige SDN-Suite zu entscheiden.

Zunächst müssen Sie als Käufer evaluieren, was die einzelnen SDN-Anbieter im Portfolio haben. Dies kann sich ziemlich unterscheiden. Einige SDN-Hersteller gehen recht traditionell an das Thema Software-defined Networking heran. Sie trennen Daten- und Kontroll-Ebene vom physikalischen Netzwerk und setzen für die Steuerung der Übertragungswege auf einen zentralisierten Controller. Andere bieten Software-Overlays mithilfe von Hypervisoren oder virtuellen Switches an und dirigieren somit das Netzwerk. Die Nächsten setzen wiederum gar nicht auf Software-defined Networking. Allerdings preisen sie virtuelle Appliances an, die eine Rolle bei der Programmierbarkeit der Netzwerke spielen könnten.

All diese Technologien helfen Ihnen dabei, das Netzwerk in Richtung Software-defined Networking umzustellen. Allerdings müssen Sie sich vom Anbieter die jeweilige SDN-Lösung detailliert beschreiben lassen. Die entsprechenden Strategien sollten mit Ihrer existierenden Architektur kooperieren und natürlich die Ansprüche des Unternehmens unterstützen und zufriedenstellen.

Im Anschluss finden Sie 14 Fragen, die Sie einem SDN-Anbieter vor einer Investition stellen sollten.

1. Mit welchen Anbietern besteht eine Partnerschaft? Eine ganzheitliche SDN-Produkt-Suite zu erschaffen, die Layer 1 bis 7 abdeckt, ist eine Mammut-Aufgabe. Aus diesem Grund bieten viele SDN-Anbieter lediglich ein oder zwei Schlüssel-Elemente aus dem SDN-Stack an. Deswegen müssen Sie evaluieren, ob das jeweilige Angebot in Ihre Umgebung passt. Dies hängt wiederum davon ab, welche Zusatzleistungen der Anbieter um sein Produkt entwickelt hat. Das gilt vor allen Dingen bei der Suche nach Controller-Produkten.

2. Welche SDN-Applikationen laufen auf Ihrer Plattform? Diverse Anbieter stellen schlüsselfertige SDN-Produkte zur Verfügung, die ausgereifte Applikationen enthalten. Damit können Sie das Netzwerk mit Ihren Business-Prozessen verbinden oder ein spezielles Problem adressieren. Andere wiederum stellen Toolsets zur Verfügung, mit denen Sie spezielle Logiken nach Ihrem Gusto maßschneidern können. Die beiden Ansätze haben verschiedene Zielgruppen im Auge. Vielleicht suchen Sie nach einer Lösung für ein bestimmtes Problem und setzen deswegen auf eine vom Hersteller entwickelte und unterstützte SDN-Applikation. Dann müssen Sie aber genau wissen, welche Applikationen heute laufen und was die zukünftigen Pläne des Anbieters sind. Möglicherweise suchen Sie nach einer Lösung, die das Netzwerk in Ihre Welt der Orchestrierung und DevOps bringt. Fragen Sie in diesem Fall den Anbieter, wie Sie Ihre Applikationen entwickeln sollen. Befinden Sie sich in dieser Situation, ist eine Bitte, etwas Zeit mit dem Produktentwickler-Team des Anbieters verbringen zu dürfen, nicht unzumutbar oder unverschämt.

3. Gibt es Anwendungsfälle für das Produkt? Bei Software-defined Networking handelt es sich nicht um eine bewährte und „erwachsene“ Netzwerk-Technologie. Den leeren Raum füllen derzeit Startups, frische Ideen und entstehende Paradigmen. Sie möchten natürlich verstehen, ob das jeweilige Produkt auch Ihren Ansprüchen genügt. Fragen Sie den Anbieter deswegen nach White Papern und Kunden-Referenzen. Nur so sehen Sie, wie die entsprechende Technologie spezielle Herausforderungen meistert. Wenn Sie nicht zum Kreis von Test-Kandidaten gehören, der bei der Entwicklung des Produkts hilft, wollen Sie auf keinen Fall das Versuchskaninchen sein.

4. Wenn sich meine Netzwerk-Hardware nicht programmieren lässt, wie kann Ihr Produkt mein Unternehmen unterstützen? Das zentrale Programmieren des Netzwerks ist natürlich einer der Haupt-Gedanken bei SDN. Allerdings ist nicht jede Hardware kompatibel zu OpenFlow oder bietet ein API (Application Programming Interface) an. Der Anbieter sollte Ihnen in diesem Fall erklären, wie sich sein Produkt mit der Hardware unterhalten kann. Für die meisten Hersteller sollte das kein Problem sein. Es gibt häufig Konfigurations-Methoden via SNMP oder die universelle Kommandozeile (Command Line Interface). Diese Technologien sind schon eine gefühlte Ewigkeit im Einsatz. Lassen Sie sich hier in Details einweihen, da man bezüglich SDN-Technologie häufig von einem Einsatz mit OpenFlow ausgeht.

5. Wie integriert sich Ihr Produkt in mein vorhandenes Netzwerk? Der jeweilige Anbieter sollte über eine Referenz-Architektur verfügen. Damit kann er illustrieren, wie sich sein SDN-Produkt in Ihr bestehendes Netzwerk integrieren lässt. Hybrid Switches und „SDN Islands“, die durch den SDN-Gateway laufen und als Bridge zu und von Ihrer alten Infrastruktur agieren, sind häufige Ansätze.

6. Wie sieht es mit Ihrem Lizenz-Modell aus? Bei Software-defined Networking geht es eigentlich um die reine Technologie. In der Realität ist es aber so, dass die Anbieter die Preise des Produkts anhand von Funktionen staffeln. Nun kommt es natürlich auf den einzelnen Anwendungsfall an. Wie der Anbieter seine Technologie lizenziert, könnte sich aber nachhaltig auf Ihren Geldbeutel auswirken. Erkundigen Sie sich deswegen sehr genau, wie der Anbieter seine Lizenzierung handhabt und was das für Ihr speziell geplantes Design bedeutet. Hängen die Lizenzen von den Funktionalitäten ab oder von den eingesetzten Geräten? Möglich sind auch Abhängigkeiten von Traffic- oder Transkations-Volumen. Dies ist natürlich entscheidend, wenn Sie Investitionskosten (Capex) mit den laufenden Kosten (Opex) vergleichen. Ein Lizenz-Modell, das während der Einkaufs-Phase gar nicht so teuer ausgesehen hat, könnte im Laufe der Jahre sehr kostspielig werden.

7. Empfehlen Sie In-Band- oder Out-of-Band-Management (OOB) zwischen Controller und Netzwerk-Hardware? Beim Aufbau eines Software-defined Netzwerks sind sowohl Southbound-Kommunikation zwischen Netzwerk-Geräten und SDN-Controller als auch Northbound-Kommunikation zwischen Applikationen und Controller entscheidende Funktionalitäten. Verschiedene Anbieter geben hier unterschiedliche Empfehlungen im Hinblick auf In-Band oder Out-of-Band aus. Gründe lassen sich immer finden, die jeweilige Betrachtungsweise zu rechtfertigen. In-Band wird für die Fähigkeit angepriesen, dass es Pfad-Ausfälle (Path Failure) im Netzwerk-Geflecht zwischen Gerät und Controller erkennen kann. Somit werden Link-Ausfälle ans Tageslicht gebracht, die ansonsten möglicherweise unentdeckt bleiben. OOB sagt man nach, dass damit die Latenz in Bezug auf die Kommunikation mit der Steuerebene garantiert ist und möglicherweise die Netzwerk-Sicherheit erhöht wird.

8. Welche OpenFlow-Operationen kann Ihr Switch innerhalb der Hardware ausführen? OpenFlow ist der Liebling der SDN-Bewegung, weil damit eine Hersteller-unabhängige Technologie zur Verfügung steht. Sie beschreibt, wie ein Netzwerk-Switch den Datenfluss behandeln sollte. Viele Anbieter haben Kompatibilität zu OpenFlow für eine oder mehrere Produktlinien ihrer Hardware-Switche angekündigt. Nun könnte man denken, dass OpenFlow ein idealer Gleichmacher für Switche ist. In der Realität haben aber nicht wenige Hersteller Probleme, die OpenFlow-Operationen in Ihre bestehende Firmware zu bekommen. Viele Anbieter haben deswegen maßgeschneiderte ASICs (Application-specific Integrated Circuits) für ihre Switches entwickelt. Diese kümmern sich dann um mehrere Arten von Forwarding-, Priorisierungs- und Verkapselungs-Operationen. Das erlaubt wiederum eine Skalierung des Netzwerks. ASICs sind langen Entwicklungs-Zyklen ausgesetzt. Allerdings wurden die meisten schon entwickelt, bevor sich OpenFlow mit dem heutigen Grad an Berühmtheit schmücken konnte.

OpenFlow könnte ein entscheidendes Kriterium sein für Ihren Evaluierungs-Prozess. In diesem Fall muss Ihnen der Anbieter sehr detailliert darlegen, mit welchen OpenFlow-Operationen seine Hardware umgehen kann und um wie viele Flows pro Sekunde es sich handelt. Planen Sie auch entsprechende Maßnahmen ein, damit Sie die Behauptungen nachprüfen können.

9. Veröffentlichen Sie Ihre APIs? Netzwerk-Geräte verfügen über APIs. Das gilt auch für Controller. Die Frage ist allerdings, ob diese APIs öffentlich zugänglich und dokumentiert sind. Ist das nicht der Fall, wird der Anbieter diese wenigstens für Sie offen legen? Sollten Sie eigene Applikationen auf Basis der Hersteller-Plattform entwickeln wollen, ist dies ein sehr wichtiger Punkt.

10. Welche Programmiersprachen unterstützen die APIs? Die Anbieter müssen sich entscheiden, welche Programmiersprachen sie unterstützen. Java und Python sind sehr beliebt, andere weniger. Sie sollten allerdings Kenntnisse über die unterstützten Programmiersprachen haben, damit Sie diese mit dem Wissen im Unternehmen abgleichen können. Im Idealfall bürdet das gewählte Produkt dem Entwickler-Team keine zusätzlichen Belastungen auf.

11. Welche Fähigkeiten müssen sich unsere Administratoren aneignen, um das Produkt einsetzen zu können? Traditionelle Netzwerk-Techniker und -Administratoren haben ihre Fähigkeiten im Laufe der Jahre immer weiter verbessert. Individuelle Geräte wurden mithilfe von CLI (Common Language Infrastructure) konfiguriert. Software-defined Networking meidet diese Common Language Infrastructure und bietet programmatische Mittel für die Konfiguration des Netzwerks. Der Wunsch-Anbieter sollte Ihnen deswegen genau erklären, welche Auswirkungen sein spezielles Produkt auf die existierenden Administrations-Policies haben. Sehr wahrscheinlich müssen sich Ihre Mitarbeiter neue Kenntnisse aneignen oder zumindest die Prozesse aktualisieren, um mit dem kommenden SDN umgehen zu können.

12. Wie werden Sie das Produkt unterstützen? Software-defined Networking bringt Anbieter in keine einfache Situation, wenn es um die Unterstützung des Unternehmens-Netzwerks geht. Kunden sind es gewohnt, Support für Bug- und Problem-Lösungen von Anbietern zu erhalten. Bei SDN haben Administratoren aber so viel Spielraum, dass sie sich leicht selbst in den Fuß schießen können. Das liegt allerdings außerhalb der Anbieter-Kontrolle. Kunden müssen daher ganz genau verstehen, in welcher Form Unterstützung angeboten wird. Das gilt vor allen Dingen für Code-Teile, die im eigenen Haus erstellt wurden.

13. Inwieweit sperrt mich Ihr Produkt nicht in einen goldenen Käfig? Manche IT-Abteilungen fühlen sich sicherlich wohl, alle Geräte von einem Anbieter oder Hersteller zu beziehen. Sollte etwas schief gehen, können Sie in diesem Fall mit dem Finger auf nur eine Instanz zeigen. Die meisten IT-Abteilungen halten sich allerdings die Optionen lieber so offen wie möglich. Das gilt im Besonderen für Netzwerke. Diese Branche hat viele Hebel in Bewegung gesetzt, um interoperable Standards zu entwickeln und diese auch beizubehalten. Aus diesem Grund konnten sich Kunden immer zwischen verschiedenen Geräte-Herstellern entscheiden. Schließlich war ihnen bewusst, dass man sich nicht an einen Anbieter bindet.

SDN ist noch so frisch, dass es diese interoperablen Standards bisher nicht gibt. Auch wenn die verschiedenen Anbieter mit ihren Produkten ähnlich an die Problemstellungen herangehen, empfehlen die meisten ein komplettes Lösungs-Portfolio. Anders gesagt funktioniert ein SDN-Controller von Hersteller X am besten mit den SDN-Switches von Hersteller X. Der Käufer muss sich dieser Situation bewusst sein. Sonst läuft er Gefahr, sich von einem Anbieter komplett abhängig zu machen.

14. Wie sehen Ihre Pläne aus, das OpenDaylight-Projekt der Linux Foundation zu unterstützen? Die fortschreitende Entwicklung von OpenDaylight (ODL) könnte eine Basis für die Interoperabilität von allen SDN-Produkten dieser Branche ermöglichen. OpenDaylight befindet sich allerdings derzeit noch in den Kinderschuhen. Es ist aber durchaus vorstellbar, dass die Hersteller OpenDaylight als die richtige Basis für ihre SDN-Angebote sehen. Sollte dieser Fall eintreffen, möchten Sie als Kunde natürlich ODL-konforme SDN-Produkte Ihr Eigen nennen. Das würde außerdem den Weg für Drittanbieter ebnen. Innovative Netzwerk-Produkte könnten die SDN-Fähigkeiten verbessern und dabei ist die Abhängigkeit vom primären Controller in Zukunft nicht gegeben. Es ist aber noch ein bisschen zu früh, um auf das Feature „konform mit OpenDaylight“ zu bestehen, weil es eben noch keine Bedeutung hat. Sie sollten dieses Thema allerdings nicht aus den Augen verlieren.

Erfahren Sie mehr über LAN-Design und Netzwerkbetrieb

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close