Vertex AI Workbench のトラブルシューティング

このページでは、Vertex AI Workbench の使用中に問題が発生した場合に役立つトラブルシューティング手順について説明します。

Vertex AI のその他のコンポーネントの使用方法については、Vertex AI のトラブルシューティングをご覧ください。

このページのコンテンツをフィルタするには、トピックをクリックします。

Vertex AI Workbench インスタンス

このセクションでは、Vertex AI Workbench インスタンスのトラブルシューティング手順について説明します。

JupyterLab への接続と起動

このセクションでは、JupyterLab に接続して開く際のトラブルシューティング手順について説明します。

[JupyterLab を開く] をクリックした後、何も行われない

問題

[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 Login を使用して SSH アクセスを有効にします。インスタンスを作成すると、Vertex AI Workbench はメタデータキー enable-oslogin を TRUE に設定し、デフォルトで OS Login を有効にします。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

インスタンスがプロビジョニングのステータスから先に進まない場合は、インスタンスのプライベート ネットワーク構成が無効な可能性があります。

ソリューション

インスタンスのログに接続エラーまたはタイムアウト エラーが表示されるのセクションの手順に沿って操作します。

共有 VPC ネットワーク内にインスタンスを作成できない

問題

共有 VPC ネットワーク内にインスタンスを作成しようとすると、次のようなエラー メッセージが表示されます。

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

ソリューション

この問題は、Notebooks サービス アカウントが適切な権限なしでインスタンスを作成しようとしているために発生しています。

共有 VPC ネットワーク内に Vertex AI Workbench インスタンスを作成するために必要な権限を Notebooks サービス アカウントに付与するには、ホスト プロジェクトに対する Compute ネットワーク ユーザー（roles/compute.networkUser）IAM ロールを Notebooks サービス アカウントに付与するよう管理者に依頼してください。

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

この事前定義ロールには、Notebooks サービス アカウントで共有 VPC ネットワーク内に Vertex AI Workbench インスタンスを作成するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

Notebooks サービス アカウントが共有 VPC ネットワーク内に 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 インスタンスにカスタム コンテナを追加できますが、この機能はサポートされていません。

[Mount shared storage] ボタンが表示されない

問題

JupyterLab インターフェースの [File Browser] タブに [Mount shared storage] ボタンが表示されません。

ソリューション

Vertex AI Workbench インスタンスの JupyterLab インターフェースに [Mount shared storage] ボタンを表示するには、storage.buckets.list 権限が必要です。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 メッセージが表示されます。

ソリューション

サードパーティの JupyterLab 拡張機能は、Vertex AI Workbench インスタンスではサポートされていません。

基盤となる仮想マシンを編集できない

問題

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 をオフにしてプライベート VPC ネットワークを使用している場合は、ネットワーク構成オプションのドキュメントも参照してください。次の点を考慮してください。

インスタンスのログに [Unable to contact 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 など）に変更することで、呼び出しの応答に時間がかかりすぎたためにリクエストが失敗したのか、それともリクエストされた URL に到達できなかったのかを確認することもできます。

docker0 アドレスが VPC アドレスと競合する

問題

デフォルトでは、docker0 インターフェースは 172.17.0.1/16 の IP アドレスで作成されます。これにより、VPC ネットワーク内の IP アドレスと競合し、インスタンスが 172.17.0.1/16 アドレスを持つ他のエンドポイントに接続できなくなる可能性があります。

ソリューション

次の起動後スクリプトを使用して、起動後スクリプトの動作を run_once に設定すると、強制的に、VPC ネットワークと競合しない IP アドレスで docker0 インターフェースを作成できます。

   #!/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 への接続と起動に関する問題のトラブルシューティングについて説明します。

[JupyterLab を開く] をクリックした後、何も行われない

問題

[JupyterLab を開く] をクリックしても、何も行われません。

ソリューション

ブラウザで新しいタブの自動表示がブロックされている場合は、その設定を解除します。JupyterLab が新しいブラウザタブで開きます。

SSH を使用してマネージド ノートブック インスタンスに接続できない

問題

SSH を使用してマネージド ノートブック インスタンスに接続できません。

ソリューション

マネージド ノートブック インスタンスには SSH 経由でアクセスできません。

マネージド ノートブック インスタンスでターミナルにアクセスできない

問題

ターミナルにアクセスできない場合、またはランチャーでターミナル ウィンドウが見つからない場合は、マネージド ノートブック インスタンスでターミナル アクセスが有効になっていない可能性があります。

ソリューション

ターミナル アクセス オプションを有効にして、新しいマネージド ノートブック インスタンスを作成する必要があります。このオプションをインスタンスの作成後に変更することはできません。

JupyterLab を開いたときに 502 エラーが発生する

問題

502 エラーが発生した場合、マネージド ノートブック インスタンスの準備ができていない可能性があります。

ソリューション

数分待ってから Google Cloud コンソールのブラウザタブを更新して、もう一度お試しください。

ノートブックを開くと 524（A Timeout Occurred）エラーが発生する

問題

524 エラーは通常、Inverting Proxy エージェントが Inverting Proxy サーバーに接続していないか、バックエンド サーバー側（Jupyter）でリクエストの処理に時間がかかりすぎていることを示しています。このエラーの一般的な原因としては、ネットワークの問題、Inverting 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 インスタンスには、デフォルトのフレームワーク バージョン セットが用意されています。移行ツールは、元のマネージド ノートブック インスタンスのフレームワーク バージョンを追加しません。移行ツールのデフォルトの動作をご覧ください。

ソリューション

特定のバージョンのフレームワークを追加するには、Vertex AI Workbench インスタンスに conda 環境を追加します。

新しい Vertex AI Workbench インスタンスに GPU が移行されない

問題

マネージド ノートブック インスタンスに含まれていた GPU が移行先の Vertex AI Workbench インスタンスに存在しません。

Vertex AI Workbench インスタンスは、デフォルトの GPU セットをサポートしています。移行元のマネージド ノートブック インスタンスの GPU が使用できない場合、インスタンスは GPU なしで移行されます。

ソリューション

移行後に Notebooks API の projects.locations.instances.patch メソッドまたは Google Cloud SDK の gcloud workbench instances update コマンドを使用して、Vertex AI Workbench インスタンスに GPU を追加できます。

移行されたインスタンスのマシンタイプが異なる

問題

マネージド ノートブック インスタンスのマシンタイプが、移行先の 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 拡張機能があることを確認するには、Deep Learning Containers イメージから派生コンテナ イメージを作成します。Deep Learning Containers イメージには 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 に保存します。

マネージド ノートブック インスタンスの作成

このセクションでは、マネージド ノートブック インスタンスの作成に関する問題のトラブルシューティングについて説明します。

エラー: 接続の作成中にエラーが発生しました

問題

このエラーがインスタンスの作成時に発生した場合:

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.

リソースエラーは、GPU や CPU などの Compute Engine リソースが現在利用できないことが原因でリクエストに対応できないゾーンで、新しいリソースをリクエストした場合に発生します。

リソースエラーは、ゾーン内の新しいリソース リクエストにのみ適用され、既存のリソースには影響しません。リソースエラーは、Compute Engine の割り当てとは関係ありません。リソースエラーは一時的なもので、変動する需要に応じて頻繁に変わる可能性があります。

ソリューション

続行するには、次のことをお試しください。

  • 別のマシンタイプでインスタンスを作成します。
  • 別のゾーンにインスタンスを作成します。
  • しばらくしてからもう一度リクエストを送信します。
  • リクエストするリソースの量を減らします。たとえば、GPU、ディスク、vCPU、メモリが少ないインスタンスを作成してみます。

インスタンスを起動すると、リソースの可用性エラーが発生する

問題

リソースの可用性エラーのためインスタンスを起動できません。

次のようなエラー メッセージが表示されます。

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

リソースエラーは、GPU や CPU などの Compute Engine リソースが現在利用できないことが原因でリクエストに対応できないゾーンで、インスタンスを起動しようとした場合に発生します。

リソースエラーは、ゾーン内のすべてのリソースではなく、リクエスト送信時に指定したリソースにのみ関係します。リソースエラーは、Compute Engine の割り当てとは関係ありません。リソースエラーは一時的なもので、変動する需要に応じて頻繁に変わる可能性があります。

ソリューション

続行するには、次のことをお試しください。

  • インスタンスのマシンタイプを変更します。
  • ファイルとデータを別のゾーンのインスタンスに移行します。
  • しばらくしてからもう一度リクエストを送信します。
  • リクエストするリソースの量を減らします。たとえば、GPU、ディスク、vCPU、メモリが少ない別のインスタンスを起動します。

マネージド ノートブックからのアウトバウンド接続で No route to host

問題

通常、 Google Cloud コンソールで表示できるルートは、独自の VPC で認識されているルートと、VPC ネットワーク ピアリングの構成完了時に予約した範囲のみです。

マネージド ノートブック インスタンスは Google が管理するネットワークに存在し、インスタンス内の Docker ネットワーク名前空間で修正版の Jupyter を実行します。

このインスタンスの Docker ネットワーク インターフェースと Linux ブリッジは、VPC によってピアリングを介してエクスポートされる IP 範囲と競合するローカル IP を選択する場合があります。これらは通常、それぞれ 172.16.0.0/161 と 192.168.10.0/24 の範囲にあります。

このような状況では、インスタンスからこれらの範囲へのアウトバウンド接続が失敗し、VPC ルートが正しく共有されているにもかかわらず、No route to host のようなエラーが報告されます。

ソリューション

ターミナル セッションで ifconfig を呼び出し、インスタンス内の仮想インターフェースの IP アドレスが、VPC によりピアリング接続にエクスポートされる IP 範囲と競合していないことを確認します。

ユーザー管理のノートブック

このセクションでは、ユーザー管理のノートブックのトラブルシューティング手順について説明します。

JupyterLab への接続と起動

このセクションでは、JupyterLab への接続と起動に関する問題のトラブルシューティングについて説明します。

[JupyterLab を開く] をクリックした後、何も行われない

問題

[JupyterLab を開く] をクリックしても、何も行われません。

ソリューション

ブラウザで新しいタブの自動表示がブロックされている場合は、その設定を解除します。JupyterLab が新しいブラウザタブで開きます。

Inverting Proxy サーバーを介して JupyterLab にアクセスできない

問題

JupyterLab にアクセスできません。

Vertex AI Workbench は、Google の内部 Inverting Proxy サーバーを使用して JupyterLab へのアクセスを実現します。ユーザー管理ノートブック インスタンスの設定、ネットワーク構成などの要因により、JupyterLab へのアクセスが妨げられる場合があります。

ソリューション

SSH 経由で JupyterLab に接続し、Inverting Proxy を介してアクセスできない理由を確認してください。

SSH 経由でユーザー管理ノートブック インスタンスに接続できない

問題

ターミナル ウィンドウから SSH 経由でインスタンスに接続できません。

ユーザー管理ノートブック インスタンスは、OS Login を使用して SSH アクセスを有効にします。インスタンスを作成すると、Vertex AI Workbench はメタデータキー enable-oslogin を TRUE に設定し、デフォルトで OS Login を有効にします。SSH 経由でインスタンスに接続できない場合は、このメタデータキーを TRUE に設定する必要があります。

ソリューション

ユーザーのユーザー管理ノートブックに対する SSH アクセスを有効にするには、ユーザー アカウントで OS Login ロールを構成する手順を完了します。

ユーザー管理ノートブック インスタンスを開くと 403（Forbidden）エラーが発生する

問題

ユーザー管理ノートブック インスタンスを開いたときに 403 (Forbidden) エラーが発生するのは、多くの場合、アクセスに問題があることを意味します。

ソリューション

アクセスの問題をトラブルシューティングするには、次の 3 つの方法でユーザー管理ノートブック インスタンスにアクセス権を付与することを検討してください。

  • シングル ユーザー
  • サービス アカウント
  • プロジェクト編集者

アクセスモードは、ユーザー管理ノートブック インスタンスの作成時に構成され、ノートブック メタデータで定義されます。

  • シングル ユーザー: proxy-mode=mail, proxy-user-mail=user@domain.com
  • サービス アカウント: proxy-mode=service_account
  • プロジェクト編集者: proxy-mode=project_editors

[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

ノートブックを開くために [JupyterLab を開く] をクリックすると、新しいブラウザタブでノートブックが開きます。複数の Google アカウントにログインしている場合、新しいタブはデフォルトの Google アカウントの下で開きます。デフォルトの Google アカウントを使用してユーザー管理ノートブック インスタンスを作成していない場合は、新しいブラウザタブに 403 (Forbidden) エラーが表示されます。

JupyterLab へのアクセス権がなく、シングル ユーザーモードが有効になっている

問題

JupyterLab にアクセスできません。

ソリューション

ユーザーが JupyterLab にアクセスできず、インスタンスの JupyterLab へのアクセスが Single user only に設定されている場合は、次のことを試してください。

  1. Google Cloud コンソールの [ユーザー管理のノートブック] ページで、インスタンスの名前をクリックして [ノートブックの詳細] ページを開きます。

  2. [VM の詳細を表示] の横にある [Compute Engine で表示] をクリックします。

  3. [VM インスタンスの詳細] ページで、[編集] をクリックします。

  4. [メタデータ] セクションで、proxy-mode メタデータ エントリが mail に設定されていることを確認します。

  5. proxy-user-mail メタデータ エントリがサービス アカウントではなく、有効なユーザーのメールアドレスに設定されていることを確認します。

  6. [保存] をクリックします。

  7. Google Cloud コンソールの [ユーザー管理のノートブック] ページで、インスタンスを停止してインスタンスを再起動し、更新されたメタデータを初期化します。

ノートブックを開くと 504（Gateway Timeout）エラーが発生する

問題

内部プロキシのタイムアウトまたはバックエンド サーバー（Jupyter）のタイムアウトを示します。これは、次のような場合に表示されます。

  • リクエストが内部 Inverting Proxy サーバーに到達しなかった。
  • バックエンド（Jupyter）が 504 エラーを返した。

ソリューション

Google サポートケースを開きます。

ノートブックを開くと 524（A Timeout Occurred）エラーが発生する

問題

内部 Inverting Proxy サーバーが、タイムアウト期間内にリクエストに対する Inverting Proxy エージェントからのレスポンスを受信していません。Inverting Proxy エージェントは、ユーザー管理ノートブック インスタンス内で Docker コンテナとして実行されます。524 エラーは通常、Inverting Proxy エージェントが Inverting Proxy サーバーに接続していないか、バックエンド サーバー側（Jupyter）でリクエストの処理に時間がかかりすぎていることを示しています。通常、このエラーはユーザー側で発生します（例: ネットワークの問題、Inverting Proxy エージェント サービスが実行されていない）。

ソリューション

ノートブックにアクセスできない場合は、ユーザー管理ノートブック インスタンスが起動していることを確認して、次のことを試してください。

オプション 1: 診断ツールを実行して、ユーザー管理のノートブックのコアサービスを自動的に確認し、修復します。使用可能なストレージを確認し、有用なログファイルを生成します。インスタンスでツールを実行するには、次の操作を行います。

  1. インスタンスがバージョン M58 以降であることを確認します。

  2. SSH を使用して Deep Learning VM Image インスタンスに接続します。

  3. 次のコマンドを実行します。

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

    --repair フラグと --bucket フラグは省略可能です。--repair フラグを指定すると、一般的なコアサービスのエラーが修正されます。--bucket フラグを使用すると、作成されたログファイルを保存する Cloud Storage バケットを指定できます。

    このコマンドの出力には、ユーザー管理ノートブック コアサービスの有用なステータス メッセージと、その検出結果のログファイルがエクスポートされます。

オプション 2: 次の手順でユーザー管理ノートブックの要件を個別に確認します。

ノートブックを開くと 598（Network read timeout）エラーが発生する

問題

Inverting Proxy サーバーが Inverting Proxy エージェントから 10 分以上応答をまったく受けていません。Inverting Proxy エージェントの問題が強く疑われます。

ソリューション

ノートブックにアクセスできない場合は、次のことを試してください。

ノートブックが応答しない

問題

ユーザー管理ノートブック インスタンスがセルを実行していないか、フリーズしているように見えます。

ソリューション

トップメニューから [Kernel] をクリックし、[Restart Kernel] をクリックして、カーネルを再起動してみてください。それでも解決しない場合は、次のことを試してください。

  • ブラウザの JupyterLab ページを更新します。保存されていないセルの出力は破棄されます。出力を再生成するには、これらのセルを再度実行する必要があります。
  • ノートブックのターミナル セッションから top コマンドを実行して、CPU を消費しているプロセスがあるかどうかを確認します。
  • ターミナルで、df コマンドを実行してディスクの空き容量を確認するか、free コマンドを実行して使用可能な RAM を確認します。
  • インスタンスをシャットダウンします。ユーザー管理ノートブックのページでインスタンスを選択して [停止] をクリックします。完全に停止したら、インスタンスを選択して [開始] をクリックします。

Vertex AI Workbench インスタンスへの移行

このセクションでは、ユーザー管理ノートブック インスタンスから Vertex AI Workbench インスタンスへの移行に関する問題を診断して解決する方法について説明します。

ユーザー管理ノートブック インスタンスにあった R、Beam、その他のカーネルが見つからない

問題

ユーザー管理ノートブック インスタンスにあるカーネルが移行先の Vertex AI Workbench インスタンスに表示されません。

デフォルトでは、R カーネルや Beam カーネルなどの一部のカーネルは Vertex AI Workbench インスタンスで使用できません。これらのカーネルの移行はサポートされていません。

ソリューション

この問題を解決するには、Vertex AI Workbench インスタンスに conda 環境を追加します。

Vertex AI Workbench インスタンスで Dataproc Hub インスタンスを設定できない

問題

Dataproc Hub は、Vertex AI Workbench インスタンスでサポートされていません。

ソリューション

ユーザー管理ノートブック インスタンスで Dataproc Hub を引き続き使用してください。

移行されたインスタンスのフレームワークのバージョンが異なる

問題

ユーザー管理ノートブック インスタンスのフレームワークのバージョンが、移行先の Vertex AI Workbench インスタンスのフレームワークと異なります。

Vertex AI Workbench インスタンスには、デフォルトのフレームワーク バージョン セットが用意されています。移行ツールは、元のユーザー管理ノートブック インスタンスのフレームワーク バージョンを追加しません。移行ツールのデフォルトの動作をご覧ください。

ソリューション

特定のバージョンのフレームワークを追加するには、Vertex AI Workbench インスタンスに conda 環境を追加します。

新しい Vertex AI Workbench インスタンスに GPU が移行されない

問題

ユーザー管理ノートブック インスタンスに含まれていた GPU が移行先の Vertex AI Workbench インスタンスに存在しません。

Vertex AI Workbench インスタンスは、デフォルトの GPU セットをサポートしています。移行元のユーザー管理ノートブック インスタンスの GPU が使用できない場合、インスタンスは GPU なしで移行されます。

ソリューション

移行後に Notebooks API の projects.locations.instances.patch メソッドまたは Google Cloud SDK の gcloud workbench instances update コマンドを使用して、Vertex AI Workbench インスタンスに GPU を追加できます。

移行されたインスタンスのマシンタイプが異なる

問題

ユーザー管理ノートブック インスタンスのマシンタイプが、移行先の 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 インスタンスのマシンタイプを変更できます。

ファイル操作

このセクションでは、ユーザー管理ノートブック インスタンスのファイルの問題のトラブルシューティングについて説明します。

ファイルのダウンロードが無効になっていてもファイルをダウンロードできる

問題

Dataproc Hub ユーザー管理ノートブック インスタンスでは、JupyterLab ユーザー インターフェースからのファイルのダウンロードを無効にすることはできません。Dataproc Hub フレームワークを使用するユーザー管理ノートブック インスタンスでは、インスタンスの作成時に [JupyterLab UI からのファイルのダウンロードを有効にする] を選択していなくても、ファイルのダウンロードが許可されます。

ソリューション

Dataproc Hub ユーザー管理ノートブック インスタンスでは、ファイルのダウンロード制限がサポートされません。

ダウンロードしたファイルが切り捨てられるか、ダウンロードが完了しない

問題

ユーザー管理ノートブック インスタンスからファイルをダウンロードする場合、プロキシ転送エージェントのタイムアウト設定により、ダウンロードが完了するまでの接続時間が制限されます。ダウンロードに時間がかかりすぎる場合は、ダウンロードしたファイルが切り捨てられるか、ダウンロードされない可能性があります。

ソリューション

ファイルをダウンロードするには、ファイルを 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 とネットワークの構成を確認します。詳細については、ネットワーク構成オプションのセクションをご覧ください。

新しいユーザー管理ノートブック インスタンスを作成できない（権限が不十分）

問題

通常、ユーザー管理ノートブック インスタンスを作成するのに 1 分ほどかかります。新しいユーザー管理ノートブック インスタンスが pending 状態のままになる原因としては、ユーザー管理ノートブック インスタンスの起動に使用されたサービス アカウントに、 Google Cloud プロジェクトで必要な権限が付与されていないことが考えられます。

ユーザー管理ノートブック インスタンスは、作成したカスタム サービス アカウントを使用して起動することも、ユーザー ID を使用してシングル ユーザーモードで起動することもできます。ユーザー管理ノートブック インスタンスは、シングルユーザー モードで起動した場合、ユーザー ID に制御を切り替える前に、Compute Engine のデフォルトのサービス アカウントを使用して起動プロセスを開始します。

ソリューション

サービス アカウントに適切な権限があることを確認するには、次の操作を行います。

コンソール

  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. サービス アカウントにノートブック実行者（roles/notebooks.runner）ロールが付与されていることを確認します。付与されていない場合は、サービス アカウントにノートブック実行者（roles/notebooks.runner）ロールを付与します。

詳細については、IAM ドキュメントのリソースへのアクセス権の付与、変更、取り消しをご覧ください。

gcloud

  1. まだインストールしていない場合は、Google Cloud CLI をインストールします。

  2. 次のコマンドを使用して、 Google Cloud プロジェクトの名前とプロジェクト番号を取得します。PROJECT_ID は、Google Cloud プロジェクトのプロジェクト ID に置き換えます。

    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 はプロジェクトの名前に、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 にインスタンスを作成できない

問題

共有 VPC にインスタンスを作成できません。

ソリューション

共有 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.

リソースエラーは、GPU や CPU などの Compute Engine リソースが現在利用できないことが原因でリクエストに対応できないゾーンで、新しいリソースをリクエストした場合に発生します。

リソースエラーは、ゾーン内の新しいリソース リクエストにのみ適用され、既存のリソースには影響しません。リソースエラーは、Compute Engine の割り当てとは関係ありません。リソースエラーは一時的なもので、変動する需要に応じて頻繁に変わる可能性があります。

ソリューション

続行するには、次の手順をお試しください。

  • 別のマシンタイプでインスタンスを作成します。
  • 別のゾーンにインスタンスを作成します。
  • しばらくしてからもう一度リクエストを送信します。
  • リクエストするリソースの量を減らします。たとえば、GPU、ディスク、vCPU、メモリが少ないインスタンスを作成してみます。

インスタンスを起動すると、リソースの可用性エラーが発生する

問題

リソースの可用性エラーのためインスタンスを起動できません。

次のようなエラー メッセージが表示されます。

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

リソースエラーは、GPU や CPU などの Compute Engine リソースが現在利用できないことが原因でリクエストに対応できないゾーンで、インスタンスを起動しようとした場合に発生します。

リソースエラーは、ゾーン内のすべてのリソースではなく、リクエスト送信時に指定したリソースにのみ関係します。リソースエラーは、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. 新しいユーザー管理ノートブック インスタンスにユーザーデータを移行します。

アップグレード後にユーザー管理ノートブック インスタンスにアクセスできない

問題

アップグレード後にユーザー管理ノートブック インスタンスにアクセスできない場合、ブートディスクのイメージの置換中にエラーが発生している可能性があります。

アップグレード可能なユーザー管理のノートブック インスタンスは、ブートディスクとデータディスクを 1 つずつ含むデュアル ディスクです。アップグレード プロセスでは、データディスク上のデータを保持しながら、ブートディスクが新しいイメージにアップグレードされます。

ソリューション

新しい有効なイメージをブートディスクにアタッチするには、次の操作を行います。

  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"）
    • MY_ACCELERATOR_CORE_COUNT: コア数（例: 1）

ユーザー管理ノートブック インスタンスのヘルス ステータスのモニタリング

このセクションでは、ヘルス ステータス エラーのモニタリングに関する問題のトラブルシューティングについて説明します。

docker-proxy-agent のステータスが失敗

docker-proxy-agent のステータスが失敗の場合は、次の操作を行います。

  1. Inverting Proxy エージェントが実行されていることを確認します。実行中でない場合は、手順 3 に進みます。

  2. Inverting Proxy エージェントを再起動します。

  3. Inverting 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 に保存するか、ディスクのスナップショットを作成します。

インスタンスからのデータの復元

問題

削除されたユーザー管理ノートブック インスタンスからデータを復元することはできません。

ソリューション

インスタンスのデータをバックアップするには、ノートブックを GitHub に保存するか、ディスクのスナップショットを作成します。

共有メモリを増やすことはできない

問題

既存のユーザー管理ノートブック インスタンスで共有メモリを増やすことはできません。

ソリューション

ただし、ユーザー管理ノートブック インスタンスを作成するときに、次のような値を持つ container-custom-params メタデータキーを使用して、共有メモリサイズを指定できます。

--shm-size=SHARED_MEMORY_SIZE gb

SHARED_MEMORY_SIZE は、必要なサイズ（GB）に置き換えます。

役に立つ手順

このセクションでは、役に立ちそうな手順について説明します。

SSH を使用してユーザー管理ノートブック インスタンスに接続する

SSH を使用してインスタンスに接続するには、Cloud Shell または Google Cloud CLI がインストールされている環境で次のコマンドを入力します。

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] ボタンをクリックしてインスタンスに接続することもできます。

Inverting Proxy サーバーに再登録する

ユーザー管理ノートブック インスタンスを内部 Inverting Proxy サーバーに再登録するには、ユーザー管理ノートブックのページから VM を停止して起動します。あるいは、SSH を使用してユーザー管理ノートブック インスタンスに接続して、次のように入力します。

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

Docker サービスのステータスを確認する

Docker サービスのステータスを確認するには、SSH でユーザー管理のノートブック インスタンスに接続して、次のように入力します。

sudo service docker status

Inverting Proxy エージェントが実行されていることを確認する

ノートブックの Inverting Proxy エージェントが実行されているかどうかを確認するには、SSH でユーザー管理のノートブック インスタンスに接続して、次のように入力します。

# 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 で実行する必要があります。これを確認するには、インスタンスの syslog で次のようなエントリを調べます。

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 サービスを再起動するには、ユーザー管理のノートブックのページから VM を停止して起動します。あるいは、SSH でユーザー管理ノートブック インスタンスに接続して、次のように入力します。

sudo service docker restart

Inverting Proxy エージェントを再起動する

Inverting Proxy エージェントを再起動するには、ユーザー管理のノートブックのページから VM を停止して起動します。あるいは、SSH でユーザー管理ノートブック インスタンスに接続して、次のように入力します。

sudo docker restart proxy-agent

Jupyter サービスを再起動する

Jupyter サービスを再起動するには、ユーザー管理のノートブックのページから VM を停止して起動します。あるいは、SSH でユーザー管理ノートブック インスタンスに接続して、次のように入力します。

sudo service jupyter restart

Notebooks Collection Agent を再起動する

Notebooks Collection Agent サービスは、Vertex AI Workbench インスタンスのコアサービスのステータスを確認する Python プロセスをバックグラウンドで実行します。

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 を使用してユーザー管理ノートブック インスタンスに接続して、次のように入力します。

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 バケットを作成する（省略可）

インスタンスが配置されているプロジェクトと同じプロジェクトに、ユーザーデータを保存する Cloud Storage バケットを作成します。すでに Cloud Storage バケットがある場合は、この手順をスキップします。

  • 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] を選択して、ターミナル ウィンドウを開きます。ユーザー管理ノートブック インスタンスの場合は、代わりに SSH を使用してインスタンスのターミナルに接続できます。

    2. gcloud CLI を使用して、Cloud Storage バケットにユーザーデータをコピーします。次のコマンドの例では、インスタンスの /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 イメージ、Deep Learning 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 アクセスがオフになっているかどうかを確認します。ネットワーク構成が正しくないと、インスタンスがプロビジョニング ステータスから進まなくなる可能性があります。

    Docker

    Docker コンテナで gcpdiag を起動するラッパーを使用して 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

    このランブックで使用可能なパラメータを表示します。

    次のように置き換えます。

    • PROJECT_ID: リソースを含むプロジェクトの ID。
    • INSTANCE_NAME: プロジェクト内のターゲット Vertex AI Workbench インスタンスの名前。
    • ZONE: ターゲット Vertex AI Workbench インスタンスが配置されているゾーン。

    有用なフラグ:

    gcpdiag ツールのフラグの一覧と説明については、gcpdiag の使用手順をご覧ください。

    Vertex AI でサービス アカウントのロールを使用する際の権限エラー

    問題

    Vertex AI でサービス アカウント ロールを使用すると、一般的な権限エラーが発生します。

    これらのエラーは、Cloud Logging のプロダクト コンポーネント ログまたは監査ログに表示されることがあります。影響を受けるプロジェクトの任意の組み合わせで表示されることもあります。

    これらの問題は、次のいずれかまたは両方が原因で発生する可能性があります。

    • Service Account User ロールを使用すべきときに Service Account Token Creator ロールを使用した場合、またはその逆の場合。これらのロールはサービス アカウントに異なる権限を付与するため、相互に置き換えることはできません。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