トラブルシューティングと既知の問題

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

• 既知の問題
• インスタンス オペレーションに関する問題
• Compute Engine の問題
• GKE の問題
• VPC ネットワークの問題

既知の問題

• ファイル システムで I/O が発生していない場合、パフォーマンス グラフに「選択した期間にはデータがありません」というメッセージが表示されます。これは、パフォーマンス指標が生成されるのは I/O がある場合のみであるためです。指標の詳細については、インスタンスとオペレーションをモニタリングするをご覧ください。
• 次の Lustre 機能はサポートされていません。
  • クライアントサイドのデータ圧縮
  • 永続的なクライアント キャッシュ保存
• 一部の Lustre コマンドはサポートされていません。
• POSIX 準拠には例外があります。

インスタンス オペレーションの問題

以降のセクションでは、インスタンス オペレーションに関連する問題について説明します。

オペレーションをキューに登録できません

オペレーションの開始を試みたときに、次のようなエラーが表示された場合:

ERROR: (gcloud.lustre.instances.import-data) ABORTED: unable to queue the operation
ERROR: (gcloud.lustre.instances.export-data) ABORTED: unable to queue the operation
ERROR: (gcloud.lustre.instances.update) ABORTED: unable to queue the operation

このエラーは、同じタイプの別のオペレーションが同じインスタンスで進行中のときに、オペレーションを開始しようとすると発生します。

• インポート/エクスポート: Managed Lustre では、インスタンスごとに一度に 1 つのアクティブな転送オペレーションのみがサポートされます。転送オペレーションではキューイングはサポートされていません。
• インスタンスの更新: Managed Lustre では、インスタンスごとに一度に 1 つの更新を有効にできます。また、追加の更新オペレーションをキューに登録することもできます。

この問題を解決するには、現在のオペレーションが完了するまで待ってから、新しいオペレーションを開始します。

Compute Engine の問題

Compute Engine インスタンスに Managed Lustre ファイル システムをマウントする際に問題が発生した場合は、次の手順で問題を診断します。

Managed Lustre インスタンスに到達できることを確認する

まず、Managed Lustre インスタンスが Compute Engine インスタンスから到達可能であることを確認します。

sudo lctl ping IP_ADDRESS@tcp

IP_ADDRESS の値を取得するには、インスタンスを取得するをご覧ください。

ping が成功すると、次のようなレスポンスが返されます。

12345-0@lo
12345-10.115.0.3@tcp

ping が失敗すると、次の結果が返されます。

failed to ping 10.115.0.3@tcp: Input/output error

ping が失敗した場合:

• Managed Lustre インスタンスと Compute Engine インスタンスが同じ VPC ネットワークにあることを確認します。次のコマンドの出力を比較します。

  gcloud compute instances describe VM_NAME \
    --zone=VM_ZONE \
    --format='get(networkInterfaces[0].network)'
  
  gcloud lustre instances describe INSTANCE_NAME \
    --location=ZONE --format='get(network)'
  

  出力は次のようになります。

  https://www.googleapis.com/compute/v1/projects/my-project/global/networks/my-network
  projects/my-project/global/networks/my-network
  

  gcloud compute instances describe コマンドの出力の接頭辞は https://www.googleapis.com/compute/v1/ です。この文字列に続くすべての文字列は、gcloud lustre instances describe コマンドの出力と一致する必要があります。

• VPC ネットワークのファイアウォール ルールとルーティング構成を確認して、Compute Engine インスタンスと Managed Lustre インスタンス間のトラフィックが許可されていることを確認します。

LNet 受信ポートを確認する

Managed Lustre インスタンスは、作成時に --gke-support-enabled フラグを指定することで、GKE クライアントをサポートするように構成できます。

GKE サポートが有効になっている場合は、すべての Compute Engine インスタンスで accept_port 6988 を使用するように LNet を構成する必要があります。gke-support-enabled インスタンスの LNet を構成するをご覧ください。

インスタンスが GKE クライアントをサポートするように構成されているかどうかを確認するには、次のコマンドを実行します。

gcloud lustre instances describe INSTANCE_NAME \
  --location=LOCATION | grep gkeSupportEnabled

コマンドが gkeSupportEnabled: true を返す場合は、LNet を構成する必要があります。

Ubuntu カーネル バージョンと Lustre クライアントの不一致

Ubuntu を実行している Compute Engine インスタンスの場合、Ubuntu カーネルのバージョンは Lustre クライアント パッケージの特定のバージョンと一致している必要があります。Lustre クライアント ツールが失敗する場合は、Compute Engine インスタンスが新しいカーネルに自動アップグレードされているかどうかを確認します。

カーネル バージョンを確認するには:

uname -r

レスポンスは次のようになります。

6.8.0-1029-gcp

Lustre クライアント パッケージのバージョンを確認するには:

dpkg -l | grep -i lustre

レスポンスは次のようになります。

ii  lustre-client-modules-6.8.0-1029-gcp 2.14.0-ddn198-1  amd64  Lustre Linux kernel module (kernel 6.8.0-1029-gcp)
ii  lustre-client-utils                  2.14.0-ddn198-1  amd64  Userspace utilities for the Lustre filesystem (client)

