Redundanz für Storage Account von Benutzer Profilen

Azure Storage Accounts sind eine essentielle Komponente in vielen Azure-Umgebungen und dienen als vielseitige Lösung für unterschiedlichste Anforderungen – von der Speicherung von Log-Dateien bis hin zu Daten für Applikationen. In meinem Alltag nutze ich sie jedoch vor allem für einen ganz besonderen Zweck: das Speichern von Benutzerprofilen mithilfe von FSLogix. Diese Profile spielen eine zentrale Rolle, um eine performante und nahtlose Endbenutzererfahrung zu gewährleisten, besonders in virtuellen Desktopumgebungen wie Azure Virtual Desktop (AVD).

Ein oft übersehener, aber kritischer Punkt dabei ist die Wahl der Redundanz des Storage Accounts. In der Vergangenheit war es im Nerdio Manager for Enterprise nur möglich, Storage Accounts mit lokal redundanter Speicherung (LRS) zu erstellen. Viele bestehende FSLogix-Implementierungen basieren daher noch auf LRS-Storage. Doch diese Konfiguration birgt Risiken, besonders in Umgebungen, die auf Verfügbarkeit über mehrere Azure Availability Zones ausgelegt sind.

Warum LRS in solchen Szenarien oft nicht ausreicht und welche Auswirkungen dies auf die Verfügbarkeit von Benutzerprofilen haben kann, möchte ich in diesem Beitrag genauer erläutern.

Verteilung von AVD Host Pools über Availability Zonen

Eine bewährte Methode, um die Ausfallsicherheit von Azure Virtual Desktop (AVD) Umgebungen zu erhöhen, ist die Verteilung der virtuellen Maschinen (VMs) eines Host Pools über mehrere Availability Zonen. Dieses Setup stellt sicher, dass bei einem Ausfall einer Zone ein Teil der Host Pool Kapazitäten weiterhin verfügbar bleibt und Benutzer weiterarbeiten können.

Diese Architektur nutzt die hohe Verfügbarkeit, die Azure innerhalb einer Region bietet, optimal aus und minimiert gleichzeitig das Risiko, dass ein Zonenausfall die gesamte Umgebung beeinträchtigt. Jedoch wird oft übersehen, dass die Verfügbarkeit der Benutzerprofile – und damit die Fähigkeit der Benutzer, sich überhaupt anzumelden – eine ebenso wichtige Rolle spielt. Wenn die Profile auf einem Storage Account liegen, der nur lokal redundant ist, kann ein Zonenausfall trotzdem zu einem Ausfall für die Benutzer führen, selbst wenn ausreichend Host Pool Kapazitäten vorhanden sind.

Dieser kritische Zusammenhang zwischen der Verteilung der VMs und der Wahl des richtigen Speichermodells für FSLogix-Profile wird häufig unterschätzt, obwohl er entscheidend für die Gesamtverfügbarkeit ist.

Warum LRS für Profile falsch sein kann

Lokal redundante Speicherung (LRS) sorgt dafür, dass Daten innerhalb eines einzelnen Rechenzentrums dreifach repliziert werden. Das bietet Schutz gegen Ausfälle innerhalb dieser Zone. Allerdings bleibt ein großes Risiko bestehen: Fällt die gesamte Azure Availability Zone aus, sind die Daten auf einem LRS-Storage Account nicht mehr verfügbar.

In zonenübergreifenden AVD Umgebungen, bei denen virtuelle Maschinen auf mehrere Zonen verteilt sind, kann dies problematisch sein. Der Vorteil, dass ein Teil der Benutzer trotz eines Zonenausfalls weiterarbeiten könnte, wird durch die Abhängigkeit von einem LRS-Storage Account zunichtegemacht. Wenn das Benutzerprofil nicht erreichbar ist, können sich Benutzer nicht anmelden oder arbeiten nur eingeschränkt – unabhängig davon, ob die VM selbst noch läuft.

