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 di calcolo classico, 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 classiche del piano di calcolo di Azure Databricks nella propria rete virtuale (talvolta denominata inserimento reti virtuali), consentendo di:
- Connessione Azure Databricks ad altri servizi di Azure (ad esempio Archiviazione di Azure) in modo più sicuro usando endpoint di servizio o endpoint privati.
- Connessione alle origini dati locali da usare con Azure Databricks, sfruttando le route definite dall'utente.
- Connessione Azure Databricks a un'appliance virtuale di rete per esaminare tutto il traffico in uscita e intraprendere 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 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. Gli intervalli di subnet più piccoli, /27 ad esempio, non sono supportati.
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 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 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). 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 nodi massimi 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 dai nomi e dagli 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 arm 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 di 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 Resource Manager forniti da Azure Databricks.
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).
Nota
È 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 (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.
- 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.
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 esistenti 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 le opzioni di implementazione, vedere Connettività sicura del cluster
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é 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 Azure Resource Manager.
Importante
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.
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 nell'argomento di avvio rapido 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 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.
Importante
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.
Importante
Azure Databricks richiede che i nomi delle subnet non siano più di 80 caratteri. Questo valore è più breve della lunghezza massima consentita per le subnet nel portale di Azure. Prima di usare una subnet esistente, rinominarla se il nome è più lungo 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 avrà 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.
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 comunque creata ma ha uno stato di errore. Eliminare l'area di lavoro in errore e crearne una nuova per risolvere gli errori di distribuzione. Quando si elimina l'area di lavoro in errore, vengono eliminati anche il gruppo di risorse gestite e tutte le eventuali risorse distribuite correttamente.
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/workspacesservizio 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.
Contenuto della 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 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; qualsiasi tentativo di eseguire questa operazione 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 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 del rilascio della connettività sicura del cluster (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 | Origine | Porta di origine | Destinazione | Porta Dest | nr. utilizzato |
|---|---|---|---|---|---|---|
| In ingresso | Qualsiasi | VirtualNetwork | Qualsiasi | VirtualNetwork | Any | Default |
| 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 | Default |
| In uscita | TCP | VirtualNetwork | Any | SQL | 3306 | Default |
| In uscita | TCP | VirtualNetwork | Any | Storage | 443 | Default |
| In uscita | Qualsiasi | VirtualNetwork | Qualsiasi | VirtualNetwork | Any | Default |
| 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.
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 il 13 gennaio 2020 o dopo il 13 gennaio 2020, vedere la sezione precedente.
| Direzione | Protocollo | Origine | Porta di origine | Destinazione | Porta Dest | nr. utilizzato |
|---|---|---|---|---|---|---|
| In ingresso | Qualsiasi | VirtualNetwork | Qualsiasi | VirtualNetwork | Any | Default |
| In entrata | TCP | ControlPlane IP | Qualsiasi | VirtualNetwork | 22 | IP pubblico |
| In entrata | TCP | ControlPlane IP | Qualsiasi | VirtualNetwork | 5557 | IP pubblico |
| In uscita | TCP | VirtualNetwork | Any | IP dell'app Web | 443 | Default |
| In uscita | TCP | VirtualNetwork | Any | SQL | 3306 | Default |
| In uscita | TCP | VirtualNetwork | Any | Storage | 443 | Default |
| In uscita | Qualsiasi | VirtualNetwork | Qualsiasi | VirtualNetwork | Any | Default |
| In uscita | TCP | VirtualNetwork | Any | EventHub | 9093 | Default |
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 con l'account di archiviazione DBFS. Correggere aggiungendo una route personalizzata alle subnet per l'account di archiviazione DBFS in cui l'hop successivo è Internet.