両方のコマンドでリストされたカーネル バージョンが一致しない場合は、Lustre クライアント パッケージを再インストールする必要があります。

dmesg で Lustre エラーを確認する

Lustre の警告とエラーの多くは、Linux カーネルのリングバッファに記録されます。dmesg コマンドはカーネル リングバッファを出力します。

Lustre 固有のメッセージを検索するには、dmesg と組み合わせて grep を使用します。

dmesg | grep -i lustre

または、関連する可能性のある一般的なエラーを探すには:

dmesg | grep -i error

サポート リクエストに含める情報

マウントの失敗を解決できない場合は、サポートケースを作成する前に診断情報を収集します。

sosreport を実行する: このユーティリティは、システムログと構成情報を収集し、圧縮された tarball を生成します。

sudo sosreport

sosreport アーカイブと dmesg からの関連する出力をサポートケースに添付します。

GKE の問題

このセクションのトラブルシューティングの手順を行う前に、GKE から Managed Lustre に接続する際の制限事項を参照してください。

最小インスタンス容量の更新

Managed Lustre インスタンスの最小容量が 9,000 GiB に更新されました。Managed Lustre CSI ドライバを使用して 9, 000 GiB のインスタンスを作成するには、クラスタ バージョンを 1.34.0-gke.2285000 以降にアップグレードします。

動的にプロビジョニングされた Lustre インスタンスのパフォーマンス階層が正しくない

Lustre インスタンスを動的にプロビジョニングすると、API リクエストで指定された perUnitStorageThroughput の値に関係なく、PerUnitStorageThroughput の InvalidArgument エラーでインスタンスの作成が失敗します。これは、1.33.4-gke.1036000 より前の GKE 1.33 バージョンに影響します。

回避策:

GKE クラスタをバージョン 1.33.4-gke.1036000 以降にアップグレードします。Stable チャンネルを使用している場合、新しいバージョンはまだ利用できない可能性があります。この場合は、修正を含む Regular チャンネルまたは Rapid チャンネルのバージョンを手動で選択できます。

Managed Lustre 通信ポート

Managed Lustre CSI ドライバは、GKE クラスタのバージョンと既存の Managed Lustre 構成に応じて、Managed Lustre インスタンスとの通信に異なるポートを使用します。

• デフォルト ポート（988）: バージョン 1.33.2-gke.4780000 以降を実行する新しい GKE クラスタの場合、ドライバはデフォルトで Lustre 通信にポート 988 を使用します。

• 以前のポート（6988）: 次のシナリオでは、ドライバはポート 6988 を使用します。

  • 以前の GKE バージョン: GKE クラスタで 1.33.2-gke.4780000 より前のバージョンが実行されている場合、CSI ドライバを有効にするときに --enable-legacy-lustre-port フラグが必要です。このフラグを有効にすると、GKE ノードの gke-metadata-server とのポート競合を回避できます。
  • GKE をサポートする既存の Managed Lustre インスタンス: --gke-support-enabled フラグを使用して作成された既存の Managed Lustre インスタンスに接続する場合は、クラスタ バージョンに関係なく、CSI ドライバを有効にするときに --enable-legacy-lustre-port を含める必要があります。このフラグがないと、GKE クラスタは既存の Lustre インスタンスをマウントできません。

  以前のポートで CSI ドライバを有効にする方法について詳しくは、Lustre 通信ポートをご覧ください。

ログクエリ

ログを確認するには、ログ エクスプローラで次のクエリを実行します。

Managed Lustre CSI ドライバのノードサーバーログを返すには:

resource.type="k8s_container"
resource.labels.pod_name=~"lustre-csi-node*"

ボリュームのプロビジョニングに関するトラブルシューティング

PersistentVolumeClaim（PVC）が Pending 状態のままで、20 ～ 30 分後に PersistentVolume（PV）が作成されない場合は、エラーが発生した可能性があります。

1. PVC イベントを確認します。

   kubectl describe pvc PVC_NAME
   

2. エラーが構成の問題または無効な引数を示している場合は、StorageClass パラメータを確認します。

3. PVC を再作成します。

4. 問題が解決しない場合は、Cloud カスタマーケアにお問い合わせください。

ボリュームのマウントに関するトラブルシューティング

Pod がノードにスケジュールされると、ボリュームがマウントされます。失敗した場合は、Pod イベントと kubelet ログを確認します。

kubectl describe pod POD_NAME

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

症状:

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

または

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

原因: CSI ドライバが有効になっていないか、まだ実行されていません。

解決策:

1. CSI ドライバが有効になっていることを確認します。
2. クラスタを最近スケーリングまたはアップグレードした場合は、ドライバが機能するまで数分待ちます。
3. エラーが解決しない場合は、lustre-csi-node ログで「Operation not permitted」を確認します。これは、ノード バージョンが古すぎて Managed Lustre をサポートできないことを示しています。この問題を解決するには、ノードプールをバージョン 1.33.2-gke.1111000 以降にアップグレードします。
4. ログに「LNET_PORT mismatch」と表示された場合は、ノードプールをアップグレードして、互換性のある Lustre カーネル モジュールがインストールされていることを確認します。

