Vue d’ensemble de la liaison Managed Instance

S’applique à :Azure SQL Managed Instance

Cet article fournit une vue d’ensemble de la liaison Managed Instance, qui permet une réplication des données en quasi-temps réel entre SQL Server et Azure SQL Managed Instance. Cette liaison offre une flexibilité hybride et une mobilité de la base de données en déverrouillant plusieurs scénarios, comme la mise à l’échelle des charges de travail en lecture seule, le déchargement des analyses et des rapports vers Azure, et la migration vers Azure. De plus, avec SQL Server 2022, le lien permet la récupération d'urgence en ligne avec retour à SQL Server après un échec, ainsi que la configuration du lien de SQL Managed Instance vers SQL Server 2022.

Pour commencer, passez en revue Préparer votre environnement pour la liaison.

Vue d’ensemble

Le lien Managed Instance utilise des groupes de disponibilité distribués pour étendre votre infrastructure de données de manière sûre et sécurisée. Il réplique les données en quasi-temps réel de SQL Server hébergées n’importe où vers Azure SQL Managed Instance, ou d’Azure SQL Managed Instance vers SQL Server 2022 hébergée n’importe où.

La liaison prend en charge les instances SQL Server à nœud unique et à nœuds multiples, avec ou sans groupes de disponibilité existants. Grâce à cette liaison, vous pouvez profiter des avantages d’Azure sans migrer vos données SQL Server vers le cloud.

Bien que le lien prenne en charge la réplication d’une base de données par lien, vous pouvez répliquer plusieurs bases de données d’une instance unique de SQL Server vers une ou plusieurs instances managées SQL, ou répliquer la même base de données sur plusieurs instances managées SQL, en configurant plusieurs liens - un lien pour chaque base de données vers une paire d’instances managées.

La fonctionnalité de liaison offre actuellement les possibilités suivantes :

• réplication unidirectionnelle à partir de SQL Server versions 2016, 2017 et 2019: utilisez la fonctionnalité de liaison pour répliquer les données d’une façon unique de l’instance SQL vers Azure SQL Managed Instance. Bien que vous puissiez effectuer un basculement manuel vers votre instance managée en cas de sinistre, cela interrompt la liaison, et revenir en arrière n’est pas pris en charge.
• Récupération d’urgence (SQL Server 2022) : utilisez la fonctionnalité de liaison pour répliquer des données entre SQL Server 2022 et SQL Managed Instance, basculer manuellement vers votre serveur secondaire lors d’un sinistre et revenir à votre serveur principal après avoir atténué le sinistre. SQL Server ou SQL Managed Instance peut être l’instance primaire initiale.

Vous pouvez maintenir cette liaison aussi longtemps que vous le voulez, de plusieurs mois à plusieurs années à la fois. En ce qui concerne votre parcours de modernisation, si/quand vous êtes prêt à migrer vers Azure, la liaison propose une expérience de migration considérablement améliorée. La migration via la liaison offre un temps d’arrêt minimal par rapport à toutes les autres options de migration disponibles, ce qui permet une véritable migration en ligne vers votre SQL Managed Instance.

Vous pouvez utiliser des bases de données répliquées via le lien entre SQL Server et Azure SQL Managed Instance pour plusieurs scénarios, tels que :

• Récupération d’urgence
• Utilisation des services Azure sans migrer vers le cloud
• Déchargement des charges de travail en lecture seule vers Azure
• Migration vers Azure
• Copie de données locales

Supportabilité des versions

Les niveaux de service Usage général et Critique pour l’entreprise d’Azure SQL Managed Instance prennent en charge le lien Managed Instance. La fonctionnalité de liaison fonctionne avec les éditions Entreprise, Développeur et Standard de SQL Server.

La table suivante liste les fonctionnalités de liaison et les versions minimales de SQL Server prises en charge :

