Logo faq-o-matic.net
Logo faq-o-matic.net

Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 2

von veröffentlicht am31. Oktober 2011, 06:42 Uhr Kurzlink und Zitatlink einblenden
Kategorie Kategorie: Netzwerk, Virtualisierung, Windows Server 2012   Translate with Google Translate Translate EN   Die angezeigte Seite drucken
Zuletzt aktualisiert: 17. April 2012

Diese zweite Folge unserer Artikelserie zu Hyper-V 3.0 konzentriert sich auf die Neuheiten bei den Netzwerkfunktionen. Vorsichtshalber hier noch einmal der Hinweis: Alle Angaben beziehen sich auf die Developer Preview von Windows Server “8”. Da die Software sich noch in der Vor-Beta-Phase befindet, ist nichts dazu endgültig und alles kann sich ändern. Zudem gibt es noch kaum schriftliche, verlässliche Dokumentation, also betrachte bitte alle Angaben als reine Illustration.

Erweiterte Grundfunktionen

imageEinige Netzwerk-Neuerungen haben direkt ins Betriebssystem Einzug gefunden und sind keine Spezialität von Hyper-V. Dazu zählt vor allem das Teaming von Netzwerkkarten – auch dies durchaus eine Sensation, denn bislang (also auch bei Windows Server 2008 R2) hat Microsoft diese Technik vollständig auf die Hersteller der Netzwerkkarten abgeschoben. Zwar empfehlen die Redmonder auch heute (mit Windows Server 2008 R2) den Einsatz des Teaming, sie unterstützen es aber nicht selbst. Gibt es damit also Probleme, so muss der Treiber-Hersteller diese lösen.

Mit dem neuen Server-Windows scheint das nun anders zu werden. Zukünftig wird Windows Teams auch über Karten verschiedener Hersteller bilden können, und es dürfen mehr als zwei Karten beteiligt sein. Das Team dient dann sowohl für Failoverzwecke (beim Ausfall einer Karte bzw. einer Netzwerkverbindung läuft der Traffic über die andere Verbindung weiter) als auch für den Lastenausgleich (im Normalbetrieb nutzt Windows alle Verbindungen gleichzeitig und verteilt den Traffic darüber). Daher verwendet Microsoft den Ausdruck “LBFO” (“Load Balancing and Fail-over”). Es ist dabei nicht einmal notwendig, dass die physischen Switches “hinter” dem Server das Teaming direkt unterstützen, denn es gibt einen “Switch Independent Mode”, den man bei Bedarf auswählen kann. Interessant dabei: Das Teaming soll auch remote verwaltbar sein.

WLAN soll mit Hyper-V 3.0 auch im VM-Gast nutzbar sein. Bislang waren dafür immer einige (nicht supportete) Workarounds nötig, weil Microsoft auf dem Host nur LAN-Adapter zur Virtualisierung vorgesehen hatte.

imageDerzeit anscheinend noch nicht nutzbar ist die “Guest IP Address Injection”, mit der eine VM (wahrscheinlich) eine bestimmte IP-Konfiguration gewissermaßen “von außen” erhält. Was es damit genau auf sich hat, ist noch unklar, denn der einzige Hinweis auf diese Funktion stammt aus einer neuen BPA-Regel (Best Practices Analyzer), die noch nicht angewandt wird.

Hardwarebeschleunigung

imageIn der neuen Fassung wird Hyper-V gleich mehrere Techniken zur Hardwarebeschleunigung von Netzwerkverbindungen enthalten. Neben der eher speziellen Möglichkeit, die Netzwerkverschlüsselung per IPSec von der Netzwerkkarte erledigen lässt, sind hierbei VMQ (Virtual Machine Queue) und SR-IOV relevant. Beide erfordern spezielle Netzwerkkarten im Host.

  • VMQ ist bereits in Windows Server 2008 R2 verfügbar. Damit ist es möglich, die Verarbeitung des Netzwerktraffics durch mehrere Host-CPUs erledigen zu lassen. Ohne VMQ nutzt der Host immer nur eine einzige seiner CPUs für das Netzwerk. Durch VMQ kann man den Netzwerkverkehr in mehrere interne Queues aufteilen, die von mehreren CPUs abgearbeitet werden. In 2008 R2 weist man dazu statisch mehrere CPUs zu.
    Hyper-V 3.0 ermöglicht die dynamische CPU-Zuweisung abhängig von der aktuellen Last. Gibt es viel Netzwerkverkehr, so kann Hyper-V mehrere CPUs zur Verarbeitung einbinden. Ist wenig los, dann reduziert der Hypervisor die verarbeitenden CPUs.
  • SR-IOV ist eine neue Technik, mit der sich leistungsfähige Netzwerkkarten in mehrere logische Karten (VF, Virtual Function) partitionieren lassen. Die Ansprache dieser VFs geschieht dann direkt durch die VM oder VMs, die einen vSwitch nutzen, der auf einer solchen VF beruht. Dadurch ist die Netzwerkansprache direkter und muss nicht mehr durch die Parent Partition laufen. In Hyper-V 3.0 ist es dazu nötig, dass die Zuweisung eines vSwitch zu einer VF beim Erzeugen des vSwitch geschieht. Im Fall einer Live Migration auf einen Host ohne SR-IOV kann die betreffende VM auf einen “konventionellen” vSwitch umschalten.

