Partager via

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.

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.
  • Version prise en charge de SQL Server avec la mise à jour de service requise.
  • Azure SQL Managed Instance. Commencez si vous n’en avez pas.
  • Serveur que vous envisagez d’être le serveur principal initial. Ce choix détermine l’emplacement à partir duquel vous devez créer le lien.

Attention

Lorsque vous créez votre instance managée SQL à utiliser avec la fonctionnalité de liaison, prenez en compte les exigences de mémoire pour toutes In-Memory les fonctionnalités OLTP (traitement transactionnel en ligne) 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 (lecture, écriture)
Microsoft.Sql/managedInstances/hybridCertificate /action
Microsoft.Sql/managedInstances/databases /lecture, /suppression, /écriture, /restaurationComplète/action, /lectureSauvegardes/action, /détailsRestauration/lecture
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /lire, /écrire, /supprimer, /définirRôle/action
Microsoft.Sql/managedInstances/endpointCertificates /read
Microsoft.Sql/managedInstances/hybridLink /lire, /écrire, /supprimer
Microsoft.Sql/managedInstances/serverTrustCertificates /écrire, /supprimer, /lire

Préparer votre instance SQL Server

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

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

Le lien utilise des certificats pour chiffrer l’authentification et la communication entre SQL Server et SQL Managed Instance. La clé principale de base de données protège les certificats utilisés par le lien. Si vous disposez déjà d’une clé principale de base de données, vous pouvez ignorer cette étape.

Créez une clé principale de base de données dans la master base de données. 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.

Remarque

Pour SQL Server sur Linux, consultez Activer groupes de disponibilité Always On.

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 avez besoin d’activer la fonctionnalité groupes de disponibilité, vous devez suivre les étapes supplémentaires décrites dans préparer les prérequis sql Server 2016 - Lien Azure SQL Managed Instance. Ces étapes supplémentaires ne sont pas requises pour SQL Server 2017 (14.x) et les versions ultérieures prises en charge par le lien.

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.

    Capture d’écran montrant le Gestionnaire de configuration SQL Server, avec des sélections pour l’ouverture de propriétés pour le service.

  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.

    Capture d’écran montrant les propriétés des groupes de disponibilité Always On.

  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.

Remarque

Pour SQL Server sur Linux, consultez Activer les indicateurs de trace.

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.

    Capture d’écran montrant le Gestionnaire de configuration SQL Server.

  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.

    Capture d’écran montrant les propriétés du paramètre de démarrage.

  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.

    Capture d’écran montrant l’appel de commande de redémarrage de SQL Server.

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 illustre le résultat attendu d’une instance SQL Server correctement configurée :

Capture d’écran montrant le résultat attendu dans SSMS.

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 des machines virtuelles Azure dans le même réseau virtuel Azure qui héberge SQL Managed Instance est la méthode la plus simple, car la connectivité réseau existe automatiquement 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 des machines virtuelles Azure se trouve dans un réseau virtuel différent de votre instance managée SQL, vous devez connecter les deux réseaux virtuels. Les réseaux virtuels n’ont pas besoin d’être dans le même abonnement pour que ce scénario fonctionne.

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

Le peering est préférable, car il utilise le réseau principal Microsoft. Par conséquent, du point de vue de la connectivité, il n'y a aucune différence notable de latence entre les machines virtuelles dans un réseau virtuel appairé et celles dans le même réseau virtuel. Le couplage de réseaux virtuels est pris en charge entre les réseaux de la 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 :

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 SQL Managed Instance 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)

Diagramme montrant la configuration réseau requise pour configurer le lien entre SQL Server et SQL Managed Instance.

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 de groupe de sécurité réseau dans le portail Azure pour autoriser le trafic entrant et sortant à partir de l’adresse IP et la mise en réseau qui héberge SQL Server sur le port 5022 et la plage de ports 11000-11999.

Pour ouvrir des ports dans le Pare-feu Windows, utilisez le script PowerShell suivant sur le système d’exploitation hôte Windows de l’instance SQL Server :

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 :

Diagramme montrant l’infrastructure réseau pour configurer le lien entre SQL Server et SQL Managed Instance.

Important

  • Les ports doivent être ouverts dans chaque pare-feu dans l’environnement de mise en réseau, y compris le serveur hôte, ainsi que 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

Selon vos paramètres de sécurité réseau, il peut être nécessaire d’ajouter des URL à votre liste d’autorisation pour le nom de domaine complet SQL Managed Instance et certains des points de terminaison Resource Management 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 : managedinstance.a1b2c3d4e5f6.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.

Remarque

L’exécution de scripts PowerShell par l’agent SQL Server sur SQL Server sur Linux n’est pas prise en charge actuellement. Il n’est donc pas possible d’exécuter Test-NetConnection à partir du projet SQL Server Agent sur SQL Server sur Linux.

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.

Tenez compte des éléments suivants :

  • Pour éviter les faux négatifs, tous les pare-feu le long du chemin d’accès réseau doivent autoriser le trafic ICMP (Internet Control Message Protocol).
  • Pour éviter les faux positifs, tous les pare-feu le long du chemin réseau doivent autoriser le trafic sur le protocole UCS SQL Server propriétaire. Le blocage du protocole peut entraîner un test de connexion réussi, mais le lien ne parvient pas à créer.
  • Les configurations avancées de pare-feu avec des garde-fous au niveau des paquets doivent être correctement configurées pour permettre correctement le trafic entre SQL Server et SQL Managed Instance.

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 :

    Capture d’écran de l’Explorateur d’objets dans SSMS, avec la connexion de test sélectionnée dans le menu contextuel du lien de base de données.

  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.

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) à une instance managée SQL, vous devez migrer le certificat de chiffrement correspondant de l’instance SQL Server locale ou de machine virtuelle Azure vers l’instance managée SQL avant d’utiliser le lien. 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 ne pouvez lier une base de données chiffrée qu’à SQL Server si elle a été chiffrée avec une clé gérée par le client et que le serveur de destination a accès à la même clé utilisée pour chiffrer la base de données. Pour plus d’informations, consultez Configurer SQL Server TDE avec Azure Key Vault.

Remarque

Azure Key Vault est pris en charge par SQL Server sur Linux à partir de la mise à jour cumulative 14 pour SQL Server 2022.

Installation de SSMS

SQL Server Management Studio (SSMS) est le moyen le plus simple d’utiliser une liaison Managed Instance. Installez la dernière version de SQL Server Management Studio (SSMS) 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.

Capture d’écran montrant l’option de lien Azure SQL Managed Instance sur le menu contextuel.

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 :

Capture d’écran de l’interface utilisateur de SSMS, page d’options, services Azure, avec le cloud Azure mis en évidence.

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

Contenu connexe

Pour utiliser le lien :

Pour en savoir plus sur le lien :

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

  • Last updated on