Architecture de connectivité d’Azure SQL Managed Instance
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.
Remarque
La vague de fonctionnalités de novembre 2022 a introduit des modifications à la structure de connectivité par défaut de SQL Managed Instance. Cet article fournit des informations sur l’architecture actuelle et 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é de SQL Managed Instance :
- Le point de terminaison de gestion a été supprimé.
- Les règles de groupe de sécurité réseau obligatoires ont été simplifiées (une règle obligatoire a été supprimée).
- Les règles de groupe de sécurité réseau obligatoires ont été révisées afin de ne plus inclure plus le trafic sortant vers AzureCloud sur le port 443.
- La table de routage a été simplifiée (le nombre d’itinéraires obligatoires a été réduit de 13 à 5).
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.
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.
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.
- Point de terminaison local de réseau virtuel
- Point de terminaison public
- Points de terminaison privés
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 de réseau virtuel prennent en charge le type de connexion 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 fonctionne toujours dans le type de connexion Proxy.
Découvrez comment configurer un point de terminaison public dans Configurer un point de terminaison public pour Azure SQL Managed Instance.
Points de terminaison privés
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 fonctionnent toujours dans le type de connexion Proxy.
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
Cette section présente de plus près l’architecture de connectivité de cluster virtuel de SQL Managed Instance. Le diagramme suivant montre l’organisation conceptuelle du cluster virtuel :
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 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. La stratégie configure le sous-réseau, le groupe de sécurité réseau associé et la table de routage pour s’assurer que les exigences minimales pour SQL Managed Instance sont 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 de niveau de service 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.
Une configuration de sous-réseau assistée par le service s’appuie sur la fonctionnalité de délégation de sous-réseau du réseau virtuel pour fournir une gestion automatique de la configuration du réseau et pour activer les points de terminaison de service.
Vous pouvez utiliser des points de terminaison de service pour configurer des règles de pare-feu de réseau virtuel sur des comptes de stockage qui conservent des sauvegardes et des journaux d’audit. Même si les points de terminaison de service sont activés, les clients sont encouragés à utiliser Azure Private Link pour 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, une 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 avoir les 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. 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
- Les ressources de type
- 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.
Règles de sécurité obligatoires avec configuration du sous-réseau assistée par le service
Pour garantir le flux de trafic de gestion entrant, les règles décrites dans le tableau suivant sont requises. Les règles sont appliquées par la stratégie d’intention réseau et n’ont pas besoin d’être déployées par le client. Pour plus d’informations sur l’architecture de connectivité et le trafic de gestion, consultez Architecture de connectivité de haut niveau.
| Nom | Port | Protocole | Source | Destination | Action |
|---|---|---|---|---|---|
| healthprobe-in | Quelconque | Quelconque | AzureLoadBalancer | subnet | Autoriser |
| internal-in | Quelconque | Quelconque | subnet | subnet | Autoriser |
Pour garantir le flux de trafic de gestion sortant, les règles décrites dans le tableau suivant sont requises. Pour plus d’informations sur l’architecture de connectivité et le trafic de gestion, consultez Architecture de connectivité de haut niveau.
| Nom | Port | Protocole | 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
Les itinéraires décrits dans le tableau suivant sont nécessaires pour garantir que le trafic de gestion est acheminé directement vers une destination. Les itinéraires sont appliqués par la stratégie d’intention réseau et n’ont pas besoin d’être déployés par le client. Pour plus d’informations sur l’architecture de connectivité et le trafic de gestion, consultez Architecture de connectivité de haut niveau.
| 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
* La valeur Internet dans la colonne Tronçon suivant indique à la passerelle d’acheminer le trafic en dehors du réseau virtuel. Toutefois, si l’adresse de destination est celle d’un service Azure, Azure achemine le trafic directement vers le service sur le réseau 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 Routage du trafic de réseau virtuel Azure.
Vous pouvez aussi utiliser la passerelle de réseau virtuel ou une appliance de réseau virtuel 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 : à 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 :
- 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.
- 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.
- Zones privées Azure DNS avec un nom réservé aux services Microsoft : les noms de domaine suivants sont 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.netetvault.azure.net. Le déploiement de SQL Managed Instance sur un réseau virtuel auquel est associée une zone privée Azure DNS qui utilise un nom réservé aux services Microsoft échoue. L’association d’une zone privée Azure DNS qui utilise un nom réservé avec un réseau virtuel contenant une instance managée rend SQL Managed Instance indisponible. Pour plus d’informations sur la configuration de Private Link, consultez Configuration DNS du point de terminaison privé Azure.
Étapes suivantes
- Pour obtenir une vue d’ensemble, consultez Présentation d’Azure SQL Managed Instance.
- Pour en savoir plus, reportez-vous à l'architecture du cluster virtuel
- Découvrez comment configurer un nouveau réseau virtuel Azure ou un réseau virtuel Azure existant sur lequel vous pouvez déployer une instance managée SQL.
- Calculez la taille du sous-réseau sur lequel vous souhaitez déployer SQL Managed Instance.
- Découvrez comment créer une instance managée :
- À partir du portail Azure.
- En utilisant PowerShell.
- En utilisant un modèle Azure Resource Manager.
- En utilisant un modèle Azure Resource Manager avec un jumpbox et SQL Server Management Studio.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour