排解 Vertex AI Workbench 問題

本頁面說明疑難排解步驟，解決您使用 Vertex AI Workbench 時可能遇到的問題。

如需使用 Vertex AI 其他元件的協助，請參閱排解 Vertex AI 問題。

如要篩選這個頁面的內容，請按一下主題：

Vertex AI Workbench 執行個體

本節說明如何排解 Vertex AI Workbench 執行個體的問題。

連線及開啟 JupyterLab

本節說明如何排解連線至 JupyterLab 和開啟 JupyterLab 的問題。

按一下「Open JupyterLab」後沒有任何反應

問題

按一下「Open JupyterLab」後沒有任何反應。

解決方案

確認瀏覽器不會封鎖自動開啟的新分頁。JupyterLab 會在新瀏覽器分頁中開啟。

無法存取 Vertex AI Workbench 執行個體中的終端機

問題

如果無法存取終端機，或是在啟動器中找不到終端機視窗，可能是因為 Vertex AI Workbench 執行個體未啟用終端機存取權。

解決方案

您必須建立新的 Vertex AI Workbench 執行個體，並啟用「終端機存取權」選項。執行個體建立完成後，即無法變更這項設定。

開啟 JupyterLab 時發生 502 錯誤

問題

502 錯誤可能表示 Vertex AI Workbench 執行個體尚未準備就緒。

解決方案

稍等幾分鐘，然後重新整理 Google Cloud 控制台瀏覽器分頁，再試一次。

筆記型電腦沒有回應

問題

Vertex AI Workbench 執行個體未執行儲存格，或似乎已凍結。

解決方案

首先，請依序點選頂端選單中的「Kernel」和「Restart Kernel」，重新啟動核心。如果還是無法解決問題，請嘗試下列做法：

  • 重新整理 JupyterLab 瀏覽器頁面。未儲存的儲存格輸出內容不會保留，因此您必須重新執行這些儲存格，才能重新產生輸出內容。
  • 重設執行個體。

無法使用 SSH 連線至 Vertex AI Workbench 執行個體

問題

您無法透過終端機視窗，使用 SSH 連線至執行個體。

Vertex AI Workbench 執行個體會使用 OS 登入功能啟用 SSH 存取權。建立執行個體時，Vertex AI Workbench 會將中繼資料金鑰 enable-oslogin 設為 TRUE，預設啟用 OS 登入功能。如果無法使用 SSH 連線至執行個體，可能需要將這個中繼資料金鑰設為 TRUE。

解決方案

系統不支援使用 Google Cloud 控制台連線至 Vertex AI Workbench 執行個體。如果無法透過終端機視窗使用 SSH 連線至執行個體，請參閱下列文章：

如要將中繼資料金鑰 enable-oslogin 設為 TRUE，請使用 Notebooks API 中的 projects.locations.instances.patch 方法，或 Google Cloud SDK 中的 gcloud workbench instances update 指令。

已超過 GPU 配額

問題

您無法建立含 GPU 的 Vertex AI Workbench 執行個體。

解決方案

如要判斷專案可用的 GPU 數量，請查看配額頁面。 如果配額頁面未列出 GPU，或您需要額外的 GPU 配額，請要求增加 Compute Engine GPU 配額。請參閱「要求提高配額限制」一文。

建立 Vertex AI Workbench 執行個體

本節說明如何排解建立 Vertex AI Workbench 執行個體時發生的問題。

執行個體無限期處於待處理狀態，或卡在佈建狀態

問題

建立 Vertex AI Workbench 執行個體後，執行個體會無限期處於待處理狀態。序列記錄中可能會出現類似下列的錯誤：

Could not resolve host: notebooks.googleapis.com

如果執行個體停滯在佈建狀態，可能是因為執行個體的私人網路設定無效。

解決方案

請按照「執行個體記錄顯示連線或逾時錯誤」一節中的步驟操作。

無法在共用虛擬私有雲網路中建立執行個體

問題

嘗試在共用虛擬私有雲網路中建立執行個體時，會收到類似以下的錯誤訊息：

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

解決方案

問題在於Notebooks 服務帳戶嘗試建立執行個體，但沒有正確的權限。

為確保 Notebooks 服務帳戶具備必要權限，能在共用虛擬私有雲網路中建立 Vertex AI Workbench 執行個體，請要求管理員將主專案的 Compute 網路使用者角色 (roles/compute.networkUser) IAM 角色授予 Notebooks 服務帳戶。

如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和機構的存取權」。

這個預先定義的角色具備必要的權限，可確保 Notebooks 服務帳戶能在共用虛擬私有雲網路中建立 Vertex AI Workbench 執行個體。如要查看確切的必要權限，請展開「必要權限」部分：

所需權限

如要確保 Notebooks 服務帳戶可以在共用虛擬私有雲網路中建立 Vertex AI Workbench 執行個體，請授予下列權限：

  • 如何使用子網路： compute.subnetworks.use

管理員或許還可透過自訂角色或其他預先定義的角色，將這些權限授予 Notebooks 服務帳戶。

無法使用自訂容器建立 Vertex AI Workbench 執行個體

問題

在 Google Cloud 控制台中建立 Vertex AI Workbench 執行個體時，無法使用自訂容器。

解決方案

Vertex AI Workbench 執行個體不支援新增自訂容器，且您無法使用 Google Cloud 控制台新增自訂容器。

建議新增 conda 環境，而非使用自訂容器。

您可以使用 Notebooks API 將自訂容器新增至 Vertex AI Workbench 執行個體，但這項功能不受支援。

沒有「掛接共用儲存空間」按鈕

問題

JupyterLab 介面的「File Browser」(檔案瀏覽器) 分頁中沒有「Mount shared storage」(掛接共用儲存空間) 按鈕。

解決方案

您必須具備 storage.buckets.list 權限，Vertex AI Workbench 執行個體的 JupyterLab 介面才會顯示「掛接共用儲存空間」按鈕。請管理員授予 Vertex AI Workbench 執行個體服務帳戶專案的 storage.buckets.list 權限。

使用 Dataproc 時發生 599 錯誤

問題

嘗試建立啟用 Dataproc 的執行個體時，會收到類似以下的錯誤訊息：

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

解決方案

在 Cloud DNS 設定中，為 *.googleusercontent.com 網域新增 Cloud DNS 項目。

無法安裝第三方 JupyterLab 擴充功能

問題

嘗試安裝第三方 JupyterLab 擴充功能時，會出現 Error: 500 訊息。

解決方案

Vertex AI Workbench 執行個體不支援第三方 JupyterLab 擴充功能。

無法編輯基礎虛擬機器

問題

嘗試編輯 Vertex AI Workbench 執行個體的基礎虛擬機器 (VM) 時，可能會收到類似以下的錯誤訊息：

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

解決方案

發生這項錯誤的原因是，您無法使用 Google Cloud 控制台或 Compute Engine API 編輯執行個體的基礎 VM。

如要編輯 Vertex AI Workbench 執行個體底層的 VM，請使用 Notebooks API 中的 projects.locations.instances.patch 方法，或 Google Cloud SDK 中的 gcloud workbench instances update 指令。

新增 conda 環境後，無法使用 pip 套件

問題

新增以 conda 為基礎的核心後，就無法使用 pip 套件。

解決方案

