Risoluzione dei problemi di Vertex AI Workbench

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 nell'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 di 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 launcher, è possibile che l'accesso al terminale non sia abilitato nell'istanza di 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 all'apertura di JupyterLab

Problema

Un errore 502 potrebbe significare che la tua 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 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 le 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 OS Login per abilitare l'accesso SSH. Quando crei un'istanza, Vertex AI Workbench attiva l'accesso al OS Login 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 di metadati 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 tramite SSH da 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 in Google Cloud SDK.

La quota di GPU è stata superata

Problema

Non puoi creare un'istanza di Vertex AI Workbench con GPU.

Soluzione:

Determina il numero di GPU disponibili nel progetto controllando la pagina Quote. Se le GPU non sono elencate nella pagina delle quote o se hai bisogno di una quota GPU aggiuntiva, puoi richiedere un aumento della quota per le GPU di Compute Engine. 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 In attesa a tempo indeterminato o è bloccata nello stato di provisioning

Problema

Dopo aver creato un'istanza di Vertex AI Workbench, questa rimane indefinitamente nello stato in attesa. Nei log seriali potrebbe essere visualizzato un errore simile al seguente:

Could not resolve host: notebooks.googleapis.com

Se la tua istanza è bloccata nello stato di provisioning, 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 condiviso 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 il service account Notebooks sta tentando di creare l'istanza senza le autorizzazioni corrette.

Per assicurarti che il service account Notebooks disponga delle autorizzazioni necessarie per creare un'istanza Vertex AI Workbench all'interno di una rete VPC condiviso, chiedi all'amministratore di concedere al service account Notebooks il ruolo IAM Utente di rete Compute (roles/compute.networkUser) nel progetto host.

Per ulteriori informazioni sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Questo ruolo predefinito contiene le autorizzazioni necessarie per garantire che il service account Notebooks possa creare un'istanza Vertex AI Workbench all'interno di una rete VPC condiviso. Per vedere quali sono esattamente le autorizzazioni richieste, espandi la sezione Autorizzazioni obbligatorie:

Autorizzazioni obbligatorie

Per assicurarti che il service account Notebooks possa creare un'istanza 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 essere in grado di concedere queste autorizzazioni all'account di servizio Notebook con ruoli personalizzati o altri ruoli predefiniti.

Impossibile creare un'istanza di Vertex AI Workbench con un container personalizzato

Problema

Non è disponibile un'opzione per utilizzare un contenitore personalizzato quando crei un'istanza di Vertex AI Workbench nella console Google Cloud .

Soluzione:

L'aggiunta di un container personalizzato a un'istanza Vertex AI Workbench non è supportata e non puoi aggiungere un container personalizzato utilizzando la console Google Cloud .

L'aggiunta di un ambiente conda è consigliata anziché l'utilizzo di un container personalizzato.

Puoi aggiungere un container personalizzato a un'istanza Vertex AI Workbench utilizzando l'API Notebooks, ma questa funzionalità non è supportata.

Il pulsante Monta archivio condiviso non è presente

Problema

Il pulsante Monta spazio di archiviazione condiviso non è presente nella scheda Esplora file dell'interfaccia di JupyterLab.

Soluzione:

L'autorizzazione storage.buckets.list è necessaria per visualizzare il pulsante Monta spazio di archiviazione condiviso nell'interfaccia JupyterLab dell'istanza Vertex AI Workbench. Chiedi all'amministratore di concedere all'account di servizio dell'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 restituisce 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 messaggio Error: 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 ricevere 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 nel Google Cloud SDK

I pacchetti pip non sono disponibili dopo l'aggiunta dell'ambiente conda

Problema

I tuoi 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 a opt/conda/envs/ENVIRONMENT/bin/pip. Puoi eseguire il comando which pip per ottenere il percorso.

Impossibile accedere o copiare i dati di un'istanza con accesso per un solo utente

Problema

I dati di un'istanza con accesso per un singolo utente non sono accessibili.

Per le istanze Vertex AI Workbench configurate con l'accesso di un singolo utente, solo l'utente singolo specificato (il proprietario) può accedere ai dati sull'istanza.

Soluzione:

Per accedere ai dati o copiarli quando non sei il proprietario dell'istanza, apri una richiesta di assistenza.

Arresto imprevisto

Problema

L'istanza Vertex AI Workbench si arresta in modo imprevisto.

Soluzione:

Se la tua istanza si arresta in modo imprevisto, il motivo potrebbe essere l'avvio dell'arresto inattivo.

Se hai attivato l'arresto inattivo, l'istanza si arresta quando non viene rilevata attività del kernel per il periodo di tempo specificato. Ad esempio, l'esecuzione di una cella o la stampa di un nuovo output in un blocco note è un'attività che reimposta il timer di timeout per inattività. L'utilizzo della CPU non reimposta il timer di timeout per inattività.

I log dell'istanza 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 Verifica 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 sulle opzioni di configurazione di rete. Considera quanto segue:

I log dell'istanza mostrano "Unable to contact Jupyter API" (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 impostare HTTP_TIMEOUT_SESSION su un valore maggiore, ad esempio 60, per verificare se la richiesta non è andata a buon fine perché la chiamata ha impiegato troppo tempo per rispondere o l'URL richiesto non è raggiungibile.

docker0 conflitti di indirizzi 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 tua rete VPC, in modo che l'istanza non possa 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 post-startup e impostando il comportamento dello script post-startup 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

Le prenotazioni specificate non esistono

Problema

L'operazione per creare l'istanza genera un messaggio di errore Specified reservations do not exist. L'output dell'operazione potrebbe essere simile al seguente:

