クラスタ作成に関する問題のトラブルシューティング

gcpdiag ツールを使用する

gcpdiag はオープンソース ツールです。正式にサポートされている Google Cloud プロダクトではありません。gcpdiag ツールを使用すると、 Google Cloudプロジェクトの問題を特定して修正できます。詳細については、GitHub の gcpdiag プロジェクトをご覧ください。

gcpdiag ツールは、次のチェックを実行して、次の Dataproc クラスタ作成の問題を検出します。

  • 在庫切れエラー: ログ エクスプローラのログを評価して、リージョンとゾーンの在庫切れを確認します。
  • 不十分な割り当て: Dataproc クラスタ プロジェクトの割り当てが使用可能かどうかを確認します。
  • ネットワーク構成が不完全: 必要なファイアウォール ルールのチェック、外部 IP と内部 IP の構成など、ネットワーク接続テストを実行します。クラスタが削除された場合、gcpdiag ツールはネットワーク接続チェックを実行できません。
  • プロジェクト間の構成が正しくない: プロジェクト間のサービス アカウントを確認し、追加のロールと組織のポリシーの適用を確認します。
  • 共有 Virtual Private Cloud ネットワーク IAM ロールがない: Dataproc クラスタが共有 VPC ネットワークを使用する場合は、必要なサービス アカウント ロールが追加されていることを確認します。
  • 初期化アクションの失敗: ログ エクスプローラのログを評価して、初期化アクション スクリプトの失敗とタイムアウトを検出します。

gcpdiag クラスタの作成手順のリストについては、想定される対策手順をご覧ください。

gcpdiag コマンドを実行する

gcpdiag コマンドは、Cloud Shell のGoogle Cloud コンソールまたは Docker コンテナ内で実行できます。

Google Cloud コンソール

  1. 次のコマンドを入力してコピーします。
    2. gcpdiag runbook dataproc/cluster-creation \
    --parameter project_id=PROJECT_ID \
    --parameter cluster_name=CLUSTER_NAME \
    --parameter OPTIONAL_FLAGS
  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 dataproc/cluster-creation \
    --parameter project_id=PROJECT_ID \
    --parameter cluster_name=CLUSTER_NAME \
    --parameter OPTIONAL_FLAGS

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

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

    • PROJECT_ID: リソースを含むプロジェクトの ID。
    • CLUSTER_NAME: プロジェクト内のターゲット Dataproc クラスタの名前
    • OPTIONAL_PARAMETERS: 次のオプション パラメータを 1 つ以上追加します。これらのパラメータは、クラスタが削除された場合に必要です。
      • cluster_uuid: プロジェクト内のターゲット Dataproc クラスタの UUID
      • service_account: Dataproc クラスタの VM サービス アカウント
      • subnetwork: Dataproc クラスタ サブネットワークの完全な URI パス
      • internal_ip_only: True または False
      • cross_project: Dataproc クラスタが別のプロジェクトの VM サービス アカウントを使用する場合のクロスプロジェクト ID

有用なフラグ:

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

クラスタ作成のエラーの把握と修正

