Preparare l'ambiente per un collegamento - Istanza gestita di SQL di Azure

Si applica a: Istanza gestita di SQL di Azure SQL

Questo articolo illustra come preparare l'ambiente per un collegamento di Istanza gestita in modo da poter eseguire la replica tra SQL Server installato su Windows e Istanza gestita di SQL di Azure.

Prerequisiti

Per creare un collegamento tra SQL Server e Istanza gestita di SQL di Azure, sono necessari i seguenti prerequisiti:

• Una sottoscrizione di Azure attiva. Se non se ne ha una, creare un account gratuito.
• Versione supportata di SQL Server con l'aggiornamento del servizio richiesto.
• Istanza gestita di SQL di Azure. Attività iniziali se non è disponibile.
• Scegliere il server che sarà il server primario iniziale per determinare da dove creare il collegamento.
  • La configurazione di un collegamento da istanza primaria gestita di SQL a istanza secondaria di SQL Server è supportata solo a partire da SQL Server 2022 CU10 e dalle istanze configurate con i criteri di aggiornamento di SQL Server 2022.

Autorizzazioni

Per SQL Server è necessario disporre delle autorizzazioni amministratore di sistema.

Per Istanza gestita di SQL di Azure, è necessario essere membri del Contributore Istanza gestita di SQL oppure disporre delle autorizzazioni seguenti per un ruolo personalizzato:

Preparare l'istanza di SQL Server

Per preparare l'istanza di SQL Server è necessario verificare quanto segue:

• Viene utilizzata la versione minima supportata.
• La funzionalità Gruppi di disponibilità è stata attivata.
• Sono stati aggiunti i flag di traccia necessari all'avvio.
• I database si trovano nel modello di recupero con registrazione completa e ne è stato eseguito il backup.

È necessario riavviare SQL Server per applicare le modifiche.

Installare gli aggiornamenti di manutenzione

Assicurarsi che la versione di SQL Server abbia installato l'aggiornamento di manutenzione appropriato, come indicato nella tabella delle versioni supportate. Se è necessario installare eventuali aggiornamenti, occorre riavviare l'istanza di SQL Server durante l'aggiornamento.

Per controllare la versione di SQL Server, eseguire il seguente script Transact-SQL (T-SQL) in SQL Server:

-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';

Creare una chiave master del database nel database master

Creare la chiave master nel database master, se non è già presente. Inserire la password al posto di <strong_password> nello script seguente e mantenerla in un luogo riservato e sicuro. Eseguire questo script T-SQL in SQL Server:

-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';

Per assicurarsi di disporre della chiave master del database, usare il seguente script T-SQL in SQL Server:

-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';

Abilitare i gruppi di disponibilità

La funzionalità di collegamento è basata sulla funzionalità Gruppi di disponibilità Always On, disabilitata per impostazione predefinita. Per altre informazioni, vedere Abilitare la funzionalità Gruppi di disponibilità AlwaysOn.

Per verificare che la funzionalità dei gruppi di disponibilità sia abilitata, eseguire il seguente script T-SQL in SQL Server:

-- Run on SQL Server
-- Is the availability groups feature enabled on this SQL Server
DECLARE @IsHadrEnabled sql_variant = (select SERVERPROPERTY('IsHadrEnabled'))
SELECT
    @IsHadrEnabled as 'Is HADR enabled',
    CASE @IsHadrEnabled
        WHEN 0 THEN 'Availability groups DISABLED.'
        WHEN 1 THEN 'Availability groups ENABLED.'
        ELSE 'Unknown status.'
    END
    as 'HADR status'

Se la funzionalità dei gruppi di disponibilità non è abilitata, seguire questa procedura per abilitarla:

1. Aprire Gestione configurazione SQL Server.

2. Selezionare Servizi di SQL Server dal riquadro a sinistra.

3. Fare clic con il pulsante destro del mouse sul servizio SQL Server e scegliere Proprietà.

   

4. Passare alla scheda Gruppi di disponibilità AlwaysOn.

