Solução de problemas do Vertex AI Workbench

Nesta página, descrevemos as etapas de solução de problemas que podem ser úteis se você tiver problemas ao usar o Vertex AI Workbench.

Consulte também Solução de problemas da Vertex AI para receber ajuda ao usar outros componentes da Vertex AI.

Para filtrar o conteúdo desta página, clique em um tópico:

Qualquer instância do Vertex AI Workbench Notebooks gerenciados Notebooks gerenciados pelo usuário

Instâncias do Vertex AI Workbench

Nesta seção, descrevemos as etapas de solução de problemas das instâncias do Vertex AI Workbench.

Como se conectar e abrir o JupyterLab

Nesta seção, descrevemos as etapas de solução de problemas para se conectar e abrir o JupyterLab.

Nada acontece após clicar em Abrir JupyterLab

Problema

Quando você clica em Abrir JupyterLab, nada acontece.

Solução

Verifique se o navegador não impede que novas guias sejam abertas automaticamente. O JupyterLab é aberto em uma nova guia do navegador.

Não é possível acessar o terminal em uma instância do Vertex AI Workbench.

Problema

Se você não consegue acessar o terminal ou encontrar a janela do terminal na tela de início, isso pode ser porque a instância do Vertex AI Workbench não tem o acesso ao terminal ativado.

Solução

Crie uma nova instância do Vertex AI Workbench com a opção Acesso de terminal ativada. Essa opção não pode ser alterada após a criação da instância.

Erro 502 ao abrir o JupyterLab

Problema

Um erro 502 pode significar que sua instância do Vertex AI Workbench ainda não está pronta.

Solução

Aguarde alguns minutos, atualize a guia do navegador do Console do Google Cloud e tente novamente.

O notebook não responde

Problema

Sua instância do Vertex AI Workbench não está executando células ou parece estar congelada.

Solução

Primeiro, tente reiniciar o kernel clicando em Kernel no menu superior e depois em Reiniciar kernel. Se isso não funcionar, tente o seguinte:

• Atualize a página do navegador JupyterLab. A saída da célula não salva não persiste. Portanto, execute essas células novamente para gerar a saída novamente.
• Redefina a instância.

Não foi possível se conectar à instância do Vertex AI Workbench usando SSH

Problema

Não é possível se conectar à sua instância usando SSH em uma janela de terminal.

As instâncias do Vertex AI Workbench usam o Login do SO para permitir o acesso SSH. Quando você cria uma instância, o Vertex AI Workbench ativa o login do SO por padrão, definindo a chave de metadados enable-oslogin como TRUE. Se não for possível usar o SSH para se conectar à instância, talvez essa chave de metadados precise ser definida como TRUE.

Solução

Não há suporte para conexão com uma instância do Vertex AI Workbench usando o console do Google Cloud. Se você não conseguir se conectar à sua instância usando SSH em uma janela de terminal, consulte:

Para definir a chave de metadados enable-oslogin como TRUE, use o método projects.locations.instances.patch na API Notebooks ou o comandogcloud workbench instances update no SDK Google Cloud.

A cota de GPU foi excedida

Problema

Não é possível criar uma instância do Vertex AI Workbench com GPUs.

Solução

Consulte a página de cotas para saber o número de GPUs disponíveis no seu projeto. Se as GPUs não estiverem listadas nessa página ou se você precisar de mais cotas, solicite um aumento. Consulte Solicitar um limite de cota maior.

Como criar instâncias do Vertex AI Workbench

Esta seção descreve como solucionar problemas relacionados à criação de instâncias do Vertex AI Workbench.

A instância permanece no estado pendente indefinidamente ou fica presa no status de provisionamento

Problema

Depois de criar uma instância do Vertex AI Workbench, ela permanece no estado pendente indefinidamente. Um erro como este pode aparecer nos registros seriais:

Could not resolve host: notebooks.googleapis.com

Se a instância fica presa no status de provisionamento, isso pode ser porque você tem uma configuração de rede particular inválida para ela.

Solução

Dica: é possível usar gcpdiag para investigar uma instância que está presa no status de provisionamento.

Siga as etapas na seção Os registros da instância mostram erros de conexão ou de tempo limite.

Não é possível criar uma instância dentro de uma rede VPC compartilhada

Problema

A tentativa de criar uma instância em uma rede VPC compartilhada resulta em uma mensagem de erro como esta:

Required 'compute.subnetworks.use' permission for
'projects/network-administration/regions/us-central1/subnetworks/v'

Solução

O problema é que a conta de serviço de notebooks está tentando criar a instância sem as permissões corretas.

Para garantir que a conta de serviço de notebooks tenha as permissões necessárias para criar uma instância do Vertex AI Workbench em uma rede VPC compartilhada, peça ao administrador para conceder a ela o papel do IAM de Usuário da rede do Compute (roles/compute.networkUser) no projeto host. Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esse papel predefinido contém as permissões necessárias para garantir que a conta de serviço de notebooks possa criar uma instância do Vertex AI Workbench em uma rede VPC compartilhada. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As permissões a seguir são necessárias para garantir que a conta de serviço do Notebooks possa criar uma instância do Vertex AI Workbench em uma rede VPC compartilhada:

• Para usar sub-redes: compute.subnetworks.use

O administrador também pode conceder essas permissões à conta de serviço de notebooks com papéis personalizados ou outros papéis predefinidos.

Não é possível criar uma instância do Vertex AI Workbench com um contêiner personalizado

Problema

Não há opção para usar um contêiner personalizado ao criar uma instância do Vertex AI Workbench no console do Google Cloud.

Solução

Adicionar um contêiner personalizado a uma instância do Vertex AI Workbench não é compatível, e não é possível adicionar um contêiner personalizado usando o console do Google Cloud.

Adicionar um ambiente conda é recomendado em vez de usar um contêiner personalizado.

É possível adicionar um contêiner personalizado a uma instância do Vertex AI Workbench usando a API Notebooks, mas esse recurso não é compatível.

O botão "Ativar armazenamento compartilhado" não aparece

Problema

O botão Montar armazenamento compartilhado não aparece na guia Navegador de arquivos da interface do JupyterLab.

Solução

A permissão storage.buckets.list é necessária para que o botão Montar armazenamento compartilhado apareça na interface do JupyterLab da sua instância do Vertex AI Workbench. Peça ao administrador para conceder à conta de serviço da instância do Vertex AI Workbench a permissão storage.buckets.list no projeto.

Erro 599 ao usar o Dataproc.

Problema

A tentativa de criar uma instância ativada para Dataproc resulta em uma mensagem de erro como esta:

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

Solução

Na configuração do Cloud DNS, adicione uma entrada do Cloud DNS para o domínio *.googleusercontent.com.

Não foi possível instalar a extensão JupyterLab de terceiros

Problema

A tentativa de instalar uma extensão JupyterLab de terceiros resulta em uma mensagem Error: 500.

Solução

As extensões do JupyterLab de terceiros não são compatíveis com as instâncias do Vertex AI Workbench.

Não é possível editar a máquina virtual subjacente

Problema

Ao tentar editar a máquina virtual (VM) subjacente de uma instância do Vertex AI Workbench, é possível que você receba uma mensagem de erro semelhante a esta:

Current principal doesn't have permission to mutate this resource.

Solução

Esse erro ocorre porque não é possível editar a VM subjacente de uma instância usando o console do Google Cloud ou a API Compute Engine.

Para editar a VM subjacente de uma instância do Vertex AI Workbench, use o método projects.locations.instances.patch na API Notebooks ou o comando gcloud workbench instances update no SDK do Google Cloud.

pacotes pip não ficam disponíveis após a adição do ambiente conda

Problema

Seus pacotes pip não ficam disponíveis depois que você adiciona um kernel baseado em conda.

Solução

Para resolver o problema, consulte Adicionar um ambiente conda e tente o seguinte:

• Verifique se você usou a variável DL_ANACONDA_ENV_HOME e se ela contém o nome do ambiente.

• Verifique se pip está localizado em um caminho semelhante a opt/conda/envs/ENVIRONMENT/bin/pip. Execute o comando which pip para indicar o caminho.

Não é possível acessar ou copiar dados de uma instância com acesso de usuário único

Problema

Os dados em uma instância com acesso de usuário único ficam inacessíveis.

Para instâncias do Vertex AI Workbench configuradas com acesso de um único usuário, apenas o único usuário especificado (o proprietário) pode acessar os dados na instância.

Solução

Para acessar ou copiar os dados quando você não é o proprietário da instância, abra um caso de suporte.

Desligamento inesperado

Problema

