Partilhar via


Rede virtual gerida do Azure Data Factory

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Gorjeta

Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange tudo, desde a movimentação de dados até ciência de dados, análises em tempo real, business intelligence e relatórios. Saiba como iniciar uma nova avaliação gratuitamente!

Este artigo explica redes virtuais gerenciadas e pontos de extremidade privados gerenciados no Azure Data Factory.

Rede virtual gerenciada

Quando você cria um tempo de execução de integração do Azure em uma rede virtual gerenciada pelo Data Factory, o tempo de execução da integração é provisionado com a rede virtual gerenciada. Ele usa pontos de extremidade privados para se conectar com segurança a armazenamentos de dados suportados.

Criar um tempo de execução de integração dentro de uma rede virtual gerenciada garante que o processo de integração de dados seja isolado e seguro.

Benefícios de usar uma rede virtual gerenciada:

  • Com uma rede virtual gerenciada, você pode descarregar o fardo do gerenciamento da rede virtual para o Data Factory. Você não precisa criar uma sub-rede para um tempo de execução de integração que poderia eventualmente usar muitos IPs privados de sua rede virtual e exigiria planejamento prévio de infraestrutura de rede.
  • O conhecimento profundo de rede do Azure não é necessário para fazer integrações de dados com segurança. Em vez disso, começar a usar o ETL seguro é muito mais simples para os engenheiros de dados.
  • Uma rede virtual gerenciada, juntamente com pontos de extremidade privados gerenciados, protege contra a exfiltração de dados.

Atualmente, a rede virtual gerenciada só é suportada na mesma região que a região Data Factory.

Nota

Um tempo de execução de integração global existente não pode alternar para um tempo de execução de integração em uma rede virtual gerenciada pelo Data Factory e vice-versa.

Diagrama que mostra a arquitetura de rede virtual gerenciada pelo Data Factory.

Há duas maneiras de habilitar a rede virtual gerenciada em seu data factory:

  1. Habilite a rede virtual gerenciada durante a criação do data factory.

Captura de tela da habilitação da rede virtual gerenciada durante a criação do data factory.

  1. Habilite a rede virtual gerenciada no tempo de execução da integração.

Captura de tela mostrando a habilitação da rede virtual gerenciada no tempo de execução da integração

Pontos finais privados geridos

Os pontos finais privados geridos são pontos finais privados criados na rede virtual gerida do Data Factory, que estabelece uma ligação privada aos recursos do Azure. O Data Factory gere estes pontos finais privados em seu nome.

O Data Factory suporta links privados. Você pode usar o link privado do Azure para acessar os serviços da plataforma Azure como serviço (PaaS), como o Armazenamento do Azure, o Azure Cosmos DB e o Azure Synapse Analytics.

Quando você usa um link privado, o tráfego entre seus armazenamentos de dados e a rede virtual gerenciada atravessa inteiramente a rede de backbone da Microsoft. O link privado protege contra riscos de exfiltração de dados. Você estabelece um link privado para um recurso criando um ponto de extremidade privado.

Um ponto de extremidade privado usa um endereço IP privado na rede virtual gerenciada para efetivamente trazer o serviço para ela. Os pontos de extremidade privados são mapeados para um recurso específico no Azure e não para o serviço inteiro. Os clientes podem limitar a conectividade a um recurso específico aprovado pela organização. Para obter mais informações, consulte Links privados e pontos de extremidade privados.

Nota

O fornecedor de recursos Microsoft.Network tem de estar registado na sua subscrição.

  1. Certifique-se de ativar a rede virtual gerenciada em seu data factory.
  2. Crie um novo ponto de extremidade privado gerenciado em Gerenciar Hub.

Captura de tela que mostra novos pontos de extremidade privados gerenciados.

  1. Uma conexão de ponto de extremidade privado é criada em um estado Pendente quando você cria um ponto de extremidade privado gerenciado no Data Factory. Um fluxo de trabalho de aprovação é iniciado. O proprietário do recurso de link privado é responsável por aprovar ou rejeitar a conexão.

Captura de ecrã que mostra a opção Gerir aprovações no portal do Azure.

  1. Se o proprietário aprovar a conexão, o link privado é estabelecido. Caso contrário, o link privado não será estabelecido. Em ambos os casos, o ponto de extremidade privado gerenciado é atualizado com o status da conexão.

Captura de tela que mostra a aprovação de um ponto de extremidade privado gerenciado.

Somente um ponto de extremidade privado gerenciado em um estado aprovado pode enviar tráfego para um recurso de link privado específico.

Nota

O DNS personalizado não é suportado na rede virtual gerenciada.

Criação interativa

