トラブルシューティング

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このページでは、一般的な問題やエラーのトラブルシューティングの手順について説明します。

FAILED インスタンス

ステータスが FAILED の場合、インスタンス データが失われ、インスタンスを削除する必要があることを意味します。

FAILED 状態の Parallelstore インスタンスは、削除されるまで課金され続けます。

インスタンスの状態を取得するには、インスタンスの管理: インスタンスを取得するの手順に沿って操作します。

インスタンスを削除するには、インスタンスの管理: インスタンスを削除するをご覧ください。

dfuse マウント時またはネットワーク テスト時のタイムアウト

Parallelstore インスタンスをマウントするときに dfuse -m コマンドがタイムアウトする場合、または self_test や daos health net-test などのネットワーク テスト コマンドがタイムアウトする場合は、ネットワーク接続の問題が原因である可能性があります。

Parallelstore サーバーへの接続を確認するには、次のコマンドを実行します。

self_test --use-daos-agent-env -r 1

テストで接続に関する問題が報告された場合、次の 2 つの理由が考えられます。

DAOS エージェントがセットアップ中に間違ったネットワーク インターフェースを選択した可能性があります。

access_points リスト内の IP に到達できないネットワーク インターフェースを除外することが必要になる場合があります。

1. ifconfig を実行して、使用可能なネットワーク インターフェースを一覧表示します。出力例には、eth0、docker0、ens8、lo などの複数のネットワーク インターフェースが表示される場合があります。

2. daos_agent を停止します。

3. /etc/daos/daos_agent.yml を編集して、不要なネットワーク インターフェースを除外します。exclude_fabric_ifaces 行のコメント化を解除して値を更新します。入力するエントリは状況に応じて異なります。次に例を示します。

   exclude_fabric_ifaces: ["docker0", "ens8", "lo"]
   

4. daos_agent を再起動します。

インスタンスまたはクライアントの IP アドレスが内部 IP アドレスと競合している

Parallelstore インスタンスとクライアントは、172.17.0.0/16 サブネット範囲の IP アドレスを使用できません。詳しくは、既知の問題をご覧ください。

ENOSPC インスタンスに未使用の容量がある場合

インスタンスで最小またはバランスストライプ（デフォルト）を使用している場合、既存のファイルがインスタンスの容量をすべて使用していない場合でも、ENOSPC エラーが発生することがあります。これは、通常 8 GiB を超える大きなファイルを書き込む場合や、そのようなファイルを Cloud Storage からインポートする場合に発生する可能性があります。

最大ファイル ストリッピングを使用すると、このようなエラーの発生を抑えることができます。

Google Kubernetes Engine のトラブルシューティング

次のセクションでは、一般的な問題とその解決手順について説明します。

ワークロード Pod の Transport endpoint is not connected

このエラーは、dfuse の終了が原因で発生します。ほとんどの場合、メモリ不足が原因で dfuse が終了しました。Pod アノテーション gke-parallelstore/[cpu-limit|memory-limit] を使用して、Parallelstore サイドカー コンテナにさらにリソースを割り当てます。サイドカーに割り当てるメモリ量がわからない場合は、gke-parallelstore/memory-limit: "0" を設定してサイドカーのメモリ制限を削除できます。これは Standard クラスタでのみ機能します。Autopilot クラスタでは、値 0 を使用してサイドカー コンテナのリソース上限とリクエストの設定を解除することはできません。サイドカー コンテナに大きなリソース上限を明示的に設定する必要があります。

アノテーションを変更したら、ワークロード Pod を再起動する必要があります。実行中のワークロードにアノテーションを追加しても、リソース割り当てが動的に変更されることはありません。

Pod イベントの警告

ワークロード Pod が起動できない場合は、Pod イベントを確認します。

kubectl describe pod POD_NAME -n NAMESPACE

次の解決策は、一般的なエラーを対象としています。

CSI ドライバの有効化に関する問題

一般的な CSI ドライバの有効化エラーは次のとおりです。

