Technische Details zur Hyper-V-Netzwerkvirtualisierung in Windows Server

Gilt für Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI (Version 21H2 und 20H2)

Mittels Servervirtualisierung können auf einem physischen Host mehrere Serverinstanzen parallel und voneinander isoliert ausgeführt werden. Jeder virtuelle Computer arbeitet im Prinzip so, als wäre er der einzige Server, der auf dem Computer ausgeführt wird.

Netzwerkvirtualisierung bietet eine ähnliche Funktionalität: Dabei werden mehrere virtuelle Netzwerke (u. U. mit überlappenden IP-Adressen) auf der gleichen physischen Netzwerkinfrastruktur ausgeführt, und jedes virtuelle Netzwerk arbeitet so, als wäre es das einzige virtuelle Netzwerk in der gemeinsam genutzten Netzwerkinfrastruktur. In Abbildung 1 wird diese Beziehung gezeigt.

Abbildung 1: Vergleich von Servervirtualisierung und Netzwerkvirtualisierung

Erklärung der Begriffe für Hyper-V-Netzwerkvirtualisierung

Bei der Hyper-V-Netzwerkvirtualisierung (HNV) wird ein Kunde oder Mandant als „Besitzer“ einer Gruppe von IP-Subnetzen definiert, die in einem Unternehmen oder Rechenzentrum bereitgestellt sind. Ein Kunde kann eine Körperschaft oder ein Unternehmen mit mehreren Abteilungen oder Geschäftseinheiten in einem privaten Rechenzentrum sein, für die Netzwerkisolation erforderlich ist, oder ein Mandant in einem öffentlichen Rechenzentrum, das von einem Dienstanbieter gehostet wird. Jeder Kunde kann über ein oder mehrere virtuelle Netzwerke im Rechenzentrum verfügen, und jedes virtuelle Netzwerk besteht aus mindestens einem virtuellen Subnetz.

Unter Windows Server 2016 stehen zwei HNV-Implementierungen zur Verfügung: HNVv1 und HNVv2.

• HNVv1

  HNVv1 ist mit dem Virtual Machine Manager (VMM) von Windows Server 2012 R2 und System Center 2012 R2 kompatibel. Die Konfiguration für HNVv1 basiert auf WMI-Verwaltungs- und Windows PowerShell-Cmdlets (unterstützt durch System Center-VMM), um Isolationseinstellungen sowie Zuordnung und Routing von Kundenadressen (CA = virtuelles Netzwerk) zu physischen Adressen (PA) zu definieren. In Windows Server 2016 wurden HNVv1 keine zusätzlichen Features hinzugefügt, und es sind keine neuen Features geplant.

  • SET Teaming und HNV V1 sind nicht plattformkompatibel.

  o Zur Verwendung von HA NVGRE-Gateways müssen Benutzer entweder LBFO-Team oder Kein Team verwenden. oder

  o Verwenden Sie bereitgestellte Gateways des Netzwerkcontrollers mit per SET gebündeltem Switch.

• HNVv2

  HNVv2 enthält eine beträchtliche Anzahl neuer Features, die mithilfe der Azure Virtual Filtering Platform (VFP)-Weiterleitungserweiterung im Hyper-V-Switch implementiert sind. HNVv2 ist vollständig in Microsoft Azure Stack integriert, der den neuen Netzwerkcontroller im SDN-Stapel (Software Defined Networking) enthält. Die Richtlinie für virtuelle Netzwerke wird über den Microsoft-Netzwerkcontroller mithilfe einer RESTful NorthBound-API (NB) definiert und über mehrere SouthBound-Schnittstellen (SBI), die OVSDB beinhalten, mit einem Host-Agent verknüpft. Der Host-Agent programmiert Richtlinien in der VFP-Erweiterung des Hyper-V-Switches, auf der sie durchgesetzt werden.

  Wichtig

  In diesem Thema liegt der Schwerpunkt auf HNVv2.

Virtuelles Netzwerk

• Jedes virtuelle Netzwerk besteht aus mindestens einem virtuellen Subnetz. Ein virtuelles Netzwerk bildet eine Isolationsbegrenzung, in der virtuelle Computer innerhalb des virtuellen Netzwerks nur miteinander kommunizieren können. Traditionell wurde diese Isolation mithilfe von VLANs mit einem getrennten IP-Adressbereich und 802.1q-Tag- oder VLAN-ID durchgesetzt. Bei HNV wird die Isolation jedoch mithilfe einer NVGRE- oder VXLAN-Kapselung erzwungen, um Überlagerungsnetzwerke mit der Möglichkeit zu überlappenden IP-Subnetzen zwischen Kunden oder Mandanten zu erstellen.

• Jedes virtuelle Netzwerk verfügt über eine eindeutige Routingdomänen-ID (RDID) auf dem Host. Diese RDID wird ungefähr einer Ressourcen-ID zugeordnet, um die REST-Ressource des virtuellen Netzwerks im Netzwerkcontroller zu identifizieren. Auf die REST-Ressource des virtuellen Netzwerks wird mit einem URI-Namespace (Uniform Resource Identifier) mit der angefügten Ressourcen-ID verwiesen.

Virtuelle Subnetze