Daher ist es wichtig, für FSLogix-Profile eine redundantere Speicheroption zu wählen, wie zum Beispiel zone-redundante Speicherung (ZRS), um eine höhere Verfügbarkeit und Ausfallsicherheit zu gewährleisten.

Für Umgebungen, in denen Geo-Redundanz erforderlich ist, empfiehlt es sich, diese durch dedizierte Host Pools und separate Storage Accounts pro Region zu erreichen. So wird sichergestellt, dass Benutzer immer mit einer lokal verfügbaren Infrastruktur arbeiten können, ohne auf die höhere Latenz und potenziellen Einschränkungen von GRS oder GZRS zurückgreifen zu müssen. Diese Ansätze ermöglichen nicht nur eine bessere Kontrolle über die Datenströme, sondern bieten auch die Möglichkeit, regionale Ausfälle gezielt und effizient abzufangen.

Im nächsten Abschnitt zeige ich, wie eine Migration von LRS- zu ZRS-Speicherung mithilfe von PowerShell durchgeführt werden kann, um bestehende Umgebungen auf den neuesten Stand zu bringen.

Migration von LRS zu ZRS mit PowerShell

Die Migration bestehender Storage Accounts von lokal redundanter Speicherung (LRS) zu zonenredundanter Speicherung (ZRS) kann primär auf zwei Wegen durchgeführt werden: über ein Support-Ticket oder mithilfe von PowerShell. Im Folgenden zeige ich den Code, den ich für diese Migrationen verwende.

Mit dem Array können mehrere Storage Accounts gleichzeitig migriert werden. Dafür werden der Name, die Resource Group und die Subscription des jeweiligen Storage Accounts benötigt. Als Ziel-SKU verwende ich Premium_ZRS, da meine Storage Accounts in der Regel bereits Premium_LRS sind und für Profile optimiert werden sollen.

Wichtig: Mit dem Parameter $migrate wird das Skript zunächst nur zur Überprüfung verwendet. Um die Migration tatsächlich zu starten, muss der Parameter auf $true gesetzt werden. Anschließend sollte er wieder auf $false zurückgesetzt werden, um zu verhindern, dass die Migration versehentlich mehrfach ausgeführt wird.

Um den Code auszuführen, öffne ich das Azure-Portal, starte die Cloud Shell und füge den Code dort ein. Die Ausgabe sieht dann wie folgt aus:

Wenn nun später mit dem Parameter $migrate und dem Wert auf $false das Skript ausgeführt wird, kann die Migration überprüft werden:

Weitere Informationen

Welche Migration Szenarien für Storage Accounts zur Verfügung stehen kann unter folgendem Artikel überprüft werden: Changing redundancy configuration

Ebenso sollte vor einer allfälligen Migration geprüft werden, ob der Storage Account in einer Region ist, welche Availability Zonen unterstützt: Azure regions that support zone-redundant storage (ZRS)

Es kann vorkommen, dass eine Migration nicht innerhalb von 5 Tagen Abgeschlossen werden kann. In diesem Fall müsste ein Support Ticket erstellt werden. Wir haben schon erlebt, dass der Support dies dann überprüfen und in Auftrag geben musste. In unserem Fall war es eine stark ausgelastete Region.

Neue Storage Accounts

Seit Version 6.0 des Nerdio Manager for Enterprise ist es möglich, neue Storage Accounts direkt mit zone-redundanter Speicherung (ZRS) zu erstellen. Diese Verbesserung erleichtert die Einrichtung von Storage Accounts erheblich, da ZRS nun von Anfang an als Redundanzoption verfügbar ist und nicht mehr manuell nachträglich migriert werden muss.

Abschluss

Die Migration von Storage Accounts kann komplex sein, insbesondere wenn die Zielregionen nicht unterstützt werden oder bestimmte Features die Migration verhindern. In solchen Spezialfällen sollte die offizielle Dokumentation sorgfältig geprüft und die Migration zunächst mit einem Test-Storage-Account ausprobiert werden.

Ich hoffe jedoch, dass ich aufzeigen konnte, warum eine Migration sinnvoll ist und wie sie erfolgreich durchgeführt werden kann.