Gestire i cluster

Questo articolo descrive come gestire i cluster di Azure Databricks, tra cui la visualizzazione, la modifica, l'avvio, l'interruzione, l'eliminazione, il controllo dell'accesso e il monitoraggio delle prestazioni e dei log.

Visualizzare i cluster

Per visualizzare i cluster nell'area di lavoro, fare clic su Calcolo nella barra laterale.

Sul lato sinistro sono presenti due colonne che indicano se il cluster è stato aggiunto e lo stato del cluster. Passare il puntatore del mouse sullo stato per ottenere altre informazioni.

Aggiungere un cluster

Un cluster viene eliminato definitivamente 30 giorni dopo che è stato terminato. Per mantenere una configurazione di cluster tutto scopo dopo che un cluster è stato terminato per più di 30 giorni, un amministratore può aggiungere il cluster. È possibile aggiungere fino a 100 cluster.

Amministrazione è possibile aggiungere un cluster dall'elenco di cluster o dalla pagina dei dettagli del cluster facendo clic sull'icona a forma di puntina.

È anche possibile richiamare l'endpoint dell'API Clusters per aggiungere un cluster a livello di codice.

Visualizzare una configurazione del cluster come file JSON

A volte può essere utile visualizzare la configurazione del cluster come JSON. Ciò è particolarmente utile quando si vogliono creare cluster simili usando l'API Clusters. Quando si visualizza un cluster esistente, passare alla scheda Configurazione , fare clic su JSON nella parte superiore destra della scheda, copiare il codice JSON e incollarlo nella chiamata API. La visualizzazione JSON è di sola lettura.

Modificare un cluster

È possibile modificare una configurazione del cluster dall'interfaccia utente dei dettagli del cluster. È anche possibile richiamare l'endpoint dell'API Clusters per modificare il cluster a livello di codice.

Nota

• I notebook e i processi collegati al cluster rimangono collegati dopo la modifica.
• Le librerie installate nel cluster rimangono installate dopo la modifica.
• Se si modifica un attributo di un cluster in esecuzione (ad eccezione delle dimensioni e delle autorizzazioni del cluster), è necessario riavviarlo. Ciò può compromettere gli utenti che attualmente usano il cluster.
• È possibile modificare solo i cluster in esecuzione o terminati. È tuttavia possibile aggiornare le autorizzazioni per i cluster che non si trovano in tali stati, nella pagina dei dettagli del cluster.

Clonare un cluster

Per clonare un cluster esistente, selezionare Clona dal menu kebab del cluster (noto anche come menu a tre punti).

Dopo aver selezionato clone, l'interfaccia utente di creazione del cluster si apre prepopolato con la configurazione del cluster. I seguenti attributi non sono inclusi nel clone:

• Autorizzazioni del cluster
• Librerie installate
• Notebook collegati

Controllare l'accesso ai cluster

Il controllo di accesso al cluster all'interno della pagina delle impostazioni di amministrazione consente agli amministratori dell'area di lavoro di concedere agli altri utenti l'accesso al cluster con granularità fine. Esistono due tipi di controllo di accesso del cluster:

• Autorizzazione per la creazione del cluster: gli amministratori dell'area di lavoro possono scegliere quali utenti possono creare cluster.
• Autorizzazioni a livello di cluster: un utente che dispone dell'autorizzazione Può gestire per un cluster può configurare se altri utenti possono connettersi, riavviare, ridimensionare e gestire il cluster.

Per modificare le autorizzazioni per un cluster, selezionare Modifica autorizzazioni dal menu kebab del cluster.

Per altre informazioni sul controllo di accesso del cluster e sulle autorizzazioni a livello di cluster, vedere Controllo di accesso del cluster.

Terminare un cluster

Per salvare le risorse del cluster, è possibile terminare un cluster. La configurazione del cluster terminato viene archiviata in modo che possa essere riutilizzata (o, nel caso di processi, avvio automatico) in un secondo momento. È possibile terminare manualmente un cluster o configurare il cluster per terminare automaticamente dopo un periodo di inattività specificato. Quando il numero di cluster terminati supera 150, i cluster meno recenti vengono eliminati.

A meno che un cluster non venga aggiunto o riavviato, viene eliminato automaticamente e definitivamente 30 giorni dopo la chiusura.

I cluster terminati vengono visualizzati nell'elenco dei cluster con un cerchio grigio a sinistra del nome del cluster.

Nota

