Implantar o cluster do Azure Data Explorer na sua Rede Virtual

Este artigo explica os recursos que estão presentes quando ao implantar um cluster do Azure Data Explorer em uma Rede Virtual do Microsoft Azure. Essas informações ajudarão você a implantar um cluster em uma sub-rede em sua Rede Virtual (VNet). Para obter mais informações sobre Redes Virtuais do Microsoft Azure, veja O que é uma Rede Virtual do Microsoft Azure?

O Azure Data Explorer dá suporte à implantação de um cluster em uma sub-rede na sua VNet (rede virtual). Essa nova funcionalidade permite a você:

• Impor regras de NSG (grupo de segurança de rede) no seu tráfego de cluster do Azure Data Explorer.
• Conectar a rede local para a sub-rede do cluster do Azure Data Explorer.
• Proteger suas fontes de conexão de dados (Hubs de Eventos e a Grade de Eventos) com pontos de extremidade de serviço.

Aceda ao cluster do Azure Data Explorer na sua rede virtual

Você pode acessar o cluster do Azure Data Explorer usando os seguintes endereços IP para cada serviço (serviços de gerenciamento de dados e mecanismo):

• IP privado: usado para acessar o cluster dentro da rede virtual.
• IP público: usado para acessar o cluster de fora da rede virtual para gerenciamento e monitoramento e como endereço de origem para conexões de saída iniciadas no cluster.

Os seguintes registros DNS são criados para acessar o serviço:

• [clustername].[geo-region].kusto.windows.net (mecanismo)ingest-[clustername].[geo-region].kusto.windows.net (gerenciamento de dados) são mapeados para o IP público para cada serviço.

• private-[clustername].[geo-region].kusto.windows.net (mecanismo)ingest-private-[clustername].[geo-region].kusto.windows.net\private-ingest-[clustername].[geo-region].kusto.windows.net (gerenciamento de dados) são mapeados para o IP privado para cada serviço.

Planeje o tamanho da sub-rede na sua rede virtual

O tamanho da sub-rede usada para hospedar um cluster do Azure Data Explorer não pode ser alterado depois que a sub-rede é implantada. Na sua rede virtual, o Azure Data Explorer utiliza um endereço IP privado para cada VM e dois endereços IP privados para os equilibradores de carga internos (motor e gestão de dados). A rede do Azure também usa cinco endereços IP para cada sub-rede. O Azure Data Explorer provisiona duas VMs para o serviço de gerenciamento de dados. As VMs do serviço de mecanismo são provisionadas por capacidade de escala de configuração do usuário.

O número total de endereços IP:

Pontos de extremidade de serviço para conexão com o Azure Data Explorer

O Azure Service Endpoints permite-lhe proteger os seus recursos multi-inquilinos do Azure na sua rede virtual. A implantação do cluster em sua sub-rede permite que você configure conexões de dados com os Hubs de Eventos ou a Grade de Eventos ao restringir os recursos subjacentes para a sub-rede do Azure Data Explorer.

Pontos de extremidade privados

Os Pontos de Extremidade Privado permitem acesso privado aos recursos do Azure (como hub de armazenamento/evento/Data Lake Gen 2) e usam IP privado da sua Rede Virtual, trazendo efetivamente o recurso para a sua rede virtual. Crie um ponto de extremidade privado para recursos utilizados por ligações de dados, como hub de eventos e armazenamento, e tabelas externas, como Armazenamento, Data Lake Gen 2 e Banco de Dados SQL do Microsoft Azure da sua rede virtual para aceder aos recursos subjacentes de forma privada.

Configurar regras do grupo de segurança de rede

NSGs oferece a capacidade de controlar o acesso à rede dentro de uma rede virtual. Você deve configurar NSGs para que seu cluster do Azure Data Explorer funcione em sua rede virtual.

Configurar regras do Grupo de Segurança de Rede usando a delegação de sub-rede

