Migrazione di Microsoft SQL Server da AWS a Google Cloud

Last reviewed 2023-05-05 UTC

Questo documento mostra come eseguire la migrazione di un'istanza Microsoft SQL Server installata su Amazon Elastic Compute Cloud (Amazon EC2) a un'istanza di Microsoft SQL Server su Compute Engine in Google Cloud. Questa migrazione si basa esclusivamente sulla tecnologia di database integrata fornita da Microsoft SQL Server. Questo metodo è di fatto un metodo senza tempi di inattività che utilizza un gruppo di disponibilità sempre attivo. Il gruppo di disponibilità Always On comprende AWS e Google Cloud su VPN e consente la replica del database Microsoft SQL Server. Questo documento presuppone che tu conosca la configurazione di rete, Google Cloud, Compute Engine, AWS e Microsoft SQL Server.

Se vuoi eseguire solo la replica, puoi seguire i passaggi di questo tutorial, ma interrompere l'operazione dopo aver aggiunto i dati di test e omettere i passaggi del cutover.

Obiettivi

  • Esegui il deployment di un gruppo di disponibilità sempre attivo di Microsoft SQL Server multi-cloud che comprende un Microsoft SQL Server in Amazon EC2 e un Microsoft SQL Server in Google Cloud su Compute Engine.
  • Configura un'istanza Microsoft SQL principale in Amazon EC2.
  • Configura l'istanza di Microsoft SQL Server in Google Cloud come secondaria rispetto al server Microsoft SQL principale in AWS (target della replica dei dati).
  • Completa la migrazione dei dati impostando Microsoft SQL Server secondario in Google Cloud come Microsoft SQL Server principale in Google Cloud.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Questo tutorial richiede anche risorse su AWS che potrebbero comportare costi.

Prima di iniziare

  1. Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  2. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  3. Nella console Google Cloud, attiva Cloud Shell.

    Attiva Cloud Shell

Informazioni sulla migrazione dei database

La migrazione del database sposta i dati da un database di origine a un database di destinazione. In generale, puoi eseguire la migrazione di un sottoinsieme dei dati o avere uno schema diverso nel database di origine e di destinazione. Tuttavia, questo tutorial riguarda una migrazione del database omogenea che richiede la migrazione dell'intero database senza modifiche: il database di destinazione è una copia del database di origine.

Migrazione del database senza tempi di inattività

Il termine zero tempi di inattività si riferisce al fatto che durante la migrazione i client che accedono al database di origine rimangono completamente operativi e non vengono interrotti. L'unico tempo di inattività si verifica quando i client devono riconnettersi al database di destinazione al termine della migrazione. Anche se questo metodo non corrisponde a un tempo di inattività pari a zero, il termine si riferisce a questo scenario di tempo di inattività minimo.

Per una discussione generale sulla migrazione dei database, consulta Migrazione dei database - Concetti e principi (Parte 1) e Migrazione dei database - Concetti e principi (Parte 2). Questi articoli forniscono una panoramica della possibile complessità della migrazione del database in scenari diversi.

Migrazione dei database con la tecnologia Microsoft SQL Server

Alcune tecnologie di migrazione dei database forniscono componenti e servizi separati. Quando la migrazione del database richiede una copia del database di origine, puoi utilizzare la tecnologia Microsoft SQL Server integrata.

Questo tutorial utilizza la tecnologia del gruppo di disponibilità sempre attivo di Microsoft SQL Server per connettere il database di origine (principale) a un database di destinazione (secondario). Questa tecnologia fornisce la replica asincrona dal database principale a quello secondario. Poiché il database principale si trova in Amazon EC2 e il database secondario si trova in Google Cloud su Compute Engine, la replica completa la migrazione del database. Dopo la migrazione di tutti i dati tramite la replica asincrona, il secondario viene promosso a principale e i client possono riconnettersi alla nuova rete principale per continuare a elaborare.

Questo approccio supporta i test espliciti mediante una replica di prova in un database di destinazione di test: puoi avviare la replica, mantenerla in esecuzione per un po' di tempo e poi interromperla. Il database di destinazione del test è in uno stato coerente e puoi utilizzarlo per testare l'applicazione. Al termine del test, puoi eliminare il database di destinazione del test e avviare la replica per un database in tempo reale.

Architettura di migrazione dei database multi-cloud

Il seguente diagramma mostra l'architettura complessiva di deployment per la migrazione di un database multi-cloud:

Un gruppo di disponibilità sempre attivo connette un database AWS a un database Google Cloud.

Il diagramma precedente mostra il database SQL Server di origine (primario) in AWS come istanza Amazon EC2. Il diagramma mostra anche il database di destinazione (secondario) in Google Cloud. I database sono collegati da un gruppo di disponibilità sempre attivo. Si presume che la connessione di rete tra AWS e Google Cloud sia una connessione VPN ad alta disponibilità protetta.

Configurazione di un gruppo di disponibilità di Microsoft SQL Server multi-cloud

Nelle sezioni seguenti, configurerai un gruppo di disponibilità sempre attivo a due nodi, in cui il nodo principale si trova in AWS e il nodo secondario in Google Cloud. Questa configurazione è descritta in precedenza in questo documento in Architettura di migrazione di database multi-cloud.

