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 割り当てが必要な場合には、割り当て量の増加をリクエストしてください。割り当て上限の引き上げをリクエストするをご覧ください。

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 に到達できないためにリクエストが失敗したかどうかを確認することもできます。

マネージド ノートブック

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

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. ご使用のサービス アカウントに Notebooks Runner（roles/notebooks.runner）ロールが付与されていることを確認します。付与されていない場合は、そのサービス アカウントに 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 Image、サポートされていないイメージで作成されたかどうか確認します。これらは、インスタンスがプロビジョニングのステータスのままになる原因になり得ます。
  • カスタム スクリプト: インスタンスで、デフォルトの 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. GOOGLE_AUTH_TOKEN=GOOGLE_AUTH_TOKEN \
  gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE \
    --auto --reason=REASON
  2. Google Cloud コンソールを開き、Cloud Shell をアクティブにします。
    3. Cloud コンソールを開く
  3. コピーしたコマンドを貼り付けます。
  4. gcpdiag コマンドを実行します。gcpdiag Docker イメージがダウンロードされ、診断チェックが実行されます。必要に応じて、出力の指示に沿って、失敗したチェックを修正します。

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 の使用手順をご覧ください。