Sua instância do Vertex AI Workbench é encerrada inesperadamente.

Solução

Se a instância for encerrada inesperadamente, pode ser que o desligamento inativo tenha sido iniciado.

Se você ativou o encerramento inativo, a instância será encerrada quando não houver atividade do kernel para o período especificado. Por exemplo, executar uma célula ou nova impressão de saída em um notebook é a atividade que redefine o timer de tempo limite de inatividade. O uso da CPU não redefine o timer de tempo limite de inatividade.

Os registros da instância mostram erros de conexão ou de tempo limite

Problema

Os registros da instância do Vertex AI Workbench mostram erros de conexão ou de tempo limite.

Solução

Se você notar erros de conexão ou de tempo limite nos registros da instância, verifique se o servidor Jupyter está em execução na porta 8080. Siga as etapas na seção Verificar se a API interna do Jupyter está ativa.

Se você desativou External IP e está usando uma rede VPC particular, siga a documentação de opções de configuração de rede. Considere o seguinte:

• Ative o acesso privado do Google na sub-rede escolhida na mesma região em que a instância está no projeto host da VPC. Para mais informações sobre como configurar o acesso privado do Google, consulte a documentação do acesso privado do Google.

• Ao usar o Cloud DNS, a instância precisa resolver os domínios do Cloud DNS necessários especificados na documentação de opções de configuração de rede. Para verificar isso, siga as etapas na seção Verificar se a instância pode resolver os domínios DNS necessários.

Os registros da instância mostram "Não é possível entrar em contato com a API Jupyter: ReadTimeoutError".

Problema

Os registros da instância do Vertex AI Workbench mostram um erro, como:

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

Solução

Siga as etapas na seção Os registros da instância mostram erros de conexão ou de tempo limite. Você também pode tentar modificar o script do agente de coleta de notebooks para mudar HTTP_TIMEOUT_SESSION para um valor maior, como 60, o que pode ajudar a verificar se a solicitação falhou devido a uma chamada que demorou muito para responder ou à impossibilidade de acessar o URL solicitado.

O endereço docker0 entra em conflito com o endereço da VPC

Problema

Por padrão, a interface docker0 é criada com um endereço IP de 172.17.0.1/16. Isso pode entrar em conflito com o endereçamento IP na rede VPC, de modo que a instância não consiga se conectar a outros endpoints com endereços 172.17.0.1/16.

Solução

É possível forçar a interface docker0 a ser criada com um endereço IP que não entre em conflito com a rede VPC usando o script pós-inicialização a seguir e definindo o comportamento do script pós-inicialização como 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
   

As reservas especificadas não existem.

Problema

A operação para criar a instância resulta em uma mensagem de erro Specified reservations do not exist. A saída da operação pode ser semelhante a esta:

{
  "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"
      }
    ]
  }
}

Solução

Alguns tipos de máquina do Compute Engine exigem parâmetros adicionais na criação, como discos locais ou uma plataforma de CPU mínima. A especificação de instância precisa incluir esses campos adicionais.

Por exemplo, o tipo de máquina a3-megagpu-8g exige 16 discos SSD locais, que precisam ser incluídos na reserva e especificados na solicitação de criação da instância.

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",
      },
    ],
  }
}'

Notebooks gerenciados

Os notebooks gerenciados do Vertex AI Workbench foram descontinuados. Em 30 de janeiro de 2025, o suporte a notebooks gerenciados será encerrado, e não será mais possível criar instâncias de notebooks gerenciados. As instâncias que já existem continuarão funcionando, mas patches, atualizações e upgrades não estarão disponíveis. Para continuar usando o Vertex AI Workbench, recomendamos que você migre suas instâncias de notebooks gerenciados para instâncias do Vertex AI Workbench.

Nesta seção, descrevemos as etapas de solução de problemas para notebooks gerenciados.

Como se conectar e abrir o JupyterLab

Nesta seção, descrevemos a solução de problemas de conexão e abertura do JupyterLab.

Nada acontece após clicar em Abrir JupyterLab

Problema

Quando você clica em Abrir JupyterLab, nada acontece.

Solução

Verifique se o navegador não impede que novas guias sejam abertas automaticamente. O JupyterLab é aberto em uma nova guia do navegador.

Não foi possível estabelecer conexão com a instância de notebooks gerenciados usando SSH

Problema

Não há uma opção para se conectar a instâncias de notebooks gerenciados usando SSH.

Solução

O acesso SSH às instâncias de notebooks gerenciados não está disponível.

Não é possível acessar o terminal em uma instância de notebooks gerenciados

Problema

Se você não conseguir acessar o terminal ou não conseguir encontrar a janela do terminal na tela de início, pode ser que a instância de notebooks gerenciados não tenha o acesso ao terminal ativado.

Solução

É preciso criar uma nova instância de notebooks gerenciados com a opção Acesso ao terminal ativada. Essa opção não pode ser alterada após a criação da instância.

Erro 502 ao abrir o JupyterLab

Problema

Um erro 502 pode significar que sua instância de notebooks gerenciados ainda não está pronta.

Solução

Aguarde alguns minutos, atualize a guia do navegador do Console do Google Cloud e tente novamente.

Abrir um notebook resulta no erro "524 (Tempo limite atingido)"

Problema

Um erro 524 geralmente é uma indicação de que o agente do Inverting Proxy não está se conectando ao servidor Inverting Proxy ou que as solicitações estão demorando muito no lado do servidor de back-end (Jupyter). As causas comuns desse erro incluem problemas de rede ou o agente do Inverting Proxy ou o serviço do Jupyter não estar em execução.

Solução

Verifique se a instância de notebooks gerenciados foi iniciada.

O notebook não responde

Problema

A instância de notebooks gerenciados não está executando células ou parece estar congelada.

Solução

Primeiro, tente reiniciar o kernel clicando em Kernel no menu superior e depois em Reiniciar kernel. Se isso não funcionar, tente o seguinte:

• Atualize a página do navegador JupyterLab. A saída da célula não salva não persiste. Portanto, execute essas células novamente para gerar a saída novamente.
• Redefina a instância.

Como migrar para instâncias do Vertex AI Workbench

Nesta seção, descrevemos métodos para diagnosticar e resolver problemas na migração de uma instância de notebooks gerenciados para uma instância do Vertex AI Workbench.

Não foi possível encontrar um kernel que estava na instância de notebooks gerenciados

Problema

Um kernel que estava na instância de notebooks gerenciados não aparece na instância do Vertex AI Workbench que você migrou.

Contêineres personalizados aparecem como kernels em notebooks gerenciados. A ferramenta de migração do Vertex AI Workbench não permite migração de contêineres personalizados.

Solução

Para resolver esse problema, adicione um ambiente conda à sua instância do Vertex AI Workbench.

Versão diferente do framework na instância migrada

Problema

Um framework que estava na instância de notebooks gerenciados era uma versão diferente daquela na instância do Vertex AI Workbench para a qual você migrou.

As instâncias do Vertex AI Workbench oferecem um conjunto padrão de versões de framework. A ferramenta de migração não adiciona versões de framework da sua instância original de notebooks gerenciados. Consulte os comportamentos padrão da ferramenta de migração.

Solução

Para adicionar uma versão específica de um framework, adicione um ambiente conda à sua instância do Vertex AI Workbench.

As GPUs não são migradas para a nova instância do Vertex AI Workbench

Problema

As GPUs que estavam na instância de notebooks gerenciados não estão na instância do Vertex AI Workbench para a qual você migrou.

As instâncias do Vertex AI Workbench são compatíveis com um conjunto padrão de GPUs. Se as GPUs na instância original de notebooks gerenciados não estiverem disponíveis, a instância será migrada sem GPUs.

Solução

Após a migração, é possível adicionar GPUs à sua instância do Vertex AI Workbench usando o método projects.locations.instances.patch na API Notebooks ou o comando gcloud workbench instances update no SDK Google Cloud.

O tipo de máquina da instância migrada é diferente

Problema

O tipo de máquina da sua instância de notebooks gerenciados é diferente da instância do Vertex AI Workbench para a qual você migrou.

As instâncias do Vertex AI Workbench não aceitam todos os tipos de máquina. Se o tipo de máquina na instância original de notebooks gerenciados não estiver disponível, a instância será migrada para o tipo de máquina e2-standard-4.

Solução

Após a migração, é possível alterar o tipo de máquina da sua instância do Vertex AI Workbench usando o método projects.locations.instances.patch na API Notebooks ou o comando gcloud workbench instances update no SDK Google Cloud.

A cota de GPU foi excedida

Problema

