Condividi tramite

rete virtuale gestita di Azure Data Factory

  • Articolo

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Suggerimento

Provare Data Factory in Microsoft Fabric, una soluzione di analisi all-in-one per le aziende. Microsoft Fabric copre tutto, dallo spostamento dati al data science, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Vedere le informazioni su come iniziare una nuova prova gratuita!

Questo articolo illustra le reti virtuali gestite e gli endpoint privati gestiti in Azure Data Factory.

Rete virtuale gestita

Quando si crea un runtime di integrazione di Azure all'interno di una rete virtuale gestita di Data Factory, viene effettuato il provisioning del runtime di integrazione con la rete virtuale gestita. Usa endpoint privati per connettersi in modo sicuro agli archivi dati supportati.

La creazione di un runtime di integrazione all'interno di una rete virtuale gestita garantisce che il processo di integrazione dei dati sia isolato e sicuro.

Vantaggi dell'uso di una rete virtuale gestita:

  • Con una rete virtuale gestita, è possibile scaricare l'onere della gestione della rete virtuale in Data Factory. Non è necessario creare una subnet per un runtime di integrazione che potrebbe eventualmente usare molti INDIRIZZI IP privati dalla rete virtuale e richiedere una pianificazione precedente dell'infrastruttura di rete.
  • Le conoscenze approfondite sulla rete di Azure non sono necessarie per eseguire le integrazioni dei dati in modo sicuro. In alternativa, iniziare a usare ETL sicuro è molto più semplice per i data engineer.
  • Una rete virtuale gestita insieme agli endpoint privati gestiti protegge dall'esfiltrazione di dati.

Attualmente, la rete virtuale gestita è supportata solo nella stessa area dell'area di Data Factory.

Nota

Un runtime di integrazione globale esistente non può passare a un runtime di integrazione in una rete virtuale gestita di Data Factory e viceversa.

Diagramma che mostra l'architettura di rete virtuale gestita di Data Factory.

Esistono due modi per abilitare la rete virtuale gestita nella data factory:

  1. Abilitare la rete virtuale gestita durante la creazione della data factory.

Screenshot dell'abilitazione della rete virtuale gestita durante la creazione della data factory.

  1. Abilitare la rete virtuale gestita nel runtime di integrazione.

Screenshot dell'abilitazione della rete virtuale gestita nel runtime di integrazione

Endpoint privati gestiti

Gli endpoint privati gestiti sono endpoint privati creati nella rete virtuale gestita di Data Factory che stabiliscono un collegamento privato alle risorse di Azure. Data Factory gestisce questi endpoint privati per conto dell'utente.

Data Factory supporta collegamenti privati. È possibile usare il collegamento privato di Azure per accedere ai servizi PaaS (Platform as a Service) di Azure come Archiviazione di Azure, Azure Cosmos DB e Azure Synapse Analytics.

Quando si usa un collegamento privato, il traffico tra gli archivi dati e la rete virtuale gestita attraversa interamente la rete backbone Microsoft. Il collegamento privato protegge dai rischi di esfiltrazione dei dati. Per stabilire un collegamento privato a una risorsa, è necessario creare un endpoint privato.

Un endpoint privato usa un indirizzo IP privato nella rete virtuale gestita per inserirlo in modo efficace nel servizio. Gli endpoint privati sono associati a una risorsa specifica in Azure e non all'intero servizio. I clienti possono limitare la connettività a una risorsa specifica approvata dall'organizzazione. Per altre informazioni, vedere Collegamenti privati ed endpoint privati.

Nota

Il provider di risorse Microsoft.Network deve essere registrato nella sottoscrizione.

  1. Assicurarsi di abilitare la rete virtuale gestita nella data factory.
  2. Creare un nuovo endpoint privato gestito in Gestire l'hub.

Screenshot che mostra i nuovi endpoint privati gestiti.

  1. Una connessione endpoint privato viene creata in uno stato In sospeso quando si crea un endpoint privato gestito in Data Factory. Viene avviato un flusso di lavoro di approvazione. Il proprietario della risorsa collegamento privato è responsabile dell'approvazione o del rifiuto della connessione.

Screenshot che mostra l'opzione Gestisci approvazioni in portale di Azure.

  1. Se il proprietario approva la connessione, il collegamento privato viene stabilito. In caso contrario, il collegamento privato non verrà stabilito. In entrambi i casi, l'endpoint privato gestito viene aggiornato con lo stato della connessione.

