Windows Azure Pack: Aufbau einer IaaS-Demoumgebung mit dem Powershell Deployment Toolkit (PDT)

Das “Windows Azure Pack für Windows Server” ist eine Sammlung von Windows Azure-Technologien, die Microsoft-Kunden ohne zusätzliche Kosten im eigenen Rechenzentrum installieren können. Damit können Enterprise Anwender oder Service Provider umfangreiche Multi-Mandantenfähige Cloud Dienste anbieten, die konsistent sind mit denen der öffentlichen Windows Azure Cloud in den weltweit verteilten Microsoft Rechenzentren.

In verschiedenen Kundenkontakten wurde ich immer wieder gefragt, wie sich insbesondere der mit dem Azure Pack mögliche IaaS (Infrastructure as a Service) Dienst – also das Bereitstellen und Betreiben von kundenspezifischen virtuellem Maschinen in per Netzwerkvirtualisierung voneinander isolierten Netzwerkumgebungen – in der Praxis “anfühlt”. Um hier nicht nur mit bunten Powerpoint Folien arbeiten zu müssen, sondern auch etwas zum “Anfassen” zu haben, beschloss ich, mir eine kleine “mobile” Demoumgebung auf einem Laptop aufzubauen,

Für das Windows Azure Pack benötigt man eine Microsoft System Center 2012 R2 Umgebung, die auf Basis von Windows Server 2012 R2 installiert ist. Die einzelnen Komponenten können als physische oder virtuelle Maschinen realisiert sein. Details dazu befinden sich in der Microsoft TechNet Library. Für meine Demoumgebung kommen natürlich nur virtuelle Maschinen in Frage.

In der Microsoft TechNet Library ist die Vorgehensweise für eine “manuelle” Installation beschrieben. Eine interessante Alternative dazu ergibt sich mit dem von Rob Willis (MSFT) erstellten Powershell Deployment Toolkit (PDT). Damit kann eine komplette Microsoft System Center 2012 R2 Umgebung einschließlich des Windows Azure Pack vollautomatisch innerhalb weniger Stunden erzeugt werden. Ein Beispiel dazu zeigt Carsten Rachfahl in seinem Videocast.

Aber unabhängig davon, wie man die Installation durchführt, muss eine Reihe von Konfigurationsarbeiten durchgeführt werden, die ich in diesem und weiteren Beiträgen etwas genauer beschreiben will. Ich werde mich dabei beschränken auf die Vorgehensweise für eine Installation mit dem PDT, wie ich sie für meine Demoumgebung gewählt habe.

Im Wesentlichen sind folgende Schritte notwendig:

• Planung / Beschreibung der Demoumgebung
• Vorbereiten der PDT-Steuerdateien für die Demoumgebung und Installation
• Download der benötigten Komponenten
• Start der PDT-Installation
• Nach der PDT-Installation

• Konfigurieren der “Fabric” im System Center Virtual Machine Manager (SCVMM)
• Konfigurieren der Komponenten der Service Provider Foundation als Bindeglied zwischen System Center und den Azure Pack Komponenten
• Konfigurieren und Bereitstellen von Diensten im Windows Azure Pack für Benutzer / Kunden

Planung / Beschreibung der Demoumgebung

Bevor man mit dem Aufbau einer Cloud Umgebung mit dem Windows Azure Pack beginnen kann, sind normalerweise umfangreiche und sorgfältige Planungen für die Infrastruktur notwendig: Welche Server Hardware, welche Speicher- / Storage-Architektur und welche Netzwerk-Technologien sollen zum Einsatz kommen? Bestimmt werden solche Entscheidungen zum Beispiel durch das angepeilte Geschäftsmodell sowie die dazugehörigen Service Level Agreements (SLAs).

Diese Entscheidungen sind für meine Demoumgebung schnell erledigt. Es soll nur ein Laptop System als Host zum Einsatz kommen und als Storage wird ein lokales SSD-Laufwerk verwendet. Um aus der Demoumgebung auf externe Ressourcen oder ins Internet zugreifen zu können, wird die im System fest eingebaute 1GBit Ethernet-Karte herangezogen.

