灾难恢复 - 部署 Amazon AppStream 2.0 的最佳实践

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

灾难恢复

Amazon AppStream 2.0 内置了跨多达三个可用区的冗余。这意味着,如果用户在已降级的可用区中有一个活动会话,他们只需断开连接并重新连接即可,就能在一个正常的可用区内保留会话,前提是您有足够的容量。虽然这在区域内提供了高可用性,但如果服务在区域层面遇到问题,则无法提供灾难恢复解决方案。

要为您的 AppStream 2.0 用户提供灾难恢复计划,您首先需要在辅助区域构建一个 AppStream 2.0 环境。从设计角度来看,此环境应与您的本地环境建立冗余连接(如果适用),并且不应依赖主区域。例如,如果您的 AppStream 2.0 实例集已加入域,则您应该在辅助区域中部署其他域控制器,并配置站点和服务。从 AppStream 2.0 的角度来看,此环境应包含与主区域相同的实例集和堆栈设置。实例集本身应运行相同的基础映像,该映像可以通过控制台或以编程方式复制到您的辅助区域。如果在 AppStream 2.0 会话中运行的应用程序与您的主区域有后端依赖关系,则也应具有区域冗余,以确保用户仍然可以在主区域出现故障时访问应用程序的后端。您在目标区域的服务级别限制应与您的主区域相匹配。

身份路由

在灾难恢复场景中,有两种不同的方法可以实现对应用程序的访问。总体而言,这两种方法的不同之处在于如何将用户定向到失效转移区域。第一种方法是在 IdP 中使用单个 AppStream 2.0 应用程序配置执行的,第二种方法是使用两个单独的应用程序配置。

方法 1:更改应用程序的中继状态

当用户从身份提供商 (IdP) 登录到 AppStream 2.0 时,在进行身份验证后,他们会被中继到一个特定 URL,该 URL 与他们打算访问的区域和堆栈相一致。有关中继状态 URL 的更多信息,请参阅 Amazon AppStream 2.0 管理指南。管理员可以基于与主区域相同的 AppStream 2.0 映像配置一个跨区域堆栈,供用户进行失效转移。管理员只需更新中继状态 URL,使其指向失效转移堆栈,即可控制此失效转移。要使此方法正常运行,需要让关联的 IAM 策略允许访问两个堆栈(主堆栈和失效转移堆栈)。有关如何配置这些 IAM 策略的更多详细信息,请参阅以下示例策略。

{ "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}" } } } ] }

方法 2:在 IdP 中配置两个 AppStream 2.0 应用程序

此方法要求管理员在 IdP 中为 AppStream 2.0 构建两个单独的应用程序。然后,他们可以同时展示两个应用程序并让用户选择去哪里,也可以锁定/隐藏应用程序,直到需要进行失效切换。这种方法更适合让全球用户经常四处走动的使用案例。这些用户应该从最近的端点进行流式传输,因此,分配两个应用程序可以让他们选择为最近的区域配置的应用程序。这也可以自动完成,有关更多信息,请参阅此博客文章

存储持久性

在利用 AppStream 2.0 中包含的数据持久性特征(例如应用程序持久性主文件夹同步)时,您需要将这些数据复制到失效转移区域。这些特征可将持久性数据存储在给定 AppStream 2.0 区域的 Amazon S3 存储桶中。要跨区域持久保存数据,您需要将源存储桶上的所有更改复制到失效转移区域 AppStream 2.0 存储桶。这可以通过原生 Amazon S3 特征来完成,例如 Amazon S3 跨区域复制。每个用户的持久性数据将存储在经过哈希处理的用户名的文件夹下。由于用户名将统一跨区域进行哈希处理,因此只需复制数据即可确保数据在辅助区域中持久保存。有关 AppStream 2.0 使用的 Amazon S3 存储桶的更多信息,请参阅本指南