¹ Alors que la création d’une liaison avec SQL Server 2022 comme instance primaire initiale est prise en charge à partir de la version RTM de SQL Server 2022, la création d’une liaison avec Azure SQL Managed Instance comme instance primaire initiale est prise en charge qu’à partir de SQL Server 2022 CU10. Si vous créez le lien à partir d’une instance SQL Managed primaire initiale, le passage de SQL Server à une version antérieure à CU10 n’est pas pris en charge lorsque le lien est actif, car cela peut entraîner des problèmes après le basculement dans un sens ou dans l'autre.

Les versions SQL Server antérieures à SQL Server 2016 (SQL Server 2008 – 2014) ne sont pas prises en charge, car la fonctionnalité de liaison s’appuie sur la technologie de groupe de disponibilité distribué, qui a été introduite dans SQL Server 2016.

Outre la version SQL Server prise en charge, vous aurez besoin des éléments suivants :

• Connectivité réseau entre votre instance SQL Server et votre instance managée. Si SQL Server s’exécute localement, utilisez une liaison VPN ou Azure ExpressRoute. Si SQL Server s’exécute sur une machine virtuelle Azure, déployez votre machine virtuelle sur le même réseau virtuel que votre instance managée ou utilisez le peering de réseaux virtuels pour connecter les deux sous-réseaux distincts.
• Un déploiement Azure SQL Managed Instance provisionné sur n’importe quel niveau de service.

Vous avez également besoin des outils suivants :

Comment fonctionne la liaison

La fonctionnalité de lien pour SQL Managed Instance fonctionne en créant un groupe de disponibilité distribué entre SQL Server et Azure SQL Managed Instance. La solution prend en charge les systèmes à nœud unique avec ou sans groupes de disponibilité existants, ou les systèmes à nœuds multiples avec groupes de disponibilité existants.

Une connexion privée telle qu’un VPN ou Azure ExpressRoute connecte un réseau local et Azure. Si vous hébergez SQL Server sur une machine virtuelle Azure, l'infrastructure interne d'Azure peut connecter la machine virtuelle et l'instance SQL managée, comme par le peering de réseaux virtuels. Les deux systèmes établissent une approbation à l’aide de l’authentification basée sur des certificats, où SQL Server et SQL Managed Instance échangent des clés publiques de leurs certificats respectifs.

Azure SQL Managed Instance prend en charge plusieurs liens provenant de sources SQL Server identiques ou différentes vers une instance azure SQL Managed Instance unique. Le nombre de liens dépend du nombre de bases de données qu’une instance managée peut héberger en même temps : jusqu’à 100 liens pour les niveaux de service Usage général et Critique pour l’entreprise, et 500 liens pour la mise à niveau du niveau Usage général de nouvelle génération. Une instance SQL Server unique peut créer plusieurs liens de synchronisation de base de données parallèles avec plusieurs instances managées SQL, même dans différentes régions Azure, avec une relation un-à-un entre une base de données et une instance managée.

Utilisez la liaison

Pour vous aider à configurer l’environnement initial, consultez le guide pour préparer votre environnement SQL Server afin d’utiliser la fonctionnalité de liaison avec SQL Managed Instance :

• Préparer l’environnement de liaison pour SQL Server 2019 et les versions ultérieures, ou pour SQL Server 2016
• Automatisez la préparation de votre environnement pour le lien Managed Instance à l’aide d’un script téléchargeable. Pour en savoir plus, reportez-vous au Automatiser le blog d’installation de liaison.

Après avoir satisfait aux exigences initiales de l’environnement, créez le lien à l’aide de l’Assistant automatisé dans SQL Server Management Studio (SSMS) ou configurez le lien manuellement à l’aide de scripts :

• Configurer la liaison avec SSMS
• Configurer la liaison avec les scripts

Après avoir créé le lien, suivez les bonnes pratiques pour maintenir le lien :

• Meilleures pratiques pour préserver la liaison

Récupération d’urgence

La liaison Managed Instance active la récupération d’urgence, où, en cas de sinistre, vous pouvez basculer manuellement votre charge de travail de votre instance primaire vers votre instance secondaire. Pour commencer, passez en revue Récupération d’urgence avec une liaison Managed Instance.