如要解決這個問題，請參閱「新增 conda 環境」，並嘗試下列做法：

  • 確認您已使用 DL_ANACONDA_ENV_HOME 變數，且該變數包含環境名稱。

  • 確認 pip 位於類似 opt/conda/envs/ENVIRONMENT/bin/pip 的路徑中。您可以執行 which pip 指令來取得路徑。

無法存取或複製僅限單一使用者存取的執行個體資料

問題

您無法存取單一使用者存取權例項的資料。

如果 Vertex AI Workbench 執行個體設定為單一使用者存取權，只有指定的單一使用者 (擁有者) 才能存取執行個體上的資料。

解決方案

如要存取或複製執行個體中的資料，但您不是執行個體擁有者，請開啟支援案件。

意外關機

問題

Vertex AI Workbench 執行個體意外關閉。

解決方案

如果執行個體無預警關機，可能是因為系統啟動了閒置關機。

如果您已啟用閒置關機功能，執行個體會在指定時間內沒有任何核心活動時關機。舉例來說，在筆記本中執行儲存格或列印新輸出內容，都會重設閒置逾時計時器。CPU 使用量不會重設閒置逾時計時器。

執行個體記錄檔顯示連線或逾時錯誤

問題

Vertex AI Workbench 執行個體的記錄會顯示連線或逾時錯誤。

解決方案

如果發現執行個體記錄中出現連線或逾時錯誤，請確認 Jupyter 伺服器是否在通訊埠 8080 上執行。按照「確認 Jupyter 內部 API 是否已經啟動」一節中的步驟操作。

如果已關閉 External IP，且您使用的是私人虛擬私有雲網路，請務必也遵循網路設定選項說明文件。 請考量下列事項：

執行個體記錄顯示「無法與 Jupyter API 聯絡」和「ReadTimeoutError」

問題

Vertex AI Workbench 執行個體記錄會顯示類似下列的錯誤：

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

解決方案

請按照「執行個體記錄顯示連線或逾時錯誤」一節中的步驟操作。您也可以嘗試修改 Notebooks Collection Agent 指令碼，將 HTTP_TIMEOUT_SESSION 變更為較大的值 (例如 60)，藉此確認要求是否因呼叫回應時間過長或無法連線至要求的網址而失敗。

docker0 與虛擬私有雲位址發生位址衝突

問題

根據預設，docker0 介面會以 172.17.0.1/16 的 IP 位址建立。這可能會與虛擬私有雲網路中的 IP 位址衝突，導致執行個體無法使用 172.17.0.1/16 位址連線至其他端點。

解決方案

您可以透過下列開機後指令碼，並將開機後指令碼行為設為 run_once，強制建立 docker0 介面，並使用與虛擬私有雲網路不衝突的 IP 位址。

   #!/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

指定的預留項目不存在

問題

建立執行個體的作業會產生 Specified reservations do not exist 錯誤訊息。作業的輸出內容可能如下所示：

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

解決方案

部分 Compute Engine 機器類型在建立時需要額外參數，例如本機磁碟或最低 CPU 平台。執行個體規格必須包含這些額外欄位。

舉例來說，a3-megagpu-8g 機器類型需要 16 個本機 SSD 磁碟，這些磁碟必須納入預訂項目，並在執行個體建立要求中指定。

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

代管的筆記本

本節說明如何排解代管筆記本的問題。

連線及開啟 JupyterLab

本節說明如何排解連線及開啟 JupyterLab 時發生的問題。

按一下「Open JupyterLab」後沒有任何反應

問題

按一下「Open JupyterLab」後沒有任何反應。

解決方案

確認瀏覽器不會封鎖自動開啟的新分頁。JupyterLab 會在新瀏覽器分頁中開啟。

無法使用 SSH 連線至受管理筆記本執行個體

問題

您無法使用 SSH 連線至受管理筆記本執行個體。

解決方案

無法透過 SSH 存取受管理的筆記本執行個體。

無法存取代管型筆記本執行個體中的終端機

問題

如果無法存取終端機，或在啟動器中找不到終端機視窗，可能是因為受管理筆記本執行個體未啟用終端機存取權。

解決方案

您必須建立新的代管筆記本執行個體，並啟用「終端機存取」選項。執行個體建立完成後，即無法變更這項設定。

開啟 JupyterLab 時發生 502 錯誤

問題

502 錯誤可能表示受管理筆記本執行個體尚未準備就緒。

解決方案

稍等幾分鐘，然後重新整理 Google Cloud 控制台瀏覽器分頁，再試一次。

開啟筆記本造成 524 (發生逾時) 錯誤

問題

524 錯誤通常表示反向 Proxy 代理程式無法連線至反向 Proxy 伺服器，或後端伺服器端 (Jupyter) 的要求處理時間過長。這項錯誤的常見原因包括網路問題、反向 Proxy 代理程式未執行，或是 Jupyter 服務未執行。

解決方案

確認代管筆記本執行個體已啟動。

筆記型電腦沒有回應

問題

代管的筆記本執行個體未執行儲存格，或似乎已凍結。

解決方案

首先，請依序點選頂端選單中的「Kernel」和「Restart Kernel」，重新啟動核心。如果還是無法解決問題，請嘗試下列做法：

  • 重新整理 JupyterLab 瀏覽器頁面。未儲存的儲存格輸出內容不會保留，因此您必須重新執行這些儲存格，才能重新產生輸出內容。
  • 重設執行個體。

改用 Vertex AI Workbench 執行個體

本節說明如何診斷及解決從代管型筆記本執行個體遷移至 Vertex AI Workbench 執行個體時發生的問題。

找不到代管型筆記本執行個體中的核心

問題

代管型筆記本執行個體中的核心不會顯示在您遷移到的 Vertex AI Workbench 執行個體中。

自訂容器會以核心的形式顯示在受管理筆記本中。 Vertex AI Workbench 遷移工具不支援遷移自訂容器。

解決方案

如要解決這個問題，請在 Vertex AI Workbench 執行個體中新增 conda 環境。

遷移的執行個體中框架版本不同

問題

代管型筆記本執行個體中的架構版本，與您遷移至的 Vertex AI Workbench 執行個體不同。

Vertex AI Workbench 執行個體提供預設的架構版本組合。遷移工具不會新增原始受管理筆記本執行個體的架構版本。請參閱預設遷移工具行為。

解決方案

如要新增特定版本的架構，請將 conda 環境新增至 Vertex AI Workbench 執行個體。

GPU 不會遷移至新的 Vertex AI Workbench 執行個體

問題

您遷移到的 Vertex AI Workbench 執行個體，不包含代管型筆記本執行個體中的 GPU。

Vertex AI Workbench 執行個體支援預設的 GPU 集。如果原始受管理筆記本執行個體中的 GPU 無法使用，系統會遷移執行個體，但不含任何 GPU。

解決方案

遷移後，您可以使用 Notebooks API 中的 projects.locations.instances.patch 方法，或 Google Cloud SDK 中的 gcloud workbench instances update 指令，將 GPU 新增至 Vertex AI Workbench 執行個體。

遷移的執行個體機器類型不同

問題

代管型筆記本執行個體的機器類型，與您遷移到的 Vertex AI Workbench 執行個體不同。

