Préparer votre environnement pour une liaison - Azure SQL Managed Instance

S’applique à :Azure SQL Managed Instance

Cet article vous apprend à préparer votre environnement pour une liaison Managed Instance pour pouvoir répliquer entre SQL Server et Azure SQL Managed Instance.

Remarque

Vous pouvez automatiser la préparation de votre environnement pour la liaison Managed Instance en utilisant un script téléchargeable. Pour en savoir plus, reportez-vous au Automatiser le blog d'installation de liaison.

Prérequis

Pour créer une liaison entre SQL Server et Azure SQL Managed Instance, vous devez remplir les conditions préalables suivantes :

• Un abonnement Azure actif. Si vous n’en avez pas, créez un compte gratuit.
• Une version prise en charge de SQL Server avec la mise à jour de service requise.
• Azure SQL Managed Instance. Effectuez une prise en main si vous ne l’avez pas
• Décidez du serveur qui sera le serveur primaire pour déterminer le lieu où vous devez créer la liaison. La configuration d'une liaison de SQL Managed Instance primaire vers SQL Server secondaire n'est prise en charge qu'à partir de SQL Server 2022 CU10.

Attention

Lorsque vous créez votre SQL Managed Instance pour l'utiliser avec la fonction de liaison, tenez compte de la mémoire requise pour toutes les fonctions OLTP en mémoire utilisées par SQL Server. Pour plus d’informations, consultez Vue d’ensemble des limites de ressources Azure SQL Managed Instance.

Autorisations

Pour SQL Server, vous devez disposer des autorisations sysadmin.

Pour Azure SQL Managed Instance, vous devez être membre du rôle Contributeur SQL Managed Instance ou disposer des autorisations suivantes pour un rôle personnalisé :

Ressource Microsoft.Sql/	Autorisations nécessaires
Microsoft.Sql/managedInstances	/read, /write
Microsoft.Sql/managedInstances/hybridCertificate	/action
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

Préparer votre instance SQL Server

Pour préparer votre instance SQL Server, vous devez confirmer que :

• Vous êtes sur la version minimale prise en charge.
• Vous avez activé la fonctionnalité de groupes de disponibilité.
• Vous avez ajouté les indicateurs de trace appropriés au démarrage.
• Vos bases de données sont en mode de récupération complète et sauvegardées.

Vous devez redémarrer SQL Server pour que ces modifications soient prises en compte.

Installer des mises à jour du service

Assurez-vous que la version de SQL Server dispose de la mise à jour appropriée installée, comme indiqué dans la table de compatibilité de version. Si vous devez installer des mises à jour, vous devez redémarrer votre instance SQL Server pendant la mise à jour.

Pour vérifier votre version de SQL Server, exécutez le script Transact-SQL (T-SQL) suivant sur SQL Server :

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

Créer une clé principale de base de données dans la base de données master

Créez une clé principale de base de données dans la base de données master, s'il n'y en a pas. Insérez votre mot de passe à la place de <strong_password> dans le script suivant et conservez-le dans un lieu confidentiel et sûr. Exécutez ce script T-SQL sur SQL Server :

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

Pour vérifier que vous disposez de la clé principale de base de données, utilisez le script T-SQL suivant sur SQL Server :

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

Activer des groupes de disponibilité

La fonction de liaison repose sur la fonction de groupes de disponibilité Always On, qui est désactivée par défaut. Pour plus d’informations, consultez Activer la fonctionnalité Groupes de disponibilité AlwaysOn.

Pour confirmer que la fonctionnalité de groupes de disponibilité est activée, exécutez le script T-SQL suivant sur 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'

Important

Pour SQL Server 2016 (13.x), si vous devez activer la fonctionnalité de groupes de disponibilité, vous devez suivre des étapes supplémentaires décrites dans Prérequis pour préparer SQL Server 2016 - Liaison Azure SQL Managed Instance. Ces étapes supplémentaires ne sont pas requises pour SQL Server 2019 (15.x) et les versions ultérieures que le lien prend en charge.