Quando si esegue un processo in un nuovo cluster di processi (in genere consigliato), il cluster termina e non è disponibile per il riavvio al termine del processo. D'altra parte, se si pianifica l'esecuzione di un processo in un cluster all-purpose esistente che è stato terminato, tale cluster verrà avviato automaticamente.

Importante

Se si usa un'area di lavoro Premium di valutazione, tutti i cluster in esecuzione vengono terminati:

• Quando si aggiorna un'area di lavoro al livello Premium completo.
• Se l'area di lavoro non viene aggiornata e la versione di valutazione scade.

Terminazione manuale

È possibile terminare manualmente un cluster dall'elenco di cluster facendo clic sul quadrato nella riga del cluster o sulla pagina dei dettagli del cluster facendo clic su Termina.

Terminazione automatica

È anche possibile impostare la terminazione automatica per un cluster. Durante la creazione del cluster, è possibile specificare un periodo di inattività in minuti dopo il quale si vuole che il cluster termini.

Se la differenza tra l'ora corrente e l'ultima esecuzione del comando nel cluster è maggiore del periodo di inattività specificato, Azure Databricks termina automaticamente il cluster.

Un cluster viene considerato inattivo quando tutti i comandi nel cluster, inclusi processi Spark, Structured Streaming e chiamate JDBC, hanno terminato l'esecuzione.

Avviso

• I cluster non segnalano l'attività risultante dall'uso di D Flussi. Ciò significa che un cluster con terminazione automatica può essere terminato durante l'esecuzione di D Flussi. Disattivare la terminazione automatica per i cluster che eseguono D Flussi o prendere in considerazione l'uso di Structured Streaming.
• La funzionalità di terminazione automatica monitora solo i processi Spark, non i processi locali definiti dall'utente. Pertanto, se tutti i processi Spark sono stati completati, un cluster può essere terminato, anche se i processi locali sono in esecuzione.
• I cluster inattivi continuano ad accumulare addebiti per le istanze cloud e DBU durante il periodo di inattività prima della chiusura.

Configurare la terminazione automatica

È possibile configurare la terminazione automatica nell'interfaccia utente del cluster di creazione. Assicurarsi che la casella sia selezionata e immettere il numero di minuti nell'impostazione Termina dopo ___ di minuti di inattività .

È possibile rifiutare esplicitamente la terminazione automatica deselezionando la casella di controllo Terminazione automatica o specificando un periodo di inattività di 0.

Nota

La terminazione automatica è più supportata nelle versioni più recenti di Spark. Le versioni precedenti di Spark presentano limitazioni note che possono causare la segnalazione imprecisa dell'attività del cluster. Ad esempio, i cluster che eseguono comandi JDBC, R o streaming possono segnalare un tempo di attività non aggiornato che porta alla terminazione prematura del cluster. Eseguire l'aggiornamento alla versione di Spark più recente per trarre vantaggio dalle correzioni di bug e dai miglioramenti alla terminazione automatica.

Terminazione imprevista

A volte un cluster viene terminato in modo imprevisto, non a causa di una terminazione manuale o di una terminazione automatica configurata.

Per un elenco dei motivi di terminazione e dei passaggi di correzione, vedere la Knowledge Base.

Eliminare un cluster

L'eliminazione di un cluster termina il cluster e ne rimuove la configurazione. Per eliminare un cluster, selezionare Elimina dal menu del cluster.

Avviso

Non è possibile annullare questa azione.

Per eliminare un cluster aggiunto, è necessario prima rimuoverlo da un amministratore.

È anche possibile richiamare l'endpoint dell'API Clusters per eliminare un cluster a livello di codice.

Riavviare un cluster

È possibile riavviare un cluster terminato in precedenza dall'elenco di cluster, dalla pagina dei dettagli del cluster o da un notebook. È anche possibile richiamare l'endpoint dell'API Clusters per avviare un cluster a livello di codice.

Azure Databricks identifica un cluster usando l'ID cluster univoco. Quando si avvia un cluster terminato, Databricks ricrea il cluster con lo stesso ID, installa automaticamente tutte le librerie e ricollega i notebook.

Nota

Se si usa un'area di lavoro Versione di valutazione e la versione di valutazione è scaduta, non sarà possibile avviare un cluster.

Riavviare un cluster per aggiornarlo con le immagini più recenti