Você não consegue criar uma instância de notebooks gerenciados com GPUs.

Solução

Consulte a página de cotas para saber o número de GPUs disponíveis no seu projeto. Se as GPUs não estiverem listadas nessa página ou você precisar de mais cotas, solicite um aumento. Consulte Solicitar um limite de cota maior.

Como usar imagens de contêiner

Nesta seção, descrevemos a solução de problemas relacionados ao uso de imagens de contêiner.

A imagem do contêiner não aparece como um kernel no JupyterLab

Problema

As imagens de contêiner que não têm um kernelspec válido não são carregadas como kernels no JupyterLab.

Solução

Verifique se o contêiner atende aos nossos requisitos. Para mais informações, consulte os requisitos de contêineres personalizados.

O notebook é desconectado em um job de longa duração

Problema

Se você vir a mensagem de erro a seguir ao executar um job em um notebook, talvez isso seja causado por uma solicitação que demora muito para carregar ou porque a utilização da CPU ou da memória é alta, o que pode fazer com que o serviço do Jupyter não responda.

{"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"}

Solução

Esse problema é causado pela execução de um job de longa duração em um notebook. Para executar um job que pode levar muito tempo para ser concluído, é recomendável usar o executor.

Como usar o executor

Nesta seção, descrevemos a solução de problemas com o uso do executor.

Instalações de pacote não disponíveis para o executor

Observação :verifique se a nuvem privada virtual permite acesso ao PyPI e ao VPC Service Controls e se a política da organização não bloqueia o acesso.

Problema

O executor executa o código do notebook em um ambiente separado do kernel em que o código do arquivo do notebook é executado. Por isso, alguns dos pacotes instalados podem não estar disponíveis no ambiente do executor.

Solução

Para resolver esse problema, consulte Garantir que as instalações de pacotes estejam disponíveis para o executor.

Erros 401 ou 403 ao executar o código do notebook usando o executor

Problema

Um erro 401 ou 403 ao executar o executor pode significar que ele não pode acessar recursos.

Solução

Consulte as possíveis causas a seguir:

• O executor executa o código do notebook em um projeto de locatário separado do projeto da instância de notebooks gerenciados. Portanto, quando você acessa recursos com o código executado pelo executor, ele pode não se conectar ao projeto Google Cloud correto por padrão. Para resolver esse problema, use a seleção explícita do projeto.

• Por padrão, a instância de notebooks gerenciados pode ter acesso a recursos no mesmo projeto e, portanto, quando você executa manualmente o código do arquivo de notebook, esses recursos não precisam de outra autenticação. No entanto, como o executor é executado em um projeto de locatário separado, ele não tem o mesmo acesso padrão. Para resolver esse problema, autentique o acesso usando contas de serviço.

• O executor não pode usar credenciais de usuário final para autenticar o acesso a recursos, por exemplo, o comando gcloud auth login. Para resolver esse problema, autentique o acesso usando contas de serviço.

Erro exited with a non-zero status of 127 ao usar o executor.

Problema

Um erro exited with a non-zero status of 127 ou "comando não encontrado" pode ocorrer ao usar o executor para executar código em um contêiner personalizado que não tenha a extensão nbexecutor instalada.

Solução

Para garantir que o contêiner personalizado tenha a extensão nbexecutor, crie uma imagem derivada do contêiner a partir de uma imagem do Deep Learning Containers. As imagens do Deep Learning Containers incluem a extensão nbexecutor.

Mensagem de erro de configuração inválida de rede de serviço

Problema

Esse erro pode ter a seguinte aparência:

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

Isso significa que nenhum bloco livre foi encontrado nos intervalos de IP alocados da sua rede.

Solução

Use uma máscara de sub-rede de /24 ou menos. Crie um intervalo de endereço IP alocado mais longo e anexe-o modificando a conexão de serviço particular para servicenetworking-googleapis-com.

Para mais informações, consulte Configurar uma rede.

Não foi possível instalar a extensão JupyterLab de terceiros

Problema

A tentativa de instalar uma extensão JupyterLab de terceiros resulta em uma mensagem Error: 500.

Solução

As extensões terceirizadas do JupyterLab não são compatíveis com instâncias de notebooks gerenciados.

Não é possível acessar ou copiar dados de uma instância com acesso de usuário único

Problema

Os dados em uma instância com acesso de usuário único ficam inacessíveis.

Solução

Para instâncias de notebooks gerenciados configuradas com acesso de usuário único, somente esse usuário especificado (o proprietário) pode acessar os dados na instância.

Para acessar ou copiar os dados quando você não é o proprietário da instância, abra um caso de suporte.

Desligamento inesperado

Problema

Sua instância do Vertex AI Workbench é encerrada inesperadamente.

Solução

Se a instância for encerrada inesperadamente, pode ser que o desligamento inativo tenha sido iniciado.

Se você ativou o encerramento inativo, a instância será encerrada quando não houver atividade do kernel para o período especificado. Por exemplo, executar uma célula ou nova impressão de saída em um notebook é a atividade que redefine o timer de tempo limite de inatividade. O uso da CPU não redefine o timer de tempo limite de inatividade.

Restaurar instância

Problema

Não é possível restaurar uma instância de notebooks gerenciados depois que ela é excluída.

Solução

Para fazer backup dos dados na instância, salve seus notebooks no GitHub.

Recuperar dados de uma instância

Problema

Não é possível recuperar dados de uma instância de notebooks gerenciados após a exclusão.

Solução

Para fazer backup dos dados na instância, salve seus notebooks no GitHub.

Como criar instâncias de notebooks gerenciados

Nesta seção, descrevemos a solução de problemas com a criação de instâncias de notebooks gerenciados.

Erro: problema ao criar uma conexão

Problema

Se você encontrar este erro ao criar uma instância:

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

Solução

Crie um intervalo de IP alocado maior que /24 e anexe esse intervalo modificando a conexão de serviço particular para a conexão servicenetworking-googleapis-com.

Criar uma instância resulta em um erro de disponibilidade de recurso

Problema

Não é possível criar uma instância devido a um erro de disponibilidade de recursos.

Esse erro pode ser assim:

Creating notebook INSTANCE_NAME: ZONE does not have
enough resources available to fulfill the request.
Retry later or try another zone in your configurations.

Os erros de recurso ocorrem quando você solicita novos recursos em uma zona que não pode acomodar sua solicitação devido à indisponibilidade atual de recursos do Compute Engine, como GPUs ou CPUs.

Os erros de recurso só se aplicam a novas solicitações de recursos na zona e não afetam os recursos que já existem. Os erros de recurso não estão relacionados à sua cota do Compute Engine. Os erros de recurso são temporários e podem mudar com frequência com base na flutuação da demanda.

Solução

Para continuar, tente isto:

• Crie uma instância com um tipo de máquina diferente.
• Crie a instância em uma zona diferente.
• Tente refazer a solicitação mais tarde.
• Reduza a quantidade de recursos solicitados. Por exemplo, tente criar uma instância com menos GPUs, discos, vCPUs ou memória.

Criar uma instância resulta em um erro de disponibilidade de recurso

Problema

Não é possível iniciar uma instância devido a um erro de disponibilidade de recursos.

Esse erro pode ser assim:

The zone ZONE_NAME doesn't have enough resources available to fulfill
the request. '(resource type:compute)'.

Os erros de recurso ocorrem quando você tenta iniciar uma instância em uma zona que não pode acomodar sua solicitação devido à indisponibilidade atual dos recursos do Compute Engine, como GPUs ou CPUs.

Os erros de recurso se aplicam somente aos recursos especificados na solicitação no momento em que você a envia, e não a todos os recursos da zona. Os erros de recurso não estão relacionados à sua cota do Compute Engine. Os erros de recurso são temporários e podem mudar com frequência com base na variação da demanda.

Solução

Para continuar, tente isto:

• Altere o tipo de máquina da instância.
• Migre seus arquivos e dados para uma instância em uma zona diferente.
• Tente refazer a solicitação mais tarde.
• Reduza a quantidade de recursos solicitados. Por exemplo, inicie uma VM diferente com menos GPUs, discos, vCPUs ou memória.

No route to host em conexões de saída de notebooks gerenciados

Problema

Normalmente, as únicas rotas que podem ser encontradas no console do Google Cloud são aquelas conhecidas pela própria VPC, bem como os intervalos reservados quando você realiza a configuração de peering de rede VPC.

As instâncias de notebooks gerenciados residem em uma rede gerenciada pelo Google e executam uma versão modificada do Jupyter em um namespace de rede do Docker na instância.

A interface de rede do Docker e a ponte do Linux nessa instância podem selecionar um IP local que esteja em conflito com os intervalos de IP que estão sendo exportados pelo peering pela VPC. Normalmente, eles estão nos intervalos 172.16.0.0/161 e 192.168.10.0/24, respectivamente.

Nessas circunstâncias, as conexões de saída da instância para esses intervalos falharão com uma reclamação que é alguma variação de No route to host, mesmo que as rotas de VPC estejam sendo compartilhadas corretamente.

Observação: os endereços IP de origem das conexões de saída da instância ainda são convertidos para o intervalo de peering selecionado.

Solução

Invoque ifconfig em uma sessão de terminal e confirme se nenhum endereço IP em nenhuma interface virtual na instância entra em conflito com os intervalos de IP que a VPC está exportando para a conexão de peering.

Notebooks gerenciados pelo usuário

Os notebooks gerenciados pelo usuário do Vertex AI Workbench foram descontinuados. Em 30 de janeiro de 2025, o suporte a notebooks gerenciados pelo usuário será encerrado, e não será mais possível criar instâncias de notebooks gerenciados pelo usuário. As instâncias que já existem continuarão funcionando, mas patches, atualizações e upgrades não estarão disponíveis. Para continuar usando o Vertex AI Workbench, recomendamos que você migre suas instâncias de notebooks gerenciados pelo usuário para instâncias do Vertex AI Workbench.

Nesta seção, descrevemos as etapas de solução de problemas para notebooks gerenciados pelo usuário.

Como se conectar e abrir o JupyterLab

Nesta seção, descrevemos a solução de problemas de conexão e abertura do JupyterLab.

Nada acontece após clicar em Abrir JupyterLab

Problema

Quando você clica em Abrir JupyterLab, nada acontece.

Solução

Verifique se o navegador não impede que novas guias sejam abertas automaticamente. O JupyterLab é aberto em uma nova guia do navegador.

Não há acesso do servidor do Inverting Proxy ao JupyterLab

Problema

Você não consegue acessar o JupyterLab.

O Vertex AI Workbench usa um servidor Inverting Proxy interno do Google para fornecer acesso ao JupyterLab. Configurações de instância de notebooks gerenciados pelo usuário, configuração de rede e outros fatores podem impedir o acesso ao JupyterLab.

Solução

Use o SSH para se conectar ao JupyterLab e saber mais sobre por que você talvez não tenha acesso pelo Inverting Proxy.

Não foi possível estabelecer conexão com a instância de notebooks gerenciados pelo usuário usando SSH

Problema

Não é possível se conectar à sua instância usando SSH em uma janela de terminal.

As instâncias de notebooks gerenciados pelo usuário usam o Login do SO para ativar o acesso SSH. Quando você cria uma instância, o Vertex AI Workbench ativa o Login do SO por padrão, definindo a chave de metadados enable-oslogin como TRUE. Se não for possível usar o SSH para se conectar à instância, talvez essa chave de metadados precise ser definida como TRUE.

Solução

Para ativar o acesso SSH dos notebooks gerenciados pelo usuário para os usuários, conclua as etapas de configuração de papéis do Login do SO em contas de usuário.

Abrir uma instância de notebooks gerenciados pelo usuário resulta em um erro 403 (Proibido)

Problema

Um erro 403 (Forbidden) ao abrir uma instância de notebooks gerenciados pelo usuário geralmente indica que há um problema de acesso.

Solução

Para resolver problemas de acesso, considere as três maneiras de conceder acesso a uma instância de notebooks gerenciados pelo usuário:

• Único usuário
• Conta de serviço
• Editores de projetos

O modo de acesso é configurado durante a criação da instância de notebooks gerenciados pelo usuário e é definido nos metadados do notebook:

• Único usuário: proxy-mode=mail, proxy-user-mail=[e-mail]
• Conta de serviço: proxy-mode=service_account
• Editores de projeto: proxy-mode=project_editors

Cuidado: não é possível alterar os metadados do modo de acesso e pode tornar a interface do usuário do JupyterLab inacessível.

.

Se você não conseguir acessar um notebook ao clicar em Abrir JupyterLab, tente isto:

• Verifique se a entrada de metadados proxy-mode está correta.

• Verifique se o usuário que acessa a instância tem a permissão iam.serviceAccounts.ActAs para a conta de serviço da instância. A conta de serviço é a conta de serviço padrão do Compute Engine ou uma conta de serviço especificada na criação da instância.

• Se a instância usar o acesso de usuário único com uma conta de serviço especificada como o usuário único, consulte Sem acesso ao JupyterLab, modo de usuário único ativado.

O exemplo a seguir mostra como especificar uma conta de serviço ao criar uma instância:

gcloud notebooks instances create nb-1 \
  --vm-image-family=tf-latest-cpu \
  --metadata=proxy-mode=mail,proxy-user-mail=[e-mail] \
  --service-account=your_service_account@project_id.iam.gserviceaccount.com \
  --location=us-west1-a

Quando você clica em Abrir JupyterLab para abrir um notebook, ele abre em uma nova guia do navegador. Se você tiver feito login em mais de uma conta do Google, a nova guia abrirá com a conta padrão. Se você não criou a instância de notebooks gerenciados pelo usuário com sua Conta do Google padrão, a nova guia do navegador mostrará o erro 403 (Forbidden).

Sem acesso ao JupyterLab, modo de usuário único ativado

Problema

Você não consegue acessar o JupyterLab.

Solução

Se um usuário não conseguir acessar o JupyterLab e o acesso da instância ao JupyterLab estiver definido como Single user only, tente isto:

1. Na página Notebooks gerenciados pelo usuário do console do Google Cloud, clique no nome da instância para abrir a página Detalhes do notebook.

2. Ao lado de Visualizar detalhes da VM, clique em Visualizar no Compute Engine.

3. Na página de detalhes da VM, clique em Editar.

4. Na seção Metadados, verifique se a entrada de metadados proxy-mode está definida como mail.

5. Verifique se a entrada de metadados proxy-user-mail está definida como um endereço de e-mail válido do usuário, não uma conta de serviço.

6. Clique em Salvar.

7. Na página de notebooks gerenciados pelo usuário do Console do Google Cloud, inicialize os metadados atualizados interrompendo a instância e reiniciando a instância.

Abrir um notebook resulta no erro "504 (Tempo limite do gateway)"

Problema

Essa é uma indicação de um tempo limite do proxy interno ou de um servidor de back-end (Jupyter). Ele é exibido nas seguintes situações:

• A solicitação nunca chegou ao servidor Inverting Proxy interno
• O back-end (Jupyter) retorna um erro 504.

Solução

Abra um caso de suporte do Google.

Abrir um notebook resulta no erro "524 (Tempo limite atingido)"

Problema

O servidor Inverting Proxy interno não recebeu uma resposta do agente do Inverting Proxy para a solicitação dentro do tempo limite. O agente do Inverting Proxy é executado na instância de notebooks gerenciados pelo usuário como um contêiner do Docker. Um erro 524 geralmente é uma indicação de que o agente do Inverting Proxy não está se conectando ao servidor Inverting Proxy ou que as solicitações estão demorando muito no lado do servidor de back-end (Jupyter). Um caso típico desse erro está no lado do usuário (por exemplo, um problema na rede ou o agente do Inverting Proxy ou serviço do Jupyter não estar em execução).

Solução

Se não for possível acessar um notebook, verifique se a instância de notebooks gerenciados pelo usuário foi iniciada e tente isto:

Opção 1: execute a ferramenta de diagnóstico para verificar e reparar automaticamente os serviços principais de notebooks gerenciados pelo usuário, verifique o armazenamento disponível e gere arquivos de registro úteis. Para executar a ferramenta na sua instância, realize as seguintes etapas:

1. Verifique se a instância está na versão M58 ou mais recente.

2. Conecte-se à instância de imagens da VM de aprendizado profundo usando SSH.

3. Execute este comando:

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

   As sinalizações --repair e --bucket são opcionais. A flag --repair tentará corrigir os principais erros comuns de serviço e a flag --bucket permitirá que você especifique um bucket do Cloud Storage para armazenar os arquivos de registros criados.

   A saída desse comando exibirá mensagens de status úteis para os serviços principais de notebooks gerenciados pelo usuário e exportará os arquivos de registro das descobertas.

Opção 2: use as etapas a seguir para verificar requisitos específicos de notebooks gerenciados pelo usuário individualmente.

