Exportieren (0) Drucken
Alle erweitern

Anleitung zur Gatewayarchitektur für die Hyper-V-Netzwerkvirtualisierung

Letzte Aktualisierung: Oktober 2014

Betrifft: Windows Server 2012, Windows Server 2012 R2



führt eine skalierbare, sichere mehrinstanzfähige Lösung namens Hyper-V-Netzwerkvirtualisierung ein. Diese Technologie kann zum Aufbauen von Rechenzentren verwendet werden und kann es Kunden erleichtern, ihre Netzwerkstruktur in Private, Hybrid und Public Clouds inkrementell zu verschieben.

Eine Übersicht über die Hyper-V-Netzwerkvirtualisierung finden Sie unter Hyper-V-Netzwerkvirtualisierung – Übersicht, Hyper-V-Netzwerkvirtualisierung – Technische Details und im Sicherheitsleitfaden für Windows Server® 2012 Hyper-V auf der Microsoft TechNet-Website.

Die Hyper-V-Netzwerkvirtualisierung kann mit vorhandener Hardware für Server und Switches bereitgestellt werden. Zum Bewältigen wichtiger Szenarien (wie das Bereitstellen von Private, standortübergreifenden und Hybrid Clouds) ist neben einer Rechenzentrums-Verwaltungslösung jedoch auch eine Gatewayfunktionalität erforderlich.

Dieser Artikel umfasst Anforderungen für unterschiedliche Typen der Hyper-V-Netzwerkvirtualisierungsgateways und -Gatewayfunktionen. Beachten Sie, dass besonders auf die Gatewayfunktion hingewiesen wird, da vorhandene Netzwerkgeräte möglicherweise die Hyper-V-Netzwerkvirtualisierungs-Gatewayfunktion umfassen. Zusätzliche technische Details in Bezug auf das Paketkapselungsformat, das durch die Hyper-V-Netzwerkvirtualisierung verwendet wird, finden sich möglicherweise unter NVGRE draft RFC.

Für die meisten Kundenbereitstellungen ist die Kommunikation aus der virtualisierten Netzwerkumgebung mit der nicht netzwerkbasierten virtualisierten Umgebung erforderlich. Daher fungieren Hyper-V-Netzwerkvirtualisierungsgateways als Brücke dieser zwei Umgebungen.

Gateways sind in verschiedenen Formfaktoren erhältlich. Sie können auf basieren. Alternativ können sie in einem TOR-Switch (Top of Rack) oder in einem vorhandenen Netzwerkgerät eingebaut sein, oder sie können ein eigenständiges Netzwerkgerät sein. Für das Private Cloud-Szenario ist die Routingfunktion erforderlich, die im Abschnitt „Private Cloud“ beschrieben wird. Neben dem Routing ist die VPN-Funktionalität für das Szenario der Hybrid Cloud erforderlich, das im Abschnitt „Hybrid Cloud“ beschrieben wird. Im dritten Szenario wird die Gatewayfunktion in einen Lastenausgleich integriert, was im Abschnitt „Lastenausgleich“ beschrieben wird.

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 Public Cloud-Hoster zu wechseln. Unternehmen möchten dennoch weiterhin von den Vorteilen der Cloud und Netzwerkvirtualisierung profitieren, indem sie ihre Rechenzentrenressourcen in eine Private Cloud konsolidieren. Bei Bereitstellungen in einer Private Cloud werden überlappende IP-Adressen nicht unbedingt benötigt, da Unternehmen ü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 1.

Abbildung 1: Bereitstellung der privaten Cloud

Abbildung 1: Bereitstellung der privaten Cloud