Os recursos de criação interativa são usados para funcionalidades como conexão de teste, procurar lista de pastas e lista de tabelas, obter esquema e visualizar dados. Você pode habilitar a criação interativa ao criar ou editar um tempo de execução de integração do Azure, que está na rede virtual gerenciada do Azure Data Factory. O serviço de back-end pré-alocará computação para funcionalidades de criação interativa. Caso contrário, a computação será alocada sempre que qualquer operação interativa for executada, o que levará mais tempo. O tempo de vida (TTL) para criação interativa é de 60 minutos por padrão, o que significa que ele será desativado automaticamente após 60 minutos da última operação de criação interativa. Você pode alterar o valor TTL de acordo com suas necessidades reais.

Captura de tela que mostra a criação interativa.

Time to live

Atividade Copiar

Por padrão, cada atividade de cópia gera uma nova computação com base na configuração na atividade de cópia. Com a rede virtual gerenciada habilitada, o tempo de inicialização de cálculos a frio leva alguns minutos e a movimentação de dados não pode ser iniciada até que esteja concluída. Se seus pipelines contiverem várias atividades de cópia sequencial ou se você tiver muitas atividades de cópia em loop foreach e não puder executá-las todas em paralelo, poderá habilitar um valor TTL (time to live) na configuração do tempo de execução de integração do Azure. A especificação de um valor de tempo de vida e dos números DIU necessários para a atividade de cópia mantém os cálculos correspondentes vivos por um determinado período de tempo após a conclusão de sua execução. Se uma nova atividade de cópia for iniciada durante o tempo TTL, ela reutilizará os cálculos existentes e o tempo de inicialização será muito reduzido. Após a conclusão da atividade de segunda cópia, os cálculos permanecerão ativos novamente pelo tempo TTL. Você tem a flexibilidade de selecionar entre os tamanhos de computação predefinidos, variando de pequeno a médio a grande. Como alternativa, você também tem a opção de personalizar o tamanho da computação com base em seus requisitos específicos e necessidades em tempo real.

Nota

A reconfiguração do número DIU não afetará a execução da atividade de cópia atual.

Nota

A medida de unidade de integração de dados (DIU) de 2 DIU não é suportada para a atividade de cópia em uma rede virtual gerenciada.

A DIU selecionada no TTL será usada para executar todas as atividades de cópia, o tamanho da DIU não será dimensionado automaticamente de acordo com as necessidades reais. Então você tem que escolher DIUs suficientes.

Aviso

Selecionar algumas DIUs para executar muitas atividades fará com que muitas atividades fiquem pendentes na fila, o que afetará seriamente o desempenho geral.

Pipeline e atividade externa

Semelhante à cópia, você tem a capacidade de personalizar o tamanho da computação e a duração do TTL de acordo com suas necessidades específicas. No entanto, ao contrário da cópia, observe que o pipeline e o TTL externo não podem ser desativados.

Nota

O tempo de vida (TTL) só é aplicável à rede virtual gerenciada.

Captura de tela que mostra a configuração TTL.

Você pode utilizar a tabela abaixo como referência para determinar o número ideal de nós para executar Pipelines e atividades externas.

Tipo de Atividade Capacidade
Atividade de pipeline Aproximadamente 50 por nó
A atividade de script e a atividade de pesquisa com SQL alwaysEncrypted tendem a consumir mais recursos em comparação com outras atividades de pipeline, com o número sugerido sendo de cerca de 10 por nó
Atividade externa Aproximadamente 800 por nó

Comparação de diferentes TTL

A tabela a seguir lista as diferenças entre os diferentes tipos de TTL:

Caraterística Criação interativa Copiar escala de computação Pipeline & Escala de computação externa
Quando entrar em vigor Imediatamente após a ativação Execução da primeira atividade Execução da primeira atividade
Pode ser desativado Y Y N
A computação reservada é configurável N Y Y

Nota

Não é possível habilitar o TTL no tempo de execução de integração do Azure de resolução automática padrão. Você pode criar um novo tempo de execução de integração do Azure para ele.

Nota

Quando o TTL da escala de computação Copy/Pipeline/External é ativado, o faturamento é determinado pelos recursos de computação reservados. Como resultado, a saída da atividade não inclui o billingReference, pois isso é exclusivamente relevante em cenários não TTL.

Criar uma rede virtual gerenciada por meio do Azure PowerShell

$subscriptionId = ""
$resourceGroupName = ""
$factoryName = ""
$managedPrivateEndpointName = ""
$integrationRuntimeName = ""
$apiVersion = "2018-06-01"
$privateLinkResourceId = ""

$vnetResourceId = "subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.DataFactory/factories/${factoryName}/managedVirtualNetworks/default"
$privateEndpointResourceId = "subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.DataFactory/factories/${factoryName}/managedVirtualNetworks/default/managedprivateendpoints/${managedPrivateEndpointName}"
$integrationRuntimeResourceId = "subscriptions/${subscriptionId}/resourceGroups/${resourceGroupName}/providers/Microsoft.DataFactory/factories/${factoryName}/integrationRuntimes/${integrationRuntimeName}"

