Opzioni e considerazioni sull'HA/DR

Sebbene la possibilità che una zona o una regione di AWS disponibilità vada completamente offline è estremamente rara, consigliamo un approccio su più fronti al backup e al ripristino in caso di emergenza per la ridondanza e per ridurre al minimo la perdita di dati. I processi di backup e ripristino devono includere il livello di granularità appropriato per soddisfare il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO) per il carico di lavoro e supportare i processi aziendali e spesso dipendono dall'applicazione. Nel caso dei database, supporta AWS anche tutti i consigli di Microsoft per l'installazione e la configurazione di SQL Server per l'alta disponibilità e il disaster recovery (HA/DR). Different editions of SQL Server support various HA/DR options, and you should consider special cases such as very large databases (VLDBs) on a case-by-case basis. As with any DR configuration, testing is essential to ensure that each application meets its service-level agreements (SLAs) for HA/DR. For your test/developmentambiente), prendi in considerazione l'utilizzo dell'edizione SQL Server Developer, che è gratuita ma presenta delle limitazioni.

Per un caso d'uso che richiede un RPO di 15 minuti e un RTO di 4 ore, è possibile prendere in considerazione una combinazione delle seguenti opzioni HA/DR:

• Opzioni HA/DR native di SQL Server con standby caldo (a livello di database): per illustrazioni di alcune di queste architetture, consulta la sezione più avanti in questa guida. Diagrammi di EC2 architettura SQL Server su Amazon

  • Multi-AZ a due nodi in una singola regione (modalità di commit sincrona) o in più regioni (modalità di commit asincrona, gruppo di disponibilità di base)

  • Multi-AZ a tre nodi (o più) in più regioni (modalità di commit sincrono e commit asincrono)

  • Spedizione a due nodi, Multi-AZ e dei log in più regioni (con backup dei log ogni 5 minuti)

• Backup nativi di SQL Server su Amazon S3 (a livello di database, solo DR): backup completi (una volta al giorno)

  • Backup differenziali (ogni 2-4 ore).

  • Backup dei log (ogni 5-10 minuti).

  • I backup devono essere eseguiti e copiati su Amazon Simple Storage Service (Amazon S3) utilizzando script personalizzati o un'opzione come File Gateway per backup e trasferimento efficienti.

  • Se disponi di centinaia di database, puoi continuare a utilizzare gli strumenti di backup esistenti (come Commvault o Litespeed) per gestire in modo efficiente i backup e archiviarli direttamente in Amazon S3.

  • Usa Amazon S3 Cross-Region Replication (CRR) con S3 Replication Time Control (RTC) per controllare e monitorare la replica degli oggetti entro uno SLA di 15 minuti.

  • Per garantire la conformità e ridurre i costi, puoi anche utilizzare S3 Lifecycle Management per spostare e archiviare i backup più vecchi per lo storage a lungo termine.

  • Se esegui backup nativi di SQL Server e li sposti regolarmente su Amazon S3, in caso di emergenza, i backup saranno immediatamente disponibili nella regione di destinazione. Ciò elimina la necessità di trasferire backup o ripristinare istantanee.

  • Si consiglia di utilizzare SQL Native Backup Compression per ridurre le dimensioni dei file.

• AWS istantanee (a livello di istanza e volume, solo DR)

  • Amazon Elastic Compute Cloud (Amazon EC2) Backup di Amazon Machine Image (AMI) per ricostruire database da zero

  • Istantanee del volume Amazon Elastic Block Store (Amazon EBS) per collegare volumi EBS ad Amazon EC2

Gestione delle risorse HA/DR in AWS Backup

AWS Backupè un servizio completamente gestito che offre la possibilità di creare piani e pianificazioni di backup e assegnare AWS le risorse coinvolte nella configurazione HA/DR, come i volumi Amazon EBS per creare istantanee e Amazon, a questi piani di backup. EC2 AMIs Puoi anche AWS Backup utilizzarlo per pianificare copie multiregionali di questi snapshot EBS. Per un utilizzo ottimale, è AWS Backup necessario un efficiente meccanismo di etichettatura delle risorse. AWS Backup supporta anche backup coerenti con le applicazioni tramite Windows Volume Shadow Copy Service (VSS), che è possibile utilizzare per SQL Server. Per una protezione a livello di storage, consigliamo di utilizzare le istantanee EBS. Le istantanee EBS iniziali sono complete e le istantanee successive sono incrementali. Sebbene le istantanee EBS offrano una protezione a livello di storage, non sostituiscono i backup nativi basati su file di SQL Server che offrono il ripristino. point-in-time

Utilizzo per HA/DR AWS DMS

Se stai cercando un'alternativa alle opzioni di replica di SQL Server Always On o se disponi di database di origine e di destinazione eterogenei, in una configurazione ibrida o in AWS, puoi utilizzare AWS Database Migration Service ()AWS DMS nei seguenti modi.

Se si utilizza AWS DMS SQL Server in un contesto autogestito (ospitato su Amazon EC2 o in locale), supporta la replica una tantum e continua in due modalità: utilizzando MS-REPLICATION (per acquisire le modifiche alle tabelle con chiavi primarie) e MS-CDC (per acquisire le modifiche alle tabelle che non dispongono di chiavi primarie). Tuttavia, se utilizzi Amazon Relational Database Service (Amazon RDS) come sorgente AWS DMS per, è supportato solo MS-CDC. AWS DMS offre una gamma di endpoint di origine e destinazione, supporta motori di database eterogenei e offre un controllo granulare sul processo di replica. È inoltre possibile utilizzare il () with per migrazioni di database eterogenei AWS Schema Conversion Tool .AWS SCT AWS DMS AWS SCT automatizza le modifiche a livello di schema e produce anche report sulla preparazione e la pianificazione della migrazione.