Für meine Demoumgebung habe ich mir eine “Schmalspur”-Installation des Windows Azure Packs mit Hilfe des PDT erzeugt. Sie enthält nur die für das Azure Pack unbedingt notwendigen System Center Komponenten als virtuelle Maschinen (VMs):

Alle VMs laufen gemeinsam auf einem einzigen Hyper-V Host – dem erwähnten Laptop. Er ist mit einem i7 Prozessor und 32 GB RAM ausgestattet. Damit gewinnt man zwar mit dem Azure Pack keinen Preis in Bezug auf Performance, aber für Test-, Entwicklungs- und Demozwecke reicht es allemal.

Die VMs können untereinander und mit dem Hyper-V Host über ein virtuelles Netz mit dem Namen ”Contoso Internal Switch” kommunizieren, das im “virtual Switch Manager” des Hyper-V Hosts als “Internal” für einen virtuellen Ethernet-Switch definiert ist.

Die VMs erhalten während der Erzeugung mit dem PDT statische IP-Adressen. Auch dem Hyper-V Host muss eine statische IP-Adresse aus dem gleichen IP-Subnetz zugewiesen werden.

Der Hyper-V Host hat den Namen HV2012R2. Es handelt sich um einen Standalone bzw. Workgroup Server, der kein Mitglied einer Active Directory Domäne, also auch nicht der oben erwähnten Domäne CONTOSO.COM ist. Dies ist wichtig bei der späteren Integration in den System Center Virtual Machine Manager (SCVMM). Für mich hat es den Vorteil, dass ich das System auch für andere Testszenarien verwenden kann, ohne dass es fest mit einem bestimmten Active Directory “verheiratet” ist.

Als Betriebssystem kommt sowohl auf dem Hyper-V Host als auch bei allen VMs Windows Server 2012 R2 in der US-englischen Version zum Einsatz.

zurück zur Übersicht

Vorbereiten der PDT-Steuerdateien für die Demoumgebung und Installation

Nach dem Herunterladen des PDT aus der TechNet Gallery und einer ersten Sichtung der darin enthaltenen Dateien stellte ich fest, dass ich für meine Demoumgebung einige Anpassungen vornehmen muss:

• Mit der Original Steuerdatei Variable.xml kann zwar eine vollständige System Center 2012 R2 Umgebung erzeugt werden. Sie enthält dann allerdings einige für meine “Schmalspur”-Demoumgebung nicht notwendige Komponenten wie den Data Protection Manager (DPM), den Configuration Manager (CM) und den Service Manager (SM). Andererseits fehlten die Komponenten der Service Provider Foundation (SPF) und des Windows Azure Pack (WAP), dem eigentlichen Objekt meiner Demoumgebung. Das ist aber kein Problem. Durch eine entsprechende Bearbeitung der Variable.xml lässt sich das beheben.
• Die erzeugten VMs bieten zunächst nur eine US-amerikanische Tastaturbelegung. Schöner wäre es natürlich, wenn gleich beim Erzeugen der VMs eine deutsche Tastaturbelegung eingestellt würde. Meinen ersten Ansatz, dies über entsprechende Erweiterungen des PDT-Skripts VMcreator.ps1 direkt durchzuführen, habe ich mittlerweile verworfen, da diese Anpassungen sehr komplex sind und für jedes neue PDT-Release nachgezogen weden müssten. Ich habe mir stattdessen ein kleines Powershell-Skript geschrieben, das man nach der Installation der VMs einmalig in jeder VM aufrufen muss. Damit bin ich dann unabhängig vom jeweiligen PDT-Release. Details dazu siehe am Ende unter Nach der PDT-Installation.

Entfernen nicht benötigter System Center Komponenten sowie Integration der Service Provider Foundation (SPF) und Windows Azure Pack (WAP) Komponenten