# Create managed Virtual Network resource
New-AzResource -ApiVersion "${apiVersion}" -ResourceId "${vnetResourceId}" -Properties @{}

# Create managed private endpoint resource
New-AzResource -ApiVersion "${apiVersion}" -ResourceId "${privateEndpointResourceId}" -Properties @{
        privateLinkResourceId = "${privateLinkResourceId}"
        groupId = "blob"
    }

# Create integration runtime resource enabled with virtual network
New-AzResource -ApiVersion "${apiVersion}" -ResourceId "${integrationRuntimeResourceId}" -Properties @{
        type = "Managed"
        typeProperties = @{
            computeProperties = @{
                location = "AutoResolve"
                dataFlowProperties = @{
                    computeType = "General"
                    coreCount = 8
                    timeToLive = 0
                }
            }
        }
        managedVirtualNetwork = @{
            type = "ManagedVirtualNetworkReference"
            referenceName = "default"
        }
    }

Nota

Você pode obter o groupId de outras fontes de dados de um recurso de link privado.

Nota

O referenceName só deve ser definido como "padrão" se você criar por meio do Comando PowerShell.

Conexão de saída

Fontes de dados e serviços suportados

Os seguintes serviços têm suporte de ponto final privado nativo. Eles podem ser conectados através de link privado a partir de uma rede virtual gerenciada pelo Data Factory:

  • Azure Databricks
  • Funções do Azure (plano Premium)
  • Azure Key Vault
  • Azure Machine Learning
  • Azure Private Link
  • Microsoft Purview

Para o suporte de fontes de dados, você pode consultar a visão geral do conector. Você pode acessar todas as fontes de dados suportadas pelo Data Factory por meio de uma rede pública.

Origens de dados no local

Para saber como aceder a origens de dados no local a partir de uma rede virtual gerida através de um ponto final privado, veja Access on-premises SQL Server from a Data Factory managed virtual network using a private endpoint (Aceder a SQL Server no local a partir de uma rede virtual gerida do Data Factory através de um ponto final privado.

Comunicações de saída através de ponto de extremidade público de uma rede virtual gerenciada pelo Data Factory

Todas as portas são abertas para comunicações de saída.

Problemas conhecidos e de limitações

Criação de serviço vinculado para o Cofre da Chave

Quando você cria um serviço vinculado para o Cofre de Chaves, não há referência de tempo de execução de integração. Portanto, você não pode criar pontos de extremidade privados durante a criação do serviço vinculado do Cofre da Chave. Mas quando você cria um serviço vinculado para armazenamentos de dados que faz referência ao Cofre da Chave, e esse serviço vinculado faz referência a um tempo de execução de integração com a rede virtual gerenciada habilitada, você pode criar um ponto de extremidade privado para o Cofre da Chave durante a criação.

  • Testar conexão: esta operação para um serviço vinculado do Cofre da Chave apenas valida o formato de URL, mas não faz nenhuma operação de rede.
  • Usando ponto de extremidade privado: esta coluna é sempre mostrada como em branco, mesmo se você criar um ponto de extremidade privado para o Cofre de Chaves.

Criação de serviço vinculado do Azure HDInsight

A coluna Usando ponto de extremidade privado é sempre mostrada como em branco, mesmo se você criar um ponto de extremidade privado para o HDInsight usando um serviço de link privado e um balanceador de carga com encaminhamento de porta.

Captura de ecrã que mostra um ponto de extremidade privado para o Cofre da Chave.

FQDN (nome de domínio totalmente qualificado) do Azure HDInsight

Se você criou um serviço de link privado personalizado, o FQDN deve terminar com azurehdinsight.net sem link privado à esquerda no nome de domínio quando você cria um ponto de extremidade privado. Se você usar privatelink no nome de domínio, certifique-se de que é válido e você é capaz de resolvê-lo.

Restrições de acesso na rede virtual gerenciada com pontos de extremidade privados

Você não consegue acessar cada recurso PaaS quando ambos os lados são expostos ao Private Link e a um ponto de extremidade privado. Esse problema é uma limitação conhecida do Private Link e dos pontos de extremidade privados.

Por exemplo, você tem um ponto de extremidade privado gerenciado para a conta de armazenamento A. Você também pode acessar a conta de armazenamento B através da rede pública na mesma rede virtual gerenciada. Mas quando a conta de armazenamento B tem uma conexão de ponto de extremidade privada de outra rede virtual gerenciada ou rede virtual do cliente, você não pode acessar a conta de armazenamento B em sua rede virtual gerenciada por meio da rede pública.

Veja os tutoriais seguintes: