• ​01 Azure Stack HCI Stretched Cluster Series – Introduction – Dauer: 55:30 
• 02 Azure Stack HCI – Stretched Cluster Series – Networking Overview – Dauer: 25:31
• ​03 Azure Stack HCI Stretched Cluster Series – Management Network – Dauer: ​16:16
• ​04 Azure Stack HCI Stretched Cluster Series – Compute Network – Dauer: ​11:09
• ​05 Azure Stack HCI Stretched Cluster Series – Storage Network – Dauer: ​13:31
• ​06 Azure Stack HCI Stretched Cluster Series – Replica Network – Dauer: ​05:45
• ​07 Azure Stack HCI Stretched Cluster Series – Additional Cluster Networks – Dauer: ​07:43
• ​08 Azure Stack HCI Stretched Cluster Series – Routing A Stretched Cluster – Dauer: ​27:38
• ​09 Azure Stack HCI Stretched Cluster Series – Switches In A Stretched Cluster – Dauer: ​19:35
• ​10 Azure Stack HCI Stretched Cluster Series – Creating A Stretched Cluster With Fault Domains – Dauer: ​10:07
• ​11 Azure Stack HCI Stretched Cluster Series – Cluster Housekeeping – Dauer: 25:31
• ​12 Azure Stack HCI Stretched Cluster Series – Enabling Storage (Enable-ClusterStorageSpacesDirect) – Dauer: ​12:17
• ​13 Azure Stack HCI Stretched Cluster Series – Creating stretched- and non-stretched Volumes – Dauer: 34:39
• ​​14 Azure Stack HCI Stretched Cluster Series – Benchmarking A Single Stretched Volume (iometer VM) – Dauer: ​18:56
• ​​15 Azure Stack HCI Stretched Cluster Series – Benchmarking The Whole Stretched Cluster (vmfleet) – Dauer: ​28:05
• ​​16 Azure Stack HCI Stretched Cluster Series – Resilience Testing – Planned Maintenance – Dauer: ​1:00:19
• ​​17 Azure Stack HCI Stretched Cluster Series – Resilience Testing – Desaster & Closing – Dauer: ​54:41

Habt ihr Fragen oder Probleme rund um die Themen Hyper-V, Failover Cluster, Storage Spaces Direct und Azure Stack HCI, so könnt ihr euch gerne an uns wenden. Wir bereaten und unterstützen euch gerne bei Sizing- und Hardwarefragen und im Anschluss bei der Implementierung eurer Projekte. Wir verkaufen selbst keine Hardware, daher können wir euch ehrlich und aus der Erfahrung vieler Installationen im Hyper-V Umfeld sagen, was ihr beim Hardwarekauf beachten müsst. Habt ihr Interesse euer Wissen zu vertiefen oder aufzufrischen, kann ich euch ​die Powerkurse von Carsten ans Herz legen.

Weiterhin viel Erfolg

Ich habe euch die Videos hier zusammen gestellt und kann euch jetzt nur noch viel Spaß beim schauen und lernen wünschen.

• 01 – SOFS on S2D in VMs – Installation requirements – Dauer: 17:59
• 02 – SOFS on S2D in VMs – Adding Cluster SOFS Role – Dauer: 28:57
• 01 Azure Virtual Desktop on Azure Stack HCI Series – Introduction – Dauer: 19:32
• 02 Azure Virtual Desktop on Azure Stack HCI Series – Downloading an Marketplace Image Manually – Dauer: 22:58
• 03 Azure Virtual Desktop on Azure Stack HCI Series – Optimizing the Downloaded Image – Dauer: 07:06
• 04 Azure Virtual Desktop on Azure Stack HCI Series – Customizing The OS or creating a Golden Image – Dauer: 36:55
• 05 Azure Virtual Desktop on Azure Stack HCI Series – FSLogix Permissions on a Central Profile Share – Dauer: 10:02
• 06 Azure Virtual Desktop on Azure Stack HCI Series – Create A Group Policy (GPO) For FSLogix – Dauer: 12:04
• 07 Azure Virtual Desktop on Azure Stack HCI Series – Creating A Hostpool – Dauer: 11:13
• 08 Azure Virtual Desktop on Azure Stack HCI Series – Creating an AVD Application Group – Dauer: 02:15
• 09 Azure Virtual Desktop on Azure Stack HCI Series – Creating An AVD Workspace – Dauer: 04:19
• 10 Azure Virtual Desktop on Azure Stack HCI Series – Preparing A VM On HCI For AVD Using Our Image – Dauer: 12:00
• 11 Azure Virtual Desktop on Azure Stack HCI Series – Deploy AVD Agents In The AVD VM (manual) – Dauer: 09:56
• 12 Azure Virtual Desktop on Azure Stack HCI Series – Connecting to an HCI hosted AVD Desktop – Dauer: 17:48
• 13 Azure Virtual Desktop on Azure Stack HCI Series – Creating Remote App Group and Update Client – Dauer: 20:40
• 14 Azure Virtual Desktop on Azure Stack HCI Series – An Administrator’s View On FSLogix – Dauer: 11:17
• 15 Azure Virtual Desktop on Azure Stack HCI Series – Adding GPUs To Your AVD Workload (extended) – Dauer: 22:52
• 16 Azure Virtual Desktop on Azure Stack HCI Series – Experiencing vGPU Performance on HCI (extended) – Dauer: 09:44

Habt ihr Fragen oder Probleme rund um die Themen Hyper-V, Failover Cluster, Storage Spaces Direct und Azure Stack HCI, so könnt ihr euch gerne an uns wenden. Wir bereaten und unterstützen euch gerne bei Sizing- und Hardwarefragen und im Anschluss bei der Implementierung eurer Projekte. Wir verkaufen selbst keine Hardware, daher können wir euch ehrlich und aus der Erfahrung vieler Installationen im Hyper-V Umfeld sagen, was ihr beim Hardwarekauf beachten müsst. Habt ihr Interesse euer Wissen zu vertiefen oder aufzufrischen, kann ich euch nur die Powerkurse von Carsten ans Herz legen.

Weiterhin viel Erfolg

Im Anschluss die Links zu den einzelnen Videos. Viel Spaß beim Anschauen.

• 01 Azure Stack HCI Installation series – Introduction – Dauer: 22:21 
• 02 Azure Stack HCI Installation Series – OS Installation – Dauer 08:42
• 03 Azure Stack HCI Installation Series – Driver Installation – Dauer: 10:42
• 04 Azure Stack HCI Installation Series – Feature Installation – Dauer: 04:14
• 05 Azure Stack HCI Installation Series – Management Network – Dauer: 08:39
• 06 Azure Stack HCI Installation Series – Housekeeping – Dauer: 02:45 
• 07 Azure Stack HCI Instalation Series – Updates – Dauer: 11:53
• 08 Azure Stack HCI Installation Series – VM Network – Dauer: 04:38 
• 09 Azure Stack HCI Installation Series – SMB Networks – Dauer: 29:47
• 10 Azure Stack HCI Installation Series – Test RDMA – Dauer: 06:41
• 11 Azure Stack HCI Installation Series – RDMA Test with BigVM – Dauer: 18:30
• 12 Azure Stack HCI Installation Series – Mellanox RDMA (optional Video) – Dauer: 09:12
• 13 Azure Stack HCI Installation Series – Cluster Validation – Dauer: 16:47
• 14 Azure Stack HCI Installation Series – Cluster Creation – Dauer: 18:30
• 15 Azure Stack HCI Installation Series – Cluster Housekeeping – Dauer: 16:37
• 16 Azure Stack HCI Installation Series – S2D Enablement – Dauer: 13:01
• 17 Azure Stack HCI Installation Series – Cluster Housekeeping II Registration and Settings – Dauer: 31:03
• 18 Azure Stack HCI Installation Series – Creating Volumes- Dauer: 32:32
• 19 Azure Stack HCI Installation Service – Storage Benchmark with IOmeter In Windows VM – Dauer: 28:20
• 20 Azure Stack HCI Installation Series – Benchmark A Linux VM Using FIO – Dauer: 10:31
• 21 Azure Stack HCI Installation Series – Storage Benchmark VMFleet Installation – Dauer: 26:28
• 22 Azure Stack HCI Storage Benchmark VMFleet Measurement – Dauer: 49:17
• 23 Azure Stack HCI Installation Series – Updating Using WAC And CAU – Dauer: 29:35

… so, jetzt ist die Video Serie komplett online, ich wünsche euch viel Spaß beim Schauen, es gibt sicherlich viele Tipps und Infos die euch bei einer Azure Stack HCI Installation ​unterstützen. 

Habt ihr Fragen oder Probleme rund um die Themen Hyper-V, Failover Cluster, Storage Spaces Direct und Azure Stack HCI, so könnt ihr euch gerne an uns wenden. Wir bereaten und unterstützen euch gerne bei Sizing- und Hardwarefragen und im Anschluss bei der Implementierung eurer Projekte. Wir verkaufen selbst keine Hardware, daher können wir euch ehrlich und aus der Erfahrung vieler Installationen im Hyper-V Umfeld sagen, was ihr beim Hardwarekauf beachten müsst. Habt ihr Interesse euer Wissen zu vertiefen oder aufzufrischen, kann ich euch nur die Powerkurse von Carsten ans Herz legen.

Weiterhin viel Erfolg

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:

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.

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:

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.

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: 

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:

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.

Here are some of the highlights:

• 2 days of sessions
• 22 technical sessions
• 30 speakers, alone 19 from Microsoft and 8 Microsoft MVPs
• all sessions are live
• Q&A after the sessions

We have nearly every topic covert. There is an Azure Stack HCI Roadmap session, multiple best practice sessions about sizing Azure Stack HCI and building a Stretched Cluster, three Networking sessions (SMB over QUIC, Network ATC and News from SDN), Configuring Azure Stack HCI with WAC, exploring new features with MSLAB and storage features like thin provisioning, security improvements with Secure Core, What’s coming with GPU support, performance testing with the new VMFleet, Azure ARC and Azure Kubernetes Services and even a Session about Windows Server 2022.

And last but not least, we have three unique technical sessions from our sponsors Dell, Fujitsu, and Lenovo, about how their products fit into all of this.

If you want to know more look into the a session description in the online schedule.

If you don’t want to miss this great free event, sign-up today and you will also be informed when the recordings are available!

Unsere Kunden berichteten von abgestürzen VMs und einem nicht mehr zu administrierenden Storage Spaces Direct Cluster. Die Problematik wird mit jedem Clusterknoten der gepatcht wurde schlimmer, die Repairjobs laufen oft stunden bis tagelang.  Am Ende hilft meist nur das Herunterfahren der VMs, damit der Cluster seine Repairjobs abarbeiten kann und sich das Ganze wieder etwas beruhigt. Nachdem alle Storagejobs abgearbeitet wurden, läuft der Storage Spaces Cluster wieder normal und performant.

In machen Fällen hat es etwas gebracht, wenn der Clusterdienst vor dem Neustart der Knoten auf „disabled“ gesetzt wurde und nachdem der Knoten das Update verarbeitet hatte und wieder zur Anmeldung bereit steht, kann der Clusterdienst wieder auf „automatisch“ gestetzt und gestartet werden.

Sobald wir neue Erkenntisse zu der Problematik haben, werde ich euch diese an dieser Stelle mitteilen.

Weiterhin viel Erfolg

​

• Cluster Installation
• Azure Registrerung
• Fast Repair
• Azure Kubernetes Services
• …
• – Q & A

Ich hoffe ihr lernt sovieles Neues, wie ich bei der Vorbereitung gelernt habe ;-)

P.S.: Wenn ihr keine Zeit habt meldet euch trotzdem an, dann bekommt Ihr einen Link zur Aufzeichnung.

Ich kann es imernoch nicht glauben! Am 18. November verastalten wir den ersten Azure Stack HCI Day. Schaut euch nur die Agenda an! 11 von 12 Sprechern sind aus der Microsoft Produktgruppe in Redmond. Da ist überhaupt kein Platz für MVPs mehr. Crasy!

Wenn euch das neue Hyper-Converged Betriebsystem Azure Stack HCI intersiert oder die Neuerungen in Hyper-V oder Stretched Cluster usv. dann ist das Event für euch ein muß.

Hier ein paar Schlagworte aus dem Inhalt:

Hybrid build-in, AKS, ARC-enabled, Data Services, Easy Deployment, Hyper-V news, Lenovo, Network ATC, SDN, Performance Benchmarking, Streched Cluster, Modernizing, Azure Stack HCI

Klingt spannend? Dann meldet euch direkt auf der Azure Stack HCI Day Website zum Event an. Ich kann versprechen das ihr es nicht bereuen werdet !

Carsten

P.S.: Auch wenn Ihr keine Zeit habt live dabei zu sein, meldet euch bitte trotzdem an. Ihr bekommt dann, sobald die Aufzeichnung verfügbar ist, den Link dazu automatisch zugeschickt.

Update: Aufzeichnung des Events ist jetzt verfügbar!

I still can’t believe it! On November 18th we will host the first Azure Stack HCI Day. Just look at the agenda! 11 of 12 speakers are from the Microsoft product group in Redmond. There is no room at all for MVPs. Crasy!If you are interested in the new Hyper-Converged operating system Azure Stack HCI or the new features in Hyper-V or Stretched Cluster etc. then this event is a must for you.Here are a few keywords from the content:Hybrid build-in, AKS, ARC-enabled, Data Services, Easy Deployment, Hyper-V news, Lenovo, Network ATC, SDN, Performance Benchmarking, Streched Cluster, Modernizing, Azure Stack HCI

Sounds exciting? Then sign up for the Azure Stack HCI Day because I can promise it will be interesting.

Carsten

P.S.: Even if you do not have time to attend live, please register anyway. As soon as the recording is available, you will receive the link automatically.

Update: Recording of the hole event is now available!

Live migration of <VMName> failed.