{
  "name": "projects/PROJECT/locations/LOCATION/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.notebooks.v2.OperationMetadata",
    "createTime": "2025-01-01T01:00:01.000000000Z",
    "endTime": "2025-01-01T01:00:01.000000000Z",
    "target": "projects/PROJECT/locations/LOCATION/instances/INSTANCE_NAME",
    "verb": "create",
    "requestedCancellation": false,
    "apiVersion": "v2",
    "endpoint": "CreateInstance"
  },
  "done": true,
  "error": {
    "code": 3,
    "message": "Invalid value for field 'resource.reservationAffinity': '{  \"consumeReservationType\": \"SPECIFIC_ALLOCATION\",  \"key\": \"compute.googleapis.com/reservation-name...'. Specified reservations [projects/PROJECT/zones/ZONE/futureReservations/RESERVATION_NAME] do not exist.",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.RequestInfo",
        "requestId": "REQUEST_ID"
      }
    ]
  }
}

Soluzione:

Alcuni tipi di macchine Compute Engine richiedono parametri aggiuntivi al momento della creazione, come dischi locali o una piattaforma CPU minima. La specifica dell'istanza deve includere questi campi aggiuntivi.

Ad esempio, il tipo di macchina a3-megagpu-8g richiede 16 dischi SSD locali, che devono essere inclusi nella prenotazione e specificati nella richiesta di creazione dell'istanza.

BODY='{
  "gce_setup": {
    "machine_type": "a3-megagpu-8g",
    "reservation_affinity": {
      "consume_reservation_type": "RESERVATION_SPECIFIC",
      "key": "compute.googleapis.com/reservation-name",
      "values": ["RESERVATION_NAME"]
    },
    "bootDisk": {
        "disk_type": "PD_SSD",
        "diskSizeGb": "150",
        "diskEncryption": "GMEK"
    },
    "data_disks": [
      {
        "disk_type": "PD_SSD",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
    ],
  }
}'

Notebook gestiti

Questa sezione descrive i passaggi per la risoluzione dei problemi relativi ai blocchi note gestiti.

Connessione e apertura di JupyterLab

Questa sezione descrive 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 di 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 notebook gestiti utilizzando SSH.

Soluzione:

L'accesso SSH alle istanze di notebook gestiti 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 launcher, è possibile che l'accesso al terminale non sia abilitato nell'istanza dei notebook gestiti.

Soluzione:

Devi creare una nuova istanza di blocchi note gestiti con l'opzione Accesso al terminale attivata. Questa opzione non può essere modificata dopo la creazione dell'istanza.

Errore 502 all'apertura di JupyterLab

Problema

Un errore 502 potrebbe significare 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 proxy inverso non si connette al server proxy inverso o che le richieste richiedono troppo tempo sul lato server di backend (Jupyter). Le cause comuni di questo errore includono problemi di rete, l'agente proxy inverso non è in esecuzione o il servizio Jupyter non è in esecuzione.

Soluzione:

Verifica che l'istanza di blocchi note gestiti sia avviata.

Il notebook non risponde

Problema

L'istanza di blocchi note gestiti non esegue celle o sembra 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 le 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 che si trovava nell'istanza di notebook gestiti

Problema

Un kernel presente 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 di container personalizzati.

Soluzione:

Per risolvere il problema, aggiungi un ambiente conda all'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 aveva una versione diversa da quella dell'istanza di Vertex AI Workbench a cui hai eseguito la migrazione.

Le istanze di Vertex AI Workbench forniscono un insieme predefinito di versioni del framework. Lo strumento di migrazione non aggiunge versioni del framework dall'istanza originale di notebook gestiti. 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.

Le GPU non vengono migrate alla nuova istanza di Vertex AI Workbench

Problema

Le GPU presenti nell'istanza dei blocchi note gestiti 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 originale di blocchi note gestiti non sono disponibili, la migrazione dell'istanza viene eseguita senza GPU.

Soluzione:

Dopo la migrazione, puoi aggiungere GPU all'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.

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 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 originale di notebook gestiti 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 puoi creare un'istanza di blocchi note gestiti con GPU.

Soluzione:

Determina il numero di GPU disponibili nel progetto controllando la pagina Quote. Se le GPU non sono elencate nella pagina 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 container.

L'immagine container non viene visualizzata come kernel in JupyterLab

Problema

Le immagini container che non hanno una specifica del kernel valida non vengono caricate correttamente come kernel in JupyterLab.

Soluzione:

Assicurati che il contenitore soddisfi i nostri requisiti. Per maggiori informazioni, consulta i requisiti dei container personalizzati.

Il notebook si disconnette per un job di lunga durata

Problema

Se visualizzi il seguente messaggio di errore durante l'esecuzione di un job in un notebook, è possibile che la richiesta impieghi troppo tempo per caricarsi o che l'utilizzo di CPU o memoria sia elevato, il che può rendere il servizio Jupyter non reattivo.

