Partage via

Architecture de connectivité d’Azure SQL Managed Instance

  • Article

S’applique à : Azure SQL Managed Instance

Cet article décrit l’architecture de connectivité dans Azure SQL Managed Instance et la façon dont les composants dirigent le trafic de communication pour une instance managée.

Vue d’ensemble

Dans SQL Managed Instance, une instance est placée à l’intérieur du réseau virtuel Azure et du sous-réseau dédié aux instances managées. Le déploiement offre :

  • Une adresse IP sécurisée pour le réseau virtuel local (VNet-local).
  • La capacité à connecter un réseau local à SQL Managed Instance.
  • La capacité à connecter SQL Managed Instance à un serveur lié ou à un autre magasin de données local.
  • La capacité à connecter SQL Managed Instance à des ressources Azure.

Architecture de la connectivité globale

SQL Managed Instance est constituée de composants du service hébergés sur un ensemble dédié de machines virtuelles isolées qui sont regroupées par des attributs de configuration similaires et jointes à un cluster virtuel. Certains composants de service sont déployés à l’intérieur du sous-réseau de réseau virtuel du client, tandis que d’autres services fonctionnent dans un environnement réseau sécurisé géré par Microsoft.

Diagramme montrant l’architecture de connectivité globale pour Azure SQL Managed Instance après novembre 2022.

Les applications client peuvent se connecter à des instances managées SQL ainsi qu’interroger et mettre à jour des bases de données à l’intérieur du réseau virtuel, du réseau virtuel appairé ou du réseau connecté grâce à un VPN ou Azure ExpressRoute.

Le diagramme suivant représente les entités connectées à SQL Managed Instance. Il montre également les ressources qui doivent communiquer avec une instance gérée. Le processus de communication situé dans la partie inférieure du diagramme représente les applications et les outils des clients qui se connectent à l’instance managée SQL en tant que sources de données.

Diagramme montrant les entités dans l’architecture de connectivité pour Azure SQL Managed Instance après novembre 2022.

SQL Managed Instance est une offre PaaS (Platform-as-a-Service) monolocataire qui fonctionne sur deux plans : un plan de données et un plan de contrôle.

Le plan de données est déployé à l’intérieur du sous-réseau du client pour assurer la compatibilité, la connectivité et l’isolement réseau. Le plan de données dépend des services Azure, tels que Stockage Azure, Microsoft Entra ID (anciennement Azure Active Directory) pour l’authentification, et des services de collecte de télémétrie. Vous verrez le trafic qui provient de sous-réseaux contenant SQL Managed Instance se diriger vers ces services.

Le plan de contrôle transporte les fonctions de déploiement, de gestion et de maintenance de service de base via des agents automatisés. Ces agents ont un accès exclusif aux ressources de calcul qui exploitent le service. Vous ne pouvez pas utiliser ssh ou le protocole Bureau à distance pour accéder à ces hôtes. Toutes les communications du plan de contrôle sont chiffrées et signées à l’aide de certificats. Pour s’assurer de la fiabilité des parties communicantes, SQL Managed Instance vérifie en permanence ces certificats à l’aide de listes de révocation de certificats.

Vue d’ensemble des communications

Les applications peuvent se connecter à SQL Managed Instance via trois types de points de terminaison. Ces points de terminaison servent différents scénarios et présentent des propriétés et des comportements réseau distincts.

Diagramme montrant l’étendue de la visibilité des points de terminaison locaux, publics et privés de réseau virtuel sur Azure SQL Managed Instance.

Point de terminaison local de réseau virtuel

Le point de terminaison local de réseau virtuel est le moyen par défaut permettant de se connecter à SQL Managed Instance. Le point de terminaison local de réseau virtuel est un nom de domaine de la forme <mi_name>.<dns_zone>.database.windows.net qui se résout en adresse IP à partir du pool d’adresses du sous-réseau, d’où l’appellation local de réseau virtuel pour désigner un point de terminaison local au réseau virtuel. Le point de terminaison local de réseau virtuel peut être utilisé pour connecter une instance SQL Managed Instance dans tous les scénarios de connectivité standard.

Les points de terminaison locaux VNet de réseau virtuel prennent en charge les types de connexion proxy et de redirection.

Lors de la connexion au point de terminaison VNet-local, utilisez toujours son nom de domaine car l'adresse IP sous-jacente peut changer occasionnellement.

Point de terminaison public

Le point de terminaison public est un nom de domaine facultatif de la forme <mi_name>.public.<dns_zone>.database.windows.net qui se résout en une adresse IP publique accessible à partir d’Internet. Le point de terminaison public permet au trafic TDS d'atteindre uniquement la SQL Managed Instance sur le port 3342 et ne peut pas être utilisé pour des scénarios d'intégration, comme des groupes de basculement, des liaisons Managed Instance et des technologies similaires.

Lorsque vous vous connectez au point de terminaison public, utilisez toujours son nom de domaine, car l'adresse IP sous-jacente peut changer occasionnellement.

Le point de terminaison public utilise toujours le type de connexion proxy quel que soit le paramètre du type de connexion.

Découvrez comment configurer un point de terminaison public dans Configurer un point de terminaison public pour Azure SQL Managed Instance.

Instances Private Endpoint

Un point de terminaison privé, est une adresse IP fixe facultative dans un autre réseau virtuel qui achemine le trafic vers votre instance managée SQL. Azure SQL Managed Instance peut avoir plusieurs points de terminaison privés dans plusieurs réseaux virtuels. Les points de terminaison privés permettent au trafic TDS d'atteindre uniquement la SQL Managed Instance sur le port 1433 et ne peuvent pas être utilisés pour des scénarios d'intégration, comme les groupes de basculement, les liaisons Managed Instance et d'autres technologies similaires.

Lors de la connexion à un point de terminaison privé, utilisez toujours le nom de domaine, car la connexion à Azure SQL Managed Instance via son adresse IP n'est pas prise en charge pour le moment.

Les points de terminaison privés utilisent toujours le type de connexion proxy quel que soit le paramètre du type de connexion.

Apprenez-en plus sur les points de terminaison privés et comment les configurer dans Azure Private Link pour Azure SQL Managed Instance.

Architecture de la connectivité du cluster virtuel

Le diagramme suivant montre l’organisation conceptuelle de l’architecture du cluster virtuel :

Diagramme montrant l’architecture de connectivité du cluster virtuel pour Azure SQL Managed Instance.

Le nom de domaine du point de terminaison local de réseau virtuel correspond à l’adresse IP privée d’un équilibreur de charge interne. Bien que ce nom de domaine soit inscrit dans une zone DNS publique et qu’il soit résolvable publiquement, son adresse IP appartient à la plage d’adresses du sous-réseau et n’est accessible qu’à partir de l’intérieur de son réseau virtuel par défaut.

Il redirige le trafic vers une passerelle SQL Managed Instance. Comme plusieurs instances managées peuvent s’exécuter à l’intérieur du même cluster, la passerelle utilise le nom d’hôte vu dans la chaîne de connexion de SQL Managed Instance pour rediriger le trafic vers le service du moteur SQL approprié.

La valeur pour dns-zone est générée automatiquement lorsque vous créez le cluster. Si un nouveau cluster héberge une instance gérée secondaire, il partage son ID de zone avec le cluster principal.

Configuration requise pour le réseau

Azure SQL Managed Instance nécessite que les aspects du sous-réseau délégué soient configurés de manière spécifique, ce que vous pouvez faire à l’aide de la configuration du sous-réseau assistée par le service. Au-delà de ce dont le service exige, les utilisateurs ont un contrôle total sur la configuration réseau de leur sous-réseau, par exemple :

  • Autorisation ou blocage du trafic sur certains ports ou tous les ports
  • Ajout d’entrées à la table de routage pour router le trafic via des appliances de réseau virtuel ou une passerelle
  • Configuration de la résolution DNS personnalisée ou
  • Configuration du peering ou d’un VPN

Le sous-réseau dans lequel SQL Managed Instance est déployé doit répondre aux exigences suivantes :

  • Sous-réseau dédié : le sous-réseau utilisé par SQL Managed Instance ne peut être délégué qu’au service SQL Managed Instance. Le sous-réseau ne peut pas être un sous-réseau de passerelle et vous ne pouvez déployer que des ressources SQL Managed Instance dans le sous-réseau.
  • Délégation de sous-réseau : le sous-réseau SQL Managed Instance doit être délégué au fournisseur de ressources Microsoft.Sql/managedInstances.
  • Groupe de sécurité réseau : un groupe de sécurité réseau doit être associé au sous-réseau de SQL Managed Instance. Vous pouvez utiliser un groupe de sécurité réseau pour contrôler l’accès au point de terminaison de données SQL Managed Instance en filtrant le trafic sur les ports 1433 et 11000 à 11999 quand SQL Managed Instance est configuré pour rediriger les connexions. Le service provisionne automatiquement les règles et les maintient à jour pour permettre un flux ininterrompu du trafic de gestion.
  • Table de routage : une table de routage doit être associée au sous-réseau SQL Managed Instance. Vous pouvez ajouter des entrées à cette table de routage, par exemple pour acheminer le trafic vers un emplacement local via une passerelle de réseau virtuel ou pour ajouter la route 0.0.0.0/0 par défaut qui dirige tout le trafic via une appliance de réseau virtuel comme un pare-feu. Azure SQL Managed Instance attribue et gère automatiquement ses entrées requises dans la table de routage.
  • Nombre d’adresses IP suffisant : le sous-réseau SQL Managed Instance doit disposer d’au moins 32 adresses IP. Pour plus d’informations, consultez Déterminer la taille du sous-réseau pour SQL Managed Instance. Vous pouvez déployer des instances managées dans le réseau existant après l’avoir configuré de manière à satisfaire les exigences réseau pour SQL Managed Instance. Sinon, créez un nouveau réseau et sous-réseau.
  • Autorisé par les stratégies Azure : si vous utilisez Azure Policy pour empêcher la création ou la modification de ressources dans une étendue qui comprend un sous-réseau ou un réseau virtuel SQL Managed Instance, vos stratégies ne doivent pas empêcher SQL Managed Instance de gérer ses ressources internes. Les ressources suivantes doivent être exclues des effets de refus de la stratégie pour permettre un fonctionnement normal :
    • Les ressources de type Microsoft.Network/serviceEndpointPolicies, lorsque le nom de la ressource commence par \_e41f87a2\_
    • Toutes les ressources de type Microsoft.Network/networkIntentPolicies
    • Toutes les ressources de type Microsoft.Network/virtualNetworks/subnets/contextualServiceEndpointPolicies
  • Verrous sur le réseau virtuel : les verrous sur le réseau virtuel du sous-réseau dédié, son groupe de ressources parent ou son abonnement peuvent parfois interférer avec les opérations de gestion et de maintenance de SQL Managed Instance. Soyez particulièrement vigilant lorsque vous utilisez les verrous de ressource.
  • Trafic de réplication : le trafic de réplication pour les groupes de basculement entre deux instances managées doit être direct et ne doit pas passer par un réseau hub.
  • Serveur DNS personnalisé : si le réseau virtuel est configuré pour utiliser un serveur DNS personnalisé, ce serveur doit être capable de résoudre les enregistrements DNS publics. L’utilisation de fonctionnalités comme l’authentification Microsoft Entra peut nécessiter de résoudre plus de noms de domaine complets. Pour plus d’informations, consultez Résolution des noms DNS privés dans Azure SQL Managed Instance.

Configuration de sous-réseau assistée par le service

Pour améliorer la sécurité du service, la facilité de gestion et la disponibilité, SQL Managed Instance utilise la configuration du sous-réseau assistée par le service et la stratégie d’intention réseau sur l’infrastructure de réseau virtuel Azure pour configurer le réseau, les composants associés et la table de routage pour garantir que les exigences minimales pour SQL Managed Instance sont remplies.

Les règles de sécurité réseau et les règles de table de routage configurés automatiquement sont visibles par le client et annotés avec l’un de ces préfixes :

  • Microsoft.Sql-managedInstances_UseOnly_mi- pour les règles et itinéraires obligatoires ; ou
  • Microsoft.Sql-managedInstances_UseOnly_mi-optional- pour les règles et itinéraires facultatifs.

Pour plus d’informations, consultez Configuration du sous-réseau assistée par le service.

Pour plus d’informations sur l’architecture de connectivité et le trafic de gestion, consultez Architecture de connectivité de haut niveau.

Contraintes de mise en réseau

  • TLS 1.2 est appliqué aux connexions sortantes : à partir de janvier 2020, Microsoft a appliqué TLS 1.2 pour le trafic intra-service dans tous les services Azure. Pour SQL Managed Instance, cela a eu pour effet que TLS 1.2 était appliqué aux connexions sortantes utilisées pour la réplication et aux connexions de serveur lié à SQL Server. Si vous utilisez une version de SQL Server antérieure à 2016 avec SQL Managed Instance, veillez à appliquer les mises à jour spécifiques à TLS 1.2.