Virtual machine migration operation for <VMName> failed at migration destination <ServerName>. (Virtual machine ID <GuidIDderVM>.

The virtual machine <VMName> is unsing processor-specific features not supported on physical computer <ServerName>. To allow for migration of this virtual machine to physical computers with different processors. modify the virtual machine settings to limit the processor features used by the virtual machine. (Virtual machine ID <GuidIDderVM>

hier noch die deutsche Fehlermeldung:

Fehler bei der Livemigration von  <VMName>.

Fehler beim Migrationsvorgang für den virtuellen Computer <VMName> am Migrationsziel  <ServerName>. (ID des virtuellen Computers: <GuidIDderVM>)

Für den virtuellen Computer <VMName> werden prozessorspezifische Features verwendet, die auf dem physikalischen Computer <ServerName> nicht unterstützt werden. Ändern Sie die Einstellungen des virtuellen Computers, um die vom virtuellen Computer verwendeten Prozessorfeatures zu beschränken, wenn Sie die Migration des virtuellen Computers zu physikalischen Computern mit anderen Prozessoren zulassen möchten. (ID des virtuellen Computers: <GuidIDderVM>)

Was ist die Ursache dieser Fehlermeldung?

Warum schlägt die Live Migration fehl, obwohl alle Server im Cluster die gleiche CPU haben und auch alle Server den gleichen Patchstand – ihr erinnert euch, dies war die Ursache bei meinem ersten Blogbeitrag zu diesem Fehler.

Ein Blogbeitrag von Eric Siron brachte mich ganz schnell auf die Fehlerursache. An dieser Stelle ein herzliches Dankeschön an Eric Siron für diesen tollen und ausführlichen Blogbeitrag. Ich möchte euch an dieser Stelle nur die Lösungsmöglichkeit beschreiben. Wer nähere Infos nachlesen möchte über das weshalb und warum, findet die Infos in dem oben verlinkten Blogbeitrag von Eric Sirion.

Mit dem Befehl

gwmi win32_bios

ausgeführt in einem administrativen CMD Fenster,  konnte ich feststellen, dass zwei der Kundenserver aus dem vier Knotencluster eine ältere Bios Version aufwiesen, als die Beiden anderen.

Nachdem wir die Bios Versionen auf dem zwei betroffenen Servern upgedaten hatten,  konnten wir die VMs ohne Probleme zwischen den vier Knoten des Failover Clusters hin und her vrschieben.

Ich hoffe, ich konnte euch auch mit diesem kurzen Blogbeitrag helfen.

Bis Bald und viel Erfolg

Petra

Ich denke jeder IT-Pro hat sicherlich schon mal was von Kubernetes gehört. Viele bezeichnen sogar die Container als Virtualisierung 2.0. Und jetzt die Überaschung: auf der diesjährigen Ignite hat Microsoft Kubernetes für Azure Stack HCI vorgestellt und zwar als „echten“ Azure Service. Dabei wurden nicht nur die Azure Kubernetes Services (AKS) für Azure Stack HCI anouncet, nein es gibt auch schon einen Public Preview.

Deswegen freue ich mich riesig in diesem Webinar zwei bekante Microsoft Program Manager Ben Armstrong und Cosmos Darwin von der Microsoft Corp. zu Gast zu haben die im Webinar „Azure Kubernetes Services (AKS) on Azure Stack HCI 20H2 (in Englisch)“ vorstellen. 

Hier ein Auszug aus dem Inhalt:

• Container the new Virtual Machine
• What is Kubernetes and what is Azure Kubernetes Services?
• Installation of AKS on Azure Stack HCI
• Feature Demo
• – Q & A

Klingt spannend? Dann meldet euch zum Webinar an denn ich kann versprechen es wir super interessant.

Carsten

P.S.: Wenn Ihr keine Zeit habt meldet euch trotzdem an, Ihr bekommt dann den Link zur Aufzeichnung automatisch zugeschickt.

I think every IT-Pro has heard of Kubernetes. Many even call the containers Virtualization 2.0. And now the surprise: at this year’s Ignite conference Microsoft introduced Kubernetes for Azure Stack HCI as a „real“ Azure Service. Not only the Azure Kubernetes Services (AKS) for Azure Stack HCI were presented, but there is also a public preview.Therefore I am very pleased to have two well-known Microsoft Program Managers Ben Armstrong and Cosmos Darwin from Microsoft Corp. as guests. They will all „Azure Kubernetes Services (AKS) on Azure Stack HCI 20H2“ in this webinar.Heir is a glimpse of the agenda:

• Container the new Virtual Machine
• What is Kubernetes and what is Azure Kubernetes Services?
• Installation of AKS on Azure Stack HCI
• Feature Demo
• Q&A

Sounds exciting? Then sign up for the webinar because I can promise it will be interesting.

Carsten

P.S.: To sign-up click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar . If you sign-up you will get a link to the recording afterward.

Dieses Webinar plane ich schon seit dem ich von Azure Stack HCI 20H2 zum ersten mal gehört habe. Cosmos Darwin (Microsoft Senior Produktmanager in Redmond) und einer der Köpfe hinter Azure Stack HCI präsentiert live am Freitag den 21. August um 8 Uhr Morgens. Dieses Webinar ist ein Muss für alle die an der Zukunft der Microsoft „on-premises“ Welt interessiert sind. Am besten Ihr meldet euch sofort zum  „Azure Stack HCI 20H2 mit Cosmos Darwin (in Englisch)“ an. 

Hier ein Auszug aus dem Inhalt:

• – Core HCI stack
• – Delivered from Azure
• – Familiar for IT
• – Q & A

Klingt spannend? Dann meldet euch zum Webinar an denn ich kann versprechen es wir super interessant.

Carsten

P.S.: Wenn Ihr keine Zeit habt meldet euch trotzdem an, Ihr bekommt dann den Link zur Aufzeichnung automatisch zugeschickt.

Update: die Aufzeichnung ist jetzt online!

I have been planning this webinar since I first heard about the Azure Stack HCI 20H2. Cosmos Darwin, one of the brains behind Azure Stack HCI, will be presenting live on Friday August 21st at 8am CEST. This webinar is a must for all those interested in the future of the Microsoft „on-premises“ world. The best thing to do is to register immediately for the „Azure Stack HCI 20H2 with Cosmos Darwin„. Heir is a glimpse of the agenda:

• Core HCI stack
• Delivered from Azure
• Familiar for IT
• Q&A

Sounds exciting? Then sign up for the webinar because I can promise it will be interesting.

Carsten

P.S.: To sign-up click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar . If you sign-up you will get a link to the recording afterward.

Update: the recording is now online!

Am Donnerstag den 20. Dezember um 11 Uhr findet der zweite Teil des Webinars „Ignite 2019 Azure Stack HCI News – Part 2(in Deutsch)„ statt. In diesem Webinar schauen wir uns die Neuhigkeiten rund um Storage Spaces Direct die auf der Microsoft Ignite 2019 im November verkündet wurden.

Hier ein Auszug aus dem Inhalt:

• News zu Azure Stack HCI 
• Q&A

Klingt spannend? Dann meldet euch zum Webinar an denn ich kann versprechen es wir interessant.

Carsten

P.S.: Wenn Ihr keine Zeit habt meldet euch trotzdem an, Ihr bekommt dann den Link zur Aufzeichnung automatisch zugeschickt.

P.P.S.: Den ersten Teil findet ihr als Aufzeichung  im Webinar Archiv!

On the 20th of Dezember we will have the secound part of our „Webinar Ignite 2019 Azure Stack HCI News – Part 2 (in Englisch)“. In this Webinar I share the Microsoft Ignite 2019 News around Storage Spaces Direct from November. 

Here is a peek into the Agenda:

• S2D Tipps  Azure Stack HCI News
• Q&A

Carsten

P.S.: To sign-up click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar if you sign-up you will get a link to the recording afterward.

P.P.S.: You find the first part of the Webinar in our „Webinar archiv„!

Fehler bei der Livemigration von „Virtueller Computer „​XXX““.

Fehler beim Migrationsvorgang für den virtuellen Computer „​XXX“ am Migrationsziel „Node1“. (ID des virtuellen Computers: BA95E504-E33F-4EEB-94B0-B306A58B8D73)

Für den virtuellen Computer „dc3“ werden prozessorspezifische Features verwendet, die auf dem physikalischen Computer „Node1“ nicht unterstützt werden. Ändern Sie die Einstellungen des virtuellen Computers, um die vom virtuellen Computer verwendeten Prozessorfeatures zu beschränken, wenn Sie die Migration des virtuellen Computers zu physikalischen Computern mit anderen Prozessoren zulassen möchten. (ID des virtuellen Computers: „​BA95E504-E33F-4EEB-94B0-B306A58B8D73“)

Ergeignis ID 21502

Der Vorgang zum Verschieben von Clusterrolle „​XXX“ zum Ausgleichen konnte nicht abgeschlossen werden. Fehlercode: 0x80048016.

​Als ich den Fehler zum ersten Mal gesehen habe, war mein erster Gedanke, ich muss an der VM die CPU Kompatibilität aktivieren. Doch leider war dies nicht die Lösung. Trotz der aktivierten CPU Kompatibilität konnte die VM nicht verschoben werden. Auf der Suche nach einer Lösung ist ​mir folgendes aufgefallen.​

Am Freitag den 3. Mai 2020 um 15 Uhr findet unser kostenloses Webinar „Windows Virtual Desktop in Azure (in Deutsch)„ statt. In diesem Webinar habe ich meinen langjährigen Partner in Crime Bernhard Frank (Microsoft Cloud Solution Architect) zu Gast. Er wird mit uns sein Wissen zu „Windows Virtual Desktop“, den Shootingstar in Azure teilen.

Hier ein Auszug aus dem Inhalt:

• Überblick / Licensing & Kosten
• Architektur & Anforderungen
• Demo
• Partner Ökosystem
• – Spring Update & zukünftiges
• Q&A

Klingt spannend? Dann meldet euch zum Webinar an denn ich kann versprechen es wir interessant denn wie ich Bernhard kenne wirds bestimmt technisch!

Carsten

P.S.: Wenn Ihr keine Zeit habt meldet euch trotzdem an, Ihr bekommt dann den Link zur Aufzeichnung automatisch zugeschickt.

Ergänzung vom 4. 7. 2020: Mittlerweile ist auch die Aufzeichnung verfügbar. Viel Spass beim anschauen!

Am Montag den 15. Mai 2020 um 11 Uhr findet unser kostenloses Webinar „Create great test and demo Environments with WSLAB (in Englisch)“ statt. In diesem Webinar habe ich den Microsoft PFE Jaromir Kaspar zu gast. ER wird seine PowerShell Scriptumgebung WSLAB vorstellen und am Beispiel einiger Szenarien zeigen was man alles damit cooles zaubern kann.

Hier ein Auszug aus dem Inhalt:

• WSLAB what is it
• Demo, Demo, Demo
• Q&A

Klingt spannend? Dann meldet euch zum Webinar an denn ich kann versprechen es wir interessant denn als Jaromir mir WSLAB zum ersten mal gezeigt hat, war ich geradezu sprachlos!

Carsten

P.S.: Wenn Ihr keine Zeit habt meldet euch trotzdem an, Ihr bekommt dann den Link zur Aufzeichnung automatisch zugeschickt.

Mittlerweile ist auch die Aufzeichnung verfügbar

Our free webinar „Create great test and demo Environments with WSLAB“ will take place on Monday 15th of May 2020 at 11 am. In this Webinar, I have the Microsoft PFE Jaromir Kaspar as a guest. He will present his absolutely fantastic PowerShell script suite WSLAB and show us with the help of some scenarios what cool things can be created with it.

Here is a glimpse of the agenda:

• WSLab what is it?
• Demo of some scenarios
• Q&A

Don’t miss this because I’m sure you can learn a lot in this Webinar because when Jaromir showed WSLAB to me, I did, and I was amazed!

Sound great? Than sign-up for the free Webinar ! 

Carsten

P.S.: If you are not sure if you can make the Webinar live sign-up anyway because you will get a mail afterward with the recording.

Meanwhile the recording is availible

Am Dienstag den 9. Juni 2020 findet das ExpertsLive Cafe virtuell statt. Von 16 Uhr bis 19 Uhr präsentieren vier Microsoft Cloud & Datacenter MVPs zum Thema Azure Stack HCI.

Hier ein Blick in die Agenda:

Teams-Livestream 

Das ganze Event wird live in einem Teams-Livestream übertragen.

​

Update 17. Juni 2020: mitlerweile hat das Event statgefunden und ich möchte hier meinen Vortrag bereitstellen falls Ihn jemand schauen möchte.

Am Freitag den 29. Mai 2020 um 14 Uhr findet unser kostenloses Webinar ​„Sicherheit von Hyper-V VMs erhöhen (in Deutsch)“ statt. Jeder weiß, das Sicherheit heute wichtig ist auch Microsoft! Deswegen gibt es schon seit geraumer Zeit Möglichkeiten VMs in Hyper-V zu schützen. Wei erfahrt ihr in diesem Webinar

Hier ein Auszug aus dem Inhalt:

• Sicherheitsbeispiel virtuelle AD Controller
• der einfache weg: vTPM und Bitlocker
• der schwere Weg: Shielded VMs
• Q&A

Klingt spannend? Dann meldet euch zum Webinar an denn ich kann versprechen es wir interessant.

Carsten

P.S.: Wenn Ihr keine Zeit habt meldet euch trotzdem an, Ihr bekommt dann den Link zur Aufzeichnung automatisch zugeschickt.

Mittlerweile gibt’s auch die Aufzeichnung. 

Since we have two Azure Stack HCI clusters with TPM version 2 chip, I thought it would be a good idea to encrypt our domain controllers with Bitlocker. Under Hyper-V, it is straightforward to equip a VM with a vTPM chip. To do this, you only have to check the checkbox „Enable Trusted Platform Module“ in the settings of a Generation 2 VM (see screenshot).

If the TPM chip is available in the VM, you can now use it for BitLocker. The screenshot shows the TPM information on the left and the BitLocker status on the right.

So far, so good. However, there is a problem if you want to move the VM from one cluster node to another node via live migration. Here the live migration fails with the following error message:

Virtual machine migration operation for ‚vTPM2‘ failed at migration destination ‚TAROXS2D4‘. (Virtual machine ID 85D7A0BC-9979-4B64-A817-609B14278C67)The version of the device ‚Microsoft Virtual TPM Device‘ of the virtual machine ‚vTPM2‘ is not compatible with device on physical computer ‚TAROXS2D4‘. (Virtual machine ID 85D7A0BC-9979-4B64-A817-609B14278C67)The key protector for the virtual machine “ could not be unwrapped. HostGuardianService returned: One or more arguments are invalid (0x80070057) . Details are included in the HostGuardianService-Client event log. (Virtual machine ID )

In the error text, the „HostGuardianService“ is mentioned. Does this mean that we absolutely need it? Fortunately, the answer is no. Don’t get me wrong. Of course, for a secure environment, it is advisable to build the Hostguardian Service or better a cluster of Hostguardian Services, but it is also possible without it.However, we need two certificates per host that are imported on all live migration targets. How do we get these certificates? This is relatively simple.When a VM is created with a vTPM or a vTPM is activated on an existing VM, Hyper-V creates a „directory“ in the local „Certificate Store“ called „Shielded VM Local Certificates“. The two required certificates, each of which is valid for 10 years, are then created in this directory. They are called:

• „Shielded VM Encryption Certificate (UntrustedGuardian) (<Hostname>)“
• „Schielded VM Signing Certificate (UntrustedGuardian) (<Hostname>„

These certificates must be exported, including the private key, and then imported on each host where you want to move the VM. In a Cluster like a Storage Spaces Direct Cluster this is obviously every node.Since the certificates are only generated when a VM with vTPM is created, the procedure is as follows:

1. 1Create a VM with a TPM on each host or activate the TPM for a VM
2. 2Export certificates from any host including the private key
3. 3Import missing certificates on each host

After this is done, the „Certificate Store“ on each system should look like the screenshot.

Now you can move the VM to any node in the Hyper-V cluster.

I have created a video about this topic in which everything is explained again.

Have fun watching.

Da wir zwei Azure Stack HCI Cluster mit TPM Version 2 Chip haben, dachte ich mir, es ist doch einen gute Idee unsere Domain Controller mit Bitlocker zu verschlüsseln. Unter Hyper-V ist es kinderleicht eine VM mit einem vTPM Chip auszustatten. Hierzu muss man nur in den Eistellungen einer Generation 2 VM die Checkbox „Enable Trusted Platform Module“ anhaken (siehe Screenshot).

Wenn der TPM Chip in der VM verfügbar ist kann man nun dieses z.B. für BitLocker nutzen. Im Screenshot sieht man links die TPM Informationen und Rechts den BitLocker Status.

Soweit so gut. Allerdings gibt es ein Problem wenn man die VM per Livemigration von einem Clusterknoten auf einen anderen Knoten schieben möchte. Hier schlagt die Livemigration mit der folgenden Fehlermeldung fehl:

Virtual machine migration operation for ‚vTPM2‘ failed at migration destination ‚TAROXS2D4‘. (Virtual machine ID 85D7A0BC-9979-4B64-A817-609B14278C67)The version of the device ‚Microsoft Virtual TPM Device‘ of the virtual machine ‚vTPM2‘ is not compatible with device on physical computer ‚TAROXS2D4‘. (Virtual machine ID 85D7A0BC-9979-4B64-A817-609B14278C67)The key protector for the virtual machine “ could not be unwrapped. HostGuardianService returned: One or more arguments are invalid (0x80070057) . Details are included in the HostGuardianService-Client event log. (Virtual machine ID )

Im Fehlertext wird der „HostGuardianService“ erwähnt. Bedeutet das, das wir diesen unbedingt brauchen? Zum Glück ist die Antwort nein. Versteht mich nicht falsch. Natürlich ist es für eine sichere Umgebung ratsam den Hostguardian Service oder besser einen Cluster aus Hostguardian Services zu bauen, aber es geht auch ohne.

Wir brauchen dazu allerdings zwei Zertifikate pro Host die auf allen Livemigrations Zielen importiert werden. Wie bekommen wir nun diese Zertifikate? Das ist relative einfach.

Wenn eine VM mit einem vTPM angelegt wird oder ein vTPM nachträglich bei einer bestehende VM aktiviert wird, erzeugt Hyper-V im lokalen „Certificate Store“ ein „Verzeichnis“ mit dem Namen „Shielded VM Local Certificates“. Darin werden dann die zwei benötigten Zertifikate, die jeweils für 10 Jahre gültig sind, erzeugt. Sie heissen:

• „Shielded VM Encryption Certificate (UntrustedGuardian) (<Hostname>)“
• „Schielded VM Signing Certificate (UntrustedGuardian) (<Hostname>„

Diese Zertifikate muss man inclusieve des Private Keys exportieren und dann auf jedem Host der Ziel der Livemigration sein soll, was in einem Storage Spaces Direct Cluster jeder Knoten ist, importieren.

Da die Zertifikate nur erzeugt werden, wenn eine VM mit vTPM erzeugt wird, ist das Vorgehen folgendermassen:

1. 1Auf jedem Host je eine VM mit vTPM erzeugen oder bei einer VM den TPM aktivieren
2. 2Zertifikate von jedem Host einschliesslich des Private Keys exportieren
3. 3Zertifikate auf jedem Host importieren

Nach dem das geschehen ist sollte der „Certificate Store“ auf jedem System wie im Screenshot aussehen.

Jetzt kann man die VM im Hyper-V Cluster auf jeden Knoten verschieben.

Ich habe zum Thema ein Video erstellt in dem alles nochmal erklärt wird.

Viel Spass beim anschauen. 

Am Freitag den 3. April 2020 um 11 Uhr findet unser kostenloses Webinar „Windows Admin Center und Azure Stack HCI (in Deutsch)„ statt. Windows Admin Center ist ein Tool das man zeigen muss also besteht diese Webinar nur aus Demos!

Hier ein Auszug aus dem Inhalt:

• Demo Cluster Creation Wizard
• Demo Volumes und Devices
• Demo VMs
•  Demo Performance
• Q&A

Klingt spannend? Dann meldet euch zum Webinar an denn ich kann versprechen es wir interessant.

Carsten

P.S.: Wenn Ihr keine Zeit habt meldet euch trotzdem an, Ihr bekommt dann den Link zur Aufzeichnung automatisch zugeschickt.

Mittlerweile gibt’s auch die Aufzeichnung. Der Ton ist zwar etwas schlechter das macht den Inhalt aber nicht weniger interessant. Viel Spass beim anschauen.

Update von Grafana

Der letzte Beitrag ist ein bisschen her, daher gibt es auch schon wieder Updates für die von mir genutzte Installation. Das Debian als Basis ist bereits aktuell, allerdings gibt es eine neue Version Grafana. Diese bekommen wir immer von der Hauptseite, dort ist beschrieben wie man das aktuelle Paket zur Installation bekommt: https://grafana.com/grafana/download

Das eigentliche Update gestaltet sich recht einfach, hier zu müssen wir nur das Paket herunterladen und mittels dpkg installieren:

Klappt nach dem Update von ein Aufruf der Hauptseite und eine Anmeldung, scheint das Update geklappt zu haben. In diesem Fall können wir fortfahren mit der Einrichtung.

Einsammeln der Daten mittels Telegram Agent

Im ersten Teil hatten wir uns angeschaut, wie man mittels Influx-Modul per Windows PowerShell einen oder mehrere Werte ausliest und diese dann in die Influx-Datenbank schreibt. Diese Art von Daten sammeln ist nicht gerade ressourcenschonend, daher werden wir uns nun eine andere Möglichkeit anschauen: Telegraf.Telegraf ist ein Agent, der von den Machern von InfluxDB (der genutzten Datenbank) zur Verfügung gestellt wird. Die Installation und die Nutzung ist ebenfalls kostenlos, nach einem Download und einem entpacken kann direkt losgelegt werden.

Download: https://portal.influxdata.com/downloads/

Zum aktuellen Zeitpunkt ist Version 1.13.3 die aktuelle Stabil-Version. Achtet bei dem Download darauf, vorne den Telegraf-Agent herunterzuladen und nicht eines der anderen Produkte.

Download und Einrichtung

Nach dem Download kann das Zip-Archiv entpackt werden. Damit konstant Daten abgerufen und in der Datenbank gespeichert werden, empfiehlt sich die Einrichtung als Dienst.

Laut der Installationsanleitung empfiehlt es sich, die Daten unter C:Program Files in einem Ordner mit dem Namen Telegraf abzulegen. Das habe ich, wie man in dem Screenshot erkennen kann, gemacht. Nun kann der Dienst registriert werden:

C:Program FilesTelegraftelegraf.exe –service install –config „C:Program FilesTelegraftelegraf.conf“

Hat die Registrierung geklappt, kann der Dienst entweder per services.msc, per cmd oder per PowerShell gestartet werden.

Die Anpassung der Konfiguration

Die Datei telegraf.conf enthält die Steuerung für den Agenten. Schauen wir uns die Datei mal genauer an. Wichtig hierfür ist ein ordentlicher Editor wie Visual Studio Code oder auch notepad++, ein normales Notepad zerreißt ggf. die gesamte Formatierung und ist nicht zu brauchen.

Globale Einstellungen

Im oberen Teil der Konfiguration können wir im agent-Bereich diverse Optionen angeben, z.B. das Intervall. Damit legen wir fest, in welchem Abstand wir die Daten einsammeln und in die Datenbank schicken möchten. Hier sollten wir einen guten Abstand zwischen „zu selten“ und „zu oft“ auswählen. Sammeln wir zu selten Werte (z.B. nur alle 60 oder 90 Sekunden), können wir mögliche Ausschläge schlechter erkennen und die gemittelten Werte sind nicht realistisch. Fragen wir hingegen zu häufig Werte ab, erhöht dies die Belastung auf dem System und wir erzeugen künstlich Last.

Wir können mit den Werten jederzeit spielen und testen, das Intervall kann einfach durch diese eine Zeile angepasst werden. Starten wir erst einmal mit 2 Sekunden. Ich gehe nicht auf alle Möglichkeiten ein, nahezu alle Einstellungen sind beschrieben und erklärt. Primär gehe ich auf die Werte und Dinge ein, die ich gegenüber der Haupt-Konfiguration ändere.

OUTPUT PLUGINS

In diesem Bereich müssen wir einstellen, wie wir uns mit der Datenbank verbinden können. Hier tragen wir den Namen bzw. die IP vom Influx-Server ein, den Namen der Datenbank, die Zugangsdaten und auf Wunsch auch noch SSL/HTTPS-Einstellungen.Mehr ist es dann auch erstmal nicht, damit eine eine grundsätzliche Verbindung zur Datenbank aufbauen können. Kommen wir nun zum spannendsten Teil, die Auswahl der Mess-Counter.

INPUT PLUGINS

Im unteren Teil der Konfigurationsdatei sind standardmäßig bereits einige Performance-Counter vorhanden, z.B. die Auslastung von CPU, RAM usw.

Wenn wir nun die Datei speichern und den Telegraf-Agenten starten (und wir uns nicht vertan haben bei Servername und den Zugangsdaten), sollten die ersten Daten in die Datenbank eingetragen werden. Dies können wir unter anderem probieren, indem wir in einem Dashboard eine neue Abfrage erstellen. Direkt nach der Erstellung einer neuen Query müssten wir unter FROM mehrere Einträge sehen, z.B. win_cpu.

Sind diese Daten vorhanden, funktioniert die Einspielung der Daten vom lokalen Knoten in die Influx-Datenbank. Nun können wir damit fortfahren, die benötigten Daten und Werte zusammenzubringen, die relevant sind bei dem Betrieb von einem S2D Cluster.

Die korrekten Werte

Bei einem Hyper-V Host, einem Failover Cluster Knoten und/oder einem S2D Cluster gibt es mehrere Werte, die interessant sind für die Betrachtung der Performance.Zum einen wäre da die Auslastung der CPUs in den Hosts. Hier ist wichtig zu wissen, dass ein Hyper-V Host möglicherweise nicht korrekt anzeigt, wie seine wirkliche Auslastung ist. Dies liegt daran, dass das Management OS auf dem System nur „seinen“ CPU-Wert anzeigt und nicht den Wert, der auf dem gesamten Host anliegt. Hier ein Beispiel mit konkreten Werten:

Wir sehen in diesem Screenshot sehr gut, wie sich der Wert „Hyper-V Hypervisor Logical Processor“ vom Wert „Processor Information“ unterscheidet. Der erste Wert ist auf die gesamte Hardware bezogen und spiegelt die Auslastung über alle VMs hinweg wieder, der zweite Wert ist „nur“ die CPU vom Management OS. Hier sind die Werte nicht allzu weit voneinander entfernt und auch mehr als unkritisch, teilweise habe ich aber schon Systeme gesehen bei denen die Auslastung bei 80% oder mehr liegt und bei denen dies nicht wahrgenommen wurde, weil schlicht der falsche Werte überwacht wurde.

Ein weiterer Wert, der sinnvollerweise abgebildet werden sollte, ist die Auslastung des RAMs. Hier ist es deutlich einfacher, der Wert kann relativ einfach ausgelesen und angezeigt werden. Da nicht nur der frei RAM, sondern auch der belegte sowie der maximal verfügbare abgefragt werden kann, können hier auch recht einfach „gestackte“ Anzeigen gebaut werden, d.h. freier RAM und belegter RAM können in Grafana übereinander gelegt werden, damit dann in Summe der maximal verfügbare Arbeitsspeicher eingesehen werden kann.

Die Auslastung sowie die Belastung der CSV-Datenträger sollte auch im Auge behalten werden, dies ist häufig die Ursache für Probleme oder Performance-Engpässe. Spontan interessante und aussagekräftige Werte ist der gesamte Speicherplatz, der freie bzw. belegte Speicherplatz und die Latenz beim Zugriff auf den Speicher. Eine Monitoring von Netzwerk-Komponenten wie den SMB-Karten, der vSwitch und den Karten allgemein kommt ebenfalls noch hinzu und sollten nicht vergessen werden.

Nachdem wir nun über einen Teil der interessanten Werte gesprochen haben stellt sich jetzt bestimmt die Frage: Wie bekomme ich diese Werte und was muss ich dazu anstellen?

Damit die Werte abgefragt und gespeichert werden können, müssen sie in der Konfigurationsdatei vom Telegraf-Agenten eingetragen werden. Da der Agent auf den Perfmon im Hintergrund zugreift, können die benötigten Werte (mehr oder weniger einfach) über den Perfmon bzw. die Windows PowerShell abgefragt werden.Schauen wir uns mal einen kleinen Block an, der den Gesundheitszustand der VMs auf dem Host abfragt:

[[inputs.win_perf_counters.object]]ObjectName = „Hyper-V Virtual Machine Health Summary“Instances = [„——„]Measurement = „hyperv.vm.health“Counters = [„Health Ok“, „Health Critical“]

Wir sehen hier in der ersten Zeile unter Objectname das Objekt, welches abgefragt wird. Der Name deckt sich mit dem Namen, der auch im Perfmon abgefragt und eingesehen werden kann. Wenn man nicht genau weiß, wie und was man überwachen soll, kann man hier sehr gut den Perfmon zur Hilfe nehmen und die Namen und Einträge einfach abpinnen.

Der Eintrag Instances fragt ab, welche Instanzen überwacht werden. Habe ich z.B. vier Netzwerkkarten in meinem Server verbaut, könnte ich mit einem „*“ alle verfügbaren Karten abfragen. Sollen diverse NICs ausgelassen werden, z.B. die Isatap-Adapter usw., kann ich diese hier aktiv ausschließen. Die Nutzung von 6x „-„ führt dazu, dass das Instanz-Bit entfernt wird.

Im oberen Beispiel führt dies z.B. dazu, dass nicht für jede einzelne VM ein Status in die Datenbank eingetragen wird, sondern das die Summe der VMs eingetragen wird. Gebe ich diesen Wert später im Grafana aus, sehe ich immer die Gesamtzahl aller gesunden VMs sowie die Gesamtzahl aller kritischen VMs. Ich könnte diese Summierung natürlich auch später im Grafana machen, da wäre es dann aber mehr Aufwand. Man muss bzw. kann immer pro Abfrage entscheiden, ob man die einzelnen Werte in die Datenbank schreibt oder die Gesamtsumme.

Unter Measurement kann ich angeben, unter welchem Namen die Daten abgespeichert werden. Später in meiner Abfrage (Query) im Grafana sehe ich diesen Namen wieder. Je deutlicher dieser Name gewählt wird, desto einfacher komme ich später bei dem Aufbau der Dashboards zurecht. Der aktuell gewählte Name „hyperv.vm.health“ sagt eigentlich schon sehr deutlich aus, was genau hier abgefragt wird.

Zu guter Letzt muss mit Counters ausgewählt werden, welche Daten abgefragt und gespeichert werden. Diese Informationen kann ich ebenfalls sehr gut über den Perfmon abfragen und einsehen, man sieht in dem Screenshot weiter oben die hier angegebenen Counter „Health OK“ und „Health Critical“.

Wird dieser Block in die Config-Datei eingearbeitet, gespeichert und der Dienst wird kurz durchgestartet, sollten kurz darauf die ersten neuen Einträge in der Datenbank sichtbar sein und über Grafana visualisiert werden können.

Ganz einfach zusammengesetzt kann dies dann z.B. so aussehen:

Bei der Gestaltung der Kacheln sind mehr oder weniger keine Grenzen gesetzt, eine sehr schicke Möglichkeit zur besseren Darstellung ist die Möglichkeit, dass bei „VMs Critical“ alle Zahlen größer als 0 direkt Rot angezeigt werden. Wer möchte schon kritische VMs haben ;)

Und welche Werte brauche ich jetzt WIRKLICH?

Microsoft hat in den Docs ein sehr gutes Dokument veröffentlicht, welches einige relevante Werte bei dem Betrieb von Hyper-V aufführt: https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/hyper-v-server/detecting-virtualized-environment-bottlenecks

Hier sind einige gute Werte sowie Grenzwerte aufgeführt, die in einer Umgebung sinnvollerweise nicht überschritten werden sollten. Welche Werte die richtigen für genau euren Bedarf sind kann ich hier nicht generell sagen, das kommt immer auf die Umgebung an. Bei 15 Systemen werden vermutlich 16 unterschiedliche Konfigurationen herauskommen :)

Sehr gut. Und wie bekomme ich die Namen alle raus?

Um die Namen der einzelnen Werte nicht abtippen zu müssen , kann man sich die PowerShell zur Hilfe nehmen. Wenn ich nun z.B. herausgefunden habe, dass ich gerne einzelne Werte aus dem Satz „Cluster CSVFS“ haben möchte, kann ich mir diese anzeigen lassen mit

(Get-Counter -ListSet „Cluster CSVFS“).Paths

Diese Ausgabe kann ich nun benutzen, um in meiner telegraf-Konfiguration einen neuen Block einzufügen, der die gewünschten Werte abfragt. Da ich immer alle CSV-Datenträger einlesen möchte, wird bei Instances der Wert „*“ eingetragen. ObjectName und Measurement kann ich frei wählen, unter Counters werden dann die gewünschten Counter eingetragen.

[[inputs.win_perf_counters.object]]  ObjectName = „Cluster CSVFS“  Counters = [„Write Bytes/sec“, „Read Bytes/sec“, „Writes/sec“, „Reads/sec“, „Current Write Queue Length“, „Current Read Queue Length“]  Instances = [„*“]  Measurement = „cluster.storage.csvfs“

So füllt sich dann nach und nach die Konfigurationsdatei und die Werte werden in dem von uns definierten Intervall abgezogen und in die Datenbank geschrieben.

Dateien und Dashboards

Die Datei, die ich während dem Schreiben von diesem Artikel zusammengetragen habe, sieht wie folgt aus:

​Download: Telegraf Konfiguration

Das erstellte Grafana-Dashboard sieht wie folgt aus:

Falls jemand das fertige Dashboard als JSON-Datei haben möchte:

Download: Grafana-JSON-File

Wenn ihr für euch ebenfalls ein Dashboard baut und Werte abfragt, könnt ihr diese gerne hier teilen und anderen Lesern die Arbeit ein bisschen leichter machen. Einfach einen kurzen Kommentar dalassen und auf eure Konfig-Datei verweisen. Wenn Fragen sind könnt ihr diese natürlich ebenfalls gern hier in den Kommentaren schreiben, ich lese hier immer noch mit :)

​In meinem Beispiel handelt es sich um ein ​3 Node Azure Stack HCI Cluster von HPE auf Basis Windows Server 2019  mit ​je ​24 SSDs vom Type MO001600JWTBT pro Server.

Überprüfen der aktuellen Firmware

​Zuerst überprüfen wir, welche Firmware ist aktuell installiert und unterstützen unsere NVMe’s oder SSDs ​das aktualisieren per PowerShell. ​​Einen Überblick über alle Festplatten erhalten wir mit folgenden PowerShell Befehl.

 Get-PhysicalDisk  | Get-StorageFirmwareInformation

steht  „SupportsUpdate“ auf „True“ können wir grundsätzlich die Firmware der SSDs per PowerShell aktualisieren.

Download der Firmware Datei beim Hersteller

​​Zum Einsatz kommen nur vom Hersteller supportete Firmwareversionen. In meinem Beispiel ​war dies die Firmwareversion „HPD7“ die unter folgendem Link heruntergeladen werden kann.

​​Die heruntergeladene .EXE Datei entpacken. ​In ​meinem Beispiel handelt es sich bei der  „TAPM5ALLHPD/.rel“ um die Image Datei für das Firmwarupdate. Wenn ihr nicht schon auf dem Server seid, müsst ihr diese in ein Verzeichnis auf dem Server kopieren.

​S2DNode und Festplatten in den Maintanence Mode setzen

​Der S2D Node muss vor der Firmwareaktualisierung  „Angehalten“ und die Rollen verschoben werden. Im Anschluss müssen die Festplatten des ​S2D Nodes in den „Maintanence Mode“ gesetzt werden. Dies könnt ihr über folgende PowerShell Befehle ​erreichen.

# Node anhalten und Rollen verschieben$Node = <NodeName>Suspend-ClusterNode -Name $Node -Drain -Wait -Verbose

# Festplatten des Hosts werden in den Maintenance Mode gesetzt$S2DStorage=Get-StorageFaultDomain -type StorageScaleUnit | Where-Object {$_.FriendlyName -eq $Node} Enable-StorageMaintenanceMode -InputObject $S2DStorage

Firmwareupdate Installieren

​​​Das Firmwareupdate ​muss lokal auf dem jeweiligen Server ausführt werden. ​Überprüft bitte vor dem Firmwareupate, ob die Festplatten tatsächlich im Maintanence Mode sind. Das könnt ihr z.B. mit folgenden PowerShell Befehl machen.

Get-PhysicalDisk -PhysicallyConnected -StorageNode(Get-StorageNode -Name „$Node*“)[1] ​| ft DeviceId, FriendlyName,SerialNumber, Firmwareversion, MediaType,OperationalStatus​

​Jetzt kann die neue Firmwareversion ​installiert werden.

$Disks = Get-PhysicalDisk | ? Operationalstatus -eq ‚In Maintenance Mode‘

foreach($Disk in $Disks) {    $Disk | Update-StorageFirmware -ImagePath ‚C:installFirmware für SSD MO001600JWTBTcp040482TAPM5ALLHPD7.rel‘ -SlotNumber 0 -Verbose}

​​Danach muss der ​S2DNode neu gestartet werden. ​​​Nach dem Neustart die Firmwareversion der SSDs kontrollieren, die Festplatten und den ​S2DNode aus dem Maintanence Mode nehmen.

S2DNode und Festplatten ​aus dem Maintanence Mode ​nehmen

# Festplatten des Hosts werden ​aus den Maintenance Mode ​genommen

​$Node = <NodeName>​​$S2DStorage=Get-StorageFaultDomain -type StorageScaleUnit | Where-Object {$_.FriendlyName -eq $Node} Disable-StorageMaintenanceMode -InputObject $S2DStorage

# Festplatten kontrollierenGet-PhysicalDisk

​# Clusterknoten „Fortsetzen und Rollen zurückholenResume-ClusterNode -Name $S2DNode -Failback Immediate -Verbose

​Denk bitte daran, dass ihr den Abschluss der Storagejobs abwartet, bis ihr mit den nächsten Knoten forffahrt. Mit

Get-StorageJob

könnt ihr die Storagejobs überwachen.

So, das war es schon.

An dieser Stelle sei darauf hingewiesen, dass ihr solche ​Aktionen nach Möglichkeit nie erstmals an einen Produktivsystem testen solltet. Außerdem ist mit großer Sorgfalt darauf zu achten, dass ihr die richtige Firmwaredatei installiert. Solltet ihr in eurem System NVMe’s und SSDs haben, so kann es sein, dass ihr die hier gezeigten PowerShell Befehle anpassen müsst. Ich wünsche euch ganz viel Erfolg dabei und verbleibe bis zum nächsten Mal 

Eure Petra

Ich denke wir haben wieder einige interessante Sprecher und Vorträge zu Hybrid Cloud Themen am Morgen und zu Hyper-V Themen am Nachmittag zusammengetragen.

Ein Dank auch an unseren Gastgeben der Dell EMC die uns mit Getränken und Speissen versorgt.

Agenda

Kostenloses Ticket reservieren

Am Donnerstag den 20. Dezember um 11 Uhr findet der zweite Teil des Webinars „Ignite 2019 Azure Stack HCI News – Part 2(in Deutsch)„ statt. In diesem Webinar schauen wir uns die Neuhigkeiten rund um Storage Spaces Direct die auf der Microsoft Ignite 2019 im November verkündet wurden.

Hier ein Auszug aus dem Inhalt:

• News zu Azure Stack HCI 
• Q&A

Klingt spannend? Dann meldet euch zum Webinar an denn ich kann versprechen es wir interessant.

Carsten

P.S.: Wenn Ihr keine Zeit habt meldet euch trotzdem an, Ihr bekommt dann den Link zur Aufzeichnung automatisch zugeschickt.

P.P.S.: Den ersten Teil findet ihr als Aufzeichung  im Webinar Archiv!

On the 20th of Dezember we will have the secound part of our „Webinar Ignite 2019 Azure Stack HCI News – Part 2 (in Englisch)“. In this Webinar I share the Microsoft Ignite 2019 News around Storage Spaces Direct from November. 

Here is a peek into the Agenda:

• S2D Tipps  Azure Stack HCI News
• Q&A

Carsten

P.S.: To sign-up click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar if you sign-up you will get a link to the recording afterward.

P.P.S.: You find the first part of the Webinar in our „Webinar archiv„!

Ich finde das Webinar ist ein muss für jeden Hyper-V Administrator und gibt euch auch Argumente warum man gerade kein LACP bei einer Hyper-V Switch braucht.

Aber schaut selbst:

P.S.: Das Video ist eines von über 35 Webinar Aufzeichnungen welche ihr in meinem Webinar Archiv findet. Interesse? Dann erhaltet Ihr hier Zugriff und verpasst auch kein weiteres Webinar. 

Am 7. September findet Teil 2 unseres Deutsch sprachingen Webinar zu unseren Best Pracitces aus unzähligen Hyper-V Failover Cluster Installationen. Nachdem wir in Teil 1 über am 7. September um 11 Uhr spreche wir über einige Best Practices die wir in unseren unzähligen Failover Cluster 2016 Implementierung der letzten 2 Jahre gelernt haben. 

In Teil 1 haben wir einige grundlegenden Cluster Einstellungen behandelt und mit den verschiedenen Netzwerk und deren Bedeutung angefangen. In Teil 2 werden daran anschließen und uns Netzwerkdesigns, die Hyper-V Switch und SMB3 und DMB Direct anschauen.

Hier ein Auszug aus dem Inhalt:

•  Best Practices Cluster Einstellungen 
• Best Practice Networking
• Best Practices Storage
• checkDemo
• checkQ&A

Meldet euch zum Webinar an den es gibt wieder viele Demos und auch ein Webinar Special.

Carsten

On the 7th of September at 5pm CET +2 we will have ​our ​english speaking Failover Cluster Best Practices Webinar Part 2 where we continue with our best practices that we build in numerous Hyper-V Failover Cluster ​pojects over the last years.

After talking in Part 1 of the Webinar ​about some generic Cluster setings ​we started with Cluster Networking.​ In Part 2 we will talk about Network Designs, the Hyper-V Switch and SMB3 and SMB Direct.​

​Here is the Agenda:

• Best Practices Cluster Settings
• Best Practices Networking
• Best Practices Storage
• checkDemo
• checkQ&A

​To sign-up just click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar if you sign-up you will get a link to the recording afterwards.

Carsten

Viel Spaß bei dieser Episode der Hyper-V Amigos!

Auf der diesjährigen Cloud & Datacenter Conference Germany, die vom 21. bis 22. Mai in Hanau stattgefunden hat (https://www.cdc-germany.de), hatten wir einige fantastische Storage Spaces Direct Vorträge. Besonders hervorzuheben sind hier die vier von Cosmos Darwin (Microsoft Produktmanager in Redmond/USA) der persönlich einige der Features in Azure Stack HCI verantwortet. Alle Sessions wurden aufgezeichnet und ich möchte hier seine vier Session zum anschauen bereitstellen.

Cosmos Darvin – What’s new in Windows Server 2019 for Hyper-Converged Infrastructure

Cosmos Darvin – Understanding Storage Spaces Direct fault tolerance

Cosmos Darvin – Understanding the cache in Storage Spaces Direct

Cosmos Darwin – Understand how Storage Spaces Direct uses the network

So das waren die Videos. Übrigens wenn ihr pro aktive über die CDC-Germany 2020 oder über bevorstehende Webinare informiert werden möchtet, dann meldet euch doch bei meinem Newsletter an!

This year at the Cloud & Datacenter Conference Germany, which took place from the 21st to the 22nd May in Hanau Germany (https://www.cdc-germany.de), we had some extraordinary Storage Spaces Direct presentations. Four of them were done by Cosmos Darvin (Microsoft Produktmanager in Redmond/USA) who is responsible for some of the Azure Stack HCI. So I decided to publish his session here in the blog.

Cosmos Darvin – What’s new in Windows Server 2019 for Hyper-Converged Infrastructure

Cosmos Darvin – Understanding Storage Spaces Direct fault tolerance

Cosmos Darvin – Understanding the cache in Storage Spaces Direct

Cosmos Darwin – Understand how Storage Spaces Direct uses the network

BTW if you like to be informed when my englisch speaking Webinars take place please sign up for my Newsletter.

Am 7. September findet Teil 2 unseres Deutsch sprachingen Webinar zu unseren Best Pracitces aus unzähligen Hyper-V Failover Cluster Installationen. Nachdem wir in Teil 1 über am 7. September um 11 Uhr spreche wir über einige Best Practices die wir in unseren unzähligen Failover Cluster 2016 Implementierung der letzten 2 Jahre gelernt haben. 

In Teil 1 haben wir einige grundlegenden Cluster Einstellungen behandelt und mit den verschiedenen Netzwerk und deren Bedeutung angefangen. In Teil 2 werden daran anschließen und uns Netzwerkdesigns, die Hyper-V Switch und SMB3 und DMB Direct anschauen.

Hier ein Auszug aus dem Inhalt:

•  Best Practices Cluster Einstellungen 
• Best Practice Networking
• Best Practices Storage
• checkDemo
• checkQ&A

Meldet euch zum Webinar an den es gibt wieder viele Demos und auch ein Webinar Special.

Carsten

On the 7th of September at 5pm CET +2 we will have ​our ​english speaking Failover Cluster Best Practices Webinar Part 2 where we continue with our best practices that we build in numerous Hyper-V Failover Cluster ​pojects over the last years.

After talking in Part 1 of the Webinar ​about some generic Cluster setings ​we started with Cluster Networking.​ In Part 2 we will talk about Network Designs, the Hyper-V Switch and SMB3 and SMB Direct.​

​Here is the Agenda:

• Best Practices Cluster Settings
• Best Practices Networking
• Best Practices Storage
• checkDemo
• checkQ&A

​To sign-up just click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar if you sign-up you will get a link to the recording afterwards.

Carsten

​Ich habe dies in einer Kunden Umgebung getestet. Die S2D Hosts waren mit Windows Server 2019 installiert und der Veeam Backup Server hatte die Version 9.5 Update 4 und dem passenden Veeam Agent dazu.

​Folgende Schritte sind dafür notwendig:

​1. Installation des Veeam Agent für Windows auf den S2D Host

​​Die aktuelle Version des Veeam Agent für Windows ​könnt hier euch bei Veeam herunterladen, dafür müsst ihr euch bei Veeam registrieren. Nach erfolgreichem Download könnt ihr auch schon starten. Ich habe den Veeam Agent für Windows direkt auf den S2D Hosts installiert.

​weiter müssen wir am S2D Host nichts konfigurieren, das machen wir in den nächsten Schritten über dem Veeam Backup & Replication Server. Solltet ihr keinen Veeam Backup & Replication Server zur Verfügung haben, so könnt ihr den Agent auch direkt am Server konfigurieren. 

2. S2D Hosts zum Veeam Backup & Replication Server hinzufügen

​Wir öffnen die Veeam Backup & Replication Konsole und wählen Backup Infrastructure aus.

​3. Backup Job erstellen und ausführen

​Sind die S2D Hosts erfolgreich am Veeam Server hinzugefügt, können wir im nächsten Schritt die Backup Jobs erstellen. Hierfür wechseln wir auf „Home“ und rufen den Wizard für „Backup Jobs“ auf.

​Im nächsten Schritt müssen die zu sichernden Server dem Backup Job hinzugefügt werden.

​Zum Abschluß muss noch das Scheduling eingerichtet werden. Danach können unsere S2D Hosts gesichert werden.

​4. ​Veeam Recovery Media für die S2D Hosts erstellen

​Um einen S2D Hosts wiederherstellen zu können, benötigen wir noch das Veeam Recovery Media. 

Voraussetzung zum Erstellen des Veeam Recovery Medias:

• ​Installation des Windows Assessment and Deployment Kit (MS ADK) auf dem Backup Server
• Windows-Installationsmedien, damit Veeam Agent für Windows die erforderlichen Komponenten von dort laden kann

Ich würde vor der Erstellung des Veeam Recovery Medias auf dem jeweiligen S2D Host die CSVs auf einen anderen Knoten verschieben. ​In der Veeam Konsole unter „Inventory“ wählen wir den gewünschten S2D Hosts aus und ​klicken dann auf „Recovery Media“  

​Im nächsten Schritt geben wir den Pfad an, ​auf dem die ISO Datei gespeichter werden soll. Wir sollten uns hier einen Pfad überlegen, der in jedem Fall zugänglich ist,​ auch wenn das S2D Cluster z. B. nicht zur Verfügung stehen sollte. 

​Dieser Vorgang muss für alle S2D Hosts wiederholt werden. Das Veeam Recovery Media, muss gegebenenfalls nach einem Agent Update neu erstellt werden. Bitte haltet das Veeam Recovery Media immer kompatibel mit den Agent Versionen. Es wäre doch ärgerlich wenn ihr ein Backup für den Host habt und im Anwendungsfalle das Veeam Recovery Media mit dem Agent nicht kompatibel ist und ihr somit euren Host nicht wiederherstellen könnt.

​5. Restore eines S2D Hosts

​Die als Veeam Recovery Media erstellte ISO-Datei, mounten wir nun in der iDRAC Console (bei unserem Test arbeiten wir mit Dell Servern) um von der ISO den Server zu booten.

​Wenn ihr auf die zu restorenden Laufwerke klickt, bekommt hier eine detailierte Darstellung angezeigt, was von den Laufwerken wiederhergestellt wird. 

​Es ist für mich immer wieder faszinierend zu sehen, wie schnell so ein Restore durchläuft. Jetzt muss der Server noch neu gestartet werden und der Host steht dem Cluster wieder zur Verfügung.​

​Zum Abschluß müsst ihr noch die Storage Jobs kontollieren, dass diese auch wieder sauber abgearbeitet werden. Ich würde auch noch die Treiberstände kontollieren um sicher zu gehen, dass auch hier alles passt.

​Ihr solltet die Schritte unbedingt einmal in der Parxis durchgehen – vielleicht an einem nicht kritischen System um zu überprüfen, ob es auch in eurer Umgebung so läuft wie hier beschrieben. Wenn ihr das erst im Erstfall tut, können sich fatale Fehler einschleichen, die euch dann sehr viel Zeit und Nerven kosten. In diesem Sinne viel Erfolg

Eure Petra​

Es war ein langer Weg bis das geklappt hat. Wer mehr über die Hintergründe wissen möchte, schaut sich am besten mal den Microsoft Techcommunity Thread an.

Eine weitere gute Nachricht: Server Core App Compatibility Feature on Demand (FOD) laufen auch mit Hyper-V Server. Aber was ist FOD?  Microsoft möchte ja seit geraumer Zeit das auf Servern ohne GUI installiert wird. Allerdings fehlen in der Core Edition (auf der auch der kostenlose Hyper-V Server basiert) einige wichtige Bibliotheken wenn man Programm oder Services dort laufen lassen möchte. Deswegen wurden etliche Libraries nach Core portiert und als seiten Effekt ist es nun möglich auch die MMC und viele MMC-Plugins auf Core zu betreiben.

Am 7. September findet Teil 2 unseres Deutsch sprachingen Webinar zu unseren Best Pracitces aus unzähligen Hyper-V Failover Cluster Installationen. Nachdem wir in Teil 1 über am 7. September um 11 Uhr spreche wir über einige Best Practices die wir in unseren unzähligen Failover Cluster 2016 Implementierung der letzten 2 Jahre gelernt haben. 

In Teil 1 haben wir einige grundlegenden Cluster Einstellungen behandelt und mit den verschiedenen Netzwerk und deren Bedeutung angefangen. In Teil 2 werden daran anschließen und uns Netzwerkdesigns, die Hyper-V Switch und SMB3 und DMB Direct anschauen.

Hier ein Auszug aus dem Inhalt:

•  Best Practices Cluster Einstellungen 
• Best Practice Networking
• Best Practices Storage
• checkDemo
• checkQ&A

Meldet euch zum Webinar an den es gibt wieder viele Demos und auch ein Webinar Special.

Carsten

On the 7th of September at 5pm CET +2 we will have ​our ​english speaking Failover Cluster Best Practices Webinar Part 2 where we continue with our best practices that we build in numerous Hyper-V Failover Cluster ​pojects over the last years.

After talking in Part 1 of the Webinar ​about some generic Cluster setings ​we started with Cluster Networking.​ In Part 2 we will talk about Network Designs, the Hyper-V Switch and SMB3 and SMB Direct.​

​Here is the Agenda:

• Best Practices Cluster Settings
• Best Practices Networking
• Best Practices Storage
• checkDemo
• checkQ&A

​To sign-up just click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar if you sign-up you will get a link to the recording afterwards.

Carsten

Folgendes Scenario: wir haben eine Storage Spaces Direct Cluster zu patchen. Wie geht man vor? Bei Hyper-V verschiebt man die VMs auf einen Anderen Host, installiert die Patche und bootet das System. Wenn der Host wieder da ist wiederholt man den Prozess bei dem nächsten Host und so weiter.

Das ist keine gute Idee bei einem Storage Spaces Direct System!

Falls ihr diese Vorgehen anwendet lauft ihr Gefahr in große Schwierigkeiten zu kommen. Ihr fragt warum? Nun nach dem Join des bootenden Hosts in den Cluster müssen noch Repairjobs im Storage Spaces Layer laufen die alle Datenänderungen die nicht auf den bootenden Host geschrieben werden könnten durchführt. Diese Repairjobs dauern in der einige Minuten und können bei großer Belastung auch bis zu einer Stunde dauern.

Die Gefahr ist nun das Ihr einen zweiten Knoten bootet während die Daten der Volumes noch nicht vollständig repariert sind. Wenn das passiert ist man bei Verwendung eines 2-wege Spiegel jetzt bereits in Schwierigkeiten (die Volumes wären jetzt offline und alle VMs gehen in den „Pause Critical“ Zustand. Erst wenn der zweite Knoten wieder den Cluster joined können die Volumes wieder online genommen werden). Wenn wir einen drei-wege Spiegel benutzen passiert das zwar nicht, aber bei einem Ausfall eines Storage Devices in einem Dritten Knoten sind dann auch die Daten nicht zugreifbar.

Die Frage ist also wie vermeide ich das? Ganz einfach wir müssen warten bis die Repair Jobs abgeschlossen sind und alle Volumes wieder Healthy bevor wir uns den nächste Knoten vornehmen.

Die Storage Repairjobs kann man zum einen mit dem Windows Admin Center im Hyper-converged Scenario und zum anderen mit mit Powershell sehen.

Bei PoweShell sind hierbei zwei CmdLets wichtig:

Get-VirtualDisk

​​Get-StorageJob

Wenn Ihr gerne seht was im Cluster passiert und vielleicht auch den Fortschritt der Repairjobs sehen möchte, der kann folgende kleine PowerShell Zeile helfen:

do {Get-VirtualDisk | ft; Get-StorageJob | ft; sleep 3} while($true)

Die verwendete „do { } while($true)“ Schleife ist hierbei eine „Endlos Schleife“ die alle CmdLets zwischen den beiden „{}“ Klammern ausführt bis die Schleiefenverabeitung abbrochen wird. Ihr könnt diese beliebig für eure Zwecke erweitern.

Ich verwende z.B. oft eine Variante des Befehls, der mir zusätzlich die Cluster Knoten und die Nicht Healhy Disks anzeigt:

do {Get-ClusterNode|ft; Get-VirtualDisk|ft; Get-StorageJob|ft; get-Physicaldisk | where HealthStatus -ne Healthy|ft; sleep 3} while(1)

Ich wünsche euch viel Spass beim experimentieren.

Die Grundvoraussetzung

Der Aufbau beschränkt sich in meinem Fall auf eine VM mit einem aktuellen Debian 9.8. Keine Angst, die Installation ist schnell gemacht und alle Schritte werden hier zum einfachen kopieren beschrieben.

Die Debian Grundinstallation

Die VM bekommt von mir 2 vCPUs, 4 GB RAM und eine 80 GB große VHDX zugewiesen. Ich nutze eine Generation 2-VM, bei der allerdings das Secure-Boot deaktiviert wurde, da Debian hier noch keine passenden Zertifikate vorhanden sind. Weiterhin sollten Sie darauf achten, dass die virtuelle Netzwerkkarte eine statische MAC-Adresse hat, da Debian es nicht so gerne hat, wenn sich die MAC-Adresse ändert. Falls es zu einer Änderung der MAC-Adresse kommt, kann es hier sein das diese dann als eth1 erkannt wird, eth1 hat keine Konfiguration usw…

Die eigentliche Installation

Hier gibt es eigentlich nicht viel zu beschreiben, es handelt sich um eine gewöhnliche Installation von Debian. Falls dies vollkommen unbekannt ist, gibt es haufenweise Anleitungen im Internet, z.B. von DigitalOcean oder anderen Howto-Seiten. – Ich bevorzuge die „Install“-Variante ohne die grafische GUI, diese geht schneller von der Hand.- Die Sprache bleibt bei mir auf Englisch, lediglich die Tastatur wird auf Deutsch gestellt.- Die komplette Platte wird verwendet, kein Volume Manager, alles auf eine Partition- Bei der Auswahl der Software wähle ich nichts aus außer SSH und die Standard-Systemtools (d.h. Desktop weg und Print Server weg)

Nach der Grundinstallation beginnen wir mit dem Download und der Installation der benötigten Pakete. Vorab aktualisieren wir die Paketquellen und das gesamte System, so das alles auf dem aktuellen Stand ist.

# Aktualisierung auf den neuesten Stand, Installation von ein paar benötigten Tools und Paketenapt update && apt install mc htop nano -y && apt upgrade -y && apt dist-upgrade -yapt-get install -y adduser libfontconfig# Download der Setup-Dateiencd /usr/srcwget wget https://dl.influxdata.com/influxdb/releases/influxdb_1.7.4_amd64.debwget https://dl.grafana.com/oss/release/grafana_6.0.2_amd64.deb# Installationdpkg -i influxdb_1.7.4_amd64.debdpkg -i grafana_6.0.2_amd64.deb# Automatischer Start von Grafana zum Systemstart/bin/systemctl daemon-reload/bin/systemctl enable grafana-server

Nun haben wir die reine Grundinstallation abgeschlossen und kommen zur Konfiguration der beiden Applikationen. Dazu editieren wir zuerst die config-Datei der InfluxDB-Datenbank.

nano /etc/influxdb/influxdb.conf

In dieser Datei müssen wir nun den Bereich „HTTP“ anpassen. Wir setzen „enabled“ auf „true“ und aktivieren den port „8086“. Das Ergebnis sieht wie folgt aus:

Danach müssen wir den Influx-Dienst einmal durchtreten

service influxd restart

Nun wechseln wir in die Influx-Datenbank und legen einen neuen Benutzer sowie eine neue Datenbank an. „username“ muss ersetzt werden durch einen beliebigen Username, ebenso „password“ mit einem starken Passwort. Danach verlassen wir influxDB wieder.

influxCREATE USER „username“ WITH PASSWORD ‚password‘ WITH ALL PRIVILEGESCREATE DATABASE „Datenbankname“exit

Eine manuelle Test-Verbindung zur Datenbank können wir auch herstellen, hierzu kann der influx-Befehl mit Parametern genutzt werden. Klappt dies, steht einer Nutzung eigentlich nichts mehr im Weg.

influx -username „username“ -password „password“

Die Einrichtung von Grafana

Nachdem wir nun die Installation von Grafana und der Datenbank abschlossen haben, können wir mit der Einrichtung starten. Durch die Installation im vorherigen Schritt steht Grafana schon zur Verfügung und lauscht standardmäßig auf Port 3000. Schauen Sie kurz nach, mit welcher IP-Adresse ihr Linux-System online ist:

ip a s

Danach können Sie die Weboberfläche auf Port 3000 aufrufen und sich mit admin und admin anmelden. Sie werden direkt nach der ersten Anmeldung dazu aufgefordert, das Standard-Kennwort zu ändern. Tun Sie dies!

Anbindung der Datenbank-Quelle

Wir müssen nun die vorab installierte InfluxDB als Datenbankquelle hinzufügen, damit die Daten zur Visualisierung genutzt werden können. Direkt nach der ersten Anmeldung können wir die Option „Datenquelle hinzufügen“ benutzen, alternativ geht es über das Menü auf der linken Seite.

In den Einstellungen müssen wir die folgenden Optionen angeben:

– Name: Hier geben wir der DB-Quelle einen Namen. z.B. InfluxDB

– URL: Hier tragen wir die lokale Adresse mit dem Port 8086 ein, den wir zuvor aktiviert haben in der Konfiguration: http://localhost:8086

– Auth: Hier wählen wir „with credentials“ aus, damit wir eine Anmeldung an der Datenbank machen können.

– InfluxDB Details: Hier tragen wir den Namen der Datenbank, den Benutzernamen und das Kennwort ein, was wir im Vorfeld in der Influx-Datenbank angelegt haben.

Alle weiteren Optionen können wir leer lassen, diese werden an dieser Stelle nicht benötigt.

Nun haben wir eine Datenbank hinzugefügt. Diese Datenbank dient später als Quelle für die Performance-Daten, die wir visualisieren möchten. Zum aktuellen Zeitpunkt befinden sich allerdings noch keine Daten in dieser Datenbank, daher werden wir nun im nächsten Schritt dafür sorgen, dass Daten in die Datenbank gelangen.

Einen oder mehrere Server als Datenquelle hinzufügen

Um nun an die Daten der Windows S2D-Server zu kommen, nutzen wir ein PowerShell-Modul, welches die gewünschten Daten in die vorab eingerichtete Datenbank speichert. Ich beginne in meinem Fall mit dem ersten der beiden Knoten und richte ein kleines Test-Skript ein, welches ein paar Demo-Daten ausliest und speichert. Die Installation erfolgt in einer PowerShell:

Install-Module Influx

Nach der Installation benötigen wir ein kleines Skript, welches die Daten per Perfmon ausliest und in die entsprechende Datenbank schreibt. Anbei eine kleine txt-Datei mit dem Skript.

​​Download: Performance-Demo.txt​​​

Die paar Zeilen PowerShell machen die folgenden Dinge:- Zeile 1 definiert den Datenbank-Server- Zeile 2 und 3 sind Benutzername und Kennwort der Datenbank (dies könnte auch manuell eingegeben werden, damit die Daten nicht im Plaintext im Skript stehen)- Zeile 4 baut die Credentials so zusammen, dass sie in dem Skript nutzbar sind- Zeile 6 holt sich die Werte für die CPU-Auslastung und den verwendeten Speicher- Zeile 7 und 8 speichern den reinen Wert (z.B. 41,52 für die prozentuale CPU-Auslastung)- Zeile 10 bis 13 schreibt diese Werte in ein Array und definiert dafür den Namen, der später in Grafana als Datenquellwert angewählt werden kann (z.B. cpu active).- Zeile 15 schreibt die beiden Werte in die InfluxDB

Sind alle Daten korrekt eingetragen, wird ein ersten Datenwert in die Datenbank geschrieben. Diesen Wert önnen wir uns nun in einem neuen Dashboard anzeigen lassen. Final wird es dann so sein, dass über einen geplanten Task kontinuierlich Daten in die Datenbank geschrieben werden, mit Hilfe dieser Punkte können wir uns dann einen Graph erzeugen.

Das erste Dashboard erzeugen

Wir wechseln nun zurück in die Grafana-Oberfläche und erzeugen ein neues Dashboard. Als erstes geben wir die Query-Daten ein, damit das Dashboard weiß, von wo und welche Daten es sich holen soll. Sobald die Daten korrekt eingetragen sind, können wir den einen erzeugten Punkt sehen.

Nachdem nun die korrekte Datenquelle angegeben wurde, können wir nun mit der Formatierung der Anzeige beginnen. Dazu wechseln wir in der linken Seitenleiste auf die Visualisierung.

Hier können wir allerlei Einstellungen vornehmen, die unsere Anzeige verändert und so anpasst, dass wir die Daten optimal sehen können. Ich stelle fast immer unter „Stacking & Null value“ die Option „Connected“ ein, damit die Punkte untereinander verbunden werden und es keine Null-Werte gibt (die kann es natürlich geben, aber wenn man die RAM-Größe beobachtet, wird diese ja nicht auf Null fallen, nur weil gerade in diesem Moment nichts gemessen wurde :) )

An dieser Stelle sind wir am Ende von Teil 1 angekommen, die Grund-Infrastruktur steht soweit. Im zweiten Teil werden wir uns anschauen, welche relevanten Perfmon-Werte wir uns anschauen und protokollieren sollten. Mit diesen Werten werden wir dann ein Dashboard bauen, welches uns die Latenzen und IOPS-Werte der Volumes anzeigt. Danke fürs Lesen und bis zum nächsten Mal :)

Am 7. September findet Teil 2 unseres Deutsch sprachingen Webinar zu unseren Best Pracitces aus unzähligen Hyper-V Failover Cluster Installationen. Nachdem wir in Teil 1 über am 7. September um 11 Uhr spreche wir über einige Best Practices die wir in unseren unzähligen Failover Cluster 2016 Implementierung der letzten 2 Jahre gelernt haben. 

In Teil 1 haben wir einige grundlegenden Cluster Einstellungen behandelt und mit den verschiedenen Netzwerk und deren Bedeutung angefangen. In Teil 2 werden daran anschließen und uns Netzwerkdesigns, die Hyper-V Switch und SMB3 und DMB Direct anschauen.

Hier ein Auszug aus dem Inhalt:

•  Best Practices Cluster Einstellungen 
• Best Practice Networking
• Best Practices Storage
• checkDemo
• checkQ&A

Meldet euch zum Webinar an den es gibt wieder viele Demos und auch ein Webinar Special.

Carsten

On the 7th of September at 5pm CET +2 we will have ​our ​english speaking Failover Cluster Best Practices Webinar Part 2 where we continue with our best practices that we build in numerous Hyper-V Failover Cluster ​pojects over the last years.

After talking in Part 1 of the Webinar ​about some generic Cluster setings ​we started with Cluster Networking.​ In Part 2 we will talk about Network Designs, the Hyper-V Switch and SMB3 and SMB Direct.​

​Here is the Agenda:

• Best Practices Cluster Settings
• Best Practices Networking
• Best Practices Storage
• checkDemo
• checkQ&A

​To sign-up just click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar if you sign-up you will get a link to the recording afterwards.

Carsten

Am 7. September findet Teil 2 unseres Deutsch sprachingen Webinar zu unseren Best Pracitces aus unzähligen Hyper-V Failover Cluster Installationen. Nachdem wir in Teil 1 über am 7. September um 11 Uhr spreche wir über einige Best Practices die wir in unseren unzähligen Failover Cluster 2016 Implementierung der letzten 2 Jahre gelernt haben. 

In Teil 1 haben wir einige grundlegenden Cluster Einstellungen behandelt und mit den verschiedenen Netzwerk und deren Bedeutung angefangen. In Teil 2 werden daran anschließen und uns Netzwerkdesigns, die Hyper-V Switch und SMB3 und DMB Direct anschauen.

Hier ein Auszug aus dem Inhalt:

•  Best Practices Cluster Einstellungen 
• Best Practice Networking
• Best Practices Storage
• checkDemo
• checkQ&A

Meldet euch zum Webinar an den es gibt wieder viele Demos und auch ein Webinar Special.

Carsten

On the 7th of September at 5pm CET +2 we will have ​our ​english speaking Failover Cluster Best Practices Webinar Part 2 where we continue with our best practices that we build in numerous Hyper-V Failover Cluster ​pojects over the last years.

After talking in Part 1 of the Webinar ​about some generic Cluster setings ​we started with Cluster Networking.​ In Part 2 we will talk about Network Designs, the Hyper-V Switch and SMB3 and SMB Direct.​

​Here is the Agenda:

• Best Practices Cluster Settings
• Best Practices Networking
• Best Practices Storage
• checkDemo
• checkQ&A

​To sign-up just click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar if you sign-up you will get a link to the recording afterwards.

Carsten

Am 7. September findet Teil 2 unseres Deutsch sprachingen Webinar zu unseren Best Pracitces aus unzähligen Hyper-V Failover Cluster Installationen. Nachdem wir in Teil 1 über am 7. September um 11 Uhr spreche wir über einige Best Practices die wir in unseren unzähligen Failover Cluster 2016 Implementierung der letzten 2 Jahre gelernt haben. 

In Teil 1 haben wir einige grundlegenden Cluster Einstellungen behandelt und mit den verschiedenen Netzwerk und deren Bedeutung angefangen. In Teil 2 werden daran anschließen und uns Netzwerkdesigns, die Hyper-V Switch und SMB3 und DMB Direct anschauen.

Hier ein Auszug aus dem Inhalt:

•  Best Practices Cluster Einstellungen 
• Best Practice Networking
• Best Practices Storage
• checkDemo
• checkQ&A

Meldet euch zum Webinar an den es gibt wieder viele Demos und auch ein Webinar Special.

Carsten

On the 7th of September at 5pm CET +2 we will have ​our ​english speaking Failover Cluster Best Practices Webinar Part 2 where we continue with our best practices that we build in numerous Hyper-V Failover Cluster ​pojects over the last years.

After talking in Part 1 of the Webinar ​about some generic Cluster setings ​we started with Cluster Networking.​ In Part 2 we will talk about Network Designs, the Hyper-V Switch and SMB3 and SMB Direct.​

​Here is the Agenda:

• Best Practices Cluster Settings
• Best Practices Networking
• Best Practices Storage
• checkDemo
• checkQ&A

​To sign-up just click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar if you sign-up you will get a link to the recording afterwards.

Carsten

Da von drei Aufzeichnungen existieren möchte ich diese unten aufführen damit ihr bei intresse diese Anschauen könnt.

Vorweg das eilige: die Early Bird Tickets zur Cloud & DataCenter Conference 2019 sind nur noch bis einschließlich dem 31. Januar buchbar. Dann erhöhen Sich die Preise um €100 beim Premium Ticket und € 200 beim VIP Ticket. Also greift unbedingt noch zu und bucht heute noch euer Ticket wenn Ihr den Preisvorteil mitnehmen wollt.

Einige Infos zur CDC-Germany 2019

Es wird ein super Event und ich bin sicher es wird die beste CDC-Germany die es bisher gab. Wir haben dazu aber einiges zu toppen da die CDC-Germany 2018 von den Teilnehmern top bewertet wurde. Hier einige Zahlen:

Eine Vorlage die nicht so leicht zu übertreffen ist. Damit wir das noch toppen können versuchen wir diesmal noch mehr Top Speaker zu bekommen. Einen kleinen Ausblick seht Ihr bereits bei den Featured Speakern auf der Website. Eine Agenda und Session Liste dauert aber noch da momentan noch der „Call for Speaker“ läuft.

pre-Day Communitys

Ich werde ganz oft per Mail gefragt, ob es auch wieder einen pre-Day Community Tag geben wird. Die Antwort ist JA. Ich bin bereits in Verhandlungen mit der Event Lokation und wir haben auch schon einen Sponsor für das Catering (danke hier an die xces) gefunden. Wir werden wieder eine Hyper-V Community und eine Hybrid Cloud Community parallel veranstalten. Wer also seine Reise plant kann sich den 20. Mai bereits mit vormerken.

Ich hoffe wir sehen uns vom 2. bis 22. Mai in Hanau

Carsten

Am 7. September findet Teil 2 unseres Deutsch sprachingen Webinar zu unseren Best Pracitces aus unzähligen Hyper-V Failover Cluster Installationen. Nachdem wir in Teil 1 über am 7. September um 11 Uhr spreche wir über einige Best Practices die wir in unseren unzähligen Failover Cluster 2016 Implementierung der letzten 2 Jahre gelernt haben. 

In Teil 1 haben wir einige grundlegenden Cluster Einstellungen behandelt und mit den verschiedenen Netzwerk und deren Bedeutung angefangen. In Teil 2 werden daran anschließen und uns Netzwerkdesigns, die Hyper-V Switch und SMB3 und DMB Direct anschauen.

Hier ein Auszug aus dem Inhalt:

•  Best Practices Cluster Einstellungen 
• Best Practice Networking
• Best Practices Storage
• checkDemo
• checkQ&A

Meldet euch zum Webinar an den es gibt wieder viele Demos und auch ein Webinar Special.

Carsten

On the 7th of September at 5pm CET +2 we will have ​our ​english speaking Failover Cluster Best Practices Webinar Part 2 where we continue with our best practices that we build in numerous Hyper-V Failover Cluster ​pojects over the last years.

After talking in Part 1 of the Webinar ​about some generic Cluster setings ​we started with Cluster Networking.​ In Part 2 we will talk about Network Designs, the Hyper-V Switch and SMB3 and SMB Direct.​

​Here is the Agenda:

• Best Practices Cluster Settings
• Best Practices Networking
• Best Practices Storage
• checkDemo
• checkQ&A

​To sign-up just click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar if you sign-up you will get a link to the recording afterwards.

Carsten

This blog post is about the case where a phantom storage pool on disks recuperated from a previous Storage Spaces Direct deployment could not be made writable. The storage pool showed up on a standalone member server in the lab. The pool was not functional, nor did we expect or want it to be functional. We wanted to get rid of it and use the recuperated disks from that old S2D cluster for some other storage spaces testing. As part of getting rid if this old storage pool information we ran into the issue that Set-StoragePool -IsReadOnly $false leads to access denied error.

The Issue

When prepping a number of previously used servers to deploy Storage Spaces Direct there is a nice script available from Microsoft Docs Deploy Storage Spaces Direct in section 3.1 Clean drives.

# Fill in these variables with your values

$ServerList = „Server01“, „Server02“, „Server03“, „Server04“

Invoke-Command ($ServerList) {Update-StorageProviderCacheGet-StoragePool | ? IsPrimordial -eq $false | Set-StoragePool -IsReadOnly:$false -ErrorAction SilentlyContinueGet-StoragePool | ? IsPrimordial -eq $false | Get-VirtualDisk | Remove-VirtualDisk -Confirm:$false -ErrorAction SilentlyContinueGet-StoragePool | ? IsPrimordial -eq $false | Remove-StoragePool -Confirm:$false -ErrorAction SilentlyContinueGet-PhysicalDisk | Reset-PhysicalDisk -ErrorAction SilentlyContinueGet-Disk | ? Number -ne $null | ? IsBoot -ne $true | ? IsSystem -ne $true | ? PartitionStyle -ne RAW | % {$_ | Set-Disk -isoffline:$false$_ | Set-Disk -isreadonly:$false$_ | Clear-Disk -RemoveData -RemoveOEM -Confirm:$false$_ | Set-Disk -isreadonly:$true$_ | Set-Disk -isoffline:$true}Get-Disk | Where Number -Ne $Null | Where IsBoot -Ne $True | Where IsSystem -Ne $True | Where PartitionStyle -Eq RAW | Group -NoElement -Property FriendlyName} | Sort -Property PsComputerName, Count​

Be careful with this as it will clear the disks and their content. Normally this works quite well. I do prefer to tweak it a bit to exclude any USB disks or other disks I do not want to be affected by this script. But this is not the subject of this blog post. We are talking about an issue with:

Get-StoragePool | ? IsPrimordial -eq $false | Set-StoragePool -IsReadOnly:$false -ErrorAction SilentlyContinue

It throws an error:

PS C:Windowssystem32> Get-StoragePool -FriendlyName  „S2D on TaroxCluster“ | Set-StoragePool -IsReadOnly $false

Set-StoragePool : Access deniedExtended information:Access is denied. Recommended Actions:- Check if you have the necessary privileges to perform the operation.Activity ID: {7480dd11-3547-4ade-aef4-3f8ae460d7c7}At line:1 char:56+ … endlyName  „S2D on TaroxCluster“ | Set-StoragePool -IsReadOnly $false+                                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    + CategoryInfo          : PermissionDenied: (StorageWMI:ROOT/Microsoft/…_StorageCmdlets) [Set-StoragePool], CimException    + FullyQualifiedErrorId : StorageWMI 40001,Set-StoragePool

Normally this works fine and you need to do this or otherwise you run into problems when you try to remove virtual disks later in the script. This is clear when we try it out on its own and see the following error:

Error deleting virtual disk: The storage pool could not complete the operation because its configuration is read-only.

Basically, that means the storage pool is not writable, which is why the first thing the script does is make the storage pool writable. But that failed with an “access denied” error.

This also means we could not delete the storage pool, due to it being read only. We’re pretty much stuck and we need to fix this.

Figuring out what’s causing the problem

Let’s take a closer look at our problematic storage pool via:

Get-StoragePool -FriendlyName  „S2D on TaroxCluster

FriendlyName OperationalStatus HealthStatus IsPrimordial IsReadOnly Size AllocatedSize———— —————– ———— ———— ———- —- ————-S2D on TaroxCluster Read-only Unknown False True 22.77 TB 16.23 TB

We can see that the Operational Status is read-only and “IsReadOnly” Is set to true. The normal fix can is to make the storage pool writable via PowerShell with:

Get-StoragePool -FriendlyName  „S2D on TaroxCluster“ | Set-StoragePool -IsReadOnly $false

That does not work. I keep getting an access denied error. A well-known reason for this error is that you are trying to run this PowerShell commands without administrative privileges. This is not the reason in this case, I made sure of that.

So I dive in a little deeper and list all the details of the Get-StoragePool command:

Get-StoragePool -FriendlyName „S2D on TaroxCluster“ | fl *

PS C:Windowssystem32> Get-StoragePool -FriendlyName „S2D on TaroxCluster“ | fl *Usage : OtherOperationalStatus : Read-onlyHealthStatus : UnknownProvisioningTypeDefault : FixedSupportedProvisioningTypes : {Thin, Fixed}MediaTypeDefault : UnspecifiedReadOnlyReason : By PolicyRepairPolicy : ParallelRetireMissingPhysicalDisks : NeverWriteCacheSizeDefault : AutoVersion : Windows Server 2019FaultDomainAwarenessDefault : StorageScaleUnitObjectId : {1}\TAROXS2D4root/Microsoft/Windows/Storage/Providers_v2SPACES_StoragePool.ObjectId=“{76bbc2fd-c8a2-11e8-8546-806e6f6e6963}:SP:{50aadde0-2fc3-4457-b701-fe8460df7b32}“PassThroughClass : PassThroughIds : PassThroughNamespace : PassThroughServer : UniqueId : {50aadde0-2fc3-4457-b701-fe8460df7b32}AllocatedSize : 17846662856704ClearOnDeallocate : FalseEnclosureAwareDefault : FalseFriendlyName : S2D on TaroxClusterIsClustered : TrueIsPowerProtected : TrueIsPrimordial : FalseIsReadOnly : TrueLogicalSectorSize : 4096Name : OtherOperationalStatusDescription : OtherUsageDescription : Reserved for S2DPhysicalSectorSize : 4096ResiliencySettingNameDefault : MirrorSize : 25033928867840SupportsDeduplication : TrueThinProvisioningAlertThresholds : {70}WriteCacheSizeMax : 18446744073709551614WriteCacheSizeMin : 0PSComputerName : CimClass : ROOT/Microsoft/Windows/Storage:MSFT_StoragePoolCimInstanceProperties : {ObjectId, PassThroughClass, PassThroughIds, PassThroughNamespace…}CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties

I noticed a couple of things (yellow highlights). The health status is unknown. The reason for being read only is “By Policy”.  This could lead you to investigate disk policies for storage, but that would be a diversion at best. When we look at the individual disks most of them are visible in disk manager and diskpart but they are also offline due to a policy. Changing the policy in diskpart will not help and trying to get the disk to come on line fail with an access denied and write errors. This is not the path to follow.

In Server Manager, Storage Pools we see that the “Managed By” and “Available to” are blank. The storage pool is set to Read only.

The second thing that I noticed, even when I knew this before, is that the friendly name “S2D on TaroxCluster” reminded me of the fact the Storage Pool belonged to a cluster before as indicated by “IsClustered” being true.

Diagnosis

While a functional storage pool will also be off line after a reinstall of the OS, an in-place upgrade or moving them to a new server it normally can be brought on line quite quickly. But not here, it doesn’t work, there is no cluster and the storage pool is clustered. When the storage pool is a cluster resource it is normally made writable by bringing the pool on line. But as this node isn’t part of a cluster anymore so that won’t work. We don’t even have the cluster tools installed anymore on this server.

We can also normally use the Storage Pools page of Server Manager. When the storage pool is “read-only” you’ll have and option Set Read-Write Access when you right-click the storage pool. That doesn’t work, just like the PowerShell commands do not work. All options are blanked out and not available.

Basically, the metadata on the disks is showing us the phantom storage pool from a former S2D deployment, where that pool is a cluster resource. The disks in this server have come from other nodes and the metadata on there is preventing us form reusing them. The fact that they were part of an S2D cluster deployment holds the key to the fix.

The Solution

Once I realized that the fact that this storage pool thinks it is part of a cluster that isn’t around anymore prevents us changing the properties and cause the “Access denied” error I came up with a plan.

In the end, I created a 1 node on the host with the disks. I added the storage pool to the cluster pools…

The existing Storage Pool was found and I clicked OK to add it.

That made the storage pool managed by the cluster. Normally you can bring the storage pool online with a cluster to make it writable. That would not work here as the storage pool only exists on the metadata on some of the disks and not in real life.

The trick then was to remove the storage pool from the cluster as shown below.

You confirm this is what you want and that’s it…

Once I did that it was still read-only. But now the command Get-StoragePool -FriendlyName „S2D on TaroxCluster“ | Set-StoragePool -IsReadOnly $false could be run successfully.

Finally, I got to run the script to clean the drives from any remaining metadata from the disks. After that I had all of my NVMe, SSD and HDD disks available to build a new storage spaces set up.

Conclusion

Never give up. Things can and will confuse you now and then. That’s normal. It is OK you need some time to investigate and figure out what has happened to a system. Take that time and once you’ve wrapped your head around the context you will likely come up with some ideas to try and solve the issue at hand. You can figure it out. I hope this helps some of you when you run into a storage pool that cannot be made writable in any way. Thank you for reading!

When you are testing designs, validating implementations or giving demos Performance Monitor is your friend. It pays to spend a little time to learn about it in order to use it better and be more productive.

The tool is not perfect and it has its (annoying) idiosyncrasies like any other tool. It also has its little gems. Overall it is a very useful tool for Windows systems engineer at any experience level.

Standard behavior of perfmon

One of the “annoying” things about perfmon is that by default it does not save a configuration. Every time you close it you have to rebuild perfmon to show the desired counters, set the correct scale, colors, background etc. This can be time consuming and is rather annoying when you are giving demos as you need a long time to prepare your perfmon environment. It becomes outright frustrating during testing. You might find you need to remove and add counters over and over again. This is due to the fact that very often, after changing settings the counters for an object, the counters stop working. Reconfiguring network settings are a prime example of this.

Default Perfmom behavior: your configuration and counter settings are not persisted

The default behavior of Performance Monitor gives you the option to define Data collector sets and open reports next to to adding performance counters and customizing your settings. But all the work you have done in regards to the configuration and visualization of the counters are gone after you close Performance Monitor.

There is a good way to avoid this frustration. Use Perfmon /sys from the command line.

Benefits of Perfmon /sys

Persistence under your Windows user profile

When you run perfmon /sys it will remember the configuration and the counters. The first use case of this just to make sure the default counters you like to see are always there. And as it remembers the configuration the layout, colors, scaling, background are also there. That’s a big improvement over the default.

Perfmon /Sys behavior: you changes are persisted to your Windows user profile

As these settings are persisted under your windows user profile. That’s nice but what if I want to have preconfigured perfmon configurations available on multiple systems or you want to share them with colleagues or customers?

Persistence to a file

The good news is that you can persist your favorite Perfmon configurations to a file. That means that you can create a collection of them for various use cases and scenarios. You can share these between users and systems.

Save your Perfmon /sys settings to files for resuse, sharing and portability

I hope it goes without saying that the ability to share is dependent on the counters you use. When you have Mellanox RDMA cards in some servers and not in another that won’t work. But other than that, it is all pretty straight forward.

When you’re testing you also tend to disable and enable devices such as network or Fibre Channel cards. Some 3^rd party counters tend to survive such operations but both the inbox native counters and 3^rd party counters do not. The counters stop working. You end up having to remove the counters and add them again just to get ‘m working again. As said, when you do a lot of testing this becomes a drag. Closing a your perfmon down and opening your PerfmonCfg file make it all a lot more convenient and faster. I know it saves me a ton of time.

The histogram idiosyncrasy

A small idiosyncrasy exists when opening a PerfmonCfg of a persisted histogram layout. Opening a report or a line layout you saved works very well. When you save and open a histogram layout it opens the layout as line. The histogram option is shown as selected in the file menu and configuration but not visualized. All your settings are persisted, it is only a cosmetic issue. The workaround is to switch to another layout and back to histogram after which it correctly. It’s been around for a long time and it seems it might never get fixed.

Conclusion

Fore demonstration and test purposes, running perfmon /sys is a time saver. The settings are persisted in your user profile. By saving these setting to a PerfmonCfg file your customized Perfmon settings becomes portable.  You can add it to your presentation files to open quickly manually or via a demo script. Whether you’ll use this during demo’s, POCs, verification of an installation … it’s a great way to quickly show predefined reports of real time data. This has been of very much help to during presentations and testing. I hope you find it useful as well. No, I am convinced you will, just give it a try!

• Teil 1 – Was ist Storage Spaces Direct?
• Teil 2 – Grundlegende Anforderungen für Storage Spaces Direct
• Teil 3 – SSD und NVMe, DWPD, TBW und PBW berechnen und verstehen
• ​Teil 4 – Netzw​​​​​erkdesign bei Storage Spaces Direct
• Teil 5 – SMB 3 und SMB Direct

​​​SMB 3 und SMB Direct spielen​ bei Storage Spaces Direct eine wichtige Rolle. Daher möchte ich mich in diesem Blogpost näher mit diesen Protokollen beschäftigen. 

​​Der Vorläufer des  SMB (Server Messaging Block) Protokoll ​​hat seine Wurzel bereits im​ Windows für Workgroups 3.11. Ursprünglich wurde SMB von IMB entwickelt. ​​Im Laufe der Jahre wurde das SMB Protokoll in den verschiedenen Betriebssystemversionen von Micrsoft weiterentwickelt. Bis mit Windows Server 2012 das SMB Protokoll mit der Version 3.0 zur Verfügung steht.

​Mit Einführung von Windows Server 2012 bekam das SMB Protokoll einige sehr interessante ​​Verbesserungen wie

• SMB Multichannel
• SMB Direct
• ​SMB ​Verschlüsselung
• SMB Transparent Failover
• usw..

​Diese Verbessungerungen spielen ​auch bei Storage Spaces Direct eine große Rolle, daher möchte ​an dieser Stelle auf die einzelnen Punkte eingehen.

​SMB Multichannel

​SMB Multichannel ermöglicht ​die Zusammenfassung von Netzwerkbandbreite und Netzwerkfehlertoleranz, wenn zwischen dem SMB 3.x Client und dem SMB 3.x Server mehrere Netzwerkpfade verfügbar sind.

• Geschwindigkeit
  • Bandbreiten-Aggregation durch Nutzung mehrer Kanäle
  • Standard für Netzwekkarten mit RSS Support sind 4 Kanäle
  • Verteilung der Prozessor-Belastung auf mehrere Cores (RSS Support)
• Failover
  • Implementiert Ende-zu-Ende Ausfall Erkennung
  • Benutzung von NIC-Teaming möglich
• Automatische Konfiguration
  • SMB erkennt automatisch das Vorhandensein mehrerer verfügbarer Netzwerkpfade  und ​fügt diese Verbindung bei Bedarf dynamisch dazu
  • Für NICs abschaltbar

​Beispiele für SMB Multichannel

​Einzelne Netzwerkkarte mit RSS Support​​Eine typische Konfiguration besteht aus einem SMB Client und einen SMB Server, die z.B. jeweils mit einer 10 Gbit Netzwerkkarte ausgestattet sind. Ohne SMB Multichannel wird nur ein TCP/IP Kanal aufgebaut, diesen nutzt das SMB​ Protokoll. ​Dieser TCP/IP Kanal wird ​einem CPU-Kern zugewiesen. Dies ist standardmäßig der Core 0, der auch vom Betriebssystem genutzt wird. Hier kann es leicht zu einer Auslastung der CPU-Kerns kommen. Ein ​CPU-Kern ist in der Lage ca. 3 Gbit Netzwerk Traffic zu verarbeiten. ​Dadurch kann die Bandbreite der 10 Gbit Netzwerkkarte ohne SMB Multichannel und RSS nicht genutzt werden.Verwenden wir SMB Mulitchannel ​in Verbindung mit einer RSS (Receive Side Scaling) fähigen Netzwerkkarte können ​mehrere TCP/IP Kanäle aufgebaut und vom SMB Protokoll genutzt werden. Jeder TCP/IP Kanal wird einem CPU​-Kern zugewiesen. Somit ist die Last auf ​mehrere CPU-Kerne ​verteilt, dadurch kann ein Engpass auf einem einzigen CPU-Kern vermieden werden. Die Bandbreite der Netzwerkkarte kann voll genutzt werden.​​Mehrere Netzwerkkarten​wird in einer Umgebung mit mehreren Netzwerkkarten kein SMB Multichannel genutzt, so ​kann nur ein TCP/IP Kanal auf einer Netzwerkkarte aufgebaut werden, der dann vom SBM Protokoll genutzt ​wird.​ In diesem Fall ist es nicht möglich die Bandbreite der verfügbaren NIC zusammenzufassen. Bei Ausfall dieser Netzwerkkarte wird die Verbindung getrennt.​Mit RSS (Receive Side Scaling) ​Support für die Netzwerkkarten in Verbindung mit SMB Multichannel ermöglicht es, über alle ​Netzwerkkarten der gleichen Geschwindigkeit, mehrere TCP/IP Kanäle, die verschiedenen CPU-Kernen zugewiesen werden, gemeinsam zu nutzen. Dies verteilt die Last auf mehrere CPU-Kerne und ermöglicht es die volle Bandbreite der verfügbaren Netzwerkkarten zu nutzen.Bei Netzwerkkarten ohne RSS Support kann mit SMB Multichannel nur jeweils ein TCP/IP Kanal pro Netzwerkkarte aufgebaut werden.Bei SMB Multichannel Nutzung kann eine Netzwerkkarte ausfallen, ​der Traffic ​geht über die verbliebene Netzwerkkarte. Es können auch dynamisch Netzwerkkarten der gleichen Geschwindigkeit zugeschaltet werden.​Netzwerkkarten Team​Beim Netzwerkkartenteams ohne SMB Multichannel sehen wir in der Abbildung untern nur einen TCP/IP Kanal. Warum ist das so? Nun für den SMB Client und dem SMB Server ist der Team-Adapter eine NIC und über diese kann er nur eine TCP/IP Verbindung aufbauen. Einziger Vorteil hierbei, fällt der eine Team-Adapter aus, so kann die Verbindung über den zweiten Team Adapter neu aufgebaut werden.​Steht dem Netzwerkkartenteam SMB Mulitchannel und RSS zur Verfügung, ​können, wie hier im Beispiel aufgezeigt, bei den 10 Gbit Karten nur insgesamt 4 TCP/IP Kanäle aufgebaut werden. ​Auch hier ​sieht der SMB Client und SMB Server​ nur eine NIC. Da wir bei SMB Multichannel auch ohne Team einen transparenten Failover haben, macht das Netzwerkkartenteam für reine SMB Anwendungen keinen Sinn. Denn ohne das Netzwerkkartenteam könnten wir bei den 2 10 Gbit NICs imsgesamt 8 TCP/IP Kanäle aufbauen. Ein weiterer Nachteil des Netzwerkkartenteams ist, dass die RDMA Funktionalität der Netzwerkkarten für den Team-Adapter nicht mehr zur Verfügung steht.Unsere Empfehlung:​Bei SMB Multichannel Anwendungen wie Storage Spaces Direct kein Netzadapterteam für den SMB Traffic.​Mehrere RDMA Netzwerkkarten​​Ohne SMB Multichannel, kann nur eine TCP/IP Verbindung aufgebaut werden.Mit SMB Multichannel plus der RDMA Fähigkeit der Netzwekkarte können sehr hohe Bandbreiten übertragen werden, ohne das die CPU der Server dadurch belastet wäre. Pro Netzwerkkarte werden zwei RDMA Verbindungen erstellt.

​SMB Direct (SMB über RDMA)

Vorteile von SMB Direct:

• schnelle Netzewrkkommunikation aus dem HPC (High-Performance Computing)
• SMB Direct nutzt RDMA um Daten zwischen Hosts zu übertragen
  • hoher Durchsatz
  • geringe Latenz
  • geringe Prozessorbelastung
• alle Möglichkeiten von SMB Multichannel
• Implementierungen
  • Infiniband – bis 100 Gbit auf Infiniband Switchen
  • RoCE – 100 Gbit mit Ethernet Switche die DCB unterstützen
  • iWarp – 100 Gbit mit Ethernet Switche
• Für Storage Spaces Direct wird von Microsoft RoCE und iWarp supportet.

​SMB Verschlüsselung

• Ende-zu-Ende Verschlüsselung der SMB Daten
  • Schützt die Daten auf der Leitung
  • Nutzt vorhandene SMB Session Schlüssel um Schlüssel abzuleiten
• Nutzt den AES-CCM Algorithums
• keine Deploymentkosten
  • keine spezielle Hardware notwendig
  • keine iPSec Infrastruktur notwendig
• Konfigurierbar pro Share oder für den ganzen Server

​SMB Transparentes Failover

• Der Failover ist transparent für die Anwendungen
  • zero downtime
  • kurzzeitiger I/O-Delay während des Failovers
• ​Unterstützt geplante und ungeplante Faiovers
  • Hardware/Software Wartung
  • Hardware/Software Ausfälle
  • Load Balancing / Client Redirection
• Resilierend für Datei- und Verzeichnisoperationen

• Funktioniert mit beiden Typen des Dateiservers im Cluster
  • Scale-Out File Server
  • „Classic“ File Server
• Anforderungen:
  • ab Windows Server 2012 Failover Cluster
  • SMB Client mit SMB 3.0
  • Dateifreigaben sind mit „Continuously Availability“ Eigenschaften konfiguriert

​So, das soll es für heute gewesen sein, in meinem nächsten Blog Teil 6 zu dieser Serie wird es um die RDMA Einstellungen für Storage Spaces Direct gehen.Viel Spass bis dahin​Petra

Alle fünf Teile

Im folgenden finden Sie die Links zu den fünf Beiträgen. Sollte ein Link noch nicht vorhanden sein, liegt es daran, dass er noch nicht veröffentlicht wurde.

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 1– Architektur und Netzwerk Topologie

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 2– SDN Deployment und eine Lab-Umgebung mit dem Netzwerk Controller

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 3– Software Load Balancing 

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 4– RRAS Gateways

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 5

Zusammenfassung

In den vorangegangenen Blogposts habe ich versucht, einige der Testszenarien, die Petra Lipp und ich bei unserer Session auf der CDC 2018 präsentiert haben sowie den Testaufbau unserer Lab-Umgebung etwas detaillierter zu beschreiben.

Das Ganze habe ich in einem Whitepaper zusammengefasst, das Sie als PDF-Datei erhalten können, wenn Sie sich für unseren Newsletter registrieren. 

Nun ist das nur ein Bruchteil dessen, was die Microsoft SDN-Technologie bietet. Was wir hier überhaupt nicht weiter betrachtet haben, sind Remote Szenarien, um z.B. ein Unternehmensnetz mit einem VMnet in unserer SDN-Umgebung zu verbinden.

Eine weitere Herausforderung wäre auch, wie Service Provider SDN-Technologien ihren Kunden über Self Service Portale anbieten können. Eine Lösung dafür wäre z.B. das gute alte Windows Azure Pack, das sich hervorragend in eine SDN-Umgebung integrieren lässt. Petra und ich haben auf der CDC2018 auch dazu eine Session gehalten und die Implementierung eines Kunden vorgestellt.

Hierzu müssten wir aber unsere Lab-Umgebung noch um weitere Infrastruktur- und Remote-Systeme erweitern, was aber irgendwann unsere Ressourcen und den Rahmen dieses Whitepapers sprengen würde.

Bei Bedarf können wir gerne in weiteren Dokumenten und persönlichen Beratungsgesprächen darauf eingehen. Im Moment kann ich Sie nur auf die offizielle Microsoft Dokumentation in der TechNet-Library verweisen, die zugegebenermaßen zumindest in der englischen Originalfassung mal relativ ausführlich und gut verständlich ist. Die (maschinelle) deutsche Übersetzung sollten Sie mit Vorsicht genießen.

Neben dieser offiziellen Dokumentation gibt es auch noch eine Reihe sehr empfehlenswerter Blog-Beiträge verschiedener Microsoft Gurus und MVPs, die mir beim Erstellen und dem Aufbau der Lab-Umgebung wertvolle Informationen geliefert haben. Ohne Anspruch auf Vollständigkeit möchte ich hier auf folgende Artikelserien verweisen (in Englisch):

Schumann Ge’s Blog: Deploying SDN on One single physical host using VMM

Larryexchange Blog

• Step-by-step for deploying a SDNv2 using VMM – Part 1-4
• Configure WAP to support new SDN stack on Windows Server 2016

Und die Entwicklung wird weitergehen. Im Herbst dieses Jahres wird die nächste Version von Windows Server unter dem Namen Windows Server 2019 erscheinen und voraussichtlich einige Neuerungen zum Thema SDN bringen, über die wir natürlich zeitnah berichten werden.

Skript Download Details

In dieser Blog-Serie habe ich einige PowerShell Skripte beschrieben, die ich mir zusätzlich zu den von Microsoft auf GitHub bereitgestellten erstellt habe, um Aktionen, die mit vielen Mausklicks verbunden sind, etwas zu vereinfachen. Diese zusätzlichen Skripte habe ich in einer .ZIP-Datei zusammengestellt, die Sie hier downloaden können. Nachstehend finden Sie Details zum Inhalt dieser .ZIP-Datei.

Dateiname: VMM-SDN.zip – Entpacken Sie den Inhalt dieser Datei in das SDN-Master Verzeichnis, das Sie nach dem Download der Microsoft Skripte aus GitHub erstellt haben.

Inhalt:

VMM\scripts\CreateTenantVMnet-Red.ps1 – erzeugt das Red VMnetVMM\scripts\CreateTenantVMnet-Green.ps1 – erzeugt das Green VMnetVMM\scripts\CreateTenantVMnet-Red.ps1 – erzeugt VIP im PublicVIP-Netz für den Red TenantVMM\scripts\CreateTenantVMnet-Green.ps1 – erzeugt VIP im PublicVIP-Netz für den Green TenantVMM\VMM SDN Express\Fabricconfig-SDNcloud-Production.psd1 – Konfigurationsdatendatei für das Deployment der Lab-Umgebung mit VMMexpress.ps1

Danke

Ich danke ihnen, dass Sie bis zum Ende dieser Blog-Serie mit dabei waren und hoffe, dass ich Ihnen einen Überblick geben konnte zu den Microsoft SDN Technologien mit Windows Server 2016 und dem SCVMM 2016 und Ihnen auch zeigen konnte, wie Sie eine SDN-Umgebung mit Hilfe der von Microsoft auf GitHub bereitgestellten PowerShell Skripte ausrollen können.

Für weitere Fragen, Anregungen und Kommentare stehen wir gerne zur Verfügung.

• ​Deutsch Sprachiges Webinar
• ​Englisch sprachiges Webinar

Am 7. November um 17 Uhr habe ich einen echten Knaller für euch: Cosmos Darvin (Microsoft Product Manager im Storage Spaces Direct Team) präsentiert für uns die Neuerungen in Microsoft Storage Spaces Direct 2019.

Hier ein Auszug aus dem Inhalt:

•  DeDup 
• Two Node Cluster Enhancements
• Windows Admin Center
• Performance Statistics
• checkDemo
• checkQ&A

Meldet euch zum Webinar an den es gibt wieder viele Demos und auch ein Webinar Special.

Carsten

On the 7th of November at 5pm CET we have the Webinar for all Storage Spaces direct intrested people: Cosmos Darvin (Microsoft Program Manager in the Storage Spaces Direct Team) will present What’s new in Microsoft Storage Spaces Direct 2019.​

Here is a peek into the Agenda:

• DeDUP
• New from 2 Node Deployment
• Windows Admin Center
• Performance Statistics
• checkDemo
• checkQ&A

​To sign-up just click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar if you sign-up you will get a link to the recording afterwards.

Carsten

Die unerwartete Konsequenz hieraus ist, das es keine oder nur sehr wenige für Windows Server 2019 zertifizierte Hardware gibt. Und ich meine nicht ganze Server Systeme, sondern HBAs, SSDs, NVMEs, Netzwerkkarten, etc.).

