(0) exportieren Drucken
Alle erweitern

Hyper-V-Netzwerkvirtualisierung – Technische Details

Veröffentlicht: Mai 2012

Letzte Aktualisierung: August 2013

Betrifft: Windows Server 2012 R2



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 Netzwerkinfrastrukturen im gleichen physischen Netzwerk ausgeführt (u. U. mit überlappenden IP-Adressen), wobei jede virtuelle Netzwerkinfrastruktur so arbeitet, als wäre sie das einzige virtuelle Netzwerk in der gemeinsam genutzten Netzwerkinfrastruktur. In Abbildung 1 wird diese Beziehung gezeigt.

Abbildung 1: Vergleich von Server- und Netzwerkvirtualisierung

Abbildung 1: Vergleich von Servervirtualisierung und Netzwerkvirtualisierung

Bei Hyper-V-Netzwerkvirtualisierung (HNV) wird ein Kunde als der "Besitzer" einer Gruppe virtueller Computer definiert, die in einem Datencenter bereitgestellt werden. Ein Kunde kann eine Organisation oder ein Unternehmen in einem mehrinstanzenfähigen öffentlichen Datencenter oder eine Abteilung oder Geschäftseinheit in einem privaten Datencenter sein. Jeder Kunde kann über ein oder mehrere VM-Netzwerke im Datencenter verfügen, und jedes VM-Netzwerk besteht aus mindestens einem virtuellen Subnetz.

VM-Netzwerk

  • Jedes VM-Netzwerk besteht aus mindestens einem virtuellen Subnetz. Ein VM-Netzwerk bildet eine Isolationsbegrenzung, in der virtuelle Computer innerhalb des VM-Netzwerks miteinander kommunizieren können. Daher dürfen für virtuelle Subnetze, die sich im gleichen VM-Netzwerk befinden, keine überlappenden IP-Adresspräfixe verwendet werden.

  • Jedes VM-Netzwerk verfügt über eine Routingdomäne, die das VM-Netzwerk identifiziert. Die RDID (Routing Domain ID, Routingdomänen-ID), die das Kundennetzwerk identifiziert, wird von Datencenteradministratoren oder Datencenter-Verwaltungssoftware wie beispielsweise System Center 2012 R2 – Virtual Machine Manager (VMM) zugewiesen. Die RDID ist eine Windows-GUID, beispielsweise "{11111111-2222-3333-4444-000000000000}".

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 ist eine Übertragungsdomäne (vergleichbar mit einem VLAN). Für virtuelle Computer im gleichen virtuellen Subnetz muss das gleiche IP-Präfix verwendet werden.

  • Jedes virtuelle Subnetz gehört zu einem einzigen VM-Netzwerk (RDID) und verfügt über eine zugewiesene eindeutige VSID (Virtual Subnet ID). Die VSID muss im Datencenter eindeutig sein und liegt im Bereich von 4096 bis 2^24-2.

Ein wichtiger Vorteil von VM-Netzwerk und Routingdomäne besteht darin, dass Kunden damit eigene Netzwerktopologien 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: "F&E-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-F&E-Netzwerk" ist vom "Contoso-Vertriebsnetzwerk" isoliert, obgleich beide Subnetze mit Contoso Corp. den gleichen Besitzer haben. "Contoso-F&E-Netzwerk" enthält drei virtuelle Subnetze. Beachten Sie, dass sowohl die RDID als auch VSID innerhalb eines Datencenters eindeutig sind.

Abbildung 6: Hyper-V-Netzwerkvirtualisierungsstapel

Abbildung 2: Kundennetzwerke und virtuelle Subnetze

In Abbildung 2 können die Pakete des virtuellen Computers mit der VSID 5001 über die Hyper-V-Netzwerkvirtualisierung an virtuelle Computer mit der VSID 5002 oder 5003 geroutet oder weitergeleitet werden. Vor der Übergabe des Pakets an den Hyper-V-Switch wird die VSID des eingehenden Pakets mit der VSID des virtuellen Zielcomputers aktualisiert. Dies geschieht nur dann, wenn sich beide VSIDs in der gleichen RDID befinden. Wenn die mit dem Paket verknüpfte VSID mit der VSID des virtuellen Zielcomputers nicht übereinstimmt, wird das Paket verworfen. Daher können virtuelle Netzwerkadapter mit der RDID 1 keine Pakete an virtuelle Netzwerkadapter mit der RDID 2 senden.

noteHinweis
In der oben aufgeführten Beschreibung des Paketflusses ist mit dem Begriff "virtueller Computer" eigentlich der "virtuelle Netzwerkadapter" in dem virtuellen Computer gemeint. Ein virtueller Computer verfügt üblicherweise nur über einen einzigen virtuellen Netzwerkadapter. In diesem Fall ist mit den Bezeichnungen "virtueller Computer" und "virtueller Netzwerkadapter" das Gleiche gemeint. Da ein virtueller Computer über mehrere virtuelle Netzwerkadapter verfügen kann, die wiederum unterschiedliche VSIDs und eindeutige RDIDs besitzen können, liegt bei der Hyper-V-Netzwerkvirtualisierung ein besonderes Augenmerk auf den Paketen, die zwischen virtuellen Netzwerkadaptern gesendet und empfangen werden.

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 überträgt, ist diese Übertragung auf die virtuellen Computer eingeschränkt, die an Switchports mit der gleichen VSID angeschlossen sind. Jede VSID kann mit einer Multicastadresse in der PA verknüpft werden. An diese Multicastadresse wird sämtlicher Broadcastdatenverkehr für eine VSID gesendet.

noteHinweis
Die Hyper-V-Netzwerkvirtualisierung ist NICHT von Broadcast oder Multicast abhängig. Für Broadcast- oder Multicastpakete in einem VM-Netzwerk wird eine PA-Multicast-IP-Adresse verwendet, falls eine konfiguriert ist. Viele Datencenterbetreiber aktivieren Multicast in ihren Umgebungen jedoch nicht. Wenn keine PA-Multicastadresse verfügbar ist, wird daher eine intelligente PA-Unicastreplikation verwendet. Das heißt, die Pakete werden nur als Unicast an PA-Adressen gesendet, die für das virtuelle Subnetz konfiguriert sind, in dem sich das Paket befindet. Außerdem wird unabhängig von der Anzahl der relevanten virtuellen Computer auf dem Host nur ein Unicastpaket pro Host gesendet.

Neben ihrer Rolle als Übertragungsdomäne bewirkt die VSID auch die Isolation. Ein virtueller Netzwerkadapter in der Hyper-V-Netzwerkvirtualisierung ist mit einem Hyper-V-Switchport verbunden, der über eine VSID-ACL verfügt. Wenn an diesem Hyper-V-Switchport ein Paket mit einer anderen VSID ankommt, wird das Paket verworfen. Pakete werden in einem Hyper-V-Switchport nur dann übermittelt, wenn deren VSIDs mit der VSID des Switchports übereinstimmen. Aus diesem Grund muss im oben gezeigten Beispiel (Abbildung 2) in den Paketen, die von VSID 5001 zu 5003 verlaufen, die VSID geändert werden, bevor die Pakete an den virtuellen Zielcomputer übermittelt werden können.

Wenn der Hyper-V-Switchport keine VSID-ACL besitzt, gehört der an diesen Switchport angeschlossene virtuelle Netzwerkadapter auch zu keinem virtuellen Hyper-V-Netzwerkvirtualisierungs-Subnetz. Von einem virtuellen Netzwerkadapter ohne VSID-ACL gesendete Pakete passieren die Hyper-V-Netzwerkvirtualisierung unverändert.

Wenn von einem virtuellen Computer ein Paket gesendet wird, wird die VSID des Hyper-V-Switchports diesem Paket zugeordnet. Auf der Empfängerseite übermittelt die Hyper-V-Netzwerkvirtualisierung die VSID in den OOB-Daten zusammen mit dem entkapselten Paket an den Hyper-V-Switch. Beim Empfänger wird eine Richtliniensuche durchgeführt, und den OOB-Daten wird die VSID hinzugefügt, bevor das Paket an den Hyper-V-Switch übergeben wird.

