Recuperação de desastres

O Amazon AppStream 2.0 tem redundância integrada em até três zonas de disponibilidade. Ou seja, se um usuário tiver uma sessão ativa em uma zona de disponibilidade que se torna degradada, é possível se desconectar e reconectar, o que reservará uma sessão em uma zona de disponibilidade saudável, supondo que você tenha capacidade. Embora isso forneça alta disponibilidade na região, não fornece uma solução de recuperação de desastres se o serviço tiver problemas em nível regional.

Para fornecer um plano de recuperação de desastres aos usuários do AppStream 2.0, primeiro será necessário criar um ambiente do AppStream 2.0 na região secundária. Do ponto de vista do design, esse ambiente deve ter conexões redundantes com o ambiente local, se aplicável, e não deve depender da região primária. Por exemplo, se a frota do AppStream 2.0 estiver associada a um domínio, você deverá ter controladores de domínio adicionais na região secundária com sites e serviços configurados. Do ponto de vista do AppStream 2.0, esse ambiente deve consistir nas mesmas configurações de frota e pilha da região principal. A frota em si deve executar a mesma imagem base, que pode ser copiada para a região secundária por meio do console ou programaticamente. Se os aplicativos executados em suas sessões do AppStream 2.0 tiverem uma dependência de back-end vinculada à região principal, ela também deverá ter redundância regional, garantindo que os usuários ainda possam acessar o back-end do aplicativo se a região principal ficar inativa. Os limites de nível de serviço na região de destino devem corresponder à região principal.

Roteamento de identidade

Há dois métodos distintos para fornecer acesso a aplicativos em um cenário de DR. Em um alto nível, os dois métodos diferem na forma como os usuários são direcionados para a região de failover. O primeiro método é executado com uma única configuração do aplicativo do AppStream 2.0 no IdP e o segundo método é ter duas configurações de aplicativo separadas.

Método 1: como alterar o estado de retransmissão do aplicativo

Quando os usuários entram no AppStream 2.0 a partir de um provedor de identidades (IdP), após a autenticação, eles são retransmitidos para um URL específico que se alinha à região e à pilha que devem acessar. Para obter mais informações sobre o URL do estado de retransmissão, consulte o Guia de administração do Amazon AppStream 2.0. O administrador pode configurar uma pilha entre regiões criada na mesma imagem do AppStream 2.0 da região principal para a qual os usuários podem fazer o failover. O administrador pode controlar esse failover ao atualizar o URL do estado de retransmissão a fim de apontar para a pilha de failover. Para que esse método funcione adequadamente, as políticas associadas do IAM precisarão refletir o acesso às duas pilhas: primária e de failover. Para obter mais detalhes sobre como essas políticas do IAM devem ser configuradas, consulte o exemplo de política a seguir.

{
    "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étodo 2: como configurar dois aplicativos do AppStream 2.0 no IdP

Esse método exige que o administrador crie dois aplicativos separados para o AppStream 2.0 dentro do IdP. Em seguida, eles podem apresentar os dois aplicativos e permitir que o usuário escolha para onde ir, ou bloquear/ocultar um aplicativo até o momento do failover. Esse método está melhor alinhado ao caso de uso de usuários globais que se movimentam com frequência. Esses usuários devem estar transmitindo do endpoint mais próximo. Portanto, ter os dois aplicativos atribuídos dá a eles a opção de escolher o aplicativo que está configurado para a região mais próxima. Isso também pode ser automatizado. Para obter mais informações, consulte esta publicação do blog.

Persistência de armazenamento

Ao aproveitar os recursos de persistência de dados incluídos no AppStream 2.0, como persistência de aplicativos e sincronização de pastas base, você precisará replicar esses dados para sua região de failover. Esses recursos armazenam os dados persistentes em um bucket do Amazon S3 na região específica do AppStream 2.0. Para que os dados persistam entre regiões, você precisará replicar todas as alterações no bucket de origem para o bucket do AppStream 2.0 da região de failover. Isso pode ser feito com recursos nativos do Amazon S3, como a replicação entre regiões do Amazon S3. Os dados persistentes de cada usuário residirão em uma pasta com seu nome de usuário com hash. Como o nome de usuário será codificado na mesma região cruzada, a simples replicação dos dados fornecerá persistência de dados na região secundária. Para obter mais informações sobre os buckets do Amazon S3 usados pelo AppStream 2.0, consulte este guia.