Le seguenti tabelle forniscono un riepilogo dei nodi e degli indirizzi IP configurati in questo tutorial. Per ogni VM del database, allochi due indirizzi IP oltre all'indirizzo IP principale: un indirizzo IP per il cluster di failover di Windows Server (WSFC) e un indirizzo IP per il listener del gruppo di disponibilità.

Provider Istanza IP principale IP WSFC e listener di gruppi di disponibilità WSFC Gruppo di disponibilità
AWS cluster-sql1 192.168.1.4 192.168.1.5
192.168.1.6 		Name: cluster-dbclus Name: cluster-ag
Listener: ag-listener
Google Cloud cluster-sql2 10.1.1.4 10.1.1.5
10.1.1.6
Provider Istanza IP principale —
AWS dc-windows 192.168.1.100 Domain controller

Nelle istruzioni vengono utilizzati questi nomi e indirizzi IP come esempi. Se vuoi utilizzare i tuoi nomi e indirizzi IP, sostituisci i valori di esempio nelle istruzioni.

Prerequisiti per AWS

Su AWS dovresti avere due macchine virtuali: una che esegue il controller di dominio e l'altra che esegue SQL Server. Il controller di dominio utilizzato come esempio in questo tutorial ha la seguente configurazione:

Domain                    : dbeng.com
Domain controller         : Name: dc-windows
                            Private IP: 192.168.1.100
VPC Subnet                : 192.168.1.0/24
SQL Server service account: dbeng\sql_service

La VM SQL Server utilizzata come esempio in questo tutorial fa parte di un dominio Windows Active Directory in Amazon EC2. Il server ha due indirizzi IP secondari che devono essere utilizzati dal WSFC e dal listener del gruppo di disponibilità. La VM SQL Server ha la seguente configurazione:

VM Instance : Name: cluster-sql1
              Private IP: 192.168.1.4
              Secondary Private IPs: 192.168.1.5, 192.168.1.6
VPC Subnet  : 192.168.1.0/24

Puoi utilizzare l'account di servizio NT SERVICE\MSSQLSERVER come account di servizio SQL Server. Durante la configurazione del gruppo di disponibilità sempre attivo, concedi l'accesso agli account della macchina (dbeng\cluster-sql1$, dbeng\cluster-sql2$) anziché all'account del dominio. La seguente sezione fornisce i comandi per configurare il gruppo di disponibilità.

Prerequisiti per la connettività tra AWS e Google Cloud

Per connettere il progetto AWS al progetto Google Cloud, configura la seguente connettività di rete:

  1. Configura un Google Virtual Private Cloud e un VPC AWS nei rispettivi progetti e configura una VPN tra i VPC. Per informazioni su come configurare una VPN tra Google Cloud e AWS, vedi VPN multi-cloud e subnet multi-zona: configurazione della rete per deployment di database multi-cloud.

  2. In Cloud Shell, crea una subnet nel progetto Google Cloud in cui stai creando l'istanza SQL Server. Se hai già una subnet, puoi utilizzarla, ma assicurati di configurare le regole firewall nel passaggio successivo.

    gcloud compute networks create demo-vpc --subnet-mode custom

gcloud compute networks subnets create demo-subnet1 \
  --network demo-vpc --region us-east4 --range 10.1.1.0/24

    Questo tutorial utilizza i seguenti valori:

    • VPC: demo-vpc
    • Subnet: demo-subnet1; 10.1.1.0/24

    La subnet viene visualizzata nella pagina Reti VPC della console Google Cloud.

  3. Nel tuo progetto Google Cloud, crea una regola firewall per aprire tutto il traffico tra la subnet Google Cloud e la subnet AWS:

    gcloud compute firewall-rules create allow-vpn-ports \
  --network demo-vpc --allow tcp:1-65535,udp:1-65535,icmp \
  --source-ranges 10.1.1.0/24,192.168.1.0/24

    La regola firewall viene visualizzata nella pagina Criteri firewall della console Google Cloud.

  4. Nel progetto AWS, crea una regola firewall nel gruppo di sicurezza per aprire tutto il traffico tra la subnet Google Cloud e la subnet AWS, come mostrato nello screenshot seguente:

    Le regole AWS in entrata sono impostate per consentire tutto il traffico, tutti i protocolli e tutti gli intervalli di porte.

    In un ambiente di produzione, considera l'apertura solo delle porte TCP/UDP necessarie. L'apertura solo delle porte obbligatorie limita il traffico potenzialmente dannoso e segue un principio meno necessario.

Creazione di un'istanza in Google Cloud per il gruppo di disponibilità sempre attivo

Questo tutorial funziona con le seguenti versioni e funzionalità di Microsoft SQL Server:

  • Versione:
    • Microsoft SQL Server 2016 Enterprise Edition o
    • Microsoft SQL Server 2017 Enterprise Edition oppure
    • Microsoft SQL Server 2019 Enterprise Edition oppure
    • Microsoft SQL Server 2022 Enterprise Edition oppure
    • Microsoft SQL Server 2016 Standard Edition o
    • Microsoft SQL Server 2017 Standard Edition o
    • Microsoft SQL Server 2019 Standard Edition o
    • Microsoft SQL Server 2022 Standard Edition
  • Funzionalità: gruppi di disponibilità sempre attivi

