Netzwerke in Hyper-V: Ein Überblick (Teil 3)

Teil 1 und Teil 2 dieses Artikels fanden sich vor wenigen Tagen auf diesem Blog.

Konvergente Netze

Das Thema „Converging Networks“ interpretiert Microsoft im Zusammenhang mit seinem Hypervisor etwas eigenwillig. In der IT-Infrastrukturbranche bezeichnet der Terminus derzeit meist die Verbindung von LAN und SAN, also das Zusammenwachsen von Allzweck-Netzwerken mit Speicher-Netzen. Als gemeinsames Trägermedium etabliert sich dabei Ethernet, das man zu diesem Zweck funktional aufgebohrt hat. Im Kern handelt es sich um zweierlei: Storage-Daten kann man über das recht junge Protokoll „Fibre Channel over Ethernet (FCoE)“ transportieren, was nichts anderes ist als herkömmliches Fibre Channel, dessen Transportschicht durch Ethernet ersetzt wurde. Damit das funktioniert, bedurfte es einiger Ergänzungen des Ethernet-Protokolls, damit es Fehler und Latenzen vermeiden kann. Das bedeutet, dass man FCoE eben nicht, wie das Marketing manchmal behauptet, über herkömmliche Ethernet-Switches verteilen kann, sondern es braucht angepasste Hardware. Hat man diese aber, so benötigt man keine separate Infrastruktur mehr für das SAN, sondern aller LAN-und SAN-Traffic läuft über dasselbe Netz. Ab da wird also ein Schuh draus – vorausgesetzt, die Storage-Geräte und Server beherrschen dies auch.

Natürlich kann Windows Server 2012 mit dieser Technik umgehen, wenn der Server über die nötigen Netzwerkkarten verfügt, die hier „Converged Network Adapter (CNA)“ heißen. Deren Treiber präsentieren dem Betriebssystem bei Bedarf parallele Netzwerk- und Fibre-Channel-Adapter und kümmern sich dann um den Rest. Hierfür muss Windows also nur Treiber einbinden.

Spricht Microsoft selbst von „Converged Networks“ oder „Converged Fabrics“, dann meint man dort etwas anderes. Hier geht es dann um den virtualisierten Zugriff auf (vor allem) 10-Gigabit-Ethernet-Karten, die ganz klassisch auf der IP-Ebene verschiedene Protokolle umsetzen. Vereinfacht gesagt, besteht der Clou darin, an einen solchen 10-GE-Adapter einen virtuellen Switch für Hyper-V zu binden. Im Host-Betriebssystem definiert man dann parallel mehrere virtuelle Netzwerkkarten, die man an den vSwitch koppelt, und separiert den Traffic über VLANs. Einen dieser vNICs nutzt man dann für den LAN-Verkehr des Host-Betriebssystems, einen weiteren für Storage über iSCSI, und parallel greifen auch die vNICs der virtuellen Maschinen auf diesen vSwitch zu.

Im Ergebnis transportiert der virtuelle Switch also verschiedene Typen von Datenverkehr parallel: Host-LAN, VM-LAN und iSCSI-SAN, alles über dieselbe Netzwerkkarte. Verschiedene Netzwerke laufen hier also zusammen – das bezeichnen die Redmonder als „Converged Fabric“, auch wenn es sich bei allen Teilen um herkömmliche IP-basierte Protokolle ohne jede Anpassung handelt.

Das ging so früher nicht mit Hyper-V, denn bisher konnte der Administrator direkt im Host-Betriebssystem nicht mehr als eine virtuelle Netzwerkkarte mit einem vSwitch verbinden (während er problemlos in den VMs beliebig viele Netzwerkkarten parallel nutzen konnte). Es liegt auf der Hand, dass Konstrukte dieser Art in einer produktiven Umgebung vor allem mit 10-GE-Karten Sinn ergeben, denn nur dieser Kartentyp erreicht genügend Durchsatz für solchen Parallelbetrieb. Dadurch benötigt ein Hostserver viel weniger physische Netzwerkkarten als in traditionellen 1-Gigabit-Designs. Denkbar ist allerdings auch ein Aufbau mit einem Team aus mehreren einfachen Gigabit-Karten, deren gebündelte Leistung der vSwitch dann in mehrere virtuelle Netzwerkkarten aufteilt.

Solche Feinheiten stehen jedoch in der grafischen Oberfläche nicht zur Verfügung. Hierzu muss der Administrator zur PowerShell greifen, die nun auch für Hyper-V zumindest aus funktionaler Sicht zum bevorzugten Werkzeug wird. Ein so aufgebautes Netzwerk eignet sich als Basis für einen Failover-Cluster mit Hyper-V. Der Hostserver erhält damit beispielsweise vier logische Netzwerke.

• Ein Netzwerk dient dem Management des Hosts selbst, also Administration, Datensicherung usw. Dieses Netz bekommt 5 Prozent der Bandbreite des Teams garantiert, bei zwei 10-GE-Karten ist das minimal 1 Gigabit an Durchsatz. Die Netzwerkpakete erhalten die VLAN-ID 10.
• Das zweite Netz verbindet die Clusterknoten für die gegenseitige Überwachung. Es erhält ebenfalls 5 Prozent Bandbreitengarantie und belegt das VLAN 11.
• Über das dritte Netz laufen die Live-Migrationen ab, also das Verschieben virtueller Maschinen von einem Host zum anderen. Hier ist Dampf gefragt, daher gilt eine Garantie von 40 Prozent der Bandbreite. Die VLAN-ID ist 12.
• Das vierte Netz bleibt ohne ausdrückliche Definition, es entsteht automatisch, indem der Administrator virtuelle Maschinen an den vSwitch ankoppelt. Für den VM-Traffic gilt die „Default Flow Minimum Bandwidth“ von 50 Prozent. VLANs lassen sich pro VM-Netzwerkkarte individuell bestimmen.

