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

Mit den ersten beiden Versionen seines Hypervisors in Windows Server 2008 und dessen Nachfolger 2008 R2 hat Microsoft Achtungserfolge erzielt und besonders in kleinen und mittelständischen Unternehmen eine Marktposition erarbeitet. Im Vergleich zu Platzhirsch VMware und Mitbewerber Citrix bietet Hyper-V hohe Performance, niedrige Kosten und das gewisse „Zuhause“-Gefühl, weil Administratoren sich mit der Windows-Lösung vertraut sehen. Sobald ein Kunde allerdings höhere Anforderungen an die Einbindung seiner Virtualisierungslösung in komplexere Rechenzentren hat, neigt er weiterhin zu den traditionellen Anbietern, vor allem zu VMware. Dazu tragen bislang vor allem zwei Faktoren bei: Zu Hyper-V gibt es erheblich weniger Zusatzprodukte, die ergänzende Aufgaben wie Datensicherung oder Management übernehmen. In erster Linie aber waren die Netzwerkfunktionen des Redmonder Hypervisors in den ersten beiden Fassungen bestenfalls als rudimentär zu bezeichnen.

Mit einem großen architektonischen Wurf begegnet Microsoft diesen Schwächen und versucht zwei Fliegen mit einer Klappe zu schlagen. Zum einen hat das Softwarehaus die eingebauten Netzwerk-Funktionen erheblich erweitert, sodass schon mit Bordmitteln deutlich leistungsfähigere Aufbauten möglich sind. Zum anderen bringt Hyper-V nun definierte Schnittstellen mit, über die Drittanbieter recht einfach eigene Erweiterungen für den virtuellen Netzwerk-Stack anbinden können. Das ermöglicht neben virtuellen Firewalls und Monitoring-Lösungen auch eine gemeinsame Konfiguration virtueller und physischer Switches. Ebenso können die virtuellen Switches nachträglich neue Fähigkeiten bekommen, um auch für den Datacenter-Betrieb fit zu werden. Erste Anbieter haben schon Produkte dafür vorgelegt oder angekündigt.

Bislang konnte der Administrator in Hyper-V zur Netzwerkanbindung nicht viel mehr tun, als pro Host-Netzwerkkarte einen virtuellen Switch einzurichten und an diesen die virtuellen Maschinen zu koppeln. Zu konfigurieren gab es nichts weiter außer optional einem VLAN-Tag pro virtuellem Switch-Port. Keine Priorisierung, keine Bandbreitensteuerung, Port-Spiegelung ebenso wenig wie Filterfunktionen. Nicht einmal das Teaming von Netzwerkkarten unterstützte Microsoft selbst, hier mussten die Kartenhersteller mit eigenen Treibern (und eigenem Support) in die Bresche springen. Das alles reichte für einfache Aufgaben, doch RZ-Betreiber mit VMware-Erfahrung lächelten nur müde.

Teamarbeit

Eine der wichtigsten Neuerungen haben die Redmonder im Server 2012 außerhalb des Hypervisors vorgenommen: Endlich unterstützen Windows-Server von Haus aus das Netzwerkkarten-Teaming. Diese Technik bindet mehrere LAN-Adapter zu einer logischen Einheit zusammen, um gleichzeitig Ausfallsicherheit und Lastverteilung (effektiv also höheren Durchsatz) zu erzielen. Microsoft nennt dies „Load Balancing and Failover (LBFO)“ und benötigt dazu erstmals keine Drittanbieter-Software mehr. Ein solches Team kann bis zu 32 Karten (genauer: Netzwerkports) umfassen, die auch von unterschiedlichen Herstellern stammen können. Üblich sind Konfigurationen mit zwei bis vier Adaptern.

Das Teaming von Netzwerkkarten ist nun eine Funktion des Betriebssystems

Stets bietet ein solches Team die Failover-Funktion an: Fällt eine Netzwerkverbindung aus, kann der gesamte Datenverkehr über die andere(n) Karte(n) des Teams weiter fließen. Das setzt natürlich voraus, dass die Infrastruktur „hinter“ dem Server das erlaubt – sind alle Team-Karten mit demselben Switch verbunden und dieser ist defekt, dann gibt es auch keine Verbindung. Da Switches durchaus häufiger ausfallen als Netzwerkkarten, verbindet man die Adapter eines Teams vorzugsweise mit verschiedenen Switches. Für solche Konfigurationen bietet Windows Server 2012 mehrere Teaming-Betriebsarten. Ein Team kann „Switch-abhängig“ sein, also bestimmte Einstellungen und Protokolle im aktiven Netz erfordern, oder „Switch-unabhängig“, was Aufbauten ohne Anpassung des physischen Netzwerks ermöglicht.

Die Lastverteilungsfunktion im Teaming ist optional, aber meist erwünscht. Hierbei bündelt Windows die Bandbreite aller beteiligten Karten zu einer nominellen Gesamtbandbreite: vier Gigabit-Ports erkennt der Server im Team als 4-Gbit-Link. Diese vier Gigabit kann man aber prinzipiell nur in günstigen Situationen nutzen, nämlich wenn es vier parallele Datenströme (oder mehr) gibt, die das System auf die vier Karten aufteilen kann. Diese Einschränkung gilt für jede Technik dieser Art unabhängig vom Hersteller, denn die Pakete einer bestimmten Verbindung zwischen zwei Rechnern laufen immer über dieselbe Netzwerkkarte. Tatsächlich sind es also hier nicht vier Gigabit, sondern viermal ein Gigabit. Nur wenige Applikationsprotokolle beherrschen die Aufteilung ihres Traffics auf mehrere Adapter (dazu zählt etwa SMB 3.0), aber das geschieht auf einer anderen Ebene.

Hat der Administrator ein Team auf der Host-Ebene definiert (die in Hyper-V „Management-OS“ heißt), so kann er dafür in Hyper-V einen virtuellen Switch (vSwitch) einrichten und an diesen die virtuellen Netzwerkkarten (vNIC) seiner VMs anbinden. Die Zahl der vNICs, die ein vSwitch verträgt, ist nicht begrenzt und auch nicht pauschal zu benennen. Da die Applikationen innerhalb einer VM sehr unterschiedlichen Traffic erzeugen, hängt das sinnvolle Maximum immer von der jeweiligen Umgebung ab. Im Zweifel helfen nur Messungen bei der Planung. Virtuelle Maschinen eignen sich hervorragend, um die Lastverteilung im Netzwerkkarten-Teaming auszunutzen, denn alle VMs erzeugen eigene Datenströme, die sich parallel verarbeiten lassen.

… weiter geht’s im zweiten Teil (in wenigen Tagen auf diesem Blog.)