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à.
Opzioni di disaster recovery nel cloud
Le strategie di disaster recovery disponibili in AWS possono essere ampiamente suddivise in quattro approcci, che vanno dal basso costo e dalla bassa complessità dei backup a strategie più complesse che utilizzano più regioni attive. Le strategie attive/passive utilizzano un sito attivo (come una regione AWS) per ospitare il carico di lavoro e servire il traffico. Il sito passivo (ad esempio un'altra regione AWS) viene utilizzato per il ripristino. Il sito passivo non serve attivamente il traffico fino a quando non viene attivato un evento di failover.
È fondamentale valutare e testare regolarmente la strategia di disaster recovery in modo da poterla utilizzare con fiducia, se necessario. Usa AWS Resilience Hub

Figura 6 - Strategie di disaster recovery
Per un evento di emergenza basato sull'interruzione o la perdita di un data center fisico per un carico di lavoro ben progettato
Quando scegli la tua strategia e le risorse AWS per implementarla, tieni presente che all'interno di AWS, di solito dividiamo i servizi in piano dati e piano di controllo. Il piano dati è responsabile della fornitura del servizio in tempo reale mentre i piani di controllo (control-plane) consentono di configurare l'ambiente. Per la massima resilienza, è necessario utilizzare solo le operazioni del piano dati come parte delle operazioni di failover. Questo perché i piani dati in genere hanno obiettivi di progettazione di disponibilità più elevati rispetto ai piani di controllo.
Backup e ripristino
Il backup e il ripristino sono un approccio adatto per mitigare la perdita o il danneggiamento dei dati. Questo approccio può essere utilizzato anche per mitigare un disastro regionale replicando i dati in altre regioni AWS o per mitigare la mancanza di ridondanza per i carichi di lavoro distribuiti in una singola zona di disponibilità. Oltre ai dati, è necessario ridistribuire l'infrastruttura, la configurazione e il codice dell'applicazione nella regione di ripristino. Per consentire una ridistribuzione rapida dell'infrastruttura senza errori, è consigliabile eseguire sempre la distribuzione utilizzando l'infrastruttura come codice (IaC) utilizzando servizi come o il. AWS CloudFormationAWS Cloud Development Kit (AWS CDK)

Figura 7 - Architettura di backup e ripristino
Servizi AWS
I dati del carico di lavoro richiederanno una strategia di backup che venga eseguita periodicamente o sia continua. La frequenza con cui esegui il backup determinerà il punto di ripristino raggiungibile (che deve essere allineato per soddisfare l'RPO). Il backup dovrebbe inoltre offrire un modo per ripristinarlo al momento in cui è stato eseguito. Il backup con point-in-time ripristino è disponibile tramite i seguenti servizi e risorse:
-
Backup Amazon EFS (se utilizzato AWS Backup)
-
Amazon FSx per Windows File Server, Amazon FSx for Lustre, Amazon FSx per NetApp ONTAP e Amazon FSx per OpenZFS
Per Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3), puoi utilizzare Amazon S3 Cross-Region Replication (CRR) per copiare in modo asincrono oggetti su un bucket S3 nella regione
AWS Backup
-
EC2Istanze Amazon
-
Database Amazon Relational Database Service (Amazon RDS
) (inclusi i database Amazon Aurora ) -
File system Amazon Elastic File System (Amazon EFS)
-
Volumi AWS Storage Gateway
-
Amazon FSx per Windows File Server, Amazon FSx for Lustre, Amazon FSx per NetApp ONTAP e Amazon FSx per OpenZFS
AWS Backup supporta la copia di backup tra regioni, ad esempio in una regione di disaster recovery.
Come strategia di disaster recovery aggiuntiva per i tuoi dati Amazon S3, abilita il controllo delle versioni degli oggetti S3. Il controllo delle versioni degli oggetti protegge i dati in S3 dalle conseguenze delle azioni di eliminazione o modifica conservando la versione originale prima dell'azione. Il controllo delle versioni degli oggetti può essere un'utile mitigazione per i disastri di tipo umano. Se utilizzi la replica S3 per eseguire il backup dei dati nella tua regione DR, per impostazione predefinita, quando un oggetto viene eliminato nel bucket di origine, Amazon S3 aggiunge un marker di eliminazione solo nel bucket di origine. Questo approccio protegge i dati nella regione DR da eliminazioni dannose nella regione di origine.
Oltre ai dati, è necessario eseguire il backup della configurazione e dell'infrastruttura necessarie per ridistribuire il carico di lavoro e raggiungere il Recovery Time Objective (RTO). AWS CloudFormation
Tutti i dati archiviati nella regione di disaster recovery come backup devono essere ripristinati al momento del failover. AWS Backup offre funzionalità di ripristino, ma attualmente non abilita il ripristino programmato o automatico. Puoi implementare il ripristino automatico nella regione DR utilizzando l'SDK AWS da APIs richiedere AWS Backup. Puoi impostarlo come un processo ricorrente regolarmente o attivare il ripristino ogni volta che viene completato un backup. La figura seguente mostra un esempio di ripristino automatico utilizzando Amazon Simple Notification Service (Amazon AWS Lambda

Figura 8 - Ripristino e test dei backup
Nota
La tua strategia di backup deve includere il test dei backup. Per ulteriori informazioni, consulta la sezione Testing Disaster Recovery. Fai riferimento a AWS Well-Architected Lab: Testing Backup and Restore of
Pilot light
Con l'approccio pilot light, puoi replicare i dati da una regione all'altra e fornire una copia dell'infrastruttura di carico di lavoro principale. Le risorse necessarie per supportare la replica dei dati e il backup, come database e archiviazione di oggetti, sono sempre attive. Altri elementi, come i server delle applicazioni, vengono caricati con il codice e le configurazioni dell'applicazione, ma sono «disattivati» e vengono utilizzati solo durante i test o quando viene richiamato il failover del disaster recovery. Nel cloud, hai la flessibilità di eseguire il deprovisioning delle risorse quando non ne hai bisogno e il provisioning quando ne hai bisogno. Una procedura consigliata per «disattivarla» consiste nel non distribuire la risorsa e quindi creare la configurazione e le funzionalità necessarie per distribuirla («accenderla») quando necessario. A differenza dell'approccio di backup e ripristino, l'infrastruttura principale è sempre disponibile e si ha sempre la possibilità di fornire rapidamente un ambiente di produzione su vasta scala attivando e scalando i server delle applicazioni.

Figura 9 - Architettura dell'illuminazione pilota
Un approccio pilota leggero riduce al minimo i costi correnti del disaster recovery riducendo al minimo le risorse attive e semplifica il ripristino al momento del disastro perché i requisiti dell'infrastruttura di base sono tutti soddisfatti. Questa opzione di ripristino richiede la modifica dell'approccio di implementazione. È necessario apportare modifiche all'infrastruttura di base in ciascuna regione e implementare le modifiche del carico di lavoro (configurazione, codice) contemporaneamente in ciascuna regione. Questo passaggio può essere semplificato automatizzando le implementazioni e utilizzando l'infrastruttura come codice (IaC) per distribuire l'infrastruttura su più account e regioni (implementazione completa dell'infrastruttura nella regione principale e implementazione dell'infrastruttura ridimensionata/disattivata nelle regioni DR). Si consiglia di utilizzare un account diverso per regione per fornire il massimo livello di isolamento delle risorse e della sicurezza (nel caso in cui anche le credenziali compromesse rientrino nei piani di disaster recovery).
Con questo approccio, è inoltre necessario mitigare un problema di dati. La replica continua dei dati ti protegge da alcuni tipi di emergenza, ma potrebbe non proteggerti dal danneggiamento o dalla distruzione dei dati, a meno che la tua strategia non includa anche il controllo delle versioni dei dati archiviati o opzioni di ripristino. point-in-time È possibile eseguire il backup dei dati replicati nella regione di emergenza per creare point-in-time backup nella stessa regione.
Servizi AWS
Oltre a utilizzare i servizi AWS descritti nella sezione Backup and Restore per creare point-in-time backup, prendi in considerazione anche i seguenti servizi per la tua strategia pilota.
Per una fase pilota, la replica continua dei dati su database e archivi di dati attivi nella regione DR è l'approccio migliore per un RPO basso (se utilizzato in aggiunta ai point-in-time backup discussi in precedenza). AWS fornisce una replica dei dati continua, interregionale e asincrona utilizzando i seguenti servizi e risorse:
Con la replica continua, le versioni dei dati sono disponibili quasi immediatamente nella regione DR. I tempi di replica effettivi possono essere monitorati utilizzando funzionalità di servizio come S3 Replication Time Control (S3 RTC) per oggetti S3 e funzionalità di gestione dei database globali Amazon Aurora.
Quando si esegue il failover per eseguire il carico di lavoro di lettura/scrittura dalla regione di disaster recovery, è necessario promuovere una replica di lettura RDS per farla diventare l'istanza principale. Per le istanze DB diverse da Aurora, il completamento del processo richiede alcuni minuti e il riavvio fa parte del processo. Per la replica tra regioni (CRR) e il failover con RDS, l'utilizzo del database globale Amazon Aurora offre diversi vantaggi. Il database globale utilizza un'infrastruttura dedicata che lascia i database completamente disponibili per servire la tua applicazione e può replicarsi nella regione secondaria con una latenza tipica inferiore a un secondo (e all'interno di una regione AWS è molto inferiore a 100 millisecondi). Con il database globale di Amazon Aurora, se la tua regione principale subisce un peggioramento delle prestazioni o un'interruzione delle prestazioni, puoi promuovere una delle regioni secondarie affinché si assuma responsabilità di lettura/scrittura in meno di un minuto, anche in caso di interruzione totale a livello regionale. Puoi anche configurare Aurora per monitorare il tempo di ritardo dell'RPO di tutti i cluster secondari per assicurarti che almeno un cluster secondario rimanga all'interno della finestra RPO di destinazione.
È necessario implementare una versione ridotta dell'infrastruttura di carico di lavoro principale con un numero inferiore o inferiore di risorse nella regione DR. Utilizzando AWS CloudFormation, puoi definire la tua infrastruttura e distribuirla in modo coerente tra gli account AWS e tra le regioni AWS. AWS CloudFormation utilizza pseudo parametri predefiniti per identificare l'account AWS e la regione AWS in cui viene distribuito. Pertanto, puoi implementare la logica delle condizioni nei tuoi CloudFormation modelli per distribuire solo la versione ridotta dell'infrastruttura nella regione DR. Ad EC2 esempio, le implementazioni, un'Amazon Machine Image (AMI) fornisce informazioni come la configurazione hardware e il software installato. È possibile implementare una pipeline Image Builder che crei ciò di cui AMIs si ha bisogno e copiarla sia nella regione principale che in quella di backup. Questo aiuta a garantire che queste Golden AMIs abbiano tutto il necessario per ridistribuire o scalare il carico di lavoro in una nuova regione, in caso di emergenza. Le EC2 istanze Amazon vengono distribuite in una configurazione ridotta (meno istanze rispetto alla regione principale). Per scalare l'infrastruttura in modo da supportare il traffico di produzione, consulta Amazon Auto EC2 Scaling nella sezione Warm Standby.
Per una configurazione attiva/passiva come Pilot Light, tutto il traffico viene inizialmente indirizzato alla regione principale e passa alla regione di disaster recovery se la regione primaria non è più disponibile. Questa operazione di failover può essere avviata automaticamente o manualmente. Il failover avviato automaticamente sulla base di controlli o allarmi di stato deve essere usato con cautela. Anche utilizzando le migliori pratiche illustrate qui, i tempi di ripristino e il punto di ripristino saranno superiori a zero, con una certa perdita di disponibilità e di dati. Se si esegue il failover quando non è necessario (falso allarme), si subiscono tali perdite. Pertanto si usa spesso il failover avviato manualmente. In questo caso, devi comunque automatizzare i passaggi del failover, in modo che l'avvio manuale si limiti al clic su un pulsante.
Esistono diverse opzioni di gestione del traffico da considerare quando si utilizzano AWS i servizi.
Tra le opzioni, vi è l'utilizzo di Amazon Route 53
Un'altra opzione è quella di utilizzare AWS Global Accelerator
Amazon CloudFront
AWS Disaster Recovery elastico
AWS Elastic Disaster Recovery

