Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Notfallwiederherstellung
Amazon AppStream 2.0 verfügt über integrierte Redundanz in bis zu drei Availability Zones. Das heißt, wenn ein Benutzer eine aktive Sitzung in einer Availability Zone hat, die heruntergefahren ist, kann er einfach die Verbindung trennen und erneut verbinden, wodurch ihm eine Sitzung in einer fehlerfreien Availability Zone reserviert wird, vorausgesetzt, Sie haben Kapazität. Dadurch wird zwar eine hohe Verfügbarkeit innerhalb der Region gewährleistet, es ist jedoch keine Notfallwiederherstellungslösung, wenn der Service auf regionaler Ebene Probleme hat.
Um einen Notfallwiederherstellungsplan für Ihre WorkSpaces Anwendungsbenutzer bereitzustellen, müssen Sie zunächst eine WorkSpaces Anwendungsumgebung in Ihrer sekundären Region aufbauen. Aus Sicht des Designs sollte diese Umgebung gegebenenfalls redundante Verbindungen zu Ihrer lokalen Umgebung haben und nicht von der primären Region abhängig sein. Wenn Ihre WorkSpaces Anwendungsflotte beispielsweise zu einer Domäne gehört, sollten Sie zusätzliche Domänencontroller in der sekundären Region haben, für die Standorte und Dienste konfiguriert sind. Aus Sicht der WorkSpaces Anwendungen sollte diese Umgebung aus denselben Flotten- und Stack-Einstellungen bestehen wie in Ihrer primären Region. Auf der Flotte selbst sollte dasselbe Basis-Image ausgeführt werden, das über die Konsole oder programmgesteuert in Ihre sekundäre Region kopiert werden kann. Wenn die Anwendungen, die in Ihren WorkSpaces Anwendungssitzungen ausgeführt werden, eine Backend-Abhängigkeit haben, die an Ihre primäre Region gebunden ist, sollte auch diese über regionale Redundanz verfügen, um sicherzustellen, dass die Benutzer auch dann auf das Backend der Anwendung zugreifen können, wenn die primäre Region ausfällt. Ihre Service-Level-Grenzwerte in Ihrer Zielregion sollten mit Ihrer Hauptregion übereinstimmen.
Routing von Identitäten
Es gibt zwei unterschiedliche Methoden, um den Zugriff auf Anwendungen in einem DR-Szenario bereitzustellen. Im Großen und Ganzen unterscheiden sich die beiden Methoden darin, wie die Benutzer in die Failover-Region geleitet werden. Die erste Methode wird mit einer einzigen WorkSpaces Anwendungskonfiguration in Ihrem IdP ausgeführt, und die zweite Methode besteht aus zwei separaten Anwendungskonfigurationen.
Methode 1: Ändern des Relay-Status Ihrer Anwendung
Wenn sich Benutzer über einen Identitätsanbieter (IdP) bei WorkSpaces Anwendungen anmelden, werden sie nach ihrer Authentifizierung an eine bestimmte URL weitergeleitet, die der Region und dem Stack entspricht, auf die sie Zugriff haben sollen. Weitere Informationen zur Relay State-URL finden Sie im Amazon WorkSpaces Applications Administration Guide. Der Administrator kann einen regionsübergreifenden Stack konfigurieren, der auf demselben WorkSpaces Anwendungs-Image wie die primäre Region basiert und zu dem Benutzer ein Failover durchführen können. Der Administrator kann dieses Failover steuern, indem er einfach die Relay-State-URL so aktualisiert, dass sie auf den Failover-Stack verweist. Damit diese Methode ordnungsgemäß funktioniert, müssen die zugehörigen IAM-Richtlinien den Zugriff auf beide Stacks (primär und Failover) widerspiegeln. Weitere Informationen zur Konfiguration dieser IAM-Richtlinien finden Sie in der folgenden Beispielrichtlinie.
Methode 2: Konfiguration von zwei WorkSpaces Anwendungsanwendungen in Ihrem IdP
Bei dieser Methode muss der Administrator zwei separate Anwendungen für WorkSpaces Anwendungen innerhalb des IdP erstellen. Sie können dann entweder beide Anwendungen präsentieren und dem Benutzer die Wahl lassen, wohin er gehen soll, oder sie können lock/hide eine Anwendung erstellen, bis ein Failover erforderlich ist. Diese Methode eignet sich besser für den Anwendungsfall globaler Benutzer, die sich häufig bewegen. Diese Benutzer sollten vom nächstgelegenen Endpunkt aus streamen. Wenn ihnen also beide Anwendungen zugewiesen sind, haben sie die Möglichkeit, die Anwendung auszuwählen, die für ihre nächstgelegene Region konfiguriert ist. Dies kann auch automatisiert werden. Weitere Informationen finden Sie in diesem Blogbeitrag
Persistenz des Speichers
Wenn Sie die in WorkSpaces Anwendungen enthaltenen Datenpersistenzfunktionen wie Anwendungspersistenz und Home-Folder-Synchronisierung nutzen möchten, müssen Sie diese Daten in Ihre Failover-Region replizieren. Diese Funktionen speichern die persistenten Daten in einem Amazon S3 S3-Bucket in der angegebenen WorkSpaces Anwendungsregion. Damit die Daten regionsübergreifend bestehen bleiben, müssen Sie alle Änderungen im Quell-Bucket in den Anwendungs-Bucket der Failover-Region WorkSpaces replizieren. Dies kann mit systemeigenen Amazon S3 S3-Funktionen wie der regionsübergreifenden Amazon S3-Replikation geschehen. Die persistenten Daten jedes Benutzers werden in einem Ordner mit seinem Hash-Benutzernamen gespeichert. Da der Benutzername regionsübergreifend gleich gehasht wird, sorgt eine einfache Replikation der Daten für Datenpersistenz in Ihrer sekundären Region. Weitere Informationen zu den Amazon S3 S3-Buckets, die von WorkSpaces Applications verwendet werden, finden Sie in diesem Handbuch.