Beachten Sie, dass in diesem Beispiel die Kundenadressen (CAs) in den virtuellen Subnetzen mit „10.229.x“ beginnen, während die IP-Adressen in dem Teil des Netzwerks ohne Netzwerkvirtualisierung (CorpNet) mit „10.229.1“ beginnen. In diesem Fall beginnen die PA-IP-Adressen für die virtuellen Subnetze im Datacenter mit „10.60.x“. Diese Bereitstellung versetzt das Unternehmen in die Lage, die bei der Hyper-V-Netzwerkvirtualisierung mögliche Flexibilität sowohl bei der Unterbringung virtueller Computer als auch bei subnetzübergreifenden Livemigrationen im Rechenzentrum zu nutzen. Dadurch wird die Effizienz des Rechenzentrums gesteigert, indem sowohl die Betriebskosten als auch die Kapitalkosten gesenkt werden.

Für das in Abbildung 1 veranschaulichte Private Cloud-Szenario ist eine Gatewayappliance für die Private Cloud oder eine Gatewayfunktion erforderlich, die in einem vorhandenen Netzwerkgerät enthalten ist. Der Zweck des Gateways für die Private Cloud besteht darin, ein Routing und einen Übergang zwischen physischen und virtuellen Adressen bereitzustellen.

Ein wichtiger Vorteil der Hyper-V-Netzwerkvirtualisierung besteht darin, dass hiermit ein lokales Rechenzentrum nahtlos auf ein -basiertes Cloud-Rechenzentrum erweitert werden kann. Dieses Modell wird Hybrid Cloud-Modell genannt (siehe Abbildung 2).

Abbildung 2: Bereitstellung der Hybrid Cloud

Abbildung 2: Bereitstellung der privaten Cloud

In diesem Szenario wird ein interner Server, beispielsweise ein Webserver, aus dem Unternehmensnetzwerk in ein Rechenzentrum des Cloud-Hosters verschoben. Dank des vom Hoster angebotenen Prinzips Bring Your Own IP Address (Verwendung der eigenen IP-Adresse) braucht das Unternehmen nicht die Netzwerkkonfiguration des virtuellen Computers, auf dem sich der Webserver befindet, oder anderer Netzwerkendpunkte zu ändern, die auf diesen Webserver Bezug nehmen. Der Hoster stellt über eine VPN-Gatewayappliance 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 hat keine Kenntnis davon, 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 Webservercomputer interagiert auch weiter mit anderen Servern in dem Unternehmen (wie zum Beispiel einem SQL-Server). In diesem Beispiel verbleiben diese drei Dienste (AD, DNS, SQL) alle lokal vor Ort. Netzwerkdiagnosetools wie tracert, das die Anzahl der Netzwerkhops zwischen einer Quelle und einem Ziel zählt, zeigen an, dass der Netzwerkdatenverkehr zwischen dem virtuellen Webservercomputer und SQL nicht mehr lokal erfolgt, sondern über das Internet geroutet wird.

Für das in Abbildung 2 veranschaulichte Hybrid Cloud-Szenario ist eine mehrinstanzfähige VPN-Appliance wie eine Netzwerkvirtualisierungs-Gatewayappliance erforderlich. Das VPN-Appliancegateway muss mit der Orchestrierung des Rechenzentrums (wie System Center Virtual Machine Manager) interagieren, um die entsprechenden Netzwerkvirtualisierungsrichtlinien abzurufen.

Ein Lastenausgleich vermittelt Clients, die einen Dienst anfordern, den Eindruck einer einzelnen IP-Adresse (virtuelle IP-Adresse oder VIP). Der Dienst wird auf mehreren verschiedenen IP-Adressen (direkte IP-Adresse oder DIP) implementiert. Ein herkömmlicher Lastenausgleich ordnet den Netzwerkdatenverkehr über die Netzwerkadressenübersetzung (Network Address Translation, NAT) von VIP zu DIP zu. Der Lastenausgleich schreibt die Ziel-IP-Adresse (VIP) des eingehenden Pakets mit einer der IP-Adressen (DIP) hinter dem Lastenausgleich um, der den Dienst ausführt. In Fällen, in denen der Lastenausgleich als bidirektionale NAT fungiert, sendet der DIP ein Rückgabepaket zum Lastenausgleich, und der Lastenausgleich schreibt die Quell-IP (DIP) mit der VIP um. In diesem Fall kennt der Client nur die VIP, nicht aber die DIP.

