Funktionsweise und Nutzen von SDN

SDN ist derzeit in aller Munde. Wir zeigen, wie sich der Begriff eingrenzen lässt und wo die Schnittmengen mit ähnlichen Technologie liegen.

Software-defined Networking (SDN) erhält in letzter Zeit viel Aufmerksamkeit. Der Wirbel wird vor allem von den...

Herstellern verursacht. Sie sehen eine Gelegenheit, den Netzwerk-Markt neu zu ordnen, der sich seit einigen Jahrzehnten fest in Ciscos Griff befindet.

Die Fragen für Data-Storage-Profis sind: Was genau ist ein Software-definiertes Netzwerk und warum sollen oder wollen Sie es einsetzen?

Viele Experten behaupten, die einzig richtige Definition für SDN vorzuweisen. Allerdings beseitigen diese Definitionen jegliche Klarheit. Wir hören, dass Software-defined Networking die Netzwerk-Kontroll-Ebene von der Daten-Schicht separiert und die Kontroll-Logik des Netzwerks aus den Routern oder Switches nimmt. SDN legt diese in zentralisierte Server. Deswegen lassen sich Entscheidungen bezüglich der Datenweiterleitungen ganzheitlich sehen und verteilen. Physikalische Ports und Pfade zwischen verbundenen Systemen müssen nicht mehr ausgewertet werden.

Warum der ganze Aufwand? Einige Hersteller sind der Meinung, dass Netzwerk-Management heutzutage zu aufwendig und ineffizient ist. Für die Verwaltung von hunderten oder tausenden Netzwerkgeräten würden eine Menge Handarbeit, Programmierung und Administration notwendig sein. Wie bei Storage, haben Netzwerk-Hersteller nur ein Minimum an Standard-basierter Interoperabilität im Angebot. Darauf sitzt jede Menge proprietäre Technologie, die Kunden entsprechend binden sollen. Es tauchen dieselben Phrasen auf, die man auch von Server- und Storage-Virtualisierung kennt. Verfechter von SDN abstrahieren „ausgewiesene“ Funktionalitäten von der Hardware (was immer mehr der Regel entspricht) und zentralisieren diese Systemfunktionalität auf einem Server. Das würde in Form eines Software-Controller geschehen, der die Zuweisung von Netzwerk-Diensten an Applikationsdaten effizienter erledigt.

Prinzipiell klingt das fantastisch. Durch eine derartige Trennung ist vielleicht Netzwerk-Traffic direkt von Server zu Server ohne Umwege durch die Kernkomponenten des Netzwerks möglich. Das würde definitiv die Bandbreite schonen. Auch hinzufügen, verschieben und ändern könnte man zentralisierter und effizienter abhandeln, schenkt man einigen Fürsprechern Glauben.

Der eigentliche Punkt ist allerdings, aufkeimende Probleme mit Server-Virtualisierung zu adressieren: Die Unfähigkeit, Netzwerke so anzupassen, das der Traffic von einigen virtualisierten Gast-Maschinen auf einem virtuellem Host angefragt werden können. Traditionelle Netzwerke sind nicht für sprunghafte Workload-Konfigurationen geschaffen, sagen die Fürsprecher. Die Bereitstellung von Netzwerk-Ressourcen kann also hinter den virtuellen Server-Instantiierungen einige Wochen hinterher hängen. SDN-Evangelisten argumentieren, dass man „Netzwerk-Engpässe“ auf dem Weg in die neue Welt der virtuellen Server und der Cloud eliminieren muss.

Verschwommene Sichtweise hinsichtlich SDN

Den Wert von Software-defined Networking mit den sowieso fragwürdigen Inhalten von Server-Virtualisierung (führende Analysten sagen, dass die im Jahre 2012 Server-Hypervisoren lediglich auf 17 bis 20 Prozent der weltweit im Betrieb befindlichen Server eingesetzt wurden) und der Cloud (man hat weit weniger darauf gesetzt, als das von einigen vorausgesagt wurde) zusammenzufassen, ist mühsam.

VMware wird die 1,2 Milliarden US-Dollar wahrscheinlich nicht ausgleichen können, die man in die Akquise von SDN-Pionier Nicira letztes Jahr gesteckt hat. Dieser Kauf hat allein schon den SDN-Wahnsinn angefacht und für die Kooptation und Neu-Kontextualisierung gesorgt, wie Hersteller SDN definieren.

