Dela via


Felsöka åtkomst, inmatning och drift av ditt Azure Data Explorer-kluster i ditt virtuella nätverk

Viktigt

Överväg att flytta till en Azure Private Endpoint-baserad lösning för att implementera nätverkssäkerhet med Azure Data Explorer. Den är mindre felbenägen och ger funktionsparitet.

I det här avsnittet får du lära dig hur du felsöker problem med anslutning, drift och klusterskapande för ett kluster som distribueras till din Virtual Network.

Åtkomstproblem

Om du har problem med att komma åt klustret med hjälp av den offentliga (cluster.region.kusto.windows.net) eller den privata slutpunkten (private-cluster.region.kusto.windows.net) och du misstänker att den är relaterad till konfiguration av virtuellt nätverk utför du följande steg för att felsöka problemet.

Kontrollera TCP-anslutningen

Det första steget omfattar kontroll av TCP-anslutning med windows- eller Linux-operativsystem.

  1. Ladda ned TCping till datorn som ansluter till klustret.

  2. Pinga målet från källdatorn med hjälp av följande kommando:

    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
    

Om testet inte lyckas fortsätter du med följande steg. Om testet lyckas beror problemet inte på ett TCP-anslutningsproblem. Gå till driftproblem för att felsöka ytterligare.

Kontrollera NSG-regler (Network Security Group)

Kontrollera att nätverkssäkerhetsgruppen som är ansluten till klustrets undernät har en regel för inkommande trafik som tillåter åtkomst från klientdatorns IP-adress för port 443.

Kontrollera att routningstabellen är konfigurerad för att förhindra åtkomstproblem

Om klustrets undernät har konfigurerats för att tvinga tillbaka all Internetbunden trafik till brandväggen (undernät med en routningstabell som innehåller standardvägen "0.0.0.0/0" kontrollerar du att datorns IP-adress har en väg med nästa hopptyp till VirtualNetwork/Internet. Den här vägen krävs för att förhindra problem med asymmetrisk väg.

Problem med inmatning

Om du har problem med inmatning och misstänker att det är relaterat till konfiguration av virtuellt nätverk utför du följande steg.

Kontrollera inmatningshälsa

Kontrollera att måtten för klusterinmatning anger ett felfritt tillstånd.

Kontrollera säkerhetsregler för datakällans resurser

Om måtten anger att inga händelser har bearbetats från datakällan (händelser bearbetade mått för Event/IoT Hubs) kontrollerar du att datakällresurserna (Event Hubs eller Storage) tillåter åtkomst från klustrets undernät i brandväggsreglerna eller tjänstslutpunkterna.

Kontrollera säkerhetsregler som konfigurerats i klustrets undernät

Kontrollera att klustrets undernät har NSG, UDR och brandväggsregler korrekt konfigurerade. Testa dessutom nätverksanslutningen för alla beroende slutpunkter.

Problem med att skapa kluster och åtgärder

Om du har problem med att skapa eller åtgärda kluster och misstänker att det är relaterat till konfiguration av virtuellt nätverk följer du de här stegen för att felsöka problemet.

Kontrollera konfigurationen av DNS-servrar

Konfiguration av privat slutpunkt kräver konfiguration av DNS. Vi stöder endast konfiguration av Azure Privat DNS zon. Anpassad DNS-serverkonfiguration stöds inte. Kontrollera att posterna som skapades som en del av den privata slutpunkten är registrerade i Azure Privat DNS zon.

Diagnostisera det virtuella nätverket med REST-API:et

ARMClient används för att anropa REST-API:et med hjälp av PowerShell.

  1. Logga in med ARMClient

    armclient login
    
  2. Anropa diagnoseringsåtgärd

    $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. Kontrollera svaret

    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. Vänta tills åtgärden har slutförts

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

    Vänta tills statusegenskapen visar Slutförd. Sedan ska egenskapsfältet visa:

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

Om egenskapen Resultat visar ett tomt resultat innebär det att alla nätverkstester har godkänts och att inga anslutningar bryts. Om följande fel visas kanske utgående beroende {dependencyName}:{port} inte uppfylls (utgående) kan klustret inte nå de beroende tjänstslutpunkterna. Fortsätt med följande steg.

Kontrollera NSG-regler

Kontrollera att NSG:n är korrekt konfigurerad enligt anvisningarna i Konfigurera regler för nätverkssäkerhetsgrupp.

Kontrollera att routningstabellen är konfigurerad för att förhindra inmatningsproblem

Om klustrets undernät har konfigurerats för att tvinga tunneltrafik tillbaka all Internetbunden trafik till brandväggen (undernät med en routningstabell som innehåller standardvägen "0.0.0.0/0") kontrollerar du att hanterings-IP-adresserna) och ip-adresserna för hälsoövervakning har en väg med nästa hopptypInternet och källadressprefixettill "management-ip/32" och "health-monitoring-ip/32". Den här vägen krävs för att förhindra problem med asymmetrisk väg.

Kontrollera brandväggsreglerna

Om du tvingar utgående trafik från tunnelundernätet till en brandvägg kontrollerar du att alla beroenden FQDN (till exempel .blob.core.windows.net) tillåts i brandväggskonfigurationen enligt beskrivningen i skydda utgående trafik med brandväggen.

Problem med klusteravstängning

Om klustret inte pausas kontrollerar du att det inte finns några lås på nätverksresurserna i din prenumeration.