• Ein virtuelles Subnetz implementiert die Layer 3-IP-Subnet-Semantik für die virtuellen Computer, die sich im gleichen virtuellen Subnetz befinden. Das virtuelle Subnetz bildet eine Broadcastdomäne (ähnlich einem VLAN), und die Isolation wird entweder mithilfe des NVGRE-TNI-Felds (Tenant Network ID) oder des VNI-Felds (VXLAN Network Identifier) erzwungen.

• Jedes virtuelle Subnetz gehört zu einem einzelnen virtuellen Netzwerk (RDID), und ihm wird eine eindeutige virtuelle Subnetz-ID (VSID) zugewiesen, die entweder den TNI- oder VNI-Schlüssel im gekapselten Paketheader verwendet. Die VSID muss innerhalb des Rechenzentrums eindeutig sein und liegt im Bereich von 4096 bis 2^24-2.

Ein wichtiger Vorteil von virtuellen Netzwerken und Routingdomänen besteht darin, dass Kunden damit eigene Netzwerktopologien (beispielsweise IP-Subnetze) in die Cloud bringen können. In Abbildung 2 wird ein Beispiel gezeigt, in dem das Unternehmen Contoso Corp. über zwei separate Netzwerke verfügt: „R&D-Netzwerk” für Forschung und Entwicklung und „Vertriebsnetzwerk” für den Vertrieb. Da beide Netzwerke unterschiedliche Routingdomänen-IDs besitzen, sind keine Interaktionen zwischen den Netzwerken möglich. Das heißt, das „Contoso-R&D-Netzwerk” ist vom „Contoso-Vertriebsnetzwerk” isoliert, obgleich beide Subnetze mit Contoso Corp. den gleichen Besitzer haben. „Contoso-R&D-Netzwerk” enthält drei virtuelle Subnetze. Beachten Sie, dass sowohl die RDID als auch VSID innerhalb eines Datencenters eindeutig sind.

Abbildung 2: Kundennetzwerke und virtuelle Subnetze

Layer 2: Weiterleitung

In Abbildung 2 können die Pakete der virtuellen Computer in VSID 5001 über den Hyper-V-Switch an virtuelle Computer weitergeleitet werden, die sich ebenfalls in VSID 5001 befinden. Die eingehenden Pakete von einem virtuellen Computer in VSID 5001 werden an einen bestimmten VPort auf dem Hyper-V-Switch gesendet. Vom Hyper-V-Switch werden für diese Pakete Eingangsregeln (z. B. Kapsel) und Zuordnungen (z. B. Kapselungsheader) angewendet. Die Pakete werden dann entweder an einen anderen VPort auf dem Hyper-V-Switch (wenn der virtuelle Zielcomputer an denselben Host angefügt ist) oder an einen anderen Hyper-V-Switch auf einem anderen Host weitergeleitet (wenn sich der virtuelle Zielcomputer auf einem anderen Host befindet).

Layer 3-Routing

Ebenso können die virtuellen Computer in VSID 5001 ihre Pakete vom verteilten HNV-Router, der im VSwitch jedes Hyper-V-Hosts vorhanden ist, an virtuelle Computer in VSID 5002 oder VSID 5003 weiterleiten lassen. Bei der Übergabe des Pakets an den Hyper-V-Switch aktualisiert HNV die VSID des eingehenden Pakets auf die VSID des virtuellen Zielcomputers. Dies geschieht nur dann, wenn sich beide VSIDs in der gleichen RDID befinden. Daher können virtuelle Netzwerkadapter mit der RDID 1 ohne Durchquerung eines Gateways keine Pakete an virtuelle Netzwerkadapter mit der RDID 2 senden.

Hinweis

In der oben gegebenen Beschreibung des Paketflusses ist mit dem Begriff „virtueller Computer“ eigentlich der „virtuelle Netzwerkadapter“ des virtuellen Computers gemeint. Ein virtueller Computer verfügt üblicherweise nur über einen einzigen virtuellen Netzwerkadapter. In diesem Fall können die Bezeichnungen „virtueller Computer“ und „virtueller Netzwerkadapter“ konzeptionell das Gleiche bedeuten.

Jedes virtuelle Subnetz legt ein Layer-3-IP-Subnetz und eine Layer-2-(L2)-Übertragungsdomänenbegrenzung ähnlich einem VLAN fest. Wenn ein virtueller Computer ein Paket per Broadcast überträgt, verwendet HNV Unicast Replication (UR), um eine Kopie des ursprünglichen Pakets zu erstellen und die Ziel-IP und MAC durch die Adressen jeder VM zu ersetzen, die sich in derselben VSID befindet.

Hinweis

In der veröffentlichten Version von Windows Server 2016 sind Broadcast- und Subnetz-Multicasts mithilfe der Unicastreplikation implementiert. Subnetzübergreifendes Multicastrouting und IGMP werden nicht unterstützt.

Neben ihrer Rolle als Übertragungsdomäne bewirkt die VSID auch die Isolation. Ein virtueller Netzwerkadapter in HNV ist mit einem Hyper-V-Switchport verbunden, an dem ACL-Regeln entweder direkt auf den Port (virtualNetworkInterface-REST-Ressource) oder auf das virtuelle Subnetz (VSID) angewendet werden, zu dem er gehört.

Auf den Hyper-V-Switchport muss eine ACL-Regel angewendet werden. Diese ACL kann ALLOW ALL, DENY ALL oder spezifischer sein, wenn nur bestimmte Arten von Datenverkehr zugelassen werden sollen, die auf dem 5-Tupel-Abgleich (Quell-IP, Ziel-IP, Quellport, Zielport, Protokoll) basieren.