noteHinweis
Hyper-V-Switcherweiterungen können sowohl im Anbieteradressraum (PA) als auch im Kundenadressraum (CA) verwendet werden. Dies bedeutet, dass die VSID für die Switcherweiterungen verfügbar ist. Dadurch kann die Switcherweiterung mehrinstanzenfähig werden. So kann zum Beispiel eine Firewallswitcherweiterung die CA-IP-Adresse 10.1.1.5 anhand der in den OOB-Daten enthaltenen VSID 5001 von der gleichen CA-IP-Adresse mit der VSID 6001 unterscheiden.

Wie in physischen Netzwerken ist Routing ein wichtiger Teil der Hyper-V-Netzwerkvirtualisierung. Zwei wichtige Aspekte müssen Sie verstehen: Wie werden Pakete zwischen virtuellen Subnetzen weitergeleitet, und wie werden Pakete außerhalb eines virtuellen Netzwerks weitergeleitet?

In einem physischen Netzwerk bildet ein Subnetz die Domäne der Ebene 2 (L2), auf der die direkte Kommunikation zwischen (virtuellen und physischen) Computern ohne Routing möglich ist. Wenn Sie in Windows einen Netzwerkadapter statisch konfigurieren, können Sie ein Standardgateway festlegen. An diese IP-Adresse wird der gesamte vom jeweiligen Subnetz ausgehende Datenverkehr gesendet, sodass dieser entsprechend weitergeleitet werden kann. Dies ist normalerweise der Router für das physische Netzwerk. Bei der Hyper-V-Netzwerkvirtualisierung wird ein integrierter Router verwendet, der als Bestandteil jedes Hosts einen verteilten Router für ein virtuelles Netzwerk darstellt. Dies bedeutet. dass jeder Host, insbesondere der virtuelle Hyper-V-Switch, als Standardgateway für den gesamten Datenverkehr zwischen virtuellen Subnetzen im gleichen VM-Netzwerk fungiert. In Windows Server 2012 und Windows Server 2012 R2 wird für das Standardgateway die Adresse aus dem niedrigsten Eintrag für das Subnetz verwendet (für das Subnetzpräfix "/24" beispielsweise ist dies die Adresse ".1"). Diese Adresse ist in jedem virtuellen Subnetz für das Standardgateway reserviert und kann nicht von virtuellen Computern im virtuellen Subnetz verwendet werden.

Der Einsatz der Hyper-V-Netzwerkvirtualisierung als verteilter Router ermöglicht die sehr effiziente richtige Weiterleitung des gesamten Datenverkehrs in einem VM-Netzwerk, da der Datenverkehr von jedem Host ohne Einbeziehung einer zwischengeschalteten Instanz direkt an den richtigen Host weitergeleitet werden. 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.

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. Beispiele für Szenarien, in denen ein Hyper-V-Netzwerkvirtualisierungs-Gateway benötigt wird, wären eine private Cloud und eine hybride Cloud. Im Wesentlichen werden Hyper-V-Netzwerkvirtualisierungs-Gateways für VPNs und Routing benötigt.

Gateways sind in verschiedenen Formfaktoren erhältlich. Sie können auf Windows Server 2012 R2 basieren, in einem TOR-Switch (Top of Rack), einem Lastenausgleich oder anderen vorhandenen Netzwerkgeräten integriert sein oder als neues eigenständiges Netzwerkgerät vorliegen.

noteHinweis
Weitere Informationen zu Gateways finden Sie unter Hyper-V Network Virtualization Gateway Architectural Guide und Einfaches Demo mit Gatewayskript.

Größere Unternehmen zögern möglicherweise noch – oder sehen sich aus Compliance-Gründen nicht in der Lage – mit einigen Ihrer Dienste und Daten zu einem öffentlichen Cloud-Hoster zu wechseln. Trotzdem möchten sie jedoch die Vorteile nutzen, die eine über Hyper-V-Netzwerkvirtualisierung bereitgestellte Cloud bietet, indem sie ihre Datencenterressourcen in einer privaten Cloud zusammenlegen. Bei Bereitstellungen in einer privaten Cloud werden überlappende IP-Adressen nicht unbedingt benötigt, da Unternehmen für gewöhnlich über einen ausreichend großen internen Adressraum an nicht routbaren Adressen verfügen (z. B. 10.x.x.x oder 192.x.x.x). Betrachten Sie das Beispiel in Abbildung 3.

Bereitstellung der privaten Cloud

Abbildung 3: Bereitstellung in einer privaten Cloud