マウント ポイントがすでに存在します

症状:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = AlreadyExists
desc = A mountpoint with the same lustre filesystem name "yyy" already exists on
node "yyy". Please mount different lustre filesystems

原因: 同じファイル システム名を持つ異なる Managed Lustre インスタンスから複数のボリュームを単一ノードにマウントすることはできません。

解決策: Managed Lustre インスタンスごとに一意のファイル システム名を使用します。

マウントに失敗しました: 該当するファイルまたはディレクトリがありません

症状:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = Internal desc = Could not mount ... failed: No such file or directory

原因: 指定されたファイル システム名が正しくないか、存在しません。

解決策: StorageClass または PV 構成の fs_name が Managed Lustre インスタンスと一致していることを確認します。

マウントに失敗しました: 入出力エラー

症状:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = Internal desc = Could not mount ... failed: Input/output error

原因: クラスタが Managed Lustre インスタンスに接続できません。

解決策:

1. Managed Lustre インスタンスの IP アドレスを確認します。
2. GKE クラスタと Managed Lustre インスタンスが同じ VPC ネットワーク内にあるか、正しくピアリングされていることを確認します。

内部エラー

症状: rpc error: code = Internal desc = ...

解決策: エラーが解決しない場合は、Cloud カスタマーケアにお問い合わせください。

ボリュームのマウント解除に関するトラブルシューティング

症状:

UnmountVolume.TearDown failed for volume "yyy" : rpc error: code = Internal desc = ...

解決策:

1. Pod を強制削除します。

   kubectl delete pod POD_NAME --force
   

2. 問題が解決しない場合は、Cloud カスタマーケアにお問い合わせください。

ボリュームの削除に関するトラブルシューティング

PVC を削除した後、PV が「Released」状態のまま長時間（1 時間以上など）経過している場合は、Cloud カスタマーケアにお問い合わせください。

ボリューム拡張のトラブルシューティング

PVC が ExternalExpanding でスタックしている

症状: PVC のステータスが Resizing に変わらず、イベントに ExternalExpanding が表示されます。

原因: allowVolumeExpansion フィールドがないか、false に設定されている可能性があります。

解決策: StorageClass に allowVolumeExpansion: true があることを確認します。

kubectl get storageclass STORAGE_CLASS_NAME -o yaml

拡張が失敗する: 引数が無効

症状: VolumeResizeFailed: rpc error: code = InvalidArgument ...

原因: リクエストされたサイズが無効です（ステップサイズの倍数ではない、上限を超えているなど）。

解決策: 有効な容量範囲を確認し、有効なサイズで PVC を更新します。

拡張に失敗する: 内部エラー

症状: VolumeResizeFailed ... rpc error: code = Internal

解決策: PVC を再適用して、拡張を再試行します。繰り返し失敗する場合は、Cloud カスタマーケアにお問い合わせください。

期限を超過しました

症状: VolumeResizeFailed で DEADLINE_EXCEEDED が発生する。

原因: オペレーションに予想よりも時間がかかっていますが、まだ進行中の可能性があります。

解決策: オペレーションが完了するまで待ちます。リサイザーは自動的に再試行します。長時間（1 時間以上など）動かない場合は、> 90 分）の場合は、サポートにお問い合わせください。

割り当てを超えている

症状: 割り当ての上限により拡張が失敗する。

解決策: 割り当ての増加をリクエストするか、容量の増加を小さくリクエストします。

VPC ネットワークの問題

以降のセクションでは、VPC ネットワークの一般的な問題について説明します。

ピアリングされたプロジェクトから Managed Lustre にアクセスできない

ピアリングされた VPC ネットワーク内の VM から Managed Lustre インスタンスにアクセスするには、Network Connectivity Center（NCC）を使用する必要があります。NCC を使用すると、複数の VPC ネットワークとオンプレミス ネットワークを中央ハブに接続し、それらの間の接続を提供できます。

NCC の設定方法については、Network Connectivity Center のドキュメントをご覧ください。

マルチ NIC VM で Lustre のマウントが失敗する

VM に複数のネットワーク インターフェース コントローラ（NIC）があり、マネージド Lustre インスタンスがセカンダリ NIC に接続された VPC 上にある場合（例: eth1）、インスタンスのマウントが失敗する可能性があります。この問題を解決するには、セカンダリ NIC を使用してマウントする手順に沿って操作します。

172.17.0.0/16 サブネット範囲から接続できない

172.17.0.0/16 サブネット範囲の IP アドレスを持つ Compute Engine クライアントと GKE クライアントは、マネージド Lustre インスタンスをマウントできません。

サービス 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-peering をすでに作成している場合に返されます。考えられる解決法は次の 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())" \
       --flatten=reservedPeeringRanges
   )
   

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

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

IP アドレス範囲が枯渇した

範囲が使い果たされたというエラーでインスタンスの作成に失敗した場合:

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

VPC ガイドに沿って、既存のプライベート接続を変更して IP アドレス範囲を追加します。

プレフィックス長は /20 以上（1,024 個のアドレス）にすることをおすすめします。