Azure Stack HCI 20H2 - hyperkonvergente Cluster auf Basis eines eigenen Windows-OS

Unter Azure Stack fasst Micro­soft Pro­dukte für das lokale Rechen­zen­trum zu­sammen. Mit­glied dieser Produkt­familie ist auch Azure Stack HCI, mit dem sich hyper­konver­gente Cluster ein­richten lassen. Version 20H2 bringt ein dedi­ziertes Betriebs­system mit und lässt sich über WAC konfigurieren.

Hyper­konvergente Cluster bestehen aus Standard-x86-Server-Hardware, lokalem Festspeicher wie SSDs oder NVMe und einem Hypervisor wie Hyper-V. Damit der Verbund auf den gemeinsamen Festspeicher Zugriff hat, benötigt man eine weitere Komponente für das Software-defined Storage. Im Falle von Azure Stack HCI (steht für Hyper-converged Infrastructure) ist das Storage Spaces Direct (S2D).

Der lokale Speicher der Hosts lässt sich über die virtuellen HBA-Komponenten in einem Cluster zusammen­ziehen. Hochverfügbare virtuelle Maschinen von Hyper-V werden dann auf den Cluster Shared Volumes (CSVs) der Knoten abgelegt. Shared Storage in Form eines klassischen Storage Area Network (SAN) ist somit hinfällig.

Azure Stack HCI OS

Microsoft hat S2D seit Server 2016 als Feature in seinem OS implementiert. Die erste Version einer Azure Stack HCI-Lösung setzte dann auf Windows Server 2019 Datacenter auf. Azure Stack HCI 20H2 geht nun einen Schritt weiter und verwendet als Grundlage nicht den kompletten Windows Server 2019, sondern bringt ein dediziertes und schlankes Betriebs­system an den Start. Die Fakturierung passiert über Azure und verwendet keine Datacenter-Version Lizenzierung.

Das Betriebssystem von Azure Stack HCI 20H2 (bis September als Preview) bündelt sämtliche Software-Komponenten für einen HCI-Virtualisierungs-Host. Infrastruktur­dienste wie DNS, AD DS oder DHCP lassen sich damit nicht implementieren. Das reduziert die Angriffsfläche und erhöht die Stabilität. Erwartungs­gemäß sind die Parallelen zu Windows Server Core nicht zu übersehen.

Die Spezialisierung auf hyperkonvergente Infrastrukturen wirkt auch möglichen Fehlkon­figurationen entgegen, und das aktuelle Windows Admin Center (WAC) liefert dafür die nötige Verwaltungs­oberfläche. Zusätzlich erhält das neue Azure Stack HCI OS Optimierungen, beispielsweise beim resync von Storage Spaces Direct.

Wer das Azure Stack HCI OS evaluieren und das eventuell in seinem eigenen Nested Lab tun möchte, findet das 2,9 GB-große ISO hier.

Windows Admin Center und Azure Stack HCI

Microsofts Weg zu einem grafischen Tool für hyper­konvergente Cluster zeichnete sich bereits Ende letzten Jahres ab. Damals erhielt das Windows Admin Center eine Extension zum Einrichten eines solchen Verbundes.

Erstmals war es damit möglich, via Web-Oberfläche und ohne große PowerShell-Umschweife diese Art von HA-Cluster zu erstellen (siehe: Hyperkonvergente Cluster mit Storage Spaces Direct in Windows Admin Center erstellen und auch meinen Tweet dazu).

Eine bequeme und Dashboard-basierte Administration einer S2D-Umgebung lieferte das Windows Admin Center bereits früher. Meiner Meinung nach gaben Storage Spaces Direct und hyper-converged Cluster den Anstoss zur Entwicklung des WAC.

Die Möglichkeit zum Einrichten eines Stretched Cluster mit S2D für ein Disaster-Recovery-Szenario kam erst Ende letzten Jahres hinzu (siehe: Disaster Recovery in the next version of Azure Stack HCI). Ein solcher lässt sich jetzt ebenfalls über das aktuelle WAC konfigurieren.

Hybrid Cloud und Azure Stack HCI

Für mich nicht besonders überraschend ist der immer engere Zusammen­schluss der On-Prem-Produkte mit der Azure Public Cloud. Dieser äußert sich erneut etwa darin, dass Azure Arc (siehe dazu: Lokale Server mit Azure Arc for Servers verwalten) nun nativ eine Azure Stack HCI-Konfiguration verwalten kann.

Azure Stack HCI erfordert eine Azure Subscription. Der Cluster muss sich alle 30 Tage bei Azure melden. Virtuelle Maschinen lassen sich optional zukünftig bequem über den etablierten Azure Resource Manager (ARM) definieren, zudem können Azure Resource Groups (RG) ihre Organisation verbessern. Interessant dabei ist die Möglichkeit, über den Azure AD Tenant das Erstellen von virtuellen Maschinen an andere User für das Self-Deployment zu delegieren.