Resolução de problemas do Vertex AI Workbench

Esta página descreve os passos de resolução de problemas que podem ser úteis se tiver problemas quando usa o Vertex AI Workbench.

Consulte também o artigo Resolução de problemas do Vertex AI para obter ajuda na utilização de outros componentes do Vertex AI.

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

Instâncias do Vertex AI Workbench

Esta secção descreve os passos de resolução de problemas para instâncias do Vertex AI Workbench.

Estabelecer ligação e abrir o JupyterLab

Esta secção descreve os passos de resolução de problemas para estabelecer ligação e abrir o JupyterLab.

Não acontece nada depois de clicar em Abrir JupyterLab

Problema

Quando clica em Abrir JupyterLab, não acontece nada.

Solução

Verifique se o navegador não impede a abertura automática de novos separadores. O JupyterLab é aberto num novo separador do navegador.

Não é possível aceder ao terminal numa instância do Vertex AI Workbench

Problema

Se não conseguir aceder ao terminal ou não conseguir encontrar a janela do terminal no iniciador, tal pode dever-se ao facto de a sua instância do Vertex AI Workbench não ter o acesso ao terminal ativado.

Solução

Tem de criar uma nova instância do Vertex AI Workbench com a opção Acesso ao terminal ativada. Não é possível alterar esta opção após a criação da instância.

Erro 502 ao abrir o JupyterLab

Problema

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

Solução

Aguarde alguns minutos, atualize o separador do navegador da Google Cloud consola e tente novamente.

O bloco de notas não responde

Problema

A sua instância do Vertex AI Workbench não está a executar células ou parece estar bloqueada.

Solução

Primeiro, experimente reiniciar o kernel clicando em Kernel no menu superior e, de seguida, em Reiniciar kernel. Se isso não funcionar, pode tentar o seguinte:

  • Atualize a página do navegador do JupyterLab. O resultado das células não guardado não persiste, pelo que tem de executar essas células novamente para regenerar o resultado.
  • Reponha a instância.

Não é possível estabelecer ligação à instância do Vertex AI Workbench através de SSH

Problema

Não consegue estabelecer ligação à sua instância através de SSH numa janela de terminal.

As instâncias do Vertex AI Workbench usam o Início de sessão do SO para ativar o acesso SSH. Quando cria uma instância, o Vertex AI Workbench ativa o início de sessão do SO por predefinição definindo a chave de metadados enable-oslogin como TRUE. Se não conseguir usar o SSH para se ligar à sua instância, esta chave de metadados pode ter de ser definida como TRUE.

Solução

A ligação a uma instância do Vertex AI Workbench através da Google Cloud consola não é suportada. Se não conseguir estabelecer ligação à sua instância através de SSH numa janela de terminal, consulte o seguinte:

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

A quota de GPU foi excedida

Problema

Não consegue criar uma instância do Vertex AI Workbench com GPUs.

Solução

Determine o número de GPUs disponíveis no seu projeto consultando a página de quotas. Se as GPUs não estiverem listadas na página de quotas ou precisar de uma quota de GPU adicional, pode pedir um aumento da quota para GPUs do Compute Engine. Consulte o artigo Peça um limite de quota mais elevado.

Criar instâncias do Vertex AI Workbench

Esta secção descreve como resolver problemas relacionados com a criação de instâncias do Vertex AI Workbench.

A instância permanece no estado pendente indefinidamente ou está bloqueada no estado de aprovisionamento

Problema

Depois de criar uma instância do Vertex AI Workbench, esta permanece no estado pendente indefinidamente. Pode aparecer um erro como o seguinte nos registos de série:

Could not resolve host: notebooks.googleapis.com

Se a sua instância estiver bloqueada no estado de aprovisionamento, tal pode dever-se a uma configuração de rede privada inválida para a sua instância.

Solução

Siga os passos na secção Os registos de instâncias mostram erros de ligação ou de tempo limite.

Não é possível criar uma instância numa rede de VPC partilhada

Problema

A tentativa de criar uma instância numa rede de VPC partilhada resulta numa mensagem de erro semelhante à seguinte:

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

Solução

O problema é que a conta de serviço do Notebooks está a tentar criar a instância sem as autorizações corretas.

Para garantir que a conta de serviço dos blocos de notas tem as autorizações necessárias para criar uma instância do Vertex AI Workbench numa rede de VPC partilhada, peça ao seu administrador para conceder à conta de serviço dos blocos de notas a função de utilizador da rede de computação (roles/compute.networkUser) função de IAM no projeto anfitrião.

Para mais informações sobre a concessão de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Esta função predefinida contém as autorizações necessárias para garantir que a conta de serviço dos Notebooks pode criar uma instância do Vertex AI Workbench numa rede de VPC partilhada. Para ver as autorizações exatas que são necessárias, expanda a secção Autorizações necessárias:

Autorizações necessárias

São necessárias as seguintes autorizações para garantir que a conta de serviço dos notebooks pode criar uma instância do Vertex AI Workbench numa rede de VPC partilhada:

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

O administrador também pode atribuir estas autorizações à conta de serviço dos blocos de notas com funções personalizadas ou outras funções predefinidas.

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

Problema

Não existe uma opção para usar um contentor personalizado quando cria uma instância do Vertex AI Workbench na Google Cloud consola.

Solução

A adição de um contentor personalizado a uma instância do Vertex AI Workbench não é suportada, e não pode adicionar um contentor personalizado através da consola. Google Cloud

Recomendamos que adicione um ambiente conda em vez de usar um contentor personalizado.

Pode adicionar um contentor personalizado a uma instância do Vertex AI Workbench através da API Notebooks, mas esta capacidade não é suportada.

O botão para montar o armazenamento partilhado não está presente

Problema

O botão Montar armazenamento partilhado não se encontra no separador Explorador de ficheiros da interface do JupyterLab.

Solução

A autorização storage.buckets.list é necessária para que o botão Montar armazenamento partilhado 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 sua instância do Vertex AI Workbench a autorização storage.buckets.list no projeto.

Erro 599 ao usar o Dataproc

Problema

A tentativa de criar uma instância com o Dataproc ativado resulta numa mensagem de erro semelhante à seguinte:

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 é possível instalar a extensão JupyterLab de terceiros

Problema

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

Solução

As extensões do JupyterLab de terceiros não são suportadas em instâncias do Vertex AI Workbench.

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

Problema

Quando tenta editar a máquina virtual (VM) subjacente de uma instância do Vertex AI Workbench, pode receber uma mensagem de erro semelhante à seguinte:

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

Solução

Este erro ocorre porque não pode editar a VM subjacente de uma instância através da consola ou da API Compute Engine. Google Cloud

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 Google Cloud SDK

Os pip pacotes não estão disponíveis depois de adicionar o ambiente conda

Problema

Os seus pacotes pip não estão disponíveis depois de adicionar um kernel baseado no conda.

Solução

Para resolver o problema, consulte o artigo Adicione um ambiente conda e experimente o seguinte:

  • Verifique se usou a variável DL_ANACONDA_ENV_HOME e se esta contém o nome do seu ambiente.

  • Verifique se o ficheiro pip está localizado num caminho semelhante ao de opt/conda/envs/ENVIRONMENT/bin/pip. Pode executar o comando which pip para obter o caminho.

Não é possível aceder nem copiar dados de uma instância com acesso de utilizador único

Problema