Le seguenti istruzioni utilizzano l'immagine per Microsoft SQL Server 2019 Enterprise Edition: sql-ent-2019-win-2019. Se vuoi installare le versioni Enterprise di Microsoft SQL Server 2017, 2016 o 2022, utilizza invece sql-ent-2017-win-2019, sql-ent-2016-win-2019 rispettivamente sql-ent-2022-win-2019. Per un elenco di tutte le immagini, consulta la pagina Dettagli del sistema operativo di Compute Engine.

Nei passaggi seguenti, creerai un'istanza SQL Server in Google Cloud per il gruppo di disponibilità. L'istanza utilizza la seguente configurazione di indirizzi IP con indirizzi IP alias:

VM Instance: Name: cluster-sql2
             Private IP: 10.1.1.4
             Secondary Private IPs: 10.1.1.5, 10.1.1.6

Creerai un'istanza denominata cluster-sql2 da immagini SQL Server pubbliche, con una dimensione del disco di avvio da 200 GB e un tipo di macchina n1-highmem-4. Le istanze SQL Server di solito richiedono più risorse di calcolo rispetto all'istanza del controller di dominio. Se in un secondo momento avrai bisogno di risorse di calcolo aggiuntive, potrai modificare il tipo di macchina per queste istanze. Se hai bisogno di ulteriore spazio di archiviazione, aggiungi un disco o ridimensiona il disco di avvio permanente. In gruppi di disponibilità più grandi, puoi creare diverse istanze.

I passaggi seguenti includono anche il flag --metadata sysprep-specialize-script-ps1 che esegue un comando di Microsoft PowerShell durante la creazione dell'istanza per installare la funzionalità di clustering di failover.

  1. In Cloud Shell, crea un'istanza SQL Server in Google Cloud che utilizza la stessa versione del sistema operativo di AWS:

    gcloud compute instances create cluster-sql2 --machine-type n1-highmem-4 \
  --boot-disk-type pd-ssd --boot-disk-size 200GB \
  --image-project windows-sql-cloud --image-family sql-ent-2019-win-2019 \
  --zone us-east4-a \
  --network-interface "subnet=demo-subnet1,private-network-ip=10.1.1.4,aliases=10.1.1.5;10.1.1.6" \
  --can-ip-forward \
  --metadata sysprep-specialize-script-ps1="Install-WindowsFeature Failover-Clustering -IncludeManagementTools;"

  2. Imposta un nome utente e una password Windows prima di connetterti all'istanza.

  3. Quando utilizzi Remote Desktop Protocol (RDP) dal tuo laptop, crea una regola firewall che consenta l'accesso all'istanza.

  4. Connettiti all'istanza Google Cloud utilizzando RDP e apri una PowerShell elevata (esegui come amministratore).

  5. In questo tutorial configurerai un DNS locale per utilizzare il controller di dominio in AWS (192.168.1.100) al fine di evitare di creare un'altra VM in Google Cloud. Per i carichi di lavoro di produzione, ti consigliamo di utilizzare un controller di dominio (principale o secondario) in Google Cloud per evitare l'autenticazione sul tunnel VPN.

    Nella PowerShell elevata, dovresti essere in grado di inviare un ping al controller di dominio 192.168.1.100:

    ping 192.168.1.100

    Se il ping non va a buon fine, assicurati che il firewall e il tunnel VPN siano configurati correttamente tra AWS e Google Cloud, come descritto nella sezione Prerequisiti per la connettività di questo documento.

  6. Poiché il server è stato originariamente configurato con DHCP, modifica l'istanza in modo che utilizzi indirizzi IP statici:

    netsh interface ip set address name=Ethernet static 10.1.1.4 255.255.255.0 10.1.1.1 1

    Dopo aver eseguito il comando precedente, perderai la connessione. Riconnettiti in RDP.

  7. Configura il DNS locale per utilizzare il controller di dominio in AWS e apri le porte del firewall locali per SQL Server. L'apertura delle porte firewall consente a SQL Server di connettersi ai server SQL remoti.

    netsh interface ip set dns Ethernet static 192.168.1.100

netsh advfirewall firewall add rule name="Open Port 5022 for Availability Groups" dir=in action=allow protocol=TCP localport=5022

netsh advfirewall firewall add rule name="Open Port 1433 for SQL Server" dir=in action=allow protocol=TCP localport=1433

  8. Aggiungi l'istanza al dominio Windows:

    Add-Computer -DomainName "dbeng.com" -Credential "dbeng.com\Administrator" -Restart -Force

    Il comando richiede l'inserimento delle credenziali di amministratore del dominio. Al termine dell'esecuzione del comando, l'istanza viene riavviata.

    Se il comando non viene eseguito, assicurati di eseguirlo come amministratore.

  9. Utilizza l'account dbeng\Administrator per riconnetterti all'istanza mediante RDP.

  10. Imposta l'account di servizio SQL Server:

    1. Apri SQL Server 2019 Configuration Manager.
    2. Nella scheda Servizi SQL Server, fai clic con il pulsante destro del mouse su SQL Server (MSSQLSERVER), quindi fai clic su Proprietà.
    3. Imposta l'account e la password per dbeng\sql_service.
    4. Riavvia SQL Server.

  11. Rinomina l'istanza SQL Server in modo che corrisponda al nome del computer e riavvia SQL Server:

    Invoke-Sqlcmd -Query "EXEC sp_dropserver @@SERVERNAME, @droplogins='droplogins'"