Hinweis

Erweiterungen des Hyper-V-Switch funktionieren nicht mit HNVv2 im neuen SDN-Stapel (Software Defined Networking). HNVv2 wird mithilfe der Switcherweiterung Azure Virtual Filtering Platform (VFP) implementiert, die nicht zusammen mit anderen Switcherweiterungen von Drittanbietern verwendet werden kann.

Wechsel und Routing in der Hyper-V-Netzwerkvirtualisierung

HNVv2 implementiert die korrekte Layer-2-Switching-Semantik (L2) und Layer 3-Routingsemantik (L3), um genau wie ein physischer Switch oder Router zu funktionieren. Wenn ein virtueller Computer, der mit einem virtuellen HNV-Netzwerk verbunden ist, versucht, eine Verbindung mit einem anderen virtuellen Computer im selben virtuellen Subnetz (VSID) herzustellen, muss er zunächst die CA-MAC-Adresse des virtuellen Remotecomputers kennen. Wenn in der ARP-Tabelle des virtuellen Quellcomputers ein ARP-Eintrag für die IP-Adresse des virtuellen Zielcomputers vorhanden ist, wird die MAC-Adresse aus diesem Eintrag verwendet. Wenn kein Eintrag vorhanden ist, fordert der virtuelle Quellcomputer per ARP-Broadcast die MAC-Adresse an, die der IP-Adresse des virtuellen Zielcomputers entspricht. Der Hyper-V-Switch fängt diese Anforderung ab und sendet sie an den Host-Agent. Der Host-Agent sucht in seiner lokalen Datenbank nach einer entsprechenden MAC-Adresse für die angeforderte IP-Adresse des virtuellen Zielcomputers.

Hinweis

Der Host-Agent, der als OVSDB-Server fungiert, verwendet eine Variante des VTEP-Schemas, um CA-PA-Zuordnungen, MAC-Tabelle usw. zu speichern.

Wenn eine MAC-Adresse verfügbar ist, fügt der Host-Agent eine ARP-Antwort ein und sendet diese an den virtuellen Computer zurück. Nachdem dem Netzwerkstapel des virtuellen Computers alle erforderlichen L2-Headerinformationen zugänglich gemacht wurden, wird der Frame an den entsprechenden Hyper-V-Port auf dem V-Switch gesendet. Intern testet der Hyper-V-Switch diesen Frame anhand von N-Tupel-Abgleichsregeln, die dem V-Port zugewiesen sind, und wendet auf der Grundlage dieser Regeln bestimmte Transformationen auf den Frame an. Am wichtigsten ist, dass eine Reihe von Kapselungstransformationen angewendet wird, um den Kapselungsheader mit NVGRE oder VXLAN zu erstellen, abhängig von der Richtlinie, die auf dem Netzwerkcontroller definiert ist. Basierend auf der vom Host-Agent programmierten Richtlinie wird eine CA-PA-Zuordnung verwendet, um die IP-Adresse des Hyper-V-Hosts zu bestimmen, auf dem sich der virtuelle Zielcomputer befindet. Der Hyper-V-Switch stellt sicher, dass die richtigen Routingregeln und VLAN-Tags auf das äußere Paket angewendet werden, damit es die Remote-PA-Adresse erreicht.

Wenn ein virtueller Computer, der mit einem virtuellen HNV-Netzwerk verbunden ist, eine Verbindung mit einem virtuellen Computer in einem anderen virtuellen Subnetz (VSID) herstellen möchte, muss das Paket entsprechend geroutet werden. HNV geht von einer Sterntopologie aus, in der nur eine IP-Adresse im CA-Bereich als nächster Hop verwendet wird, um alle IP-Präfixe (d. h. eine Standardroute/ein Standardgateway) zu erreichen. Derzeit erzwingt dies eine Einschränkung auf eine einzelne Standardroute, und nicht standardmäßige Routen werden nicht unterstützt.

Routing zwischen virtuellen Subnetzen

In einem physischen Netzwerk bildet ein IP-Subnetz eine Domäne der Schicht 2 (L2), auf der die direkte Kommunikation zwischen (virtuellen und physischen) Computern möglich ist. Die L2-Domäne ist eine Broadcastdomäne, in der ARP-Einträge (IP:MAC-Adresszuordnung) über ARP-Anforderungen erlernt werden, die auf allen Schnittstellen übertragen werden, und ARP-Antworten an den anfordernden Host zurückgesendet werden. Der Computer verwendet die MAC-Informationen, die er aus der ARP-Antwort erfahren hat, um den L2-Frame einschließlich Ethernet-Headern vollständig zu konstruieren. Wenn sich eine IP-Adresse jedoch in einem anderen L3-Subnetz befindet, überschreitet die ARP-Anforderung diese L3-Grenze nicht. Stattdessen muss eine L3-Routerschnittstelle (Next-Hop oder Standardgateway) mit einer IP-Adresse im Quellsubnetz auf diese ARP-Anforderungen mit einer eigenen MAC-Adresse antworten.