Um beim Erzeugen meiner Demoumgebung mit dem PDT unnötige Komponenten wie den DPM, CM und SM wegzulassen, dafür aber gleich die Komponenten der Service Provider Foundation (SPF) und des Windows Azure Packs mit zu installieren, muss die Steuerdatei Variable.xml entsprechend geändert werden:

Im Abschnitt <Components> … </Components> können die Untertags <Component> für DPM, CM und SM entfernet werden. Analog müssen auch die entsprechenden <Role> Einträge im Abschnitt <Roles> gelöscht werden.

Die neu einzufügenden Einträge für SPF und WAP muss man sich selbst zusammenbasteln. Das ist zwar etwas mühsam, aber es geht mit Hilfe der Datei Workflow.xml, in der alle unterstützten Komponenten mit ihren notwendigen Definitionen hinterlegt sind. In der nachstehenden ZIP-Datei habe ich die Variable.xml hinterlegt, wie ich sie für meine Demoumgebung verwende.

Anmerkung: In den aktuellen PDT-Releases (z.B. 2.64.2608) sind die Einträge für SPF und WAP mittlerweile in der variable.xml enthalten, so dass nur die nicht benötigten Einträge entfernt werden müssen. Ein Schnelltest mit dem aktuellen PDT-Release 2.64.2608 zeigte, dass die von mir vorstehend angegebene Datei variable.xml auch mit den neuen PDT-Versionen verwendet werden kann.

Weitere Einträge in Variable.xml

Neben den vorstehend beschriebenen Definitionen zum Erzeugen der Demoumgebung enthält die Datei Variable.xml noch einige weitere wichtige Einträge:

• Definitionen für Netzwerk- und Domäne
• Definitionen für Benutzernamen einschl. Service Accounts und zugehöriger Kennwörter
• Definition der Computernamen für die vom VMCreator.ps1 Skript zu erzeugenden VMs
• …

All dies kann vor dem Start von VMCreator.ps1 auf die eigene Umgebung angepasst werden.

zurück zur Übersicht

Download der benötigten Komponenten

Das VMCreator.ps1 Skript erwartet die zu installierenden Komponenten in einer speziellen Ordnerstruktur auf einer lokalen Festplatte. Der Pfadname der Ordnerstruktur muss in der Variable.xml angegeben werden. Das zum PDT gehörige Skript Downloader.ps1 ist dafür zuständig, alle benötigten Komponenten aus dem Internet herunterzuladen und die Ordnerstruktur zu erzeugen. Das Downloader.ps1 Skript benötigt dazu ein Entpackungsprogramm wie WinRAR oder 7-zip, das zuvor manuell installiert werden muss. Das Zielverzeichnis, in das die heruntergeladenen und entpackten Komponenten abgelegt werden sollen, wird in der Datei variable.xml im Eintrag   <Variable Name=“Download“ Value=“…“ /> (Zeile 8) festgelegt

Leider hat Microsoft seit einiger Zeit das Verfahren zum Download der Evaluierungsversionen der Windows Server Betriebssysteme sowie der System Center Komponenten geändert, so dass diese nicht mehr mit dem Downloader.ps1 Skript heruntergeladen werden können. Dies und das anschließende Entpacken muss nun manuell erfolgen. Wichtig dabei ist, das Entpacken in die vom PDT erwartete Ordnerstruktur vorzunehmen:

$Download\SystemCenter2012R2\AppController
$Download\SystemCenter2012R2\ConfigurationManager
$Download\SystemCenter2012R2\DataProtectionManager
$Download\SystemCenter2012R2\OperationsManager.en
$Download\SystemCenter2012R2\Orchestrator
$Download\SystemCenter2012R2\ServiceManager
$Download\SystemCenter2012R2\VirtualMachineManager

$Download\SystemCenter2012SP1\AppController
$Download\SystemCenter2012SP1\ConfigurationManager
$Download\SystemCenter2012SP1\DataProtectionManager
$Download\SystemCenter2012SP1\OperationsManager.en
$Download\SystemCenter2012SP1\Orchestrator
$Download\SystemCenter2012SP1\ServiceManager
$Download\SystemCenter2012SP1\VirtualMachineManager

$Download\WindowsServer2012
$Download\WindowsServer2012R2

wobei $Download den Pfad angibt, der in der Datei variables.xml als Download-Zielverzeichnis definiert ist.

Wichtig: Es genügt nicht, nur die heruntergeladenen Komponenten (ISO, EXE, ZIP, …) in diese Verzeichnisstruktur zu kopieren. Vielmehr muss der entpackte Inhalt der Downloads kopiert werden.

Nach diesen manuellen Vorarbeiten kann nun das Skript Downloader.ps1 ausgeführt werden, das die restlichen Komponenten wie SQL-Server und andere zwingend vorausgesetzte Softwarepakete herunterlädt und entpackt.

zurück zur Übersicht

Start der PDT Installation

Sind alle für die Installation benötigten Komponenten mit dem Downloader.ps1 Skript bzw. manuell aus dem Internet heruntergeladen und die Datei Variable.xml an die eigene (Test-) Umgebung angepasst, kann die Installation durch Aufruf desPowershell-Skripts VMCreator.ps1 gestartet werden. Wichtig: Alle PDT-Steuerdateien müssen im gleichen Verzeichnis liegen.

VMcreator.ps1 erzeugt die in der Steuerdatei variable.xml definierten VMs (einschließlich einem Domänen Controller sofern angegeben), kopiert das Download-Verzeichnis auf den Domaänen Controller in das im Eintrag <Variable Name=“SourcePath“ Value=“$SystemDrive\Temp“ /> (Zeile 7 in variable.xml) und startet dann auf dem Domänen Controller das Skript Installer.ps1, das sich dann um die eigentliche Verteilung und Installation der Komponenten auf den erzeugten VMs kümmert.

Warnung: Ändern Sie nicht den Eintrag SourcePath in variable.xml! Dies kann zu nicht vorhersehbaren Fehlern führen!

Die Installation kann je nach Geschwindigkeit der Hyper-V Umgebung einige Zeit (bis zu mehreren Stunden) dauern, sie läuft jedoch automatisch und ohne weitere manuelle Eingriffe ab. Im Fehlerfall kann das Skript Installer.ps1 jederzeit erneut gestartet werden, nachdem die Fehlerursache beseitigt wurde.

zurück zur Übersicht

Nach der PDT Installation

Deutsche Tastaturbelegung in den VMs

Ist das Skript Installer.ps1 erfolgreich abgeschlossen (Fortgang kann über die Hyper-V Konsole des Domänen Controllers beobachtet werden), steht die gewünschte Umgebung betriebsbereit zur Verfügung und wir könnten eigentlich loslegen mit der Konfiguration unserer Cloud-Umgebung im SCVMM. Doch halt: Da wir mit den englischen Versionen der Server-Betriebssysteme arbeiten, haben wir in allen VMs auch eine amerikanische Tastaturbelegung. Um diese auf die bei uns gebräuchliche deutsche Einstellung zu “verbiegen”, sollten wir jetzt noch die folgenden Powershell-Befehle in jeder VM ausführen.

set-culture de-de
set-winsystemlocale de-de
Set-WinHomeLocation 0x5E
Set-WinUserLanguageList de-de –force

zurück zur Übersicht

Nächste Schritte

Ist die Installation der Testumgebung mit dem PDT erfolgreich beendet worden, müssen als nächstes die erzeugten System Center Komponenten konfiguriert werden. Darauf werde ich in den folgenden Blog-Beiträgen näher eingehen:

• Konfigurieren der “Fabric” im System Center Virtual Machine Manager (SCVMM)
• Konfigurieren und Bereitstellen eines einfachen IaaS Cloud- Dienstes

zurück zur Übersicht

Weitere Informationen zum PDT

Für weitere detaillierte Informationen sei auf die Blog Beiträge (in englischer Sprache) des PDT Autors Rob Williss verwiesen.

PowerShell Deployment Toolkit Blog