Invoke-Sqlcmd -Query "EXEC sp_addserver '$env:COMPUTERNAME', local"

Stop-Service -Name "MSSQLServer" -Force

Start-Service -Name "MSSQLServer"

Il passaggio successivo consiste nel configurare l'istanza in AWS.

Configura l'istanza in AWS

Questo tutorial presuppone che tu abbia già configurato quanto segue in AWS:

  • L'istanza SQL Server fa parte del dominio Active Directory.
  • Il DNS locale funziona correttamente e il nome del server remoto in Google Cloud (cluster-sql2.dbeng.com) può essere convertito in un indirizzo IP.
  • Le regole firewall vengono aperte tra le subnet su AWS e Google Cloud.

Per configurare cluster-sql1 in AWS:

  1. Connettiti all'istanza AWS utilizzando RDP (cluster-sql1).
  2. Apri una PowerShell elevata (esegui come amministratore).

  3. Installa il clustering di failover di Windows, se non è già installato.

    Install-WindowsFeature Failover-Clustering -IncludeManagementTools

    Questo comando richiede il riavvio se la funzionalità non è già installata. Dopo il riavvio, continua con il passaggio successivo.

  4. Apri le porte del firewall locali per l'istanza SQL Server in AWS:

    netsh advfirewall firewall add rule name="Open Port 5022 for Availability Groups" dir=in action=allow protocol=TCP localport=5022

netsh advfirewall firewall add rule name="Open Port 1433 for SQL Server" dir=in action=allow protocol=TCP localport=1433

netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol="icmpv4:8,any" dir=in action=allow

  5. Rinomina l'istanza SQL Server in modo che corrisponda al nome del computer e riavvia SQL Server:

    Invoke-Sqlcmd -Query "EXEC sp_dropserver @@SERVERNAME, @droplogins='droplogins'"

Invoke-Sqlcmd -Query "EXEC sp_addserver '$env:COMPUTERNAME', local"

Stop-Service -Name "MSSQLServer" -Force

Start-Service -Name "MSSQLServer"

  6. Verifica che l'istanza in AWS possa connettersi all'istanza in Google Cloud quando utilizzi il nome istanza remota. Per testare la connessione, esegui i comandi seguenti da un account di dominio che ha concesso l'accesso di connessione a SQL Server.

    1. Verifica la connessione di rete:

      ping -4 cluster-sql2.dbeng.com

      L'output sarà simile al seguente:

      RESULTS:
Pinging cluster-sql2.dbeng.com [10.1.1.4] with 32 bytes of data:
Reply from 10.1.1.4: bytes=32 time=3ms TTL=127
Reply from 10.1.1.4: bytes=32 time=2ms TTL=127
Reply from 10.1.1.4: bytes=32 time=2ms TTL=127
Reply from 10.1.1.4: bytes=32 time=2ms TTL=127

    2. Verifica l'autenticazione Windows sul server remoto:

      sqlcmd -E -S cluster-sql2.dbeng.com -Q "SELECT 'CONNECTED'"

      L'output sarà simile al seguente:

      RESULTS:
--------------------------------------------------------------------------
CONNECTED

(1 rows affected)

    Se non riesci a connetterti, assicurati che il DNS funzioni correttamente e che le regole firewall siano aperte tra le subnet AWS e Google Cloud.

Verifica che l'istanza Google Cloud sia pronta per partecipare al gruppo di disponibilità

  1. Usa l'account dbeng\Administrator per connetterti all'istanza Google Cloud tramite RDP (cluster-sql2).
  2. Apri una PowerShell elevata (esegui come amministratore).

  3. Verifica che l'istanza in Google Cloud possa connettersi all'istanza in AWS quando utilizzi il nome dell'istanza. Per testare la connessione, esegui i comandi seguenti da un account di dominio che ha concesso l'accesso di connessione a SQL Server.

    1. Verifica la connessione di rete:

      ping -4 cluster-sql1.dbeng.com

      L'output sarà simile al seguente:

      RESULTS:
Pinging CLUSTER-SQL1.dbeng.com [192.168.1.4] with 32 bytes of data:
Reply from 192.168.1.4: bytes=32 time=3ms TTL=127
Reply from 192.168.1.4: bytes=32 time=2ms TTL=127
Reply from 192.168.1.4: bytes=32 time=3ms TTL=127
Reply from 192.168.1.4: bytes=32 time=2ms TTL=127

    2. Verifica l'autenticazione Windows sul server remoto:

      sqlcmd -E -S cluster-sql1 -Q "SELECT 'CONNECTED'"

      L'output sarà simile al seguente:

      RESULTS:
------------------------------------------------------------
CONNECTED

(1 rows affected)

      Se non riesci a connetterti, assicurati che il DNS funzioni correttamente e che le regole firewall siano aperte tra le subnet AWS e Google Cloud.

  4. Crea cartelle in C:\SQLData e C:\SQLLog. I dati del database e i file di log utilizzano queste cartelle.

    New-Item "C:\SQLData" –type directory
New-Item "C:\SQLLog" –type directory

  5. Crea una cartella in C:\SQLBackup e una condivisione Windows in \\cluster-sql2\SQLBackup per trasferire il backup dall'istanza AWS. Puoi utilizzare qualsiasi altra condivisione di rete disponibile per entrambi i server.

    New-Item "C:\SQLBackup" –type directory
New-SmbShare -Name "SQLBackup" -Path "C:\SQLBackup" -FullAccess
"dbeng.com\cluster-sql1$","dbeng.com\cluster-sql2$","NT
SERVICE\MSSQLSERVER","authenticated users","dbeng.com\sql_service"

Le istanze sono ora pronte per il gruppo di disponibilità. Poiché hai solo due istanze, nella sezione successiva configurerai una testimonianza della condivisione di file per fornire un voto decisivo e raggiungere il quorum.

Creazione di un witness di condivisione file

Per fornire un voto tie-breaking e raggiungere un quorum per lo scenario di failover, crea una condivisione file che funga da testimone. Ai fini di questo tutorial, creerai il witness della condivisione file sulla VM controller di dominio. In un ambiente di produzione, devi creare il testimone della condivisione file su qualsiasi server all'interno del tuo dominio Active Directory.

  1. Utilizza l'account dbeng\Administrator per connetterti alla VM controller di dominio dc-windows tramite RDP.
  2. Apri una PowerShell elevata (esegui come amministratore).

  3. Crea la cartella di testimone:

    New-Item "C:\QWitness" –type directory

  4. Condividi la cartella:

    New-SmbShare -Name "QWitness" -Path "C:\QWitness" -Description "SQL File Share Witness" -FullAccess "dbeng.com\Administrator", "dbeng.com\cluster-sql1$", "dbeng.com\cluster-sql2$"

  5. Utilizza dbeng.com\Administrator per connetterti sia a cluster-sql1 sia a cluster-sql2 tramite RDP.

  6. Verifica di poter accedere alla directory condivisa da entrambi i server:

    dir \\dc-windows\QWitness

    Se non riesci ad accedere alla directory condivisa, prova a modificare la connessione di rete sul nodo per impostare il server WINS in modo che corrisponda al server di dominio. La modifica della connessione di rete potrebbe richiedere alcuni secondi. Il seguente screenshot mostra le impostazioni WINS aggiornate:

    Impostazioni degli indirizzi WINS aggiornate in Impostazioni TCP/IP avanzate.

Ora è tutto pronto per il gruppo di disponibilità. Il passaggio successivo consiste nel configurare il clustering di failover.

Configurazione del clustering di failover

In questa sezione configurerai WSFC e abiliti l'alta disponibilità sempre attiva per entrambe le istanze. Esegui tutti i seguenti comandi di configurazione dall'istanza in AWS.

  1. Connettiti all'istanza AWS (cluster-sql1) utilizzando RDP.
  2. Apri una PowerShell elevata (esegui come amministratore).

  3. Imposta variabili che riflettono l'ambiente del tuo cluster. Per questo esempio, imposta le seguenti variabili:

    $node1 = "cluster-sql1.dbeng.com"
$node2 = "cluster-sql2.dbeng.com"
$nameWSFC = "cluster-dbclus" #Name of cluster
$ipWSFC1 = "192.168.1.5" #IP address of cluster in subnet 1 (AWS)
$ipWSFC2 = "10.1.1.5"    #IP address of cluster in subnet 2 (Google Cloud)

  4. Crea il cluster di failover (l'esecuzione di questo comando potrebbe richiedere un po' di tempo):

    New-Cluster -Name $nameWSFC -Node $node1, $node2 -NoStorage -StaticAddress $ipWSFC1, $ipWSFC2

Set-ClusterQuorum -FileShareWitness \\dc-windows\QWitness

  5. Abilita l'alta disponibilità sempre attiva sul nodo 1. Se non hai mai abilitato l'opzione Sempre attiva in precedenza, questi comandi forzano il riavvio di SQL Server.

    Enable-SqlAlwaysOn -ServerInstance $node1 -Force

  6. Abilita l'alta disponibilità sempre attiva sul nodo 2. Questi comandi interrompono il servizio SQL Server prima di abilitare SQL sempre attivo. In questo modo puoi ignorare l'errore: Enable-SqlAlwaysOn : StopService failed for Service 'MSSQLSERVER'.

    Get-Service -ComputerName $node2 -Name "MSSQLServer" | Stop-Service -Force

Enable-SqlAlwaysOn -ServerInstance $node2 -Force

