Mal wieder etwas technisches: SDN – Softare Defined Networking mausert sich ja zum nächsten Hype – mit welchem Recht auch immer – und wie bei jedem Hype Thema springen die üblichen Verdächtigen zügig auf. Die Sprungrate hat dabei 2013 drastisch zugenommen – ob begründet oder unbegründet sei mal dahin gestellt.

Aufspringen bedeutet dabei ja gerne, dass man die Technologie, die man ohnehin schon im Haus hat etwas erweitert und dann seine eigene Deutung definiert, die einen natürlich zum gefragtesten Anbieter in dem Segment macht.

Nachdem VMWare als der Marktführer im Bereich Virtualisierung hier mit der Nicira Aquise hier früh 2012 den Reigen eröffnet hat lohnt sich ein genauerer Blick auf die Szenarien und Aufgabenstellungen, sowie den Status-Quo:

Ein wichtiger Schritt um aus einer Hype tatsächlich eine interoperable Technologie zu machen, ist die Standardisierung – wie auch immer diese aussieht. Dabei scheint sich die Forschungsarbeit an der Stanford University zum Thema OpenFlow durchzusetzen, da sich in der Open Network Foundation zahlreiche Hersteller zusammen getan haben, um genau diese Technologie zu fördern und daran zu partizipieren. Die Liste liest sich wie das Who-is-Who der Netzwerk Vendoren ausschließlich derer, die meinen eine eigene proprietäre Interpretation von Software Defined Networking zu propagieren. Dabei ist die Entstehung 2008 tatsächlich dem wissenschaftlichen Interesse geschuldet, eine Plattform zu schaffen, auf der neue Netzwerktechnologien auch erforscht und experimentell getestet werden können, ohne gleich komplette Systeme der jeweiligen Kategorie entwickeln zu müssen.

Was geht jetzt aber eigentlich ?

Ich sehe hier vor allen Dingen drei Aspekte:

1. Ist im etablierten Bereich der Virtualisierung in den jeweiligen HA- Cluster- Konfigurationen eine einschlägige Distributed Switching Lösung notwendig – welche eine Packet- Forwarding Engine nach identischen Regeln auf verschiedenen Hosts realisiert. Dabei werden Dienst- Merkmale wie Traffic Separierung oder Dienstgüte – IEEE 802.1q VLANs oder QoS – erhalten, eine zwingende Anforderung ab mittlerer Komplexität. Management Domänen bereiten Entwicklungen wie dem CISCO Nexus 1000v den Boden, welche die Netzwerkkonfiguration aus den Händen der Virtualisierungs- Administratoren zu den Netzwerk- Kollegen übertragen. Gerade VMWare hat mit seiner REST- API an der Stelle den Weg bereitet und zum Beispiel CISCO hat mit seinen Virtual ASA Firewalls oder der Virtual WAAS Appliance einen WAN Accelerator entwickelt, direkt auf Host- Ebene mit zentralem Management entsprechende Datenstöme abfangen und Richtlinien basiert abarbeiten. Der Charme ist, die Komplexität in anspruchsvollen Umgebungen gleich auf dem Host abzuarbeiten und über extrem flache Backbone Strukturen einen hochverfügbaren und performanten Betrieb mit einer gigantischen Skalierbarkeit zu realisieren.

   Alleine das erzeugt natürlich Last auf dem Host und kanibalisiert Server- Ressourcen, welche eigentlich den virtuellen Gästen zur Verfügung stehen sollten.

