Windows Azure Pack: Konfigurieren der “Fabric” im System Center Virtual Machine Manager (SCVMM)

In meinem vorangegangenen Blog Beitrag habe ich beschrieben, wie ich mir mit dem Powershell Deployment Toolkit (PDT) eine Demoumgebung für das Windows Azure Pack auf einem Laptop aufgebaut habe. Zur Erinnerung: Die Umgebung besteht aus 6 virtuellen Maschinen, die alle zusammen auf einem Hyper-V Host laufen.

Die Systeme sind über einen internen Hyper-V Switch mit dem Namen Contoso Internal Switch vernetzt.

In diesem Beitrag geht es nun um das Konfigurieren der “Fabric” im System Center Virtual Machine Manager (SCVMM). Da das Ganze etwas umfangreicher wird, hier erst mal eine kurze Inhaltsübersicht mit Links zu den einzelnen Themen:

1. Importieren von Hyper-V Hosts in die SCVMM Fabric
1.1. Manuelle Installation des VMM Agent auf einen Standalone Hyper-V Host
1.2. Importieren von Standalone Hyper-V Hosts in die Fabric
2. Definition von Netzwerk Ressourcen
2.1. Netzwerkvirtualisierung mit NVGRE
2.2. Logische Netzwerke
2.3. IP Pools für die logischen Netze
2.4. VM Networks
2.5. Port Profiles, Uplink Port Profiles, Port Classifications und logical Switches
2.5.1. Port Profiles
2.5.2. Uplink Port Profiles
2.5.3. Port Classifications
2.5.4. Logical Switches
2.6. Netzwerkkonfiguration der Hyper-V Hosts mit logical Switches
3. “Umziehen” der existierenden VMs vom internen Hyper-V Switch auf den logischen VMM Switch
4. Nächste Schritte

1. Importieren von Hyper-V Hosts in die SCVMM Fabric

Um Hyper-V Hosts mit den darauf laufenden virtuellen Maschinen (VMs) mit dem System Center Virtual Machine Manager (SCVMM) verwalten zu können, müssen sie in die “Fabric” des SCVMM importiet werden. Das Vorgehen dabei unterscheidet sich in Abhängigkeit vom Typ des Hyper-V Hosts:

• Wenn der Hyper-V Host ein Mitglied der gleichen Active Directory Domäne wie der SCVMM ist bzw. wenn er sich in einer anderen vertrauenswürdigen Domäne befindet (zu der also ein “Trust” besteht), kann der Import in den SCVMM direkt geschehen. Dieser Abschnitt kann dann übersprungen werden.
• Einen Spezialfall stellt ein Server dar, der als Hyper-V Host importiert werden soll, auf dem aber noch kein Betriebssystem installiert ist (sogenanntes “Bare Metal Deployment”). Auch dann ist ein direkter Import  aus dem SCVMM heraus möglich, sofern die Server Hardware eine Remote Installation des Betriebssystems unterstützt. Diesen Fall wollen wir hier nicht weiter betrachten.
• Wenn es sich bei dem Hyper-V Host um einen Standalone Server handelt – wie hier im Fall meiner Demoumgebung – müssen wir vor dem Import zuerst den VMM Agent manuell auf dem Hyper-V Host installieren.

Zurück zur Übersicht

1.1. Manuelle Installation des VMM Agent auf einen Standalone Hyper-V Host

Um den VMM auf einen Standalone Hyper-V Host zu installieren, benötigen wir das Installationsmedium des SCVMM, entweder als DVD oder als ISO-Datei.

Tipp: Wenn Sie das Installer Verzeichnis von der PDT-Installation auf dem Hyper-V Host zur Verfügung haben, dann finden Sie die VMM Installationsdateien im Unterverzeichnis
…Installer\SystemCenter2012R2\VirtualMachineManager

Und so läuft die manuelle Installation des VMM Agents auf einem Standalone Hyper-V Host ab:

• Legen Sie das VMM Installationsmedium in den Hyper-V Host ein und starten dort die Setup.exe.
• Wählen Sie im Setup-Startbildschirm die Option Local Agent
• Es meldet sich der VMM Agent Setup Wizard.Klicken Sie auf Next.
• Lesen Sie die Lizenzinformationen und wählen Sie dann die Option I agree with the terms of this notice
  
  Klicken Sie auf Next
• Wählen Sie den Installationsordner für den VMM Agent. Im Normalfall werden Sie die Voreinstellung beibehalten.
  
  Klicken Sie auf Next
• Jetzt kommt ein entscheidender Schritt: Aktivieren Sie die Checkbox This host is in a perimeter network

Hierdurch werden die restlichen Felder der Wizard Seite aktiviert. Tippen Sie in die beiden Textfelder für den Encryption Key ein Passwort ein. Wichtig: Dieses Passwort wird später beim Importieren des Hyper-V Hosts in die VMM Fabric wieder benötigt. Achten Sie insbesondere auf Groß- und Kleinschreibung!

Der Setup Wizard erzeugt damit eine Datei mit dem Namen SecurityFile.txt (letztendlich ein selbstsigniertes Server Zertifikat). Das Verzeichnis für diese Datei können Sie über die Schaltfläche Change anpassen. Voreingestellt ist das Programmverzeichnis für den VMM Agent.

