Microsoft hat Azure Stack HCI vor wenigen Tagen offiziell in Azure Local umbenannt. Seitdem werde ich oft gefragt, was sich technisch tatsächlich ändert und ob es überhaupt um mehr als den Namen geht. Bei den Kunden in meinen Projekten, die bisher auf Azure Stack HCI gesetzt haben, beobachte ich vor allem eines: Sie müssen sich an den neuen Begriff gewöhnen, können ihre bewährten Workloads und Verwaltungsansätze aber weiterhin nutzen. Zugleich gewinnen die Azure-Integration und die Verwaltung über Arc noch mehr Gewicht.

Azure Local verbindet validierte Hardware mit der Verwaltung über Azure Arc

Azure Local steht für eine Infrastruktur auf Hardware, die Microsoft validiert hat und auf der das sogenannte Azure-Local-OS läuft. Verwaltet werden diese Systeme vollständig über das Azure-Portal und Azure Arc. Das gilt für klassische virtuelle Maschinen (Arc VMs) ebenso wie für AKS-Cluster oder Azure Virtual Desktop. Die Workloads laufen lokal im Rechenzentrum oder in der Filiale, gesteuert werden sie zentral aus der Cloud. Für viele Kunden bedeutet das einen spürbaren Schritt in Richtung eines einheitlichen Betriebs, denn wer Azure kennt, deckt mit denselben Werkzeugen auch Edge-Standorte, Zweigstellen oder besondere On-Premises-Anforderungen ab. Mehr zur Architektur (Überblick) und zum Abrechnungsmodell (Abrechnung) stellt Microsoft in der eigenen Dokumentation bereit.

Seine Stärken spielt Azure Local dort aus, wo niedrige Latenzen, besondere Compliance-Vorgaben oder Regeln zur Datenresidenz gefragt sind, etwa im Gesundheitswesen, an Produktionsstandorten oder im Einzelhandel. Liegt die nächste Azure-Region zu weit entfernt oder ist die Internetanbindung unzuverlässig, lassen sich moderne Cloud-Patterns und eine zentrale Verwaltung trotzdem nutzen. Wer dagegen nur ein paar VMs in einem einfachen Netzwerk betreibt, kommt mit klassischem Hyper-V meist günstiger und mit weniger Aufwand ans Ziel. Und wo es keine besonderen Edge-Anforderungen gibt, aber maximale Skalierung zählt, ist reines Azure kaum zu schlagen.

Die Bereitstellung läuft inzwischen komplett über das Azure-Portal

Im Vergleich zu älteren Hyper-V-Installationen fällt sofort auf, wie stark Azure Local von Azure Arc abhängt. Ohne Arc-Registrierung und Verbindung zu Azure geht praktisch nichts. Für die Inbetriebnahme sind deshalb folgende Voraussetzungen nötig:

  • von Microsoft validierte Hardware (zertifizierte OEMs, z. B. Dell, HPE, Lenovo)
  • ein lokales Active Directory und ein Netzwerk für die Hosts
  • eine Azure-Subscription mit Berechtigung für die Arc-Registrierung
  • Konnektivität zu Azure für Verwaltung und Abrechnung
  • die Installationsmedien für das Azure-Local-OS

Die eigentliche Bereitstellung hat Microsoft mittlerweile ordentlich ins Azure-Portal eingebunden. Unter Azure → Azure Local → Neues Cluster erstellen bindet man nacheinander die Hardware an, konfiguriert das lokale Cluster und aktiviert die Verwaltung über Arc (Details zur Bereitstellung). Viele frühere Stolpersteine wie manuell verteilte Zertifikate oder eine verzwickte Netzwerkkonfiguration fallen damit weg. Nach wie vor muss das lokale Active Directory aber sauber eingerichtet sein, und die Netzwerkanforderungen sollte man früh klären, also Ports, Firewall und Site-to-Site-VPNs.

Wie die einzelnen Komponenten zusammenspielen, zeigt das folgende Diagramm:

flowchart TD
  User["Admin im Azure-Portal"] --> Arc["Azure Arc"]
  Arc --> AzureLocalOS["Azure Local-OS"]
  AzureLocalOS --> VMs["Arc VMs"]
  AzureLocalOS --> AKS["AKS-Cluster"]
  AzureLocalOS --> AVD["Azure Virtual Desktop auf Azure Local"]
  AzureLocalOS --> AD["Lokales Active Directory"]
  Arc --> Azure["Azure (Abrechnung, Management)"]

Abbildung: Komponenten und Verwaltungswege bei Azure Local.

Microsoft rechnet Azure Local pro physischem Core und Monat ab

Die Abrechnung von Azure Local erfolgt ausschließlich über Azure. Lizenziert wird pro physischem Core und Monat, berechnet über die verknüpfte Subscription. Lizenzen für Windows-Server-Gastsysteme lassen sich flexibel ergänzen, entweder als Add-on oder über vorhandene Volumenlizenzen mit Software Assurance. Interessant ist das vor allem für Kunden mit vielen Windows-Server-VMs, die Workloads bei Bedarf zwischen lokaler Umgebung und Cloud verschieben möchten. Weil das Modell gut durchschaubar ist, bleiben unangenehme Überraschungen eher aus, gerade in größeren Umgebungen mit vielen Hosts.

Praxistipp: Vor der Inbetriebnahme rate ich dazu, die Hardwareausstattung und die geplanten Workloads genau zu erfassen. Jeder überflüssige Core erhöht die Kosten, und bei großen Clustern summiert sich das schnell. Auch die Lizenzierung der Gastsysteme und die Verteilung der Serverrollen sollte man vorher prüfen, damit die monatliche Rechnung kein böses Erwachen bringt.

Nicht jedes Projekt braucht Azure Local

In vielen Tenants, die ich mir ansehe, lohnt sich Azure Local vor allem dann, wenn tatsächlich eine Brücke zwischen klassischem Rechenzentrum und Cloud nötig ist. Typische Gründe sind latenzkritische Anwendungen, Daten, die vor Ort bleiben müssen, oder der Wunsch nach einer einheitlichen Verwaltung über Arc. Für gewöhnliche Server-Workloads ohne besondere Anforderungen ist ein lokales Hyper-V oder VMware oft schlanker und billiger. Umgekehrt rufen manche Projekte sofort „Azure Local!“, wären aber mit reinem Azure und Diensten wie Azure Virtual Desktop oder AKS in der Cloud auf Dauer besser aufgehoben. Dort entfällt die Hardwarepflege, die Komplexität sinkt, und skalieren lässt sich nahezu beliebig. Welche Variante passt, hängt am Ende vor allem von Standort, Compliance, Netzwerk und der Bereitschaft zu investieren ab.

Azure Local ist mit dem neuen Namen erwachsen geworden

Die Umbenennung macht deutlich, in welche Richtung Microsoft das Produkt entwickelt. Es wächst konsequent ins Azure-Ökosystem hinein, die Herkunft als HCI-Lösung verliert an Bedeutung. In der Praxis erlebe ich, dass viele Kunden von der zentralen Steuerung und der einheitlichen Verwaltung profitieren. Trotzdem bleibt Azure Local eine Lösung für bestimmte Fälle. Nicht jeder kleine Standort braucht eigene Hardware samt Arc-Integration, nur weil das Ganze jetzt nach „Azure im eigenen Haus“ klingt. Wer Edge-Standorte oder Zweigstellen ernsthaft modernisieren möchte, bekommt damit aber eine ausgereifte, cloudnahe Plattform, die den Vergleich nicht mehr scheuen muss.