Beachten Sie, dass in diesem Beispiel die Kundenadressen (CAs) in den virtuellen Subnetzen mit "157.x" beginnen, während die IP-Adressen in dem Teil des Netzwerks ohne Netzwerkvirtualisierung (Corp Net) ebenfalls mit "157.x" beginnen. In diesem Fall beginnen die PA-IP-Adressen für die virtuellen Subnetze im Datacenter mit "10.x". Diese Bereitstellung versetzt das Unternehmen in die Lage, die bei Hyper-V-Netzwerkvirtualisierung mögliche Flexibilität sowohl bei der Unterbringung virtueller Computer als auch bei subnetzübergreifenden Livemigrationen im Datencenter zu nutzen. Dadurch wird die Effizienz des Datencenters gesteigert, indem sowohl die Betriebskosten als auch die Kapitalkosten gesenkt werden. In diesem Szenario übernimmt das Hyper-V-Netzwerkvirtualisierungsgateway das Routing zwischen den 10.x- und den 157.1-IP-Adressen.

Ein wichtiger Vorteil der Hyper-V-Netzwerkvirtualisierung besteht darin, dass hiermit ein lokales Datencenter nahtlos zu einem Windows Server 2012-basierten Clouddatencenter erweitert werden kann. Dieses Modell wird als "hybride Cloud" bezeichnet (siehe Abbildung 4).

Bereitstellung der Hybridcloud

Abbildung 4: Bereitstellung in einer hybriden Cloud

In diesem Szenario wird ein internes Subnetz (wie zum Beispiel das Subnetz, in dem sich Webserver befinden) aus dem Netzwerk des Unternehmens in das Datencenter eines Cloud-Hosters verschoben. Dank des vom Hoster angebotenen Prinzips Bringen Sie Ihre eigene IP-Adresse mit braucht das Unternehmen nicht die Netzwerkkonfiguration des virtuellen Computers, auf dem sich der Webserver befindet, oder anderer Netzwerkendpunkte, die auf diesen Webserver Bezug nehmen, zu ändern. Der Hoster stellt über ein Hyper-V-Netzwerkvirtualisierungs-Gateway einen sicheren Link bereit. Die Administratoren des Unternehmens müssen nur das eigene lokale VPN mit der entsprechenden IP-Adresse konfigurieren. Der virtuelle Computer mit dem Webserver merkt nicht, dass er in die Cloud verlagert wurde. Er verbleibt mit Active Directory (AD) in der Domäne und nutzt den DNS-Server des Unternehmens. Der virtuelle Computer mit dem Webserver interagiert auch weiter mit anderen Servern in dem Unternehmen (wie zum Beispiel einem SQL-Server).

Das Hyper-V-Netzwerkvirtualisierungsgateway kann mehrere standortübergreifende (Site-to-Site, S2S) VPN-Tunnel unterstützen (siehe Abbildung 5). Beachten Sie, dass VMM in der Abbildung zwar nicht enthalten ist, für Hyper-V-Netzwerkvirtualisierungen jedoch benötigt wird.

Hyper-V-Netzwerkvirtualisierungsgateway

Abbildung 5: HNV-Gateway

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

  • Kundenadresse (Customer Address, CA)   Die IP-Adresse, die vom Kunden gemäß seiner 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 Hoster oder den Datencenteradministratoren 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 2

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 "Briefumschlä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-Räume, 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 zur Adressvirtualisierung eingesetzte Mechanismus wird im nächsten Abschnitt beschrieben.

Bei der Hyper-V-Netzwerkvirtualisierung wird "Network Virtualization for Generic Routing Encapsulation" (NVGRE) als Mechanismus zum Virtualisieren der IP-Adresse unterstützt:

Generic Routing Encapsulation (GRE) 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 3: Umschreiben der IP-Adresse

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 wenn sich die PAs und CAs in den Paketen möglicherweise überlappen. 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.

Bei Windows Server 2012 und höher wird NVGRE von der Hyper-V-Netzwerkvirtualisierung 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.

