Architecture de connectivité d’Azure SQL Managed Instance

S’applique à : Azure SQL Managed Instance

Cet article explique la communication dans Azure SQL Managed Instance, décrivant l’architecture de connectivité et la façon dont les composants dirigent le trafic vers une instance gérée.

SQL Managed Instance se trouve à l’intérieur du réseau virtuel Azure et du sous-réseau dédié aux instances managées. Ce déploiement offre :

  • Une adresse IP locale sécurisée du réseau virtuel.
  • 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.

Remarque

Le mois de novembre 2022 a vu l’introduction d’un certain nombre de modifications à la structure de connectivité par défaut pour SQL Managed Instance. Cet article fournit des informations sur l’architecture actuelle, ainsi que sur l’architecture des instances qui n’ont pas encore été inscrites dans la vague de fonctionnalités. Pour plus d’informations, consultez Vague de fonctionnalités de novembre 2022.

Vague de fonctionnalités de novembre 2022

La vague de fonctionnalités de novembre 2022 a introduit les modifications suivantes dans l’architecture de connectivité pour SQL Managed Instance :

  • Le point de terminaison de gestion a été supprimé.
  • Les règles de groupe de sécurité réseau (NSG) obligatoires ont été simplifiées (une règle obligatoire a été supprimée).
  • Les règles de groupe de sécurité réseau obligatoires n’incluent plus le trafic sortant vers AzureCloud sur le port 443.
  • La table de routage a été simplifiée (le nombre de routes obligatoires a été réduit de 13 à 5).

Vue d’ensemble des communications

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 figurant dans l’architecture de connectivité pour Azure SQL Managed Instance

SQL Managed Instance est une offre PaaS (Platform-as-a-Service) monolocataire qui fonctionne sur deux plans : le plan de données et le 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. Il est généralement accessible via son point de terminaison local de réseau virtuel. Le plan de données dépend des services Azure, tels que Stockage Azure, Azure Active Directory (Azure AD) pour l’authentification, et des services de collecte de télémétrie. Les clients observeront le trafic vers ces services à partir des sous-réseaux contenant SQL Managed Instance.

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 disposent d’un accès exclusif aux ressources de calcul qui exploitent le service : il n’est pas possible d’utiliser ssh ni RDP 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, les instances managées SQL vérifient en permanence ces certificats à l’aide de listes de révocation de certificat.

Architecture de la connectivité globale

Globalement, SQL Managed Instance est un ensemble de composants de service hébergés sur un ensemble dédié de machines virtuelles isolées, 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 fonctionnent dans un environnement réseau sécurisé géré par Microsoft.

Un cluster virtuel peut héberger plusieurs instances gérées. Le cluster s’étend ou se contracte automatiquement en fonction des besoins pour prendre en charge l’ajout ou la suppression d’instances.

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.

Diagramme montrant l’architecture de connectivité pour Azure SQL Managed Instance

Pour faciliter la connectivité avec les applications clientes, SQL Managed Instance propose deux types de points de terminaison : le point de terminaison local de réseau virtuel et le point de terminaison public.

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. Il s’agit d’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.

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. Ce point de terminaison permet uniquement au trafic TDS d’atteindre SQL Managed Instance et ne peut pas être utilisé pour les scénarios d’intégration (tels que les groupes de basculement, la liaison Managed Instance et d’autres technologies similaires).

Architecture de la connectivité du cluster virtuel

Examinons plus en détail l’architecture de connectivité de SQL Managed Instance. Le diagramme suivant montre l’organisation conceptuelle du cluster virtuel.

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

Les clients se connectent à SQL Managed Instance en utilisant le nom d’hôte qui a la forme suivante : <mi_name>.<dns_zone>.database.windows.net. Ce nom d’hôte se résout en une adresse IP privée, bien qu’elle soit inscrite dans une zone DNS (Domain Name System) publique et puisse être résolue publiquement. L’identifiant zone-id est généré 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. Pour plus d’informations, consultez Utiliser des groupes de basculement automatique pour permettre le basculement transparent et coordonné de plusieurs bases de données.

Cette adresse IP privée appartient à l’équilibreur de charge interne de SQL Managed Instance. Il redirige le trafic vers la passerelle de 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 de SQL Managed Instance pour rediriger le trafic vers le service du moteur SQL approprié.

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

Pour améliorer la sécurité, la facilité de gestion et la disponibilité du service, SQL Managed Instance applique une stratégie d’intention réseau à certains éléments de l’infrastructure de réseau virtuel Azure. Cette stratégie configure le sous-réseau, le groupe de sécurité réseau (NSG) et la table de routage associés, en veillant à ce que les exigences minimales pour SQL Managed Instance soient remplies. Ce mécanisme de plateforme transmet les exigences réseau aux utilisateurs de manière transparente. L’objectif principal de la stratégie est d’éviter une mauvaise configuration du réseau et de veiller à l’engagement du contrat SLA et au bon fonctionnement de SQL Managed Instance. Lorsque vous supprimez une instance gérée, la stratégie d’intention de réseau est également supprimée.

La configuration de sous-réseau assistée par le service s’appuie sur la fonctionnalité de délégation de sous-réseau de réseau virtuel pour fournir une gestion automatique de la configuration du réseau et activer les points de terminaison de service.

Des points de terminaison de service peuvent être utilisés pour configurer des règles de pare-feu de réseau virtuel sur des comptes de stockage qui conservent des sauvegardes et journaux d’audit. Même si les points de terminaison de service sont activés, les clients sont encouragés à utiliser Private Link afin d’accéder à leurs comptes de stockage. Private Link fournit un isolement supplémentaire par rapport aux points de terminaison de service.

Important

En raison des spécificités de la configuration du plan de contrôle, la configuration de sous-réseau assistée par le service n’active pas les points de terminaison de service dans les clouds nationaux.

Configuration requise pour le réseau

Le sous-réseau dans lequel SQL Managed Instance est déployé doit répondre aux caractéristiques 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. Il ne peut pas s’agir d’un sous-réseau de passerelle et vous pouvez uniquement y déployer des ressources SQL Managed Instance.
  • Délégation de sous-réseau : le sous-réseau de SQL Managed Instance doit être délégué à un fournisseur de ressources Microsoft.Sql/managedInstances.
  • Groupe de sécurité réseau : Un groupe de sécurité réseau (NSG) 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 de l’instance managée SQL en filtrant le trafic sur les ports 1433 et 11000 à 11999 quand SQL Managed Instance est configuré pour rediriger les connexions. Le service approvisionne et conserve automatiquement les règles actuelles requises 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 utiliser la passerelle de réseau virtuel ou une appliance de réseau virtuel (NVA) pour ajouter des entrées à la table d’itinéraires pour acheminer le trafic disposant de plages d’adresses IP privées locales en tant que destination. Le service approvisionne et conserve automatiquement les entrées actuelles requises pour permettre un flux ininterrompu du trafic de gestion.
  • 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 gérées dans le réseau existant une fois que vous l’avez 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 des stratégies Azure Policy pour refuser la création ou la modification de ressources dans l’étendue qui comprend un sous-réseau/réseau virtuel SQL Managed Instance, ces 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 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 ces verrous.
  • Trafic de réplication : le trafic de réplication pour les groupes de basculement automatique entre deux instances SQL Managed Instance 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 en mesure de résoudre les enregistrements DNS publics. Des résolutions de noms de domaine complets (FQDN) additionnels peuvent être nécessaires si vous utilisez des fonctionnalités supplémentaires comme Azure AD Authentication. Pour plus d’informations, consultez Résolution des noms DNS privés dans Azure SQL Managed Instance.

Règles de sécurité obligatoires avec configuration du sous-réseau assistée par le service

Ces règles sont nécessaires pour garantir le flux du trafic de gestion entrant. Elles sont appliquées par la stratégie d’intention réseau et n’ont pas besoin d’être déployées par le client. Consultez la section précédente sur l’architecture de connectivité de haut niveau pour plus d’informations sur l’architecture de connectivité et le trafic de gestion.

Nom Port Protocol Source Destination Action
internal-in Quelconque Quelconque subnet subnet Autoriser

Ces règles sont nécessaires pour garantir le flux du trafic de gestion sortant. Consultez le paragraphe ci-dessus pour plus d’informations sur l’architecture de connectivité et le trafic de gestion.

