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 le programme d’installation de SQL Server sur Windows ou sur Linux et Azure SQL Managed Instance.

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’un lien de SQL Managed Instance principale vers SQL Server secondaire n’est prise en charge qu’à partir de SQL Server 2022 CU10 et par les instances configurées avec la stratégie de mise à jour de SQL Server 2022.

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é :

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'

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 :

• Appairage 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

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)
• Ports sortants 5022 et plage de ports 11000-11999 ouverts pour envoyer le trafic vers la plage 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 :

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 :

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.

Testez le réseau en créant un projet SQL Agent temporaire sur SQL Server et SQL Managed Instance pour vérifier la connectivité entre les deux instances. Lorsque vous utilisez Vérificateur de réseau dans SSMS, le projet est automatiquement créé pour vous et supprimé une fois le test terminé. Vous devez supprimer manuellement le projet SQL Agent si vous testez votre réseau à l’aide de T-SQL.

Pour utiliser SQL Agent pour tester la connectivité réseau, vous avez besoin des exigences suivantes :

• L’utilisateur qui effectue le test doit disposer des autorisations pour créer un projet (en tant qu’administrateur système ou il appartient au rôle SQLAgentOperator pour msdb) pour SQL Server et SQL Managed Instance.
• Le service SQL Server Agent doit être en cours d’exécution sur SQL Server. Étant donné que l’Agent est activé par défaut sur SQL Managed Instance, aucune action supplémentaire n’est nécessaire.

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

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 du secteur public

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

Pour utiliser le lien :

• 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
• Basculez le lien
• Migrer avec le lien
• Meilleures pratiques pour préserver la liaison

Pour en savoir plus sur le lien :

• Liaison Managed Instance – Vue d’ensemble
• Récupération d’urgence avec la liaison Managed Instance

Pour d’autres scénarios de réplication et de migration, considérez :

• Réplication transactionnelle avec SQL Managed Instance
• Service LRS