Si la fonctionnalité de groupes de disponibilité n’est pas activée, procédez comme suit pour l’activer :

1. Ouvrez le Gestionnaire de configuration SQL Server.

2. Sélectionnez Services SQL Server dans le volet gauche.

3. Cliquez avec le bouton droit sur le service SQL Server, puis sélectionnez Propriétés.

   

4. Accédez à l’onglet Groupes de disponibilité Always On.

5. Sélectionnez la case à cocher Activer les groupes de disponibilité Always On, puis sélectionnez OK.

   

   • Si vous utilisez SQL Server 2016 (13.x) et si l’option Activer des groupes de disponibilité Always On est désactivée avec le message This computer is not a node in a failover cluster., suivez les étapes supplémentaires décrites dans Prérequis pour préparer SQL Server 2016 – liaison Azure SQL Managed Instance. Une fois ces autres étapes accomplies, revenez en arrière et réessayez cette étape.

6. Sélectionnez OK dans la boîte de dialogue.

7. Redémarrez le service SQL Server.

Activer les indicateurs de trace de démarrage

Pour optimiser les performances de votre liaison, nous vous recommandons d'activer les indicateurs de trace suivants au démarrage :

• -T1800 : cet indicateur de trace optimise les performances lorsque les fichiers journaux des réplicas principal et secondaire dans un groupe de disponibilité sont hébergés sur des disques avec des tailles de secteur différentes (par exemple 512 octets et 4 Ko). Si les réplicas principal et secondaire ont une taille de secteur de disque de 4 Ko, cet indicateur de trace n’est pas nécessaire. Pour plus d’informations, consultez l’article KB3009974 de la Base de connaissances.
• -T9567 : cet indicateur de trace active la compression du flux de données pour les groupes de disponibilité au cours de l’amorçage automatique. La compression augmente la charge sur le processeur, mais peut réduire considérablement le temps de transfert pendant l’amorçage.

Pour activer ces indicateurs de trace au démarrage, effectuez les étapes suivantes :

1. Ouvrez le Gestionnaire de configuration SQL Server.

2. Sélectionnez Services SQL Server dans le volet gauche.

3. Cliquez avec le bouton droit sur le service SQL Server, puis sélectionnez Propriétés.

   

4. Accédez à l’onglet Paramètres de démarrage. Dans Spécifier un paramètre de démarrage, entrez -T1800, puis sélectionnez Ajouter pour ajouter le paramètre de démarrage. Ensuite, entrez -T9567 et sélectionnez Ajouter pour ajouter l’autre indicateur de trace. Sélectionnez Appliquer pour enregistrer vos modifications.

   

5. Cliquez sur OK pour fermer la fenêtre Propriétés.

Pour en savoir plus, reportez-vous à la syntaxe permettant d'activer les indicateurs de trace.

Redémarrer SQL Server et valider la configuration

Une fois que vous avez vérifié que vous disposez d’une version prise en charge de SQL Server, activé la fonctionnalité de groupes de disponibilité Always On et ajouté vos indicateurs de trace de démarrage, redémarrez votre instance SQL Server pour appliquer toutes ces modifications :

1. Ouvrez le Gestionnaire de configuration SQL Server.

2. Sélectionnez Services SQL Server dans le volet gauche.

3. Cliquez avec le bouton droit sur le service SQL Server, puis sélectionnez Redémarrer.

   

Après le redémarrage, exécutez le script T-SQL suivant sur SQL Server pour valider la configuration de votre instance de 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;

Votre version de SQL Server devrait être l'une des versions prises en charge et appliquées avec les mises à jour de service appropriées. La fonctionnalité de groupes de disponibilité Always On, ainsi que les indicateurs de trace -T1800 et -T9567 devraient être activés. La capture d'écran suivante est un exemple du résultat attendu pour une instance de SQL Server correctement configurée :

Configurer la connectivité réseau

