Zukunft der SDN-Umgebungen
Brücke zum Hyperscale-RZ
Traditionelle Netzwerktopologien stellen die größte Hürde auf dem Weg zu einer flexiblen, automatisierten und Cloud-fähigen Infrastruktur dar. Mit Software-Defined Networking (SDN) und der richtigen Implementierungsstrategie öffnet sich dagegen der Weg hin zu einer völlig neuen Art der Ressourcennutzung: dem sogenannten Hyperscale-Rechenzentrum.
Das Netzwerk erweist sich oft als hemmender Faktor bei der Automatisierung von Rechenzentren. Während sich die Server-Virtualisierung weitgehend durchgesetzt hat und im Speicherbereich Software-Defined Storage immer häufiger Verwendung findet, ist die Virtualisierung des Netzwerks noch nicht so recht in den Rechenzentren der Unternehmen angekommen. Was nutzt es aber, virtuelle Server- und Speicherumgebungen bedarfsorientiert und automatisiert zu- und abschalten zu können, wenn der Administrator neuen Maschinen jedes Mal manuell Ports zuweisen oder gar physische Switch-Verbindungen ändern muss? Um das Verfahren zu automatisieren, bedarf es eines sorgfältig abgestimmten Prozesses.
1. Schritt: Netzwerktopologie vereinfachen
Typische traditionelle Netzwerke sind in drei Ebenen aufgebaut. Der Netzwerkverkehr von Blade- oder Rack-Servern wird pro Rack über einen Top-of-the-Rack-Switch (ToR-Switch) in einem Aggregations-Layer zusammengeführt und von dort zu einem Core-Switch geleitet, der die weitere Verbreitung übernimmt. Um Ausfallsicherheit zu gewährleisten, sind alle Netzwerkverbindungen redundant ausgelegt. Der STP-Algorithmus (Spanning Tree Protocol) sorgt dafür, dass immer nur ein Pfad verwendet wird, damit es nicht zu Schleifen oder Broadcast-Stürmen kommt. An diesem "besten Pfad" hält das System allerdings auch dann fest, wenn es zu Datenstaus und in der Folge zu Paketverlusten auf der Leitung kommt. Nur beim Ausfall eines Switches schaltet der Algorithmus auf eine alternative Route um. Diese Lösung lastet also die vorhandene Switching-Architektur ineffizient aus, 50 Prozent der Kapazität im RZ bleiben die meiste Zeit ungenutzt. Sie ist zudem komplex und unflexibel.
Durch das Zusammenfassen von Aggregations- und Core-Ebene lässt sich die Topologie hingegen vereinfachen. Hochverfügbarkeit lässt sich wesentlich ressourceneffizienter durch eine Active-/Active-Lösung realisieren, indem man redundante physische Verbindungen zwischen Switches und Servern per LACP (Link Aggregation Control Protocol) zu einer logischen aggregiert. Im Core werden die Switches und Router per Intelligent Resilient Framework (IRF) zu einem virtuellen Device zusammengefasst. So lassen sie sich von außen wie ein einziges Gerät ansprechen und verwalten. Die Umschaltzeiten in einer solchen virtualisierten Umgebung betragen Millisekunden und nicht Sekunden wie beim traditionellen Modell. Zudem ist die Umgebung viel leichter skalierbar: Ports, Bandbreite oder Verarbeitungskapazität lassen sich einfach erhöhen, indem ein weiteres physisches Gerät per IRF in das virtuelle Device integriert wird.
Noch einfacher skalierbar und höher verfügbar wird ein Netzwerk durch die Kombination aus IRF und einer Fabric-Technik. Zur Wahl stehen das von der IETF (Internet Engineering Task Force) standardisierte Verfahren TRILL (Transparent Interconnection of Lots of Links) und der SPB-Standard (Shortest Path Bridging) des IEEE (Institute of Electrical and Electronics Engineers). Beide Techniken erlauben reine Layer-2-Netzwerke. Für das Routing kommt bevorzugt das Link-State-Protokoll IS-IS (Intermediate System to Intermediate System) zum Einsatz. In einer solchen Spine-Leaf-Architektur ist jeder Switch der unteren Ebene mit jedem der oberen verbunden. So lange es keine Überbuchung von Ports gibt, lässt sich damit eine blockierungsfreie Vermaschung erreichen. Die Wahl eines Pfades erfolgt randomisiert, sodass der Netzwerkverkehr gleichmäßig über alle Verbindungswege verteilt wird. Fällt ein Switch aus, hat das nur eine geringe Performance-Einbuße zur Folge.
Die Komplexität gegenüber herkömmlichen hierarchischen Topologien sinkt durch Spine-Leaf mit der Virtualisierung mit TRILL oder SPB und der Kombination mit IRF um den Faktor 20. Sprungfixe Kosten fallen weg, und die IT kann Bandbreite bedarfsgerecht hinzufügen. Da alle Switches einer Ebene gleich sind und mehrere Geräte den Core bilden, entfallen große modulare Gehäuse mit hoher Port-Anzahl. Bei der Auswahl der Switches ist zudem darauf zu achten, dass diese Openflow (siehe unten) unterstützen und dass dies nicht mit zusätzlichen Lizenzkosten verbunden ist.
2. Schritt: SDN einführen
Im zweiten Schritt lässt sich die Migration zum Software-Defined Network realisieren. SDN zentralisiert die Steuerung des Datenverkehrs (Control Plane) und entkoppelt sie vom eigentlichen Verkehr (Data Plane), also der Weiterleitung von Paketen. Netzwerkadministratoren haben so die Möglichkeit, den Netzwerkverkehr zentral und automatisiert zu steuern, ohne per CLI (Command Line Interface) direkt auf die einzelnen physischen Netzwerkkomponenten zugreifen zu müssen.
Die Migration zu SDN ist kein Selbstzweck, sondern bringt erhebliche Vorteile für Business-Anwendungen. Zuallererst ist SDN eine Grundvoraussetzung für eine Cloud-Infrastruktur. Sie sollte Self-Service mit automatisiert bereitgestellten Diensten sowie eine automatischen Ressourcenprovisionierung und -überwachung bieten. SDN kann aber auch in anderen Bereichen seine Vorteile ausspielen, etwa wenn es darum geht, Plattformen zusammenzuführen, Campus-Applikationen bereitzustellen, Sicherheitszonen zu definieren oder um Lastverteilung ohne dedizierten Load Balancer betreiben zu können. Eine UCC-Lösung (Unified Communication and Collaboration) profitiert ebenfalls stark von SDN, da damit granulare QoS-Level (Quality of Service) für verschiedene Dienste wie Sprache oder Video problemlos möglich sind.
Zur Steuerung der Pakete in einem SDN kommt in der Regel Openflow zum Einsatz, ein offenes Kommunikationsprotokoll, das zahlreiche Hersteller unterstützen und die Open Networking Foundation (ONF) weiterentwickelt. Openflow erlaubt die Fernsteuerung des Netzverkehrs über SDN Controller. Statt der Forwarding-Tabellen traditioneller Topologien erhalten die Switches die Informationen, welche Pakete wohin zu leiten sind, über "Flow Tables". Diese lassen sich manuell oder automatisiert aus der Ferne verändern, ohne dass ein manueller Zugriff auf das Gerät notwendig ist. Gemischte Implementierungen von Netzkomponenten verschiedener Hersteller sind kein Problem, sofern sie Openflow-kompatibel sind, da die Intelligenz in den Controllern und nicht in den Switches liegt.
SDN mit Openflow lässt sich auf zwei Arten realisieren: als Overlay oder als Open SDN. Im ersten Fall legt man über die physische Infrastruktur ein getunneltes Netzwerk virtualisierter Switches (Vswitches). Die Kommunikation der Vswitches erfolgt mittels VXLAN (Virtual Extensible LAN) und mit der darunter liegenden physischen Infrastruktur über ein VXLAN-Gateway. Diese Art der Implementierung bietet folgende Vorteile:
Overlay-Netzwerke lassen sich über eine bestehende physische Infrastruktur legen, ohne dass diese erst anzupassen wäre.
Mehrere virtuelle Netzwerke können dieselbe Infrastruktur nutzen.
Dank Entkopplung der virtuellen MAC-/IP-Adressen von der physischen Adresse lassen sich beispielsweise die Limitierungen durch MAC-Tabellen in physischen Switches umgehen.
Verbesserte Mobilität virtueller Maschinen (VMs): Migriert eine VM auf einen anderen Host oder gar in ein anderes Subnetz, sind nur die Mapping-Tabellen in den Vswitches anzupassen.
IP-Adressräume mehrerer Mandanten können sich überlappen, ohne dass es zu Problemen kommt.
Multipath-Forwarding wird innerhalb virtueller Netzwerke unterstützt.
Eine einfache Provisionierung von Netzwerk-Services ist möglich.
In Overlay-SDN-Netzen ist zudem das Troubleshooting einfach, da die Verbindungssteuerung in der Software liegt und die Ethernet Fabric keine dienstspezifische, sich verändernde Konfiguration trägt. Bei der Open-SDN-Alternative dagegen wird direkt auf den physischen Switches virtualisiert, ohne eine zusätzliche virtuelle Netzwerkschicht dazwischenzuschalten. Voraussetzung dafür sind Openflow-fähige Switches.
Obwohl sich Openflow großer Beliebtheit erfreut, gibt es Hersteller, die SDN über andere Wege implementieren wollen, etwa indem sie per API eine Fernsteuerung der Forwarding-Tabellen auf den Switches ermöglichen. Diese Art der Implementierung widerspricht jedoch komplett der Intention, durch die Software-Implementierung ein weitgehend von den Eigenschaften der Hardware unabhängiges Datacenter zu schaffen. Stattdessen begibt man sich wieder in die Abhängigkeit von einem Hersteller oder einer bestimmten Produktgruppe.
3. Schritt: vom virtuellen zum Hyperscale-RZ
Mittels SDN verlegt man die Steuerung der Netzwerkkomponenten in die über der Physik liegende Software. Herkömmliche Switches bringen aber eine Menge an eigener Intelligenz mit, die in einem virtualisierten RZ eigentlich gar nicht mehr gebraucht wird - im Gegenteil: Die oft proprietären Betriebssysteme und Protokolle der Switches erschweren ihre Virtualisierung. Was liegt also näher, als komplett auf diese Intelligenz zu verzichten und stattdessen "reines Blech", also Bare-Metal-Switches einzusetzen? Port-Zahl, Bandbreite und Verbindungskapazität lassen sich so in Sekunden in großem Stil erweitern, ohne den Netzwerkbetrieb zu stören oder zu unterbrechen.
Große RZ-Betreiber wie Google und Facebook sind diesen Schritt ins Hyperscale-Rechenzentrum bereits gegangen, aber auch für andere Service-Provider kann es künftig überlebenswichtig sein, auf erhöhte Anforderungen schnell, automatisiert und unterbrechungsfrei reagieren zu können. Schließlich wird vor allem der Trend zu Industrie 4.0 gerade im Maschinenbauland Deutschland für erhebliche Nachfrageschübe bei RZ-Kapazität führen.
Ausblick: RZ der Zukunft
Auch wenn Hyperscale-Rechenzentren wesentlich effizienter und flexibler als herkömmliche Datacenter sind, basieren sie doch auf Standardhardware mit ihrem immer noch sehr hohen Bedarf an Platz, Strom und Kühlung. Rund zwei Prozent des weltweiten Energieverbrauchs entfällt heute schon auf die IT-Infrastruktur - so viel wie das gesamte Industrieland Japan mit seinen mehr als 126 Millionen Einwohnern verbraucht. Dazu kommt ein immenses Datenwachstum. Trends wie das Internet der Dinge oder Big Data werden die Datenerzeugung weiter ankurbeln.
Ein erster Schritt zur Lösung dieses Problems ist die höhere Integration von Systemen, zum Beispiel in Form der Embedded-Compute-Integration des "Moonshot"-Systems von HP. Dieses verbraucht fast 90 Prozent weniger Energie bei 80 Prozent weniger Platzbedarf als traditionelle Systeme mit derselben Leistung. Die Verkabelung lässt sich gar um 98 Prozent reduzieren. Das Geheimnis des Systems liegt unter anderem in einer Workload-optimierten Architektur und dem SoC-Design (System on a Chip), das eine extrem dichte Packung von 45 Servern in einem 4,3 Höheneinheiten messenden Gehäuse ermöglicht. Dank Local Chassis Fabric ist die Kommunikation zwischen den Recheneinheiten schnell und latenzarm. Switch-Module erlauben externe High-Speed-Verbindungen mit bis zu 45 10GBit/s-Ports pro Switch. Die Server-Module fassen bis zu 1 TByte an lokalem Storage. Dieser ist erweiterbar.
Langfristig wird sich die Rechenarchitektur noch stärker verändern. Unter dem Arbeitstitel "The Machine" arbeiten die HP Labs an einer völlig neuen Art von Server. Er soll die Rechenarchitektur radikal vereinfachen und so die 80 Prozent an Rechenleistung einsparen, die heute nötig ist, um die Daten vom Plattenspeicher in das RAM zu bewegen und umgekehrt. Kern dieser Strategie ist die "Memristor"-Technik, die RAM und Plattenspeicher (HD und/oder SSD) vereint.
Die "Memristor"-Technik basiert auf der "Widerstanderinnerung" elektronischer Komponenten. Fließt Strom durch eine Komponente in eine bestimmte Richtung, erhöht sich der Widerstand, fließt er in die andere, nimmt der Widerstand ab. Wird der Strom abgeschaltet, "erinnert" sich die Komponente beim nächsten Start an den zuletzt anliegenden Widerstand.
Auf Basis der Memristor-Technik hat HP bereits Speicherriegel-Prototypen entwickelt, die eine vielfach höhere Datenmenge als bisher speichern können. Momentan liegt die geplante Speichergröße von 100 TByte in der Größe eines Mobiltelefons, ein PByte wäre dann ein Block von zirka 15 cm Kantenlänge. Um möglichst schnell auf diese Mengen an Speicher zugreifen zu können, verwendet The Machine optische Verbindungen auf Substratebene: Die CPU wird direkt über ein optisches Medium mit dem Speicherblock verbunden. Zum Einsatz kommt hier eine bereits bekannte Lasertechnik namens VCSEL (Vertical Cavity Surface-Emitting Laser). Die von HP entwickelten Laser sind circa 25 Mikrometer groß und lassen sich daher direkt in das CPU-Design integrieren. Die Kombination dieser einzelnen Technologien ermöglicht nun ein SoC-Design. Eine neue Server-Architektur ist denkbar, ebenso die für das Internet of Things oder die bei der Industrie 4.0 benötigten Kleinstrechensysteme für die Sensorik.
Lesen Sie mehr zum Thema