noteHinweis
In Windows Server 2012 R2 und Windows Server 2012 ist der Netzwerklastenausgleich nicht vollständig in die Hyper-V-Netzwerkvirtualisierung integriert. Einige Drittanbieter bieten jedoch Lastenausgleichslösungen für den Lastenausgleich in virtuellen Netzwerken, die auf Hyper-V-Netzwerkvirtualisierung basieren, kombiniert mit einer Hyper-V-Netzwerkvirtualisierungs-Gatewayfunktionalität an. Für die Verwendung eines Lastenausgleichmoduls als Hyper-V-Netzwerkvirtualisierungs-Gateway ist ein Hotfix von System Center Virtual Machine Manager (VMM) erforderlich. Weitere Informationen zum Netzwerklastenausgleich finden Sie unter Netzwerklastenausgleich (Übersicht).

Angenommen, sowohl die virtuellen Computer des blauen als auch des roten Unternehmens befinden sich im selben mehrinstanzfähigen Rechenzentrum, das einen Lastenausgleich für die Mandanten bereitstellt. Das blaue Unternehmen verfügt über vier virtuelle Computer, die einen Dienst hinter einem Lastenausgleich anbieten. Das rote Unternehmen verfügt über zwei virtuelle Computer, die einen unterschiedlichen Dienst anbieten, für den ein Lastenausgleich vorgenommen werden soll.

Abbildung 3: Lastenausgleich und Richtlinie

Abbildung 3: Beispiel mit mehrinstanzfähigem Lastenausgleich

In Abbildung 3 wird eine virtuelle Topologie veranschaulicht, wobei für öffentlich routbare IP-Adresse ein Lastenausgleich über mehrere virtuelle Zielcomputer hinweg vorgenommen wird. Beispielsweise senden Kunden aus dem Internet Datenverkehr zur öffentlichen IP (VIP) des blauen Unternehmens. Der Lastenausgleich gibt auf Basis der Netzwerkvirtualisierungsrichtlinie ein NVGRE-Paket aus, um das Paket zum entsprechenden Hyper-V-Host zu senden. Der Hyper-V-Host entkapselt das Paket und sendet es anschließend an den virtuellen Zielcomputer.

Abbildung 4: Lastenausgleich zwischen Ebenen

Abbildung 4: Bereitstellung eines mehrinstanzfähigen Lastenausgleichs

Abbildung 4 zeigt eine mögliche Bereitstellung von Abbildung 3. In diesem Fall lautet der Anbieteradressraum der virtuellen Computer, für die ein Lastenausgleich vorgenommen wurde, 192.168.6.x. Der blaue Kunde verfügt über vier virtuelle Computer, die auf drei physischen Hosts ausgeführt werden. Der rote Kunde verfügt über zwei virtuelle Computer, die auf zwei unterschiedlichen Hosts ausgeführt werden. Sowohl blau als auch rot hosten Webdienste. Die Außenwelt greift über die entsprechende öffentlich routbare VIP (blaue VIP und rote VIP) auf diese Dienste zu. Der die Netzwerkvirtualisierungsrichtlinie verwendende Lastenausgleich generiert das entsprechende NVGRE-Paket.

Angenommen, für die von der ClientIP initiierte Verbindung und das Senden zur blauen VIP wird ein Lastenausgleich zum blauen VM2 ausgeführt. Der Lastenausgleich muss ein Paket an den blauen VM2 senden, der einen VSID von BlueVSID1, einen KA von 10.1.6.21 und eine Anbieteradresse von 192.168.6.4 aufweist. Die Anbieteradresse des Lastenausgleichs lautet 192.168.6.2. Daher generiert der Lastenausgleich die NVGRE-Paketkopfzeile:

 

MACLB --> MACH1

192.168.6.2 --> 192.168.6.4

BlueVSID1

MACext --> MACVM2

ClientIP --> 10.1.6.21