Pour que la liaison fonctionne, vous devez disposer d’une connectivité réseau entre SQL Server et SQL Managed Instance. L'option de réseau que vous choisissez dépend du fait que votre instance SQL Server se trouve ou non sur un réseau Azure.

SQL Server sur les machines virtuelles Azure

Le déploiement de SQL Server sur Machines virtuelles Azure dans le réseau virtuel Azure qui héberge SQL Managed Instance est la méthode la plus simple, car il existera automatiquement une connectivité réseau entre les deux instances. Pour plus d’informations, consultez Démarrage rapide : Configurer une machine virtuelle Azure pour qu’elle se connecte à Azure SQL Managed Instance.

Si votre instance SQL Server sur les machines virtuelles Azure se trouve dans un réseau virtuel différent de votre instance managée, vous devez établir une connexion entre les deux réseaux virtuels. Pour que ce scénario fonctionne, les réseaux virtuels ne doivent pas nécessairement être dans le même abonnement.

Il existe deux options pour connecter des réseaux virtuels :

• Peering de réseaux virtuels Azure
• Passerelle VPN de réseau virtuel à réseau virtuel (portail Azure, PowerShell, Azure CLI)

Le peering est préférable parce qu'il utilise le réseau dorsal de Microsoft. Du point de vue de la connectivité, il n'existe donc aucune différence notable de latence entre les machines virtuelles d'un réseau virtuel peerisé et celles du même réseau virtuel. Le peering de réseaux virtuels est pris en charge entre les réseaux d’une même région. L’appairage de réseaux virtuels global est pris en charge pour les instances hébergées dans des sous-réseaux créés après le 22 septembre 2020. Pour plus d’informations, consultez la Foire aux questions (FAQ).

SQL Server en dehors d’Azure

Si votre instance de SQL Server est hébergée en dehors d’Azure, établissez une connexion VPN entre SQL Server et SQL Managed Instance avec l’une ou l’autre des options suivantes :

• Connexion VPN site à site
• Connexion Azure ExpressRoute

Conseil

Nous vous recommandons d’utiliser ExpressRoute pour optimiser les performances du réseau lors de la réplication des données. Provisionnez une passerelle avec assez de bande passante pour votre cas d’usage.

Ports réseau entre les environnements

Quel que soit le mécanisme de connexion, il existe des exigences qui doivent être satisfaites pour que le trafic réseau circule entre les environnements :

Les règles de Groupe de sécurité réseau (NSG) sur le sous-réseau hébergeant l’instance gérée doivent autoriser :

• Port entrant 5022 et plage de ports 11000-11999 pour recevoir le trafic de l’IP source SQL Server
• Port sortant 5022 pour envoyer le trafic vers l’IP de destination SQL Server

Tous les pare-feu sur le réseau hébergeant SQL Server, et le système d’exploitation hôte doit autoriser :

• Port entrant 5022 ouvert pour recevoir le trafic à partir de la plage IP source du sous-réseau MI /24 (par exemple 10.0.0.0/24)
• Les ports de sortie 5022 et la plage de ports 11000 à 11999 ouverts devant envoyer le trafic vers la plage d'adresses IP de destination du sous-réseau MI (exemple 10.0.0.0/24)

Le tableau suivant décrit les actions de port pour chaque environnement :

Environnement	Procédure à suivre
SQL Server (dans Azure)	Ouvrez le trafic entrant et sortant sur le port 5022 pour le pare-feu réseau vers la plage d’adresses IP de sous-réseau entière de SQL Managed Instance. Si nécessaire, faites de même sur le pare-feu du système d’exploitation hôte (Windows/Linux) de SQL Server. Pour autoriser la communication sur le port 5022, créez une règle de groupe de sécurité réseau (NSG) dans le réseau virtuel qui héberge la machine virtuelle.
SQL Server (en dehors d’Azure)	Ouvrez le trafic entrant et sortant sur le port 5022 pour le pare-feu réseau vers la plage d’adresses IP de sous-réseau entière de SQL Managed Instance. Si nécessaire, faites de même sur le pare-feu du système d’exploitation hôte (Windows/Linux) de SQL Server.
Instance managée SQL	Créez une règle NSG dans le portail Azure pour autoriser le trafic entrant et sortant en lien avec l’adresse IP et le réseau hébergeant SQL Server sur le port 5022 et la plage de ports 11000-11999.