Quando si riavvia un cluster, vengono recuperate le immagini più recenti per i contenitori di risorse di calcolo e gli host della macchina virtuale. È importante pianificare i riavvii regolari per i cluster a esecuzione prolungata, ad esempio quelli usati per l'elaborazione dei dati di streaming.

È responsabilità dell'utente riavviare regolarmente tutte le risorse di calcolo per mantenere aggiornata l'immagine con la versione più recente dell'immagine.

Importante

Se si abilita il profilo di sicurezza di conformità per l'account o l'area di lavoro, i cluster a esecuzione prolungata vengono riavviati automaticamente dopo 25 giorni. Databricks consiglia agli amministratori dell'area di lavoro di riavviare manualmente i cluster durante una finestra di manutenzione pianificata. In questo modo si riduce il rischio di un riavvio automatico che interrompe un processo pianificato.

Esempio di notebook: Trovare cluster con esecuzione prolungata

Se si è un amministratore dell'area di lavoro, è possibile eseguire uno script che determina per quanto tempo è stato eseguito ogni cluster e, facoltativamente, riavviarli se sono più vecchi di un numero di giorni specificato. Azure Databricks fornisce questo script come notebook.

Le prime righe dello script definiscono i parametri di configurazione:

• min_age_output: numero massimo di giorni di esecuzione di un cluster. Il valore predefinito è 1.
• perform_restart: se True, lo script riavvia i cluster con età maggiore del numero di giorni specificato da min_age_output. Il valore predefinito è False, che identifica i cluster a esecuzione prolungata, ma non li riavvia.
• secret_configuration: sostituire REPLACE_WITH_SCOPE e REPLACE_WITH_KEY con un ambito segreto e un nome di chiave. Per altri dettagli sulla configurazione dei segreti, vedere il notebook.

Avviso

Se si imposta su perform_restartTrue, lo script riavvia automaticamente i cluster idonei, causando l'esito negativo dei processi attivi e la reimpostazione dei notebook aperti. Per ridurre il rischio di interrompere i processi aziendali critici dell'area di lavoro, pianificare una finestra di manutenzione pianificata e assicurarsi di informare gli utenti dell'area di lavoro.

Identificare e riavviare facoltativamente il notebook dei cluster con esecuzione prolungata

Ottenere il notebook

Avvio automatico del cluster per processi e query JDBC/ODBC

Quando un processo assegnato a un cluster terminato è pianificato per l'esecuzione oppure ci si connette a un cluster terminato da un'interfaccia JDBC/ODBC, il cluster viene riavviato automaticamente. Vedere Creare un processo e una connessione JDBC.

L'avvio automatico del cluster consente di configurare i cluster per terminare automaticamente senza richiedere l'intervento manuale per riavviare i cluster per i processi pianificati. È inoltre possibile pianificare l'inizializzazione del cluster pianificando l'esecuzione di un processo in un cluster terminato.

Prima che un cluster venga riavviato automaticamente, vengono controllate le autorizzazioni di controllo dell'accesso al cluster e al processo.

Nota

Se il cluster è stato creato nella piattaforma Azure Databricks versione 2.70 o precedente, non è previsto alcun avvio automatico: i processi pianificati per l'esecuzione nei cluster terminati avranno esito negativo.

Visualizzare le informazioni sul cluster nell'interfaccia utente di Apache Spark

È possibile visualizzare informazioni dettagliate sui processi Spark selezionando la scheda Interfaccia utente Spark nella pagina dei dettagli del cluster.

Se si riavvia un cluster terminato, l'interfaccia utente di Spark visualizza informazioni per il cluster riavviato, non le informazioni cronologiche per il cluster terminato.

Visualizzare i registri cluster

Azure Databricks offre tre tipi di registrazione delle attività correlate al cluster:

• Log eventi del cluster, che acquisisce eventi del ciclo di vita del cluster, ad esempio la creazione, la terminazione e le modifiche alla configurazione.
• Driver Apache Spark e log di lavoro, che è possibile usare per il debug.
• Log init-script del cluster, utili per il debug di script init.

Questa sezione illustra i log eventi del cluster e i log di driver e di lavoro. Per informazioni dettagliate sui log init-script, vedere Registrazione degli script Init.

Log eventi del cluster

Il registro eventi del cluster visualizza importanti eventi del ciclo di vita del cluster che vengono attivati manualmente dalle azioni dell'utente o automaticamente da Azure Databricks. Tali eventi influiscono sul funzionamento di un cluster nel suo complesso e sui processi in esecuzione nel cluster.