Vertex AI Workbench 執行個體不支援所有機器類型。如果原始代管筆記本執行個體中的機器類型無法使用，系統會將執行個體遷移至 e2-standard-4 機器類型。

解決方案

遷移後，您可以使用 Notebooks API 中的 projects.locations.instances.patch 方法，或 Google Cloud SDK 中的 gcloud workbench instances update 指令，變更 Vertex AI Workbench 執行個體的機器類型。

已超過 GPU 配額

問題

您無法建立具備 GPU 的代管型筆記本執行個體。

解決方案

如要判斷專案可用的 GPU 數量，請查看配額頁面。 如果配額頁面未列出 GPU，或您需要額外的 GPU 配額，請要求增加配額。請參閱「要求提高配額限制」。

使用容器映像檔

本節說明如何排解使用容器映像檔時的問題。

容器映像檔未顯示為 JupyterLab 中的核心

問題

如果容器映像檔沒有有效的 kernelspec，就無法在 JupyterLab 中成功載入為核心。

解決方案

請確認容器符合我們的規定。詳情請參閱自訂容器需求。

長時間執行的作業導致筆記本中斷連線

問題

如果在筆記本中執行工作時看到下列錯誤訊息，可能是因為要求載入時間過長，或是 CPU 或記憶體使用率偏高，導致 Jupyter 服務沒有回應。

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

解決方案

這個問題是因為在筆記本中執行長時間執行的工作所致。如要執行可能需要長時間才能完成的工作，建議使用執行器。

使用執行器

本節說明如何排解使用執行器時的問題。

執行者無法安裝套件

問題

執行器會在與核心不同的環境中執行筆記本程式碼，您會在核心中執行筆記本檔案的程式碼。因此，您安裝的部分套件可能無法在執行器的環境中使用。

解決方案

如要解決這個問題，請參閱「確保執行者可安裝套件」。

使用執行器執行筆記本程式碼時發生 401 或 403 錯誤

問題

執行器執行時發生 401 或 403 錯誤，可能表示執行器無法存取資源。

解決方案

可能原因如下：

  • 執行器會在與受管理筆記本執行個體專案不同的租戶專案中，執行筆記本程式碼。因此，當您透過執行器執行的程式碼存取資源時，執行器預設可能不會連線至正確的 Google Cloud 專案。如要解決這個問題，請明確選取專案。

  • 根據預設，代管筆記本執行個體可以存取相同專案中的資源，因此手動執行筆記本檔案的程式碼時，這些資源不需要額外驗證。不過，由於執行器是在不同的租戶專案中執行，因此沒有相同的預設存取權。如要解決這個問題，請使用服務帳戶驗證存取權。

  • 執行器無法使用使用者憑證驗證資源存取權，例如 gcloud auth login 指令。如要解決這個問題，請使用服務帳戶驗證存取權。

使用執行器時發生 exited with a non-zero status of 127 錯誤

問題

如果使用執行程式在未安裝 nbexecutor 擴充功能的自訂容器上執行程式碼，可能會發生 exited with a non-zero status of 127 錯誤或「找不到指令」錯誤。

解決方案

如要確保自訂容器具有 nbexecutor 擴充功能，可以從深度學習容器映像檔建立衍生容器映像檔。深度學習容器映像檔包含 nbexecutor 擴充功能。

服務聯播網設定無效錯誤訊息

問題

這個錯誤可能如下所示：

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

這表示系統在您網路的已分配 IP 範圍中，找不到任何可用區塊。

解決方案

使用 /24 或更低的子網路遮罩。建立更大的已分配 IP 位址範圍，然後修改 servicenetworking-googleapis-com 的私人服務連線，附加這個範圍。

詳情請參閱「設定網路」一文。

無法安裝第三方 JupyterLab 擴充功能

問題

嘗試安裝第三方 JupyterLab 擴充功能時，會出現 Error: 500 訊息。

解決方案

代管筆記本執行個體不支援第三方 JupyterLab 擴充功能。

無法存取或複製僅限單一使用者存取的執行個體資料

問題

您無法存取單一使用者存取權例項的資料。

解決方案

如果是設定為單一使用者存取的受管理筆記本執行個體，只有指定使用者 (擁有者) 可以存取執行個體上的資料。

如要存取或複製執行個體中的資料，但您不是執行個體擁有者，請開啟支援案件。

意外關機

問題

Vertex AI Workbench 執行個體意外關閉。

解決方案

如果執行個體無預警關機，可能是因為系統啟動了閒置關機。

如果您已啟用閒置關機功能，執行個體會在指定時間內沒有任何核心活動時關機。舉例來說，在筆記本中執行儲存格或列印新輸出內容，都會重設閒置逾時計時器。CPU 使用量不會重設閒置逾時計時器。

還原執行個體

問題

系統不支援在刪除代管筆記本執行個體後還原。

解決方案

如要備份執行個體中的資料，可以將筆記本儲存至 GitHub。

從執行個體復原資料

問題

刪除代管筆記本執行個體後，系統不支援復原資料。

解決方案

如要備份執行個體中的資料，可以將筆記本儲存至 GitHub。

建立代管型筆記本執行個體

本節說明如何排解建立代管 Notebook 執行個體的問題。

錯誤：建立連線時發生問題

問題

建立執行個體時發生這項錯誤：

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

解決方案

建立大於 /24 的分配 IP 範圍，然後修改 servicenetworking-googleapis-com 連線的私人服務連線，附加這個範圍。

建立執行個體時發生資源可用性錯誤

問題

由於資源可用性錯誤，您無法建立執行個體。

這個錯誤可能如下所示：

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

如果您在某個區域要求新資源，但該區域目前無法提供 Compute Engine 資源 (例如 GPU 或 CPU)，因此無法滿足您的要求，就會發生資源錯誤。

資源錯誤只會影響區域中的新資源要求，不會影響現有資源。資源錯誤與 Compute Engine 配額無關。資源錯誤是暫時性的，並且可能會根據波動的需求而頻繁變更。

解決方案

如要繼續，請嘗試下列方法：

  • 建立使用不同機器類型的執行個體。
  • 在其他可用區建立執行個體。
  • 請稍後再試。
  • 減少要求的資源數量。舉例來說，您可以嘗試建立 GPU、磁碟、vCPU 或記憶體較少的執行個體。

啟動執行個體時發生資源可用性錯誤

問題

由於資源可用性錯誤，您無法啟動執行個體。

這個錯誤可能如下所示：

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

如果您嘗試在無法滿足要求的可用區中啟動執行個體，就會發生資源錯誤，因為目前無法使用 Compute Engine 資源 (例如 GPU 或 CPU)。

資源錯誤只適用於您在傳送要求時指定的要求資源，不適用於可用區中的所有資源。資源錯誤與 Compute Engine 配額無關。資源錯誤是暫時性的，並且可能會根據波動的需求而頻繁變更。

解決方案

如要繼續，請嘗試下列方法：

  • 變更執行個體的機器類型。
  • 將檔案和資料遷移至其他區域的執行個體。
  • 請稍後再試。
  • 減少要求的資源數量。舉例來說，啟動的執行個體可以減少 GPU、磁碟、vCPU 或記憶體。

No route to host，從代管型筆記本建立連出連線

問題

一般來說，您在 Google Cloud 控制台中只會看到 VPC 本身已知的路徑，以及完成 VPC 網路對等互連設定時保留的範圍。

