hybrid cloud mit nvgre (ws sc 2012...
TRANSCRIPT
Hybrid Cloud mit NVGRE (WS SC 2012 R2)
Autoren:
Kristian Nese, Cloud & Datacenter Management MVP @KristianNese
Flemming Riis Cloud & Datacenter Management MVP @FlemmingRiis
Reviewers:
Daniel Neumann, Cloud & Datacenter Management MVP @neumanndaniel
Stanislav Zhelyazkov, Cloud & Datacenter Management MVP @StanZhelyazkov
Übersetzung ins Deutsche:
Daniel Neumann, Cloud & Datacenter Management MVP @neumanndaniel
Danksagungen: Dank an Travis Wright, Christian Booth, Vijay Tewari und speziell Greg Cusanza für die stete
Unterstützung. Dieses Whitepaper wäre ohne eure Unterstützung nie entstanden.
Auch danke an Damian Flynn für die Diskussionen über das Thema und für das Vorantreiben dieser
Technologie in der Community auf einer täglichen Basis und Marc van Eijk für seine Erfahrungen aus
der Praxis.
Inhalt Autoren: .................................................................................................................................................. 1
Reviewers: ............................................................................................................................................... 1
Übersetzung ins Deutsche: ...................................................................................................................... 1
Danksagungen: ........................................................................................................................................ 2
Hybrid Cloud mit NVGRE (WS SC 2012 R2).............................................................................................. 5
Einführung ............................................................................................................................................... 5
Unternehmensziele ................................................................................................................................. 5
Technische Beschreibung ........................................................................................................................ 6
Implementierung einer Hybrid Cloud mit Windows Server 2012 R2 und System Center 2012 R2 –
Virtual Machine Manager ........................................................................................................................ 7
Konfiguration und Modellierung der Logical Networks in der Fabric ................................................... 10
Schritt 1 ................................................................................................................................................. 11
Konfiguration der Management, Front-end, Cluster und Live Migration Netzwerke in der Fabric ...... 11
Schritt 2 ................................................................................................................................................. 12
Erstellen der IP-Adresspools für die Netzwerke Management, Front-end, Cluster und Live Migration
............................................................................................................................................................... 12
Schritt 3 ................................................................................................................................................. 17
Erstellen des Provider Address Logical Network für die Netzwerkvirtualisierung ................................ 17
Schritt 4 ................................................................................................................................................. 18
Erstellen und Zuweisen eines IP-Adresspools für das Provider Address Netzwerk .............................. 18
Schritt 5 ................................................................................................................................................. 21
Erstellen der Logical Switches mit Port Profilen .................................................................................... 21
Schritt 6 ................................................................................................................................................. 40
Erstellen der VM Networks ................................................................................................................... 40
Schritt 8 ................................................................................................................................................. 41
Netzwerkkonfiguration der Hosts ......................................................................................................... 41
Schritt 8 ................................................................................................................................................. 46
Konfiguration des Gateway Hosts ......................................................................................................... 46
Schritt 9 ................................................................................................................................................. 47
Erstellen der Netzwerkvirtualisierungsgateway – Service Template für nicht hochverfügbare
Virtualisierungsgateways ...................................................................................................................... 47
Schritt 10 ............................................................................................................................................... 52
Nachkonfiguration des Virtualisierungsgateway Service ...................................................................... 52
Schritt 10.1 ............................................................................................................................................ 54
Erstellen der Netzwerkvirtualisierungsgateway – Service Template für hochverfügbare
Virtualisierungsgateways ...................................................................................................................... 54
Schritt 11 ............................................................................................................................................... 56
Hinzufügen des Virtualisierungsgateway Network Service im VMM .................................................... 56
Schritt 12 ............................................................................................................................................... 63
Erstellen des VM Networks mit NAT ..................................................................................................... 63
Schritt 13 ............................................................................................................................................... 73
Bereitstellen von virtuellen Maschinen, die mit dem VM Network verbunden sind ........................... 73
Schritt 14 ............................................................................................................................................... 78
Überprüfen der Verbindung und Troubleshooting ............................................................................... 78
Troubleshooting und FAQ ..................................................................................................................... 88
Feedback und Kontakt: .......................................................................................................................... 94
Hybrid Cloud mit NVGRE (WS SC 2012 R2)
Die Netzwerkvirtualisierung wurde erstmals in Windows Server 2012 und System Center 2012 SP1 –
Virtual Machine Manager eingeführt.
In der kommenden Version R2 von Windows Server 2012 und System Center 2012 wurden einige
wesentliche Verbesserungen im Bereich Netzwerkvirtualisierung mit NVGRE vorgenommen. Zu dem
beinhaltet Windows Server 2012 R2 ein natives Virtualisierungsgateway mit der Routing und Remote
Access Server Rolle, welches Multi-Tenant Site-2-Site VPN, NAT und BGP unterstützt.
Dieses Whitepaper soll die Bereitstellung einer Fabric Infrastruktur, die die Netzwerkvirtualisierung
mit NVGRE für Hybrid Cloud Computing unterstützt, zeigen.
Einführung
Wir alle kennen das Konzept der Servervirtualisierung, die es ermöglicht gleichzeitig mehrere
Serverinstanzen auf einem physischen Host laufen lassen zu können, und eine komplette Isolierung
dieser Instanzen untereinander gewährleistet, obwohl alle die gleichen physischen Ressourcen teilen.
Die Netzwerkvirtualisierung basiert auf genau demselben Konzept.
Die Industrie bewegt sich in Richtung Cloud Computing und ein wichtiger Erfolgsfaktor dafür ist die
Umsetzung von Software-Defined Datacenters. Vor allem Software-Defined Networking ist ein
wesentlicher Bestandteil davon, um eine Hybrid Cloud Umgebung bereitzustellen, in der die
Mandanten nicht nur ihre eigenen IP-Adressen, sondern auch ihr eigene Netzwerktopologie
verwenden können, da die virtualisierten Netzwerke von dem darunterliegenden Fabric Netzwerk
abstrahiert sind. Diese Abstrahierung gibt den virtuellen Maschinen vor, dass sie sich in einem
physischen Netzwerk befinden, obwohl sie von diesem vollständig isoliert sind.
Unternehmensziele
Die Netzwerkvirtualisierung ist eine Grundvoraussetzung für die Multimandantenfähigkeit, kann aber
auch für andere Ziele Verwendung finden, wie unten beschrieben:
Unternehmen
In einer Private Cloud kann eine Rechenzentrumskonsolidierung mithilfe der
Netzwerkvirtualisierung leichter erreicht werden.
Erhöhte Integration der erworbenen Unternehmensnetzwerkinfrastruktur.
Erweiterung des Rechenzentrums hinein in die Hybrid Cloud
Service-Provider
Mandanten können ihre eigene Netzwerktopologie einbringen und schließlich ihre eigenen
Netzwerke (VM Networks) verwalten.
Das sichere Teilen eines physischen Netzwerks über mehrere Mandanten hinweg.
Mandanten
Nahtlose Migration in die Cloud
Verschieben von n-Tier Topologien in die Cloud
Erhaltung von Richtlinien, VM Einstellungen und IP-Adressen
Cloud- und Rechenzentrenadministratoren
Die Entkopplung der Rollen von Server- und Netzwerkadministration erhöht die Agilität
Flexible Platzierung von VMs ohne Neukonfiguration des Netzwerks
Reduzierung der Kosten für Verwaltung und Support
Wenn wir wieder zu den Grundlagen zurückkehren und uns die Definition des Cloud Computing
anschauen, dann sehen wir die wesentlichen Merkmale, die Broad Network Access, Elasticity,
Resource Pooling und Self-Service mit einbeziehen.
Software-Defined Datacenters sind der Schlüssel dazu sowie eine Infrastruktur, die die hohe Dichte
an Flexibilität unterstützt, die erforderlich ist.
Technische Beschreibung
Das Konzept der Netzwerkvirtualisierung besteht aus den sogenannten Customer Addresses,
Provider Addresses, Virtual Subnet IDs und Routing Domains.
Es folgt die Einführung und Erläuterung der Customer Addresses, Provider Addresses, Virtual
Subnet IDs und Routing Domains.
Eine Customer-Address (CA) wird vom Mandanten auf Basis seiner Subnetze, seiner IP-
Adressbereiche und seiner Networktopologie zugewiesen. Diese Adresse ist nur für die virtuelle
Maschine und alle anderen virtuellen Maschinen innerhalb desselben Subnetzes/VM Network
sichtbar, wenn das Routing erlaubt ist. Es ist zu beachten, dass die CA nur für die VM sichtbar ist und
nicht für die darunterliegende Netzwerkinfrastruktur.
Eine Provider-Address (PA) wird entweder vom Administrator oder vom System Center Virtual
Machine Manager basierend auf der physischen Netzwerkinfrastruktur zugewiesen. Die PA ist nur für
das physische Netzwerk sichtbar und wird für den Austausch von Paketen zwischen Hyper-V Hosts
(Standalone oder Cluster) & anderen Geräten verwendet, die an der Netzwerkvirtualisierung beteiligt
sind.
Virtual Subnets werden über eine eindeutige Virtual Subnet ID (VSID) identifiziert. Dieses Konzept ist
identisch mit der VLAN-Technologie, die ein IP-Subnetz auf Layer 3 Ebene und eine Broadcast Domain
Boundary auf Layer 2 Ebene definiert. Die Virtual Subnet ID (VSID) muss innerhalb des
Rechenzentrums eindeutig sein und befindet sich im Bereich von 4096 bis 224-2.
Routing Domains definieren eine Beziehung zwischen den Virtual Subnets, die von den Mandanten
erstellt wurden, und identifizieren die VM Networks. Die Routing Domain ID (RDID) hat eine Globally
Unique ID (GUID) innerhalb des Rechenzentrums. Der Stack der Netzwerkvirtualisierung ermöglicht
ein Layer 3 Routing zwischen diesen Subnetzen mit einem Standardgateway (immer x.x.x.1), das
weder deaktiviert noch konfiguriert werden kann.
Diese Konzepte werden wir später in diesem Handbuch bei der Konfiguration der
Netzwerkvirtualisierung mit SC 2012 R2 VMM behandeln.
Es folgt die Erläuterung der Netzwerkvirtualisierung mit GRE (NVGRE).
Die Netzwerkvirtualisierung in Windows Server 2012 R2 (NVGRE) verwendet das GRE Protokoll
(http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-03). NVGRE ist für die meisten
Rechenzentren vorgesehen, um die Netzwerkvirtualisierung bereitzustellen. Die Pakete werden in
einem anderen Paket gekapselt (Stichwort „Briefumschlag“), und der Header dieses neuen Pakets
enthält die entsprechende Quell und Ziel PA IP-Adresse neben der Virtual Subnet ID, die im GRE
Header gespeichert wird.
Die Virtual Subnet ID, die im GRE Header enthalten ist, ermöglicht es den Hosts die virtuellen
Maschinen der Mandanten für jedes angegebene Paket zu identifizieren. Da dies eine auf Richtlinien
basierte Lösung ist, können sich Provider Addresses und Customer Addresses ohne Probleme in den
Paketen überschneiden. Dies bedeutet, dass sich alle virtuellen Maschinen auf demselben Host eine
Provider Address teilen. Dies führt gleichzeitig zu einer großen Skalierbarkeit als auch Einfachheit
innerhalb der Verwaltung und der Bereitstellung.
Implementierung einer Hybrid Cloud mit Windows Server 2012 R2 und
System Center 2012 R2 – Virtual Machine Manager
Eines der Ziele dieses Whitepapers ist es zu demonstrieren, wie man dies in einem realen Szenario
mit den folgenden Technologien implementiert:
NIC-Teaming (WS 2012 R2)
QoS (WS 2012 R2)
Virtual Switch Erweiterungen (WS 2012 R2)
Virtualisierungsgateway mit RRAS (WS 2012 R2)
Hyper-V Netzwerkvirtualisierung (WS 2012 R2)
Logical Networks (VMM 2012 R2)
Port Profile (VMM 2012 R2)
Logical Switches (VMM 2012 R2)
Netzwerkdienste (VMM 2012 R2)
Service Templates (VMM 2012 R2)
Voraussetzungen:
Ein oder mehrere dedizierte physische Server die mit Windows Server 2012 R2 und der
Hyper-V Rolle betrieben werden. Dieser dedizierte Host oder diese dedizierten Hosts
werden für den Betrieb der virtuellen Maschine verwendet, die als Virtualisierungsgateway
dient.
Einen oder mehrere physische Server die mit Windows Server 2012 R2 und der Hyper-Rolle
betrieben werden. Dieser oder diese Server werden für den Betrieb der virtuellen
Maschinen verwendet, die die virtualisierten Netzwerke nutzen.
Ein physischer Switch, der die VLAN-Technologie unterstützt, so dass Converged Networks
mit WS SC 2012 R2 verwendet werden können.
Eine oder mehrere öffentliche IP-Adressen.
Eine virtuelle Maschine mit installiertem Windows Server 2012 R2 und System Center 2012
R2 – Virtual Machine Manager.
Eine Active Directory Domäne mit DNS für die VMM und Fabric Ressourcen.
Topologie
Die Umgebung besteht aus mehreren Computern (Hyper-V Server, sowohl Standalone als auch im
Cluster), zusätzlich zur DR Site und den dedizierten Hosts für die Netwerkvirtualisierung.
Alles wird mittels Virtual Machine Manager konfiguriert und bereitgestellt um sicherzustellen, dass
die Virtualisierungsrichtlinien korrekt implementiert sind und für die gesamte Umgebung verwaltet
werden.
Abbildung 1 - Physische Umgebung
Auf Hardwareseite stehen 4 Blades HV01-HV04 in einem Failover Cluster mit Shared Storage zur
Verfügung, der sich auf einem HP EVA SAN mit Fibre Channel Anbindung befindet. HVDR01/HVDR02
sind die letzten Blades in dieser Umgebung, die dediziert für die Hyper-V Replica Verwendung finden.
Diese Server werden in diesem Dokument nicht weiter behandelt.
Alle Uplink Ports des Bladecenters gehen in einen HP Layer 3 Managed Switch. Für produktive
Umgebungen sind redundante Switche und separate Netzwerkschnittstellen für den NVGRE Verkehr
empfohlen.
Die beiden Gateway Hosts verwenden Shared Storage und besitzen eine dedizierte Netzwerkkarte für
den Internetverkehr.
Die Hosts sind bereits bereitgestellt und werden vom VMM in der folgenden Hostgruppenstruktur
verwaltet:
Abbildung 2 - Logischer Überblick der Hostgruppen im VMM 2012 R2
Gateway ist die Hostgruppe mit den dedizierten Hosts für die Netzwerkvirtualisierung. Da man das
native Virtualisierungsgateway des Windows Server 2012 R2 verwendet, muss ein dedizierter Host
dafür verwendet werden, um die Netzwerkvirtualisierungsrichtlinien pflegen zu können.
Die Hostgruppe in der Umgebung heißt deshalb Gateway um zu zeigen, dass die Hosts in dieser
Hostgruppe sich außerhalb der Domäne befinden. Als Best Practice sollten die dedizierten Hosts nicht
mit derselben Domäne verbunden sein wie der VMM, da diese Hosts eine direkte Verbindung ins
Internet haben können. Jedoch müssen die virtuellen Maschinen, die für die Netzwerkvirtualisierung
Verwendung finden, mit der Domäne, in der sich der VMM befindet, verbunden sein. Als Best Practice
sollten die Gateway VMs in einem Hyper-V Failover Cluster betrieben werden, so dass auf VM Level
die Hochverfügbarkeit gewährleistet ist. Ebenfalls sollte auch ein HA Service Template bereitgestellt
werden, um die Hochverfügbarkeit auch auf Applikationsebene zu gewährleisten.
Production ist die Hostgruppe, die Hyper-V Failover Cluster enthält. Optionen wie Dynamic
Optimization und Power Optimization sind aktiviert.
Research & Development ist die Hostgruppe, die Hyper-V Server enthält, die für Test- und
Entwicklungszwecke verwendet werden.
Konfiguration und Modellierung der Logical Networks in der Fabric
In dieser Anleitung wird gezeigt, wie man sein Logical Network im VMM abbildet, um in der Fabric
Converged Network (NIC-Teaming, QoS und virtuelle Adapter) zu unterstützen und die
Netzwerkvirtualisierung zu nutzen.
Die Hyper-V Server in dieser Umgebung verwenden 2 x 10GBe und diese NICs sollen in einem Team
zusammengefasst werden, um QoS und Converged Networking zu nutzen. Jeder Host ist dabei mit
demselben physischen Switch verbunden, besitzt eine statische IP-Konfiguration auf einer der NICs,
so dass dieser mit der Domäne verbunden und mit dem VMM verwaltet wird.
Abbildung 3 - NICs auf einem der Hosts ohne Teaming
Zuerst müssen die Logical Networks im VMM erstellt werden.
Ein Logical Network kann mit einer oder mehreren Network Sites assoziiert sein. Diese sind
benutzerdefinierte und benannte Gruppen von IP-Subnetzen, VLANs oder IP-Subnetz/VLAN Paaren,
die verwendet werden, um die Netzwerkzuordnung zu organisieren und zu vereinfachen. In großen
Umgebungen ist dies sehr nützlich, da die Netzwerkkonnektivität und die Abhängigkeiten innerhalb
der Konfiguration abgebildet und bereitgestellt werden können.
Wir werden mehrere Logical Networks für unterschiedliche Verwendungszwecke erstellen.
Logical Networks:
Management
o Enthält das IP-Subnetz für die Verwaltung. Normalerweise sind der VMM und die
Hyper-V Server mit diesem physischen Netzwerk verbunden. Wenn mehrere Sites
und/oder VLANs vorhanden sind, können alle demselben Logical Network
zugeordnet werden.
o Dieses Netzwerk hat zudem einen zugeordneten IP-Adresspool, so dass der VMM die
IP-Adresszuweisung für Hosts, Cluster und andere Ressourcen, die mit diesem
Netzwerk verbunden sind, vornehmen kann.
Cluster
o Enthält das IP-Subnetz und das VLAN für die Cluster Kommunikation. Dieses
Netzwerk ist nicht routingfähig. Die Kommunikation erfolgt nur innerhalb desselben
VLAN.
o Dieses Netzwerk hat zudem einen zugeordneten IP-Adresspool, so dass der VMM die
IP-Adresszuweisung für Hosts, Cluster und andere Ressourcen, die mit diesem
Netzwerk verbunden sind, vornehmen kann.
Live Migration
o Enthält das IP-Subnetz und das VLAN für die Live Migration Kommunikation. Dieses
Netzwerk ist nicht routingfähig. Die Kommunikation erfolgt nur innerhalb desselben
VLAN.
o Dieses Netzwerk hat zudem einen zugeordneten IP-Adresspool, so dass der VMM die
IP-Adresszuweisung für Hosts, Cluster und andere Ressourcen, die mit diesem
Netzwerk verbunden sind, vornehmen kann.
Front-end
o Enthält das IP-Subnetz, welches für die öffentlichen IP-Adressen verwendet wird.
o Dieses Netzwerk hat zudem einen zugeordneten IP-Adresspool, so dass der VMM die
IP-Adresszuweisung für die Virtualisierungsgateways, die mit diesem Netzwerk
verbunden sind, vornehmen kann.
PA network
o Enthält das IP-Subnetz, welches für die Provider Addresses verwendet wird. Dieses
Netzwerk wird ausschließlich für die Netzwerkvirtualisierung verwendet und hat die
entsprechende Option auf der Ebene des Logical Network gesetzt. Besonders wichtig
ist es dieses Netzwerk zu isolieren und nicht die anderen Netzwerke für diesen Zweck
zu verwenden.
o Dieses Netzwerk hat zudem einen zugeordneten IP-Adresspool, so dass der VMM die
IP-Adresszuweisung für Hosts, die für die Netzwerkvirtualisierung vorgesehen sind,
Virtualisierungsgateway VMs und Virtualisierungshosts mit VMs, die mit einem VM
Network verbunden sind, vornehmen kann.
Schritt 1
Konfiguration der Management, Front-end, Cluster und Live Migration
Netzwerke in der Fabric
1) Aufrufen des Abschnitts Fabric in der VMM Konsole
2) Erweitern der Registerkarte Networking und ein Rechtsklick auf Logical Networks, um ein
neues Logical Network zu erstellen
3) Zuweisen des Namens und der Beschreibung. Außerdem muss sichergestellt sein, dass nur
die Optionen „One connected network“ und „Create a VM network with the same name to
allow virtual machines to access this logical network directly“ ausgewählt sind. Es folgt ein
Klick auf weiter, um fortzufahren.
4) Erstellen der Network Site, des IP-Subnetzes und des VLAN sowie der Zuordnung zu den
Hostgruppen. In diesem Beispiel wird das Standard VLAN (VLAN ID 0), das IP-Subnetz
10.0.0.0/24 verwendet und die Konfiguration jeder Hostgruppe zugeordnet, da alle Hosts
Zugriff auf das Management Netzwerk haben sollen. Es folgt ein Klick auf weiter, um die
Konfiguration abzuschließen.
Dieser Vorgang wiederholt sich für die Logical Networks Front-end, Cluster und Live Migration. Das
Erstellen des Logical Network für die PA-Adressen erfolgt später.
Hinweis: Wenn die Logical Networks Cluster und Live Migration zugeordnet werden,
können die Hostgruppen ausgelassen werden, die diese Netzwerke nicht benötigen.
Als Best-Practice gilt, dass man die Netzwerke entsprechend auf die Hostgruppen
anwendet, die diese benötigen.
Schritt 2
Erstellen der IP-Adresspools für die Netzwerke Management, Front-
end, Cluster und Live Migration
Als nächstes werden die IP-Adresspools für jede Logical Network Site angelegt, so dass der VMM die
richtige IP-Konfiguration den Ressourcen innerhalb dieses Netzwerks zuweisen kann. Der Vorteil
dieses großartigen Features im VMM ist es, dass man keine manuelle Konfiguration vornehmen oder
man auf andere Dienste wie zum Beispiel DHCP setzen muss. Es können auch IP-Adressen
ausgeschlossen werden, die bereits anderen Ressourcen zugeordnet worden sind.
1) Rechtsklick auf das Logical Network Management in der Fabric und ein Klick auf „Create IP
pool“.
2) Zuweisen des Namens und der Beschreibung. Außerdem muss sichergestellt sein, dass der IP-
Adresspool dem richtigen Logical Network zugeordnet wird.
3) Auswählen der Network Site und des IP-Subnetzes. Am besten hier „Use an existing network
site“ anklicken, so dass man die Network Site auswählen kann, die schon erstellt wurde.
4) Festlegen des IP-Adressbereichs. Hier die Start- und End-IP-Adresse bestimmen. Außerdem
können IP-Adressen für VIP-Templates und andere Zwecke reserviert werden.
5) Festlegen des Gateways.
6) Festlegen der DNS-Server und der DNS Suffixe.
7) Wenn WINS benötigt wird, können im nächsten Schritt auch noch die WINS-Server
angegeben werden.
Dieser Vorgang wiederholt sich für die IP-Adresspools Front-end, Cluster und Live Migration. Nicht
routingfähige Netzwerke wie Cluster und Live Migration benötigen keine Angabe des Gateways,
der DNS-Server oder WINS-Server.
Schritt 3
Erstellen des Provider Address Logical Network für die
Netzwerkvirtualisierung
1) Aufrufen des Abschnitts Fabric in der VMM Konsole
2) Erweitern der Registerkarte Networking und ein Rechtsklick auf Logical Networks, um ein
neues Logical Network zu erstellen
3) Zuweisen des Namens und der Beschreibung. Außerdem muss sichergestellt sein, dass neben
der Option „One connected network“ zusätzlich die Option „Allow new VM networks
created on this logical network to use network virtualization“ ausgewählt ist und als
Standardtechnologie „Hyper-V Network Virtualization“ angezeigt wird.
4) Als nächstes erfolgt das Erstellen einer Site, die das IP-Subnetz und VLAN für das PA
Netzwerk enthält. Diese Network Site sollte nur mit den Hostgruppen assoziiert werden, die
die Virtualisierungsgateways oder die virtuellen Maschinen, die die Netzwerkvirtualisierung
verwenden, betreiben.
Wichtiger Hinweis: Im weiteren Verlauf dieses Handbuchs wird man feststellen, dass die
Hosts keine direkte Zuordnung zu dem PA Netzwerk haben. Dieses wird nur durch diese
Konfiguration zusammen mit dem Uplink Port Profiles und den Logical Switches den Hosts
zur Verfügung gestellt. Des Weiteren sollte sichergestellt sein, dass die
Netzwerkvirtualisierung auf keinem anderen Logical Network aktiv ist, welches den Hosts
präsentiert wird. Dies kann eine Fehlkonfiguration verursachen und zu stundenlangem
Troubleshooting führen.
Schritt 4
Erstellen und Zuweisen eines IP-Adresspools für das Provider Address
Netzwerk
1) Rechtsklick auf das Logical Network PA Network in der Fabric und ein Klick auf „Create IP
pool“.
2) Zuweisen des Namens und der Beschreibung. Außerdem muss sichergestellt sein, dass der IP-
Adresspool dem richtigen Logical Network zugeordnet wird.
3) Sicherstellen, dass die richtige Network Site verwendet wird.
4) Festlegen des IP-Adressbereichs mit Start- und End-IP-Adresse.
5) Wenn es sich um ein nicht routingfähiges Netzwerk handelt können die Einstellungen
bezüglich des Gateways, der DNS-Server und WINS-Server ignoriert werden.
Es sollten jetzt alle erforderlichen Logical Networks, IP-Subnetze, VLANs und IP-Adresspools im Fabric
Workspace des VMM konfiguriert sein, die die tatsächliche Netzwerkkonfiguration wiederspiegeln.
Abbildung 4 - Überblick über die Logical Network Konfiguration und der dazugehörigen IP-Adresspools
Schritt 5
Erstellen der Logical Switches mit Port Profilen
Nach dem Erstellen der Logical Networks müssen identische Funktionen für die Netzwerkadapter
über mehrere Hosts bereitgestellt werden. Um dies zu erreichen werden Port Profiles und Logical
Switches verwendet. Port Profiles und Logical Switches dienen dabei als Container für die
Eigenschaften und Funktionen mit denen die Netzwerkadapter ausgestattet werden sollen. Anstatt
für jeden Netzwerkadapter eigene Eigenschaften und Funktionen zu definieren, kann dies zentral
über Port Profiles und Logical Switches erfolgen, die dann auf die entsprechenden Adapter
angewendet werden. Durch diese beiden Komponenten vereinfacht sich der Konfigurationsprozess
und stellt gleichzeitig sicher, dass die Hosts den korrekten Algorithmus zur Lastverteilung und die
virtuellen Adapter die richtigen Einstellungen in Bezug auf ihre Funktionalität und QoS verwenden.
In dieser Umgebung wird die native NIC-Teaming Unterstützung des Windows Server genutzt.
Der Standardalgorithmus, der für das NIC-Teaming genutzt wird, ist der Switch-Independent Modus,
wo der Switch nicht in Kenntnis ist, welche NIC Adapter sich in einem Team befinden. Die NICs selber
können an verschiedene Switche angeschlossen sein.
Der Switch-Dependent Modus setzt voraus, dass alle NIC Adapter eines Teams mit demselben Switch
verbunden sind. Die Wahl für den Switch-Dependent Modus ist generisches oder statisches Teaming
(IEEE 802.3ad draft v1). Was voraussetzt, dass eine Konfiguration auf Seite des Switch und des
Computers erfolgt ist, um die Verbindungen zu identifizieren, die das Team bilden. Da dies eine
statische Konfiguration ist, stehen keine weiteren Verfahren zur Unterstützung zur Verfügung, die ein
falsch angeschlossenes Kabel oder ein ungewöhnliches Verhalten erkennen können.
Das dynamische Teaming (IEEE 802.1ax, LACP) verwendet das Link Aggregation Control Protocol zur
dynamischen Erkennung der Verbindungen zwischen dem Switch und dem Computer. Dadurch ist die
Möglichkeit gegeben, dass Team automatisch erstellen zu lassen, als auch es zu verkleinern oder zu
erweitern.
Windows Server 2012 R2 unterstützt drei verschiedene Distributionsmethoden.
Hashing, Hyper-V Port und Dynamic.
Hyper-V Port
Wenn virtuelle Maschinen über individuelle MAC-Adressen verfügen, dann stellt die MAC-Adresse
die Grundlage für die Verteilung des Netzwerkverkehrs dar. Der Switch kann somit feststellen, dass
die spezifische Quell MAC-Adresse nur einem Netzwerkadapter zu geordnet ist, somit ist der Switch
in der Lage die Last (Netzwerkverkehr vom Switch zum Computer), basierend auf der Ziel MAC-
Adresse für die VM, auf mehrere Verbindungen zu verteilen.
Hashing
Der Hashing Algorithmus erstellt einen Hashwert basierend auf den Komponenten des Paketes und
weist den Paketen mit dem Hashwert einen verfügbaren Netzwerkadapter zu. Dadurch wird
sichergestellt, dass Pakete von dem gleichen TCP-Stream denselben Netzwerkadapter nutzen.
Die folgenden Komponenten können für die Hash-Funktionen als Ausgangsbasis verwendet werden:
Quell und Ziel IP-Adresse, mit oder ohne Beachtung der MAC-Adressen (2-Tupel Hash)
Quell und Ziel TCP-Port, meistens zusammen mit den IP-Adressen (4-Tupel Hash)
Quell und Ziel MAC-Adresse
Dynamic (Neu in Windows Server 2012 R2)
Lastverteilung basiert auf sogenannten Flowlets
Optimiert die Auslastung eines Teams mit der vorhandenen Hardware
Das Dynamic Load Balancing verteilt laufend und automatisch den Netzwerkverkehr über alle
Netzwerkkarten im NIC-Team, um eine gleichbleibende Verteilung des Netzwerkverkehrs soweit wie
möglich zu gewährleisten.
Um das NIC-Teaming in einer Hyper-V Umgebung zu verwenden, gibt es einige neue Features in der
PowerShell, um den Netzwerkverkehr mit QoS zu regeln.
Weitere Informationen findet man unter http://technet.microsoft.com/en-us/library/jj735302.aspx
Das gezeigte Szenario mittels VMM verwendet ein NIC-Team bestehend aus 2 x 10GBe Modulen pro
physischem Server.
Überblick
Die Standardeinstellungen im VMM werden für die virtuellen Netzwerkadapter mit
unterschiedlichem Netzwerkverkehr verwendet, wie zum Beispiel Cluster, Live Migration und
Management (Virtual Port Profiles mit Port Classifications).
Ein Virtual Port Profile für die Tenants, die NVGRE nutzen.
Ein einzelnes Team wird auf jedem Host erstellt (Uplink Profiles).
Die Konfiguration von Port Profiles und Uplink Profiles wird zusammengefasst (Logical
Switch).
Man beachte, dass das Team mit dem Virtual Machine Manager erstellt werden muss. Wenn das
Team außerhalb des VMM erstellt wird, so ist der VMM nicht in der Lage die Konfiguration zu
importieren und die vorgenommenen Änderungen darzustellen.
Virtual Port Profiles
1) Aufrufen der Port Profiles unter dem Networking Tab in der Fabric. Dort sieht man
verschiedene Port Profiles, die mit dem VMM ausgeliefert werden. Es werden die
vorhandenen Profiles Host management, Cluster und Live Migration verwendet.
2) Doppelklick auf das Host management Profile, um die Eigenschaften anzuzeigen.
3) Ein Klick auf den Reiter Offload Settings, um die Einstellungen des Profiles für den virtuellen
Netzwerkadapter zu sehen. Features wie VMQ benötigen oft noch eine zusätzliche
Konfiguration auf den Hosts bevor diese genutzt werden können. Die zusätzlichen
Konfigurationsschritte werden von den Netzwerkkartenherstellern bereitgestellt.
4) Ein Klick auf den Reiter Bandwidth Settings zeigt die QoS Einstellungen, die einer eventuellen
Anpassung bedürfen.
Um sich die unterschiedlichen Konfigurationen anzeigen zu lassen, sollte man sich die Einstellungen
der anderen Profiles anschauen. Jedes Default Port Profile im VMM hat eine entsprechende Port
Classification, mit dem es verknüpft werden kann.
Wenn die Einstellungen der Default Port Profiles mit der eigenen Umgebung nicht übereinstimmen,
können eigene Virtual Port Profiles und Port Classifications erstellt werden.
Erstellen des Virtual Port Profile für die Tenants, die NVGRE nutzen
1) Rechtsklick auf Port Profiles in der Fabric, um ein neues Hyper-V Port Profile zu erstellen.
2) Zuweisen des Namens und sicherstellen, dass „Virtual network adapter port profile“
ausgewählt ist.
3) Auf der Seite Offload Settings nur „Enable virtual machine queue“ auswählen, wenn die
physischen Netzwerkkarten auch NVGRE Offloading unterstützen.
4) Auf der Seite Security Settings die Option „Allow guest specified IP addresses (only available
for virtual machines on Windows Server 2012 R2)” auswählen, so dass der VMM Änderungen
innerhalb der VM wahrnehmen kann und entsprechend die NVGRE Richtlinien aktualisiert.
5) Auf der Seite Bandwidth Settings bei „Minimum bandwidth weight“ 1 eintragen, so dass der
Netzwerkverkehr unter den Tenants gleichermaßen aufgeteilt wird.
Erstellen einer Port Classification für die Tenants, die NVGRE nutzen
Es muss auch eine Port Classification erstellt werden, die man mit dem Port Profile zuordnen kann.
Wenn man virtuelle Netzwerkadapter in einem Team auf einem Host konfiguriert, kann man
beispielsweise dem Netzwerkadapter eine Klassifizierung zuordnen, die sicherstellt, dass die
Konfiguration in den Virtual Port Profiles zugeordnet wird. Als Beispiel: Wenn eine virtuelle Maschine
bereitstellt und die virtuelle Netzwerkkarte mit einem VM Network wird, kann dem Adapter ein Port
Profile zugeordnet werden. Durch die Zuordnung des virtuellen Netzwerkadapters mit der Port
Classification für Tenans wird sichergestellt, dass die Tenant VM für die Gewichtung der
Mindestbandbreite den Wert 1 erhält und kein VMQ nutzt.
1) Rechtsklick auf Port Classification in der Fabric, um eine neue Port Classfication zu erstellen.
2) Zuweisen des Namens und der Beschreibung.
Hinweis: Es sollte ein weiteres Virtual Port Profile für Tenants angelegt werden, wo die Option
VMQ deaktiviert ist. VMQ wird in Netzwerk Virtualisierungszenarien nicht funktionieren, außer die
physischen Netzwerkkarten unterstützten NVGRE Offloading. Ebenso sollte die Minimum
Bandwidth Weight in dem Port Profile auf 1 gesetzt sein, so dass der Netzwerkverkehr
gleichermaßen unter den Tenant VMs verteilt wird. Dieses Port Profile sollte später im Logical
Switch als Standard Port Profile definiert sein.
Uplink Port Profile
Der VMM enthält kein Standard Uplink Port Profile, so dass man erst eins erstellen muss. Es werden
zwei Uplink Port Profiles erstellt. Eines für den produktiven Cluster und eines für die Gateway Hosts
sowie Standalone Hosts.
Hinweis: Da auf den Gateway Hosts dedizierte physische Netzwerkadapter für den Internetverkehr
ohne VLAN Tagging eingesetzt werden, sollte ein separates Uplink Port Profile erstellt werden,
welches später einem dedizierten Logical Switch zugeordnet wird. Wenn alles über ein Team laufen
würde, braucht man nur ein Uplink Port Profile. Hier muss vorher die Umgebung auf die genauen
Gegebenheiten analysiert werden.
Production Uplink für Hyper-V Cluster
1) Rechtsklick auf Port Profiles in der Fabric, um ein neues Hyper-V Port Profile zu erstellen.
2) Zuweisen des Namens und der Beschreibung. Es muss „Uplink port profile“ ausgewählt sein.
Dann werden der Load Balancing Algorithmus und der Teaming Mode festgelegt. Für diese
Umgebung wird Dynamic und Switch Independent verwendet.
3) Auswahl der Network Sites, die von diesem Uplink Port Profile unterstützt werden sollen.
Hiermit wird die Konnektivität der physischen Adapter in den Hosts definiert. Somit teilt der
VMM den Hosts mit, dass diese in diesem Fall mit den folgenden Logical Networks und Sites
verbunden sind: Cluster (Cluster Kommunikation), Live Migration ( Live Migration Verkehr),
Management ( Management Kommunikation, das Netzwerk in dem der VMM die Hosts
verwaltet), Front-end (Public IP Zugriff) und PA Network (Dediziertes Netzwerk für die
Provider Addresses, um die Netzwerkvirtualisierung zu betreiben). Falls Windows Server
2012 als Betriebssystem zum Einsatz kommt, muss der Haken bei „Enable Hyper-V Network
Virtualization“ gesetzt sein. Dies aktiviert den Windows Network Virtualization Filter Driver
auf den Hosts. Unter Windows Server 2012 R2 ist dieser schon standardmäßig aktiviert.
4) Abschließen der Konfiguration mit einem Klick auf Next, um die Übersicht der Änderungen
anzuzeigen, und Finish.
Der Prozess wird für das Uplink Port Profile der Gateway Hosts wiederholt.
Zur Erinnerung: Die Hyper-V Hosts, die dediziert für NVGRE zur Verfügung stehen, sind mit dem
Management Netzwerk und dem Internet über dedizierte Netzwerkkarten verbunden. Hier kann
dasselbe Uplink Port Profile für diesen Cluster verwendet werden, wie für den Cluster im Production
Netzwerk auf Seite des Management, Cluster und der Live Migration. Aber es wird ein zusätzliches
Uplink Port Profiles für die Netzwerkkarten benötigt, die mit dem Internet verbunden sind. Das Uplink
Port Profile was man hier erstellt, ist für die Netzwerkkarten auf den Gateway Hosts, die mit dem
Internet verbunden sind. In der Zusammenfassung benötigen die Gateway Hosts zwei Uplink Port
Profiles. Eines für Management, Cluster und Live Migration und ein weiteres für das Front-end. Der
Grund wieso man die Uplink Port Profiles und Logical Switches verwendet ist der, dass man vom NIC-
Teaming profitieren möchte.
1) Rechtsklick auf Port Profiles in der Fabric, um ein neues Hyper-V Port Profile zu erstellen.
2) Zuweisen des Namens und der Beschreibung. Es muss „Uplink port profile“ ausgewählt sein.
Dann werden der Load Balancing Algorithmus und der Teaming Mode festgelegt. Für diese
Umgebung wird Dynamic und Switch Independent verwendet.
3) Auswahl der Network Sites, die von diesem Uplink Port Profile unterstützt werden sollen. Da
das NIC-Team nur für die Front-end Verbindung verwendet wird, benötigen man die
Netzwerke für Cluster und Live Migration nicht. Front-end wird ausgewählt.
Zu Erinnerung: Falls Windows Server 2012 als Betriebssystem zum Einsatz kommt, muss der
Haken bei „Enable Hyper-V Network Virtualization“ gesetzt sein.
4) Abschließen der Konfiguration mit einem Klick auf Next, um die Übersicht der Änderungen
anzuzeigen, und Finish.
Nun muss man die erstellten Profiles nur noch in den Logical Switches zusammenführen.
Abbildung 5 - Port Profiles im VMM
Logical Switch
Ein Logical Switch ist ein Container für Uplink Port Profiles und Virtual Port Profiles. Damit man zwei
unterschiedliche NIC-Teams auf ein und demselben Host (bei den NVGRE Hosts ist dies der Fall)
betreiben kann, werden zwei Logical Switches erstellt, da zwei unterschiedliche Konfigurationen
(Hyper-V Cluster und NVGRE Hyper-V Cluster) bestehen mit dedizierten Netzwerkkarten für die
Front-end NICs in den Gateway Hosts.
Production Switch
1) Rechtsklick auf Logical Switches in der Fabric, um einen neuen Logical Switch zu erstellen.
2) Zuweisen des Namens und der Beschreibung. Der Haken bei „Enable single root I/O
virtualization (SR-IOV)“ wird nicht gesetzt, da dies außerhalb des Fokus des Handbuchs liegt.
3) Auswahl der Switch Extensions, die man mit dem Logical Switch nutzen möchte. Die
Standardauswahl Microsoft Windows Filtering Platform wird beibehalten.
4) Zuweisen der Uplink Port Profiles. Als Uplink Mode wählt man Team aus und weist das Uplink
Port Profile „Production Uplink“ zu.
5) Zuweisen der Port Classifications für die Virtual Ports. Mit einem Klick auf Add fügt man die
Virtual Ports hinzu. Dazu muss man die richtige Port Classification und das entsprechende
Virtual Network Adapter Port Profile hinzufügen. Am Ende sollten die Classifications und
Profiles für Management, Cluster, Live Migration sowie Tenants hinzugefügt worden sein.
6) Überprüfen der Einstellungen und Abschließen der Konfiguration.
Der Prozess wird für den Logical Switch der Gateway Hosts wiederholt.
Gateway Switch
1) Rechtsklick auf Logical Switches in der Fabric, um einen neuen Logical Switch zu erstellen.
2) Zuweisen des Namens und der Beschreibung. Der Haken bei „Enable single root I/O
virtualization (SR-IOV)“ wird nicht gesetzt, da dies außerhalb des Fokus des Handbuchs liegt.
3) Auswahl der Switch Extensions, die man mit dem Logical Switch nutzen möchte. Die
Standardauswahl Microsoft Windows Filtering Platform wird beibehalten.
4) Zuweisen der Uplink Port Profiles. Als Uplink Mode wählt man Team aus und weist das Uplink
Port Profile „Gateway Uplink“ zu.
5) Zuweisen der Port Classifications für die Virtual Ports. Mit einem Klick auf Add fügt man die
Virtual Ports hinzu. Dazu muss man die richtige Port Classification und das entsprechende
Virtual Network Adapter Port Profile hinzufügen.
6) Überprüfen der Einstellungen und Abschließen der Konfiguration.
Nachdem die Logical Networks, Port Profiles und Logical Switches in der Fabric angelegt worden sind,
muss man als nächstes die VM Networks für die virtuellen Netzwerkadapter erstellen.
Schritt 6
Erstellen der VM Networks
Hinweis: Dieser Schritt ist nicht notwendig, wenn die Option „Create a VM network with the same
name to allow virtual machines to access this logical network directly“ bei der Erstellung der
Logical Networks gesetzt war. Ansonsten fährt man mit dem Erstellen der VM Networks fort.
Ein VM Network im VMM ist ein zusätzlicher Abstraktionslayer. Dabei kann ein VM Network
entweder als virtualisiertes Netzwerk (CA Addresses für virtuelle Maschinen) oder als 1:1 Beziehung
zu einem Logical Network angelegt werden. Um die virtuellen Adapter der Hosts mit dem richtigen
Logical Network verbinden zu können, muss man für jedes Logical Network ein VM Network
erstellen.
1) Aufrufen des Reiters VMs and Services
2) Rechtsklick auf VM Networks, um ein neues VM Network zu erstellen
3) Zuweisen des Namens und des Management Logical Network. (Der Prozess muss für das
Cluster Netzwerk, das Front-end Netzwerk und das Live Migration Netzwerk wiederholt
werden).
4) Abschließen der Konfiguration mit Finish.
Wiederholung des Prozesses für das Front-end, Cluster und Live Migration Netzwerk.
Schritt 8
Netzwerkkonfiguration der Hosts
Um den Logical Switch den Hosts hinzufügen zu können, müssen die physischen NICs den Logical
Networks zugeordnet werden. Bevor Microsoft das NIC-Teaming für Windows Server und VMM
eingeführt hatte, musste man die Logical Networks manuell den physischen Netzwerkkarten
zuordnen. Dies ist ab sofort nicht mehr notwendig, da die Uplink Port Profiles die entsprechenden
Informationen bereits besitzen. So kann direkt mit der Bereitstellung der Logical Switches begonnen
werden.
Production Cluster
1) Hostgruppe des Hyper-V Cluster auswählen
2) Rechtsklick auf einen der Knoten und dann Eigenschaften auswählen
3) Den Reiter Virtual Switches auswählen. Dann einen neuen virtuellen Switch erstellen.
4) Sicherstellen, dass der richtige Logical Switch und das richtige Uplink Port Profile ausgewählt
sind und alle physischen Adapter hinzufügen.
5) Um einen virtuellen Adapter der Konfiguration hinzuzufügen auf „New Virtual Network
Adapter“ klicken. Es werden drei virtuelle Netzwerkadapter hinzugefügt. Einer für das
Management, einer für Cluster und einer für Live Migration. Der Adapter für das
Management sollte die Option „This virtual network adapter inherits settings from the
physical management adapter“ aktiviert haben. Diese Einstellung bewirkt, dass die
Einstellungen der physischen NIC, die für das Management konfiguriert wurde, auf den
virtuellen Adapter angewendet werden. Außerdem müssen die virtuellen Adapter mit dem
entsprechenden VM Networks verbunden sein.
6) Wiederholen der Konfigurationsschritte für die virtuellen Adapter für Live Migration und
Cluster. Auch hier müssen die virtuellen Adapter mit den entsprechenden VM Networks
verbunden sein sowie den VLANs, IP-Adresspools und Port Classifications.
7) Mit einem Klick auf OK werden die Einstellungen übernommen und der VMM kommuniziert
diese dann an die VMM Agents. Wiederholen der Schritte für alle Knoten im Cluster.
Zur Erinnerung: Wie man sicherlich bemerkt hat, wurde kein virtueller Adapter für das PA Netzwerk
hinzugefügt. Dies sollte auch unter keinen Umständen getan werden. Denn die Hosts erhalten
automatisch eine PA Adresse aus dem PA Pool sobald eine VM mit einer CA Adresse bereitgestellt
wird. Der Automatismus kommt durch die Aktivierung der Netzwerkvirtualisierung auf dem PA
Netzwerk und der Zuordnung dieses Netzwerks mit den physischen Adaptern zustande.
Gateway Hosts/Cluster (Dedizierte Hosts für das Virtualisierungsgateway)
Ebenso besteht eine Konfiguration für die Gateway Hosts. Für die Virtualisierungsgateway Hosts
werden zwei Logical Switches bereitgestellt. Der Host ist mit einer physischen NIC direkt mit dem
Internet verbunden. Daher benötigt man einen dedizierten Logical Switch für das Front-end und
einen Logical Switch für die anderen NICs die mit dem Management, Cluster und Live Migration
Network verbunden sind.
1) Hostgruppe der Hosts für die Netzwerkvirtualisierungsgateways auswählen
2) Rechtsklick auf einen der Server und dann Eigenschaften auswählen
3) Reiter Hardware auswählen. Die Netzwerkadapter erweitern und die Namen der
Netzwerkkarten für das Managment und Front-end notieren. Hier heißen die NICs LAN01 und
WAN01.
4) Wieder die Eigenschaften des Servers aufrufen und den Reiter Virtual Switches auswählen.
Dann einen neuen virtuellen Switch erstellen.
5) Sicherstellen, dass der richtige Logical Switch und das richtige Uplink Port Profile ausgewählt
sind und alle physischen Adapter hinzufügen, die als Team für das Management, Cluster und
Live Migration Netzwerk dienen sollen.
6) Um einen virtuellen Adapter der Konfiguration hinzuzufügen auf „New Virtual Network
Adapter“ klicken. Es werden virtuelle Netzwerkadapter für das Management, Cluster und die
Live Migration hinzugefügt. Der Adapter für das Management sollte die Option „This virtual
network adapter inherits settings from the physical management adapter“ aktiviert haben.
Diese Einstellung bewirkt, dass die Einstellungen der physischen NIC, die für das
Management konfiguriert wurde, auf den virtuellen Adapter angewendet werden. Außerdem
müssen die virtuellen Adapter mit dem entsprechenden VM Networks verbunden sein.
7) Einen weiteren Logical Switch anlegen, „Gateway Switch“ als Logical Switch auswählen und
die NICs, die direkt mit dem Internet verbunden sind, hinzufügen. Es braucht kein virtueller
Netzwerkadapter hinzugefügt werden.
8) Mit einem Klick auf OK werden die Einstellungen übernommen und der VMM kommuniziert
diese dann an den VMM Agent.
Damit ist die Konfiguration der Netzwerkeinstellungen in der Fabric abgeschlossen und man kann mit
der Konfiguration des Gateways fortfahren.
Schritt 8
Konfiguration des Gateway Hosts
Ein wichtiger Schritt der beachtet werden muss, wenn man Windows Server 2012 R2 als natives
Gateway verwendet, ist der, dass der Host für die Netzwerkvirtualisierung reserviert sein muss.
Dieser Host wird nur VMs ausführen, die als Virtualisierungsgateways konfiguriert sind.
Reservieren des Hosts für die Netzwerkvirtualisierung
1) In der VMM Konsole die Eigenschaften der Gateway Hosts aufrufen.
2) Auf den Reiter Host Access gehen und dort den Haken bei „This host is a dedicated network
virtualization gateway, as a result it is not available for placement of virtual machines
requiring network virtualization“ setzen.
Diese Schritte auf jedem Gateway Host wiederholen.
Hinweis: Die PowerShell kann man ebenfalls dazu verwenden, um zu überprüfen ob die
Einstellungen auf jedem Gateway Host richtig gesetzt sind.
(get-scvmhostcluster -name "HVGWC01").nodes | ft -property
Name,IsDedicatedToNetworkVirtualizationGateway
Schritt 9
Erstellen der Netzwerkvirtualisierungsgateway – Service Template für
nicht hochverfügbare Virtualisierungsgateways
Für die Bereitstellung des Virtualisierungsgateways auf die dedizierten Hosts durch den VMM,
können die Service Templates im VMM genutzt werden, so dass das Virtualisierungsgateway
automatisch konfiguriert wird. Es kann entweder ein Service Template erstellt werden, dass für ein
Standalone VM Gateway dient, also keine Hochverfügbarkeit auf Applikationsebene bereitstellt, oder
ein HA Service Template das für ein HA Guest Cluster VM Gateway dient. Im ersten Teil wird der
Fokus auf das Service Template für Standalone Gateways gelegt.
Dazu benötigt man eine VHDX mit Windows Server 2012 R2, die mit Sysprep generalisiert wurde, und
ein VM Template.
1) Aufrufen des Reiters Library in der VMM Konsole.
2) Ein Klick auf Service Templates und auf „Create service template“ im Ribbon Menü, so dass
der Service Template Designer startet.
3) Zuweisen des Namens, der Version und der Pattern. Es stehen mehrere vordefinierte
Möglichkeiten zum Erstellen eines Multi-Tier Services zur Verfügung oder man verwendet ein
leeres Template. Hier wird ein leeres Template verwendet und das benötigte VM Template
per Drag & Drop direkt in den Designer gezogen.
4) Es ist zu beachten, dass das Template nur über drei virtuelle Netzwerkadapter verfügen
sollte. Ein Adapter wird mit dem Management VM Network verbunden, so dass die VM der
Domäne hinzugefügt und vom VMM verwaltet werden kann. Der nächste Adapter wird mit
dem Front-end VM Network verbunden und erhält eine öffentliche IP-Adresse. Beide
Adapter müssen mit einer statischen IP-Adresse sowie einer statischen MAC-Adresse
versehen sein. Der letzte, der dritte, Adapter wird noch nicht mit einem VM Network
verbunden. Dies erfolgt später, da dieser Adapter nicht mit einem VM Network verbunden
sein muss, sondern direkt mit dem Switch.
5) Als Nächstes nutzt man die umfangreichen Einstellungen des Guest OS Profiles. Ein
Doppelklick auf die Service Instanz öffnet die Eigenschaften und mit einem Klick auf OS
Configuration erreicht man die Konfigurationsmöglichkeiten. Hier wird ein Name für den Tier
vergeben (Für eine automatische Inkrementierung bei einer mehrfachen Bereitstellung von
Gateways verwendet man zweimal hintereinander das Hashzeichen (##) nach dem
vergebenen Namen).
6) Danach werden weitere Einstellungen wie der Produktschlüssel, die Domäneneinstellungen
und das Administratorpasswort vorgenommen. Service Templates bieten einem die
Möglichkeit Rollen & Features mit zu installieren. Für das Virtualisierungsgateway aktiviert
man die folgende Rollen: Remote Access -> DirectAccess and VPN (RAS), Routing
7) Zweitens müssen die folgenden Features aktiviert sein: Remote Access Management Tools -
> Remote Access GUI and Command-Line Tools, Remote Access module for Windows
PowerShell
8) Mit einem Klick auf Save and validate wird das Service Template auf Fehler oder
Fehlkonfiguration überprüft sowie gespeichert.
9) Ein Klick auf Configure Deployment im Ribbon Menü und man kann das Ziel für die
Bereitstellung sowie den Namen des Service vergeben. Der Service muss dabei auf einen
dedizierten physischen Hyper-V Host bereitgestellt werden. Daher muss man die
entsprechende Hostgruppe auswählen, in diesem Fall die Hostgruppe „Gateway“.
10) Das Intelligent Placement prüft ebenfalls ob eventuell eine falsche Konfiguration vorliegt, um
so eine erfolgreiche Bereitstellung auf dem Host zu gewährleisten. Ein Klick auf den Tier und
Ratings zeigt die Details dazu an. Ist alles in Ordnung wird die Bereitstellung mit einem Klick
auf „Deploy service“ gestartet. Anderenfalls muss in den Service Template Designer
gewechselt werden, um die Fehler zu beheben, die ansonsten eine Bereitstellung verhindern.
Schritt 10
Nachkonfiguration des Virtualisierungsgateway Service
Nachdem der Service bereitgestellt wurde, meldet man sich an dem Service Tier an und stellt die
folgenden Dinge sicher.
Die VM ist Mitglied der Domäne.
Die Netzwerkadapter für das Management und das Front-end Netzwerk besitzen jeweils eine
statische IP-Adresse.
Die Rolle Routing and Remote Access ist installiert, aber nicht konfiguriert.
Nun wird der dritte virtuelle Netzwerkadapter konfiguriert und mit dem Logical Switch verbunden.
1) Zuerst ruft man dazu die Einstellungen der VM unter VMs and Services im VMM auf.
2) Danach erfolgt der Aufruf des Reiters Hardware settings und die Auswahl des dritten
virtuellen Adapters, der mit keinem Netzwerk verbunden ist.
3) Nun erfolgt ein Klick auf „Connected to a VM network“ und anschließend auf „Browse“. Dann
„Clear selection“ und „OK“. Mit diesem Vorgehen verbindet man den Adapter mit dem
Switch anstatt mit einem VM Network.
4) Wieder meldet man sich an der virtuellen Maschine an und verifiziert mittels ipconfig die
Verbindungen und notiert sich welcher Adapter mit welchem Netzwerk verbunden ist. Da die
Adapter, die mit dem Front-end und PA Netzwerk verbunden sind, für die Konfiguration des
Network Service im VMM benötigt werden. Als Faustregel gilt die Adapter in der VM
umzubenennen, so dass diese der Verbindung zu dem entsprechenden Netzwerk gleichen.
Dies erleichtert die korrekte Konfiguration des Services und die eventuelle Fehlerbehebung
bei Verbindungsproblemen.
Im oberen Screenshot ist der Adapter „Front-end“ mit dem Front-end, „Ethernet“ mit dem
Management und „Back-end“ mit dem PA Netzwerk verbunden (keine zugewiesene IP-
Adresse).
Schritt 10.1
Erstellen der Netzwerkvirtualisierungsgateway – Service Template für
hochverfügbare Virtualisierungsgateways
Ein Service Template für hochverfügbare Virtualisierungsgateways erfordert einiges mehr an
Konfigurationsaufwand. Microsoft stellt allerdings ein schon vorkonfiguriertes Service Template zur
Verfügung. Dieses muss nur heruntergeladen und in die VMM Library importiert werden.
Überblick über die Konfigurationsschritte
1) Für diese Konfiguration muss man eine Shared VHDX verwenden. Dazu einfach mittels
Windows Explorer in die VMM Library navigieren und eine Kopie der „Blank Disk –
Small.vhdx“ und der „Blank Disk – Large.vhdx“ erstellen. Die „Blank Disk – Small.vhdx“ in
„Quroum.vhdx“ und die „Blank Disk – Large.vhdx“ in „CSV1.vhdx“ umbenennen. Danach die
VMM Library aktualisieren, damit die neuen VHDX Dateien erkannt werden.
2) Das Custom Resource Verzeichnis, VMClusterSetup.CR, welches im dem heruntergeladenen
Service Template enthalten ist, in die VMM Library kopieren.
3) Importieren des Service Template „Windows Server 2012 R2 HA Gateway 3NIC.xml in die
VMM Library.
4) Danach den Service Template Designer öffnen. Dieser zeigt nun das HA Service Template an,
welches für das Quorum und die CSV Disk das Feature Shared VHDX nutzt. Ebenfalls enthält
das Service Template ein Verfügbarkeitsset für dieses Aktiv-Passiv Virtualisierungsgateway.
Anschließend kann das hochverfügbare Virtualisierungsgateway bereitgestellt werden. Für
die weiteren Konfigurationsschritte einfach der Anleitung folgen, die in dem
heruntergeladenen Service Template enthalten ist.
5) Um das hochverfügbare Virtualisierungsgateway der VMM Fabric hinzuzufügen sind
eventuell weitere Optionen für den Connection String notwendig. Welche Optionen zur
Verfügung stehen sind in der folgenden Tabelle dargestellt.
Connection String Option Wird benötigt? Beschreibung
VM Host= Ja FQDN des dedizierten Standalone Hyper-V Hosts oder des dedizierten Hyper-V Failover Cluster für die NVGRE Gateways
GatewayVM= Ja FQDN der NVGRE Gateway VM oder des NVGRE Gateway Cluster
BackendSwitch= Optional Name des Virtual Switch, der auf dem Hyper-V Host für die Back End Connection verwendet wird.
DirectRoutingMode=True Optional Legt fest, ob Direct Routing bei diesem NVGRE Gateway verwendet wird.
FrontEndServerAddress= Ja, wenn DirectRoutingMode verwendet wird
IP-Adresse des Front End Connection Adapters. Muss bei der Option DirectRoutingMode=True angegeben werden.
Connection String Option Wird benötigt? Beschreibung
VPNServerAddress= Optional IP-Adresse des VPN Servers / Endpoints. Muss nur angegeben werden, wenn sich das Gateway hinter einem externen Load Balancer befindet.
MaxVMNetworksSupported= Optional Legt die Anzahl der mit dem NVGRE Gateway verwendbaren VM Networks fest. Standardmäßig sind es 50. Maximal 100 werden unterstützt. Bei der Option DirectRoutingMode=True ist es nur ein VM Network welches unterstützt wird.
Schritt 11
Hinzufügen des Virtualisierungsgateway Network Service im VMM
Nun wird der Service der als Virtualisierungsgateway installiert wurde als Network Service innerhalb
des VMM hinzugefügt. Während dieses Prozesses konfiguriert der VMM die RRAS Rolle um als Multi-
Tenant Gateway für S2S VPN, NAT und BGP zu fungieren.
1) Aufrufen der Fabric und erweitern des Abschnitts Networking und ein Rechtsklick auf
Network Service, um einen neuen Network Service hinzuzufügen.
2) Zuweisen des Namens und einer Beschreibung
3) Auswählen des Herstellers und des Modells des Network Service. Da es sich um ein
Virtualisierungsgateway handelt wird als Hersteller Microsoft und als Model Microsoft
Windows Server Gateway ausgewählt.
4) Als Nächstes benötigt man einen Run As Account, der lokale Adminrechte auf der
Virtualisierungsgateway VM besitzen muss, für die Konfiguration. Falls noch keiner angelegt
ist, kann dies hier nachgeholt werden.
5) Nun wird der Connection String definiert, der die Verbindung zwischen dem dedizierten
Virtualisierungsgateway Host, der Virtualisierungsgateway VM und dem VMM herstellt. Der
String sollte so ausschauen VMHost=nameofyourdedicatedhost;RRAS=nameofyourNVGREVM
Hinweis: Dies stellt sicher, dass die Virtualisierungsgateway VM nur auf diesem Host läuft.
Für eine Bereitstellung eines hochverfügbaren Virtualisierungsgateways gibt die vorherige
Tabelle Hinweise, wie man dies entsprechend konfiguriert.
6) Validierung des Network Service Configuration Provider. Dies führt zu einigen Tests auf der
Gateway VM und implementiert die Netzwerkvirtualisierungsrichtlinien.
7) Der Network Service wird den Hostgruppen Gateway, Research & Development und
Production zur Verfügung gestellt.
Der letzte Schritt den man tätigen muss, ist die Konfiguration der Netzwerkverbindungen des Service.
1) Rechtsklick auf den neu erstellten Netzwork Service und dann Eigenschaften.
2) Aufrufen des Reiters „Connectivity“ und Aktivierung der Front End und Back End Verbindung.
Als Front End Verbindung wird der Adapter ausgewählt, der mit dem Front-end VM Network
verbunden ist und als Network Site wird Front-end ausgewählt. Als Back End Verbindung
wird der Adapter ausgewählt, der mit dem Logical Switch direkt verbunden ist und als
Network Site wird PA Network ausgewählt. Ebenfalls kann die Bandbreite limitiert werden.
Damit ist das Virtualisierungsgateway fertig konfiguriert und steht für die Netzwerkvirtualisierung
bereit.
Schritt 12
Erstellen des VM Networks mit NAT
Um die Netzwerkvirtualisierung verwenden zu können, muss ein VM Network erstellt werden,
welches mit dem für Netzwerkvirtualisierung aktivierten Logical Network verbunden wird. Hier
verwendet man das PA Netzwerk dafür.
1) Aufrufen von VMs and Services in der VMM Konsole
2) Rechtsklick auf VM Networks, um ein neues VM Network zu erstellen
3) Zuweisen des Namens und der Beschreibung. Sicherstellen, dass das Logical Network mit
aktivierter Netzwerkvirtualisierung Verwendung findet. Wie man feststellen wird, steht das
Logical Network, welches mit einem direkten Link zu dem Management VM Network
versehen wurde, nicht mehr zur Verfügung. Dagegen steht ein Logical Network mit
aktivierter Netzwerkvirtualisierung immer zur Verfügung.
4) Auswählen der Isolation und des IP-Protokolls. Hier Hyper-V Netzwerkvirtualisierung und
IPv4.
5) Zuweisen von VM Subnets. Einfach das Netzwerk angeben so wie man es möchte, denn dank
der Netzwerkvirtualisierung mit GRE erhält jedes VM Subnet seine eigene VSID (Virtual
Subnet ID) und ist automatisch innerhalb des VM Networks (RDID – Routing Domain ID)
routingfähig.
6) Nun die Verbindung nach Außen auswählen. Es stehen VPN (auch mit BGP) und die direkte
Verbindung in ein zusätzliches Logical Network über Direct Routing, wenn es im Connection
String des Network Service angegeben wurde, und Network Address Translation (NAT) zur
Verfügung. In diesem Beispiel wird NAT verwendet, um den VMs den Internetzugriff
bereitzustellen.
7) Festlegen der NAT-Einstellungen und der NAT-Regeln. Sobald NAT ausgewählt ist, erhalten
die VMs automatisch über das Virtualisierungsgateway Internetzugriff. Falls VMs in diesem
VM Network ausgerollt werden, die einen Service nach Außen bereitstellen sollen, zum
Beispiel ein Webserver, dann können NAT-Regeln definiert werden. Diese zeigen auf die IP-
Adresse der VM. Der IP-Adresspool entspricht dem Pool der mit dem Logical Network „Front-
end“ assoziiert wurde. Der VMM kann selbstständig die nächste freie Adresse daraus
zuweisen oder man bestimmt diese manuell.
8) Überprüfen der Einstellungen und Abschließen der Konfiguration.
Nachdem man das VM Network erstellt hat, sollte man einen IP-Adresspool dem VM Network
hinzufügen, sodass der VMM ein komplettes Life Cycle Management der IP-Adressen vornehmen
kann.
1) Rechtsklick auf das VM Network, um einen neuen IP-Adresspool zu erstellen.
2) Zuweisen des Namens und der Beschreibung. Sicherstellen, dass das richtige VM Network
und VM Subnet eingestellt ist.
3) Festlegen der Start und End IP-Adresse
4) Festlegen des standardmäßigen Gateways. Dies kann leer gelassen werden, da der VMM
automatisch die Adresse x.x.x.1 als Standardgateway für das VM Network festlegt. Dies kann
man nicht ändern.
5) Festlegen der DNS-Server, so dass die VMs eine Namensauflösung für Internetadressen
betreiben können.
Das VM Network ist nun fertig konfiguriert, um NVGRE mit NAT zu verwenden.
Abbildung 6 - Konfiguriertes VM Network mit NAT
Schritt 13
Bereitstellen von virtuellen Maschinen, die mit dem VM Network
verbunden sind
Jetzt kann eine virtuelle Maschine ausgerollt werden, die mit dem neu erstellten VM Network
verbunden ist. Die VM muss dabei auf einer Hostgruppe bereitgestellt werden, die Zugriff auf die
konfigurierten Einstellungen hat. In diesem Fall die Hostgruppe Production, worin der Hyper-V
Cluster enthalten ist.
1) Aufrufen von VMs and Services in der VMM Konsole. Rechtsklick auf die Hostgruppe
Production und Create virtual machine.
2) Auswählen des Templates aus der VMM Library.
3) Zuweisen des Namens der virtuellen Maschine und der Beschreibung.
4) Am Hardware Reiter angelangt erfolgen die Auswahl des Netzwerkadapters und die
Zuweisung des VM Network sowie des VM Subnet. Der VMM wird eine statische IP-Adresse
vergeben und die NAT-Regeln auf die VM anwenden.
5) Konfiguration des Betriebssystems. Der Computername sollte mit dem VM Namen identisch
sein, um eine Konsistenz zu schaffen.
6) Auswahl des Ziels. Sicherstellen, dass die Hostgruppe Production ausgewählt ist.
7) Das Intelligent Placement wählt den besten potentiellen Host für den Workload aus.
8) Unter Configure Settings sind die Netzwerkeinstellungen einzusehen, so dass man das VM
Network und die verfügbaren Pools erkennt. Auch das Logical Network für die PA Adressen
ist zu sehen. Der VMM wird automatisch eine Provider Address für den Ziel Hyper-V Host der
VM bereitstellen.
Nach dem Starten des VM Deployment wiederholt man den Prozess, um eine weitere VM
(TenantBlue2) bereitzustellen. So lässt sich die korrekte Funktionalität von NVGRE in der Umgebung
testen.
Schritt 14
Überprüfen der Verbindung und Troubleshooting
In diesem Abschnitt werden nützliche Tipps zum Verifizieren von NVGRE und zum Troubleshooting
gegeben.
Verifizieren der VM Konnektivität
Es wurden zwei virtuelle Maschinen, TenantBlue und TenantBlue2, bereitgestellt. Beide sind mit
demselben VM Network (RDID) und demselben Subnet (VSID).
Da IP-Adresspools in dem VM Network verwendet werden, sollte man zuerst die IP Konfiguration
überprüfen.
1) Anmelden auf den virtuellen Maschinen und überprüfen der IP Konfiguration. TenantBlue
hat die IP-Adresse 192.168.0.7 (hier ist auch eine NAT-Regel auf Port 80 aktiv) und
TenantBlue2 die 192.168.0.8 erhalten.
2) Da sich die virtuellen Maschinen im selben VM Network (RDID) und in diesem Fall auch im
selben Subnet (VDID) befinden, können diese untereinander kommunizieren. Standardmäßig
blockt die Windows Firewall ICMP Verkehr, so dass Ping Versuche scheitern. Die Windows
Firewall wurde zu Testzwecken deaktiviert, um die Kommunikation untereinander zu
überprüfen. Wenn sich die VMs auf unterschiedlichen Hosts befinden, erfolgt die
Kommunikation über die Hosts über das PA Netzwerk, über das die CA Adressen gekapselt
übertragen werden.
3) Wenn man route print eingibt, kann man das Standardgateway 192.168.0.1 erkennen.
4) Mittels nslookup und einem Lookup auf Microsoft.com kann man überprüfen, ob die über
das VM Network mitgegebenen öffentlichen DNS-Server funktionieren.
5) Außerdem kann mit dem Internet Explorer Webseiten aufgerufen werden.
Überprüfen der Hostfunktionalität des Netzwerkvirtualisierungsgateway
Um sicherzustellen, dass der Virtualisierungsgateway Host und die VM funktionieren erfolgt eine
Anmeldung auf dem Host.
1) Zuerst muss der Host auf die richtige Provider Address überprüft werden. Dazu startet man
eine PowerShell Sitzung und gibt den folgenden Befehl ein Get-
NetVirtualizationProviderAddress. Die Provider Address wird vom VMM zugewiesen und der
VMM verwaltet ebenso die Virtualisierungsrichtlinien innerhalb der gesamten Umgebung.
Wie zu sehen ist, stammt die IP-Adresse 10.10.50.53 aus dem Logical Network PA Netzwerk.
2) Mittels Get-NetVirtualizationLookupRecord bekommt man sämtliche Lookup Record
Richtlinieneinträge für IP-Adressen im VM Network zu Gesicht. Die angezeigten Einträge
spiegeln das Mapping von Customer Addresses zu Provider Addresses wieder. Hier werden
die Einträge für die virtuellen Maschinen (TenantBlue – 192.168.0.7 & TenantBlue2 –
192.168.0.8) angezeigt. Die zwei virtuellen Maschinen haben unterschiedliche IP-Adressen,
teilen sich aber ein und dieselbe Provider Address, da sich beide auf demselben Host
befinden. So funktioniert NVGRE und ist daher ideal für die Skalierung nach oben geeignet.
Auch diese Einträge verwaltet der VMM.
Überprüfen der Netzwerkvirtualisierung auf den Hyper-V Hosts
Wenn der Hyper-V Host für virtuelle Maschinen mit NVGRE verwendet wird, sollte der Host eine
Adresse aus dem PA Netzwerk allokiert haben.
1) Anmelden auf dem Host, der die VM TenantBlue und TenantBlue2 hostet.
2) Eingeben des Befehls Get-NetVirtualizationProviderAddress und überprüfen der PA Adresse.
Man beachte, dass es sich um dieselbe PA Adresse handelt, die man schon auf dem Gateway
Host in den Lookup Records gesehen hat. Dies zeigt einem, dass die
Netzwerkvirtualisierungsrichtlinien über die ganze Umgebung hinweg richtig implementiert
sind.
3) Eingeben des Befehls Get-NetVirtualizationLookupRecord und überprüfen, dass die
Richtlinien auf diesem Host mit denen auf dem Gateway Host übereinstimmen.
Für jede Customer Address existiert eine Virtual Subnet ID (VSID) und Customer ID (RDID).
Für TenantBlue und TenantBlue2 sind diese identisch. In der Ausgabe ist auch das
Standardgateway zu sehen, welches zu diesem VM Network gehört.
Überprüfen der Netzwerkvirtualisierungsgateway Funktionalität
Zum Überprüfen der Virtualisierungsgateway VM muss man sich wieder anmelden und einige
Cmdlets ausführen.
1) Bei der Ausgabe von ipconfig sollten mehrere IPs zu sehen sein, die vom Front-end Netzwerk
dem Front-end Adapter zugewiesen wurden. Für jedes erstellte VM Network und jede
konfigurierte NAT-Verbindung wird eine IP dem Netzwerk zugewiesen und auf der Gateway
VM auf dem Front-end Netzwerk implementiert.
2) Um die IP-Adresse für die NAT-Verbindung herauszufinden gibt man Get-
NetNatExternalAddress ein.
3) Ebenso können mittels Get-NetNatSession die NAT Sessions der Gateway VM angezeigt
werden.
Das wurde überprüft:
Das die VMs untereinander über dasselbe VM Network und dasselbe Subnet verbunden sind.
Das der Virtualisierungsgateway Host die korrekten NVGRE Richtlinien besitzt.
Das der Virtualisierungsgateway Host eine IP-Adresse aus dem PA Netzwerk verwendet.
Das die Hyper-V Hosts die korrekten NVGRE Richtlinien besitzen.
Das die Hyper-V Hosts eine IP-Adresse aus dem PA Netzwerk verwenden.
Das die Gateway VM funktioniert und eine IP-Adresse aus dem Front-end IP-Adresspool
verwendet.
Das die Gateway VM die NAT Sessions anzeigt.
Troubleshooting und FAQ Seit der ersten Version dieses Handbuchs, mit über 5000 Downloads, wurde Feedback von Kunden,
Partner Blogs und Foren gesammelt, um die häufigsten Fehler, Missverständnisse und Irrtümer die
dieses Thema betreffen herauszufinden. Um den Wert dieses Handbuchs zu steigern, wurde dieser
neue Abschnitt hinzugefügt, so dass man ein besseres Verständnis über die Technologie und die
Konfiguration erhält.
Q: Ist es möglich Ping oder andere Tools für das Troubleshooting in einer NVGRE Umgebung zu
verwenden?
A: Ja. Nachdem man die VMM Umgebung für NVGRE konfiguriert hat, kann man diese
Konfiguration testen und verifizieren. Dazu stehen einem mehrere neuartige Tools im R2 Release
des Windows Servers zur Verfügung, die helfen können den Fehler zu identifizieren.
Das erste Programm ist der PA Ping oder auch Provider Address Ping genannt.
PA Ping
Als Administrator muss man die Fehler, die die VM Konnektivität in der eigenen Fabric betrifft, die
die physische Infrastruktur verwendet (dediziertes Netzwerk für die Netzwerkvirtualisierung,
identifizieren können. Der PA Ping initiiert die ICMP Pakete oberhalb der physischen NIC der Quell
VM und wartet auf die Antwort der Ziel VM. Als Resultat dessen kann man ICMP Pakete von einer PA
Adresse zu einer anderen senden. Um den PA Ping zu verwenden reicht es, wenn man ping –p
ProviderAddress eingibt.
Zuerst sollten die derzeit verwendeten PA Adressen und die zugeordneten VMs (CA’s) identifiziert
werden.
Get-NetVirtualizationLookupRecord | ft ProviderAddress, CustomerAddress, VMName
Sind die PA Adressen identifiziert worden, die man testen möchten, einfach den ping Befehl
ausführen.
Virtualisierungsgateway Cmdlets
Wenn die Virtualisierungsgateways oder das Virtualisierungsgateway bereitgestellt worden ist, sind
folgende Cmdlets zur Verfizierung oder zum Troubleshooting hilfreich.
Get-NetNat
Dieses Cmdlet gibt die konfigurierten NAT Objekte auf dem Computer wieder. NAT modifiziert IP
Adressen und Port Informationen im Paket Header.
Get-NetNatStaticMapping
Dieses Cmdlet gibt das statische Mapping einer NAT Instanz wieder. Statisches Mapping ermöglicht
eine eingehende Verbindung von einem externen Netzwerk zu einem Host im internen Netzwerk
(NVGRE) über NAT.
Get-NetCompartment
Dieses Cmdlet gibt die Network Compartments im Protokoll Stack wieder und man kann die ID von
dem Compartment definieren, welches man erhalten möchte.
Get-NetRoute –IncludeAllCompartments
Dieses Cmdlet gibt die IP Routen Informationen aus der IP Routing Tabelle wieder. Diese
Informationen beinhalten das Zielnetzwerk, die Präfixe, den nächsten IP Hop und die Metrik der
Route.
Q: Welche VPN Geräte werden im Zusammenhang mit dem Virtualisierungsgateway unter
Windows Server 2012 R2 unterstützt?
A: Die folgenden Geräte werden mit Windows Server 2012 R2 unterstützt:
Hersteller Gerätefamilie Minimale OS Version
Cisco ASR IOS 15.2
Cisco ISR IOS 15.1
Juniper SRX JunOS 11.4
Juniper J-Series JunOS 11.4
Juniper ISG ScreenOS 6.3
Juniper ISG ScreenOS 6.3
Microsoft RRAS Windows Server 2012
Q: Sollten Offloading Funktionalitäten wie zum Beispiel VMQ auf der physischen NIC, die für die
Netzwerkvirtualisierung verwendet wird, aktiviert oder deaktiviert werden?
A: Offloading Funktionalitäten wie zum Beispiel VMQ sollten besser deaktiviert werden, wenn die
physische NIC kein NVGRE Offloading unterstützt. In vielen Threads der TechNet SCVMM Foren
wird von Problemen mit VMQ berichtet und es hat sich gezeigt, dass die Lösung die Deaktivierung
von VMQ ist. Windows Server 2012 R2 unterstützt NVGRE Offloading mittels Large Send Offload
(LSO), Receive Side Scaling (RSS) und Virtual Machine Queue (VMQ) in NDIS 6.30 und höher.
Mellanox und Emulex haben die Unterstützung für NVGRE Offloading bereits angekündigt. Um
VMQ auf der physischen NIC in der Parent Partition zu deaktivieren reicht das folgende PowerShell
Cmdlet:
Disable-NetAdapterVMQ –Name NIC1
Q: Ist das gleichzeitige Verwenden von IPv4 und IPV6 (Dual Stack) zum selben Zeitpunkt in einem
VM Network möglich oder/und welche Limitierungen bestehen bei Verwendung von NAT, Direct
Routing, S2S?
A: Nein. Man muss sich entweder für IPv4 oder IPv6 im CA Adressbereich für ein VM Network
entscheiden. Für NAT oder Direct Routing muss das Front-End Logical Network des Gateways mit
dem des Virtual Subnets übereinstimmen. Verwendet der CA Adressbereich IPv4, so muss auch das
Front-End ein IPv4 Subnet haben.
Für S2S muss nur das andere Ende des Tunnels von der Konfiguration übereinstimmen. Zum
Beispiel wird ein IPv6 CA Adressbereich und ein IPv4 Logical Network für das Front-End verwendet,
so muss die andere Seite des Tunnels IPv6 verwenden. Denn die ein- und ausgehenden Pakete des
VM Networks werden nie über das Front-End Netzwerk ohne IPSec Encapsulation geleitet.
Q: Wenn das Kommando „netsh interface IPv4 show subinterfaces“ ausgeführt wird, so ist die MTU
Größe in den VMs, die NVGRE verwenden, auf 1458 gesetzt. Warum?
A: Für die Verwendung von NAT muss die MTU Größe innerhalb einer VM für die IPv4 Provider
Address auf 1458 gesetzt sein. Diese Einstellung wird automatisch über den Hyper-V Virtual Switch
durch NDIS gesetzt.
Q: Das Virtualisierungsgateway wurde erfolgreich über das Service Template von Microsoft
bereitgestellt. Das Gateway wurde ebenfalls erfolgreich als Network Service im VMM hinzugefügt.
Aber irgendwie bekommen die Tenants keine Internetverbindung über NAT bereitgestellt.
A: In den meisten Fällen hat die VM der Virtualisierungsgateways mehrere NICs mit den jeweiligen
Standardgateways definiert. In diesem Fall muss man vorsichtig bei der Konfiguration der beiden
Routen und Metriken sein. Es ist wichtig, dass das Gateway über das Management Netzwerk vom
VMM verwaltet werden kann. Wenn das Management Netzwerk routingfähig ist, dann sollte eine
statische Route mit der passenden Metrik konfiguriert werden. Gleiches gilt für das Front-End
Netzwerk über das die Tenants ihre Internetverbindung erhalten. Für weitere Informationen bitte
den folgenden Blogeintrag lesen:
http://kristiannese.blogspot.no/2014/02/configuring-metrics-and-static-routes.html
Q: Nach einiger Zeit (Stunden, Tage) kann das Gateway sporadisch keine ausgehenden UDP oder
TCP Verbindungen mehr herstellen.
A: Dieses Problem entsteht dadurch, dass die Windows Filtering Platform (WFP) Binding Anfragen
unterbindet. Microsoft hat für dieses Problem einen Hotfix zur Verfügung gestellt.
http://support.microsoft.com/kb/2918813
Q: Gibt es Empfehlungen, wenn man das NVGRE Gateway Cluster mittels dem Multi-Tenant RRAS
Management Pack überwachen möchte?
A: Ja. Dazu bitte den folgenden Blogeintrag lesen, um das Management Pack in der eigenen System
Center Operations Manager Umgebung zu konfigurieren:
https://cloudadministrator.wordpress.com/2014/01/22/nvgre-gateway-cluster-not-discovered-
completely-by-the-multi-tenant-rras-mp/
Q: Best Practice ist es einen dedizierten Hyper-V Cluster für die Virtualisierungsgateways zu haben,
aber das Service Template von Microsoft ist nicht für das HA Deployment konfiguriert. Wieso?
A: Das Service Template des Virtualisierungsgateway stellt zwei VMs in einem Windows Failover
Cluster bereit. Aber wenn man sich das Hardware Profile anschaut, wird man feststellen das die
Option „High Availability“ nicht ausgewählt ist und dass das Service Deployment einen Shared
Storage auf dem Hyper-V Cluster benötigt. Der Grund dafür ist, dass das Service Template die
neuen Funktionalitäten im VMM 2012 R2 und Hyper-V unter Windows Server 2012 R2 verwendet.
Dazu zählen die Möglichkeiten unterschiedliche Skripte während der Guest Cluster Erstellung auf
der ersten VM (Erstellung des Clusters) und der anderen VM (Tritt dem Cluster bei) laufen zu
lassen. Ebenso die Verwendung von Shared VHDX für einen Guest Cluster, so dass der
Abstraktionslayer in der Fabric nicht aufgebrochen werden muss.
Das Service Template erstellt für beide VMs ein Availability Set, so dass die Shared VHDX Dateien
auf dem Shared Storage des Hyper-V Clusters liegen (CSV oder SMB), aber die VMs nicht als
hochverfügbar konfiguriert werden. Dies liegt daran, dass dass Virtualisierungsgateway Cluster ein
Aktiv/Passiv Cluster ist und daher eine 1:1 Beziehung zu den zwei für die Netzwerkvirtualisierung
dedizierten Hyper-V Cluster Knoten hat. Das heißt, dass man die Gateway VMs nicht per Live
Migration zwischen den Cluster Knoten verschoben werden sollten. Der Failover geschieht auf Host
und Guest Cluster Ebene automatisch.
Q: Wie kann ich das Dynamic IP Learning für meine Tenant VMs verwenden?
A: Das Dynamic IP Learning wurde mit Windows Server 2012 R2 eingeführt und muss in der VMM
Umgebung aktiviert werden. Dazu legt man ein neues Virtual Port Profile in der Fabric an und fügt
dieses dem Logical Switch, den die Hosts verwenden, hinzu. Diese Virtual Port Profile sollte die
Option „Allow guest specified IP addresses (only available for virtual machines on Windows Server
2012 R2)” aktiviert haben. Zum Schluss muss dieses Virtual Port Profile über die Port Classification
dem VM Template zugewiesen werden.
Q: Können die PA Adressen, Customer Routes und die Lookup Records manuell geändert werden?
A: Nein. Solange man den VMM verwendet und man sollte dieses verwenden, ist dieser für die
komplette Umgebung und das Setup zuständig. Wenn man die Netzwerkvirtualisierungsrichtlinien
anpasst, so wird man in den meisten Fällen die Funktionalität der Netzwerkvirtualisierung
verlieren, da die Lookup Records nicht mehr aktualisiert werden.
Q: Gibt es Performance Counter, um Geschwindigkeitsprobleme in den NVGRE Networks zu
identifizieren?
A: Ja. Die Performance Counter lauten „Network Virtualization\Inbound packets
dropped\Customer Routing Domain-(RDID)” und “Network Virtualization\Outbound packets
dropped\Customer Routing Domain-(RDID)”.
Feedback und Kontakt: Wir sind ständig auf der Suche nach Verbesserungen. Um uns Feedback zu geben und mit uns in
Kontakt zu treten, einfach die Q&A auf TechNet Gallery verwenden.