Tags: Hyperkonvergenz, Azure, Windows Admin Center
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
Marcel Küppers arbeitet seit über 25 Jahren in der IT, aktuell als Team Leader, zuvor als Consultant und Infrastructure Architect unter anderem für den japanischen Konzern JTEKT/TOYODA mit Verantwortung über die Europastandorte Krefeld und Paris. Darüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Lokationen des Konzerns mit und ist spezialisiert auf hochverfügbare virtualisierte Microsoft-Umgebungen plus Hybrid Cloud Solutions. Zertifizierungen: MS Specialist und MCTS für Hyper-V/SCVMM, MCSE, MCITP, MCSA. Zusätzlich zertifiziert für PRINCE2 Projektmanagementmethode.
// Kontakt: E-Mail, Twitter, LinkedIn //
Ähnliche Beiträge
- Windows Admin Center 2110: Multi-Server-Dashboard, VHD-Tool, Support für Azure Stack HCI 21H2
- Hyperkonvergente Windows-Cluster mit Azure Monitor überwachen
- Azure Stack HCI: Microsoft kombiniert Windows Server 2019, Storage Spaces Direct und Admin Center
- Windows Admin Center 2306: Erweitertes Management von Hyper-V, Cluster und Azure Stack HCI
- Windows Admin Center 2211: Konfiguration von WDAC, erweiterter Support für Azure Stack HCI
Weitere Links
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.“