In Windows-Standardnetzwerken kann ein Administrator statische Routen erstellen und diese einer Netzwerkschnittstelle zuweisen. Darüber hinaus wird ein „Standardgateway“ in der Regel so konfiguriert, dass es sich um die IP-Adresse des nächsten Hops auf einer Schnittstelle handelt, von der Pakete für die Standardroute (0.0.0.0/0) gesendet werden. Pakete werden an dieses Standardgateway gesendet, wenn keine spezifischen Routen vorhanden sind. Dies ist normalerweise der Router für das physische Netzwerk. HNV verwendet einen integrierten Router, der Bestandteil jedes Hosts ist und über eine Schnittstelle in jeder VSID verfügt, um einen verteilten Router für die virtuellen Netzwerke zu erstellen.

Da HNV von einer Sterntopologie ausgeht, fungiert der verteilte HNV-Router als einzelnes Standardgateway für den gesamten Datenverkehr zwischen virtuellen Subnetzen, die Teil desselben VSID-Netzwerks sind. Die als Standardgateway verwendete Adresse ist standardmäßig die niedrigste IP-Adresse in der VSID und dem verteilten HNV-Router zugewiesen. Der verteilte Router ermöglicht ein sehr effizientes Verfahren zum Weiterleiten des gesamten Datenverkehrs in einem VSID-Netzwerk, da der Datenverkehr von jedem Host ohne Einbeziehung einer zwischengeschalteten Instanz direkt an den richtigen Host weitergeleitet werden kann. Dies gilt insbesondere dann, wenn sich zwei virtuelle Computer im gleichen VM-Netzwerk befinden, während auf dem gleichen physischen Host verschiedene virtuelle Subnetze vorhanden sind. Weiter unten in diesem Abschnitt wird darauf eingegangen, dass das Paket den physischen Host nie verlassen muss.

Routing zwischen PA-Subnetzen

Im Gegensatz zu HNVv1, bei dem für jedes virtuelle Subnetz (VSID) eine PA-IP-Adresse zugewiesen wird, verwendet HNVv2 jetzt eine PA-IP-Adresse pro SET-NIC-Teammitglied (Switch-Embedded Teaming-Network Interface Card). Bei der Standardbereitstellung wird von einem Team mit zwei Netzwerkkarten ausgegangen, und pro Host werden zwei PA-IP-Adressen zugewiesen. Ein einzelner Host verfügt über PA-IPs, die aus demselben logischen Anbietersubnetz (PA) in demselben VLAN zugewiesen werden. Zwei Mandanten-VMs im selben virtuellen Subnetz können sich auf zwei verschiedenen Hosts befinden, die mit zwei verschiedenen logischen Anbietersubnetzen verbunden sind. HNV erstellt die äußeren IP-Header für das gekapselte Paket auf der Grundlage der CA-PA-Zuordnung. Es basiert jedoch auf dem TCP/IP-Hoststapel für ARP für das PA-Standardgateway und erstellt dann die äußeren Ethernet-Header basierend auf der ARP-Antwort. In der Regel stammt diese ARP-Antwort von der SVI-Schnittstelle auf dem physischen Switch oder L3-Router, mit dem der Host verbunden ist. HNV stützt sich daher auf den L3-Router, um die gekapselten Pakete zwischen logischen Anbietersubnetzen/-VLANs zu routen.

Routing außerhalb eines virtuellen Netzwerks

Bei den meisten Kundenbereitstellungen wird es erforderlich sein, dass aus der Hyper-V-Netzwerkvirtualisierungsumgebung heraus mit Ressourcen kommuniziert werden kann, die nicht zur Hyper-V-Netzwerkvirtualisierungsumgebung gehören. Damit eine Kommunikation zwischen diesen beiden Umgebungen möglich ist, sind Netzwerkvirtualisierungsgateways erforderlich. Zu den Infrastrukturen, in denen ein HNV-Gateway benötigt wird, zählen Private Cloud und Hybrid Cloud. Grundsätzlich sind HNV-Gateways für das Layer-3-Routing zwischen internen und externen (physischen) Netzwerken (einschließlich NAT) oder zwischen verschiedenen Standorten und/oder Clouds (privat oder öffentlich) erforderlich, die einen IPSec-VPN- oder GRE-Tunnel verwenden.

Gateways sind in verschiedenen Formfaktoren erhältlich. Sie können auf Windows Server 2016 basieren, in einen TOR-Switch (Top of Rack) integriert werden, der als VXLAN-Gateway fungiert. Dann erfolgt der Zugriff über eine von einem Lastenausgleich angekündigte virtuelle IP (VIP). Alternativ ist die Integration in andere vorhandene Netzwerkgeräte oder die Implementierung als neue eigenständige Netzwerkappliance möglich.

Weitere Informationen zu Windows RAS-Gatewayoptionen finden Sie unter RAS-Gateway.

Paketkapselung

Jedem virtuellen Netzwerkadapter werden bei der Hyper-V-Netzwerkvirtualisierung zwei IP-Adressen zugeordnet:

• Kundenadresse (Customer Address, CA) Die IP-Adresse, die vom Kunden auf der Grundlage der Intranetinfrastruktur zugewiesen wird. Diese Adresse ermöglicht es dem Kunden, Netzwerkdatenverkehr mit dem virtuellen Computer so auszutauschen, als ob dieser nicht in eine öffentliche oder private Cloud verlagert worden wäre. Die Kundenadresse (CA) ist für den virtuellen Computer sichtbar und für den Kunden zugänglich.