Anstatt dieses selbstsignierte Zertifikat zu verwenden, könnten Sie auch mit vorgefertigten Zertifikaten arbeiten, indem Sie die Option Use CA Signed certificate… aktivieren und die zusätzlich notwendigen Eingaben machen. In vielen Fällen – so auch hier in unserer Testumgebung – wird man wahrscheinlich darauf verzichten.

Wenn alle Eingaben erfolgt seind, klicken Sie wieder auf Next.

• Wählen Sie nun aus, ob Sie den Hyper-V Host beim späteren Importieren in den VMM über seinen Namen oder über die IP-Adresse ansprechen wollen. Auswirkung hat dies beim Erzeugen des Inhalts der vorstehend erwähnten Zertifikatsdatei.
  
  Klicken Sie wieder auf Next.
• In den Configuration Settings können Sie die Voreinstellungen übernehmen.Klicken Sie wieder auf Next.
• Damit sind alle notwendigen Informationen für die Installation des VMM Agents erfasst. Durch einen Klick auf die Schaltfläche Install können Sie nun die Installation starten.
• Der Fortschritt der Installation wird angezeigt und das Ende mit einer entsprechenden Meldung signalisiert.
  Durch einen Klick auf die Schaltfläche Finish wird die manuelle Installation des VMM Agents auf dem Hyper-V Host abgeschlossen. Das Installationsmedium für den SCVMM können Sie jetzt wieder aus dem Host entfernen.

Anmerkung: Ein Neustart des Hyper-V Hosts ist nicht notwendig!

Zurück zur Übersicht

1.2. Importieren von Standalone Hyper-V Hosts in die Fabric

Nachdem die Vorbereitungen auf dem / den Hyper-V Hosts abgeschlossen sind, können wir mit dem Konfigurieren der “Fabric” im SCVMM beginnen. Dazu starten wir in der Virtuellen Maschine (VM) WAPVMM01 die “Virtual Machine Manager Console” und melden uns als Administrator aus der CONTOSO-Domäne an.

Wenn wir im Konsolenfenster den Fabric Bereich auswählen und im Navigationsbaum den Knoten Servers anklicken, sehen wir, dass bislang nur das SCVMM System selbst registriert ist.

Ein Tipp vorneweg:

Um später beim Konfigurieren der Netzwerkumgebung im VMM keine Verwirrungen zu erzeugen, habe ich mir angewöhnt, im Settings Bereich der VMM-Konsole bei den Network Settings die Option Create logical networks automatically zu deaktivieren.

Zum Registrieren unseres Hyper-V Hosts wählen wir nun Im Fabric Bereich der VMM-Konsole im Menüband den Befehl Add Resources und rufen die Funktion Add Hyper-V Hosts and Clusters auf.

Es meldet sich der Add Resource Wizard

Hier müssen wir zunächst festlegen, wo sich unsere zu importierenden Hosts befinden:

• In einer vertrauenswürdigen Active Directory Domäne. Dies wird der Normalfall sein, wenn die Hyper-V Hosts Mitglieder in der gleichen Active Directory Domäne sind wie der VMM.
• In einer nicht vertrauenswürdigen Active Directory Domäne. Dies ist der Fall, wenn die Hyper-V Hosts Mitglieder einer anderen Active Directory Domäne sind wie der VMM.
• Die Hyper-V Hosts sind keine Mitglieder in einem Active Directory, d.h. es sind Standalone / Workgroup Systeme.
• Die Hyper-V Systeme sind noch nicht installiert, d.h. es sind “nackte” physische Server ohne Betriebssystem (“Bare Metal”). Dieser Weg kann gewählt werden, wenn zu einem späteren Zeitpunkt weitere neue physische Serversysteme in die Cloud Umgebung aufgenommen werden sollen.

Da es sich bei unserem Hyper-V Host um einen Standalone Server handelt, müssen wir die dritte Option Windows Server computers in a perimeter network auswählen. Dann können wir auf Next klicken.

Anmerkung: Damit wir den Vorgang fortsetzen können, muss spätestens jetzt auf dem Hyper-V Host der VMM Agent manuell installiert werden. Details dazu weiter oben.

Der Add Resource Wizard benötigt nun einige Angaben zu den Hyper-V Hosts, die importiert werden sollen:

• Computer name – Hier wird der computername des einzubindenden Hosts angegeben. Wurde bei der manuellen VMM Agent Installation auf dem Host angegeben, dass der VMM den Host über die IP-Adresse ansprechen soll, muss hier statt des Computernamens die IP-Adresse des Hosts eingegeben werden.
• Encryption key – Hier muss das “Passwort” eingegeben werden, das bei der manuellen VMM Agent Installation auf dem Hyper-V Host als Encryption Key festgelegt wurde. Es muss exakt mit dem Wert bei der Installation übereinstimmen, insbesondere bezüglich Groß- und Kleinschreibung.
• Security file path – Hier ist der Pfadname für die Zertifikatsdatei SecurityFile.txt anzugeben, wo diese bei der manuellen VMM Agent Installation erzeugt wurde. In unserem Fall hatte ich die Standardvorgabe verwendet, also das Programmverzeichnis des VMM Agent auf dem Host. Entsprechend kann ich hier als Pfad direkt eingeben:
  “\\<Hostname>\C$\Program Files\Microsoft System Center 2012 R2\Virtual Machine Manager\SecurityFile.txt”
