Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Ripristino di emergenza
Amazon AppStream 2.0 ha una ridondanza integrata in un massimo di tre zone di disponibilità. Ciò significa che se un utente ha una sessione attiva in una zona di disponibilità che si deteriora, può semplicemente disconnettersi e riconnettersi, per riservargli una sessione in una zona di disponibilità integra, a patto che la capacità sia disponibile. Sebbene ciò offra un'elevata disponibilità all'interno della regione, non fornisce una soluzione di disaster recovery se il servizio presenta problemi a livello regionale.
Per fornire un piano di disaster recovery per gli utenti WorkSpaces delle applicazioni, è innanzitutto necessario creare un ambiente WorkSpaces applicativo nella regione secondaria. Dal punto di vista della progettazione, questo ambiente dovrebbe avere connessioni ridondanti all'ambiente locale, se applicabile, e non dovrebbe dipendere dalla regione principale. Ad esempio, se il parco WorkSpaces applicazioni è aggiunto a un dominio, è necessario disporre di controller di dominio aggiuntivi nella regione secondaria con siti e servizi configurati. Dal punto di vista WorkSpaces delle applicazioni, questo ambiente dovrebbe includere le stesse impostazioni di flotta e stack presenti nella regione principale. La flotta stessa dovrebbe eseguire la stessa immagine di base, che può essere copiata nella regione secondaria tramite la console o a livello di programmazione. Se le applicazioni eseguite all'interno delle sessioni WorkSpaces Applicazioni hanno una dipendenza dal backend legata alla regione principale, anche questa dovrebbe avere una ridondanza regionale per garantire che gli utenti possano continuare ad accedere al backend dell'applicazione se la regione principale non funziona. I limiti del livello di servizio nella regione di destinazione devono corrispondere alla regione principale.
Routing delle identità
Esistono due metodi distinti per fornire l'accesso alle applicazioni in uno scenario di DR. Ad un livello elevato, i due metodi differiscono in base al modo in cui gli utenti vengono indirizzati alla regione di failover. Il primo metodo viene eseguito con una singola configurazione dell'applicazione WorkSpaces Applicazioni nell'IdP e il secondo metodo prevede due configurazioni dell'applicazione separate.
Metodo 1: modifica dello stato di inoltro dell'applicazione
Quando gli utenti accedono alle WorkSpaces applicazioni da un provider di identità (IdP), dopo l'autenticazione vengono inoltrati a un URL specifico che si allinea alla regione e allo stack a cui devono avere accesso. Per ulteriori informazioni sull'URL Relay State, consulta la Amazon WorkSpaces Applications Administration Guide. L'amministratore può configurare uno stack interregionale basato sulla stessa immagine WorkSpaces Applications della regione principale su cui gli utenti possano effettuare il failover. L'amministratore può controllare questo failover semplicemente aggiornando l'URL Relay State in modo che punti allo stack di failover. Affinché questo metodo funzioni correttamente, le policy IAM associate dovranno riflettere l'accesso a entrambi gli stack, primario e di failover. Per maggiori dettagli su come devono essere configurate queste policy IAM, consulta la seguente policy di esempio.
Metodo 2: configurazione di due WorkSpaces applicazioni all'interno del tuo IdP
Questo metodo richiede all'amministratore di creare due applicazioni separate per le WorkSpaces applicazioni all'interno dell'IdP. Possono quindi presentare entrambe le applicazioni e consentire all'utente di scegliere dove andare, oppure utilizzare l'applicazione fino al momento del failover. lock/hide Questo metodo è più adatto al caso d'uso in cui gli utenti globali si spostano spesso. Questi utenti devono eseguire lo streaming dall'endpoint più vicino, pertanto l'assegnazione di entrambe le applicazioni offre loro la possibilità di scegliere l'applicazione configurata per la regione più vicina. Questa operazione può anche essere automatizzata, per maggiori informazioni consulta questo post del blog
Persistenza dello storage
Quando si sfruttano le funzionalità di persistenza dei dati incluse WorkSpaces nelle applicazioni, come Application Persistence e Home Folder Synchronization, è necessario replicare tali dati nella regione di failover. Queste funzionalità archiviano i dati persistenti in un bucket Amazon S3 nella regione Applicazioni specificata WorkSpaces . Per far sì che i dati persistano in tutte le regioni, sarà necessario replicare tutte le modifiche sul bucket di origine nel bucket Applications delle regioni di failover. WorkSpaces Questa operazione può essere eseguita con funzionalità native di Amazon S3, come la replica interregionale di Amazon S3. I dati persistenti di ogni utente risiederanno in una cartella contenente il suo nome utente con hash. Poiché al nome utente verrà applicato l'hash nella stessa area geografica, la semplice replica dei dati garantirà la persistenza dei dati nella regione secondaria. Per ulteriori informazioni sui bucket Amazon S3 utilizzati dalle WorkSpaces applicazioni, consulta questa guida.