代管筆記本執行個體位於 Google 代管網路中，並在執行個體內的 Docker 網路命名空間中執行修改後的 Jupyter 版本。

這個執行個體上的 Docker 網路介面和 Linux 橋接器可能會選取與虛擬私有雲透過對等互連匯出的 IP 範圍衝突的本機 IP。這些通常分別位於 172.16.0.0/161 和 192.168.10.0/24 範圍。

在這種情況下，執行個體連出至這些範圍的連線會失敗，並顯示 No route to host 的某種變體，即使虛擬私有雲路徑已正確共用也一樣。

解決方案

在終端機工作階段中叫用 ifconfig，並確認執行個體中任何虛擬介面上的 IP 位址，都不會與虛擬私有雲匯出至對等互連連線的 IP 範圍衝突。

使用者自行管理的筆記本

本節說明如何排解使用者管理的筆記本問題。

連線及開啟 JupyterLab

本節說明如何排解連線及開啟 JupyterLab 時發生的問題。

按一下「Open JupyterLab」後沒有任何反應

問題

按一下「Open JupyterLab」後沒有任何反應。

解決方案

確認瀏覽器不會封鎖自動開啟的新分頁。JupyterLab 會在新瀏覽器分頁中開啟。

無法透過反向 Proxy 伺服器存取 JupyterLab

問題

您無法存取 JupyterLab。

Vertex AI Workbench 會使用 Google 內部反向 Proxy 伺服器，提供 JupyterLab 的存取權。使用者管理的筆記本執行個體設定、網路設定和其他因素可能會導致 JupyterLab 無法存取。

解決方案

使用 SSH 連線至 JupyterLab，進一步瞭解無法透過反向 Proxy 存取的原因。

無法使用 SSH 連線至使用者管理的筆記本執行個體

問題

您無法透過終端機視窗，使用 SSH 連線至執行個體。

使用者管理的 Notebooks 執行個體會使用 OS 登入功能啟用 SSH 存取權。建立執行個體時，Vertex AI Workbench 會將中繼資料金鑰 enable-oslogin 設為 TRUE，預設啟用 OS 登入。如果無法使用 SSH 連線至執行個體，可能需要將這個中繼資料鍵設為 TRUE。

解決方案

如要為使用者啟用使用者管理的筆記本的 SSH 存取權，請完成在使用者帳戶上設定 OS Login 角色的步驟。

開啟使用者管理的筆記本執行個體時發生 403 (禁止) 錯誤

問題

開啟使用者管理的 Notebooks 執行個體時發生 403 (Forbidden) 錯誤，通常表示存取權有問題。

解決方案

如要排解存取問題，請考量授予使用者管理的筆記本執行個體存取權的三種方式：

  • 單一使用者
  • 服務帳戶
  • 專案編輯者

存取模式是在建立使用者管理的筆記本執行個體時設定，並定義於筆記本中繼資料中：

  • 單一使用者：proxy-mode=mail, proxy-user-mail=user@domain.com
  • 服務帳戶：proxy-mode=service_account
  • 專案編輯者：proxy-mode=project_editors

如果按一下「Open JupyterLab」(開啟 JupyterLab) 後無法存取筆記本，請嘗試下列做法：

以下範例說明如何建立執行個體時指定服務帳戶：

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

當您按一下「Open JupyterLab」開啟筆記本時，會在新的瀏覽器分頁中開啟筆記本。如果您登入多個 Google 帳戶，則會使用預設 Google 帳戶開啟新分頁。如果未使用預設的 Google 帳戶建立使用者管理的筆記本執行個體，新的瀏覽器分頁會顯示 403 (Forbidden) 錯誤。

無法存取 JupyterLab，已啟用單一使用者模式

問題

您無法存取 JupyterLab。

解決方案

如果使用者無法存取 JupyterLab，且執行個體的 JupyterLab 存取權設為 Single user only，請嘗試下列做法：

  1. 在 Google Cloud 控制台的「使用者管理的 Notebook」頁面中，按一下執行個體名稱，開啟「Notebook details」(Notebook 詳細資料) 頁面。

  2. 在「查看 VM 詳細資料」旁邊，按一下「在 Compute Engine 中查看」。

  3. 在 VM 詳細資料頁面中，按一下「編輯」。

  4. 在「Metadata」(中繼資料) 區段中，確認 proxy-mode 中繼資料項目已設為 mail。

  5. 確認 proxy-user-mail 中繼資料項目已設為有效的使用者電子郵件地址，而非服務帳戶。

  6. 按一下 [儲存]。

  7. 在 Google Cloud 控制台的「使用者管理的 Notebook」頁面，停止執行個體，然後重新啟動執行個體，藉此初始化更新後的中繼資料。

開啟筆記本造成 504 (閘道逾時) 錯誤

問題

這表示內部 Proxy 逾時或後端伺服器 (Jupyter) 逾時。以下列舉幾個合適的問題：

  • 要求從未送達內部反向 Proxy 伺服器
  • 後端 (Jupyter) 傳回 504 錯誤。

解決方案

建立 Google 支援案件。

開啟筆記本造成 524 (發生逾時) 錯誤

問題

在逾時期間內，內部反向 Proxy 伺服器未收到反向 Proxy 代理程式對要求的任何回應。反向 Proxy 代理程式會在使用者自行管理的筆記本執行個體中，以 Docker 容器的形式執行。524 錯誤通常表示反向 Proxy 代理程式無法連線至反向 Proxy 伺服器，或要求在後端伺服器端 (Jupyter) 耗費過多時間。這個錯誤通常發生在使用者端 (例如網路問題，或反向 Proxy 代理程式服務未執行)。

解決方案

如果無法存取筆記本，請確認您已啟動使用者管理的筆記本執行個體，然後嘗試下列做法：

方法 1：執行診斷工具，自動檢查及修復使用者代管筆記本的核心服務、驗證可用儲存空間，並產生實用的記錄檔。如要在執行個體中執行這項工具，請按照下列步驟操作：

  1. 確認執行個體使用 M58 以上版本。

  2. 使用 SSH 連線至深度學習 VM 映像檔執行個體。

  3. 執行下列指令：

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

    請注意，--repair 和 --bucket 旗標為選用。--repair 標記會嘗試修正常見的核心服務錯誤，而 --bucket 標記則可讓您指定 Cloud Storage bucket，用來儲存建立的記錄檔。

    這項指令的輸出內容會顯示使用者管理筆記本核心服務的實用狀態訊息，並匯出發現結果的記錄檔。

方法 2：按照下列步驟，逐一檢查特定使用者管理的筆記本需求。

開啟筆記本造成 598 (網路讀取逾時) 錯誤

問題

反向 Proxy 伺服器已超過 10 分鐘未收到反向 Proxy 代理程式的訊息。這強烈指出反向 Proxy 代理程式有問題。

解決方案

如果無法存取筆記本，請嘗試下列做法：

筆記型電腦沒有回應

問題

使用者管理的 Notebook 執行個體未執行儲存格，或似乎已凍結。

解決方案