• Host group – Sofern in der VMM Konsole bereits verschiedene Hostgruppen angelegt wurden, kann man hier die gewünschte Zielgruppe auswählen. Wir lassen hier die Voreinstellung All Hosts stehen.

Mit einem Klick auf die Schaltfläche Add sollte der Hype-V Host jetzt gefunden und in die Liste der einzubindenden Computer aufgenommen werden.

Will man weitere Hyper-V Hosts aufnehmen, kann dies auch gleich hier geschehen durch Eingabe der entsprechenden Informationen und einem erneuten Klick auf Add.

Sind alle Hyper-V Hosts in die Liste aufgenommen, können wir auf Next klicken.

Auf der Seite Host Settings können wir die Voreinstellungen übernehmen (die Option Reassociate this host with this VMM environment ist nur in Verbindung mit Active Directory Computern von Bedeutung; für Standalone Hosts spielt sie keine Rolle).

Durch einen Klick auf Next gelangen wir auf die Summary Seite und können die Eingaben nochmals kontrollieren. Außerdem befindet sich dort die Schaltfläche View Script, über die wir uns das vom Wizard erzeugte Powershell Skript anzeigen lassen und auf Wunsch auch speichern können.

Ein Klick auf die Schaltfläche Finish beendet nun den Wizard und startet das erzeugte Skript als Job in der VMM Konsole. Den Fortgang können wir im Job Fenster mitverfolgen.

Das Job Fenster können wir nun schließen. In der VMM Konsole erscheint nach kurzer Zeit im Fabric Bereich unser soeben importierter Hyper-V Host.

Wenn wir jetzt in der VMM Konsole den Bereich VMs and Services aktivieren und dort unseren soeben importierten Server markieren, werden uns die darauf laufenden VMs aufgelistet, in diesem Fall die mit dem PDT erzeugten System Center VMs.

Zurück zur Übersicht

2. Definition von Netzwerk Ressourcen

Bevor wir im VMM mit der Konfiguration von Netzwerk Ressourcen beginnen, sollten wir uns erst mal überlegen, welche Ressourcen wir für unsere Demoumgebung benötigen, was wir bereits haben und wie das im VMM abgebildet werden kann.

2.1. Netzwerkvirtualisierung mit NVGRE

Unser Ziel ist ein Infrastructure as a Service (IaaS) Angebot, das wir über das Windows Azure Pack (WAP) interessierten Kunden / Endanwendern (“Tenants”) bereitstellen wollen. Dies bedeutet, dass wir in der Lage sein müssen, kundenspezifische Netze mit vom Kunden vergebenen IP-Adressen zu isolieren und zu verwalten. Windows Server 2012 R2 und System Center 2012 R2 stellen uns hierfür die Netzwerkvirtualisierung auf Basis das GRE Protokolls (deshalb “NVGRE”) (http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-03) zur Verfügung. Dabei definiert der Kunde auf Basis seiner vorhandenen Netzwerkstruktur (Subnetze, IP-Adressbereiche, …) ein eigenes VM Netzwerk. Die in einem VM Netzwerk vergebenen IP-Adressen sind nur für die VMs sichtbar, die mit diesem VM Netzwerk verbunden sind. Wir sprechen deshalb hier von sogenannten “Customer Adressen” (CA), die ausschließlich vom Kunden verwaltet werden. Der Cloud Provider hat darauf keinen Einfluss. Er muss “nur” sicherstellen, dass die verschiedenen Kunden VM Netzwerke wirklich sauber voneinander isoliert sind.

Hierzu weist der Service Provider über den VMM jedem Kunden VM Netzwerk eine eindeutige “Virtuelle Subnet ID – VSID” zu, die innerhalb der Cloud eindeutig sein muss.

Will jetzt eine Kunden VM mit einer Customer Adresse (CA) Daten mit einer anderen VM im gleichen VM Netzwerk austauschen, so sind 2 Fälle zu unterscheiden:

• Die zweite VM läuft auf dem gleichen Hyper-V Host. Dann können die Datenpakete zwischen den VMs direkt ausgetauscht werden.
• Läuft die zweite VM dagegen auf einem anderen Hyper-V Host, so müssen die Datenpakete mit dem GRE-Protokoll verpackt und über ein Provider Netzwerk mit Provider Adressen (PA) an den anderen Host weitergeleitet werden. Die dabei übermittelten Datenpakete tragen als Quelle und Ziel IP-Adressen aus dem Provider Netzwerk (Provider Adressen – PA). In den verpackten Daten mit den CA ist außerdem die VSID des Kunden VM Netzwerks hinterlegt, so dass der empfangende Host die ausgepackten Daten dann an das richtige Kunden VM Netzwerk weiterleiten kann. Wichtig dabei ist, dass dieses Verfahren für die Kunden VMs völlig transparent ist. Sie sehen nur ihre eigenen CA.

