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 e Istanza gestita di SQL di Azure.

Nota

È possibile automatizzare la preparazione dell’ambiente per il collegamento a Istanza gestita usando uno script scaricabile. Per altre informazioni, vedere il blog sulla configurazione automatica dei collegamenti.

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 gestita di SQL primaria a SQL Server secondario è supportata solo a partire da SQL Server 2022 CU10.

Attenzione

Quando si crea l'Istanza gestita di SQL da usare con la funzionalità di collegamento, tenere conto dei requisiti di memoria per le funzionalità OLTP in memoria usate da SQL Server. Per altre informazioni, vedere Panoramica dei limiti delle risorse di Istanza gestita di SQL di Azure.

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:

Risorsa Microsoft.Sql/	Autorizzazioni necessarie
Microsoft.Sql/managedInstances	/read, /write
Microsoft.Sql/managedInstances/hybridCertificate	/azione
Microsoft.Sql/managedInstances/databases	/read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups	/read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates	/read
Microsoft.Sql/managedInstances/hybridLink	/read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates	/write, /delete, /read

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 lo script T-SQL su 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'

Importante

Per SQL Server 2016 (13.x), se è necessario abilitare la funzionalità dei gruppi di disponibilità, occorre completare passaggi aggiuntivi documentati in Preparare i prerequisiti di SQL Server 2016 - Collegamento di Istanza gestita di SQL di Azure. Tali passaggi aggiuntivi non sono necessari per SQL Server 2019 (15.x) e versioni successive supportate dal collegamento.

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

Suggerimento

È consigliabile Usare ExpressRoute per ottenere prestazioni di rete ottimali quando si replicano i dati. Effettuare il provisioning di un gateway con larghezza di banda sufficiente per il caso d'uso.

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:

Ambiente	Operazione da eseguire
SQL Server (in Azure)	Aprire il traffico in entrata e in uscita sulla porta 5022 per il firewall di rete per l'intero intervallo di subnet IP dell'istanza gestita di SQL. Se necessario, eseguire la stessa operazione per il firewall del sistema operativo host di SQL Server (Windows/Linux). Per consentire la comunicazione sulla porta 5022, creare una regola del gruppo di sicurezza di rete (NSG) nella rete virtuale che ospita la macchina virtuale.
SQL Server (al di fuori di Azure)	Aprire il traffico in entrata e in uscita sulla porta 5022 per il firewall di rete per l'intero intervallo di subnet IP dell'istanza gestita di SQL. Se necessario, eseguire la stessa operazione per il firewall del sistema operativo host di SQL Server (Windows/Linux).
Istanza gestita di SQL	Creare una regola del gruppo di sicurezza di rete in portale di Azure per consentire il traffico in ingresso e in uscita dall'indirizzo IP e dalla rete che ospita SQL Server sulla porta 5022 e sull'intervallo di porte 11000-11999.

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:

Importante

• Le porte devono essere aperte in ogni firewall nell'ambiente di rete, compreso il server host, nonché tutti i firewall o i gateway aziendali sulla rete. Negli ambienti aziendali, potrebbe essere necessario mostrare all'amministratore di rete le informazioni contenute in questa sezione per consentire l'apertura di porte aggiuntive nel livello di rete aziendale.
• Sebbene sia possibile scegliere di personalizzare l'endpoint sul lato SQL Server, i numeri di porta per Istanza gestita di SQL non possono essere modificati o personalizzati.
• Gli intervalli di indirizzi IP delle subnet che ospitano istanze gestite e SQL Server non devono sovrapporsi.

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.

SSMS

Per testare la connettività di rete tra SQL Server e Istanza gestita di SQL in SSMS, seguire questa procedura:

1. Connettersi all'istanza che sarà la replica primaria in SSMS.

2. In Esplora oggetti, espandere i database e fare clic con il pulsante destro del mouse sul database che si intende collegare a quello secondario. Selezionare Attività>Collegamento a Istanza gestita di SQL di Azure>Testare la connessione per aprire la procedura guidata Controllo rete:

   

3. Selezionare Avanti nella pagina Introduzione della procedura guidata Controllo rete.

4. Se tutti i requisiti sono soddisfatti nella pagina Prerequisiti, selezionare Avanti. Altrimenti, risolvere eventuali prerequisiti non soddisfatti e quindi selezionare Esegui nuovamente la convalida.

5. Nella pagina Accedi, selezionare Accedi per connettersi all'altra istanza che sarà la replica secondaria. Selezionare Avanti.

6. Controllare i dettagli nella pagina Specifica opzioni di rete e specificare un indirizzo IP, se necessario. Selezionare Avanti.

7. Nella pagina Riepilogo, esaminare le azioni eseguite dalla procedura guidata, quindi selezionare Fine per testare la connessione tra le due repliche.

8. Esaminare la pagina Risultati per convalidare l'esistenza della connettività tra le due repliche, quindi selezionare Chiudi per terminare.

T-SQL