I database di origine e di destinazione vengono aggiunti come endpoint in AWS DMS, come illustrato nel diagramma seguente. Questo servizio implementa un processo di replica logica utilizzando MS-REPLICATION o MS-CDC. Se si dispone di una configurazione ibrida, è possibile configurare AWS DMS la replica continua tra sistemi locali e. AWS Durante il cutover, l'attività di AWS DMS migrazione può essere interrotta e l'applicazione sarà in grado di connettersi al database già sincronizzato con il database locale senza ulteriori ritardi. L'utilizzo AWS DMS di SQL Server come sorgente presenta alcune limitazioni, descritte nella documentazione.AWS DMS

Valuta la possibilità di utilizzare metodi HA/DR AWS DMS al posto dei metodi HA/DR nativi nei seguenti scenari:

• Quando vuoi risparmiare sui costi di licenza. Ad esempio, se utilizzi una versione avanzata come SQL Server Enterprise Edition solo per le opzioni Always On, potresti prendere in considerazione la possibilità di configurarla AWS DMS , poiché può fornire un'opzione di replica logica senza il costo di una licenza dell'edizione Enterprise.

• Quando si hanno fonti e destinazioni eterogenee. Non è necessario che le versioni di SQL Server sui nodi primari e di disaster recovery corrispondano (entro AWS DMS limiti), il che offre una flessibilità significativa.

• Per evitare il sovraccarico di Windows, il clustering di SQL Server e la configurazione e la gestione dei gruppi di disponibilità distribuita. AWS DMS offre una configurazione semplice e una facile gestione delle attività di replica.

• Per casi d'uso aziendali come il trasferimento quasi in tempo reale (a seconda dell'istanza di replica, della configurazione di rete e del volume dei dati), il mascheramento dei dati, il filtraggio selettivo, la mappatura di schema/tabelle (omogenea ed eterogenea), le valutazioni prima della migrazione e il supporto JSON.

• Per duplicare, interrompere e avviare facilmente le attività in base alle esigenze in base ai numeri di sequenza di log (), ai timestamp e a opzioni simili. LSNs

Il diagramma seguente mostra un approccio alternativo a come fornire supporto per la AWS DMS replica. In questa configurazione, l'origine è un cluster di gruppo di disponibilità Always On di SQL Server e AWS DMS utilizza l'opzione Change Data Capture (CDC) per replicare continuamente i dati su una destinazione in una regione diversa. AWS Per ottenere prestazioni ottimali, è fondamentale garantire che l'istanza di replica abbia le dimensioni corrette e rimanga nella regione di origine.

I motori di origine e di destinazione non devono necessariamente corrispondere. Nel diagramma, i nodi primari e secondari contrassegnati come (1) possono essere un cluster SQL Server in una configurazione Single-AZ o Multi-AZ. Oppure l'origine può essere un singolo nodo di SQL Server che supporta MS-CDC o MS-REPLICATION.

L'istanza DB di destinazione, contrassegnata come (2) nel diagramma, può essere qualsiasi versione di SQL Server su Amazon RDS EC2, Amazon o qualsiasi altra destinazione eterogenea. Non deve necessariamente corrispondere alle istanze primarie e secondarie o supportare i gruppi di disponibilità Always On. Ad esempio, l'origine può essere un cluster di gruppo di disponibilità SQL Server Always On e la destinazione può essere Amazon Aurora PostgreSQL Compatible Edition.

AWS Application Migration Service Utilizzo per DR

Si consiglia di utilizzare il AWS Application Migration Service per lift-and-shift le migrazioni verso. AWS Application Migration Service replica continuamente le macchine (inclusi il sistema operativo, la configurazione dello stato del sistema, i database, le applicazioni e i file) in un'area di gestione temporanea a basso costo nell' AWS account di destinazione e nella regione preferita. In caso di emergenza, puoi utilizzare Application Migration Service per avviare automaticamente migliaia di macchine nello stato di completo provisioning in pochi minuti.

Ulteriori considerazioni

L'elenco seguente identifica i possibili ostacoli da considerare quando si progetta una strategia HA/DR.

• Larghezza di banda, latenza, complessità della rete e connettività in una configurazione di nodi multiregione.

• Dimensioni degli EC2 snapshot di Amazon EBS o Amazon e tempo necessario per copiarli utilizzando. AWS Backup

  • Le EC2 istantanee di Amazon EBS e Amazon vengono archiviate in Amazon S3 utilizzando. AWS Backup

  • Uno snapshot EBS non viene replicato nella regione di destinazione in Amazon S3 fino al completamento dello snapshot corrente. La durata della replica dipende anche dalla dimensione del volume.

  • Una volta completata l'istantanea, il tempo necessario per copiare le istantanee può essere di soli 15 minuti per il 99,99% degli oggetti. Tuttavia, sono necessari test approfonditi per casi d'uso specifici e volumi critici di grandi dimensioni.

• Tempo necessario per ripristinare i volumi EBS nella zona e nella regione di disponibilità di destinazione.

• Tempo necessario per ripristinare EC2 le immagini Amazon nella zona e nella regione di disponibilità di destinazione.

• Se si crea da zero, è necessario del tempo per fornire l'infrastruttura per l' EC2immagine Amazon o ripristinare gli snapshot EBS nella zona di disponibilità e nella regione di destinazione.

• In caso di ripristino da zero, è necessario il tempo necessario per ripristinare i backup completi, differenziali e di log nativi di SQL Server nella zona di disponibilità e nella regione di destinazione.

• Applicazioni e dipendenze esterne che devono essere disponibili in tutte le regioni.

• Limitazioni sulle dimensioni dei file per i volumi e per il caricamento su Amazon S3.