Das Konzept der VSIDs ist vergleichbar mit der bisherigen VLAN Technologie. Es ist jedoch flexibler, da VSIDs ausschließlich von den beteiligten virtuellen Instanzen im Hyper-V defineirt werden, also keine zusätzlichen Netzwerktools benötigen, und auch wesentlich besser skalierten. VSIDs liegen im Bereich 4096 bis 2²⁴-2, wohingegen in einem herkömmlichen Netzsegment nur 4096 VLANs möglich sind.

Wir benötigen also auf jeden Fall ein solches Provider Netzwerk, das die Netzwerkvirtualisierung mit GRE unterstützt. Desweiteren sollten wir noch eigene Netze für einen externen Zugriff unserer (Kunden-) VMs (z.B. ins Internet) sowie für die Management Systeme mit den System Center Komponenten vorsehen.

Wir werden also 3 Netze definieren:

• Tenant Virtual Machines: Das erwähnte Service Provider Netz mit NVGRE. Wir verwenden dazu den im Host eingebauten Ethernet Adapter mit einem eigenen IP-Bereich. Auf eine VLAN-Kennung verzichten wir der Einfachheit halber.
• External: Das Netz für den Zugriff auf externe Ressourcen. Wir verwenden dazu den im Host eingebauten Ethernet Adapter ohne eine spezielle VLAN Kennung.
• Management: Dieses Netz wurde bereits in unserem Hyper-V Host als virtuelles Netz für die Installation mit dem PDT angelegt. Wir werden es hier im VMM der Vollständigkeit halber zwar definieren, aber zunächst keine weiteren Aktionen damit durchführen. Dem Netz geben wir entsprechend dem Zweck den Namen Management.

Anmerkung: In einer Produktivumgebung wird man weitere Netze z.B. für den Datenaustausch von Cluster-Knoten, für die Live Migration oder für den Zugriff auf die Storagegeräte hvorsehen. In unserer Demoumgebung mit nur einem Host und lokalen Storage Bereichen können wir natürlich darauf verzichten.

Jetzt können wir also loslegen mit der Definition der Netzwerk Ressourcen im VMM.

Zurück zur Übersicht

2.2. Logische Netzwerke

Zunächst müssen wir im SCVMM “Logical Networks” definieren, die unsere vorhandene bzw. geplante  Netzwerkinfrastruktur beschreiben.

Management Netz Management

Im Fabric Bereich der SCVMM Konsole öffnen wir den Knoten Networking, klicken mit der rechten Maustaste auf Logical Networks und rufen im Kontextmenü den Befehl Create Logical Network auf.

Es öffnet sich der Wizard Create Logical Network:

Ins Feld Name geben wir den Namen des Logical Networks ein, also Management. Die übrigen Optionen können wir mit den Voreinstellungen übernehmen (One connected network, keine Haken bei den Einstellungen Allow new VM networks … und Create a VM Network …).

Klicken Sie auf Next.  Es erscheint die Wizard Seite Network Site.

Hier können wir jetzt die zum Logical Network gehörenden Network Sites mit ihren IP Subnetzen und VLANs festlegen. Durch einen Klick auf Add fügen wir jeweils eine Network Site hinzu. Jede Network Site erhält einen Namen und wir legen fest, welche Hyper-V Hosts diese Network Site verwenden können. Über Insert row können wir jeweils ein oder mehrere VLAN / IP Subnetz Pärchen festlegen. Für unser Management Netz legen wir die Network Site Management_0 für alle Hosts an und legen als VLAN / IP Subnet die bei der PDT Installation verwendeten Werte VLAN 0 und IP Subnet 10.240.20.0/24 fest. Dann klicken wir auf Next.

Auf der Summary Seite werden die Eingaben nochmals angezeigt, die wir mit einem Klick auf Finish bestätigen.

Das logische Netzwerk wird nun angelegt. Den Fortschritt sehen wir im Job Fenster, das wir nach dem erfolgreichen Ende wieder schließen können.

Externes Netz External

Analog zum Management Netz Management erzeugen wir nun das logische Netzwerk External. Also

• Rechtsklick auf Logical Network –> Menüpunkt Create logical Network
• Name: External
  Option One connected network aktivieren
  Keine Haken bei den Einstellungen Allow new VM networks … und Create a VM Network …).
• Network Site:
  

  Name	External_0
  Host Groups	All Hosts
  VLAN	0 Anm.: Dieses VLAN ist von meinem etxernen Internet Router vorgegeben.
  IP Subnet	192.168.1.0/24 Anm.: Dieses Subnet ist von meinem etxernen Internet Router vorgegeben.

Das abschließende Job Fenster kann wieder geschlossen werden.

Logisches Netzwerk Tenant Virtual Machines

Dieses logische Netzwerk soll später Tenant-spezifische Netze per NVGRE bereitstellen. Das müssen wir hier gleich festlegen. Auf der ersten Seite des Create Logical Network Wizard müssen wir deshalb jetzt einen Haken setzen bei der Option Allow new VM networks created on this logical network to use network virtualization.

Der Rest läuft analog zum Anlegen der beiden anderen logischen Netze.

Network Site:

Das am Ende erscheinende Job-Fenster können wir wieder schließen.

Zurück zur Übersicht

2.3. IP Pools für die logischen Netze