Os dados numa instância com acesso de utilizador único são inacessíveis.

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

Solução

Para aceder ou copiar os dados quando não é o proprietário da instância, abra um registo de apoio técnico.

Encerramento inesperado

Problema

A sua instância do Vertex AI Workbench é encerrada inesperadamente.

Solução

Se a sua instância for encerrada inesperadamente, isto pode dever-se ao facto de ter sido iniciado o encerramento por inatividade.

Se ativou o encerramento por inatividade, a instância é encerrada quando não existe atividade do kernel durante o período especificado. Por exemplo, executar uma célula ou imprimir um novo resultado num bloco de notas é uma atividade que repõe o temporizador de tempo limite de inatividade. A utilização da CPU não repõe o temporizador de tempo limite de inatividade.

Os registos da instância mostram erros de ligação ou de limite de tempo excedido

Problema

Os registos da instância do Vertex AI Workbench mostram erros de ligação ou de tempo limite.

Solução

Se notar erros de ligação ou de tempo limite nos registos da instância, certifique-se de que o servidor Jupyter está em execução na porta 8080. Siga os passos na secção Confirme que a API interna do Jupyter está ativa.

Se desativou a opção External IP e está a usar uma rede VPC privada, certifique-se de que também seguiu a documentação de opções de configuração de rede. Considere o seguinte:

Os registos de instâncias mostram "Unable to contact Jupyter API" "ReadTimeoutError"

Problema

Os registos da sua 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 os passos na secção Os registos de instâncias mostram erros de ligação ou de tempo limite. Também pode tentar modificar o script do agente da coleção Notebooks para alterar HTTP_TIMEOUT_SESSION para um valor superior, por exemplo: 60, para ajudar a verificar se o pedido falhou devido a a chamada demorar demasiado tempo a responder ou o URL pedido não estar acessível.

docker0 está em conflito com o endereçamento da VPC

Problema

Por predefinição, a interface docker0 é criada com um endereço IP de 172.17.0.1/16. Isto pode entrar em conflito com o endereçamento IP na sua rede VPC, de modo que a instância não consiga estabelecer ligação a outros pontos finais com endereços 172.17.0.1/16.

Solução

Pode forçar a criação da interface docker0 com um endereço IP que não entre em conflito com a sua rede VPC através do seguinte script de pós-arranque e definindo o comportamento do script de pós-arranque 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 numa mensagem de erro Specified reservations do not exist. O resultado da operação pode ser semelhante ao seguinte:

{
  "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áquinas do Compute Engine requerem parâmetros adicionais na criação, como discos locais ou uma plataforma de CPU mínima. A especificação da instância tem de incluir estes campos adicionais.

Por exemplo, o tipo de máquina a3-megagpu-8g requer 16 discos SSD locais, que têm de ser incluídos na reserva e especificados no pedido de criação de instâncias.

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

Blocos de notas geridos

Esta secção descreve os passos de resolução de problemas para blocos de notas geridos.

Estabelecer ligação e abrir o JupyterLab

Esta secção descreve a resolução de problemas relacionados com a ligação e a abertura do JupyterLab.

Não acontece nada depois de clicar em Abrir JupyterLab

Problema

Quando clica em Abrir JupyterLab, não acontece nada.

Solução

Verifique se o navegador não impede a abertura automática de novos separadores. O JupyterLab é aberto num novo separador do navegador.

Não é possível estabelecer ligação à instância de notebooks geridos através de SSH

Problema

Não existe uma opção para estabelecer ligação a instâncias de blocos de notas geridos através de SSH.

Solução

O acesso SSH a instâncias de notebooks geridos não está disponível.

Não é possível aceder ao terminal numa instância de notebooks geridos

Problema

Se não conseguir aceder ao terminal ou não conseguir encontrar a janela do terminal no launcher, tal pode dever-se ao facto de a sua instância de blocos de notas geridos não ter o acesso ao terminal ativado.

Solução

Tem de criar uma nova instância de notebooks geridos com a opção Acesso ao terminal ativada. Não é possível alterar esta opção após a criação da instância.

Erro 502 ao abrir o JupyterLab

Problema

Um erro 502 pode significar que a instância dos blocos de notas geridos ainda não está pronta.

Solução

Aguarde alguns minutos, atualize o separador do navegador da Google Cloud consola e tente novamente.

A abertura de um notebook resulta num erro 524 (A Timeout Occurred)

Problema

Normalmente, um erro 524 é uma indicação de que o agente do proxy inverso não está a estabelecer ligação ao servidor do proxy inverso ou os pedidos estão a demorar demasiado tempo no lado do servidor de back-end (Jupyter). As causas comuns deste erro incluem problemas de rede, o agente de proxy invertido não está em execução ou o serviço Jupyter não está em execução.

Solução

Verifique se a instância de blocos de notas geridos está iniciada.

O bloco de notas não responde

Problema

A instância de blocos de notas geridos não está a executar células ou parece estar congelada.

Solução

Primeiro, experimente reiniciar o kernel clicando em Kernel no menu superior e, de seguida, em Reiniciar kernel. Se isso não funcionar, pode tentar o seguinte:

  • Atualize a página do navegador do JupyterLab. O resultado das células não guardado não persiste, pelo que tem de executar essas células novamente para regenerar o resultado.
  • Reponha a instância.

Migrar para instâncias do Vertex AI Workbench

Esta secção descreve métodos para diagnosticar e resolver problemas com a migração de uma instância de blocos de notas geridos para uma instância do Vertex AI Workbench.

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

Problema

Um kernel que estava na sua instância de blocos de notas geridos não aparece na instância do Vertex AI Workbench para a qual migrou.

Os contentores personalizados aparecem como kernels nos blocos de notas geridos. A ferramenta de migração do Vertex AI Workbench não suporta a migração de contentores personalizados.

Solução

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

Versão diferente da framework na instância migrada

Problema

Uma framework que estava na sua instância de blocos de notas geridos tinha uma versão diferente da que estava na instância do Vertex AI Workbench para a qual migrou.

As instâncias do Vertex AI Workbench oferecem um conjunto predefinido de versões de frameworks. A ferramenta de migração não adiciona versões da framework da sua instância de blocos de notas geridos original. Consulte os comportamentos predefinidos da ferramenta de migração.

Solução

Para adicionar uma versão específica de uma 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 dos blocos de notas geridos não estão na instância do Vertex AI Workbench para a qual migrou.

As instâncias do Vertex AI Workbench suportam um conjunto predefinido de GPUs. Se as GPUs na instância dos blocos de notas geridos originais não estiverem disponíveis, a instância é migrada sem GPUs.

Solução

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

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

Problema

O tipo de máquina da instância de blocos de notas geridos é diferente da instância do Vertex AI Workbench para a qual migrou.

As instâncias do Vertex AI Workbench não são compatíveis com todos os tipos de máquinas. Se o tipo de máquina na instância de blocos de notas geridos original não estiver disponível, a instância é migrada para o tipo de máquina e2-standard-4.

Solução

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

A quota de GPU foi excedida

Problema

Não pode criar uma instância de blocos de notas geridos com GPUs.

Solução

Determine o número de GPUs disponíveis no seu projeto consultando a página de quotas. Se as GPUs não estiverem listadas na página de quotas ou precisar de uma quota de GPUs adicional, pode pedir um aumento de quota. Consulte o artigo Peça um limite de quota superior.

Usar imagens de contentores

Esta secção descreve a resolução de problemas relacionados com a utilização de imagens de contentores.

A imagem do contentor não aparece como um kernel no JupyterLab

Problema

As imagens de contentores que não tenham um kernelspec válido não são carregadas com êxito como kernels no JupyterLab.

Solução

Certifique-se de que o seu contentor cumpre os nossos requisitos. Para mais informações, consulte os requisitos do contentor personalizado.

O notebook desliga-se em tarefas de execução prolongada

Problema

Se vir a seguinte mensagem de erro ao executar uma tarefa num bloco de notas, pode ser causado pelo facto de o pedido demorar demasiado tempo a carregar ou a utilização da CPU ou da memória ser elevada, o que pode tornar o serviço Jupyter não responsivo.

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

Este problema é causado pela execução de uma tarefa de longa duração num bloco de notas. Para executar uma tarefa que pode demorar muito tempo a ser concluída, é recomendável usar o executor.

Usar o executor

Esta secção descreve a resolução de problemas relacionados com a utilização do executor.

As instalações de pacotes não estão disponíveis para o executor

Problema

O executor executa o código do bloco de notas num ambiente separado do kernel onde executa o código do ficheiro do bloco de notas. Por este motivo, alguns dos pacotes que instalou podem não estar disponíveis no ambiente do executor.

Solução

Para resolver este problema, consulte o artigo Certifique-se de que as instalações de pacotes estão disponíveis para o executor.

Erros 401 ou 403 ao executar o código do bloco de notas com o executor

Problema

Um erro 401 ou 403 quando executa o executor pode significar que o executor não consegue aceder aos recursos.

Solução

Seguem-se algumas possíveis causas:

  • O executor executa o código do bloco de notas num projeto de inquilino separado do projeto da instância de blocos de notas geridos. Por conseguinte, quando acede a recursos através de código executado pelo executor, o executor pode não estabelecer ligação ao projeto correto por predefinição. Google Cloud Para resolver este problema, use a seleção explícita do projeto.

  • Por predefinição, a instância de blocos de notas geridos pode ter acesso a recursos existentes no mesmo projeto e, por isso, quando executa o código do ficheiro de bloco de notas manualmente, estes recursos não precisam de autenticação adicional. No entanto, uma vez que o executor é executado num projeto de inquilino separado, não tem o mesmo acesso predefinido. Para resolver este problema, autentique o acesso através de contas de serviço.

  • O executor não pode usar credenciais do utilizador final para autenticar o acesso a recursos, por exemplo, o comando gcloud auth login. Para resolver este problema, autentique o acesso através de contas de serviço.

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

Problema

Pode ocorrer um erro exited with a non-zero status of 127 ou um erro "comando não encontrado" quando usa o executor para executar código num contentor personalizado que não tem a extensão nbexecutor instalada.

Solução

Para garantir que o seu contentor personalizado tem a extensão nbexecutor, pode criar uma imagem de contentor derivada a partir de uma imagem de contentores de aprendizagem profunda. As imagens do Deep Learning Containers incluem a extensão nbexecutor.

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

Problema

Este erro pode ter o seguinte aspeto:

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

Isto significa que não foram encontrados blocos gratuitos nos intervalos de IP atribuídos da sua rede.

Solução

Use uma máscara de sub-rede de /24 ou inferior. Crie um intervalo de endereços IP atribuídos maior e anexe este intervalo modificando a ligação de serviço privado para servicenetworking-googleapis-com.

Para mais informações, consulte o artigo Configure uma rede.

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

Problema

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

Solução

As extensões do JupyterLab de terceiros não são suportadas em instâncias de blocos de notas geridos.

Não é possível aceder nem copiar dados de uma instância com acesso de utilizador único

Problema

Os dados numa instância com acesso de utilizador único são inacessíveis.

Solução

Para instâncias de blocos de notas geridas configuradas com acesso de utilizador único, apenas o utilizador único especificado (o proprietário) pode aceder aos dados na instância.

Para aceder ou copiar os dados quando não é o proprietário da instância, abra um registo de apoio técnico.

Encerramento inesperado

Problema

A sua instância do Vertex AI Workbench é encerrada inesperadamente.

Solução

Se a sua instância for encerrada inesperadamente, isto pode dever-se ao facto de ter sido iniciado o encerramento por inatividade.

Se ativou o encerramento por inatividade, a instância é encerrada quando não existe atividade do kernel durante o período especificado. Por exemplo, executar uma célula ou imprimir um novo resultado num bloco de notas é uma atividade que repõe o temporizador de tempo limite de inatividade. A utilização da CPU não repõe o temporizador de tempo limite de inatividade.

Restaure a instância

Problema

A restauração de uma instância de blocos de notas geridos após a eliminação não é suportada.

Solução

Para fazer uma cópia de segurança dos dados na sua instância, pode guardar os seus blocos de notas no GitHub.

Recupere dados de uma instância

Problema

Não é possível recuperar dados de uma instância de blocos de notas geridos depois de esta ter sido eliminada.

Solução

Para fazer uma cópia de segurança dos dados na sua instância, pode guardar os seus blocos de notas no GitHub.

Criar instâncias de notebooks geridos

Esta secção descreve a resolução de problemas com a criação de instâncias de blocos de notas geridos.

Erro: problema ao criar uma associação

Problema

Encontra 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 IPs alocado superior a /24 e anexe este intervalo modificando a ligação de serviço privada para a ligação servicenetworking-googleapis-com.

A criação de uma instância resulta num erro de disponibilidade de recursos

Problema

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

Este erro pode ter o seguinte aspeto:

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 recursos ocorrem quando pede novos recursos numa zona que não pode satisfazer o seu pedido devido à indisponibilidade atual de recursos do Compute Engine, como GPUs ou CPUs.

Os erros de recursos aplicam-se apenas a novos pedidos de recursos na zona e não afetam os recursos existentes. Os erros de recursos não estão relacionados com a sua quota do Compute Engine. Os erros de recursos são temporários e podem mudar com frequência com base na flutuação da procura.

Solução

Para continuar, experimente o seguinte:

  • Crie uma instância com um tipo de máquina diferente.
  • Crie a instância numa zona diferente.
  • Tente fazer o pedido novamente mais tarde.
  • Reduza a quantidade de recursos que está a pedir. Por exemplo, experimente criar uma instância com menos GPUs, discos, vCPUs ou memória.

O início de uma instância resulta num erro de disponibilidade de recursos

Problema

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

Este erro pode ter o seguinte aspeto:

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

Os erros de recursos ocorrem quando tenta iniciar uma instância numa zona que não consegue satisfazer o seu pedido devido à indisponibilidade atual de recursos do Compute Engine, como GPUs ou CPUs.

Os erros de recursos aplicam-se apenas aos recursos especificados no pedido no momento em que o enviou e não a todos os recursos na zona. Os erros de recursos não estão relacionados com a sua quota do Compute Engine. Os erros de recursos são temporários e podem mudar com frequência com base na flutuação da procura.

Solução

Para continuar, experimente o seguinte:

  • Altere o tipo de máquina da sua instância.
  • Migre os seus ficheiros e dados para uma instância numa zona diferente.
  • Tente fazer o pedido novamente mais tarde.
  • Reduza a quantidade de recursos que está a pedir. Por exemplo, pode iniciar uma instância diferente com menos GPUs, discos, vCPUs ou memória.

No route to host em ligações de saída de blocos de notas geridos

Problema

Normalmente, as únicas rotas que pode ver na consola são as conhecidas do seu próprio VPC, bem como os intervalos reservados quando conclui a configuração do VPC Network Peering. Google Cloud

As instâncias de blocos de notas geridos residem numa rede gerida pela Google e executam uma versão modificada do Jupyter num espaço de nomes de rede do Docker na instância.

A interface de rede do Docker e a ponte Linux nesta instância podem selecionar um IP local que entra em conflito com os intervalos de IP que estão a ser exportados através da interligação pela sua VPC. Normalmente, estes encontram-se nos intervalos 172.16.0.0/161 e 192.168.10.0/24, respetivamente.

Nestes casos, as ligações de saída da instância para estes intervalos falham com uma reclamação que é uma variação de No route to host, apesar de as rotas de VPC serem partilhadas corretamente.

Solução

Invoque ifconfig numa sessão de terminal e certifique-se de que nenhum endereço IP em nenhuma interface virtual na instância entra em conflito com os intervalos de IP que a sua VPC está a exportar para a ligação de peering.

Notebooks geridos pelo utilizador

Esta secção descreve os passos de resolução de problemas para blocos de notas geridos pelo utilizador.

Estabelecer ligação e abrir o JupyterLab

Esta secção descreve a resolução de problemas relacionados com a ligação e a abertura do JupyterLab.

Não acontece nada depois de clicar em Abrir JupyterLab

Problema

Quando clica em Abrir JupyterLab, não acontece nada.

Solução

Verifique se o navegador não impede a abertura automática de novos separadores. O JupyterLab é aberto num novo separador do navegador.

Sem acesso ao servidor proxy inverso para o JupyterLab

Problema

Não consegue aceder ao JupyterLab.

O Vertex AI Workbench usa um servidor proxy inverso interno da Google para fornecer acesso ao JupyterLab. As definições da instância de blocos de notas geridos pelo utilizador, a configuração de rede e outros fatores podem impedir o acesso ao JupyterLab.

Solução

Use o SSH para se ligar ao JupyterLab e saiba mais sobre os motivos pelos quais pode não ter acesso através do proxy invertido.

Não é possível estabelecer ligação à instância de blocos de notas geridos pelo utilizador através de SSH

Problema

Não consegue estabelecer ligação à sua instância através de SSH numa janela de terminal.

As instâncias de blocos de notas geridas pelo utilizador usam o Início de sessão do SO para ativar o acesso SSH. Quando cria uma instância, o Vertex AI Workbench ativa o início de sessão no SO por predefinição definindo a chave de metadados enable-oslogin como TRUE. Se não conseguir usar o SSH para se ligar à sua instância, pode ter de definir esta chave de metadados como TRUE.

Solução

Para ativar o acesso SSH para blocos de notas geridos pelo utilizador para utilizadores, conclua os passos para configurar funções de Início de sessão do SO em contas de utilizador.

A abertura de uma instância de notebooks gerida pelo utilizador resulta num erro 403 (Proibido)

Problema

Um erro 403 (Forbidden) ao abrir uma instância de blocos de notas geridos pelo utilizador significa frequentemente que existe um problema de acesso.

Solução

Para resolver problemas de acesso, considere as três formas de conceder acesso a uma instância de notebooks geridos pelo utilizador:

  • Utilizador único
  • Conta de serviço
  • Editores de projetos

O modo de acesso é configurado durante a criação da instância de blocos de notas geridos pelo utilizador e é definido nos metadados do bloco de notas:

  • Utilizador único: proxy-mode=mail, proxy-user-mail=user@domain.com
  • Conta de serviço: proxy-mode=service_account
  • Editores do projeto: proxy-mode=project_editors

Se não conseguir aceder a um bloco de notas quando clica em Abrir JupyterLab, experimente o seguinte:

O exemplo seguinte mostra como especificar uma conta de serviço quando cria uma instância:

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 clica em Abrir JupyterLab para abrir um bloco de notas, este é aberto num novo separador do navegador. Se tiver sessão iniciada em mais de uma Conta Google, o novo separador é aberto com a sua Conta Google predefinida. Se não criou a instância de blocos de notas geridos pelo utilizador com a sua Conta Google predefinida, o novo separador do navegador apresenta um erro 403 (Forbidden).

Sem acesso ao JupyterLab, modo de utilizador único ativado

Problema

Não consegue aceder ao JupyterLab.

Solução

Se um utilizador não conseguir aceder ao JupyterLab e o acesso da instância ao JupyterLab estiver definido como Single user only, experimente o seguinte:

  1. Na página Notebooks geridos pelo utilizador da Google Cloud consola, clique no nome da sua instância para abrir a página Detalhes do notebook.

  2. Junto a Ver detalhes da VM, clique em Ver no Compute Engine.

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

  4. Na secçã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 para um endereço de email de utilizador válido e não para uma conta de serviço.

  6. Clique em Guardar.

  7. Na página Notebooks geridos pelo utilizador da Google Cloud consola, inicialize os metadados atualizados parando a instância e iniciando novamente a instância.

A abertura de um bloco de notas resulta num erro 504 (Tempo limite do gateway)

Problema

Isto é uma indicação de um limite de tempo do proxy interno ou de um limite de tempo do servidor de back-end (Jupyter). Isto pode ser visto quando:

  • O pedido nunca chegou ao servidor proxy invertido interno
  • O back-end (Jupyter) devolve um erro 504.

Solução

Abra um registo do apoio técnico da Google.

A abertura de um notebook resulta num erro 524 (A Timeout Occurred)

Problema

O servidor proxy invertido interno não recebeu uma resposta do agente do proxy invertido para o pedido dentro do período de tempo limite. O agente de proxy invertido é executado na instância de blocos de notas geridos pelo utilizador como um contentor do Docker. Normalmente, um erro 524 indica que o agente do proxy invertido não está a estabelecer ligação ao servidor do proxy invertido ou que os pedidos estão a demorar demasiado tempo do lado do servidor de back-end (Jupyter). Um caso típico para este erro é do lado do utilizador (por exemplo, um problema de rede ou o serviço do agente de proxy invertido não está em execução).

Solução

Se não conseguir aceder a um bloco de notas, verifique se a instância dos blocos de notas geridos pelo utilizador está iniciada e experimente o seguinte:

Opção 1: execute a ferramenta de diagnóstico para verificar e reparar automaticamente os serviços principais dos notebooks geridos pelo utilizador, validar o armazenamento disponível e gerar ficheiros de registo úteis. Para executar a ferramenta na sua instância, siga estes passos:

  1. Certifique-se de que a sua instância tem a versão M58 ou mais recente.

  2. Estabeleça ligação à sua instância de Deep Learning VM Images através do SSH.

  3. Execute o seguinte comando:

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

    Tenha em atenção que as flags --repair e --bucket são opcionais. A flag --repair tenta corrigir erros comuns do serviço principal e a flag --bucket permite especificar um contentor do Cloud Storage para armazenar os ficheiros de registo criados.

    O resultado deste comando apresenta mensagens de estado úteis para os serviços principais dos blocos de notas geridos pelo utilizador e exporta ficheiros de registo das respetivas conclusões.

Opção 2: siga os passos abaixo para verificar os requisitos específicos dos blocos de notas geridos pelo utilizador individualmente.

A abertura de um notebook resulta num erro 598 (Tempo limite de leitura da rede)

Problema

O servidor proxy inverso não recebe informações do agente do proxy inverso há mais de 10 minutos. Este é um forte indicador de um problema do agente de proxy invertido.

Solução

Se não conseguir aceder a um bloco de notas, experimente o seguinte:

O bloco de notas não responde

Problema

A instância de blocos de notas gerida pelo utilizador não está a executar células ou parece estar bloqueada.

Solução

Primeiro, experimente reiniciar o kernel clicando em Kernel no menu superior e, de seguida, em Reiniciar kernel. Se isso não funcionar, pode tentar o seguinte:

  • Atualize a página do navegador do JupyterLab. Qualquer resultado de célula não guardado não persiste. Por isso, tem de executar novamente essas células para regenerar o resultado.
  • A partir de uma sessão de terminal no bloco de notas, execute o comando top para ver se existem processos a consumir a CPU.
  • No terminal, verifique a quantidade de espaço livre no disco através do comando df ou verifique a RAM disponível através do comando free.
  • Encerre a instância selecionando-a na página Notebooks geridos pelo utilizador e clicando em Parar. Depois de parar completamente, selecione-o e clique em Iniciar.

Migrar para instâncias do Vertex AI Workbench

Esta secção descreve os métodos para diagnosticar e resolver problemas com a migração de uma instância de user-managed notebooks para uma instância do Vertex AI Workbench.

Não é possível encontrar o R, o Beam ou outros kernels que estavam na instância de blocos de notas geridos pelo utilizador

Problema

Um kernel que estava na instância dos blocos de notas geridos pelo utilizador não aparece na instância do Vertex AI Workbench para a qual migrou.

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

Solução

Para resolver este 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 é suportado em instâncias do Vertex AI Workbench.

Solução

Continue a usar o Dataproc Hub em instâncias de blocos de notas geridas pelo utilizador.

Versão diferente da framework na instância migrada

Problema

Uma framework na instância de blocos de notas geridos pelo utilizador tinha uma versão diferente da versão na instância do Vertex AI Workbench para a qual migrou.

As instâncias do Vertex AI Workbench oferecem um conjunto predefinido de versões de frameworks. A ferramenta de migração não adiciona versões da framework a partir da instância de blocos de notas gerida pelo utilizador original. Consulte os comportamentos predefinidos da ferramenta de migração.

Solução

Para adicionar uma versão específica de uma 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 dos blocos de notas geridos pelo utilizador não estão na instância do Vertex AI Workbench para a qual migrou.

As instâncias do Vertex AI Workbench suportam um conjunto predefinido de GPUs. Se as GPUs na instância de blocos de notas geridos pelo utilizador original não estiverem disponíveis, a instância é migrada sem GPUs.

Solução

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

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

Problema

O tipo de máquina da instância de blocos de notas geridos pelo utilizador é diferente da instância do Vertex AI Workbench para a qual migrou.

As instâncias do Vertex AI Workbench não são compatíveis com todos os tipos de máquinas. Se o tipo de máquina na instância de blocos de notas gerida pelo utilizador original não estiver disponível, a instância é migrada para o tipo de máquina e2-standard-4.

Solução

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

Trabalhar com ficheiros

Esta secção descreve a resolução de problemas com ficheiros para instâncias de blocos de notas geridas pelo utilizador.

Transferência de ficheiros desativada, mas o utilizador ainda pode transferir ficheiros

Problema

Para instâncias de blocos de notas geridas pelo utilizador do Dataproc Hub, a desativação da transferência de ficheiros a partir da interface do utilizador do JupyterLab não é suportada. As instâncias de blocos de notas geridas pelo utilizador que usam a framework Dataproc Hub permitem a transferência de ficheiros mesmo que não selecione Ativar a transferência de ficheiros a partir da IU do JupyterLab quando cria a instância.

Solução

As instâncias de blocos de notas geridas pelo utilizador do Dataproc Hub não suportam a restrição de transferências de ficheiros.

Os ficheiros transferidos estão truncados ou a transferência não é concluída

Problema

Quando transfere ficheiros da instância de blocos de notas geridos pelo utilizador, uma definição de limite de tempo no agente de encaminhamento de proxy limita o tempo de ligação para a conclusão da transferência. Se a transferência demorar demasiado tempo, pode truncar o ficheiro transferido ou impedir a respetiva transferência.

Solução

Para transferir o ficheiro, copie-o para o Cloud Storage e, em seguida, transfira-o a partir do Cloud Storage.

Considere migrar os seus ficheiros e dados para uma nova instância de blocos de notas gerida pelo utilizador.

Após reiniciar a VM, não é possível fazer referência a ficheiros locais a partir do terminal do bloco de notas

Problema

Por vezes, depois de reiniciar uma instância de blocos de notas gerida pelo utilizador, não é possível fazer referência a ficheiros locais a partir de um terminal do bloco de notas.

Solução

Este é um problema conhecido. Para fazer referência aos seus ficheiros locais a partir de um terminal do bloco de notas, primeiro, restabeleça o seu diretório de trabalho atual com o seguinte comando:

cd PWD

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

Depois de restabelecer o diretório de trabalho atual, pode fazer referência aos ficheiros locais a partir do terminal do bloco de notas.

Criar instâncias de blocos de notas geridas pelo utilizador

Esta secção descreve a resolução de problemas relacionados com a criação de instâncias de blocos de notas geridos pelo utilizador.

A quota de GPU foi excedida

Problema

Não pode criar uma instância de notebooks geridos pelo utilizador com GPUs.

Solução

Determine o número de GPUs disponíveis no seu projeto consultando a página de quotas. Se as GPUs não estiverem listadas na página de quotas ou precisar de uma quota de GPUs adicional, pode pedir um aumento da quota. Consulte o artigo Peça um limite de quota superior.

A instância permanece no estado pendente indefinidamente

Problema

Depois de criar uma instância de blocos de notas geridos pelo utilizador, esta permanece no estado pendente indefinidamente. Pode aparecer um erro como o seguinte nos registos de série:

Could not resolve host: notebooks.googleapis.com

Solução

A sua instância não consegue estabelecer ligação ao servidor da API Notebooks devido a uma configuração do Cloud DNS ou a outro problema de rede. Para resolver o problema, verifique as configurações de rede e do Cloud DNS. Para mais informações, consulte a secção de opções de configuração de rede.

Não é criada uma nova instância de blocos de notas geridos pelo utilizador (autorizações insuficientes)

Problema

Normalmente, a criação de uma instância de notebooks geridos pelo utilizador demora cerca de um minuto. Se a nova instância de blocos de notas geridos pelo utilizador permanecer no estado pending indefinidamente, pode dever-se ao facto de a conta de serviço usada para iniciar a instância de blocos de notas geridos pelo utilizador não ter as autorizações necessárias no seu projeto Google Cloud .

Pode iniciar uma instância de blocos de notas geridos pelo utilizador com uma conta de serviço personalizada que criar ou no modo de utilizador único com um ID do utilizador. Se iniciar uma instância de blocos de notas geridos pelo utilizador no modo de utilizador único, a instância de blocos de notas geridos pelo utilizador inicia o processo de arranque com a conta de serviço predefinida do Compute Engine antes de transferir o controlo para o seu ID de utilizador.

Solução

Para verificar se uma conta de serviço tem as autorizações adequadas, siga estes passos:

Consola

  1. Abra a página IAM na Google Cloud consola.

    Abra a página IAM

  2. Determine a conta de serviço usada com a instância dos blocos de notas geridos pelo utilizador, que é uma das seguintes:

    • Uma conta de serviço personalizada que especificou quando criou a instância de blocos de notas geridos pelo utilizador.

    • A conta de serviço predefinida do Compute Engine para o seu projeto Google Cloud , que é usada quando inicia a instância de blocos de notas gerida pelo utilizador no modo de utilizador único. A conta de serviço predefinida do Compute Engine para o seu projeto Google Cloud tem o nome PROJECT_NUMBER-compute@developer.gserviceaccount.com. Por exemplo: 113377992299-compute@developer.gserviceaccount.com.

  3. Verifique se a sua conta de serviço tem a função Executador de blocos de notas (roles/notebooks.runner). Caso contrário, conceda à conta de serviço a função Notebooks Runner (roles/notebooks.runner).

Para mais informações, consulte o artigo Conceder, alterar e revogar o acesso a recursos na documentação da IAM.

gcloud

  1. Se ainda não o fez, instale a CLI Google Cloud.

  2. Obtenha o nome e o número do projeto do seu Google Cloud projeto com o seguinte comando. Substitua PROJECT_ID pelo ID do projeto do seu projeto Google Cloud .

    gcloud projects describe PROJECT_ID

    Deverá ver um resultado semelhante ao seguinte, que apresenta o nome (name:) e o número do projeto (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 blocos de notas gerida pelo utilizador, que é uma das seguintes:

    • Uma conta de serviço personalizada que especificou quando criou a instância de blocos de notas geridos pelo utilizador.

    • A conta de serviço predefinida do Compute Engine para o seu projeto Google Cloud , que é usada quando inicia a instância de blocos de notas gerida pelo utilizador no modo de utilizador único. A conta de serviço predefinida do Compute Engine para o seu projeto Google Cloud tem o nome PROJECT_NUMBER-compute@developer.gserviceaccount.com. Por exemplo: 113377992299-compute@developer.gserviceaccount.com.

  4. Adicione a função roles/notebooks.runner à conta de serviço com o seguinte comando. Substitua project-name pelo nome do seu projeto e substitua service-account-id pelo ID da conta de serviço da sua instância de blocos de notas geridos pelo utilizador.

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

A criação de uma instância resulta num erro Permission denied

Problema

A conta de serviço na instância fornece acesso a outros Google Cloud serviços. Pode usar qualquer conta de serviço no mesmo projeto, mas tem de ter a autorização Utilizador da conta de serviço (iam.serviceAccounts.actAs) para criar a instância. Se não for especificada, é usada a conta de serviço predefinida do Compute Engine.

Solução

Quando criar uma instância, verifique se o utilizador que a está a criar tem a autorização iam.serviceAccounts.ActAs para a conta de serviço definida.

O exemplo seguinte mostra como especificar uma conta de serviço quando cria 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 a função de utilizador da conta de serviço, consulte o artigo Faça a gestão do acesso a contas de serviço.

A criação de uma instância resulta num erro already exists

Problema

Ao criar uma instância, verifique se uma instância de blocos de notas geridos pelo utilizador com o mesmo nome não foi eliminada anteriormente pelo Compute Engine e ainda existe na base de dados da API Notebooks.

Solução

O exemplo seguinte mostra como listar instâncias através da API Notebooks e verificar o respetivo estado.

gcloud notebooks instances list --location=LOCATION

Se o estado de uma instância for DELETED, execute o seguinte comando para a eliminar permanentemente.

gcloud notebooks instances delete INSTANCE_NAME --location=LOCATION

Não é possível criar uma instância numa VPC partilhada

Problema

Não é possível criar uma instância numa VPC partilhada.

Solução

Se estiver a usar a VPC partilhada, tem de adicionar os projetos de anfitrião e de serviço ao perímetro de serviço. No projeto anfitrião, também tem de conceder a função de utilizador da rede de computação (roles/compute.networkUser) ao agente de serviço dos blocos de notas do projeto de serviço. Para mais informações, consulte o artigo Gerir perímetros de serviço.

A criação de uma instância resulta num erro de disponibilidade de recursos

Problema

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

Este erro pode ter o seguinte aspeto:

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 recursos ocorrem quando pede novos recursos numa zona que não pode satisfazer o seu pedido devido à indisponibilidade atual de recursos do Compute Engine, como GPUs ou CPUs.

Os erros de recursos aplicam-se apenas a novos pedidos de recursos na zona e não afetam os recursos existentes. Os erros de recursos não estão relacionados com a sua quota do Compute Engine. Os erros de recursos são temporários e podem mudar com frequência com base na flutuação da procura.

Solução

Para continuar, pode tentar o seguinte:

  • Crie uma instância com um tipo de máquina diferente.
  • Crie a instância numa zona diferente.
  • Tente fazer o pedido novamente mais tarde.
  • Reduza a quantidade de recursos que está a pedir. Por exemplo, experimente criar uma instância com menos GPUs, discos, vCPUs ou memória.

O início de uma instância resulta num erro de disponibilidade de recursos

Problema

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

Este erro pode ter o seguinte aspeto:

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

Os erros de recursos ocorrem quando tenta iniciar uma instância numa zona que não consegue satisfazer o seu pedido devido à indisponibilidade atual de recursos do Compute Engine, como GPUs ou CPUs.

Os erros de recursos aplicam-se apenas aos recursos especificados no pedido no momento em que o enviou e não a todos os recursos na zona. Os erros de recursos não estão relacionados com a sua quota do Compute Engine. Os erros de recursos são temporários e podem mudar com frequência com base na flutuação da procura.

Solução

Para continuar, pode tentar o seguinte:

  • Altere o tipo de máquina da sua instância.
  • Migre os seus ficheiros e dados para uma instância numa zona diferente.
  • Tente fazer o pedido novamente mais tarde.
  • Reduza a quantidade de recursos que está a pedir. Por exemplo, pode iniciar uma instância diferente com menos GPUs, discos, vCPUs ou memória.

Atualizar instâncias de blocos de notas geridos pelo utilizador

Esta secção descreve a resolução de problemas relacionados com a atualização de instâncias de blocos de notas geridos pelo utilizador.

Não é possível fazer a atualização porque não é possível obter informações do disco da instância

Problema

A atualização não é suportada para instâncias de blocos de notas geridas pelo utilizador com um único disco.

Solução

Recomendamos que migre os dados do utilizador para uma nova instância de blocos de notas geridos pelo utilizador.

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

Problema

O Vertex AI Workbench depende da compatibilidade com UEFI para concluir uma atualização.

As instâncias de blocos de notas geridas pelo utilizador criadas a partir de algumas imagens mais antigas não são compatíveis com UEFI e, por isso, não podem ser atualizadas.

Solução

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

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

Substitua o seguinte:

  • INSTANCE_NAME: o nome da sua instância
  • ZONE: a zona onde a sua instância está localizada

Para verificar se a imagem que usou 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 que usou para criar a sua instância.

Se determinar que a sua instância ou imagem não é compatível com UEFI, pode tentar migrar os dados do utilizador para uma nova instância de blocos de notas geridos pelo utilizador. Para o fazer, conclua os seguintes passos:

  1. Verifique se a imagem que quer usar para criar a nova instância é compatível com UEFI. Para o fazer, escreva o seguinte comando no Cloud Shell ou em qualquer ambiente onde a CLI do Google Cloud 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 quer usar para criar a sua instância.

  2. Migre os seus dados do utilizador para uma nova instância de blocos de notas geridos pelo utilizador.

A instância de blocos de notas gerida pelo utilizador não está acessível após a atualização

Problema

Se a instância de blocos de notas geridos pelo utilizador não estiver acessível após uma atualização, pode ter ocorrido uma falha durante a substituição da imagem do disco de arranque.

As instâncias de blocos de notas geridas pelo utilizador que podem ser atualizadas são de disco duplo, com um disco de arranque e um disco de dados. O processo de atualização atualiza o disco de arranque para uma nova imagem, ao mesmo tempo que preserva os seus dados no disco de dados.

Solução

Conclua os passos seguintes para anexar uma nova imagem válida ao disco de arranque.

  1. Para armazenar os valores que vai usar para concluir este procedimento, escreva o seguinte comando no Cloud Shell ou em qualquer ambiente onde a CLI do Google Cloud esteja instalada.

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

    Substitua o seguinte:

    • MY_INSTANCE_NAME: o nome da sua instância
    • MY_PROJECT_ID: o ID do seu projeto
    • MY_ZONE: a zona onde a sua instância está localizada

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

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

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

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

  4. Elimine 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 eliminar a instância de notebooks geridos pelo utilizador.

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

  6. Crie uma instância de notebooks geridos pelo utilizador 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 o seguinte:

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

Monitorizar o estado de funcionamento das instâncias de blocos de notas geridas pelo utilizador

Esta secção descreve como resolver problemas com erros de monitorização do estado de funcionamento.

Falha no estado de docker-proxy-agent

Siga estes passos após uma falha do estado docker-proxy-agent:

  1. Verifique se o agente de proxy invertido está em execução. Caso contrário, avance para o passo 3.

  2. Reinicie o agente de proxy invertido.

  3. Volte a registar-se no servidor proxy inverso.

Falha no estado de docker-service

Siga estes passos após uma falha do estado docker-service:

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

  2. Reinicie o serviço Docker.

Falha no estado de jupyter-service

Siga estes passos após uma falha do estado jupyter-service:

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

  2. Reinicie o serviço Jupyter.

Falha no estado de jupyter-api

Siga estes passos após uma falha do estado jupyter-api:

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

  2. Reinicie o serviço Jupyter.

Percentagem de utilização do disco de arranque

O estado do espaço do disco de arranque é não saudável se o espaço do disco estiver mais de 85% cheio.

Se o estado do espaço no disco de arranque for mau, experimente o seguinte:

  1. A partir de uma sessão de terminal na instância de blocos de notas gerida pelo utilizador ou usando ssh para estabelecer ligação, verifique a quantidade de espaço livre no disco usando o comando df -H.

  2. Use o comando find . -type d -size +100M para ajudar a encontrar ficheiros grandes que pode eliminar, mas não os elimine a menos que tenha a certeza de que o pode fazer em segurança. Se não tiver a certeza, pode obter ajuda do apoio técnico.

  3. Se os passos anteriores não resolverem o problema, receba apoio técnico.

Percentagem de utilização do disco de dados

O estado do espaço no disco de dados é não saudável se o espaço no disco estiver mais de 85% cheio.

Se o estado do espaço no disco de dados for mau, experimente o seguinte:

  1. A partir de uma sessão de terminal na instância de blocos de notas gerida pelo utilizador ou usando ssh para estabelecer ligação, verifique a quantidade de espaço livre no disco usando o comando df -h -T /home/jupyter.

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

  3. Se os passos anteriores não resolverem o problema, receba apoio técnico.

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

Problema

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

Solução

As extensões do JupyterLab de terceiros não são suportadas em instâncias de blocos de notas geridas pelo utilizador.

Restaure a instância

Problema

Não é suportada a restauração de uma instância de notebooks gerida pelo utilizador após a sua eliminação.

Solução

Para fazer uma cópia de segurança dos dados na sua instância, pode guardar os seus blocos de notas no GitHub ou criar um instantâneo do disco.

Recupere dados de uma instância

Problema

Não é possível recuperar dados de uma instância de blocos de notas gerida pelo utilizador depois de esta ter sido eliminada.

Solução

Para fazer uma cópia de segurança dos dados na sua instância, pode guardar os seus blocos de notas no GitHub ou criar um instantâneo do disco

Não é possível aumentar a memória partilhada

Problema

Não pode aumentar a memória partilhada numa instância de notebooks geridos pelo utilizador existente.

Solução

No entanto, pode especificar um tamanho da memória partilhada quando cria uma instância de blocos de notas geridos pelo utilizador através da chave de metadados container-custom-params, com um valor semelhante ao seguinte:

--shm-size=SHARED_MEMORY_SIZE gb

Substitua SHARED_MEMORY_SIZE pelo tamanho que quer em GB.

Procedimentos úteis

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

Use o SSH para se ligar à instância de blocos de notas geridos pelo utilizador

Use o SSH para se ligar à sua instância escrevendo o seguinte comando no Cloud Shell ou em qualquer ambiente onde a CLI Google Cloud esteja instalada.

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

Substitua o seguinte:

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

Também pode ligar-se à sua instância abrindo a página de detalhes do Compute Engine da instância e, de seguida, clicando no botão SSH.

Volte a registar-se no servidor proxy inverso

Para voltar a registar a instância de blocos de notas geridos pelo utilizador no servidor proxy inverso interno, pode parar e iniciar a VM na página Blocos de notas geridos pelo utilizador ou usar o SSH para estabelecer ligação à instância de blocos de notas geridos pelo utilizador e introduzir:

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

Valide o estado do serviço Docker

Para verificar o estado do serviço Docker, pode usar o SSH para estabelecer ligação à sua instância de blocos de notas gerida pelo utilizador e introduzir:

sudo service docker status

Verifique se o agente de proxy invertido está em execução

Para verificar se o agente do proxy inverso do bloco de notas está em execução, use o SSH para estabelecer ligação à instância de blocos de notas geridos pelo utilizador e introduza:

# 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 estado do serviço Jupyter e recolha registos

Para verificar o estado do serviço Jupyter, pode usar o SSH para se ligar à instância de blocos de notas geridos pelo utilizador e introduzir:

sudo service jupyter status

Para recolher registos de serviços do Jupyter:

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

Verifique se a API interna do Jupyter está ativa

A API Jupyter deve ser sempre executada na porta 8080. Pode verificar esta situação inspecionando os registos do sistema da instância para ver se existe uma entrada semelhante à seguinte:

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

Para verificar se a API interna do Jupyter está ativa, também pode usar o SSH para se ligar à instância de blocos de notas gerida pelo utilizador e introduzir:

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

Também pode medir o tempo que a API demora a responder caso os pedidos estejam a demorar demasiado 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

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

Reinicie o serviço Docker

Para reiniciar o serviço Docker, pode parar e iniciar a VM na página Notebooks geridos pelo utilizador ou pode usar o SSH para se ligar à instância de notebooks geridos pelo utilizador e introduzir:

sudo service docker restart

Reinicie o agente de proxy invertido

Para reiniciar o agente de proxy invertido, pode parar e iniciar a VM na página Notebooks geridos pelo utilizador ou pode usar o SSH para se ligar à instância de notebooks geridos pelo utilizador e introduzir:

sudo docker restart proxy-agent

Reinicie o serviço Jupyter

Para reiniciar o serviço Jupyter, pode parar e iniciar a VM na página Blocos de notas geridos pelo utilizador ou pode usar o SSH para estabelecer ligação à instância de blocos de notas geridos pelo utilizador e introduzir:

sudo service jupyter restart

Reinicie o agente de recolha do Notebooks

O serviço Notebooks Collection Agent executa um processo Python em segundo plano que verifica o estado dos serviços principais da instância do Vertex AI Workbench.

Para reiniciar o serviço do agente da coleção de notebooks, pode parar e iniciar a VM a partir da Google Cloud consola ou pode usar o SSH para se ligar à instância do Vertex AI Workbench e introduzir:

sudo systemctl stop notebooks-collection-agent.service

seguido de:

sudo systemctl start notebooks-collection-agent.service

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

Modifique o script do agente de recolha do Notebooks

Para aceder e editar o guião, abra um terminal na nossa instância ou use ssh para estabelecer ligação à sua instância do Vertex AI Workbench, e introduza:

nano /opt/deeplearning/bin/notebooks_collection_agent.py

Depois de editar o ficheiro, lembre-se de o guardar.

Em seguida, tem de reiniciar o serviço do agente de recolha de blocos de notas.

Verifique se a instância consegue resolver os domínios DNS necessários

Para verificar se a instância consegue resolver os domínios DNS necessários, pode usar o SSH para se ligar à instância de blocos de notas geridos pelo utilizador e introduzir:

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, pode verificar se a instância 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 estes comandos na sua instância do Vertex AI Workbench, abra o JupyterLab e crie um novo terminal.

Crie uma cópia dos dados do utilizador numa instância

Para armazenar uma cópia dos dados do utilizador de uma instância no Cloud Storage, conclua os seguintes passos.

Crie um contentor do Cloud Storage (opcional)

No mesmo projeto onde a sua instância está localizada, crie um contentor do Cloud Storage onde possa armazenar os dados do utilizador. Se já tiver um contentor do Cloud Storage, ignore este passo.

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

    Copie os seus dados do utilizador

    1. Na interface do JupyterLab da sua instância, selecione Ficheiro > Novo > Terminal para abrir uma janela de terminal. Para instâncias de notebooks geridas pelo utilizador, pode, em alternativa, usar o SSH para se ligar ao terminal da instância.

    2. Use a CLI gcloud para copiar os dados do utilizador para um contentor do Cloud Storage. O comando de exemplo seguinte copia todos os ficheiros do diretório /home/jupyter/ da sua instância para um diretório num contentor do Cloud Storage.

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

      Substitua o seguinte:

      • BUCKET_NAME: o nome do seu contentor do Cloud Storage
      • PATH: o caminho para o diretório onde quer copiar os seus ficheiros, por exemplo: /copy/jupyter/

    Investigue uma instância bloqueada no aprovisionamento através do gcpdiag

    gcpdiag é uma ferramenta de código aberto. Não é um produto Google Cloud suportado oficialmente. Pode usar a ferramenta gcpdiag para ajudar a identificar e corrigir Google Cloud problemas do projeto. Para mais informações, consulte o projeto gcpdiag no GitHub.

    Este gcpdiagrunbook investiga as potenciais causas de uma instância do Vertex AI Workbench ficar bloqueada no estado de aprovisionamento, incluindo as seguintes áreas:
    • Estado: verifica o estado atual da instância para garantir que está bloqueada no aprovisionamento e não parada nem ativa.
    • Imagem do disco de arranque da VM do Compute Engine da instância: Verifica se a instância foi criada com um contentor personalizado, uma imagem workbench-instances oficial, imagens de VMs de aprendizagem avançada ou imagens não suportadas que podem fazer com que a instância fique bloqueada no estado de aprovisionamento.
    • Scripts personalizados: verifica se a instância está a usar scripts de arranque ou pós-arranque personalizados que alteram a porta Jupyter predefinida ou quebram dependências que podem fazer com que a instância fique bloqueada no estado de aprovisionamento.
    • Versão do ambiente: verifica se a instância está a usar a versão mais recente do ambiente, verificando a respetiva capacidade de atualização. As versões anteriores podem fazer com que a instância fique bloqueada no estado de aprovisionamento.
    • Desempenho da VM do Compute Engine da instância: Verifica o desempenho atual da VM para garantir que não está prejudicado por uma utilização elevada da CPU, memória insuficiente ou problemas de espaço em disco que possam interromper as operações normais.
    • Porta série do Compute Engine da instância ou registo do sistema: verifica se a instância tem registos da porta série, que são analisados para garantir que o Jupyter está em execução na porta 127.0.0.1:8080.
    • Acesso ao terminal e ao SSH do Compute Engine da instância: verifica se a VM do Compute Engine da instância está em execução para que o utilizador possa usar o SSH e abrir um terminal para verificar se a utilização do espaço em "home/jupyter" é inferior a 85%. Se não restar espaço, isto pode fazer com que a instância fique bloqueada no estado de aprovisionamento.
    • IP externo desativado: verifica se o acesso ao IP externo está desativado. Uma configuração de rede incorreta pode fazer com que a instância fique bloqueada no estado de aprovisionamento.

    Docker

    Pode executar o gcpdiag usando um wrapper que inicia o gcpdiag num contentor do Docker. O Docker ou o Podman têm de estar instalados.

    1. Copie e execute o seguinte comando na sua 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 manual de procedimentos.

    Substitua o seguinte:

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

    Sinalizações úteis:

    Para ver uma lista e uma descrição de todas as flags da ferramenta gcpdiag, consulte as gcpdiag instruções de utilização.

    Erros de autorizações ao usar funções de contas de serviço com o Vertex AI

    Problema

    Recebe erros de autorizações gerais quando usa funções de contas de serviço com o Vertex AI.

    Estes erros podem aparecer no Cloud Logging nos registos de componentes do produto ou nos registos de auditoria. Também podem aparecer em qualquer combinação dos projetos afetados.

    Estes problemas podem dever-se a uma ou ambas das seguintes situações:

    • Uso da função Service Account Token Creator quando devia ter sido usada a função Service Account User ou vice-versa. Estas funções concedem autorizações diferentes numa conta de serviço e não são intercambiáveis. Para saber mais sobre as diferenças entre as funções de Service Account Token Creator e Service Account User, consulte o artigo Funções da conta de serviço.

    • Concedeu autorizações de uma conta de serviço em vários projetos, o que não é permitido por predefinição.

    Solução

    Para resolver o problema, experimente uma ou mais das seguintes opções:

    • Determine se é necessária a função de Service Account Token Creator ou Service Account User. Para saber mais, leia a documentação da IAM para os serviços do Vertex AI que está a usar, bem como quaisquer outras integrações de produtos que esteja a usar.

    • Se concedeu autorizações a uma conta de serviço em vários projetos, certifique-se de que iam.disableCrossProjectServiceAccountUsage para permitir que as contas de serviço sejam anexadas em vários projetos. não está aplicada. Para garantir que iam.disableCrossProjectServiceAccountUsage não é aplicada, execute o seguinte comando:

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