首先，請依序點選頂端選單中的「Kernel」和「Restart Kernel」，重新啟動核心。如果還是無法解決問題，請嘗試下列做法：

  • 重新整理 JupyterLab 瀏覽器頁面。任何未儲存的儲存格輸出內容都不會保留，因此您必須再次執行這些儲存格，才能重新產生輸出內容。
  • 在筆記本的終端機工作階段中，執行 top 指令，查看是否有程序耗用 CPU。
  • 在終端機中，使用 df 指令查看可用的磁碟空間容量，或使用 free 指令查看可用的 RAM。
  • 從「User-managed notebooks page」(使用者管理的筆記本頁面) 選取執行個體，然後按一下「Stop」(停止)，即可關閉執行個體。完全停止後，選取該服務並點選「啟動」。

改用 Vertex AI Workbench 執行個體

本節說明如何診斷及解決從使用者管理型筆記本執行個體遷移至 Vertex AI Workbench 執行個體時發生的問題。

找不到使用者管理的 Notebooks 執行個體中的 R、Beam 或其他核心

問題

使用者自行管理的筆記本執行個體中的核心，不會顯示在您遷移到的 Vertex AI Workbench 執行個體中。

根據預設，Vertex AI Workbench 執行個體不支援部分核心 (例如 R 和 Beam 核心)。系統不支援遷移這些核心。

解決方案

如要解決這個問題，請在 Vertex AI Workbench 執行個體中新增 conda 環境。

無法在 Vertex AI Workbench 執行個體中設定 Dataproc Hub 執行個體

問題

Vertex AI Workbench 執行個體不支援 Dataproc Hub。

解決方案

繼續在使用者管理的筆記本執行個體中使用 Dataproc Hub。

遷移的執行個體中框架版本不同

問題

使用者自行管理的筆記本執行個體中的架構版本，與您遷移至的 Vertex AI Workbench 執行個體不同。

Vertex AI Workbench 執行個體提供預設的架構版本組合。遷移工具不會新增原始使用者管理筆記本執行個體的架構版本。請參閱預設遷移工具行為。

解決方案

如要新增特定版本的架構，請在 Vertex AI Workbench 執行個體中新增 conda 環境。

GPU 不會遷移至新的 Vertex AI Workbench 執行個體

問題

使用者自行管理的筆記本執行個體中的 GPU，不會出現在您遷移到的 Vertex AI Workbench 執行個體中。

Vertex AI Workbench 執行個體支援預設的 GPU 集。如果原始使用者管理的 Notebooks 執行個體中的 GPU 無法使用，系統會遷移執行個體，但不含任何 GPU。

解決方案

遷移後，您可以使用 Notebooks API 中的 projects.locations.instances.patch 方法，或 Google Cloud SDK 中的 gcloud workbench instances update 指令，將 GPU 新增至 Vertex AI Workbench 執行個體。

遷移的執行個體機器類型不同

問題

使用者自行管理的筆記本執行個體機器類型，與您遷移到的 Vertex AI Workbench 執行個體不同。

Vertex AI Workbench 執行個體不支援所有機器類型。 如果原始使用者管理的 Notebooks 執行個體中的機器類型無法使用，系統會將執行個體遷移至 e2-standard-4 機器類型。

解決方案

遷移完成後，您可以使用 Notebooks API 中的 projects.locations.instances.patch 方法，或 Google Cloud SDK 中的 gcloud workbench instances update 指令，變更 Vertex AI Workbench 執行個體的機型。

處理檔案

本節說明如何排解使用者管理筆記本執行個體檔案的問題。

檔案下載功能已停用，但使用者仍可下載檔案

問題

對於 Dataproc Hub 使用者管理的筆記本執行個體，系統不支援從 JupyterLab 使用者介面停用檔案下載功能。即使您在建立執行個體時未選取「啟用從 JupyterLab 使用者介面下載檔案的功能」，使用 Dataproc Hub 架構的使用者管理筆記本執行個體仍允許下載檔案。

解決方案

Dataproc Hub 使用者管理的筆記本執行個體不支援限制檔案下載。

下載的檔案遭到截斷或未完整下載

問題

從使用者管理的 Notebooks 執行個體下載檔案時，Proxy 轉送代理程式的逾時設定會限制下載完成的連線時間。如果下載時間過長，下載的檔案可能會遭到截斷或無法下載。

解決方案

如要下載檔案，請將檔案複製到 Cloud Storage，然後從 Cloud Storage 下載檔案。

建議您將檔案和資料遷移至新的使用者自行管理筆記本執行個體。

重新啟動 VM 後，無法從筆記本終端機參照本機檔案

問題

有時在重新啟動使用者管理的筆記本執行個體後，無法從筆記本終端機參照本機檔案。

解決方案

此為已知問題。如要從筆記本終端機參照本機檔案，請先使用下列指令重新建立目前的工作目錄：

cd PWD

在這項指令中，請將 PWD 替換為目前的工作目錄。舉例來說，如果目前的工作目錄是 /home/jupyter/，請使用 cd /home/jupyter/ 指令。

重新建立目前的工作目錄後，即可從筆記本終端機參照本機檔案。

建立由使用者管理的筆記本執行個體

本節說明如何排解建立由使用者管理的筆記本執行個體時發生的問題。

已超過 GPU 配額

問題

您無法使用 GPU 建立由使用者管理的筆記本執行個體。

解決方案

如要判斷專案可用的 GPU 數量，請查看配額頁面。 如果配額頁面未列出 GPU，或您需要額外的 GPU 配額，請要求增加配額。請參閱「要求提高配額限制」。

執行個體無限期處於待處理狀態

問題

建立由使用者管理的筆記本執行個體後，該執行個體會無限期處於待處理狀態。序列記錄中可能會出現類似下列的錯誤：

Could not resolve host: notebooks.googleapis.com

解決方案

由於 Cloud DNS 設定或其他網路問題，您的執行個體無法連線至 Notebooks API 伺服器。如要解決這個問題，請檢查 Cloud DNS 和網路設定。詳情請參閱網路設定選項一節。

未建立新的使用者管理筆記本執行個體 (權限不足)

問題

建立由使用者管理的筆記本執行個體通常需要大約一分鐘。如果新的使用者代管筆記本執行個體無限期地停留在 pending 狀態，可能是因為用來啟動使用者代管筆記本執行個體的服務帳戶，沒有 Google Cloud 專案中所需的權限。

如要啟動由使用者管理的筆記本執行個體，您可以使用您建立的自訂服務帳戶或以單一使用者模式使用使用者 ID。如果您以單一使用者模式啟動使用者代管的筆記本執行個體，使用者代管的筆記本執行個體則會先使用 Compute Engine 預設服務帳戶開始啟動程序，然後再將控制權轉交給您的使用者 ID。

解決方案

如要確認服務帳戶是否具有適當的權限，請按照下列步驟操作：

主控台

  1. 在 Google Cloud 控制台中開啟「IAM」頁面。

    開啟 IAM 頁面

  2. 確認用於使用者代管筆記本執行個體的服務帳戶為下列其中一項：

    • 您在建立使用者代管的筆記本執行個體時指定的自訂服務帳戶。

    • 您Google Cloud 專案的 Compute Engine 預設服務帳戶，這是以單一使用者模式啟動使用者管理的筆記本執行個體時使用的帳戶。您 Google Cloud 專案的 Compute Engine 預設服務帳戶名稱為PROJECT_NUMBER-compute@developer.gserviceaccount.com。例如：113377992299-compute@developer.gserviceaccount.com。

  3. 確認服務帳戶是否具備 Notebooks Runner (roles/notebooks.runner) 角色。如果沒有，請授予服務帳戶 Notebooks Runner (roles/notebooks.runner) 角色。

