Notfallwiederherstellung für Azure Virtual Desktop

  • Artikel

Zum Schützen der Daten Ihrer Organisation sollten Sie eine Strategie für Geschäftskontinuität und Notfallwiederherstellung (Business Continuity and Disaster Recovery, BCDR) einführen und verwalten. Eine solide BCDR-Strategie sorgt dafür, dass Ihre Apps und Workloads während geplanter und ungeplanter Wartungen oder Azure-Ausfälle weiter in Betrieb bleiben. Diese Pläne sollten die kundenseitig verwalteten Sitzungshost-VMs abdecken – im Gegensatz zum Azure Virtual Desktop-Dienst, der von Microsoft verwaltet wird. Weitere Informationen zu Verwaltungsbereichen finden Sie unter Konzepte für die Azure Virtual Desktop-Notfallwiederherstellung.

Der Azure Virtual Desktop-Dienst wurde mit Blick auf Hochverfügbarkeit entwickelt. Azure Virtual Desktop ist ein globaler Dienst, der von Microsoft verwaltet wird. Dabei werden mehrere Instanzen seiner unabhängigen Komponenten auf mehrere Azure-Regionen verteilt. Wenn es einen unerwarteten Ausfall in einer der Komponenten gibt, wird Ihr Datenverkehr an eine der verbleibenden Instanzen umgeleitet, oder Microsoft leitet ein vollständiges Failover auf redundante Infrastruktur in einer anderen Azure-Region ein.

Um sicherzustellen, dass Benutzer während eines Regionsausfalls auf Sitzungshost-VMs weiterhin eine Verbindung herstellen können, müssen Sie Ihre Infrastruktur mit Hochverfügbarkeit und Notfallwiederherstellung entwerfen. Ein typischer Notfallwiederherstellungsplan umfasst das Replizieren von VMs an einen anderen Speicherort. Bei einem Ausfall erfolgt dann ein Failover vom primären Standort auf die replizierten VMs am sekundären Standort. Die Benutzer können ohne Unterbrechung weiterhin auf Apps am sekundären Standort zugreifen. Über die VM-Replikation hinaus müssen Sie den Zugriff auf die Benutzeridentitäten am sekundären Standort sicherstellen. Wenn Sie Profilcontainer verwenden, müssen diese ebenfalls repliziert werden. Stellen Sie schließlich sicher, dass Ihre Geschäftsanwendungen, die von Daten am primären Standort abhängig sind, einen Failover mit den restlichen Daten ausführen können.

Zusammenfassend lässt sich sagen, dass Sie die Verbindungen Ihrer Benutzer während eines Ausfalls nur dann sicherstellen können, wenn Sie die folgenden Aktionen ausführen:

  • Replizieren der VMs an einen sekundären Standort.
  • Wenn Sie Profilcontainer verwenden, richten Sie am zweiten Standort Datenreplikation ein.
  • Stellen Sie sicher, dass Benutzeridentitäten, die Sie am primären Standort einrichten, am sekundären Standort verfügbar sind. Um die Verfügbarkeit sicherzustellen, stellen Sie sicher, dass Ihre Active Directory-Domänencontroller am sekundären Standort für ein- und ausgehenden Datenverkehr verfügbar sind.
  • Sorgen Sie dafür, dass für alle Branchenanwendungen und Daten an Ihrem primären Standort ebenfalls ein Failover auf den sekundären Standort erfolgt.

Aktiv/Passiv- und Aktiv-Aktiv-Notfallwiederherstellungspläne

Es gibt zwei verschiedene Arten von Notfallwiederherstellungsinfrastruktur: Aktiv/Passiv und Aktiv/Aktiv. Jede Art von Infrastruktur funktioniert anders. Untersuchen wir, worin diese Unterschiede bestehen.

Aktiv/Passiv-Pläne sind Pläne, bei denen Sie eine Region mit einem Satz aktiver Ressourcen verwenden sowie eine Region, die deaktiviert ist, bis sie benötigt wird (passiv). Wenn die aktive Region durch einen Ausfall oder einen Notfall offline geht, kann in Organisation passive Region umgeschaltet werden, indem diese aktiviert wird und alle Benutzer dorthin umgeleitet werden.

