Partager via

Connectivité réseau pour SQL Managed Instance avec Azure Arc

  • Article

Les services de données avec Azure Arc prennent en charge deux modes de connectivité différents. Les modes connecté directement et connecté indirectement déploient SQL Managed Instance avec Azure Arc s’exécutant sur des clusters Kubernetes avec Azure Arc avec un plan de contrôle Azure Arc.

Les composants des services de données avec Arc sont les suivants :

  • Contrôleur de données Azure Arc
  • Connecteur Active Directory Azure Arc
  • SQL Managed Instance avec Azure Arc

Ces composants communiquent avec les points de terminaison Azure Arc, les contrôleurs de domaine Active Directory et les serveurs DNS (Domain Name System) qui s’exécutent localement et dans d’autres environnements cloud.

Cet article décrit l’architecture réseau, les considérations relatives à la conception et les recommandations de conception pour la connexion au plan de contrôle Azure à partir d’une infrastructure locale ou cloud. Vous allez découvrir comment gérer et exploiter des services de données avec Arc et SQL Managed Instance avec Arc s’exécutant sur des clusters Kubernetes avec Arc dans des environnements locaux et d’autres environnements cloud.

Architecture

Le diagramme suivant illustre une architecture réseau des services de données avec Arc qui prend en charge les modes réseau « connecté directement » et « connecté indirectement ».

Diagramme montrant une architecture réseau des services de données avec Azure Arc.

Le diagramme de scénario suivant montre un exemple de différents services consommateurs qui accèdent de manière sécurisée à SQL Managed Instance avec Arc.

Diagramme montrant une architecture réseau avec accès sécurisé des services de données avec Azure Arc.

Remarques relatives à la conception

  • Passez en revue la topologie réseau et la zone de conception de connectivité des zones d’atterrissage Azure pour aligner la connectivité réseau des services de données avec Arc avec la conception de zone d’atterrissage adoptée par votre organisation.

  • Passez en revue la connectivité réseau pour Kubernetes avec Azure Arc afin de comprendre l’architecture réseau et les recommandations et ainsi prendre des décisions de conception appropriées pour le déploiement et l’exploitation des services de données avec Arc sur un cluster Kubernetes avec Arc. Les services de données avec Arc utilisent la connectivité réseau Kubernetes avec Azure Arc pour le déploiement de service et les opérations.

  • Passez en revue la disponibilité des fonctionnalités des services de données avec Arc par mode de connectivité et les exigences réseau pour les services de données avec Azure Arc. Déterminez si le mode « connecté directement » ou le mode « connecté indirectement » s’aligne le mieux avec les stratégies de sécurité réseau de votre organisation sur le réseau local ou d’autres fournisseurs de cloud.

  • Le mode « connecté directement » nécessite une connexion directe à Azure et offre d’autres avantages inhérents à cette connectivité. Prenez en compte les compromis nécessaires pour activer cette connexion directe en fonction des exigences de sécurité et de conformité de votre organisation.

  • En fonction de l’emplacement d’exécution du cluster Kubernetes avec Arc, envisagez d’utiliser un type Kubernetes LoadBalancer ou NodePort. Ces services exposent des services de données avec Arc tels que le contrôleur de données et SQL Managed Instance. Un équilibreur de charge conserve le même numéro de port sur plusieurs instances, tandis que le port de nœud nécessite des numéros de port différents pour chaque SQL Managed Instance avec Arc.

  • Pour le service SQL Managed Instance avec Arc, vous pouvez déployer des types d’équilibreur de charge logiciel tels que MetalLB dans les environnements locaux, et des équilibreurs de charge internes dans les environnements cloud. Les équilibreurs de charge fournissent des adresses IP cohérentes et des ports SQL Server tels que 1433 ou des ports personnalisés, et ils équilibrent la charge des nœuds dans le cluster Kubernetes. Les adresses IP de nœud changent dans les clusters à mise à l’échelle automatique. Elles ne fournissent pas de haute disponibilité lorsque les pods passent d’un nœud Worker Kubernetes à un autre, par exemple lors du basculement, des mises à niveau et de la maintenance des clusters Kubernetes, des contrôleurs de données et de SQL Managed Instance avec Arc.

  • Envisagez d’utiliser des ports TLS (Transport Layer Security) tels que 636 et 3269 plutôt que les ports non TLS 389 et 3268 avec les services de domaine Active Directory. Les ports TLS sécurisent les connexions lors de l’utilisation de l’authentification AD dans SQL Managed Instance avec Azure Arc.

  • Lorsque vous utilisez Azure Key Vault pour protéger les secrets Kubernetes de SQL Managed Instance avec Arc pour l’authentification AD, vous pouvez utiliser des points de terminaison privés Azure Key Vault pour garantir le caractère privé des connexions. Pour plus d’informations sur l’utilisation d’Azure Key Vault avec des clusters Kubernetes avec Arc et pour savoir comment extraire des secrets dans des clusters Kubernetes avec Azure Arc, consultez Extension de fournisseur de secrets Azure Key Vault.

  • Comparez les points de terminaison publics et privés lors de l’utilisation de l’objet blob d’archive de compte Stockage Azure pour conserver les fichiers de sauvegarde de base de données SQL Managed Instance avec Arc pour la conservation à long terme.

