Ripristino di emergenza locale per AWS

L'utilizzo AWS come ambiente di disaster recovery (DR) offsite per carichi di lavoro locali è uno scenario ibrido comune. Definisci i tuoi obiettivi di disaster recovery, inclusi i tempi di ripristino e gli obiettivi dei punti di ripristino richiesti, prima di selezionare le tecnologie da utilizzare. Per facilitare questa definizione, puoi utilizzare la checklist del piano DR.

Sono disponibili diverse opzioni per aiutarti a configurare e fornire rapidamente un ambiente DR. AWS Assicurati di tenere conto di tutte le dipendenze del carico di lavoro e testa il piano e la soluzione di DR in modo accurato e regolare per verificarne l'integrità.

AWS consente AWS Elastic Disaster Recoverydi creare una replica completa dei server locali, inclusi il volume root e il sistema operativo, su. AWS Elastic Disaster Recovery replica continuamente le tue macchine in un'area di staging a basso costo nell'account AWS di destinazione e preferito. Regione AWS La replica a livello di blocco è una replica esatta dello storage dei server, inclusi il sistema operativo, la configurazione dello stato del sistema, i database, le applicazioni e i file. In caso di emergenza, puoi indicare a Elastic Disaster Recovery di avviare rapidamente migliaia di macchine nello stato di completo provisioning in pochi minuti.

Elastic Disaster Recovery utilizza un agente installato su ciascuno dei server locali. Gli agenti sincronizzano lo stato dei server locali con gli equivalenti Amazon EC2 a bassa potenza in esecuzione su. AWS Puoi anche automatizzare il processo di failover e failback del DR con Elastic Disaster Recovery. L'automazione del processo di failover e failback può aiutarti a raggiungere un obiettivo di tempo di ripristino (RTO) inferiore e più coerente.

1. Segnalazione dello stato del server di replica

2. Le risorse dell'area di staging vengono create e terminate automaticamente

3. Istanze di ripristino avviate con RTO in minuti e RPO in secondi

4. Replica continua a livello di blocco (compressa e crittografata)

È importante testare il processo di disaster recovery e verificare che l'ambiente di live staging non crei conflitti con l'ambiente locale. Ad esempio, verifica che le licenze appropriate siano disponibili e funzionanti nell'ambiente di disaster recovery locale, di staging e avviato. Verifica inoltre che tutti i processi di tipo worker che potrebbero eseguire il polling e recuperare il lavoro da un database centrale siano configurati in modo appropriato per evitare sovrapposizioni o conflitti. Nel processo di ripristino di emergenza, includi tutti i passaggi necessari da eseguire prima che le istanze del server di ripristino siano online. Includi anche i passaggi da eseguire dopo che le istanze del server di ripristino sono online e disponibili. È possibile utilizzare soluzioni come la soluzione AWS Elastic Disaster Recovery Plan Automation o un altro approccio per automatizzare i piani di disaster recovery.

È possibile utilizzare un gateway di volume Storage Gateway per fornire ai server locali volumi basati sul cloud. È inoltre possibile effettuare rapidamente il provisioning di questi volumi per l'uso con Amazon EC2 utilizzando le istantanee di Amazon EBS. In particolare, gli Stored Volume Gateway forniscono alle applicazioni locali un accesso a bassa latenza a interi set di dati. I Volume Gateway forniscono anche backup durevoli basati su snapshot che possono essere ripristinati per l'uso in locale o per l'uso con Amazon EC2. Puoi pianificare le point-in-time istantanee in base al Recovery Point Objective (RPO) per il tuo carico di lavoro.

Importante

I volumi Volume Gateway sono pensati per essere utilizzati come volumi di dati e non come volumi di avvio.

Puoi utilizzare un'Amazon Machine Image (AMI) di Amazon EC2 con una configurazione che corrisponde ai tuoi server locali e specifica i volumi di dati separatamente. Dopo aver configurato e testato l'AMI, esegui il provisioning delle istanze EC2 dall'AMI insieme ai volumi di dati basati sulle istantanee del gateway del volume. Questo approccio richiede un test approfondito dell'ambiente per verificare che l'istanza EC2 funzioni correttamente, in particolare per i carichi di lavoro Windows.