Utilisez le script PowerShell suivant sur le système d’exploitation hôte Windows de l’instance SQL Server pour ouvrir des ports dans le pare-feu Windows :

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

Le diagramme suivant montre un exemple d’environnement réseau local, indiquant que tous les pare-feux de l’environnement doivent avoir des ports ouverts, y compris le pare-feu du système d’exploitation hébergeant le SQL Server et les pare-feu et/ou passerelles d’entreprise :

Important

• Les ports doivent être ouverts dans chaque pare-feu de l’environnement réseau, y compris le serveur hôte, ainsi que dans tous les pare-feu ou passerelles d’entreprise sur le réseau. Dans les entreprises, il se peut que vous deviez montrer à votre administrateur réseau les informations de cette section pour l'aider à ouvrir des ports supplémentaires dans la couche réseau de l'entreprise.
• Même si vous pouvez choisir de personnaliser le point de terminaison côté SQL Server, les numéros de port de SQL Managed Instance ne peuvent être ni changés ni personnalisés.
• Les plages d’adresses IP des sous-réseaux hébergeant les instances managées et SQL Server ne doivent pas se chevaucher.

Ajouter des URL à la liste d'autorisation

En fonction des paramètres de sécurité de votre réseau, il peut être nécessaire d'ajouter à votre liste d'autorisation les URL du FQDN de SQL Managed Instance et certains des points de terminaison de la gestion des ressources utilisés par Azure.

La liste suivante liste les ressources qui doivent être ajoutées à votre liste d'autorisation :

• Nom de domaine complet (FQDN) de votre SQL Managed Instance. Par exemple : managedinstance1.6d710bcf372b.database.windows.net.
• Autorité Microsoft Entra
• ID de ressource du point de terminaison Microsoft Entra
• Point de terminaison Resource Manager
• Point de terminaison de service

Suivez les étapes de la section Configurer SSMS pour les clouds d'administration pour accéder à l'interface Outils dans SQL Server Management Studio (SSMS) et identifier les URL spécifiques pour les ressources de votre cloud que vous devez ajouter à votre liste d'autorisation.

Testez la connectivité réseau

La connectivité réseau bidirectionnelle entre SQL Server et SQL Managed Instance est nécessaire pour que la liaison fonctionne. Après avoir ouvert les ports du côté du SQL Server et configuré une règle NSG du côté de SQL Managed Instance, testez la connectivité à l'aide de SQL Server Management Studio (SSMS) ou de Transact-SQL.

SSMS

Pour tester la connectivité réseau entre SQL Server et SQL Managed Instance dans SSMS, procédez comme suit :

1. Connectez-vous à l'instance qui sera le réplica principal dans SSMS.

2. Dans l'Explorateur d'objets, développez les bases de données et faites un clic droit sur la base de données que vous souhaitez lier à la réplica secondaire. Sélectionnez Tâches>liaison Azure SQL Managed Instance> Tester la connexion pour ouvrir l'Assistant Network Checker :

   

3. Sélectionnez Suivant sur la page Introduction de l'Assistant Network Checker.

4. Si toutes les conditions requises sont remplies sur la page Conditions préalables, sélectionnez Suivant. Dans le cas contraire, résolvez toutes les conditions préalables non remplies, puis sélectionnez Réexécuter la validation.

5. Sur la page Connexion, sélectionnez Connexion pour vous connecter à l'autre instance qui sera la réplica secondaire. Cliquez sur Suivant.

6. Vérifiez les détails de la page Spécifier les options de réseau et fournissez une adresse IP, si nécessaire. Cliquez sur Suivant.