Recommandations de conception

  • Passez en revue les recommandations de conception réseau Kubernetes avec Azure Arc lorsque SQL Managed Instance avec Arc est déployé sur un cluster Kubernetes avec Arc existant.

  • Utilisez le mode « connecté directement » au lieu du mode « connecté directement » pour le déploiement de vos services de données avec Arc et de SQL Managed Instance avec Arc, afin de tirer parti des avantages en matière de fonctionnalités offerts par le déploiement en mode « connecté directement ».

  • Choisissez le type de service Kubernetes LoadBalancer plutôt que le type de service NodePort pour les services de données avec Arc tels que le contrôleur de données, les tableaux de bord et SQL Managed Instance avec Arc. Le type LoadBalancer fournit une résilience en cas de défaillance de nœud Kubernetes, de redémarrage de nœud et de suppression de nœuds lors de la mise à niveau et de la maintenance des clusters Kubernetes.

  • Utilisez des équilibreurs de charge internes plutôt que des équilibreurs de charge externes lors de l’utilisation de l’infrastructure cloud publique pour le déploiement des services de données avec Arc. L’équilibreur de charge interne affecte des adresses IP privées du réseau virtuel, et fait en sorte que le trafic de base de données reste privé sur le réseau interne.

  • Pour le déploiement local, utilisez un équilibreur de charge conteneurisé tel que MetalLB pour prendre en charge le type de service d’équilibreur de charge. Un équilibreur de charge conteneurisé simplifie les règles de pare-feu à l’aide du port SQL standard 1433. Son application est plus simple que l’utilisation de ports aléatoires avec le type de service NodePort. Veillez à allouer une taille CIDR de sous-réseau pour prendre en charge le nombre d’instances SQL Managed Instances avec Arc déployées sur le cluster Kubernetes avec Azure Arc.

  • Lorsque vous utilisez l’authentification AD pour SQL Managed Instance avec Arc à la fois dans les modes avec clé gérée par le système et gérée par le client, veillez à automatiser l’inscription DNS pour les points de terminaison SQL Managed Instance avec Arc. L’automatisation vous aide à découvrir les services à l’aide de serveurs DNS locaux ou d’autres serveurs DNS cloud. Elle élimine également la surcharge des opérations et met automatiquement à jour les adresses IP lorsqu’elles changent ou lorsque vous supprimez une instance de service.

  • Utilisez des règles de pare-feu pour restreindre l’accès réseau aux points de terminaison de tableaux de bord, de contrôleur de données et SQL Managed Instance, afin d’empêcher l’accès à partir de sources non approuvées. Les règles de pare-feu réduisent la surface d’attaque de SQL Managed Instance avec Arc et empêchent l’exfiltration des données.

  • Lorsque vous utilisez des points de terminaison privés Azure pour Registre des artefacts Microsoft (également appelé Microsoft Container Registry ou MCR), Azure Key Vault, Azure Log Analytics et des comptes de stockage, configurez les serveurs DNS locaux de façon à transférer les requêtes DNS vers un redirecteur DNS dans Azure. Cette approche permet la découverte automatique de ces points de terminaison privés à l’aide de noms DNS, et élimine la nécessité d’utiliser des entrées d’hôte ou l’inscription d’entrée DNS dans les serveurs DNS locaux.

  • L’authentification AD pour SQL Managed Instance avec Arc nécessite une connexion aux services de domaine Active Directory. Configurez la connectivité aux contrôleurs de domaine dans les sites principaux et de reprise d’activité après sinistre pour la haute disponibilité. De nombreuses entreprises déployant des forêts de récupération de site dans des zones géographiques, pensez à utiliser le site le plus proche afin de réduire la latence réseau aux contrôleurs de domaine. Passez en revue cet article sur la continuité d’activité et la reprise d’activité SQL Managed Instance avec Arc pour obtenir plus d’instructions.

Étapes suivantes

Pour plus d’informations sur votre parcours cloud hybride et multicloud, consultez les articles suivants :