In Windows Server 2012 hat ein normgerechter Betrieb eine hohe Priorität erhalten. Microsoft hat zusammen mit wichtigen Branchenpartnern (Arista, Broadcom, Dell, Emulex, Hewlett Packard und Intel) einen RFC-Entwurf veröffentlicht, in dem der Einsatz von Generic Routing Encapsulation (GRE) – was bereits als IETF-Standard vorliegt – als Kapselungsprotokoll zur Netzwerkvirtualisierung beschrieben wird. Weitere Informationen finden Sie im folgenden Internet-Entwurf: Network Virtualization using Generic Routing Encapsulation (Netzwerkvirtualisierung mithilfe von Generic Routing Encapsulation). Mit der kommerziellen Nutzung von NVGRE werden die Vorteile dieser Technologie noch größer.

In der folgenden Abbildung wird ein Beispiel für eine Bereitstellung zweier Kunden gezeigt, die in ein Clouddatencenter verschoben wird, wobei die CA-PA-Beziehung durch die Hyper-V-Netzwerkvirtualisierungs-Richtlinien definiert wird.

Abbildung 5

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.

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.

Bei der Bereitstellung der virtuellen Computer werden beiden Firmen von ihrem Hostinganbieter die folgenden VSID (Virtual Subnet ID) und PAs zugewiesen:

  • PAs der virtuellen Computer von Contoso Corp.: Die VSID ist 5001, die PA von SQL lautet 192.168.1.10, und die von Web lautet 192.168.2.20.

  • PAs der virtuellen Computer von Fabrikam Corp.: Die VSID ist 6001, die PA von SQL lautet 192.168.1.10, und die von Web lautet 192.168.2.20.

Der Hostinganbieter erstellt Richtlinieneinstellungen, die aus einem virtuellen Subnetz für den Kunden Fabrikam Corp. bestehen, das die CAs der virtuellen Computer von Fabrikam Corp. deren zugewiesenen PAs und VSID zuordnet, sowie ein separates virtuelles Subnetz für den Kunden Contoso Corp., das die CAs der virtuellen Computer von Contoso Corp. deren zugewiesenen PAs und VSID zuordnet. Diese Richtlinieneinstellungen wendet der Anbieter auf den Hyper-V-Host 1 und Hyper-V-Host 2 an.

Wenn von dem virtuellen Computer "Web" von Contoso Corp. auf Hyper-V-Host 2 eine Abfrage an den zugehörigen SQL-Server unter 10.1.1.11 gerichtet wird, geschieht Folgendes:

Hyper-V-Host 2 übersetzt die Adressen in dem Paket gemäß seiner Richtlinieneinstellungen von:

  • Quelle: 10.1.1.12 (CA von Contoso Corp. Web)

  • Ziel: 10.1.1.11 (CA von Contoso Corp. SQL)

Das gekapselte Paket enthält die folgenden Elemente:

  • GRE-Header mit der VSID: 5001

  • Äußere Quelle: 192.168.2.20 (PA für Contoso Corp. "Web")

  • Äußeres Ziel: 192.168.1.10 (PA für Contoso Corp. "SQL")

Wenn das Paket bei Hyper-V-Host 1 ankommt, wird dieser das NVGRE-Paket gemäß seinen Richtlinieneinstellungen wie folgt entkapseln:

  • Äußere Quelle: 192.168.2.20 (PA für Contoso Corp. Web)

  • Äußeres Ziel: 192.168.1.10 (PA für Contoso Corp. SQL)

  • GRE-Header mit der VSID: 5001

Das entkapselte Paket (d. h. das Original, das vom virtuellen Computer Web von Contoso Corp. gesendet wurde) wird an den virtuellen Computer SQL von Contoso Corp. übergeben:

  • Quelle: 10.1.1.12 (CA von Contoso Corp. Web)

  • Ziel: 10.1.1.11 (CA von Contoso Corp. SQL)

Wenn der virtuelle Computer SQL von Contoso Corp. auf Hyper-V-Host 1 auf die Abfrage antwortet, geschieht Folgendes:

Hyper-V-Host 1 übersetzt die Adressen in dem Paket gemäß seiner Richtlinieneinstellungen von:

  • Quelle: 10.1.1.11 (CA von Contoso Corp. SQL)

  • Ziel: 10.1.1.12 (CA von Contoso Corp. Web)

Das Paket wird mit den folgenden Werten gekapselt:

  • GRE-Header mit der VSID: 5001

  • Äußere Quelle: 192.168.1.10 (PA für Contoso Corp. "SQL")

  • Äußeres Ziel: 192.168.2.20 (PA für Contoso Corp. "Web")