このセクションでは、Dataproc のエラー メッセージとその一般的な原因、解決策を記載します。

  • オペレーション タイムアウト: 最低 2 つ必要な実行中のデータノード / ノード マネージャーが 0 個です

    原因: コントローラ ノードが、ワーカーノードと通信できないためクラスタを作成できない。

    解決方法:

    • ファイアウォール ルールの警告を確認します。
    • 正しいファイアウォール ルールが設定されていることを確認します。詳細については、デフォルトの Dataproc ファイアウォール ルールの概要をご覧ください。
    • Google Cloud コンソールで接続テストを実行して、コントローラ ノードとワーカーノード間の通信をブロックしているものを特定します。

  • projects/{projectId}/regions/{region}/subnetworks/{subnetwork} に必要な compute.subnetworks.use 権限

    原因: このエラーは、別のプロジェクトの VPC ネットワークを使用して Dataproc クラスタを設定する際、ネットワークをホストする共有 VPC プロジェクトの Dataproc サービス エージェント サービス アカウントに必要な権限がない場合に発生します。

    解決策: 別のプロジェクトで VPC ネットワークを使用するクラスタを作成するの手順に沿って行います。

  • ゾーン projects/zones/{zone} には、リクエスト (resource type:compute) に対応できる十分なリソースがない

    原因: クラスタの作成に使用されているゾーンに十分なリソースがない。

    解決方法:

  • 割り当て超過エラー

    CPUS/CPUS_ALL_REGIONS の割り当てが不足しています
    「DISKS_TOTAL_GB」の割り当てが不足しています
    「IN_USE_ADDRESSES」の割り当てが不足しています

    原因: CPU、ディスク、または IP アドレスのリクエストが利用可能な割り当てを超えています。

    解決策: Google Cloud コンソールから追加の割り当てをリクエストします。

  • 初期化アクションに失敗しました

    原因: インストールがクラスタの作成時に指定された初期化アクションで失敗しました。

    解決方法:

  • ノード CLUSTER-NAME-m を初期化できませんでした。出力は <gs://PATH_TO_STARTUP_SCRIPT_OUTPUT> で確認できます。

    原因: Dataproc クラスタ コントローラ ノードの初期化に失敗しました。

    解決方法:

  • クラスタの作成に失敗しました: IP アドレス空間が不足しています

    原因: リクエストされたクラスタノードをプロビジョニングするために必要な IP アドレス空間を使用できません。

    解決方法:

    • 別のサブネットワークまたはネットワークにクラスタを作成します。
    • ネットワークの使用量を減らして IP アドレス空間を解放します。
    • ネットワークで十分な IP 空間が使用可能になるまで待ちます。

  • 初期化スクリプトのエラー メッセージ: リポジトリ REPO_NAME にリリース ファイルがない

    原因: Debian の旧安定版のバックポート リポジトリが完全に削除された。

    解決方法:

    初期化スクリプトで、apt-get を実行するコードの前に次のコードを追加します。

    oldstable=$(curl -s https://deb.debian.org/debian/dists/oldstable/Release | awk '/^Codename/ {print $2}');
stable=$(curl -s https://deb.debian.org/debian/dists/stable/Release | awk '/^Codename/ {print $2}');

matched_files="$(grep -rsil '\-backports' /etc/apt/sources.list*)"
if [[ -n "$matched_files" ]]; then
  for filename in "$matched_files"; do
    grep -e "$oldstable-backports" -e "$stable-backports" "$filename" || \
      sed -i -e 's/^.*-backports.*$//' "$filename"
  done
fi

  • インスタンス DATAPROC_CLUSTER_VM_NAME のレポートを待機中にタイムアウトしました。またはネットワークに到達できません。dataproccontrol-REGION.googleapis.com

    原因: これらのエラー メッセージは、Dataproc クラスタのネットワーク設定が完了していないことを示しています。デフォルトのインターネット ゲートウェイへのルートまたはファイアウォール ルールがない可能性があります。

    解決方法:

    この問題をトラブルシューティングするには、次の接続テストを作成します。

    • 2 つの Dataproc クラスタ VM 間の接続テストを作成します。このテストの結果は、ネットワークの上り（内向き）または下り（外向き）許可ファイアウォール ルールがクラスタ VM に正しく適用されているかどうかを判断する際に役立ちます。
    • Dataproc クラスタ VM と現在の Dataproc コントロール API IP アドレスの間に接続テストを作成します。現在の Dataproc コントロール API の IP アドレスを取得するには、次のコマンドを使用します。
    dig dataproccontrol-REGION.googleapis.com A

    出力の回答セクションにある IPv4 アドレスのいずれかを使用します。

    接続テストの結果は、デフォルトのインターネット ゲートウェイへのルートと下り（外向き）許可ファイアウォールが正しく構成されているかどうかを把握する際に役立ちます。

    接続テストの結果に基づいて、次のことを行います。

  • 更新によるエラー

    原因: クラスタは Dataproc サービスに送信されたジョブを受け入れましたが、手動または自動スケーリングでスケールアップまたはスケールダウンできませんでした。このエラーは、標準以外のクラスタ構成が原因で発生することもあります。

    解決方法:

    • クラスタのリセット: サポート チケットを開き、診断用 tar ファイルを添付して、クラスタを RUNNING 状態にリセットするよう依頼します。

    • 新しいクラスタ: 同じ構成でクラスタを再作成します。この方法は、サポート提供のリセットよりも迅速に行えます。

クラスタのトラブルシューティングのヒント

このセクションでは、Dataproc クラスタの作成を妨げる可能性のある一般的な問題のトラブルシューティングに関する追加のガイダンスを提供します。

Dataproc クラスタのプロビジョニングが失敗すると、多くの場合、一般的なエラー メッセージが生成されるか、失敗する前に PENDING または PROVISIONING ステータスが報告されます。クラスタ障害の問題を診断して解決するには、クラスタログを調べて、一般的な障害点を評価することが重要です。

一般的な症状とエラー メッセージ

クラスタの作成エラーに関連する一般的な症状とエラー メッセージは次のとおりです。

  • クラスタのステータスが PENDING または PROVISIONING のまま、長時間経過している。
  • クラスタが ERROR 状態に遷移する。
  • クラスタの作成中に発生する一般的な API エラー（Operation timed out など）。

  • ログに記録されたエラー メッセージまたは API レスポンスのエラー メッセージ（次のようなもの）:

    • RESOURCE_EXHAUSTED: CPU、ディスク、IP アドレスの割り当てに関連する
    • Instance failed to start
    • Permission denied
    • Unable to connect to service_name.googleapis.com または Could not reach required Google APIs
    • Connection refused または network unreachable
    • スクリプト実行エラーやファイルが見つからないなど、初期化アクションの失敗に関連するエラー。

クラスタログを確認する

クラスタ作成の失敗を診断する際の重要な最初の手順は、Cloud Logging で使用可能な詳細なクラスタログを確認することです。

  1. ログ エクスプローラに移動します。 Google Cloud コンソールでログ エクスプローラを開きます。
  2. Dataproc クラスタをフィルタします。
    • [リソース] プルダウンで、[Cloud Dataproc Cluster] を選択します。
    • cluster_name と project_id を入力します。location（リージョン）でフィルタすることもできます。
  3. ログエントリを確認します:
    • クラスタ作成の失敗に近い時間に発生した ERROR または WARNING レベルのメッセージを探します。
    • VM レベルまたは Dataproc エージェントの問題に関する分析情報を得るには、master-startup、worker-startup、agent コンポーネントのログに注意してください。
    • VM の起動時間に関する問題を把握するには、resource.type="gce_instance" でログをフィルタし、クラスタノードに関連付けられたインスタンス名（CLUSTER_NAME-m や CLUSTER_NAME-w-0 など）からのメッセージを探します。シリアル コンソール ログにより、VM ライフサイクルの早い段階で発生するネットワーク構成の問題、ディスクの問題、スクリプトの失敗を確認できます。

クラスタ障害の一般的な原因とトラブルシューティングのヒント

このセクションでは、Dataproc クラスタの作成が失敗する一般的な理由と、クラスタの障害のトラブルシューティングに役立つトラブルシューティングのヒントについて説明します。

十分な IAM 権限がない

Dataproc クラスタが使用する VM サービス アカウントには、Compute Engine インスタンスのプロビジョニング、Cloud Storage バケットへのアクセス、ログの書き込み、他の Google Cloud サービスとのやり取りを行うための適切な IAM ロールが必要です。

  • 必要なワーカーロール: VM サービス アカウントに Dataproc ワーカーロール（roles/dataproc.worker）があることを確認します。このロールには、Dataproc がクラスタ リソースを管理するために必要な最小限の権限が付与されています。
  • データアクセス権限: ジョブが Cloud Storage または BigQuery から読み取りまたは書き込みを行う場合、サービス アカウントには、Cloud Storage の Storage Object Viewer、Storage Object Creator、Storage Object Admin、BigQuery の BigQuery Data Viewer、BigQuery Editor などの関連するロールが必要です。
  • ロギング権限: サービス アカウントには、Cloud Logging にログを書き込むために必要な権限（Logging Writer ロールなど）を持つロールが必要です。

トラブルシューティングのヒント:

  • サービス アカウントを特定します。クラスタが使用するように構成されている VM サービス アカウントを特定します。指定されていない場合、デフォルトは Compute Engine のデフォルト サービス アカウントです。

  • IAM ロールを確認します。 Google Cloud コンソールの [IAM と管理] > [IAM] ページに移動し、クラスタ VM サービス アカウントを見つけて、クラスタ オペレーションに必要なロールがあることを確認します。不足しているロールを付与します。

リソース割り当ての超過

Dataproc クラスタは、Compute Engine やその他の Google Cloud サービスからリソースを消費します。プロジェクトまたはリージョンの割り当てを超えると、クラスタの作成が失敗する可能性があります。

  • 確認する一般的な Dataproc の割り当て:
    • CPUs（リージョン）
    • DISKS_TOTAL_GB（リージョン）
    • IN_USE_ADDRESSES（内部 IP の場合はリージョン、外部 IP の場合はグローバル）
    • Dataproc API の割り当て（ClusterOperationRequestsPerMinutePerProjectPerRegion など）。

トラブルシューティングのヒント:

  • 割り当てを確認します。 Google Cloud コンソールの [IAM と管理] > [IAM] ページに移動します。[サービス] で [Compute Engine API] と [Dataproc API] をフィルタします。
  • 使用量と上限を確認します。上限に達しているか、上限に近い割り当てを特定します。
  • 必要に応じて、割り当ての増加をリクエストします。

ネットワーク構成に関する問題

クラスタの作成が失敗する一般的な原因は、VPC ネットワーク、サブネット、ファイアウォール、DNS の構成が正しくないなどのネットワーク構成の問題です。クラスタ インスタンスは、相互に通信し、Google API と通信できる必要があります。

  • VPC ネットワークとサブネット:
    • クラスタの VPC ネットワークとサブネットが存在し、正しく構成されていることを確認します。
    • サブネットに十分な範囲の IP アドレスが使用可能であることを確認します。
  • プライベート Google アクセス（PGA）: クラスタ VM に内部 IP アドレスがあり、Cloud Storage、Cloud Logging、その他のオペレーションで Google API にアクセスする必要がある場合は、サブネットでプライベート Google アクセスが有効になっていることを確認します。デフォルトでは、2.2 以降のイメージ バージョンで作成された Dataproc クラスタは、クラスタのリージョン サブネットでプライベート Google アクセスが有効になっている、内部専用 IP アドレスを持つ VM をプロビジョニングします。
  • Private Service Connect（PSC）: Private Service Connect を使用して Google API にアクセスする場合は、Dataproc が依存する Google API（dataproc.googleapis.com、storage.googleapis.com、compute.googleapis.com、logging.googleapis.com など）に必要な Private Service Connect エンドポイントが正しく構成されていることを確認します。API の DNS エントリは、プライベート IP アドレスに解決される必要があります。Private Service Connect を使用しても、他のユーザー管理の VPC ネットワークと通信するために VPC ピアリングを使用する必要がなくなるわけではありません。
  • VPC ピアリング: クラスタが他の VPC ネットワーク（共有 VPC ホスト プロジェクトや他のユーザーの VPC など）のリソースと通信する場合は、VPC ピアリングが正しく構成され、ルートが伝播されていることを確認します。

  • ファイアウォール ルール:

    • デフォルト ルール: allow-internal や allow-ssh などのデフォルトのファイアウォール ルールが過度に制限されていないことを確認します。

    • カスタムルール: カスタム ファイアウォール ルールが設定されている場合は、必要な通信パスが許可されていることを確認します。

      • クラスタ内の内部通信（-m ノードと -w ノード間）。

      • クラスタ VM から Google API へのアウトバウンド トラフィック。パブリック IP、インターネット ゲートウェイ、プライベート Google アクセス、または Private Service Connect エンドポイントのいずれかを使用します。

      • ジョブが依存する外部データソースまたはサービスへのトラフィック。

  • DNS 解決: クラスタ インスタンスが Google API と内部サービスまたは外部サービスの DNS 名を正しく解決できることを確認します。

トラブルシューティングのヒント:

  • ネットワーク構成を確認します。クラスタがデプロイされる VPC ネットワークとサブネットの設定を調べます。
  • ファイアウォール ルールを確認します。VPC ネットワークまたは共有 VPC ホスト プロジェクトのファイアウォール ルールを確認します。
  • 接続をテストします。クラスタ サブネットに一時的な Compute Engine VM を起動し、次の操作を行います。
    • ping または curl を storage.googleapis.com などの外部 Google API ドメインに転送します。
    • nslookup を使用して、想定される IP アドレス（プライベート Google アクセスまたは Private Service Connect）への DNS 解決を確認します。
    • Google Cloud 接続テストを実行して、テスト VM から関連するエンドポイントまでのパスを診断します。

初期化アクションの失敗

Dataproc 初期化アクションは、クラスタの作成中にクラスタ VM で実行されるスクリプトです。これらのスクリプトのエラーにより、クラスタの起動が妨げられる可能性があります。

トラブルシューティングのヒント:

  • 初期化アクションのエラーのログを確認します。Cloud Logging で、クラスタ インスタンスの init-actions または startup-script に関連するログエントリを探します。
  • スクリプトのパスと権限を確認します。初期化アクション スクリプトが Cloud Storage に正しく配置されていることと、クラスタ VM サービス アカウントに Cloud Storage スクリプトの読み取りに必要な Storage Object Viewer ロールがあることを確認します。
  • スクリプト ロジックをデバッグします。クラスタ環境を模倣した別の Compute Engine VM でテスト スクリプトのロジックをテストして、エラーを特定します。スクリプトに詳細ロギングを追加します。

リージョン リソースの可用性（リソース不足）

リージョンまたはゾーンのマシンタイプまたはリソースが一時的に利用できなくなる（リソース不足になる）ことがあります。この場合は通常、プロジェクトの割り当ての問題とは関係のない RESOURCE_EXHAUSTED エラーが発生します。

トラブルシューティングのヒント:

  • 別のゾーンまたはリージョンを試します。同じリージョン内の別のゾーン、または別のリージョンにクラスタを作成してみます。
  • 自動ゾーン プレースメントを使用します。Dataproc の自動ゾーン プレースメント機能を使用して、容量のあるゾーンを自動的に選択します。
  • マシンタイプを調整します。カスタム マシンタイプまたは特殊なマシンタイプを使用している場合は、標準マシンタイプを試して、問題が解決するかどうかを確認します。

次のステップ

クラスタ障害の問題が引き続き発生する場合は、次の操作を行います。

  • Cloud カスタマーケアに問い合わせる。クラスタ障害の問題と、実施したトラブルシューティングの手順を説明します。以下の情報も併せてご提供ください。
    • クラスタ診断データ
    • 次のコマンドの出力:
      gcloud dataproc clusters describe CLUSTER_NAME \
    -region=REGION
    • 失敗したクラスタからエクスポートしたログ。