Esegui la migrazione di SQL Server su AWS utilizzando gruppi di disponibilità distribuiti - Prontuario AWS

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

Esegui la migrazione di SQL Server su AWS utilizzando gruppi di disponibilità distribuiti

Creato da Praveen Marthala (AWS)

Fonte: SQL Server locale

Destinazione: SQL Server su EC2

Tipo R: Rehost

Ambiente: PoC o pilota

Tecnologie: database; migrazione

Carico di lavoro: Microsoft

Servizi AWS: Amazon EC2

Riepilogo

I gruppi di disponibilità Always On di Microsoft SQL Server forniscono una soluzione ad alta disponibilità (HA) e disaster recovery (DR) per SQL Server. Un gruppo di disponibilità è costituito da una replica primaria che accetta traffico di lettura/scrittura e fino a otto repliche secondarie che accettano traffico di lettura. Un gruppo di disponibilità è configurato su un Windows Server Failover Cluster (WSFC) con due o più nodi.

I gruppi di disponibilità distribuita Microsoft SQL Server Always On forniscono una soluzione per configurare due gruppi di disponibilità separati tra due WFSC indipendenti. I gruppi di disponibilità che fanno parte del gruppo di disponibilità distribuita non devono necessariamente trovarsi nello stesso data center. Un gruppo di disponibilità può essere locale e l'altro gruppo di disponibilità può trovarsi nelle istanze Amazon Web Services (AWS) Cloud on Amazon Elastic Compute Cloud (Amazon EC2) in un dominio diverso. 

Questo modello descrive i passaggi per l'utilizzo di un gruppo di disponibilità distribuito per migrare i database SQL Server locali che fanno parte di un gruppo di disponibilità esistente verso SQL Server con gruppi di disponibilità configurati su Amazon EC2. Seguendo questo schema, puoi migrare i database sul cloud AWS con tempi di inattività minimi durante il cutover. I database sono altamente disponibili su AWS subito dopo il cutover. Puoi anche utilizzare questo modello per modificare il sistema operativo sottostante da locale ad AWS mantenendo la stessa versione di SQL Server.

Prerequisiti e limitazioni

Prerequisiti

  • Un account AWS attivo

  • AWS Direct Connect o VPN da sito a sito AWS

  • La stessa versione di SQL Server installata in locale e sui due nodi di AWS

Versioni del prodotto

  • SQL Server versione 2016 e successive

  • SQL Server Enterprise Edition

Architettura

Stack tecnologico di origine

  • Database Microsoft SQL Server con gruppi di disponibilità Always On locali

Stack tecnologico Target

  • Database Microsoft SQL Server con gruppi di disponibilità Always On su Amazon EC2 sul cloud AWS

Architettura di migrazione

Terminologia

  • WSFC 1 — WSFC locale

  • WSFC 2 — WSFC sul cloud AWS

  • AG 1 — Primo gruppo di disponibilità, che si trova in WSFC 1

  • AG 2 — Secondo gruppo di disponibilità, che si trova nel WSFC 2

  • Replica primaria di SQL Server: nodo in AG 1 considerato il principale globale per tutte le scritture

  • SQL Server forwarder: nodo in AG 2 che riceve i dati in modo asincrono dalla replica primaria di SQL Server

  • Replica secondaria di SQL Server: nodi in AG 1 o AG 2 che ricevono dati in modo sincrono dalla replica primaria o dal server d'inoltro

Strumenti

  • AWS Direct Connect: AWS Direct Connect collega la rete interna a una posizione AWS Direct Connect tramite un cavo Ethernet standard in fibra ottica. Con questa connessione, puoi creare interfacce virtuali direttamente ai servizi AWS pubblici, aggirando i provider di servizi Internet nel tuo percorso di rete.

  • Amazon EC2 — Amazon Elastic Compute Cloud (Amazon EC2) Elastic Compute Cloud (Amazon EC2) fornisce capacità di calcolo scalabile nel cloud AWS. Puoi usare Amazon EC2 per lanciare tutti o pochi server virtuali di cui hai bisogno e puoi scalare orizzontalmente o orizzontalmente.

  • VPN da sito a sito AWS: la VPN da sito a sito di AWS supporta la creazione di una rete privata virtuale (VPN). site-to-site Puoi configurare la VPN per far passare il traffico tra le istanze che avvii su AWS e la tua rete remota.

  • Microsoft SQL Server Management Studio — Microsoft SQL Server Management Studio (SSMS) è un ambiente integrato per la gestione dell'infrastruttura SQL Server. Fornisce un'interfaccia utente e un gruppo di strumenti con editor di script avanzati che interagiscono con SQL Server.