• Anbieteradresse (Provider Address, PA) Die IP-Adresse, die vom Hostinganbieter oder den Rechenzentrumsadministratoren gemäß deren physischer Netzwerkinfrastruktur zugewiesen wird. Die PA steht in den Netzwerkpaketen, die mit dem Hyper-V-Server ausgetauscht werden, der als Host für den virtuellen Computer dient. Die PA ist im physischen Netzwerk, jedoch nicht für den virtuellen Computer sichtbar.

Mit den CAs wird die Netzwerktopologie des Kunden abgebildet, die virtualisiert und von der eigentlichen, darunter befindlichen physischen Netzwerktopologie mit ihren Adressen gemäß der Implementierung der PAs (Anbieteradressen) entkoppelt wird. In der folgenden Abbildung wird gezeigt, welche konzeptionelle Beziehung zwischen den CAs des virtuellen Computers und den PAs der Netzwerkinfrastruktur bei einer Netzwerkvirtualisierung besteht.

Abbildung 6: Konzeptionelle Darstellung der Netzwerkvirtualisierung über eine physische Infrastruktur

In dieser Abbildung senden virtuelle Computer auf der Kundenseite Datenpakete in den Kundenadressraum, die die physische Netzwerkinfrastruktur über ihre eigenen virtuellen Netzwerke durchlaufen (tunneln). Die Tunnel im oben gezeigten Beispiel können Sie sich als „Umschläge“ um die Contoso- und Fabrikam-Datenpakete mit grünen Adressaufklebern (PA-Adressen) vorstellen, die vom Quellhost auf der linken Seite an den Zielhost rechts übermittelt werden sollen. Wichtig dabei ist, wie die Hosts die zu den CA-Adressen von Contoso und Fabrikam gehörenden „Lieferadressen“ (PAs) ermitteln, wie die Pakete in „Umschläge“ eingepackt werden und wie die Zielhosts die Pakete wieder auspacken und richtig an die virtuellen Zielcomputer bei Contoso und Fabrikam übermitteln.

Diese einfache Analogie verdeutlicht die wichtigsten Aspekte bei der Netzwerkvirtualisierung:

• Jede CA eines virtuellen Computers ist einer PA eines physischen Hosts zugeordnet. Einer PA können mehrere CAs zugeordnet sein.

• Virtuelle Computer senden Datenpakete in die CA-Bereiche, wobei die Datenpakete in einen „Umschlag“ eingepackt werden, auf dem PA-Quelle und -Ziel gemäß Zuordnung angegeben sind.

• Anhand der CA-PA-Zuordnungen müssen die Hosts unterscheiden können, welche Pakete für welchen virtuellen Kundencomputer bestimmt sind.

Die Virtualisierung des Netzwerks wird also dadurch realisiert, indem die von den virtuellen Computern verwendeten Netzwerkadressen virtualisiert werden. Der Netzwerkcontroller ist für die Adresszuordnung zuständig, und der Host-Agent verwaltet die Zuordnungsdatenbank mithilfe des MS_VTEP Schemas. Der zur Adressvirtualisierung eingesetzte Mechanismus wird im nächsten Abschnitt beschrieben.

Netzwerkvirtualisierung durch Adressvirtualisierung

HNV implementiert Mandantenüberlagerungsnetzwerke entweder mithilfe von Network Virtualization Generic Routing Encapsulation (NVGRE) oder dem Virtual eXtensible Local Area Network (VXLAN). VXLAN ist die Standardeinstellung.

Virtuelles eXtensible Local Area Network (VXLAN)

Das VXLAN-Protokoll (Virtual eXtensible Local Area Network) (RFC 7348) ist auf dem Markt breit eingeführt, mit Unterstützung von Anbietern wie Cisco, Brocade, Arista, Dell, HP und anderen. Das VXLAN-Protokoll verwendet UDP als Transport. Der von IANA zugewiesene UDP-Zielport für VXLAN ist 4789, und der UDP-Quellport sollte ein Hash mit Informationen aus dem inneren Paket sein, der für die ECMP-Verteilung verwendet werden soll. Nach dem UDP-Header wird ein VXLAN-Header an das Paket angefügt, der ein reserviertes 4-Byte-Feld, gefolgt von einem 3-Byte-Feld für den VXLAN-Netzwerkbezeichner (VNI) – VSID –, gefolgt von einem weiteren reservierten 1-Byte-Feld enthält. Nach dem VXLAN-Header wird der ursprüngliche CA L2-Frame (ohne den CA-Ethernet-Frame FCS) angefügt.

Generic Routing Encapsulation (NVGRE)

Bei diesem Mechanismus zur Netzwerkvirtualisierung wird Generic Routing Encapsulation (NVGRE) als Bestandteil des Tunnel-Headers eingesetzt. Bei NVGRE wird das Paket des virtuellen Computers in einem anderen Paket gekapselt. Der Header dieses neuen Pakets enthält neben der virtuellen Subnetz-ID (Virtual Subnet ID) – die im Key-Feld des GRE-Headers gespeichert ist (siehe Abbildung 7) – auch die entsprechenden PA-IP-Quell- und -Zieladressen.

Abbildung 7: Netzwerkvirtualisierung – NVGRE-Kapselung

Anhand der ID für das virtuelle Subnetz können Hosts für jedes Paket den virtuellen Kundencomputer ermitteln, selbst für den Fall, dass sich die PAs und CAs in den Paketen überschneiden. Daher kann auch für alle virtuellen Computer auf dem gleichen Host eine einzige PA gemeinsam genutzt werden (siehe Abbildung 7).

