Share via


Behandlung von Problemen im Zusammenhang mit dem Zugriff, der Erfassung und dem Betrieb Ihres Azure Data Explorer-Clusters in Ihrem virtuellen Netzwerk

Wichtig

Ziehen Sie die Umstellung auf eine auf einem privaten Azure-Endpunkt basierende Lösung für die Implementierung der Netzwerksicherheit mit Azure Data Explorer in Erwägung. Diese Lösung ist weniger fehleranfällig und bietet Featureparität.

In diesem Abschnitt erfahren Sie, wie Sie Konnektivitäts-, Betriebs- und Clustererstellungsprobleme bei einem Cluster beheben können, der in Ihrem virtuellen Netzwerk bereitgestellt wird.

Zugriffsprobleme

Wenn beim Zugriff auf den Cluster über den öffentlichen („cluster.region.kusto.windows.net“) oder privaten („private-cluster.region.kusto.windows.net“) Endpunkt ein Problem auftritt und Sie vermuten, dass er im Zusammenhang mit dem Einrichten des virtuellen Netzwerks steht, führen Sie die folgenden Schritte zur Problembehandlung aus.

Überprüfen der TCP-Konnektivität

Der erste Schritt ist die Überprüfung der TCP-Konnektivität mithilfe von Windows oder Linux OS.

  1. Laden Sie TCping auf den Computer herunter, der eine Verbindung mit dem Cluster herstellt.

  2. Pingen Sie das Ziel vom Quellcomputer aus mit folgendem Befehl:

    C:\> tcping -t yourcluster.kusto.windows.net 443
    ** Pinging continuously.  Press control-c to stop **
    Probing 1.2.3.4:443/tcp - Port is open - time=100.00ms
    

Wenn der Test nicht erfolgreich war, setzen Sie den Vorgang mit den folgenden Schritten fort. Ist der Test aber erfolgreich, wurde das Problem nicht durch ein TCP-Konnektivitätsproblem verursacht. Wechseln Sie zu Betriebsprobleme, um mehr zur Problembehandlung zu erfahren.

Überprüfen von NSG-Regeln (Network Security Group, Netzwerksicherheitsgruppe)

Überprüfen Sie, ob es bei der NSG, die an das Subnetz des Clusters angefügt ist, eine eingehende Regel gibt, die den Zugriff über die IP-Adresse des Clientcomputers für Port 443 zulässt.

Überprüfen, ob die Routingtabelle konfiguriert ist, um Zugriffsprobleme zu vermeiden

Wenn für das Subnetz des Clusters die Tunnelerzwingung des gesamten Internetdatenverkehrs zurück zur Firewall konfiguriert wurde (Subnetz mit einer Routingtabelle, in der die Standardroute „0.0.0.0/0“ enthalten ist), vergewissern Sie sich, dass es in der IP-Adresse des Computers eine Route mit Typ des nächsten Hops zum virtuellen Netzwerk/Internet gibt. Diese Route ist erforderlich, um Probleme mit asymmetrischen Routen zu vermeiden.

Erfassungsprobleme

Wenn bei der Erfassung Probleme auftreten und Sie vermuten, dass sie im Zusammenhang mit der Einrichtung des virtuellen Netzwerks stehen, führen Sie die folgenden Schritte aus.

Überprüfen der Erfassungsintegrität

Überprüfen Sie, ob die Clustererfassungsmetriken einen fehlerfreien Status aufweisen.

Überprüfen von Sicherheitsregeln für Datenquellenressourcen

Wenn die Metriken angeben, dass keine Ereignisse aus der Datenquelle verarbeitet wurden (Metrik Verarbeitete Ereignisse für Event Hubs/IoT Hubs), vergewissern Sie sich, dass die Datenquellenressourcen (Event Hubs oder Storage) den Zugriff aus dem Subnetz des Clusters in den Firewallregeln oder Dienstendpunkten zulassen.

Überprüfen von Sicherheitsregeln, die im Subnetz des Clusters konfiguriert wurden

Vergewissern Sie sich, dass die NSG-, UDR- und Firewallregeln für das Subnetz des Clusters ordnungsgemäß konfiguriert wurden. Testen Sie außerdem die Netzwerkkonnektivität bei allen abhängigen Endpunkten.

Probleme bei der Clustererstellung und dem Betrieb

Wenn bei der Clustererstellung oder dem Betrieb Probleme auftreten und Sie vermuten, dass sie im Zusammenhang mit der Einrichtung des virtuellen Netzwerks stehen, führen Sie die folgenden Schritte zur Problembehandlung aus.

Überprüfen der Konfiguration „DNS-Server“

Die Einrichtung eines privaten Endpunkts erfordert die Konfiguration von DNS. Wir unterstützen nur die Einrichtung einer privaten Azure DNS-Zone. Die Einrichtung eines benutzerdefinierten DNS-Servers wird nicht unterstützt. Überprüfen Sie, ob die Datensätze, die als Teil eines privaten Endpunkts erstellt wurden, für die private Azure DNS-Zone registriert sind.

Diagnostizieren des virtuellen Netzwerks mit der REST-API

Der ARMClient dient zum Aufrufen der REST-API mithilfe von PowerShell.

  1. Anmelden mit ARMClient

    armclient login
    
  2. Diagnosevorgang aufrufen

    $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. Die Antwort überprüfen

    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. Auf Abschluss des Vorgangs warten

    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": {...}
    }
    

    Warten Sie, bis die Eigenschaft status die Meldung Completed (Abgeschlossen) anzeigt. Dann sollte im Feld properties (Eigenschaften) Folgendes angezeigt werden:

    {
      "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": [...]
      }
    }
    

Wenn die Eigenschaft Findings (Ergebnisse) ein leeres Ergebnis anzeigt, bedeutet dies, das alle Netzwerktests erfolgreich waren und keine Verbindungen unterbrochen sind. Wenn der Fehler Ausgehende Abhängigkeit {dependencyName}:{port} wurde möglicherweise nicht berücksichtigt (ausgehend) angezeigt wird, kann der Cluster die abhängigen Dienstendpunkte nicht erreichen. Fahren Sie mit den folgenden Schritten fort.

Überprüfen von NSG-Regeln

Stellen Sie sicher, dass die NSG gemäß den Anweisungen unter Konfigurieren von Netzwerksicherheitsgruppen-Regeln ordnungsgemäß konfiguriert wurde.

Überprüfen, ob die Routingtabelle konfiguriert ist, um Erfassungsprobleme zu vermeiden

Wenn für das Subnetz des Clusters die Tunnelerzwingung des gesamten Internetdatenverkehrs zurück zur Firewall konfiguriert wurde (Subnetz mit einer Routingtabelle, in der die Standardroute „0.0.0.0/0“ enthalten ist), vergewissern Sie sich, dass es in den Verwaltungs-IP-Adressen und IP-Adressen zur Systemüberwachung eine Route mit Typ des nächsten HopsInternet und Quelladresspräfix zu management-ip/32 und health-monitoring-ip/32 gibt. Diese Route ist erforderlich, um Probleme mit asymmetrischen Routen zu vermeiden.

Überprüfen von Firewallregeln

Wenn Sie den ausgehenden Datenverkehr des Tunnelsubnetzes an eine Firewall erzwingen, vergewissern Sie sich, dass alle Abhängigkeiten mit FQDN (z. B. .blob.core.windows.net) in der Firewallkonfiguration zulässig sind, wie in Sichern von ausgehendem Datenverkehr mit Firewall beschrieben wird.

Probleme beim Aussetzen von Clustern

Wenn der Cluster nicht angehalten werden kann, vergewissern Sie sich, dass keine Sperren für die Netzwerkressourcen in Ihrem Abonnement vorhanden sind.