Wenn das Paket bei Hyper-V-Host 2 ankommt, wird dieser das Paket gemäß seinen Richtlinieneinstellungen wie folgt entkapseln:

  • Quelle: 192.168.1.10 (PA für Contoso Corp. SQL)

  • Ziel: 192.168.2.20 (PA für Contoso Corp. Web)

  • GRE-Header mit der VSID: 5001

Das aus der Kapsel entnommene Paket wird mit den folgenden Werten an den virtuellen Computer Web von Contoso Corp. übergeben:

  • Quelle: 10.1.1.11 (CA von Contoso Corp. SQL)

  • Ziel: 10.1.1.12 (CA von Contoso Corp. Web)

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 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.

noteHinweis
Weitere Informationen zum Paketfluss erhalten Sie, indem Sie die PowerPoint-Präsentation zum Paketfluss der Hyper-V-Netzwerkvirtualisierung (in englischer Sprache) unter http://www.microsoft.com/en-us/download/details.aspx?id=34782 herunterladen.

In Windows Server 2012 wurden die Erzwingung der Hyper-V-Netzwerkvirtualisierungsrichtlinie und die IP-Virtualisierung von NDIS (Network Driver Interface Specification) LWF (Lightweight Filter) unter der Bezeichnung Windows Network Virtualization (WNV) ausgeführt. Der WNV-Filter befand sich unterhalb des Hyper-V-Switches, wie in Abbildung 9 gezeigt. Diese Architektur hatte den Nebeneffekt, dass für Switcherweiterungen nur der Datenverkehr im CA-Adressraum sichtbar war, der für den PA-Adressraum jedoch nicht.

In Windows Server 2012 R2 ist die Hyper-V-Netzwerkvirtualisierung Bestandteil des virtuellen Switches, sodass in Erweiterungen nun auch Adressen aus dem CA- und PA-Adressraum sichtbar sind.

Abbildung 7: Datencenterorchestrator (VMM)

Abbildung 9: Architektur der Hyper-V-Netzwerkvirtualisierung

Jeder Netzwerkadapter eines virtuellen Computers wird mit einer IPv4- und/oder einer IPv6-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. Bei der Hyper-V-Netzwerkvirtualisierung werden die CAs gemäß den Netzwerkvirtualisierungsrichtlinien als PAs virtualisiert.

Von einem virtuellen Computer wird ein Paket mit der Quelladresse CA1 gesendet, das richtliniengemäß im WNV-Filter im Hyper-V-Switch virtualisiert wird. Durch eine auf VSIDs basierende spezielle Zugriffssteuerungsliste (Access Control List, ACL) wird der virtuelle Computer von anderen virtuellen Computern isoliert, die nicht dem gleichen virtuellen Subnetz oder der gleichen virtuellen Routingdomäne angehören.

Auf der Windows-Plattform werden öffentliche APIs bereitgestellt, über die eine Hyper-V-Netzwerkvirtualisierung mithilfe von Datencenter-Verwaltungssoftware verwaltet werden kann. Eines dieser Produkte für die Datencenterverwaltung ist Virtual Machine Manager. Die Verwaltungssoftware enthält sämtliche Hyper-V-Netzwerkvirtualisierungsrichtlinien. Da Virtual Machine Manager die virtuellen Computer und – wichtiger noch – die Bereitstellungen virtueller Computer und kompletter virtueller Kundennetzwerke im Datencenter kennen muss und mehrinstanzenfähig sein muss, bildet die Verwaltung der Hyper-V-Netzwerkvirtualisierungsrichtlinie eine natürliche Erweiterung des richtlinienbasierten Netzwerks.

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. Basierend auf einem existierenden Standard wird Hyper-V-Netzwerkvirtualisierung schon heute in Datencentern eingesetzt, und sobald NVGRE-fähige Hardware erhältlich ist, werden sich noch mehr Vorteile ergeben. Kunden können mit Hyper-V-Netzwerkvirtualisierung jetzt Datencenter in einer privaten Cloud zusammenlegen oder nahtlos in die Umgebung eines Hosters mit einer hybriden Cloud ausweiten.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2014 Microsoft