詳情請參閱 IAM 說明文件中的授予、變更及撤銷資源的存取權。

gcloud

  1. 如果尚未安裝，請先安裝 Google Cloud CLI。

  2. 透過下列指令取得 Google Cloud 專案的名稱和專案編號。 將 PROJECT_ID 替換為專案的專案 ID。Google Cloud 

    gcloud projects describe PROJECT_ID

    您應該會看到類似以下內容的輸出，其中顯示專案的名稱 (name:) 和專案編號 (projectNumber:)。

    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. 確認用於使用者代管筆記本執行個體的服務帳戶為下列其中一項：

    • 您在建立使用者代管的筆記本執行個體時指定的自訂服務帳戶。

    • 您Google Cloud 專案的 Compute Engine 預設服務帳戶，這是以單一使用者模式啟動使用者管理的筆記本執行個體時使用的帳戶。您 Google Cloud 專案的 Compute Engine 預設服務帳戶名稱為PROJECT_NUMBER-compute@developer.gserviceaccount.com。例如：113377992299-compute@developer.gserviceaccount.com。

  4. 使用下列指令將 roles/notebooks.runner 角色加入服務帳戶。請將「project-name」project-name替換為您的專案名稱，並將「service-account-id」service-account-id替換為使用者管理筆記本執行個體的服務帳戶 ID。

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

建立執行個體時發生 Permission denied 錯誤

問題

執行個體上的服務帳戶可提供其他服務的存取權。 Google Cloud 您可以使用同一專案中的任何服務帳戶，但必須具備服務帳戶使用者權限 (iam.serviceAccounts.actAs) 才能建立執行個體。如未指定，系統會使用 Compute Engine 預設服務帳戶。

解決方案

建立執行個體時，請確認建立執行個體的使用者具有定義服務帳戶的iam.serviceAccounts.ActAs權限。

以下範例說明如何建立執行個體時指定服務帳戶：

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

如要授予服務帳戶使用者角色，請參閱管理服務帳戶的存取權。

建立執行個體時發生 already exists 錯誤

問題

建立執行個體時，請確認 Compute Engine 先前未刪除同名的使用者管理筆記本執行個體，且該執行個體仍存在於 Notebooks API 資料庫中。

解決方案

以下範例說明如何使用 Notebooks API 列出執行個體，並驗證其狀態。

gcloud notebooks instances list --location=LOCATION

如果執行個體的狀態為 DELETED，請執行下列指令永久刪除執行個體。

gcloud notebooks instances delete INSTANCE_NAME --location=LOCATION

無法在共用虛擬私有雲中建立執行個體

問題

您無法在共用虛擬私有雲中建立執行個體。

解決方案

如果您使用共用 VPC，請務必將主專案和服務專案新增至服務範圍。在主專案中，您也必須將Compute 網路使用者角色 (roles/compute.networkUser) 授予服務專案的 Notebooks 服務代理程式。詳情請參閱「管理服務邊界」。

建立執行個體時發生資源可用性錯誤

問題

由於資源可用性錯誤，您無法建立執行個體。

這個錯誤可能如下所示：

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

如果您在某個區域要求新資源，但該區域目前無法提供 Compute Engine 資源 (例如 GPU 或 CPU)，因此無法滿足您的要求，就會發生資源錯誤。

資源錯誤只會影響區域中的新資源要求，不會影響現有資源。資源錯誤與 Compute Engine 配額無關。資源錯誤是暫時性的，並且可能會根據波動的需求而頻繁變更。

解決方案

如要繼續，請嘗試下列做法：

  • 建立使用不同機器類型的執行個體。
  • 在其他可用區建立執行個體。
  • 請稍後再試。
  • 減少要求的資源數量。舉例來說，您可以嘗試建立 GPU、磁碟、vCPU 或記憶體較少的執行個體。

啟動執行個體時發生資源可用性錯誤

問題

由於資源可用性錯誤，您無法啟動執行個體。

這個錯誤可能如下所示：

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

如果您嘗試在無法滿足要求的可用區中啟動執行個體，就會發生資源錯誤，因為目前無法使用 Compute Engine 資源 (例如 GPU 或 CPU)。

資源錯誤只適用於您在傳送要求時指定的要求資源，不適用於可用區中的所有資源。資源錯誤與 Compute Engine 配額無關。資源錯誤是暫時性的，並且可能會根據波動的需求而頻繁變更。

解決方案

如要繼續，請嘗試下列做法：

  • 變更執行個體的機器類型。
  • 將檔案和資料遷移至其他區域的執行個體。
  • 請稍後再試。
  • 減少要求的資源數量。舉例來說，啟動的執行個體可以減少 GPU、磁碟、vCPU 或記憶體。

升級使用者管理的筆記本執行個體

本節說明如何排解升級使用者管理筆記本執行個體時的問題。

無法取得執行個體磁碟資訊，因此無法升級

問題

單一磁碟的使用者自行管理的筆記本執行個體不支援升級。

解決方案

您可能需要將使用者資料遷移至新的使用者自行管理筆記本執行個體。

無法升級，因為執行個體不相容於 UEFI

問題

Vertex AI Workbench 必須相容於 UEFI，才能完成升級。

從某些舊版映像檔建立的由使用者管理的筆記本執行個體不相容於 UEFI，因此無法升級。

解決方案

如要確認執行個體是否與 UEFI 相容，請在 Cloud Shell 或任何已安裝 Google Cloud CLI 的環境中，輸入下列指令。

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

更改下列內容：

  • INSTANCE_NAME：執行個體名稱
  • ZONE：執行個體所在的區域

如要確認用於建立執行個體的映像檔是否與 UEFI 相容，請使用下列指令：

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

將 VM_IMAGE_FAMILY 替換為您用來建立執行個體的映像檔系列名稱。

如果判斷執行個體或映像檔與 UEFI 不相容，可以嘗試將使用者資料遷移至新的使用者管理筆記本執行個體。若要這樣做，請完成下列步驟：

  1. 確認要用來建立新執行個體的映像檔與 UEFI 相容。如要這麼做，請在 Cloud Shell 或任何已安裝 Google Cloud CLI 的環境中，輸入下列指令。

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

    將 VM_IMAGE_FAMILY 替換為您要用來建立執行個體的映像檔系列名稱。

  2. 將使用者資料遷移至新的使用者管理筆記本執行個體。

升級後無法存取使用者自行管理的筆記本執行個體

問題

如果升級後無法存取使用者管理的 Notebooks 執行個體，可能是因為開機磁碟映像檔更換失敗。

可升級的使用者自行管理的筆記本執行個體為雙磁碟，包含一個開機磁碟和一個資料磁碟。升級程序會將開機磁碟升級至新映像檔，同時保留資料磁碟上的資料。

解決方案