Nun sehen wir uns das in Abbildung 5 veranschaulichte Szenario näher an, in dem die blauen und roten Kunden über mehrstufige Anwendungen verfügen, für die ein Lastenausgleich erforderlich ist. Aus Sicht der virtuellen Computer kommunizieren sie mit der nächsten Ebene über VIP1. Beispielsweise kommunizieren virtuelle Computer in Ebene B1 mit virtuellen Computern in Ebene B2 über die blaue VIP1. Bei der blauen VIP1 handelt es sich um eine blaue KA-IP-Adresse, die auch über eine entsprechende Anbieteradresse im Lastenausgleich verfügt. Eine mögliche Bereitstellungstopologie wird in Abbildung 6 veranschaulicht.

Abbildung 5: Intern platzierter Lastenausgleich

Abbildung 5: Lastenausgleich zwischen Ebenen (logische Perspektive)

Abbildung 6: Intern platzierter Lastenausgleich

Abbildung 6: Intern im Rechenzentrum platzierter Lastenausgleich

Sowohl die blaue KA-VIP als auch die rote KA-VIP des Lastenausgleichs haben die Anbieteradresse 192.168.6.2. Der Lastenausgleich muss in der VSID im NVGRE-Paket suchen und anschließend die entsprechende VIP zur DIP-Zuordnung bestimmen. Beispielsweise sendet der blaue virtuelle Computer 11 ein Paket an die KA-VIP. Der NVGRE-Paket-Header weist die Quell-IP 192.168.6.7, die Ziel-IP 192.168.6.2, das Feld mit dem GRE-Schlüssel der blauen VSID1, die innere Quell-IP 10.1.5.20, die innere Ziel-IP blaue KA-VIP und den Rest des ursprünglichen Pakets auf. Die Lastenausgleichsrichtlinie muss auf der VSID und der VIP übereinstimmen, da aufgrund der Überlappung der KA-IP-Adressen die VIP an sich nicht eindeutig ist.

Gateways müssen die Hyper-V-Netzwerkvirtualisierungsrichtlinie enthalten und Aktionen ausführen, die einem -Host ähneln. In der typischen Bereitstellung kennt der -Host alle Richtlinieninformationen für jede Routingdomäne für alle sich auf diesem Host befindenden virtuellen Computer. Wenn ein Host beispielsweise über einen virtuellen Computer mit der Routingdomäne X und einen anderen virtuellen Computer von der Routingdomäne Y verfügt, weist der Host die gesamten Richtlinieninformationen für alle virtuellen Subnetze auf, die in der Routingdomäne X und Y enthalten sind. Selbst im Fall einer einzelnen Routingdomäne könnte ein beträchtlicher Richtlinienumfang vorliegen, der auf jedem Hyper-V-Host vorhanden sein müsste.

Ziehen Sie den in Abbildung 1 veranschaulichten Fall einer Private Cloud in Betracht. In diesem Szenario verfügt ein Unternehmen über eine interne Cloud mit einer einzelnen Routingdomäne. In diesem Fall muss jeder Hyper-V-Host über eine Richtlinie für alle virtualisierten Netzwerkcomputer verfügen. Dies kann für die Orchestrierung des Rechenzentrums eine Belastung sein, wenn es darum geht, diese Richtlinie auf allen Hosts zu verwalten. Beachten Sie, dass ein virtueller Computer nur in wenigen Fällen mit sämtlichen anderen virtuellen Subnetzen im Unternehmen kommuniziert, ein derartiger Umfang dieser Richtlinie auf einem angegebenen Host ist in der Praxis nicht erforderlich.