Diese gemeinsame Nutzung spielt bei der Netzwerkskalierbarkeit eine große Rolle. So kann die Anzahl der IP- und MAC-Adressen, die der Netzwerkinfrastruktur bekannt sein müssen, beträchtlich reduziert werden. Wenn zum Beispiel jeder Endhost durchschnittlich 30 virtuelle Computer beherbergt, wird die Anzahl der IP- und Mac-Adressen in diesem Fall um den Faktor 30 gesenkt. Außerdem ermöglichen die in den Paketen eingebetteten Virtual Subnet IDs eine einfache Zuordnung der Pakete zu den Kunden.

Das PA-Freigabeschema für Windows Server 2012 R2 ist eine PA pro VSID und Host. Für Windows Server 2016 ist das Schema ein PA pro NIC-Teammitglied.

Bei Windows Server 2016 und höher werden NVGRE und VXLAN von HNV von vornherein vollständig unterstützt. Ein Upgrade oder der Erwerb neuer Netzwerkhardware (wie Netzwerkkarten, Switches oder Router) ist NICHT erforderlich. Der Grund dafür ist, dass es sich bei dem NVGRE-Paket im Netzwerk um ein normales IP-Paket im PA-Raum handelt, das mit der Infrastruktur heutiger Netzwerke kompatibel ist. Verwenden Sie jedoch zum Erzielen einer optimalen Leistung unterstützte NICs mit den neuesten Treibern, die Aufgabenauslagerungen unterstützen.

Beispiel für mehrinstanzenfähige Bereitstellung

In der folgenden Abbildung wird ein Beispiel für eine Bereitstellung zweier Kunden gezeigt, die sich in einem Cloudrechenzentrum befinden und deren CA-PA-Beziehung durch die Netzwerkrichtlinien definiert ist.

Abbildung 8: Beispiel für eine mehrinstanzenfähige Bereitstellung

Betrachten Sie das Beispiel in Abbildung 8. Vor dem Verschieben in den freigegebenen IaaS-Dienst des Hostinganbieters:

• Contoso Corp. führte unter der IP-Adresse 10.1.1.11 einen SQL-Server (mit dem Namen SQL) und unter der IP-Adresse 10.1.1.12 einen Webserver (mit dem Namen Web) aus, für dessen Datenbanktransaktionen der zugehörige SQL-Server verwendet wurde.

• Auch Fabrikam Corp. führte einen SQL-Server (SQL) unter der zugewiesenen IP-Adresse 10.1.1.11 und einen Webserver (Web) unter der IP-Adresse 10.1.1.12 aus, für dessen Datenbanktransaktionen der zugehörige SQL-Server verwendet wurde.

Es wird davon ausgegangen, dass der Hostingdienstanbieter zuvor das logische Anbieternetzwerk (PA) über den Netzwerkcontroller so erstellt hat, dass es seiner physischen Netzwerktopologie entspricht. Der Netzwerkcontroller ordnet zwei PA-IP-Adressen aus dem IP-Präfix des logischen Subnetzes zu, in dem die Hosts verbunden sind. Der Netzwerkcontroller gibt außerdem das entsprechende VLAN-Tag zur Anwendung der IP-Adressen an.

Mithilfe des Netzwerkcontrollers erstellen Contoso Corp und Fabrikam Corp anschließend ihr virtuelles Netzwerk und ihre Subnetze, die von dem vom Hostingdienstanbieter angegebenen logischen Anbieternetzwerk (PA) unterstützt werden. Contoso Corp. und Fabrikam Corp. verschieben ihre jeweiligen SQL-Server und Webserver in den freigegebenen IaaS-Dienst des gleichen Hostinganbieters. Dort wird zufällig der virtuelle Computer SQL auf dem Hyper-V Host 1 und der virtuelle Computer Web (IIS7) auf dem Hyper-V-Host 2 ausgeführt. Alle virtuellen Computer behalten die ursprünglichen Intranet-IP-Adressen (CAs) bei.

Beiden Unternehmen wird vom Netzwerkcontroller die folgende Virtual Subnet ID (VSID) zugewiesen, wie unten angegeben. Der Host-Agent auf jedem der Hyper-V-Hosts empfängt die zugeordneten PA-IP-Adressen vom Netzwerkcontroller und erstellt zwei PA-Host-vNICs in einem nicht standardmäßigen Netzwerkfach. Jeder dieser Host-VNICs wird eine Netzwerkschnittstelle zugewiesen, wobei die PA-IP-Adresse wie unten dargestellt zugewiesen ist:

• VSID und PAs für virtuelle Computer von Contoso Corp. : VSID ist 5001, SQL PA ist 192.168.1.10, Web PA ist 192.168.2.20

• VSID und PAs für virtuelle Computer von Fabrikam Corp. : VSID ist 6001, SQL PA ist 192.168.1.10, Web PA ist 192.168.2.20

Der Netzwerkcontroller führt alle Netzwerkrichtlinien (einschließlich CA-PA-Zuordnung) in den SDN-Host-Agent ein, der die Richtlinie in einem dauerhaften Speicher (in OVSDB-Datenbanktabellen) verwaltet.

