Tests de connectivité interne automatiques pour Azure SQL Managed Instance

S’applique à :Azure SQL Managed Instance

Cet article décrit les tests de connectivité interne automatiques qui s’exécutent sur Azure SQL Managed Instance pour surveiller la fiabilité du service et accélérer la détection des problèmes.

Ces tests sont entièrement automatisés et ne nécessitent aucune action de votre part. La surveillance proactive des connexions réseau internes permet Microsoft d’identifier rapidement les problèmes potentiels et de maintenir une connectivité de bout en bout stable.

Les tests de connectivité s’exécutent à partir d’une paire d’adresses IP internes à partir de la plage de sous-réseaux qui héberge l’instance managée SQL. Les tests ne nécessitent aucune connectivité entrante ou sortante externe. Des adresses IP supplémentaires sont réservées aux tests de connectivité, et les traces peuvent apparaître dans les journaux d’observation.

À compter de mai 2026, les tests de connectivité s’exécutent à intervalles réguliers sur toutes les instances managées SQL.

Avantages

Les tests de connectivité interne automatiques offrent les avantages suivants :

• Diagnostiquer les problèmes de disponibilité du service interne et du réseau.
• Accélérez la découverte des problèmes et réduisez le temps d’atténuation.
• Améliorez la visibilité de l’état de mise en réseau interne de SQL Managed Instance.

Les résultats des tests sont utilisés en interne et ne reflètent pas dans Service Health ou Resource Health.

Impact sur l’exploitation

Les tests de connectivité interne ont l’impact opérationnel suivant :

• Deux adresses IP supplémentaires sont approvisionnées pour chaque groupe de machines virtuelles, ce qui augmente la configuration requise de l’adresse IP de six à huit. Pour plus d’informations, consultez Déterminer la taille et la plage du sous-réseau.
• Les tests s’exécutent toutes les 10 secondes et ont un impact négligeable sur le débit réseau et les performances du service.
• Les nouveaux sous-réseaux créés pour les instances managées SQL réservent automatiquement les adresses IP supplémentaires requises pour les tests de connectivité.
• Dans les sous-réseaux existants avec des instances managées SQL, les tests réservent des adresses IP supplémentaires uniquement si le sous-réseau a suffisamment d’adresses IP gratuites pour prendre en charge les adresses IP supplémentaires requises par les tests. Si un sous-réseau existant n’a pas suffisamment d’adresses IP gratuites, les tests ne s’exécutent pas.

Considérations relatives à la sécurité

Les principes de sécurité suivants guident la conception de tests de connectivité internes :

• Les tests sont étendus à une seule instance managée SQL et s’exécutent à l’intérieur de son réseau virtuel et de son sous-réseau délégués.
• Les tests de connectivité ne peuvent pas accéder au contenu d’une base de données.
• Les résultats des tests ne contiennent aucune donnée client au-delà du nom de l’instance.
• Seuls les ingénieurs Microsoft peuvent accéder aux résultats.
• Les systèmes d’audit peuvent enregistrer les tentatives de connexion ayant échoué générées par les tests. Pour plus d’informations sur l’identification de ces entrées, consultez Observer les connexions ayant échoué provoquées par les tests de bout en bout.

Tests effectués

Les tests de connectivité suivants s’exécutent automatiquement :

Surveiller les tentatives de connexion échouées causées par les tests de bout en bout

Le test de connectivité de bout en bout effectue intentionnellement une tentative de connexion infructueuse afin de valider l’ensemble de la chaîne de connectivité. Le test utilise la AzureSQLConnectivityChecker connexion, qui n'existe pas et s'attend à ce que Azure SQL Managed Instance retourne l'erreur 18456. Cette erreur vérifie que le chemin d’accès réseau entier à SQL Managed Instance est fonctionnel.

Les outils d’observabilité SQL peuvent détecter ces échecs de connexion. Utilisez les signatures suivantes pour identifier les entrées de test de connectivité et les distinguer des tentatives de connexion ayant échoué.

Les outils d’observabilité suivants détectent les échecs de connexion :

• Journaux d’audit
• Événements étendus
• Journaux d’erreurs SQL

Journaux d’audit

Lorsque vous activez FAILED_LOGIN_GROUP, les événements d’audit apparaissent environ toutes les 10 secondes en AzureDiagnostics:

Événements étendus

Sessions d’événements étendus qui capturent sqlserver.error_reported où error_number = 18456 et severity = 14 affichent les attributs suivants :

Par exemple, si l’authentification SQL est désactivée sur l’instance managée SQL, l’état est 170 et le message indique que l’authentification Microsoft Entra seule est activée.

Journaux d’erreurs SQL

Dans sp_readerrorlog, les échecs de connexion du test de connectivité apparaissent par paires de lignes :

et

Par exemple, lorsque l’authentification SQL est désactivée, le message indique que l’authentification Microsoft Entra seule est activée et inclut une adresse IP de sous-réseau.

Contenu connexe

• Architecture de connectivité d’Azure SQL Managed Instance
• Haute disponibilité pour Azure SQL Managed Instance
• Déterminer la taille et la plage du sous-réseau pour Azure SQL Managed Instance
• Questions fréquentes sur Azure SQL Managed Instance