Um den auf jedem Host benötigten Richtlinienumfang zu reduzieren, kann der -Host in einen bestimmten Modus versetzt werden, in dem er den Datenverkehr in einem angegebenen virtuellen Subnetz auf Grundlage seiner eigenen Hostrichtlinie weiterleitet. Sämtlicher Datenverkehr über das virtuelle Subnetz hinweg wird an einen externen Router zwecks Netzwerkvirtualisierungs-Richtlinienüberprüfung gesendet, und das Paket wird potenziell entlang des Pfads zum Ziel weitergeleitet. In einer derartigen Bereitstellung muss der Host die Richtlinie für virtuellen Subnetze der virtuellen Computer kennen, die auf dem Host ausgeführt werden, und nicht für jedes virtuelle Subnetz der Routingdomänen der virtuellen Computer, die auf dem Host ausgeführt werden. In diesem Szenario trifft das Hyper-V-Netzwerkvirtualisierungsgateway sämtliche Entscheidungen in Bezug auf das subnetzübergreifende Routing. Das Hyper-V-Netzwerkvirtualisierungsgateway muss über sämtliche Richtlinieninformationen für alle virtuellen Computer in den virtuellen Subnetzen verfügen, an die es Pakete weiterleitet.

Für jede Hyper-V-Netzwerkvirtualisierungsbereitstellung ist eine Rechenzentrumsorchestrierung erforderlich. Bei System Center Virtual Machine Manager (VMM) handelt es sich um eine Rechenzentrumsorchestrierung. Die Rechenzentrumsorchestrierung ist für das Bereitstellen eines Mechanismus verantwortlich, um die Hyper-V-Netzwerkvirtualisierungsrichtlinien an die entsprechende Gatewayappliance zu senden. Beachten Sie, dass das Anbieteradress-IP-Routing nicht durch die Rechenzentrumsorchestrierung verwaltet wird.

Der Hyper-V-Netzwerkvirtualisierungs-Gatewaypartner sollte eine Verwaltungskonsole für die grundlegende Konfiguration der Gatewayappliance oder der Appliancefunktion bereitstellen. Diese Verwaltungskonsole sollte Vorgänge wie die Anbieteradresszuweisung, hohe Verfügbarkeit, Überwachung und Authentifizierung verarbeiten. Die Verwaltungskonsole ist für das Konfigurieren der Aspekte des Gateways verantwortlich, das nicht durch eine Rechenzentrumsorchestrierung wie VMM verwaltet wird.

Die mithilfe mehrerer physischer Hyper-V-Netzwerkvirtualisierungsgateways erzielte hohe Verfügbarkeit wird in diesem Thema nicht behandelt. Die Rechenzentrumsorchestrierung (beispielsweise VMM) muss das Gateway konfigurieren und verwalten. Szenarien, in denen das Rechenzentrum mehrere Gateways bereitstellt, umfassen Skalierbarkeit und Resilienz. In puncto Skalierbarkeit ist ein einzelnes physisches Gateway möglicherweise nicht in der Lage, die für ein Rechenzentrum erforderliche Last zu verarbeiten. Zusätzlich führt ein einzelnes Gateway einen einzelnen Fehlerpunkt ein. Die Verwaltungskonsole des Partners sollte Bereitstellungen verarbeiten können, die aus mehreren Gateways bestehen.

Im VMM-Modell wird das Hyper-V-Netzwerkvirtualisierungsgateway über ein PowerShell-Plug-In-Modul verwaltet. Partner, die Hyper-V-Netzwerkvirtualisierungsgateways erstellen, müssen ein PowerShell-Plug-In-Modul erstellen, das auf dem VMM-Server physisch ausgeführt wird. Dieses Plug-In-Modul kommuniziert die Richtlinie zum Gateway. Abbildung 7 zeigt ein Blockdiagramm der VMM-Verwaltung einer Hyper-V-Netzwerkvirtualisierungsbereitstellung. Beachten Sie, dass ein Partner-Plug-In auf dem VMM-Server ausgeführt wird. Dieses Plug-In kommuniziert mit den Gatewayappliances. Das für diese Kommunikation verwendete Protokoll ist hier nicht angegeben. Der Partner muss das entsprechende Protokoll möglicherweise bestimmen. Beachten Sie, dass der VMM die Microsoft-Implementierung des WS-Verwaltungsprotokoll namens Windows-Remoteverwaltung (WinRM) und Windows-Verwaltungsinstrumentation (WMI) verwendet, um die Windows Server 2012-Hosts zu verwalten und die Netzwerkvirtualisierungsrichtlinien zu aktualisieren.

