Notfallwiederherstellung

Amazon AppStream 2.0 hat Redundanz für bis zu drei Availability Zones eingebaut. 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 AppStream 2.0-Benutzer bereitzustellen, müssen Sie zunächst eine AppStream 2.0-Umgebung 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 AppStream 2.0-Flotte beispielsweise in eine Domäne eingebunden ist, sollten Sie zusätzliche Domänencontroller in der sekundären Region haben, für die Standorte und Dienste konfiguriert sind. Aus Sicht der AppStream Version 2.0 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 AppStream 2.0-Sitzungen 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 AppStream 2.0-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 Identity Provider (IdP) bei AppStream 2.0 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 AppStream 2.0-Administrationshandbuch. Der Administrator kann einen regionsübergreifenden Stack konfigurieren, der auf demselben AppStream 2.0-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.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "appstream:Stream",
            "Resource": [
            "arn:aws:appstream:PrimaryRegion:190836837966:stack/StackName",
            "arn:aws:appstream:FailoverRegion:190836837966:stack/StackName"
            ],
            "Condition": {
                "StringEquals": {
                    "appstream:userId": "${saml:sub}"
                }
            }
        }
    ]
}

Methode 2: Konfiguration von zwei AppStream 2.0-Anwendungen in Ihrem IdP

Bei dieser Methode muss der Administrator zwei separate Anwendungen für AppStream 2.0 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 sperren/verstecken eine Anwendung, bis es Zeit für einen Failover 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 AppStream 2.0 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 AppStream 2.0-Region. Damit die Daten regionsübergreifend bestehen bleiben, müssen Sie alle Änderungen am Quell-Bucket in den Failover-Regions AppStream 2.0-Bucket 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 von AppStream 2.0 verwendeten Amazon S3 S3-Buckets finden Sie in diesem Handbuch.