Screenshot che mostra l'approvazione di un endpoint privato gestito.

Solo un endpoint privato gestito in uno stato approvato può inviare traffico a una risorsa di collegamento privato specifica.

Nota

IL DNS personalizzato non è supportato nella rete virtuale gestita.

Creazione interattiva

Le funzionalità di creazione interattiva vengono usate per funzionalità come la connessione di test, l'elenco di cartelle e l'elenco di tabelle, ottenere lo schema e i dati di anteprima. È possibile abilitare la creazione interattiva durante la creazione o la modifica di un runtime di integrazione di Azure, che si trova nella rete virtuale gestita di Azure Data Factory. Il servizio back-end prea allocherà il calcolo per le funzionalità di creazione interattiva. In caso contrario, il calcolo verrà allocato ogni volta che viene eseguita un'operazione interattiva che richiederà più tempo. Il tempo di durata (TTL) per la creazione interattiva è di 60 minuti per impostazione predefinita, il che significa che diventerà automaticamente disabilitato dopo 60 minuti dell'ultima operazione di creazione interattiva. È possibile modificare il valore TTL in base alle esigenze effettive.

Screenshot che mostra la creazione interattiva.

Durata (TTL)

Attività di copia

Per impostazione predefinita, ogni attività di copia attiva un nuovo calcolo in base alla configurazione nell'attività di copia. Con la rete virtuale gestita abilitata, il tempo di avvio dei calcoli ad accesso sporadico richiede alcuni minuti e lo spostamento dei dati non può essere avviato fino al completamento. Se le pipeline contengono più attività di copia sequenziale o si hanno molte attività di copia nel ciclo foreach e non possono essere eseguite tutte in parallelo, è possibile abilitare un valore TTL (Time To Live) nella configurazione del runtime di integrazione di Azure. Se si specifica un valore di durata e i numeri DIU necessari per l'attività di copia, i calcoli corrispondenti vengono memorizzati per un determinato periodo di tempo dopo il completamento dell'esecuzione. Se una nuova attività di copia viene avviata durante l'ora TTL, riutilizzerà i calcoli esistenti e il tempo di avvio verrà notevolmente ridotto. Al termine della seconda attività di copia, i calcoli rimarranno nuovamente attivi per il tempo TTL. È possibile scegliere tra le dimensioni di calcolo predefinite, da piccole a medie e grandi dimensioni. In alternativa, è anche possibile personalizzare le dimensioni di calcolo in base ai requisiti specifici e alle esigenze in tempo reale.

Nota

La riconfigurazione del numero DIU non influirà sull'esecuzione dell'attività di copia corrente.

Nota

La misura dell'unità di integrazione dati (DIU) di 2 unità di distribuzione non è supportata per il attività Copy in una rete virtuale gestita.

L'unità DIU selezionata in TTL verrà usata per eseguire tutte le attività di copia, le dimensioni dell'unità di distribuzione non verranno ridimensionate automaticamente in base alle esigenze effettive. Quindi è necessario scegliere sufficienti DIU.

Avviso

Se si selezionano poche DIU per eseguire molte attività, molte attività saranno in sospeso nella coda, che influiranno gravemente sulle prestazioni complessive.

Pipeline ed attività esterna

Analogamente alla copia, è possibile personalizzare le dimensioni di calcolo e la durata TTL in base ai requisiti specifici. Tuttavia, a differenza della copia, si noti che la pipeline e il TTL esterno non possono essere disabilitati.

Nota

La durata (TTL) è applicabile solo alla rete virtuale gestita.

Screenshot che mostra la configurazione TTL.

È possibile usare la tabella seguente come riferimento per determinare il numero ottimale di nodi per l'esecuzione di pipeline e attività esterne.

Tipo di attività Capacità
Attività della pipeline Circa 50 per nodo
L'attività script e l'attività di ricerca con SQL alwaysEncrypted tendono a usare più risorse rispetto ad altre attività della pipeline, con il numero suggerito di circa 10 per nodo
Attività esterna Circa 800 per nodo

Confronto tra TTL diversi

Nella tabella seguente sono elencate le differenze tra tipi diversi di TTL:

Funzionalità Creazione interattiva Copiare la scalabilità di calcolo Scalabilità di calcolo esterna e pipeline
Quando rendere effettivo Subito dopo l'abilitazione Prima esecuzione dell'attività Prima esecuzione dell'attività
Può essere disabilitato S Y N
Il calcolo riservato è configurabile N S S

Nota

Non è possibile abilitare la durata (TTL) nel runtime di integrazione automatica predefinito di Azure. È possibile creare un nuovo runtime di integrazione di Azure.

Nota

Quando viene attivata la durata TTL copia/pipeline/scala di calcolo esterna, la fatturazione viene determinata dalle risorse di calcolo riservate. Di conseguenza, l'output dell'attività non include billingReference, perché questo è rilevante esclusivamente negli scenari non TTL.

Creare una rete virtuale gestita tramite 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

È possibile ottenere il groupId di altre origini dati da una risorsa di collegamento privato.

Nota

ReferenceName deve essere impostato come "predefinito" solo se si crea tramite il comando di PowerShell.

Connessione in uscita

Origini dati e servizi supportati

I seguenti servizi supportano endpoint privati nativi. Possono essere connessi tramite collegamento privato da una rete virtuale gestita di Data Factory:

  • Azure Databricks
  • Funzioni di Azure (piano Premium)
  • Azure Key Vault
  • Azure Machine Learning
  • Collegamento privato di Azure
  • Microsoft Purview

Per il supporto delle origini dati, è possibile fare riferimento alla panoramica del connettore. È possibile accedere a tutte le origini dati supportate da Data Factory tramite una rete pubblica.

Origini dati locali

Per informazioni su come accedere alle origini dati locali da una rete virtuale gestita usando un endpoint privato, consultare la sezione Accedere a SQL Server locale da una rete virtuale gestita di Data Factory usando un endpoint privato.

Comunicazioni in uscita tramite endpoint pubblico da una rete virtuale gestita di Data Factory

Tutte le porte vengono aperte per le comunicazioni in uscita.

Limitazioni e problemi noti

Creazione del servizio collegato per Key Vault

Quando si crea un servizio collegato per Key Vault, non è disponibile alcun riferimento al runtime di integrazione. Non è quindi possibile creare endpoint privati durante la creazione del servizio collegato di Key Vault. Tuttavia, quando si crea un servizio collegato per archivi dati che fanno riferimento a Key Vault e questo servizio collegato fa riferimento a un runtime di integrazione con rete virtuale gestita abilitata, è possibile creare un endpoint privato per Key Vault durante la creazione.

  • Test connessione: questa operazione per un servizio collegato di Key Vault convalida solo il formato url, ma non esegue alcuna operazione di rete.
  • Uso dell'endpoint privato: questa colonna viene sempre visualizzata come vuota anche se si crea un endpoint privato per Key Vault.

Creazione del servizio collegato di Azure HDInsight

La colonna Uso dell'endpoint privato viene sempre visualizzata come vuota anche se si crea un endpoint privato per HDInsight usando un servizio di collegamento privato e un servizio di bilanciamento del carico con port forwarding.

Screenshot che mostra un endpoint privato per Key Vault.

Nome di dominio completo (FQDN) di Azure HDInsight

Se è stato creato un servizio di collegamento privato personalizzato, il nome di dominio completo deve terminare con azurehdinsight.net senza portare privatelink nel nome di dominio quando si crea un endpoint privato. Se si usa privatelink nel nome di dominio, assicurarsi che sia valido e che sia possibile risolverlo.

Vincoli di accesso nella rete virtuale gestita con endpoint privati

Non è possibile accedere a ogni risorsa PaaS quando entrambi i lati sono esposti a collegamento privato e a un endpoint privato. Questo problema è una limitazione nota dei collegamento privato e degli endpoint privati.

Ad esempio, si dispone di un endpoint privato gestito per l'account di archiviazione A. È anche possibile accedere all'account di archiviazione B tramite la rete pubblica nella stessa rete virtuale gestita. Tuttavia, quando l'account di archiviazione B ha una connessione endpoint privato da un'altra rete virtuale gestita o da una rete virtuale del cliente, non è possibile accedere all'account di archiviazione B nella rete virtuale gestita tramite la rete pubblica.

Contenuto correlato

Vedere le esercitazioni seguenti: