Résoudre les problèmes d’accès, d’ingestion et de fonctionnement de votre cluster Azure Data Explorer dans votre réseau virtuel

Dans cette section, vous allez apprendre à résoudre les problèmes de connectivité, les problèmes de fonctionnement et les problèmes de création de cluster pour un cluster déployé dans votre réseau virtuel.

Problèmes liés à l’accès

Si vous rencontrez un problème lors de l’accès au cluster à l’aide du point de terminaison public (cluster.region.kusto.windows.net) ou privé (private-cluster.region.kusto.windows.net) et que vous pensez qu’il est lié à la configuration du réseau virtuel, procédez comme suit pour résoudre le problème.

Vérifier la connectivité TCP

La première étape comprend la vérification de la connectivité TCP à l’aide du système d’exploitation Windows ou Linux.

Si le test échoue, effectuez les étapes suivantes. Si le test réussit, le problème n’est pas dû à un problème de connectivité TCP. Accédez aux problèmes opérationnels pour approfondir la résolution des problèmes.

Vérifier les règles du groupe de sécurité réseau

Vérifiez que le groupe de sécurité réseau attaché au sous-réseau du cluster possède une règle de trafic entrant qui autorise l’accès à partir de l’adresse IP de l’ordinateur client pour le port 443.

Vérifier que la table de routage est configurée pour empêcher les problèmes d’accès

Si le sous-réseau du cluster est configuré pour forcer le tunneling de tout le trafic lié à Internet vers votre pare-feu (sous-réseau avec une table de routage contenant la route par défaut « 0.0.0.0/0 »), vérifiez que l’adresse IP de l’ordinateur a une route avec le type de tronçon suivant vers VirtualNetwork/Internet. Cet itinéraire est nécessaire pour éviter les problèmes de routage asymétrique.

Problèmes d’ingestion

Si vous rencontrez des problèmes d’ingestion et que vous soupçonnez qu’ils sont liés à une configuration de réseau virtuel, procédez comme suit.

Vérifier l’intégrité d’ingestion

Vérifiez que les métriques d’ingestion du cluster indiquent un état sain.

Vérifier les règles de sécurité sur les ressources de source de données

Si les métriques indiquent qu’aucun événement n’a été traité à partir de la source de données (métrique Événements traités pour les hubs d’événements/IoT), vérifiez que les ressources de source de données (hubs d’événements ou stockage) autorisent l’accès à partir du sous-réseau du cluster dans les règles de pare-feu ou les points de terminaison de service.

Vérifier les règles de sécurité configurées sur le sous-réseau du cluster

Vérifiez que les règles de groupe de sécurité réseau, de route définie par l’utilisateur et de pare-feu sont correctement configurées pour le sous-réseau du cluster. En outre, testez la connectivité réseau pour tous les points de terminaison dépendants.

Problèmes de création de cluster et de fonctionnement

Si vous rencontrez un problème de création de cluster ou de fonctionnement et que vous soupçonnez qu’il est lié à une configuration de réseau virtuel, procédez comme suit pour résoudre le problème.

Vérifier la configuration « Serveurs DNS »

La configuration d’un point de terminaison privé demande de configurer DNS. Nous prenons en charge la configuration d’une zone DNS privée Azure uniquement. La configuration personnalisée de serveur DNS n’est pas prise en charge, vérifiez que les enregistrements qui ont été créés dans le cadre du point de terminaison privé sont inscrits dans la zone de DNS privé Azure.

Diagnostiquer le réseau virtuel avec l’API REST

L’outil ARMClient permet d’appeler l’API REST à l’aide de PowerShell.

1. Se connecter avec ARMClient

   armclient login
   

2. Appeler l’opération de diagnostic

   $subscriptionId = '<subscription id>'
   $clusterName = '<name of cluster>'
   $resourceGroupName = '<resource group name>'
   $apiversion = '2019-11-09'
   
   armclient post "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Kusto/clusters/$clusterName/diagnoseVirtualNetwork?api-version=$apiversion" - verbose
   

3. Vérifier la réponse

   HTTP/1.1 202 Accepted
   ...
   Azure-AsyncOperation: https://management.azure.com/subscriptions/{subscription-id}/providers/Microsoft.Kusto/locations/{location}/operationResults/{operation-id}?api-version=2019-11-09
   ...
   

4. Attendre la fin de l’opération

   armclient get https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.Kusto/locations/{location}/operationResults/{operation-id}?api-version=2019-11-09
   
   {
     "id": "/subscriptions/{subscription-id}/providers/Microsoft.Kusto/locations/{location}/operationresults/{operation-id}",
     "name": "{operation-name}",
     "status": "[Running/Failed/Completed]",
     "startTime": "{start-time}",
     "endTime": "{end-time}",
     "properties": {...}
   }
   

   Attendez que la propriété status indique Completed, le champ properties doit alors indiquer :

   {
     "id": "/subscriptions/{subscription-id}/providers/Microsoft.Kusto/locations/{location}/operationresults/{operation-id}",
     "name": "{operation-name}",
     "status": "Completed",
     "startTime": "{start-time}",
     "endTime": "{end-time}",
     "properties": {
       "Findings": [...]
     }
   }
   

Si la propriété Findings affiche un résultat vide, cela signifie que tous les tests réseau ont réussi et qu’aucune connexion n’est interrompue. Si l’erreur suivante s’affiche, La dépendance sortante '{dependencyName}:{port}' n’est peut-être pas satisfaite (sortante), le cluster ne peut pas atteindre les points de terminaison du service dépendant. Procédez avec les étapes suivantes.

Vérifier les règles NSG

Vérifiez que le groupe de sécurité réseau est correctement configuré conformément aux instructions fournies dans Configurer des règles de groupe de sécurité réseau.

Vérifier que la table de routage est configurée pour empêcher les problèmes d’ingestion

Si le sous-réseau du cluster est configuré pour forcer le tunneling de tout le trafic lié à Internet vers votre pare-feu (sous-réseau avec une table de routage qui contient la route par défaut « 0.0.0.0/0 »), vérifiez que les adresses IP de gestion et les adresses IP de monitoring de l’intégrité ont une route avec type de tronçon suivant Internet et préfixe d’adresse source sur 'management-ip/32' et 'health-monitoring-ip/32'. Cet itinéraire nécessaire pour éviter les problèmes de routage asymétrique.

Vérifier les règles de pare-feu

Si vous forcez le trafic sortant du sous-réseau de tunnel vers un pare-feu, vérifiez que les noms de domaine complet de toutes les dépendances (par exemple, .blob.core.windows.net) sont autorisés dans la configuration du pare-feu, comme décrit dans Sécurisation du trafic sortant avec pare-feu.

Problèmes de suspension de cluster

S’il est impossible de suspendre le cluster, vérifiez qu’il n’existe aucun verrou sur les ressources de mise en réseau de votre abonnement.