Als nächstes sollten wir IP-Adresspools für jede Logical Network Site anlegen, so dass der VMM IP-Konfigurationen den Ressourcen innerhalb des jeweiligen Netzwerks selbst zuweisen kann. Hierdurch erspart man sich später manuelle Konfigurationen und ist auch nicht auf andere Dienste wie zum Beispiel DHCP angewiesen.

Zum Anlegen eines IP-Pools für eine Logical Network Site klicken wir mit der rechten Maustaste im Fabric Bereich der SCVMM Konsole bei den Logical Networks auf das logische Netzwerk, für das wir einen IP-Pool anlegen wollen und wählen im Kontextmenü den Befehl Create IP Pool.

Es öffnet sich der Create IP Pool Wizard:

Im Feld Name geben wir eine geeignete Bezeichnung für den neuen IP-Pool (im Beispiel Management IP Pool) ein und stellen sicher, dass in der Klappbox Logical network das gewünschte Netzwerk ausgewählt ist Mit einem Klick auf Next kommen wir zur Auswahl der gewünschten Network Site innerhalb des Logical Networks:

Nach dem Klick auf Next gelangen wir auf die Seite zum Festlegen des IP-Bereichs, der vom VMM verwaltet werden soll. Voreingestellt ist immer das gesamte IP-Subnet. Soll der vom VMM verwaltete IP-Bereich eingeschränkt werden, weil bereits Adressen andersweitig vergeben wurden, so kann dies hier geschehen. Im Beispiel hier erlaube ich für mein Management Netz nur IP-Adressen zwischen 10.240.20.201 und 10.240.20.239. Die anderen Adressen sind im Zuge der Installation der Management Systeme mit dem PDT bereits manuell vergeben.

Auf den Folgeseiten können wir – sofern notwendig und verfügbar – Gateway, DNS- und sogar WINS-Server Adressen angeben.

Auf der Summary Seite können wir die Eingaben nochmals überprüfen und dann durch einen Klick auf Finish den IP-Pool anlegen.

Das Job-Fenster können wir nach erfolgreichem Anlegen wieder schließen.

Analog zum IP-Pool für das Management-Netz legen wir für das External und das Tenant Virtual Machines Netzwerk ebenfalls je einen IP-Pool an:

External Netzwerk

Tenant Virtual Machines Netzwerk

Zurück zur Übersicht

2.4. VM Networks

Mit System Center Virtual Machine Manager 2012 R2 hat Microsoft ein weitere Abstraktionssschicht zum Beschreiben einer Cloud Netzwerkumgebung eingeführt, die insbesondere in Verbindung mit der Netzwerkvirtualisierung per NVGRE hilfreich ist.

Mit VM Networks können logische Netze mit virtuellen Netzwerkadaptern verbunden werden. Dabei besteht die Möglichkeit, Zugriffsrechte für VMM Self Service Benutzer (“Benutzerrollen / User Roles”) zu definieren. In einer Multi Tenant Umgebung kann somit sichergestellt werden, dass VMs einer Benutzergruppe auch nur mit ihr zur Verfügung stehenden VM Netzwerken verbunden werden können.

Generell sollten die virtuellen Netzwerkadapter aller virtuellen Maschinen grundsätzlich nur noch mit VM Networks verbunden werden (auch wenn eine direkte Zuordnung eines logischen Netzwerks technisch weiterhin möglich wäre und auch unterstützt ist).

Für “normale” logische Netzwerke (gemeint sind logical Network ohne Netzwerkvirtualisierung) besteht eine 1:1 Verbindung zu einem VM Network. Wir sollten deshalb für unsere logischen Netzwerke Management und External jeweils ein VM Network definieren.

Und warum kein VM Network für unser logisches Tenant Virtual Machines Netzwerk? Hierbei handelt es sich um ein logisches Netzwerk mit Netzwerkvirtualisierung per NVGRE. Und dafür wollen wir unseren späteren Kunden (Tenants) die Möglichkeit anbieten, eigene isolierte VM Netze mit eigenen IP-Subnetzen für ihre VMs anzulegen. Für solche logischen Netze können also beliebig viele VM Networks definiert werden. Wie wir noch sehen werden, kann dies über das Tenant Portal des Windows Azure Packs durch die Kunden selbst durchgeführt werden.

Zum Anlegen eines VM Networks aktivieren wir in der VMM Konsole den Arbeitsbereich VMs and Services und klicken mit der rechten Maustaste auf den Knoten VM Networks.

Es öffnet sich das Dialogfenster Create VM Network Wizard.

Hier können wir den Namen des neuen VM Networks und eine Beschreibung dazu eingeben. In der Klappbox Logical network wählen wir das gewünschte logische Netzwerk aus (hier External). Mit einem Klick auf Next gelangen wir auf die Summary Seite, die wir mit einem Klick auf Finish beenden können.

Analog erzeugen wir uns ein VM Network mit dem Namen Management VM Network für das logische Netzwerk Management.

Jetzt werden Sie fragen, wo man die soeben erwähnten Zugriffrechte für Benutzerrollen festlegen kann. Vom Wizard wird automatisch die Benutzerrolle, unter der man gerade angemeldet ist, als Besitzer / Owner eingetragen. Einsehen oder Ändern kann man das dann über die Properties des VM Networks in der Registerkarte Access.

Zurück zur Übersicht