Eine andere Option ist eine Aktiv/Aktiv-Bereitstellung, bei der Sie beide Infrastrukturgruppen gleichzeitig verwenden. Auch wenn einige Benutzer von den Ausfällen betroffen sind, beschränken sich die Auswirkungen auf Benutzer in der Region, die ausgefallen ist. Benutzer in der anderen Region, die weiterhin online ist, sind nicht betroffen, und die Wiederherstellung ist auf die Benutzer in der betroffenen Region beschränkt, die sich erneut mit der funktionierenden aktiven Region verbinden. Aktiv/Aktiv-Bereitstellungen können viele Formen annehmen, darunter:

  • Überbereitstellung der Infrastruktur in jeder Region, um die betroffenen Benutzer bei einem Ausfall in einer der Regionen aufzunehmen. Ein potenzieller Nachteil dieser Methode besteht darin, dass die zusätzlichen Ressourcen mehr kosten.
  • Verwenden zusätzlicher Sitzungshosts in beiden aktiven Regionen, deren Zuordnung aufgehoben wird, wenn sie nicht benötigt werden, wodurch die Kosten sinken.
  • Bereitstellen neuer Infrastrukturen nur während der Notfallwiederherstellung und Ermöglichen, dass die betroffenen Benutzer eine Verbindung mit den neu bereitgestellten Sitzungshosts herstellen. Diese Methode erfordert regelmäßige Tests mit Infrastructure-as-Code-Tools, damit Sie die neue Infrastruktur während eines Notfalls so schnell wie möglich bereitstellen können.

Weitere Informationen zu Arten von Notfallwiederherstellungsplänen, die Sie verwenden können, finden Sie unter Konzepte für die Azure Virtual Desktop-Notfallwiederherstellung.

Bevor Sie beginnen, sollten Sie zunächst herausfinden, welche Methode für Ihr Unternehmen am besten geeignet ist. Sobald Sie Ihren Plan festgelegt haben, können Sie ihren Wiederherstellungsplan erstellen.

VM-Replikation

Zunächst müssen Sie Ihre VMs an den sekundären Standort replizieren. Ihre Optionen dafür hängen von der Konfiguration Ihrer VMs ab:

  • Mit Azure Site Recovery können Sie für alle Ihre VMs sowohl für gepoolte als auch für persönliche Hostpools Replikation konfigurieren. Weitere Informationen zur Funktionsweise dieses Prozesses finden Sie unter Replizieren von Azure-VMs in eine andere Azure-Region. Wenn Sie jedoch über gepoolte Hostpools verfügen, die Sie aus demselben Image erstellt haben, und keine personenbezogenen Benutzerdaten lokal gespeichert sind, können Sie diese wahlweise nicht replizieren. Stattdessen haben Sie die Möglichkeit, die VMs im Voraus zu erstellen und zunächst deaktiviert zu lassen. Sie können auch wahlweise nur neue VMs in der sekundären Region bereitstellen, während ein Notfall auftritt. Bei diesen Methoden müssen Sie nur einen Hostpool und die ihm zugeordneten Anwendungsgruppen und Arbeitsbereiche einrichten.
  • Sie können einen neuen Hostpool in der Failoverregion einrichten, dabei aber zugleich alle Ressourcen an Ihrem Failoverstandort deaktiviert lassen. Bei dieser Methode müssen Sie neue Anwendungsgruppen und Arbeitsbereiche in der Failoverregion einrichten. Anschließend können Sie einen Azure Site Recovery-Plan zum Aktivieren von Hostpools verwenden.
  • Sie können einen Hostpool erstellen, der von erstellten VMs sowohl in der primären als auch der Failoverregion aufgefüllt wird, wobei die VMs in der Failoverregion deaktiviert bleiben. In diesem Fall müssen Sie nur einen Hostpool und die ihm zugeordneten Anwendungsgruppen und Arbeitsbereiche einrichten. Mit dieser Methode können Sie einen Azure Site Recovery-Plan verwenden, um die Hostpools einzuschalten.

Wir empfehlen die Verwendung von Azure Site Recovery zum Verwalten der Replikation von VMs an anderen Azure-Standorten, wie in Azure-zu-Azure-Notfallwiederherstellung beschrieben. Wir empfehlen die Verwendung von Azure Site Recovery insbesondere für persönliche Hostpools, da sie (wie ihr Name schon sagt) für ihre Benutzer etwas Persönliches haben. Azure Site Recovery unterstützt sowohl serverbasierte als auch clientbasierte SKUs.

Wenn Sie Azure Site Recovery verwenden, brauchen Sie diese VMs nicht manuell zu registrieren. Der Azure Virtual Desktop-Agent in der sekundären VM verwendet automatisch das neueste Sicherheitstoken, um eine Verbindung mit der nächstgelegenen Dienstinstanz herzustellen. Die VM (Sitzungshost) am sekundären Standort wird automatisch Teil des Hostpools. Der Endbenutzer muss während des Prozesses automatisch erneut eine Verbindung herstellen, abgesehen davon gibt es aber keine weiteren manuellen Vorgänge.

Wenn während des Ausfalls Benutzerverbindungen bestehen, müssen Sie die Benutzerverbindungen in der aktuellen Region beenden, bevor der Administrator ein Failover auf die sekundäre Region einleiten kann.