Abbildung 7: Verwenden von System Center zur Verwaltung

Abbildung 7: Verwenden von System Center zum Verwalten der Hyper-V-Netzwerkvirtualisierung

kann als die grundlegende Plattform für eine Hyper-V-Netzwerkvirtualisierungs-Gatewayappliance verwendet werden.

Abbildung 8 zeigt die Architektur für den Private Cloud-Router mit als grundlegende Plattform. In diesem Szenario befinden sich alle virtuellen Computer in derselben Routingdomäne. Die roten, blauen und rosafarbenen virtuellen Computer haben jeweils das entsprechende KA-IP-Präfix 157.4, 157.3, 157.2. Die Dienste auf CorpNet verfügen über IP-Adressen mit einem Präfix von 157.1.

Abbildung 8: Gateway der privaten Cloud

Abbildung 8: Privates Cloud-Gateway mit Windows Server 2012

Der WNV-Filter im Gateway empfängt Datenverkehr aus den roten, blauen und rosafarbenen virtuellen Subnetzen und sendet ihn über den übergeordneten (Verwaltung) Betriebssystemstapel an CorpNet. Der virtuelle Switch verfügt über eine übergeordnete (Host) VNIC für die Kommunikation mit dem Host-Betriebssystemstapel aus der virtualisierten Netzwerkwelt. Die andere Netzwerkschnittstelle ist an die physische Netzwerkschnittstelle (pnic2), die mit CorpNet verbunden ist, gebunden. Beachten Sie, dass es keine Anforderung gibt, dass zwei physische Netzwerkschnittstellen im Hyper-V-Netzwerkvirtualisierungsgateway sein müssen (siehe Abbildung 8). Eine einzelne physische Netzwerkschnittstelle könnte zusammen mit zwei übergeordneten virtuellen Netzwerkschnittstellen verwendet werden. Rechenzentrumsadministratoren bevorzugen jedoch möglicherweise eine physische Trennung des Datenverkehrs. Zwei physische Netzwerkschnittstellen im Gateway ermöglichen dem konsolidierten Rechenzentrums- und CorpNet-Datenverkehr, mit dem Gateway über physische Switches zu interagieren. Zwei physische Netzwerkschnittstellen, wobei eine für die virtualisierte Netzwerkwelt und eine für die nicht virtualisierte Netzwerkwelt vorgesehen wäre, brächten eine größere Flexibilität in Kundenbereitstellungen mit sich.

Mit dem Hybrid Cloud-Szenario können Unternehmen ihre lokalen Rechenzentren nahtlos auf die Cloud ausweiten. Hierfür ist ein Standort-zu-Standort-VPN-Tunnel erforderlich. Dies kann mit als die Hostplattform und einem pro Mandant verfügbaren virtuellen -Gastbetriebssystem erzielt werden, auf dem ein S2S-VPN-Tunnel ausgeführt wird (Site To Site, Standort zu Standort), der das Cloudrechenzentrum mit verschiedenen lokalen Rechenzentren verbindet. Das -S2S-VPN unterstützt IKEv2 und die Konfiguration der Remoterichtlinie kann über PowerShell/WMI umgesetzt werden. Zudem unterstützen virtuelle -Gastbetriebssysteme neue Netzwerkschnittstellen-Abladungsfunktionen, die die Leistung und Skalierbarkeit der Gatewayappliance verbessern. Diese Abladungsfunktionen werden unten im Abschnitt „Hardwareanforderungen“ erläutert.

Abbildung 9: Hybrid Cloud mit Windows Server 2012

Abbildung 9: Hybrid Cloud mit auf Windows Server 2012 basierendem Gateway