請按照下列步驟，將新的有效映像檔附加至開機磁碟。

  1. 如要儲存完成這項程序時使用的值，請在 Cloud Shell 或任何已安裝 Google Cloud CLI 的環境中，輸入下列指令。

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

    更改下列內容：

    • MY_INSTANCE_NAME：執行個體名稱
    • MY_PROJECT_ID：您的專案 ID
    • MY_ZONE：執行個體所在的區域

  2. 使用下列指令停止執行個體：

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

  3. 從執行個體卸離資料磁碟。

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

  4. 刪除執行個體的 VM。

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

  5. 使用 Notebooks API 刪除使用者管理的筆記本執行個體。

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

  6. 使用與先前執行個體相同的名稱，建立由使用者管理的筆記本執行個體。

    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

    更改下列內容：

    • MY_VM_IMAGE_FAMILY：圖片系列名稱
    • MY_INSTANCE_OWNER：執行個體擁有者
    • MY_MACHINE_TYPE：執行個體 VM 的機器類型
    • MY_SERVICE_ACCOUNT：要用於這個例項的服務帳戶，或使用 "default"
    • MY_ACCELERATOR_TYPE：加速器類型，例如 "NVIDIA_TESLA_T4"
    • ：核心數量； 例如 1MY_ACCELERATOR_CORE_COUNT

監控使用者自行管理的筆記本執行個體健康狀態

本節說明如何排解監控健康狀態錯誤的問題。

docker-proxy-agent 狀態失敗

如果 docker-proxy-agent 狀態失敗，請按照下列步驟操作：

  1. 確認反向 Proxy 代理程式是否正在運作。 如果代理程式未運作，請前往步驟 3。

  2. 重新啟動反向 Proxy 代理程式。

  3. 透過反向 Proxy 伺服器重新註冊。

docker-service 狀態失敗

如果 docker-service 狀態失敗，請按照下列步驟操作：

  1. 確認 Docker 服務是否正在運作。

  2. 重新啟動 Docker 服務。

jupyter-service 狀態失敗

如果 jupyter-service 狀態失敗，請按照下列步驟操作：

  1. 確認 Jupyter 服務是否正在運作。

  2. 重新啟動 Jupyter 服務。

jupyter-api 狀態失敗

如果 jupyter-api 狀態失敗，請按照下列步驟操作：

  1. 確認 Jupyter 內部 API 是否已啟動。

  2. 重新啟動 Jupyter 服務。

開機磁碟使用率百分比

如果磁碟空間使用率高於 85%，即代表開機磁碟空間健康狀態不良。

如果開機磁碟空間健康狀態不良，請嘗試下列做法：

  1. 在使用者管理的筆記本執行個體中，透過終端機工作階段或使用 ssh 連線，使用 df -H 指令檢查可用的磁碟空間容量。

  2. 使用 find . -type d -size +100M 指令找出可能可以刪除的大型檔案，但請務必確認刪除這些檔案不會造成問題，再進行刪除。如果不確定，可以向支援團隊尋求協助。

  3. 如果上述步驟無法解決問題，請取得支援。

資料磁碟使用率百分比

如果磁碟空間使用率高於 85%，即代表資料磁碟空間健康狀態不良。

如果資料磁碟空間健康狀態不良，請嘗試下列做法：

  1. 在使用者管理的筆記本執行個體中，透過終端機工作階段或使用 ssh 連線，使用 df -h -T /home/jupyter 指令檢查可用的磁碟空間容量。

  2. 刪除大型檔案來增加可用的磁碟空間。 使用 find . -type d -size +100M 指令尋找大型檔案。

  3. 如果上述步驟無法解決問題，請取得支援。

無法安裝第三方 JupyterLab 擴充功能

問題

嘗試安裝第三方 JupyterLab 擴充功能時，會出現 Error: 500 訊息。

解決方案

使用者管理的筆記本執行個體不支援第三方 JupyterLab 擴充功能。

還原執行個體

問題

刪除使用者管理的筆記本執行個體後，系統不支援還原。

解決方案

如要備份執行個體上的資料，可以將筆記本儲存至 GitHub，或建立磁碟快照。

從執行個體復原資料

問題

刪除使用者管理的 Notebooks 執行個體後，系統不支援復原資料。

解決方案

如要備份執行個體上的資料，可以將筆記本儲存至 GitHub，或建立磁碟快照

無法增加共用記憶體

問題

您無法增加現有使用者自行管理的筆記本執行個體的共用記憶體。

解決方案

不過，您可以在建立使用者管理的 Notebooks 執行個體時，使用 container-custom-params 中繼資料鍵指定共用記憶體大小，值如下所示：

--shm-size=SHARED_MEMORY_SIZE gb

將 SHARED_MEMORY_SIZE 替換為所需大小 (以 GB 為單位)。

實用程序

本節說明可能對您有幫助的程序。

使用 SSH 連線至使用者管理的 Notebook 執行個體

在 Cloud Shell 或任何已安裝 Google Cloud CLI 的環境中，輸入下列指令，使用 SSH 連線至執行個體。

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

更改下列內容：

  • PROJECT_ID：您的專案 ID
  • ZONE：執行個體所在的 Google Cloud 區域
  • INSTANCE_NAME：執行個體名稱

您也可以開啟執行個體的 Compute Engine 詳細資料頁面，然後點選「SSH」SSH按鈕，連線至執行個體。

透過反向 Proxy 伺服器重新註冊

如要向內部反向 Proxy 伺服器重新註冊使用者管理的筆記本執行個體，請從使用者管理的筆記本頁面停止並啟動 VM，或是使用 SSH 連線至使用者管理的筆記本執行個體，然後輸入：

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

確認 Docker 服務狀態

如要確認 Docker 服務狀態，請使用 SSH 連線至使用者管理的 Notebook 執行個體，然後輸入：

sudo service docker status

確認反向 Proxy 代理程式是否正在運作

如要確認 Notebook 反向 Proxy 代理程式是否正在執行，請使用 SSH 連線至使用者管理的 Notebooks 執行個體，然後輸入：

# 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

確認 Jupyter 服務狀態並收集記錄

如要驗證 Jupyter 服務狀態，請使用 SSH 連線至使用者管理的筆記本執行個體，然後輸入：

sudo service jupyter status

如要收集 Jupyter 服務記錄，請按照下列步驟操作：

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

確認 Jupyter 內部 API 是否已啟動

Jupyter API 一律應在通訊埠 8080 上執行。如要確認這點，請檢查執行個體的系統記錄，是否有類似下列的項目：

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

如要確認 Jupyter 內部 API 是否已啟動，您也可以使用 SSH 連線至使用者管理的筆記本執行個體，然後輸入：

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

如果要求時間過長，您也可以測量 API 回應所需的時間：

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

如要在 Vertex AI Workbench 執行個體中執行這些指令，請開啟 JupyterLab 並建立新的終端機。

重新啟動 Docker 服務

如要重新啟動 Docker 服務，請從「User-managed notebooks」(使用者管理的筆記本) 頁面停止並啟動 VM，或是使用 SSH 連線至使用者管理的筆記本執行個體，然後輸入以下內容：

sudo service docker restart

重新啟動反向 Proxy 代理程式

如要重新啟動反向 Proxy 代理程式，請從「User-managed notebooks」(使用者管理的筆記本) 頁面停止並啟動 VM，或是使用 SSH 連線至使用者管理的筆記本執行個體，然後輸入：

sudo docker restart proxy-agent

重新啟動 Jupyter 服務

