Questa pagina descrive i passaggi per la risoluzione dei problemi, utili in caso di problemi nell'utilizzo di Vertex AI Workbench.
Consulta anche la sezione Risoluzione dei problemi di Vertex AI per assistenza sull'utilizzo di altri componenti di Vertex AI.
Per filtrare i contenuti di questa pagina, fai clic su un argomento:
Istanze Vertex AI Workbench
Questa sezione descrive i passaggi per la risoluzione dei problemi relativi alle istanze di Vertex AI Workbench.
Connessione e apertura di JupyterLab
Questa sezione descrive i passaggi per la risoluzione dei problemi relativi alla connessione e all'apertura di JupyterLab.
Non succede nulla dopo aver fatto clic su Apri JupyterLab
Problema
Quando fai clic su Apri JupyterLab, non succede nulla.
Soluzione:
Verifica che il browser non blocchi l'apertura automatica delle nuove schede. JupyterLab si apre in una nuova scheda del browser.
Impossibile accedere al terminale in un'istanza di Vertex AI Workbench
Problema
Se non riesci ad accedere al terminale o non riesci a trovare la finestra del terminale nel avviatore, è possibile che l'accesso al terminale non sia abilitato nell'istanza Vertex AI Workbench.
Soluzione:
Devi creare una nuova istanza di Vertex AI Workbench con l'opzione Accesso al terminale abilitata. Questa opzione non può essere modificata dopo la creazione dell'istanza.
Errore 502 durante l'apertura di JupyterLab
Problema
Un errore 502 potrebbe indicare che l'istanza di Vertex AI Workbench non è ancora pronta.
Soluzione:
Attendi qualche minuto, aggiorna la scheda del browser della console Google Cloud e riprova.
Il notebook non risponde
Problema
L'istanza di Vertex AI Workbench non esegue celle o sembra essere bloccata.
Soluzione:
Per prima cosa, prova a riavviare il kernel facendo clic su Kernel nel menu in alto e poi su Riavvia kernel. Se non funziona, puoi provare quanto segue:
- Aggiorna la pagina del browser JupyterLab. L'output delle celle non salvato non viene mantenuto, quindi devi eseguire di nuovo queste celle per rigenerare l'output.
- Reimposta l'istanza.
Impossibile connettersi all'istanza Vertex AI Workbench tramite SSH
Problema
Non riesci a connetterti all'istanza utilizzando SSH tramite una finestra del terminale.
Le istanze Vertex AI Workbench utilizzano l'accesso al sistema operativo per attivare l'accesso SSH. Quando crei un'istanza, Vertex AI Workbench attiva
l'accesso all'OS Login per impostazione predefinita impostando la chiave dei metadati enable-oslogin
su TRUE
. Se non riesci a utilizzare SSH per connetterti all'istanza, questa chiave dei metadati potrebbe dover essere impostata su TRUE
.
Soluzione:
La connessione a un'istanza Vertex AI Workbench utilizzando la console Google Cloud non è supportata. Se non riesci a connetterti all'istanza utilizzando SSH tramite una finestra del terminale, consulta quanto segue:
Per impostare la chiave dei metadati enable-oslogin
su TRUE
, utilizza il metodo
projects.locations.instances.patch
nell'API Notebooks o il comando
gcloud workbench instances update
nell'Google Cloud SDK.
La quota di GPU è stata superata
Problema
Non riesci a creare un'istanza di Vertex AI Workbench con GPU.
Soluzione:
Determina il numero di GPU disponibili nel tuo progetto controllando la pagina Quote. Se le GPU non sono elencate nella pagina delle quote o se hai bisogno di una quota di GPU aggiuntiva, puoi richiedere un aumento della quota. Consulta Richiedere un limite di quota più alto.
Creazione di istanze Vertex AI Workbench
Questa sezione descrive come risolvere i problemi relativi alla creazione di istanze di Vertex AI Workbench.
L'istanza rimane in stato di attesa a tempo indeterminato o è bloccata nello stato di provisioning
Problema
Dopo aver creato un'istanza di Vertex AI Workbench, questa rimane nello stato in attesa a tempo indeterminato. Nei log di serie potrebbe essere visualizzato un errore simile al seguente:
Could not resolve host: notebooks.googleapis.com
Se lo stato del provisioning dell'istanza è bloccato, il motivo potrebbe essere una configurazione di rete privata non valida per l'istanza.
Soluzione:
Segui i passaggi descritti nella sezione I log dell'istanza mostrano errori di connessione o timeout.
Impossibile creare un'istanza all'interno di una rete VPC condiviso
Problema
Il tentativo di creare un'istanza all'interno di una rete VPC condivisa genera un messaggio di errore simile al seguente:
Required 'compute.subnetworks.use' permission for 'projects/network-administration/regions/us-central1/subnetworks/v'
Soluzione:
Il problema è che l'account di servizio Notebooks sta tentando di creare l'istanza senza le autorizzazioni corrette.
Per assicurarti che l'account di servizio Notebooks disponga delle autorizzazioni necessarie per creare un'istanza di Vertex AI Workbench all'interno di una rete VPC condivisa,
chiedi all'amministratore di concedere all'account di servizio Notebooks il ruolo IAM Utente di rete Compute (roles/compute.networkUser
) nel progetto host.
Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.
Questo ruolo predefinito contiene le autorizzazioni necessarie per garantire che l'account di servizio Notebooks possa creare un'istanza Vertex AI Workbench all'interno di una rete VPC condiviso. Per visualizzare le autorizzazioni esatte richieste, espandi la sezione Autorizzazioni richieste:
Autorizzazioni obbligatorie
Per assicurarti che l'account di servizio Notebooks possa creare un'istanza di Vertex AI Workbench all'interno di una rete VPC condiviso, sono necessarie le seguenti autorizzazioni:
-
Per utilizzare le subnet:
compute.subnetworks.use
L'amministratore potrebbe anche assegnare all'account di servizio Notebook queste autorizzazioni con ruoli personalizzati o altri ruoli predefiniti.
Impossibile creare un'istanza di Vertex AI Workbench con un contenitore personalizzato
Problema
Non è possibile utilizzare un contenitore personalizzato durante la creazione di un'istanza di Vertex AI Workbench nella console Google Cloud.
Soluzione:
L'aggiunta di un contenitore personalizzato a un'istanza di Vertex AI Workbench non è supportata e non puoi aggiungere un contenitore personalizzato utilizzando la console Google Cloud.
È consigliabile aggiungere un ambiente conda anziché utilizzare un container personalizzato.
Puoi aggiungere un contenitore personalizzato a un'istanza Vertex AI Workbench utilizzando l'API Notebooks, ma questa funzionalità non è supportata.
Il pulsante Montaggio dello spazio di archiviazione condiviso non è presente
Problema
Il pulsante Monta spazio di archiviazione condiviso non è presente nella scheda File Browser dell'interfaccia JupyterLab.
Soluzione:
L'autorizzazione storage.buckets.list
è necessaria per visualizzare il pulsante
Monta archiviazione condivisa nell'interfaccia JupyterLab della tua
istanza Vertex AI Workbench. Chiedi all'amministratore di concedere all'account di servizio della tua istanza Vertex AI Workbench l'autorizzazione storage.buckets.list
per il progetto.
Errore 599 durante l'utilizzo di Dataproc
Problema
Il tentativo di creare un'istanza abilitata per Dataproc genera un messaggio di errore simile al seguente:
HTTP 599: Unknown (Error from Gateway: [Timeout while connecting] Exception while attempting to connect to Gateway server url. Ensure gateway url is valid and the Gateway instance is running.)
Soluzione:
Nella configurazione di Cloud DNS, aggiungi una voce Cloud DNS per il dominio *.googleusercontent.com
.
Impossibile installare l'estensione JupyterLab di terze parti
Problema
Il tentativo di installare un'estensione JupyterLab di terze parti genera un messaggioError: 500
.
Soluzione:
Le estensioni JupyterLab di terze parti non sono supportate nelle istanze di Vertex AI Workbench.
Impossibile modificare la macchina virtuale sottostante
Problema
Quando provi a modificare la macchina virtuale (VM) sottostante di un'istanza di Vertex AI Workbench, potresti visualizzare un messaggio di errore simile al seguente:
Current principal doesn't have permission to mutate this resource.
Soluzione:
Questo errore si verifica perché non puoi modificare la VM sottostante di un'istanza utilizzando la console Google Cloud o l'API Compute Engine.
Per modificare la VM sottostante di un'istanza di Vertex AI Workbench, utilizza il metodo
projects.locations.instances.patch
nell'API Notebooks o il comando
gcloud workbench instances update
in Google Cloud SDK
I pacchetti pip
non sono disponibili dopo l'aggiunta dell'ambiente conda
Problema
I pacchetti pip
non sono disponibili dopo l'aggiunta di un kernel basato su conda.
Soluzione:
Per risolvere il problema, consulta Aggiungere un ambiente conda e prova quanto segue:
Verifica di aver utilizzato la variabile
DL_ANACONDA_ENV_HOME
e che contenga il nome del tuo ambiente.Verifica che
pip
si trovi in un percorso simile aopt/conda/envs/ENVIRONMENT/bin/pip
. Puoi eseguire il comandowhich pip
per ottenere il percorso.
Impossibile accedere o copiare i dati di un'istanza con accesso a un solo utente
Problema
I dati di un'istanza con accesso a un solo utente non sono accessibili.
Per le istanze di Vertex AI Workbench configurate con accesso a un solo utente, solo il singolo utente specificato (il proprietario) può accedere ai dati dell'istanza.
Soluzione:
Per accedere o copiare i dati quando non sei il proprietario dell'istanza, apri una richiesta di assistenza.
Arresto imprevisto
Problema
L'istanza di Vertex AI Workbench si arresta in modo imprevisto.
Soluzione:
Se l'istanza si arresta in modo imprevisto, il motivo potrebbe essere che è stato avviato il riavvio in caso di inattività.
Se hai attivato l'arresto in caso di inattività, l'istanza si arresta quando non c'è attività del kernel per il periodo di tempo specificato. Ad esempio, l'esecuzione di una cella o la stampa di un nuovo output su un notebook è un'attività che reimposta il timer di spegnimento inattivo. L'utilizzo della CPU non reimposta il timer di spegnimento per inattività.
I log delle istanze mostrano errori di connessione o timeout
Problema
I log dell'istanza Vertex AI Workbench mostrano errori di connessione o timeout.
Soluzione:
Se noti errori di connessione o timeout nei log dell'istanza, assicurati che il server Jupyter sia in esecuzione sulla porta 8080. Segui i passaggi descritti nella sezione Verificare che l'API interna Jupyter sia attiva.
Se hai disattivato External IP
e utilizzi una rete VPC privata, assicurati di aver seguito anche la documentazione relativa alle opzioni di configurazione di rete.
Considera quanto segue:
Devi abilitare l'accesso privato Google nella subnet scelta nella stessa regione in cui si trova l'istanza nel progetto host VPC. Per ulteriori informazioni sulla configurazione di accesso privato Google, consulta la documentazione di Private Google Access.
Se utilizzi Cloud DNS, l'istanza deve essere in grado di risolvere i domini Cloud DNS richiesti specificati nella documentazione delle opzioni di configurazione di rete. Per verificare, segui i passaggi descritti nella sezione Verificare che l'istanza possa risolvere i domini DNS richiesti.
I log dell'istanza mostrano "Impossibile contattare l'API Jupyter" "ReadTimeoutError"
Problema
I log dell'istanza di Vertex AI Workbench mostrano un errore come:
notebooks_collection_agent. Unable to contact Jupyter API:
HTTPConnectionPool(host=\'127.0.0.1\', port=8080):
Max retries exceeded ReadTimeoutError(\"HTTPConnectionPool(host=\'127.0.0.1\', port=8080
Soluzione:
Segui i passaggi descritti nella
sezione I log dell'istanza mostrano errori di connessione o timeout.
Puoi anche provare a modificare lo script dell'agente di raccolta dei notebook per cambiare HTTP_TIMEOUT_SESSION
in un valore maggiore, ad esempio 60
, per verificare se la richiesta non è andata a buon fine perché la chiamata richiede troppo tempo per rispondere o perché non è possibile raggiungere l'URL richiesto.
Indirizzi docker0
in conflitto con l'indirizzamento VPC
Problema
Per impostazione predefinita, l'interfaccia docker0
viene creata con un indirizzo IP 172.17.0.1/16
. Ciò potrebbe entrare in conflitto con l'indirizzamento IP nella rete VPC, in modo che l'istanza non sia in grado di connettersi ad altri endpoint con indirizzi 172.17.0.1/16
.
Soluzione:
Puoi forzare la creazione dell'interfaccia docker0
con un indirizzo IP che non sia in conflitto con la tua rete VPC utilizzando il seguente script di post-avvio e impostando il comportamento dello script di post-avvio su run_once
.
#!/bin/bash # Wait for Docker to be fully started while ! systemctl is-active docker; do sleep 1 done # Stop the Docker service systemctl stop docker # Modify /etc/docker/daemon.json cat </etc/docker/daemon.json { "bip": "CUSTOM_DOCKER_IP/16" } EOF # Restart the Docker service systemctl start docker
Notebook gestiti
Questa sezione descrive la procedura per la risoluzione dei problemi relativi ai notebook gestiti.
Connessione e apertura di JupyterLab
Questa sezione descrive la risoluzione dei problemi di connessione e apertura di JupyterLab.
Non succede nulla dopo aver fatto clic su Apri JupyterLab
Problema
Quando fai clic su Apri JupyterLab, non succede nulla.
Soluzione:
Verifica che il browser non blocchi l'apertura automatica delle nuove schede. JupyterLab si apre in una nuova scheda del browser.
Impossibile connettersi all'istanza di notebook gestiti tramite SSH
Problema
Non è disponibile un'opzione per connettersi alle istanze di Notebooks gestite tramite SSH.
Soluzione:
L'accesso SSH alle istanze di notebook gestite non è disponibile.
Impossibile accedere al terminale in un'istanza di notebook gestiti
Problema
Se non riesci ad accedere al terminale o non riesci a trovare la finestra del terminale nel avviatore, è possibile che l'accesso al terminale non sia abilitato nell'istanza di Notebook gestiti.
Soluzione:
Devi creare una nuova istanza di Notebook gestiti con l'opzione Accesso al terminale attivata. Questa opzione non può essere modificata dopo la creazione dell'istanza.
Errore 502 durante l'apertura di JupyterLab
Problema
Un errore 502 potrebbe indicare che l'istanza di Notebook gestiti non è ancora pronta.
Soluzione:
Attendi qualche minuto, aggiorna la scheda del browser della console Google Cloud e riprova.
L'apertura di un notebook genera un errore 524 (si è verificato un timeout)
Problema
Un errore 524 indica in genere che l'agente del proxy invertente non si connette al server del proxy invertente o che le richieste richiedono troppo tempo sul lato server del backend (Jupyter). Le cause comuni di questo errore includono problemi di rete, l'agente proxy di inversione non è in esecuzione o il servizio Jupyter non è in esecuzione.
Soluzione:
Verifica che l'istanza di Notebook gestiti sia avviata.
Il notebook non risponde
Problema
l'istanza di Notebook gestiti non esegue celle o sembra essere bloccata.
Soluzione:
Per prima cosa, prova a riavviare il kernel facendo clic su Kernel nel menu in alto e poi su Riavvia kernel. Se non funziona, puoi provare quanto segue:
- Aggiorna la pagina del browser JupyterLab. L'output delle celle non salvato non viene mantenuto, quindi devi eseguire di nuovo queste celle per rigenerare l'output.
- Reimposta l'istanza.
Migrazione alle istanze Vertex AI Workbench
Questa sezione descrive i metodi per diagnosticare e risolvere i problemi relativi alla migrazione da un'istanza di notebook gestiti a un'istanza di Vertex AI Workbench.
Impossibile trovare un kernel presente nell'istanza di notebook gestiti
Problema
Un kernel che si trovava nell'istanza di blocchi note gestiti non viene visualizzato nell'istanza di Vertex AI Workbench a cui hai eseguito la migrazione.
I container personalizzati vengono visualizzati come kernel nei notebook gestiti. Lo strumento di migrazione di Vertex AI Workbench non supporta la migrazione dei contenitori personalizzati.
Soluzione:
Per risolvere il problema, aggiungi un ambiente conda alla tua istanza di Vertex AI Workbench.
Versione diversa del framework nell'istanza di cui è stata eseguita la migrazione
Problema
Un framework presente nell'istanza di notebook gestiti era di una versione diversa da quella nell'istanza di Vertex AI Workbench a cui hai eseguito la migrazione.
Le istanze Vertex AI Workbench forniscono un insieme predefinito di versioni del framework. Lo strumento di migrazione non aggiunge le versioni del framework dall'istanza di Notebook gestiti originale. Consulta i comportamenti predefiniti dello strumento di migrazione.
Soluzione:
Per aggiungere una versione specifica di un framework, aggiungi un ambiente conda alla tua istanza di Vertex AI Workbench.
La migrazione delle GPU alla nuova istanza di Vertex AI Workbench non è stata eseguita
Problema
Le GPU presenti nell'istanza di blocchi note gestiti non sono nell'istanza di Vertex AI Workbench a cui hai eseguito la migrazione.
Le istanze di Vertex AI Workbench supportano un insieme predefinito di GPU. Se le GPU nell'istanza di Notebook gestiti originale non sono disponibili, la migrazione dell'istanza viene eseguita senza GPU.
Soluzione:
Dopo la migrazione, puoi aggiungere GPU all'istanza di Vertex AI Workbench utilizzando il metodo projects.locations.instances.patch
nell'API Notebooks o il comando gcloud workbench instances update
nello SDK Google Cloud.
Il tipo di macchina dell'istanza di cui è stata eseguita la migrazione è diverso
Problema
Il tipo di macchina dell'istanza di notebook gestiti è diverso dall'istanza di Vertex AI Workbench a cui hai eseguito la migrazione.
Le istanze Vertex AI Workbench non supportano tutti i tipi di macchine. Se il tipo di macchina nell'istanza di notebook gestita originale non è disponibile, viene eseguita la migrazione dell'istanza al tipo di macchina e2-standard-4
.
Soluzione:
Dopo la migrazione, puoi modificare il tipo di macchina dell'istanza Vertex AI Workbench utilizzando il metodo projects.locations.instances.patch
nell'API Notebooks o il comando gcloud workbench instances update
in Google Cloud SDK.
La quota di GPU è stata superata
Problema
Non riesci a creare un'istanza di notebook gestiti con GPU.
Soluzione:
Determina il numero di GPU disponibili nel tuo progetto controllando la pagina Quote. Se le GPU non sono elencate nella pagina delle quote o se hai bisogno di una quota di GPU aggiuntiva, puoi richiedere un aumento della quota. Consulta Richiedere un limite di quota più alto.
Utilizzo delle immagini container
Questa sezione descrive la risoluzione dei problemi relativi all'utilizzo delle immagini dei contenitori.
L'immagine del contenitore non viene visualizzata come kernel in JupyterLab
Problema
Le immagini container che non dispongono di un kernelspec valido non vengono caricate correttamente come kernel in JupyterLab.
Soluzione:
Assicurati che il contenitore soddisfi i nostri requisiti. Per ulteriori informazioni, consulta i requisiti dei container personalizzati.
Il notebook si disconnette in caso di job di lunga durata
Problema
Se visualizzi il seguente messaggio di errore durante l'esecuzione di un job in un notebook, il motivo potrebbe essere che il caricamento della richiesta richiede troppo tempo o che l'utilizzo della CPU o della memoria è elevato, il che può rendere Jupyter Service non rispondente.
{"log":"2021/06/29 18:10:33 failure fetching a VM ID: compute: Received 500
`internal error`\n","stream":"stderr","time":"2021-06-29T18:10:33.383650241Z"}
{"log":"2021/06/29 18:38:26 Websocket failure: failed to read a websocket
message from the server: read tcp [::1]:40168-\u003e[::1]:8080: use of closed
network connection\n","stream":"stderr","time":"2021-06-29T18:38:26.057622824Z"}
Soluzione:
Questo problema è causato dall'esecuzione di un job a lunga esecuzione all'interno di un notebook. Per eseguire un job che potrebbe richiedere molto tempo, è consigliabile utilizzare l'executor.
Utilizzo dell'eseguitore
Questa sezione descrive la risoluzione dei problemi relativi all'utilizzo dell'executor.
Installazioni dei pacchetti non disponibili per l'eseguitore
Problema
L'executor esegue il codice del notebook in un ambiente separato dal kernel in cui esegui il codice del file del notebook. Per questo motivo, alcuni dei pacchetti che hai installato potrebbero non essere disponibili nell'ambiente dell'eseguibile.
Soluzione:
Per risolvere il problema, consulta Verificare che le installazioni dei pacchetti siano disponibili per l'eseguitore.
Errori 401 o 403 durante l'esecuzione del codice del notebook utilizzando l'executor
Problema
Un errore 401 o 403 quando esegui l'eseguibile può indicare che l'eseguibile non è in grado di accedere alle risorse.
Soluzione:
Di seguito sono riportate le possibili cause:
L'executor esegue il codice del notebook in un progetto tenant distinto da quello dell'istanza di notebook gestita. Pertanto, quando accedi alle risorse tramite il codice eseguito dall'eseguitore, l'eseguitore potrebbe non connettersi al progetto Google Cloud corretto per default. Per risolvere il problema, utilizza la selezione esplicita del progetto.
Per impostazione predefinita, l'istanza dei notebook gestiti può avere accesso alle risorse esistenti nello stesso progetto e, pertanto, quando esegui manualmente il codice del file del notebook, queste risorse non richiedono un'autenticazione aggiuntiva. Tuttavia, poiché l'executor viene eseguito in un progetto del tenant distinto, non ha lo stesso accesso predefinito. Per risolvere il problema, autentica l'accesso utilizzando gli account di servizio.
L'eseguitore non può utilizzare le credenziali dell'utente finale per autenticare l'accesso alle risorse, ad esempio il comando
gcloud auth login
. Per risolvere il problema, autentica l'accesso utilizzando gli account di servizio.
Errore exited with a non-zero status of 127
durante l'utilizzo dell'executor
Problema
Un errore exited with a non-zero status of 127
o un errore "comando non trovato" può verificarsi quando utilizzi l'eseguibile per eseguire codice in un contenitore personalizzato su cui non è installata l'estensione nbexecutor
.
Soluzione:
Per assicurarti che il tuo container personalizzato abbia l'estensione nbexecutor
, puoi
creare un'immagine container derivata da un'immagine di Deep Learning Containers.
Le immagini di Deep Learning Containers includono l'estensione nbexecutor
.
Messaggio di errore relativo alla configurazione della rete di servizi non valida
Problema
Questo errore potrebbe avere il seguente aspetto:
Invalid Service Networking configuration. Couldn't find free blocks in allocated IP ranges.
Please use a valid range using: /24 mask or below (/23,/22, etc).
Ciò significa che non sono stati trovati blocchi liberi negli intervalli IP allocati della tua rete.
Soluzione:
Utilizza una subnet mask pari o inferiore a /24
. Crea un intervallo di indirizzi IP allocato più grande e associalo modificando la connessione al servizio privato per servicenetworking-googleapis-com
.
Per ulteriori informazioni, vedi Configurare una rete.
Impossibile installare l'estensione JupyterLab di terze parti
Problema
Il tentativo di installare un'estensione JupyterLab di terze parti genera un messaggioError: 500
.
Soluzione:
Le estensioni JupyterLab di terze parti non sono supportate nelle istanze di blocchi note gestiti.
Impossibile accedere o copiare i dati di un'istanza con accesso a un solo utente
Problema
I dati di un'istanza con accesso a un solo utente non sono accessibili.
Soluzione:
Per le istanze di notebook gestiti configurate con accesso di un singolo utente, solo l'utente singolo specificato (il proprietario) può accedere ai dati dell'istanza.
Per accedere o copiare i dati quando non sei il proprietario dell'istanza, apri una richiesta di assistenza.
Arresto imprevisto
Problema
L'istanza di Vertex AI Workbench si arresta in modo imprevisto.
Soluzione:
Se l'istanza si arresta in modo imprevisto, il motivo potrebbe essere che è stato avviato il riavvio in caso di inattività.
Se hai attivato l'arresto in caso di inattività, l'istanza si arresta quando non c'è attività del kernel per il periodo di tempo specificato. Ad esempio, l'esecuzione di una cella o la stampa di un nuovo output su un notebook è un'attività che reimposta il timer di spegnimento inattivo. L'utilizzo della CPU non reimposta il timer di spegnimento per inattività.
Ripristina istanza
Problema
Il ripristino di un'istanza di Notebook gestiti dopo l'eliminazione non è supportato.
Soluzione:
Per eseguire il backup dei dati dell'istanza, puoi salvare i notebook su GitHub.
Recuperare i dati da un'istanza
Problema
Il recupero dei dati da un'istanza di Notebook gestiti dopo la sua eliminazione non è supportato.
Soluzione:
Per eseguire il backup dei dati dell'istanza, puoi salvare i notebook su GitHub.
Creazione di istanze di notebook gestiti
Questa sezione descrive la risoluzione dei problemi relativi alla creazione di istanze di notebook gestiti.
Errore: problema durante la creazione di una connessione
Problema
Si verifica questo errore durante la creazione di un'istanza:
We encountered a problem while creating a connection.
Service 'servicenetworking.googleapis.com' requires at least
one allocated range to have minimal size; please make sure
at least one allocated range will have prefix length at most '24'.
Soluzione:
Crea un intervallo IP allocato
più grande di /24
e collegalo modificando la connessione privata ai servizi
per la connessione servicenetworking-googleapis-com
.
La creazione di un'istanza genera un errore di disponibilità delle risorse
Problema
Non riesci a creare un'istanza a causa di un errore di disponibilità delle risorse.
Questo errore può avere il seguente aspetto:
Creating notebook INSTANCE_NAME: ZONE does not have enough resources available to fulfill the request. Retry later or try another zone in your configurations.
Gli errori delle risorse si verificano quando richiedi nuove risorse in una zona che non può soddisfare la tua richiesta a causa dell'attuale indisponibilità delle risorse di Compute Engine, ad esempio GPU o CPU.
Gli errori delle risorse si applicano solo alle nuove richieste di risorse nella zona e non influiscono sulle risorse esistenti. Gli errori relativi alle risorse non sono correlati alla quota di Compute Engine. Gli errori relativi alle risorse sono temporanei e possono cambiare di frequente in base alla domanda fluttuante.
Soluzione:
Per procedere, prova quanto segue:
- Crea un'istanza con un tipo di macchina diverso.
- Crea l'istanza in un'altra zona.
- Riprova a inviare la richiesta in un secondo momento.
- Riduci la quantità di risorse richieste. Ad esempio, prova a creare un'istanza con meno GPU, dischi, vCPU o memoria.
L'avvio di un'istanza comporta un errore di disponibilità delle risorse
Problema
Non riesci ad avviare un'istanza a causa di un errore di disponibilità delle risorse.
Questo errore può avere il seguente aspetto:
The zone ZONE_NAME doesn't have enough resources available to fulfill the request. '(resource type:compute)'.
Gli errori delle risorse si verificano quando provi ad avviare un'istanza in una zona che non può soddisfare la tua richiesta a causa dell'attuale indisponibilità delle risorse di Compute Engine, come GPU o CPU.
Gli errori delle risorse si applicano solo alle risorse specificate nella richiesta al momento dell'invio, non a tutte le risorse della zona. Gli errori relativi alle risorse non sono correlati alla quota di Compute Engine. Gli errori delle risorse sono temporanei e possono cambiare frequentemente in base alla domanda in evoluzione.
Soluzione:
Per procedere, prova quanto segue:
- Modifica il tipo di macchina dell'istanza.
- Esegui la migrazione dei file e dei dati a un'istanza in un'altra zona.
- Riprova a inviare la richiesta in un secondo momento.
- Riduci la quantità di risorse richieste. Ad esempio, avvia un'altra istanza con meno GPU, dischi, vCPU o memoria.
No route to host
sulle connessioni in uscita dai blocchi note gestiti
Problema
In genere, le uniche route che puoi vedere nella console Google Cloud sono quelle conosciute dal tuo VPC, nonché gli intervalli riservati al termine della configurazione del peering di rete VPC.
Le istanze di blocchi note gestiti si trovano in una rete gestita da Google e eseguono una versione modificata di Jupyter in uno spazio dei nomi di rete Docker all'interno dell'istanza.
L'interfaccia di rete Docker e il bridge Linux su questa istanza potrebbero selezionare un IP locale in conflitto con gli intervalli IP esportati tramite il peering dalla VPC. In genere, si trovano rispettivamente negli intervalli 172.16.0.0/161
e
192.168.10.0/24
.
In queste circostanze, le connessioni in uscita dall'istanza a questi intervalli non andranno a buon fine con un reclamo che è una variante di No route to host
, nonostante le route VPC siano condivise correttamente.
Soluzione:
Richiama ifconfig
in una sessione di terminale e assicurati che nessun indirizzo IP su alcuna
interfaccia virtuale dell'istanza entri in conflitto con gli intervalli IP che il
tuo VPC esporta nella connessione di peering.
Notebook gestiti dall'utente
Questa sezione descrive la procedura per la risoluzione dei problemi relativi ai notebook gestiti dall'utente.
Connessione e apertura di JupyterLab
Questa sezione descrive la risoluzione dei problemi di connessione e apertura di JupyterLab.
Non succede nulla dopo aver fatto clic su Apri JupyterLab
Problema
Quando fai clic su Apri JupyterLab, non succede nulla.
Soluzione:
Verifica che il browser non blocchi l'apertura automatica delle nuove schede. JupyterLab si apre in una nuova scheda del browser.
Nessun accesso del server proxy inverso a JupyterLab
Problema
Non riesci ad accedere a JupyterLab.
Vertex AI Workbench utilizza un server proxy inverso interno di Google per fornire accesso a JupyterLab. Le impostazioni dell'istanza di notebook gestita dall'utente, la configurazione di rete e altri fattori possono impedire l'accesso a JupyterLab.
Soluzione:
Impossibile connettersi all'istanza di notebook gestita dall'utente tramite SSH
Problema
Non riesci a connetterti all'istanza utilizzando SSH tramite una finestra del terminale.
Le istanze di notebook gestite dall'utente utilizzano OS Login per abilitare l'accesso SSH. Quando crei un'istanza, Vertex AI Workbench attiva l'accesso all'OS per impostazione predefinita impostando la chiave dei metadati enable-oslogin
su
TRUE
. Se non riesci a utilizzare SSH per connetterti all'istanza, potrebbe essere necessario impostare questa chiave dei metadati su TRUE
.
Soluzione:
Per attivare l'accesso SSH per i notebook gestiti dagli utenti, completa i passaggi per la configurazione dei ruoli OS Login negli account utente.
L'apertura di un'istanza di notebook gestiti dall'utente genera un errore 403 (Forbidden)
Problema
Un errore 403 (Forbidden)
durante l'apertura di un'istanza di Notebook gestita dall'utente spesso indica un problema di accesso.
Soluzione:
Per risolvere i problemi di accesso, tieni presente i tre modi in cui è possibile concedere l'accesso a un'istanza di notebook gestita dall'utente:
- Utente singolo
- Service account
- Editor progetto
La modalità di accesso viene configurata durante la creazione dell'istanza di notebook gestita dall'utente ed è definita nei metadati del notebook:
- Singolo utente:
proxy-mode=mail, proxy-user-mail=user@domain.com
- Service account:
proxy-mode=service_account
- Editor del progetto:
proxy-mode=project_editors
Se non riesci ad accedere a un blocco note quando fai clic su Apri JupyterLab, prova quanto segue:
Verifica che l'utente che accede all'istanza disponga dell'autorizzazione
iam.serviceAccounts.ActAs
per l'account di servizio dell'istanza. L'account di servizio è l'account di servizio predefinito di Compute Engine o un account di servizio specificato al momento della creazione dell'istanza.Se la tua istanza utilizza l'accesso a un singolo utente con un account di servizio specificato come utente singolo, consulta Nessun accesso a JupyterLab, modalità singolo utente attivata.
Il seguente esempio mostra come specificare un account di servizio quando crei un'istanza:
gcloud notebooks instances create nb-1 \ --vm-image-family=tf-latest-cpu \ --metadata=proxy-mode=mail,proxy-user-mail=user@domain.com \ --service-account=your_service_account@project_id.iam.gserviceaccount.com \ --location=us-west1-a
Quando fai clic su Apri JupyterLab per aprire un blocco note, il blocco note si apre in una nuova scheda del browser. Se hai eseguito l'accesso a più di un Account Google, la nuova scheda si apre con il tuo Account Google predefinito. Se non hai creato l'istanza dei notebook gestiti dall'utente con il tuo Account Google predefinito, nella nuova scheda del browser verrà visualizzato un errore 403 (Forbidden)
.
Nessun accesso a JupyterLab, modalità utente singolo abilitata
Problema
Non riesci ad accedere a JupyterLab.
Soluzione:
Se un utente non riesce ad accedere a JupyterLab e l'accesso dell'istanza a JupyterLab è impostato su Single user only
, prova a procedere nel seguente modo:
Nella pagina Blocchi note gestiti dall'utente della console Google Cloud, fai clic sul nome dell'istanza per aprire la pagina Dettagli del blocco note.
Accanto a Visualizza dettagli VM, fai clic su Visualizza in Compute Engine.
Nella pagina dei dettagli della VM, fai clic su Modifica.
Nella sezione Metadati, verifica che la voce dei metadati
proxy-mode
sia impostata sumail
.Verifica che la voce dei metadati
proxy-user-mail
sia impostata su un indirizzo email valido dell'utente, non su un account di servizio.Fai clic su Salva.
Nella pagina Blocchi note gestiti dall'utente della console Google Cloud, inizializza i metadati aggiornati fermando l'istanza e riavviandola.
L'apertura di un notebook genera un errore 504 (timeout del gateway)
Problema
Questo è un indicatore di un timeout del proxy interno o di un timeout del server di backend (Jupyter). Questo può accadere quando:
- La richiesta non ha mai raggiunto il server Inverting Proxy interno
- Il backend (Jupyter) restituisce un errore 504.
Soluzione:
Apri una richiesta di assistenza Google.
L'apertura di un notebook genera un errore 524 (si è verificato un timeout)
Problema
Il server proxy invertente interno non ha ricevuto una risposta dall'agente proxy invertente per la richiesta entro il periodo di timeout. L'agente Inverting Proxy viene eseguito all'interno dell'istanza di Notebook gestita dall'utente come contenitore Docker. Un errore 524 indica in genere che l'agente del proxy invertente non si connette al server del proxy invertente o che le richieste richiedono troppo tempo sul lato server di backend (Jupyter). Un caso tipico di questo errore si verifica sul lato utente (ad esempio, un problema di rete o il servizio dell'agente proxy di inversione non è in esecuzione).
Soluzione:
Se non riesci ad accedere a un notebook, verifica che l'istanza di notebook gestita dall'utente sia avviata e prova a procedere nel seguente modo:
Opzione 1: esegui lo strumento di diagnostica per controllare e riparare automaticamente i servizi di base dei notebook gestiti dagli utenti, verificare lo spazio di archiviazione disponibile e generare file di log utili. Per eseguire lo strumento nell'istanza, svolgi i seguenti passaggi:
Assicurati che l'istanza sia nella versione M58 o successiva.
Esegui questo comando:
sudo /opt/deeplearning/bin/diagnostic_tool.sh [--repair] [--bucket=$BUCKET]
Tieni presente che i flag
--repair
e--bucket
sono facoltativi. Il flag--repair
tenterà di correggere gli errori comuni del servizio di base, mentre il flag--bucket
ti consentirà di specificare un bucket Cloud Storage per archiviare i file di log creati.L'output di questo comando mostrerà messaggi di stato utili per i servizi principali dei notebook gestiti dall'utente ed esporterà i file di log dei risultati.
Opzione 2: segui i passaggi che seguono per verificare singolarmente i requisiti specifici dei notebook gestiti dall'utente.
Verifica che lo spazio del disco dell'istanza dei blocchi note gestiti dall'utente non sia esaurito.
Esegui questo comando:
df -h -T /home/jupyter
Se la percentuale di utilizzo è superiore a
85%
, devi eliminare manualmente i file da/home/jupyter
. Come primo passaggio, puoi svuotare il cestino con il seguente comando:sudo rm -rf /home/jupyter/.local/share/Trash/*
Verifica che l'agente Inverting Proxy sia in esecuzione. Se l'agente è avviato, prova a riavviarlo.
Assicurati che il servizio Jupyter sia in esecuzione. Se è così, prova a riavviare il dispositivo.
Verifica l'utilizzo della memoria nell'istanza di notebook gestiti dall'utente.
Esegui questo comando:
free -t -h
Se la memoria utilizzata è superiore a
85%
del totale, ti consigliamo di modificare il tipo di macchina.Puoi installare l'agente Cloud Monitoring per monitorare se l'utilizzo della memoria è elevato nell'istanza di Notebook gestita dall'utente. Consulta le informazioni sui prezzi.
Verifica di utilizzare la versione VM per il deep learning M55 o successive. Per scoprire di più sull'upgrade, consulta Eseguire l'upgrade dell'ambiente di un'istanza di blocchi note gestita dall'utente.
L'apertura di un notebook genera un errore 598 (timeout di lettura della rete)
Problema
Il server Inverting Proxy non ha ricevuto alcun messaggio dall'agente Inverting Proxy per più di 10 minuti. Questo è un chiaro indicatore di un problema con l'agente proxy di inversione.
Soluzione:
Se non riesci ad accedere a un blocco note, prova a procedere nel seguente modo:
Verifica che l'istanza di blocchi note gestiti dall'utente sia avviata.
Verifica che l'agente Inverting Proxy sia in esecuzione. Se l'agente è avviato, prova a riavviarlo.
Assicurati che il servizio Jupyter sia in esecuzione. Se è così, prova a riavviare il dispositivo.
Verifica di utilizzare la versione VM per il deep learning M55 o successive. Per scoprire di più sull'upgrade, consulta Eseguire l'upgrade dell'ambiente di un'istanza di blocchi note gestita dall'utente.
Il notebook non risponde
Problema
L'istanza di notebook gestita dall'utente non esegue celle o sembra essere bloccata.
Soluzione:
Per prima cosa, prova a riavviare il kernel facendo clic su Kernel nel menu in alto e poi su Riavvia kernel. Se non funziona, puoi provare quanto segue:
- Aggiorna la pagina del browser JupyterLab. Qualsiasi output di cella non salvato non viene mantenuto, quindi devi eseguire di nuovo queste celle per rigenerare l'output.
- Da una sessione del terminale nel notebook, esegui il comando
top
per verificare se esistono processi che consumano la CPU. - Dal terminale, controlla la quantità di spazio libero su disco utilizzando il comando
df
o la RAM disponibile utilizzando il comandofree
. - Arresta l'istanza selezionandola dalla pagina Blocchi note gestiti dall'utente e facendo clic su Interrompi. Dopo che si è fermato completamente, selezionalo e fai clic su Avvia.
Migrazione alle istanze Vertex AI Workbench
Questa sezione descrive i metodi per diagnosticare e risolvere i problemi relativi alla migrazione da un'istanza di notebook gestiti dall'utente a un'istanza di Vertex AI Workbench.
Impossibile trovare R, Beam o altri kernel che si trovavano nell'istanza di notebook gestita dall'utente
Problema
Un kernel che si trovava nell'istanza di notebook gestiti dall'utente non viene visualizzato nell'istanza di Vertex AI Workbench a cui hai eseguito la migrazione.
Alcuni kernel, come i kernel R e Beam, non sono disponibili per impostazione predefinita nelle istanze di Vertex AI Workbench. La migrazione di questi kernel non è supportata.
Soluzione:
Per risolvere il problema, aggiungi un ambiente conda alla tua istanza di Vertex AI Workbench.
Impossibile configurare un'istanza Dataproc Hub nell'istanza Vertex AI Workbench
Problema
Dataproc Hub non è supportato nelle istanze di Vertex AI Workbench.
Soluzione:
Continuare a utilizzare Dataproc Hub nelle istanze di blocchi note gestite dall'utente.
Versione diversa del framework nell'istanza di cui è stata eseguita la migrazione
Problema
Un framework presente nell'istanza di notebook gestiti dall'utente era di una versione diversa da quella dell'istanza di Vertex AI Workbench a cui hai eseguito la migrazione.
Le istanze Vertex AI Workbench forniscono un insieme predefinito di versioni del framework. Lo strumento di migrazione non aggiunge le versioni del framework dall'istanza di notebook gestita dall'utente originale. Consulta i comportamenti predefiniti dello strumento di migrazione.
Soluzione:
Per aggiungere una versione specifica di un framework, aggiungi un ambiente conda all'istanza di Vertex AI Workbench.
La migrazione delle GPU alla nuova istanza di Vertex AI Workbench non è stata eseguita
Problema
Le GPU che si trovavano nell'istanza di notebook gestiti dall'utente non sono presenti nell'istanza di Vertex AI Workbench a cui hai eseguito la migrazione.
Le istanze di Vertex AI Workbench supportano un insieme predefinito di GPU. Se le GPU nell'istanza di notebook gestita dall'utente originale non sono disponibili, la migrazione dell'istanza viene eseguita senza GPU.
Soluzione:
Dopo la migrazione, puoi aggiungere GPU all'istanza di Vertex AI Workbench utilizzando il metodo projects.locations.instances.patch
nell'API Notebooks o il comando gcloud workbench instances update
in Google Cloud SDK.
Il tipo di macchina dell'istanza di cui è stata eseguita la migrazione è diverso
Problema
Il tipo di macchina dell'istanza di notebook gestita dall'utente è diverso dall'istanza di Vertex AI Workbench a cui hai eseguito la migrazione.
Le istanze Vertex AI Workbench non supportano tutti i tipi di macchine.
Se il tipo di macchina nell'istanza di notebook gestita dall'utente originale non è disponibile, viene eseguita la migrazione dell'istanza al tipo di macchina e2-standard-4
.
Soluzione:
Dopo la migrazione, puoi modificare il tipo di macchina dell'istanza Vertex AI Workbench utilizzando il metodo projects.locations.instances.patch
nell'API Notebooks o il comando gcloud workbench instances update
in Google Cloud SDK.
Lavorare con i file
Questa sezione descrive la risoluzione dei problemi relativi ai file per le istanze dei blocchi note gestiti dall'utente.
Download dei file disattivato, ma l'utente può comunque scaricare file
Problema
Per le istanze di blocchi note gestite dall'utente di Dataproc Hub, la disattivazione del download dei file dall'interfaccia utente di JupyterLab non è supportata. Le istanze di notebook gestite dall'utente che utilizzano il framework Dataproc Hub consentono il download dei file anche se non selezioni Consenti il download di file dall'interfaccia utente di JupyterLab quando crei l'istanza.
Soluzione:
Le istanze di blocchi note gestite dall'utente di Dataproc Hub non supportano la limitazione dei download dei file.
I file scaricati vengono troncati o il download non viene completato
Problema
Quando scarichi file dall'istanza di Notebook gestita dall'utente, un'impostazione di timeout sull'agente di inoltro proxy limita il tempo di connessione per il completamento del download. Se il download richiede troppo tempo, il file scaricato potrebbe essere troncato o potrebbe non essere scaricato.
Soluzione:
Per scaricare il file, copialo su Cloud Storage, quindi scaricalo da Cloud Storage.
Valuta la possibilità di eseguire la migrazione dei tuoi file e dati a una nuova istanza di notebook gestiti dagli utenti.
Dopo il riavvio della VM, non è possibile fare riferimento ai file locali dal terminale del notebook
Problema
A volte, dopo il riavvio di un'istanza di Notebook gestita dall'utente, non è possibile fare riferimento ai file locali da un terminale del notebook.
Soluzione:
Si tratta di un problema noto. Per fare riferimento ai file locali da un terminale del notebook, reimposta prima la directory di lavoro corrente utilizzando il seguente comando:
cd PWD
In questo comando, sostituisci PWD con la tua directory di lavoro corrente. Ad esempio, se la tua directory di lavoro attuale fosse
/home/jupyter/
, utilizza il comando cd /home/jupyter/
.
Dopo aver ristabilito la directory di lavoro corrente, puoi fare riferimento ai file locali dal terminale del notebook.
Creazione di istanze di notebook gestiti dall'utente
Questa sezione descrive la risoluzione dei problemi relativi alla creazione di istanze di blocchi note gestiti dall'utente.
La quota di GPU è stata superata
Problema
Non riesci a creare un'istanza di Notebooks gestita dall'utente con GPU.
Soluzione:
Determina il numero di GPU disponibili nel tuo progetto controllando la pagina Quote. Se le GPU non sono elencate nella pagina delle quote o se hai bisogno di una quota di GPU aggiuntiva, puoi richiedere un aumento della quota. Consulta Richiedere un limite di quota più alto.
L'istanza rimane in stato di attesa a tempo indeterminato
Problema
Dopo aver creato un'istanza di blocchi note gestiti dall'utente, questa rimane nello stato in attesa a tempo indeterminato. Nei log di serie potrebbe essere visualizzato un errore simile al seguente:
Could not resolve host: notebooks.googleapis.com
Soluzione:
L'istanza non riesce a connettersi al server dell'API Notebooks a causa di una configurazione Cloud DNS o di un altro problema di rete. Per risolvere il problema, controlla le configurazioni di Cloud DNS e di rete. Per ulteriori informazioni, consulta la sezione sulle opzioni di configurazione di rete.
La nuova istanza di notebook gestiti dall'utente non viene creata (autorizzazioni insufficienti)
Problema
In genere sono necessari circa un minuto per creare un'istanza di blocchi note gestiti dall'utente. Se la nuova istanza di notebook gestita dall'utente rimane nello stato pending
a tempo indeterminato, è possibile che l'account di servizio utilizzato per avviarla non disponga delle autorizzazioni richieste nel progetto. Google Cloud
Puoi avviare un'istanza di Notebooks gestita dall'utente con un account di servizio personalizzato creato da te o in modalità utente singolo con un ID utente. Se avvii un'istanza di notebook gestita dall'utente in modalità monoutente, l'istanza inizia la procedura di avvio utilizzando l'account di servizio predefinito di Compute Engine prima di trasferire il controllo al tuo ID utente.
Soluzione:
Per verificare che un account di servizio disponga delle autorizzazioni appropriate:
Console
Apri la pagina IAM nella console Google Cloud.
Determina l'account di servizio utilizzato con l'istanza di Notebook gestita dall'utente, che è uno dei seguenti:
Un account di servizio personalizzato specificato quando hai creato la tua istanza di blocchi note gestita dall'utente.
L'account di servizio predefinito di Compute Engine per il tuo progettoGoogle Cloud , che viene utilizzato quando avvii l'istanza di Notebook gestita dall'utente in modalità monoutente. L'account di servizio Compute Engine predefinito per il tuo Google Cloud progetto è denominato
PROJECT_NUMBER-compute@developer.gserviceaccount.com
. Ad esempio:113377992299-compute@developer.gserviceaccount.com
.
Verifica che il tuo account di servizio abbia il ruolo Notebooks Runner (
roles/notebooks.runner
). In caso contrario, concedi all'account di servizio il ruolo Notebooks Runner (roles/notebooks.runner
).
Per ulteriori informazioni, consulta Concessione, modifica e revoca dell'accesso alle risorse nella documentazione di IAM.
gcloud
Se non lo hai ancora fatto, installa Google Cloud CLI.
Recupera il nome e il numero del progetto Google Cloud con il seguente comando. Sostituisci PROJECT_ID con l'ID progetto del tuo progettoGoogle Cloud .
gcloud projects describe PROJECT_ID
Dovresti visualizzare un output simile al seguente, che mostra il nome (
name:
) e il numero (projectNumber:
) del progetto.createTime: '2018-10-18T21:03:31.408Z' lifecycleState: ACTIVE name: my-project-name parent: id: '396521612403' type: folder projectId: my-project-id-1234 projectNumber: '113377992299'
Determina l'account di servizio utilizzato con la tua istanza di notebook gestita dall'utente, che è uno dei seguenti:
Un account di servizio personalizzato specificato quando hai creato la tua istanza di blocchi note gestita dall'utente.
L'account di servizio predefinito di Compute Engine per il tuo Google Cloud progetto, che viene utilizzato quando avvii la tua istanza di notebook gestita dall'utente in modalità monoutente. L'account di servizio Compute Engine predefinito per il tuo Google Cloud progetto è denominato
PROJECT_NUMBER-compute@developer.gserviceaccount.com
. Ad esempio:113377992299-compute@developer.gserviceaccount.com
.
Aggiungi il ruolo
roles/notebooks.runner
all'account di servizio con il seguente comando. Sostituisci project-name con il nome del tuo progetto e service-account-id con l'ID account di servizio per la tua istanza di notebook gestita dall'utente.gcloud projects add-iam-policy-binding project-name \ --member serviceAccount:service-account-id \ --role roles/notebooks.runner
La creazione di un'istanza genera un errore Permission denied
Problema
L'account di servizio nell'istanza fornisce l'accesso ad altri Google Cloud
servizi. Puoi utilizzare qualsiasi account di servizio all'interno dello stesso progetto, ma devi avere l'autorizzazione Utente account di servizio (iam.serviceAccounts.actAs
) per creare l'istanza. Se non specificato, viene utilizzato l'account di servizio predefinito di Compute Engine.
Soluzione:
Quando crei un'istanza, verifica che l'utente che la crea disponga dell'autorizzazione
iam.serviceAccounts.ActAs
per l'account di servizio definito.
Il seguente esempio mostra come specificare un account di servizio quando crei un'istanza:
gcloud notebooks instances create nb-1 \ --vm-image-family=tf-latest-cpu \ --service-account=your_service_account@project_id.iam.gserviceaccount.com \ --location=us-west1-a
Per concedere il ruolo Utente account di servizio, consulta Gestire l'accesso agli account di servizio.
La creazione di un'istanza genera un errore already exists
Problema
Quando crei un'istanza, verifica che un'istanza di notebook gestita dall'utente con lo stesso nome non sia stata eliminata in precedenza da Compute Engine e che esista ancora nel database dell'API Notebooks.
Soluzione:
L'esempio seguente mostra come elencare le istanze utilizzando l'API Notebooks e verificarne lo stato.
gcloud notebooks instances list --location=LOCATION
Se lo stato di un'istanza è DELETED
, esegui il seguente comando per eliminarla definitivamente.
gcloud notebooks instances delete INSTANCE_NAME --location=LOCATION
Impossibile creare un'istanza in una VPC condiviso
Problema
Non riesci a creare un'istanza in un VPC condiviso.
Soluzione:
Se utilizzi VPC condivisa, devi aggiungere il progetto host e i progetti di servizio al perimetro di servizio. Nel progetto host, devi anche concedere il ruolo Utente di rete Compute
(roles/compute.networkUser
) all'agente di servizio Notebooks
dal progetto di servizio. Per saperne di più, consulta Gestire i perimetri di servizio.
La creazione di un'istanza genera un errore di disponibilità delle risorse
Problema
Non riesci a creare un'istanza a causa di un errore di disponibilità delle risorse.
Questo errore può avere il seguente aspetto:
Creating notebook INSTANCE_NAME: ZONE does not have enough resources available to fulfill the request. Retry later or try another zone in your configurations.
Gli errori delle risorse si verificano quando richiedi nuove risorse in una zona che non può soddisfare la tua richiesta a causa dell'attuale indisponibilità delle risorse di Compute Engine, ad esempio GPU o CPU.
Gli errori delle risorse si applicano solo alle nuove richieste di risorse nella zona e non influiscono sulle risorse esistenti. Gli errori relativi alle risorse non sono correlati alla quota di Compute Engine. Gli errori relativi alle risorse sono temporanei e possono cambiare di frequente in base alla domanda fluttuante.
Soluzione:
Per procedere, puoi provare quanto segue:
- Crea un'istanza con un tipo di macchina diverso.
- Crea l'istanza in un'altra zona.
- Riprova a inviare la richiesta in un secondo momento.
- Riduci la quantità di risorse richieste. Ad esempio, prova a creare un'istanza con meno GPU, dischi, vCPU o memoria.
L'avvio di un'istanza comporta un errore di disponibilità delle risorse
Problema
Non riesci ad avviare un'istanza a causa di un errore di disponibilità delle risorse.
Questo errore può avere il seguente aspetto:
The zone ZONE_NAME doesn't have enough resources available to fulfill the request. '(resource type:compute)'.
Gli errori delle risorse si verificano quando provi ad avviare un'istanza in una zona che non può soddisfare la tua richiesta a causa dell'attuale indisponibilità delle risorse di Compute Engine, come GPU o CPU.
Gli errori delle risorse si applicano solo alle risorse specificate nella richiesta al momento dell'invio, non a tutte le risorse della zona. Gli errori relativi alle risorse non sono correlati alla quota di Compute Engine. Gli errori delle risorse sono temporanei e possono cambiare frequentemente in base alla domanda in evoluzione.
Soluzione:
Per procedere, puoi provare quanto segue:
- Modifica il tipo di macchina dell'istanza.
- Esegui la migrazione dei file e dei dati a un'istanza in un'altra zona.
- Riprova a inviare la richiesta in un secondo momento.
- Riduci la quantità di risorse richieste. Ad esempio, avvia un'altra istanza con meno GPU, dischi, vCPU o memoria.
Upgrade delle istanze di blocchi note gestiti dall'utente
Questa sezione descrive la risoluzione dei problemi relativi all'upgrade delle istanze di blocchi note gestiti dall'utente.
Impossibile eseguire l'upgrade perché non è possibile ottenere le informazioni sul disco dell'istanza
Problema
L'upgrade non è supportato per le istanze di blocchi note gestite dall'utente con un solo disco.
Soluzione:
Ti consigliamo di eseguire la migrazione dei dati utente a una nuova istanza di notebook gestita dall'utente.
Impossibile eseguire l'upgrade perché l'istanza non è compatibile con UEFI
Problema
Vertex AI Workbench dipende dalla compatibilità con UEFI per completare un upgrade.
Le istanze di notebook gestite dall'utente create da alcune immagini meno recenti non sono compatibili con UEFI e, pertanto, non è possibile eseguirne l'upgrade.
Soluzione:
Per verificare che l'istanza sia compatibile con UEFI, digita il seguente comando in Cloud Shell o in qualsiasi ambiente in cui è installato Google Cloud CLI.
gcloud compute instances describe INSTANCE_NAME \ --zone=ZONE | grep type
Sostituisci quanto segue:
INSTANCE_NAME
: il nome dell'istanzaZONE
: la zona in cui si trova l'istanza
Per verificare che l'immagine utilizzata per creare l'istanza sia compatibile con UEFI, utilizza il seguente comando:
gcloud compute images describe VM_IMAGE_FAMILY \ --project deeplearning-platform-release | grep type
Sostituisci VM_IMAGE_FAMILY
con il nome della famiglia di immagini che hai utilizzato per creare l'istanza.
Se stabilisci che l'istanza o l'immagine non è compatibile con UEFI, puoi tentare di eseguire la migrazione dei dati utente a una nuova istanza di Jupyter gestita dall'utente. Per farlo, segui questa procedura.
Verifica che l'immagine che vuoi utilizzare per creare la nuova istanza sia compatibile con UEFI. A tale scopo, digita il seguente comando in Cloud Shell o in qualsiasi ambiente in cui è installato Google Cloud CLI.
gcloud compute images describe VM_IMAGE_FAMILY \ --project deeplearning-platform-release --format=json | grep type
Sostituisci
VM_IMAGE_FAMILY
con il nome della famiglia di immagini che vuoi utilizzare per creare l'istanza.Esegui la migrazione dei dati utente a una nuova istanza di notebook gestiti dall'utente.
L'istanza di notebook gestita dall'utente non è accessibile dopo l'upgrade
Problema
Se l'istanza dei notebook gestita dall'utente non è accessibile dopo un upgrade, potrebbe essere stato riscontrato un errore durante la sostituzione dell'immagine del disco di avvio.
Le istanze di notebook gestite dall'utente di cui è possibile eseguire l'upgrade sono con doppio disco, con un disco di avvio e un disco di dati. Il processo di upgrade esegue l'upgrade del disco di avvio a una nuova immagine, conservando i dati sul disco di dati.
Soluzione:
Completa i seguenti passaggi per collegare una nuova immagine valida al disco di avvio.
Per memorizzare i valori che utilizzerai per completare questa procedura, digita il seguente comando in Cloud Shell o in qualsiasi ambiente in cui è installato Google Cloud CLI.
export INSTANCE_NAME=MY_INSTANCE_NAME export PROJECT_ID=MY_PROJECT_ID export ZONE=MY_ZONE
Sostituisci quanto segue:
MY_INSTANCE_NAME
: il nome dell'istanzaMY_PROJECT_ID
: il tuo ID progettoMY_ZONE
: la zona in cui si trova l'istanza
Utilizza il seguente comando per arrestare l'istanza:
gcloud compute instances stop $INSTANCE_NAME \ --project=$PROJECT_ID --zone=$ZONE
Scollega il disco di dati dall'istanza.
gcloud compute instances detach-disk $INSTANCE_NAME --device-name=data \ --project=$PROJECT_ID --zone=$ZONE
Elimina la VM dell'istanza.
gcloud compute instances delete $INSTANCE_NAME --keep-disks=all --quiet \ --project=$PROJECT_ID --zone=$ZONE
Utilizza l'API Notebooks per eliminare l'istanza di blocchi note gestiti dall'utente.
gcloud notebooks instances delete $INSTANCE_NAME \ --project=$PROJECT_ID --location=$ZONE
Crea un'istanza di blocchi note gestiti dall'utente utilizzando lo stesso nome dell'istanza precedente.
gcloud notebooks instances create $INSTANCE_NAME \ --vm-image-project="deeplearning-platform-release" \ --vm-image-family=MY_VM_IMAGE_FAMILY \ --instance-owners=MY_INSTANCE_OWNER \ --machine-type=MY_MACHINE_TYPE \ --service-account=MY_SERVICE_ACCOUNT \ --accelerator-type=MY_ACCELERATOR_TYPE \ --accelerator-core-count=MY_ACCELERATOR_CORE_COUNT \ --install-gpu-driver \ --project=$PROJECT_ID \ --location=$ZONE
Sostituisci quanto segue:
MY_VM_IMAGE_FAMILY
: il nome della famiglia di immaginiMY_INSTANCE_OWNER
: il proprietario dell'istanzaMY_MACHINE_TYPE
: il tipo di macchina della VM della tua istanzaMY_SERVICE_ACCOUNT
: l'account di servizio da utilizzare con questa istanza oppure"default"
MY_ACCELERATOR_TYPE
: il tipo di acceleratore; ad esempio,"NVIDIA_TESLA_T4"
MY_ACCELERATOR_CORE_COUNT
: il numero di core; ad esempio,1
Monitoraggio dello stato di integrità delle istanze di blocchi note gestite dall'utente
Questa sezione descrive come risolvere i problemi relativi al monitoraggio degli errori dello stato di salute.
Errore di stato docker-proxy-agent
Segui questi passaggi dopo un errore di stato docker-proxy-agent
:
Verifica che l'agente Inverting Proxy sia in esecuzione. In caso contrario, vai al passaggio 3.
Esegui nuovamente la registrazione con il server Inverting Proxy.
Errore di stato docker-service
Segui questi passaggi dopo un errore di stato docker-service
:
Errore di stato jupyter-service
Segui questi passaggi dopo un errore di stato jupyter-service
:
Errore di stato jupyter-api
Segui questi passaggi dopo un errore di stato jupyter-api
:
Percentuale di utilizzo del disco di avvio
Lo stato dello spazio sul disco di avvio non è integro se lo spazio su disco occupato è maggiore dell'85%.
Se lo stato dello spazio sul disco di avvio non è integro, prova a procedere nel seguente modo:
Da una sessione del terminale nell'istanza di notebook gestita dall'utente o utilizzando SSH per la connessione, controlla la quantità di spazio libero su disco utilizzando il comando
df -H
.Utilizza il comando
find . -type d -size +100M
per trovare i file di grandi dimensioni che potresti essere in grado di eliminare, ma non eliminarli a meno che non sia certo che puoi farlo in sicurezza. In caso di dubbi, puoi richiedere assistenza all'assistenza.Se i passaggi precedenti non risolvono il problema, richiedi assistenza.
Percentuale di utilizzo del disco dati
Lo stato dello spazio sul disco dati non è integro se lo spazio su disco occupato è maggiore dell'85%.
Se lo stato dello spazio sul disco dati non è integro, prova a procedere nel seguente modo:
Da una sessione del terminale nell'istanza di notebook gestita dall'utente o utilizzando SSH per la connessione, controlla la quantità di spazio libero su disco utilizzando il comando
df -h -T /home/jupyter
.Elimina i file di grandi dimensioni per aumentare lo spazio disponibile su disco. Utilizza il comando
find . -type d -size +100M
per trovare i file di grandi dimensioni.Se i passaggi precedenti non risolvono il problema, richiedi assistenza.
Impossibile installare l'estensione JupyterLab di terze parti
Problema
Il tentativo di installare un'estensione JupyterLab di terze parti genera un messaggioError: 500
.
Soluzione:
Le estensioni JupyterLab di terze parti non sono supportate nelle istanze di blocchi note gestite dall'utente.
Ripristina istanza
Problema
Il ripristino di un'istanza di Notebook gestita dall'utente dopo l'eliminazione non è supportato.
Soluzione:
Per eseguire il backup dei dati dell'istanza, puoi salvare i blocchi note su GitHub o creare uno snapshot del disco.
Recuperare i dati da un'istanza
Problema
Il recupero dei dati da un'istanza di Notebook gestita dall'utente dopo l'eliminazione non è supportato.
Soluzione:
Per eseguire il backup dei dati dell'istanza, puoi salvare i blocchi note su GitHub o creare uno snapshot del disco
Impossibile aumentare la memoria condivisa
Problema
Non puoi aumentare la memoria condivisa su un'istanza di Notebooks gestita dall'utente esistente.
Soluzione:
Tuttavia, puoi specificare una dimensione della memoria condivisa quando crei un'istanza di notebook gestita dall'utente utilizzando la chiave di metadati container-custom-params
, con un valore come il seguente:
--shm-size=SHARED_MEMORY_SIZE gb
Sostituisci SHARED_MEMORY_SIZE
con la dimensione che preferisci in GB.
Procedure utili
Questa sezione descrive procedure che potresti trovare utili.
Utilizza SSH per connetterti all'istanza di Notebook gestita dall'utente
Utilizza ssh per connetterti all'istanza digitando il seguente comando in Cloud Shell o in qualsiasi ambiente in cui è installato Google Cloud CLI.
gcloud compute ssh --project PROJECT_ID \
--zone ZONE \
INSTANCE_NAME -- -L 8080:localhost:8080
Sostituisci quanto segue:
PROJECT_ID
: il tuo ID progettoZONE
: la Google Cloud zona in cui si trova la tua istanzaINSTANCE_NAME
: il nome dell'istanza
Puoi anche connetterti all'istanza aprendo la pagina dei dettagli di Compute Engine dell'istanza e facendo clic sul pulsante SSH.
Esegui nuovamente la registrazione con il server Inverting Proxy
Per registrare di nuovo l'istanza dei blocchi note gestiti dall'utente con il server proxy di inversione interno, puoi arrestare e avviare la VM dalla pagina Blocchi note gestiti dall'utente oppure puoi utilizzare SSH per connetterti all'istanza dei blocchi note gestiti dall'utente e inserire:
cd /opt/deeplearning/bin sudo ./attempt-register-vm-on-proxy.sh
Verifica lo stato del servizio Docker
Per verificare lo stato del servizio Docker, puoi utilizzare SSH per connetterti all'istanza di Notebook gestita dall'utente e inserire:
sudo service docker status
Verifica che l'agente Inverting Proxy sia in esecuzione
Per verificare se l'agente Inverting Proxy del notebook è in esecuzione, utilizza SSH per connetterti all'istanza di notebook gestita dall'utente e inserisci:
# Confirm Inverting Proxy agent Docker container is running (proxy-agent) sudo docker ps # Verify State.Status is running and State.Running is true. sudo docker inspect proxy-agent # Grab logs sudo docker logs proxy-agent
Verifica lo stato del servizio Jupyter e raccogli i log
Per verificare lo stato del servizio Jupyter, puoi utilizzare SSH per collegarti all'istanza di blocchi note gestiti dall'utente e inserire:
sudo service jupyter status
Per raccogliere i log del servizio Jupyter:
sudo journalctl -u jupyter.service --no-pager
Verificare che l'API interna Jupyter sia attiva
L'API Jupyter deve sempre essere eseguita sulla porta 8080. Puoi verificarlo esaminando i log syslog dell'istanza per trovare una voce simile alla seguente:
Jupyter Server ... running at: http://localhost:8080
Per verificare che l'API interna Jupyter sia attiva, puoi anche utilizzare SSH per connetterti all'istanza di notebook gestita dall'utente e inserire:
curl http://127.0.0.1:8080/api/kernelspecs
Puoi anche misurare il tempo necessario all'API per rispondere nel caso in cui le richieste impieghino troppo tempo:
time curl -V http://127.0.0.1:8080/api/status
time curl -V http://127.0.0.1:8080/api/kernels
time curl -V http://127.0.0.1:8080/api/connections
Per eseguire questi comandi nell'istanza Vertex AI Workbench, apri JupyterLab e crea un nuovo terminale.
Riavvia il servizio Docker
Per riavviare il servizio Docker, puoi arrestare e avviare la VM dalla pagina Notebook gestiti dall'utente oppure puoi utilizzare SSH per connetterti alla tua istanza di Notebook gestiti dall'utente e inserire:
sudo service docker restart
Riavvia l'agente Inverting Proxy
Per riavviare l'agente proxy invertente, puoi arrestare e avviare la VM dalla pagina dei notebook gestiti dall'utente oppure puoi utilizzare SSH per connetterti all'istanza dei notebook gestiti dall'utente e inserire:
sudo docker restart proxy-agent
Riavvia il servizio Jupyter
Per riavviare il servizio Jupyter, puoi arrestare e avviare la VM dalla pagina Blocchi note gestiti dall'utente oppure puoi utilizzare SSH per connetterti alla tua istanza di blocchi note gestiti dall'utente e inserire:
sudo service jupyter restart
Riavviare l'agente di raccolta di Notebooks
Il servizio Notebooks Collection Agent esegue un processo Python in background che verifica lo stato dei servizi principali dell'istanza Vertex AI Workbench.
Per riavviare il servizio Notebooks Collection Agent, puoi arrestare e avviare la VM dalla console Google Cloud oppure puoi utilizzare SSH per connetterti alla tua istanza Vertex AI Workbench e inserire:
sudo systemctl stop notebooks-collection-agent.service
seguita da:
sudo systemctl start notebooks-collection-agent.service
Per eseguire questi comandi nell'istanza Vertex AI Workbench, apri JupyterLab e crea un nuovo terminale.
Modificare lo script dell'agente di raccolta dei notebook
Per accedere e modificare lo script, apri un terminale nella nostra istanza o utilizza ssh per connetterti all'istanza Vertex AI Workbench e inserisci:
nano /opt/deeplearning/bin/notebooks_collection_agent.py
Dopo aver modificato il file, ricordati di salvarlo.
Poi devi riavviare il servizio Notebooks Collection Agent.
Verifica che l'istanza possa risolvere i domini DNS richiesti
Per verificare che l'istanza possa risolvere i domini DNS richiesti, puoi utilizzare SSH per connetterti all'istanza di Notebook gestita dall'utente e inserire:
host notebooks.googleapis.com
host *.notebooks.cloud.google.com
host *.notebooks.googleusercontent.com
host *.kernels.googleusercontent.com
oppure:
curl --silent --output /dev/null "https://notebooks.cloud.google.com"; echo $?
Se l'istanza ha Dataproc abilitato, puoi verificare che risolva *.kernels.googleusercontent.com
eseguendo:
curl --verbose -H "Authorization: Bearer $(gcloud auth print-access-token)" https://${PROJECT_NUMBER}-dot-${REGION}.kernels.googleusercontent.com/api/kernelspecs | jq .
Per eseguire questi comandi nell'istanza Vertex AI Workbench, apri JupyterLab e crea un nuovo terminale.
Crea una copia dei dati utente in un'istanza
Per archiviare una copia dei dati utente di un'istanza in Cloud Storage, completa i seguenti passaggi.
(Facoltativo) Crea un bucket Cloud Storage
Nello stesso progetto in cui si trova l'istanza, crea un bucket Cloud Storage in cui archiviare i dati utente. Se hai già un bucket Cloud Storage, salta questo passaggio.
-
Create a Cloud Storage bucket:
Replacegcloud storage buckets create gs://BUCKET_NAME
BUCKET_NAME
with a bucket name that meets the bucket naming requirements.
Copiare i dati utente
Nell'interfaccia JupyterLab della tua istanza, seleziona File > Nuovo > Terminale per aprire una finestra del terminale. Per le istanze di notebook gestite dall'utente, puoi invece connetterti al terminale dell'istanza utilizzando SSH.
Utilizza la CLI gcloud per copiare i dati utente in un bucket Cloud Storage. Il seguente comando di esempio copia tutti i file dalla directory
/home/jupyter/
dell'istanza in una directory di un bucket Cloud Storage.gcloud storage cp /home/jupyter/* gs://BUCKET_NAMEPATH --recursive
Sostituisci quanto segue:
BUCKET_NAME
: il nome del tuo bucket Cloud StoragePATH
: il percorso della directory куда vuoi copiare i file, ad esempio:/copy/jupyter/
Esaminare un'istanza bloccata nel provisioning utilizzando gcpdiag
gcpdiag
è uno strumento open source. Non è un prodotto Google Cloud supportato ufficialmente.
Puoi utilizzare lo strumento gcpdiag
per identificare e risolvere i problemi Google Cloud
del progetto. Per maggiori informazioni, consulta il progetto gcpdiag su GitHub.
gcpdiag
esamina le potenziali cause per cui un'istanza di Vertex AI Workbench si blocca nello stato di provisioning, tra cui le seguenti aree:
- Stato: controlla lo stato corrente dell'istanza per verificare che non sia bloccata nel provisioning e non sia interrotta o attiva.
- Immagine del disco di avvio della VM Compute Engine dell'istanza:
controlla se l'istanza è stata creata con un contenitore personalizzato, un'immagine
workbench-instances
ufficiale, immagini VM di deep learning o immagini non supportate che potrebbero causare il blocco dell'istanza nello stato di provisioning. - Script personalizzati: verifica se l'istanza utilizza script di avvio o post-avvio personalizzati che modificano la porta Jupyter predefinita o interrompono le dipendenze che potrebbero causare l'arresto dell'istanza nello stato di provisioning.
- Versione ambiente: verifica se l'istanza utilizza la versione più recente dell'ambiente controllandone l'upgradeabilità. Le versioni precedenti potrebbero causare il blocco dello stato di provisioning dell'istanza.
- Prestazioni della VM Compute Engine dell'istanza: controlla le prestazioni attuali della VM per assicurarsi che non siano compromesse da un elevato utilizzo della CPU, da una memoria insufficiente o da problemi di spazio su disco che potrebbero interrompere le normali operazioni.
- Log di sistema o della porta seriale Compute Engine dell'istanza: controlla se l'istanza ha log della porta seriale, che vengono analizzati per verificare che Jupyter sia in esecuzione sulla porta
127.0.0.1:8080
. - Accesso SSH e al terminale di Compute Engine dell'istanza: verifica se la VM Compute Engine dell'istanza è in esecuzione in modo che l'utente possa accedere tramite SSH e aprire un terminale per verificare che l'utilizzo dello spazio in "home/jupyter" sia inferiore all'85%. Se non è rimasto spazio, l'istanza potrebbe rimanere bloccata nello stato di provisioning.
- IP esterno disattivato: controlla se l'accesso all'IP esterno è disattivato. Una configurazione di rete errata può causare il blocco dello stato del provisioning dell'istanza.
Console Google Cloud
- Completa e poi copia il seguente comando.
- Apri la console Google Cloud e attiva Cloud Shell. Apri Cloud Console
- Incolla il comando copiato.
- Esegui il comando
gcpdiag
, che scarica l'immagine Dockergcpdiag
, quindi esegui i controlli diagnostici. Se applicabile, segui le istruzioni di output per correggere i controlli non riusciti.
gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
--parameter project_id=PROJECT_ID \
--parameter instance_name=INSTANCE_NAME \
--parameter zone=ZONE
Docker
Puoi
eseguire gcpdiag
utilizzando un wrapper che avvia gcpdiag
in un
container Docker. È necessario installare Docker o Podman.
- Copia ed esegui il seguente comando sulla tua workstation locale.
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
- Esegui il comando
gcpdiag
../gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \ --parameter project_id=PROJECT_ID \ --parameter instance_name=INSTANCE_NAME \ --parameter zone=ZONE
Visualizza i parametri disponibili per questo runbook.
Sostituisci quanto segue:
- PROJECT_ID: l'ID del progetto contenente la risorsa.
- INSTANCE_NAME: il nome dell'istanza di Vertex AI Workbench di destinazione nel progetto.
- ZONE: la zona in cui si trova l'istanza di Vertex AI Workbench di destinazione.
Flag utili:
--universe-domain
: se applicabile, il dominio Trusted Partner Sovereign Cloud che ospita la risorsa--parameter
o-p
: parametri del runbook
Per un elenco e una descrizione di tutti i flag dello strumento gcpdiag
, consulta le istruzioni per l'utilizzo di gcpdiag
.