Abbildung 9 zeigt ein Szenario, in dem das rote und blaue Unternehmen Kunden der Hoster-Cloud sind. Das rote und blaue Unternehmen erweitern ihre Rechenzentren nahtlos in die Hoster-Cloud. hat auf einer Pro-Mandanten-Basis für virtuelle Computergateways bereitgestellt, was dem roten und blauen Unternehmen ermöglicht, ihre lokalen Rechenzentren nahtlos zu erweitern. In Abbildung besteht keine Notwendigkeit, dass das rote oder blaue Unternehmen das -S2S-VPN ausführt, sondern nur, dass das lokale S2S-VPN IKEv2 unterstützt, um mit entsprechenden virtuellen -S2S-Computern interagieren zu können, die auf HostGW ausgeführt werden.

Abbildung 9 zeigt die interne Architektur für HostGW. Für jede Routingdomäne ist ein eigener virtueller Computer erforderlich. Technisch gesehen begründet sich dies darin, dass eine vmnic (Netzwerkkarte eines virtuellen Computers) nur mit einem einzelnen VSID (virtuelles Subnetz) verknüpft werden kann und eine VSID nur ein Teil einer einzelnen Routingdomäne sein kann. Die VSID-Switchport-Zugriffssteuerungsliste unterstützt nicht das Trunking von VSIDs. Daher besteht der einfachste Weg darin, die Isolierung mit einem virtuellen Pro-Mandanten-Gatewaycomputer (Routingdomäne) bereitzustellen.

Jeder virtuelle Computer wird zweifach verwaltet, d. h., sie haben zwei virtuelle Netzwerkschnittstellen. Eine der virtuellen Netzwerkschnittstellen verfügt über eine entsprechend verknüpfte VSID. Die andere virtuelle Netzwerkschnittstelle hat eine VSID von 0. Datenverkehr wird demnach nicht durch den WNV-Filter geändert. Auf dem virtuellen -Computer wird RRAS ausgeführt und IKEv2 verwendet, um einen sicheren Tunnel zwischen der Hoster-Cloud und dem lokalen Gateway des Kunden zu erstellen.

Abbildung 10: Hybrid Cloud mit Windows Server 2012

Abbildung 10: Hybrid Cloud auf Basis virtueller Windows Server 2012-Pro-Mandanten-Computergateways

Abbildung 10 zeigt die Architektur, in der VMM eine Hyper-V-Netzwerkvirtualisierungsbereitstellung verwaltet. Der Partner verfügt über ein Plug-In, das auf dem VMM-Server ausgeführt wird. Beim Verwenden von Windows Server 2012 als eine Hyper-V-Netzwerkvirtualisierungs-Gatewayappliance ist ein lokaler Verwaltungsprozess, der in Windows ausgeführt wird, als Endpunkt für diese Kommunikation aus dem Plug-In erforderlich, das auf dem VMM-Server ausgeführt wird. Auf diese Weise kann das Plug-In die Netzwerkvirtualisierungsrichtlinie an den WNV-Filter kommunizieren, der auf HostGW ausgeführt wird.

Die Skalierbarkeit der auf basierenden Gatewayappliance wird durch die Serverhardware bestimmt, dazu zählen:

  • NUMA-Funktionen

  • Anzahl der CPU-Kerne

  • Arbeitsspeicher

  • Abladungsfunktionen und Leistung der Netzwerkschnittstellen

Allgemein sollte eine durch die wichtigsten OEMs bereitgestellte Dual-Socket-Serverplattform eine ausreichende Basisplattform darstellen. Die Anzahl der virtuellen Computer, die effektiv auf der Serverappliance ausgeführt werden können, wird für gewöhnlich durch den Arbeitsspeicher auf dem Server bestimmt.