Epiche

AttivitàDescrizioneCompetenze richieste
Crea un WSFC su AWS.

Crea WSFC 2 su istanze Amazon EC2 con due nodi per HA. Utilizzerai questo cluster di failover per creare il secondo gruppo di disponibilità (AG 2) su AWS.

Amministratore di sistema, SysOps amministratore
Creare il secondo gruppo di disponibilità su WSFC 2.

Utilizzando SSMS, crea AG 2 su due nodi in WSFC 2. Il primo nodo in WSFC 2 fungerà da server d'inoltro. Il secondo nodo di WSFC 2 fungerà da replica secondaria di AG 2.

In questa fase, nessun database è disponibile in AG 2. Questo è il punto di partenza per configurare il gruppo di disponibilità distribuita.

DBA, Sviluppatore
Crea database senza opzioni di ripristino su AG 2.

Esegui il backup dei database nel gruppo di disponibilità locale (AG 1). 

Ripristina i database sia sul server d'inoltro che sulla replica secondaria di AG 2 senza alcuna opzione di ripristino. Durante il ripristino dei database, specificate una posizione con spazio su disco sufficiente per i file di dati del database e i file di registro.

In questa fase, i database sono in fase di ripristino. Non fanno parte di AG 2 o del gruppo di disponibilità distribuita e non si sincronizzano.

DBA, Sviluppatore
AttivitàDescrizioneCompetenze richieste
Crea il gruppo di disponibilità distribuita su AG 1.

Per creare il gruppo di disponibilità distribuita su AG 1, utilizzare l'DISTRIBUTEDopzione CREATE AVAILABILITY GROUP with.

  1. Utilizza gli indirizzi degli LISTENER_URL endpoint per AG 1 e AG 2.

  2. AVAILABILITY-MODEUtilizzatelo infatti ASYNCHRONOUS_COMMIT per evitare l'eventuale latenza di rete. Ciò non influirà sulle prestazioni del database.

  3. Per FAILOVER_MODE, utilizza MANUAL. È l'unica modalità di disponibilità che funziona con i gruppi di disponibilità distribuiti.

  4. Per ripristinare manualmente i database su AG 2 e avere un maggiore controllo su database più grandi, usa MANUAL forSEEDING_MODE.

DBA, Sviluppatore
Crea il gruppo di disponibilità distribuita su AG 2.

Per creare il gruppo di disponibilità distribuita su AG 2, utilizzare ALTER AVAILABILITY GROUP con l'DISTRIBUTEDopzione.

  1. Utilizza gli indirizzi degli LISTENER_URL endpoint per AG 1 e AG 2.

  2. AVAILABILITY-MODEUtilizzatelo infatti ASYNCHRONOUS_COMMIT per evitare l'eventuale latenza di rete. Ciò non influirà sulle prestazioni del database.

  3. Per FAILOVER_MODE, utilizza MANUAL. È l'unica modalità di disponibilità che funziona con i gruppi di disponibilità distribuiti.

  4. Per ripristinare manualmente i database su AG 2 e avere un maggiore controllo su database più grandi, usa MANUAL forSEEDING_MODE.

Il gruppo di disponibilità distribuito viene creato tra AG 1 e AG 2.

I database di AG 2 non sono ancora configurati per partecipare al flusso di dati da AG 1 a AG 2.

DBA, Sviluppatore
Aggiungi database al server d'inoltro e alla replica secondaria su AG 2.

Aggiungi i database al gruppo di disponibilità distribuito utilizzando l'ALTER DATABASESET HADRAVAILABILITY GROUPopzione sia nel server d'inoltro che nella replica secondaria su AG 2. 

Ciò avvia il flusso di dati asincrono tra i database su AG 1 e AG 2. 

Il primario globale esegue le scritture, invia i dati in modo sincrono alla replica secondaria su AG 1 e invia i dati in modo asincrono al server d'inoltro su AG 2. Lo spedizioniere su AG 2 invia i dati in modo sincrono alla replica secondaria su AG 2.