5. Selezionare la casella di controllo Abilita gruppi di disponibilità Always On, quindi scegliere OK.

   

   • Se si usa SQL Server 2016 (13.x) e se l'opzione Abilita gruppi di disponibilità AlwaysOn è disabilitata con il messaggio This computer is not a node in a failover cluster., seguire i passaggi aggiuntivi descritti in Preparare i prerequisiti di SQL Server 2016 - Collegamento di Istanza gestita di SQL di Azure. Dopo aver completato questi ulteriori passaggi, tornare indietro e riprovare a eseguire questo passaggio.

6. Nella finestra di dialogo, selezionare OK.

7. Riavviare il servizio SQL Server.

Abilitare flag di traccia di avvio

Per ottimizzare le prestazioni del collegamento, è consigliabile abilitare i seguenti flag di traccia all'avvio:

• -T1800: questo flag di traccia ottimizza le prestazioni quando i file di log per le repliche primarie e secondarie in un gruppo di disponibilità sono ospitati su dischi di dimensioni di settore diverse, ad esempio 512 byte e 4 KB. Se sia le repliche primarie che quelle secondarie hanno dimensioni del settore del disco di 4 KB, questo flag di traccia non è obbligatorio. Per altre informazioni, vedere KB3009974.
• -T9567: questo flag di traccia abilita la compressione del flusso di dati per i gruppi di disponibilità durante il seeding automatico. La compressione aumenta il carico sul processore, ma può ridurre significativamente i tempi di trasferimento durante il seeding.

Per abilitare questi flag di traccia all'avvio, seguire questa procedura:

1. Aprire Gestione configurazione SQL Server.

2. Selezionare Servizi di SQL Server dal riquadro a sinistra.

3. Fare clic con il pulsante destro del mouse sul servizio SQL Server e scegliere Proprietà.

   

4. Passare alla scheda Parametri di avvio. In Specificare un parametro di avvio, digitare il parametro -T1800 e selezionare Aggiungi per aggiungere il parametro di avvio. Immettere, quindi, -T9567 e selezionare Aggiungi per aggiungere l'altro flag di traccia. Selezionare Applica per salvare le modifiche.

   

5. Selezionare OK per chiudere la finestra Proprietà.

Per altre informazioni, vedere la sintassi per abilitare i flag di traccia.

Riavviare SQL Server ed esaminare la configurazione

Dopo aver verificato di essere in una versione supportata di SQL Server, aver abilitato la funzionalità Gruppi di disponibilità AlwaysOn e aver aggiunto i flag di traccia di avvio, riavviare l'istanza di SQL Server per applicare tutte queste modifiche:

1. Aprire Gestione configurazione SQL Server.

2. Selezionare Servizi di SQL Server dal riquadro a sinistra.

3. Fare clic con il pulsante destro del mouse sul servizio di SQL Server, quindi selezionare Avvia.

   

Dopo il riavvio, eseguire lo script T-SQL seguente in SQL Server per convalidare la configurazione dell'istanza di SQL Server:

-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;

La versione di SQL Server deve essere una delle versioni supportate applicate con gli aggiornamenti del servizio appropriati, la funzionalità Gruppi di disponibilità AlwaysOn deve essere abilitata e devono essere abilitati i flag di traccia -T1800 e -T9567. Lo screenshot seguente è un esempio del risultato previsto per un'istanza di SQL Server configurata correttamente:

Configurare la connettività di rete

Affinché il collegamento funzioni, la connettività di rete tra SQL Server e Istanza gestita di SQL deve essere presente. L'opzione di rete scelta dipende dal fatto che l'istanza di SQL Server si trovi in una rete di Azure o meno.

SQL Server in Macchine virtuali di Azure

La distribuzione di SQL Server in Macchine virtuali di Azure nella stessa rete virtuale di Azure che ospita Istanza gestita di SQL è il metodo più semplice, perché la connettività di rete esisterà automaticamente tra le due istanze. Per ulteriori informazioni, vedere Avvio rapido: Configurare una VM di Azure per la connessione a un'istanza gestita di SQL di Azure.

