Partager via

Vue d’ensemble de la liaison Managed Instance

  • Article

S’applique à : Azure SQL Managed Instance

Cet article fournit un aperçu de la fonctionnalité de liaison Managed Instance, qui permet une réplication des données en quasi-temps réel de SQL Server vers 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. Avec SQL Server 2022, la liaison permet la récupération d’urgence en ligne avec retour sur SQL Server (actuellement en aperçu). Cette liaison permet également la configuration de la liaison entre SQL Managed Instance et SQL Server 2022 (également en aperçu).

Pour commencer, passez en revue la préparation de votre environnement pour le lien.

Vue d’ensemble

La liaison Managed Instance utilise des groupes de disponibilité distribués pour étendre votre domaine de données de manière sûre et sécurisée, en répliquant les données en quasi-temps réel depuis SQL Server hébergé n’importe où vers Azure SQL Managed Instance, ou depuis Azure SQL Managed Instance vers SQL Server 2022 hébergé 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 la liaison prenne en charge la réplication d’une base de données par liaison, il est possible de répliquer plusieurs bases de données à partir d’une seule instance de SQL Server vers une ou plusieurs SQL Managed Instances, ou de répliquer la même base de données vers plusieurs SQL Managed Instances, en configurant plusieurs liaisons – une liaison pour chaque paire base de données/instance managée.

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

  • Réplication unidirectionnelle à partir des versions 2016 et 2019 de SQL Server : utilisez la fonctionnalité de liaison pour répliquer les données dans un sens à partir d’une 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 la restauration n’est pas prise en charge.
  • Récupération d’urgence (SQL Server 2022) : utilisez la fonctionnalité de liaison pour répliquer les données entre SQL Server 2022 et SQL Managed Instance, basculer manuellement sur votre instance secondaire en cas de sinistre et revenir sur votre instance primaire après avoir prévenu le sinistre. SQL Server ou SQL Managed Instance peut être l’instance primaire initiale. Actuellement, cette fonctionnalité est uniquement disponible en tant que version préliminaire.

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.

Les bases de données répliquées via la liaison entre SQL Server et Azure SQL Managed Instance peuvent être utilisées pour plusieurs scénarios, comme :

  • 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

Diagramme illustrant le scénario de liaison Managed Instance principal.

Prise en charge des versions

La liaison Managed Instance est prise en charge sur les niveaux de service Usage général et Critique pour l’entreprise d’Azure SQL 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 :

Version primaire initiale Système d’exploitation (OS) Réplication unidirectionnelle Options de récupération d’urgence Exigence de mise à jour de maintenance
Azure SQL Managed Instance Windows Server et Linux Aperçu Bidirectionnel – Aperçu - SQL Server 2022 CU10 (KB5031778) : création d’un lien entre Azure SQL Managed Instance et SQL Server 2022 1
- SQL Server 2022 CU13 (KB5036432) : basculement du lien à l’aide de Transact-SQL
- La configuration d’un lien depuis Azure SQL Managed Instance vers SQL Server 2022 n’est prise en charge que par les instances configurées avec la stratégie de mise à jour SQL Server 2022
SQL Server 2022 (16.x) Windows Server et Linux Mise à la disposition générale Bidirectional :
Hors connexion (en disponibilité générale)
En ligne (aperçu)		 SQL Server 2022 RTM
SQL Server 2019 (15.x) Windows Server uniquement Mise à la disposition générale De SQL Server à SQL MI uniquement SQL Server 2019 CU20 (KB5024276)
SQL Server 2017 (14.x) N/A N/A N/A SQL Server 2017 n’est pas pris en charge actuellement.
SQL Server 2016 (13.x) Windows Server uniquement Mise à la disposition générale De SQL Server à SQL MI uniquement La version la plus récente de SQL Server 2016 SP3 et la version correspondante du pack SQL Server 2016 Azure Connect.
SQL Server 2014 (12.x) et versions précédentes N/A N/A N/A Les versions antérieures à SQL Server 2016 ne sont pas prises en charge.

1 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 la liaison à partir d’une SQL Managed Instance primaire initiale, le passage de SQL Server à une version antérieure de CU10 n’est pas pris en charge lorsque la liaison est active, car elle peut entraîner des problèmes après le basculement dans les deux sens.

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 aurez également besoin d’outils suivants :

Outil Notes
SSMS 20.2 ou version ultérieure SQL Server Management Studio (SSMS) est le moyen le plus simple d’utiliser une liaison Managed Instance car il fournit des Assistants qui automatisent la configuration de la liaison.
Az.SQL 3.9.0 ou version ultérieure Un module PowerShell est requis pour les étapes de configuration manuelle.