Wenn von dem virtuellen Webcomputer von Contoso Corp. (10.1.1.12) auf Hyper-V-Host 2 eine TCP-Verbindung mit dem SQL-Server unter 10.1.1.11 hergestellt wird, geschieht Folgendes:

• VM-ARPs für die MAC-Zieladresse 10.1.1.11

• Die VFP-Erweiterung im vSwitch fängt dieses Paket ab und sendet es an den SDN-Host-Agent.

• Der SDN-Host-Agent sucht in seinem Richtlinienspeicher nach der MAC-Adresse für 10.1.1.11.

• Wenn eine MAC gefunden wird, fügt der Host-Agent eine ARP-Rückantwort an den virtuellen Computer ein.

• Wenn keine MAC gefunden wird, wird keine Antwort gesendet, und der ARP-Eintrag in der VM für 10.1.1.11 wird als nicht erreichbar markiert.

• Der virtuelle Computer erstellt jetzt ein TCP-Paket mit den richtigen CA-Ethernet- und IP-Headern und sendet es an den vSwitch.

• Die VFP-Weiterleitungserweiterung im vSwitch verarbeitet dieses Paket über die VFP-Ebenen (unten beschrieben), die dem vSwitch-Quellport zugewiesen sind, an dem das Paket empfangen wurde, und erstellt einen neuen Flusseintrag in der vereinheitlichten VFP-Flusstabelle.

• Die VFP-Engine führt basierend auf den IP- und Ethernet-Headern einen Regelabgleich oder eine Flusstabellensuche für jede Schicht (z. B. virtuelle Netzwerkschicht) durch.

• Die übereinstimmende Regel in der virtuellen Netzwerkschicht verweist auf einen CA-PA-Zuordnungsbereich und führt eine Kapselung durch.

• Der Kapselungstyp (entweder VXLAN oder NVGRE) ist in der VNET-Schicht zusammen mit der VSID angegeben.

• Bei der VXLAN-Kapselung wird ein äußerer UDP-Header mit der VSID 5001 im VXLAN-Header erstellt. Ein äußerer IP-Header wird mit der Quell- und Ziel-PA-Adresse erstellt, die dem Hyper-V-Host 2 (192.168.2.20) bzw. Hyper-V-Host 1 (192.168.1.10) zugewiesen sind, basierend auf dem Richtlinienspeicher des SDN-Host-Agents.

• Dieses Paket fließt dann zur PA-Routingschicht in VFP.

• Die PA-Routingschicht in VFP verweist auf das Netzwerkfach, das für PA-Bereichs-Datenverkehr und eine VLAN-ID verwendet wird, und verwendet den TCP/IP-Stapel des Hosts, um das PA-Paket ordnungsgemäß an Hyper-V-Host 1 weiterzuleiten.

• Nach Erhalt des gekapselten Pakets empfängt Hyper-V-Host 1 das Paket im PA-Netzwerkfach und leitet es an den vSwitch weiter.

• Der VFP verarbeitet das Paket über seine VFP-Ebenen und erstellt einen neuen Flusseintrag in der vereinheitlichten VFP-Flowtabelle.

• Die VFP-Engine stimmt mit den Eingangsregeln in der virtuellen Netzwerkschicht überein und entfernt die Ethernet-, IP- und VXLAN-Header des äußeren gekapselten Pakets.

• Die VFP-Engine leitet das Paket dann an den vSwitch-Port weiter, mit dem die Ziel-VM verbunden ist.

Ein ähnlicher Prozess beim Datenverkehr zwischen den virtuellen Computern Web und SQL von Fabrikam Corp. verwendet die Hyper-V-Netzwerkvirtualisierungs-Richtlinieneinstellungen für Fabrikam Corp. Dies hat zur Folge, dass die virtuellen Computer von Fabrikam Corp. und Contoso Corp. dank Hyper-V-Netzwerkvirtualisierung so miteinander interagieren, als befänden sie sich noch in den ursprünglichen Intranets. Mit den virtuellen Computern des jeweils anderen Unternehmens findet keine Interaktion statt, auch wenn für diese die gleichen IP-Adressen verwendet werden.

Durch die separaten Adressen (CAs und PAs), die Richtlinieneinstellungen der Hyper-V-Hosts und die Adressübersetzung zwischen der CA und der PA bei ein- und ausgehendem Datenverkehr für virtuelle Computer sind die Servergruppen beider Firmen entweder mithilfe des NVGRE-Schlüssels oder der VLXAN-VNID voneinander isoliert. Außerdem wird die virtuelle Netzwerkarchitektur durch die Virtualisierungszuordnungen und -umwandlungen von der physischen Netzwerkarchitektur entkoppelt. Obwohl sich Contoso SQL und Web sowie Fabrikam SQL und Web in jeweils eigenen CA-IP-Subnetzen befinden (10.1.1/24), werden sie physisch auf zwei Hosts in unterschiedlichen PA-Subnetzen bereitgestellt: 192.168.1/24 bzw. 192.168.2/24. Dies bringt mit sich, dass durch Hyper-V-Netzwerkvirtualisierung subnetzübergreifende Bereitstellungen virtueller Computer und Livemigrationen möglich werden.

Architektur der Hyper-V-Netzwerkvirtualisierung