Die daraus resultierende Verwirrung könnte die Einführung von SDN limitieren. Ich glaube nicht wirklich daran, dass sich Software-defined Networking gegenüber der herkömmlichen Ersetzen- und Aufrüsten-Methode auszahlt. Cisco ermutigt anscheinend seine an SDN interessierten Kunden, die Sache etwas langsamer anzugehen und einen weniger zerreißenden, mehr evolutionären Pfad hinsichtlich dieses Modells einzuschlagen. Cisco versucht SDN einen Schritt voraus zu sein und verbessert deswegen die Management-Möglichkeiten in seinen Produkten. Hier sind einfacherer Zugriff und zusätzliche Verwaltungs-Möglichkeiten mithilfe von offenen Programmierschnittstellen für Applikationen gemeint.

Ob man nun mit SDN liebäugelt oder komplett darauf umsteigt, spiegelt derzeit das Vor und Zurück zwischen den Herstellern und Ihren Sprachrohren in der Analysten-Community, Fachpresse und Blogosphäre wider. Konkurrierende Bündnisse bilden sich und diese wollen so viele Anhänger wie möglich rekrutieren.

Ist es einen Gedanken wert, Quality-of-Service-Manager, Load Balancer, Identitäts-Management, Antivirus-, Antispam-, Intrusion-Detection-Funktionalitäten, intelligente Stapelverarbeitung, Pufferung und andere Funktionen aus den vorintegrierten Switch- oder Router-Plattformen zu nehmen? Ist es kostengünstiger, Geräte ohne diese Funktionen zu kaufen und diese stattdessen auf einen zentralisierten Server zu packen? Oder transferieren wir ganz einfach unsere Netzwerk-Kontrolle (und das entsprechende Budget) in Richtung eines anderen und anspruchsvolleren Herren und Meister?

Parallelen zu Virtualisierung

Wir sehen einige abschreckende Parallelen zwischen SDN und Server-Virtualisierung. Auch dort haben sich zum Beispiel bereits Probleme gezeigt, die aufgrund der konkurrierenden Server-Hypervisoren aufgetaucht sind. Möglicherweise treten Herausforderungen auf, wenn die proprietären Stacks die Infrakstruktur für Cloud-Dienste zur Verfügung stellen. An vielen Stellen haben wir uns einen Schritt zurück bewegt, so dass es sich mit der Zeit vor Erscheinen von Samba vergleichen lässt. Fragte man damals Microsoft, wie ein gemeinsames Nutzen der Daten mit Sun-Microsystems-Plattformen möglich sei, bekam man als Antwort: „Das ist einfach. Werfen Sie einfach die komplette Sun-Ausrüstung raus.“

Genauer gesagt haben Analysten hinsichtlich Server-Virtualisierung im Jahre 2005 gemutmaßt, dass sich die Investitionsausgaben für virtuelle Server im Jahre 2009 egalisiert haben. Danach würden Firmen massiv im Hinblick auf Capex und Opex Kosten einsparen. Im Jahre 2012 haben selbst Erstanwender von Server-Hypervisoren nicht unerheblich Capex-Euro ausgegeben, um die Plattformen betriebsfähig zu halten. Wird SDN tatsächlich Kosten reduzieren und gleichzeitig den Datendurchsatz oder die Effizienz der Kapazitäten verbessern? Oder sind die Vorteile so gering, dass man sich den ganzen Aufwand besser sparen sollte? Zum Glück scheinen sich mehr und mehr Firmen genau diese Fragen zu stellen.

Den besten Rat habe ich bisher von der Open Networking User Group erhalten. Dort ist man der Ansicht, dass die behaupteten Capex-Einsparungen irrelevant sind. Netzwerk-Ausrüstung kostet nämlich gar nicht so viel. Inkrementeller Einsatz, um die Auswirkungen der Technologie hinsichtlich momentaner Problemzonen im Netzwerk zu testen, ist legitim. Somit können Sie in den SDN-Bereich schnuppern.

Artikel wurde zuletzt im November 2013 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Software Defined Networking (SDN)

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close