Avec SQL Server 2016 vers SQL Server 2019, le serveur principal est toujours SQL Server et le basculement vers l’instance managée SQL secondaire est unidirectionnel. La restauration automatique vers SQL Server n’est pas prise en charge. Toutefois, vous pouvez récupérer vos données dans SQL Server à l’aide d’options de déplacement de données telles que la réplication transactionnelle ou l’exportation d’un bacpac.

Avec SQL Server 2022, SQL Server ou SQL Managed Instance peut être l’instance primaire initiale et vous pouvez établir la liaison à partir de SQL Server ou de SQL Managed Instance. Vous pouvez restaurer automatiquement vos charges de travail entre le serveur principal et le serveur secondaire, ce qui permet de bénéficier d’une récupération d’urgence bidirectionnelle.

Lorsque vous effectuez une restauration automatique vers SQL Server, vous pouvez choisir d’effectuer une restauration automatique :

• en ligne en utilisant directement le lien Managed Instance.
• hors connexion en effectuant une sauvegarde de votre base de données à partir de SQL Managed Instance et en la restaurant sur votre instance SQL Server 2022.

Utiliser les services Azure

Utilisez la fonctionnalité de liaison pour tirer parti des services Azure en utilisant des données SQL Server sans les migrer vers le cloud. Citons par exemple la création de rapports, l’analytique, les sauvegardes, le Machine Learning et d’autres tâches qui envoient des données à Azure.

Déplacer des charges de travail vers Azure

Vous pouvez également utiliser la fonctionnalité de liaison pour déplacer des charges de travail vers Azure. Par exemple, une application peut utiliser SQL Server pour des charges de travail en lecture/écriture tout en déchargeant des charges de travail en lecture seule sur des déploiements SQL Managed Instance dans n’importe quelle région Azure à l’échelle mondiale. Une fois le lien établi, la base de données primaire sur SQL Server est accessible en lecture/écriture, tandis que les données répliquées sur votre instance managée SQL dans Azure sont accessibles en lecture seule. Cette disposition permet de créer différents scénarios dans lesquels les bases de données répliquées sur votre instance managée SQL peuvent être utilisées pour effectuer un scale-out en lecture et décharger des charges de travail en lecture seule sur Azure. Votre instance managée SQL, en parallèle, peut également héberger des bases de données en lecture/écriture indépendantes, ce qui permet également de copier la base de données répliquée vers une autre base de données en lecture/écriture sur la même instance managée SQL pour un traitement ultérieur des données.

La liaison est délimitée à la base de données (une liaison par base de données), ce qui permet la consolidation et la déconsolidation des charges de travail dans Azure. Par exemple, vous pouvez répliquer des bases de données à partir de plusieurs instance SQL Server vers un seul déploiement SQL Managed Instance dans Azure (consolidation) ou vous pouvez répliquer des bases de données à partir d’une seule instance SQL Server vers plusieurs instances managées via une relation 1:1 entre une base de données et une instance managée, dans n’importe quelle région Azure à l’échelle mondiale (déconsolidation). La deuxième option vous offre un moyen efficace de rapprocher rapidement vos charges de travail de vos clients dans n’importe quelle région du monde et la possibilité de les utiliser comme réplicas en lecture seule.

Migrer vers Azure

La fonctionnalité de liaison facilite également la migration de SQL Server vers SQL Managed Instance, avec les avantages suivants :

• Migration la plus performante avec un temps d’arrêt minimum par rapport aux autres solutions actuellement disponibles.
• Véritable migration en ligne vers SQL Managed Instance dans n’importe quel niveau de service.

Compte tenu du temps d’arrêt minimum occasionné par la fonctionnalité de liaison, vous pouvez effectuer une migration vers votre instance managée tout en conservant votre charge de travail primaire en ligne. Bien qu’il soit actuellement possible d’effectuer des migrations en ligne vers le niveau de service Usage général avec d’autres solutions, la fonctionnalité de lien est la seule solution qui autorise de véritables migrations en ligne vers le niveau de service Critique pour l’entreprise . Pour obtenir une comparaison approfondie de la migration entre la migration avec le lien et le service Log Replay, consultez Comparer le lien Managed Instance à LRS.