{"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 il cui completamento potrebbe richiedere molto tempo, ti consigliamo di utilizzare l'executor.

Utilizzo dell'executor

Questa sezione descrive la risoluzione dei problemi relativi all'utilizzo dell'executor.

Installazioni di pacchetti non disponibili per l'esecutore

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'executor.

Soluzione:

Per risolvere il problema, consulta la sezione Assicurarsi che le installazioni dei pacchetti siano disponibili per l'esecutore.

Errori 401 o 403 durante l'esecuzione del codice del blocco note utilizzando l'executor

Problema

Un errore 401 o 403 durante l'esecuzione dell'executor può significare che l'executor non è in grado di accedere alle risorse.

Soluzione:

Per le possibili cause, consulta quanto segue:

  • L'executor esegue il codice del notebook in un progetto tenant separato dal progetto dell'istanza di Managed Notebooks. Pertanto, quando accedi alle risorse tramite il codice eseguito dall'executor, l'executor potrebbe non connettersi al progetto Google Cloud corretto per impostazione predefinita. Per risolvere il problema, seleziona esplicitamente il progetto.

  • Per impostazione predefinita, l'istanza di notebook gestiti può accedere alle risorse che esistono nello stesso progetto e, pertanto, quando esegui manualmente il codice del file notebook, queste risorse non richiedono un'autenticazione aggiuntiva. Tuttavia, poiché l'executor viene eseguito in un progetto tenant separato, non dispone dello stesso accesso predefinito. Per risolvere il problema, autentica l'accesso utilizzando i service account.

  • L'esecutore 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 i service account.

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 "comando non trovato" può verificarsi quando utilizzi l'executor per eseguire codice su un contenitore personalizzato in 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 Deep Learning Containers. Le immagini Deep Learning Containers includono l'estensione nbexecutor.

Messaggio di errore relativo a una configurazione di service networking 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 di /24 o inferiore. Crea un intervallo di indirizzi IP allocato più grande e collegalo modificando la connessione di servizio privato per servicenetworking-googleapis-com.

Per maggiori 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 messaggio Error: 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 per un solo utente

Problema

I dati di un'istanza con accesso per un singolo utente non sono accessibili.

Soluzione:

Per le istanze di notebook gestiti configurate con l'accesso di un singolo utente, solo l'utente singolo specificato (il proprietario) può accedere ai dati sull'istanza.

Per accedere ai dati o copiarli quando non sei il proprietario dell'istanza, apri una richiesta di assistenza.

Arresto imprevisto

Problema

L'istanza Vertex AI Workbench si arresta in modo imprevisto.

Soluzione:

Se la tua istanza si arresta in modo imprevisto, il motivo potrebbe essere l'avvio dell'arresto inattivo.

Se hai attivato l'arresto inattivo, l'istanza si arresta quando non viene rilevata attività del kernel per il periodo di tempo specificato. Ad esempio, l'esecuzione di una cella o la stampa di un nuovo output in un blocco note è un'attività che reimposta il timer di timeout per inattività. L'utilizzo della CPU non reimposta il timer di timeout per inattività.

Ripristina istanza

Problema

Il ripristino di un'istanza di blocchi note gestiti dopo l'eliminazione non è supportato.

Soluzione:

Per eseguire il backup dei dati nell'istanza, puoi salvare i notebook su GitHub.

Recuperare i dati da un'istanza

Problema

Il recupero dei dati da un'istanza di blocchi note gestiti dopo l'eliminazione non è supportato.

Soluzione:

Per eseguire il backup dei dati nell'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 è verificato 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 maggiore di /24 e collega questo intervallo 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 puoi 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 non disponibilità di 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 delle risorse non sono correlati alla quota di Compute Engine. Gli errori di risorse sono temporanei e possono cambiare di frequente in base alle fluttuazioni della domanda.

Soluzione:

Per continuare, prova quanto segue:

  • Crea un'istanza con un tipo di macchina diverso.
  • Crea l'istanza in una zona diversa.
  • Riprova a inviare la richiesta più tardi.
  • Riduci la quantità di risorse che stai richiedendo. Ad esempio, prova a creare un'istanza con meno GPU, dischi, vCPU o memoria.

L'avvio di un'istanza genera un errore di disponibilità delle risorse

Problema

Non puoi 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 non disponibilità di risorse di Compute Engine, ad esempio 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 delle risorse non sono correlati alla quota di Compute Engine. Gli errori delle risorse sono temporanei e possono cambiare frequentemente in base alle fluttuazioni della domanda.

Soluzione:

Per continuare, prova quanto segue:

  • Modifica il tipo di macchina dell'istanza.
  • Esegui la migrazione dei file e dei dati a un'istanza in una zona diversa.
  • Riprova a inviare la richiesta più tardi.
  • Riduci la quantità di risorse che stai richiedendo. 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 visualizzare nella console Google Cloud sono quelle note al tuo VPC, nonché gli intervalli riservati quando completi la configurazione del peering di rete VPC.

Le istanze di blocchi note gestiti si trovano in una rete gestita da Google ed 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 dal tuo VPC. Questi valori rientrano in genere negli intervalli 172.16.0.0/161 e 192.168.10.0/24, rispettivamente.

In queste circostanze, le connessioni in uscita dall'istanza a questi intervalli non andranno a buon fine e verrà visualizzato un messaggio di errore simile a No route to host nonostante le route VPC siano condivise correttamente.

Soluzione:

Richiama ifconfig in una sessione del terminale e assicurati che nessun indirizzo IP su qualsiasi interfaccia virtuale nell'istanza sia in conflitto con gli intervalli IP che il tuo VPC sta esportando nella connessione di peering.

Notebook gestiti dall'utente

Questa sezione descrive i passaggi per la risoluzione dei problemi relativi ai notebook gestiti dall'utente.

Connessione e apertura di JupyterLab

Questa sezione descrive 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 di nuove schede. JupyterLab si apre in una nuova scheda del browser.

Nessun accesso al 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 l'accesso a JupyterLab. Le impostazioni dell'istanza di blocchi note gestiti dall'utente, la configurazione di rete e altri fattori possono impedire l'accesso a JupyterLab.

Soluzione:

Utilizza SSH per connetterti a JupyterLab e scoprire di più sul motivo per cui potresti non avere accesso tramite il proxy inverso.

Impossibile connettersi all'istanza di notebook gestiti dall'utente tramite SSH

Problema

Non riesci a connetterti all'istanza utilizzando SSH tramite una finestra del terminale.

Le istanze di notebook gestiti dall'utente utilizzano OS Login per abilitare l'accesso SSH. Quando crei un'istanza, Vertex AI Workbench attiva l'accesso al OS Login 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 di metadati su TRUE.

Soluzione:

Per attivare l'accesso SSH per i notebook gestiti dall'utente per gli utenti, completa i passaggi per configurare i ruoli OS Login sugli account utente.

L'apertura di un'istanza di blocchi note gestiti dall'utente genera un errore 403 (accesso negato)

Problema

Un errore 403 (Forbidden) durante l'apertura di un'istanza di blocchi note gestiti dall'utente spesso indica che si è verificato un problema di accesso.

Soluzione:

Per risolvere i problemi di accesso, considera i tre modi in cui l'accesso può essere concesso a un'istanza di blocchi note gestiti dall'utente:

  • Utente singolo
  • Service account
  • Editor progetto

La modalità di accesso viene configurata durante la creazione dell'istanza di blocchi note gestiti 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 progetto: proxy-mode=project_editors

Se non riesci ad accedere a un notebook quando fai clic su Apri JupyterLab, prova a procedere nel seguente modo:

L'esempio seguente 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, questo 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:

  1. Nella pagina dei blocchi note gestiti dall'utente della console Google Cloud , fai clic sul nome dell'istanza per aprire la pagina Dettagli notebook.

  2. Accanto a Visualizza dettagli VM, fai clic su Visualizza in Compute Engine.

  3. Nella pagina dei dettagli della VM, fai clic su Modifica.

  4. Nella sezione Metadati, verifica che la voce di metadati proxy-mode sia impostata su mail.

  5. Verifica che la voce di metadati proxy-user-mail sia impostata su un indirizzo email utente valido, non su un account di servizio.

  6. Fai clic su Salva.

  7. Nella pagina Blocchi note gestiti dall'utente della console Google Cloud , inizializza i metadati aggiornati interrompendo l'istanza e riavviandola.

L'apertura di un notebook genera un errore 504 (timeout del gateway)

Problema

Questo indica un timeout del proxy interno o un timeout del server di backend (Jupyter). Ciò si verifica 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 inverso interno non ha ricevuto una risposta dall'agente proxy inverso per la richiesta entro il periodo di timeout. L'agente proxy inverso viene eseguito all'interno dell'istanza di blocchi note gestiti dall'utente come container Docker. Un errore 524 indica in genere che l'agente Inverting Proxy non si connette al server Inverting Proxy 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 inverso non è in esecuzione).