A delegação de sub-rede é o método padrão para configurar regras do Grupo de Segurança de Rede para clusters do Azure Data Explorer implantados em uma sub-rede na sua rede virtual. Ao usar a delegação de sub-rede, você precisa delegar a sub-rede a Microsoft.Kusto/clusters antes de criar o cluster na sub-rede.

Ao habilitar a delegação de sub-rede na sub-rede do cluster, você permite que o serviço defina as próprias pré-condições para implantação na forma de Políticas de Intenção de Rede. Ao criar o cluster na sub-rede, as configurações do NSG mencionadas nas seções a seguir são criadas automaticamente para você.

Configurar regras do grupo de segurança de rede manualmente

Como alternativa, você pode configurar manualmente seu NSG. Por padrão, implantar um cluster em uma rede virtual impõe a delegação de sub-rede para que "Microsoft.Kusto/clusters" seja configurado. Recusar esse requisito é possível usando o painel Versão prévia do recurso.

Configuração de entrada do NSG

Configuração de entrada do NSG

As seções a seguir listam os endereços IP relevantes para gerenciamento e monitoramento de integridade.

Endereços IP de gerenciamento do Azure Data Explorer

Endereços de monitoramento de integridade

Configuração do ExpressRoute

Use o ExpressRoute para conectar a rede local à rede virtual do Azure. Uma configuração comum é anunciar a rota padrão (0.0.0.0/0) por meio da sessão do BGP (Border Gateway Protocol). Isso força o tráfego proveniente da rede virtual a ser encaminhada para a rede local do cliente que pode descartar o tráfego, causando a interrupção dos fluxos de saída. Para superar esse padrão, a UDR (rota definida pelo usuário) (0.0.0.0/0) pode ser configurada e o próximo salto será Internet. Como o UDR tem precedência sobre o BGP, o tráfego será destinado à Internet.

Protegendo o tráfego de saída com um firewall

Se você quiser proteger o tráfego de saída usando o Firewall do Azure ou qualquer dispositivo virtual para limitar os nomes de domínio, os seguintes Nomes de Domínio Totalmente Qualificados (FQDN) devem ser permitidos no firewall.

prod.warmpath.msftcloudes.com:443
gcs.prod.monitoring.core.windows.net:443
production.diagnostics.monitoring.core.windows.net:443
graph.windows.net:443
graph.microsoft.com:443
*.login.microsoft.com :443
*.update.microsoft.com:443
login.live.com:443
wdcp.microsoft.com:443
login.microsoftonline.com:443
azureprofilerfrontdoor.cloudapp.net:443
*.core.windows.net:443
*.servicebus.windows.net:443,5671
shoebox2.metrics.nsatc.net:443
prod-dsts.dsts.core.windows.net:443
*.vault.azure.net
ocsp.msocsp.com:80
*.windowsupdate.com:80
ocsp.digicert.com:80
go.microsoft.com:80
dmd.metaservices.microsoft.com:80
www.msftconnecttest.com:80
crl.microsoft.com:80
www.microsoft.com:80
adl.windows.com:80
crl3.digicert.com:80

Configurar a tabela de rotas

Você precisa configurar a tabela de rotas da sub-rede do cluster com a Internet de próximo salto para evitar problemas de rotas assimétricas.

Configurar a tabela de rotas usando a delegação de sub-rede

É recomendável usar a delegação de sub-rede para configurar a tabela de rotas para a implantação do cluster, da mesma forma como ela foi feita para regras NSG. Ao habilitar a delegação de sub-rede na sub-rede do cluster, você permite que o serviço configure e atualize a tabela de rotas para você.

Configurar a tabela de rotas manualmente

Como alternativa, você pode configurar manualmente a tabela de rotas. Por padrão, implantar um cluster em uma rede virtual impõe a delegação de sub-rede para que "Microsoft.Kusto/clusters" seja configurado. Recusar esse requisito é possível usando o painel Versão prévia do recurso.

Para configurar manualmente a tabela de rotas, você deve defini-la na sub-rede. Você precisa adicionar os endereços de gerenciamento e monitoramento de integridade com a Internet de próximo salto.

