Identifizieren des richtigen Notfallwiederherstellungsszenarios

• 10 Minuten

Um die Auswirkungen eines Rechenzentrumsausfalls oder eines regionalen Ausfalls zu begrenzen, muss Ihre Organisation den richtigen Notfallwiederherstellungsschutz vorbereiten. Das Festlegen der richtigen Schutzstrategie hängt in erster Linie davon ab, welche der verschiedenen Fehlerszenarien sich wahrscheinlich auf die Funktionalität von Azure Virtual Desktop auswirken.

Ziele und Metriken

Der Notfallwiederherstellungsprozess erfordert eine Koordination zwischen den einzelnen Maßnahmen und Verfahren, die durchgeführt werden, um eine Organisation wieder in den vollen Betrieb zu bringen. Diese Maßnahmen und Verfahren haben als gemeinsame, sie vereinende Basis klar definierte Servicelevelziele. Notfallwiederherstellungsdienste sollten die folgenden Metriken enthalten:

• Recovery Point Objective (RPO): Die Mindestmenge an Daten, die Clients wieder für den Dienst bereitgestellt werden müssen, basierend auf den gesicherten Ressourcen, die als wiederhergestellt gelten. Umgekehrt kann diese Menge als maximaler tolerierbarer Datenverlust betrachtet werden, ausgedrückt als Prozentsatz, der von 100 subtrahiert wird.
• Recovery Time Objective (RTO): Das für die Ausführung eines Wiederherstellungsprozesses maximale zulässige Zeitfenster. Dieses kann auch als Maß für die Ausfallzeit angesehen werden, die die betreffende Organisation in Kauf nehmen kann.
• Aufbewahrungszeitraum: Der maximal zulässige Zeitraum für die Aufbewahrung eines Sicherungsdatensatzes, bevor er aktualisiert und ersetzt werden muss.

RPO und RTO könnten als sich gegenseitig ausbalancierend betrachtet werden. Ein Kunde könnte also entscheiden, längere Wiederherstellungszeiten zuzulassen, um einen höheren RTO zu erzielen. Wenn die Wiederherstellungszeit für einen Kunden aufgrund der verfügbaren Bandbreite oder des Ausfallrisikos ein Problem darstellt, kann der Kunde möglicherweise keine hohe RPO erreichen.

Im Rest der Lerneinheit werden drei verschiedene Ausfallszenarien und die Vorbereitung eines BCDR-Plans (Bussiness Continuity and Disaster Recovery, Geschäftskontinuität und Notfallwiederherstellung) für Azure Virtual Desktop erläutert:

• Szenario 1: Lokale Beschädigung von Daten, Metadaten oder Ressourcen
• Szenario 2: Ausfall eines einzelnen Rechenzentrums der Verfügbarkeitszone in einer Azure-Region
• Szenario 3: Ausfall der Azure-Region

Szenario 1: Lokale Beschädigung von Daten, Metadaten oder Ressourcen

Angenommen, in Ihrer Azure Virtual Desktop-Umgebung kommt es zu einem Sitzungshostfehler oder einer Beschädigung des FSLogix-Profils. In solchen Situationen besteht die gängigste Wiederherstellungsmethode darin, die Profile aus einer Sicherung wiederherzustellen oder den Sitzungshost neu zu erstellen. In dieser Lerneinheit wird erklärt, wie die jeweilige Methode für die einzelnen Azure Virtual Desktop-Umgebungskomponenten anwendbar ist.

Azure Virtual Desktop-Dienst

Der Azure Virtual Desktop-Dienst bleibt voll funktionsfähig und von diesen Fehlertypen nicht betroffen. Microsoft ist dafür verantwortlich, alles innerhalb der bereitgestellten Vereinbarung zum Servicelevel (Service Level Agreement, SLA) wieder einzurichten und auszuführen.

AD DS und Microsoft Entra Domain Services

Active Directory-Domänencontroller sind wichtige Komponenten von Azure Virtual Desktop und müssen immer zugänglich sein. Um sicherzustellen, dass der Fehler die Funktionalität nicht beeinträchtigt, stellen Sie sicher, dass Sie mehrere Domänencontroller erstellt haben. Wenn Sie über Domänencontroller in Azure Virtual Machines verfügen, stellen Sie sicher, dass Sie diese so konfiguriert haben, dass sie sich in derselben Verfügbarkeitsgruppe befinden. Wenn Ihre Domänencontroller als lokale Computer ausgeführt werden, sollten Sie die Konnektivität zwischen Ihrem lokalen Netzwerk und dem virtuellen Azure-Netzwerk redundanzfrei entwerfen. Verwenden Sie Azure ExpressRoute, um redundante Pfade und Verbindungen zu verwalten. Sichern Sie den Active Directory-Systemstatus, und stellen Sie ihn bei Bedarf wieder her. Wenn Sie Microsoft Entra Domain Services verwenden, ist Microsoft für die Wartung redundanter Domänencontroller und deren Schutz vor ungeplanten Ausfällen verantwortlich.

Hostpools

Hostpools könnten im normalen Betriebsablauf nicht mehr verfügbar sein. Hostpools stellen Azure Virtual Desktops und Apps für Benutzer bereit. Sie werden über das Desktopimage eingerichtet. Wenn also ein Fehler auftritt und ein Desktopimage verfügbar ist, können Sie sie neu erstellen. Sie können auch einen separaten Hostpool für Anwendungen verwenden, die über Azure Virtual Desktop genutzt werden. Sie sollten auch einen ähnlichen Notfallwiederherstellungsansatz für diesen Hostpool in Betracht ziehen.

Virtuelle Netzwerke

Virtuelle Netzwerke sind verwaltete Dienste und von dieser Art von Ausfall nicht betroffen. Azure Virtual Network stellt einen privaten IP-Block bereit, wo Sie alle Ihre Ressourcen für private Verbindungen bereitstellen können, und diese Ressourcen können Sie dann innerhalb einer Grenze sichern. Daher kommt es bei einem virtuellen Netzwerk nie zu einer Unterbrechung oder bei einem lokalen Ausfall der Ressource in einem einzigen Rechenzentrum zu einem Ausfall.

FSLogix-Profile und MSIX App Attach

Abhängig von Ihrer FsLogix-Speichertechnologie können Sie Azure Backup für Azure Files-Freigaben und Azure NetApp Files-Momentaufnahmen konfigurieren. Alternativ können Sie den Sicherungsdienst verwenden, um Dateien und Ordner auf virtuellen Servercomputern zu schützen.

Bilder

Möglicherweise nehmen Sie während der normalen Wartung der Azure Virtual Desktop-Umgebung häufig Änderungen an Desktopimages vor. Sie sollten Sicherungen von Images verwalten, damit Sie sie im Falle einer Beschädigung schnell wiederherstellen können.

Szenario 2: Ausfall eines einzelnen Rechenzentrums der Verfügbarkeitszone in einer Azure-Region

Eine Azure-Region besteht aus einer Reihe von Rechenzentren, die innerhalb eines latenzdefinierten Perimeters bereitgestellt und über ein dediziertes regionales Netzwerk mit geringer Latenz verbunden sind. Ihr BCDR-Plan für Azure Virtual Desktop sollte für den Fall eines Ausfalls eines Rechenzentrums oder einer Zone in einer Azure-Region die in den folgenden Abschnitten aufgeführten Empfehlungen umfassen.

Azure Virtual Desktop-Dienst

Der Azure Virtual Desktop-Dienst ist von dieser Art von Ausfall nicht betroffen und bleibt voll funktionsfähig. Microsoft ist dafür verantwortlich, alles in Einklang mit der angegebenen SLA wiederherzustellen.

AD DS und Microsoft Entra Domain Services

Um den Ausfall eines einzelnen Rechenzentrums zu vermeiden, richten Sie in einer Verfügbarkeitszone mindestens zwei Domänencontroller ein. Wenn Sie Microsoft Entra Domain Services verwenden, verwaltet Microsoft die beiden Domänencontroller für Ihren Mandanten in einer separaten Verfügbarkeitszone, sofern dies von der Region unterstützt wird.

Hostpools

Für die Resilienz von virtuellen Hostpool-Computern können Sie einen Azure Virtual Desktop-Hostpool mithilfe von Verfügbarkeitszonen für virtuelle Computer bereitstellen. Sie können virtuelle Computer im Hostpool auf verschiedene Rechenzentren verteilen, die sich in derselben Region befinden.

Virtuelles Netzwerk

Virtuelle Netzwerke sind ein verwalteter Dienst und von diesem Fehlertyp nicht betroffen. Sie sollten sicherstellen, dass zuverlässige Ressourcen immer mit geeigneter Netzwerkkonnektivität konfiguriert sind. Beispielsweise kann die Verwendung eines Load Balancers vom Typ "Basic" von dieser Art von Fehler betroffen sein, da die Zonenverfügbarkeit nicht unterstützt wird.

FSLogix-Profile und MSIX App Attach

Verwenden Sie Azure Files mit zonenredundantem Premium-Speicher, um die Unterstützung für Verfügbarkeitszonen zu nutzen. In diesem Szenario bleiben FSLogix-Profile und MSIX App Attach-VHDs verfügbar, wenn ein Rechenzentrum ausfällt.

Bilder

Diese Art von Fehler wirkt sich nicht auf Images aus, da sie in einer anderen Zone verfügbar sind.

Szenario 3: Ausfall der Azure-Region

Ein Ausfall vollständiger Azure-Regionen ist sehr unwahrscheinlich und selten. Sie sollten dennoch auch auf das Eintreten solcher Ausfälle vorbereitet sein. Erwägen Sie die Aufnahme der folgenden Empfehlungen in einen BCDR-Plan für Azure Virtual Desktop.

Azure Virtual Desktop-Dienst

Der Azure Virtual Desktop-Dienst ist von dieser Art von Ausfall nicht betroffen und bleibt voll funktionsfähig. Microsoft ist dafür verantwortlich, alles in Einklang mit der angegebenen SLA wiederherzustellen.

AD DS und Microsoft Entra Domain Services

Um sich auf diese Art von Fehler vorzubereiten, können Sie eine verwaltete Domäne erweitern, um mehr als einen Replikatsatz pro Microsoft Entra-Mandant zu erhalten. Replikatgruppen können jedem virtuellen Netzwerk mit Peering in jeder Azure-Region hinzugefügt werden, die Microsoft Entra Domain Services unterstützt.

Wenn Sie lokale Domänencontroller verwenden, müssen Sie die Konnektivität mit dem virtuellen Netzwerk in der neuen Region konfigurieren, indem Sie entweder ein VPN, ExpressRoute oder ein virtuelles Wide Area Network (Virtual WAN) verwenden. Wenn Sie Microsoft Entra Domain Services verwenden, können Sie einen zusätzlichen Replikatsatz in einer anderen Region erstellen. Das virtuelle Netzwerk in der zusätzlichen Region, in der die neue Replikatmenge gehostet wird, muss mit dem Netzwerk kommunizieren können, das die primäre Gruppe von Microsoft Entra Domain Services hostet. Es wird empfohlen, Peering zwischen virtuellen Netzwerken für die standortinterne Replikation zwischen Replikatsätzen zu verwenden.

Hostpools

Sie können einen Azure Virtual Desktop-Hostpool in Aktiv/Aktiv- und Aktiv-Passiv-Konfigurationen bereitstellen:

• Aktiv/Aktiv: Bei einer Aktiv/Aktiv-Konfiguration kann ein einzelner Hostpool über VMs aus mehreren Regionen verfügen. Sie müssen Cloudcachefeatures kombinieren, um das FSLogix-Profil eines Benutzers aktiv in mehreren Regionen speicherübergreifend zu replizieren. Verwenden Sie zum Anfügen von MSIX-Apps eine weitere Kopie auf einer zusätzlichen Dateifreigabe in der anderen Region. Die virtuellen Computer in den einzelnen Regionen sollten die Cloudcacheregistrierung enthalten, um die Speicherorte anzugeben. Darüber hinaus müssen Sie die Gruppenrichtlinien so konfigurieren, dass dem lokalen Speicherort Vorrang gegeben wird. Diese Azure Virtual Desktop-Bereitstellung bietet aus Benutzersicht die höchste Effizienz. Dies liegt daran, dass Benutzer in der verbleibenden Region bei einem Ausfall den Dienst weiterhin verwenden können, ohne sich erneut anmelden zu müssen. Die Bereitstellung dieser Konfiguration ist jedoch teurer und komplexer und nicht auf Leistungsoptimierung ausgelegt.

• Aktiv/Passiv: Für eine Aktiv/Passiv-Konfiguration können Sie Azure Site Recovery verwenden, um Ihre VMs in der sekundären Region mit Ihren Domänencontrollern zu replizieren. Wenn Sie Azure Site Recovery verwenden, müssen Sie die virtuellen Computer nicht manuell registrieren. Stattdessen verwendet der Azure Virtual Desktop-Agent auf der sekundären VM automatisch das neueste Sicherheitstoken, um eine Verbindung mit der Dienstinstanz herzustellen, die sich am nächsten befindet. Dadurch wird sichergestellt, dass Ihr Sitzungshost automatisch dem Hostpool beitritt und der Benutzer nur wieder eine Verbindung herstellen muss, um auf seine VMs zuzugreifen. Für diese Konfiguration können Sie auch einen sekundären Hostpool (einen sog. Hot Standby) in der Failoverregion erstellen, in dem alle Ressourcen deaktiviert sind. Anschließend können Sie einen Wiederherstellungsplan in Azure Site Recovery verwenden, um Hostpools zu aktivieren und einen koordinierten Prozess zu erstellen. Außerdem müssen Sie eine neue Anwendungsgruppe in der Failoverregion erstellen und ihnen Benutzer zuweisen.

Virtuelle Netzwerke

Regionale Ausfälle wirken sich auf virtuelle Netzwerke und die Dienste aus, die in den virtuellen Netzwerken bereitgestellt werden. Sie müssen ein virtuelles Netzwerk in Ihrer sekundären Region vorsehen. Sie können ein virtuelles Netzwerk manuell erstellen und dann das Peering mit dem primären Netzwerk einrichten. Sie können auch Azure Site Recovery verwenden, um das virtuelle Netzwerk in der Failoverregion einzurichten, und die Einstellungen Ihres primären Netzwerks beibehalten.

In einer Azure Virtual Desktop-Instanz, die mit Ihrem lokalen Netzwerk verbunden ist, sollten Sie das virtuelle Netzwerk in der sekundären Region mit Konnektivität zu dem lokalen Netzwerk konfigurieren.

FSLogix-Profile und MSIX App Attach

Sie können Azure NetApp Files als Speicheroption für FSXlogix-Profile und MSIX App Attach verwenden, da sie die regionenübergreifende Replikation unterstützen. Azure Files mit Standardleistung unterstützt ebenfalls die regionenübergreifende Replikation. Sie können den FSLogix-Agent so konfigurieren, dass er mehrere Profilspeicherorte unterstützt. Dies trägt dazu bei, die Verfügbarkeit bei einem Ausfall sicherzustellen. Wenn der primäre Standort ausfällt, wird der FSLogix-Agent als Teil der Azure Site Recovery-VM repliziert. Der Agent versucht automatisch, den Profilpfad zu verwenden, der auf die sekundäre Region verweist.

Beim Aktiv/Aktiv-Szenario und wenn RTO oder RTA weniger als einen Tag betragen, empfiehlt es sich, FSLogix-Profile für die Verwendung von Cloud Cache zu nutzen. Cloud Cache ist ein Feature von FSLogix, das speziell aktiviert und konfiguriert werden muss. Sie können mehrere Remotestandorte verwenden, die alle während der Benutzersitzung kontinuierlich aktualisiert werden.

Bilder

Nach jeder Änderung des primären Desktopimages sollten Sie Images in der sekundären Region replizieren. Sie können eine Azure Compute Gallery verwenden, um benutzerdefinierte Images regionsübergreifend zu teilen. Bei einem Ausfall einer primären Region können Sie geklonte Desktopimages als Quellen für die Erstellung der Hostpools verwenden.

Anwendungsabhängigkeiten

Anwendungen, die von in der primären Region verfügbaren Ressourcen abhängig sind, benötigen die gleichen Ressourcen am sekundären Standort. Wenn einige Ihrer Anwendungen beispielsweise mit einem SQL-Back-End verbunden sind, das in einer Region bereitgestellt wird, stellen Sie sicher, dass Sie SQL am sekundären Standort replizieren. Für SQL Server auf virtuellen Azure-Computern können Sie Azure Site Recovery verwenden. Für die PaaS-Lösung (SQL as a Platform as a Service) können Sie aktive Georeplikation oder Autofailover-Gruppen verwenden. Sie sollten diese Ressourcen in den BCDR-Gesamtplan einschließen. Darüber hinaus sollten Sie einen Azure Site Recovery-Plan einbinden, der App-Abhängigkeiten im Schutzplan abbilden kann.