Soluzione:

Se non riesci ad accedere a un notebook, verifica che l'istanza dei notebook gestiti 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 blocchi note gestiti dall'utente, verificare lo spazio di archiviazione disponibile e generare file di log utili. Per eseguire lo strumento nell'istanza, segui questi passaggi:

  1. Assicurati che la tua istanza sia alla versione M58 o successive.

  2. Connettiti all'istanza Deep Learning VM Images utilizzando SSH.

  3. Esegui questo comando:

    sudo /opt/deeplearning/bin/diagnostic_tool.sh [--repair] [--bucket=$BUCKET]

    Tieni presente che il flag --repair e i flag --bucket sono facoltativi. Il flag --repair tenterà di correggere gli errori comuni dei servizi di base, mentre il flag --bucket ti consentirà di specificare un bucket Cloud Storage in cui 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 questi passaggi per controllare individualmente i requisiti specifici dei notebook gestiti dagli utenti.

L'apertura di un notebook genera un errore 598 (timeout di lettura della rete)

Problema

Il server Inverting Proxy non riceve comunicazioni dall'agente Inverting Proxy da più di 10 minuti. Questo è un forte indicatore di un problema dell'agente Inverting Proxy.

Soluzione:

Se non riesci ad accedere a un blocco note, prova a procedere nel seguente modo:

Il notebook non risponde

Problema

L'istanza di blocchi note gestiti dall'utente non esegue celle o sembra 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 nuovamente le celle per rigenerare l'output.
  • Da una sessione del terminale nel notebook, esegui il comando top per verificare se ci sono processi che consumano la CPU.
  • Dal terminale, controlla la quantità di spazio libero su disco utilizzando il comando df oppure controlla la RAM disponibile utilizzando il comando free.
  • Arresta l'istanza selezionandola dalla pagina Blocchi note gestiti dall'utente e facendo clic su Arresta. Dopo che si è arrestato 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 blocchi note gestiti dall'utente

Problema

Un kernel presente nell'istanza di notebook gestiti dall'utente non viene visualizzato nell'istanza di Vertex AI Workbench di cui è stata eseguita la migrazione.

Alcuni kernel, come i kernel R e Beam, non sono disponibili nelle istanze di Vertex AI Workbench per impostazione predefinita. La migrazione di questi kernel non è supportata.

Soluzione:

Per risolvere il problema, aggiungi un ambiente conda all'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:

Continua a utilizzare Dataproc Hub nelle istanze di blocchi note gestiti 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 aveva una versione diversa da quella nell'istanza di Vertex AI Workbench a cui hai eseguito la migrazione.

Le istanze di Vertex AI Workbench forniscono un insieme predefinito di versioni del framework. Lo strumento di migrazione non aggiunge versioni del framework dall'istanza originale dei notebook gestiti dall'utente. 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.

Le GPU non vengono migrate alla nuova istanza di Vertex AI Workbench

Problema

Le GPU che si trovavano nell'istanza di notebook gestiti dall'utente non si trovano nell'istanza 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 originale dei blocchi note gestiti dall'utente non sono disponibili, la tua istanza viene migrata senza GPU.