Copier les données locales

Avec SQL Server 2022, vous pouvez établir une liaison entre SQL Managed Instance et SQL Server, ce qui vous permet d’envisager d’autres scénarios, comme la création d’un réplica de base de données en quasi-temps réel en dehors d’Azure, le test de plans de continuité d’activité et le respect des exigences en matière de conformité.

Sauvegardes automatisées

Après avoir configuré un lien avec Azure SQL Managed Instance, les bases de données sur l’instance managée SQL sont automatiquement sauvegardées dans le stockage Azure, que SQL Managed Instance soit primaire ou non. Les sauvegardes automatisées avec le lien prennent des sauvegardes complètes et des sauvegardes du journal des transactions, mais pas des sauvegardes différentielles, ce qui peut entraîner des temps de restauration plus longs.

Vous pouvez réduire vos coûts de gestion et d’exploitation locaux tout en profitant de la fiabilité des sauvegardes Azure pour vos bases de données répliquées. Vous pouvez ensuite effectuer une restauration à un instant dans le passé de votre base de données répliquée sur n’importe quel déploiement SQL Managed Instance dans la même région, comme avec toute autre sauvegarde automatisée.

Réplica de récupération d’urgence passive sans licence

Vous pouvez économiser sur les coûts de licence vCore si vous activez l’avantage de basculement hybride pour la récupération d’urgence passive secondaire uniquement pour les instances gérées SQL qui n’ont aucune charge de travail.

Pour commencer, passez en revue Réplica passif sans licence.

Analyse coût-bénéfice

Si vous désignez un réplica de Managed Instance pour la récupération d’urgence uniquement, Microsoft ne vous facture pas de coûts de licence SQL Server pour les vCores utilisés par l’instance secondaire. L’instance est facturée à une granularité horaire et vous pouvez toujours être facturé des coûts de licence pour une heure complète si vous mettez à jour l’avantage de licence pendant l’heure.

L’avantage fonctionne différemment pour le modèle de facturation avec paiement à l’utilisation et Azure Hybrid Benefit. Dans le cas d'un modèle de facturation à la consommation, les vCores bénéficient d'une réduction sur votre facture. Si vous utilisez Azure Hybrid Benefit pour le réplica passif, le nombre de vCores utilisés par le réplica secondaire est reversé dans votre pool de licences.

Par exemple, en tant que client en mode paiement à l'usage, si vous disposez de 16 vCores attribués à l’instance secondaire, une remise de 16 vCores apparaît sur votre facture si vous désignez votre instance secondaire pour le basculement en mode hybride.

Dans un autre exemple, si vous disposez de 16 licences Azure Hybrid Benefit et que votre SQL Managed Instance secondaire utilise 8 vCores, après avoir désigné l’instance secondaire pour le basculement hybride, 8 vCores sont retournés dans votre pool de licences pour que vous puissiez les utiliser avec d’autres déploiements Azure SQL.

Pour obtenir des conditions générales précises de l’avantage des droits de basculement hybride, consultez les conditions de licence SQL Server en ligne dans la section SQL Server – Droits de basculement.

Limites

Tenez compte des limitations suivantes quand vous utilisez la liaison.

Les limitations de prise en charge des versions sont les suivantes :

• Vous ne pouvez pas utiliser des clients Windows 10 et 11 pour héberger votre instance SQL Server, car il n’est pas possible d’activer la fonctionnalité de groupe de disponibilité Always On nécessaire pour la liaison. Vous devez héberger des instances SQL Server sur Windows Server 2012 ou version ultérieure.
• La fonctionnalité de liaison ne prend pas en charge sql Server versions 2008 à 2014, car le moteur SQL de ces versions n’a pas de prise en charge intégrée pour les groupes de disponibilité distribués requis pour le lien. Mettez à niveau SQL Server vers une version plus récente pour utiliser la liaison.
• La réplication et le basculement des données de SQL Managed Instance vers SQL Server 2022 ne sont pas pris en charge par les instances configurées avec la stratégie de mise à jour permanente. Votre instance doit être configurée avec la stratégie de mise à jour SQL Server 2022 pour effectuer les opérations suivantes :
  • Établir un lien depuis SQL Managed Instance vers SQL Server.
  • Basculement de SQL Managed Instance vers SQL Server 2022.