Switch-Logik

imageDramatisch erweitert hat Microsoft die Logik innerhalb der vSwitches. Das neue Switch-Modell arbeitet als “Extensible vSwitch” und bringt schon einige Ergänzungen mit. Besonders interessant ist aber das darunterliegende API, das auch von Drittanbietern zur Erweiterung der Switch-Funktionen genutzt werden kann.

Direkt integriert sind ein paar Schutzfunktionen:

  • DHCP Guard: Der vSwitch kann so konfiguriert werden, dass er DHCP-Serverinformationen nur von bestimmten VMs durchlässt, die als DHCP-Server vorgesehen sind. Falls eine VM eigentlich kein DHCP-Server sein soll, aber aufgrund einer Fehlkonfiguration doch DHCP-Serverpakete verschickt, so unterdrückt der vSwitch diese Pakete.
  • Router Guard: Diese Funktion ist sehr ähnlich, unterdrückt aber Router-Informationen von VMs, die nicht als Router arbeiten sollen.
  • Netzwerk-ACLs: Ein vSwitch kann so konfiguriert werden, dass er nur Verkehr für VMs mit bestimmten IP- oder MAC-Adressen weiterleitet. Damit lässt sich steuern, welche VM mit welchem anderen System kommunizieren darf. Derzeit scheint man dies nur per PowerShell konfigurieren zu können.
  • Bandbreitensteuerung: Eine QoS-Funktion (Quality of Service) kann man nun pro VM einrichten. Damit legt man fest, welche minimale oder maximale Netzwerk-Bandbreite eine VM nutzen kann.
    image

imageDas Kernkonzept sind aber die “Switch Extensions”, die man pro vSwitch einrichten und je nach Anbieter detailliert konfigurieren kann. Das Extension-Modell unterstützt mehrere Kategorien von Erweiterungen, etwa zum Filtern des Verkehrs (die Funktionen ähneln dann einer Firewall), zum Überwachen (für Monitoring-Zwecke) oder für die Verwaltung von Switches. Das Konzept folgt einem Plug-in-Ansatz, sodass mehrere Erweiterungen parallel nutzbar sind und jede Erweiterung sich nur um ihre eigene Funktion kümmern muss. Jede Erweiterung kann im laufenden Betrieb ein- und ausgeschaltet werden. Dabei sind die Konfigurationen der Erweiterungen bei einer Live Migration auch auf andere Hosts übertragbar. Eingebaut sind zwei rudimentäre Erweiterungen für WPF-basierte Filter (Windows Filtering Platform) und für das Monitoring (NDIS-Monitor). Damit lässt sich bereits der Verkehr eines vSwitches zu einer VM an ein anderes System für die Auswertung weiterleiten.

In einem Build-Video zeigen einige externe Anbieter interessante Zusatzfunktionen für die Extensible Switches:

  • Firewall-Funktionen
  • Monitoring
  • Einheitliche Verwaltung von physischen und virtuellen Switches

[Extending the Hyper-V switch | BUILD2011 | Channel 9]
http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-559T

© 2005-2019 bei faq-o-matic.net. Alle Rechte an den Texten liegen bei deren Autorinnen und Autoren.

Jede Wiederveröffentlichung der Texte oder von Auszügen daraus - egal ob kommerziell oder nicht - bedarf der ausdrücklichen Genehmigung durch die jeweiligen Urheberinnen oder Urheber.

Das Impressum findet sich unter: http://www.faq-o-matic.net/impressum/

Danke, dass du faq-o-matic.net nutzt. Du hast ein einfaches Blog sehr glücklich gemacht!