Soluzione:

Dopo la migrazione, puoi aggiungere GPU all'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.

Il tipo di macchina dell'istanza di cui è stata eseguita la migrazione è diverso

Problema

Il tipo di macchina dell'istanza di notebook gestiti 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 originale di notebook gestiti dall'utente 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.

Utilizzo dei 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 i file

Problema

Per le istanze di blocchi note gestiti dall'utente di Dataproc Hub, la disattivazione del download di file dall'interfaccia utente di JupyterLab non è supportata. Le istanze di blocchi note gestiti dall'utente che utilizzano il framework Dataproc Hub consentono il download dei file anche se non selezioni Abilita il download di file dall'interfaccia utente di JupyterLab quando crei l'istanza.

Soluzione:

Le istanze di blocchi note gestiti dall'utente di Dataproc Hub non supportano la limitazione dei download di file.

I file scaricati sono troncati o il download non viene completato

Problema

Quando scarichi file dall'istanza di notebook gestiti dall'utente, un'impostazione di timeout nell'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 non essere scaricato.

Soluzione:

Per scaricare il file, copialo in Cloud Storage e poi scaricalo da Cloud Storage.

Valuta la possibilità di eseguire la migrazione dei file e dei dati a una nuova istanza di blocchi note gestiti dall'utente.

Dopo il riavvio della VM, non è possibile fare riferimento ai file locali dal terminale del notebook

Problema

A volte, dopo aver riavviato un'istanza di notebook gestiti dall'utente, non è possibile fare riferimento ai file locali da un terminale del notebook.

Soluzione:

Questo è un problema noto. Per fare riferimento ai file locali da un terminale del notebook, ristabilisci prima la directory di lavoro corrente utilizzando il seguente comando:

cd PWD

In questo comando, sostituisci PWD con la directory di lavoro corrente. Ad esempio, se la tua directory di lavoro attuale è /home/jupyter/, utilizza il comando cd /home/jupyter/.

Dopo aver ristabilito la directory di lavoro corrente, è possibile fare riferimento ai file locali dal terminale del notebook.

Creazione di istanze di blocchi note 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 puoi creare un'istanza di blocchi note gestiti dall'utente con GPU.

Soluzione:

Determina il numero di GPU disponibili nel progetto controllando la pagina Quote. Se le GPU non sono elencate nella pagina 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 In 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 seriali potrebbe essere visualizzato un errore simile al seguente:

Could not resolve host: notebooks.googleapis.com

Soluzione:

L'istanza non può connettersi al server 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 Opzioni di configurazione di rete.

La nuova istanza di blocchi note gestiti dall'utente non viene creata (autorizzazioni insufficienti)

Problema

In genere, la creazione di un'istanza di blocchi note gestiti dall'utente richiede circa un minuto. Se la nuova istanza di blocchi note gestiti dall'utente rimane nello stato pending a tempo indeterminato, il motivo potrebbe essere che l'account di servizio utilizzato per avviare l'istanza non dispone delle autorizzazioni richieste nel tuo progetto Google Cloud .

Puoi avviare un'istanza di notebook gestiti dall'utente con un account di servizio personalizzato che crei o in modalità utente singolo con un ID utente. Se avvii un'istanza di notebook gestiti dall'utente in modalità utente singolo, l'istanza di notebook gestiti dall'utente avvia il processo di avvio utilizzando il account di servizio predefinito di Compute Engine prima di cedere il controllo al tuo ID utente.

Soluzione:

Per verificare che un account di servizio disponga delle autorizzazioni appropriate, segui questi passaggi:

Console

  1. Apri la pagina IAM nella console Google Cloud .

    Apri la pagina IAM

  2. Determina il account di servizio utilizzato con l'istanza di blocchi note gestiti dall'utente, che è uno dei seguenti:

    • Un account di servizio personalizzato che hai specificato quando hai creato l'istanza di blocchi note gestiti dall'utente.

    • Il account di servizio Compute Engine predefinito per il tuo progettoGoogle Cloud , che viene utilizzato quando avvii l'istanza di notebook gestiti dall'utente in modalità single-user. L'account di servizio Compute Engine predefinito per il tuo progetto Google Cloud si chiama PROJECT_NUMBER-compute@developer.gserviceaccount.com. Ad esempio: 113377992299-compute@developer.gserviceaccount.com.

  3. Verifica che il account di servizio disponga del ruolo Notebooks Runner (roles/notebooks.runner). In caso contrario, concedi al account di servizio il ruolo Notebooks Runner (roles/notebooks.runner).

Per saperne di più, consulta l'articolo Concessione, modifica e revoca dell'accesso alle risorse nella documentazione di IAM.

gcloud

  1. Se non l'hai ancora fatto, installa Google Cloud CLI.

  2. Recupera il nome e il numero di progetto del tuo Google Cloud progetto con il seguente comando. Sostituisci PROJECT_ID con l'ID progetto del tuo progettoGoogle Cloud .

    gcloud projects describe PROJECT_ID

    Dovresti vedere un output simile al seguente, che mostra il nome (name:) e il numero di progetto (projectNumber:) del tuo 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'

  3. Determina il account di servizio utilizzato con l'istanza di blocchi note gestiti dall'utente, che è uno dei seguenti:

    • Un account di servizio personalizzato che hai specificato quando hai creato l'istanza di blocchi note gestiti dall'utente.

    • Il account di servizio Compute Engine predefinito per il tuo progettoGoogle Cloud , che viene utilizzato quando avvii l'istanza di notebook gestiti dall'utente in modalità single-user. L'account di servizio Compute Engine predefinito per il tuo progetto Google Cloud si chiama PROJECT_NUMBER-compute@developer.gserviceaccount.com. Ad esempio: 113377992299-compute@developer.gserviceaccount.com.

  4. 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 l'istanza di notebook gestiti 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