Figura 10 - Architettura AWS elastica di disaster recovery
Warm standby
L'approccio warm standby implica la verifica della presenza di una copia ridotta verticalmente, ma comunque funzionale, dell'ambiente di produzione in un'altra regione. Questo approccio estende il concetto di Pilot Light e diminuisce il tempo di ripristino, poiché il carico di lavoro è sempre attivo in un'altra regione. Questo approccio consente inoltre di eseguire più facilmente i test o di implementare test continui per aumentare la fiducia nella capacità di ripristino in caso di emergenza.

Figura 11 - Architettura Warm Standby
Nota: la differenza tra luce pilota e standby caldo a volte può essere difficile da capire. Entrambi includono un ambiente nella regione DR con copie delle risorse principali della regione. La differenza è che Pilot Light non può elaborare le richieste senza prima intraprendere un'azione aggiuntiva, mentre lo standby caldo può gestire immediatamente il traffico (a livelli di capacità ridotti). L'approccio pilot light richiede di «accendere» i server, possibilmente implementare un'infrastruttura aggiuntiva (non core) e scalare, mentre lo standby caldo richiede solo la scalabilità (tutto è già installato e funzionante). Utilizzate le vostre esigenze RTO e RPO per aiutarvi a scegliere tra questi approcci.
Servizi AWS
Tutti i servizi AWS coperti da backup e ripristino e pilot light vengono utilizzati anche in modalità warm standby per il backup dei dati, la replica dei dati, il routing del traffico attivo/passivo e l'implementazione dell'infrastruttura, comprese le istanze. EC2
Amazon EC2 Auto Scaling viene utilizzato per scalare
Poiché l'Auto Scaling è un'attività del piano di controllo, dipendere da essa ridurrà la resilienza della strategia di ripristino complessiva. È un compromesso. È possibile scegliere di fornire una capacità sufficiente in modo che la regione di ripristino sia in grado di gestire l'intero carico di produzione man mano che viene distribuito. Questa configurazione staticamente stabile è denominata hot standby (vedere la sezione successiva). Oppure puoi scegliere di fornire meno risorse, il che costerà meno, ma affidandoti all'Auto Scaling. Alcune implementazioni di DR impiegheranno risorse sufficienti per gestire il traffico iniziale, garantendo un RTO basso, e quindi si affideranno all'Auto Scaling per aumentare il traffico successivo.
Attivo/attivo multi-sito
È possibile eseguire il carico di lavoro contemporaneamente in più regioni come parte di una strategia attiva/passiva multisito o attiva/passiva in standby a caldo. Multisito. active/active serves traffic from all regions to which it is deployed, whereas hot standby serves traffic only from a single region, and the other Region(s) are only used for disaster recovery. With a multi-site active/active approach, users are able to access your workload in any of the Regions in which it is deployed. This approach is the most complex and costly approach to disaster recovery, but it can reduce your recovery time to near zero for most disasters with the correct technology choices and implementation (however data corruption may need to rely on backups, which usually results in a non-zero recovery point). Hot standby uses an active/passive configuration where users are only directed to a single region and DR regions do not take traffic. Most customers find that if they are going to stand up a full environment in the second Region, it makes sense to use it active/active In alternativa, se non desideri utilizzare entrambe le regioni per gestire il traffico degli utenti, Warm Standby offre un approccio più economico e meno complesso dal punto di vista operativo.