• Verifique se o disco da instância de notebooks gerenciados pelo usuário não está sem espaço.

  1. Conecte-se à instância de imagens da VM de aprendizado profundo usando SSH.

  2. Execute este comando:

     df -h -T /home/jupyter

     Se Use% for maior que 85%, você vai precisar excluir manualmente os arquivos de /home/jupyter. O primeiro passo é esvaziar a lixeira com o seguinte comando:

     sudo rm -rf  /home/jupyter/.local/share/Trash/*

• Verifique se o serviço do Docker foi iniciado.

• Verifique se o agente do Inverting Proxy está em execução. Se o agente for iniciado, reinicie-o.

• Verifique se o serviço do Jupyter está em execução. Se estiver, tente reiniciá-lo.

• Verifique a utilização da memória na instância de notebooks gerenciados pelo usuário.

  1. Conecte-se à instância de VM de aprendizado profundo usando SSH.

  2. Execute este comando:

     free -t -h

     Se a memória usada for maior que 85% do total, considere mudar o tipo de máquina.

  3. É possível instalar o agente do Cloud Monitoring para monitorar se há alto uso de memória na instância do Notebooks. Veja as informações de preços.

• Verifique se você está usando a VM de aprendizado profundo versão M55 ou posterior. Para saber mais sobre upgrade, consulte Fazer upgrade do ambiente de uma instância de notebook gerenciada pelo usuário.

Abrir um notebook resulta no erro "598 (Tempo limite de leitura da rede)"

Problema

O servidor Inverting Proxy não se comunica com o agente do Inverting Proxy há mais de 10 minutos. Isso é um forte indicador de um problema do agente do Inverting Proxy.

Solução

Se não for possível acessar um notebook, tente o seguinte:

• Verifique se a instância de notebooks gerenciados pelo usuário foi iniciada.

• Verifique se o serviço do Docker foi iniciado.

• Verifique se o agente do Inverting Proxy está em execução. Se o agente for iniciado, reinicie-o.

• Verifique se o serviço do Jupyter está em execução. Se estiver, tente reiniciá-lo.

• Verifique se você está usando a VM de aprendizado profundo versão M55 ou posterior. Para saber mais sobre upgrade, consulte Fazer upgrade do ambiente de uma instância de notebook gerenciada pelo usuário.

O notebook não responde

Problema

Sua instância de notebooks gerenciados pelo usuário não está executando células ou parece estar congelada.

Solução

Primeiro, tente reiniciar o kernel clicando em Kernel no menu superior e depois em Reiniciar kernel. Se isso não funcionar, tente o seguinte:

• Atualize a página do navegador JupyterLab. Qualquer saída de célula não salva não persiste. Portanto, execute essas células novamente para gerar a saída outra vez.
• Em uma sessão de terminal no notebook, execute o comando top para ver se há processos que consomem a CPU.
• No terminal, verifique a quantidade de espaço livre em disco usando o comando df ou verifique a RAM disponível usando o comando free.
• Encerre a instância selecionando-a na página de notebooks gerenciados pelo usuário e clicando em Parar. Depois que ela parar completamente, selecione-a e clique em Iniciar.

Como migrar para instâncias do Vertex AI Workbench

Nesta seção, descrevemos métodos para diagnosticar e resolver problemas na migração de uma instância de notebooks gerenciados pelo usuário para uma instância do Vertex AI Workbench.

Não foi possível encontrar R, Beam ou outros kernels que estavam na instância de notebooks gerenciados pelo usuário.

Problema

Um kernel que estava na instância de notebooks gerenciados pelo usuário não aparece na instância do Vertex AI Workbench para a qual você migrou.

Alguns kernels, como os de R e Beam, não estão disponíveis nas instâncias do Vertex AI Workbench por padrão. A migração desses kernels não é possível.

Solução

Para resolver esse problema, adicione um ambiente conda à sua instância do Vertex AI Workbench.

Não é possível configurar uma instância do Dataproc Hub na instância do Vertex AI Workbench

Problema

O Dataproc Hub não é compatível com instâncias do Vertex AI Workbench.

Solução

Continue a usar o Dataproc Hub em instâncias de notebooks gerenciados pelo usuário.

Versão diferente do framework na instância migrada

Problema

Um framework que estava na instância de notebooks gerenciados pelo usuário era uma versão diferente daquele na instância do Vertex AI Workbench para que você migrou.

As instâncias do Vertex AI Workbench oferecem um conjunto padrão de versões de framework. A ferramenta de migração não adiciona versões de framework da instância original de notebooks gerenciados pelo usuário. Consulte os comportamentos padrão da ferramenta de migração.

Solução

Para adicionar uma versão específica de um framework, adicione um ambiente conda à sua instância do Vertex AI Workbench.

As GPUs não são migradas para a nova instância do Vertex AI Workbench

Problema

As GPUs que estavam na instância de notebooks gerenciados pelo usuário não estão na instância do Vertex AI Workbench para a qual você migrou.

As instâncias do Vertex AI Workbench são compatíveis com um conjunto padrão de GPUs. Se as GPUs na instância original de notebooks gerenciados pelo usuário não estiverem disponíveis, a instância será migrada sem GPUs.

Solução

Após a migração, é possível adicionar GPUs à sua instância do Vertex AI Workbench usando o método projects.locations.instances.patch na API Notebooks ou a função gcloud workbench instances update no SDK do Google Cloud.

O tipo de máquina da instância migrada é diferente

Problema

O tipo de máquina da sua instância de notebooks gerenciados pelo usuário é diferente da instância do Vertex AI Workbench para a qual você migrou.

As instâncias do Vertex AI Workbench não aceitam todos os tipos de máquina. Se o tipo de máquina na instância original de notebooks gerenciados pelo usuário não estiver disponível, a instância será migrada para o tipo de máquina e2-standard-4.

Solução

Após a migração, é possível alterar o tipo de máquina da sua instância do Vertex AI Workbench usando o método projects.locations.instances.patch na API Notebooks ou a guia gcloud workbench instances update no SDK do Google Cloud.

Como trabalhar com arquivos

Nesta seção, descrevemos a solução de problemas com arquivos para instâncias de notebooks gerenciados pelo usuário.

Download de arquivos desativado, mas o usuário ainda pode fazer o download de arquivos

Problema

Para instâncias de notebooks gerenciados pelo usuário do Dataproc Hub, não é possível desativar o download de arquivos da interface do usuário do JupyterLab. As instâncias de notebooks gerenciadas pelo usuário que usam o framework do Dataproc Hub permitem o download de arquivos, mesmo que você não selecione Ativar o download de arquivos da interface do JupyterLab ao criar a instância.

Solução

As instâncias de notebooks gerenciados pelo usuário do Dataproc Hub não aceitam a restrição de downloads de arquivos.

Os arquivos transferidos por download estão truncados ou o download não é concluído

Problema

Quando você faz o download de arquivos da instância de notebooks gerenciados pelo usuário, uma configuração de tempo limite no agente de encaminhamento de proxy limita o tempo de conexão para a conclusão do download. Se o download demora muito, isso pode truncar o arquivo de download ou impedir que o download seja feito.

Solução

para baixar o arquivo, copie-o para o Cloud Storage e faça o download do arquivo pelo Cloud Storage.

Considere migrar seus arquivos e dados para uma nova instância de notebooks gerenciados pelo usuário.

Depois de reiniciar a VM, não é possível fazer referência aos arquivos locais por terminal de notebook

Problema

Às vezes, depois de reiniciar uma instância de notebooks gerenciados pelo usuário, não possível fazer referência aos arquivos locais em um terminal de notebook.

Solução

Esse é um problema conhecido. Para fazer referência aos arquivos locais a partir de um terminal de notebook, primeiro restabeleça o diretório de trabalho atual usando o seguinte comando:

cd PWD

Neste comando, substitua PWD pelo diretório de trabalho atual. Por exemplo, se o diretório de trabalho atual for /home/jupyter/, use o comando cd /home/jupyter/.

Depois de restabelecer o diretório de trabalho atual, os arquivos locais podem ser referenciados no terminal do notebook.

Como criar instâncias de notebooks gerenciados pelo usuário

Nesta seção, descrevemos a solução de problemas com a criação de instâncias de notebooks gerenciados pelo usuário.

A cota de GPU foi excedida

Problema

Você não consegue criar uma instância de notebooks gerenciados com GPUs.

Solução

Consulte a página de cotas para saber o número de GPUs disponíveis no seu projeto. Se as GPUs não estiverem listadas nessa página ou se você precisar de mais cotas, solicite um aumento. Consulte Solicitar um limite de cota maior.

A instância permanece no estado pendente indefinidamente

Problema

Depois de criar uma instância de notebooks gerenciados pelo usuário, ela permanece no estado pendente indefinidamente. Um erro como este pode aparecer nos registros seriais:

Could not resolve host: notebooks.googleapis.com

Solução

Não é possível conectar sua instância ao servidor da API Notebooks devido a uma configuração do Cloud DNS ou outro problema de rede. Para resolver o problema, verifique suas configurações do Cloud DNS e de rede. Para mais informações, consulte a seção de opções de configuração de rede.

Nova instância de notebooks gerenciados pelo usuário não criada (permissões insuficientes)

Problema

Geralmente, leva cerca de um minuto para criar uma instância de notebooks gerenciados pelo usuário. Se a nova instância de notebooks gerenciados pelo usuário permanecer no estado pending indefinidamente, talvez a conta de serviço usada para iniciar essa instância não tenha as permissões necessárias no projeto Google Cloud .

Inicie uma instância de notebooks gerenciados pelo usuário com uma conta de serviço personalizada que você criou ou no modo de usuário único com um ID de usuário. Se você iniciar uma instância de notebooks gerenciados pelo usuário no modo de usuário único, ela iniciará o processo de inicialização usando a conta de serviço padrão do Compute Engine antes de passar o controle para o ID de usuário.

Solução

Para verificar se uma conta de serviço tem as permissões apropriadas, siga estas etapas:

Console

1. Abra a página "IAM" no console do Google Cloud.

   Abrir a página do IAM

2. Determine a conta de serviço usada com sua instância de notebooks gerenciados pelo usuário, que é uma das seguintes opções:

   • Uma conta de serviço personalizada especificada ao criar a instância de notebooks gerenciados pelo usuário.

   • A conta de serviço padrão do Compute Engine para o projeto Google Cloud , usada ao iniciar a instância de notebooks gerenciados pelo usuário no modo de usuário único. A conta de serviço padrão do Compute Engine para o projeto Google Cloud é chamada de [e-mail]. Exemplo: [e-mail].

3. Verifique se a conta de serviço tem o papel de Executor de notebooks (roles/notebooks.runner). Se ela não tiver, conceda a ele esse papel (roles/notebooks.runner).

Para mais informações, consulte Como conceder, alterar e revogar o acesso a recursos na documentação do IAM.

gcloud

1. Instale a CLI do Google Cloud, caso ainda não tenha feito isso.

2. Use o comando a seguir para conferir o nome e o número do projeto Google Cloud . Substitua PROJECT_ID pelo ID do projetoGoogle Cloud .

   gcloud projects describe PROJECT_ID
   

   Você verá uma saída semelhante à abaixo, que exibe o nome (name:) e o número (projectNumber:) do seu projeto.

   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. Determine a conta de serviço usada com a instância de notebooks gerenciados pelo usuário, que é uma das seguintes opções:

   • Uma conta de serviço personalizada especificada ao criar a instância de notebooks gerenciados pelo usuário.

   • A conta de serviço padrão do Compute Engine para o projeto Google Cloud , usada ao iniciar a instância de notebooks gerenciados pelo usuário no modo de usuário único. A conta de serviço padrão do Compute Engine para o projeto Google Cloud é chamada de [e-mail]. Exemplo: [e-mail].

4. Use o comando a seguir para atribuir o papel roles/notebooks.runner à conta de serviço. Substitua project-name pelo nome do projeto e service-account-id pelo ID da conta de serviço da instância de notebooks gerenciada pelo usuário.

   gcloud projects add-iam-policy-binding project-name \
    --member serviceAccount:service-account-id \
    --role roles/notebooks.runner
   

Criar uma instância resulta em um erro Permission denied

Problema

A conta de serviço na instância fornece acesso a outros serviços Google Cloud. É possível usar qualquer conta de serviço no mesmo projeto, mas é necessário ter a permissão de usuário da conta de serviço (iam.serviceAccounts.actAs) para criar a instância. Se não for especificada, a conta de serviço padrão do Compute Engine será usada.

Solução

Ao criar uma instância, verifique se o usuário que a cria tem a permissão iam.serviceAccounts.ActAs para a conta de serviço definida.

O exemplo a seguir mostra como especificar uma conta de serviço ao criar uma instância:

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

Para conceder o papel de usuário da conta de serviço, consulte Gerenciar acesso a contas de serviço.

Criar uma instância resulta em um erro already exists

Problema

Ao criar uma instância, verifique se uma instância de notebooks gerenciados pelo usuário com o mesmo nome não foi excluída anteriormente pelo Compute Engine e ainda existe no banco de dados da API Notebooks.

Solução

No exemplo a seguir, veja como listar instâncias usando a API Notebooks e verificar o estado delas.

gcloud notebooks instances list --location=LOCATION

Se o estado de uma instância for DELETED, execute o comando a seguir para excluí-la permanentemente.

gcloud notebooks instances delete INSTANCE_NAME --location=LOCATION

Não é possível criar uma instância em uma VPC compartilhada

Problema

Você não consegue criar uma instância em uma VPC compartilhada.

Solução

Se você estiver usando uma VPC compartilhada, será necessário adicionar o host e os projetos de serviço ao perímetro de serviço. No projeto host, também é necessário conceder o papel de Usuário da rede do Compute (roles/compute.networkUser) ao Agente de serviço de notebooks no projeto de serviço. Para mais informações, consulte Como gerenciar perímetros de serviço.

Criar uma instância resulta em um erro de disponibilidade de recurso

Problema

Não é possível criar uma instância devido a um erro de disponibilidade de recursos.

Esse erro pode ser assim:

Creating notebook INSTANCE_NAME: ZONE does not have enough
resources available to fulfill the request. Retry later or try another zone in
your configurations.

Os erros de recurso ocorrem quando você solicita novos recursos em uma zona que não pode acomodar sua solicitação devido à indisponibilidade atual de recursos do Compute Engine, como GPUs ou CPUs.

Os erros de recurso só se aplicam a novas solicitações de recursos na zona e não afetam os recursos que já existem. Os erros de recurso não estão relacionados à sua cota do Compute Engine. Os erros de recurso são temporários e podem mudar com frequência com base na flutuação da demanda.

Solução

Para continuar, tente isto:

• Crie uma instância com um tipo de máquina diferente.
• Crie a instância em uma zona diferente.
• Tente refazer a solicitação mais tarde.
• Reduza a quantidade de recursos solicitados. Por exemplo, tente criar uma instância com menos GPUs, discos, vCPUs ou memória.

Criar uma instância resulta em um erro de disponibilidade de recurso

Problema

Não é possível iniciar uma instância devido a um erro de disponibilidade de recursos.

Esse erro pode ser assim:

The zone ZONE_NAME doesn't have enough resources available to fulfill
the request. '(resource type:compute)'.

Os erros de recurso ocorrem quando você tenta iniciar uma instância em uma zona que não pode acomodar sua solicitação devido à indisponibilidade atual dos recursos do Compute Engine, como GPUs ou CPUs.

Os erros de recurso se aplicam somente aos recursos especificados na solicitação no momento em que você a envia, e não a todos os recursos da zona. Os erros de recurso não estão relacionados à sua cota do Compute Engine. Os erros de recurso são temporários e podem mudar com frequência com base na variação da demanda.

Solução

Para continuar, tente isto:

• Altere o tipo de máquina da instância.
• Migre seus arquivos e dados para uma instância em uma zona diferente.
• Tente refazer a solicitação mais tarde.
• Reduza a quantidade de recursos solicitados. Por exemplo, inicie uma VM diferente com menos GPUs, discos, vCPUs ou memória.

Como fazer upgrade de instâncias de notebooks gerenciados pelo usuário

Esta seção descreve a solução de problemas com o upgrade de instâncias de notebooks gerenciados pelo usuário.

Não foi possível fazer o upgrade porque não foi possível receber as informações do disco da instância

Problema

O upgrade não é compatível com instâncias de notebooks gerenciados pelo usuário de disco único.

Solução

É recomendável migrar os dados do usuário para uma nova instância de notebooks gerenciados pelo usuário.

Não foi possível fazer upgrade porque a instância não é compatível com UEFI

Problema

O Vertex AI Workbench depende da compatibilidade com UEFI para concluir um upgrade.

As instâncias de notebooks gerenciados pelo usuário criadas com base em algumas imagens mais antigas não são compatíveis com UEFI. Por isso, o upgrade delas não é possível.

Solução

Para verificar se a instância é compatível com UEFI, digite o seguinte comando no Cloud Shell ou em qualquer ambiente em que a CLI do Google Cloud esteja instalada.

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

Substitua:

• INSTANCE_NAME: o nome da instância
• ZONE: a zona em que a instância está localizada

Para verificar se a imagem usada para criar a instância é compatível com UEFI, use o seguinte comando:

gcloud compute images describe VM_IMAGE_FAMILY \
  --project deeplearning-platform-release | grep type

Substitua VM_IMAGE_FAMILY pelo nome da família de imagens usado para criar a instância.

Se você constatar que sua instância ou imagem não é compatível com UEFI, tente migrar os dados dos usuários para uma nova instância de notebooks gerenciados pelo usuário. Para isso, siga as etapas abaixo:

1. Verifique se a imagem que você quer usar para criar a nova instância é compatível com UEFI. Para fazer isso, digite o seguinte comando no Cloud Shell ou em qualquer ambiente em que a Google Cloud CLI esteja instalada.

   gcloud compute images describe VM_IMAGE_FAMILY \
     --project deeplearning-platform-release --format=json | grep type

   Substitua VM_IMAGE_FAMILY pelo nome da família de imagens que você quer usar para criar sua instância.

2. Migre os dados do usuário para uma nova instância de notebooks gerenciados pelo usuário.

A instância de notebooks gerenciados pelo usuário não poderá ser acessada após o upgrade

Problema

Se a instância de notebooks gerenciados pelo usuário não estiver acessível após um upgrade, talvez tenha ocorrido uma falha durante a substituição da imagem do disco de inicialização.

As instâncias de notebooks gerenciados pelo usuário que podem fazer upgrade são discos duplos, com um disco de inicialização e um disco de dados. O processo de upgrade atualiza o disco de inicialização para uma nova imagem e preserva seus dados no disco.

Solução

Conclua as etapas a seguir para anexar uma nova imagem válida ao disco de inicialização.

1. Para armazenar os valores que você usará para concluir este procedimento, digite o seguinte comando no Cloud Shell ou em qualquer ambiente em que a Google Cloud CLI esteja instalada.

   export INSTANCE_NAME=MY_INSTANCE_NAME
   export PROJECT_ID=MY_PROJECT_ID
   export ZONE=MY_ZONE

   Substitua:

   • MY_INSTANCE_NAME: o nome da instância
   • MY_PROJECT_ID: ID do projeto
   • MY_ZONE: a zona em que a instância está localizada

2. Use o seguinte comando para interromper a instância:

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

3. Remova o disco de dados da instância.

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

4. Exclua a VM da instância.

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

5. Use a API Notebooks para excluir a instância de notebooks gerenciados pelo usuário.

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

6. Crie uma instância de notebooks gerenciados pelo usuário com o mesmo nome da instância anterior.

   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

   Substitua:

   • MY_VM_IMAGE_FAMILY: o nome da família de imagens
   • MY_INSTANCE_OWNER: proprietário da instância
   • MY_MACHINE_TYPE: o tipo de máquina da VM da instância
   • MY_SERVICE_ACCOUNT: a conta de serviço a ser usada com essa instância ou use "default"
   • MY_ACCELERATOR_TYPE: o tipo de acelerador. Por exemplo, "NVIDIA_TESLA_T4"
   • MY_ACCELERATOR_CORE_COUNT: a contagem de núcleos, por exemplo: 1

Como monitorar o status de integridade das instâncias de notebooks gerenciados pelo usuário

Nesta seção, descrevemos como solucionar problemas com o monitoramento de erros de status de integridade.

Falha de status docker-proxy-agent

Siga estas etapas após uma falha de status docker-proxy-agent:

1. Verifique se o agente do Inverting Proxy está em execução. Caso contrário, acesse a etapa 3.

2. Reinicie o agente do Inverting Proxy.

3. Registre-se novamente com o servidor Inverting Proxy.

Falha de status docker-service

Siga estas etapas após uma falha de status docker-service:

1. Verifique se o serviço do Docker está em execução.

2. Reinicie o serviço do Docker.

Falha de status jupyter-service

Siga estas etapas após uma falha de status jupyter-service:

1. Verifique se o serviço Jupyter está em execução.

2. Reinicie o serviço Jupyter.

Falha de status jupyter-api

Siga estas etapas após uma falha de status jupyter-api:

1. Verifique se a API interna do Jupyter está ativa.

2. Reinicie o serviço Jupyter.

Porcentagem de utilização do disco de inicialização

O status do espaço no disco de inicialização não será íntegro se o espaço em disco for maior que 85%.

Se o status do espaço no disco de inicialização não estiver íntegro, tente o seguinte:

1. Em uma sessão de terminal na instância de notebooks gerenciados pelo usuário ou usando ssh para se conectar, verifique a quantidade de espaço livre em disco usando o comando df -H.

2. Use o comando find . -type d -size +100M para encontrar arquivos grandes que possam ser excluídos, mas não os exclua, a menos que você tenha certeza de que pode fazer isso com segurança. Se você não tiver certeza, receba ajuda do suporte.

3. Se as etapas anteriores não resolverem o problema, busque suporte.

Porcentagem de utilização do disco de dados

O status do espaço no disco de dados não será íntegro se o espaço em disco for maior que 85%.

Se o status do espaço em disco de dados não estiver íntegro, tente o seguinte:

1. Em uma sessão de terminal na instância de notebooks gerenciados pelo usuário ou usando ssh para se conectar, verifique a quantidade de espaço livre em disco usando o comando df -h -T /home/jupyter.

2. Exclua arquivos grandes para aumentar o espaço disponível em disco. Use o comando find . -type d -size +100M para encontrar arquivos grandes.

3. Se as etapas anteriores não resolverem o problema, busque suporte.

Não foi possível instalar a extensão JupyterLab de terceiros

Problema

A tentativa de instalar uma extensão JupyterLab de terceiros resulta em uma mensagem Error: 500.

Solução

As extensões do JupyterLab de terceiros não são compatíveis com instâncias de notebooks gerenciados pelo usuário.

Restaurar instância

Problema

Não é possível restaurar uma instância de notebooks gerenciada pelo usuário depois que ela é excluída.

Solução

Para fazer backup dos dados na instância, salve os notebooks no GitHub ou faça um snapshot do disco.

Recuperar dados de uma instância

Problema

Não é possível recuperar dados de uma instância de notebooks gerenciados pelo usuário após a exclusão.

Solução

Para fazer backup dos dados na instância, salve os notebooks no GitHub ou faça um snapshot do disco.

Não foi possível aumentar a memória compartilhada

Problema

Não é possível aumentar a memória compartilhada em uma instância de notebooks gerenciados que já existe.

Solução

No entanto, é possível especificar um tamanho de memória compartilhada ao criar uma instância de notebooks gerenciados usando a chave de metadados container-custom-params, com um valor como este:

--shm-size=SHARED_MEMORY_SIZE gb

Substitua SHARED_MEMORY_SIZE pelo tamanho em GB que você quer.

Procedimentos úteis

Esta seção descreve procedimentos que podem ser úteis.

Use SSH para se conectar à instância de notebooks gerenciados pelo usuário

Use o SSH para se conectar à instância digitando o seguinte comando no Cloud Shell ou em qualquer ambiente em que a Google Cloud CLI esteja instalada.

gcloud compute ssh --project PROJECT_ID \
  --zone ZONE \
  INSTANCE_NAME -- -L 8080:localhost:8080

Substitua:

• PROJECT_ID: o ID do projeto
• ZONE: a Google Cloud zona em que a instância está localizada
• INSTANCE_NAME: o nome da instância

Também é possível conectar-se à instância abrindo a página de detalhes do Compute Engine dela e clicando no botão SSH.

Dica: se não for possível usar SSH para se conectar à instância, use gcpdiag para resolver esse problema

Registrar novamente com o servidor Inverting Proxy

Para registrar novamente a instância de notebooks gerenciados pelo usuário no servidor Inverting Proxy interno, interrompa e inicie a VM na página de notebooks gerenciados pelo usuário ou use SSH para se conectar à instância de notebooks gerenciados pelo usuário e digite:

cd /opt/deeplearning/bin
sudo ./attempt-register-vm-on-proxy.sh

Verificar o status do serviço do Docker

Para verificar o status do serviço do Docker, use ssh para se conectar a instância de notebooks gerenciados pelo usuário e digite:

sudo service docker status

Verifique se o agente do Inverting Proxy está em execução

Para verificar se o agente Inverting Proxy do notebook está em execução, use SSH para se conectar à instância de notebooks gerenciados pelo usuário e digite:

# 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

Verifique o status do serviço Jupyter e colete os registros

Para verificar o status do serviço Jupyter, use ssh para se conectar à instância de notebooks gerenciados pelo usuário e digite:

sudo service jupyter status

Para coletar os registros do serviço Jupyter:

sudo journalctl -u jupyter.service --no-pager

Verificar se a API interna do Jupyter está ativa

A API Jupyter precisa ser executada sempre na porta 8080. Para verificar se isso está acontecendo, inspecione os syslogs da instância em busca de uma entrada semelhante a esta:

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

Para verificar se a API interna do Jupyter está ativa, use SSH para se conectar à instância de notebooks gerenciados pelo usuário e digite:

curl http://127.0.0.1:8080/api/kernelspecs

Também é possível medir o tempo que a API leva para responder, caso as solicitações estejam demorando muito:

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

Para executar esses comandos na instância do Vertex AI Workbench, abra o JupyterLab e crie um terminal.

Reinicie o serviço do Docker

Para reiniciar o serviço do Docker, interrompa e inicie a VM na página de notebooks gerenciados pelo usuário ou use o SSH para se conectar à instância de notebooks gerenciados pelo usuário e digite:

sudo service docker restart

Reiniciar o agente do Inverting Proxy

Para reiniciar o agente Inverting Proxy, interrompa e inicie a VM na página de notebooks gerenciados pelo usuário ou use o SSH para se conectar à instância de notebooks gerenciados pelo usuário e digite:

sudo docker restart proxy-agent

Reiniciar o serviço Jupyter

Para reiniciar o serviço do Jupyter, interrompa e inicie a VM na página de notebooks gerenciados pelo usuário ou use o SSH para se conectar à instância de notebooks gerenciados pelo usuário e digite:

sudo service jupyter restart

Reiniciar o agente de coleta de notebooks

O serviço do agente de coleta de notebooks executa um processo Python em segundo plano que verifica o status dos principais serviços da instância do Vertex AI Workbench.

Para reiniciar o serviço do agente de coleta de notebooks, interrompa e inicie a VM no console do Google Cloud ou use SSH para se conectar à instância do Vertex AI Workbench e digite:

sudo systemctl stop notebooks-collection-agent.service

seguido por:

sudo systemctl start notebooks-collection-agent.service

Para executar esses comandos na instância do Vertex AI Workbench, abra o JupyterLab e crie um terminal.

Modificar o script do agente de coleta de notebooks

Observação: não modifique o script do agente de coleta de notebooks, a menos que isso seja necessário para resolver um problema com a instância.

Para acessar e editar o script, abra um terminal na instância ou use SSH para se conectar à instância do Vertex AI Workbench e digite:

nano /opt/deeplearning/bin/notebooks_collection_agent.py

Depois de editar o arquivo, salve-o.

Em seguida, reinicie o serviço do agente de coleta de notebooks.

Verificar se a instância pode resolver os domínios DNS necessários

Para verificar se a instância pode resolver os domínios DNS necessários, use SSH para se conectar à instância de notebooks gerenciados pelo usuário e digite:

host notebooks.googleapis.com
host *.notebooks.cloud.google.com
host *.notebooks.googleusercontent.com
host *.kernels.googleusercontent.com

ou

curl --silent --output /dev/null "https://notebooks.cloud.google.com"; echo $?

Se a instância tiver o Dataproc ativado, você poderá verificar se ela resolve *.kernels.googleusercontent.com executando o seguinte:

curl --verbose -H "Authorization: Bearer $(gcloud auth print-access-token)" https://${PROJECT_NUMBER}-dot-${REGION}.kernels.googleusercontent.com/api/kernelspecs | jq .

Para executar esses comandos na instância do Vertex AI Workbench, abra o JupyterLab e crie um terminal.

Fazer uma cópia dos dados do usuário em uma instância

Para armazenar uma cópia dos dados do usuário da sua instância no Cloud Storage, conclua as etapas a seguir.

Observação: é preciso ter acesso ao terminal para a instância. O acesso ao terminal é definido manualmente durante a criação de uma instância. A configuração de acesso ao terminal não pode ser alterada após a criação da instância.

Criar um bucket do Cloud Storage (opcional)

No mesmo projeto em que sua instância está localizada, crie um bucket do Cloud Storage para armazenar os dados do usuário. Caso você já tenha um bucket do Cloud Storage, pule esta etapa.

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

Copiar dados do usuário

1. Na interface da instância do JupyterLab, selecione File > New > Terminal para abrir uma janela de terminal. Para instâncias de notebooks gerenciados pelo usuário, é possível se conectar ao terminal da instância usando SSH.

2. Use a gcloud CLI para copiar os dados do usuário para um bucket do Cloud Storage. O exemplo de comando a seguir copia todos os arquivos do diretório /home/jupyter/ da instância para um diretório em um bucket do Cloud Storage.

   gcloud storage cp /home/jupyter/* gs://BUCKET_NAMEPATH --recursive
   

   Substitua:

   • BUCKET_NAME: o nome do bucket do Cloud Storage
   • PATH: o caminho para o diretório em que você quer copiar os arquivos, por exemplo: /copy/jupyter/

Investigar uma instância que está com problemas de provisionamento usando o gcpdiag

gcpdiag é uma ferramenta de código aberto. Não é um produto Google Cloud com suporte oficial. Use a ferramenta gcpdiag para identificar e corrigir problemas do projeto Google Cloud. Para mais informações, consulte o projeto gcpdiag no GitHub.

Este runbook gcpdiag investiga as possíveis causas de uma instância do Vertex AI Workbench ficar presa no status de provisionamento, incluindo as seguintes áreas:

• Status: verifica o status atual da instância para confirmar se ela está travada no provisionamento e não interrompida ou ativa.
• Imagem de disco de inicialização da VM do Compute Engine da instância: verifica se a instância foi criada com um contêiner personalizado, uma imagem workbench-instances oficial, Deep Learning VM Images ou imagens sem suporte que podem causar o travamento dela no status de provisionamento.
• Scripts personalizados: verifica se a instância está usando scripts personalizados de inicialização ou pós-inicialização que mudam a porta padrão do Jupyter ou quebram dependências que podem fazer com que a instância fique presa no status de provisionamento.
• Versão do ambiente: verifica se a instância está usando a versão mais recente do ambiente, verificando a capacidade de upgrade dela. Versões anteriores podem fazer com que a instância fique presa no status de provisionamento.
• Desempenho da VM do Compute Engine da instância: verifica o desempenho atual da VM para garantir que ela não esteja prejudicada pelo uso de CPU alto, por memória insuficiente ou por problemas de espaço em disco que possam interromper as operações normais.
• Porta serial do Compute Engine ou geração de registros do sistema da instância: verifica se a instância tem registros de porta serial, que são analisados para garantir que o Jupyter esteja em execução na porta 127.0.0.1:8080.
• Acesso SSH e de terminal do Compute Engine da instância: verifica se a VM do Compute Engine da instância está em execução para que o usuário possa usar SSH e abrir um terminal para verificar se o uso de espaço em home/jupyter é inferior a 85%. Quando não há espaço, a instância pode ficar presa no status de provisionamento.
• IP externo desativado: verifica se o acesso a IPs externos está desativado. Uma configuração de rede incorreta pode fazer com que a instância fique presa no status de provisionamento.

Console do Google Cloud

1. Preencha e copie o comando a seguir.

gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE

2. Abra o console do Google Cloud e ative o Cloud Shell.
Abrir Console do Cloud
3. Cole o comando copiado.
4. Execute o comando gcpdiag, que faz o download da imagem Docker gcpdiag. e realiza verificações de diagnóstico. Se aplicável, siga as instruções de saída para corrigir verificações com falha.

Docker

Você pode executar gcpdiag usando um wrapper que inicia gcpdiag em um contêiner do Docker. Docker ou Podman precisa ser instalado.

1. Copie e execute o seguinte comando na estação de trabalho local.

   curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag

2. Execute o comando gcpdiag.

   ./gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
       --parameter project_id=PROJECT_ID \
       --parameter instance_name=INSTANCE_NAME \
       --parameter zone=ZONE

Veja os parâmetros disponíveis para este runbook.

Substitua:

• PROJECT_ID: o ID do projeto que contém o recurso.
• INSTANCE_NAME: o nome da instância de destino do Vertex AI Workbench no projeto.
• ZONE: a zona em que a instância de destino do Vertex AI Workbench está.

Flags úteis

• --universe-domain: se aplicável, a Nuvem soberana de parceiro confiável que hospeda o recurso
• --parameter ou -p: parâmetros do runbook

Para conferir uma lista e descrição de todas as flags da ferramenta gcpdiag, consulte Instruções de uso do gcpdiag.