Get-Service -ComputerName $node2 -Name "MSSQLServer" | Start-Service

  7. Crea cartelle in C:\SQLData e C:\SQLLog. Utilizza queste cartelle per i dati del database e i file di log di TestDB. Se il tuo server dispone già di un database con questa struttura di cartelle, puoi saltare questo passaggio. Se non sei sicuro, esegui i comandi e ignora gli eventuali messaggi di errore relativi alle cartelle preesistenti.

    New-Item "C:\SQLData" –type directory
New-Item "C:\SQLLog" –type directory

Il gestore di cluster di failover è pronto. Ora crea il gruppo di disponibilità.

Creazione del gruppo di disponibilità

In questa sezione creerai un database di test in AWS (cluster-sql1) e lo configurerai in modo che funzioni con un nuovo gruppo di disponibilità. In alternativa, puoi specificare un database esistente per il gruppo di disponibilità.

  1. Connettiti all'istanza AWS (cluster-sql1) utilizzando RDP.
  2. Apri una PowerShell elevata (esegui come amministratore).

  3. Crea una cartella in C:\SQLBackup per archiviare un backup del database. Il backup è necessario prima di poter configurare il gruppo di disponibilità su un nuovo database.

    New-Item "C:\SQLBackup" –type directory

  4. Se non hai già configurato un database, esegui SQL Server Management Studio e crea un database di test nell'istanza AWS (cluster-sql1):

    CREATE DATABASE TestDB
ON PRIMARY (NAME = 'TestDB_Data', FILENAME='C:\SQLData\TestDB_Data.mdf', SIZE = 256MB, MAXSIZE = UNLIMITED, FILEGROWTH = 256MB )
LOG ON (NAME = 'TestDB_Log', FILENAME='C:\SQLLog\TestDB_Log.ldf', SIZE = 256MB, MAXSIZE = UNLIMITED, FILEGROWTH = 256MB )
GO

USE [TestDB]
Exec dbo.sp_changedbowner @loginame = 'sa', @map = false;
ALTER DATABASE [TestDB] SET RECOVERY FULL;
GO

BACKUP DATABASE TestDB to disk = 'C:\SQLBackup\TestDB-backup.bak' WITH INIT
GO

  5. In Microsoft SQL Server Management Studio, seleziona Query > Modalità SQLCMD.

    SQL Server Management Studio fornisce una procedura guidata per creare i gruppi di disponibilità. In questo tutorial utilizzerai comandi SQL per semplificare il debug dei problemi che potresti riscontrare durante la connessione tra diversi provider cloud. Se preferisci, puoi eseguire la procedura guidata dei gruppi di disponibilità e andare al passaggio successivo per verificare che il gruppo di disponibilità sia in fase di sincronizzazione.

  6. Esegui le seguenti query in modalità SQLCMD. Se utilizzi un database preesistente, sostituisci TestDB con il nome del tuo database.

    1. Crea un endpoint nel primo nodo e concedi l'autorizzazione all'endpoint:

      :Connect CLUSTER-SQL1
IF NOT EXISTS (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint')
BEGIN
  CREATE ENDPOINT [Hadr_endpoint]
  AS TCP (LISTENER_PORT = 5022)
  FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM AES)
END
GO

IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
  ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED
END
GO

use [master]
GO

IF SUSER_ID('DBENG\sql_service') IS NULL
  CREATE LOGIN [DBENG\sql_service] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\sql_service]
GO

    2. Abilita la sessione dell'evento esteso AlwaysOn_health nel primo nodo. I gruppi di disponibilità richiedono la sessione dell'evento estesa.

      :Connect CLUSTER-SQL1
IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

    3. Crea un endpoint nel secondo nodo e concedi l'autorizzazione all'endpoint:

      :Connect CLUSTER-SQL2
IF NOT EXISTS (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint')
BEGIN
  CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM AES)
END
GO

IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
  ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED
END
GO

use [master]
GO

IF SUSER_ID('DBENG\sql_service') IS NULL
  CREATE LOGIN [DBENG\sql_service] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\sql_service]
GO

    4. Abilita la sessione dell'evento esteso AlwaysOn_health nel secondo nodo. I gruppi di disponibilità richiedono la sessione dell'evento estesa.

      :Connect CLUSTER-SQL2
IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
  ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

    5. Crea il gruppo di disponibilità nel primo nodo:

      :Connect CLUSTER-SQL1
USE [master]
GO

--DROP AVAILABILITY GROUP [cluster-ag];
GO