7. Sur la page Résumé, passez en revue les actions effectuées par l'Assistant, puis sélectionnez Terminer pour tester la connexion entre les deux réplicas.

8. Passez en revue la page Résultats pour valider la connectivité qui existe entre les deux réplicas, puis sélectionnez Fermer pour terminer.

T-SQL

Pour utiliser T-SQL afin de tester la connectivité, vous devez vérifier la connexion dans les deux sens. Testez d'abord la connexion de SQL Server à SQL Managed Instance, puis la connexion de SQL Managed Instance à SQL Server.

Tester la connexion entre SQL Server et SQL Managed Instance

Utilisez SQL Server Agent sur SQL Server pour exécuter des tests de connectivité de SQL Server vers SQL Managed Instance.

1. Connectez-vous à SQL Managed Instance et exécutez le script suivant pour générer les paramètres dont vous aurez besoin ultérieurement :

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

   Les résultats devraient ressembler à l'échantillon suivant :

   

   Enregistrez les résultats à utiliser dans les étapes suivantes. Comme ces paramètres peuvent changer après un basculement, veillez à les générer à nouveau, si nécessaire.

2. Connectez-vous à SQL Server.

3. Ouvrez une nouvelle fenêtre Requête et collez le script suivant :

   --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. Remplacez les paramètres @node, @port et @serverName avec les valeurs obtenues à la première étape.

5. Exécutez le script et vérifiez les résultats. Vous devriez obtenir des résultats comme ceux de l'échantillon suivant :

   

6. Vérifiez les résultats :

   • Le résultat de chaque test doit être TcpTestSucceeded : True pour TcpTestSucceeded.
   • Les adresses RemoteAddresses doivent être comprises dans la plage d’adresses IP du sous-réseau SQL Managed Instance.

   Si la réponse échoue, vérifiez les paramètre réseau suivants :

   • Il existe des règles dans le pare-feu réseau et le pare-feu du système d’exploitation (Windows/Linux) hôte de SQL Server qui autorisent le trafic vers la plage d’adresses IP de sous-réseau entière de SQL Managed Instance.
   • Il existe une règle NSG qui autorise la communication sur le port 5022 pour le réseau virtuel qui héberge SQL Managed Instance.

Tester la connexion entre SQL Managed Instance et SQL Server

Pour vérifier que SQL Managed Instance peut atteindre SQL Server, créez d'abord un point de terminaison de test. Ensuite, utilisez SQL Server Agent pour exécuter un script PowerShell avec la commande tnc qui effectue un test Ping sur SQL Server sur le port 5022 à partir de SQL Managed Instance.

Pour créer un point de terminaison de test, connectez-vous à SQL Server et exécutez le script (T-SQL) suivant :

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

Pour vérifier que le point de terminaison SQL Server reçoit des connexions sur le port 5022, exécutez la commande PowerShell suivante sur le système d’exploitation hôte de votre instance de SQL Server :

tnc localhost -port 5022

Les tests réussis affichent TcpTestSucceeded : True. Vous pouvez ensuite créer une tâche SQL Server Agent sur SQL Managed Instance pour essayer de tester le point de terminaison de test SQL Server sur le port 5022 à partir de SQL Managed Instance.

Puis, créez une tâche SQL Server Agent sur SQL Managed Instance appelée NetHelper en exécutant le script T-SQL suivant sur SQL Managed Instance. Remplacez :

• <SQL_SERVER_IP_ADDRESS> par l'adresse IP de SQL Server accessible à partir de SQL Managed Instance.

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

Conseil

Si vous devez modifier l'adresse IP de votre serveur SQL pour la sonde de connectivité de SQL Managed Instance, supprimez la tâche NetHelper en exécutant EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper', et recréez la tâche NetHelper en utilisant le script précédent.

Ensuite, créez une procédure stockée ExecuteNetHelper qui facilite l’exécution du travail et recueille les résultats de la sonde réseau. Exécutez le script T-SQL suivant sur SQL Managed Instance :

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