Per i tipi di evento supportati, vedere la struttura dei dati dell'API Clusters.

Gli eventi vengono archiviati per 60 giorni, che è paragonabile ad altri tempi di conservazione dei dati in Azure Databricks.

Visualizzare un registro eventi del cluster

Per visualizzare il registro eventi del cluster, selezionare la scheda Registro eventi nelle pagine dei dettagli del cluster.

Per altre informazioni su un evento, fare clic sulla relativa riga nel log, quindi fare clic sulla scheda JSON per informazioni dettagliate.

Log del driver e del ruolo di lavoro del cluster

Le istruzioni di stampa diretta e log dai notebook, dai processi e dalle librerie passano ai log dei driver Spark. È possibile accedere a questi file di log dalla scheda Log driver nella pagina dei dettagli del cluster. Fare clic sul nome di un file di log per scaricarlo.

Questi log hanno tre output:

• Output standard
• Errore standard
• Log4j

Per visualizzare i log del ruolo di lavoro Spark, usare la scheda Interfaccia utente Spark. È anche possibile configurare un percorso di recapito dei log per il cluster. I log del ruolo di lavoro e del cluster vengono recapitati nel percorso specificato.

Monitorare le prestazioni

Per monitorare le prestazioni dei cluster Di Azure Databricks, Azure Databricks consente di accedere alle metriche dalla pagina dei dettagli del cluster. Per Databricks Runtime 12.2 e versioni successive, Azure Databricks fornisce l'accesso alle metriche Ganglia . Per Databricks Runtime 13.0 e versioni successive, le metriche del cluster vengono fornite da Azure Databricks.

È anche possibile configurare un cluster Azure Databricks in modo da inviare metriche a un'area di lavoro Log Analytics in Monitoraggio di Azure, la piattaforma di monitoraggio per Azure.

È anche possibile installare agenti Datadog nei nodi del cluster per inviare le metriche di Datadog all'account Datadog.

Metriche del cluster

Le metriche dei cluster sono lo strumento di monitoraggio predefinito per Databricks Runtime 13.0 e versioni successive. Per accedere all'interfaccia utente delle metriche del cluster, passare alla scheda Metriche nella pagina dei dettagli del cluster.

È possibile visualizzare le metriche cronologiche selezionando un intervallo di tempo usando il filtro selezione data. Le metriche vengono raccolte ogni minuto. È anche possibile ottenere le metriche più recenti facendo clic sul pulsante Aggiorna . Per altre informazioni, vedere Visualizza le metriche dei cluster in tempo reale e cronologico.

Metriche Ganglia

Nota

Le metriche Ganglia sono disponibili solo per Databricks Runtime 12.2 e versioni successive.

Per accedere all'interfaccia utente di Ganglia, passare alla scheda Metriche nella pagina dei dettagli del cluster. Le metriche della CPU sono disponibili nell'interfaccia utente ganglia per tutti i runtime di Databricks. Le metriche GPU sono disponibili per i cluster abilitati per GPU.

Per visualizzare le metriche in tempo reale, fare clic sul collegamento Ganglia UI .To view live metrics, click the Ganglia UI link.

Per visualizzare le metriche cronologiche, fare clic su un file di snapshot. Lo snapshot contiene metriche aggregate per l'ora che precede l'ora selezionata.

Nota

Ganglia non è supportata con i contenitori Docker. Se si usa un contenitore Docker con il cluster, le metriche Ganglia non saranno disponibili.

Configurare la raccolta di metriche Ganglia

Per impostazione predefinita, Azure Databricks raccoglie le metriche Ganglia ogni 15 minuti. Per configurare il periodo di raccolta, impostare la DATABRICKS_GANGLIA_SNAPSHOT_PERIOD_MINUTES variabile di ambiente usando uno script init o nel spark_env_vars campo nell'API Crea nuovo cluster.

Monitoraggio di Azure

È possibile configurare un cluster di Azure Databricks per inviare metriche a un'area di lavoro Log Analytics in Monitoraggio di Azure, la piattaforma di monitoraggio per Azure. Per trovare le istruzioni complete, vedere Monitoraggio di Azure Databricks.

Nota

Se l'area di lavoro di Azure Databricks è stata distribuita nella propria rete virtuale e sono stati configurati gruppi di sicurezza di rete (NSG) per negare tutto il traffico in uscita non richiesto da Azure Databricks, è necessario configurare una regola aggiuntiva in uscita per il tag di servizio "AzureMonitor".

