Virtuelles RZ mit Software-Defined Networking
Netzwerk ohne Grenzen
Software-Defined Networking und Software-Defined Datacenter beschäftigen derzeit sowohl Netzwerk-Architekten als auch -Administratoren. Allerdings sendet die Industrie recht widersprüchliche Signale, was die Umsetzung dieses Konzepts angeht. Aus Anwendersicht stellt sich die Frage: Kann ich heute schon von dieser neuen Art der Netzwerkinfrastruktur profitieren?Software-Defined Networking (SDN) beschreibt ein durch Software gesteuertes Netzwerk. Wozu? In dem Moment, in dem es gelingt, die wesentlichen Steuerungsfunktionen und -kommunikation von der Physik zu abstrahieren und rein über Software-Controller abzubilden, ergeben sich völlig neue Gestaltungsmöglichkeiten für Aufbau und Betrieb eines dann virtuellen Rechenzentrums, eines Software-Defined Datacenters (SDDC). Jede zentrale Komponente des Netzwerks - Server, Speicher, Switches/Router und Security - steht zu jedem Zeitpunkt genau in der Menge und Weise zur Verfügung, wie der Anwender sie gerade braucht. Herausforderungen durch Lastspitzen gehören damit ebenso der Vergangenheit an wie die Anschaffung teurer und nur teilweise ausgelasteter Hardwareressourcen. Letztlich ist dies Cloud Computing in Reinkultur. Vor diesem Hintergrund haben Analysten wie Richard Fichera von Forrester formuliert, dass SDDC eine Produktkategorie zu werden verspricht, gleichzeitig aber auch einen Trend markiert. Je tiefer die Schicht im OSI-Modell, an der der Controller ansetzt, desto besser. Denn dann beeinträchtigen Operationen auf den höheren Layern die Gesamtleistung des Systems nicht und verursachen möglichst wenige Schnittstellenprobleme. Ein in der Praxis erprobter Ort ist die Grenze zwischen Layer 2 und Layer 3. Die Hardwaresteuerung der Switches wird virtualisiert, indem man die Control Plane und Data Plane trennt. Die darüber liegenden Schichten interpretieren diese virtualisierte Schicht als komplette Hardwarestruktur, die real nur auf der Softwareebene existiert. SDN ist Virtualisierung auf Netzwerkebene Letztlich führt dies das Thema Virtualisierung fort, wie es bereits seit rund 50 Jahren bei Servern oder Storage erprobt ist und sich in den letzten fünf Jahren zum Beispiel bei Servern durch den intensiven Einsatz von Hypervisoren wie VMware Vsphere, Windows Hyper-V, Citrix Xen und zuletzt zunehmend KVM im Rechenzentrum durchgesetzt hat. Das entscheidend Neue ist, diesen Gedanken auch auf die anderen Komponenten eines Rechenzentrums jenseits von Servern und Storage auszudehnen. Nur dann lässt sich die volle Flexibilität und Skalierbarkeit eines SDDCs nutzen. Hersteller von Netzwerkhardware wie Cisco, Juniper und andere entfalten gerade massive Aktivitäten in diese Richtung. Aber auch klassische Hardwareanbieter und Meinungsführer der Virtualisierungstechnik wollen ihren Anteil in diesem Markt. An einer aus Anwendersicht sinnvollen Standardisierung von Schnittstellen und Protokollen arbeiten die Beteiligten zwar, noch aber versucht jeder Hersteller, seine eigenen Ideen und seine Perspektive auf dem Markt durchzusetzen. Ein Beispiel: Erst gründeten EMC, VMware und Cisco das Joint Venture VCE, um so genannte Vblocks, das heißt Racks aus aufeinander abgestimmten Servern, Netzwerkelementen, Speichern und einem Virtualisierungs-Layer auf den Markt zu bringen. Dann übernahm VMware den SDN-Spezialisten Nicira und machte VCE direkt Konkurrenz. Openflow, 2011 an der Stanford University entwickelt, kristallisiert sich als ein Hoffnungsträger heraus. Mit diesem Protokoll lassen sich auch über Anbietergrenzen hinweg ganze virtuelle Netzwerke managen. Genügend Software-Controller dafür gibt es bereits. Allerdings sind bisher nur sehr wenige Komponenten kompatibel zu Openflow, obwohl es in der so genannten Open Network Foundation (ONF) weltweit immerhin 80 Unternehmen unterstützen und weiterentwickeln, darunter Schwergewichte wie die Deutsche Telekom, Facebook, Google und Microsoft. Zwar haben alle wichtigen Komponentenhersteller angekündigt, entsprechende Produkte auf den Markt zu bringen, aber einstweilen ist die Auswahl sehr überschaubar. Gleichzeitig hat Cisco mit Cisco One wiederum eine zwar programmierbare, aber letztlich proprietäre Plattform vorgestellt. Gigabit Ethernet bremst das virtuelle Datacenter Ebenfalls ein limitierender Faktor ist die Datenübertragungsgeschwindigkeit im Netzwerkstack. Geht man davon aus, dass das Netzwerk permanent "atmet", also sich bedarfsgerecht erweitert oder zusammenzieht, sind permanent hohe interne Datenströme (Flows) zu erwarten. Gigabit Ethernet reicht nicht aus, um dabei Latenzen zu vermeiden. Die Lösung: Infiniband als Tunnel für den internen Ethernet-Traffic. Es bringt von Haus aus eine mindestens viermal so hohe Geschwindigkeit mit wie die derzeit maximale Ausbaustufe von 10 GBit/s Ethernet. Setzt man nun in jede Netzwerkkomponente zwei Infiniband-Netzwerkkarten ein, erhöht sich die Übertragungsgeschwindigkeit auf 80 GBit/s. Dies ist eine wesentliche Voraussetzung dafür, das Netzwerk vollständig virtualisieren und vor allem skalieren zu können. Denn das Thema Skalierung ist ebenfalls noch nicht ausgereizt. Bisherige Cloud-Computing-Angebote skalieren, zum Teil sogar automatisiert, horizontal. Im Bedarfsfall starten also neue Instanzen hoch. Allerdings hat dies den Nachteil, dass eine Unterbrechung in der Datenverarbeitung entsteht, weil die neue Instanz erst zu provisionieren ist. Zudem steigt die Leistung des gesamten Netzwerks nicht linear mit der Anzahl der Instanzen. Darüber hinaus müssen die eingesetzten Anwendungen parallelisierbar sein, das heißt über mehrere physische Instanzen hin verteilt arbeiten können. Und: Anwendungsfälle und deren Applikationen können ganz unterschiedlich sein, was ihren Ressourcenverbrauch betrifft. Manche sind besonders rechenintensiv, andere benötigen viel Arbeitsspeicher, wieder andere bewegen große Datenmengen auf den Storage-Systemen. Damit ist klar, dass nicht scheibchenweise virtualisierte physische Instanzen zur Verfügung stehen dürfen, sondern frei konfigurierbare virtuelle Systeme. Genau an dieser Stelle kommt Software-Defined Networking ins Spiel: Nur wenn jede Komponente und auch die Kommunikation zwischen diesen Komponenten virtualisiert ist, ist auch eine vertikale Skalierung machbar. Dann nämlich lassen sich granular innerhalb einer Instanz Cores, RAM und - über das virtuelle Network Attached Storage (NAS) - Speicher im laufenden Betrieb hinzufügen. Diese Live Vertical Scaling genannte Technik sorgt ohne Unterbrechung des Betriebs für mehr Rechenleistung oder verhindert den Speicherüberlauf. Derzeit sind pro virtueller Maschine maximal 62 Cores, 256 GByte RAM und bis zu 16 TByte Storage realistisch, Tendenz steigend. Alle Komponenten solcher Instanzen lassen sich in Einserschritten ohne Reboot der VM hinzufügen. Sofort starten mit IaaS Grundsätzlich ist die Technik also vorhanden, um SDDC aufzubauen. Nur bedeutet dies derzeit einen enormen Entwicklungsaufwand im eigenen Datacenter, weil der Software-Controller für die vorhandene physische Infrastruktur selbst zu schreiben wäre. Wer noch vier, fünf Jahre warten kann, um dann auf standardisierte Konzepte der Industrie zu bauen, um ein SDDC selbst im eigenen Rechenzentrum zu etablieren, hält sich von dieser Aufgabe derzeit eher fern. Allerdings steigt der Leidensdruck: Zur selben Zeit übernehmen nämlich die Business-Anwender zunehmend die Herrschaft über die IT-Beschaffung, indem sie ungefragt Apps und Dienste aus der Cloud anwenden und so im Grunde Bypässe um die offiziellen Services der IT legen - mit allen Risiken hinsichtlich Daten- und Netzwerksicherheit sowie Administrierbarkeit der IT. Strategisch gedacht bleibt die Option, ein SDDC komplett von einem IaaS-Anbieter (Infrastructure as a Service) aus der Public Cloud zu beziehen. Dies bedeutet allerdings, sich von dem Gedanken "Mein Rechenzentrum, meine virtuelle Maschine, meine Steuerungssoftware" zu verabschieden. Der echte Paradigmenwechsel besteht dann darin, nicht mehr in Produkten, sondern in Services zu denken und dieses Service-Denken nicht nur gegenüber seinen Anwendern, sondern auch als Beschaffer von IT-Ressourcen konsequent zu Ende zu führen. Bei einem seriösen IaaS-Provider kann der Interessent wohl voraussetzen, dass sich mehrere Dutzend Experten ausschließlich mit den Fragestellungen der Virtualisierung aller Netzwerkkomponenten beschäftigen - anders als im heimischen Rechenzentrum, in dem die Administratoren genügend Arbeit zu leisten haben, um die bestehende Infrastruktur perfekt am Laufen zu halten. Klar verhandelte Service Level Agreements sorgen für die nötige Sicherheit insbesondere bei den Themen Verfügbarkeit und Ausfallsicherheit. Statt sich mit den Kommunikationsproblemen auf physischer Ebene zu beschäftigen, administrieren IT-Experten ihr virtuelles RZ mittels Zugriff auf die Softwaresteuerungsschicht ihres Providers für Cloud Hosting. Die darunter liegende physische Infrastruktur ist dann nur noch insofern relevant, als sie die Basis für Service Level Agreements mit dem Provider bildet. Der Administrator wird zum Anwender einer Infrastruktur, die er physisch nicht selbst betreibt. Mittels Scripting kann er beliebig komplexe Netzwerke am Reißbrett konstruieren und administrieren. Wie komfortabel und flexibel sich dieser Prozess darstellt, das ist die eigentliche Herausforderung für den Cloud-Anbieter. Der Trend geht hier eindeutig zu grafischen Benutzeroberflächen. Cloud-Angebote aus Deutschland Bei der Auswahl des passenden Providers spielen grundsätzlich juristische Erwägungen eine wichtige Rolle. Anbieter aus den USA oder dem Nicht-EU-Ausland bieten dem Anwender nicht die notwendige Rechtssicherheit für datenschutzkonforme Speicherung und Transfer kritischer Unternehmens- oder Kundendaten. Dies gilt auch dann, wenn zum Beispiel das US-Unternehmen physische Rechenzentren in Europa oder Deutschland betreibt. Aus Sicht eines deutschen Unternehmens kann daher die Schlussfolgerung nur sein, sich nur an einen Cloud-Anbieter zu wenden, der dedizierte virtuelle Ressourcen im europäischen Rechtsraum garantiert, am besten gehostet in einem Rechenzentrum in Deutschland, und der seinen Hauptsitz im europäischen Rechtsraum hat. Dann lässt sich auch ganz klar vertraglich vereinbaren, dass gelöschte Daten auf den Storage-Systemen tatsächlich physisch gelöscht und so keinesfalls von Dritten rekonstruiert oder eingesehen werden können. Das Gleiche muss auch bei Deprovisionierung von Storage-Devices gelten. Die Kosten Hinsichtlich der Kosten gibt es im Grunde nur eine sinnvolle Option: Pay per Use - bezogen auf jede einzelne Komponente des virtuellen RZ. Feste Laufzeitverträge sind im Grunde ebenso kontraproduktiv wie die fixe Abrechnung monatlicher Kosten, ganz gleich, wie stark der Kunde die Ressourcen genutzt hat. Anders als im klassischen Hosting mietet er keinen vorkonfigurierten Server mehr für einen Monatspreis, der Preis berechnet sich aus der Addition der provisionierten Infrastruktur zuzüglich des angefallenen Traffics.
Lesen Sie mehr zum Thema