Exécutez la requête suivante sur SQL Managed Instance pour exécuter la procédure stockée qui exécutera la tâche de l'agent NetHelper, et affichera le journal obtenu :

-- Run on managed instance
EXEC ExecuteNetHelper;

Si la connexion aboutit, le journal affiche True. Si la connexion n’aboutit pas, le journal affiche False.

Si la connexion n’aboutit pas, vérifiez les points suivants :

• Le pare-feu sur l’instance de SQL Server hôte autorise les communications entrantes et sortantes sur le port 5022.
• Une règle NSG pour le réseau virtuel qui héberge l’instance SQL Managed Instance autorise la communication sur le port 5022.
• Si votre instance de SQL Server se trouve sur une machine virtuelle Azure, une règle NSG autorise la communication sur le port 5022 sur le réseau virtuel qui héberge la machine virtuelle.
• SQL Server est en cours d’exécution.
• Il existe un point de terminaison de test sur SQL Server.

Après avoir résolu les problèmes, réexécutez la sonde réseau NetHelper en exécutant EXEC ExecuteNetHelper sur une instance gérée.

Enfin, une fois test réseau réussi, supprimez le point de terminaison de test et le certificat sur SQL Server en utilisant les commandes T-SQL suivantes :

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

Attention

Passez aux étapes suivantes uniquement si vous avez validé la connectivité réseau entre vos environnements source et cible. Sinon, corrigez les problèmes de connectivité réseau avant de continuer.

Migrer un certificat d’une base de données protégée par TDE (facultatif)

Si vous liez une base de données SQL Server protégée par Transparent Data Encryption (TDE) vers une Managed Instance, vous devez migrer le certificat de chiffrement correspondant de l'instance SQL Server local ou de machine virtuelle Azure vers la Managed Instance avant d'utiliser la liaison. Pour des étapes détaillées, consultez Migrer vers Azure SQL Managed Instance un certificat d’une base de données protégée par TDE.

Les bases de données SQL Managed Instance qui sont chiffrées avec des clés TDE managées par le service ne peuvent pas être liées à SQL Server. Vous pouvez lier une base de données chiffrée vers SQL Server uniquement si elle a été chiffrée avec une clé gérée par le client et si le serveur de destination a accès à la même clé que celle utilisée pour chiffrer la base de données. Pour plus d’informations, consultez Configurer SQL Server TDE avec Azure Key Vault.

Installation de SSMS

SQL Server Management Studio (SSMS) est le moyen le plus simple d’utiliser une liaison Managed Instance. Téléchargez SSMS version 19.0 ou ultérieure et installez-la sur votre ordinateur client.

Une fois l’installation terminée, ouvrez SSMS et connectez-vous à votre instance de SQL Server prise en charge. Cliquez avec le bouton droit sur une base de données utilisateur et vérifiez que l’option Liaison Azure SQL Managed Instance s’affiche dans le menu.

Configurer SSMS pour les clouds publics

Si vous voulez déployer votre SQL Managed Instance sur un cloud gouvernemental, vous devez modifier vos paramètres SQL Server Management Studio (SSMS) pour utiliser le cloud approprié. Si vous ne déployez pas votre SQL Managed Instance sur un cloud public, ignorez cette étape.

Pour mettre à jour vos paramètres SSMS, effectuez ces étapes :

1. Ouvrez SSMS.
2. Dans le menu, choisissez Outils, puis choisissez Options.
3. Développez Services Azure et sélectionnez Cloud Azure.
4. Sous Sélectionner un cloud Azure, utilisez la liste déroulante pour choisir AzureUSGovernment ou un autre cloud de secteur public, comme AzureChinaCloud :

Si vous souhaitez revenir au cloud public, choisissez AzureCloud dans la liste déroulante.

Contenu connexe

• Vue d’ensemble de la fonctionnalité de liaison Managed Instance
• Configurer la liaison entre SQL Server et SQL Managed Instance avec SSMS
• Configurer la liaison entre SQL Server et SQL Managed Instance avec les scripts