Reprise après sinistre

Amazon AppStream 2.0 a intégré la redondance dans un maximum de trois zones de disponibilité. Cela signifie que si un utilisateur dispose d'une session active dans une zone de disponibilité dégradée, il peut simplement se déconnecter et se reconnecter, ce qui lui réservera une session dans une zone de disponibilité saine en supposant que vous en ayez la capacité. Bien que cela assure une haute disponibilité au sein de la région, cela ne constitue pas une solution de reprise après sinistre si le service rencontre des problèmes au niveau régional.

Pour fournir un plan de reprise après sinistre à vos utilisateurs AppStream 2.0, vous devez d'abord créer un environnement AppStream 2.0 dans votre région secondaire. Du point de vue de la conception, cet environnement doit disposer de connexions redondantes avec votre environnement sur site, le cas échéant, et ne doit pas dépendre de la région principale. Par exemple, si votre flotte AppStream 2.0 est jointe à un domaine, vous devriez avoir des contrôleurs de domaine supplémentaires dans la région secondaire avec des sites et des services configurés. Dans une perspective AppStream 2.0, cet environnement doit comporter les mêmes paramètres de flotte et de stack que ceux que vous avez dans votre région principale. La flotte elle-même doit exécuter votre même image de base, qui peut être copiée dans votre région secondaire via la console ou par programmation. Si les applications qui s'exécutent dans le cadre de vos sessions AppStream 2.0 dépendent du backend de votre région principale, celle-ci doit également bénéficier d'une redondance régionale afin de garantir que les utilisateurs puissent toujours accéder au backend de l'application en cas de panne de la région principale. Vos limites de niveau de service dans votre région de destination doivent correspondre à celles de votre région principale.

Routage des identités

Il existe deux méthodes distinctes pour fournir l'accès aux applications dans un scénario de reprise après sinistre. À un niveau élevé, les deux méthodes diffèrent selon la manière dont les utilisateurs sont dirigés vers la région de basculement. La première méthode est exécutée avec une seule configuration d'application AppStream 2.0 dans votre IdP et la seconde consiste à avoir deux configurations d'application distinctes.

Méthode 1 : modification de l'état du relais de votre application

Lorsque les utilisateurs se connectent à la AppStream version 2.0 à partir d'un fournisseur d'identité (IdP), après leur authentification, ils sont redirigés vers une URL spécifique qui correspond à la région et à la pile auxquelles ils sont censés avoir accès. Pour plus d'informations sur l'URL de l'état du relais, consultez le guide d'administration Amazon AppStream 2.0. L'administrateur peut configurer une pile interrégionale basée sur la même image AppStream 2.0 que la région principale vers laquelle les utilisateurs peuvent basculer. L'administrateur peut contrôler ce basculement en mettant simplement à jour l'URL de l'état du relais pour qu'elle pointe vers la pile de basculement. Pour que cette méthode fonctionne correctement, les politiques IAM associées devront refléter l'accès aux deux piles : primaire et basculement. Pour plus de détails sur la manière dont ces politiques IAM doivent être configurées, consultez l'exemple de stratégie suivant.

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

Méthode 2 : Configuration de deux applications AppStream 2.0 au sein de votre IdP

Cette méthode oblige l'administrateur à créer deux applications distinctes pour la AppStream version 2.0 au sein de l'IdP. Ils peuvent ensuite soit présenter les deux applications et laisser l'utilisateur choisir où aller, soit verrouiller/masquer une application jusqu'au moment du basculement. Cette méthode est mieux adaptée au cas d'utilisation consistant à avoir des utilisateurs internationaux qui se déplacent souvent. Ces utilisateurs doivent diffuser depuis le point de terminaison le plus proche. Le fait d'avoir les deux applications assignées leur donne la possibilité de choisir l'application configurée pour la région la plus proche. Cela peut également être automatisé. Pour plus d'informations, consultez ce billet de blog.

Persistance du stockage

Lorsque vous utilisez les fonctionnalités de persistance des données incluses dans la AppStream version 2.0, telles que la persistance des applications et la synchronisation du dossier de base, vous devez répliquer ces données dans votre zone de basculement. Ces fonctionnalités stockent les données persistantes dans un compartiment Amazon S3 dans la région AppStream 2.0 donnée. Pour que les données soient conservées d'une région à l'autre, vous devez répliquer toutes les modifications apportées au compartiment source vers le compartiment failover regions AppStream 2.0. Cela peut être fait avec les fonctionnalités natives d'Amazon S3, telles que la réplication entre régions d'Amazon S3. Les données persistantes de chaque utilisateur résideront dans un dossier contenant son nom d'utilisateur haché. Étant donné que le nom d'utilisateur sera haché dans la même région, le simple fait de répliquer les données assurera la persistance des données dans votre région secondaire. Pour plus d'informations sur les compartiments Amazon S3 utilisés par la AppStream version 2.0, consultez ce guide.