0

Mit MSLab Azure Stack HCI 2.0 evaluieren

Seit Dezember 2020 bietet Microsoft eine neue Systemumgebung Version 2.0 von Azure Stack HCI (Hyper Converged Infrastructure) als Azure Dienst an, der für jedermann über das Microsoft Azure Portal buch- und benutzbar ist.

Seit dem Sommer 2021 bietet Microsoft nun auch die Möglichkeit, an einem kostenlosen Preview Programm für Azure Stack HCI teilzunehmen, um (ähnlich wie beim Windows Insider Programm) neue Funktionen und Versionen noch vor deren offiziellen Verfügbarkeit testen zu können.

Also eigentlich höchste Zeit, sich mit diesem neuen Azure Angebot etwas genauer auseinander zu setzen. Dazu besteht die Möglichkeit, die Azure Stack HCI-Software herunterzuladen und mit einer kostenlosen 60-tägigen Testversion zu starten.

Nun will ich hier keine große Marketing-Lobhudelei von mir geben, wie toll diese neue Plattform ist. Ob sie für einen Anwendungsfall geeignet ist, muss letztlich jeder selbst entscheiden. Ein Evaluierungsprojekt kann dabei sehr hilfreich sein.

Microsoft hat im Zuge der Bereitstellung des Dienstes auf Github einen Azure Stack HCI 20H2 – Evaluation Guide veröffentlicht. Darin wird Klick für Klick der Aufbau einer HCI-Testumgebung einschließlich Active Directory und Management Systemen auf Basis einer Nested Hyper-V Umgebung beschrieben. Das Ganze funktioniert zwar meistens, ist allerdings etwas mühsam.

Wesentlich einfacher und eleganter lässt sich das mit dem ebenfalls auf GitHub veröffentlichten MSLab Projekt von Jaromir Kaspar, einem Microsoft Premier Field Engineer realisieren. MSLab ist kein speziell für Azure Stack HCI designtes Werkzeug, sondern erlaubt mit Hilfe von einigen wenigen PowerShell Skripten und einer Parameterdatei beliebige Windows Server Basis-Infrastrukturen als virtuelle Hyper-V Umgebungen zu erstellen. 

Mit solchen Windows Server Basis-Infrastrukturen können dann spezielle Szenarien sowohl für Test- und Evaluierungszwecke als auch für produktive Lösungen realisiert werden. Im MSLab Download sind bereits weit über 65 Szenarien enthalten, wobei einige davon auch schon Lösungen mit Azure Stack HCI bieten.

Ich gehe jetzt mal davon aus, dass nicht jeder Leser hier mit dem MSLab Projekt vertraut ist, auch wenn Jaromir es sowohl bei der CDC-Konferenz 2019 als auch hier in einem Webinar Ende Juni 2020 bereits mal vorgestellt hat. 

Deshalb will ich im Folgenden versuchen, anhand eines Azure Stack HCI Einstiegsszenarios sowohl einen Überblick über das Arbeiten mit MSLab zu geben als auch den Weg zu einer fertigen Azure Stack HCI Clusterumgebung mit Storage Spaces Direct (S2D) aufzuzeigen. Ich werde dazu auf das MSLab-Szenario AzSHCI Deployment zurückgreifen. Dieses Szenario präsentierte Jaromir auch in einer Session bei den Azure Stack HCI Days 2021 mit den Neuerungen der nächsten Azure Stack HCI Version 21H2.

Anmerkung für „alte Hasen“: Das MSLab Projekt hieß früher WSLab und wurde erst kurz vor der Ignite 2021 Konferenz umbenannt. Immerhin funktionieren alte Links, die noch WSLab enthalten, weiterhin. Sie führen jetzt auf MSLab.

Architektur unserer Azure Stack HCI Eval-Umgebung

Für eine Azure Stack HCI benötigen wir neben den eigentlichen Azure Stack HCI Serversystemen ein Active Directory sowie Management Systeme mit Windows 10 und / oder Windows Server 2019. Microsoft empfiehlt, auf den Management Systemen jeweils das Windows Admin Center zu installieren. All diese Systeme sind lokal installiert und laufen bei unserer Eval-Umgebung als virtuelle Maschinen (VMs) auf einem lokalen Hyper-V Host. Sie sind miteinander über ein Hyper-V internes Domain Netzwerk verbunden. Der lokale Hyper-V Host kann entweder mit Windows Server 2016 / 2019 oder mit Windows 10 Pro / Enterprise / Education betrieben werden, wobei die Hyper-V Rolle aktiviert sein muss.

Für Registrierung und Lizensierung einer Azure Stack HCI Umgebung ist eine Azure Subscription erforderlich. Sie können sowohl eine vorhandene Azure Subscription Ihrer Firma verwenden als auch auf eine Subscription aus einem Visual Studio Abonnement zurückgreifen. Falls Sie keine solche Subscription zur Verfügung haben, können Sie sich auch für eine kostenlose Testversion registrieren, die ein Guthaben über 170 EUR für die ersten 30 Tage enthält (Stand Juli 2021).

Ihre Azure Subscription wird durch eine Azure Stack HCI Umgebung erst 60 Tage nach der Registrierung mit 10 US-Dollar monatlich pro physischem Kern in den Cluster Knoten belastet.

Anmerkung: Falls Sie mit Ihrem HCI-Cluster am Azure Stack HCI Preview Programm teilnehmen, wird Ihre Azure Subscription für diese Ressourcen nicht belastet. Aber bitte berücksichtigen Sie, dass Preview Installationen nicht für produktive Umgebungen genutzt werden dürfen und auch keinen Support erhalten. 

Die Internetverbindung zur Public Microsoft Azure Cloud wird in unserer mit MSLab erzeugten Eval-Umgebung auf dem Domain Controller über eine zweite (virtuelle) Netzwerkkarte (vNIC) mit Hilfe der RAS (Remote Access Server) Rolle als NAT-Gateway konfiguriert und mit einem External vSwitch im Hyper-V verbunden, der dann mit dem Internet verbunden ist. 

Anmerkung: Sofern von MSLab beim Erzeugen der Internet Anbindung im Hyper-V ein vSwitch mit dem Namen Default Switch erkannt wird (bei Windows 10 Systemen), so wird dieser für die Internet Verbindung verwendet.

Unsere Eval-Umgebung werde ich nachstehend mit der „kleinsten“ Azure Stack HCI Konfiguration aufbauen, einem Cluster mit 2 HCI-Knoten. Hierzu empfiehlt sich als lokaler Hyper-V Host ein leistungsfähiges Server- oder Workstation-System. Für die nachstehende Konfiguration sollte es wenigstens 32 GB RAM haben, (deutlich) mehr kann nicht schaden, insbesondere wenn auf den Cluster-Knoten noch zusätzliche VMs laufen sollen.

Falls Sie genügend RAM und Festplattenplatz verfügbar haben, können Sie das Szenario problemlos auch auf 3, 4, 8 oder 16 Azure Stack HCI Knoten erweitern. Die Grundstruktur bleibt dabei immer die gleiche. Es ist lediglich ein Wert in der MSLab Parameterdatei und im späteren Szenarienskript anzupassen. 

Ein absolutes Muss für unseren lokalen Hyper-V Host ist auf jeden Fall eine sehr sehr schnelle „Festplatte“, auf der die virtuellen Cluster Knoten einschließlich zusätzlicher Datenlaufwrke erzeugt werden, also ein aktuelles SSD- oder NVMe-Laufwerk.

Auf dem lokalen Hyper-V Host laufen dann VMs mit folgenden Computernamen:

• AzsHCI1, AzsHCI2 …

Das sind die Cluster-Knoten unseres Azure Stack HCI Clusters. Auf ihnen läuft als Betriebssystem „Azure Stack HCI“, also die neue Windows Server Variante aus der Public Azure Cloud. Im Zuge des Deployments unserer Eval-Umgebung werden wir in diesem Cluster dann Storage Spaces Direct (S2D) konfigurieren.

Das „Azure Stack HCI“ Betriebssystem enthält keine grafischen Verwaltungstools, sondern nur die aus den Server Core Datacenter Editionen bzw. dem Hyper-V Server bekannte SCONFIG-Konfigurationsoberfläche sowie ein Kommandozeilenfenster, in dem mit der PowerShell gearbeitet werden kann. Konfiguration und Management sollten bzw. müssen über externe Systeme remote durchgeführt werden. Microsoft empfiehlt hierfür vorzugsweise das Windows Admin Center auf einem separaten Windows 10 Client oder Windows Server System oder direkt in der Public Azure Cloud. Aber auch die „klassischen“ RSAT (Remote Server Administration Tools) Module sind natürlich nutzbar.

• AzsHCIMGMT und AzsHCIW10

Diese beiden VMs sind unsere Management Systeme für die gesamte Eval-Umgebung.

AzsHCIMGMT ist ein Windows Server 2019 System, auf dem das Windows Admin Center (WAC) als Gateway installiert ist. Für unsere Eval-Umgebung sind darauf auch alle RSAT-Module installiert. Für produktive Umgebungen ist dies nicht zwingend notwendig, aber manchmal ganz hilfreich.

AzsHCIW10 ist ein Windows 10 Client System, auf dem ebenfalls das Windows Admin Center (WAC) installiert ist, allerdings nur als lokale Browser App (Anm: Das WAC-Gateway erfordert ein Windows Server System). Zusätzlich sind auch wieder alle RSAT-Module installiert. Da in unserer Eval-Umgebung alle VMs Mitglieder in einem Active Directory sein müssen, kommen als Windows 10 Varianten nur die Professional, Enterprise oder Education Edition in Frage. Mit der Home Edition ist kein Beitritt als Member in ein Active Directory möglich.

• DC

