Distribuire Azure Databricks nella rete virtuale di Azure (VNet injection)
La distribuzione predefinita di Azure Databricks è un servizio completamente gestito in Azure: tutte le risorse del piano dati, inclusa una rete virtuale a cui verranno associati tutti i cluster, vengono distribuiti in un gruppo di risorse bloccato. Se è necessaria la personalizzazione della rete, tuttavia, è possibile distribuire le risorse del piano dati di Azure Databricks nella propria rete virtuale (talvolta denominata inserimento reti virtuali), consentendo di:
- Connettere Azure Databricks ad altri servizi di Azure (ad esempio Archiviazione di Azure) in modo più sicuro usando endpoint di servizio o endpoint privati.
- Connettersi alle origini dati locali per l'uso con Azure Databricks, sfruttando le route definite dall'utente.
- Connettere Azure Databricks a un'appliance virtuale di rete per esaminare tutto il traffico in uscita ed eseguire azioni in base alle regole di autorizzazione e negazione, usando route definite dall'utente.
- Configurare Azure Databricks per l'uso di DNS personalizzato.
- Configurare le regole del gruppo di sicurezza di rete (NSG) per specificare le restrizioni del traffico in uscita.
- Distribuire cluster Di Azure Databricks nella rete virtuale esistente.
La distribuzione delle risorse del piano dati di Azure Databricks nella propria rete virtuale consente anche di sfruttare intervalli CIDR flessibili (ovunque si /16-/24 trovino per la rete virtuale e fino a /26 per le subnet).
Importante
Non è possibile sostituire la rete virtuale per un'area di lavoro esistente. Se l'area di lavoro corrente non può contenere il numero necessario di nodi del cluster attivo, è consigliabile creare un'altra area di lavoro in una rete virtuale più grande. Seguire questi passaggi di migrazione dettagliati per copiare le risorse (notebook, configurazioni del cluster, processi) dall'area di lavoro precedente a quella nuova.
Importante
Questo articolo descrive il termine piano dati, ovvero il livello di calcolo della piattaforma Azure Databricks. Nel contesto di questo articolo, il piano dati fa riferimento al piano dati classico nella sottoscrizione di Azure. Al contrario, il piano dati serverless che supporta sql warehouse serverless viene eseguito nella sottoscrizione di Azure di Azure Databricks. Per altre informazioni, vedere Calcolo serverless.
Requisiti della rete virtuale
La rete virtuale che si distribuisce l'area di lavoro di Azure Databricks per soddisfare i requisiti seguenti:
Regione: La rete virtuale deve trovarsi nella stessa area dell'area di lavoro di Azure Databricks.
Sottoscrizione: La rete virtuale deve trovarsi nella stessa sottoscrizione dell'area di lavoro di Azure Databricks.
Spazio indirizzi: Un blocco CIDR tra
/16e/24per la rete virtuale e un blocco CIDR fino a/26per le due subnet: una subnet del contenitore e una subnet host. Per indicazioni sul numero massimo di nodi del cluster in base alle dimensioni della rete virtuale e alle relative subnet, vedere Spazio indirizzi e numero massimo di nodi del cluster.Subnet: La rete virtuale deve includere due subnet dedicate all'area di lavoro di Azure Databricks: una subnet del contenitore (talvolta denominata subnet privata) e una subnet host (talvolta denominata subnet pubblica). Tuttavia, per un'area di lavoro che usa la connettività sicura del cluster, sia la subnet del contenitore che la subnet host sono private. Non è supportato condividere subnet tra aree di lavoro o distribuire altre risorse di Azure nelle subnet usate dall'area di lavoro di Azure Databricks. Per indicazioni sul numero massimo di nodi del cluster in base alle dimensioni della rete virtuale e alle relative subnet, vedere Spazio indirizzi e numero massimo di nodi del cluster.
- Se si crea un'area di lavoro di Azure Databricks usando portale di Azure, scegliere di usare le subnet esistenti nella rete virtuale o creare due nuove subnet specificate in base ai nomi e agli intervalli IP.
- Se si usa il modello ARM all-in-one o il modello arm di sola rete virtuale, i modelli creano automaticamente le subnet. In entrambi i casi, le subnet vengono delegate al provider di risorse prima della
Microsoft.Databricks/workspacesdistribuzione dell'area di lavoro, che consente ad Azure Databricks di creare regole del gruppo di sicurezza di rete. Azure Databricks fornirà una notifica anticipata se è necessario aggiungere o aggiornare l'ambito di una regola del gruppo di sicurezza di rete gestita da Azure Databricks. - Se si usa il modello di Resource Manager dell'area di lavoro o un modello di Resource Manager personalizzato, è necessario assicurarsi che le due subnet per l'area di lavoro usino lo stesso gruppo di sicurezza di rete e siano delegate correttamente. Vedere Aggiungere o rimuovere una delega subnet.
Importante
Esiste una relazione uno-a-uno tra queste subnet e un'area di lavoro di Azure Databricks. Non è possibile condividere più aree di lavoro in una singola subnet. Non è supportata la condivisione di subnet tra aree di lavoro o la distribuzione di altre risorse di Azure nelle subnet usate dall'area di lavoro di Azure Databricks.
Per altre informazioni sui modelli per configurare la rete virtuale e distribuire l'area di lavoro, vedere Modelli di Azure-Databricks forniti da Azure Resource Manager.
Spazio indirizzi e numero massimo di nodi del cluster
Un'area di lavoro con una rete virtuale più piccola può esaurire gli indirizzi IP (spazio di rete) più rapidamente rispetto a un'area di lavoro con una rete virtuale più grande. Usare un blocco CIDR tra /16 e /24 per la rete virtuale e un blocco CIDR fino a /26 per le due subnet (la subnet del contenitore e la subnet host).
L'intervallo CIDR per lo spazio indirizzi della rete virtuale influisce sul numero massimo di nodi del cluster che l'area di lavoro può usare:
- Un'area di lavoro di Azure Databricks richiede due subnet nella rete virtuale: una subnet del contenitore (nota anche come subnet privata) e una subnet host (nota anche come subnet pubblica). Se l'area di lavoro usa la connettività sicura del cluster, le subnet del contenitore e dell'host sono private.
- Azure riserva cinque indirizzi IP in ogni subnet.
- All'interno di ogni subnet, Azure Databricks richiede un indirizzo IP per ogni nodo del cluster. In totale, sono presenti due indirizzi IP per ogni nodo del cluster: un indirizzo IP per l'host nella subnet host e un indirizzo IP per il contenitore nella subnet del contenitore.
- È possibile che non si voglia usare tutto lo spazio indirizzi della rete virtuale. Ad esempio, è possibile creare più aree di lavoro in una rete virtuale. Poiché non è possibile condividere subnet tra aree di lavoro, è possibile che le subnet che non usino lo spazio indirizzi della rete virtuale totale.
- È necessario allocare spazio indirizzi per due nuove subnet all'interno dello spazio indirizzi della rete virtuale e non sovrapporre lo spazio indirizzi delle subnet correnti o future in tale rete virtuale.
La tabella seguente illustra le dimensioni massime della subnet in base alle dimensioni della rete. Questa tabella presuppone che non esistano subnet aggiuntive che occupano spazio indirizzi. Usare subnet più piccole se sono presenti subnet preesistenti o se si vuole riservare spazio indirizzi per altre subnet:
| Spazio indirizzi della rete virtuale (CIDR) | Dimensioni massime della subnet di Azure Databricks (CIDR) presupponendo che non siano presenti altre subnet |
|---|---|
/16 |
/17 |
/17 |
/18 |
/18 |
/19 |
/20 |
/21 |
/21 |
/22 |
/22 |
/23 |
/23 |
/24 |
/24 |
/25 |
Per trovare il numero massimo di nodi del cluster in base alle dimensioni della subnet, usare la tabella seguente. Gli indirizzi IP per ogni colonna subnet includono i cinque indirizzi IP riservati di Azure. La colonna più a destra indica il numero di nodi del cluster che possono essere eseguiti simultaneamente in un'area di lavoro di cui viene effettuato il provisioning con subnet di tale dimensione.
| Dimensioni subnet (CIDR) | Indirizzi IP per subnet | Numero massimo di nodi del cluster Di Azure Databricks |
|---|---|---|
/17 |
32768 | 32763 |
/18 |
16384 | 16379 |
/19 |
8192 | 8187 |
/20 |
4096 | 4091 |
/21 |
2048 | 2043 |
/22 |
1024 | 1019 |
/23 |
512 | 507 |
/24 |
256 | 251 |
/25 |
128 | 123 |
/26 |
64 | 59 |
Creare un'area di lavoro di Azure Databricks usando portale di Azure
Questa sezione descrive come creare un'area di lavoro di Azure Databricks nel portale di Azure e distribuirla nella propria rete virtuale esistente. Azure Databricks aggiorna la rete virtuale con due nuove subnet, se non esistono ancora, usando intervalli CIDR specificati. Il servizio aggiorna anche le subnet con un nuovo gruppo di sicurezza di rete, la configurazione delle regole in ingresso e in uscita e infine distribuisce l'area di lavoro nella rete virtuale aggiornata. Per un maggiore controllo sulla configurazione della rete virtuale, usare i modelli di Azure-Databricks forniti da Azure Resource Manager (ARM) anziché l'interfaccia utente del portale. Ad esempio, usare i gruppi di sicurezza di rete esistenti o creare regole di sicurezza personalizzate. Vedere Configurazione avanzata con i modelli di Resource Manager di Azure.
Importante
All'utente che crea l'area di lavoro deve essere assegnato il ruolo Collaboratore rete al Rete virtuale corrispondente o a un ruolo personalizzato a cui è assegnata l'azioneMicrosoft.Network/virtualNetworks/subnets/join/action.
È necessario configurare una rete virtuale in cui si distribuirà l'area di lavoro di Azure Databricks. È possibile usare una rete virtuale esistente o crearne una nuova, ma la rete virtuale deve trovarsi nella stessa area e nella stessa sottoscrizione dell'area di lavoro di Azure Databricks che si intende creare. La rete virtuale deve essere ridimensionata con un intervallo CIDR compreso tra /16 e /24. Per altri requisiti, vedere Requisiti di rete virtuale.
Usare subnet esistenti o specificare nomi e intervalli IP per le nuove subnet quando si configura l'area di lavoro.
Nella portale di Azure selezionare + Crea una risorsa > Analisi > di Azure Databricks o cercare Azure Databricks e fare clic su Crea o + Aggiungi per avviare la finestra di dialogo Servizio Azure Databricks.
Seguire i passaggi di configurazione descritti nella guida introduttiva Creare un'area di lavoro di Azure Databricks nella propria rete virtuale.
Nella scheda Rete selezionare la rete virtuale da usare nel campo Rete virtuale .
Importante
Se non viene visualizzato il nome di rete nella selezione, verificare che l'area di Azure specificata per l'area di lavoro corrisponda all'area di Azure della rete virtuale desiderata.
Assegnare un nome alle subnet e fornire intervalli CIDR in un blocco fino alle dimensioni
/26. Per indicazioni sui nodi del cluster massimo in base alle dimensioni della rete virtuale e alle relative subnet, vedere Spazio indirizzi e nodi del cluster massimo.- Per specificare le subnet esistenti, specificare i nomi esatti delle subnet esistenti. Quando si usano subnet esistenti, impostare anche gli intervalli IP nel modulo di creazione dell'area di lavoro per corrispondere esattamente agli intervalli IP delle subnet esistenti.
- Per creare nuove subnet, specificare i nomi di subnet che non esistono già nella rete virtuale. Le subnet vengono create con gli intervalli IP specificati. È necessario specificare intervalli IP all'interno dell'intervallo IP della rete virtuale e non già allocati alle subnet esistenti.
Importante
Azure Databricks richiede che i nomi delle subnet non siano più di 30 caratteri. Questa lunghezza è più breve della lunghezza massima consentita per le subnet nella portale di Azure. Prima di usare una subnet esistente, rinominarla se il nome è più lungo di 30 caratteri.
Le subnet ottengono regole del gruppo di sicurezza di rete associate che includono la regola per consentire la comunicazione interna del cluster. Azure Databricks avrà autorizzazioni delegate per aggiornare entrambe le subnet tramite il
Microsoft.Databricks/workspacesprovider di risorse. Queste autorizzazioni si applicano solo alle regole del gruppo di sicurezza di rete richieste da Azure Databricks, non ad altre regole del gruppo di sicurezza di rete aggiunte o alle regole predefinite del gruppo di sicurezza di rete incluse in tutti i gruppi di sicurezza di rete.Fare clic su Crea per distribuire l'area di lavoro di Azure Databricks nella rete virtuale.
Nota
Quando una distribuzione dell'area di lavoro ha esito negativo, l'area di lavoro viene ancora creata ma ha uno stato non riuscito. Eliminare l'area di lavoro non riuscita e creare una nuova area di lavoro che risolve gli errori di distribuzione. Quando si elimina l'area di lavoro non riuscita, viene eliminato anche il gruppo di risorse gestito e tutte le risorse distribuite correttamente.
Configurazione avanzata con modelli di Resource Manager di Azure
Per un maggiore controllo sulla configurazione della rete virtuale, usare i modelli di Azure Resource Manager (ARM) seguenti anziché la configurazione automatica e la distribuzione automatica della rete virtuale basata sull'interfaccia utente del portale. Ad esempio, usare subnet esistenti, un gruppo di sicurezza di rete esistente o aggiungere regole di sicurezza personalizzate.
Se si usa un modello di Azure Resource Manager personalizzato o il modello di area di lavoro per Azure Databricks VNet Injection per distribuire un'area di lavoro in una rete virtuale esistente, è necessario creare subnet host e contenitori, collegare un gruppo di sicurezza di rete a ogni subnet e delegare le subnet al Microsoft.Databricks/workspaces provider di risorse prima di distribuire l'area di lavoro. È necessario disporre di una coppia separata di subnet per ogni area di lavoro distribuita.
Modello all-in-one
Per creare una rete virtuale e un'area di lavoro di Azure Databricks usando un modello, usare il modello All-in-one per le aree di lavoro inserite in Azure Databricks.
Modello di rete virtuale
Per creare una rete virtuale con le subnet appropriate usando un modello, usare il modello di rete virtuale per Databricks VNet Injection.
Modello di area di lavoro di Azure Databricks
Per distribuire un'area di lavoro di Azure Databricks in una rete virtuale esistente con un modello, usare il modello di area di lavoro per Azure Databricks VNet Injection.
Il modello di area di lavoro consente di specificare una rete virtuale esistente e di usare subnet esistenti:
- È necessario disporre di una coppia separata di subnet host/contenitore per ogni area di lavoro distribuita. Non è supportato per condividere subnet tra aree di lavoro o per distribuire altre risorse di Azure nelle subnet usate dall'area di lavoro di Azure Databricks.
- Gli host e le subnet del contenitore della rete virtuale devono avere gruppi di sicurezza di rete collegati e devono essere delegati al servizio prima di usare questo modello di Azure Resource Manager per distribuire un'area
Microsoft.Databricks/workspacesdi lavoro. - Per creare una rete virtuale con subnet delegate correttamente, usare il modello di rete virtuale per Databricks VNet Injection.
- Per usare una rete virtuale esistente quando non è ancora stato delegato le subnet host e contenitori, vedere Aggiungere o rimuovere una delega di subnet.
Regole del gruppo di sicurezza di rete
Le tabelle seguenti visualizzano le regole correnti del gruppo di sicurezza di rete usate da Azure Databricks. Se Azure Databricks deve aggiungere una regola o modificare l'ambito di una regola esistente in questo elenco, si riceverà un avviso anticipato. Questo articolo e le tabelle verranno aggiornate ogni volta che si verifica tale modifica.
In questa sezione:
- Come Azure Databricks gestisce le regole del gruppo di sicurezza di rete
- Regole del gruppo di sicurezza di rete per le aree di lavoro create dopo il 13 gennaio 2020
- Regole del gruppo di sicurezza di rete per le aree di lavoro create prima del 13 gennaio 2020
Come Azure Databricks gestisce le regole del gruppo di sicurezza di rete
Le regole del gruppo di sicurezza di rete elencate nelle sezioni seguenti rappresentano quelle che Azure Databricks esegue il provisioning automatico e gestisce nel gruppo di sicurezza di rete, a causa della delega delle subnet host e contenitori della rete virtuale al Microsoft.Databricks/workspaces servizio. Non si dispone dell'autorizzazione per aggiornare o eliminare queste regole del gruppo di sicurezza di rete; qualsiasi tentativo di eseguire questa operazione viene bloccato dalla delega della subnet. Azure Databricks deve possedere queste regole per garantire che Microsoft possa operare in modo affidabile e supportare il servizio Azure Databricks nella rete virtuale.
Alcune di queste regole del gruppo di sicurezza di rete hanno VirtualNetwork assegnato come origine e destinazione. Questa operazione è stata implementata per semplificare la progettazione in assenza di un tag di servizio a livello di subnet in Azure. Tutti i cluster sono protetti da un secondo livello di criteri di rete internamente, in modo che il cluster A non possa connettersi al cluster B nella stessa area di lavoro. Ciò si applica anche in più aree di lavoro se le aree di lavoro vengono distribuite in una coppia di subnet diverse nella stessa rete virtuale gestita dal cliente.
Importante
Se la rete virtuale dell'area di lavoro viene eseguito il peering in un'altra rete gestita dal cliente o se le risorse non di Azure Databricks vengono sottoposte a provisioning in altre subnet, Databricks consiglia di aggiungere regole nega in ingresso ai gruppi di sicurezza di rete collegati alle altre reti e subnet per bloccare il traffico di origine dai cluster di Azure Databricks. Non è necessario aggiungere tali regole per le risorse a cui si desidera connettere i cluster di Azure Databricks.
Regole del gruppo di sicurezza di rete per le aree di lavoro create dopo il 13 gennaio 2020
Le informazioni contenute in questa sezione si applicano solo alle aree di lavoro di Azure Databricks create dopo il 13 gennaio 2020. Se l'area di lavoro è stata creata prima della versione di connettività del cluster sicura (SCC) il 13 gennaio 2020, vedere la sezione successiva.
Importante
Questa tabella elenca due regole del gruppo di sicurezza in ingresso incluse solo se la connettività del cluster sicura (SCC) è disabilitata.
| Direzione | Protocollo | Fonte | Porta di origine | Destinazione | Porta dest | Utilizzato |
|---|---|---|---|---|---|---|
| Inbound | Qualsiasi | VirtualNetwork | Qualsiasi | VirtualNetwork | Qualsiasi | Predefinito |
| Inbound | TCP | AzureDatabricks (tag del servizio) Solo se SCC è disabilitato |
Qualsiasi | VirtualNetwork | 22 | IP pubblico |
| Inbound | TCP | AzureDatabricks (tag del servizio) Solo se SCC è disabilitato |
Qualsiasi | VirtualNetwork | 5557 | IP pubblico |
| Outbound | TCP | VirtualNetwork | Qualsiasi | AzureDatabricks (tag del servizio) | 443 | Predefinito |
| Outbound | TCP | VirtualNetwork | Qualsiasi | SQL | 3306 | Predefinito |
| Outbound | TCP | VirtualNetwork | Qualsiasi | Archiviazione | 443 | Predefinito |
| Outbound | Qualsiasi | VirtualNetwork | Qualsiasi | VirtualNetwork | Qualsiasi | Predefinito |
| Outbound | TCP | VirtualNetwork | Qualsiasi | EventHub | 9093 | Predefinito |
| Outbound | Qualsiasi | VirtualNetwork | Qualsiasi | NFS | 111 | Predefinito |
| Outbound | Qualsiasi | VirtualNetwork | Qualsiasi | NFS | 2049 | Predefinito |
Regole del gruppo di sicurezza di rete per le aree di lavoro create prima del 13 gennaio 2020
Le informazioni contenute in questa sezione si applicano solo alle aree di lavoro di Azure Databricks create prima del 13 gennaio 2020. Se l'area di lavoro è stata creata o dopo il 13 gennaio 2020, vedere la sezione precedente.
| Direzione | Protocollo | Fonte | Porta di origine | Destinazione | Porta dest | Utilizzato |
|---|---|---|---|---|---|---|
| Inbound | Qualsiasi | VirtualNetwork | Qualsiasi | VirtualNetwork | Qualsiasi | Predefinito |
| Inbound | TCP | ControlPlane IP | Qualsiasi | VirtualNetwork | 22 | IP pubblico |
| Inbound | TCP | ControlPlane IP | Qualsiasi | VirtualNetwork | 5557 | IP pubblico |
| Outbound | TCP | VirtualNetwork | Qualsiasi | IP dell'app Web | 443 | Predefinito |
| Outbound | TCP | VirtualNetwork | Qualsiasi | SQL | 3306 | Predefinito |
| Outbound | TCP | VirtualNetwork | Qualsiasi | Archiviazione | 443 | Predefinito |
| Outbound | Qualsiasi | VirtualNetwork | Qualsiasi | VirtualNetwork | Qualsiasi | Predefinito |
| Outbound | TCP | VirtualNetwork | Qualsiasi | EventHub | 9093 | Predefinito |
Importante
Azure Databricks è un servizio di prima parte di Microsoft Azure distribuito nell'infrastruttura cloud pubblico di Azure globale. Tutte le comunicazioni tra i componenti del servizio, inclusi gli indirizzi IP pubblici nel piano di controllo e il piano dati del cliente, rimangono all'interno del backbone della rete di Microsoft Azure. Vedere anche Rete globale Microsoft.
Risoluzione dei problemi relativi
Errori di creazione dell'area di lavoro
Per fare riferimento al collegamento di associazione del servizio, la subnet richiede una delle deleghe seguenti [Microsoft.Databricks/workspaces]
Possibile causa: si sta creando un'area di lavoro in una rete virtuale le cui subnet host e contenitore non sono state delegate al Microsoft.Databricks/workspaces servizio. Ogni subnet deve avere un gruppo di sicurezza di rete collegato e deve essere delegato correttamente. Per altre informazioni, vedere Requisiti di rete virtuale .
La subnet è già usata dall'area di lavoro
Possibile causa: si sta creando un'area di lavoro in una rete virtuale con subnet host e contenitori già usate da un'area di lavoro di Azure Databricks esistente. Non è possibile condividere più aree di lavoro in una singola subnet. È necessario avere una nuova coppia di subnet host e contenitori per ogni area di lavoro distribuita.
Risoluzione dei problemi relativi
Istanze non raggiungibili: le risorse non sono raggiungibili tramite SSH.
Possibile causa: il traffico dal piano di controllo ai ruoli di lavoro è bloccato. Se si esegue la distribuzione in una rete virtuale esistente connessa alla rete locale, esaminare la configurazione usando le informazioni fornite in Connettere l'area di lavoro di Azure Databricks alla rete locale.
Errore di avvio imprevisto: si è verificato un errore imprevisto durante la configurazione del cluster. Riprovare e contattare Azure Databricks se il problema persiste. Messaggio di errore interno: Timeout while placing node.
Possibile causa: il traffico dai ruoli di lavoro agli endpoint di Archiviazione di Azure è bloccato. Se si usano server DNS personalizzati, controllare anche lo stato dei server DNS nella rete virtuale.
Errore di avvio del provider di servizi cloud: si è verificato un errore del provider di servizi cloud durante la configurazione del cluster. Per altre informazioni, vedere la guida di Azure Databricks. Codice errore di Azure: AuthorizationFailed/InvalidResourceReference.
Possibile causa: la rete virtuale o le subnet non esistono più. Assicurarsi che la rete virtuale e le subnet esistano.
Cluster terminato. Motivo: Errore di avvio spark: Spark non è riuscito ad avviarsi nel tempo. Questo problema può essere causato da un metastore Hive non funzionante, da configurazioni Spark non valide o da script init non funzionanti. Vedere i log del driver Spark per risolvere questo problema e contattare Databricks se il problema persiste. Messaggio di errore interno: Spark failed to start: Driver failed to start in time.
Possibile causa: il contenitore non può comunicare con l'istanza di hosting o l'account di archiviazione DBFS. Correzione aggiungendo una route personalizzata alle subnet per l'account di archiviazione DBFS con l'hop successivo internet.