Führen Sie dieses Cmdlet aus, um die Benutzer in Azure Virtual Desktop (klassisch) zu trennen:

Invoke-RdsUserSessionLogoff

Führen Sie dieses Cmdlet aus, um die Benutzer in Azure Virtual Desktop zu trennen:

Remove-AzWvdUserSession

Nachdem Sie alle Benutzer in der primären Region abgemeldet haben, können Sie ein Failover der VMs in der primären Region ausführen und Benutzern die Möglichkeit geben, Verbindungen mit den VMs in der sekundären Region herzustellen.

Virtuelles Netzwerk

Betrachten Sie als nächsten Punkt Ihre Netzwerkkonnektivität während des Ausfalls. Sie müssen sicherstellen, dass Sie in Ihrer sekundären Region ein virtuelles Netzwerk (VNET) eingerichtet haben. Wenn Ihre Benutzer auf lokale Ressourcen zugreifen müssen, müssen Sie dieses VNET für diesen Zugriff konfigurieren. Sie können lokale Verbindungen mit einem VPN, ExpressRoute oder einem virtuellen WAN einrichten.

Wir empfehlen, zum Einrichten des VNETs in der Failoverregion Azure Site Recovery zu verwenden, da hierbei die Einstellungen Ihres primären Netzwerks erhalten bleiben und kein Peering erforderlich ist.

Benutzeridentitäten

Stellen Sie als nächstes sicher, dass der Domänencontroller am sekundären Standort verfügbar ist.

Die Verfügbarkeit des Domänencontrollers kann auf drei Wegen sichergestellt werden:

  • Verwenden mindestens eines Active Directory-Domänencontrollers am sekundären Standort
  • Es wird ein lokaler Active Directory-Domänencontroller verwendet
  • Der Active Directory-Domänencontroller wird mithilfe von Azure Site Recovery repliziert

Benutzerprofile

Es wird empfohlen, FSLogix für die Verwaltung von Benutzerprofilen zu verwenden. Weitere Informationen finden Sie unter Optionen für Geschäftskontinuität und Notfallwiederherstellung für FSLogix.

Sichern Ihrer Daten

Sie haben auch die Möglichkeit, Ihre Daten zu sichern. Sie können eine der folgenden Methoden auswählen, um Ihre Azure Virtual Desktop-Daten zu sichern:

App-Abhängigkeiten

Stellen Sie schließlich sicher, dass für alle Geschäftsanwendungen, die auf Daten aufbauen, die sich am primären Standort befinden, ein Failover zum sekundären Standort ausgeführt werden kann. Achten Sie ferner unbedingt darauf, die erforderlichen Einstellungen zu konfigurieren, damit die Apps am neuen Standort funktionieren können. Wenn beispielsweise eine der Apps vom SQL-Back-End abhängt, stellen Sie sicher, dass SQL am sekundären Standort repliziert wird. Sie sollten die App für die Verwendung des sekundären Standorts entweder als Teil des Failoverprozesses oder als Standardkonfiguration konfigurieren. Anwendungsabhängigkeiten können in Azure Site Recovery-Plänen modelliert werden. Weitere Informationen finden Sie unter Informationen zu Wiederherstellungsplänen.

Tests der Notfallwiederherstellung

Nachdem Sie das Einrichten der Notfallwiederherstellung abgeschlossen haben, ist es sinnvoll, Ihren Plan zu testen, um sicherzustellen, dass er funktioniert.

Hier finden Sie einige Vorschläge zum Testen Ihres Plans:

  • Wenn die Test-VMs über Internetzugang verfügen, übernehmen sie jeden vorhandenen Sitzungshost für neue Verbindungen, aber alle vorhandenen Verbindungen mit den ursprünglichen Sitzungshost bleiben aktiv. Achten Sie darauf, dass der Administrator, der den Test durchführt, alle aktiven Benutzer abmeldet, bevor er den Plan testet.
  • Tests der vollständigen Notfallwiederherstellung sollten nur während eines Wartungsfensters durchgeführt werden, um die Arbeit Ihrer Benutzer nicht zu unterbrechen.
  • Vergewissern Sie sich, dass Ihr Test alle geschäftskritischen Anwendungen und Daten abdeckt.
  • Es empfiehlt sich, in einen Failoverprozess nicht mehr als 100 VMs einzubeziehen. Wenn Sie eine größere Anzahl VMs betreiben, empfehlen wir den Failover in Batches im Abstand von 10 Minuten.

Nächste Schritte

Antworten auf Fragen zum Schutz Ihrer Daten über die Ausfallplanung hinaus finden Sie in unserem Sicherheitsleitfaden.