Esempio di notebook: metriche di Datadog

È possibile installare gli agenti Datadog nei nodi del cluster per inviare le metriche di Datadog all'account Datadog. Il notebook seguente illustra come installare un agente Datadog in un cluster usando uno script init con ambito cluster.

Per installare l'agente Datadog in tutti i cluster, gestire lo script init con ambito cluster usando un criterio cluster.

Installare il notebook script init dell'agente Datadog

Ottenere il notebook

Rimuovere le istanze spot

Poiché le istanze spot possono ridurre i costi, la creazione di cluster che usano istanze spot anziché istanze su richiesta è un modo comune per eseguire i processi. Tuttavia, le istanze spot possono essere annullate dai meccanismi di pianificazione del provider di servizi cloud. La precedenza delle istanze spot può causare problemi con i processi in esecuzione, tra cui:

• Errori di recupero casuale
• Perdita di dati casuali
• Perdita di dati RDD
• Errori dei processi

È possibile abilitare la rimozione delle autorizzazioni per risolvere questi problemi. La rimozione delle autorizzazioni sfrutta la notifica che il provider di servizi cloud in genere invia prima che un'istanza spot venga rimossa. Quando un'istanza spot contenente un executor riceve una notifica di precedenza, il processo di rimozione delle autorizzazioni tenterà di eseguire la migrazione di dati casuali e RDD a executor integri. La durata prima della precedenza finale è in genere compresa tra 30 e 2 minuti, a seconda del provider di servizi cloud.

Databricks consiglia di abilitare la migrazione dei dati anche quando la rimozione delle autorizzazioni è abilitata. In genere, la possibilità di errori diminuisce man mano che viene eseguita la migrazione di più dati, tra cui errori di recupero casuale, perdita di dati casuali e perdita di dati RDD. La migrazione dei dati può anche comportare una riduzione del calcolo e dei costi risparmiati.

Nota

La rimozione delle autorizzazioni è un'operazione ottimale e non garantisce che tutti i dati possano essere migrati prima della precedenza finale. La rimozione delle autorizzazioni non può garantire errori di recupero casuale quando le attività in esecuzione recuperano dati casuali dall'executor.

Con la rimozione delle autorizzazioni abilitata, gli errori delle attività causati dalla precedenza dell'istanza spot non vengono aggiunti al numero totale di tentativi non riusciti. Gli errori di attività causati dalla precedenza non vengono conteggiati come tentativi non riusciti perché la causa dell'errore è esterna all'attività e non genererà un errore del processo.

Abilitare la rimozione delle autorizzazioni

Per abilitare la rimozione delle autorizzazioni in un cluster, immettere le proprietà seguenti nella scheda Spark in Opzioni avanzate nell'interfaccia utente della configurazione del cluster. Per informazioni su queste proprietà, vedere Configurazione di Spark.

• Per abilitare la rimozione delle autorizzazioni per le applicazioni, immettere questa proprietà nel campo Configurazione Spark:

  spark.decommission.enabled true
  

• Per abilitare la migrazione casuale dei dati durante la rimozione delle autorizzazioni, immettere questa proprietà nel campo configurazione spark:

  spark.storage.decommission.enabled true
  spark.storage.decommission.shuffleBlocks.enabled true
  

• Per abilitare la migrazione dei dati della cache RDD durante la rimozione delle autorizzazioni, immettere questa proprietà nel campo Configurazione Spark:

  spark.storage.decommission.enabled true
  spark.storage.decommission.rddBlocks.enabled true
  

  Nota

  Quando la replica RDD Archiviazione Level è impostata su più di 1, Databricks non consiglia di abilitare la migrazione dei dati RDD perché le repliche assicurano che i set di dati RDD non perdano i dati.

• Per abilitare la rimozione delle autorizzazioni per i ruoli di lavoro, immettere questa proprietà nel campo Variabili di ambiente:

  SPARK_WORKER_OPTS="-Dspark.decommission.enabled=true"
  

Visualizzare lo stato e la perdita delle autorizzazioni nell'interfaccia utente

Per accedere allo stato di rimozione delle autorizzazioni di un ruolo di lavoro dall'interfaccia utente, passare alla scheda Interfaccia utente cluster Spark - Master .

Al termine della rimozione delle autorizzazioni, è possibile visualizzare il motivo della perdita dell'executor nella scheda Executor dell'interfaccia utente > Spark nella pagina dei dettagli del cluster.