CREATE AVAILABILITY GROUP [cluster-ag]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
DB_FAILOVER = OFF,
DTC_SUPPORT = NONE)
FOR DATABASE [TestDB]
REPLICA ON N'CLUSTER-SQL1' WITH (ENDPOINT_URL = N'TCP://CLUSTER-SQL1.dbeng.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = MANUAL),
  N'CLUSTER-SQL2' WITH (ENDPOINT_URL = N'TCP://cluster-sql2.dbeng.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = MANUAL);
GO

    6. Unisci il secondo nodo al gruppo di disponibilità appena creato:

      :Connect CLUSTER-SQL2
ALTER AVAILABILITY GROUP [cluster-ag] JOIN;
GO

    7. Crea un backup del database nel primo nodo:

      :Connect CLUSTER-SQL1
BACKUP DATABASE [TestDB] TO DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.bak' WITH COPY_ONLY, FORMAT, INIT, SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
GO

    8. Ripristina il backup del database sul secondo nodo:

      :Connect CLUSTER-SQL2
RESTORE DATABASE [TestDB] FROM DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.bak' WITH NORECOVERY, NOUNLOAD, STATS = 5
GO

    9. Crea un backup dei log delle transazioni nel primo nodo:

      :Connect CLUSTER-SQL1
BACKUP LOG [TestDB] TO DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.trn' WITH NOFORMAT, INIT, NOSKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
GO

    10. Ripristina il backup del log delle transazioni nel secondo nodo:

      :Connect CLUSTER-SQL2
RESTORE LOG [TestDB] FROM  DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.trn' WITH NORECOVERY, NOUNLOAD, STATS = 5
GO

  7. Per assicurarti che non siano presenti errori nella sincronizzazione, esegui la query seguente e assicurati che il valore della colonna connected_state_desc sia CONNECTED:

    :Connect CLUSTER-SQL2
select r.replica_server_name, r.endpoint_url,
       rs.connected_state_desc, rs.last_connect_error_description,
       rs.last_connect_error_number, rs.last_connect_error_timestamp
 from sys.dm_hadr_availability_replica_states rs
  join sys.availability_replicas r
   on rs.replica_id=r.replica_id
 where rs.is_local=1

    • Se la colonna connected_state_desc mostra il messaggio di errore An error occurred while receiving data: '24(The program issued a command but the command length is incorrect)', esegui il comando seguente per provare a cancellare l'errore:

      :Connect CLUSTER-SQL1
IF SUSER_ID('DBENG\CLUSTER-SQL2$') IS NULL
   CREATE LOGIN [DBENG\CLUSTER-SQL2$] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\CLUSTER-SQL2$]
GO

:Connect CLUSTER-SQL2
IF SUSER_ID('DBENG\CLUSTER-SQL1$') IS NULL
  CREATE LOGIN [DBENG\CLUSTER-SQL1$] FROM WINDOWS
GO

GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\CLUSTER-SQL1$]
GO

      Esegui nuovamente la query precedente per assicurarti che l'errore di sincronizzazione non si verifichi più. Potresti dover attendere qualche minuto prima che l'errore venga cancellato. Se l'errore persiste, consulta Risolvere i problemi relativi alla configurazione dei gruppi di disponibilità sempre attivi (SQL Server).

  8. Completa la configurazione del gruppo di disponibilità:

    :Connect CLUSTER-SQL2
ALTER DATABASE [TestDB] SET HADR AVAILABILITY GROUP = [cluster-ag]
GO

ALTER DATABASE [TestDB] SET HADR RESUME;
GO

  9. Verifica che il gruppo di disponibilità sia in fase di sincronizzazione:

    1. In SQL Server Management Studio, in Alta disponibilità sempre attiva > Gruppi di disponibilità, fai clic con il pulsante destro del mouse sul gruppo di disponibilità, quindi seleziona Mostra dashboard.

    2. Verifica che lo stato della sincronizzazione principale sia Sincronizzato e che lo stato della sincronizzazione secondario sia Sincronizzazione, come mostrato nello screenshot seguente:

      SQL Server Management Studio mostra lo stato della sincronizzazione per il gruppo di disponibilità.

  10. Per aggiungere un listener, in Alta disponibilità sempre attiva > Gruppi di disponibilità > cluster-ag (Primary) > Listener di gruppi di disponibilità, fai clic con il pulsante destro del mouse sul nome del gruppo di disponibilità, quindi seleziona Aggiungi listener.

  11. Nella finestra di dialogo Nuovo listener del gruppo di disponibilità, specifica i seguenti parametri per il listener:

    • Nome DNS del listener: ag-listener
    • Porta: 1433
    • Modalità rete: Static IP

  12. Aggiungi due campi di subnet e di indirizzo IP. Per questo esempio, utilizza le seguenti coppie di subnet e indirizzi IP. Queste coppie sono gli indirizzi IP che hai creato in aggiunta all'indirizzo IP principale nelle VM dell'istanza del servizio SQL:

    1. Per la prima coppia, inserisci i seguenti valori:
      • Subnet: 192.168.1.0/24
      • Indirizzo IPv4: 192.168.1.6
    2. Per la seconda coppia, inserisci i seguenti valori:
      • Subnet: 10.1.1.0/24
      • Indirizzo IPv4: 10.1.1.6

  13. Dopo aver aggiunto le coppie di subnet e indirizzi IP, fai clic su OK.

  14. Connettiti a SQL Server utilizzando ag-listener.dbeng.com come nome del database SQL Server anziché il nome delle istanze. Questa connessione punta all'istanza attualmente attiva.

    1. In Esplora oggetti, fai clic su Connetti e quindi seleziona Database Engine.
    2. Nella finestra di dialogo Connetti al server, nel campo Nome server, inserisci il nome del listener ag-listener.dbeng.com.

    3. Dopo aver aggiunto il nome del server, fai clic su Connetti. Explorer oggetti mostra la nuova connessione, come mostrato nel seguente screenshot:

      Esplora oggetti mostra una connessione.

    Se hai stabilito la connessione a cluster-sql2 tramite RDP, puoi facoltativamente ripetere questo passaggio per stabilire la connessione.

Aggiunta di dati di test

In questa sezione, aggiungerai una tabella di test e alcuni dati di test al database TestDB in cluster-sql1, quindi verificherai la replica dei dati.

  1. Crea una tabella denominata Persons in cluster-sql1:

    :Connect CLUSTER-SQL1
USE TestDB;
CREATE TABLE Persons (
    PersonID int,
    LastName varchar(255),
    FirstName varchar(255),
    PRIMARY KEY (PersonID)
);

  2. Inserisci alcune righe:

    :Connect CLUSTER-SQL1
USE TestDB;
INSERT INTO Persons (PersonId, LastName, FirstName)
  VALUES (1, 'Velasquez', 'Ava');
INSERT INTO Persons (PersonId, LastName, FirstName)
  VALUES (2, 'Delaxcrux', 'Paige');

  3. Se utilizzi la versione Enterprise, abilita l'accesso in lettura della replica di lettura (cluster-sql2) in modo da poter verificare che la replica venga eseguita. L'edizione Standard non supporta l'accesso di sola lettura alla replica di lettura. Se utilizzi la versione Standard, passa alla sezione successiva per eseguire il cutover su Google Cloud.

    :Connect CLUSTER-SQL1
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL))
GO

  4. Nella versione Enterprise, esegui una query sulla tabella in cluster-sql2 per verificare che i contenuti della tabella siano stati replicati:

    :Connect CLUSTER-SQL2
SELECT * FROM TestDB.dbo.Persons;

Ora che i dati sono stati replicati da cluster-sql1 a cluster-sql2, esegui il cutover. Se vuoi eseguire solo la replica, puoi saltare le seguenti sezioni e non eseguire il cutover o il fallback. Se non vuoi conservare le risorse utilizzate per eseguire la replica, puoi evitare addebiti seguendo i passaggi di pulizia alla fine di questo tutorial.

Esecuzione del cutover a Google Cloud

Per garantire un set di dati coerente, qualsiasi client che scrive in cluster-sql1 deve essere arrestato in modo che tutti i dati possano essere replicati in cluster-sql2 prima di eseguire il cutover.

Per garantire la coerenza, tutti i dati devono essere completamente replicati. In questa sezione completi la replica dei dati modificando la modalità di disponibilità in SYNCHRONOUS_COMMIT. Questa modifica assicura una replica completa di cluster-sql1 in cluster-sql2.

  1. Per modificare la modalità di disponibilità di entrambi i nodi in commit sincrono, esegui il comando SQL seguente in cluster-sql1. L'impostazione del commit sincrono per entrambi i nodi è l'unico modo per garantire che non vadano persi dati.

    :Connect CLUSTER-SQL1
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO

ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO

  2. Cluster-sql2 è ora pronto a diventare il nodo principale. Connettiti a cluster-sql2 e impostalo come nodo principale:

    :Connect CLUSTER-SQL2
ALTER AVAILABILITY GROUP [cluster-ag] FAILOVER;
GO

  3. Modifica la modalità di disponibilità in commit asincrono in entrambi i nodi. Poiché cluster-sql2 è il nodo principale, esegui i seguenti comandi SQL in cluster-sql2:

    :Connect CLUSTER-SQL2
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

    Ora puoi utilizzare cluster-sql2 come nodo principale per le applicazioni. cluster-sql1 è l'elemento secondario replicato in modo asincrono.

  4. Ora che cluster-sql2 è il nodo principale, esegui una query sulla tabella in cluster-sql2 per verificare che i contenuti della tabella siano stati replicati:

    :Connect CLUSTER-SQL2
SELECT * FROM TestDB.dbo.Persons;

    L'output corrisponde ai dati di test che hai inserito nella tabella in precedenza in questo tutorial.

Per eseguire un'ulteriore verifica della replica, puoi creare una nuova tabella e inserire una singola riga nella nuova tabella principale. Quando la tabella e la relativa riga vengono visualizzate nella seconda, sai che la replica funziona.

Fallback

A volte potrebbe essere necessario passare dalla nuova rete principale a quella principale originale. Una volta completato il passaggio a Google Cloud in precedenza in questo tutorial, hai impostato come secondaria la precedente (cluster-sql1) e la nuova (cluster-sql2).

Per completare un fallback, segui la procedura per eseguire il passaggio a Google Cloud e sostituisci i seguenti valori:

  • Sostituisci l'origine principale originale (cluster-sql1) con la nuova principale (cluster-sql2).
  • Sostituisci l'elemento secondario originale (cluster-sql2) con quello secondario originale (cluster-sql1).

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial:

Elimina il progetto in Google Cloud

  1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Elimina il progetto in AWS

Poiché hai creato e utilizzato risorse in AWS, queste continuano a essere soggette a costi. Per evitare di accumulare ulteriori costi, elimina queste risorse su AWS.

Passaggi successivi