Neue Netzwerk-Designs

Die Kombination der durchsatzstarken 10-Gigabit-Netzwerkhardware mit den neuen Konfigurationsoptionen in Windows Server 2012 lässt für Hyper-V-Administratoren völlig neuartige Designs zu, die den bisher erforderlichen Overkill an physischen Switchports drastisch minimieren. Die Kombination zweier 10-GE-Karten ergibt eine nominelle Bandbreite von 20 Gigabit pro Sekunde, die man mit der oben gezeigten Technik sehr flexibel aufteilen kann. Dafür benötigt man nur zwei Ports in der Infrastruktur und erhält gleichzeitig eine hohe Ausfallsicherheit.

Ein zweiter Design-Vorschlag arbeitet mit vier Karten und bildet darüber ein sehr anspruchsvolles Konzept ab. Zwei Netzwerkports stehen für den Speicher-Datenverkehr mit iSCSI zur Verfügung. Hieran lassen sich neben den Hostservern (die ja ein gemeinsames Speichersystem für die Ablage der VMs und ihrer Daten benötigen) auch die virtuellen Maschinen selbst anbinden, wenn diese Bedarf an SAN-Speicher haben. Wer nun aufhorcht und sich erinnert, dass iSCSI und NIC-Teaming nicht zusammenpassen: Hier findet das Teaming auf einer anderen Ebene statt, nämlich unterhalb des virtuellen Switches. Für iSCSI ist dies transparent; bei Bedarf lassen sich zwei virtuelle iSCSI-Adapter auch hier standardkonform mit MPIO koppeln.

Einstöpseln

Der Clou an Microsofts renovierten virtuellen Switches liegt in ihrer Erweiterbarkeit. Über eine dokumentierte Schnittstelle öffnen die Redmonder ihre Netzwerk-Architektur für Drittanbieter, die eigene Module zur Erweiterung entwickeln können. Dabei kann es sich um Filter handeln, wie man sie von Firewalls kennt, aber auch um Analysefunktionen oder Management-Software. Mehrere Hersteller haben Erweiterungen angekündigt, von denen einige immerhin schon als funktionsfähige Beta-Versionen vorliegen.

Von Cisco kommt der „Nexus 1000V for Hyper-V“, der den eingebauten virtuellen Switch in ein Cisco-Device verwandeln soll. Der so erweiterte vSwitch soll sich in mancher Hinsicht wie ein Cisco-Switch verhalten und sich genauso verwalten lassen. 5Nine Software baut einen „Security Manager“, der mehrere Sicherheitsfunktionen wie Firewall und Virenschutz umsetzen soll. InMon und NEC haben Analyse- und Management-Module in Arbeit, und Broadcom entwickelt einen DoS-Blocker.

Eine solche „Switch Extension“ installiert man auf jedem Hostserver, wo man sie nutzen will. Mehrere Erweiterungen dürfen parallel existieren, der Administrator kann sie auch einzeln ein- und abschalten. Verfügen nicht alle Hosts in einem Cluster über dieselben Extensions, so können VMs trotzdem von einem auf den anderen wechseln, nur funktioniert am Ziel die Extension natürlich nicht. Wer die dadurch möglichen Sicherheitsrisiken vermeiden will, sorgt für eine einheitliche Ausstattung aller Hosts.

Fazit

Die Netzwerkfunktionen in Windows Server 2012 und vor allem in Hyper-V sprechen dafür, dass Microsoft als Virtualisierungsanbieter ernsthaft in die großen Unternehmen und Rechenzentren vordringen will. Endlich gibt es Teaming-Funktionen auf Betriebssystemebene, die vollen Support aus einer Hand genießen und dabei noch hohe Flexibilität ermöglichen. Noch erfreulicher ist, dass die Redmonder an anderen Stellen technisch ganz vorn im Feld spielen, etwa bei der Unterstützung von High-End-Netzwerkkarten.

Wer mit Hyper-V virtualisiert, profitiert nun von einer leistungsfähigen Netzwerkschicht im Hypervisor. Durch multiple logische Adapter im Hostsystem im Verbund mit der Bandbreitensteuerung entstehen flexible Design-Optionen, die auch in anspruchsvollen Umgebungen den Bedarf decken dürften. Mit seiner Plug-in-Schnittstelle für Drittanbieter, die die virtuellen Netzwerke um komplexe Funktionen ergänzen können, hat Microsoft einen klugen Schachzug getan. Ärgerlich, dass die externen Module schon seit bald einem Jahr auf sich warten lassen. Kommen die Hersteller hier nun bald aus dem Knick, dann stellt sich Hyper-V durchaus als ernsthafte Alternative für virtuelle Server im Rechenzentrum dar.

Dabei hat Microsoft auch noch andere Pfeile im Köcher: Mit der „Network Virtualization“ lässt sich ein Software-definiertes Netzwerk aufbauen, das besonders für Hoster interessant ist. Hierdurch entkoppelt sich die logische Ebene von der physischen, sodass es ganz ohne VLANs etwa mehrere getrennte Netze mit denselben Adressen auf derselben physischen Struktur geben kann.