Les fonctionnalités de réseau virtuel suivantes ne sont pas prises en charge avec SQL Managed Instance :

  • Sous-réseaux privés : le déploiement d’instances managées dans des sous-réseaux privés (où l’accès sortant par défaut est désactivé) n’est actuellement pas pris en charge.
  • E-mail de la base de données vers des relais SMTP externes sur le port 25 : l’envoi d’e-mail de la base de données via le port 25 aux services de messagerie externes n’est disponible que pour certains types d’abonnements dans Microsoft Azure. Les instances d’autres types d’abonnement doivent utiliser un autre port (par exemple, 587) pour contacter des relais SMTP externes. Dans le cas contraire, les instances risquent de ne pas remettre l'e-mail de la base de données. Pour plus d’informations, consultez Résoudre les problèmes de connectivité SMTP sortante dans Azure.
  • Peering Microsoft : l’activation du peering Microsoft sur des circuits ExpressRoute appairés directement ou transitivement avec un réseau virtuel sur lequel SQL Managed Instance réside affecte le flux de trafic entre les composants SQL Managed Instance au sein du réseau virtuel et les services dont il dépend. Cela entraîne des problèmes de disponibilité. Les déploiements SQL Managed Instance sur un réseau virtuel avec le peering Microsoft déjà activé devraient échouer.
  • Appairage de réseaux virtuels – global : la connectivité d’appairage de réseaux virtuels entre régions Azure ne fonctionne pas pour les SQL Managed Instances placées dans des sous-réseaux créés avant le 9 septembre 2020.
  • Appairage de réseaux virtuels – configuration : lors de l’établissement d’un appairage de réseaux virtuels entre des réseaux virtuels qui contiennent des sous-réseaux avec des SQL Managed Instances, ces sous-réseaux doivent utiliser différentes tables de routage et différents groupes de sécurité réseau (NSG). La réutilisation de la table de routage et du NSG dans deux sous-réseaux ou plus participant à l’appairage de réseaux virtuels entraîne des problèmes de connectivité dans tous les sous-réseaux utilisant ces tables de routage ou NSG et entraîne l’échec des opérations de gestion de SQL Managed Instance.
  • Balise AzurePlatformDNS : l’utilisation de l’étiquette de service AzurePlatformDNS pour bloquer la résolution DNS de plateforme rendrait SQL Managed Instance indisponible. Même si SQL Managed Instance prend en charge le DNS défini par le client pour la résolution DNS à l’intérieur du moteur, il existe une dépendance envers le système DNS de plateforme pour les opérations de plateforme.
  • Passerelle NAT : l’utilisation du service NAT de réseau virtuel Azure pour contrôler la connectivité sortante avec une adresse IP publique spécifique rend SQL Managed Instance indisponible. Le service SQL Managed Instance est actuellement limité à l’utilisation de l’équilibreur de charge de base qui ne permet pas la coexistence de flux entrants et sortants avec le service NAT de réseau virtuel Azure.
  • IPv6 pour réseau virtuel Azure : Le déploiement de SQL Managed Instance sur des réseaux virtuels IPv4/IPv6 à double pile se solde par un échec. L’association d’un groupe de sécurité réseau ou d’une table de routage avec des itinéraires définis par l’utilisateur (UDR) qui contiennent des préfixes d’adresse IPv6 à un sous-réseau SQL Managed Instance rend SQL Managed Instance indisponible. En outre, l’ajout de préfixes d’adresse IPv6 à un groupe de sécurité réseau ou à un UDR déjà associé à un sous-réseau d’instance managée rend SQL Managed Instance indisponible. Les déploiements SQL Managed Instance sur un sous-réseau avec un groupe de sécurité réseau et un UDR disposant déjà de préfixes IPv6 devraient échouer.
  • Enregistrements DNS pour les services Microsoft réservés : les noms de domaine suivants sont réservés et leur résolution telle que définie dans Azure DNS ne doit pas être substituée dans un réseau virtuel hébergeant des instances managées : windows.net, database.windows.net, core.windows.net, blob.core.windows.net, table.core.windows.net, management.core.windows.net, monitoring.core.windows.net, queue.core.windows.net, graph.windows.net, login.microsoftonline.com, login.windows.net, servicebus.windows.net et vault.azure.net. Le déploiement de SQL Managed Instance sur un réseau virtuel dans lequel un ou plusieurs noms de domaine de ce type sont remplacés, soit via des zones privées Azure DNS, soit par un serveur DNS personnalisé, échoue. Le remplacement de la résolution de ces domaines dans un réseau virtuel qui contient une instance managée rend cette instance managée non disponible. Pour plus d’informations sur la configuration des enregistrements DNS de liaison privée à l’intérieur d’un réseau virtuel qui contient des instances managées, consultez Configuration DNS des points de terminaison privés Azure.

Contenu connexe