In Windows Server 2016 ist HNVv2 mithilfe der Azure Virtual Filtering Platform (VFP) implementiert, bei der es sich um eine NDIS-Filtererweiterung innerhalb des Hyper-V-Switches handelt. Das Schlüsselkonzept von VFP ist das einer Match-Action-Flow-Engine mit einer internen API, die dem SDN-Host-Agent für die Programmierung von Netzwerkrichtlinien verfügbar gemacht wird. Der SDN-Host-Agent selbst empfängt die Netzwerkrichtlinie vom Netzwerkcontroller über die Kommunikationskanäle OVSDB und WCF SouthBound. Die Richtlinie für virtuelle Netzwerke (z. B. CA-PA-Zuordnung) ist nicht nur mithilfe von VFP, sondern auch mit zusätzlichen Richtlinien wie ACLs, QoS usw. programmiert.

Die Objekthierarchie für die vSwitch- und VFP-Weiterleitungserweiterung lautet wie folgt:

• vSwitch

  • Externe NIC-Verwaltung

  • NIC-Hardwareabladungen

  • Globale Weiterleitungsregeln

  • Port

    • Weiterleitungsschicht für ausgehendes Anheften

    • Bereichslisten für Zuordnungen und NAT-Pools

    • Vereinheitlichte Flowtabelle

    • VFP-Schicht

      • Flowtabelle

      • Group

      • Regel

        • Regeln können auf Bereiche verweisen

In der VFP wird eine Schicht pro Richtlinientyp (z. B. Virtual Network) erstellt, und es handelt sich um einen generischen Satz von Regel-/Flusstabellen. Sie verfügt erst dann über systeminterne Funktionen, wenn dieser Schicht bestimmte Regeln zugewiesen werden, um diese Funktionalität zu implementieren. Jeder Schicht wird eine Priorität zugewiesen, und Schichten werden einem Port durch aufsteigende Priorität zugewiesen. Regeln werden in Gruppen organisiert, die in erster Linie auf Richtung und IP-Adressfamilie basieren. Gruppen wird ebenfalls eine Priorität zugewiesen, und höchstens eine Regel aus einer Gruppe kann mit einem bestimmten Flow übereinstimmen.

Die Weiterleitungslogik für den vSwitch mit der VFP-Erweiterung lautet wie folgt:

• Eingangsverarbeitung (eingehend aus der Sicht des Pakets, das bei einem Port eingeht)

• Weiterleitung

• Ausgangsverarbeitung (ausgehend aus der Sicht des Pakets, das von einem Port ausgeht)

Der VFP unterstützt die interne MAC-Weiterleitung für NVGRE- und VXLAN-Kapselungstypen sowie die äußere MAC-VLAN-basierte Weiterleitung.

Die VFP-Erweiterung verfügt über einen langsamen und einen schnellen Pfad für die Paketdurchquerung. Das erste Paket in einem Flow muss alle Regelgruppen in jeder Schicht durchlaufen und eine Regelsuche durchführen, was ein teurer Vorgang ist. Sobald jedoch ein Flow in der einheitlichen Flowtabelle mit einer Liste von Aktionen registriert wurde (basierend auf den übereinstimmenden Regeln), werden alle nachfolgenden Pakete auf der Grundlage der Einträge der einheitlichen Flowtabelle verarbeitet.

Die HNV-Richtlinie wird vom Host-Agent programmiert. Jeder Netzwerkadapter eines virtuellen Computers ist mit einer IPv4-Adresse konfiguriert. Das sind die CAs, mit deren Hilfe die virtuellen Computer miteinander kommunizieren, und sie sind in den aus den virtuellen Computern abgehenden Paketen enthalten. HNV kapselt den CA-Frame in einem PA-Frame auf der Grundlage der Netzwerkvirtualisierungsrichtlinien, die in der Datenbank des Host-Agents gespeichert sind.

Abbildung 9: Architektur der Hyper-V-Netzwerkvirtualisierung

Zusammenfassung

Cloudbasierte Datencenter bieten viele Vorteile, wie zum Beispiel eine bessere Skalierbarkeit und Ressourcenauslastung. Um diese potenziellen Vorteile praktisch nutzen zu können, ist eine Technologie erforderlich, die sich um die Problematik der mehrinstanzenfähigen Skalierbarkeit in einer dynamischen Umgebung kümmert. Hyper-V-Netzwerkvirtualisierung wurde für diese Problematik entworfen. Außerdem wird die Effizienz von Datencentern erhöht, indem die virtuelle von der physischen Netzwerktopologie entkoppelt wird. Aufbauend auf einem vorhandenen Standard, wird HNV in heutigen Rechenzentren ausgeführt und mit Ihrer vorhandenen VXLAN-Infrastruktur betrieben. Kunden können mit HNV jetzt Rechenzentren in einer privaten Cloud zusammenlegen oder ihre Rechenzentren nahtlos in die Umgebung eines Hostinganbieters mit einer Hybrid Cloud ausweiten.

Siehe auch

Weitere Informationen zu HNVv2 finden Sie unter den folgenden Links:

Inhaltstyp	Referenzen
Community-Ressourcen	- Blog zur Architektur von Private Clouds – Stellen Sie Fragen: cloudnetfb@microsoft.com
RFC	- RFC-Entwurf zu NVGRE - VXLAN - RFC 7348
Verwandte Technologien	– Technische Details zur Hyper-V-Netzwerkvirtualisierung in Windows Server 2012 R2 finden Sie unter Technische Details zur Hyper-V-Netzwerkvirtualisierung. - Netzwerkcontroller