Windows Azure Pack: Konfigurieren und Bereitstellen eines einfachen IaaS Cloud- Dienstes
Das Windows Azure Pack (WAP) im Zusammenspiel mit der Service Provider Foundation (SPF), dem System Center Virtual Machine Manager 2012 R2 (SCVMM) und dem Windows Server 2012 R2 ermöglicht es einem Service Provider, Multitenant IaaS-Cloud Dienste zu realisieren.
In diesem Artikel möchte ich an Hand meiner WAP-Demoumgebung aufzeigen, wie man diese Komponenten konfigurieren kann, um ein einfaches Multitanent IaaS- Angebot bereitzustellen. Endanwender (“Tenants”) können damit virtuelle Maschinen erzeugen und nutzen, die über selbst erzeugte virtuelle Netzwerke miteinander kommunizieren. Die virtuellen Netze der verschiedenen Tenants sind durch Netzwerkvirtualisierung per GRE-Protokoll (NVGRE) vollständig voneinander getrennt.
Um in diesem etwas längeren Artikel die Navigation zu erleichtern, hier erst mal eine Übersicht mit Links zu den einzelnen Themen:
1. Eine Architekturübersicht
2. Vorbereiten der Demoumgebung
2.1. Netzwerkdefinitionen aus der SCVMM “Fabric”
2.2. Vorlagen für virtuelle Maschinen (VM Templates) in der “Library”
2.3. Nacharbeiten an den VM Templates
2.4. Kapazitätsdefinitionen für Clouds
3. Konfiguration des Admin Portals im Windows Azure Pack
3.1. Definieren von Cloud Diensten
3.2. Erstellen eines Plans
3.3. Plan veröffentlichen
4. Das Tenant Self Service Portal
4.1. Anmeldung bzw. Registrierung beim Tenant Portal
4.2. Hinzufügen eines Abonnements für einen Plan
4.3. Erstellen eines Tenant-spezifischen virtuellen Netzwerks
4.4. Erstellen von virtuellen Maschinen
4.5. Unschönheiten
5. Verifikation der Isolation von Tenant Netzen per Netzwerkvirtualisierung
5.1. Vorbereitungen
6. Fazit und nächste Schritte
1. Eine Architekturübersicht
Bevor wir mit der Konfiguration der Komponenten loslegen, sollten wir uns einen Überblick über die Architektur der beteiligten Komponenten verschaffen.
Endanwender registrieren bzw. authentisieren sich auf einer Website – hier “Tenant Self Service Portal” genannt – und können aus einem vom Service Provider bereitgestellten Katalog virtuelle Maschinen, Speicherplatz und isolierte virtuelle Netzwerke als Abonnement bestellen und nutzen.
Die bestellbaren Ressourcen werden vom Service Provider über eine eigene Website – hier “Admin Portal” genannt – definiert und veröffentlicht.
Für die beiden Portale stellt die Service Provider Foundation (SPF) jeweils eine eigene Anwendungsschnittstelle (API) in Form von Webservice Endpunkten zur Verfügung. Darüber können die Portale auf die verschiedenen Objekte und Funktionen der darunter liegenden System Center Komponenten zugreifen sowie die WAP-spezifischen Objekte wie Cloud Dienste, Pläne und Abonnements verwalten. Die WAP-spezifischen Objekte werden innerhalb der SPF in einer eigenen Datenbank organisiert.
Für die Bereitstellung von IaaS Cloud Diensten sind insbesondere Objekte aus dem System Center Virtual Machine Manager (SCVMM) von Bedeutung:
- Netzwerkdefinitionen aus der SCVMM “Fabric”
- Vorlagen für virtuelle Maschinen (VM Templates) in der “Library”
- Kapazitätsdefinitionen für Clouds
Wir müssen also zunächst im SCVMM die Basis schaffen, um dann im Admin Portal entsprechende Dienste und Pläne bereitstellen zu können.
2. Vorbereiten der Demoumgebung
Für die nachstehenden Schritte zur Bereitstellung eines einfachen IaaS Cloud-Dienstes greife ich auf meine mit dem Powershell Deployment Toolkit (PDT) erzeugte Demoumgebung zurück, die ich in einem früheren Artikel bereits beschrieben habe (siehe Windows Azure Pack: Aufbau einer IaaS-Demoumgebung mit dem Powershell Deployment Toolkit (PDT)).
Zur Erinnerung: Die Umgebung besteht momentan aus 6 virtuellen Maschinen, die alle zusammen auf einem Hyper-V Host laufen.
| VM-Name | Funktion |
| WAPDC01 | Domain Controller. Name der Domain: CONTOSO.COM Alle VMs sind Mitglieder dieses Active Directories |
| WAPVMM01 | System Center Virtual Machine Manager (SCVMM) und App Controller |
| WAPSCO01 | Orchestrator, Service Provider Foundation (SPF) und das Administrations-Portal für das Azure Pack |
| WAPOM01 | Operations Manager einschl. der Datenbanken sowie den Datawarehouse und Report Server Funktionen |
| WAPSQL01 | MS SQL Server für alle anderen Datenbanken (außer Operations Manager) |
| WAPTenant01 | Benutzer / Kunden Portal |
Wichtig: Dank der Installation mit dem PDT sind bereits die SPF-Komponente und die beiden Portale vorkonfiguriert und mit den benötigten SQL-Datenbanken verknüpft.
2.1. Netzwerkdefinitionen aus der SCVMM “Fabric”
Die “Fabric” im SCVMM habe ich ebenfalls bereits vorkonfiguriert. Details finden sich in meinem Blog-Artikel Windows Azure Pack: Konfigurieren der “Fabric” im System Center Virtual Machine Manager (SCVMM). Das wichtigste Element für unsere weitere Vorgehensweise hier: Ein logisches Netzwerk mit dem Namen “Tenant Virtual Machines”, bei dem die Eigenschaft / Property Allow new VM networks created on this logical network to use network virtualization für Hyper-V Network Virtualization aktiviert und für das ein IP-Pool Tenant PA IP Pool mit dem IP-Subnetz 192.168.100.0/24 definiert ist.
Dieses logische Netzwerk dient als “Provider Netz” für die virtuellen Netzwerke unserer zukünftigen Tenants, die über das NVGRE-Protokoll voneinander streng isoliert sind. Details dazu finden Sie im Abschnitt Netzwerkvirtualisierung mit NVGRE in meinem vorstehend bereits verlinkten letzten Blog-Artikel.
2.2. Vorlagen für virtuelle Maschinen (VM Templates) in der “Library”
Beginnen wir also mit dem Erzeugen von VM-Templates in der Library des SCVMM. In der VMM-Konsole wechseln wir in den Library Arbeitsbereich, klicken mit der rechten Maustaste auf den Knoten VM Templates und wählen den Befehl Create VM Template.
Es öffnet sich das Fenster Create VM Template Wizard.
Wir wollen mit einer virtuellen Festplatte starten, die wir bereits in der Library hinterlegt haben. Durch einen Klick auf die Browse Schaltfläche erhalten wir eine Liste der vorhandenen VHD- bzw. VHDX-Dateien.
Für unser Beispiel wähle ich die VHDX-Datei WS12R2D.vhdx. Sie enthält eine Windows Server 2012 R2 Datacenter Edition in neutralisierter Form. Ich habe mir zuvor diese Datei mit dem Powershell-Skript Convert-WindowsImage.ps1 (siehe Microsoft Technet Gallery) aus der ISO-Datei mit dem Server 2012 R2 erzeugt und sie dann manuell in die VMM-Library kopiert.
Natürlich können Sie auch andere neutralisierte Betriebssystem Images wie z.B. Windows Server 2008 R2 verwenden. In den Images können Sie auch bereits Anwendungen vorinstallieren. Wichtig ist, dass einmal bereits installierte Images vor dem Kopieren in die Library mit sysprep.exe wieder neutralisiert werden.
Mit einem Klick auf OK kommen wir wieder zurück in das Fenster Create VM Template Wizard, wo jetzt die ausgewählte Datei aufgeführt ist.
Durch einen Klick auf Next gelangen wir auf die Seite Identity.
Hier können wir jetzt einen Namen für unser neues VM Template einschließlich einer Beschreibung eingeben und den VM Generation Typ festlegen.
Beim Namen sollten wir berücksichtigen, dass dieser später unseren Tenants im Portal in einer alphabetisch sortierten Liste angezeigt wird, d.h. wir sollten uns eine geeignete Namenskonvention überlegen.
In der Klappbox Generation können wir festlegen, ob aus diesem Template erzeugte VMs vom Typ 1 oder 2 sind. Gen2 Systeme bieten neuere Funktionen wie das Booten von virtuellen SCSI-Laufwerken, erfordern aber zwingend Windows Server 2012 R2. Gen1 VMs bieten diese neuen Möglichkeiten nicht, sind aber dafür universeller auch auf älteren Hyper-V Systemen wie Server 2012 oder 2008 R2 verwendbar.
Wichtig: Von der aktuellen Version des Windows Azure Packs werden Gen2 VMs nicht unterstützt.
Für unsere Demoumgebung vergebe ich als Template Namen A00 – Small Windows Server 2012 R2 en mit einer entsprechenden Beschreibung und lege als VM-Typ Gen1 fest.
Mit einem Klick auf Next gelangen wir auf die nächste Seite Configure Hardware. Hier müssen wir einige Besonderheiten beachten, wenn unser Template später mit dem Windows Azure Pack reibungslos funktionieren soll.
Beginnen wir mit den Cloud Capabilities in der Hardwarekategorie Compatibility. Bitte setzen Sie bei keinem der angezeigten Hypervisor einen Haken! Dies kann in Verbindung mit dem Azure Pack zu Kompatibilitätsproblemen führen. WAP VMs werden grundsätzlich auf Hyper-V Systemen erzeugt.
Bei den nächsten Hardwarekategorien können wir die Voreinstellungen übernehmen – empfehlenswert für meine Demoumgebung ist es allerdings, den Hauptspeicher statisch auf 1024 MB einzustellen.
In der Hardwarekategorie Bus Configuration sollten wir einen Blick auf die IDE Devices werfen. Dort ist mit dem Anschluss 0 am Primary Channel bereits unsere zuvor ausgewählte VHDX-Datei mit dem Betriebssystem verbunden. Wir können über die Klappbox Classification noch festlegen, auf welchem Storage die virtuelle Festplatte einer späteren VM erstellt werden soll.
Da ich in meiner Demoumgebung nur lokale Festplatten zur Verfügung habe, wähle ich hier Local Storage.
Spannend wird es in der nächsten Hardwarekategorie Network Adapters. Dort ist zwar bereits ein Netzwerkadapter vorhanden, aber mit keinem Netzwerk verbunden. Unseren Tenants wollen wir später die Möglichkeit bieten, eigene virtuelle Netze mit eigenen statischen IP-Pools anzulegen. Dazu müssten wir jetzt zumindest die Option Static IP (from a static IP pool) aktivieren. Diese ist aber ausgegraut und wird erst aktiv, wenn wir ein VM Netzwerk auswählen. Was tun?
Ich arbeite mit folgendem Workaround: Ich aktiviere die Option Connected to a VM Network und wähle über die Browse-Schaltfläche ein bereits vorhandenes VM Network aus (beispielsweise das Management VM Network). Jetzt können wir die Option Static IP (from a static IP pool) aktivieren und auch die Option für static MAC Address wird automatisch aktiviert. Außerdem können wir jetzt auch die Port Profile Classification festlegen. Ich wähle hier die in der Netzwerk Fabric vordefinierte Klassification Server Default Workload aus.
Mit diesen Einstellungen müssen wir zunächst unser VM Template erstellen. Danach können wir die Verbindung mit unserem Management VM Network wieder aufheben. Die static Einstellungen für IP Pool und MAC Adresse bleiben dann aber erhalten.
Die Einstellungen in den restlichen Hardwarekategorien können wir – zumindest hier für unsere Demoumgebung – unverändert übernehmen. Mit einem Klick auf Next gelangen wir auf die nächste Seite Configure Operating System.
Das Wichtigste zuerst: Bitte belassen Sie in der Klappbox Guest OS Profile die Voreinstellung [Create new Windows operating system customization settings] und konfigurieren Sie die verschiedenen Parameter wie nachstehend beschrieben. Überspringen Sie auf keinen Fall die weitere Konfiguration durch Auswahl von [none – customization not required] in der Klappbox Guest OS Profile. Damit wäre das VM Template in der Windows Azure Pack Umgebung nicht mehr verwendbar.
Nun zu den einzelnen Parametern in den verschiedenen Kategorien:
Kategorie General Settings
Operating System: Hier sollte auf Grund der vorangegangenen Auswahl des Festplatten Image vereits die richtige Betriebssystemversion angezeigt werden. Ansonsten können Sie über die Klappbox das gewünschte Betriebssystem auswählen.
Identity Information: Den Computernamen einer VM wollen wir durch unsere Tenants vorgeben lassen. Somit können wir den den Stern (“*”) übernehmen.
Admin Password: Hier übernehmen wir die Voreinstellung No local administrator credential required. Dies hat zur Folge, dass ein Tenant beim Bestellen einer VM im Portal zur Eingabe eines Kennworts für die lokale Administratorkennung aufgefordert wird.
Product Key: Hier sollten Sie unbedingt einen gültigen Product Key für das ausgewählte Betriebssystem eingeben. Bleibt dieses Feld leer, bleibt beim späteren Erstellen einer VM die Systeminstallation im Startbildschirm stehen und erwartet interaktiv die Eingabe eines Product Keys. Tenants haben aber zu diesem Zeitpunkt noch keinen Zugriff auf die VM. Außerdem widerspricht es dem Cloud Gedanken, dass Tenants sich um einen Product Key kümmern müssen. Optimal ist hier die Verwendung von Product Keys für einen Key Management Server (KMS). Sofern Sie die Hyper-V Hosts mit einer Windows Server 2012 R2 Datacenter Edition betreiben und die VMs eine beliebige Server 2012 R2 Edition enthalten, können Sie hier natürlich auch einen entsprechenden AVWA Product Key verwenden (Details siehe Microsoft Technet). Alternativ zur Eingabe eines Product Keys an dieser Stelle können Sie ihn auch in einer Antwortdatei (Answer File) hinterlegen. Die entsprechende Option können Sie allerdings erst anwählen, wenn Sie tatsächlich eine Antwortdatei angegeben haben (siehe weiter unten).
Time Zone: Hier können Sie die Zeitzone einstellen, mit der die VMs später laufen sollen.
Kategorie Roles and Features
Hier können Sie festlegen welche Windows Funktionen im Zuge der Erstellung einer VM mitinstalliert werden sollen. Für unser Beispiel hier verzichten wir darauf.
Kategorie Networking
Domain / Workgroup: Hier könnten wir festlegen, in welche Active Directory Domäne die VMs aufgenommen werden sollen, die aus diesem VM Template erzeugt werden. Da wir dies unseren Tenants überlassen wollen, können wir die Voreinstellungen für WORKGROUP übernehmen.
Kategorie Scripts
Answer File: Hier können Sie den Namen einer Datei angeben, die zusätzliche Installationsanweisungen für das Betriebssystem in der VM enthält. Eine solche Datei können Sie mit dem Windows Assessment and Deployment Kit (WADK) erzeugen, das auf jedem SCVMM Server System installiert ist. Diese Antwortdatei muss in der Library des VMM abgelegt werden. Ich habe für mein Beispiel hier folgende Einstellungen festgelegt:
System Lokalisierung: Deutsch (Tastatur, Datum, Uhrzeit, Währung, usw.)
Remote Desktop für Administratoren: Aktiv
Windows Firewall: Ausgeschaltet (ich mache das hier, um die spätere Verifikation der Netzwerkvirtualisierung auf einfache Weise zeigen zu können. Für produktive Systeme sollte dies natürlich nicht durchgeführt werden).
Den vollständigen XML-Code meiner Antwortdatei finden Sie hier:
[GUIRunOnce Commands]: Hier könnten wir Befehle eingeben (z.B. Aufrufe von Kommandozeilen-Programmen oder von Powershell-Skripts), die bei der ersten Anmeldung eines Benutzers ausgeführt werden sollen. Für unsere Demoumgebung verzichten wir darauf.
Damit wäre die Seite Configure Operating System abgeschlossen. Mit einem Klick auf Next gelangen wir auf die Seite Application Configuration. Da wir in unserem Festplattenimage keine Anwendungen installiert haben, können wir diese Seite direkt mit Next überspringen. Gleiches gilt für die Seite SQL Server Configuration.
Auf der letzten Seite Summary sehen wir nur noch den Namen des zu erstellenden VM Templates. Wenn man noch weitere VM Template erzeugen möchte, kann es sinnvoll sein, sich über die Schaltfläche View Script den generierten Powershell Code anzeigen zu lassen, um ihn in einer eigenen Datei zur späteren Wiedererwendung abzuspeichern. Ansonsten können wir jetzt mit einem Klick auf die Schaltfläche Create das Erzeugen des VM Templates anstoßen und über das Job Fenster den Fortschritt verfolgen.
2.3. Nacharbeiten an den VM Templates
Bei der Beschreibung der Einstellungen für den virtuellen Netzwerkadapter habe ich erwähnt, dass wir die Option Static IP (from a static IP pool aktivieren müssten, dies aber nur möglich ist, wenn wir zuvor ein VM Network auswählen. Im Beispiel oben haben wir dafür das Management VM Network ausgewählt. Da wir jedoch unseren Tenants die Möglichkeit bieten wollen, selbst ein eigenes VM Netzwerk zu erstellen und den Netzwerkadapter damit zu verbinden, müssen wir den Netzwerkadapter wieder in den Zustand Not connected zurücksetzen.
Dazu öffnen wir die Properties des VM Templates (Doppelklick), wählen die Seite Hardware Configuration und markieren den Netzwerkadapter. Jetzt können wir die Option im rechten Fensterbereich aktivieren, wobei der Rest der Einstellungen nicht verändert wird.
Mit einem Klick auf OK wird diese Änderung dann im Template gespeichert.
2.4. Kapazitätsdefinitionen für Clouds
Als nächstes müssen wir im SCVMM zumindest eine Cloud Definition anlegen. Mit Clouds werden Ressourcenpools definiert, die später im Admin Portal des Windows Azure Packs Plänen zugeordnet werden können.
Erstellen wir für unsere Demoumgebung eine eigene Cloud. Dazu wechseln wir in der SCVMM-Konsole in den Arbeitsbereich VMs and Services. Dort finden wir den Knoten Clouds. Mit einem Rechtsklick öffnen wir das Kontextmenü und starten über den Befehl Create Cloud den Create Cloud Wizard.
Auf der ersten Seite vergeben wir zunächst einen Namen für die neue Cloud, im Beispiel hier WAP IaaS Cloud.
Mit einem Klick auf Next gelangen wir auf die Seite mit Host Resources. Hier können wir zuvor in der VMM Fabric definierte Hostgruppen auswählen, die z.B. verschiedenen geografischen Standorten zugeordnet sind oder bestimmte technische Eigenschaften wie besonders schnelle (SSD-) Festplatten besitzen.
Für unsere Demoumgebung ist das einfach: Wir haben momentan nur einen Hyper-V Host, der sich in der globalen Gruppe All Hosts befindet. Diese Gruppe markieren wir.
Mit einem Klick auf Next gelangen wir auf die Seite Logical Networks. Hier erhalten wir eine Liste aller zuvor in der Netzwerkfabrik des SCVMM erstellten logischen Netze. Wir markieren hier die Netze, die unsere Tenants verwenden können. In unserer Demoumgebung ist dafür das Netz Tenant virtual Machines vorgesehen.
Die nächsten Seiten für Load Balancers und VIP Templates können wir direkt mit Next überspringen. Dür unsere Demoumgebung haben sie keine Bedeutung.
Auf der Seite Port Classifications sollten wir die Einträge wählen, die wir in der Netzwerkfabric den virtuellen Ports der logischen Switches bzw. den virtuellen Netzwerkadaptern in den VM Templates zugeordnet haben, in unserem Beispiel also Server Default Workload.
Auf der nächsten Seite Storage können wir den Typ des Speichers auswählen, den die Tenants der Cloud nutzen können. Verschiedene Storagetypen können in der SCVMM-Konsole in der Fabric im Bereich Storage definiert werden. In unserer Demoumgebung steht uns nur Local Storage zur Verfügung.
Auf der nächsten Seite Library könnten wir einen Pfad für eine VMM-Library angeben, auf die dann nur Benutzer der Cloud Zugriff haben. Wir verzichten hier darauf und springen gleich mit Next zur Seite Capacity.
Hier können wir Obergrenzen für verschiedene Ressourcen festlegen, die Tenants in dieser Cloud nutzen können. Sinnvoll kann das sein in einem Unternehmen, wo bestimmten Fachabteilungen nur ein begrenztes Kontingent an Ressourcen zugewiesen werden soll. Ein globaler Service Provider – wie wir ihn in unserer Demoumgebung simulieren wollen – wird wahrscheinlich die Voreinstellungen Unlimited übernehmen, weil er ja seinen Tenants möglichst viel an Leistung anbieten will. Natürlich muss er dann aber sicherstellen, dass auch immer unbegrenzt die notwendigen Ressourcen zur Verfügung stehen – ein Problem der Kapazitätsplanung und Überwachung, bei der z.B. der System Center Operations Manager Unterstützung bieten kann.
Mit Next gelangen wir auf die Seite für Capacity Profiles. Bitte wählen Sie keinen der angebotenen Einträge aus, da dies zu Inkompatibilitäten mit dem Windows Azure Pack führen kann! Springen Sie gleich auf die letzte Seite Summary.
Dort können Sie die vorangegangen Eingaben nochmals überprüfen und dann durch Anklicken von Finish das Erzeugen der Cloud anstoßen.
Mit diesem letzten Schritt haben wir nun die Basis im VMM geschaffen, um im Windows Azure Pack ein IaaS Cloud Angebot zu erstellen und Tenants die Nutzung zu ermöglichen.
3. Konfiguration des Admin Portals im Windows Azure Pack
Nach dem Abschluss der Arbeiten im SCVMM können wir uns nun dem Admin Portal im Windows Azure Pack zuwenden und dort entsprechende Angebote für Tenants erstellen.
In meiner Demoumgebung ist das Admin Portal zusammen mit der Service Provider Foundation (SPF) auf der Orchestrator VM WAPSCO01 installiert. Aufrufen können wir es in einem Browser von jedem System in unserem Management Netzwerk über die URL
https://WAPSCO01:30091
Tipp: Auf dem Startbildschirm der VM WAPSCO01 ist bei der Installation bereits ein Symbol zum Starten des Admin Portals erzeugt worden.
Im Browser werden uns zunächst zwei Zertifikatsfehler angezeigt, die wir jedoch bedenkenlos ignorieren können durch einen Klick auf den Link Continue to this website (not recommended). Hintergrund: Bei der Installation wurden selbst signiete SSL-Zertifikate erzeugt, deren Aussteller im aufrufenden Browser nicht bekannt ist. Ich werde auf diese Unschönheit in einem späteren Beitrag zurückkommen.
Nach dem zweiten Zertifikatsfehler erscheint ein Anmeldefenster, in das wir eine Kennung mit Administrationsrechten für das WAP Admin Portal eingeben müssen. Ich verwende hier der Einfachheit halber das Konto des Domänen Admins meiner Demodomäne CONTOSO.COM.
Nach einem Klick auf OK wird uns nochmals ein Zertifikatsfehler angezeigt, den wir genauso ignorieren können, wie die beiden vorangegangenen.
Es erscheint ein Willkommen-Fenster mit einer Kurzanleitung für die Bedienung des Admin Portals, die wir auch durch einen Klick auf das X rechts oben überspringen können. Wir gelangen damit ins Hauptmenü des Portals.
Warum ist das eigentlich plötzlich in deutscher Sprache, obwohl wir doch mit US-Versionen von Windows Server 2012 R2 arbeiten? Ganz einfach: Die Webanwendung orientiert sich an der eingestellten Länderkennung des Betriebssystems, die bei mir immer auf Deutschland eingestellt ist. Wer will, kann das Portal auch in einer anderen Sprache betreiben. Dazu klickt man auf das “Weltkugelsymbol” links vom Anmeldenamen und kann eine andere Sprache auswählen.
3.1. Definieren von Cloud Diensten
Als erstes müssen wir nun die Dienste definieren, die wir unseren Tenants anbieten wollen. Für unser Beispiel hier mit einem einfachen IaaS-Dienst in Form von einzelnen virtuellen Computern wählen wir den Dienst VM-Cloud und klicken auf den Link zum Erstellen einer neuen VM-Cloud.
Wir werden nun nach dem vollständigen Domänennamen des VMM-Servers gefragt, von dem wir die Cloud-Definitionen übernehmen wollen, in unserem Fall also WAPVMM01.contoso.com. Unser VMM arbeitet mit den Standard-Ports und ein Remote Desktop Gateway haben wir (noch) nicht. Die beiden Felder können wir also leer lassen und klicken auf Registrieren.
Nach ein paar Sekunden erhalten wir eine OK-Meldung und unser VMM wird angezeigt.
Wenn wir auf das kleine Dreieck vor dem Servernamen klicken, werden uns die zuvor im SCVMM angelegten Cloud Definitionen eingeblendet, deren Status wir uns durch einen Klick auf den Cloud Namen anzeigen lassen können.
Wir könnten nun noch weitere Cloud Provider registrieren, wie z.B. für ein Website Angebot, für den Service Bus Dienst oder SQL Server, aber auch weitere VM Cloud Provider aus anderen Standorte, die über einen eigenen VMM verwaltet werden. Für unsere Demoumgebung begnügen wir uns aber auf einen einzigen VM Cloud Provider.
3.2. Erstellen eines Plans
Wenn wir alle Cloud Provider registriert haben, können wir daran gehen, Pläne damit zu erstellen, die unsere Tenants dann abonnieren können.
Dazu klicken wir Im linken Menübereich auf Pläne und dann auf Plan erstellen.
Hinweis: Sollte der Menübereich nicht automatisch geöffnet sein, können Sie ihn öffnen durch einen Klick auf die Schaltfläche 
links unten im Browserfenster.
Es erscheint ein Assistent, in dem wir als erstes einen Namen für den Plan eingeben müssen. Dieser Name wird später im Tenant Portal zum Abonnieren angezeigt.
In unserem Beispiel geben wir WAP IaaS Plan ein und klicken auf den Pfeil nach rechts in der unteren rechten Ecke des Formulars.
Wir erhalten nun eine Liste aller zuvor registrierten Cloud Provider, aus der wir die dem Plan hinzuzufügenden Dienste auswählen können. Da wir in unserem Beispiel nur den Provider für Virtual Machine Clouds registriert haben, wird uns auch nur dieser angezeigt, den wir jetzt auswählen. Dann können wir wieder auf den Weiter Pfeil rechts unten klicken.
Im nächsten Schritt könnten wir unserem Plan noch Add Ons hinzufügen. Da wir jedoch keine registriert haben, können wir direkt auf den Haken Fertigstellen klicken.
Nach wenigen Augenblicken wird uns dann eine Liste der verfügbaren Pläne im Browserfenster angezeigt. Unser soeben erzeugter Plan sollte darin enthalten sein. Wir müssen ihn nun aber noch konfigurieren und aktivieren. Dazu klicken wir auf den Namen des Planss
und wir gelangen auf die Konfigurationsseite unseres Plans. Etwas weiter unten auf der Seite finden wir zwei Kategorien: Plandienste und Add Ons.
In den Plandiensten sehen wir die bereits registrierten Cloud Provider. Durch Anklicken eines Cloud Providers gelangen wir zu dessen Konfigurationsdetails.
Im Bereich Grundlegend müssen wir in der Klappbox VMM Verwaltungsserver das gewünschte SCVMM System und in der Klappbox Cloud für virtuellen Computer eine der im selektierten VMM verfügbaren Cloud-Definitionen auswählen.
Im Bereich Nutzungslimit werden die für die gewählte Cloud im VMM hinterlegten maximalen Ressourcenwerte angezeigt, die wir hier auch für den aktuellen Plan ändern könnten. Anmerkung: Änderungen haben nur Auswirkungen für den Plan, aber nicht für die Cloud Definition im VMM. Für unsere Demoumgebung lassen wir die Werte unverändert.
Weiter unten gibt es den Bereich Netzwerke. Hier würden die logischen Netze ohne Netzwerkvirtualisierung aus der Fabric des SCVMM angezeigt, wenn diese im SCVMM in der Cloud Definition selektiert sind. In unserer Demoumgebung haben wir im SCVMM für die WAP IaaS Cloud nur das logische Netzwerk Tenant virtual Machines selektiert, für das die Netzwerkvirtualisierung aktiviert ist. Deshalb ist dieser Bereich leer.
Der nächste Bereich Hardwareprofile ist ebenfalls leer, weil wir im SCVMM nichts dafür definiert haben.
Spannend wird’s im nächsten Bereich Vorlagen. Hier finden wir einen Link Vorlagen hinzufügen.
Wenn wir ihn anklicken, erscheint eine Liste aller VM Templates, die in unserem VMM in der Library abgelegt sind.
Wir haben bislang nur ein Template mit dem Namen A00 – Small Windows Server 2012 R2 en erstellt. Dieses können wir selektieren und dann auf das Fertig Symbol rechts unten klicken. Wir kommen zurück auf die Konfigurationsseite unseres Cloud Dienstes für virtuelle Computer, wo jetzt die ausgewählten Templates aufgelistet sind.
Den nächsten Bereich Galerie ignorieren wir. In ihm könnten wir Muster für fertig vorkonfigurierte virtuelle Maschinen und Services aufnehmen. Dieses Thema ist aber zu umfangreich, um es hier zu berücksichtigen. In einem späteren Blog Beitrag werde ich gerne darauf zurückkommen.
Dann bleibt uns noch der Bereich zusätzliche Einstellungen.
Für unsere Demoumgebung wähle ich die Funktionen Prüfpunkte virtueller Computer erstellen, anzeigen und wiederherstellen sowie Mit Konsole virtueller Computer verbinden. Damit ermöglichen wir unseren späteren Tenants, die entsprechenden Funktionen über das Tenant Portal für die eigenen VMs au
szuführen.
Ganz wichtig ist es nun, auf die Schaltfläche Speichern in der Funktionsleiste am unteren Bildschirmrand zu klicken, damit die durchgeführten Änderungen in unserem Plandiesnt VM Cloud Provider auch gespeichet werden.
![image[4]](http://www.hyper-v-server.de/wp-content/uploads/2014/07/image49.png "image[4]")
Dann können wir durch einen Klick auf den Zurück Pfeil die Konfigurationsseite unseres VM Cloud Providers verlassen und kommen wieder zurück auf die Konfigurationsseite für unseren Plan. Dort wird uns jetzt der Plandienst als aktiv und konfiguriert angezeigt.
3.3. Plan veröffentlichen
Noch aber ist es nicht soweit, dass Tenants diesen Plan abonnieren können. Wie man im vorstehenden Screenshot sieht, ist der Plan noch als Privat gekennzeichnet. Erst wenn ein Plan veröffentlicht wird, ist er im Tenant Portal sichtbar und kann abonniert werden.
Zum Veröffentlichen eines Plans gibt es in der unteren Funktionsleiste die Schaltfläche Zugriff ändern. Wenn wir die anklicken, erscheint ein kleines Menü mit den Einträgen Öffentlich und Außer Betrieb setzen.
Wenn wir auf Öffentlich klicken, wird eine Sicherheitsabfrage eingeblendet, die wir mit Ja beantworten müssen.
Es kann einige Minuten dauern, bis der Vorgang abgeschlossen ist, da dabei von der SPF einige umfangreiche Datenbankoperationen ausgeführt weden müssen.
Jetzt wären wir also so weit, um “Kunden” auf unsere Demoumgebung loszulassen. Vielleicht fragen Sie sich an dieser Stelle, wozu in der Menüleiste des Admin Portals ganz unten das Element Benutzerkonten dient. Darüber könnten wir jetzt tatsächlich Tenants anlegen. Aber wir wollen ja ein echtes Self Service Angebot aufbauen, bei dem sich Tenants selbst registrieren können. Wie wir noch sehen werden, erscheinen dann neu registrierte Tenants hier im Bereich Benutzerkonten.
Wir können hier aber einige Merkmale für die künftigen Konten festlegen, z.B.
- Kennworteigenschaften (Länge und Stärke)
- Verifikation der für die Registrierung im Tenant Portal verwendeten E-Mail Adresse (dann wird eine Mail an die angegebene Adresse gesendet mit einem Link, der angeklickt werden muss, um die Freischaltung durchzuführen)
- Regeln für das Zurücksetzen eines vergessenen Kennworts (neues Kennwort per Mail senden oder Mail mit Link auf eine Webseite für Neueingabe)
Für unsere Demoumgebung verzichten wir auf diese Funktionen, insbesondere weil wir für die auf E-Mails basierenden Funktionen auch noch einen SMTP Server definieren müssten und dann für unsere Tests mit Tenants nur gültige E-Mail Adressen verwenden könnten.
4. Das Tenant Self Service Portal
Das Tenant Self Service Portal stellt den Zugang für unsere Kunden zu unseren Cloud Angeboten dar. In meiner Demoumgebung mit dem Windows Azure Pack habe ich dafür eine eigene virtuelle Maschine mit dem Namen WAPTenant01 erstellt. Das Tenant Portal ist (momentan) nur erreichbar über einem Browser von einem beliebigen Client in meinem Management Netz. Auf die Herausforderung, das Portal auch übers Internet – also von extern – zu erreichen, will ich hier nicht näher eingehen. Dies ist ein Thema für einen zukünftigen Blog Beitrag.
Aufrufen können wir das Tenant Portal über die URL
https://WAPTENANT01:30081
Tipp: Auf dem Startbildschirm der VM WAPTenant01 ist bei der Installation bereits ein Symbol zum Starten des Tenant Portals erzeugt worden.
Wie schon beim System Admin Portal erhalten wir auch hier wieder 2 Zertifikatsfehler, weil auch das Tenant Portal mit selbstsignierten Zertifikaten installiert wurde. Wir können sie wieder bedenkenlos ignorieren durch einen Klick auf den Link Continue to this website (not recommended).
Damit gelangen wir zur eigentlichen Startseite des Tenant Portals. Aufgrund meiner für Deutschland lokalisierten Systemumgebungen wird die Seite in Deutsch angezeigt. Rechts oben gibt es einen Menüpunkt mit der gewählten Sprache. Durch einen Klick darauf wird ein Menü eingeblendet, aus dem man eine andere Sprache wählen kann.
4.1. Anmeldung bzw. Registrierung beim Tenant Portal
Tenants werden auf der Startseite aufgefordert, entweder ihre Zugangsdaten einzugeben oder sich neu zu registrieren. Da unsere Cloud Umgebung noch leer ist, werden wir also als erstes einen Tenant registrieren, indem wir auf den entsprechenden Menüpunkt am oberen Bildschirmrand klicken.
Es erscheint das Registrierungsfenster, in das wir eine E-Mail Adresse und ein Kennwort eingeben müssen.
Wichtig: Das Tenant Portal überprüft an dieser Stelle zwar, ob die eingegebene E-Mail Adresse bereits registriert ist. Es erfolgt jedoch standardmäßig keinerlei weitere Überprüfung, ob diese Adresse gültig ist. Auch werden keinerlei Informationen abgefragt, wie z.B. Name des Tenants oder gewünschte Bezahlmethoden.
Für unsere Demoumgebung ist diese Art der Registrierung sicherlich ausreichend. Bei einer kommerziellen produktiven Umgebung wird man aber nicht umhin kommen, hier eine andere Vorgehensweise zu realisieren. Teilweise kann man dies im System Admin Portal festlegen – siehe oben. Weitere Beispiele dafür (z.B. AD FS oder Authentisierungssysteme anderer Hersteller) finden sich in der MSDN Library.
In unserem Beispiel hier registriere ich einen Tenant mit der E-Mail Adresse admin@redcorp.org, vergebe ein passendes Kennwort und klicke auf Registrieren. Nach kurzer Zeit erscheint nochmals ein Zertifikatsfehler, den wir wieder ignorieren und wir gelangen dann auf die Willkommenseite mit einer Kurzanleitung zur Bedienung des Portals. Anschließend werden wir direkt auf die Seite zum Hinzufügen eines Abonnements geleitet
und voilà: Es wird uns unser Plan WAP IaaS Plan angeboten, den wir vorhin im Admin Portal angelegt haben.
An dieser Stelle sollten wir nun kurz einen Blick in das Admin Portal werfen. Ich habe oben erwähnt, dass der Bereich Benutzerkonten leer war, als wir uns dem Tenant Portal zuwandten. Durch die Tenant Registrierung wird jetzt 1 Benutzerkonto angezeigt.
Das Tenant Portal hat also über die SPF API ein neues Benutzerkonto angelegt.
4.2. Hinzufügen eines Abonnements für einen Plan
Zurück im Tenant Portal können wir unseren WAP IaaS Plan als Abonnenment hinzufügen. indem wir auf die OK Schaltfläche rechts unten klicken.
Das Tenant Portal zeigt uns jetzt links die im hinzugefügten Plan enthaltenen Elemente an, die wir bestellen können.
4.3. Erstellen eines Tenant-spezifischen virtuellen Netzwerks
Eines der Ziele unseres IaaS Demos ist es, zu zeigen, wie Tenants sich eigene virtuelle Netze erstellen können, die per Netzwerkvirtualisierung vollständig voneinander isoliert sind, auch wenn sie identische IP-Adressen besitzen.
Im Tenant Portal wählen wir dazu die Elementgruppe Netzwerke und klicken auf den Link Virtuelles Netzwerk erstellen.
im angezeigten Formular wählen wir Benutzerdefiniert erstellen.
Es öffnet sich ein Assistent, der aus 3 Schritten besteht.
Im 1. Schritt müssen wir einen Namen für das neue virtuelle Netzwerk vergeben und den Typ festlegen – im Beispiel hier Red VM Network und IPV4.
Im 2. Schritt können wir die Adresse eines Tenant-eigenen DNS-Servers eintragen und festlegen, wie VMs im neuen virtuellen Netz mit der Außenwelt kommunizieren können (Internetzugriff per NAT und / oder Kommunikation per VPN mit Tenant Systemen an einem anderen Standort). Hierfür benötigen wir in unserer Cloud allerdings zusätzliche Gateway VMs, die wir noch nicht haben. Deshalb lassen wir diese Seite leer.
Im 3. Schritt müssen wir den IP-Adressraum festlegen, den unser neues virtuelles Netzwerk abdecken soll. Für unser Demo übernehmen wir den Vorschlag 10.0.0.0/24.
Das Erstellen des neuen virtuellen Netzes dauert einen Moment. Vom Windows Azure Pack müssen einige Aktionen im SCVMM ausgelöst werden. Den Vorgang können wir in der Konsole des SCVMM mitverfolgen:
-
Falls noch nicht geschehen, wird im VMM für den Tenant eine User Role angelegt. Um sicherzustellen, dass der Name dieser User Role innerhalb des VMM eindeutig ist, wird der Benutzername des Tenants um eine GUID erweitert und an den VMM übergeben.
-
Es wird ein neues VM Subnet bei den VM Networks erzeugt, dessen Name sich aus dem vom Tenant vorgegebenen Netzwerknamen ergänzt um eine GUID zusammensetzt.
-
Für das neue VM Subnet wird ein IP Pool definiert. Der Name des IP Pools wird erzeugt aus dem vom Tenant vorgegebenen Netzwerknamen ergänzt um eine weitere GUID. Die Werte dieses IP Pools werden mit den in den Schritten 2 und 3 vom Tenant vorgegebenen Werten gefüllt.
Nach Abschluss der Erstellung des neuen VM Netzwerks wird es uns im Tenant Portal angezeigt und wir könnten uns die Details durch einen Klick darauf anzeigen lassen.
4.4. Erstellen von virtuellen Maschinen
Jetzt haben wir als Tenant für uns die Voraussetzungen geschaffen, eine virtuelle Maschine selbst zu erzeugen. Dazu wählen wir im Tenant Portal die Elementgruppe Virtuelle Computer und klicken auf den Link Rolle für virtuellen Computer erstellen.
Es erscheint ein Formular mit verschiedenen Optionen. In unserer Demoumgebung können wir momentan nur sinnvoll die Option Eigenständigen virtuellen Computer – Aus Katalog wählen.
Unser Katalog enthält momentan nur einen Eintrag – das VM Template A00 – Small Windows Server 2012 R2. Wir wählen diese Vorlage aus und klicken auf Weiter rechts unten.
Im nächsten Schritt können wir den Namen der neuen VM eingeben und ein eigenes Kennwort für das lokale Administratorkonto der VM festlegen. Für unser Demo wähle ich den Namen RedVM01. Wichtig: Der VM Name hat nichts mit dem späteren Computernamen der VM zu tun. Er dient lediglich zur Erkennung der VM hier im Portal und später im SCVMM. Auf die Anforderung, einen eigenen Computernamen zu vergeben, werde ich später noch zurückkommen.
Wir klicken auf die Weiter Schaltfläche und gelangen auf die Seite zum Angeben von Hardwareinformationen. Hier sehen wir eine Klappbox mit dem Namen Netzwerk. Aus der Liste dieser Klappbox können wir unser zuvor angelegtes Netzwerk Red VM Network auswählen. Hierdurch wird die VM beim Erstellen mit diesem Netzwerk verbunden. Mit einem Klick auf die Schaltfläche Fertigstellen rechts unten können wir nun das Erstellen der VM veranlassen.
Das Erstellen der neuen VM dauert einige Zeit. Das Windows Azure Pack initiiert einige Jobs im SCVMM, deren Ablauf wir in der Jobliste der SCVMM Konsole mitverfolgen können.
Auch im Informationbereich am unteren Rand des Tenant Portals erhalten wir ein Feedback über den Fortschritt der VM Generierung. Wir müssen jedoch nicht bis zum Abschluss warten, sondern können sofort weiterarbeiten.
Für den späteren Test der Netzwerkvirtualisierung benötige ich noch eine weitere VM für den Tenant admin@redcorp.org, deren Erzeugung wir gleich anstoßen können. Diese zweite VM soll den Namen RedVM02 erhalten und wird ebenfalls mit dem virtuellen Netzwerk Red VM Network verbunden.
4.5. Unschönheiten
Konsolen- bzw. RDP-Verbindungen zu den Tenant VMs
Nach dem Abschluss der VM Generierungen wollen wir natürlich auch mit den VMs arbeiten, d.h. uns mit ihnen verbinden. Der intuitve Versuch, eine VM im Tenant Portal zu selektieren und dann in der Funktionsleiste auf das Symbol Verbinden zu klocken, führt leider zu keinem Erfolg. Das liegt nicht am Windows Azure Pack, sondern an einigen in unserer Demoumgebung noch fehlenden Komponenten wie z.B. einem RDP-Gateway mit geeigneten SSL-Zertifikaten. Ich werde in einem späteren Artikel auf dieses Thema zurückkommen.
Momentan können wir uns behelfen, indem wir entweder über den Hyper-V Manager unseres Hosts oder auch über die SCVMM Konsole Verbindungen zu unseren Tenant VMs herstellen.
Computernamen in den Tenant VMs
Beim Erzeugen von VMs über das Tenant Portal legen wir zwar einen Namen für die VMs fest. Dieser dient aber nur im Windows Azure Pack und im SCVMM bzw. Hyper-V Host zur Identifikation. Auf den Computernamen in der VM hat er keinen Einfluss. Unsere Tenant VMs erhalten während der Installation des Betriebssystems wie beim Windows Setup üblich einen zufällig erzeugten Namen, den wir anschließend manuell über eine Konsolen- oder RDP-Sitzung anpassen können.
Eine Automatisierung per Service Management Automation (SMA) ist unter gewissen Rahmenbedingungen vorstellbar, soll jetzt hier aber nicht weiter betrachtet werden.
URLs und Zertifikatsfehler beim Starten der Portale
Das Aufrufen der Portale über die ungewöhnichen URLs mit Portnummern und die auftretenden Medlungen mit Zertifikatsfehlern können insbesondere für Tenants zu Irritationen führen. Schöner wäre es, zumindest das Tenant Portal über einen “normalen” HTTPS-Aufruf mit öffentlichen Zertifikaten von extern erreichbar zu machen.
Durch geeignete Umkonfiguration der Portal-Anwendungen und das Einbringen von offiziellen SSL-Zertifikaten kann diese Anforderung erfüllt werden. Ich werde in einem späteren Artikel auf dieses Thema zurückkommen.
5. Verifikation der Isolation von Tenant Netzen per Netzwerkvirtualisierung
Eine der wichtigsten Neuerungen beim Windows Server 2012 R2 im Zusammenspiel mit dem System Center Virtual Machine Manager (SCVMM) 2012 R2 ist die Netzwerkvirtualisierung. Hierdurch können Tenants eigene Netzwerke in einer Cloud Umgebung betreiben, die vollkommen voneinander isoliert sind, selbst wenn sie identische oder überlappende IP-Adressbereiche besitzen.
Nachdem wir in unserer Demoumgebung beim SCVMM und in den Windows Azure Pack Portalen die Voraussetzungen geschaffen haben, können wir ein solches Szenario nachstellen.
5.1. Vorbereitungen
Wir benötigen 2 Tenants: Redcorp.org und Bluecorp.org. Jeder Tenant definiert über das Tenant Portal ein eigenes virtuelles Netzwerk Red VM Network und Blue VM Network mit jeweils 2 VMs (RedVM01 und RedVM02 bzw. BlueVM01 und BlueVM02). Jedes der beiden Tenant Netze ist für den IP-Adressbereich 10.0.0.0/24 konfiguriert.
Redcorp.org haben wir entsprechend den vorstehenden Beschreibungen bereits angelegt. In analoger Weise registrieren wir über das Tenant Portal Bluecorp.org und erzeugen die beiden VMs BlueVM01 und BlueVM02.
Damit ergibt sich das folgende Szenario:
Über den Hyper-V Manager unseres Hosts verbinde ich mich zu jeder VM mit einer Konsolensitzung, in der ich eine Powershell Kommandozeile starte. Jetzt können wir experimentieren insbesondere über IP-Adressen. Beispiel: Von RedVM01 senden wir eine Nachricht an den Server 10.0.0.3
msg * /server:10.0.0.3 „Hello from RedVM01“
Und natürlich erscheint die Nachricht auf RedVM02, während auf BlueVM01 und BlueVM02 nichts passiert.
Da im VM Template, das für die Erzeugung der VMs verwendet wird, über die Answer File die Windows Firewall abgeschaltet ist (nur für das Demo hier!), können wir auch andere beliebige Netzwerkoperationen (z.B. Dateien kopieren) zwischen den VMs eines Tenants ausführen, ohne dass davon VMs anderer Tenants etwas mitbekommen, obwohl sie aus Sicht der Tenants die gleichen IP-Adressen besitzen.
6. Fazit und nächste Schritte
Ich denke, mit diesem kleinen Demo kann man eindrucksvoll die Netzwerkvirtualisierung per GRE-Protokoll (NVGRE) präsentieren, wie sie “Out of the Box” mit dem Windows Server 2012 R2 im Zusammenspiel mit System Center 2012 R2 und dem Windows Azure Pack im eigenen Rechenzentrum realisiert werden kann.
Aber wie ich an verschiedenen Stellen schon darauf hingewiesen habe, ist die Cloud Umgebung noch lange nicht perfekt. Da sollten als erstes die oben beschriebenen “Unschönheiten” beseitigt werden. In weiteren Schritten sollten wir uns dann auch ansehen, wie man das IaaS-Angebot erweitern kann zum Beispiel durch das Einbringen von VM Roles.
Ich werde auf diese Themen in zukünftigen Beiträgen zurückkommen.
Jetzt aber erst mal viel Erfolg beim Experimentieren mit unserer Demo Cloud.