DBA, Sviluppatore
AttivitàDescrizioneCompetenze richieste
Utilizza DMV e registri di SQL Server.

Monitora lo stato del flusso di dati tra due gruppi di disponibilità utilizzando viste di gestione dinamiche (DMV) e log di SQL Server. 

I DMV interessanti per il monitoraggio includono e. sys.dm_hadr_availability_replica_states sys.dm_hadr_automatic_seeding

Per lo stato della sincronizzazione del server d'inoltro, monitorate lo stato sincronizzato nel registro di SQL Server sul server d'inoltro.

DBA, Sviluppatore
AttivitàDescrizioneCompetenze richieste
Interrompi tutto il traffico verso la replica principale.

Blocca il traffico in entrata verso la replica principale in AG 1 in modo che non si verifichi alcuna attività di scrittura sui database e che i database siano pronti per la migrazione.

Proprietario dell'app, sviluppatore
Modifica la modalità di disponibilità del gruppo di disponibilità distribuita su AG 1.

Nella replica principale, imposta la modalità di disponibilità del gruppo di disponibilità distribuita su sincrona. 

Dopo aver modificato la modalità di disponibilità in sincrona, i dati vengono inviati in modo sincrono dalla replica primaria in AG 1 al server d'inoltro in AG 2.

DBA, Sviluppatore
Controlla i LSN in entrambi i gruppi di disponibilità.

Controlla gli ultimi Log Sequence Numbers (LSN) sia in AG 1 che in AG 2. Poiché non viene eseguita alcuna scrittura nella replica primaria in AG 1, i dati vengono sincronizzati e gli ultimi LSN per entrambi i gruppi di disponibilità devono corrispondere.

DBA, Sviluppatore
Aggiorna AG 1 al ruolo secondario.

Quando aggiorni AG 1 al ruolo secondario, AG 1 perde il ruolo di replica principale e non accetta scritture e il flusso di dati tra due gruppi di disponibilità si interrompe.

DBA, Sviluppatore
AttivitàDescrizioneCompetenze richieste
Failover manuale su AG 2.

Sul forwarder di AG 2, modificate il gruppo di disponibilità distribuita per consentire la perdita dei dati. Poiché avete già verificato e confermato che gli ultimi LSN su AG 1 e AG 2 coincidono, la perdita di dati non è un problema.

Quando si consente la perdita di dati sullo spedizioniere in AG 2, i ruoli di AG 1 e AG 2 cambiano:

  • AG 2 diventa il gruppo di disponibilità con la replica principale e la replica secondaria.

  • AG 1 diventa il gruppo di disponibilità con lo spedizioniere e la replica secondaria.

DBA, Sviluppatore
Modifica la modalità di disponibilità del gruppo di disponibilità distribuita su AG 2.

Sulla replica principale in AG 2, modifica la modalità di disponibilità in asincrona.

Ciò modifica lo spostamento dei dati da AG 2 a AG 1, da sincrono a asincrono. Questo passaggio è necessario per evitare l'eventuale latenza di rete tra AG 2 e AG 1 e non influirà sulle prestazioni del database.

DBA, Sviluppatore
Inizia a inviare traffico alla nuova replica primaria.

Aggiorna la stringa di connessione per utilizzare l'endpoint URL del listener su AG 2 per inviare traffico ai database.

AG 2 ora accetta scritture e invia dati allo spedizioniere in AG 1, oltre all'invio di dati alla propria replica secondaria in AG 2. I dati vengono trasferiti in modo asincrono da AG 2 a AG 1.

Proprietario dell'app, sviluppatore
AttivitàDescrizioneCompetenze richieste
Elimina il gruppo di disponibilità distribuita su AG 2.

Monitora la migrazione per il periodo di tempo pianificato. Quindi rilascia il gruppo di disponibilità distribuita su AG 2 per rimuovere la configurazione del gruppo di disponibilità distribuita tra AG 2 e AG 1. Ciò rimuove la configurazione del gruppo di disponibilità distribuito e il flusso di dati da AG 2 a AG 1 si interrompe. 

A questo punto, AG 2 è altamente disponibile su AWS, con una replica primaria che esegue scritture e una replica secondaria nello stesso gruppo di disponibilità.

DBA, Sviluppatore
Disattiva i server locali.

Disattiva i server locali in WSFC 1 che fanno parte di AG 1.

Amministratore di sistema, amministratore SysOps

Risorse correlate