如要重新啟動 Jupyter 服務，請從「使用者管理的筆記本」頁面停止並啟動 VM，或是使用 SSH 連線至使用者管理的筆記本執行個體，然後輸入以下內容：

sudo service jupyter restart

重新啟動 Notebooks Collection Agent

Notebooks Collection Agent 服務會在背景執行 Python 程序，驗證 Vertex AI Workbench 執行個體核心服務的狀態。

如要重新啟動 Notebooks Collection Agent 服務，請從Google Cloud 控制台停止並啟動 VM，或是使用 SSH 連線至 Vertex AI Workbench 執行個體，然後輸入：

sudo systemctl stop notebooks-collection-agent.service

然後：

sudo systemctl start notebooks-collection-agent.service

如要在 Vertex AI Workbench 執行個體中執行這些指令，請開啟 JupyterLab 並建立新的終端機。

修改 Notebooks Collection Agent 指令碼

如要存取及編輯指令碼，請在執行個體中開啟終端機，或使用 SSH 連線至 Vertex AI Workbench 執行個體，然後輸入：

nano /opt/deeplearning/bin/notebooks_collection_agent.py

編輯完畢後，請記得儲存檔案。

然後，您必須重新啟動 Notebooks Collection Agent 服務。

確認執行個體可以解析必要的 DNS 網域

如要確認執行個體可以解析必要的 DNS 網域，請使用 SSH 連線至由使用者管理的 Notebooks 執行個體，然後輸入：

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

或：

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

如果執行個體已啟用 Dataproc，您可以執行下列指令，確認執行個體是否解析 *.kernels.googleusercontent.com：

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

如要在 Vertex AI Workbench 執行個體中執行這些指令，請開啟 JupyterLab 並建立新的終端機。

複製執行個體上的使用者資料

如要在 Cloud Storage 中儲存執行個體使用者資料的副本，請完成下列步驟。

建立 Cloud Storage bucket (選用)

在執行個體所在的專案中，建立 Cloud Storage bucket，用來儲存使用者資料。如果已有 Cloud Storage bucket，請略過這個步驟。

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

    複製使用者資料

    1. 在執行個體的 JupyterLab 介面中，依序選取「File」(檔案)>「New」(新增)>「Terminal」(終端機)，開啟終端機視窗。 如果是使用者管理的 Notebooks 執行個體，則可以使用 SSH 連線至執行個體的終端機。

    2. 使用 gcloud CLI 將使用者資料複製到 Cloud Storage bucket。下列範例指令會將執行個體 /home/jupyter/ 目錄中的所有檔案，複製到 Cloud Storage 值區的目錄。

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

      更改下列內容：

      • BUCKET_NAME：Cloud Storage 值區的名稱
      • PATH：要複製檔案的目錄路徑，例如：/copy/jupyter/

    使用 gcpdiag 檢查卡在佈建程序的執行個體

    gcpdiag 是開放原始碼工具。這並非正式支援的 Google Cloud 產品。您可以使用 gcpdiag 工具找出並修正 Google Cloud專案問題。詳情請參閱 GitHub 上的 gcpdiag 專案。

    這份 gcpdiag 執行手冊會調查 Vertex AI Workbench 執行個體停滯在佈建狀態的可能原因，包括下列領域：
    • 狀態：檢查執行個體的目前狀態，確保執行個體停滯在佈建程序中，而非已停止或處於有效狀態。
    • 執行個體的 Compute Engine VM 開機磁碟映像檔： 檢查執行個體是否使用自訂容器、官方 workbench-instances 映像檔、深度學習 VM 映像檔，或可能導致執行個體停滯在佈建狀態的不支援映像檔建立。
    • 自訂指令碼：檢查執行個體是否使用自訂啟動或啟動後指令碼，變更預設的 Jupyter 連接埠，或中斷可能導致執行個體停滯在佈建狀態的依附元件。
    • 環境版本：檢查執行個體是否使用最新環境版本，方法是檢查是否可升級。舊版可能會導致執行個體停滯在佈建狀態。
    • 執行個體的 Compute Engine VM 效能： 檢查 VM 目前的效能，確保不會因 CPU 使用率過高、記憶體不足或磁碟空間問題而受到影響，導致正常運作中斷。
    • 執行個體的 Compute Engine 序列埠或系統記錄：檢查執行個體是否有序列埠記錄，並分析這些記錄，確保 Jupyter 在連接埠 127.0.0.1:8080 上執行。
    • 執行個體的 Compute Engine SSH 和終端機存取權：檢查執行個體的 Compute Engine VM 是否正在執行，讓使用者可以透過 SSH 開啟終端機，確認「home/jupyter」中的空間使用量低於 85%。如果沒有剩餘空間，執行個體可能會停滯在佈建狀態。
    • 外部 IP 已關閉：檢查外部 IP 存取權是否已關閉。網路設定有誤可能會導致執行個體停留在佈建狀態。

    Google Cloud 控制台

    1. 完成下列指令，然後複製。
      2. gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE
    2. 開啟 Google Cloud 控制台並啟用 Cloud Shell。
      3. 開啟 Cloud 控制台
    3. 貼上複製的指令。
    4. 執行 gcpdiag 指令，下載 gcpdiag Docker 映像檔，然後執行診斷檢查。如適用，請按照輸出內容中的操作說明修正失敗的檢查。

    Docker

    您可以使用在 Docker 容器中啟動 gcpdiag 的 wrapper 執行 gcpdiag。必須安裝 Docker 或 Podman。

    1. 複製下列指令，並在本機工作站上執行。 
      curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
    2. 執行 gcpdiag 指令。 
      ./gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE

    查看這本 Runbook 的可用參數。

    更改下列內容：

    • PROJECT_ID：包含資源的專案 ID。
    • INSTANCE_NAME：專案中目標 Vertex AI Workbench 執行個體的名稱。
    • ZONE：目標 Vertex AI Workbench 執行個體所在的區域。

    實用標記：

    如需所有 gcpdiag 工具旗標的清單和說明，請參閱 gcpdiag 使用說明。

    使用服務帳戶角色搭配 Vertex AI 時發生權限錯誤

    問題

    使用 Vertex AI 時，如果服務帳戶角色發生一般權限錯誤，

    這些錯誤可能會出現在 Cloud Logging 的產品元件記錄或稽核記錄中。也可能出現在受影響專案的任何組合中。

    這些問題可能是由下列一或多項原因所致：

    • 使用 Service Account Token Creator 角色，但應該使用 Service Account User 角色，反之亦然。這些角色會授予服務帳戶不同的權限，且無法互換。如要瞭解 Service Account Token Creator 和 Service Account User 角色之間的差異，請參閱服務帳戶角色。

    • 您已授予服務帳戶跨多個專案的權限，但這項操作預設不允許。

    解決方案

    如要解決這個問題，請嘗試下列一或多項操作：

    • 判斷是否需要 Service Account Token Creator 或 Service Account User 角色。如要瞭解詳情，請參閱您使用的 Vertex AI 服務的 IAM 說明文件，以及您使用的任何其他產品整合。

    • 如果您已跨多個專案授予服務帳戶權限，請確保iam.disableCrossProjectServiceAccountUsage，啟用跨專案附加服務帳戶。目前不會強制執行。如要確保系統不會強制執行 iam.disableCrossProjectServiceAccountUsage，請執行下列指令：

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