Per usare T-SQL per testare la connettività, occorre controllare la connessione in entrambe le direzioni. Per prima cosa, testare la connessione da SQL Server a Istanza gestita di SQL, quindi testare la connessione da Istanza gestita di SQL a SQL Server.

Testare la connessione da SQL Server a Istanza gestita di SQL

Usare SQL Server Agent in SQL Server per eseguire i test di connettività da SQL Server a Istanza gestita di SQL.

1. Connettersi a Istanza gestita di SQL ed eseguire lo script seguente per generare i parametri che saranno necessari in un secondo momento:

   SELECT 'DECLARE @serverName NVARCHAR(512) = N''' + value + ''''
   FROM sys.dm_hadr_fabric_config_parameters
   WHERE parameter_name = 'DnsRecordName'
   
   UNION
   
   SELECT 'DECLARE @node NVARCHAR(512) = N''' + NodeName + '.' + Cluster + ''''
   FROM (
       SELECT SUBSTRING(replica_address, 0, CHARINDEX('\', replica_address)) AS NodeName,
           RIGHT(service_name, CHARINDEX('/', REVERSE(service_name)) - 1) AppName,
           JoinCol = 1
       FROM sys.dm_hadr_fabric_partitions fp
       INNER JOIN sys.dm_hadr_fabric_replicas fr
           ON fp.partition_id = fr.partition_id
       INNER JOIN sys.dm_hadr_fabric_nodes fn
           ON fr.node_name = fn.node_name
       WHERE service_name LIKE '%ManagedServer%'
           AND replica_role = 2
   ) t1
   LEFT JOIN (
       SELECT value AS Cluster,
           JoinCol = 1
       FROM sys.dm_hadr_fabric_config_parameters
       WHERE parameter_name = 'ClusterName'
       ) t2
       ON (t1.JoinCol = t2.JoinCol)
   INNER JOIN (
       SELECT [value] AS AppName
       FROM sys.dm_hadr_fabric_config_parameters
       WHERE section_name = 'SQL'
           AND parameter_name = 'InstanceName'
       ) t3
       ON (t1.AppName = t3.AppName)
   
   UNION
   
   SELECT 'DECLARE @port NVARCHAR(512) = N''' + value + ''''
   FROM sys.dm_hadr_fabric_config_parameters
   WHERE parameter_name = 'HadrPort';
   

   I risultati saranno simili al campione seguente:

   

   Salvare i risultati per usare i passaggi successivi. Poiché questi parametri possono cambiare dopo un failover, assicurarsi di generarli nuovamente, se necessario.

2. Connettersi a SQL Server.

3. Aprire una nuova finestra Query e incollare lo script seguente:

   --START
   -- Parameters section
   DECLARE @node NVARCHAR(512) = N''
   DECLARE @port NVARCHAR(512) = N''
   DECLARE @serverName NVARCHAR(512) = N''
   
   --Script section
   IF EXISTS (
           SELECT job_id
           FROM msdb.dbo.sysjobs_view
           WHERE name = N'TestMILinkConnection'
           )
       EXEC msdb.dbo.sp_delete_job @job_name = N'TestMILinkConnection',
           @delete_unused_schedule = 1
   
   DECLARE @jobId BINARY (16),
       @cmd NVARCHAR(MAX)
   
   EXEC msdb.dbo.sp_add_job @job_name = N'TestMILinkConnection',
       @enabled = 1,
       @job_id = @jobId OUTPUT
   
   SET @cmd = (N'tnc ' + @serverName + N' -port 5022 | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')
   
   EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
       @step_name = N'Test Port 5022',
       @step_id = 1,
       @cmdexec_success_code = 0,
       @on_success_action = 3,
       @on_fail_action = 3,
       @subsystem = N'PowerShell',
       @command = @cmd,
       @database_name = N'master'
   
   SET @cmd = (N'tnc ' + @node + N' -port ' + @port + ' | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')
   
   EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
       @step_name = N'Test HADR Port',
       @step_id = 2,
       @cmdexec_success_code = 0,
       @subsystem = N'PowerShell',
       @command = @cmd,
       @database_name = N'master'
   
   EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
       @server_name = N'(local)'
   GO
   
   EXEC msdb.dbo.sp_start_job @job_name = N'TestMILinkConnection'
   GO
   
   --Check status every 5 seconds
   DECLARE @RunStatus INT
   
   SET @RunStatus = 10
   
   WHILE (@RunStatus >= 4)
   BEGIN
       SELECT DISTINCT @RunStatus = run_status
       FROM [msdb].[dbo].[sysjobhistory] JH
       INNER JOIN [msdb].[dbo].[sysjobs] J
           ON JH.job_id = J.job_id
       WHERE J.name = N'TestMILinkConnection'
           AND step_id = 0
   
       WAITFOR DELAY '00:00:05';
   END
   
   --Get logs once job completes
   SELECT [step_name],
       SUBSTRING([message], CHARINDEX('TcpTestSucceeded', [message]), CHARINDEX('Process Exit', [message]) - CHARINDEX('TcpTestSucceeded', [message])) AS    TcpTestResult,
       SUBSTRING([message], CHARINDEX('RemoteAddress', [message]), CHARINDEX('TcpTestSucceeded', [message]) - CHARINDEX('RemoteAddress', [message])) AS    RemoteAddressResult,
       [run_status],
       [run_duration],
       [message]
   FROM [msdb].[dbo].[sysjobhistory] JH
   INNER JOIN [msdb].[dbo].[sysjobs] J
       ON JH.job_id = J.job_id
   WHERE J.name = N'TestMILinkConnection'
       AND step_id <> 0
       --END
   

4. Sostituire i parametri @node, @port e @serverName con i valori ottenuti dal primo passaggio.

5. Eseguire lo script e controllare i risultati. Vengono visualizzati risultati simili all'esempio seguente:

   

6. Verificare i risultati:

   • Il risultato di ogni test su TcpTestSucceeded deve essere TcpTestSucceeded : True.
   • RemoteAddresses devono appartenere all'intervallo IP per la subnet Istanza gestita di SQL.

   Se la risposta ha esito negativo, verificare le impostazioni di rete seguenti:

   • Esistono regole nel firewall di rete e nel firewall del sistema operativo host di SQL Server (Windows/Linux) che consentono il traffico verso l'intero intervallo IP della subnet di Istanza gestita di SQL.
   • Esiste una regola del gruppo di sicurezza di rete che consente la comunicazione sulla porta 5022 per la rete virtuale che ospita Istanza gestita di SQL.

Testare la connessione da Istanza gestita di SQL a SQL Server

Per verificare che Istanza gestita di SQL possa raggiungere SQL Server, per prima cosa creare un endpoint di test. Usare quindi SQL Server Agent per eseguire uno script di PowerShell con il comando tnc che esegue il ping di SQL Server sulla porta 5022 dall'istanza gestita di SQL.

Per creare un endpoint di test, connettersi a SQL Server ed eseguire il seguente script T-SQL:

-- 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
    )

Per verificare che l'endpoint di SQL Server riceva le connessioni sulla porta 5022, eseguire il seguente comando di PowerShell nel sistema operativo host dell'istanza di SQL Server:

tnc localhost -port 5022

Un test con esito positivo mostra TcpTestSucceeded : True. È quindi possibile procedere alla creazione di un processo di SQL Server Agent nell'Istanza gestita di SQL per provare a testare l'endpoint di test di SQL Server sulla porta 5022 dall'Istanza gestita di SQL.

Successivamente, creare un processo di SQL Server Agent nell'Istanza gestita di SQL chiamata NetHelper eseguendo lo script T-SQL seguente nell'Istanza gestita di SQL. Sostituzione:

• <SQL_SERVER_IP_ADDRESS> con l'indirizzo IP di SQL Server a cui è possibile accedere dall'Istanza gestita di SQL.

-- 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)';

Suggerimento

Se è necessario modificare l'indirizzo IP di SQL Server per il probe di connettività dall'Istanza gestita di SQL, eliminare il processo NetHelper eseguendo EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper' e ricreare il processo NetHelper usando lo script precedente.

Creare, quindi, una stored procedure ExecuteNetHelper che consenta di eseguire il processo e di ottenere i risultati dal probe di rete. Eseguire lo script T-SQL seguente nell'Istanza gestita di SQL:

-- 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;

Eseguire la query seguente nell'Istanza gestita di SQL per eseguire la stored procedure che eseguirà il processo dell'agente NetHelper e visualizzerà il log risultante:

-- Run on managed instance
EXEC ExecuteNetHelper;

Se la connessione ha avuto esito positivo, il log visualizza True. Se la connessione ha avuto esito negativo, il log visualizza False.

Se la connessione ha avuto esito negativo, verificare gli elementi seguenti:

• Il firewall nell'Istanza di SQL Server host consente la comunicazione in ingresso e in uscita sulla porta 5022.
• Una regola del gruppo di sicurezza di rete per la rete virtuale che ospita Istanza gestita di SQL consente la comunicazione sulla porta 5022.
• Se l’Istanza di SQL Server si trova in una Macchina virtuale di Azure, una regola del gruppo di sicurezza di rete consente la comunicazione sulla porta 5022 nella rete virtuale che ospita la Macchina virtuale.
• Il SQL Server è in esecuzione.
• Esiste un endpoint di test su SQL Server.

Dopo aver risolto i problemi, eseguire nuovamente il probe di rete NetHelper eseguendo EXEC ExecuteNetHelper nell'istanza gestita.

Infine, dopo aver completato correttamente il test di rete, eliminare l'endpoint di test e il certificato in SQL Server usando i comandi T-SQL seguenti:

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

Attenzione

Procedere con i passaggi successivi soltanto se è stata convalidata la connettività di rete tra gli ambienti di origine e di destinazione. Altrimenti, risolvere i problemi di connettività di rete prima di procedere.

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

• Panoramica della funzionalità di collegamento a Istanza gestita
• 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