Siti DR e strategie DR di Amazon RDS comuni - AWS Guida prescrittiva

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à.

Siti DR e strategie DR di Amazon RDS comuni

Un sito di disaster recovery (DR) è una posizione secondaria utilizzata da un'organizzazione per ripristinare l'infrastruttura e le applicazioni IT critiche per l'azienda quando un sito primario è stato colpito da un disastro. I siti di DR sono spesso costruiti in una posizione remota per garantire che il disastro che colpisce il sito principale non influisca anche sul sito secondario. I siti di DR disponibili all'interno dell'utente AWS possono essere generalmente classificati come DR vicini e remoti:

  • Il Near DR viene spesso definito come disaster recovery interno all'area geografica. La soluzione DR è configurata tra le zone di disponibilità per proteggere il sistema in caso di interruzione della zona di disponibilità o manutenzione pianificata.

  • Far DR viene spesso definito disaster recovery interregionale. La soluzione è configurata Regioni AWS per proteggere il sistema da interruzioni a livello regionale o per eseguire passaggi pianificati per soddisfare le politiche di conformità.

DR sincrono

Nel DR sincrono, i dati vengono replicati sul sito DR contemporaneamente alla creazione o all'aggiornamento di nuovi dati sul sito primario. Per ottenere una soluzione DR sincrona per i database dell'edizione standard, è possibile utilizzare l'implementazione Multi-AZ.

L'implementazione Multi-AZ (near DR) è una soluzione AWS gestita Near-DR che fornisce la replica sincrona del database RDS su un'istanza di standby in una zona di disponibilità diversa all'interno della stessa regione. Se il database primario non è disponibile a causa di un'interruzione a livello di zona di disponibilità, promuove AWS automaticamente il database in standby al ruolo principale. Ciò garantisce una perdita di dati e tempi di inattività minimi. Tuttavia, è importante notare che l'implementazione Multi-AZ non protegge dalle interruzioni a livello regionale. Inoltre, non fornisce alcuna funzionalità di DR al di fuori di. Cloud AWS

Opzioni di DR asincrono

Nel DR asincrono, la replica non viene eseguita contemporaneamente alle modifiche apportate al sistema primario. I dati vengono replicati solo agli intervalli definiti dall'obiettivo del punto di ripristino. Per implementare una soluzione DR asincrona, è possibile utilizzare le seguenti opzioni:

  • Istantanee automatizzate gestite tramite AWS Backup : AWS Backup è un servizio di backup completamente gestito che automatizza il backup e il ripristino del database Amazon RDS in base alle impostazioni di point-in-time ripristino (PITR). Con AWS Backup, puoi scattare istantanee, creare pianificazioni di backup, politiche di conservazione e piani di backup per proteggere i dati da cancellazioni accidentali, danneggiamento o guasti hardware. È possibile ripristinare il database su una nuova istanza RDS nella stessa regione Regione AWS o in un'altra.

    AWS Backup è un'opzione di DR attiva-passiva perché è necessario avviare manualmente il processo di ripristino in caso di errore del database primario. È possibile utilizzarla AWS Backup in combinazione con un'implementazione Multi-AZ, combinando soluzioni sincrone e asincrone per fornire un ulteriore livello di protezione contro la perdita di dati.

  • Replica degli snapshot Amazon RDS PITR: gli snapshot RDS sono un'opzione di disaster recovery manuale. Definisci una configurazione di point-in-time snapshot per la tua istanza di database RDS e le istantanee vengono archiviate in Amazon Simple Storage Service (Amazon S3). È quindi possibile abilitare la replica tra regioni per replicare le modifiche dal database primario al database di standby in una regione diversa.

    La replica degli snapshot di Amazon RDS PITR è un'opzione di DR attiva-passiva, poiché è necessario avviare manualmente il processo di ripristino e promuovere il database in standby al ruolo principale in caso di guasto del database primario originale. Tuttavia, questa opzione offre maggiore flessibilità rispetto alla distribuzione Multi-AZ e può essere utilizzata per proteggersi da interruzioni a livello regionale.