Figura 12 - Architettura attiva/attiva multisito (modifica di un percorso attivo in Inattivo per hot standby)
Con un approccio multisito active/active, because the workload is running in more than one Region, there is no such thing as failover in this scenario. Disaster recovery testing in this case would focus on how the workload reacts to loss of a Region: Is traffic routed away from the failed Region? Can the other Region(s) handle all the traffic? Testing for a data disaster is also required. Backup and recovery are still required and should be tested regularly. It should also be noted that recovery times for a data disaster involving data corruption, deletion, or obfuscation will always be greater than zero and the recovery point will always be at some point before the disaster was discovered. If the additional complexity and cost of a multi-site active/active (o hot standby) è necessario mantenere tempi di ripristino vicini allo zero, quindi è necessario compiere ulteriori sforzi per mantenere la sicurezza e prevenire gli errori umani per mitigare i disastri umani.
Servizi AWS
Tutti i servizi AWS coperti da backup e ripristino, pilot light e warm standby vengono utilizzati anche qui per il backup point-in-time dei dati, la replica dei dati, il routing del traffico attivo/attivo e l'implementazione e la scalabilità dell'infrastruttura, comprese le istanze. EC2
Per gli scenari attivi/passivi discussi in precedenza (Pilot Light e Warm Standby), è AWS Global Accelerator possibile utilizzare sia Amazon Route 53 che per instradare il traffico di rete verso la regione attiva. Per quanto riguarda la strategia attiva/attiva in questo caso, entrambi questi servizi consentono anche la definizione di politiche che determinano quali utenti accedono a quale endpoint regionale attivo. Con AWS Global Accelerator you è possibile impostare una ghiera di controllo del traffico per controllare la percentuale di traffico indirizzata a ciascun endpoint dell'applicazione. Amazon Route 53 supporta questo approccio percentuale e anche molte altre policy disponibili, tra cui quelle basate sulla geoprossimità e sulla latenza. Global Accelerator sfrutta automaticamente l'ampia rete di server edge AWS per effettuare l'onboard del traffico verso la dorsale della rete AWS il prima possibile, con conseguente riduzione delle latenze di richiesta.
La replica asincrona dei dati con questa strategia consente un RPO vicino allo zero. I servizi AWS come il database globale di Amazon Aurora utilizzano un'infrastruttura dedicata che lascia i database completamente disponibili per servire la tua applicazione e possono essere replicati in un massimo di cinque regioni secondarie con una latenza tipica inferiore a un secondo. Sta progettando active/passive strategies, writes occur only to the primary Region. The difference with active/active il modo in cui viene gestita la coerenza dei dati con le scritture su ciascuna regione attiva. È comune progettare le letture degli utenti in modo che vengano servite dalla regione a loro più vicina, nota come read local. Con le scritture, hai diverse opzioni:
-
Una strategia globale di scrittura indirizza tutte le scritture verso una singola regione. In caso di fallimento di quella regione, un'altra regione verrebbe promossa ad accettare le scritture. Il database globale Aurora è ideale per la scrittura globale, in quanto supporta la sincronizzazione con le repliche di lettura e scrittura tra le regioni ed è possibile promuovere una delle regioni secondarie affinché si assuma responsabilità di lettura/scrittura in meno di un minuto. Aurora supporta anche l'inoltro di scrittura, che consente ai cluster secondari di un database globale Aurora di inoltrare istruzioni SQL che eseguono operazioni di scrittura al cluster primario.
-
Una strategia locale di scrittura indirizza la scrittura nella regione più vicina (proprio come le letture). Le tabelle globali di Amazon DynamoDB abilitano tale strategia, permettendo la lettura e la scrittura da ogni regione in cui viene distribuita la tabella globale. Le tabelle globali di Amazon DynamoDB utilizzano un last writer per la riconciliazione tra aggiornamenti simultanei.
-
Una strategia di scrittura partizionata assegna le scritture a una regione specifica in base a una chiave di partizione (come l'ID utente) per evitare conflitti di scrittura. In questo caso è possibile utilizzare la replica di Amazon S3 configurata in modo bidirezionale
e attualmente supporta la replica tra due regioni. Quando implementi questo approccio, assicurati di abilitare la sincronizzazione delle modifiche alla replica su entrambi i bucket A e B per replicare le modifiche ai metadati di replica come le liste di controllo degli accessi agli oggetti (ACLs), i tag degli oggetti o i blocchi degli oggetti sugli oggetti replicati. È inoltre possibile configurare se replicare o meno i marker di eliminazione tra i bucket nelle regioni attive. Oltre alla replica, la strategia deve includere anche i point-in-time backup per la protezione da eventi di danneggiamento o distruzione dei dati.
AWS CloudFormation è uno strumento potente per applicare un'infrastruttura distribuita in modo coerente tra gli account AWS in più regioni AWS. AWS CloudFormation StackSetsestende questa funzionalità consentendoti di creare, aggiornare o eliminare CloudFormation stack su più account e regioni con un'unica operazione. Sebbene AWS CloudFormation utilizzi YAML o JSON per definire l'infrastruttura come codice, AWS Cloud Development Kit (AWS CDK)