11.03.2015, 09:51 Uhr
SDN ist reif für die Revolution im RZ
Virtualisierte Netze und Software Defined Networking (SDN) existieren nicht mehr nur in Strategiepapieren. Die Technik ist heute praxisreif und wird in den nächsten Monaten und Jahren die Netzwerk- und Rechenzentrenszene kräftig umkrempeln.
Software Defined Networking wird konkret. Zumindest erhält man diesen Eindruck, wenn man sich in der Branche nach dem Stand der Dinge erkundigt. Die Techniken für die Netzwerkvirtualisierung sind so ausgereift, dass erste Projekte umgesetzt werden.
Auch die Hersteller von Netzwerkgeräten und -lösungen haben sich in Stellung gebracht. In diesem Zusammenhang gibt es drei Stossrichtungen: Die erste Gruppe will mit Software die Kontrolle übers Netzwerk gewinnen und verwendet hierfür das OpenFlow-Protokoll, um die Flow-Tabellen in den Switches anzusprechen. Diesen Ansatz verfolgen zum Beispiel HP, Juniper und Brocade. Eine zweite Gruppe konzentriert sich darauf, die virtuellen Workloads dynamisch zu verschieben, und zwar unter Nutzung des Server-Hypervisors und mit Techniken wie Tunneling. Sie interessiert sich also für die Ebene über dem Hypervisor. Hierzu gehören hauptsächlich VMware mit NSX, aber auch Nuage Networks. Einen dritten, bislang einzigartigen Weg schlägt Cisco Systems ein. Hauptmerkmal ist, dass die Application Centric Infrastructure (ACI) einen Teil der Kontrollfunktionen in den Switches und Routern belässt, also Hardware-Komponenten mit einschliesst. Nächste Seite: Kunden fragen nach Problemlösungen
Anwender als treibende Kraft
«Die treibende Kraft hinter SDN waren aber zunächst nicht die Hersteller, sondern spezielle Anwender wie Google und Facebook, die ein gut geöltes Netz für ihre hyperskalierenden Anwendungen benötigten», erklärt Brad Casemore, Analyst beim Marktforschungsunternehmen IDC, gegenüber Computerworld die Hintergründe der Virtualisierungsbemühungen. Mit einer klassischen Netzwerkarchitektur sei dies nicht mehr möglich gewesen. Also habe Google beispielsweise eigene SDN-Switches programmiert, um seine Rechenzentren besser zu verbinden.
Durch den Siegeszug von Cloud Computing kommen nun immer häufiger auch reguläre Firmen an eine Komplexitätsgrenze und müssen sich fragen, wie sie ihr Netz optimieren könnten. «Es sind zwar nicht die exakt gleichen Probleme und Herausforderungen wie bei Google und Facebook, denen Unternehmen sich stellen müssen, aber sie sind doch vergleichbar», weiss Casemore. «Sie sagen sich: Ich muss meinem Netzwerk eine bessere Architektur verpassen und herausfinden, wie ich es programmierbar mache.»
Kunden fragen nicht direkt nach SDN
Ähnliche Erfahrungen hat Cisco mit seiner Kundschaft in der Schweiz gemacht, wie Rolf Schärer, Consulting Systems Engineer bei Cisco Schweiz, gegenüber Computerworld bestätigt. «Die Kunden treten mit konkreten Problemstellungen an uns heran. Kaum jemand ruft uns dagegen an und interessiert sich für SDN per se», sagt er. Adressiert werde die Komplexität heutiger Umgebungen, die man habe, etwa eine Batterie von Firewalls, die man nicht mehr administrieren könne. «Daneben hat sich auch die Interessengruppe vergrössert. Auf uns kommen nicht mehr nur Netzwerkspezialisten zu, sondern auch die Manager der Firmen», berichtet Schärer. Sein Kollege Pascal Tscharner, Manager Enterprise Networks bei Cisco Schweiz, bringt noch einen weiteren Aspekt zur Sprache: «Den Reifegrad sehen wir auch an der Zertifizierung unserer Partner. Die Nachfrage ist hier stark gestiegen», gibt er zu bedenken. «Das ist für uns ein sehr gutes Signal. Denn unsere Partner würden nicht in die Ausbildung neuer Kompetenzen im Bereich ACI investieren, wenn sie sich nichts von dieser Investition erhofften», so Tscharner. Auch Johannes Weingart, Principal Solutions Architect bei Brocade, stellt gegenüber Computerworld fest, dass SDN im letzten Jahr reifer geworden ist – eine Entwicklung, die sich 2015 fortsetzen werde. «Bislang hat man sich zu sehr auf die einzelnen technischen Aspekte fokussiert. Nun beginnt man sich zu fragen, was man mit SDN bezwecken kann», sagt Weingart. Er spricht deshalb auch lieber von «SDx» als von SDN. «Mittlerweile geht es um Software Defined IT, Software Defined Compute und Software Defined Storage», führt er aus. Mit Kunden spreche er deshalb immer häufiger über Workflows und wie diese automatisiert werden könnten, und zwar sowohl im Netzwerk als auch in der ganzen IT. Lesen Sie auf der nächsten Seite: Provider als Early Adopter
Provider als Early Adopter
Besondere Treiber der SDN-Umsetzung sind derzeit Serviceprovider wie zum Beispiel Rechenzentrenbetreiber. Für sie ist es natürlich geschäftsentscheidend, ihre Infrastruktur schnell auf die Anforderungen ihrer Kunden anpassen zu können. Eine Studie von Packet Design bei Providern während der SDN/MPLS International Conference in Washington hat ergeben, dass mittlerweile 53 Prozent SDN produktiv einsetzen. Ein Jahr zuvor lag diese Quote noch bei 19 Prozent. Hauptargument für die Einführung von SDN ist die erhöhte Agilität, die dazu führt, dass schneller auf Geschäftsanforderungen reagiert werden kann.
Die Serviceprovider sind aber auch besorgt, etwa darüber, dass es zu wenig Industriestandards gibt. Bereits 56 Prozent sind in der jüngsten Umfrage von Packet Design dieser Ansicht – gegenüber 26 Prozent ein Jahr zuvor. Dagegen hat heuer ein etwas geringerer Teil der Befragten, nämlich 53 gegenüber 57 Prozent, das Gefühl, dass SDN-Techniken und -Implementierungen zu komplex sind. Schliesslich haben 70 Prozent Bedenken, dass sie zu wenig Erfahrung und Kenntnisse in Sachen SDN haben.
Die Folgen für Netzwerkadmins
Eines scheint klar zu sein: SDN, in welcher Spielart auch immer, wird den Betrieb heutiger Netzwerke stark verändern, was sich auch auf die Netzwerkadministratoren auswirkt. Laufen sie Gefahr, marginalisiert zu werden oder gar ihren Job zu verlieren, da nun die Applikationsprogrammierer und das Server-Virtualisierungs-Team das Szepter in die Hand nehmen? Für IDC hat sich Brad Casemore diese Frage gestellt und zusammen mit Rohit Mehra die Erkenntnisse in der Studie «SDN Survey» zusammengetragen. Darin kommen sie zum Schluss, dass die einzelnen Silos bereits aufgebrochen sind. Auf die Frage, wer für die Entscheidungen über die Netzwerkinfrastruktur im Rechenzentrum des Unternehmens verantwortlich ist, nannten nur 10 Prozent das Netzwerk-Team als allein verantwortlich. In den meisten Fällen arbeitet das Netzwerk-Team mit anderen IT-Divisionen zusammen, so mit dem Server-Virtualisierungs-Team (22,7 Prozent), mit den IT-Architekten (30,1 Prozent) oder mit beiden zusammen (13,5 Prozent). Entsprechend viele Unternehmen haben denn auch schon die IT-Abteilung als Ganzes restrukturiert oder planen eine derartige Umorganisation (71,6 Prozent). «Jene Netzwerkprofis, die aus ihren Silos ausbrechen, die Veränderungen annehmen und neue Fähigkeiten in Gebieten wie Automation und Programmierbarkeit erwerben, werden belohnt», so das Fazit der IDC-Studie. Und ja, Netzwerkprofis haben laut den Auguren eine Zukunft in einem von SDN geprägten Umfeld. Aber diese werde anders aussehen als in der Vergangenheit. Rolf Schärer sieht als früherer Netzwerkadministrator eine spannende Zukunft für seine Zunft: «Wenn es für einen Netzwerkadmin spannend ist, ein Netzwerk aufzubauen und die Architektur zu definieren, dann ist die neue Zeit für ihn interessant. Denn er hat letztlich für solche Aufgaben mehr Zeit und muss sich nicht mehr um tägliche Routineaufgaben kümmern, weil ihm diese nun abgenommen werden.» Nächste Seite: 2014 - die wichtigsten SDN-Ereignisse
2014: die wichtigsten SDN-Ereignisse
Januar: Cisco erweitert seine SDN-Offensive mit der Lancierung von ACI Enterprise Module, das die Reichweite des ACI-Controllers auf Campus-Netze und WAN ausdehnt. Februar: OpenDaylight meldet, dass die Version «Hydrogen» zur Verfügung steht. März: Brocade unterstützt als eine der ersten Firmen OpenFlow 1.3 und Dell stellt einen Fabric-Switch samt SDN-Controller vor, der OpenStack-Clouds
automatisieren können soll. Im gleichen Monat lanciert Cisco Chassiskonfigurationen für die eigene Switch-Reihe Nexus 9000, also die Hardware-Unterlage
für ACI. April: Dell beginnt seine Zusammenarbeit mit den SDN-Spezialisten Big Switch Networks und Cumulus Networks. Gleichzeitig setzt Juniper auf OpenDaylight und Cisco lanciert das Policy-Protokoll OpFlex. Mai: HP verstärkt sein finanzielles Engagement bei OpenDaylight. Juni: HP doppelt mit einem SDN-Switch nach. September: HP öffnet einen SDN App Store, Brocade veröffentlicht als wohl erster Hersteller einen OpenDaylight-basierten SDN-Controller. Oktober: Auch Cisco schliesst sich dem Open Compute Project an. November: Die OpenDaylight-Alternative ONOS wird lanciert. Dezember: Jupiter bringt eine Version des Netzwerkbetriebssystems Junos für Switches der Open Compute Platform
auf den Markt. Nächste Seite: SDN-Glossar
automatisieren können soll. Im gleichen Monat lanciert Cisco Chassiskonfigurationen für die eigene Switch-Reihe Nexus 9000, also die Hardware-Unterlage
für ACI. April: Dell beginnt seine Zusammenarbeit mit den SDN-Spezialisten Big Switch Networks und Cumulus Networks. Gleichzeitig setzt Juniper auf OpenDaylight und Cisco lanciert das Policy-Protokoll OpFlex. Mai: HP verstärkt sein finanzielles Engagement bei OpenDaylight. Juni: HP doppelt mit einem SDN-Switch nach. September: HP öffnet einen SDN App Store, Brocade veröffentlicht als wohl erster Hersteller einen OpenDaylight-basierten SDN-Controller. Oktober: Auch Cisco schliesst sich dem Open Compute Project an. November: Die OpenDaylight-Alternative ONOS wird lanciert. Dezember: Jupiter bringt eine Version des Netzwerkbetriebssystems Junos für Switches der Open Compute Platform
auf den Markt. Nächste Seite: SDN-Glossar
SDN-Glossar
OpenFlow: Einer der Grundpfeiler von SDN ist das Kommunikationsprotokoll OpenFlow. Es greift auf die Netzwerk-Hardware zu und übergibt dieser Datenpakete zwecks Weiterleitung. «OpenFlow ist eine Schnittstellendefinition und kein Controller an sich, also nur ein Verfahren, wie man ein Paket weiterleitet», erklärt Johannes Weingart von Brocade. Praktisch alle Netzwerkanbieter haben OpenFlow-kompatible Switches und Router im Angebot. OpenDaylight ist ein Open-Source-Rahmenwerk für SDN. Wichtigstes Element ist der OpenDaylight-Controller, von dem beispielsweise Brocade mit Vyatta eine kommerzielle Kopie im Angebot hat. Auch das OpenDaylight-Projekt wird von allen Netzwerkgrössen getragen. ACI (Application Centric Infrastructure) ist Ciscos Spielart von SDN, die Hardware-Komponenten und spezielle Asic-Chips mit einschliesst. Opflex gilt als Ciscos Antwort auf OpenFlow und bezeichnet ein offenes Policy-Protokoll. Gegenüber Computerworld erklärt Ciscos Chief Architect und CTO David Ward den Unterschied wie folgt: «OpenFlow ist eine imperative Sprache, Opflex eine deklarative Sprache.» Ward illustriert das anhand eines Beispiels: «Nehmen wir an, wir sitzen zusammen im Auto, und Sie wollen mir sagen, dass ich nach rechts abbiegen soll. Dann können sie mir mitteilen, dass ich leicht das Bremspedal drücken und das Lenkrad zunächst um 2, dann um 3 und 5 Grad nach rechts drehen, den rechten Blinker setzen soll und so weiter. Dies sind alles imperative Aktionen, die ich ausführen muss. So funktioniert OpenFlow. Eine deklarative Sprache funktioniert dagegen so: Sie sitzen neben mir im Auto und sagen mir einfach, bieg rechts ab. Das ist Opflex.» Open Compute Project ist eine Initiative, bei der Designs von Rechenzentrums-Hardware ausgetauscht werden. Das Projekt wurde ursprünglich von Facebook initiiert. Mittlerweile beteiligen sich alle grossen Netzwerkanbieter daran. ONOS (Open Network Operating System) ist wohl eines der jüngsten SDN-Projekte und stellt einen Gegenentwurf zu OpenDaylight dar. Letzteres wird nach Meinung der Initianten zu sehr von Herstellern vorangetrieben. ONOS wurde von der Non-Profit-Organisation ON.Lab lanciert, die auf die Unterstützung von SDN-Pionieren an den kalifornischen Unis Stanford und UC Berkeley zählen kann.