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à | Descrizione | Competenze 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à | Descrizione | Competenze richieste |
---|---|---|
Crea il gruppo di disponibilità distribuita su AG 1. | Per creare il gruppo di disponibilità distribuita su AG 1, utilizzare l'
| DBA, Sviluppatore |
Crea il gruppo di disponibilità distribuita su AG 2. | Per creare il gruppo di disponibilità distribuita su AG 2, utilizzare
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' 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à | Descrizione | Competenze 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. 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à | Descrizione | Competenze 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à | Descrizione | Competenze 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:
| 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à | Descrizione | Competenze 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 |