2.5. Port Profiles, Uplink Port Profiles, Port Classifications und logical Switches

Mit den vorstehend beschriebenen logischen und VM Netzen haben wir unsere Netzwerkinfrastruktur definiert. Als nächstes müssen wir nun diese Netze mit diversen weiteren Netzwerkobjekten unserer Cloudumgebung verknüpfen. Bei diesen Netzwerkobjekten handelt es sich sowohl um virtuelle Netzwerkadapter der verschiedenen virtuellen Maschinen (VMs) als auch um physische Netzwerkadapter in den Hyper-V Hosts.

Der System Center Virtual Machine Manager (SCVMM) 2012 R2 stellt uns hierfür einen Werkzeugkasten in Form von Port Profiles, Uplink Port Profiles, Port Classifications und logical Switches zur Verfügung. Bevor wir diese Elemente für unsere Demoumgebung konfigurieren, wollen wir uns jeweils einen kurzen Überblick verschaffen, wozu diese Elemente dienen.

Zurück zur Übersicht

2.5.1. Port Profiles

Mit Port Profiles können Funktionen von virtuellen Netzwerkadaptern festgelegt werden, wie z.B. Sicherheitseinstellungen (“Security Settings”) oder Einstellungen zum Auslagern von Netzwerkdatenverkehr-Funktionen (“Offload Settings”) aus dem Betriebssystem in den jeweiligen Netzwerkadapter (sofern von der zugrunde liegenden Hardware unterstützt). Auch eine gewichtete Bandbreitensteuerung kann definiert werden. Details hierzu würden den Rahmen dieses Beitrags sprengen, zumal wir sie für unsere Demoumgebung nicht benötigen. Ich verweise deshalb auf die Microsoft Technet Library (http://technet.microsoft.com/de-de/library/jj721570.aspx (deutsch) bzw. http://technet.microsoft.com/en-us/library/jj721570.aspx (englisch)), wo sie im Einzelnen näher beschrieben werden.

In der VMM Fabric sind für verschiedene Einsatzzwecke bereits Port Profiles vordefiniert. Diese Liste kann natürlich bei Bedarf um eigene Profile erweitert werden.

Für unsere Demoumgebung werden wir im Folgenden auf das vordefinierte Profile Default zurückgreifen.

Zurück zur Übersicht

2.5.2. Uplink Port Profiles

In einem Uplink Port Profile wird festgelegt, welche Netzwerk Sites unserer logischen Netzwerke mit einem physischen Netzwerkadapter in einem Hyper-V Host verbunden werden können und welcher Modus für das Bilden von Netzwerkadapter-Teams eingesetzt werden soll.

Für unsere Demoumgebung müssen wir uns nun ein geeigneten Uplink Port Profile erstellen. Dazu klicken wir mit der rechten Maustaste im Fabric Bereich der VMM Konsole auf den Knoten Port Profiles, um die Funktion Create Hyper-V Port Profile aufzurufen.

Es öffnet sich der Wizard Create Hyper-V Port Profile

Hier können wir wie üblich einen Namen für das Uplink Port Profile (hier: Server Default Uplink) und eine Beschreibung eingeben. Im unteren Bereich müssen wir noch die Option Uplink Port Profile auswählen. Die übrigen Einstellungen können wir übernehmen.

Wenn wir auf Next klicken, gelangen wir auf die Seite Network Configuration.

Hier wird uns eine Liste aller für logische Netze definierten Network Sites präsentiert. Durch Setzen eines Hakens vor einer Network Site legen wir fest, dass diese in den Uplink Port eingebunden werden soll und somit später auch mit Hosts verbunden werden kann. Für unsere Demoumgebung selektieren wir alle 3 angezeigten Sites. Die Option Enable Hyper-V Network Virtualization sollten wir grundsätzlich aktivieren, auch wenn dies für unsere Demoumgebung unwichtig ist, da wir durchgängig mit Windows Server 2012 R2 arbeiten.

Durch einen Klick auf Next gelangen wir auf die Summary Seite, wo wir durch einen Klick auf Finish das Erzeugen des Uplink Port Profiles abschließen.

Zurück zur Übersicht

2.5.3. Port Classifications

Eine Port Classification ist ein globaler Name zum Identifizieren verschiedener Typen von Port Profiles für virtuelle Netzwerkadapter. Eine Port Classification kann für mehrere logische Switche verwendet werden, wobei aber die Switch-spezifischen Einstellungen erhalten bleiben.

Auch für Port Classifications bietet der VMM bereits eine Reihe vordefinierter Elemente analog zur Liste der Port Profiles.

Da wir uns im vorstehenden Schritt ein eigenes Uplink Port Profile konfiguriert haben, definieren wir uns dafür auch eine eigene Port Classification.

Wir vergeben als Name Server Default Workload und das war’s auch schon.

Zurück zur Übersicht

2.5.4. Logical Switches

Ein logischer Switch ist eine Zusammenstellung von Port Profiles, Uplink Port Profiles und Port Classifications, die auf die physischen Netzwerkadapter unserer Hosts angewendet werden kann. Ein logischer Switch kann auch Erweiterungen enthalten für zusätzliche Switch Funktionen wie das Überwachen, das Filtern oder das Weiterleiten von Datenpaketen. Microsoft liefert mit dem VMM bereits einige Erweiterungen aus. Zusätzliche Erweiterungen können von Drittanbietern entwickelt und in die VMM-Umgebung eingebunden werden (Beispiel: Cisco Nexus 1000V).

Für unsere Demoumgebung haben wir in den vorangegangenen Schritten die notwendigen Elemente erzeugt, um einen logischen Switch für unseren Host zu erzeugen.

Im Fabric Bereich der VMM Konsole klicken wir mit der rechten Maustaste auf den Knoten Logical Switches und rufen die Funktion Create Logical Switch auf.

Die Startseite des Wizards können wir mit Next überspringen. Auf der nächsten Seite General vergeben wir einen Namen für den neuen logischen Switch (hier: Contoso Datacenter Switch).

Die nächste Seite Extensions zeigt uns eine Liste verfügbarer Erweiterungen für logische Switches. Standardmäßig ist hier bereits die Microsoft Windows Filtering Platform ausgewählt.

Für unsere Demoumgebung reicht dies und wir kommen mit einem Klick auf Next auf die Seite zum Einbinden der benötigten Uplink Port Profiles.

Zunächst müssen wir hier auswählen, ob der logische Switch einzeln oder im Team arbeiten soll. Da wir kein Teaming verwenden, können wir die Voreinstellung No Uplink Team lassen. Mit einem Klick auf Schaltfläche Add erhalten wir eine Liste der verfügbaren Uplink Port Profiles, aus der wir jeweils einen Eintrag auswählen können (hier unser zuvor definierter Server Default Uplink).

Zurück im Logical Switch Wizard finden wir unsere ausgewählten Uplink Port Profiles aufgelistet.

Durch einen Klick auf Next gelangen wir zur Seite für das Einbinden virtueller Ports in unseren logischen Switch.

Über die Schaltfläche Add können wir einen Dialog aufrufen zum Auswählen einer Port Classification und eines dazu passenden Port Profiles.

Ein Klick auf die Schaltfläche Browse bringt uns eine Liste der verfügbaren Port Classifications, in der wir den zuvor definierten Eintrag Server Default Workload auswählen.

Nun sollten wir noch ein Port Profile für den virtuellen Port einbinden. Dazu aktivieren wir die Option Include a virtual network adapter profile in this virtual port und wählen in der Liste das weiter oben bereits erwähnte Port Profile Default aus.

Mit OK gelangen wir wieder zurück in den logical Switch Wizard, wo wir in der Liste unseren soeben konfigurierten Virtual Port finden.

Jetzt können wir diesen virtuellen Port noch als Default setzen, was aber in unserer Demoumgebung überflüssig ist, da wir nur einen virtuellen Port einbinden. Mit einem Klick auf Next erreichen wir die Seite Summary

auf der wir durch einen Klick auf Finish unseren logical Switch erzeugen können. Nach kurzer Zeit wird er uns auch in der VMM Konsole angezeigt.

Zurück zur Übersicht

2.6. Netzwerkkonfiguration der Hyper-V Hosts mit logical Switches

Wir haben jetzt alle Bausteine zusammen, um den physischen Netzwerkadapter unseres Hyper-V Hosts mit einem logischen Switch in unsere geplante Cloud Umgebung mit dem Windows Azure Pack einzubinden.

Dies erfolgt über die Properties des Hyper-V Hosts. Im Fabric Bereich der VMM Konsole klicken wir mit der rechten Maustaste auf den gewünschten Hyper-V Host und rufen im Kontextmenü die Properties auf.

Im Properties Fenster des Hyper-V Hosts gibt es verschiedene Kategorien für die Einstellungen. Schauen wir uns zunächst in der Kategorie Hardware die Einstellungen für die Netzwerkadapter an. Wir finden dort u.a. einen Bradcom NetXtreme… Ethernet Adapter, auf dem wir die weitere Konfiguration durchführen wollen. In der Übersicht mit Logical Network Verbindungen finden wir zwar alle bisher definierten logical Networks mit ihren Sites, jedoch ist keines dieser Elemente aktiviert.

Bitte ändern Sie an dieser Stelle nichts! Die Zuordnung unseres logical Switches auf den Ethernetadapter des Hosts geschieht in der Kategorie Virtual Switches.

In dieser Kategorie finden wir bereits einen internen Switch. Es handelt sich um den eingangs erwähnten Hyper-V internen Switch, über den die ursprünglich mit dem Powershell Deployment Toolkit (PDT) erzeugten VMs untereinander kommunizieren. Ich werde am Ende noch zeigen, wie wir diese VMs in die endgültige Netzwerkumgebung mit unserem logischen Switch “umziehen” können und damit der interne Hyper-V Switch überflüssig wird.

Um unseren logischen Switch Contoso Datacenter Switch hier einzubinden, klicken wir zunächst auf den Menüpunkt New Virtual Switch und wählen dort die Funktion New Logical Switch aus.

Anmerkung: Über die ewbenfalls angebotene Funktion New Standard Switch könnten wir hier auch weitere Hyper-V Switches definieren wie im Hyper-V Switch Manager.

Es werden nun die Daten für einen neuen logischen Switch angezeigt.

Da wir bisher nur einen einzigen logischen Switch definiert haben, sollte dieser direkt in der Klappbox Logical Switch voreingestellt sein. Haben wir mehrere logische Switches definiert, so können wir den gewünschten in der Klappbox auswählen.

Analog wählen wir in den darunter angeordneten Klappboxen den gewünschten physischen Netzwerkadapter des Hosts und den darauf anzuwendenden Uplink Port Profile (hier unseren Server Default Uplink) aus.

Der Ethernetadapter unseres Hosts ist jetzt also mit unserem logischen Switch Contoso Datacenter Switch verbunden. Damit nun der Host selbst aber auch in dieser virtuellen Netzwerkumgebung insbesondere im VM- Network Management kommunizieren kann, müssen wir ihm noch einen virtuellen Netzwerkadapter mit geeigneter Konfiguration “spendieren”. Dazu klicken wir den Menüpunkt New Virtual Network Adapter an.

In den neu eingeblendeten Feldern können wir jetzt die Parameter für den virtuellen Netzwerkadapter eintragen.

Als erstes muss er einen Namen erhalten – hier Management:

Im nächsten Schrtt müssen wir festlegen, mit welchem VM Network dieser virtuelle Netzwerkadapter verbunden werden soll. Dazu klicken wir auf die Schaltfläche Browse. Wir erhalten eine Liste unserer zuvor definierten VM Networks und wählen dort das Management VM Network.

Zurück in den Properties unseres Hosts bei den Virtual Switches sollten wir für den virtuellen Netzwerkadapter noch in der Klappbox eine passende Port Profile Classification auswählen.

Mit einem Klick auf OK können wir nun die Integration unseres Hosts in die virtuelle VMM Netzwerkumgebung abschließen. Hinweis: Dies kann einige Zeit dauern, da je nach Konfiguration auf dem Host einige Switch-Erweiterungen installiert werden müssen. Im Job-Fenster des VMM können wir den Ablauf mitverfolgen.

Jetzt stellt sich noch eine letzte Frage: Welche IP-Adresse erhält der virtuelle Netzwerkadapter des Hosts für Management Netz? Dazu rufen wir nochmals in den Properties des Hosts die Kategorie Virtual Switches auf und markieren den gerade hinzugefügten virtuellen Netzwerkadapter Management

Jetzt werden uns zusätzliche Parameter insbesondere für die IP Address Configuration angeboten. Wir wählen jetzt die Option Static und in der dadurch aktivierten Klappbox IPv4 Pool den zuvor definierten IP-Pool für das Management Netz.

Mit einem Klick auf OK werden die neuen Einstellungen dem Host zugeordnet. Hinseis: Es kann dabei zu einer kurzzeitigen Unterbrechung der Netzwrkverbindung zwischen VMM und Host kommen.

Zurück zur Übersicht

3. “Umziehen” der existierenden VMs vom internen Hyper-V Switch auf den logischen VMM Switch

Unsere VMs mit den System Center Komponenten wurden mit dem Powershell Deployment Toolkit (PDT) in einem eigenen internen Hyper-V Netzwerk Contoso Internal Switch erzeugt. Um diese VMs nun über das VM Network Management betreiben zu können, müssen wir sie “umziehen”. In der physischen Welt würde man das Netzwerkkabel eines Systems von einem Switch abziehen und in den anderen einstecken. Das geht im Allgemeinen ohne größere Probleme. Gleiches gilt für unsere irtuelle Welt.

In den Properties einer VM – hier am Beispiel unseres Domain Controllers WAPDC01 – rufen wir die Hardware Konfiguration für den virtuellen Netzwerkadapter der VM auf.

Im oberen Bereich klicken wir auf Browse und wählen in der Liste der VM Networks das Management VM Network aus. Hierdurch werden im unteren Bereich die Optionen zum Umschalten zwischen Switch Typen aktiv.

Wir aktiveiren die Option Logical Switch und können in den zugehörigen Klappboxen den gewünschten Logical Switch und eine passende Port Classification auswählen.

Durch einen Klick auf OK wird nun der “Umzug” der VM in das neue Netz angestoßen.

Sind alle VMs in das neue Netz umgezogen, so können wir den nun nicht mehr benötigten internen Hyper-V Switch in den Properties des Hosts natürlich entfernen.

Zurück zur Übersicht

4. Nächste Schritte

Wir haben nun im VMM die Netzwerkumgebung für unsere IaaS Cloud mit dem Windows Azure Pack erzeugt. Wie geht’s weiter?

• Zunächst müssen wir die Library des SCVMM mit VM Templates füllen, die dann als Basis für “Plans” im Windows Azure Pack dienen können.
• Anschließend müssen wir die Komponenten der Service Provider Foundation (SPF) konfigurieren, die als Bindeglied zwischen den Portalen des Windows Azure Packs und den System Center Komponenten fungieren.
• Erst dann können wir uns dem Admin-Portal des Windows Azure Packs zuwenden, um Angebote (“Plans”) für unsere späteren Kunden zu schnüren.

Auf diese Themen werde ich in meinem nächsten Beitrag Windows Azure Pack: Konfigurieren und Bereitstellen eines einfachen IaaS Cloud- Dienstes zurückkommen.

Zurück zur Übersicht