• Bien que vous puissiez établir un lien entre SQL Server 2022 et une instance managée SQL configurée avec la stratégie de mise à jour Always-up-to-date, après le basculement vers SQL Managed Instance, vous ne pouvez pas répliquer de données ni effectuer une restauration automatique vers SQL Server 2022.

Les limitations de réplication des données sont les suivantes :

• Vous pouvez répliquer uniquement les bases de données utilisateur. La réplication des bases de données système n’est pas prise en charge.
• La solution ne réplique ni les objets de niveau serveur, ni les travaux de l’agent, ni les connexions utilisateur de SQL Server à SQL Managed Instance.
• Pour les versions 2016, 2017 et 2019 de SQL Server, la réplication des bases de données utilisateur des instances SQL Server vers des déploiements SQL Managed Instance est un moyen unique. Vous ne pouvez pas répliquer les bases de données utilisateur à partir de déploiements SQL Managed Instance vers des instances SQL Server via le lien. La réplication bidirectionnelle avec restauration automatique vers une instance SQL Server n’est disponible que pour SQL Server 2022.
• La configuration d’un lien entre SQL Managed Instance et SQL Server n’est pas prise en charge pour les bases de données SQL Managed Instance déjà liées.

Les limitations de configuration sont les suivantes :

• S’il existe plusieurs instances SQL Server sur un serveur, vous pouvez configurer un lien pour chaque instance, mais vous devez configurer chaque instance pour utiliser un point de terminaison de mise en miroir de bases de données distinct, avec un port dédié par instance. Seule l’instance par défaut doit utiliser le port 5022 pour le point de terminaison de mise en miroir de bases de données.
• Vous ne pouvez placer qu’une seule base de données dans un seul groupe de disponibilité pour un lien Managed Instance. Toutefois, vous pouvez répliquer plusieurs bases de données dans une instance SQL Server unique en établissant plusieurs liens.
• Vous pouvez créer un lien avec un groupe de disponibilité existant avec une base de données unique. Si votre groupe de disponibilité existant a plusieurs bases de données, vous pouvez créer un lien avec le groupe de disponibilité uniquement si vous supprimez toutes les bases de données à l’exception d’un du groupe de disponibilité.
• Une seule instance managée SQL à usage général ou critique pour l’entreprise prend en charge jusqu’à 100 liens, et une seule instance managée SQL à usage général de nouvelle génération prend en charge jusqu’à 500 liens, à partir du même ou de plusieurs sources SQL Server.
• Une liaison Managed Instance peut répliquer une base de données de n’importe quelle taille si elle s’adapte à la taille de stockage choisie du déploiement SQL Managed Instance cible.
• L’authentification de la liaison Managed Instance entre SQL Server et SQL Managed Instance est basée sur un certificat et disponible uniquement par le biais d’un échange de certificats. Vous ne pouvez pas utiliser l’authentification Windows pour établir le lien entre l’instance SQL Server et l’instance managée SQL.
• Vous pouvez établir un lien avec uniquement un point de terminaison local de réseau virtuel vers SQL Managed Instance.
• Vous ne pouvez pas utiliser un point de terminaison public ou des points de terminaison privés pour établir le lien avec l’instance gérée.
• Vous ne pouvez pas répliquer de bases de données avec plusieurs fichiers journaux, car SQL Managed Instance ne prend pas en charge plusieurs fichiers journaux.

Les limitations de la fonctionnalité sont les suivantes :

• Vous ne pouvez pas utiliser groupes de basculement avec des instances qui utilisent la fonctionnalité de lien. Vous ne pouvez pas établir de lien sur une instance managée SQL qui fait partie d’un groupe de basculement, et à l’inverse, vous ne pouvez pas configurer un groupe de basculement sur une instance ayant établi un lien.
• Si vous utilisez la capture des changements de données (CDC), le log shipping ou un courtier de services avec des bases de données répliquées sur l’instance SQL Server, lorsque la base de données est migrée vers un déploiement Instance gérée SQL, lors d’un basculement vers Azure, les clients doivent se connecter en utilisant le nom d'instance du réplica principal global actuel. Vous devez reconfigurer manuellement ces paramètres.
• Si vous utilisez la réplication transactionnelle sur une base de données avec un lien établi, tenez compte des éléments suivants :
  • La base de données liée sur le réplica secondaire ne peut pas être un serveur de publication dans une topologie de réplication transactionnelle.
  • Si vous migrez une base de données configurée en tant que serveur de publication dans une topologie de réplication transactionnelle à l’aide du lien, vous devez reconfigurer la base de données en tant que serveur de publication sur l’instance cible une fois la migration terminée.
• Si vous utilisez des transactions distribuées avec une base de données répliquée à partir de l’instance SQL Server et, dans un scénario de migration, lors du basculement vers le cloud, les fonctionnalités DTC ne sont pas transférées. Il est impossible que la base de données migrée soit impliquée dans des transactions distribuées avec l’instance SQL Server, car le déploiement SQL Managed Instance ne prend pas en charge les transactions distribuées avec SQL Server pour l’instant. Pour référence, SQL Managed Instance prend aujourd’hui en charge les transactions distribuées uniquement entre d’autres instances managées. Pour plus d’informations, consultez Transactions distribuées entre bases de données cloud.
• Si vous utilisez Transparent Data Encryption (TDE) pour chiffrer les bases de données SQL Server, vous devez exporter la clé de chiffrement de base de données à partir de SQL Server et la charger dans Azure Key Vault, et vous devez également configurer l’option BYOK TDE sur SQL Managed Instance avant de créer le lien.
• Vous ne pouvez pas lier des bases de données SQL Managed Instance chiffrées avec des clés TDE gérées par le service à SQL Server. Vous pouvez lier une base de données chiffrée à SQL Server uniquement si vous l’avez chiffrée avec une clé gérée par le client et que 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.
• Vous ne pouvez pas établir de lien entre SQL Server et SQL Managed Instance si la fonctionnalité que vous utilisez sur l’instance SQL Server n’est pas prise en charge sur l’instance managée SQL. Par exemple :
  • Vous ne pouvez pas répliquer de bases de données avec des tables de fichiers et des flux de fichiers, car SQL Managed Instance ne prend pas en charge les tables de fichiers ou les flux de fichiers.
  • Vous pouvez répliquer des bases de données qui utilisent In-Memory OLTP uniquement vers SQL Managed Instance dans le niveau de service Critique pour l’entreprise , car le niveau de service Usage général ne prend pas en charge In-Memory OLTP. SQL Managed Instance ne prend pas en charge les bases de données avec plusieurs fichiers OLTP In-Memory et vous ne pouvez pas les répliquer.

Toute tentative d’ajout d’une fonctionnalité non prise en charge à une base de données répliquée dans :

• SQL Server 2017, 2019 et 2022 échoue avec une erreur.
• SQL Server 2016 entraîne la rupture du lien, que vous devez ensuite supprimer et recréer.

Pour obtenir la liste complète des différences entre SQL Server et SQL Managed Instance, consultez Différences T-SQL entre SQL Server et Azure SQL Managed Instance.

Contenu connexe

Pour utiliser le lien :

• Préparer un environnement pour une 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
• Basculer la liaison
• Migrer avec le lien
• Meilleures pratiques pour préserver la liaison
• Résoudre les problèmes liés au lien

Pour en savoir plus sur la liaison :

• Récupération d’urgence avec le lien Managed Instance

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

• Réplication transactionnelle avec SQL Managed Instance
• Service de relecture des journaux (LRS)