Jetzt kommt es aber noch dicker: da es für Support mit Storage Spaces Direct Installation erforderlich ist, das alle verwendeten Komponenten im Windows Server Catalog aufgeführt und für Windows Server 2019 zertifiziert sind können im Moment keine Storage Spaces Direct 2019 System mit Support gebaut oder bestehende Installation auf Windows Server 2019 upgedatet werden!

Damit man nicht aus Versehen Storage Spaces Direct oder Software Defined Networking mit Windows Server 2019 installiert hat Microsoft eine Warnung beim Versuch eingebaut:

Fehlermeldung nach Enable-ClusterS2D -Verbose

PS C:\> Enable-ClusterS2D -VerboseEnable-ClusterStorageSpacesDirect : Microsoft recommends deploying SDDC on WSSD[https://www.microsoft.com/en-us/cloud-platform/software-defined-datacenter] certified hardware offerings for production environments. The WSSD offerings will be pre-validated on Windows Server 2019 in the coming months. In the meantime, we are making the SDDC bits available early to Windows Server 2019 Insiders to allow for testing and evaluation in preparation for WSSD certified hardware becoming available. Customers interested in upgrading existing WSSD environments to Windows Server 2019 should contact Microsoft for recommendations on how to proceed. Please call Microsoft support [https://support.microsoft.com/en-us/help/4051701/global-customer-service-phone-numbers].At line:1 char:1+ Enable-ClusterStorageSpacesDirect -Verbose+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ CategoryInfo : InvalidOperation: (MSCluster_StorageSpacesDirect:root/MSCLUSTER/…ageSpacesDirect) [Enable-ClusterStorageSpacesDirect], CimException+ FullyQualifiedErrorId : HRESULT 0x80070032,Enable-ClusterStorageSpacesDirectEnable-ClusterStorageSpacesDirect : Failed to run CIM method EnableStorageSpacesDirect on theroot/MSCLUSTER/MSCluster_StorageSpacesDirect CIM object. The CIM method returned the following error code: 50At line:1 char:1+ Enable-ClusterStorageSpacesDirect -Verbose+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ CategoryInfo : InvalidResult: (MSCluster_StorageSpacesDirect:String) [Enable-ClusterStorageSpacesDirect], CimJobException+ FullyQualifiedErrorId : CimJob_EnableStorageSpacesDirect_50,Enable-ClusterStorageSpacesDirect

PS C:\>

Diese Warnung kann man abschalten und Storage Spaces Direct trotzdem installieren, wenn man einen Registry Key einträgt. Den Key bekommt man, wenn man sich an den Microsoft Support wendet (soll kostenlos sein).

Hierzu gibt es auch einen Blogpost von Cosmos Darwin (Senior Program Manager im Windows Core OS Team) Hyper-converged infrastructure in Windows Server 2019 – the countdown clock starts now! der dieses Verhalten eingehend beschreibt.

Die Herausforderung

Da es sich bei der Migration um diese erste handelt, bei der UEFI mit ins Spiel kommt, bin ich eigentlich davon ausgegangen, dass ich unter Hyper-V eine Generation 2 VM erstelle und das ursprüngliche Hardware-System dort wiederherstelle. Das hat sich allerdings als falsch herausgestellt, ich habe die VM als Generation 2 nicht zum laufen bekommen. Nach einer kurzen Recherche bin ich dann auf diverse Hinweise gestoßen, dass die VM als Generation 1 betrieben werden muss. Das alleine reicht allerdings nicht aus, es muss auch noch an dem Layout der virtuellen Festplatte etwas angepasst werden, damit die VM überhaupt wieder startet. Diese Schritte zeige ich hier einmal auf.

Sicherung (P2V) des Hardware Servers

Der ganze Prozess startet damit, dass das Hardware-System übernommen wird und in die Virtualisierung überführt wird. Hierzu stehen einige Programme zur Verfügung, ich für meinen Fall habe Disk2VHD von Microsoft genutzt.

Wichtig ist hierbei, dass auf die Volume Shadow Copy-Funktion zurückgegriffen wird. Weiterhin sollten so viele Dienste/Programme wie möglich beendet werden, damit möglichst wenig Dateien im Zugriff sind. In meinem Fall lief auf dem Server eine Applikation inkl. Datenbank, ich habe sämtliche Dienste und Programme vor der Migration geschlossen und darauf geachtet, dass niemand sonst am Server angemeldet ist.

Tipps für eine erfolgreiche Migration

Falls der Server mehrere Partitionen / RAIDs hat, lege ich pro Partition eine eigene VHDX an. Windows hat so eine VHDX-Datei, die Applikationen oder Datenbanken dann eine zweite.Erstellen Sie vor der Migration ein kleines Logfile, welches die folgenden Informationen enthält:- IP-Informationen (Adresse, Subnetz, GW, DNS, … ipconfig /all halt)- Laufwerksbuchstaben, Zuordnung usw (get-volume in der PowerShell)- Sonstige Besonderheiten, die ggf. später nicht mehr abgefragt werden können

Nachbearbeitung der Boot-VHDX-Datei

Ist Disk2VHD erfolgreich durchgelaufen, ist vor der Erstellung und dem Start der VM ein wichtiger Schritt notwendig: Die Konvertierung der virtuellen Festplatte von GPT auf MBR. Dies ist wichtig, da sonst die VM im späteren Verlauf nicht booten würde. Es gibt verschiedene Möglichkeiten diese Konvertierung zu machen, am einfachsten funktioniert es mit dem AOMEI Partition Assistent Standard. Die Software ist kostenlos und darf sofort für den privaten Gebrauch als auch für den kommerziellen genutzt werden (zumindest laut der Webseite des Herstellers, keine Garantie hierfür von meiner Seite). Einschränkung der kostenfreien Version: Sie funktioniert „nur“ auf einem Client-OS. Das bedeutet, man braucht entweder ein Windows 8/8.1/10 in einer VM, oder man erwirbt die Server-Edition.

Tipp: Da wir im nächsten Schritt eine Anpassung der VHDX machen, empiehlt sich hier vorher ein Backup zu erstellen, da sonst im dümmsten Fall die Konvertierung noch einmal gemacht werden müsste.

Hängen Sie die VHDX an die Windows-VM an und installieren Sie den AOMEI Partition Manager. Nach dem Start von AOMEI müssen wir die zweite Festplatte (unsere konvertierte VHDX-Datei) auswählen und in einen MBR-Datenträger umwandeln.

Nach der Auswahl der Schritte, die durchgeführt werden müssen, muss der eigentliche Vorgang nochmal gestartet und durchgeführt werden, da wir sonst nicht fortfahren können. Dies geschieht über den Button Ausführen oben links.

Nach der Konvertierung müssen wir alle kleinen Partitionen entfernen, die sich vor der eigentlichen Datenpartition befinden. Klicken Sie die Partition an und entfernen Sie diese. Achten Sie darauf, dass Sie in der Software nochmal die zusammengeklickten Schritte bestätigen, damit diese auch durchgeführt werden. In meinem Fall war nur noch eine Partition vorhanden.

Nachdem wir nun die Anpassung der Festplatte gemacht haben, müssen wir im zweiten Schritt die eigentliche Partitionsstruktur wieder reparieren (lassen). Fahren Sie dazu die VM herunter und entfernen Sie die VHDX-Datei aus der Konfiguration der VM.

Anlegen einer neuen VM

Erstellen Sie eine neue VM und achten Sie darauf, dass es sich um eine Generation 1 VM handelt. Weisen Sie ausreichend RAM und virtuelle CPUs zu (entsprechend Ihrer Hardware oder mehr/weniger, je nach Ausstattung des Servers) und hängen Sie die im vorherigen Schritt bearbeitete VHDX-Datei an den ersten IDE-Controller an Port 0 an. Neben der Festplatte brauchen wir noch ein DVD-Laufwerk, in das eine ISO von Windows Server 2016 eingelegt wird (davon ausgehend, dass es sich auch um ein Windows Server 2016 handelt in der konvertierten VHDX-Datei).

Die Reparatur der Partitionsstruktur

Starten Sie die VM und starten Sie von der Windows ISO-Datei. Direkt am ersten Bildschirm drücken Sie die Tastenkombination Shift+F10. Dies öffnet eine Eingabeaufforderung, in der wir nun weitere Arbeiten durchführen können. Wir beginnen mit der Konfiguration der Festplatte als aktiver Datenträger, dies kann mit dem Tool diskpart gemacht werden. Führen Sie in der Eingabeaufforderung die folgenden Befehle nach und nach aus:

• diskpart
• list disk
• select disk 0
• list partition
• select partition 1
• active
• exit

Starten Sie nun die VM neu und starten Sie erneut von der ISO-Datei. Öffnen Sie direkt wieder mit Shift+F10 eine Eingabeaufforderung. Nun reparieren wir den Bootrecord der Festplatte mit den folgenden drei Befehlen:

• bootrec /fixmbr
• bootrec /fixboot
• bootrec /rebuildbcd

Der dritte Befehl sucht auf den Festplatten nach vorhandenen Windows-Installationen. Hier sollte nach kurzer Zeit eine Installation gefunden werden. Diese müssen Sie dann mit einem J bzw. Y im englischen hinzufügen.

Nach der Ausführung dieser drei Befehle muss die VM erneut neu gestartet werden, wir starten ein drittes Mal in das Setup der ISO-Datei. Nun müssen wir die Windows Reparatur-Optionen auswählen (Das ist wichtig, ein einfaches Shift+F10-Fenster reicht nun nicht mehr aus!).

Hier zwei abschließende Befehle absetzen:

• cd recovery
• startrep.exe

Nach der Ausführung von StartRep.exe beginnt die Reparatur, dies dauert einige Minuten.

Der erste Start der VM

Die ISO-Datei kann nun aus dem Laufwerk entfernt werden und die VM kann das erste Mal gestartet werden. Hat alles geklappt, sollten Sie hier ein Windows Bootscreen sehen und die VM startet bis zum Lockscreen. Der erste Startvorgang kann einige Minuten dauern, je nach Ausstattung der VM, ob Netzwerk erkannt wird (oder eben nicht) und wie schnell die Datenträger im Hyper-V Host sind. Falls die VM nicht startet, überprüfen Sie ob alle Einstellungen und Befehle, die weiter vorne in diesem Artikel beschrieben werden, durchgeführt haben und ob alles ohne Fehlermeldung funktioniert hat.

Weitere Nacharbeiten

Nun stehen noch einige Dinge an, die erledigt werden müssen, damit das System wieder lauffähig ist. Dazu gehören die folgenden Dinge:

Netzwerk

Setzen Sie wieder die vorher genutzte IP-Adresse sowie weitere Einstellungen (Gateway, DNS usw.)

Alte / Nicht mehr vorhandene Hardware

Räumen Sie alte Hardware auf und entfernen Sie die entsprechenden Einträge im Geräte-Manager. Komponenten wie RAID-Controller, Netzwerkkarten usw. Ihrer Hardware werden jetzt in der Virtualisierung nicht mehr benötigt, also können diese entfernt werden. Dies geht entweder per Hand (doof, weil immer nur ein Eintrag gleichzeitig entfernt werden kann) oder mit Unterstützung von Tools. Mein Favorit ist das Device Cleanup Tool von Uwe Sieber, hiermit können alle nicht mehr vorhandenen Einträge gleichzeitig gelöscht werden.

Windows Aktivierung

Teilweise kann es sein, dass das Windows OS neu aktiviert werden muss. Ein kurzer Blick in die System-Eigenschaften zeigt, ob dies bei Ihnen der Fall ist.

Updates

Jetzt ist vielleicht ein guter Moment, Windows Updates einzuspielen, damit das System aktuell ist.

Backup

Denken sie unbedingt daran, dass konvertierte System in Ihr Backup mit aufzunehmen. Klingt banal, kann aber vergessen werden. Kommt es im späteren Verlauf zu Datenverlust und Sie haben kein Backup, wäre dies blöd. Sie wissen ja: Kein Backup, kein Mitleid! :)

