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

Teil 1 dieses Artikels fand sich vor wenigen Tagen auf diesem Blog.

Datenschleusen

Zu den Grundfunktionen der virtuellen Switches in Hyper-V gehört nun auch eine Bandbreitensteuerung, wenn auch nur eine sehr einfache. Für jeden virtuellen „Switchport“ kann der Administrator einen maximalen oder minimalen Durchsatz definieren, mit dem die virtuelle Maschine die Außenwelt erreicht. Dadurch lassen sich allzu geschwätzige VM-Applikationen im Zaum halten und auf einen Höchstwert drosseln. In der Praxis wird es allerdings eher andersrum sein, wenn bestimmte VMs oder bestimmte Netzwerktypen eine garantierte Mindestbandbreite benötigen. So kann man etwa den Netzwerkkarten, die das Storage per iSCSI ansprechen, eine zuverlässige Schneise durchs Netz schlagen. Diese rudimentäre Quality-of-Service-Funktion (QoS) arbeitet aber nur auf der Ebene virtueller Netzwerkkarten und kann einzelne Protokolle nicht unterscheiden.

Ein paar weitere Features der virtuellen Switches nutzen die neue Filtertechnik der Architektur. Von Haus aus kann jeder Switchport bestimmte Protokolle blockieren, die sich in einem Netzwerk leicht besonders störend auswirken. Der „DHCP-Wächter“ (im Original: „DHCP Guard“) lässt auf Wunsch keine DHCP-Server-Pakete ins Netz, und sein Kollege „Router-Wächter“ („Router Guard“) unterdrückt Router-Ankündigungen. So kann man in Hosting-Umgebungen schnell Abhilfe schaffen, wenn der Betreiber einer VM versehentlich einen DHCP-Server laufen lässt, der das ganze Netzwerk durcheinander bringt, ohne dass man ins Gast-Betriebssystem der VM eingreifen muss.

Diese beiden Filter nutzen gewissermaßen als mitgelieferte Beispiele die „Extension“-Technik der virtuellen Switches im aktuellen Hyper-V. Verwandt damit ist die eingebaute Port-Spiegelung, die den gesamten Datenverkehr einer virtuellen Netzwerkkarte an eine andere virtuelle Maschine weiterleiten kann. Das benötigt man manchmal zur Problemsuche; einfach mal einschalten sollte man es aus rechtlichen Gründen natürlich nicht. Weitere Möglichkeiten dieser neuen Schnittstellen werden weiter unten Thema sein.

Hardware-Spezialitäten

Die Servervirtualisierung hat auch der Hardware-Entwicklung von Netzwerkkarten einen neuen Schub verliehen. Windows Server 2012 kann mit einigen neuartigen Funktionen aktueller Netzwerkadapter umgehen. Dazu gehört vor allem die „Single-Root I/O Virtualization (SR-IOV)“, in der deutschen Microsoft-Übersetzung unbeholfen als „E/A-Virtualisierung mit Einzelstamm“ präsent. Vereinfacht gesagt, setzt eine Netzwerkkarte dieses Typs die Idee der CPU-Virtualisierung auf einem Ethernet-Adapter um. Solche Karten lassen sich auf der Hardware-Ebene partitionieren und stellen sich dem Betriebssystem gegenüber wie mehrere Netzwerkadapter dar, die sich „Virtual Functions (VF)“ nennen. Hyper-V kann eine solche VF direkt an eine virtuelle Maschine als Netzwerkkarte durchreichen. Dadurch entsteht eine direkte Schnittstelle von der Ethernet-Hardware im Hostserver in den Netzwerkstack des Gast-Betriebssystems.

Hyper-V 2012 unterstützt einige Techniken zur Netzwerkbeschleunigung

Solche Netzwerkverbindungen verursachen erheblich weniger Last auf den CPUs des Hostservers, denn bei herkömmlicher Technik müsste der Host für jedes Netzwerkpaket einzeln nachsehen, zu welcher VM es gehört. Diese aufwändige Zuordnung entfällt hier. SR-IOV empfiehlt sich also besonders für virtuelle Maschinen, die viel Netzwerkverkehr verursachen. Der Administrator muss diese Funktion bereits beim Erzeugen des virtuellen Switches aktivieren, an den er die virtuelle Maschine anbinden will, später lässt sie sich nicht hinzuschalten. In einem Failover-Cluster schränkt diese Technik nicht ein: Sollte eine VM von einem Host mit aktivem SR-IOV auf einen anderen Host ohne die Technik wechseln, so kann sie dort weiter kommunizieren. In diesem Fall läuft die Kommunikation zwar technisch weniger effizient, aber sie bricht nicht ab.

Eine verwandte Technik ist zwar schon älter, doch das neue Hyper-V geht besser damit um. Virtual Machine Queue (VMQ) sorgt dafür, dass der Hypervisor die Netzwerkpakete für bestimmte VMs besser identifizieren kann. Auch hier spielen die Netzwerkkarte und ihre Treiber mit, es ist also spezielle Hardware nötig. Schon der ersten Hyper-V-Fassung im Server 2008 beherrschte das System die Technik, ließ aber immer nur eine CPU des Hosts die Netzwerkpakete sortieren. Bei hoher Netzwerklast stand so auch dieser Prozessor arg unter Dampf. Im Nachfolger 2008 R2 konnte der Administrator mehrere CPUs für diese Aufgabe auswählen. Der Server 2012 nun reagiert dynamisch und schaltet bei zunehmender Last weitere CPUs zur LAN-Paketverwaltung hinzu, die er bei abnehmendem Traffic wieder anderweitig einsetzt.

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