2. Daraus resultiert in erster Instanz das Offloading auf vergleichsweise intelligente Netzwerkkarten, welche Teile dieser Funktionen wieder in Hardware erledigen oder ein Schritt weiter die Ausleitung auf aktive Komponenten – Switches, welche die Policies gemäß dem virtuellen Switch umsetzen.

   Letzteres ist meiner Wahrnehmung nach nahezu aus den Diskussionen und Umsetzungen verschwunden und wurde zunächst von Hardware basierter Interface- Virtualisierung wie CISCOs UCS mit den VNIC oder HPs Virtual Connect mit Flex Fabric adressiert. Diese Basis von stateless Server Technologien hat nach wie vor extrem hohe Berechtigung in großen Umgebungen mit automatisierten Installations und Failover- Routinen auf unterster Ebene und wird nun durch die Bemühungen reiner Virtualisierungsschichten auf aktiven Komponenten (Switches und Router) abgerundet.

   Interconnect Virtualisierung ermöglicht policy- basiert das priorisierte, sauber getrennte Durchreichen des Datenverkehrs und die virtualisierten Netzwerk- Komponenten arbeiten diesen dann ebenso regelbasiert ab. Dabei erfüllen sie die gleichen Anforderungen welche die vorgelagerten Hypervisor bedienen.Entkoppeln der Funktion von dedizierter Hardware, flexible und kurzfristige Ein- und Aus- Richtung, Hochverfügbarkeit durch Migration virtueller Instanzen, Steuerung bzw. Automatisierung der administrativen Vorgänge auf logischer und/oder Software- Ebene.

3. Warum macht man das alles ? Nunja, weil es tatsächlich gebraucht wird. Neben allen diffusen Cloud Ansätzen und dem Mainstream, welcher seine Ressourcen über öffentliche Internet- Strecken, bestenfalls VPN verschlüsselt aus beliebig großen Rechenzentren einer Amazon und Konsorten holt, setzt sich meiner subjektiven Wahrnehmung nach der anspruchsvolle Unternehmenskunde mit seinem hochgradig differenzierten Wunsch nach einer “shared private Cloud” durch.

   Umgebungen welche zwar geshared Infrastruktur bereit stellen, diese jedoch im Grunde so in sich kapseln, dass der Anwender diese Ressourcen wie seine eigene private Cloud Umgebung nutzen kann. Eine wachsende Zahl mitteständischer Provider bedient genau diesen Markt. VMWare liefert mit dem VMWare Director eine Provider Technologie um genau diese Abstraktion herbei zu führen und mit dem vCloud Connect eine Schnittstelle den Kunden mit dem Provider unter des Kunden Hoheit anzubinden.

   Jetzt denkt sich der aufmerksame Leser, dass genau das nicht im Sinne des Providers sein kann, nämlich die Kontrolle seiner Infrastruktur an einen Dritten zu übergeben. vCloud Director löst das Problem nur für VMWare vSphere. Und Erfahrungsgemäß sind eigentlich immer die Themen um Netzwerk- Ankopplung, Traffic Management und Netzwerk Security genau diejenigen welche die System- Auslagerung zwischen dedizierten Kunden- Landschaften und Mittelstands- Providern extrem verkomplizieren und ggfs. verteuern.

   Genau hier setzt SDN und damit der Hype an. Die effizient bereit gestellten geteilten Server- Ressourcen können jetzt ebenso Regelbasiert angebunden werden. Die Netzwerk- Konstellation in der Kunden- Umgebung beim Provider kann genauso flexibel gestaltet und dynamisch angepasst werden. Das Netzwerk erreicht den selben Grad an Abstraktion wie der Server- Betrieb zuvor.

Damit schließt sich der Kreis. Cloud- Dienste welche sehr eng mit der abnehmenden Seite verzahnt sind und eben nicht mit minimalem Aufwand über das Internet genutzt werden, machen einen erheblichen Anteil im Markt aus. Szenarien wie das Anmieten eines Ausfall- Rechenzentrums rein Kapazitiv bei einem Dienstleister unter Beibehaltung des eigenen qualifizierten Regelbetriebs ebenso wie die Nutzung zweier völlig unabhängig voneinander agierender Provider durch die Kontrolle der eigenen Management- Systeme und so weiter werden denkbar und auch umsetzbar.

Dies setzt einen sehr sauberen Regelbetrieb, klare Richtlinien und auch die Kompetenz voraus solche Umgebungen richtig aus zu steuern – insofern halten sich die mir bekannten Installationen noch in Grenzen. Aber SDN stößt diese Tür auf und es werden Sourcing Strategien möglich die viele Kunden bisher von einer Cloud- Nutzung abgehalten haben. Umgekehrt erlaubt es den Providern ihren Kunden Freiheiten zu gewähren ohne die Kontrolle über die eigenen Kronjuwelen aus der Hand zu geben. Ein Schritt der so bis heute ohne weiteres nicht möglich war.

Kyp.F.