パフォーマンスに関する注意事項

このページでは、最高のパフォーマンスを得るために Google Cloud Managed Lustre 環境を構成する方法について説明します。

パフォーマンス Tier ごとのパフォーマンス数値については、 パフォーマンス Tier をご覧ください。

容量を増やした後のパフォーマンス

既存のインスタンスのストレージ容量を増やすと、最大スループットと IOPS が増加し、メタデータのパフォーマンスも向上する可能性があります。

新しいデータが書き込まれ、追加のストレージに再分散されるにつれて、読み取りスループットのパフォーマンスが徐々に向上します。書き込みスループットのパフォーマンスはすぐに向上します。

容量使用率が高い

インスタンスのストレージ容量の使用率が 90% に達すると、インスタンスのパフォーマンスが低下する可能性があります。Managed Lustre インスタンスの容量を増やすことを検討してください。拡張する前に、追加の割り当てをリクエストする必要がある場合があります。

No space left on device エラーが表示されるが、インスタンスに残りの容量が表示される場合は、No space left on device エラーをご覧ください。

VPC ネットワークの最大伝送単位（MTU）

VPC ネットワークを作成するときに、mtu (最大伝送単位: このネットワーク上で送信可能な最大の IP パケットサイズ）の値を、デフォルトの 1, 460 バイトから、許可されている最大値の 8, 896 バイトに設定すると、性能が最大で約 10 ％向上します。

ネットワークの現在の MTU 値は、次のコマンドで確認できます。

gcloud compute networks describe NETWORK_NAME --format="value(mtu)"

ネットワークの MTU 値は、ネットワークの作成後に更新できますが、重要な考慮事項があります。詳細については、 ネットワークの MTU を変更するをご覧ください。

Compute Engine のマシンタイプ

ネットワーク スループットは、選択するマシンタイプによって影響を受ける可能性があります。一般に、最適なスループットを得るには、次のことを行います。

  • vCPU の数を増やす。インスタンスあたりの最大下り（外向き）帯域幅は、通常は vCPU あたり 2 Gbps ですが、マシンタイプの最大値までです。
  • 上り（内向き）と下り（外向き）の上限が高いマシンシリーズを選択します。たとえば、Tier_1 ネットワーキングを使用する C2 インスタンスは、最大 100 Gbps の下り（外向き）帯域幅をサポートします。Tier_1 ネットワーキングを使用する C3 インスタンスは、最大 200 Gbps をサポートします。
  • より大きいマシンタイプを使用して、VM あたりの Tier_1 ネットワーキング パフォーマンスを有効にします。
  • Google Virtual NIC（gVNIC）を使用します。 gVNIC は、第 3 世代以降のマシンタイプでのみ使用できます。Tier_1 ネットワーキングを使用する場合は、gVNIC が 必要です。

詳細については、ネットワーク帯域幅をご覧ください。

マルチ NIC 構成

Lustre の組み込みのマルチレール機能を使用すると、クライアントは複数のネットワーク インターフェース カード（マルチ NIC）にネットワーク トラフィックをストライピングできます。これにより、帯域幅が集約され、大容量の Managed Lustre インスタンスが飽和状態になります。

マルチ NIC を構成するには、次の操作を行う必要があります。

  • 複数の物理 NIC を備えたマシンタイプを選択します。
  • NIC ごとにサブネットを作成し、各 NIC をそのサブネットに割り当てます。
  • Compute EngineまたはGKE から接続する場合は、マルチ NIC の手順に沿って操作します。

トラフィック バランシングを確認する

マルチ NIC を構成したら、データが正しくバランシングされていることを確認します。

Compute Engine

Managed Lustre バックエンドにトラフィックを生成しながら、nload を使用して構成済みのネットワーク インターフェース（eth0 や eth1 など）をモニタリングし、VM で直接データ バランシングを確認します。

nload -m eth0 eth1

マルチ NIC 構成が成功した場合、送信ビットレートは構成されたすべてのインターフェースでほぼ同じになります。

GKE

ワークロードがスケジュールされているノードに一時的なネットワーク デバッガ Pod をデプロイして、ワークロードからのネットワーク トラフィックが複数の NIC に分散されていることを確認します。

  1. ワークロードがスケジュールされているノードを特定します。

    kubectl get pod POD_NAME -o wide

    POD_NAME は、Pod の名前に置き換えます。コマンド出力で、NODE 列の名前をメモします。

  2. そのノードでネットワーク デバッガを起動します。

    kubectl run multi-nic-debug --rm -i --tty --image=nicolaka/netshoot \
  --overrides='{"spec": {"hostNetwork": true, "nodeSelector": {"kubernetes.io/hostname": "NODE_NAME"}, "tolerations": [{"key": "nvidia.com/gpu", "operator": "Exists", "effect": "NoSchedule"}]}}' \
  -- /bin/bash -c "apk update && apk add nload && nload -m eth0 eth1"

    NODE_NAME は、前の手順のノード名に置き換えます。

  3. 出力で、eth0 と eth1 の [Outgoing] 列のビットレートを分析します。構成が成功すると、ビットレートはほぼ同じになります。出力は次のようになります。

    Device eth0 [10.1.0.50] (1/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.63 MBit/s                       Curr: 1.46 GBit/s
Avg: 1.60 MBit/s                        Avg: 1.44 GBit/s
Min: 1.40 MBit/s                        Min: 1.25 GBit/s
Max: 1.64 MBit/s                        Max: 1.47 GBit/s
Ttl: 590.94 GByte                       Ttl: 405.19 GByte

Device eth1 [172.16.15.5] (2/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.64 MBit/s                       Curr: 1.47 GBit/s
Avg: 1.62 MBit/s                        Avg: 1.44 GBit/s
Min: 1.42 MBit/s                        Min: 1.26 GBit/s
Max: 1.66 MBit/s                        Max: 1.47 GBit/s
Ttl: 587.68 GByte                       Ttl: 406.36 GByte

  4. Ctrl+C を押してデバッガを終了します。

一般的なボトルネックのトラブルシューティング

ワークロードのパフォーマンスが Managed Lustre パフォーマンス Tier で想定されるよりも大幅に低い場合は、次の一般的な問題を確認してください。

  • クライアント マシンの数が少ない: 単一のクライアント マシンは、独自の仮想 CPU（vCPU）とシングルリンク ネットワーク処理の上限によってボトルネックになります。高スループット Tier を飽和させるには、負荷を分散する必要があります。たとえば、100,000 MBps の Managed Lustre ファイル システムを飽和させるには、通常、並行して書き込む 60 台以上の標準クライアント マシン（または Tier 1 高帯域幅ネットワーキングを使用するように構成された 12 台のクライアント マシン）が必要です。パフォーマンス Tier の最大インスタンス サイズの場合、Tier 1 高帯域幅ネットワーキングを使用するように構成された 2,500 台以上のクライアント マシンが必要になることがあります。

  • 理想的でない Virtual Private Cloud（VPC）MTU: デフォルトでは、VPC ネットワークは 1460 の MTU（標準イーサネット フレーム）を使用します。Managed Lustre などの高性能ストレージの場合は、MTU が 8896 のジャンボ フレームを構成する必要があります。標準の 1460 MTU で実行すると、CPU は 2 倍以上のネットワーク パケットを処理する必要があるため、CPU オーバーヘッドが増加し、最大帯域幅が制限されます。

  • Tier 1 ネットワーク帯域幅の構成がない: 多くの高性能マシンタイプでは、Tier 1 ネットワーク帯域幅を明示的にオプトインする必要があります。

    • Compute Engine と GKE Standard ノードプールでは、作成時に --network-performance-configs=total-egress-bandwidth-tier=TIER_1 フラグを使用します。このフラグがない場合、VM またはノードはデフォルトの下り（外向き）の上限が低くなる可能性があります。
    • GKE Autopilot では、このフラグを直接指定しません。代わりに、Pod 仕様のノードセレクタを使用して、より高い帯域幅をサポートするマシンシリーズ（c3 など）を選択します。

    詳細については、 Compute Engine のマシンタイプをご覧ください。

  • Lustre オブジェクト ストレージ ターゲット（OST）の使用状況が不均衡: Managed Lustre は、複数のオブジェクト ストレージ ターゲット（OST）にファイルデータを分割します。テストまたはワークロードが単一のストライピングされていないファイルに書き込む場合、またはクライアント タスクが単一の OST をオーバーロードするパターンを書き込む場合、その OST がボトルネックになり、ファイル システムの残りの部分はアイドル状態になります。これを回避するには、使用可能なすべての OST に書き込みペイロードを均等に分散します（たとえば、ベンチマークでファイルごとのプロセス モードを使用します）。

  • 共有ネットワーク帯域幅の競合: クライアント マシン（Compute Engine VM または GKE ノード）の下り（外向き）帯域幅は、マシン上のすべてのネットワーク オペレーションで共有されます。クライアント マシンまたは Pod が同時に大きなパッケージをダウンロードしたり、大量のロギング スイープを実行したり、他のクラスタノードと頻繁に通信したりすると、ストレージ パフォーマンスは残りのネットワーク帯域幅に制限されます。