Se l'istanza di SQL Server in Macchine virtuali di Azure si trova in una rete virtuale diversa dall'istanza gestita, è necessario stabilire una connessione tra le due reti virtuali. Non è necessario che le reti virtuali si trovino nella stessa sottoscrizione perché questo scenario funzioni.

Per connettere le reti virtuali esistono due opzioni:

• Peering reti virtuali di Azure
• Gateway da rete virtuale a rete virtuale (portale di Azure, PowerShell, Interfaccia della riga di comando di Azure)

Il peering è preferibile perché usa la rete backbone Microsoft quindi, dal punto di vista della connettività, non vi è alcuna differenza percepibile nella latenza tra le macchine virtuali in una rete virtuale con peering e nella stessa rete virtuale. Il peering di reti virtuali è supportato tra le reti nella stessa area. Il peering di reti virtuali globale è supportato per le istanze ospitate nelle subnet create dal 22 settembre 2020. Per ulteriori informazioni, vedere Domande frequenti (FAQ).

SQL Server al di fuori di Azure

Se l'istanza di SQL Server è ospitata al di fuori di Azure, stabilire una connessione VPN tra SQL Server e Istanza gestita di SQL usando una di queste opzioni:

• Connessione VPN da sito a sito
• Connessione Azure ExpressRoute

Porte di rete tra ambienti

Indipendentemente dal meccanismo di connettività, è necessario soddisfare i requisiti per il flusso del traffico di rete tra ambienti:

Le regole del gruppo di sicurezza di rete (NSG) nella subnet che ospita l'istanza gestita devono consentire:

• Porta in ingresso 5022 e intervallo di porte 11000-11999 per ricevere traffico dall’IP di SQL Server di origine
• Porta in uscita 5022 per inviare traffico all'indirizzo IP di SQL Server di destinazione

Tutti i firewall sulla rete che ospitano SQL Server, dove il sistema operativo host deve consentire:

• Porta in ingresso 5022 aperta per ricevere traffico dall'intervallo IP di origine della subnet MI /24 (ad esempio 10.0.0.0/24)
• Porte in uscita 5022 e l'intervallo di porte 11000-11999 aperto per inviare il traffico all'intervallo IP di destinazione della subnet MI (ad esempio 10.0.0.0/24)

La tabella seguente descrive le azioni delle porte per ciascun ambiente:

Usare il seguente script di PowerShell nel sistema operativo host Windows dell'istanza di SQL Server per aprire le porte in Windows Firewall:

New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP

Il diagramma seguente mostra un esempio di ambiente di rete locale, che indica che tutti i firewall nell'ambiente devono avere porte aperte , compreso il firewall del sistema operativo che ospita SQL Server e tutti i firewall e/o i gateway aziendali:

Aggiungere URL all'elenco degli elementi consentiti

A seconda delle impostazioni di protezione di rete, potrebbe essere necessario aggiungere URL per FQDN Istanza gestita di SQL e alcuni degli endpoint di Gestione risorse usati da Azure all'elenco degli elementi consentiti.

Di seguito sono elencate le risorse da aggiungere all'elenco degli elementi consentiti:

• Il nome di dominio completo (FQDN) dell'Istanza gestita di SQL di Azure. Ad esempio, managedinstance1.6d710bcf372b.database.windows.net.
• Autorizzazione Microsoft Entra
• ID della risorsa dell’endpoint Microsoft Entra
• Endpoint Resource Manager
• Endpoint servizio

Seguire la procedura descritta nella sezione Configurare SSMS per i cloud per enti pubblici per accedere all'interfaccia Strumenti in SQL Server Management Studio (SSMS) e identificare gli URL specifici delle risorse all'interno del cloud da aggiungere all'elenco elementi consentiti.

Testare la connettività di rete

La connettività bidirezionale di rete tra SQL Server e Istanza gestita di SQL è necessaria per il funzionamento del collegamento. Dopo aver aperto le porte sul lato SQL Server e aver configurato una regola del gruppo di sicurezza di rete sul lato Istanza gestita di SQL, testare la connettività tramite SQL Server Management Studio (SSMS) o Transact-SQL.