Remarque

La fonctionnalité de liaison Managed Instance est disponible dans toutes les régions Azure publiques et tous les clouds nationaux ou gouvernementaux.

La technologie sous-jacente à la fonction de liaison pour SQL Managed Instance est basée sur la création d’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.

Diagramme présentant la manière dont la caractéristique de liaison pour SQL Managed Instance fonctionne à l’aide de la technologie de groupe de disponibilité distribué.

Une connexion privée comme un VPN ou Azure ExpressRoute est utilisée entre un réseau local et Azure. Si SQL Server est hébergé sur une machine virtuelle Azure, le réseau principal (« backbone ») Azure interne peut être utilisé entre la machine virtuelle et l’instance managée, par exemple, le peering de réseaux virtuels. La confiance entre les deux systèmes est établie à l’aide d’une authentification basée sur un certificat, dans laquelle SQL Server et SQL Managed Instance échangent les clés publiques de leurs certificats respectifs.

Azure SQL Managed Instance prend en charge plusieurs liens à partir de la même ou de différentes sources SQL Server vers une seule instance Azure SQL Managed Instance, uniquement limitée par le nombre de bases de données pouvant être hébergées sur une instance gérée en même temps, soit jusqu’à 100 liens pour les niveaux de service Usage général et Critique pour l’entreprise, et 500 pour la mise à niveau du niveau Usage général nouvelle génération. De même, une seule instance SQL Server peut établir plusieurs liaisons de synchronisation de base de données en parallèle avec plusieurs instances managées, même vers différentes régions Azure, au sein d’une relation un-à-un entre une base de données et une instance managée.

Pour vous aider à configurer l’environnement initial, passez en revue le guide sur la manière de préparer votre environnement SQL Server à utiliser la fonctionnalité de liaison avec SQL Managed Instance :

Après vous être assuré que les exigences initiales de l’environnement sont remplies, vous pouvez créer la liaison en utilisant l’Assistant automatisé de SQL Server Management Studio (SSMS), ou vous pouvez choisir de configurer la liaison manuellement à l’aide de scripts :

Une fois la liaison créée, suivez les meilleures pratiques pour maintenir 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, évaluez la récupération d’urgence avec la liaison Managed Instance.

Avec SQL Server 2016 et SQL Server 2019, l’instance primaire reste SQL Server et le basculement vers la Managed Instance secondaire est unidirectionnel. Le basculement vers SQL Server n’est pas pris en charge. Toutefois, il est possible de récupérer vos données sur SQL Server en utilisant des options de déplacement de données comme 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 faire basculer vos charges de travail entre l’instance primaire et l’instance secondaire, ce qui permet une véritable récupération d’urgence dans les deux sens.

Lorsque vous basculez vers SQL Server, vous pouvez choisir d’effectuer le basculement :

  • en ligne en utilisant la liaison Managed Instance directement. Cette option est actuellement en aperçu.
  • 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. Cette option est en disponibilité générale.

Diagramme montrant le scénario de reprise d’activité.

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 la liaison établie, 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 dans Azure sont accessibles en lecture seule. Cette organisation permet de prendre en charge divers scénarios dans lesquels les bases de données répliquées sur votre instance managée peuvent être utilisées pour un scale-out en lecture et le déchargement des charges de travail en lecture seule vers Azure. Votre instance managée, en parallèle, peut également héberger des bases de données en lecture/écriture indépendantes. Il est alors possible 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 pour d’autres opérations de traitement 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 liaison est la seule solution qui permet d’effectuer de véritables migrations en ligne vers le niveau Critique pour l’entreprise.

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é. L’établissement d’une liaison entre SQL Managed Instance et SQL Server 2022 est actuellement en aperçu.

Sauvegardes automatisées

Après avoir configuré un lien avec Azure SQL Managed Instance, les bases de données sur Managed Instance 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 DR passif sans licence

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

Pour commencer, évaluez le réplica passif sans licence.

Coût-avantages

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. Sachez que l’instance est facturée sur une granularité d’une heure et qu’il se peut que les coûts de licence vous soient facturés pour une heure entière si vous mettez à jour les avantages de la licence au cours de l’heure.

L’avantage reflète différemment le modèle de facturation de paiement à l’utilisation et Azure Hybrid Benefit. Dans le cas d’un modèle de facturation de paiement à l’utilisation, les vCores sont déduits de 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 de paiement à l’utilisation, 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 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 connaître les conditions générales précises relatives aux droits de basculement hybride, consultez les termes du contrat de licence de 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. Les instances SQL Server doivent être hébergées sur Windows Server 2012 ou version ultérieure.
  • Les versions 2008 à 2014 de SQL Server ne peuvent pas être prises en charge par la fonctionnalité de liaison, car le moteur SQL de ces versions n’offre pas de prise en charge intégrée des groupes de disponibilité distribués nécessaires pour la liaison. 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 permanente, après le basculement vers SQL Managed Instance, vous ne pourrez plus répliquer des données ou effectuer une restauration automatique vers SQL Server 2022.

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

  • Seules les bases de données utilisateur peuvent être répliquées. 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.
  • Dans les versions 2016 et 2019 de SQL Server, la réplication de bases de données utilisateur à partir d’instances SQL Server vers des déploiements de SQL Managed Instance est unidirectionnelle. Les bases de données utilisateur des déploiements SQL Managed Instance ne peuvent pas être répliquées à nouveau sur des instances SQL Server. La réplication bidirectionnelle avec restauration automatique vers une instance SQL Server n’est disponible que pour SQL Server 2022.
  • La configuration d’une liaison entre SQL Managed Instance et SQL Server sur une base de données n’est pas prise en charge pour les bases de données SQL Managed Instance qui sont déjà liées.

Les limitations de configuration sont les suivantes :

  • S’il existe plusieurs instances SQL Server sur un serveur, il est possible de configurer une liaison avec chaque instance, mais chaque instance doit être configurée pour utiliser un point de terminaison de mise en miroir de base 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.
  • Une seule base de données peut être placée dans un groupe de disponibilité unique par liaison Managed Instance. Toutefois, il est possible de répliquer plusieurs bases de données dans une instance unique de SQL Server en créant plusieurs liaisons.
  • Une instance managée unique prend en charge jusqu’à 100 liaisons à partir de plusieurs instances de 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. L’utilisation de l’authentification Windows pour établir la liaison entre l’instance SQL Server et l’instance managée n’est pas prise en charge.
  • Seul un point de terminaison VNet local est pris en charge pour établir le lien avec 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.
  • Les bases de données contenant plusieurs fichiers journaux ne peuvent pas être répliquées, car SQL Managed Instance ne prend pas en charge plusieurs fichiers journaux.

Les limitations de la fonctionnalité sont les suivantes :

  • Les groupes de basculement ne sont pas pris en charge avec les instances qui utilisent la fonctionnalité de liaison. Vous ne pouvez pas établir de liaison sur une instance managée qui fait partie d’un groupe de basculement et, inversement, vous ne pouvez pas configurer un groupe de basculement sur une instance pour laquelle une liaison est établie.
  • Si vous utilisez la capture des changements de données (CDC), la copie des journaux de transaction ou un répartiteur de services avec des bases de données qui sont répliquées sur l’instance SQL Server, quand la base de données est migrée vers un déploiement SQL Managed Instance, lors d’un basculement vers Azure, les clients doivent se connecter à l’aide du nom d’instance du réplica principal global actuel. Ces paramètres doivent être reconfigurés manuellement.
  • Si vous utilisez la réplication transactionnelle avec une base de données sur une instance SQL Server dans un scénario de migration, lors du basculement vers Azure, la réplication transactionnelle sur le déploiement SQL Managed Instance échoue et doit être reconfigurée manuellement.
  • 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, la clé de chiffrement de base de données doit être exportée de SQL Server et chargée dans Azure Key Vault, et vous devez aussi configurer l’option BYOK TDE sur SQL Managed Instance avant de créer la liaison.
  • 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.
  • Vous ne pouvez pas établir de liaison entre SQL Server et SQL Managed Instance si la fonctionnalité utilisée sur l’instance SQL Server n’est pas prise en charge sur l’instance managée. Par exemple :
    • Les bases de données avec des tables de fichiers et des flux de fichiers ne peuvent pas être répliquées, car SQL Managed Instance ne prend pas en charge les tables de fichiers ou les flux de fichiers.
    • Les bases de données qui utilisent OLTP en mémoire ne peuvent être répliquées que vers SQL Managed Instance au niveau de service critique pour l’entreprise, car le niveau de service à usage général ne prend pas en charge OLTP en mémoire. Les bases de données avec plusieurs fichiers OLTP en mémoire ne sont pas prises en charge par SQL Managed Instance et ne peuvent pas être répliquées.

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

  • SQL Server 2019 et 2022 échoue avec une erreur.
  • SQL Server 2016 provoque la rupture du lien, qui doit alors être supprimé et recréé.

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 d’autres scénarios de réplication et de migration, considérez :