Azure Stack HCI 20H2 - hyperkonvergente Cluster auf Basis eines eigenen Windows-OS
Unter Azure Stack fasst Microsoft Produkte für das lokale Rechenzentrum zusammen. Mitglied dieser Produktfamilie ist auch Azure Stack HCI, mit dem sich hyperkonvergente Cluster einrichten lassen. Version 20H2 bringt ein dediziertes Betriebssystem mit und lässt sich über WAC konfigurieren.
Hyperkonvergente 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 zusammenziehen. 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 Betriebssystem 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. Infrastrukturdienste wie DNS, AD DS oder DHCP lassen sich damit nicht implementieren. Das reduziert die Angriffsfläche und erhöht die Stabilität. Erwartungsgemäß sind die Parallelen zu Windows Server Core nicht zu übersehen.
Die Spezialisierung auf hyperkonvergente Infrastrukturen wirkt auch möglichen Fehlkonfigurationen entgegen, und das aktuelle Windows Admin Center (WAC) liefert dafür die nötige Verwaltungsoberflä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 hyperkonvergente 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 Zusammenschluss 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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Ähnliche Beiträge
- Hyperkonvergente Windows-Cluster mit Azure Monitor überwachen
- Azure Stack HCI: Microsoft kombiniert Windows Server 2019, Storage Spaces Direct und Admin Center
- Hyperkonvergente Systeme: Azure Stack HCI versus Windows Server mit Storage Spaces Direct
- Windows Admin Center 2012 Preview: Cluster Tool nun GA (mit RDMA-Support), neues GPU-Tool
- Azure-VMs mit dem Windows Admin Center erstellen
2 Kommentare
"Der Cluster muss sich alle 30 Tage bei Azure melden." Wie geht das bzw. welche Ports/Sites müssen dafür freigeschaltet werden?. Finde nirgends eine Dokumentation.
Jeder Knoten nimmt via HTTPS (outbound) alle 30 Tage zum folgenden Endpunkt: *-azurestackhci-usage.azurewebsites.net Kontakt auf. Es fallen laut MSFT keine Kosten in der Preview-Phase an. Zusätzlicher Hinweis: „It's no problem to run disconnected from the internet for extended periods.“