As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Recuperação de desastres
A 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 para seus usuários de WorkSpaces aplicativos, primeiro você precisará criar um ambiente de WorkSpaces aplicativos em sua 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 sua frota de WorkSpaces aplicativos 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 dos WorkSpaces aplicativos, esse ambiente deve consistir nas mesmas configurações de frota e pilha que você tem na sua 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 de WorkSpaces aplicativos tiverem uma dependência de back-end vinculada à sua região principal, ela também deverá ter redundância regional para garantir 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 de aplicativo de WorkSpaces aplicativos em seu 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 fazem login nos WorkSpaces aplicativos a partir de um provedor de identidade (IdP), após a autenticação, eles são retransmitidos para uma URL específica que se alinha à região e à pilha à qual eles deveriam ter acesso. Para obter mais informações sobre a URL do estado de retransmissão, consulte o Amazon WorkSpaces Applications Administration Guide. O administrador pode configurar uma pilha entre regiões baseada na mesma imagem de WorkSpaces aplicativos da região primária 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.
Método 2: Configurando dois WorkSpaces aplicativos em seu IdP
Esse método exige que o administrador crie dois aplicativos separados para WorkSpaces aplicativos dentro do IdP. Em seguida, eles podem apresentar os dois aplicativos e permitir que o usuário escolha para onde ir, ou usar lock/hide um aplicativo até a hora 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 nos WorkSpaces aplicativos, como persistência de aplicativos e sincronização de pastas pessoais, 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 de WorkSpaces aplicativos específica. Para que os dados persistam entre regiões, você precisará replicar todas as alterações no bucket de origem para o bucket de aplicativos da região WorkSpaces 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 pelos WorkSpaces aplicativos, consulte este guia.