MountVolume.MountDevice failed for volume "volume" : kubernetes.io/csi:
attacher.MountDevice failed to create newCsiDriverClient:
driver name parallelstore.csi.storage.gke.io not found in the list of registered CSI drivers

MountVolume.SetUp failed for volume "volume" : kubernetes.io/csi:
mounter.SetUpAt failed to get CSI client:
driver name parallelstore.csi.storage.gke.io not found in the list of registered CSI drivers

これらの警告は、CSI ドライバが有効になっていないか、実行されていないことを示します。

クラスタのスケーリング、更新、アップグレードを行ったばかりの場合は、この警告は正常であり、一時的なものです。クラスタ オペレーション後に CSI ドライバ Pod が機能するまでには数分かかることがあります。

それ以外の場合は、クラスタで CSI ドライバが有効になっていることを確認します。詳細については、CSI ドライバを有効にするをご覧ください。CSI が有効になっている場合、各ノードに parallelstore-csi-node-id という名前の Pod が実行中として表示されます。

AttachVolume.Attach の失敗

Pod がノードにスケジュールされると、ボリュームはノードに接続され、ノードマウントを使用している場合はマウント Pod が作成されます。

これはコントローラで行われ、attachdetach-controller の AttachVolume ステップが関与します。

MountVolume.MountDevice の失敗

ボリュームがノードにアタッチされると、ボリュームはノードにステージングされます。

これはノードで行われ、kubelet の MountVolume.MountDevice ステップが関与します。

MountVolume.SetUp の失敗

ボリュームがノードにステージングされると、ボリュームはマウントされ、Pod 上のコンテナに提供されます。これはノードで行われ、kubelet の MountVolume.SetUp ステップが関与します。

VPC ネットワークのトラブルシューティング

サービス servicenetworking.googleapis.com のピアリングの追加が拒否されました

ERROR: (gcloud.services.vpc-peerings.connect) User [$(USER)] does not have 
permission to access services instance [servicenetworking.googleapis.com]
(or it may not exist): Permission denied to add peering for service
'servicenetworking.googleapis.com'.

このエラーは、ユーザー アカウントに servicenetworking.services.addPeering IAM 権限がないことを意味します。

次のいずれかのロールをアカウントに追加する手順については、IAM を使用したアクセス制御をご覧ください。

• roles/compute.networkAdmin または
• roles/servicenetworking.networksAdmin

CreateConnection で割り振り範囲を変更できない

ERROR: (gcloud.services.vpc-peerings.connect) The operation
"operations/[operation_id]" resulted in a failure "Cannot modify allocated
ranges in CreateConnection. Please use UpdateConnection.

このエラーは、このネットワークに異なる IP 範囲の VPC ピアリングがすでに作成されている場合に返されます。考えられる解決法は次の 2 つです。

既存の IP 範囲を置き換えます。

gcloud services vpc-peerings update \
  --network=NETWORK_NAME \
  --ranges=IP_RANGE_NAME \
  --service=servicenetworking.googleapis.com \
  --force

または、新しい IP 範囲を既存の接続に追加します。

1. ピアリングの既存の IP 範囲のリストを取得します。

   EXISTING_RANGES=$(
     gcloud services vpc-peerings list \
       --network=NETWORK_NAME \
       --service=servicenetworking.googleapis.com \
       --format="value(reservedPeeringRanges.list())"
   )
   

2. 次に、新しい範囲をピアに追加します。

   gcloud services vpc-peerings update \
     --network=NETWORK_NAME \
     --ranges=$EXISTING_RANGES,IP_RANGE_NAME \
     --service=servicenetworking.googleapis.com
   

IP アドレス範囲の枯渇

問題: 範囲が使い果たされたというエラーでインスタンスの作成に失敗する:

ERROR: (gcloud.alpha.Parallelstore.instances.create) FAILED_PRECONDITION: Invalid
resource state for "NETWORK_RANGES_NOT_AVAILABLE": IP address range exhausted

解決策: VPC ガイドに沿って、IP 範囲を再作成するか、既存の IP 範囲を拡張します。

Parallelstore インスタンスを再作成する場合は、IP 範囲を拡張するのではなく、再作成する必要があります。