Testare la rete creando un processo temporaneo di SQL Agent in SQL Server e Istanza gestita di SQL per verificare la connessione tra le due istanze. Quando si usa Controllo di rete in SSMS, il processo viene creato automaticamente ed eliminato al termine del test. È necessario eliminare manualmente il processo di SQL Agent se si testa la rete usando T-SQL.

Per usare SQL Agent per testare la connettività di rete, sono necessari i requisiti seguenti:

• L'utente che esegue il test deve disporre delle autorizzazioni per creare un processo (come amministratore di sistema o appartiene al ruolo SQLAgentOperator per msdb) sia per SQL Server che per Istanza gestita di SQL.
• È necessario che il servizio SQL Server Agent sia in esecuzione su SQL Server. Poiché l'agente è attivato per impostazione predefinita in Istanza gestita di SQL, non è necessaria alcuna azione aggiuntiva.

-- Run on SQL Server
-- Create the certificate needed for the test endpoint
USE MASTER
CREATE CERTIFICATE TEST_CERT
WITH SUBJECT = N'Certificate for SQL Server',
EXPIRY_DATE = N'3/30/2051'
GO

-- Create the test endpoint on SQL Server
USE MASTER
CREATE ENDPOINT TEST_ENDPOINT
    STATE=STARTED
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE TEST_CERT,
        ENCRYPTION = REQUIRED ALGORITHM AES
    )

tnc localhost -port 5022

-- Run on SQL managed instance
-- SQL_SERVER_IP_ADDRESS should be an IP address that could be accessed from the SQL Managed Instance host machine.
DECLARE @SQLServerIpAddress NVARCHAR(MAX) = '<SQL_SERVER_IP_ADDRESS>'; -- insert your SQL Server IP address in here
DECLARE @tncCommand NVARCHAR(MAX) = 'tnc ' + @SQLServerIpAddress + ' -port 5022 -InformationLevel Quiet';
DECLARE @jobId BINARY(16);

IF EXISTS (
        SELECT *
        FROM msdb.dbo.sysjobs
        WHERE name = 'NetHelper'
        ) THROW 70000,
    'Agent job NetHelper already exists. Please rename the job, or drop the existing job before creating it again.',
    1
    -- To delete NetHelper job run: EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'
    EXEC msdb.dbo.sp_add_job @job_name = N'NetHelper',
        @enabled = 1,
        @description = N'Test SQL Managed Instance to SQL Server network connectivity on port 5022.',
        @category_name = N'[Uncategorized (Local)]',
        @owner_login_name = N'sa',
        @job_id = @jobId OUTPUT;

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'TNC network probe from SQL MI to SQL Server',
    @step_id = 1,
    @os_run_priority = 0,
    @subsystem = N'PowerShell',
    @command = @tncCommand,
    @database_name = N'master',
    @flags = 40;

EXEC msdb.dbo.sp_update_job @job_id = @jobId,
    @start_step_id = 1;

EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
    @server_name = N'(local)';

-- Run on managed instance
IF EXISTS(SELECT * FROM sys.objects WHERE name = 'ExecuteNetHelper')
    THROW 70001, 'Stored procedure ExecuteNetHelper already exists. Rename or drop the existing procedure before creating it again.', 1