Am 7. September findet Teil 2 unseres Deutsch sprachingen Webinar zu unseren Best Pracitces aus unzähligen Hyper-V Failover Cluster Installationen. Nachdem wir in Teil 1 über am 7. September um 11 Uhr spreche wir über einige Best Practices die wir in unseren unzähligen Failover Cluster 2016 Implementierung der letzten 2 Jahre gelernt haben. 

In Teil 1 haben wir einige grundlegenden Cluster Einstellungen behandelt und mit den verschiedenen Netzwerk und deren Bedeutung angefangen. In Teil 2 werden daran anschließen und uns Netzwerkdesigns, die Hyper-V Switch und SMB3 und DMB Direct anschauen.

Hier ein Auszug aus dem Inhalt:

•  Best Practices Cluster Einstellungen 
• Best Practice Networking
• Best Practices Storage
• checkDemo
• checkQ&A

Meldet euch zum Webinar an den es gibt wieder viele Demos und auch ein Webinar Special.

Carsten

On the 7th of September at 5pm CET +2 we will have ​our ​english speaking Failover Cluster Best Practices Webinar Part 2 where we continue with our best practices that we build in numerous Hyper-V Failover Cluster ​pojects over the last years.

After talking in Part 1 of the Webinar ​about some generic Cluster setings ​we started with Cluster Networking.​ In Part 2 we will talk about Network Designs, the Hyper-V Switch and SMB3 and SMB Direct.​

​Here is the Agenda:

• Best Practices Cluster Settings
• Best Practices Networking
• Best Practices Storage
• checkDemo
• checkQ&A

​To sign-up just click on the picture or here! Don’t worry that you maybe have no time to attend this Webinar if you sign-up you will get a link to the recording afterwards.

Carsten

Dieser Blogpost ist der vierte von insgesamt fünf Teilen, die in den folgenden Wochen veröffentlicht werden. Grundlage für die Beiträge ist ein Whitepaper, welches ich als Nachlese geschrieben habe zu meinem Vortrag auf der CDC 2018, den ich zusammen mit Petra Lipp gehalten habe. Das Whitepaper steht exklusiv für Newsletter-Abonnenten zur Verfügung. Sie können das vollständige Whitepaper als PDF erhalten, wenn Sie sich für unseren Newsletter anmelden. Nach kurzer Zeit taucht ein Overlay auf, in dem Sie sich registrieren können.

Alle fünf Teile

Im folgenden finden Sie Links zu den fünf Beiträgen. Sollte ein Link noch nicht vorhanden sein, liegt es daran, dass er noch nicht veröffentlicht wurde.

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 1– Architektur und Netzwerk Topologie

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 2– SDN Deployment und eine Lab-Umgebung mit dem Netzwerk Controller

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 3– Software Load Balancing

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 4– RRAS Gateways

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 5– Zusammenfassung

RAS Gateways

Im Teil 3 dieser Blogpost Serie haben wir uns mit dem Deployment der Software Load Balancer (SLB)Komponenten in unserer SDN Lab-Umgebung beschäftigt und einige Testszenarien für den Zugriff von außen auf Tenant VMs über die SLBs sowie den Zugriff aufs Internet per NAT aus Tenant VMs durchgespielt. Als Deployment Werkzeug haben wir den System Center Virtual Machine Manager (SCVMM) 2016 verwendet und damit PowerShell Skripte ausgeführt, die Microsoft hierfür im SDN Repository auf Github bereitgestellt hat.

In diesem Beitrag wollen wir nun unsere SDN Lab-Umgebung um RAS Gateways erweitern, um unsere Tenant Testsysteme von außen erreichbar zu machen.

Ich gehe im Folgenden davon aus, dass Sie die im Teil 2 und Teil 3 beschriebenen Installationsschritte einschließlich der Testszenarien erfolgreich durchgeführt haben.

Die Tools zum Ausrollen der Gateway Komponenten bleiben die gleichen wie für das Deployment der Netzwerk Controller und SLB Instanzen, also das PowerShell Skript VMMExpress.ps1 und die dazu passende Konfigurationsdatendatei Fabricconfig.psd1, die wir in einer PowerShell ISE Sitzung mit Administratorrechten auf unserem SCVMM-System SDN-VMM01 nutzen werden.

Service Templates und Skripte für das Gateway Deployment

Wie schon die Netzwerk Controller und SLB Instanzen werden auch die Gateway-Komponenten als Netzwerk Service im VMM erzeugt. Die dafür erforderlichen Service Templates finden wir im aus Github heruntergeladenen Unterverzeichnis VMM\Templates\GW:

Hier finden wir 2 Production Versionen, eine für Gen1 und eine für Gen2 VMs. Wir werden mit der Version für Gen2 VMs arbeiten.

Ähnlich wie bereits beim Netzwerk Controller und SLB können wir diese Template Dateien an unsere Bedürfnisse anpassen. Öffnen Sie die jeweilige XML-Datei (hier: EdgeServiceTemplate_Generation2.xml) in einem XML-Editor (z.B. PowerShell ISE). So können Sie z.B. die Werte für die Anzahl der SLB-Instanzen (VMs), den RAM-Wert, Anzahl virtueller CPUs und die TimeZone ändern:

Für unsere Lab-Umgebung lasse ich die Anzahl der GW VMs wie vorgegeben auf 3, reduziere aber den RAM-Wert auf 4096, die Anzahl der CPUs je VM auf 2 und setze die Zeitzone auf den Wert 110 (W. Europe Standard Time). Anm.: Eine Tabelle mit den Indexwerten für Zeitzonen finden Sie z.B. hier.

Um die Location Einstellungen der VMs (wie z.B. Tastatur Layout und Datum / Uhrzeit Anzeige in Deutsch) anzupassen, verwende ich wieder die gleiche Unattend.xml Datei wie beim Netzwerk Controller und den SLBs, die ich während des Deployments der Service Templates dem SCVMM „unterjuble“. Die Datei sollte noch in der VMM-Library vom NC- bzw. SLB-Deployment vorhanden sein.

Nachdem wir das gewünschte Service Templates gegebenenfalls angepasst haben, können wir uns nun dem eigentlichen Deployment der GW-VMs zuwenden.

Dazu wechseln wir in das Unterverzeichnis VMM SDN Express und laden die Dateien VMMExpress.ps1 und Fabricconfig.psd1 (in der gleichen Fassung wie für das NC- bzw. SLB-Deployment – also  z.B. Fabricconfig-SDNcloud-Production.psd1) in eine PowerShell ISE Sitzung mit Administratorrechten.

Nun müssen wir die Ablaufsteuerungsschalter in der Fabricconfig.psd1 Datei so anpassen n, dass nur das GW-Deployment  ausgeführt wird (die Schalter finden Sie am Ende der Datei):

##################################            #  Deoloyment Control Switches               ##################################                                                # Do you want to deploy NC            DeployNC = $false            # DeployNC = $true                        #Do you want to create NC managed HNVPA and Transit networks.             #These are required if SLB and GW needs to be deployed            createNCManagedNetworks = $false            # createNCManagedNetworks = $true            #Do you want to Deploy SLB. Values are $true , $false            # DeploySLB =   $true            DeploySLB =   $false            #Do you want to deploy GW. Values are $true , $false            DeployGW = $true            # DeployGW = $false

Speichern Sie die Datei, bevor Sie das Skript VMMExpress.ps1 starten. Falls Sie im Debug Modus arbeiten wollen, setzen Sie zuvor an geeigneten Stellen Breakpoints, um den Ablauf genauer mit zu verfolgen und eventuell eingreifen zu können. Tipps für geeignete Breakpoints finden Sie nachstehend.

.\VMMExpress.ps1 -ConfigurationDataFile .\Fabricconfig-SDNcloud-Production.psd1

Funktion importGatewayTemplate Zeile 1050:

Dies wäre eine geeignete Stelle, um über den Service Designer in das importierte Gateway Service Template noch eine eigene Unattend.xml einzubringen. Achtung: Der VMM erzeugt selbst eine Unattend.xml Datei und mischt sie mit der angegebenen benutzerspezifischen Variante später beim Kreieren der VMs zusammen.

Funktion ConfigureAndDeployGatewayService Zeile 1091:

if($ServiceUpdate.deploymenterrorlist -ne $null)

Überprüfen Sie die Variable wieder, ob sie $null enthält und korrigieren Sie eventuell das Placement der VMs.

Funktion ConfigureAndDeployGatewayService Zeile 1112:

Hier können Sie im Service Designer der VMM-Konsole nochmals alle Parameter zum Erzeugen der Gateway VMs überprüfen.

Post Gateway Deployment Schritte

Wenn Sie das Skript VMMExpress.ps1 erfolgreich für die Gateways ausgeführt haben, finden Sie nun neben den Netzwerk Controller (NC) und SLB Komponenten auch die Gateway Komponenten als virtuelle Maschinen und Services im VMM:

Gateway Service VMs konfigurieren

Nun müssen wir die Gateway Manager Rolle konfigurieren.

Wechseln Sie in der VMM-Konsole in den Fabric Arbeitsbereich und markieren Sie die Kategorie Network Service. Klicken Sie mit der rechten Maustaste auf den Eintrag Network Controller und rufen die Properties auf.

Wechseln Sie in den Network Controller Properties auf die Registerkarte Services und markieren die Gateway Manager Role.

Für das Feld Associated Service wählen Sie über die Browse Schaltfläche den gerade installierten Gateway Manager aus.

Wählen Sie einen Run As Account (hier: NC_LocalAdminRAA). Dieser wird vom Netzwerk Controller verwendet, um auf die Gateway VMs zuzugreifen. Der Account muss auf den Gateway VMs Administratorrechte besitzen.

Für das GRE VIP Subnet wählen Sie aus der Liste das entsprechende logische Netz aus. Es wurde beim Erzeugen der Netzwerk Controller Instanzen vom Skript VMMExpress.ps1 bereits definiert.

Für das Feld Public IPv4 Pool wählen Sie aus der Liste den entsprechenden IP-Pool aus. Auch er wurde beim Erzeugen der NC-Instanzen bereits vom Skript VMMExpress.ps1 definiert und wurde auch bereits beim Deployment der SLB-Komponenten verwendet.

Geben Sie in das Feld Public IPv4 Address eine Adresse aus dem Public IPv4 Pool ein. Wählen Sie aber keine der ersten 3 Adressen des Pools, die haben wir bereits beim Erzeugen von virtuellen IPs für die SLBs belegt. Ich verwende hier die letzte Adresse aus dem Public IPv4 Pool 10.10.50.199

Bei den Feldern Gateway Capacity (Mbps) und Nodes reserved for failures können wir die Standardwerte lassen.

Jetzt müssen wir noch die einzelnen Gateway VMs konfigurieren. Klicken Sie auf jede VM

Wählen Sie als IPv4 Frontend Subnet unser Transit Netz aus.

Legen Sie eine beliebige freie ASN (Autonomous System Number) für das BGP Peering festder Gateway VM fest, hier 65011.

Tragen Sie in die Liste der Geräte, mit denen ein Peering stattfinden soll (List of devices to peer with) unseren BGP-Router ein (IP-Adresse 10.10.20.1, ASN 65000). Wir haben ihn im Zuge des Deployments unserer SLB-Komponenten konfiguriert.

Wiederholen Sie diese Schritte für die anderen Gateway VMs, wobei Sie jeweils eine andere lokale ASN verwenden (z.B. 65012, 65013)

Wenn Sie alle Gateway VMs entsprechend konfiguriert haben, klicken Sie auf OK. Damit sind sie jetzt mit der Gateway Manager Rolle verknüpft.

Und zu guter Letzt müssen wir unsere Gateway VMs noch bei unserem BGP-Router anmelden. Führen Sie auf der BGP VM folgende PowerShell Befehle aus:

Add-BgpPeer -Name GW001 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.104 `        -LocalASN 65000 -PeerASN 65011 -OperationMode Mixed -PeeringMode AutomaticAdd-BgpPeer -Name GW002 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.105 `        -LocalASN 65000 -PeerASN 65012 -OperationMode Mixed -PeeringMode AutomaticAdd-BgpPeer -Name GW003 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.103 `        -LocalASN 65000 -PeerASN 65013 -OperationMode Mixed -PeeringMode Automatic

Nach einiger Zeit sollten alle Peer Systeme verbunden sein:

Get-BgpPeerPeerName LocalIPAddress PeerIPAddress PeerASN OperationMode ConnectivityStatus——– ————– ————- ——- ————- ——————GW001    10.10.20.1     10.10.20.104  65011   Mixed         Connected         GW002    10.10.20.1     10.10.20.105  65012   Mixed         Connected         GW003    10.10.20.1     10.10.20.103  65013   Mixed         Connected         MUX001   10.10.20.1     10.10.20.102  65001   Mixed         Connected         MUX002   10.10.20.1     10.10.20.100  65002   Mixed         Connected         MUX003   10.10.20.1     10.10.20.101  65003   Mixed         Connected

Validierung

Dieser Blogpost ist der dritte  von insgesamt fünf Teilen, die in den folgenden Wochen veröffentlicht werden. Grundlage für die Beiträge ist ein Whitepaper, welches ich als Nachlese geschrieben habe zu meinem Vortrag auf der CDC 2018, den ich zusammen mit Petra Lipp gehalten habe. Das Whitepaper steht exklusiv für Newsletter-Abonnenten zur Verfügung. Sie können das vollständige Whitepaper als PDF erhalten, wenn Sie sich für unseren Newsletter anmelden. Nach kurzer Zeit taucht ein Overlay auf, in dem Sie sich registrieren können.

Alle fünf Teile

Im folgenden finden Sie Links zu den fünf Beiträgen. Sollte ein Link noch nicht vorhanden sein, liegt es daran, dass er noch nicht veröffentlicht wurde.

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 1– Architektur und Netzwerk Topologie

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 2– SDN Deployment und eine Lab-Umgebung mit dem Netzwerk Controller

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 3– Software Load Balancing 

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 4– RRAS Gateways

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 5– Zusammenfassung

Software Load Balancing

Im Teil 2 dieser Blogpost Serie haben wir uns mit dem Aufbau einer SDN Lab-Umgebung beschäftigt, dabei als Basiskomponenten einige Netzwerk Controller Instanzen erzeugt und einige Testszenarien zur Netzwerkisolation mit dem VXLAN-Protokoll durchgespielt. Als Deployment Werkzeug haben wir den System Center Virtual Machine Manager (SCVMM) 2016 verwendet und damit PowerShell Skripte ausgeführt, die Microsoft hierfür im SDN Repository auf Github bereitgestellt hat.

In diesem Beitrag wollen wir nun die SDN-Basisinstallation um Software Load Balancer Komponenten erweitern, um unsere Tenant Testsysteme von außen erreichbar zu machen.

Ich gehe im Folgenden davon aus, dass Sie die im Teil 2 beschriebenen Installationsschritte einschließlich der Testszenarien erfolgreich durchgeführt haben.

Die Tools zum Ausrollen der SLB-Komponenten bleiben die gleichen wie für das Deployment der Netzwerk Controller Instanzen, also das PowerShell Skript VMMExpress.ps1 und die dazu passende Konfigurationsdatendatei Fabricconfig.psd1, die wir in einer PowerShell ISE Sitzung mit Administratorrechten auf unserem SCVMM-System SDN-VMM01 nutzen werden.

Service Templates und Skripte für das SLB Deployment

Wie schon die Netzwerk Controller Instanzen werden auch die SLB-Komponenten als Netzwerk Service im VMM erzeugt. Die dafür erforderlichen Service Templates finden wir im aus Github heruntergeladenen Unterverzeichnis VMM\Templates\SLB:

Hier finden wir jetzt nur 2 Production Versionen, eine für Gen1 und eine für Gen2 VMs. Wir werden mit der Version für Gen2 VMs arbeiten.

Ähnlich wie bereits beim Netzwerk Controller können wir diese Template Dateien an unsere Bedürfnisse anpassen. Öffnen Sie die jeweilige XML-Datei (hier: SLB Production Generation 2 VM.xml) in einem XML-Editor (z.B. PowerShell ISE). So können Sie z.B. die Werte für die Anzahl der SLB-Instanzen (VMs), den RAM-Wert, Anzahl virtueller CPUs und die TimeZone ändern:

Für unsere Lab-Umgebung lasse ich die Anzahl der SLB VMs wie vorgegeben auf 3, reduziere aber den RAM-Wert auf 4096, die Anzahl der CPUs je VM auf 2 und setze die Zeitzone auf den Wert 110 (W. Europe Standard Time). Anm.: Eine Tabelle mit den Indexwerten für Zeitzonen finden Sie z.B. hier.

Um die Location Einstellungen der VMs (wie z.B. Tastatur Layout und Datum / Uhrzeit Anzeige in Deutsch) anzupassen, verwende ich wieder die gleiche Unattend.xml Datei wie beim Netzwerk Controller, die ich während des Deployments der Service Templates dem SCVMM „unterjuble“. Die Datei sollte noch in der VMM-Library vom NC-Deployment vorhanden sein.

Nachdem wir das gewünschte Service Templates gegebenenfalls angepasst haben, können wir uns dem eigentlichen Deployment der SLB-VMs zuwenden.

Dazu wechseln wir in das Unterverzeichnis VMM SDN Express und laden die Dateien VMMExpress.ps1 und Fabricconfig.psd1 (in der gleichen Fassung wie für das NC-Deployment – also  z.B. Fabricconfig-SDNcloud-Production.psd1) in eine PowerShell ISE Sitzung mit Administratorrechten.

Nun müssen wir die Ablaufsteuerungsschalter in der Fabricconfig.psd1 Datei so anpassen n, dass nur das SLB-Deployment  ausgeführt wird (die Schalter finden Sie am Ende der Datei):

            ##################################            #  Deoloyment Control Switches               ##################################                                                # Do you want to deploy NC            DeployNC = $false            # DeployNC = $true                        #Do you want to create NC managed HNVPA and Transit networks.             #These are required if SLB and GW needs to be deployed            createNCManagedNetworks = $false            # createNCManagedNetworks = $true            #Do you want to Deploy SLB. Values are $true , $false            DeploySLB =   $true            # DeploySLB =   $false            #Do you want to deploy GW. Values are $true , $false            # DeployGW = $true            DeployGW = $false

Speichern Sie die Datei, bevor Sie das Skript VMMExpress.ps1 starten. Falls Sie im Debug Modus arbeiten wollen, setzen Sie zuvor an geeigneten Stellen Breakpoints, um den Ablauf genauer mit zu verfolgen und eventuell eingreifen zu können. Tipps für geeignete Breakpoints finden Sie nachstehend.

.\VMMExpress.ps1 -ConfigurationDataFile .\Fabricconfig-SDNcloud-Production.psd1

​Funktion ImportSLBServiceTemplate Zeile 878:

Dies wäre eine geeignete Stelle, um über den Service Designer in das importierte SLB Service Template noch eine eigene Unattend.xml einzubringen. Achtung: Der VMM erzeugt selbst eine Unattend.xml Datei und mischt sie mit der angegebenen benutzerspezifischen Variante später beim Kreieren der VMs zusammen. Wenn es hier zu Konflikten kommt, kann es sein, dass das gesamte Deployment hängen bleibt.

Funktion ConfigureAndDeploySLBService Zeile 917:

if($ServiceUpdate.deploymenterrorlist -ne $null)

Überprüfen Sie, ob die Variable wirklich $null enthält. Nur dann war die Verteilung der SLB VMs auf die Hyper-V Hosts erfolgreich und das Skript kann weiterlaufen. Korrigieren Sie gegebenenfalls das Placement der VMs über den Service Designer in der VMM-Konsole und weisen anschließend der Variablen den Wert $null zu.

Funktion ConfigureAndDeploySLBService Zeile 937:

Hier können Sie im Service Designer der VMM-Konsole nochmals alle Parameter zum Erzeugen der SLB VMs überprüfen.

Post SLB Deployment Schritte

Wenn Sie das Skript VMMExpress.ps1 erfolgreich für die Software Load Balancer (SLBs) ausgeführt haben, finden Sie nun neben den Netzwerk Controller (NC) Komponenten auch die SLB Komponenten als virtuelle Maschinen und Services im VMM:

Notieren Sie sich die IP-Adressen der einzelnen SLBMUX VMs, die sie im logischen Netzwerk Transit beim Deployment erhalten haben (in unserer Lab-Umgebung 10.10.20.xxx). Wir werden diese Informationen später für das Definieren des BGP Peering benötigen.

SLB Service VMs für BGP konfigurieren

Wechseln Sie in der VMM-Konsole in den Fabric Arbeitsbereich und markieren Sie die Kategorie Network Service. Klicken Sie mit der rechten Maustaste auf den Eintrag Network Controller und rufen die Properties auf.

Wechseln Sie in den Network Controller Properties auf die Registerkarte Services und markieren die Load Balancer Role.

Im Feld Associated Service wählen Sie über die Browse… Schaltfläche unseren Software Load Balancer Service aus.

Wählen Sie für das Feld Run As Account einen passenden Account aus (hier: NC_MgmtAdminRAA)

In das Feld SLB Manager VIP tragen Sie die letzte IP-Adresse aus dem vom Skript VMMExpress.ps1 erzeugten IP-Pool des logischen Netzes PrivateVIP ein (hier also: 10.10.30.199).

Selektieren Sie außerdem in der Liste SLBM VIP Pools die IP Pools PublicVIP_IPAddressPool_0 und PrivateVIP_IPAddressPool_0. Diese beiden IP Pools werden dann vom VMM dem SLB Manager zur Verfügung gestellt.

Klicken Sie auf die erste SLB/MUX Instanz SDN-MUXVM01. Geben Sie in das Feld Local ASN eine für Ihre Umgebung geeignete ASN (Autonome System Nummer im Sinne des BGP-Protokolls) ein, hier 65001. Über die Add Schaltfläche fügen Sie nun die Daten des BGP-Routers ein, mit dem diese SLB-Instanz kommunizieren soll. Unser System SDN-DC01 soll ja der BGP-Router werden und er soll die ASN 65000 erhalten. Für die Kommunikation verwenden wir das Transit Netzwerk, in dem das System SDN-DC01 die IP-Adresse 10.10.20.1 besitzt.

Wiederholen Sie diese Schritte für die restlichen SLB-Instanzen.

Damit ist die Konfiguration der SLB Instanzen für BGP abgeschlossen.

Konfiguration des BGP Routers

Bei der Installation unseres Domain Controllers SDN-DC01 haben wir unter anderem bereits die Serverrolle RRAS installiert, aber nicht weiter konfiguriert. Das werden wir nun nachholen, indem wir die BGP-Funktion dieser Serverrolle aktivieren. Dies muss über PowerShell Befehle geschehen.

Führen Sie auf dem SDN-DC01 in einer PowerShell Sitzung mit Administratorberechtigung folgenden Befehl aus:

Add-BgpRouter -BgpIdentifier 10.10.20.1 -LocalASN 65000

Hiermit wird die BGP-Router Funktion aktiviert. Dabei wird auch die lokale ASN (Autonome System Nummer) des BGP-Routers festgelegt. Dies kann ein beliebiger Integer-Wert sein. Üblicherweise werden in SDN-Umgebungen ASNs ab 65000 verwendet, da diese nicht zu Konflikten mit ASNs physischer Geräte führen können. Diese sind typischerweise kleiner 65000.

Als BgpIdentifier geben wir die IP-Adresse des BGP-Routers an – in unserem Fall die Adresse des SDN-DC01 im Transit Netz (also 10.10.20.1).

Jetzt können wir die Peers definieren, die sich mit dem BGP-Router verbinden und Routen austauschen können. Führen Sie für unsere Lab-Umgebung folgende PowerShell Befehle aus. Bitte vergleichen Sie vorher die Kombinationen PeerASN / PeerIPAddress mit den Parametern, die Sie bei der Konfiguration der SLB Service Instanzen weiter oben notiert haben und passen Sie diese gegebenenfalls im nachstehenden PowerShell Skript an:.

Add-BgpPeer -Name MUX001 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.101 `-LocalASN 65000 -PeerASN 65001 -OperationMode Mixed -PeeringMode AutomaticAdd-BgpPeer -Name MUX002 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.100 `-LocalASN 65000 -PeerASN 65002 -OperationMode Mixed -PeeringMode AutomaticAdd-BgpPeer -Name MUX003 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.102 `-LocalASN 65000 -PeerASN 65003 -OperationMode Mixed -PeeringMode Automatic

Warten Sie, bis sich alle Peers mit dem BGP-Router verbunden haben (ConnectivityStatus = Connected). Dies kann unter Umständen geraume Zeit dauern. Den Verbindungsstatus können Sie mit folgendem Kommando prüfen:

Get-BgpPeer

Validierung des Software Load Balancing

Über die SLB-Komponenten wollen wir nun versuchen, unsere Tenant VMs, die wir im Teil 2 erzeugt haben, von außen über das PublicVIP Netz zu kontaktieren.

Dazu müssen wir im PublicVIP Netz für jeden Tenant eine öffentliche IP-Adresse erzeugen und diese dem BGP-Router bekannt machen.

In unserer mit dem SCVMM erzeugten Umgebung müssen wir dazu zunächst ein VIP Template erzeugen, auf dessen Basis wir dann die PublicVIPs definieren können.

Erstellen eines VIP Templates

Wechseln Sie in der VMM Konsole in den Fabric Arbeitsbereich, öffnen die Kategorie Networking und klicken mit der rechten Maustaste auf VIP Templates. Wählen Sie im Kontextmenü Create VIP Template.

Geben Sie einen Namen für das VIP Template ein (z.B. Web VIP Template) sowie die Ports, zwischen denen die Netzwerkdaten ausgetauscht werden sollen (hier: jeweils Port 80). Klicken Sie auf Next.

Wählen Sie als Template Typ Specific und selektieren Sie in der Manufacturer Liste Microsoft sowie in der Model Liste Microsoft Network Controller. Klicken Sie auf Next.

Im Protocol Dialog wählen Sie die Option Custom und geben als Protokoll Name den Text TCP ein. Klicken Sie wieder auf Next.

Die Seite Persistance können wir direkt mit Next überspringen.

Auf der Seite Load Balancing wählen Sie aus der Liste Load Balancing Method den Eintrag Round Robin und klicken dann auf Next.

Die Seite Health Monitors überspringen wir mit Next und gelangen auf die Summary Seite.

Nach dem Klick auf Finish wird nun das VIP Template angelegt.

Erstellen einer öffentlichen virtuellen IP Adresse (PublicVIP) für ein Tenant VM Netz

Um eine PublicVIP für eines unserer Tenant VM Netze zu erstellen, müssen wir die PowerShell verwenden. Führen Sie folgendes Skript aus:

param([Parameter(Mandatory=$false)]# Name of the Network Controller Network Service# This value should be the name you gave the Network Controller service# when you on-boarded the Network Controller to VMM$LBServiceName = „Network Controller“,[Parameter(Mandatory=$false)]# Name of the VM instances to which you want to assign the VIP$VipMemberVMNames = @(„Red-VM01“, „Red-VM02“),[Parameter(Mandatory=$false)]# VIP address you want to assign from the VIP pool.# Pick any VIP that falls within your VIP IP Pool range.$VipAddress = „10.10.50.100“,[Parameter(Mandatory=$false)]# Name of the VIP VM Network$VipNetworkName = „PublicVIP“,[Parameter(Mandatory=$false)]# The name of the VIP template you created via the VMM Console.$VipTemplateName = „Web VIP Template“,[Parameter(Mandatory=$false)]# Arbitrary but good to match the VIP you’re using.$VipName = „Red-VIP“)Import-Module virtualmachinemanager$lb = Get-scLoadBalancer | where { $_.Service.Name -eq $LBServiceName};$vipNetwork = get-scvmnetwork -Name $VipNetworkName;$vipMemberNics = @();foreach ($vmName in $VipMemberVMNames){    $vm = get-scvirtualmachine -Name $vmName;    # if ($vm.VirtualNetworkAdapters[0].VMNetwork.ID -ne $vipNetwork.ID)    # {        # $vm.VirtualNetworkAdapters[0] | set-scvirtualnetworkadapter -VMNetwork $vipNetwork;    # }    $vipMemberNics += $vm.VirtualNetworkAdapters[0];}$existingVip = get-scloadbalancervip -Name $VipNameif ($existingVip -ne $null){# foreach ($mem in $existingVip.VipMembers)# {#     $mem | remove-scloadbalancervipmember;# }$existingVip | remove-scloadbalancervip;}$vipt = get-scloadbalancerviptemplate -Name $VipTemplateName;$vip = New-SCLoadBalancerVIP -Name $VipName -LoadBalancer $lb -IPAddress VipAddress -LoadBalancerVIPTemplate $vipt -FrontEndVMNetwork $vipNetwork -BackEndVirtualNetworkAdapters $vipMemberNics;Write-Output „Created VIP “ $vip;$vip = get-scloadbalancervip -Name $VipName;Write-Output „VIP with members “ $vip;

Anmerkung: Die Parameter dieses Skripts sind so vorbelegt, dass Sie direkt die PublicVIP 10.10.50.100 anlegen können, um ein Load Balancing zwischen den VMs Red-VM01 und Red-VM02 zu definieren.

Analog können Sie auch eine PublicVIP 10.10.50.101 für ein Load Balancing zwischen den Tenant VMs Green-VM01 und Green.VM02 zu definieren.

Mit dem CmdLet Get-SCLoadBalancerVIP können Sie sich nun eine Liste aller definierten PublicVIPs anzeigen lassen.

Load Balancing Test

Nachdem wir nun für die vNets unserer Tenants öffentliche IP-Adressen definiert haben, können wir das Load Balancing einmal ausprobieren.

Starten Sie auf einem System, das Zugriff auf das PublicVIP Netz hat – z.B. unser Domain Controller SDN-DC01 – einen Browser und geben in die Adresszeile http://10.10.50.100 (die VIP des Red Tenants) ein. Sie sollten folgende Anzeige erhalten:

Starten Sie eine weitere Browser Instanz und geben die gleiche Adresse ein. Stellen Sie dabei sicher, dass der Browser Cache leer ist (z.B. durch Beenden der Browser Instanz und Starten einer neuen Browser Sitzung). Ergebnis:

Geben Sie in die Adressleisten der Browser die PublicVIP des Green Tenants ein (http://10.10.50.101) und Sie erhalten folgende Anzeige:

NAT konfigurieren

Bislang können die Tenant VMs nur in ihrem eigenen VMnet kommunizieren. Nachdem wir die SLB-Instanzen konfiguriert haben, können wir ihnen nun auch den Zugriff auf externe Ressourcen per NAT (Netzwerk Address Translation) einrichten.

Wechseln Sie in der VMM-Konsole in den Arbeitsbereich VMs and Services, wählen die Kategorie VM Networks und klicken Sie mit der rechten Maustaste auf das VMnet, für das Sie NAT aktivieren wollen. Rufen Sie die Properties auf.

Wählen Sie die Registerkarte Connectivity. Aktivieren Sie das Kontrollkästchen Connect directly to an additional logical network und wählen Sie darunter die Option Network Address Translation (NAT) – im linken Bereich erscheint dabei ein Reiter für eine weitere Registerkarte Network Address… Stellen Sie sicher, dass im Feld Gateway Device der Network Controller eingestellt ist.

Klicken Sie jetzt auf den neuen Reiter für die Registerkarte Network Address… Im Feld IP Address Pool wählen Sie den PublicVIP_IPAddressPool_0. Das Feld IP Address können Sie freilassen. Vom VMM wird dann eine geeignete IP-Adresse aus dem gewählten Pool eingesetzt. Klicken Sie auf OK.

Zur Kontrolle können Sie nochmals die Properties des VMnets aufrufen. Auf der Registerkarte Network Address ist jetzt das Feld IP Address ausgefüllt (hier: 10.10.50.100).

Jetzt könnten Sie von einer VM im Red VMNet eine externe Webseite aufrufen. In meiner Lab-Umgebung fehlt jedoch die Verbindung zwischen dem PublicVIP Netz und dem öffentlichen Internet. Deshalb können Sie keine externen Ressourcen im Internet ansprechen. Sie können aber beispielsweise versuchen, über die öffentliche VIP eines anderen Tenant Netzes die IIS-Startseite einer VM zu erreichen, z.B

Jetzt können wir auch noch NAT-Regeln für eingehende Netzwerkpakete von unserer öffentlichen IP-Adresse definieren. 

Öffnen Sie wieder die Properties des gewünschten Tenant VMnets und wechseln Sie auf die Registerkarte Network Address… 

Über die Schaltfläche Add können Sie jetzt Regeln für den eingehenden Netzwerkverkehr konfigurieren. Um z.B. eine Remote Desktop Verbindung (RDP) von einem externen System zum System Red-VM01 herstellen zu können, geben Sie folgende Parameter ein:

Name:

Protocol:

Incoming Port:

Destination IP:

Destination Port:

Geben Sie einen Namen für die eingehende NAT-Verbindung ein, z.B. RDP_Red-VM01

Wählen Sie das Protokoll (TCP oder UDP) der eingehenden Verbindung.

Geben Sie die Portnummer für die eingehenden Netzwerkdaten an, hier 3389

Geben Sie die IP-Adresse der Tenant VM ein, an die die Daten weitergeben werden sollen, z.B. für die Red-VM01 die Adresse 192.168.0.4

Portnummer innerhalb der Tenant VM als Ziel der Datenweiterleitung (RDP-Standard 3389)

Und wenn Sie gerade schon dabei sind, konfigurieren Sie auch gleich eine NAT-Regel für RDP zum System Red-VM02. Diesen Datenverkehr erwarten wir auf dem Port 3390 und leiten ihn an an den Port 3389 der Ziel-VM weiter.

Name:

Protocol:

Incoming Port:

Destination IP:

Destination Port:

Geben Sie den Namen der eingehenden NAT-Verbindung ein, z.B. RDP_Red-VM02

Wählen Sie das Protokoll (TCP oder UDP) der eingehenden Verbindung.

Geben Sie die Portnummer für die eingehenden Netzwerkdaten an, hier 3390

Geben Sie die IP-Adresse der Tenant VM ein, an die die Daten weitergeben werden sollen, z.B. für die Red-VM02 die Adresse 192.168.1.4

Portnummer innerhalb der Tenant VM als Ziel der Datenweiterleitung (RDP-Standard 3389)

Jetzt können Sie von einem System in unserem PublicVIP Netz RDP-Verbindungen zu den Tenant VMs herstellen, z.B. zu Red-VM01:

mstsc /v 10.10.50.100:3389

Für eine RDP-Verbindung zu Red-VM02 geben Sie die in der NAT-Regel hinterlegte Portnummer 3390 an:

mstsc /v 10.10.50.100:3390

Die NAT-Konfiguration und Regeln für ein VMnet können Sie sich auch mit der PowerShell anzeigen lassen:

$vnet = Get-SCVMNetwork -Name „Red VMnet“Write-Output „NAT Connections and Rules for VM Network: $vnet“$NATconn = Get-SCNATConnection -VMNetwork $vnetWrite-Output $NATconn$NATrules = Get-SCNATRule -NATConnection $NATWrite-Output $NATrules

Nächste Schritte

Mit dem erfolgreichen Deployment der Software Load Balancer Komponenten haben wir den zweiten Schritt für den Aufbau unserer Software Defined Networking (SDN) Umgebung vollendet.

Im nächsten Beitrag werden wir unsere Lab-Umgebung um Remote Gateways erweitern, um remote Tenant Netze mit den VMs in unserer SDN-Umgebung zu verbinden.

Bleiben Sie also dran. Es bleibt weiterhin spannend …

Dieser Blogpost ist der zweite von insgesamt fünf Teilen, die in den folgenden Wochen veröffentlicht werden. Grundlage für die Beiträge ist ein Whitepaper, welches ich als Nachlese geschrieben habe zu meinem Vortrag auf der CDC 2018, den ich zusammen mit Petra Lipp gehalten habe. Das Whitepaper steht exklusiv für Newsletter-Abonnenten zur Verfügung. Sie können das vollständige Whitepaper als PDF erhalten, wenn Sie sich für unseren Newsletter anmelden. Nach kurzer Zeit taucht ein Overlay auf, in dem Sie sich registrieren können.

Alle fünf Teile

Im folgenden finden Sie Links zu den fünf Beiträgen. Sollte ein Link noch nicht vorhanden sein, liegt es daran, dass er noch nicht veröffentlicht wurde.

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 1– Architektur und Netzwerk Topologie

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 2– SDN Deployment und eine Lab-Umgebung mit dem Netzwerk Controller

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 3– Software Load Balancing 

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 4– RRAS Gateways

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 5– Zusammenfassung

​​​​SDN Deployment

Im letzten Beitrag (Teil 1) haben wir uns mit der Architektur und der Netzwerk Topologie einer SDN-Umgebung mit dem Windows Server 2016 beschäftigt. In diesem Beitrag wollen wir nun mit dem Aufbau und dem Deployment einer SDN Lab-Umgebung beginnen. Da dieser Beitrag etwas länger ist, hier erst mal zum leichteren Navigieren eine Inhaltsübersicht:

Mcirosoft bietet für das SDN-Deployment verschiedene Methoden an:

Manuelle Installation mit PowerShell

Diese Methode ist sehr mühsam, kann aber sinnvoll sein, wenn man nur einzelne SDN-Technologien einsetzen will. Details siehe DeploySoftware Defined Network Technologies using Windows PowerShell​ in der Technet Library.

Installation mit Hilfe vorgefertigter PowerShell Skripte

Diese Methode empfiehlt sich, wenn man eine SDN-Umgebung ohne den System Center Virtual Machine Manager (SCVMM) aufbauen und betreiben will, weil man andere Management Werkzeuge einsetzen will. Details siehe Deploy a Software Defined Network infrastructure using scripts in der Technet Library.

Installation über die Netzwerkfabrik des System Center Virtual Machine Manager 2016 (SCVMM 2016) 

Dies ist meiner Meinung nach aktuell die bequemste und übersichtlichste Methode zur Installation einer SDN-Umgebung, insbesondere wenn der SCVMM 2016 sowieso als Management Werkzeug für die virtuelle Welt eingesetzt wird. Wir haben dabei sowohl die Möglichkeit der manuellen Installation über die VMM Konsole (Details siehe Setup a Software Defined Network (SDN) infrastructure in the VMM fabric in der Technet Library) als auch die automatisierte Installation mit PowerShell Skripten, die von Microsoft auf Github bereitgestellt werden.

Ich werde im Folgenden auf die automatisierte SCVMM Installation mit PowerShell Skripten näher eingehen und damit auch die Lab-Umgebung aufbauen.

Die SDN Lab Umgebung

Legen wir also los mit dem Aufbau einer SDN Lab-Umgebung. Klären wir zunächst mal die Voraussetzungen.

Hardware

In meinem Testlabor habe ich nicht die notwendige Anzahl an Hardware-Systemen zur Verfügung, um eine vollständige SDN-Umgebung auszurollen. Ich werde deshalb das Ganze auf einem einzigen Hyper-V Host aufbauen und mit Nested Virtualisierung arbeiten.

Dieser Hyper-V sollte mindestens 128 GB RAM haben, für Windows Server 2016 Datacenter geeignet bzw. zertifiziert sein und natürlich Hyper-V unterstützen. Zur Not tut es auch ein System mit Windows 10 Pro (Laptop), das aber mindestens 64 GB RAM besitzen sollte. Falls Sie kein solches physisches System zur Verfügung haben, können Sie das Ganze auch in einer einzigen virtuellen Maschine umsetzen, die Sie z.B. in der Microsoft Azure Cloud oder bei einem anderen Service Provider anmieten.

Software

Sie benötigen folgende Softwarekomponenten für die Installation:

• Windows Server 2016 Data Center
• System Center Virtual Machine Manager (SCVMM) 2016
• einschließlich SQL Server 2014 und Windows Assessment and Deployment Kit
• SCVMMService Templates und Powershell Skripte für das SDN Deploymen

Da wir hier nur eine Testumgebung aufbauen wollen, genügen die Evaluierungs-Versionen der jeweiligen Komponenten. 

Auf das Downloaden und die Verwendung der SCVMM Service Templates und PowerShell Skripte werde ich später noch genauer eingehen.

Die Lab Infrastruktur

Für die SDN-Umgebung benötigen wir einige virtuelle Maschinen sowie die Parameter der logischen SDN-Netzwerke.

Virtuelle Maschinen

Bei der Infrastruktur der SDN-Umgebung beschränke ich mich auf folgende virtuelle Maschinen:

Domain Controller SDN-DC01

Dieses System dient als Active Directory Controller mit integriertem DNS. Darüber hinaus stellt es über File Shares den Storage für unser Hyper-V Failover Cluster bereit.

BGP-Router SDN-BGP01

Dieses System stellt den BGP-Router für unsere Lab-Umgebung dar. Es verwendet dazu die Windows Serverrolle Remote Access.

SDN-VMM01

Auf diesem System ist der System Center Virtual Machine Manager 2016 einschließlich der dafür notwendigen Basiskomponenten wie SQL-Server und Windows Assessment and Deployment Kit installiert. Von diesem System werden wir auch das Deployment der SDN-Umgebung steuern.

SDN-HV01, SDN-HV02, SDN-HV03 und SDN-HV04

Diese 4 Systeme bilden ein Hyper-V Failover Cluster, in das wir die virtuellen SDN-Systeme wie Network Controller, SLB-MUXs und Gateways sowie auch beispielhaft einige Tenant VMs ausrollen werden.

Logische SDN Netze

Zum Ausrollen der SDN-Umgebung müssen wir auch die Parameter der logischen SDN-Netze festlegen. Die nachstehenden Tabellen zeigen die Parameter, wie wir sie später im VMM verwenden werden.

NC_Management

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereichreserviert für andere Zwecke

192.168.80.0255.255.255.00192.168.80.1192.168.80.10192.168.80.230 – 192.168.80.254192.168.80.230 (IP-Adresse für REST-API)

HNVPA

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereich

10.10.10.0255.255.255.0010.10.10.1192.168.80.1010.10.10.100 – 10.10.10.199

Transit

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereich

10.10.20.0255.255.255.0010.10.20.1192.168.80.1010.10.20.100 – 10.10.20.199

PrivateVIP

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereichreserviert für andere Zwecke

210.10.30.0255.255.255.0010.10.30.1192.168.80.1010.10.30.100 – 10.10.30.19910.10.30.100 – 10.10.30.199 (für Load Balancer VIPs) 

GREVIP

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereichreserviert für andere Zwecke

10.10.40.0255.255.255.0010.10.40.1192.168.80.1010.10.40.100 – 10.10.40.19910.10.40.100 – 10.10.40.199 (für Load Balancer VIPs)

PublicVIP

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereichreserviert für andere Zwecke

10.10.50.0255.255.255.0010.10.50.1192.168.80.1010.10.50.100 – 10.10.50.19910.10.50.100 – 10.10.50.199 (für Tenant VIPs))

Ein grober Überblick

Die Infrastruktur der Lab-Umgebung hat also folgendes Aussehen:

Vorbereitungen

• Installieren Sie auf dem physischen Hyper-V Host die Datacenter Edition von Windows Server 2016 und installieren Sie die Hyper-V Rolle. Für unsere Tests ist keine Windows Aktivierung erforderlich; ersatzweise können Sie auch Windows 10 Pro verwenden.
• Erstellen Sie im Hyper-V Host die 3 folgenden virtuellen Switche – entweder über die GUI im Hyper-V Manager oder per PowerShell:

New-VMSwitch -Name „SDN“ -SwitchType InternalNew-VMSwitch -Name „Public“ -SwitchType InternalNew-VMSwitch -Name „Private“ -SwitchType Internal

• Erzeugen Sie Windows Server 2016 VHDX-Dateien für die verschiedenen zu erzeugenden VMs, z.B. mit dem PowerShell Skript Convert-WindowsImage.ps1, das Sie im Verzeichnis <ISO>/NanoServer/NanoServerImageGenerator der heruntergeladenen ISO Datei des Windows Server 2016 finden.

cd ‚<ISO>:\nanoserver\NanoServerImageGenerator‘.\Convert-WindowsImage.ps1# Erzeuge dyn. VHDX für Gen2 Hyper-V VM# mit Windows Server 2016 Datacenter (= Edition4)Convert-WindowsImage `    -SourcePath ‚<ISO>:\sources\install.wim‘ `    -Edition 4 `    -VHDPath ‚E:\Hyper-V\WS2016.vhdx‘ `    -SizeBytes 80GB `    -VHDFormat VHDX `    -DiskLayout UEFI

• Erzeugen Sie auf dem physischen Hyper-V Host nun folgende virtuelle Gen 2 Maschinen. Als Festplatte können Sie jeweils die im vorstehenden Schritt erzeugte VHDX-Datei verwenden. Statten Sie die VMs mit den angegebenen Netzwerkadaptern und gegebenenfalls mit den zusätzlichen Datenlaufwerken aus. Verbinden Sie die Netzwerkadapter mit dem jeweils angegebenen virtuellen Switch. 

SDN-DC01

vCPUMemoryNetzwerkadapterZusätzliches Laufwerk

24 GBNC_ManagementIP-AdresseGatewayDNS

Verbunden mit internen Switch SDN192.168.80.10192.168.80.1192.168.80.101 virt. Festplatte, dynamisch erweiterbarGröße: >= 512 GBShares:- Hyper-V – Storage für die HV01 – HV04– Cluster-Witn6ess – Syncdaten für das Hyper-V Cluster

Installieren und konfigurieren Sie folgende Serverrollen und Features einschließlich der jeweiligen Management Tools:

Active Directory

Domainname: SDNcloud.local

Legen Sie folgende Benutzerkonten an:

• FabAdminFabric Admin: Klon des Benutzerkontos Administrator (optional). Ich arbeite normalerweise nur mit diesem Domain User. Damit kann keine Verwechslung mit dem lokalen Administrator-Konto entstehen beim Login an einem Member Server. Sie sollten dieses Konto jedoch auf allen Member Systemen in die lokale Gruppe Administrators aufnehmen, um dort auch alle Aufgaben durchführen zu können.
• VMM-SVC – Service Account für den VMM Service

Legen Sie folgende lokale Security Gruppen an:

• Network Controller AdminsMitglieder dieser Sicherheitsgruppe dürfen die Netzwerk Controller Konfiguration verwalten (Kreieren, Löschen und Updaten von NC Komponenten). Für unsere Lab-Umgebung verwende ich die Standardgruppe Domain Admins und setze zusätzlich das oben beschriebene Benutzerkonto FabAdmin ein.

• Network Controller UsersMitglieder dieser Sicherheitsgruppe dürfen nach dem NC-Deployment mit dem Netzwerk Controller über dessen REST-API kommunizieren. Für unsere Lab-Umgebung verwende ich die Standardgruppe Domain Admins und setze zusätzlich das oben beschriebene Benutzerkonto FabAdmin ein.

DNS

Active Directory integriert

Definieren Sie ggf. DNS-Forwarders, um Internet Namen auflösen zu können (optional; für einige spätere Testszenarien sinnvoll)

Stellen Sie sicher, dass Sie alle aktuellen Updates und Patches installiert haben.

SDN-BGP01

vCPUMemoryNetzwerkadapter

24 GBNC_ManagementIP-AdresseGatewayDNSHNVPAIP-AdresseTransitIP-AdressePublicIP-Adresse

Verbunden mit internen Switch SDN192.168.80.50192.168.80.1192.168.80.10Verbunden mit internen Switch SDN10.10.10.1Verbunden mit internen Switch SDN10.10.20.1Verbunden mit internen Switch Public10.10.50.1

Joinen Sie das System als Member Server ins Active Directory.

Installieren und konfigurieren Sie folgende Serverrollen und Features einschließlich der jeweiligen Management Tools:

Remote Access 

Es genügen die Rollen Direct Access and VPN sowie Routing

Aktivieren Sie die LAN-Router Funktion oder optional NAT (in meiner Lab-Umgebung arbeite ich mit NAT, da ich über das logische Netz NC_Management Internetzugriff habe).

Eine weitere Konfiguration ist zunächst nicht notwendig; sie erfolgt später.

Stellen Sie sicher, dass Sie alle aktuellen Updates und Patches installiert haben.

SDN-HV01– SDN-HV04

vCPUMemoryNetzwerkadapter

je 4>= 16 GBNC_ManagementIP-AdressenGatewayDNS

dynamic Memory darf nicht aktiviert sein!Verbunden mit internen Switch SDNSDN-HV01: 192.168.80.21SDN-HV02: 192.168.80.22SDN-HV03: 192.168.80.23SDN-HV04: 192.168.80.24192.168.80.1192.168.80.10

Joinen Sie alle 4 Systeme als Member Server ins Active Directory.

Installieren und konfigurieren Sie folgende Serverrollen und Features einschließlich der jeweiligen Management Tools auf allen 4 VMs:

Hyper-V

Achtung: Aktivieren Sie Nested Virtualization und MAC Address Spoofing für alle 4 VMs mit PowerShell:

Get-VMProcessor -VMName SDN-HV01 | Set-VMProcessor -ExposeVirtualizationExtensions $trueGet-VMNetworkAdapter -VMName SDN-HV01 | Set-VMNetworkAdapter -MacAddressSpoofing On

Definieren Sie in den Hyper-V Systemen noch keinen virtuellen Switch. Wir werden dies später mit dem SCVMM erledigen.

Setzen Sie im Hyper-V Manager in den Hyper-V Einstellungen die Pfade für virtuelle Maschinen und virtuelle Hard Disks auf den Share, den Sie beim Kreieren des Systems SDN-DC01 angelegt haben.

​​​​Failover Clustering

Erzeugen Sie ein Hyper-V Failover Cluster mit den 4 Hyper-V Systemen. In meiner Lab-Umgebung verwende ich folgende Parameter:

• Clustername: SDN-HVCL
• Cluster IP: 192.168.80.20

Stellen Sie sicher, dass Sie alle aktuellen Updates und Patches installiert haben.

SDN-VMM01

vCPUMemoryNetzwerkadapterZusätzliches Laufwerk

mind. 4 GBNC_ManagementIP-AdresseGatewayDNS

Verbunden mit internen Switch SDN192.168.80.31192.168.80.1192.168.80.10

1 virt. Festplatte, dynamisch erweiterbarGröße: >= 512 GBLegen Sie Verzeichnisse für die VMM-Library (z.B. D:\VMMLibrary) und für die SDN Installationsskripte (z.B. D:\Software) an.

Joinen Sie das System als Member Server ins Active Directory.

Downloaden und installieren Sie nun folgende Softwarekomponenten auf den SDN-VMM01:

• Windows Assessment and Deployment Kit
• SQL Server 2014 (oder neuer)
• System Center Virtual Machine Manager (SCVMM) 2016 einschließlich dem aktuellen Update Rollup UR5

Verwenden Sie als Benutzerkonto für den VMM Serverdienst den beim SDN-DC01 erstellten Service Account VMM-SVC.

Stellen Sie sicher, dass Sie alle aktuellen Updates und Patches installiert haben.

Starten Sie nach der vollständigen VMM Installation die VMM Konsole über das Icon auf dem Desktop und führen Sie folgende Basiskonfiguration durch:

Rufen Sie im Arbeitsbereich Settings unter General die Network Settings auf und deaktivieren Sie das Kontrollkästchen Create logical networks automatically.

Klicken Sie im Arbeitsbereich Settings mit der rechten Maustaste auf den Eintrag Run As Accounts und rufen den Befehl Create Run As Account auf. Im Dialogfenster geben Sie jetzt ein Benutzerkonto aus dem Active Directory einschließlich Kennwort an, das Domain Admin Rechte besitzt – im Beispiel der FabAdmin aus der Domain sdncloud.

Erstellen Sie eine SDN-Host Gruppe im VMM

Technisch ist dieser Schritt nicht unbedingt erforderlich. Man kann dann jedoch schnell sehen, welche Hosts zu der SDN-Umgebung gehören.

Wechseln Sie in der VMM-Konsole in den Arbeitsbereich Fabric, klicken mit der rechten Maustaste unter Servers auf All Hosts und wählen im Kontextmenü den Befehl Create Host Group. Geben Sie als Namen SDN-Hosts ein.

Importieren Sie die Hyper-V Hosts in den VMM

Klicken Sie in der VMM-Konsole im Arbeitsbereich Fabric mit der rechten Maustaste auf die soeben erstellte Hostgruppe SDN-Hosts und wählen im Kontextmenü den Befehl Add Hyper-V Hosts and Clusters.

Es öffnet sich der Add Resource Wizard. Wählen Sie dort die Option Windows Server computers in a trusted Active Directory domain und klicken Sie dann auf Next.

Wählen Sie den Run As Account, mit dem der Import durchgeführt werden soll, indem Sie auf Browse klicken.

Wählen Sie in der angezeigten Liste den vorhin angelegten VMM Admin aus und klicken Sie auf OK.

Zurück im Add Resource Wizard sehen Sie den ausgewählten Run As Account. klicken Sie auf Next.

Im nächsten Fenster müssen Sie jetzt die Namen der zu importierenden Hyper-V Hosts bzw. Cluster eingeben, in unserem Fall also den Clusternamen SDN-HVCL. Klicken Sie dann wieder auf Next.

Jetzt wird Ihnen das Cluster mit den Mitgliedsservern angezeigt. Aktivieren Sie die Checkbox neben dem Clusternamen und klicken Sie auf Next.

Wählen Sie jetzt die Host Group für den Import aus. Aktivieren Sie auch die Checkbox Reassociate this host with this VMM environment. Klicken Sie nochmals auf Next.

Prüfen Sie in der angezeigten Zusammenfassung nochmals Ihre Angaben und klicken Sie dann auf Finish.

Der Importvorgang startet und Sie können den Fortschritt in der Jobliste des VMM mitverfolgen.

Warten Sie, bis alle Jobs erfolgreich abgeschlossen sind (Anzeige Completed). Die angezeigten Warnungen über das nicht aktivierte Multipath IO können wir hier ignorieren.

Schließen Sie das Jobfenster. In der VMM Konsole sind jetzt unser Cluster und die Hyper-V Hosts importiert.

Im nächsten Schritt müssen wir dem VMM noch mitteilen, wo die Images für unsere zukünftigen virtuellen Maschinen abgelegt werden sollen.

Wechseln Sie im Fabric Arbeitsbereich in die Kategorie Storage, klicken mit der rechten Maustaste auf Providers und wählen den Befehl Add Storage Devices.

Es öffnet sich der Add Storage Devices Wizard. Da wir in dieser Lab-Umgebung für das Ablegen der VM-Images einen File Share mit dem Namen Hyper-V auf unserem Domain Controller SDN-DC01 verwenden wollen, wählen wir als Provider Typ Windows-based file server und klicken auf Next.

Jetzt müssen wir den Servernamen und einen Run As account angeben. 

Nach einem Klick auf Next wird uns der SDN-DC01 als Storage Device angezeigt …

… und nach einem weiteren Klick auf Next die darauf verfügbaren Shares. Wählen Sie den Hyper-V Share aus und klicken Sie nochmals auf Next.

Es wird eine Zusammenfassung angezeigt. Wenn wir nun auf Finish klicken, wird unser File Share als Storage Device importiert.

Über die Jobliste können wir den Vorgang mitverfolgen.

Jetzt müssen wir den gerade importierten Storage Provider noch in den Properties unseres Clusters registrieren, damit der VMM weiß, wo er VM Images für dieses Cluster ablegen kann.

Klicken Sie mir der rechten Maustaste auf das Cluster im Fabric Arbeitsbereich unter der vorhin angelegten Hostgroup SDN-Hosts und rufen Sie im Kontextmenü die Properties auf.

Klicken Sie auf der Registerkarte File Share Storage auf die Schaltfläche Add…

Im Add File Share Dialogfenster können Sie nun den vorher als Storage Provider definierten Pfad \\SDN-DC01.sdncloud.local\Hyper-V in der Klappbox auswählen. Klicken Sie auf OK …

… und der Pfad wird in den File Share Properties unseres Clusters angezeigt. Durch einen weiteren Klick auf OK wird die Änderung übernommen.

Damit ist die Basis-Installation und Konfiguration für unsere SDN Lab-Umgebung erstmal abgeschlossen.

Bereitstellen der Skripte für das SDN Deployment – VMM Express.ps1

Für das SDN Deployment mit dem SCVMM stellt Microsoft ein eigenes Repository auf GitHub mit Service Templates und Skripten zur Verfügung. Laden Sie dieses Paket als .ZIP-Datei in ein Verzeichnis auf dem Datenlaufwerk des System SDN-VMM01 (z.B. D:\Software).

Entsperren und extrahieren Sie die heruntergeladene .ZIP-Datei. Sie erhalten dann folgende Verzeichnisstruktur:

Interessant für unsere weitere Arbeit ist der Unterordner VMM. Er enthält 3 Unterverzeichnisse:

• Scripts – PowerShell Beispiel-Skripte für virtuelle Tenant IP-Adressen nach dem SDN Deployment
• Templates – VMM Service Templates für Network Controller, SLB und Gateway VMs
• VMM SDN Express – PowerShell Skripte für das SDN-Deployment

Werfen wir zunächst einen Blick in das Templates Verzeichnis. Es enthält 3 Ordner, je einen für die Netzwerk Controller (NC), für die Software Load Balancer(SLB) und für die Gateways (GW). Im NC-Verzeichnis finden wir 4 XML-Dateien für verschiedene Methoden zum Erzeugen der Netzwerk Controller VMs. Der Unterschied: Mit den Production Varianten wird ein virtuelles Guest Cluster mit 3 Network Controllern erzeugt, wohingegen die Standalone Varianten nur einen einzelnen Network Controller kreieren.

Für produktive Umgebungen sollten Sie auf jeden Fall die Production Varianten einsetzen. Wir werden in unserer Lab-Umgebung ebenfalls damit arbeiten und Gen2 VMs erzeugen.

Bei Bedarf können Sie in den Service Templates die Definitionen für die zu erzeugenden VMs noch anpassen. Öffnen Sie die jeweilige XML-Datei (hier: Network Controller Production Generation 2 VM.xml) in einem XML-Editor (z.B. PowerShell ISE). Sie können z.B. die Werte für RAM, Anzahl virtueller CPUs und die TimeZone anpassen:

Für unsere Lab-Umgebung reduziere ich den RAM-Wert auf 4096 und setze die Zeitzone auf den Wert 110 (W. Europe Standard Time). Anm.: Eine Tabelle mit den Indexwerten für Zeitzonen finden Sie z.B. hier.

Analog können Sie auch die Service Templates für die SLBs und Gateways anpassen.

Um die Location Einstellungen der VMs (wie z.B. Tastatur Layout und Datum / Uhrzeit Anzeige in Deutsch) anzupassen, habe ich mir eine eigene Unattend.xml Datei erstellt, die ich während des Deployments der Service Templates dem SCVMM „unterjuble“.

Nachdem wir die Service Templates gegebenenfalls angepasst haben, können wir uns dem eigentlichen Deployment der SDN-Umgebung zuwenden.

Dazu wechseln wir in das Verzeichnis VMM SDN Express:

In diesem Verzeichnis finden wir eine PowerShell Skriptdatei VMMExpress.ps1 sowie einige PowerShell Datendateien (.PSD1).

VMMExpress.ps1

Dieses PowerShell Skript enthält die komplette Logik zum Ausrollen einer SDN-Umgebung. Es installiert die notwendigen virtuellen Switches in den Hyper-V Systemen, kreiert die weiter oben beschriebenen logischen Netze und erzeugt dann die VMs für die SDN-Komponenten (Network Controller, Software Load Balancer und Gateways).

Das Skript wird über eine Konfigurationsdatei (PowerShell Datendatei – .PSD1-Datei) gesteuert, die beim Aufruf von VMMExpress.ps1 über den Parameter -ConfigurationDataFile angegeben wird. Diese Konfigurationsdatei enthält sowohl die Parameter für die SDN-Umgebung wie logische Netze und VMs als auch Ablaufsteuerungsschalter. Letztere ermöglichen entweder einen gesamten Durchlauf für alle Komponenten oder ein schrittweises Deployment der einzelnen Komponenten. So kann festgelegt werden, dass zunächst nur die Netzwerk Controller Instanzen erzeugt werden. In einem weiteren Aufruf von VMMExpress.ps1 werden dann die Software Load Balancer erzeugt und in einem dritten Aufruf schließlich die Gateways. Diese Methode für das schrittweise Deployment der diversen SDN-Komponenten werde ich für unsere Lab-Umgebung verwenden.

Das Verzeichnis VMM SDN Express enthält 2 Beispiele für Konfigurationsdateien. Die Datei Fabricconfig.psd1 stellt ein „leeres“ Muster dar. Fabricconfig_Example.psd1 enthält die Parameter für eine von Microsoft erstellte Beispielkonfiguration.

Für unsere SDN Lab-Umgebung habe ich eine eigene Konfigurationsdatei mit den weiter oben beschriebenen Parametern erstellt – Fabricconfig-SDNcloud-Production.psd1.

Fabricconfig-SDNcloud-Production.psd1

Nachstehend finden Sie die vollständige Konfigurationsdatei, um in unserer SDN Lab-Umgebung zunächst nur den Netzwerk Controller und die logischen SDN-Netze zu erzeugen. Speichern Sie diese Datei im gleichen Verzeichnis wie VMMExpress.ps1 unter dem Namen Fabricconfig-SDNcloud-Pro1duction.psd1. Auf die notwendigen Änderungen für das Deployment der SLB- und Gateway-Komponenten werde ich in den späteren Blog-Beiträgen jeweils noch eingehen.

# This is a sample configuration file for VMM Express. All the paremeters should be# modified according to your setup for correct deployment of VMM Express.# Start VMMExpress.ps1:# change into the directory with VMMExpress.ps1 and then start the following command# .\VMMExpress.ps1 -ConfigurationDataFile .\Fabricconfig-SDNcloud-Production.psd1@{    AllNodes =     @(        @{             ###########################            #  VM Creation variables             ###########################                        # Name of the VHD or VHDX to use for VM creation. Must Exist in the            # VMM Library                        VHDName=“WS2016_EN.vhdx“                        # VMM Library share to be used for keeping the resources.            VMMLibrary=“\\SDN-VMM01\MSSCVMMLibrary“                        # Product key Can be blank if using a volume license VHD or VHDX, or you are            # deploying in eval mode.  (Don’t forget to press „skip“ while VM creation).            # This key is the AVMA for Windows Server 2016 Datacenter Edition            ProductKey=“TMJ3Y-NTRTM-FJYXT-T22BY-CWG3J“            #Generation of VM to be used for deployment : Gen1 or Gen2            Generation=“Gen2″            #Type of Deployment. The values are :            #Standalone : For single Node             #Production : For 3-node            DeploymentType=“Production“                #Higly Available VM. Do you want the infrastructural VMs to be deployed on            #Clustered Host and being higly Available ? If yes pass $true else $false            HighlyAvailableVMs = $true                        StorageClassification = „Remote Storage“            #leave it if you want default IPvAddressType to be taken which is static            # else change it to „Dynamic“            IPv4AddressType=““                                    #Host Group to be Managed by Network Controller            NCHostGroupName=“SDN-Hosts“                        #########################################################################            # Section for deploying Logical switch and Logical Network for NC.             #            # Specify IsLogicalSwitchDeployed = $false and             #         IsManagementVMNetworkExisting = $false            # if VMMExpress.ps1 should try to create a SET switch.             #            # If SET cannot be used you have to deploy Logical Switch and             # Management Network by yourself.            #            # NOTE : This script assumes either you have both logical switch and            # logical Network created and deployed or else you will use the script            # to deploy both.             #########################################################################                        #Do you have an existing logical switch and the switch is deployed on all            #the hosts you wish to Manage by NC            IsLogicalSwitchDeployed = $false            # IsLogicalSwitchDeployed =  $true                        #if above is true give the name of logical switch               LogicalSwitch  = „NC_LogicalSwitch“            # Do you have existing Management Network that you would like to use            IsManagementVMNetworkExisting = $false            # IsManagementVMNetworkExisting = $true            #if above is true give the name of ManagementVMNetwork            ManagementVMNetwork = „NC_Management“            #Uplink Port Profile to be used            UplinkPortProfile = „HV Uplink Port“                                     #====================================================================================            # The below set of Parameters are required for creation of Management Logical Network            # and other Logical Networks Managed by NC.                                                       # NOTE : If you already have Management Logical Network Created and switch deployed,            # you don’t need to specify any parameters for „NC_Management“ LN            #====================================================================================             LogicalNetworks = @(               @{                    Name = „HNVPA“                    Subnets = @(                        @{                            # VLANID = 255                                                                  VLANID = 0                                                                         AddressPrefix = „10.10.10.0/24“                                   DNS = @(„192.168.80.10“)                                             Gateways = „10.10.10.1“                                                 PoolStart = „10.10.10.100“                                              PoolEnd = „10.10.10.199“                                           }                    )                },               @{                    Name = „Transit“                    Subnets = @(                        @{                            # VLANID = 254                                                                VLANID = 0                                                                        AddressPrefix = „10.10.20.0/24“                                  DNS = @(„192.168.80.10“)                                            Gateways = „10.10.20.1“                                                PoolStart = „10.10.20.100“                                            PoolEnd = „10.10.20.199“                                          }                      )                },                 @{                    #The first IP address (PoolStart) for this logical network is                     #automatically assigned to the SLB Manager. Other addresses such                    #as the GatewayPublicIPAddress will start after that.                    Name = „PublicVIP“                    Subnets = @(                        @{                            VLANID = 0                            AddressPrefix = „10.10.50.0/24“                               DNS = @(„192.168.80.10“)                                         Gateways = „10.10.50.1“                                             PoolStart = „10.10.50.100“                                          PoolEnd = „10.10.50.199“                                            IsPublic = $true                        }                      )                },                @{                    #The first IP address (PoolStart) for this logical network is                     #automatically assigned to the SLB Manager. Other addresses such                    #as the GatewayPublicIPAddress will start after that.                    Name = „PrivateVIP“                    Subnets = @(                        @{                            # VLANID = 253                            VLANID = 0                            AddressPrefix = „10.10.30.0/24“                                 DNS = @(„192.168.80.10“)                                           Gateways = „10.10.30.1“                                               PoolStart = „10.10.30.100“                                            PoolEnd = „10.10.30.199“                                              IsPublic = $false                        }                      )                },                @{                    #This is used for onboarding Gateway                    Name = „GREVIP“      # Don’t change this. There should be no LN with this name in VMM                    Subnets = @(                        @{                            VLANID = 0                            AddressPrefix = „10.10.40.0/24“                                   DNS = @(„192.168.80.10“)                                             Gateways = „10.10.40.1“                                                 PoolStart = „10.10.40.100“                                              PoolEnd = „10.10.40.199“                                                IsPublic = $false                        }                      )                }                    @{                  # if Management VM Network is not deployed give the ManagementVMNetwork information. Skip                  # this if you already have this created.                    Name = „NC_Management“                    Subnets = @(                        @{                            # VLANID = 811                                                             VLANID = 0                                                                     AddressPrefix = „192.168.80.0/24“                            DNS = @(„192.168.80.10“)                                          Gateways = „192.168.80.1“                                         PoolStart = „192.168.80.230“                                      PoolEnd = „192.168.80.254“                                        ReservedIPset =  „192.168.80.230“      #This IP will be used for NC Rest API                           }                      )                }            )                    #=========================================================================================            # The following set of paremeters are required for importing VMM service Template,            # configuring the Service Template and Deploying the service Template.            #==========================================================================================            # Make this true if self signed certificate is to be used            # Example : $True , $False            IsCertSelfSigned = $true             #The password for server certificate. This certificate will be installed on the Host            ServerCertificatePassword=“Passw0rd!“                      # The following are service settings required for configuring and            # deploying the service template imported client security Group Name            ClientSecurityGroupName= „SDNcloud\Network Controller Users“            # Local Admin credentials            # The local admin user name will be .\Administrator            LocalAdminPassword= „Passw0rd!“               # Management Domain Account Which will be used for NC Deployment            ManagementDomainUser=“SDNcloud\FabAdmin“            ManagementDomainUserPassword=“Passw0rd!“            # This is the domain which NC VMs will join            ManagementDomainFDQN=“SDNcloud.local“              #Managemet Security Group Name            ManagementSecurityGroupName=“SDNcloud\Network Controller Admins“                        # Prefix to be added to infrastructural VMs created. Put the prefix such            # that it makes VM name unique as this is the machine name of VM and should be unique.                        ComputerNamePrefix = „SDN“              # RestName = „SDN-NCREST.SDNcloud.local“            RestName = „192.168.80.230“                        ##################################            #  Deoloyment Control Switches               ##################################                                                # Do you want to deploy NC            # DeployNC = $false            DeployNC = $true                        #Do you want to create NC managed HNVPA and Transit networks.             #These are required if SLB and GW needs to be deployed            # createNCManagedNetworks = $false            createNCManagedNetworks = $true            #Do you want to Deploy SLB. Values are $true , $false            # DeploySLB =   $true            DeploySLB =   $false            #Do you want to deploy GW. Values are $true , $false            # DeployGW = $true            DeployGW = $false        };                );}

Schrittweises Deployment der SDN-Komponenten

Ich habe bereits erwähnt, dass die Datei Fabricconfig.psd1 auch Schalter zur Steuerung der von VMMExpress.ps1 durchzuführenden Aktionen enthält. Ich werde dies für das Deployment unserer SDN Lab-Umgebung nutzen.

Ich sehe darin den Riesenvorteil, dass man jede Komponentenkategorie separat ausrollen und validieren kann. So kann man z.B. vor der Installation der Software Load Balancer sicherstellen, dass die Netzwerk Controller Umgebung korrekt arbeitet und die Netzwerkvirtualisierung mit dem VXLAN-Protokoll funktioniert.

Folgende Schalter stehen zur Verfügung. Sie finden Sie am Ende der Datei Fabricconfig.psd1:

DeployNC = $true | $false

Durch Angabe von $true weisen Sie das Skript an, die Netzwerk Controller Instanzen zu erzeugen. Ändern Sie diesen Wert auf $false, wenn Sie nach einer erfolgreichen Installation des Netzwerk Controllers nur die Software Load Balancer bzw. Gateway Instanzen erzeugen wollen.

createNCManagedNetworks = $true | $false

Durch Angabe von $true werden durch VMMExpress.ps1 die für die SDN-Umgebung notwendigen logischen Netze wie HNVPA, Transit, PublicVIP, GREVIP und PrivateVIP im VMM erzeugt und an die SDN-Switches in den Hyper-V Hosts verteilt. Diese Netze müssen vorhanden sein, um die SLB und Gateway Komponenten erzeugen zu können.

DeploySLB = $false | $true

Damit legen Sie fest, dass die Software Load Balancer Komponenten erzeugt werden. Wenn Sie $true angeben, muss sichergestellt sein, dass zuvor der Netzwerk Controller und die logischen SDN-Netze erfolgreich erzeugt wurden.

DeployGW = $false | $true

Damit legen Sie fest, dass die Gateway Komponenten erzeugt werden. Wenn Sie $true angeben, muss sichergestellt sein, dass zuvor der Netzwerk Controller, die logischen SDN-Netze sowie die SLB-Komponenten erfolgreich erzeugt wurden.

Starten des Netzwerk Controller  Deployments

Wenn Sie die Konfigurationsdatei Fabricconfig.psd1 mit den zu Ihrer Umgebung passenden Parametern und den gewünschten Ablaufsteuerungsschaltern erstellt haben, speichern Sie diese im gleichen Verzeichnis wie das Skript VMMExpress.ps1 mit einem passenden Namen, z.B. für unsere Lab-Umgebung unter Fabricconfig-SDNcloud-Production.psd1.

Dann können Sie das SDN-Deployment mit folgendem Aufruf in einer Powershell Konsole mit Admin-Rechten folgendermaßen starten:

.\VMMExpress.ps1 -ConfigurationDataFile .\Fabricconfig-SDNcloud-Production.psd1

Anmerkung: Mit den in der vorstehenden Fabricconfig-SDNcloud-Production.psd1 angegebenen Ablaufsteuerungsschaltern werden wir zunächst nur die Netzwerk Controller Komponenten und die notwendigen logischen Netze erzeugen.

Tipp: Laden Sie VMMExpress.ps1 in ein PowerShell ISE Fenster und arbeiten Sie im Debug Modus. Ich werde gleich darauf zurückkommen.

Erfahrungen, Tipps und Tricks

Hyper-V Switch Deployment

In den meisten Fällen kann die Logik in VMMExpress.ps1 verwendet werden, um in den Hyper-V Hosts einen SDN-kompatiblen Switch zu erzeugen. Dieser wird mit SET (Switch Embedded Teaming) angelegt. Das Skript prüft dazu die in den Hyper-V Hosts vorhandenen physischen Netzwerkadapter und bindet den SDN-Switch an den ersten Adapter, der im Trunk Mode mit dem physischen Netz verbunden ist und dem noch kein logisches Netz zugeordnet ist.

Skript-Ausschnitt Zeile 738:

         $NetworkAdapter = @(Get-SCVMHostNetworkAdapter -VMHost $VMHost | `                    where {$_.VLanMode -eq „Trunk“ -and `                           $_.ConnectionState -eq „Connected“ -and `                           $_.LogicalNetworkMap.count -eq  0})

Wird kein geeigneter Adapter gefunden ($NetworkAdapter.count -eq 0), gibt das Skript eine Warnung aus. In diesem Fall müssen Sie den logischen SDN-Switch über die VMM-Konsole selbst erzeugen und an die Hyper-V Hosts verteilen.

Ebenso müssen Sie den logischen SDN-Switch selbst erzeugen, wenn Sie SET nicht verwenden wollen (z.B. weil keine geeigneten Netzwerkadapter vorhanden sind oder weil Sie mit „klassischem“ Teaming auf Betriebssystemebene in den Hyper-V Hosts arbeiten wollen).

Anmerkung: SET in Verbindung mit geeigneter Hardware bringt zwar deutliche Performance Vorteile, ist aber keine zwingende Voraussetzung für SDN!

Selbst erzeugte Hyper-V Switches müssen vor dem Start von VMMExpress.ps1 definiert und verteilt sein. Setzen Sie in diesem Fall in der Konfigurationsdatei Fabricconfig.psd1 dann folgende Werte:

            #Do you have an existing logical switch and the switch is deployed on all            #the host you wish to Manage by NC            IsLogicalSwitchDeployed = $true                        #if above is true give the name of logical switch               LogicalSwitch  = „NC_LogicalSwitch“            # Do you have existing Management Network that you would like to use            IsManagementVMNetworkExisting = $true            #if above is true give the name of ManagementVMNetwork            ManagementVMNetwork = „NC_Management“            #Uplink Port Profile to be used            UplinkPortProfile = „HV Uplink Port“ 

REST-IP

Wenn Sie die Production Variante des Netzwerk Controllers ausrollen wollen, müssen Sie für die REST API des NC eine IP-Adresse in der Konfigurationsdatei angeben. Diese muss eine Adresse aus dem IP-Pool für das Management Netz sein und darf nicht für andere Zwecke verwendet werden. Geben Sie in der Definition für das Managementnetz diese IP-Adresse beim Parameter ReservedIPset an:

ReservedIPset = „192.168.80.230“

oder über die VMM Konsole:

Damit ist sichergestellt, dass der VMM diese Adresse nicht einem anderen Objekt zuweisen kann.

In der Konfigurationsdatendatei geben Sie dann diese Adresse beim Parameter RestName an:

RestName = „192.168.80.230“

Beim Erzeugen der NC VMs wird hierdurch von VMMExpress.ps1 diese Adresse für die REST API des NC Guest Clusters konfiguriert.

Bitte verwenden Sie keinen DNS-Namen; dies wird im Deployment für unsere Lab-Umgebung nicht unterstützt. 

Wenn Sie für das NC Deployment die Standalone Variante definiert haben, werden diese Angaben ignoriert. Als IP-Adresse für die REST API wird dann direkt die IP-Adresse der NC VM verwendet.

Undo Funktion

VMMExpress.ps1 hat eine eingebaute Undo-Funktion, die aufgerufen wird, wenn während der Ausführung des Skripts ein Fehler auftritt. Sie sorgt dafür, dass alle zuvor angelegten Objekte in der richtigen Reihenfolge wieder aus dem VMM entfernt werden. Das funktioniert aber nur, solange der Netzwerk Controller noch nicht im VMM als Netzwerk Service registriert ist. Danach müssen Sie manuell die Umgebung wieder bereinigen. Hilfe dazu erhalten Sie in der Technet-Library

Tipp: Führen Sie VMMExpress.ps1 im Debug Modus aus und setzen Sie einen Breakpoint auf den Start der UndoNCDeployment-Funktion (ab Zeile 513). Dann können Sie im Fehlerfall die einzelnen Schritte beim Beseitigen fehlerhafter Objekte genauer mitverfolgen und gegebenenfalls manuell eingreifen.

function undoNCDeployment    {        param([Object] $node)        if ($NetworkControllerOnBoarder -eq $false)…

VMMExpress.ps1 im Debugger ausführen

Im Zusammenhang mit der Undo-Funktion von VMMExpress.ps1 habe ich Ihnen gerade empfohlen, VMMExpress.ps1 im Debug Modus der PowerShell ISE auszuführen. Nach meiner Erfahrung hat dies den Vorteil, dass man die einzelnen Schritte bzw. Funktionsblöcke genauer mitverfolgen kann. VMMExpress.ps1 arbeitet intern mit den CmdLets des PowerShell Moduls für den Virtual Machine Manager. Diese CmdLets starten jeweils einen Job im VMM Server, was im Job-Fenster der VMM-Konsole mitverfolgt werden kann.

Der folgende Screenshot zeigt eine Situation, als während des Erzeugens der VMs für den Netzwerk Controller ein Problem im Hyper-V Cluster auftrat (Zeile 505 in VMMExpress.ps1).

Oftmals können Sie die Ursache des Problems sofort beheben und dann einen Restart des fehlgeschlagenen Jobs versuchen (im Kontextmenü des Jobs).

Ich empfehle Ihnen an folgenden Stellen Breakpoints zu setzen und dann die jeweiligen Befehle im Einzelschrittmodus auszuführen:

NC Deployment

Funktion OnBoardNetworkController Zeile 252:

An dieser Stelle können Sie den Connection String für die REST API des Netzwerk Controllers in der Variablen $ConnectionString überprüfen.

Funktion importServiceTemplate Zeile 359:

Dies wäre eine geeignete Stelle, um über den Service Designer in das importierte NC Service Template noch eine eigene Unattend.xml einzubringen. Achtung: Der VMM erzeugt selbst eine Unattend.xml Datei und mischt sie mit der angegebenen benutzerspezifischen Variante später beim Kreieren der VMs zusammen. Wenn es hier zu Konflikten kommt, kann es sein, dass das gesamte Deployment hängen bleibt.

Funktion configureAndDeployService Zeile 467:

if($ServiceUpdate.deploymenterrorlist -ne $null)

Überprüfen Sie, ob die Variable wirklich $null enthält. Nur dann war die Verteilung der NC VMs auf die Hyper-V Hosts erfolgreich und das Skript kann weiterlaufen. Korrigieren Sie gegebenenfalls das Placement der VMs über den Service Designer in der VMM-Konsole und weisen anschließend der Variablen den Wert $null zu.

Funktion configureAndDeployService Zeile 505:

$sc= New-SCService -ServiceConfiguration $ServiceConfig

Hier können Sie im Service Designer der VMM-Konsole nochmals alle Parameter zum Erzeugen der NC VMs überprüfen.

NC Deployment Validierung

Wenn Sie das Skript VMMExpress.ps1 erfolgreich ausgeführt haben, finden Sie die Netzwerk Controller Komponenten als virtuelle Maschinen und Services im VMM.

Und auch die logischen SDN-Netze sind angelegt:

Damit ist zwar das Deployment des Netzwerk Controllers und der logischen SDN-Netze abgeschlossen. Bevor wir aber weitere SDN-Komponenten ausrollen, sollten wir einige Testszenarien durchspielen, um den NC und die Netzwerkvirtualisierung mit VXLAN zu validieren.

Tenant Testumgebungen

Wir werden 2 Tenant Testumgebungen anlegen. Jede Tenant Umgebung enthält ein VM Network mit jeweils 2 Subnetzen. In jedem Tenant VM Network gibt es dann jeweils 2 VMs.

Tenant VM Netze

Erzeugen Sie 2 Tenant VM Netzwerk Umgebungen („Red VMNet“ und „Green VMNet“) mit identischen Netzwerkdefinitionen:

Subnetz 0: „Red VMnet_0“ bzw. „Green VMnet_0“ – 192.168.0.0/24IP-Pool 0: “Red IP Pool 0” bzw. “Green IP Pool 0” – 192.168.0.4 – 192.168.0.254Gateway in den IP Pools: jeweils 192.168.0.1

Subnetz 1: „Red VMnet_1“ bzw. „Green VMnet_1“ – 192.168.1.0/24IP-Pool 1: “Red IP Pool 1” bzw. “Green IP Pool 1” – 192.168.1.4 – 192.168.1.254Gateway in den IP Pools: jeweils 192.168.1.1

DNS in allen IP Pools:192.168.80.10 (der Standard DNS-Server in unserer Lab-Umgebung auf dem SystemSDN-DC01). 

Sie können dies über die VMM-Konsole oder mit dem weiterunten folgenden PowerShell Skript erledigen.

VMM Konsole

Klicken Sie im VMM Arbeitsbereich VMs and Services mit der rechten Maustaste auf die Kategorie VM Networks und wählen Sie im Kontextmenü Create VM Network.

Geben Sie den Namen des anzulegenden VM Netzwerks an und achten Sie darauf, dass in der Klappliste Logical Network das HNVPA Netz ausgewählt ist. Klicken Sie auf Next.

Lassen Sie im Dialogfenster Isolation die Voreinstellung Isolate using Hyper-V network virtualization und klicken Sie auf Next.

Tragen Sie im Dialogfenster VM Subnets die Parameter für die beiden Subnetze ein. Klicken Sie dann wieder auf Next.

Im Dialog Connectivity lassen Sie die Voreinstellungen und klicken auf Next.

Sie sehen nun eine Zusammenfassung Ihrer Eingaben.

Durch einen Klick auf Finish können Sie nun das Anlegen des VM Networks starten. In der Job-Liste des VMM können Sie das mitverfolgen.

Nun müssen Sie für jedes Subnetz noch den zugehörigen IP Pool anlegen.

Klicken Sie mit der rechten Maustaste auf das soeben erzeugte VM Network (Green VMnet) und wählen Sie im Kontextmenü die Aktion Create IP Pool.

Geben Sie den Namen des IP Pools an. Stellen Sie sicher, dass im Feld VM network das richtige Tenant VM-Netz und im Feld VM Subnet das gewünschte Subnetz ausgewählt sind. Klicken Sie dann auf Next.

Die im Dialog IP address range angezeigten Werte können Sie für unsere Test-Umgebung durch einen Klick auf Next übernehmen.

Geben Sie im Gateway Dialog die Adresse des jeweiligen Gateways ein und klicken Sie auf Next.

Im DNS Dialog geben Sie die Adresse des DNS-Servers unserer Lab-Umgebung (192.168.80.10) ein und klicken auf Next.

Den WINS Dialog können Sie mit Next überspringen. Überprüfen Sie in der Zusammenfassung nochmals Ihre Eingaben und klicken Sie dann auf Finish, um den IP Pool zu erstellen.

In der VMM Jobliste können Sie den Vorgang wieder mitverfolgen. 

Erzeugen Sie analog die IP Pools für die anderen Subnetze der Tenants.

PowerShell

Etwas schneller und komfortabler geht das Ganze mit dem nachstehenden PowerShell Skript. Weisen Sie der Variablen $tenantname den gewünschten Tenant Namen zu und starten das Skript in einer PowerShell Sitzung mit Administrator Rechten.

# Create VM network for tenant$tenantname = „Red“# $tenantname = „Green“$subnet0 = „192.168.0.0/24″$IPrangeStart0 = „192.168.0.4“$IPrangeEnd0 = „192.168.0.254“$gateway0 = „192.168.0.1“$subnet1 = „192.168.1.0/24″$IPrangeStart1 = „192.168.1.4“$IPrangeEnd1 = „192.168.1.254“$gateway1 = „192.168.1.1“$DNSserver = „192.168.80.10“$logicalNetwork = Get-SCLogicalNetwork -Name „HNVPA“# tenant VM net$vmNetwork = New-SCVMNetwork -Name „$tenantname VMnet“ `             -LogicalNetwork $logicalNetwork -IsolationType „WindowsNetworkVirtualization“ `             -CAIPAddressPoolType „IPV4“ -PAIPAddressPoolType „IPV4″# tenant subnets$subnetVLan0 = New-SCSubnetVLan -Subnet $subnet0$VMsubnet0 = New-SCVMSubnet -Name „$tenantname VMnet_0“ `             -VMNetwork $vmNetwork -SubnetVLan $subnetVLan0$subnetVLan1 = New-SCSubnetVLan -Subnet $subnet1$VMsubnet1 = New-SCVMSubnet -Name „$tenantname VMnet_1“ `             -VMNetwork $vmNetwork -SubnetVLan $subnetVLan1# VMnet_0# Gateways$allGateways = @()$allGateways += New-SCDefaultGateway -IPAddress $gateway0 -Automatic# DNS servers$allDnsServer = @($DNSserver)# DNS suffixes$allDnsSuffixes = @()# WINS servers$allWinsServers = @()New-SCStaticIPAddressPool -Name „$Tenantname IP Pool 0“ -VMSubnet $VMsubnet0 `    -Subnet $subnet0 -IPAddressRangeStart $IPrangeStart0 -IPAddressRangeEnd $IPrangeEnd0 `    -DefaultGateway $allGateways -DNSServer $allDnsServer -DNSSuffix „“ `    -DNSSearchSuffix $allDnsSuffixes# VMnet_1# Gateways$allGateways = @()$allGateways += New-SCDefaultGateway -IPAddress $gateway1 -Automatic# DNS servers$allDnsServer = @($DNSserver)# DNS suffixes$allDnsSuffixes = @()# WINS servers$allWinsServers = @()New-SCStaticIPAddressPool -Name „$Tenantname IP Pool 1“ -VMSubnet $VMsubnet1 `    -Subnet $subnet1 -IPAddressRangeStart $IPrangeStart1 -IPAddressRangeEnd $IPrangeEnd1 `    -DefaultGateway $allGateways -DNSServer $allDnsServer -DNSSuffix „“ `    -DNSSearchSuffix $allDnsSuffixes

Den Ablauf des Skripts können Sie wieder über die Jobliste im VMM verfolgen. Als Ergebnis erhalten Sie dann das jeweilige Tenant VM Netzwerk einschließlich der IP Pools.

Tenant Test VMs

Erzeugen Sie für jeden der beiden Tenants 2 VMs und verbinden Sie diese wie folgt mit den Subnetzen der beiden VM Netze:

analog:

• Red-VM02 – verbunden mit Subnetz 1 von VM Netzwerk Red VMnet
• Green-VM01 – verbunden mit Subnetz 0 von VM Netzwerk Green VMnet
• Green-VM02 – verbunden mit Subnetz 1 von VM Netzwerk Green VMnet

Installieren Sie in jeder dieser VMs die Serverrolle Web Server mit Standardeinstellungen. Modifizieren Sie anschließend das Bild der IIS-Startseite – Datei iisstart.png im Verzeichnis C:\inetpub\wwwroot – so dass sie den Namen der VM zeigt, z.B.

Tipp: Das können Sie ganz einfach mit Paint aus dem Windows Zubehör durchführen.

Validierung der Netzwerkisolation mit dem VXLAN-Protokoll

Nun können Sie folgende Szenarien zur Netzwerkisolation mit dem VXLAN-Protokoll durchspielen.

Melden Sie sich auf dem Tenant System Red-VM01 an. Im Server Manager können Sie die zugewiesene IP-Adresse überprüfen:

Melden Sie sich jetzt auf dem Tenant System Red-VM02 an. Der Server Manager wird Ihnen die Adresse 192.168.1.4 anzeigen. Starten Sie den Internet Explorer und geben Sie in die Adresszeile folgende Adresse ein: http://192.168.0.4 – Ergebnis:

Natürlich können Sie auch die umgekehrte Richtung wählen – vom System Red-VM01 (192.168.0.4) aus die Startseite von Red-VM02 (192.168.1.4) aufrufen. Entsprechend erhalten Sie:

Die gleichen Spielchen können Sie jetzt auch zwischen den Systemen im Green-VMnet ausführen. Sie werden immer nur die Systeme im gleichen VMnet erreichen, können aber nicht auf Systeme in anderen VM Netzen zugreifen.

Erkenntnisse:

Innerhalb eines Tenant VM Netzes werden IP-Pakete zwischen den definierten Subnetzen geroutet. Eine Verbindung zu Systemen in andere Tenant VM Netze ist jedoch nicht möglich, auch wenn die IP-Bereiche identisch sind oder sich überlappen.

Nächste Schritte

Mit dem erfolgreichen Deployment der Netzwerk Controller Komponenten haben wir nun die Basis für den weiteren Ausbau unserer Software Defined Networking (SDN) Umgebung geschaffen.

Im nächsten Beitrag werden wir unsere Lab-Umgebung um die SDN-Komponenten für Software Load Balancing erweitern und auch den Zugriff auf unsere Tenant VMs von außen ermöglichen.

Bleiben Sie also dran. Es bleibt weiterhin spannend …

Dieser Blogpost ist der erste von insgesamt fünf Teilen, die in den folgenden Wochen veröffentlicht werden. Grundlage für die Beiträge ist ein Whitepaper, welches ich als Nachlese geschrieben habe zu meinem Vortrag auf der CDC 2018, den ich zusammen mit Petra Lipp gehalten habe. Das Whitepaper steht exklusiv für Newsletter-Abonnenten zur Verfügung. Sie können das vollständige Whitepaper als PDF erhalten, wenn Sie sich für unseren Newsletter anmelden. Nach kurzer Zeit taucht ein Overlay auf, in dem Sie sich registrieren können.

Alle fünf Teile

Im folgenden finden Sie Links zu den fünf Beiträgen. Sollte ein Link noch nicht vorhanden sein, liegt es daran, dass er noch nicht veröffentlicht wurde.

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 1– Architektur und Netzwerk Topologie

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 2– SDN Deployment und eine Lab-Umgebung mit dem Netzwerk Controller

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 3– Software Load Balancing 

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 4– RRAS Gateways

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 5– Zusammenfassung

Die Microsoft SDN-Architektur

Eigentlich gibt es SDN im Windows Server bereits seit der Version 2012R2. Dort hatte Microsoft die Technologie an verschiedenen Stellen im Betriebssystem und im SCVMM „versteckt“. Zur Isolation von Netzen wurde der GRE-Standard (Generic Routing Encapsulation) verwendet. GRE hat sich für diesen Zweck jedoch nicht so recht am Markt durchgesetzt. Die Mehrzahl von Netzwerk-Anbietern setzt mittlerweile auf den VXLAN-Standard (Virtual Extensible LAN), was zur Folge hatte, dass Microsoft dieses Protokoll sowohl in der Microsoft Azure Cloud implementierte und die entsprechenden Komponenten nun auch im Windows Server 2016 bereitstellt.

Anmerkung: VXLAN ist nun das Standard-Protokoll für SDN. Jedoch wird auch weiterhin das GRE-Protokoll unterstützt, so dass bisherige Installationen weiter genutzt werden können. Eine Migration von GRE auf VXLAN ist jedoch nicht vorgesehen und bedeutet eine Neuinstallation.

​Werfen wir zunächst einen Blick auf das folgende Architekturbild, das aus der Microsoft TechNet Library stammt.

Im Zentrum der neuen SDN-Architektur steht eine neue Serverrolle, die nur in der Datacenter Edition von Windows Server 2016 verfügbar ist, der Network Controller. Wir benötigen dafür entweder physische oder auch virtuelle W2016 Datacenter Systeme, auf denen diese Serverrolle installiert und konfiguriert ist. Und warum die Mehrzahl? Technisch würde eine Instanz des Network Controllers genügen. Um aber eine Hochverfügbarkeit zu gewährleisten, empfiehlt Microsoft für produktive Umgebungen aber wenigstens 3 Instanzen.

Der Network Controller besitzt zwei Schnittstellen (APIs), die Northbound API und die Southbound API. Über die Southbound API kommuniziert der Network Controller mit den physischen und virtuellen Netzwerkgeräten, also z.B. mit den physischen Switches im Server Rack (Top of Rack – TOR) oder mit den virtuellen Switches in den Hyper-V Hostsystemen. Über die Northbound API erhält der Network Controller von verschiedenen Netzwerk Management Tools Anweisungen bzw. Richtlinien, wie die über die Southbound API verbundenen Netzwerkgeräte den Netzwerkverkehr behandeln sollen.

Für die Kommunikation zwischen dem Network Controller und den verschiedenen Netzwerkkomponenten muss in einer Microsoft SDN Plattform das in jedem Rechenzentrum ohnehin vorhandene (logische) Management Netz verwendet werden, das ich in diesem Artikel mit NC_Management bezeichnen will.

Anmerkung: Die Einbettung des Network Controllers in das NC_Management Netz hat nicht zur Folge, dass der Netzwerkverkehr virtueller (Kunden-) Maschinen ebenfalls über dieses Netz läuft. Hierfür werden wir noch weitere logische Netze einführen.

Die Northbound API ist als Representational State Transfer (REST) API ausgelegt, so dass beliebige Management Tools, die dieses Protokoll beherrschen, verwendet werden können, um dem Network Controller Richtlinien zu übermitteln. Darüber hinaus bietet diese API auch die Möglichkeit, das Netzwerk zu überwachen und bei Problemen Informationen fürs Troubbleshooting abzurufen.

Als Management Tools für den Network Controller bietet Microsoft aktuell folgende Werkzeuge:

• PowerShell Cmdlets
• den Azure Resource Manager (ARM)
• den System Center 2016 Virtual Machine Manager (SCVMM 2016)

Insbesondere der SCVMM 2016 bietet mit seiner grafischen Benutzeroberfläche eine einfache Möglichkeit zum Konfigurieren des Network Controllers und stellt auch alle Funktionen über eigene PowerShell Cmdlets zur Verfügung. Wir werden uns dies später noch genauer ansehen.

Die über die Northbound API erhaltenen Richtlinien verteilt der Network Controller dann über seine Southbound API an die betroffenen Netzwerkgeräte. Bei Hyper-V Hosts ist dies eine neue Hyper-V Switch Erweiterung (Extension) mit dem Namen Microsoft Azure VFP Switch Extension. VFP steht für „Virtual Filtering Platform“.

Die Microsoft SDN-Architektur besteht also aus 3 Ebenen, wie die folgende Abbildung zeigt.

Netzwerk Controller Funktionalitäten

Mit dem Netzwerk Controller können nun folgende Funktionalitäten realisiert werden:

Netzwerk Virtualisierung

Es können für Gruppen von Kunden VMs (häufig auch als „Tenant“ VMs bezeichnet) eigene logische virtuelle Netze definiert werden. Diese Netze sind voneinander völlig getrennt, auch wenn sie identische Netzwerkparameter wie IP-Bereiche oder VLANIDs besitzen. Die Isolation des Datenverkehrs innerhalb eines solchen virtuellen Netzes erfolgt durch „Verpacken“ der Datenpakete nach dem VXLAN-Protokoll.

Das VXLAN-Protokoll

VMs in einem virtuellen Netz verwenden typischerweise kundenspezifische IP-Adressen („Customer Addresses“ – CAs), die nicht vom Rechenzentrumsbetreiber verwaltet und mit denen die Netzwerkgeräte im Rechenzentrum somit nichts anfangen können. Will nun eine Kunden-VM mit einer anderen kommunizieren, gibt sie ein Ethernet Netzwerkpaket über ihren Netzwerkadapter an einen Switch weiter, in einer Hyper-V Umgebung also an den Hyper-V Switch des Hosts, auf dem sie gerade läuft. Im Hyper-V Switch wird geprüft, ob die Ziel-VM im gleichen Host läuft. Falls ja, wird das Netzwerkpaket vom Switch direkt an die entsprechende VM weitergeleitet. 

Falls die Ziel-VM jedoch auf einem anderen Host läuft, wird das Datenpaket in ein neues Netzwerkpaket mit vom RZ-Betreiber verwalteten IP-Adressen („Provider Addresses“ – PAs) gemäß dem VXLAN-Protokoll verpackt und an den Zielhost per UDP weitergeleitet. Dieser kann dann das ursprüngliche Datenpaket wieder auspacken und an die entsprechende VM weiterleiten.

Um die Zuordnung eines verpackten Kunden-Datenpakets zu gewährleisten, wird jedem virtuellen Kundennetz beim Anlegen über den Netzwerk Controller eine eindeutige VXLANID zugewiesen. Diese VXLANID hat eine Länge von24 Bit. Somit können bis zu 16 Millionen Kundennetze identifiziert werden. Beim Verpacken eines Kunden-Datenpakets wird die VXLANID des Kundennetzes dem Kunden-Datenpaket als Header vorangestellt, so dass beim Auspacken der Daten im Zielhost diese in das entsprechende Kundennetz geleitet werden können.

Für die Kommunikation zwischen den Kunden-VMs benötigen wir also ein (und nur ein) zusätzliches vom Provider verwaltetes logisches Netz, über das die in VXLAN eingepackten Kunden-Datenpakete weitergeleitet werden. Für die weiteren im Netzwerk vorhandenen Geräte wie Switches oder Router sind die Datenpakete der Kunden-VMs also „unsichtbar“ und benötigen somit auch keine weiteren Management Aktivitäten.

Zum Vergleich: Bei der bisherigen Methode zur Netzwerk Virtualisierung mit VLANIDs muss hingegen jedes Kundennetz mit einer eindeutigen VLANID vom Provider definiert, verwaltet und an alle Netzwerkgeräteverteilt werden. Da die VLANIDs nur aus 12 Bits bestehen, ist die Anzahl von Kunden-Netzen außerdem auf knapp 4096 begrenzt.

Das logische Netzwerk zum Weiterleiten der mit VXLAN verpackten Datenpakete wird in einer Microsoft SDN-Umgebung üblicherweise als HNVPA (Hyper-V Netzwerk Virtualisierung mit Provider Adressen)Netz bezeichnet.

Die Netzwerk Virtualisierung mit VXLAN vereinfacht also drastisch das Netzwerkmanagement in einem Rechenzentrum, da sich der Provider nicht mehr explizit um die Isolation von Kundennetzen kümmern muss.

Load Balancing

Für VMs, die in einem virtuellen Kundennetzwerk den gleichen Workload bereitstellen (z.B. Webserver Cluster), kann per Software ein Lastenausgleich („Software Load Balancing“ – SLB) in Form eines SLB-Pools definiert werden. Das Load Balancing wird von eigenständigen über den Netzwerk Controller verwalteten VMs durchgeführt. Die SLB VMs ermöglichen dann auch den Zugriff von außen auf die SLB-Pools in einem virtuellen Kundennetzwerk.

Ein SLB-Pool enthält die virtuellen IP-Adressen der für das Load Balancing vorgesehenen Kunden-VMs (hier als dynamische IP-Adressen – DIPs – bezeichnet). Dem Pool wird dann eine öffentliche IP-Adresse (PublicIP) zugeordnet. PublicVIPs sind typischerweise über das Internet erreichbar, so dass sich Anwender von außen damit verbinden können.

Der Netzwerk Controller übergibt diese Definitionen an die SLB VMs über das NC_Management Netz. Diese wiederum geben die PublicVIPs über das BGP-Protokoll bei einem zentralen BGP-Router bekannt, der die Verbindung zur Außenwelt bereitstellt. Die Kommunikation zwischen den SLB-VMs und dem BGP-Router wird typischerweise über ein eigenes logisches Netz mit dem Namen Transit abgewickelt.

Erreicht nun eine Anfrage den BGP-Router zu einer ihm bekannt gemachten öffentliche VIP-Adresse, leitet er diese über das Transit Netzwerk einer SLB-VM zur weiteren Bearbeitung weiter. Da alle SLB-VMs die gleichen Pool-Definitionen enthalten, bestehen also mehrere Wege für diese Weiterleitung. Wir sprechen deshalb hier auch von einem SLB Multiplexer oder SLB-MUX. Bei der Weiterleitung wird die Zieladresse der Anfrage mit der SLB-MUX Adresse im Transit Netz überschrieben.

Der SLB-MUX kann nun in Zusammenspiel mit den SLB Agents in den Hyper-V Switches entscheiden, an welche VM bzw. DIP die Anfrage zur Bearbeitung gegeben wird. In der Anfrage wird dazu die Zieladresse mit der ermittelten DIP überschrieben, das Datenpaket mit VXLAN verpackt und dem entsprechenden Hyper-V Host über das HNVPA-Netz übermittelt. Der Hyper-V Host entpackt das Paket und leitet es an die VM weiter.

Die VM erstellt nun eine Antwort, die als Ziel die ursprüngliche Client Adresse enthält und als Sender die eigene DIP. Der Switch im Hyper-V Host ersetzt diese DIP wieder mit der dem SLB-Pool zugeordneten PublicVIP und sendet das Paket dann über ein Gateway im öffentlichen Netz direkt an den Client, von dem die Anfrage kam. Der Client bekommt also nichts mit von den verschiedenen Weiterleitungsschritten innerhalb der SLB-MUX Umgebung.

Remote Access Service (RAS) Multitenant Gateways

In der vorstehenden Beschreibung für die Load Balancing Funktion habe ich kurz beschrieben, wie eine Anfrage eines einzelnen Clients aus dem Internet in einer SDN-Umgebung bearbeitet wird. In vielen Fällen wird es jedoch notwendig sein, nicht nur von einem einzelnen Client System eine Verbindung zu den VMs eines Tenants herzustellen, sondern ganze externe Netzwerke mit den virtuellen Systemen eines Tenants zu verbinden.

Hierzu stellt der Netzwerk Controller die Funktion Remote Access Service (RAS) Multitenant Gateway bereit. Es handelt sich dabei (ähnlich den SLB-MUX Systemen) um eigene VMs, die über den Netzwerk Controller verwaltet werden. Damit können dann folgende Remote Szenarien realisiert werden:

• Site-to-Site VPN
• Point-to-Site VPN
• GRE Tunneling
• ​Dynamic Routing mit dem Border Gateway Protocol (BGP)

Ich werde hier nicht näher auf diese Themen eingehen, da wir dazu entsprechende Remote Systeme benötigen, deren Konfiguration weit über das Thema SDN hinausgehen. Vielleicht kommen wir in einem späteren eigenen Beitrag darauf zurück.

SDN-Topologie

Nachdem wir nun einige grundlegende Merkmale der Microsoft SDN Architektur geklärt haben, wollen wir uns kurz anschauen, wie dies alles in eine physikalische Umgebung abgebildet werden kann.

Logische Netze

Fassen wir zusammen, welche logischen Netze in einer SDN-Umgebung notwendig sind:

• NC_Management – Dies ist das zentrale Netzwerk, über das alle Systeme in einem „Software Defined Datacenter“ (SDDC) verwaltet und konfiguriert werden, also die Netzwerk Controller mit den SDN-Komponenten wie SLB-MUXe und Gateways, die Hyper-V Hosts, aber auch weitere Infrastruktursysteme wie Active Directory, DNS und der SCVMM. Der Netzwerk Controller erhält und verteilt über dieses Netz auch die Anweisungen für die SDN-Komponenten.
• HNVPA – Über dieses Netz laufen die mit dem VXLAN-Protokoll verpackten Netzwerkpakete der Tenant VMs zwischen den Hyper-V Hosts.
• Transit – Dieses Netz wird verwendet für die Kommunikation zwischen den SLB-MUX Systemen und der Außenwelt, z.B. mit einem BGP-Router, der mit dem Internet verbunden ist.

Diese 3 logischen Netze bilden das Rückgrat von SDN. Sie müssen in allen beteiligten Hyper-V Hosts verfügbar und dort mit den virtuellen Switches verbunden sein. Diese Netze besitzen jeweils einen eigenen IP-Adresspool. Zusätzlich können sie optional durch VLANs untereinander isoliert sein, was jedoch kein Muss ist (in der später noch zu beschreibenden Lab-Umgebung werde ich darauf verzichten).

Für spezielle Szenarien sind gegebenenfalls weitere logische Netze notwendig, die dann aber nicht in den Hyper-V Hosts verfügbar sein müssen:

• PublicVIP – Dieses Netz stellt das Tor zum und vom Internet dar. Bei den verwendeten IP- Adressen wird es sich also in der Praxis um öffentliche Adressen handeln und es gibt auch keine Isolation mit VLAN IDs. 
• PrivateVIP – Dieses Netz enthält private Adressen, über die interne Clients wie z.B. die SLB Manager und andere interne Dienste miteinander kommunizieren können.
• GREVIP – Dieses Netz enthält virtuelle IP-Adressen für Endpunkte von Site-to-Site (S2S) Verbindungen mit externen (Tenant) Netzen, bei denen das GRE-Protokoll verwendet wird.

Neben diesen SDN-spezifischen logischen Netzen wird es in einem Rechenzentrum weitere logische Netze z.B. für die Storage Anbindung geben, die wir hier aber nicht weiter betrachten wollen.

Hyper-V Hardware

Für den Aufbau einer SDN-Umgebung benötigen wir eine Reihe von Hyper-V Hosts mit der Windows Server 2016 Datacenter Edition. Es sollten wenigstens 3-4 Systeme verfügbar sein, die idealerweise in einem Hyper-V Failover Cluster zusammengefasst sind. In einer produktiven Umgebung wird man natürlich deutlich mehr Systeme einsetzen.

Netzwerk Hardware

Eigentlich stellt SDN keine speziellen Anforderungen an die Netzwerk Hardware in den Hyper-V Hosts. Jedoch muss man berücksichtigen, dass der gesamte SDN-Netzwerkverkehr über die virtuellen Switches in den Hyper-V Hosts läuft und deshalb eine hohe Bandbreite und Verfügbarkeit erfordert. Deshalb sollte man über Teaming der in den Hyper-V Hosts verbauten Netzwerkadapter als Option nachdenken, was aber nicht zwingend ist. 

Für Teaming kann sowohl das „klassische“ Teaming auf Basis des Windows Betriebssystems als auch das „Switch Embedded Teaming“ (SET) im Hyper-V Switch von Server 2016 zum Einsatz kommen. Letzteres ist natürlich vorzuziehen, wenn dies mit den vorhandenen Netzwerkadaptern möglich ist.

Putting It All Together

Wenn wir alle vorstehend beschriebenen Komponenten in einerSDN-Umgebung zusammenfassen, dann ergibt sich folgendes Bild für die SDN-Topologie:

Quelle: https://docs.microsoft.com/en-us/windows-server/networking/sdn/plan/plan-a-software-defined-network-infrastructure#network-controller-software-load-balancer-and-ras-gateway-deployment

 Die unterste Ebene zeigt das physikalische Netz und die darin eingebetteten logischen SDN-Netze. Mit diesem Netz sind die Netzwerkadapter aller Hyper-V Hosts verbunden, gegebenenfalls auch als Team. Wenn Sie die logischen SDN-Netze als VLANs definiert haben, ist es wichtig, dass für die Ports an den physischen Switches, mit denen die Hyper-V Hosts verbunden sind, der Trunk Mode eingestellt ist. Nur dann sind in den virtuellen Hyper-V Switches alle SDN-Netze verfügbar.

Die virtuellen Hyper-V Switches präsentieren die SDN-Netze den im Host laufenden Infrastruktur VMs wie Netzwerk Controller, SLB-MUXe oder Gateways, so dass sie sich mit ihren virtuellen Netzwerkadaptern damit verbinden können.

Die virtuellen Netzwerkadapter von Tenant VMs sind im Hyper-V Switch mit dem HNVPA Netz verbunden. Das Ver- und Entpacken der Tenant Daten mit dem VXLAN-Protokoll erfolgt dann im virtuellen Hyper-V Switch.

Weitere Infrastruktursysteme

Außer den Hyper-V Compute Systemen benötigen wir noch einige weitere Infrastruktursysteme:

• Active Directory mit DNS
• Ein System mit dem System Center Virtual Machine Manager (SCVMM) 2016 für das Management der SDN-Umgebung
• Einen BGP-Router, der uns die Verbindung zum öffentlichen Netz bereitstellt.

Auf diese Systeme werde ich im nächsten Blogpost wieder zurückkommen, wenn wir unsere Lab-Umgebung aufbauen.

Auf der Cloud & Datacenter Conference Germany 2018 in Hanau habe ich zusammen mit Petra Lipp einen Vortrag zum Thema „Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016)“ gehalten. Mittlerweile haben wir einige Anfrage nbekommen über Details zu den gezeigten Präsentationen und Demoszenarien. 

Da keine Mitschnitte von der Veranstaltung existieren, habe ich beschlossen, die wichtigsten technischen Informationen sowie eine Beschreibung zum Aufbau der gezeigten Demoumgebung in einem Whitepaper zusammenzufassen.

Sie können das Whitepaper über diesen Link auf Ihr System downloaden: VMM-SDN.PDF

In diesem Whitepaper sind auch einige PowerShell Skripte beschrieben, die zusätzlich zu den von Microsoft auf GitHub bereitgestellten erstellt wurden, um Aktionen, die mit vielen Mausklicks verbunden sind, etwas zu vereinfachen. Diese zusätzlichen Skripte sind in einer .ZIP-Datei zusammengestellt, die Sie hier downloaden können. Details zum Inhalt dieser .ZIP-Datei finden Sie am Ende des Whitepapers.

​

Anmerkung: Warum wir immer benchmarken habe ich in meinem Webinar Storage Spaces Direct Deep Dive – Best Practices begründet (Alle unsere Webinare findet ihr in userem Webinar Archiv). Wie man VMFleet aufsetzt könnt Ihr in der Hyper-V Amigos Showcast Episode 15 – VMFleet mit meinem Kumpel Didier Van Hoye gezeigt.

Jetzt kam am 11. Juli ein Tweet von Frederic Stefani @FredericStefani in dem er darauf hinweist das die VMFleet den CsvBalancer ausschaltet (siehe Bild). 

Das ist erstmal die Frage: was ist der CsvBalancer. Ganzeinfach in einem Hyper-V Cluster mit SAN oder auch in einem Storage Spaces Direct Cluster hat man die Daten in Cluster Shared Volumes liegen. Hiervon sollte man pro Knoten mindestens eine CSV haben, also in einem 4 Knoten S2D Cluster mindestens 4 Stück. Der CsvBalancer sorgt nun dafür, das die CSVs über die Knoten verteilt werden.

Und genau diese Verhalten wird von der VMFleet abgeschaltet, weswegen man den CsvBalancer nach der Verwendung der VMFleet wieder einschalten sollte.

Um das zu tun logt ihr euch auf einem der Storage Spaces Direct Cluster Knoten ein, startet eine administrative PowerShell und gebt folgenden Befehl ein:

(Get-Cluster).CsvBalancer = 1

Und schon wird wieder balanciert.

Viel Spaß mit eurer Storage Spaces Direct Installation

Carsten Rachfahl

​

• Teil 1 – Was ist Storage Spaces Direct?
• Teil 2 – Grundlegende Anforderungen für Storage Spaces Direct
• Teil 3 – SSD und NVMe, DWPD, TBW und PBW berechnen und verstehen
• ​Teil 4 – Netzw​​​​​erkdesign bei Storage Spaces Direct

In diesem Teil der Blogpost Serie möchte ich euch die verschiedenen Möglichkeiten für das Netzwerkdesign bei einem Storage Spaces Direct Failover Cluster aufzeigen.

Mit dem Windows Server 2016 stehen uns  zwei unterschiedliche ​Switch Typen zur Verfügung, die ich hier kurz vorstellen möchte.

Einmal der Hyper-v Switch mit dem LBFO Team.  LBFO steht für Load Balancing and Failover. Das LBFO Team wurde mit Windows Server 2012 eingeführt.

Das LBFO Team unterstützt alle verfügbaren Teaming Modi. Hier können bis zu 32 Netzwerkkarten zu einem Team hinzugefügt werden. Es kann unabhängig von einem Hyper-V Switch angelegt werden.

Ein Hyper-V Switch der auf Basis des LBFO Teams angelegt wurde, unterstützt alle verfügbaren Switch Extensions. Eine virtuelle Netzwerkkarte (vNIC) die auf Basis des LBFO Teams angelegt wird, verfügt nicht über RDMA und RSS. Das LBFO Team kann über den Server Manager erzeugt werden. Mit folgendem PowerShell Beispiel kann ein LBFO Team angelegt werden.

New-NetLBFOTeam -Name „TEAM LAN“ -TeamNICName ‚TEAM LAN‘ -TeamMembers ‚LAN1′,’LAN2‘ -TeamingModeSwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

Der zweite Teaming Mode ist der SET Switch. SET steht für Switch Embedded Teaming. Wie der Name schon sagt, ist hier die NIC-Teaming Logik im Hyper-V Switch integriert. D. h. es wird ein Hyper-V Switch erzeugt, dem dann Netzwerkkarten zugewiesen werden. Dieser Teaming Mode wurde mit Windows Server 2016 neu eingeführt. Ein SET Switch kann nur über die PowerShell oder dem SCVMM 2016 angelegt werden. Der SET Switch unterstützt nur Microsoft SDN (Software Defined Network) Extensions und Switch Independent Teaming. Ein Vorteil des SET Switches, vNICs unterstützen RDMA und RSS. Ganz ausführlich hat mein Kollege Jan Kappen in folgenden Blogpost  dem SET Switch beschrieben. Mit folgendem PowerShell Beispiel kann ein SET Switch angelegt werden.

New-VMSwitch -Name ‚vSwitch‘ -NetAdaperName ‚LAN1′,’Lan2‘ -EnableEmbeddedTeaming $true -AllowManagementOS $false

Einige Grundsatzregeln vorweg:

Optimal ist es, wenn wir unsere Netzwerke ausfallsicher, entweder im Team oder wie beim SMB Netzwerk, mit mind. 2 SMB Netzwerken einplanen. Optimal wäre es zu dem, wenn wir die Netzwerke über zwei Netzwerkkarten verteilen könnten, so dass auch eine Netzwerkkarte ausfallen kann, ohne dass ein Netzwerk komplett wegbricht.

Die Netzwerkkarten für den SMB Traffic werden nicht geteamt. Wir benötigen immer separate NICs. Microsoft empfiehlt für den SMB Traffic mind. 2 x 10 Gbps. Das erhöht die Ausfallsicherheit und die Performance. Sollten NVMe als Cache Laufwerke vorgesehen werden, so empfiehlt es sich, nach unserer Erfahrung, für den SMB Traffic auf 25 Gbps pro NIC zu gehen. Ab Windows Server 2016 können SMB Direct Netze im selben Subnetz liegen. Wir empfehlen dennoch, dass die SMB Netze jeweils in einem separaten IP Segment betrieben werden. RDMA benötigt zusätzlich eine VLAN ID.

Auch bei den weiteren Netzwerken ist genügend Bandbreite einzuplanen z.B. fürs Backup.

S2D Converged Networking Stack:

Die erste Frage, die wir uns nun stellen sollten ist: Welche Netzwerke benötigen wir?

• Server (Domain) Lan (MGMT)
• Cluster Traffic (Livemigration, Heartbeat)
• SMB Traffic

für das converged Deployment benötigen wir keinen virtuellen Switch, der die Kommunikation mit den VMs ermöglicht.

Designvariante  –  mit 2x MGMT-LAN Ports und 2x SMB Direct Ports

Beschreibung:

• Ein Team fürs MGMT-LAN
• Der Ost-West SMB Traffic (zwischen den Clusterknoten) erfolgt über SMB1 + SMB2
• Der Nord-Süd SMB Traffic (zu den Hyper-V Hosts) erfolgt ebenfalls über SMB1 + SMB2
• Cluster Traffic erfolgt auch über die SMB Adpater

Vorteil:

​​

Nachteil:

• ​​Es wird nur eine Dual Port RDMA NIC benötigt.
• Einfache Konfiguration

• Sowohl der Ost-West, wie auch der Nord-Süd SMB Traffic gehen über den gleichen Adapter.
• Keine saubere Trennung des SMB Traffics und keine Ausfallsicherheit des RDMA Adapters.

Designvariante – mit 2x MGMT-LAN Ports und 4x SMB Direct Ports

​​​​Beschreibung:

• MGMT Traffic über das MGMT-Team
• Ost-West SMB Traffic über SMB1 + SMB2
• Cluster Traffic erfolgt über SMB1 + SBM2
• Nord-Süd SMB Traffic über SMB3 + SMB4

​

Vorteil:

​

​

​​

Nachteil:

• Der Nord-Süd SMB Traffic und Ost-West SMB Traffic ist über separate SMB Netze sauber voneinander getrennt
• Es werden zwei Dualport RDMA NICs benötigt. Die SMB Netze können ausfallsicher über die beiden Netzwerkkarten verteilt werden.
• Die von uns bevorzugte Variante

• Mehr Hardware durch eine weitere Dualport RDMA NIC
• komplexeres Setup

S2D Hyper-Converged Networking Stack:

beim hyper-converged Deployment benötigen wir zu den bereits unter dem converged Deployment aufgeführten Netzwerken, zusätzlich noch einen Hyper-V Switch für die Kommunikation der VMs.

Designbeispiel – SMB Direct und LBFO Team

Beschreibung:

•  2 NIC Ports im LBFO Team für:
  • Hyper-V Switch (für die VMs)
  • vNIC für das MGMT-LAN
• SMB1 und SMB2 für:
  • Livemigration
  • Clusterkommunikation
  • Ost-West SMB Traffic

Vorteil:​

​

​​

​​

Nachteil:

• Das LBFO Team ist ein seit 2012 bekanntes und stabiles Design.
• Beim LBFO Team werden alle Teaming Modi unterstützt.
• Der Hyper-V Switch auf Basis vom LBFO Team unterstützt alle Extensions
• Ausfallsicherheit durch mehrere Netzwerk Adapter
• Die von uns bevorzugte Variante

• vNIC  (MGMT-LAN) unterstützt kein RDMA und RSS

Designbeispiel – Switch Embedded Teaming (SET)

Beschreibung:

eine DualPort RDMA Netzwerkkarte verbunden über einen SET Switch

• Hyper-V Switch für VMs
• eine vNIC für das MGMT-LAN
• 2 vNICs für das SMB1 + SMB2  Direct  LAN
• das SMB Direct LAN w​ird genutzt für
  • Livemigration
  • Clusterkommunikation
  • Ost-West SMB Traffic

Vorteil:​

​​​

Nachteil:

• vNICs unterstützen RDMA und RSS
• einfaches und günstiges Design

• SET Switch unterstützt nur Microsoft SDN Extensions und Switchindepended Teaming
• der gesamte Netzwerktraffic des hyper-converged S2D Clusters geht über eine Netzwerkkarte – keine Ausfallsicherheit.
• SMB und VM Traffic laufen über die selbe Switch Infrastruktur – keine Trennung des Storage Traffic vom übrigen LAN Traffic.
• SET Switch Technologie ist noch nicht so ausgereift wie das LBFO Team

​Mein Fazit ​aus unseren Erfahrungen in den Storage Spaces Direct Projekten ist, ein gut geplantes Netzwerk kann die Performance steigern und trägt viel zur Stabilität der Umgebung bei.

Im Teil 5 geht es um „SMB 3 und SMB Direct“

gutes Gelingen und bis zum nächsten Mal

Petra

Follow exactly the description of the Blogpost „Installing Azure Stack Development Kit in a Hyper-V Nested VM„. In the Chapter „Modify the CloudBuilder.VHDX“ you have to change two lines in the ACSBlob.psm1 file (which is also included in the Microsoft.AzureStack.Solution.Deploy.CloudDeployment.x.x.x.nupkg):

The full path to the ACSBlob.psm1 file is:

• X:/content/Roles/Roles/ACS/ACSBlob.psm1

In the file you search for the lines (arround 415):

• $acsBlobLogPath = „D:\AzureStack\Logs\ACS\blob“
• $acsBlobDumpPath = ‚D:\AzureStack\CrashDumps\blob‘

and modify them to:

• $acsBlobLogPath = Join-Path -Path $env:ProgramData -ChildPath „Microsoft\AzureStack\Logs\ACS\blob“
• $acsBlobDumpPath = Join-Path -Path $env:ProgramData -ChildPath „Microsoft\AzureStack\CrashDumps\blob“

A big thanks to Elmar Szych you shared this solution with me.

• Teil 1 – Was ist Storage Spaces Direct?
• Teil 2 – Grundlegende Anforderungen für Storage Spaces Direct
• Teil 3 – SSD und NVMe, DWPD, TBW und PBW berechnen und verstehen
• ​Teil 4 – Netzw​​​​​erkdesign bei Storage Spaces Direct​

Die Lebensdauer einer SSD oder einer NVMe kann in DWPD (Drive writes per day) , in TBW (Terabytes written) oder PBW (Petabyte written) angeben werden.

DWPD (drive write per day) gibt an, wie häufig eine SSD oder NVMe pro Tag  auf ihre Lebensdauer gesehen, komplett überschrieben werden kann. Der DWPD Wert basiert auf der Größe des Laufwerkes.

​Unten seht ihr am Beispiel der Samsung PM1725a den DWPD-Wert aller Größen.

​TBW (Terabytes written) bzw. PBW (Petabytes written) gibt an, wieviel Daten auf eine SSD oder NVMe gemessen auf  ihre Lebensdauer geschrieben werden kann.  Der TBW und PBW Wert berücksichtig nicht die Größe des Laufwerks.

Am Beispiel der Intel Optane DC P4800X Series könnt ihr das gut sehen.

Wir erinnern uns, Microsoft gibt für Caching Devices in den Hardware Requirements folgendes vor: 

• DWPD von 3 und höher  oder
• 4 TBW pro Tag – auf 5 Jahre wären das 4 TB * 5 Jahre * 365 Tage = 7.300 TBW = ca. 7,3 PBW

Mit den folgenden Formeln, können wir die unterschiedlichen Herstellerangaben umrechnen und miteinander vergleichen. Die Formel geht von einer Festplattengröße in GB aus, solltet ihr eine TB Größenangabe haben, so könnt ihr die Multiplikation/Division mit 1024 weg lassen. 

• DWPD = TBW * 1024 / (Capacity GB * Lebensdauer in Jahre * 365) 
• DWPD = PBW * 1024 * 1024 / (Capacity GB * Lebensdauer in Jahre * 365)
• TBW = (DWPD * Lebensdauer in Jahre * 365 * Capacity GB)/1024
• PBW = TBW / 1024

Ob jetzt mit 1024 oder mit 1000 gerechnet wird, ist von Hersteller zu Hersteller unterschiedlich. Ich habe mich hier bei unseren Beispielen dafür entschieden mit 1024 zu rechnen. Doch ihr könnt auch mit 1000 rechnen.

Was bedeutet dies nun für uns im Bezug auf die Cache Laufwerke von Storage Spaces Direct?

​Es ​​muss ein Cache Anteil von mindestens 10 % oder höher gemessen an der Brutto Festplattenkapazität berücksichtigt werden. Wenn wir die Gesamtgröße des Cachebedarfs so ermittelt haben, können wir bestimmen welche Anzahl und Größe wir für die Cache Laufwerke benötigen. 

Beispiel:

wir planen 32 TB Bruttokapazität pro Knoten – somit benötigen wir mind. 3,2 TB (10 %) Caching Devices je Knoten – das könnten 2 x 1,6 TB oder 4 x 800 GB Caching Devices sein. Bei einem DWPD von 3 oder höher würden wir ein Caching Device mit mind. folgenden TWB bzw. PBW Werten benötigen.

• 800 GB / 1024 * 3 DWPD * 5 Jahre * 365 Tage = 4.277 TBW oder ca. 4,3 PBW
• 1,6 TB * 3 DWPD * 5 Jahre * 365 Tage =  8.760  TBW oder ca. 8,7 PBW 

bei dem 1,6 TB großen Caching Devices sind wir bei 3 DWPD auch über den 4 TB pro Tag auf die 5 Jahre gesehen (entspricht 7,3 PBW ). ​

​Microsoft sagt, dass ihr wählen könnt, nach welchem Wert ihr die Caching Devices auswählt. ​Carsten und wir sind da viel konservativer und möchten mindestens einen DWPD von 3 oder höher für Caching Devices haben.

Die Performance des Storage Spaces Direct Clusters wird unter anderem durch die ausgewählten Cache Laufwerke beeinflusst, daher sollten hier nur NVMe und SSD die write optimiert oder mixed used optimiert sind, zum Einsatz kommen. 

Im Teil 4 geht es um „​​Netzw​​​​​erkdesign bei Storage Spaces Direct​“

gutes Gelingen und bis zum nächsten Mal 

Petra

• Teil 1 – Was ist Storage Spaces Direct?
• Teil 2 – Grundlegende Anforderungen für Storage Spaces Direct
• Teil 3 – SSD und NVMe, DWPD, TBW und PBW berechnen und verstehen
• ​Teil 4 – Netzw​​​​​erkdesign bei Storage Spaces Direct​​

In diesem Teil möchte ich ein besonderes Augenmerk auf die Hardwareanforderungen für Storage Spaces Direct legen.

Es ist für den produktiven Betrieb unerlässlich, dass alle Systeme, Komponenten, Geräte und Treiber für Storage Spaces Direct durch Microsoft für den Windows Server 2016 zertifiziert sind.

Unter folgendem Link findet Ihr sogenannte WDDS (Windows Server Software-Defined) Systeme  von verschiedenen Herstellern für Storage Spaces Direct. Die dort aufgeführten Hersteller haben ausgewählte Konfigurationen für Storage Spaces Direct bei Microsoft zertifiziert. Vorteil dieser zertifizierten Systeme ist, diese Server sind getestet und zertifiziert, die Hersteller supporten diese Systeme bei Problemen. Nachteil, es stehen nur bestimmte Konfigurationen zur Verfügung, die nur sehr eingeschränkt, wenn überhaupt angepasst werden können. 

Passt die WDDS Hardware für eure Anforderungen nicht, müsst Ihr die Serversysteme selbst zusammenstellen, dabei ist einiges zu beachten. Oberstes Gebot, alle ausgewählten Komponenten müssen für Windows Server 2016 im Server Catalog und am besten für Software-Defined Data Center (SDDC) Premium oder Standard zertifiziert sein. Die Hersteller müssen die ausgewählten HBAs, Festplatten, NICs usw. in ihren Systemen unterstützen. 

hier zwei Beispiele aus dem Windows Server Catalog mit entsprechender Zertifizierung: 

Im Folgenden möchte ich die einzelnen Komponenten näher betrachten.

Server:

Es können Standard Server mit bis zu max. 100 TB  Devices in einem Server verwendet werden. Storage Spaces Direct kann mit 2 bis max. 16 Servern betrieben werden.

2-Knoten Storage Spaces Direct Failover Cluster:

• Nur 2-Wege Spiegel
• 1 Knoten kann ausfallen

3-Knoten Storage Spaces Direct Failover Cluster:

• 2- Wege und 3-Wege Spiegel (unsere Empfehlung ist immer ein 3 Wege Spiegel einzurichten)
• 1 Knoten und mehrere Festplatte in einem weiteren Knoten können ausfallen
• es dürfen gleichzeitig nicht mehr als die Hälfte aller Festplatten (ohne OS Disks) ausfallen. (Diskmajority)

4-Knoten – 16-Knoten Storage Spaces Direct Failover Cluster:

• 2-Wege und 3-Wege Spiegel (unsere Empfehlung ist immer ein 3 Wege Spiegel einzurichten)
• Single und Double Parity (auch hier ist unsere Empfehlung mit der Double Parity zu arbeiten)
• Hybrid Disk (Mirror und Parity)
• bis zu 2 Knoten können ausfallen oder 2 unterschiedliche Festplatten in unterschiedlichen Servern.

CPU:

• Mindestanforderung ist eine Intel Nehalem CPU oder ein höherer kompatibler Prozessor. Eine AMD EPYC CPU oder ein höherer kompatibler Prozessor
• Bei einer Storage Spaces Direct hyper-converged Lösung sollte darauf geachtet werden, dass die CPU den Anforderungen gemäß größer gewählt wird, da hier der Server nicht nur für die Virtualisierung sondern auch für das Storage genügend Performance benötigt.

Arbeitsspeicherbedarf:

• Pro 1 TB Caching Device müssen 4 GB RAM pro Server zur Verfügung stehen
• Beispielrechnung:2x 3,2 TB Caching Devices => 2 x 3,2 x 4 GB = 25,6 GB RAM
• Zusätzlich muss der Arbeitsspeicherbedarf für die Server, für die VMs oder SQL Workloads berechnet werden. Beachten Sie bitte auch, dass die Server noch genügend Arbeitsspeicher Reserve haben, um beim Ausfall von Failover Clusterknoten die Workloads dieser Server aufnehmen zu können.

Storage Device Anbindung:

Für Storage Spaces Direct benötigen wir zwingend einen Hostbus Adapter (HBA)

• Einfacher Pass-Through SAS HBA für SAS und SATA Devices
• SCSI Enclousure Services (SES) für SAS und SATA Devices
• Jedes Direct-Attached Storage Enclosure muss eine Unique ID präsentieren.

Nicht unterstützt:

• RAID Controller oder SAN (Fibre Channel, iSCSI, FCoE) Laufwerke
• Multipath IO (MPIO) oder physische über mehrere Pfade angebundene Laufwerke

Laufwerke:

Voraussetzungen:

• Jedes Laufwerk muss lokal in einem Server angeschlossen sein
• Als Laufwerkstypen werden SAS, SATA und NVMe unterstützt
• In jedem Server sollten die selben Laufwerke (Typ, Größe, Anzahl, Modell, Firmware) verbaut sein. Ausführliche Infos hierzu findet ihr unter ​Drive symmetry considerations for Storage Spaces 
• Bei den SSDs müssenEnterprise SSDs verwendet werden, die „Power-loss Protection“ unterstützen. Außerdem sollte bei der Auswahl der SSDs genau darauf geachtet werden für welches Einsatzszenario diese benötigt werden. Schreibintensiv, Leseintensiv oder eine Mischung aus Beiden
• Wir werden immer  wieder gefragt ob für Storage Spaces Direct nicht auch Consumer SSDs verwendet werden können – ein ganz klares NEIN!!! Es gibt hierzu von Dan Lovinger einen sehr guten Blogbeitrag dazu mit dem Titel:  „Don’t do it: consumer-grade solid-state drives (SSD) in Storage Spaces Direct“ 
• Bei den Cache Laufwerken ist folgendes zu beachten:die SSDs oder NVMe’s sollten einen DWPD (Drive Write per Day) Wert von mindesten 3 haben oder mit  4TB pro Tag beschrieben (TBW) werden können, dieser Wert muss auf die Lebensdauer (meist 5 Jahre) der SSD oder der NVMe berechnet sein. Wie wir anhand der Hersteller Angaben berechnen können, ob die gewünschte SSD oder NVMe den Anforderungen entspricht, darüber mehr in Teil 3.
• Wer nicht solange warten möchte, kann hier schon mal Infos dazu finden. ​
• Das Betriebssystem sollte auf einem Laufwerk mit Raid1 installiert sein. Vorzugsweise auch auf SSDs. Microsoft gibt 200GB Größe als Empfehlung an.

Unterstütze Laufwerke:

HDD für Kapazität

• 2,5“ und 3,5“ Formfaktor
• Langsam (80 – 200 IOPS) bis 200MB/s Datentransfer
• Günstig

SSD für Performance oder als Cache

• 2,5“ und 3,5“ Formfaktor
• Schnell (Read and Write > 10.000 IOPS) bis 750MB/s Datentransfer
• Teuer

NVMe als Cache oder für Performance

• 2,5“ und PCIe Slot Formfaktor
• Schnell (Reads > 100.000 IOPS) bis 5.000MB/s Datentransfer
• Teuer

Minimunanzahl Laufwerke pro Knoten (ohne die Betriebssystem Festplatten):

• 2 Cache Laufwerke und 
• 4 Kapazität Laufwerke
• hier einige Beispiele für die Mindestanforderung der Laufwerke:

Laufwerkstpyen:

• nur NVMe (gleiches Modell)
• nur SSDs (gleiches Modell)
• NVMe + SSD
• SSD + HDD
• NVMe + SSD + HDD

Minimal Anzahl pro Knoten:

• 4 NVMe
• 4 SSD
• 2 NVMe + 4 SSD
• 2 SSD + 4 HDD
• 2 NVMe + 4 Andere

Maximums:

• 100 TB (brutto) Festplattenkapazität pro S2D Knoten
• 1 PB (Petabyte) Brutto Kapazität pro Storage Pool

Erweiterung durch JBODs:

• wird grundsätzlich von Microsoft unterstützt.
• Unsere Empfehlung ist: keine JBODS zu verwenden, da diese nur über einen Single Pfad angebunden werden können. Microsoft unterstützt bei Storage Spaces Direct keinMPIO!
• Ein JBOD pro S2D Knoten – kein shared JBOD.

Netzwerk:

• Minimum 10 Gbit für die interne Clusterkommunikation (Ost-West Traffic). Für Performance und Ausfallsicherheit empfiehlt Microsoft hierfür zwei NICs a 10 Gbit zu verwenden.
• Die Netzwerkkarten sollten RDMA (remote direct memory access) mit dem Protokoll RoCE oder iWARP unterstützen.
• Bei einem 2 Knoten Storage Spaces Direct Failover Cluster ist es von Microsoft supported die SMB NICs direkt miteinander zu verbinden (ohne Switche). Bei den ​WDDS (Windows Server Software-Defined) Systemen muss jedoch darauf geachtet werden, dass auch der Hardware Hersteller dies unterstützt.
• Für die RoCE Konfiguration müssen VLANs angelegt werden, da die Infos zu RoCE im VLAN Header übertragen werden.
• bei den eingesetzten Switche ist eine Unterstützung von PFC (Priority Flow Control) erforderlich , ETS (Enhanced Transmission Selection) wünschenswert .

Im Teil 3 geht es um „​​SSD und NVMe, DWPD, TBW und PBW berechnen und verstehen“

gutes Gelingen und bis zum nächsten Mal 

Petra

wir haben beschlossen eine Blogpostserie über Storage Spaces Direct (S2D) zu schreiben. Ziel der Serie soll es sein euch alle Infos über Storage Spaces Direct in kompakter Form aufzubereiten. Teil 1 beginnt mit einer kurzen Erläuterung was ist Storage Spaces Direct.

Bisher erschienene Beträge zu dieser Serie:

• Teil 1 – Was ist Storage Spaces Direct?
• Teil 2 – Grundlegende Anforderungen für Storage Spaces Direct
• Teil 3 – SSD und NVMe, DWPD, TBW und PBW berechnen und verstehen
• ​Teil 4 – Netzw​​​​​erkdesign bei Storage Spaces Direct​​

Storage Spaces wurde erstmals von Microsoft mit Windows Server 2012 eingeführt und zwar mit der Scale Out File (SOFS) Server Rolle. Die Anbindung des Storage kann über SAS, iSCSI oder FibreChanel erfolgen. Die Scale Out File Serverrolle stellt über Dateifreigaben, die speziell für Hyper-V und SQL Server Daten entwickelt wurden, den Speicherplatz zur Verfügung. Die Kommunikation zum Hyper-V Failover Cluster bzw. zum SQL Server erfolgt über Ethernet mit dem SBM 3 Multichannel Protokoll. Bei Storage Spaces Direct wird das Storage mit lokalen Festplatten zur Verfügung gestellt. Dies wird durch den neu entwickelten Software Storage Bus ermöglicht.

Was ist Storage Spaces Direct?

• Storage Spacaes Direct ist eine Software-defined, Shared-nothing Storage Lösung auf Basis von Windows Server 2016.
• sie ist Hochverfügbar durch die Nutzung des Failover Cluster Features im Windows Server 2016.
• Nutzt Industrie Standard Server Hardware
  • Unterstütze Festplatten Typen: SAS, SATA, NVMe
• kann gut skaliert werden, indem einfach ein weiterer Server hinzugefügt wird (Scale-Out).
• es wurde für Hyper-V und SQL -Server Daten entwickelt

Welche Einsatzmöglichkeiten gibt es? 

Für Storage Spaces Direct gibt es zwei Deployment Szenarien entweder hyper-converged oder converged. wir müssen uns bei der Planung für eines der beiden unterstützen Deployment Szenario entscheiden, beides zusammen kann nicht auf der selben Hardware betrieben werden. 

Hyper-converged:

beim hyper-converged Ansatz wird das Storage Spaces Direct Failover Cluster zusammen mit der Hyper-V Rolle betrieben. Das heißt:

• Storage und Hypervisor nutzen die gleichen Ressourcen
• VMs werden auf dem lokalen Storage System abgespeichert. „C:\ClusterStorage\…“
• Einfaches Management und Deployment
• Die notwendige Windows Server 2016 DataCenter Edition Lizenz kann sowohl für Storage wie auch für die VMs genutzt werden

Converged:

beim converged Ansatz werden das Storage Spaces Direct Failover Cluster in Verbindung mit der Scale Out File Server Rolle betrieben. 

• Für die Virtualisierung und für das Storage muss jeweils ein separater Failover Cluster aufgebaut werden. Die VM Daten werden dann auf dem Storage Spaces Direct Failover Cluster in sogenannten Applikations Freigaben abgelegt.
• Storage und Hypervisor Ressourcen können je nach Anforderung unabhängig voneinander erweitert werden.
• Die notwendigen Windows Server 2016 Datacenter Lizenzen werden hier sowohl für den Storage Spaces Direct Failover Cluster als auch für den Hyper-V Failover Cluster benötigt

Wie funktioniert Storage Spaces Direct?

Storage Spaces Direct ist eine Weiterentwicklung der Storage Spaces, die bereits mit Windows Server 2012 als Feature zur Verfügung gestellt wurden. Storage Spaces Direct nutzt seit langem bekannte Features wie Failover Clustering, Cluster Shared Volume (CSV), SMB 3 und SMB Direct, Storage Spaces und beinhaltet viele neue Technologien wie z.B. den Software Storage Bus.

Der Software Storage Bus erstellt innerhalb des Failover Clusters eine software-defined Storage Fabric, die es dem Cluster ermöglicht, die lokalen Festplatten jedes einzelnen Clusterknotens zu sehen.

Dies erfordert hohe Sicherheits- und Performanceansprüche an die Netzwerkkommunikation zwischen den einzelnen Failover Clusterknoten. Storage Spaces Direct nutzt das SMB3 Protokoll – beinhaltet SMB Direct und SMB Multichannel –  für die Kommunikation zwischen den Storage Spaces Direct Clusterknoten (Ost-West Traffic)  und bei dem converged Design (Nord-Süd Traffic) auch zu den Hyper-V Failover Cluster. 

Die geeigneten lokalen Festplatten der einzelnen Failover Clusterknoten (außer die OS Festplatten) werden bei der Installation des Storage Spaces Direct Clusters in einem Storage Pool zusammen gefasst. Es werden alle geeigneten Festplatten automatisch erkannt und hinzugefügt. Es wird empfohlen nur einen Storage Pool pro Storage Spaces Direct Cluster anzulegen.

Durch das Anlegen des Storage Pools steht dem Failover Cluster nun Storage Speicher (Storage Spaces) zur Verfügung, über den wir virtual Disks für CSVs (Cluster Shared Volume) anlegen können. Für die Ausfallsicherheit der Daten stehen unterschiedliche Fehlertoleranz Modis zur Verfügung (z.B. zwei- und drei Wege Spiegel) (mehr dazu später).

Die virtual Disks können mit CSV-ReFS (empfohlen) oder CSV-NTFS formatiert werden. Resilient File System (ReFS) zeigt seine Stärken besonders in einer Storage Spaces Direct Umgebung. Es ermöglicht schnellere .vhdx-Daiteioperationen wie Erstellung, Erweiterung und Checkpoint Zusammenführung. Es integriert Prüfsummen zum erkennen und korrigieren von Bit-Fehlern. Des weiteren wurden Echtzeit-Tiers eingeführt, die „heiße“ und „kalte“ Daten in Echtzeit umorganisieren können.

Hier grafisch der schematische Aufbau von Storage Spaces Direct. (Quelle)

Im Teil 2 geht es um „Grundlegene Anforderungen für Storage Spaces Direct“

gutes Gelingen und bis zum nächsten Mal 

Petra

MVP-Day Meet Experts findet in drei Städten statt:

• ​07.05.2018 von 13:00 – 17:00 Uhr bei der Bechtle in Stuttgart, Meitnerstraße 10
• 08.05.2018 von 9:00 – 13:00 Uhr bei der Bechtle in Saarbrücken, Neumühler Weg 32 a
• 22.05.2018  von 13:00 – 16:30 Uhr bei der Bechtle in Weimar, Lindenallee 6

Da heißt es schnell sein, wer Interesse an diesen interessanten und informativen Workshop Tag hat kann sich hier anmelden

das sind die Workshop-Inhalte:

• Windows Server 2016 Datacenter als Plattform für hyperkonvergente Infrastrukturen.
• Windows Server Software-defined – die PRIMEFLEX Lösungen von Fujitsu.
• Storage Spaces Direct – Planung, Konfiguration, Ausfallszenarien, Monitoring und Lizenzierung.
• Aus der Praxis für die Praxis.

hier haben Sie die Möglichkeit Carsten zum Thema Storage Spaces Direct zu hören und ihn im Anschluss daran auch in einem persönlichen Gespräch ihre Fragen zu stellen. 

Sobald alle Voraussetzungen für den Betrieb erfüllt sind, können Sie unter anderem solch eine Übersicht über Ihr S2D Cluster haben:

Voraussetzung für den erfolgreichen Betrieb ist die Installation des aktuellen Windows Admin Center-Release und die Installation des aktuellen Cumulative Update für Windows Server 2016 (KB4093120).

Nach dem Update muss (einmalig im S2D Cluster) eine neue Ressource registriert werden:

Aber jetzt erstmal der Reihe nach!

​Die dritte CDC-Germany ist die größte und beste bisher :-) Hier einige Fakten:

​- 30 MVPs und 3-ex MVPs als Sprecher

– 2 Tage mit je 6 Tracks

– 48 Community Sessions

– 2 Keynotes

– 12 technische Sponsor Sessions

​- Abendevent im Konferenzcenter

– Preise im Gesamtwert von über €9.000,-

​​​​​Und das ganze wird jetzt durch einen Community Pre-Day erweitert! Das heißt am 14. Mai findet im Hanauer Konferenz Zentrum eine Hyper-V Community und eine Hybrid Cloud Community statt.

Hier die Highlights des pre-Days:

– 11 Sessions

– 6 MVPs und 1-ex MVP als Sprecher

– paraleller Hyper-V und Hybrid Cloud Track

– Mittagessen gesponsort von der interxion

Da die Plätze begrenzt sind, können sich vorerst nur die Teilnehmer der CDC-Germany anmelden. 

Eines meiner Lieblingsprojekte in der letzten Zeit ist somit allgemein verfügbar und kann produktiv genutzt werden. Vollständig ist es allerdings noch nicht, in den kommenden Monaten wird es immer wieder neue Releases geben, die Funktionen hinzufügen und durch Feedback eingebrachte Ideen umsetzen. Im Zuge des Release hat Microsoft auch den Namen angepasst und durch „Windows Admin Center“ ersetzt.