Il account di servizio sull'istanza fornisce l'accesso ad altri Google Cloud servizi. Puoi utilizzare qualsiasi account di servizio all'interno dello stesso progetto, ma devi disporre dell'autorizzazione Utente service account (iam.serviceAccounts.actAs) per creare l'istanza. Se non specificato, viene utilizzato il service account Compute Engine predefinito.

Soluzione:

Quando crei un'istanza, verifica che l'utente che la crea disponga dell'autorizzazione iam.serviceAccounts.ActAs per il account di servizio definito.

L'esempio seguente 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 service account, consulta la pagina Gestire l'accesso ai service account.

La creazione di un'istanza genera un errore already exists

Problema

Quando crei un'istanza, verifica che un'istanza di notebook gestiti 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 verificare il loro 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 un VPC condiviso

Problema

Non puoi creare un'istanza in un VPC condiviso.

Soluzione:

Se utilizzi VPC condiviso, 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 del progetto di servizio. Per saperne di più, consulta Gestione dei perimetri di servizio.

La creazione di un'istanza genera un errore di disponibilità delle risorse

Problema

Non puoi 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 non disponibilità di 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 delle risorse non sono correlati alla quota di Compute Engine. Gli errori di risorse sono temporanei e possono cambiare di frequente in base alle fluttuazioni della domanda.

Soluzione:

Per procedere, puoi provare quanto segue:

  • Crea un'istanza con un tipo di macchina diverso.
  • Crea l'istanza in una zona diversa.
  • Riprova a inviare la richiesta più tardi.
  • Riduci la quantità di risorse che stai richiedendo. Ad esempio, prova a creare un'istanza con meno GPU, dischi, vCPU o memoria.

L'avvio di un'istanza genera un errore di disponibilità delle risorse

Problema

Non puoi 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 non disponibilità di risorse di Compute Engine, ad esempio 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 delle risorse non sono correlati alla quota di Compute Engine. Gli errori delle risorse sono temporanei e possono cambiare frequentemente in base alle fluttuazioni della domanda.

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 una zona diversa.
  • Riprova a inviare la richiesta più tardi.
  • Riduci la quantità di risorse che stai richiedendo. Ad esempio, avvia un'altra istanza con meno GPU, dischi, vCPU o memoria.

Eseguire l'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 gestiti dall'utente con un singolo disco.

Soluzione:

Potresti voler eseguire la migrazione dei dati utente a una nuova istanza di notebook gestiti dagli utenti.

Impossibile eseguire l'upgrade perché l'istanza non è compatibile con UEFI

Problema

Per completare un upgrade, Vertex AI Workbench dipende dalla compatibilità UEFI.

Le istanze di blocchi note gestiti dall'utente create da alcune immagini precedenti non sono compatibili con UEFI e pertanto non possono essere aggiornate.

Soluzione:

Per verificare che l'istanza sia compatibile con UEFI, digita il comando seguente in Cloud Shell o in qualsiasi ambiente in cui è installata Google Cloud CLI.

gcloud compute instances describe INSTANCE_NAME \
  --zone=ZONE | grep type

Sostituisci quanto segue:

  • INSTANCE_NAME: il nome dell'istanza
  • ZONE: 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 determini che la tua istanza o la tua immagine non è compatibile con UEFI, puoi tentare di eseguire la migrazione dei dati utente a una nuova istanza di blocchi note gestiti dall'utente. Per farlo, segui questa procedura.

  1. Verifica che l'immagine che vuoi utilizzare per creare la nuova istanza sia compatibile con UEFI. Per farlo, digita il comando seguente in Cloud Shell o in qualsiasi ambiente in cui è installata 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.

  2. Esegui la migrazione dei dati utente a una nuova istanza di notebook gestiti dall'utente.

L'istanza di blocchi note gestiti dall'utente non è accessibile dopo l'upgrade

Problema

Se l'istanza di notebook gestiti dall'utente non è accessibile dopo un upgrade, potrebbe essersi verificato un errore durante la sostituzione dell'immagine del disco di avvio.

Le istanze di notebook gestiti dall'utente che possono essere aggiornate sono a 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.

  1. Per memorizzare i valori che utilizzerai per completare questa procedura, digita il comando seguente in Cloud Shell o in qualsiasi ambiente in cui è installata 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'istanza
    • MY_PROJECT_ID: il tuo ID progetto
    • MY_ZONE: la zona in cui si trova l'istanza

  2. Utilizza il seguente comando per arrestare l'istanza:

    gcloud compute instances stop $INSTANCE_NAME \
  --project=$PROJECT_ID --zone=$ZONE

  3. Scollega il disco di dati dall'istanza.

    gcloud compute instances detach-disk $INSTANCE_NAME --device-name=data \
  --project=$PROJECT_ID --zone=$ZONE

  4. Elimina la VM dell'istanza.

    gcloud compute instances delete $INSTANCE_NAME --keep-disks=all --quiet \
  --project=$PROJECT_ID --zone=$ZONE

  5. Utilizza l'API Notebooks per eliminare l'istanza di notebook gestiti dall'utente.

    gcloud notebooks instances delete $INSTANCE_NAME \
  --project=$PROJECT_ID --location=$ZONE

  6. 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 immagini
    • MY_INSTANCE_OWNER: il proprietario dell'istanza
    • MY_MACHINE_TYPE: il tipo di macchina della VM della tua istanza
    • MY_SERVICE_ACCOUNT: il account di servizio da utilizzare con questa istanza oppure utilizza "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 gestiti dall'utente