Nom Port Protocol Source Destination Action
AAD-out 443 TCP subnet AzureActiveDirectory Allow
OneDsCollector-out 443 TCP subnet OneDsCollector Autoriser
internal-out Quelconque Quelconque subnet subnet Autoriser
StorageP-out 443 Quelconque subnet Storage.primaryRegion Autoriser
StorageS-out 443 Quelconque subnet Storage.secondaryRegion Autoriser

Routes obligatoires avec configuration de sous-réseau assistée par le service

Ces itinéraires sont nécessaires pour garantir que le trafic de gestion est acheminé directement vers une destination. Elles sont appliquées par la stratégie d’intention réseau et n’ont pas besoin d’être déployées par le client. Consultez la section précédente sur l’architecture de connectivité de haut niveau pour plus d’informations sur l’architecture de connectivité et le trafic de gestion.

Nom Préfixe de l’adresse Tronçon suivant
AzureActiveDirectory AzureActiveDirectory Internet*
OneDsCollector OneDsCollector Internet*
Storage.primaryRegion Storage.primaryRegion Internet*
Storage.secondaryRegion Storage.secondaryRegion Internet*
subnet-to-vnetlocal subnet Réseau virtuel

Remarque

*Internet : cette valeur dans le champ « tronçon suivant » indique à la passerelle d’acheminer le trafic en dehors du réseau virtuel. Toutefois, si l’adresse de destination correspond à l’un des services d’Azure, Azure achemine le trafic directement à ce service via le réseau principal Azure plutôt qu’en dehors du cloud Azure. Le trafic entre les services Azure ne traverse pas le réseau Internet, quelle que soit la région Azure où le réseau virtuel existe ou la région Azure dans laquelle une instance du service Azure est déployée. Pour plus d’informations, consultez la page sur le routage du trafic de réseau virtuel d’Azure.

En outre, vous pouvez utiliser la passerelle de réseau virtuel ou une appliance de réseau virtuel (NVA) pour ajouter des entrées à la table d’itinéraires pour acheminer le trafic disposant de plages d’adresses IP privées locales en tant que destination.

Contraintes de mise en réseau

TLS 1.2 est appliqué aux connexions sortantes : En 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 des versions de SQL Server antérieures à 2016 avec SQL Managed Instance, vérifiez que les mises à jour spécifiques de TLS 1.2 ont été appliquées.

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

  • 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, ce qui engendre des problèmes de disponibilité. Des déploiements de SQL Managed Instance sur un réseau virtuel avec une homologation Microsoft déjà activée sont supposés échouer.
  • Homologation de réseau virtuel mondial : La connectivité de peering de réseau virtuel entre régions Azure ne fonctionne pas pour les instances SQL Managed Instance placées dans des sous-réseaux créés avant le 22/9/2020.
  • 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 rendrait SQL Managed Instance indisponible. Le service SQL Managed Instance est actuellement limité à l’utilisation d’un équilibreur de charge de base qui ne permet pas la coexistence de flux entrants et sortants avec le service NAT de réseau virtuel.
  • 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 NSG (groupe de sécurité réseau) ou d’une table UDR (table de routage) contenant des préfixes d’adresses IPv6 à un sous-réseau SQL Managed Instance, ou l’ajout de préfixes d’adresses IPv6 à un groupe NSG ou une table UDR déjà associé(e) à un sous-réseau Managed Instance, ne permet pas d’utiliser SQL Managed Instance. Les déploiements de SQL Managed Instance sur un sous-réseau avec un groupe NSG et une table UDR disposant déjà de préfixes IPv6 se soldent par un échec.
  • Zones privées Azure DNS avec un nom réservé aux services Microsoft : Voici la liste des noms réservés :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, vault.azure.net. Le déploiement de SQL Managed Instance sur un réseau virtuel auquel est associée une zone privée Azure DNS avec un nom réservé aux services Microsoft échoue. L’association d’une zone privée Azure DNS avec un nom réservé à un réseau virtuel contenant une instance rendrait SQL Managed Instance indisponible. Respectez la configuration DNS du point de terminaison privé Azure pour une configuration correcte d’Azure Private Link.

Étapes suivantes