View a markdown version of this page

Recuperación ante desastres - Mejores prácticas para implementar WorkSpaces aplicaciones de Amazon

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Recuperación ante desastres

Amazon AppStream 2.0 ha incorporado redundancia en hasta tres zonas de disponibilidad. Esto quiere decir que si un usuario tiene una sesión activa en una zona de disponibilidad que se reduce, puede simplemente desconectarse y volver a conectarse, y esto le reservará una sesión en una zona de disponibilidad en buen estado, siempre que disponga de capacidad. Si bien esto proporciona una alta disponibilidad en la región, no proporciona una solución de recuperación de desastres si el servicio tiene problemas a nivel regional.

Para ofrecer un plan de recuperación ante desastres a los usuarios de sus WorkSpaces aplicaciones, primero tendrá que crear un entorno de WorkSpaces aplicaciones en su región secundaria. Desde el punto de vista del diseño, este entorno debe tener conexiones redundantes con el entorno en las instalaciones, si procede, y no debe depender de la región principal. Por ejemplo, si su flota de WorkSpaces aplicaciones está unida a un dominio, debería tener controladores de dominio adicionales en la región secundaria con los sitios y los servicios configurados. Desde el punto de vista de WorkSpaces las aplicaciones, este entorno debe tener la misma configuración de flota y pila que tiene en su región principal. La propia flota debería ejecutar la misma imagen base, que se puede copiar a la región secundaria mediante la consola o mediante programación. Si las aplicaciones que se ejecutan en sus sesiones de WorkSpaces aplicaciones tienen una dependencia de backend vinculada a su región principal, esta también debería tener redundancia regional para garantizar que los usuarios puedan seguir accediendo al backend de la aplicación en caso de que la región principal deje de funcionar. Los límites de nivel de servicio en la región de destino deben coincidir con los de la región principal.

Enrutamiento de identidades

Existen dos métodos distintos para proporcionar acceso a las aplicaciones en un escenario de recuperación de desastres. En términos generales, los dos métodos difieren en la forma en que se dirige a los usuarios a la región de conmutación por error. El primer método se realiza con una única configuración de aplicación de WorkSpaces aplicaciones en su IdP y el segundo método consiste en tener dos configuraciones de aplicación independientes.

Método 1: cambiar el estado de retransmisión de la aplicación

Cuando los usuarios inician sesión en WorkSpaces las aplicaciones desde un proveedor de identidad (IdP), tras su autenticación, se les retransmite a una URL específica que se alinea con la región y la pila a las que están destinados a tener acceso. Para obtener más información sobre la URL del estado de retransmisión, consulte la Guía de administración de WorkSpaces aplicaciones de Amazon. El administrador puede configurar una pila multiregional basada en la misma imagen de WorkSpaces aplicaciones que la región principal para que los usuarios realicen la conmutación por error. El administrador puede controlar esta conmutación por error simplemente actualizando la URL del estado de retransmisión para que apunte a la pila de conmutación por error. Para que este método funcione correctamente, las políticas de IAM asociadas deberán reflejar el acceso a las dos pilas: la principal y la de conmutación por error. Para obtener más información sobre cómo se deben configurar estas políticas de IAM, consulte el siguiente ejemplo de política.

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

Método 2: configurar dos WorkSpaces aplicaciones (aplicaciones) dentro de su IdP

Este método requiere que el administrador cree dos aplicaciones independientes para las WorkSpaces aplicaciones dentro del IdP. A continuación, pueden presentar ambas aplicaciones y dejar que el usuario elija a dónde ir, o crear lock/hide una aplicación hasta que llegue el momento de realizar la conmutación por error. Este método se adapta mejor al caso de uso de usuarios de un perfil global que se desplazan con frecuencia. Estos usuarios deberían realizar la transmisión desde el punto de conexión más cercano, así que tener ambas aplicaciones asignadas les da la opción de elegir la aplicación que esté configurada para su región más cercana. Esto también se puede automatizar. Puede obtener más información al respecto en la siguiente entrada de blog.

Persistencia del almacenamiento

Si utiliza las funciones de persistencia de datos incluidas en WorkSpaces las aplicaciones, como la persistencia de aplicaciones y la sincronización de carpetas principales, tendrá que replicar esos datos en la región de conmutación por error. Estas funciones almacenan los datos persistentes en un bucket de Amazon S3 en la región de WorkSpaces aplicaciones determinada. Para que los datos persistan en todas las regiones, tendrá que replicar todos los cambios del bucket de origen en el bucket de WorkSpaces aplicaciones de la región de conmutación por error. Esto se puede hacer con las características nativas de Amazon S3, como la replicación entre regiones de Amazon S3. Los datos persistentes de cada usuario se almacenarán en una carpeta con su nombre de usuario codificado. Como el nombre de usuario se codificará en la misma región cruzada, con solo replicar los datos se obtendrá una persistencia de los datos en la región secundaria. Para obtener más información sobre los buckets de Amazon S3 que utilizan las WorkSpaces aplicaciones, consulte esta guía.