Questa sezione descrive come risolvere i problemi relativi agli errori di monitoraggio dello stato di integrità.

docker-proxy-agent stato non riuscito

Segui questi passaggi dopo un errore di stato docker-proxy-agent:

  1. Verifica che l'agente Inverting Proxy sia in esecuzione. In caso contrario, vai al passaggio 3.

  2. Riavvia l'agente Inverting Proxy.

  3. Esegui nuovamente la registrazione con il server Inverting Proxy.

docker-service stato non riuscito

Segui questi passaggi dopo un errore di stato docker-service:

  1. Verifica che il servizio Docker sia in esecuzione.

  2. Riavvia il servizio Docker.

jupyter-service stato non riuscito

Segui questi passaggi dopo un errore di stato jupyter-service:

  1. Verifica che il servizio Jupyter sia in esecuzione.

  2. Riavvia il servizio Jupyter.

jupyter-api stato non riuscito

Segui questi passaggi dopo un errore di stato jupyter-api:

  1. Verifica che l'API interna Jupyter sia attiva.

  2. Riavvia il servizio Jupyter.

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:

  1. Da una sessione del terminale nell'istanza dei blocchi note gestiti dall'utente o utilizzando SSH per connetterti, controlla la quantità di spazio libero su disco utilizzando il comando df -H.

  2. Utilizza il comando find . -type d -size +100M per trovare i file di grandi dimensioni che potresti eliminare, ma non farlo a meno che tu non sia sicuro di poterlo fare in sicurezza. Se non sei sicuro, puoi richiedere assistenza.

  3. Se i passaggi precedenti non risolvono il problema, richiedi assistenza.

Percentuale di utilizzo disco dati

Lo stato dello spazio sul disco dati non è integro se lo spazio sul disco occupato è maggiore dell'85%.

Se lo stato dello spazio sul disco dati non è integro, prova a procedere nel seguente modo:

  1. Da una sessione del terminale nell'istanza dei blocchi note gestiti dall'utente o utilizzando SSH per connetterti, controlla la quantità di spazio libero su disco utilizzando il comando df -h -T /home/jupyter.

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

  3. 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 messaggio Error: 500.

Soluzione:

Le estensioni JupyterLab di terze parti non sono supportate nelle istanze di blocchi note gestiti dall'utente.

Ripristina istanza

Problema

Il ripristino di un'istanza di blocchi note gestiti dall'utente dopo l'eliminazione non è supportato.

Soluzione:

Per eseguire il backup dei dati sull'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 blocchi note gestita dall'utente dopo l'eliminazione non è supportato.

Soluzione:

Per eseguire il backup dei dati sull'istanza, puoi salvare i notebook su GitHub o creare uno snapshot del disco.

Impossibile aumentare la memoria condivisa

Problema

Non puoi aumentare la memoria condivisa su un'istanza di blocchi note gestiti dall'utente esistente.

Soluzione:

Tuttavia, puoi specificare una dimensione della memoria condivisa quando crei un'istanza di blocchi note gestiti dall'utente utilizzando la chiave di metadati container-custom-params, con un valore simile al seguente:

--shm-size=SHARED_MEMORY_SIZE gb

Sostituisci SHARED_MEMORY_SIZE con le dimensioni che vuoi in GB.

Procedure utili

Questa sezione descrive le procedure che potresti trovare utili.

Utilizzare SSH per connettersi all'istanza di blocchi note gestiti dall'utente

Utilizza ssh per connetterti all'istanza digitando il seguente comando in Cloud Shell o in qualsiasi ambiente in cui è installata 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 progetto
  • ZONE: la Google Cloud zona in cui si trova l'istanza
  • INSTANCE_NAME: il nome dell'istanza

Puoi anche connetterti all'istanza aprendo la pagina dei dettagli di Compute Engine e facendo clic sul pulsante SSH.

Esegui nuovamente la registrazione con il server Inverting Proxy

Per registrare nuovamente l'istanza di blocchi note gestiti dall'utente con il server proxy inverso interno, puoi arrestare e avviare la VM dalla pagina Blocchi note gestiti dall'utente oppure puoi utilizzare SSH per connetterti all'istanza di 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 gestiti 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 gestiti 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 connetterti 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

Verifica che l'API interna Jupyter sia attiva

L'API Jupyter deve essere sempre eseguita sulla porta 8080. Puoi verificarlo controllando i syslogs dell'istanza per una voce simile a:

Jupyter Server ... running at:
http://localhost:8080

Per verificare che l'API Jupyter interna sia attiva, puoi anche utilizzare SSH per connetterti all'istanza di blocchi note gestiti 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 richiedano 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 all'istanza di notebook gestiti dall'utente e inserire:

sudo service docker restart

Riavvia l'agente Inverting Proxy

Per riavviare l'agente proxy inverso, puoi arrestare e avviare la VM dalla pagina User-managed notebooks oppure puoi utilizzare SSH per connetterti all'istanza User-managed notebooks 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 all'istanza di blocchi note gestiti dall'utente e inserire:

sudo service jupyter restart

Riavvia l'agente di raccolta dei notebook

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 dell'agente di raccolta dei notebook, puoi arrestare e avviare la VM dalla console oppure puoi utilizzare SSH per connetterti all'istanza Vertex AI Workbench e inserire:Google Cloud 

sudo systemctl stop notebooks-collection-agent.service

seguito da:

sudo systemctl start notebooks-collection-agent.service

Per eseguire questi comandi nell'istanza Vertex AI Workbench, apri JupyterLab e crea un nuovo terminale.