GO
CREATE PROCEDURE ExecuteNetHelper AS
-- To delete the procedure run: DROP PROCEDURE ExecuteNetHelper
BEGIN
    -- Start the job.
    DECLARE @NetHelperstartTimeUtc DATETIME = GETUTCDATE();
    DECLARE @stop_exec_date DATETIME = NULL;

    EXEC msdb.dbo.sp_start_job @job_name = N'NetHelper';

    -- Wait for job to complete and then see the outcome.
    WHILE (@stop_exec_date IS NULL)
    BEGIN
        -- Wait and see if the job has completed.
        WAITFOR DELAY '00:00:01'

        SELECT @stop_exec_date = sja.stop_execution_date
        FROM msdb.dbo.sysjobs sj
        INNER JOIN msdb.dbo.sysjobactivity sja
            ON sj.job_id = sja.job_id
        WHERE sj.name = 'NetHelper'

        -- If job has completed, get the outcome of the network test.
        IF (@stop_exec_date IS NOT NULL)
        BEGIN
            SELECT sj.name JobName,
                sjsl.date_modified AS 'Date executed',
                sjs.step_name AS 'Step executed',
                sjsl.log AS 'Connectivity status'
            FROM msdb.dbo.sysjobs sj
            LEFT JOIN msdb.dbo.sysjobsteps sjs
                ON sj.job_id = sjs.job_id
            LEFT JOIN msdb.dbo.sysjobstepslogs sjsl
                ON sjs.step_uid = sjsl.step_uid
            WHERE sj.name = 'NetHelper'
        END

        -- In case of operation timeout (90 seconds), print timeout message.
        IF (datediff(second, @NetHelperstartTimeUtc, getutcdate()) > 90)
        BEGIN
            SELECT 'NetHelper timed out during the network check. Please investigate SQL Agent logs for more information.'

            BREAK;
        END
    END
END;

-- Run on managed instance
EXEC ExecuteNetHelper;

-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO

Eseguire la migrazione di un certificato di un database protetto con TDE (facoltativo)

Se si collega un database di SQL Server protetto da Transparent Data Encryption (TDE) a un'istanza gestita, è necessario eseguire la migrazione del certificato di crittografia corrispondente dall'Istanza di SQL Server locale o della Macchina virtuale di Azure prima di usare il collegamento. Per i passaggi dettagliati, vedere Eseguire la migrazione del certificato di un database protetto tramite TDE a Istanza gestita di SQL di Azure.

I database di Istanza gestita di SQL che sono crittografati con chiavi TDE gestite dal servizio non possono essere collegati a SQL Server. È possibile collegare un database crittografato in SQL Server solo se è stato crittografato con una chiave gestita dal cliente e il server di destinazione ha accesso alla stessa chiave usata per crittografare il database. Per ulteriori informazioni, vedere Configurare TDE di SQL Server con Azure Key Vault.

Installare SSMS

SQL Server Management Studio (SSMS) è il modo più semplice per usare il collegamento a Istanza gestita. Scaricare SSMS versione 19.0 o successiva e installarla nel computer client.

Al termine dell'installazione, aprire SSMS e connettersi all'Istanza di SQL Server supportata. Fare clic con il pulsante destro del mouse su un database utente e verificare che l'opzione di collegamento di Istanza gestita di SQL di Azure sia visualizzata nel menu.

Configurare SSMS per i cloud per enti pubblici

Se si vuole distribuire l’Istanza gestita di SQL in un cloud per enti pubblici, è necessario modificare le impostazioni di SQL Server Management Studio (SSMS) per usare il cloud corretto. Se non si distribuisce l’Istanza gestita di SQL in un cloud per enti pubblici, ignorare questo passaggio.

Per aggiornare le impostazioni SSMS, effettuare le seguenti operazioni:

1. Aprire SSMS.
2. Dal menu, scegliere Strumenti, quindi selezionare Opzioni.
3. Espandere Servizi di Azure e selezionare Cloud di Azure.
4. In Selezionare un cloud di Azure, usare l'elenco a discesa per scegliere AzureUSGovernment o un altro cloud per enti pubblici, ad esempio AzureChinaCloud:

Per tornare al cloud pubblico, scegliere AzureCloud dall'elenco a discesa.

Contenuto correlato

Per usare il collegamento:

• Configurare il collegamento tra SQL Server e Istanza gestita di SQL con SSMS
• Configurare il collegamento tra SQL Server e istanza gestita di SQL con script
• Eseguire il failover con il collegamento
• Eseguire la migrazione con il collegamento
• Procedure consigliate per la gestione del collegamento

Per altre informazioni sul collegamento:

• Panoramica del collegamento a Istanza gestita
• Ripristino di emergenza con il collegamento all'istanza gestita

Per altri scenari di replica e migrazione, prendere in considerazione:

• Replica transazionale con Istanza gestita di SQL
• Servizio di riproduzione log (LRS)