Distribuire Azure Databricks nella rete virtuale di Azure (VNet Injection)

Questo articolo descrive come distribuire un'area di lavoro di Azure Databricks nella propria rete virtuale di Azure, nota anche come inserimento di reti virtuali.

Personalizzazione della rete con inserimento reti virtuali

La distribuzione predefinita di Azure Databricks è un servizio completamente gestito in Azure. Una rete virtuale di Azure viene distribuita in un gruppo di risorse bloccato. Tutte le risorse del piano di calcolo classico sono associate alla rete virtuale. Se è necessaria la personalizzazione della rete, è possibile distribuire le risorse del piano di calcolo classico di Azure Databricks nella propria rete virtuale. Ciò consente 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 di Azure.
• Connettersi alle origini dati locali usando route definite dall'utente. Vedere Impostazioni di percorsi definiti dall'utente per Azure Databricks.
• Connettere Azure Databricks a un'appliance virtuale di rete per ispezionare tutto il traffico in uscita e intraprendere azioni a seconda delle regole di autorizzazione e negazione. Vedere Opzione: Instradare il traffico di Azure Databricks usando un'appliance virtuale o un firewall
• Configurare Azure Databricks in modo che usi DNS personalizzato. Vedere Opzione: Configurare il DNS personalizzato.
• Configurare le regole del gruppo di sicurezza di rete (NSG) in modo che specifichino le restrizioni del traffico in uscita.

La distribuzione di risorse del piano di calcolo classico di Azure Databricks nella propria rete virtuale consente anche di sfruttare i vantaggi di intervalli CIDR flessibili. Per la rete virtuale, è possibile usare le dimensioni /16-/24dell'intervallo CIDR. Per le subnet, usare intervalli IP di dimensioni ridotte come /26.

Importante

Non è possibile sostituire la rete virtuale per un'area di lavoro esistente. Se l'area di lavoro corrente non è in grado di contenere il numero necessario di nodi del cluster attivi, è consigliabile creare un'altra area di lavoro in una rete virtuale più grande. Seguire questi passaggi dettagliati della migrazione per copiare le risorse come notebook, configurazioni del cluster e processi dall'area di lavoro precedente a quella nuova.

Requisiti della rete virtuale

La rete virtuale che si distribuisce l'area di lavoro di Azure Databricks per soddisfare i requisiti seguenti:

• Area: la rete virtuale deve trovarsi nella stessa area e nella stessa sottoscrizione 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 /16 e /24 per la rete virtuale e un blocco CIDR fino a /26 per 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 nodi massimi 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). Quando si distribuisce un'area di lavoro usando la connettività sicura del cluster, sia la subnet del contenitore che la subnet host usano indirizzi IP privati. Non è possibile 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 nodi massimi del cluster.

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). È possibile creare un blocco CIDR fino a /28 per le subnet, tuttavia Databricks non consiglia una subnet più piccola di /26.

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 e una subnet host. Azure riserva cinque indirizzi IP in ogni subnet. Azure Databricks richiede 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.

• Potrebbe non essere necessario 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 totale della rete virtuale.
• È necessario allocare spazio indirizzi per due nuove subnet che si trovano nello spazio indirizzi della rete virtuale e non sovrapporre lo spazio indirizzi delle subnet correnti o future in tale rete virtuale.

La tabella seguente mostra 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 tali dimensioni.

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

Indirizzi IP in uscita quando si usa la connettività sicura del cluster

Se si abilita la connettività sicura del cluster nell'area di lavoro che usa l'inserimento della rete virtuale, Databricks consiglia di usare un indirizzo IP pubblico in uscita stabile nell'area di lavoro.

Gli indirizzi IP pubblici in uscita stabili sono utili perché è possibile aggiungerli a elenchi di indirizzi consentiti esterni. Ad esempio, per connettersi da Azure Databricks a Salesforce con un indirizzo IP in uscita stabile. Se si configurano gli elenchi di accesso IP, tali indirizzi IP pubblici devono essere aggiunti a un elenco di indirizzi consentiti. Consultare Configurare gli elenchi di accesso IP per le aree di lavoro.

Avviso

Microsoft ha annunciato che il 30 settembre 2025, la connettività di accesso in uscita predefinita per le macchine virtuali in Azure verrà ritirata. Vedere questo annuncio. Ciò significa che le aree di lavoro di Azure Databricks che usano l'accesso in uscita predefinito anziché un indirizzo IP pubblico in uscita stabile potrebbero non continuare a funzionare dopo tale data. Databricks consiglia di aggiungere metodi in uscita espliciti per le aree di lavoro prima di tale data.

Per configurare un indirizzo IP pubblico in uscita stabile, vedere Uscita con inserimento rete virtuale

Risorse condivise e peering

Se sono necessarie risorse di rete condivise come DNS, Databricks consiglia vivamente di seguire le procedure consigliate di Azure per il modello hub-spoke. Usare il peering reti virtuali per estendere lo spazio IP privato della rete virtuale dell'area di lavoro all'hub mantenendo gli spoke isolati l'uno dall'altro.

Se si dispone di altre risorse nella rete virtuale o si usa il peering, Databricks consiglia vivamente di aggiungere regole di negazione ai gruppi di sicurezza di rete collegati ad altre reti e subnet che si trovano nella stessa rete virtuale o sono sottoposte a peering a tale rete virtuale. Aggiungere regole di negazione per le connessioni sia in ingresso che in uscita in modo da limitare le connessioni da e verso le risorse di calcolo di Azure Databricks. Se il cluster deve accedere alle risorse in rete, aggiungere regole per consentire solo la quantità minima di accesso necessaria per soddisfare i requisiti.

Per informazioni correlate, vedere Regole del gruppo di sicurezza di rete.

Creare un'area di lavoro di Azure Databricks usando portale di Azure

Questa sezione descrive come creare un'area di lavoro di Azure Databricks nella 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é il portale. Ad esempio, usare i gruppi di sicurezza di rete esistenti o creare regole di sicurezza personalizzate. Vedere Configurazione avanzata con i modelli di Azure Resource Manager.

All'utente che crea l'area di lavoro deve essere assegnato il ruolo Collaboratore rete al Rete virtuale corrispondente oppure a un ruolo personalizzato a cui sono assegnate le Microsoft.Network/virtualNetworks/subnets/join/action autorizzazioni e Microsoft.Network/virtualNetworks/subnets/write .

È 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.

1. 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.

2. Seguire i passaggi di configurazione descritti nell'argomento di avvio rapido Creare un'area di lavoro di Azure Databricks nella propria rete virtuale.

3. 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.

   

4. Assegnare un nome alle subnet e specificare intervalli CIDR in un blocco fino alle dimensioni /26. Per indicazioni sul numero massimo di nodi del cluster in base alle dimensioni della rete virtuale e alle relative subnet, vedere Spazio indirizzi e nodi massimi del cluster. Non è possibile modificare gli intervalli CIDR della subnet dopo la distribuzione dell'area di lavoro.

   • 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 in modo che corrisponda esattamente agli intervalli IP delle subnet esistenti.
   • Per creare nuove subnet, specificare i nomi di subnet che non esistono già in tale 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.

   Azure Databricks richiede che i nomi delle subnet non siano più di 80 caratteri.

   Le subnet ottengono regole del gruppo di sicurezza di rete associate che includono la regola per consentire la comunicazione interna al cluster. Azure Databricks ha autorizzazioni delegate per aggiornare entrambe le subnet tramite il Microsoft.Databricks/workspaces provider 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.

5. Fare clic su Crea per distribuire l'area di lavoro di Azure Databricks nella rete virtuale.

Configurazione avanzata con i modelli di Azure Resource Manager

Per un maggiore controllo sulla configurazione della rete virtuale, usare i modelli di Azure Resource Manager (ARM) seguenti anziché la configurazione automatica della rete virtuale e la distribuzione dell'area di lavoro 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 l'inserimento di reti virtuali di Azure Databricks 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 avere una nuova coppia di subnet host e del contenitore per ogni area di lavoro implementata.

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 l'inserimento della rete virtuale di Azure Databricks.

Il modello di area di lavoro consente di specificare una rete virtuale esistente e di usare le subnet esistenti:

• È necessario disporre di una coppia separata di subnet host/contenitore per ogni area di lavoro distribuita. 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.
• Le subnet host e contenitori della rete virtuale devono avere gruppi di sicurezza di rete collegati e devono essere delegati al Microsoft.Databricks/workspaces servizio prima di usare questo modello di Azure Resource Manager per distribuire un'area di 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 sono ancora state delegate le subnet host e contenitori, vedere Aggiungere o rimuovere una delega di subnet.

Regole del gruppo di sicurezza di rete

Le tabelle seguenti mostrano 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.

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 di cui Azure Databricks esegue automaticamente il provisioning e la gestione nel gruppo di sicurezza di rete, in virtù 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 e qualsiasi tentativo di farlo viene bloccato dalla delega della subnet. Azure Databricks deve possedere queste regole per garantire che Microsoft possa operare e supportare in modo affidabile 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. Questo vale anche in più aree di lavoro se le aree di lavoro vengono distribuite in una coppia diversa di subnet nella stessa rete virtuale gestita dal cliente.

Importante

Databricks consiglia vivamente di aggiungere regole di negazione ai gruppi di sicurezza di rete collegati ad altre reti e subnet che si trovano nella stessa rete virtuale o con peering a tale rete virtuale. Aggiungere regole di negazione per le connessioni sia in ingresso che in uscita in modo da limitare le connessioni da e verso le risorse di calcolo di Azure Databricks. Se il cluster deve accedere alle risorse in rete, aggiungere regole per consentire solo la quantità minima di accesso necessaria per soddisfare i requisiti.

Regole del gruppo di sicurezza di rete per le aree di lavoro

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 del rilascio della connettività sicura del cluster (SCC) il 13 gennaio 2020, vedere la sezione successiva.

Questa tabella elenca le regole del gruppo di sicurezza di rete per le aree di lavoro e include due regole del gruppo di sicurezza in ingresso incluse solo se la connettività sicura del cluster è disabilitata.

Direzione	Protocollo	Origine	Porta di origine	Destinazione	Porta Dest	nr. utilizzato
In ingresso	Qualsiasi	VirtualNetwork	Qualsiasi	VirtualNetwork	Any	Predefiniti
In entrata	TCP	AzureDatabricks (tag del servizio) Solo se SCC è disabilitato	Qualsiasi	VirtualNetwork	22	IP pubblico
In entrata	TCP	AzureDatabricks (tag del servizio) Solo se SCC è disabilitato	Qualsiasi	VirtualNetwork	5557	IP pubblico
In uscita	TCP	VirtualNetwork	Any	AzureDatabricks (tag del servizio)	443, 3306, 8443-8451	Predefiniti
In uscita	TCP	VirtualNetwork	Any	SQL	3306	Predefiniti
In uscita	TCP	VirtualNetwork	Any	Storage	443	Predefiniti
In uscita	Qualsiasi	VirtualNetwork	Qualsiasi	VirtualNetwork	Any	Predefiniti
In uscita	TCP	VirtualNetwork	Any	EventHub	9093	Impostazione predefinita

Nota

Se si limitano le regole in uscita, Databricks consiglia di aprire le porte 111 e 2049 per abilitare determinate installazioni di libreria.

Importante

Azure Databricks è un servizio proprietario in Microsoft Azure distribuito nell'infrastruttura globale del cloud pubblico di Azure. Tutte le comunicazioni tra componenti del servizio, inclusi gli indirizzi IP pubblici nel piano di controllo e il piano di calcolo del cliente, rimangono all'interno del backbone della rete di Microsoft Azure. Vedere anche Rete globale Microsoft.

Risoluzione dei problemi

Errori di creazione dell'area di lavoro

La subnet <subnet-id> richiede uno o più delegati seguenti [Microsoft.Databricks/workspaces] per fare riferimento al collegamento all'associazione del servizio

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 delegata correttamente. Per altre informazioni, vedere Requisiti della rete virtuale.

La subnet <subnet-id> è già in uso per l'area di lavoro <workspace-id>

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 del contenitore per ogni area di lavoro distribuita.

Risoluzione dei problemi

Istanze non raggiungibili: le risorse non sono raggiungibili tramite SSH.

Possibile causa: il traffico dal piano di controllo ai lavoratori è bloccato. Se si esegue la distribuzione in una rete virtuale esistente connessa alla rete locale, rivedere la configurazione usando le informazioni contenute 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. Se il problema persiste, riprovare e contattare Azure Databricks. Messaggio di errore interno: Timeout while placing node.

Possibile causa: il traffico da ruoli di lavoro a Archiviazione di Azure endpoint è 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 terminated. (Cluster terminato.) Motivo: errore di avvio di Spark: Spark non è stato in grado di avviarsi in tempo. Questo problema può essere causato da un malfunzionamento del metastore Hive, da configurazioni Spark non valide o dal malfunzionamento di script init. Vedere i log dei driver di 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 dell'area di lavoro. Correzione aggiungendo una route personalizzata alle subnet per l'account di archiviazione dell'area di lavoro con l'hop successivo internet.