Modifica lo script dell'agente di raccolta dei notebook

Per accedere allo script e modificarlo, apri un terminale nella nostra istanza o utilizza SSH per connetterti all'istanza di Vertex AI Workbench e inserisci:

nano /opt/deeplearning/bin/notebooks_collection_agent.py

Dopo aver modificato il file, ricordati di salvarlo.

Dopodiché, devi riavviare il servizio dell'agente di raccolta dei blocchi note.

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 blocchi note gestiti 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 l'istanza 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 su 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: 
    gcloud storage buckets create gs://BUCKET_NAME
     Replace BUCKET_NAME with a bucket name that meets the bucket naming requirements.

    Copia i dati utente

    1. Nell'interfaccia JupyterLab della tua istanza, seleziona File > Nuovo > Terminale per aprire una finestra del terminale. Per le istanze di notebook gestiti dall'utente, puoi invece connetterti al terminale dell'istanza utilizzando SSH.

    2. Utilizza gcloud CLI 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 bucket Cloud Storage
      • PATH: il percorso della directory in cui vuoi copiare i file, ad esempio: /copy/jupyter/

    Analizza 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 Google Cloud i problemi del progetto. Per maggiori informazioni, consulta il progetto gcpdiag su GitHub.

    Questo gcpdiag runbook esamina le potenziali cause per cui un'istanza di Vertex AI Workbench rimane bloccata nello stato di provisioning, tra cui le seguenti aree:
    • Stato: controlla lo stato attuale dell'istanza per assicurarsi che sia bloccata nel provisioning e non arrestata o attiva.
    • Immagine disco di avvio della VM Compute Engine dell'istanza: Verifica se l'istanza è stata creata con un container personalizzato, un'immagine workbench-instances ufficiale, Deep Learning VM Images o immagini non supportate che potrebbero causare il blocco dell'istanza nello stato di provisioning.
    • Script personalizzati: controlla se l'istanza utilizza script di avvio o post-avvio personalizzati che modificano la porta Jupyter predefinita o interrompono le dipendenze che potrebbero causare il blocco dell'istanza nello stato di provisioning.
    • Versione dell'ambiente: verifica se l'istanza utilizza l'ultima versione dell'ambiente controllando la sua possibilità di upgrade. Le versioni precedenti potrebbero causare il blocco dell'istanza nello stato di provisioning.
    • 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, memoria insufficiente o problemi di spazio su disco che potrebbero interrompere le normali operazioni.
    • Porta seriale di Compute Engine o logging di sistema dell'istanza: controlla se l'istanza ha log della porta seriale, che vengono analizzati per assicurarsi 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 utilizzare 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 bloccarsi nello stato di provisioning.
    • IP esterno disattivato: verifica se l'accesso all'IP esterno è disattivato. Una configurazione di rete errata può causare il blocco dell'istanza nello stato di provisioning.

    Google Cloud console

    1. Completa e copia il seguente comando. 
      2. gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE
    2. Apri la console Google Cloud e attiva Cloud Shell.
      3. Apri Cloud Console
    3. Incolla il comando copiato.
    4. Esegui il comando gcpdiag, che scarica l'immagine Docker gcpdiag e poi esegue i controlli diagnostici. Se applicabile, segui le istruzioni di output per correggere i controlli non riusciti.

    Docker

    Puoi eseguire gcpdiag utilizzando un wrapper che avvia gcpdiag in un container Docker. È necessario installare Docker o Podman.

    1. Copia ed esegui il seguente comando sulla tua workstation locale. 
      curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
    2. 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 all'interno del progetto.
    • ZONE: la zona in cui si trova l'istanza di Vertex AI Workbench di destinazione.

    Flag utili:

    Per un elenco e una descrizione di tutti i flag dello strumento gcpdiag, consulta le istruzioni per l'utilizzo di gcpdiag.

    Errori di autorizzazione durante l'utilizzo dei ruoli dell'account di servizio con Vertex AI

    Problema

    Quando utilizzi i ruoli del account di servizio con Vertex AI, si verificano errori di autorizzazione generali.

    Questi errori possono essere visualizzati in Cloud Logging nei log dei componenti del prodotto o nei log di controllo. Potrebbero anche essere visualizzati in qualsiasi combinazione dei progetti interessati.

    Questi problemi possono essere causati da uno o entrambi i seguenti motivi:

    • Utilizzo del ruolo Service Account Token Creator quando avrebbe dovuto essere utilizzato il ruolo Service Account User o viceversa. Questi ruoli concedono autorizzazioni diverse su un account di servizio e non sono intercambiabili. Per scoprire le differenze tra i ruoli Service Account Token Creator e Service Account User, consulta Ruoli degli account di servizio.

    • Hai concesso a un account di servizio autorizzazioni per più progetti, il che non è consentito per impostazione predefinita.

    Soluzione:

    Per risolvere il problema, prova una o più delle seguenti soluzioni:

    • Determina se è necessario il ruolo Service Account Token Creator o Service Account User. Per saperne di più, leggi la documentazione di IAM per i servizi Vertex AI che utilizzi, nonché per qualsiasi altra integrazione di prodotto che utilizzi.

    • Se hai concesso a un account di servizio autorizzazioni per più progetti, consenti l'allegato dei service account a più progetti assicurandoti che iam.disableCrossProjectServiceAccountUsage. non è applicata in modo forzato. Per assicurarti che iam.disableCrossProjectServiceAccountUsage non sia applicato, esegui questo comando:

      gcloud resource-manager org-policies disable-enforce \
  iam.disableCrossProjectServiceAccountUsage \
  --project=PROJECT_ID