Diese VM stellt für unsere Eval-Umgebung den zentralen Active Directory (AD) Controller dar. Alle für den AD-Betrieb notwendigen bzw. sinnvollen Serverdienste wie z.B. DNS, Group Policies oder DHCP sind hier für unsere Eval-Umgebung aktiviert.

Außerdem ist auch RAS (Remote Access Service) mit einer zweiten virtuellen Netzwerkkarte (vNIC) aktiv, um unserer Eval-Umgebung einen Internet-Zugriff zu ermöglichen, insbesondere auch auf die Public Azure Cloud.

Vorbereitungen zum Erzeugen einer Azure Stack HCI Eval-Umgebung mit MSLab

Zum Erzeugen einer Azure Stack HCI Umgebung mit MSLab müssen wir einige Vorbereitungen treffen:

Konfigurieren des Hyper-V Hosts

Als erstes müssen wir den Hyper-V Host Installieren und konfigurieren. Wir können sowohl ein Windows 10 Client System (Professional, Enterprise oder Educarion) als auch eine Windows Server 2016 bzw. 2019 Edition verwenden.

Wichtig: Installieren Sie die Hyper-V Rolle und aktivieren Sie die Nested Virtualization, wenn der Hyper-V Host bereits eine virtuelle Maschine ist, z.B. in Azure.

Darüber hinaus muss eine Internet-Verbindung bestehen, um die für die MSLab-Installation notwendigen Software-Komponenten herunterzuladen. Sofern wir mit MSLab Azure Stack HCI Infrastrukturen erzeugen, benötigen wir diese Internet-Verbindung dann auch später, um sie in der Microsoft Public Azure Cloud zu registrieren und zu aktivieren.

Tipp: Falls Sie kein geeignetes Betriebssystem verfügbar haben, können Sie Testversionen dieser Systeme aus dem Microsoft Evaluation Center downloaden und installieren.

Download und Bereitstellen der MSLab Komponenten

1. Navigieren Sie in einem Browser-Fenster zur MSLab Homepage (https://github.com/microsoft/MSLab)
2. Klicken Sie auf die grüne Schaltfläche Code
3. Wählen Sie im Menü die Funktion Download ZIP

Im Download-Verzeichnis Ihres Browser finden Sie jetzt eine .ZIP-Datei mit dem Namen MSLab-master.zip. Entpacken Sie diese Archivdatei in ein geeignetes Verzeichnis auf Ihrer Festplatte, z.B. E:MSLab.

Im Scripts-Verzeichnis finden wir jetzt folgende PowerShell Skript-Dateien:

Diese 6 Dateien stellen den Kern von MSLab dar und sind eigentlich “Ready For Use” bis auf die Datei LabConfig.ps. In dieser müssen wir die Parameter zum Erzeugen unserer Eval-Umgebung hinterlegen.

Konfigurieren und Arbeiten mit der MSLab-Umgebung

Das Konfigurationsskript LabConfig.ps1

In der Datei LabConfig.ps1 müssen wir die Parameter zum Erzeugen unserer Eval-Umgebung hinterlegen. Damit wird auch festgelegt, was die anderen Skript-Dateien in MSLab durchzuführen haben. Die LabConfig.ps1 Skriptdatei wird von den anderen Skripten jeweils automatisch eingebunden.

Die Datei LabConfig.ps1 enthält eine mit PowerShell Sprachmitteln erstellte Hash Table, die einer PowerShell Variablen mit dem Namen $LabConfig zugewiesen sein muss. Als Beispiel finden Sie nachstehend die zum Erzeugen unserer AzsHCI Labumgebung verwendete $LabConfig-Version:

Tipp: Klicken Sie auf diesen Screenshot. Dann sehen Sie in einem eigenen Tab die Datei als Text.

Die $LabConfig Hash Table enthält mehrere Bereiche:

• MSLab Projektname

In diesem Bereich können Sie über den Parameter Prefix einen Namen für ihr MSLab Projekt festlegen. Dies bewirkt, dass die Namen aller Projektkomponenten mit diesem Prefix beginnen. So können Sie in größeren Umgebungen leichter die zu Ihrem Projekt gehörigen Komponenten identifizieren.

Anmerkung: Dies kann bei den Namen der VMs der Projektumgebung eventuell zu Verwirrung führen. Im Hyper-V werden die VMs mit dem Prefix aufgelistet, während als Computernamen (z.B. im Active Directory) beliebige andere Bezeichnungen verwendet werden können, die später bei den Parametern für die zu erzeugenden virtuellen Maschinen festgelegt werden.

• Active Directory Definitionen

Hier werden die Parameter für das mit MSLab zu erzeugende Active Directory festgelegt. Die Parameter sollten eigentlich selbsterklärend sein. Dass ich meine MSLab-Objekte in einer eigenen OU mit dem Namen Fabric anlege, hat den einfachen Grund, dass ich dann mit Group Policies experimentieren kann ohne die gesamte Domaine zu beeinflussen.

Noch ein Wort zum Eintrag AdminPassword: Natürlich ist das hier keine “Best Practice” Methode, sondern ein pragmatischer Ansatz im MSLab-Projekt. Falls Sie beabsichtigen, die Lab Umgebung später in eine produktive Umgebung umzuziehen, sollten Sie natürlich die Passwörter in geeigneter Form anpassen.

• Beschreibung der Netzwerkumgebung

MSLab erzeugt grundsätzlich einen virtuellen internen Hyper-V Switch, dessen Name im Eintrag SwitchName anzugeben ist. Beim Erzeugen wird diesem Namen der Wert des Eintrags Prefix vorangestellt, in unserem Beispiel wird also der vSwitch den Namen AzsHCI-Switch erhalten.

Das durch diesem Switch realisierte Netzwerk stellt das Management LAN dar. Alle VMs sind mindestens mit diesem Switch verbunden. Alle “Ports” dieses vSwitch laufen im Trunk-Mode, so dass außer dem Managementnetz noch weitere Netze insbesondere mit eigenen VLANDIDs angebunden werden können. Eine Liste erlaubter VLANIDs kann über den Eintrag AllowedVLANs festgelegt werden.

Falls wir in der Basiskonfiguration zusätzliche Netze erzeugen wollen, können wir diese hier gleich in einem Array mit dem Namen AdditionalNetworksConfig definieren und dann festlegen, ob sie auch im Domain Controller verfügbar sein sollen oder nur in den “normalen” VMs (AdditionalNetworksInDC=$false | $true).

Für die Basiskonfiguration unserer AzsHCI Labumgebung verzichten wir hier zunächst auf zusätzliche Netze und VLANs. Jedoch werden wir in späteren Szenarien darauf zurückkommen.

Interessant ist an dieser Stelle noch der Eintrag Internet = $true. Dieser bewirkt, dass beim Erzeugen des Domain Controllers dieser eine zusätzliche virtuelle Netzwerkkarte erhält. Läuft der Hyper-V Host mit einer aktuellen Windows 10 Version, wird diese zusätzliche Netzwerkkarte im DC mit dem immer vorhandenen Default Switch verbunden. Bei einem Windows Server wird nach einem freien External vSwitch gesucht bzw. falls möglich ein neuer angelegt.

• Allgemeine Angaben für den Hyper-V Host

EnableGuestServiceInterface=$true: Dieser Eintrag bewirkt, dass bei den erzeugten VMs die Hyper-V Gastdienste aktiviert werden, um z.B. Daten zwischen Hyper-V und VM auszutauschen (Zwischenablage, Client-Laufwerke, direkter PowerShell Zugriff). Mit älteren MSLab-Versionen (vor Release v21.02.2) kann es dabei bei einem nicht US-englischen Betriebssystemen auf dem Hyper-V Host zu Fehlern kommen, die allerdings keine sonstigen Auswirkungen auf das Erzeugen der Lab-Umgebung haben.

Das Problem können Sie ganz einfach über den Hyper-V Manager des Hosts beheben, indem Sie diesen Dienst für jede VM manuell aktivieren, z.B. in einem deutschen Hyper-V System:

Auf den Eintrag TelemetryLevel werde ich gleich im nächsten Abschnitt eingehen. Und über den Eintrag AutoStartAfterDeploy = $false oder $true kann festgelegt werden, ob die erzeugten VMs gleich gestartet werden sollen. Ich bevorzuge hier den $false Wert, da ich dann nochmals die erzeugten VMs vor dem ersten Start inspizieren und ggf. anpassen kann.

• Parameter für die zu erzeugenden virtuellen Maschinen

In der $LabConfig Hash Table muss ein Eintrag VMs = @(); vorhanden sein. Die Elemente dieses Arrays sind wiederum Hash Tables mit den Parametern für die zu erzeugenden virtuellen Maschinen.

Für jede zu erzeugende VM muss in der LabConfig.ps1-Datei eine eigene Hash Table angelegt werden, in der die VM-Merkmale festgelegt sind wie der VHDX-Datenträger mit dem Bootimage, Anzahl virtueller CPUs, RAM-Größen, Anzahl Netzwerkadapter oder Anzahl zusätzlicher virtueller Datenträger (z.B. für Szenarien mit S2D – Storage Spaces Direct).

Werfen wir jeweils einen kurzen Blick auf die Parameter der für unsere Lab-Umgebung notwendigen VMs.

Starten wir mit den beiden Azure Stack HCI Knoten:

Tipp: Klicken Sie auf diesen Screenshot. Dann sehen Sie in einem eigenen Tab die Datei als Text.

Sie haben bis auf den Namen identische Parameter, so dass wir sie in einem foreach Block ( 1..2 | % {…} ) gemeinsam beschreiben können. Falls Sie beabsichtigen, Ihre Azure Stack HCI Umgebung mit mehr als 2 Cluster Knoten aufzubauen, so ändern Sie einfach den oberen Wert des foreach Blocks entsprechend (also in z.B.  1..4 | % {…} ). 

Die meisten Parameter insbesondere für die virtuelle VM Hardware dürften selbsterklärend sein. Ein paar Hinweise halte ich aber für notwendig:

Configuration

MSLab kann verschiedene Typen von VMs in Bezug auf zusätzliche virtuelle lokale Laufwerke erzeugen. ‚S2D‘ erzeugt zusätzliche virtuelle Laufwerke für Storage Spaces Direct (S2D). Anzahl, Typ (HDD oder SSD) und Größe können über zusätzliche Parameter festgelegt werden (HDDNumber und HDDSize bzw. SSDNumber und SSDSize).

Anmerkung: Angaben zu SSD-Laufwerken werden zwar bei den VMs berücksichtigt. Sie dienen in unserer virtuellen Umgebung aber nur zur Simulation eines Cache für S2D ohne weitere Auswirkungen.

Wir werden gleich bei den Management Systemen sehen, dass dort als Wert ‘Simple’ angegeben ist. Dann erhält die VM nur 1 lokales Laufwerk mit dem Boot Image, das beim Parameter ParentVHD angegeben ist.

Es gibt noch einige weitere Parameterwerte, die aber für unsere Azure Stack HCI Eval Umgebung ohne Bedeutung sind.

NestedVirt=$trueStaticMemory=$trueMemoryStartupBytes=24GB

Unsere VMs sollen als Knoten in einem Hyperconverged Cluster arbeiten. Dazu muss später Hyper-V installiert werden. Das ist in einer VM, die auf einem Hyper-V läuft, nur möglich, wenn im VM-Prozessor einige Erweiterungen aktiviert sind und der VM eine feste Speichergröße zugewiesen ist – in unserem Beispiel 24GB RAM.

ParentVHD

Hier wird der Dateiname des Boot Images (.VHDX-Datei) für die VM angegeben. Diese Datei muss im Verzeichnis Scripts/ParentDisks bereitgestellt werden. Diese Image Datei dient als Parentdisk. Das Bootlaufwerk der VM wird als differenzierendes Laufwerk zu dieser Imagedatei angelegt.

Das Verzeichnis Scripts/ParentDisks wird automatisch im Script-Verzeichnis unseres MSLab-Projekts beim Aufruf des PowerShell Skripts 1_Prereq.ps1 angelegt. Die Imagedateien erzeugen Sie dann z.B. mit dem PowerShell Skript 2_CreateParentDisks.ps1. Ich werde weiter unten gleich auf diese beiden Skripte zurückkommen.

CustomPowerShellCommands

 MSLab generiert beim Erzeugen einer VM jeweils eine eigene Unattend.xml Datei für den Windows Setup Prozess. Bei diesem Parameter kann ein Array mit PowerShell Kommandos angegeben werden. Diese werden dann beim Erzeugen der VM in die Unattend.xml Datei in den Abschnitt <RunSynchronousCommand> kopiert und werden dann automatisch nach Fertigstellung der VM ausgeführt.

Zumindest für Lab-Umgebungen halte ich es für sinnvoll, hier ein paar Firewall Regeln zu aktivieren, um z.B. bei Netzwerkproblemen mit PING Verbindungstests durchführen zu können oder auch auf Freigaben anderer Systeme zugreifen zu können.

Und der Vollständigkeit halber hier auch noch die Definitionen für die Management Systeme mit Windows Server 2019 und Windows 10:

Tipp: Klicken Sie auf diesen Screenshot. Dann sehen Sie in einem eigenen Tab die Datei als Text.

Wie wir sehen, ist hier die Configuration der VMs jeweils mit Simple definiert. Dementsprechend müssen wir auch keine Angaben zu zusätzlichen SSD- oder HDD-Laufwerken machen und können mit dynamischen RAM-Speicher arbeiten.

Telemetrie – das Skript 0_Shared.ps1

Diese Skript-Datei ist relativ neu bei MSLab. Eigentlich brauchen wir uns um sie nicht weiter zu kümmern; sie wird von den anderen Skripten automatisch eingebunden. Doch was macht sie? Ganz einfach – Telemetrie! Über den Parameter TelemetryLevel in der LabConfig.ps1 können wir das Sammeln von Telemetrie-Daten steuern. Als Werte können wir festlegen:

• None: Es werden keine Telemetriedaten gesendet. Sinnvoll vor allem auch bei Offline-Szenarien!

• Basic: Sammelt und sendet Informationen über die erzeugten MSLab-Projekte. Internet-Verbindung ist notwendig!

• Full: Sammelt zusätzlich Informationen zum Host-System, auf dem MSLab gerade ausgeführt wird. Internet-Verbindung ist notwendig!

Detaillierte Informationen kann man in der Datei mslab-telemetry.md im Docs-Verzeichnis von MSLab nachlesen. Und immerhin können wir im Unterschied zu vielen anderen Produkten, die Telemetriedaten sammeln, hier uns auch im Source Code anschauen, was tatsächlich über die Leitung geht.

Sammeln benötigter Softwarekomponenten – das Skript 1_Prereq.ps1

Nachdem wir die Parameter unserer Lab-Umgebung in der Datei LabConfig.ps1 hinterlegt haben, können wir mit dem Erzeugen der Projektkomponenten und VMs starten. Der erste Schritt ist ein Aufruf der Skriptdatei 1_Prereq.ps1.

Das Skript fordert bei Bedarf erhöhte Ausführungsrechte an. Es erzeugt dann einige Unterverzeichnisse im Scripts-Verzeichnis des MSLab-Projektordners wie z.B. Scripts/ParentDisks und Scripts/Temp und führt dann einige Downloads für DSC-Komponenten nach Scripts/Temp/DSC durch. Diese sind zwingend zum Erzeugen der Lab-VMs – insbesondere des Domain Controllers – notwendig.

Unter dem Scripts/Temp Verzeichnis wird außerdem ein Verzeichnis mit dem Namen ToolsVHD angelegt und mit einigen hilfreichen zusätzlichen PowerShell Skripten befüllt wie z.B. für die optionale Installation zusätzlicher Softwarekomponenten wie SCVMM (System Center Virtual Machine Manager) oder VMFleet (ein Testpaket für Storage Spaces Direct).

In dieses ToolsVHD Verzeichnis können Sie auch selbst beliebige weitere Softwarekomponenten und Installationsprogramme kopieren. Dazu gehören in meinen MSLab-Projekten z.B. immer die Setup-Dateien für das Windows Admin Center sowie für den Microsoft Edge Browser.

Tipps: Die jeweils aktuellen Versionen des Microsoft Edge Browsers und des Windows Admin Centers (WAC) finden Sie unter folgenden URLs zum Downloaden:

Edge Browser: https://aka.ms/edge-msiAdmin Center: https://aka.ms/WACDownload

mit PowerShell z.B.

Start-BitsTransfer -Source https://aka.ms/edge-msi -Destination „E:MSLabScriptsTempToolsVHDMSEdge.msi“Start-BitsTransfer -Source https://aka.ms/WACDownload -Destination „E:MSLabScriptsTempToolsVHDWindowsAdminCenter.msi“

Der Inhalt des ToolsVHD Verzeichnisses wird später beim Erzeugen der virtuellen Festplatten für die VMs mit dem Skript 2_CreateParentDisks.ps1 in eine eigene virtuelle Festplatte mit dem Namen tools.vhdx kopiert und kann dann als zusätzliches Laufwerk an eine beliebige VM angebunden werden. Standardmäßig geschieht dies bei der Domain Controller VM. Damit können alle VMs, die Mitglieder im Active Directory sind, relativ einfach auf die Inhalte der Tools.vhdx Festplatte zugreifen.

Bereitstellen benötigter Betriebssystem-Installationsdatenträger und System Updates

In der Datei LabConfig.ps1 haben wir bei den jeweiligen VMs die System-Imagedateien (VHDX-Dateien) angegeben, mit denen sie starten sollen. Diese VHDX-Dateien können wir zwar mit den später noch beschriebenen Skripten CreateParentDisks.ps1 erzeugen. Dazu müssen wir aber die jeweiligen Installationsdatenträger als ISO-Dateien bereitstellen. Sinnvoll ist es auch, gleich die jeweils aktuellsten Updates / Patches verfügbar zu haben, da wir diese dann gleich beim Erzeugen der Imagedateien „injizieren“ können.

Bereitstellen der ISO-Installationsdateien für die Betriebssysteme

Die benötigten Windows Server ISO Dateien müssen wir manuell bereitstellen. Wir können sowohl „Voll“-Versionen z.B. aus einem Volume License Vertrag oder aus MSDN verwenden, mit Evaluierungsversionen aus dem Microsoft Eval Center arbeiten oder auch Versionen aus dem Windows Server Insider Programm benutzen. 

Für unsere Cluster Knoten mit Azure Stack HCI benötigen wir außerdem die ISO-Datei für diese spezielle Windows Server Variante, die wir nach einer Registrierung über die Azure Stack HCI Software Download Seite herunterladen können.

Download Tipps:

• Win2019 Datacenter Eval – für AzSHCI-DC und AzSHCI-MGMT
  • https://www.microsoft.com/de-de/evalcenter/evaluate-windows-server-2019
• Win10 Enterprise Eval – für AzSHCI-Win10
  • https://www.microsoft.com/de-de/evalcenter/evaluate-windows-10-enterprise
• AzSHCI – für Cluster Nodes
  • https://azure.microsoft.com/en-us/products/azure-stack/hci/hci-download

Die ISO-Dateien können Sie an beliebigen Orten speichern, ich bevorzuge dabei den Scripts/ParentDisks Ordner im MSLab Projektverzeichnis, in dem dann ja auch die erzeugtem VHDX-Dateien abgelegt werden. 

Download der aktuellsten System Updates

Beim späteren Erzeugen der Master Images für unsere Lab-VMs besteht die Möglichkeit, auch gleich die aktuellsten System Updates in die VHDX-Dateien einzuspielen. Dies ist zwar optional. Wenn man aber die zur Systemversion in der ISO-Datei passenden Updates dabei gleich „injiziert“, spart man sich hinterher in den erzeugten virtuellen Maschinen (VMs) das Patchen mit diesen Windows Updates (!). Microsoft stellt die jeweiligen System Updates üblicherweise monatlich über den Microsoft Update Katalog im Internet in Form von .MSU-Dateien zum Download bereit. 

Doch wie kommt man an diese .MSU-Dateien? Hierzu finden wir im ParentDisks-Verzeichnis ein spezielles PowerShell Skript:

DownloadLatestCUs.ps1

Dieses Skript lädt aus dem Microsoft Update Katalog im Internet die aktuellsten Update Pakete („Cummulative Updates“ – CUs und „Service Stack Updates“ – SSUs) für eine oder mehrere vorgegebene Windows Versionen und speichert sie als .MSU-Dateien in einem lokalen Ordner.

Als erstes muss man ein Verzeichnis angeben, in das die Update-Dateien gespeichert werden sollen (keine Eingabe ==> aktuelles Verzeichnis). Dann will das Skript wissen, ob nach Updates für „Preview“ (z.B. aus den Windows Insider Programmen)  oder „offiziellen“ Windows Versionen gesucht werden soll. 

In einer Tabelle kann man dann eine oder auch mehrere Windows Versionen auswählen, für die man Updates suchen und downloaden will, wobei nur Versionen angezeigt werden, deren Lebenszyklus noch nicht abgelaufen ist. 

Im vorstehenden Screenshot wurde das Skript angewiesen, nach Updates für „offizielle“ Versionen zu suchen (preview = ’n‘). In der Windows Versions Liste wurden dann alle Einträge ausgewählt und mit „OK“ bestätigt. 

Jetzt werden alle relevanten CUs und SSUs im  Microsoft Update Katalog gesucht und in das angegebene Zielverzeichnis (hier: E:MSLab/Scripts/ParentDisks) kopiert. Je nach Zahl ausgewählter Updates und deren Größe kann dies einige Zeit beanspruchen.

Nach Abschluss der Downloads wird dann unser ParentDisks-Verzeichnis beispielsweise folgenden Inhalt haben:

Für jede Windows Version wird ein eigenes Unterverzeichnis angelegt. Die zugehörigen .MSU-Dateien findet man dann in einem Ordner, dessen Name das Release Datum der Updates widerspiegelt.

PatchParentDisks.ps1

Dieses Skript ist hilfreich, wenn man in bereits erzeugte .VHDX-Dateien nachträglich System Updates (.MSU-Dateien) einspielen will. Für unsere Azure Stack HCI Evaluierung benötigen wir dieses Skript nicht und brauchen uns deshalb auch nicht weiter darum kümmern.

Master Images für die LAB-VMs erzeugen

Nachdem wir mit dem im vorigen Abschnitt beschriebenen Skript 1_Prereq.ps1 die grundlegende Verzeichnis- und Dateistruktur unserer MSLab-Umgebung angelegt und die benötigten .ISO-Dateien nebst den aktuellen Updatedateien bereitgestellt haben, kommt jetzt der zeitlich wohl aufwendigste Teil beim Erzeugen eines MSLab-Projekts: Das Generieren der Master Images für die VMs der MSLab-Umgebung. Dazu stehen uns verschiedene PowerShell Skripte sowohl im Skripts-Verzeichnis als auch im Unterverzeichnis Scripts/ParentDisks zur Verfügung.

Windows Server VHDX-Dateien, Domain Controller VM Template und das Skript 2_CreateParentDisks.ps1

MSLab-Projekte enthalten typischerweise immer mehrere virtuelle Maschinen (VMs) auf Basis einer Windows Server Version. In jedem Fall muss eine dieser VMs ein Domain Controller für eine Active Directory Umgebung sein. Die Parameter dazu sind in der LabConfig.ps1 Datei hinterlegt. Wir müssen also aus einer Windows Server ISO-Datei mindestens eine .VHDX-Datei erzeugen, auf deren Basis wir auch ein Template für einen Domain Controller erstellen können. Dies ist eine der Hauptaufgaben des Skripts 2_CreateParentDisks.ps1.

Die mit diesem Skript erzeugten .VHDX-Dateien können auch als Basis für andere VMs als den Domain Controller verwendet werden, z.B. für ein Management System. Auf die Herausforderung, wie man sich .VHDX-Dateien aus nicht Windows Server .ISO-Dateien erzeugt (z.B. für Windows 10 Client VMs) werde ich später zurückkommen. 

Erzeugen von Windows Server .VHDX-Dateien

Starten wir also das 2_CreateParentDisks.ps1 Skript in einer PowerShell Sitzung mit erhöhten Rechten (das Skript überprüft dies und startet falls notwendig eine entsprechende weitere PowerShell Sitzung). Das Skript fragt dann als erstes, mit welcher Windows Server ISO-Datei gearbeitet werden soll.

Im Beispiel hier wählen wir die ISO-Datei mit der Evaluierungsversion von Windows Server 2019. Das Skript prüft, ob es sich bei der .ISO-Datei um eine Windows Server Version handelt und fragt dann, ob  und welche Windows Server Update Files eingebunden werden sollen.

Wichtig dabei ist, alle für die zuvor angegebene Windows Server Version passenden .MSU-Dateien anzugeben – in unserem Beispiel hier die beiden zuvor mit DownloadLatestCUs.ps1 Ende März 2021 bereits heruntergeladenen .MSU-Dateien für Windows Server 2019. Versuchen Sie, nicht zur Windows Version passende .MSU-Dateien auszuwählen, werden diese ohne Meldung bei der weiteren Verarbeitung einfach ignoriert. 

Jetzt geht’s also ans Erzeugen der .VHDX-Dateien nach folgender Strategie: Das Skript prüft immer zuerst, ob eine gewünschte .VHDX-Datei bereits vorhanden ist. Falls ja, wird eine entsprechende Meldung ausgegeben und die Aktion übersprungen, wie folgende Screenshots z.B. für die Server Parent Disks oder die Tools.vhdx zeigen:

Im weiteren Ablauf wird dann die vorhandene Datei verwendet.

Daraus folgt: Um eine bereits vorhandene .VHDX-Datei neu zu erstellen, müssen wir sie vor dem Aufruf des Skript 2_CreateParentDisks.ps1 manuell löschen. 

Aus der angegebenen Windows Server .ISO-Datei werden jetzt 2 .VHDX-Dateien erzeugt: Eine mit der Datacenter Edition einschließlich GUI und eine zweite, die nur die Datacenter Core Version enthält. In unserem Beispiel mit dem Windows Server 2019 wird dies dann in etwa folgendermaßen aussehen:

Nach den Server Parent Disks wird noch die Datendisk tools.vhdx erzeugt und im ParentDisks Verzeichnis abgelegt.

Wahrscheinlich fragen Sie sich jetzt, woher die Dateinamen Win2019_G2.vhdx und Win2019Core_G2.vhdx für die Server Parent Disks kommen, obwohl wir vom Skript nicht danach gefragt wurden. Diese entstehen durch die im Skript fest implementierten Namenskonventionen. Ich werde im nächsten Abschnitt gleich darauf eingehen.

Namenskonventionen für die VHDX-Dateien aus einer Windows Server .ISO-Datei

Zum Erzeugen der Windows Server .VHDX-Dateien ermittelt das Skript 2_CreateParentDisks.ps1 aus der Setup.exe der angegebenen ISO-Datei, um welche Windows Server Variante es sich handelt (Windows Server 2016 oder 2019 oder Insider) und generiert daraus die Namen der VHDX-Dateien:

• Windows Server 2016: Win2016_G2.vhdx und Win2016Core_G2.vhdx
• Windows Server 2019: Win2019_G2.vhdx und Win2019Core_G2.vhdx
• Windows Server Insider:       WinSrvInsider<BuildNumber>.vhdx und WinSrvInsiderCore<BuildNumber>.vhdx

Wichtig ist die Kenntnis dieser Namenskonventionen, weil wir die Namen der .VHDX-Dateien in der MSLab-Konfigurationsdatei LabConfig.ps1 bei den jeweiligen VMs angeben müssen.

Erzeugen des Domain Controller Templates

Nach dem erfolgreichen Erzeugen der Windows Server .VHDX-Dateien versucht das Skript, ein Template für eine Domain Controller VM auf Basis der gerade erzeugten .VHDX-Datei zu generieren. Dazu wird im Scripts-Verzeichnis ein Unterverzeichnis mit dem Namen LAB angelegt und darunter ein weiteres mit dem Namen DC. 

└───Scripts           └───LAB                      └───DC

Im DC-Unterverzeichnis wird dann eine Hyper-V VM generiert, die als Boot Image eine Kopie der erzeugten .VHDX-Datei erhält. In diese Kopie werden noch die DSC-Komponenten zum Erzeugen und Konfigurieren einer Active Directory Umgebung einschließlich DHCP und DNS kopiert und die VM  dann gestartet. 

Dieser Vorgang kann beträchtliche Zeit dauern – vorstehender Screenshot zeigt nur die wichtigsten Statusmeldungen. Nach der erfolgreichen Erstellung der DC VM wird diese wieder heruntergefahren, die VM Konfiguration in einer .ZIP-Datei als Backup gespeichert und aus dem Hyper-V entfernt.

Damit ist die Arbeit des Skripts 2_CreateParentDisks.ps1 abgeschlossen. Es wird eine Endemeldung ausgegeben und das Skript fragt nun noch, ob Komponenten, die für die weiteren Schritte nicht mehr unbedingt notwendig sind, gelöscht werden sollen. Ich empfehle, hier mit ‚N‚ zu antworten. Dann kann man bei Bedarf (z.B. bei Fehlern) leichter wieder neu aufsetzen. 

Ablaufprotokolle der Skripte

Die Skripte eines MSLab Projekts benötigen meistens eine längere Ausführungszeit und erzeugen jede Menge Statusmeldungen. Damit man aber nicht ständig den Bildschirm beobachten muss, erzeugen alle Skripte ein Ablaufprotokoll in einer Textdatei im Scripts-Verzeichnis. Der Dateiname einer solchen Protokolldatei entspricht dem Skriptnamen, jedoch mit der Endung .log (z.B. createParentDisks.log). So kann man später die Skriptausführung einfach nachvollziehen.

Aber Achtung: Führt man ein Skript ein weiteres Mal aus, wird das Protokoll eines vorherigen Laufs ohne Warnung überschrieben.

Skripte für VHDX-Dateien aus Nicht Server 2016 / 2019 ISOs

Je nach Szenario, das wir mit MSLab umsetzen wollen, kann es notwendig sein, dass wir zusätzlich zu den .VHDX-Dateien aus den Windows Server 2016 / 2019 ISOs weitere Images bereitstellen müssen. Für  unsere Azure Stack HCI Umgebung benötigen wir zum Beispiel für die S2D Cluster Knoten .VHDX-Dateien aus der ISO-Datei, die wir aus der Microsoft Azure Cloud herunterladen müssen. Außerdem ist in der Lab-Umgebung auch ein Client Management System mit Windows 10 Enterprise vorgesehen, für das wir auch ein Image erzeugen müssen. 

Bei diesen Sonderfällen können wir nicht mit dem Skript 2_CreateParentDisks.ps1 arbeiten. Wir finden aber hierfür im ParentDisks-Verzeichnis einige weitere hilfreiche PowerShell-Skripte, mit denen wir .VHDX-Dateien auch aus Nicht Server 2016 / 2019 ISOs erzeugen und bearbeiten können:

CreateParentDisk.ps1

Dieses Skript beinhaltet die Logik zum Erzeugen von .VHDX-Dateien aus 2_CreateParentDisks.ps1 in einer erweiterten Form. Es versucht, weitere .ISO-Images zu erkennen und damit Vorschläge für den Namen der .VHDX-Datei anzubieten. Es erkennt z.B. auch unsere ISO-Datei mit dem Azure Stack HCI System und unsere Windows 10 Enterprise Edition und schlägt dafür folgende Namen für die VHDX-Dateien vor:

Azure Stack HCI 20H2Windows 10 Enterprise 20H1

AzSHCI20H2_G2.vhdxWin1020H1_G2.vhdx

In jedem Fall fragt diese Skript dann auch in einem eigenen Dialog, ob der vorgeschlagene .VHDX-Name übernommen oder ein eigener verwendet werden soll. Zusätzlich besteht auch die Möglichkeit, die (virtuelle) Größe der .VHDX-Datei (z.B. 60 GB) festzulegen. Und natürlich kann man auch optional gleich wieder die letzten Updates in die .VHDX-Dateien injizieren. 

Wichtiger Hinweis: Bitte verwechseln Sie nicht die beiden Skripte 2_CreateParentDisks.ps1 im Verzeichnis Scripts und CreateParentDisk.ps1 im Unterverzeichnis Scripts/ParentDisks. Ersteres erzeugt aus einer Windows Server .ISO-Datei .VHDX-Dateien und erstellt damit ein Template für den Domain Controller des MSLab-Projekts während CreateParentDisk.ps1 aus einer beliebigen Windows .ISO-Installationsdatei nur eine einzelne .VHDX-Datei ohne weitere Aktionen erzeugt.

Convert-WindowsImage.ps1

Mit diesem Skript wird man beim Arbeiten mit MSLab eher selten direkt in Berührung kommen. Es wird von den vorstehend beschriebenen Skripten 2_CreateParentDisks.ps1 und CreateParentDisk.ps1 mit geeigneten Parametern aufgerufen, um die gewünschten .VHDX-Dateien aus den vorgegebenen  .ISO-Files zu erzeugen. Dieses Skript stammt ursprünglich aus der PowerShell Gallery, wird jedoch beim MSLab Download gleich mit ins Scripts/Temp Verzeichnis kopiert, so dass man sich den Extra-Download aus der PowerShell Gallery sparen kann. 

Tipp: Aktivieren von Windows Features in den VHDX-Dateien

Bei vielen Szenarien, die wir mit MSLab realisieren können, müssen in den virtuellen Maschinen später verschiedene Windows Features aktiviert werden. Das ist zwar in den Skripten für die Szenarien üblicherweise berücksichtigt, hat jedoch den Nachteil dass diese Features in jeder VM einzeln aktiviert werden müssen, was unter Umständen sehr zeitaufwändig sein kann.

In solchen Fällen kann es sinnvoll sein, die benötigten Features bereits in der .VHDX-Datei zu aktivieren. Wird dann eine VM mit einer so aufbereiteten VHDX-Datei erzeugt, so stehen nach dem finalen Restart gleich all die aktivierten Features zur Verfügung.

Das trifft z.B. auch bei unseren Azure Stack HCI Knoten zu. Folgende Windows Features sind dort notwendig:

• Hyper-V einschl. PowerShell Management
• Failover Cluster 
• Bitlocker
• Datacenter Bridging
• Deduplication
• ActiveDirectory PowerShell Management

Mit einem kleinen PowerShell-Skript kann man in den AzSHCI20H2_G2.vhdx Dateien diese Windows Features gleich aktivieren. 

Tipp: Klicken Sie auf diesen Screenshot. Dann sehen Sie in einem eigenen Tab die Datei als Text.

Ergebnis nach dem Erzeugen der .VHDX-Dateien 

Nach den etwas langwierigen Schritten zum Erzeugen der verschiedenen .VHDX-Dateien sollte der Inhalt des ParentDisks-Verzeichnisses für unsere Azure Stack HCI Evaluierungsumgebung in etwa wie folgt aussehen:

Damit können wir uns dem nächsten Schritt zuwenden – dem Ausrollen der Lab-VMs

Ausrollen der Lab-VMs – das Skript 3_Deploy.ps1

Wenn wir wie im vorigen Abschnitt beschrieben die benötigten VHDX-Images erzeugt und mit dem Skript 2_CreateParentDisks.ps1 erfolgreich ein Template für unseren Domain Controller angelegt haben, liegt der zeitaufwendigste Teil beim Erstellen eines MSLab Projekts hinter uns. Jetzt können wir das Ausrollen unserer Lab-Umgebung durchführen, was mit dem PowerShell Skript 3_Deploy.ps1 geschieht.

Das Skript erfordert wieder erhöhte Ausführungsrechte. Nach dem Start legt es aber sofort ohne weitere Dialoge und Rückfragen los. Es prüft, ob die Systemvoraussetzungen des Hyper-V Hosts erfüllt sind. Dann wird versucht, den für das Projekt notwendigen Hyper-V Switch anzulegen. 

Falls in der LabConfig.ps1 beim Parameter Internet der Wert $true angegeben ist, wird auch die Internetverbindung über den Default Switch des Hyper-V Hosts generiert. 

Dann geht es ans Generieren des Domain Controllers unserer MSLab-Umgebung auf Basis des im vorherigen Schritt erzeugten Templates. 

Dabei passiert nichts außergewöhnliches. Jedoch kann es je nach Performance des Hyper-V Host zu einer oder auch mehreren Fehlermeldungen „Attempting to perform the InitializeDefaultDrives operation on the ‚ActiveDirectory‘ provider failed.“ kommen. Diese können problemlos ignoriert werden. Wenn das Active Directory betriebsbereit ist, erscheint eine entsprechende Meldung und es werden letzte Konfigurationsarbeiten wie z.B. RAS mit NAT am DC eingerichtet. 

Nun können die verschiedenen virtuellen Maschinen (VMs) entsprechend den Parametern in der LabConfig.ps1 Datei erzeugt werden, in unserem Beispiel also die beiden Cluster Knoten sowie die beiden Management Systeme mit Windows Server 2019 und Windows 10.

Wie man im obigen Screenshot sieht, dauert das Deployment unserer MSLab-Umgebung nur einige Minuten, natürlich abhängig von der Anzahl der zu erzeugenden VMs.

Wie die anderen MSLab-Skripte erstellt auch 3_Deploy.ps1 ein Protokoll in einer Textdatei mit dem Namen Deploy.log.

Ergebnis nach dem Ausrollen der Lab-Umgebung

Von 3_Deploy.ps1 erzeugte Verzeichnisstruktur

Im Hyper-V von 3_Deploy.ps1 erzeugte VMs

Nach dem erfolgreichen Abschluss des 3_Deploy.ps1 Skripts finden wir im Hyper-V Manager die erzeugten VMs und auf unserem Deployment-Laufwerk im Verzeichnis .Scripts/Lab/VMs für jede VM ein eigenes Unterverzeichnis. 

Unter Virtual Machines sind die Hyper-V Einstellungen der jeweiligen VM abgelegt und unter Virtual Hard Disks finden wir die während des Deployments erzeugten virtuellen Festplatten.  Bitte beachten Sie, dass es sich bei den Boot Images um differenzierende virtuelle Festplatten handelt, deren übergeordnete .VHDX-Dateien  im ParentDisks liegen.

Löschen einer ausgerollten Lab-Umgebung – das Skript Cleanup.ps1

Gerade in der Entwicklungsphase einer Lab-Umgebung kann es öfter passieren, dass man die ausgerollten VMs löschen und z.B. mit geänderten Parametern neu erstellen will. Das ist zwar prinzipiell kein Hexenwerk, jedoch sollte man eine bestimmte Reihenfolge beachten.

Als erstes sollte man noch laufende VMs herunterfahren und sie dann aus dem Hyper-V Manager löschen. Dann kann man die für das Deployment erzeugten Hyper-V Switches entfernen. Jetzt kann auch die Verzeichnisstruktur mit den VMs unter .Scripts/Lab/VMs gelöscht werden. 

Bitte vermeiden Sie das Löschen der Dateien für den Domain Controller bzw. dessen Template im Verzeichnis .Scripts/Lab/DC. Sollte Ihnen das versehentlich passieren, müssen Sie nochmals mit dem Skript 2_CreateParentDisks.ps1 das Generieren eines neuen DC Templates durchführen.

Ich empfehle Ihnen statt des manuellen Löschens der Lab-Komponenten das Skript Cleanup.ps1 zu verwenden. Es führt die vorstehend beschriebenen Aktionen automatisch in der richtigen Reihenfolge durch.

Danach ist unsere MSLab-Umgebung im gleichen Zustand wie nach Abschluss des Skripts 2_CreateParentDisks.ps1 und wir können (ggf. mit veränderten Parametern in der LabConfig.ps1) ein neues Deployment durchführen. 

So ist es relativ einfach, mehrere ähnliche Lab-Tests hintereinander durchzuführen durch Löschen mit Cleanup.ps1 und anschließendem erneuten Ausrollen mit 3_Deploy.ps1.

MSLab-Szenarien

Nachdem wir mit den vorstehend beschriebenen Skripten unsere MSLab-Umgebung erzeugt haben, stellt sich die Frage, wie wir mit diesen „nackten“ VMs nun spezielle Tests durchführen können. Ziel dieses Artikels ist ja z.B. der Aufbau eines HCI-Clusters mit 2 Knoten auf Basis der Azure Stack HCI Betriebssystemvariante aus der Azure Cloud.

Dazu könnten wir jetzt den  Azure Stack HCI 20H2 – Evaluation Guide heranziehen und ab Part 4 mit dem Windows Admin Center (WAC) die dort beschriebenen Schritte durchführen. Das WAC enthält seit einiger Zeit einen Cluster Creation Wizard, mit dem verschiedene Cluster Typen interaktiv im Browser erzeugt werden können. Diese WAC-Erweiterung wäre eigentlich ein tolles und einfach zu handhabendes Werkzeug. Leider mussten ich und auch andere Consultant Kollegen hin und wieder feststellen, dass dieser Wizard (noch) nicht immer zuverlässig funktioniert. Mal scheitert die Interprozesskommunikation zwischen Komponenten an Timing Problemen, mal treten Ungereimtheiten beim Ressourcenzugriff mit der CredSSP-Authentisierung auf oder es kommt keine Verbindung mit dem Public Azure Portal zustande. Die Probleme sind bei Microsoft bekannt und sollen mit zukünftigen WAC-Versionen bereinigt werden.

Aber es gibt zuverlässige Alternativen – die Scenario-Skripte aus dem MSLab-Projekt. Es sind PowerShell  Skripte, die typischerweise auf einem Managementsystem in einer PowerShell Session mit erhöhten Ausführungsrechten ausgeführt werden. Und die meisten Szenarien folgen dabei den Best Practices von Microsoft, so dass sie auch für die Konfiguration von produktiven Umgebungen verwendet werden können.

Für produktive Installationen sehe ich außerdem beim Einsatz von PowerShell Skripten den Vorteil, dass man gleichzeitig eine Dokumentation über die notwendigen und durchgeführten Konfigurationsschritte für ein Szenario verfügbar hat.

Ein MSLab Szenario besteht üblicherweise aus einem entsprechenden PowerShell Skript und enthält meistens auch weitergehende Screenshots und Dokumentationen. Aktuell sind im MSLab-Download um die 65 Szenarien enthalten, wovon sich auch einige auf die Azure Stack HCI Betriebssystemvariante beziehen.

Beim Erzeugen unserer Evaluierungsumgebung habe ich darauf geachtet, dass wir das MSLab Szenario AzSHCI Deployment möglichst ohne große Anpassungen direkt verwenden können, um ein Azure Stack HCI Cluster mit 2 Knoten einschließlich Storage Spaces Direct (S2D) zu konfigurieren.

Das Szenario Skript AzSHCI Deployment

Das Szenario-Skript AzSHCI Deployment finden Sie im MSLab-Download im Scenarios Verzeichnis im Unterverzeichnis „AzSHCI Deployment“. 

Es führt die komplette Installation eines Azure Stack HCI Clusters mit 2 Knoten einschließlich der Konfiguration der Betriebssysteme, der Cluster Konfiguration, der Storage Spaces Direct (S2D) Konfiguration sowie die zwingend notwendige Registrierung in der Public Azure Cloud durch und erzeugt dann im S2D Storage einige Volumes und darin dann einige VMs.

Das Skript folgt den von Microsoft empfohlenen „Best Practices„, so dass Sie es nicht nur für unsere Testumgebung mit virtuellen Maschinen, sondern auch für produktive Installationen mit „echter“ Hardware verwenden können. 

Bei meinen Tests musste ich dann feststellen, dass an einigen Stellen Änderungen und Ergänzungen für unsere AzsHCI-Testumgebung durchzuführen sind. Um Ihnen die Tipparbeit abzunehmen bzw. etwas zu vereinfachen, finden Sie hier die von mir aufbereitete Version des Skripts. Auf die vorgenommenen Änderungen werde ich weiter unten zurückkommen.

Speichern Sie auf dem Management System AZSHCIMGMT unserer Eval-Umgebung das Skript in einem Verzeichnis (z.B. C:/MSLab) und geben Sie der Datei den Namen Scenario.ps1. Öffnen Sie dann diese Datei in einer PowerShell ISE Sitzung mit erhöhten Ausführungsrechten (wichtig!).

Das Skript ist in mehrere PowerShell Regions gegliedert, so dass man sich rasch einen Überblick über die durchzuführenden Schritte verschaffen, aber auch jederzeit in die Tiefe bis auf einzelne Anweisungen herunterschalten kann.

Tipp: Klicken Sie auf diesen Screenshot. Dann sehen Sie in einem eigenen Tab das Skript als Text.

Tipps: Mit der Tastenkombination Strg + M können alle Regions gleichzeitig geöffnet bzw. geschlossen werden. Und durch einen Klick auf das „+“-Symbol am Anfang einer Zeile öffnen Sie die jeweilige Region.

Notwendige Anpassungen

Nachstehend will ich auf die erwähnten von mir durchgeführten Änderungen und Ergänzungen für unsere AzSHCI-Testumgebung etwas genauer eingehen.

Region LAB Config…

In diesem Bereich des Szenario-Skripts sollten alle LAB-spezifischen Parameter festgelegt werden wie z.B. Systemnamen und Netzwerkdaten. Das originale Skript wurde für eine Microsoft-spezifische Active Directory Domain erstellt. Deshalb müssen wir die Namen und IP-Angaben für unsere Testumgebung anpassen.

Die meisten Angaben in diesem Bereich sind uns bekannt aus der MSLab-Parameterdatei LabConfig.ps1 und müssen hier halt nochmals angegeben werden. Der Grund ist einfach: Das Szenario-Skript wurde unabhängig von MSLab entwickelt und ist auch für andere Umgebungen designed. 

Ein Eintrag, der im Original nicht vorhanden ist und von mir eingefügt wurde sind die Zeilen 13-14 im obigen Screenshot. Hier wird eine PowerShell Variable $corp definiert, die den NetBIOS-Namen unserer Azure Stack HCI Active Directory Umgebung enthält. Weiter unten im Skript beim Kreieren eines Fileshare Zeugen („Witness„) für unser Cluster (#region Create cluster and configure basic settings – Zeilen 597-598) tauchen dann hart codierte Strings mit AD-Namen für eine ‚corp‘-Domain auf, was natürlich für uns unsinnig ist und bei der Ausführung zu Fehlern führen würde.

Am einfachsten können wir dies umgehen, indem wir in den Strings auf unsere Variable $corp verweisen:

Statt eines lokalen Fileshare Zeugen kann das Skript auch einen Cloud Zeugen in einem Speicherkonto (Storage Account) der Public Azure Cloud erzeugen. Der gewünschte Typ des Zeugen wird in der Variablen $WitnessType festgelegt. Die für einen Cloud Zeugen notwendigen Angaben befinden sich dann anschließend in den Zeilen 31-37.

• $CloudWitnessEndpoint ist eine URL, unter der in Azure die für einen Cloud Zeugen notwendigen Verzeichnis- und Dateistrukturen erzeugt werden. Diese URL muss „core.windows.net“ lauten!
• $ResourceGroupName können Sie frei wählen. Den Namen finden Sie dann in Ihrer Azure Subsciption als Resource Gruppe.
• Für den $StorageAccountName müssen Sie die in Azure vorgegebenen Regeln beachten:
  • max. 24 Zeichen, nur Kleinbuchstaben und Ziffern
  • muss Azure-weit eindeutig sein; durch Anhängen einer möglichst großen Zufallszahl lässt sich das weitgehend sicherstellen.

Welchen Typ von Zeugen wir verwenden wollen / sollten, ist vom Cluster Szenario abhängig. Für unsere Eval Umgebung mit ausschließlich lokalen Cluster Knoten würde ein lokaler Fileshare Zeuge vollkommen genügen. Wenn man aber z.B. ein Stretch Cluster plant – also die Verteilung der Cluster Ressourcen auf verschiedene räumlich getrennte Standorte – benötigen wir einen Cluster Zeugen, der auch bei Ausfall eines Standortes immer erreichbar bleibt. Und da bietet es sich natürlich an, den Cluster Zeugen im Internet in der Public Azure Cloud anzulegen. 

Um zu zeigen, wie ein Cloud Zeuge mit PowerShell erzeugt werden kann, werde ich nachstehend aber trotzdem mit einem Cloud Zeugen arbeiten. Auf die Details werde ich später im Abschnitt Region Create cluster and configure basic settings noch eingehen.

Viele der weiteren Parameter in dieser Region sind (zumindest für Cluster Experten) selbsterklärend und beziehen sich oftmals auch auf physische Produktivumgebungen, so dass sie für unsere Testumgebung ohne Bedeutung sind. Sie sollten sie deshalb nicht ändern.

Region Install features for management…

In dieser Region werden Verwaltungstools installiert, die für die Remoteverwaltung von Azure Stack HCI und seiner Infrastruktur mit PowerShell oder herkömmlichen Tools (wie mmc) erforderlich sind. Es werden unterschiedliche Funktionen installiert, je nachdem, von wo aus Sie das Skript ausführen (Server/ServerCore/Windows 10). Für unsere Eval-Umgebund sind hier keine Änderungen notwendig.

Region Install Edge and Windows Admin Center Gateway…

Diese Region steht im Original-Skript eigentlich ganz am Ende. Ich halte es aber für sinnvoll, gleich hier die aktuelle Version des Edge Browsers zu installieren. Bei unserem Managementsystem handelt es sich ja um eine Windows Server 2016 bzw. 2019 Version, in der standardmäßig nur der „gute alte“ Internet Explorer verfügbar ist. Ein Update ist also auf jeden Fall notwendig.

Und das Windows Admin Center (WAC) würde ich hier auch gleich installieren. Dann haben wir die Möglichkeit, die Auswirkungen der einzelnen Schritte des Skripts interaktiv mit zu verfolgen.

Region Prepare for Azure Connections…

Bei einigen späteren Schritten im Skript müssen wir eine Verbindung zur Public Azure Cloud herstellen – z.B. zum Erzeugen eines Cloud Zeugen und zum Registrieren des finalen Clusters. Um dies mit PowerShell durchführen zu können, benötigen wir auf unserem Managementsystem einige zusätzliche PowerShell Module, die in dieser Region heruntergeladen und installiert werden.

Um später Funktionen in der Public Azure Cloud ausführen zu können, müssen wir uns dort mit unserem Managementsystem als Gerät anmelden und festlegen, mit welcher Azure Subscription („Abo„) wir arbeiten wollen, falls wir mehrere zur Verfügung haben.

Für die Anmeldung wird in unserem Szenario Skript das CmdLet Connect-AzAccount mit dem Parameter -UseDeviceAuthentication aufgerufen.

Das CmdLet gibt die im vorstehenden Screenshot orange dargestellten Zeile aus und wartet dann auf den interaktiven Abschluss der angezeigten Aktionen. 

Auf einer neuen Seite sehen Sie nun eine Liste der auf Ihrem Gerät aktuell verfügbaren Azure Accounts für die Anmeldung.

Wählen Sie den gewünschten Azure Account aus und klicken Sie dann auf Next.

Öffnen Sie jetzt in Ihrem Browser ein neues Fenster bzw. einen neuen Tab und übernehmen Sie in die Adresszeile die angegebene URL https://microsoft.com/devicelogin. Geben Sie dort den vom PowerShell Skript angezeigten Code ein und klicken Sie dann auf Next.

Sie erhalten jetzt eine Bestätigung über die erfolgreiche Anmeldung bei der PowerShell in Azure.

Das Browser-Fenster können Sie jetzt wieder schließen.

Wenn Ihr Microsoft Account mehrere Azure Subscriptions enthält, müssen Sie jetzt festlegen, mit welcher Subscription im Skript weitergearbeitet werden soll. In diesem Fall zeigt das Skript in einer Liste die verfügbaren Subscriptions an, wovon Sie eine auswählen müssen.

Die ausgewählte Subscription wird nach einem Klick auf OK in die interne Datenbasis der Az.* Module übernommen und gilt auf dem Gerät für alle nachfolgenden PowerShell Aufrufe an die Public Azure  Cloud.

Region Update all Servers…

In dieser Region wird sichergestellt, dass auf allen Azure Stack HCI Servern unserer Testumgebung die aktuellsten Updates vorhanden sind. Bei Bedarf werden sie nachinstalliert. Für unsere Evalumgebung sollte dies eigentlich sehr schnell erledigt sein, wenn wir beim Erzeugen der .VHDX-Images bereits die aktuellen Updates offline eingespielt haben (siehe Abschnitt Master Images für die LAB-VMs erzeugen)

Region Configure Basic Settings on Servers…

Diese Region zeigt alle Einstellungen, die Sie bei der Bereitstellung von Azure Stack HCI berücksichtigen sollten (z. B. Memory Dump-Einstellungen, Meltdown-Spectre-Mitigationen, Rolleninstallation…). Auch hier kann das Ganze beschleunigt werden, wenn wir beim Erzeugen der .VHDX-Images die benötigten Windows Features bereit offline aktiviert haben gemäß den Tipps im Abschnitt Aktivieren von Windows Features in den VHDX-Dateien weiter oben.

Region Configure Networking…

Das Skript erstellt ein Converged Setup. Es wird davon ausgegangen, dass die HCI-Server über 2 physische Netzwerkkarten (pNICs) verfügen, die mit einem Netzwerk verbunden sind. Hierzu wird dann ein virtueller Switch (vSwitch) erstellt und die pNICs mit dem in der Region Lab Config konfigurierten IP-Adresspräfix verbunden. Außerdem werden vNICs erstellt, JumboFrames konfiguriert und die Zuordnung von pNICs zu vNICs demonstriert.

Region Create Cluster and Configure Basic Settings…

In dieser Region wird zunächst getestet, ob die Cluster-Fähigkeit unserer Server für die HCI-Knoten erfüllt ist. Anschließend wird das Cluster gemäß den Angaben in der Region Lab Config erzeugt und der Cluster Zeuge (Witness) angelegt. 

Das Skript ermöglicht 2 verschiedene Typen von Cluster Zeugen: In  einem Fileshare eines lokalen Servers oder in einem Speicherkonto (Storage Account) in der Public Azure Cloud. Für unsere hier mit  MSLab erstellte Testumgebung mit 2 Cluster Knoten würde ein lokaler Fileshare Zeuge genügen. Ich will hier aber trotzdem die Schritte aufzeigen, die notwendig sind, um einen Cloud Zeugen zu generieren.

Anmerkung: Für die nachstehenden Aktionen müssen Sie bereits bei der PowerShell in der Azure Cloud angemeldet sein. Details dazu finden Sie weiter oben in der Region Prepare for Azure Connections and login

Für einen Cloud Zeugen müssen wir mit Funktionen aus den Az.* Modulen ein Speicherkonto (Storage Account) in der Public Azure Cloud anlegen. Ein solches Speicherkonto ist letztlich ein Bereich auf einem Speichermedium in der Azure Cloud, also eine AzureResource. Azure Resources müssen in Resource Groups zusammengefasst und diese dann in einer Azure Lokation – einem Standort eines Azure Rechenzentrums, in dem die gewünschten Resourcen verfügbar sind – erzeugt werden (Anm.: Nicht in allen Azure Lokationen stehen alle Resourcetypen zur Verfügung, wie wir später noch bei der Registrierung unseres Clusters sehen werden).

Zunächst müssen wir eine Azure Lokation festlegen, in der wir das Speicherkonto anlegen wollen. In einer Liste werden uns alle Azure Lokationen angezeigt, in der Speicherkonten möglich sind:

Im vorstehenden Beispiel habe ich West Europa ausgewählt. In der gewählten Lokation müssen wir jetzt eine Resource Group erzeugen, wozu das CmdLet New-AzResourceGroup dient. 

Darin können wir nun mit New-AzStorageAccount unser Speicherkonto anlegen. Bitte beachten Sie die Vorgaben für den Namen eines Speicherkontos (nur Kleinbuchstaben und Ziffern, max.24 Zeichen und Azure weit eindeutig).

Als letzten Schritt zum Anlegen eines Cloud Zeugen müssen wir nun noch mit dem CmdLet Set-ClusterQuorum unserem lokalen HCI-Cluster das erzeugten Speicherkonto zuordnen.

Region Configure Cluster Networks…

In dieser Skript Region werden die Clusternetzwerke umbenannt und es wird die Livemigration so konfiguriert, dass dabei das Managementnetzwerk nicht verwendet wird.

Region Configure Cluster-Aware-Updating…

In dieser Skript Region wird gezeigt, wie Sie CAU (Cluster Aware Updating) konfigurieren können. Im Beispiel sollen Updates für unser HCI-Cluster jeden dritten Mittwoch automatisch bereitgestellt werden.

Region Configure Fault Domains…

In dieser Region wird veranschaulicht, wie Fault Domains konfiguriert werden können. Für unsere Evaluierungsumgebung mit 2 Cluster Knoten ist das ohne Bedeutung. Es zeigt jedoch Ideen auf, wie Sie dieses sehr komplexe Thema behandeln können. 

Region Enable Cluster S2D and check Pools and Tiers…

In dieser Skript Region wird Storage Spaces Direct (S2D) mit dem PowerShell CmdLet Enable-ClusterS2D im Verbose Mode aktiviert und dann ein ausführliches Protokoll angezeigt, welche physischen Laufwerke der Cluster Knoten als Cache und welche für die Langzeitspeicherung eingerichtet werden. 

In unserer Eval-Umgebung arbeiten wir mit virtuellen Laufwerken (.VHDX-Dateien). Diese werden von Enable-ClusterS2D grundsätzlich als Festplattenlaufwerke (HDDs – Hard Disk Drives) erkannt und damit zur Langzeitspeicherung verwendet. In unserer S2D-Umgebung wird also kein Cache vorhanden sein. Auf die Funktionalität hat dies aber keinen Einfluss.

Region Create Volumes to use max Capacity…

In dieser Skript Region wird im S2D Storage pro Cluster Knoten je 1 Volume mit jeweils maximaler Kapazität generiert. Das ist natürlich nur als Beispiel gedacht. In „echten“ Umgebungen können sie selbstverständlich Speicherbereiche entsprechend Ihren eigenen Anforderungen einrichten.

Region Register Azure Stack HCI to Azure…

Alle bisherigen Konfigurationsschritte unserer Azure Stack HCI Testumgebung konnten wir ohne eine Verbindung zur Microsoft Public Azure Cloud ausführen (Ausnahme: Sie haben einen Cloud Cluster Zeugen angelegt).

Um jetzt mit dem betriebsbereiten Azure Stack HCI Cluster arbeiten zu können (z.B. virtuelle Maschinen anzulegen), ist eine Registrierung zwingend erforderlich. 

Dazu müssen wir uns in der Public Azure Cloud anmelden und eine Subscription auswählen (sofern mehrere verfügbar sind). Wie das geht, wird in der Region Prepare for Azure Connections and login gezeigt.

Für das Registrieren unseres Azure Stack HCI Clusters benötigen wir folgende Parameter: 

SubscriptionID: Die ID der beim Login ausgewählten Azure Subscription – intern in den *.Az Modulen gespeichert; kann mit Get-AzContext abgerufen werden.

Region: Die Azure Lokation, in der das Cluster registriert werden soll. Das Skript zeigt dazu eine Liste der Azure Lokationen an, in denen eine Registrierung möglich ist. Anmerkung: (Noch) nicht alle Azure Lokationen unterstützen dies!

Computername: Der Name unseres Clusters – im Skript in der Variablen $ClusterName.

Die Registrierung geschieht dann mit dem CmdLet Register-AzStackHCI aus den Az.* Modulen.

Der Registrierungsvorgang kann einige Minuten dauern. Außerdem kann es passieren, dass Sie sich dabei mit Ihrer PowerShell Sitzung nochmals bei der Public Azure Cloud anmelden müssen in der weiter oben beim Cloud Zeugen bereits beschriebenen Art und Weise.

Wurde der Registrierungsvorgang erfolgreich durchgeführt, gibt Register-AzStackHCI eine ganze Menge an Informationen in der Konsole aus, die viele geschäftskritische Daten enthalten (z.B. die Subscription ID oder die URLs zu diversen Cluster Ressourcen).

Region Unregister AZSHCI from Azure and Cleanup…

In diesem Blog-Artikel befassen wir uns mit der Evaluierung der Azure Stack HCI Betriebssystemumgebung. Und bei solchen Projekten kann es immer wieder mal vorkommen, alles wieder auf den Anfang zurückzusetzen. Prinzipiell kann das in unserer mit MSLab erstellten Umgebung mit dem Skript Cleanup.ps1 geschehen. 

Falls Sie Ihr HCI-Projekt bis hierher erfolgreich erstellt und in der Public Azure Cloud registriert haben, sollten Sie unbedingt vor dem Löschen der lokalen VMs auch alle Ressourcen in der Azure Cloud wieder freigeben und insbesondere die Registrierung des HCI-Clusters aufheben, um keine Kosten für nicht mehr benötigte bzw. nicht mehr vorhandene Cloud Ressourcen zu verursachen.

Die für die Aufhebung einer HCI-Registrierung durchzuführenden Schritte werden in dieser Skript Region aufgezeigt:

Analog zum Registrieren eines HCI-Clusters müssen wir uns auch hier in der Public Azure Cloud anmelden und eine Subscription auswählen (sofern mehrere verfügbar sind). Wie das geht, wird weiter oben in der Region Prepare for Azure Connections and login gezeigt.

Für die Aufhebung der Registrierung steht dann das CmdLet UnRegister-AzStackHCI zur Verfügung. Es benötigt folgende Parameter:

SubscriptionID: Die ID der beim Login ausgewählten Azure Subscription – intern in den *.Az Modulen gespeichert; kann mit Get-AzContext abgerufen werden.

Computername: Der Name unseres Clusters – im Skript in der Variablen $ClusterName.

Vergessen dürfen wir jetzt auch nicht die Freigabe der weiteren Azure Ressourcen wie z.B. der AzResourceGroup, in der das HCI-Cluster enthalten war.

Region Create some VMs…

Der Code in dieser Skript Region ist als Beispiel gedacht, wie Sie virtuelle Maschinen (VMs) in einem HCI-Cluster als Cluster Rolle in unserem S2D-Storage erzeugen können. Sie haben die Möglichkeit, „echte“ VMs zu erzeugen (also solche mit einem Betriebssystem zum Booten) oder „Fake VMs“ (d.h. mit einer leeren Boot VHDX-Datei).

Welche VM-Typen erzeugt werden, können Sie in der ersten Skript Region Lab Config über die Variable $realVMs festlegen. Bei einem Wert $true werden „echte“ VMs erzeugt und das Skript fragt nach dem Pfadnamen einer bootfähigen VHDX-Datei, von der dann jeweils eine Kopie als Startlaufwerk verwendet wird. 

Nächste Schritte

Wenn Sie bis hierhin unsere Azure Stack HCI Testumgebung konfiguriert haben, stellt sich die Frage, was Sie nun mit dieser Infrastruktur „anstellen“ können. Auf detaillierte Beschreibungen will ich dabei verzichten. Dieser Blogartikel ist eh schon sehr umfangreich und weitere Evaluierungsprojekte sind es wert, in eigenen Artikeln genauer beleuchtet zu werden.

Deshalb hier nur ein paar Tipps zu weiterführenden Themen.

Evaluierung mit dem Windows Admin Center

Die Installation und Konfiguration unserer Azure Stack HCI Umgebung haben wir bisher ausschließlich mit PowerShell durchgeführt. Ich halte dies bei einer Erstinstallation für eine hervorragende Vorgehensweise, da man hinterher anhand der ausgeführten PowerShell Skripte jederzeit die durchgeführten Schritte nachvollziehen kann.

Für die tägliche Administration und Überwachung eines HCI-Clusters ist die PowerShell jedoch nicht immer unbedingt die erste Wahl. Für diese Tätigkeiten empfehle ich Ihnen, sich intensiv mit dem Windows Admin Center (WAC) auseinander zu setzen. Wir haben das WAC bei der Installation unserer Testumgebung bereits auf unserem Management System installiert. Als erstes sollten Sie sich mit dem Cluster-Manager im WAC vertraut machen. Mit dessen Funktionen können Sie praktisch alle Verwaltungsaufgaben eines Clusters erledigen und auch die Integration von Überwachungs-  und Diagnosetools aus der Public Azure Cloud konfigurieren.

Außerdem sollten Sie auch einen Blick in die umfangreiche Liste an 3rd Party Erweiterungen werfen, wo Sie viele Windows- und Hersteller- spezifische Verwaltungswerkzeuge finden, z.B. für Active Directory, DNS oder Storage Systeme.

Weitere MSLab-Szenarien

Im Zuge dieses Blogartikels haben wir ein sehr einfaches Azure Stack HCI Einstiegsszenario erstellt. Wenn Sie weiterführende Szenarien probieren wollen, sollten Sie im MSLab Projekt das Scenarios Verzeichnis unter die Lupe nehmen. Dort finden Sie Skripte und Beschreibungen z.B. für Stretched Cluster oder die Integration von Kubernetes in ein Azure Stack HCI Cluster.

Das Azure Stack HCI Preview Programm

Wenn dieser Artikel Ihr Interesse an der Azure Stack HCI Technologie geweckt hat und Sie zukünftige Weiterentwicklungen mit verfolgen und noch vor einer offiziellen Freigabe testen wollen, empfehle ich Ihnen, Ihre Testumgebung für das Azure Stack HCI Preview Programm zu registrieren. Dies können Sie entweder im Windows Admin Center über die Einstellungen im Cluster Manager Ihres Azure Stack HCI Clusters oder auch mit PowerShell CmdLets durchführen.

Details für die Registrierung Ihres Azure Stack HCI Clusters im Preview Programm finden Sie in der Microsoft Dokumentation unter Beitreten zum Azure Stack HCI-Previewkanal (deutsch) bzw. Join the Azure Stack HCI preview channel (englisch).

Azure Stack HCI Cluster erhalten über den Windows Update jeweils die neuesten Preview Versionen. Für die Preview Cluster Knoten fallen keine Kosten in der Public Azure Cloud an, also insbesondere nicht die Pro Core Belastung Ihrer Azure Subscription. 

Warnung:

Verwenden Sie keine Preview Versionen in produktiven Umgebungen. Preview Versionen enthalten experimentelle Vorabversionssoftware, die nur zum Auswerten und Testen zur Verfügung gestellt wird. Es kann möglicherweise zu Abstürzen, Sicherheitsrisiken oder Datenverlusten kommen. Stellen Sie sicher, dass Sie alle wichtigen virtuellen Computer (VMs) sichern, bevor Sie ein Update Ihres Clusters auf eine Preview Version ausführen. Nachdem Sie eine Version aus dem Preview Kanal installiert haben, besteht die einzige Möglichkeit, zurück zu wechseln, in einer sauberen Neuinstallation der ursprünglichen Release Version.

Wie Sie sehen, wird die Azure Stack HCI Plattform stetig weiter entwickelt werden. Wenn eine solche Cloud-orientierte Systemumgebung und deren Weiterentwicklung für Sie von Bedeutung ist, dann können Sie mit den in diesem Artikel beschriebenen MSLab Projekt und passenden Szenario-Skripten immer wieder relativ schnell und einfach weitere Evaluierungsprojekte durchführen.

Und falls Sie weitere Fragen haben oder Unterstützung benötigen, steht Ihnen die Rachfahl IT-Solutions GmbH & Co.KG gerne zur Verfügung.