Wer direkt mit dem Download und der Installation loslegen möchte, kann dies auf der folgenden Seite tun: ​docs.microsoft.com: Windows Admin Center (formerly Project Honolulu)​​​

Was ist das Windows Admin Center (WAC)

Das Windows Admin Center ist eine Browser-basierte Administrationsmöglichkeit einer Windows Infrastruktur. Viele der bekannten Konsolen wie z.B. das Eventlog, die Zertifikate, die Windows Firewall, der Task Manager, Windows Update und noch viele weitere werden hier in einer zentralen Oberfläche gebündelt. Das Ergebnis ist eine zentrale Anlaufstelle für viele Tätigkeiten, die im normalen Betrieb oder bei der Installation von einem System anfallen.

Diese Art der Administration beschleunigt zum einen gewisse Tätigkeiten, zum anderen steht so auch eine wirklich gut nutzbare Management-Oberfläche für einen Core Server zur Verfügung, falls diese Variante eingesetzt wird. Gedacht ist der Einsatz von WAC in kleineren Umgebungen, es soll kein Ersatz oder Austausch von z.B. System Center sein.

Was kann verwaltet werden?

Zum aktuellen Zeitpunkt können Sie Windows Server 2019 in der Preview-Version, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 und Windows 10 verwalten. Die Anbindung an die jeweiligen Server erfolgt per Remote PowerShell oder per WMI über WinRM.

Binden Sie WAC nach außen an das Internet an, können Sie auch eine Administration von überall aus ermöglichen. Ob Sie dies machen möchten steht natürlich auf einem anderen Blatt.

Mögliche Betriebsarten

WAC kann auf zwei unterschiedliche Arten eingesetzt werden:

1. Im Desktop Modus
2. Im Gateway Modus

Der Desktop Modus

Bei dieser Art von Betrieb wird das WAC direkt auf dem System installiert, auf dem es genutzt wird. Dies kann z.B. ein Windows 10 PC oder Notebook sein, alternativ ein standalone Server, der verwaltet werden soll. Sobald die Installation fertig ist, kann das lokale Gerät im Browser administriert werden.

Der Gateway Modus

Bei dieser Variante wird was WAC auf einem Server installiert und dient danach als Haupteinstiegspunkt. Auch hier wird von einem Endgerät (z.B. der Workstation des Administrators) eine Administration per Browser ermöglicht, allerdings muss auf dem eigentlichen Server (oder den vielen Servern) keine lokale Installation des WAC vorhanden sein. Die Administration erfolgt hier von dem Gateway-Server aus per Remote PowerShell oder WMI über WinRM.

Windows Admin Center im HA-Betrieb

Da der Betrieb von einer VM, selbst wenn sie in einem Hyper-V Failover Cluster läuft, immer eine mögliche Downtime mit sich bringen kann (Updates, Neustarts, …), kann WAC auch in einem Failover Cluster installiert werden. Hierbei ist ein Aktiv-Passiv Betrieb möglich, d.h. bei dem Ausfall oder einer geplanten Downtime von einem der Knoten übernimmt der zweite Knoten und die Nutzung kann ausfallfrei fortgesetzt werden. Es ist nicht nur der Betrieb von zwei Knoten möglich, sondern auch mehr.

Soll WAC im HA-Betrieb laufen, muss ein Failover Cluster vorhanden sein mit zwei oder mehr Knoten, weiterhin wird ein Cluster Shared Volume (CSV) mit mindestens 10 GB Speicherplatz benötigt, vermutlich eher mehr (das wird sich zeigen, dafür ist das Produkt zu jung. Außerdem: was sind schon 10 GB). Zur Installation wird ein Satz an PowerShell-Skripten benötigt, die es bei Microsoft zum Download gibt: Windows Admin Center HA Setup Scripts zip fileOptimalerweise besitzen Sie noch ein signiertes .pfx-Zertifikat und das dazugehörige Kennwort, dann wird dieses direkt bei der Installation mit eingepflegt und für den Zugriff durch den Administrator verwendet.

Eine genaue Beschreibung der Installation und weitere Informationen gibt es ebenfalls auf der Microsoft-Seite: ​Install Windows Admin Center on a failover cluster​​​

Generell bietet das Windows Admin Center noch deutlich mehr Möglichkeiten und Optionen, die wir Ihnen in der kommenden Zeit immer mal wieder näher bringen werden.

Eine persönliche Anmerkung

Schauen Sie sich die neue Möglichkeit der Administration einmal an. Laden Sie WAC herunter. Die Downloads, die Installationen und die Nutzung wird von Microsoft gecountet und beachtet. Je mehr Leute dieses Produkt nutzen, desto mehr Entwicklungszeit wird dem Team gegeben und desto mehr Ressourcen stehen zur Verfügung. Mehr Ressourcen heißt schnellere Entwicklung und (hoffentlich) eine saubere und stabile Qualität des Produkts. WAC ist und bleibt umsonst, weiterhin ist die Installation super einfach und klein, eine kleine VM reicht aus, um alle Möglichkeiten zu haben und zu testen. Alle bestehenden Tools bleiben erhalten und können weiterhin genutzt werden, Sie verlieren nichts! bei einem Test oder einem Parallel-Betrieb. Microsoft schenkt hier einem Nicht-Cloud-Produkt sehr viel Beachtung und in Sessions mit den verantwortlichen Produkt Managern in Redmond auf der MVP Summit hat man gemerkt, dass sie unglaublich begeistert bei der Sache sind und sehr viel Engagement hineinstecken.