Die Auswahl der Netzwerkschnittstellen kann auch eine deutliche Auswirkung auf die Leistung und Skalierbarkeit der Gatewayappliance haben. Abbildung 10 zeigt eine Konfiguration mit zwei Netzwerkschnittstellen. Beachten Sie, dass der GESAMTE Datenverkehr, der im virtuellen Subnetzpfad gesendet wird, NVGRE-Datenverkehr ist. Für gekapselte Pakete bieten herkömmliche Abladungen wie die Große Sendeabladung (Large Send Offload, LSO) auf dem Sendepfad und Warteschlangen für virtuelle Computer (Virtual Machine Queues, VMQ) auf dem Empfängerpfad nicht die gewünschten Vorteil, dass sie auf der äußeren Paketkopfzeile agieren. Die äußere Kopfzeile für den NVGRE-Datenverkehr vermittelt den Eindruck, dass der gesamte Datenverkehr mithilfe derselben IP-Adresse generiert wird und für eine einzelne IP-Adresse bestimmt ist. Netzwerkschnittstellenabladungen bieten einen beträchtlichen Vorteil, wenn es um die Hyper-V-Switchleistung geht. Bei der GRE-Aufgabenabladung handelt es sich um ein neues Feature in . Darin agiert die Netzwerkschnittstelle in der inneren Paketkopfzeile für standardmäßige Abladungen, sodass LSO und VMQ ihre erwarteten Leistungs- und Skalierbarkeitsvorteile bereitstellen können. Daher sollte die Netzwerkschnittstelle auf dem Pfad für virtuelle Subnetze die GRE-Aufgabenabladung unterstützen (siehe Abbildung 10). Derlei Netzwerkschnittstellen sollten Ende 2012 kommerziell verfügbar sein.

Bei IPsec Task Offload handelt es sich um ein weiteres neues in verfügbares Feature für Gastbetriebssysteme. IPsec wird für das Sichern der S2S-VPN-Tunnel verwendet. Beide Seiten des S2S-Tunnels müssen IKEv2 unterstützen. Wenn das standortübergreifende Gateway NICHT hinter einer NAT liegt, kann IPsec Task Offload (IPsecTO) eine bessere Leistung bereitstellen, indem die Netzwerkschnittstelle des externen Netzwerks (siehe Abbildung 9) die Pro-Paket-Verschlüsselungsvorgänge im Auftrag der virtuellen Pro-Mandanten-RRAS-Computer ausführt. Beide Seiten des S2S-Tunnels müssten AES-GCM128 verwenden, um von IPsecTO profitieren zu können. Daher müssen die folgenden Bedingungen für den virtuellen RRAS-Computer erfüllt sein, um von IPsecTO zu profitieren:

  • Beide Seiten des S2S-Tunnels müssen AES-GCM128 verwenden.

  • Die Gatewayappliance darf nicht hinter einer NAT liegen.

Da IPsec-Vorgänge eine starke CPU-Auslastung verursachen können, kann IPsecTO eine erhebliche CPU-Reduzierung mit sich bringen und auch den Netzwerkdurchsatz verbessern.

SR-IOV ist ein neues -Feature, das eine physische Netzwerkschnittstelle dem virtuellen Computer direkt zur Verfügung stellt. SR-IOV umgeht den virtuellen Switch. Unglücklicherweise unterstützen aktuelle IPsecTO-Netzwerkschnittstellen auf dem Markt IPsecTO nicht auf dem SR-IOV-Pfad. Der -Hyper-V-Switch führt neue richtlinienbasierte Features wie Zugriffssteuerungslisten und QoS ein. Wenn eine dieser Hyper-V-Switchrichtlinien auf einer virtuellen Netzwerkschnittstelle eingesetzt wird, nimmt der virtuelle Netzwerkschnittstellen-Datenverkehr nicht den SR-IOV-Pfad, sondern nimmt den Hyper-V-Switchpfad für die Richtlinienerzwingung. Wenn der Datenverkehr anstelle des Hyper-V-Switchpfads den SR-IOV-Pfad nimmt, hat dies eine deutliche Reduzierung in puncto CPU-Auslastung zur Folge.

Beim Private Cloud-Gateway sollten ähnliche Überlegungen in Bezug auf die Hardwareanforderungen vorgenommen werden.

Zusätzliche Ressourcen in Bezug auf die Hyper-V-Netzwerkvirtualisierung und System Center Virtual Machine Manager sind den folgenden Artikeln (Artikel ohne Links werden noch vorbereitet) zu entnehmen:

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

Community-Beiträge

Anzeigen:
© 2015 Microsoft