Por exemplo, para a região Oeste dos EUA, o UDRs a seguir deve ser definido:

Como descobrir dependências automaticamente

O Azure Data Explorer fornece uma API que permite aos clientes descobrir todas as dependências de saída externas (FQDNs) programaticamente. Essas dependências de saída permitirão que os clientes configurem um firewall no final para permitir o tráfego de gerenciamento por meio dos FQDNs dependentes. Os clientes podem ter esses dispositivos de firewall no Azure ou localmente. O último pode causar latência adicional e pode afetar o desempenho do serviço. As equipes de serviço precisarão testar esse cenário para avaliar o impacto sobre o desempenho do serviço.

O ARMClient é usado para chamar a API REST usando o PowerShell.

1. Entrar com o ARMClient

   armclient login
   

2. Invocar operação de diagnóstico

   $subscriptionId = '<subscription id>'
   $clusterName = '<name of cluster>'
   $resourceGroupName = '<resource group name>'
   $apiversion = '2021-01-01'
   
   armclient get /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Kusto/clusters/$clusterName/OutboundNetworkDependenciesEndpoints?api-version=$apiversion
   

3. Verifique a resposta

   {
      "value":
      [
       ...
         {
           "id": "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.Kusto/Clusters/<clusterName>/OutboundNetworkDependenciesEndpoints/AzureActiveDirectory",
           "name": "<clusterName>/AzureActiveDirectory",
           "type": "Microsoft.Kusto/Clusters/OutboundNetworkDependenciesEndpoints",
           "etag": "\"\"",
           "location": "<AzureRegion>",
           "properties": {
             "category": "Azure Active Directory",
             "endpoints": [
               {
                 "domainName": "login.microsoftonline.com",
                 "endpointDetails": [
                   {
                     "port": 443
                   }
                 ]
               },
               {
                 "domainName": "graph.windows.net",
                 "endpointDetails": [
                   {
                     "port": 443
                   }
                 ]
               }
             ],
             "provisioningState": "Succeeded"
           }
         },
         {
           "id": "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.Kusto/Clusters/<clusterName>/OutboundNetworkDependenciesEndpoints/InternalTracing",
           "name": "<clustername>/InternalTracing",
           "type": "Microsoft.Kusto/Clusters/OutboundNetworkDependenciesEndpoints",
           "location": "Australia Central",
           "properties": {
             "category": "Internal Tracing",
             "endpoints": [
               {
                 "domainName": "ingest-<internalTracingCluster>.<region>.kusto.windows.net",
                 "endpointDetails": [
                   {
                     "port": 443,
                     "ipAddress": "25.24.23.22"
                   }
                 ]
               }
             ],
             "provisioningState": "Succeeded"
           }
       }
       ...
      ]
   }
   

As dependências de saída cobrem categorias como Microsoft Entra ID, Azure Monitor, Certificate Authority, Azure Storage e Internal Tracing. Em cada categoria, há uma lista de nomes de domínio e portas que são necessárias para executar o serviço. Eles podem ser usados para configurar programaticamente o dispositivo de firewall de sua escolha.

Implantar o cluster do Azure Data Explorer em sua rede virtual usando um modelo do Azure Resource Manager

Para implementar o cluster do Azure Data Explorer na sua rede virtual, utilize o Implementar o cluster do Azure Data Explorer na sua rede virtual Modelo do Azure Resource Manager.

Esse modelo cria o cluster, a rede virtual, a sub-rede, o grupo de segurança de rede e os endereços IP públicos.

Limitações conhecidas

• Os recursos de rede virtual com clusters implantados não são compatíveis com a operação de migração para uma nova assinatura ou grupo de recursos.
• Os recursos de endereço IP público usados para o mecanismo de cluster ou os serviços de gerenciamento de dados não são compatíveis com a operação de migração para um novo grupo de recursos ou assinatura.
• Não é possível usar o prefixo DNS "privado" de clusters do Azure Data Explorer injetados na rede virtual como parte da sua consulta