Laut dem Entwicklungsplan wird eine Unterstützung des WAC mit S2D unter Windows Server 2016 gebackportet (siehe Screenshot weiter oben im Artikel), damit steht auch einer Administration und einem Management per WAC nichts mehr im Weg. Wer sich die Administration von S2D in der Preview mal angeschaut hat weiß, wie cool die neue Oberfläche ist und wie viel Verbesserungen hier eingeflossen sind gegenüber dem Failover Cluster Manager.

Am Donnerstag, 7. Juni 2018, findet im Congress Park in Hanau das deutsche VeeamON Forum statt. Bei dieser Veranstaltung, die sich primär an Veeam-Kunden und Anwender der Produkte richtet, wird es vier verschiedene Tracks geben. Drei dieser Tracks haben einen technischen Background, hier werden unter anderem die folgenden Themen behandelt:

• Was ist neu in den Veeam Produkten?
• Zentrales Backup von nicht-virtualisierten Systemen
• Backup von Office365
• Veeam One
• Failover Cluster Backups
• Online-Speicher als Backup-Ziel
• …

Im Business-Track wird es einen Workshop zum Thema GDPR und DSGVO geben.

Die Anzahl der Plätze ist begrenzt, bei Interesse sollten Sie sich zeitnah anmelden. Die Anmeldung und weitere Informationen finden Sie auf der Webseite von Veeam: ​Veeam.com: VeeamON Forum Deutschland​​​

Nach der Download und der Installation steht Honolulu zur Verfügung, gegenüber der Version 1802 wurden die folgenden Änderungen und Verbesserungen eingebracht:

• Azure Active Directory wurde hinzugefügt (Wenn ein eigenes Zertifikat genutzt wird, schlägt die Anmeldung fehl. Nutzt man einen richtigen und funktionierenden Browser, funktioniert alles ;) )
• Es wurde ein erweitertes Logging eingeführt, was generell mehr Informationen bereitstellt.
• Die UI wurde anpassbar gestaltet, man kann nun einen Teil der Elemente nach eigenem Belieben vergrößern oder anpassen. Gerade bei Systemen mit großen Monitoren ist dies super, da die grundsätzlichen Einstellungen zum Teil recht klein sind.
• Zertifikate können nun verwaltet werden
• Dateien können herauf- oder heruntergeladen werden, dazu werden die Dateien gezippt
• Dienste werden angezeigt und können angepasst werden
• Das Windows Update erlaubt nun (endlich!) wieder, eine Abfrage der Updates zu machen (gegenüber einem WSUS oder auch bei Bedarf online) und es können die Updates ausgewählt werden, die heruntergeladen und installiert werden sollen…. Wuhu \o/
• Wird Windows in der Version 1803 genutzt, können die folgenden Dinge genutzt und konfiguriert werden:
  • Storage Jobs sind nun in der Konsole sichtbar => Das ist eine sehr gute Sache, durch diese Ansicht werden aktive Storage Jobs, z.B. Reparaturen, sichtbar und können bei einem Update berücksichtigt werden. Auch Dinge wie ein Storage-Rebalancing werden hier angezeigt.
• Deduplizierung kann nun in der Honolulu-Oberfläche aktiviert werden pro Volume

Wie immer gibt es in dieser Version (man bedenke, dass es ein Preview-Version ist) auch bekannte Probleme, diese werden hier aufgeführt: Announcing Project Honolulu Technical Preview 1803 and RSAT Insider Preview for Windows 10

Persönlich habe ich, wie bereits geschrieben, große Hoffnungen in Honolulu, was ein zentrales Management angeht. Mein Aufruf daher an alle Blog-Besucher und -Leser: Macht mit beim testen. Reicht Bugs ein. Reicht Vorschläge ein. Gebt Feedback. Ich habe einen Teil der verantwortlichen Menschen in Redmond auf der MVP Summit getroffen, sie arbeiten aktiv und mit einer recht großen Anzahl an Mitarbeitern an einer On-Premise-Lösung. Zum Management von On-Premise-Lösungen. Ladet Honolulu runter, installiert es so oft wie möglich, gebt Feedback, schreibt Blogposts oder Twitter-Posts oder Facebook-Meldungen oder was auch immer, alles zählt. Und wenn ihr keine Chance dazu habt, besucht uns auf der CDC-Germany in Hanau im Mai und schaut euch den Vortrag von Eric Berg an, er zeigt Honolulu in einer seiner Sessions.

Wir wissen und sehen in vielen Projekten, dass „die Cloud“ nicht alles ist und keineswegs dem Verbreitungsgrad entspricht, was euch die großen Anbieter weiß machen wollen. Zeigt Microsoft alleine schon durch Download- und Installationszahlen, wie relevant lokale Systeme und Installationen sind :)

Am 22. März ist die Hybrid Cloud Community zu Gast bei Dell in Frankfurt (Anmeldung und Adressinformationen findet Ihr auf der https://hybridcloudcommunity.de Seite).

Wir hoffen das viele von euch Zeit haben und zum Event kommen!​

Networking is a very impotent part in every successful Hyper-V Implementation. No learn in this Webinar about:

• Hyper-V Cluster and Networking
• S2D Networking
• SMB3 and SMB Direct
• VMQ and RSS
• Q&A

To sign-up just click on the picture or here! Don’t worry that you maybee have no time you will get a link to the recording afterwards.

Am 11. Dezember beschäftigen wir uns im Webinar „Managing Windows Server mit Projekt Honolulu“ mit der neuen, modernen Management Plattform für Windows Server.

Diesmal wird’s viele Demos geben.

Auszug aus dem Inhalte:​

• Grundlagen Projekt Honolulu
• Management von Hyper-converged S2D
• Management von Window Server 2016
• Management von Window Server 2012 R2
• Demo
• eure Fragen

Zum Anmelden klickt Ihr auf das Bild oder hier! Wenn Ihr keine Zeit habt meldet euch trotzdem an dann bekommt Ihr nach dem Webinar eine Mail mit dem Link zur Aufzeichnung!

Networking is a very impotent part in every successful Hyper-V Implementation. No learn in this Webinar about:

• Hyper-V Cluster and Networking
• S2D Networking
• SMB3 and SMB Direct
• VMQ and RSS
• Q&A

To sign-up just click on the picture or here! Don’t worry that you maybee have no time you will get a link to the recording afterwards.

Am 5​. Januar ​beschäftigen wir uns in unserer Storage Spaces Direct ​Deep Dive Serie Webinar mit dem ​Performance Benchmarking ​von S2D Clustern​. Meiner Meinung nach ist dieser Punkt extrem wichtig um die Leistung einer S2D Lösung richtig einschätzen zu können.

Auszug aus dem Inhalte:​

• Grundlagen Benchmarking​​
• Vorststellung und Demo IOMeter
• Vorststellung und VMFleet
• eure Fragen

Zum Anmelden klickt Ihr auf das Bild oder hier! Wenn Ihr keine Zeit habt meldet euch trotzdem an dann bekommt Ihr nach dem Webinar eine Mail mit dem Link zur Aufzeichnung!

​​Für das SET Team habe ich folgenden Uplink Port im SCVMM 2016 konfiguriert.

​…. und im Anschluß daran ​den logischen Switch mit den folgenden Einstellungen.

​In nächsten Schritt, habe ich das Uplink Portprofil für das SET Team ausgewählt und die in unserer Umgebung erforderlichen vNICs erstellt.

​unser Hyper-V Failover Cluster ist bereits im SCVMM 2016 importiert und so können wir direkt über die Eigenschaften des Hyper-V Hosts unter „Virtual Switches“ das SET Team mit den vNICs anlegen.

​das hat auch alles ohne Fehlermeldung geklappt, doch sobald der SCVMM 2016 die Konfiguration der Hyper-V Hosts neu einliest, fehlen pötzlich die Netzwerkkarten im SET Team.

​beim Blick auf den Hyper-V Host ist alles okay, dort sind die NICs dem SET Team zugewiesen. Warum also hat der SCVMM 2016 in seiner Konfiguration keine Netzwerkkarten mehr?

​Es hat mich einige Zeit gekostet bis ich es gesehen habe, die Netzwerkkarten die der Powershell Befehl

„Get-VMSwitchTeam“

anzeigt, haben nicht den gleichen Namen, wie ​in der Netzwerk Umgebung der „Device Name“ der Netzwerkkarten. Das genau ist das Probelm, denn der SCVMM 2016 arbeitet mit dem „Device Name“ und verliert so die Netzwerkkarten nach der Aktualisierung, da er diese über den „Device Name“ nicht mehr findet​. Dieses Problem ist mir bei den HP Server passiert und es gibt hierzu auch von HP einen Hinweis unter folgenden Link. Wir haben in unserem Projekt die Netzwerkkarten in Mellanox Karten getauscht, bei denen trat das Problem nicht auf.

Vielleicht hilft ja Betroffenen mit Qlogic Netzerkkarten der folgende ​Link weiter. Ich habe die Empfehlungen dort allerdings nicht getestet und kann nur hoffen, dass die Treiber das Probelm beheben.

Bis bald wieder

Petra

More…

https://support.hpe.com/hpsc/doc/public/display?sp4ts.oid=7500985&docLocale=en_US&docId=emr_na-c05306829

Durchgeführt wurde der Befehl mit dem folgenden Parameter:

sas3flash.exe -c 0 -f SAS9300_8e_IT.bin

Das Problem lässt sich beheben, wenn hinter dem Vorgang ein weiterer Parameter angehangen wird, der einen Reset der Karte verhindert. Dies verhindert den Bluescreen, der Server muss dann nach dem Flash-Vorgang per Hand neu gestartet werden.

sas3flash.exe -c 0 -f SAS9300_8e_IT.bin -noreset

Gefunden habe ich den Parameter in dem folgenden Artikel:

Servethehome.com: How to flash a LSI SAS 3008 HBA (e.g. IBM M1215) to IT mode

Thanks for this :)

Networking is a very impotent part in every successful Hyper-V Implementation. No learn in this Webinar about:

• Hyper-V Cluster and Networking
• S2D Networking
• SMB3 and SMB Direct
• VMQ and RSS
• Q&A

To sign-up just click on the picture or here! Don’t worry that you maybee have no time you will get a link to the recording afterwards.

Am 11. Dezember beschäftigen wir uns im Webinar „Managing Windows Server mit Projekt Honolulu“ mit der neuen, modernen Management Plattform für Windows Server.

Diesmal wird’s viele Demos geben.

Auszug aus dem Inhalte:​

• Grundlagen Projekt Honolulu
• Management von Hyper-converged S2D
• Management von Window Server 2016
• Management von Window Server 2012 R2
• Demo
• eure Fragen

Zum Anmelden klickt Ihr auf das Bild oder hier! Wenn Ihr keine Zeit habt meldet euch trotzdem an dann bekommt Ihr nach dem Webinar eine Mail mit dem Link zur Aufzeichnung!

Die Teilnehmer konfigurieren ihren persönlichen Hyper-V Host so, dass er für eine Konfiguration als Hyper-V Cluster Knoten genutzt werden kann. Vor der Erstellung wird eine Validierung der beiden Knoten gemacht um sicher zu gehen, dass die Konfiguration keine Fehler enthält und alles wie gewünscht funktioniert. Alle verfügbaren und von Microsoft empfohlenen Tests wurden durchgeführt und hatten in der Vergangenheit (zumindest nicht offensichtlich) keinen Einfluss auf die VMs, die auf den lokalen Laufwerken liegen. Das lokale Laufwerk, auf dem die VMs bis zu diesem Zeitpunkt betrieben werden, wird über die Storage Spaces Technik bereitgestellt.

Eine Änderung an dem Verhalten ist aufgefallen im Oktober-Kurs. Hier wurden bei dem Test der Cluster-Konfiguration auf allen Systemen die Laufwerke, die lokal per Storage Spaces bereitgestellt wurden (zwei SSDs in einem Pool und einem Simple-Volume), abgehängt. Dies führte dazu, dass alle VMs abgestürzt sind, da sie nicht mehr an ihre Daten kamen und somit nicht mehr lauffähig waren. Die Kurs-Systeme werden immer mit den aktuellsten Windows Updates ausgestattet, daher war der Patchstand beim Oktober-Kurs inkl. dem CU für Oktober (10-2017).

Abhilfe schafft hier die Deaktivierung der Storage-Tests bei einer Cluster-Validierung, in diesem Fall passiert nichts weiter und die Datenträger und VMs verbleiben alle online. Ob dieses Verhalten erst ab Oktober besteht oder es vorher niemanden aufgefallen ist weiß ich nicht genau, ich werde allerdings nun verstärkt darauf achten bzw. prüfen, ob das Verhalten weiterhin so ist. Vielleicht hilft diese Info dem einen oder anderen, der (bisher unerklärliche) Ausfälle bei einer Cluster Validierung hatte.

The goal of this post

In this Post I want to give you a step by step guide how you can install the Azure Stack Development Kit in a Hyper-V Nested virtual machine. The deployment is tested with the Version of Azure Stack Development Kit that was available in October 2017 (Release Build Version 20170928.3) and in November 2017 (Release Build Version 20171020.1).

​Don’t​ get me wrong! I think the best way to experience the Azure Stack Development Kit is by installing it on a decent hardware box but maybe you don’t have one handy or don’t have the budget for a new one. In ​this case this is a solution for you. 

Get​ the Azure Stack Development Kit

Download the Azure Stack Development Kit

You will find the download link for the Azure Stack Development Kit (at least the time of writing of this post) at: https://azure.microsoft.com/en-us/overview/azure-stack/development-kit/

After downloading and starting the AzureStackDownloader.exe ​and ​filling in the mask below the Download starts​.

https://azure.microsoft.com/en-us/overview/azure-stack/development-kit/

​When the download has finished you find approximately 11 GB of files in the specified Download Directory or 18 GB depending if you selected to also downloaded the Windows Server 2016 evaluation version (ISO file)

Double click on AzureStackDevelopmentKit.exe to extract the Azure Stack Development Kit from the highly compressed archive. Click through the Wizard and after the extraction process finished you get the „CloudBuilder.vhdx“ virtual disk to work with.

Modify CloudBuilder.vhdx for Nested Hyper-V

To deploy the Azure Stack Development Kit in a Nested Hyper-V VM we ​must make some changes to the Build system in it. To do that we right-click on the VHDX and choose „Mount“.

Find the Drive where it is mounted​ and navigate to the Directory <MountDrive>:/CloudDeployment/NuGetStore​.

​Here you find the file Microsoft.AzureStack.Solution.Deploy.CloudDeployment.1.0.598.8.nupkg which we have to modify. To do that copy it to a folder, rename the extension from „.nupkg“ to „.zip“ and then extract it.

Now we ​must change ​two files:

• ​X:/content/Roles/PhysicalMachines/Tests/BareMetal.Tests.ps1
• ​X:/content/Configuration/Roles/Infrastructure/BareMetal/OneNodeRole.xml

In the BareMetal.Test.ps1 we ​must disable the check if the Azure Stack Host is a Virtual Machine. The easiest way to do that is by changing ​the tree places in the script where the check is done.​ So replace the line:

• ​if (-not ​$isVirtualizedDeployment)

​with the line 

• ​​if ($isVirtualizedDeployment)

tree times!

The next step is only ​requiredif you are low on diskspace. Then we ​should modify the file „OneNodeRole.xml“ to lower the disk ​requirements of the ​deployment.​

​Open „OneNodeRole.xml“ and find the following entries

      <MinimumSizeOfDataDisksGB>135</MinimumSizeOfDataDisksGB>      <MinimumSizeOfSystemDiskGB>180</MinimumSizeOfSystemDiskGB>​and change them to

      <MinimumSizeOfDataDisksGB>120</MinimumSizeOfDataDisksGB>      <MinimumSizeOfSystemDiskGB>120</MinimumSizeOfSystemDiskGB>

​. By setting them to a smaler size ​you will ​be able to deploy to smaller disk​.

After editing the two files, copy them back into the „Microsoft.AzureStack.Solution.Deploy.CloudDeployment.​1.0.598.8.zip„​ archive.​ Rename the extension form „.zip“ back to „.nupkg“​ and copy the file back into the „CloudBuilder.vhdx„. In the last step you unmount ​the „CloudBuilder.vhdx“ by right clicking on the Drive letter where the VHDX is mounted and then select „Eject“.

if (-not $isVirtualizedDeployment)

​Prepare the Hyper-V Host

Creating a NAT Switch

The best way to connect your Azure Stack virtual machine with the outside world is to create a NAT Switch on the Hyper-V Host. You do that by executing the following PowerShell script in an PowerShell or PowerShell ISE with Administrative Rights:

$SwitchTest = Get-VMSwitch -Name „NATSwitch“ -ErrorAction SilentlyContinue if($SwitchTest -eq $null) {    New-VMSwitch -Name „NATSwitch“ -SwitchType Internal -Verbose        $NIC = Get-NetAdapter  | where Name -like „vEthernet*(NATSwitch)“        New-NetIPAddress -IPAddress 172.16.0.1 -PrefixLength 24 -InterfaceIndex $NIC.ifIndex    New-NetNat -Name „NatSwitch“ -InternalIPInterfaceAddressPrefix „172.16.0.0/24“ -Verbose}

​The Script will create an Internal Switch, give the Internal Adapter „vEthernet (NATSwitch)“ the IPv4 Address „172.16.0.1“ and change the Switch to an NAT Switch​.

​​Prepare the AzureStack VM

​Create the AzureStack VM

​Now it is time to create our VM. If ​you have ​modified the „OneNodeRole.xml“ as ​su​​​​​ggested you need a VM with 12 Cores, 96GB of RAM, one OS Disk with 120GB and four Data Disks with 120 GB each. To create such a VM you open „Hyper-V Manager“ on your Hyper-V Host and start the ​Virtual Machine Wizard ​by clicking on „New ->“ and then „Virtual Machine…“.

​Specify a Name for the VM (I choose in this ​example „AzureStackDevKit“) and check the „Store the virtual machine in a different location“ checkbox

​choose VM Generation 2

​specify at least ​96 GB of RAM (I use in the example 100 GB)

​connect the NIC to the „NATSwitch“

​choose „Attach a virtual hard disk later“

​and press „Finish“.

​Add CloudBuilder.vhdx Bootdisk

​Now open an Windows Explorer and navigate to the VM Directory (in my example C:/ClusterStorage/DaONS2D2/AzureStackDevKit) and create a „Virtual Hard Disks“ Directory. ​Copy the modified „CloudBuild.vhdx“ into the ​“Virtual Hard Disks“ Directory​.

​Open the „VM settings“ in „Hyper-V Manager“ and add the „CloudBuilder.vhdx“ Disk ​to the VM. To do so choose „SCSI Controller“, „Hard Disk“ and press the „Add“ button.

Choose „Browse…“ and navigate to the folder where you copied the „CloudBuilder.vhdx„. Select it and then click the „Apply“ button.

Modify Processor Count

​Now we modify the ​Processor count. To do ​so click in the still open VM Settings Windows on „Processor“ and enter 12 in the „Number of virtual processors:“ field. Then​ click the „​Apply“ Button.

Add four Data VHDX

In the next step we add four Data Disks to the VM. To do so click in the VM Settings on the „SCSI Controller“ and choose „Hard Disk“. Create a new Disk by clicking on the „New“ Button.

​In the „New Virtual Hard Disk Wizard“ click next to the „Choose Disk Type“ dialog and​ go with „Dynamically expanding“.

​In the „Specify Name and Location“ Dialog press „Browse…“ and navigate to the „Virtual Hard Disks“ directory of your VM. Then change the Name of the Disk to „Data1.vhdx“.

​In the „Configure Disk“ dialog specify the size of the new disk. The Disk must have ​at least ​​120 GB but I ​recommend ​200 GB.

​Now click „Finish“ and your first disk is created.

​To create all four ​necessary data disks you ​must ​repeat the disk creation steps tree more times ​for the Disk „Data2.vhdx“, „Data3.vhdx“ and „Data4.vhdx“. Finally your „VM Settings“ should look similar to the following screenshot:

​Disabling Time Syncronisation

We will configure our own Time Server in the Azure Stack VM so we should turn of time ​synchronization in the Virtual Machine Integration Services.

​Open the „VM Settings“, click on „Integration Services“ and uncheck „Time ​synchronization“.

Change Automatic Stop Action (optional)

If you don’t have a lot of free disk space on the host you may want to chance the „Automatic Stop Action“ for the Azure Stack VM from the default behavior „Save“ to „Shutdown“. If you do that Hyper-V will not reserve the size of the VMs memory in the „.BIN“ configuration file.

​Enable​ Nested Virtualization

To deploy Azure Stack in a virtual machine we ​must enable Nested Virtualization for that virtual machine. To do that execute the following PowerShell CmdLet on the Hyper-V Hosts:

Set-VMProcessor -VMName AzureStackDevKit -ExposeVirtualizationExtensions $true -Verbose

Set-VMProcessor -VMName AzureStackDevKit -ExposeVirtualizationExtensions $true -Verbose

​Enable Mac Address Spoofing

Because our Azure Stack VMs in the Nested VM ​must communicate with the outside world we enable MAC Address Spoofing. If you can’t do that ​there is a way to configure an ​additional NAT Switch for the ​Azure Stack BGPNAT VM. To do so I ​encourage you to look at ​Daniel Neumann’s Blog ​Running the Azure Stack Development Kit on Azure blog post.

​In this post I configure ​MAC Address Spoofing. To do so we open again the VM Settings of your Azure Stack VM. Click on the small ‚+‘-Symbol next to Network Adapter. Then click on „Advanced Features“ and ​in the ​right windows ​click in ​the checkbox next to „Enable MAC address spoofing“.​

​Close the VM Settings dialog by clicking on the „OK“ button.

​Change VM Boot Order

​Open the VM Settings ​click on „Firmware“ and move the „CloudBuilder.vhdx“ entry to the first position by clicking on „Move Up“. ​

​Then click the „OK“ button.

​Change Settings in the AzureStack VM

​Now we ​continue the configuration inside the VM. ​Open a connection to the VM by clicking on the AzureStackDevKit VM in „Hyper-V Manager“. Start the VM and go ​through the Setup process (choosing ​the Language, enter a Product key or skip this by pressing the „Do this later“ link, Accept the EULA, choosing a password and ​finally login-in).

Change the Network Settings

​​In the VM we ​must configure the network, so that it works with the NAT Switch. To do so ​open the „Network Settings“ by right click on the Network symbol in the taskbar and clicking on „Open Network and Sharing Center“.

​Click on the „Ethernet“ Connections, click on the „Properties“ button and navigate to the „Internet Protocol Version 4 (TCP/IPv4) Properties“ dialog (like you see in the screenshot below) and configure the IP settings to:​

IP address: 172.16.0.2Subnet mask : 255.255.0.0Default gateway: 172.16.0.1Prefered DNS server: 8.8.8.8​Alternate DNS server: 8.8.4.4

​Test the IP Configuration (DNS and conectivity) by opening a PowerShell and ping www.microsoft.com.

Modify the VM Name (optional)

​If you like you can change the Name of the Azure Stack VM. To do so you open the „Server Manager“ and switch to „Local Server“. ​Then click on the actual Name right to „Computer name“. ​In the „System Properties“ dialog click on „Change…“. ​Enter a Name in the ​“Computer name:“ text field that describe the Computer better than the ​self-generated name.​

Modify the IE Security Settings

To change the IE Security setting open „Server ​Manager“ and switch to „Local Server“. Then click on „IE Enhanced Security Configuration“. In the „Internet Explorer ​Enhanced Security Configuration“ and change the „Administrators:“ and „Users:“ Settings to „Off“

Installing Azure Stack

​Collect ​Deployment Parameter

​We are nearly ready to kick of the Azure Stack installation with the following PowerShell script.

./InstallAzureStackPOC.ps1 -InfraAzureDirectoryTenantName xxx.onmicrosoft.com -NATIPv4Subnet 172.16.0.0/24 -NATIPv4Address 172.16.0.3 -NATIPv4DefaultGateway 172.16.0.1 -TimeServer xxx.xxx.xxx.xxx -Verbose

​But first we need to ​substitute the „xxx“ placeholders with our deployment values.

​Azure Active Directory Tenant Name

​You can deploy Azure Stack in two different scenarios: the Connected one and the ​Disconnected one. ​The ​Connected scenario offers ​more ​possibility so we use this one. ​Therefor we need ​an Azure Subscription and an Azure Active Directory account. If you don’t have an Azure Subscription you can get a free Test ​Subscription here: https://azure.microsoft.com/en-us/free/

​In the PowerShell Script that we will use we need the Azure ​Directory Tenant Name. I use in the Installation my admin@RitsASTPoC.onmicrosoft.com Account. Here ​the Azure Directory Tenant Name is ​everything behind the @. So in my example ​ it is RitsASTPoC.onmicrosoft.com.​​​​​

https://azure.microsoft.com/en-us/free/

Time Server IP Address

​To install Azure Stack with PowerShell we ​also must specify an Time Server. To get one you have many ​possibilities. I like the Ntp ​Pool Project.  Choose one that is near your deployment for example if you are in Germany you ​use ​an IP of ​​de.pool.ntp.org or if you are in the US you ​use ​an IP of us.pool.ntp.org. ​ ​I use „nslookup de.pool.ntp.org“ and take the first IP Address ​that is returned (in this example it was 213.209.209.45).

Deploy with the PowerShell Script

Now we are ready to kick off the ​deployment. To do so open PowerShell and change the Working directory to C:/CloudDeployment/Setup.

Start the Installation with the following PowerShell Script (change your Azure Directory ​Tenant Name and your Time Server)

./InstallAzureStackPOC.ps1 -InfraAzureDirectoryTenantName ​RitsASTPoC.onmicrosoft.com -NATIPv4Subnet 172.16.0.0/24 -NATIPv4Address 172.16.0.3 -NATIPv4DefaultGateway 172.16.0.1 -TimeServer ​213.209.209.45 -Verbose

Enter the Local Admin Password of your Azure Stack virtual machine.

​

​The Installation starts and after some tests you ​must enter a AAD Account for the Installation as you see in the Screenshot below (In my case it would be admin@RitsASTPoC.onmicrosoft.com).

​Now the installation process will run for 4 to 5 hours. After that you should see an output like the screenshot below.

​In Case of Errors

​If something went wrong and the installation stops with some errors you can restart the installation with the following PowerShell Command:

./InstallAzureStackPOC.ps1 -rerun

​Check Installation​

​To check if the installation was ​successful start the Azure Stack Admin Portal. You can do that by open the Internet Explorer and ​browse to the „https://adminportal.local.azurestack.external“ ​URL​.

​If the Browers open the portal everything should work as ​planned.

Have fun playing with Azure Stack.

​What do you think about the Article? Do you have questions? Please leave a comment below.

Am 13​. November ist es um 11 Uhr wieder soweit. Wir haben ein weiteres Webinar in unserer Storage Spaces Direct Deep Dive Serie. Diesmal geht es um die Neuerungen die es für diese Technologie im Windows Server Insider Preview gibt.​

Inhalte:

• • ​Storage Class Memory
  • ReFS Verbesserung
  • Mirror-Accelerated Parity Volumes
  • Honolulu
  • Demo
  • eure Fragen

Zum Anmelden klickt Ihr auf das Bild oder hier! Wenn Ihr keine Zeit habt meldet euch trotzdem an dann bekommt Ihr nach dem Webinar eine Mail mit dem Link zur Aufzeichnung!

Dieser Blogpost ist der fünfte von insgesamt fünf Teilen, die in den folgenden Wochen veröffentlicht werden. Grundlage für die Beiträge ist ein Whitepaper, welches ich vor kurzem geschrieben habe und welches exklusiv für Newsletter-Abonnenten ​zur Verfügung steht. Sie können das vollständige Whitepaper als PDF weiterhin erhalten, wenn Sie sich für unseren Newsletter anmelden. Nach kurzer Zeit taucht ein Overlay auf, in dem Sie sich registrieren können.

Alle fünf Teile

Im folgenden finden Sie Links zu den fünf Beiträgen. Sollte ein Link noch nicht vorhanden sein, liegt es daran, dass er noch nicht veröffentlicht wurde.

​Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 1​

Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 2​

Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 3​

Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 4​

Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 5

Die Nutzung von iSCSI oder Fibre Channel Storage

​Kommen statt SMB3 Shares LUNs zum Einsatz, so sind diese erfahrungsgemäß per iSCSI oder per Fibre Channel angeschlossen. Dieser Teilbereich geht auf die Änderungen und Anpassungen ein, die bei der Nutzung von solch einem SAN-System zu beachten ist.

​Die Anbindung an das Storage-System

​Kommt Fibre Channel zum Einsatz, so müssen die Server mindestens einen FC HBA besitzen, meist ist ein Dual Port-Controller oder zwei Controller im Einsatz. Installieren Sie die aktuellste Firmware sowie den aktuellsten Treiber vor der Einrichtung.

​Bei der Nutzung von iSCSI sollten Sie ebenfalls auf die aktuellsten Treiber und Firmware-Stände achten, weiterhin sollten die Netzwerkkarten (ich gehe einfach mal davon aus, dass grundsätzlich eine Redundanz besteht) ausschließlich eine IPv4 oder IPv6-Bindung haben:

Weiterhin sollten DNS- und NetBIOS-Einstellungen angepasst werden:

MPIO

​Als nächstes müssen wir, egal ob iSCSI oder FC, die Multipath-Funktion (MPIO) aktivieren. Dieses geschieht über den Server-Manager und benötigt seit Windows Server 2016 einen Neustart, bisher war die Installation ohne einen Neustart möglich, erst die Aktivierung brauchte einen Neustart. Nun dürfen wir zwei Mal einen neuen Kaffee holen :)

Kein Teaming bei iSCSI

Ich sehe immer wieder Installationen, bei denen die iSCSI-Karten zu einem Team zusammengefasst wurden. Diese Art von Betrieb ist nicht unterstützt, die iSCSI-Karten müssen und dürfen ausschließlich per MPIO betrieben werden. Wir haben schon die unterschiedlichsten Verhalten und Fehler gesehen, wenn iSCSI-Karten geteamt betrieben werden.

Wir beginnen nun mit der Installation von MPIO und dem Neustart der Server:

Install-WindowsFeature -Name Multipath-IO

Ist der Server wieder da, können wir MPIO konfigurieren. Dies geschieht entweder über den Server-Manager im Reiter Tools, über das Startmenü oder über die Systemsteuerung. Beim ersten Aufruf sehen wir im ersten der vier Reiter den einzigen und immer enthaltenen Eintrag:Vendor 8Product      16.

Wechseln Sie auf den zweiten Reiter (Discover Multi-Paths) und wählen Sie hier die benötigte Konfiguration. Bei iSCSI markieren Sie Add Support for iSCSI devices, bei Fibre Channel haben Sie im oberen oder unteren Bereich einen Eintrag, den Sie markieren müssen. Danach müssen Sie die Auswahl mit Add bestätigen, NICHT mit OK das Fenster wieder schließen!

Wenn alles korrekt ist, bekommen Sie eine Rückfrage, ob Sie den Server erneut durchstarten möchten. Beantworten Sie die Frage mit Ja, wird der sofort augenblicklich neu gestartet und wir können uns erneut einen Kaffee holen :)

Enable-MSDSMAutomaticClaim -BusType SAS

Hat die Installation geklappt, sehen wir nach dem Neustart einen weiteren Eintrag im MPIO-Manager:

Warum eigentlich MPIO

MPIO wird benötigt, um mehrere Wege (Ihre Netzwerkkarten oder FC HBAs) zu einem Ziel (z.B. eine LUN) zu verstehen. Nutzen Sie zwei Netzwerkkarten und verbinden sich über beide Karten mit einer LUN, taucht diese LUN in Ihrem Windows ohne eine aktive MPIO-Nutzung doppelt auf. Hätten Sie vier Verbindungen zum gleichen Datenträger, so würde der Datenträger vier Mal auftauchen. Durch die Installation und Konfiguration von MPIO versteht Ihr Betriebssystem, dass es sich bei den „zwei“ oder „vier“ LUNs um das gleiche Objekt handelt und zeigt es nur noch einmal an. Sie können weiterhin unterschiedliche Einstellungen vornehmen, wie mit dem Datenträger kommuniziert wird: Eine Round-Robin-Einstellung verteilt die Kommunikation mit der LUN über die verfügbaren Netzwerkkarten, eine Failover-Only-Konfiguration zum Beispiel nutzt nur eine Karte und weicht auf eine andere aus, falls die erste mal nicht zur Verfügung steht. Least-Queue-Depth als weitere Möglichkeit sucht sich immer die Karte mit der geringsten Warteschlagen aus. Kontaktieren Sie den Hersteller von Ihrem SAN bzw. schauen Sie im Admin-Guide nach, welche Einstellung für Ihr Gerät empfohlen wird. Die meisten Hersteller geben eine Empfehlung raus für den optimalen Betrieb.

Die Einrichtung der iSCSI-Verbindungen

Öffnen Sie, z.B. über den Server-Manager und den Reiter Tools, den iSCSI Initiator. Beim ersten Aufruf bekommen Sie eine Frage, ob der iSCSI-Dienst in Zukunft immer automatisch starten soll. Beantworten Sie diese Frage auf jeden Fall mit Ja, sonst wird der Dienst nach einem Neustart nicht automatisch gestartet und die Storage-Verbindungen können nicht aufgebaut werden.

Nun können wir die Verbindung zu unserem Storage aufbauen. Vermeiden Sie hier eine Verbindung per Quick Connect, da Sie bei dieser Variante zu wenig Einfluss auf die Verbindungen haben. Eine Ausnahme bildet hier ein eigener MPIO-Treiber vom Hersteller des SAN-Storage, ich habe teilweise schon mit Treibern gearbeitet, die alle verfügbaren Pfade automatisch erkennen und eintragen. In meinem Fall ist dies aber nicht möglich, daher der manuelle Weg.

Wir beginnen damit, dass wir im Reiter Discovery mit der Option Discover Portal… die IP-Adressen von unserem SAN hinzufügen.

In meinem Fall sind dies zwei IP-Adressen, 192.168.207.33 und 192.168.206.33. Weitere Optionen müssen hier erstmal nicht ausgewählt werden, es reicht, wenn die IP-Adressen eingetragen sind.

Nutzen Sie mehrere Subnetze

Nutzen Sie nach Möglichkeit unterschiedliche Subnetze für Ihre iSCSI-Netzwerkkarten in den Hyper-V Hosts und in Ihrem SAN. Dies erhöht die Übersicht bei der Einrichtung der Verbindungen, weiterhin erhalten Sie im Failover Cluster mehrere Cluster-Netzwerke, die entsprechend dem Bedarf eingerichtet werden können.

Wenn die Verbindung innerhalb einer Sekunde eingetragen ist, sieht das häufig nach einer erfolgreichen Verbindung aus. Je länger der Manager braucht, um die IP-Adresse einzutragen, desto wahrscheinlicher haben Sie einen Fehler und können nicht auf das Storage-System zugreifen. Das Resultat sieht bei mir wie folgt aus:

Wir wechseln nun in den Reiter Targets, um die Verbindung mit unseren LUNs aufzubauen. Vor der Einrichtung sehen wir (in meinem Fall) eine inaktive Verbindung. Je nach SAN können sich die einzelnen Controller auch als eigenes Ziel zeigen, in diesem Fall haben Sie dann zwei oder mehr Einträge.

Nun beginnt der aufwändigste Teil der Konfiguration: Die Einrichtung der Verbindungen zu unserem Storage. Ziel ist es, von jeder Netzwerkkarte mindestens eine Verbindung zu unserem Ziel aufzubauen. Haben Sie zwei Karten und zwei Ziel-IPs auf Ihrem SAN, so brauchen Sie in Summe zwei Verbindungen. Hat auf dem SAN jeder Controller zwei IP-Adressen, so sind es schon vier Verbindungen usw.

​Beginnen Sie mit einem Klick auf das erkannte Ziel (in meinem Fall iqn.1991-05.com.microsoft:fscluster-san1-target) und wählen Sie Connect. Im nächsten Fenster aktivieren Sie beide Optionen (die erste ist für eine Wiederverbindung nach einem Neustart, Wichtig! und die zweite Option ist eine aktive Nutzung der Multi-Pfad-Option) und wählen dann den Button Advanced….

Stellen Sie in den erweiterten Optionen den lokalen Adapter auf Microsoft iSCSI Initiator, die Initiator-IP auf den ersten iSCSI-Adapter in Ihrem lokalen Server und die Target portal IP auf die entsprechende Adresse in dem gleichen IP-Subnetz.

Drücken Sie nun OK und bestätigen das dahinterliegende Fenster ebenfalls, haben Sie die erste Verbindung mit Ihrem SAN aufgebaut. Die Verbindung sollte nun auf Connected umspringen. Diesen Schritt müssen wir nun für jede Verbindung erneut durchführen. Die zweite Verbindung in meinem Fall sieht wie folgt aus:

In der Datenträgerverwaltung sollten nun, wenn Sie die Zugriffsrechte auf dem Storage korrekt vergeben haben, die LUNs auftauchen.

Zurück im iSCSI-Initiator tauchen nun im dritten Reiter, den bevorzugten Zielen, zwei neue Einträge auf:

Nun müssen wir noch eine letzte Einstellung vornehmen, bevor wir mit der Anbindung der LUNs fertig sind. Wechseln Sie in den vierten Reiter (Volumes und Devices) und bestätigen Sie die Option Auto Configure. Diese Option sorgt dafür, dass die Datenträger bei einem Reboot zu einem früheren Zeitpunkt gemappt werden und schneller zur Verfügung stehen.

Damit sind wir mit der Konfiguration des ersten Servers durch, nun werden die gleichen Einstellungen auf dem zweiten Host gesetzt.

Formatierung der Datenträger

Bevor wir die Datenträger im Failover Cluster nutzen können, müssen wir sie natürlich noch mit einem Dateisystem ausstatten. Dies geht am einfachsten über die Datenträgerverwaltung auf einem der Hosts. Nehmen Sie die Datenträger online und formatieren Sie die Datenträger mit NTFS. Achten Sie bei der Blockgröße darauf, welche Empfehlungen der SAN-Hersteller hier vorgibt. Diese Informationen finden sich meist, wie auch die MPIO-Einstellungen, in den Hersteller-Guides. Vergeben Sie KEINE Buchstaben für die Volumes, wir nutzen die Datenträger später als Cluster Shared Volumes, dort arbeiten wir mit Mount Points, nicht mit Buchstaben. Das Ergebnis sieht folgendermaßen aus:

Test der Datenträger im Failover Cluster

Wenn Sie noch kein Failover Cluster besitzen, können Sie nun einen Test der Konfiguration durchführen, in diesem Fall werden die Datenträger auf Ihre Tauglichkeit im Failover Cluster getestet. Ich in meinem Fall besitze bereits ein aktives Failover Cluster, daher starte ich den Test manuell. Dieses Mal, gegenüber dem Test vorher mit der Anbindung an die SMB3-Shares, kann man die Tests der Datenträger sehen und auch, ob diese erfolgreich sind oder nicht.

Als nächstes können die Datenträger im Bereich Storage – Disks hinzugefügt und als Cluster Shared Volume eingebunden werden. Der kleine Datenträger mit einer Größe von 10 GB wird als Quorum verwendet.

Per PowerShell geht das natürlich auch :)

Get-ClusterAvailableDisk | Add-ClusterDisk