このページでは、最高のパフォーマンスを実現するように Google Cloud Managed Lustre 環境を構成するためのガイダンスを提供します。
パフォーマンス仕様
次のパフォーマンス値は、おおよその最大値です。
IOPS
最大 IOPS は、プロビジョニングされたインスタンス容量の TiB あたりで線形にスケーリングされます。
| スループット ティア | 読み取り IOPS（TiB あたり） | 書き込み IOPS（TiB あたり） |
|---|---|---|
125 MBps per TiB |
725 | 700 |
250 MBps per TiB |
1,450 | 1,400 |
500 MBps per TiB |
2,900 | 2,800 |
1000 MBps per TiB |
5,800 | 5,600 |
メタデータ オペレーション
プロビジョニングされたスループット 72 GBps ごとに、メタデータ オペレーションの最大数が段階的に増加します。
| ファイル統計情報 | ファイル作成 | ファイルの削除 | |
|---|---|---|---|
| 72 GBps あたり | 410,000/秒 | 115,000/秒 | 95,000/秒 |
容量増加後のパフォーマンス
既存のインスタンスのストレージ容量を増やすと、最大スループットと IOPS が増加し、メタデータ パフォーマンスも向上する可能性があります。
新しいデータが書き込まれ、追加ストレージに再分配されるにつれて、読み取りスループットのパフォーマンスが徐々に向上します。書き込みスループットのパフォーマンスがすぐに向上します。
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
ワークロードから複数の NIC にネットワーク トラフィックが分散されていることを確認するには、ワークロードがスケジュールされているノードに一時的なネットワーク デバッガ Pod をデプロイします。
ワークロードがスケジュールされているノードを特定します。
kubectl get pod POD_NAME -o widePOD_NAME は、Pod の名前に置き換えます。コマンド出力で、
NODE列の名前をメモします。そのノードでネットワーク デバッガを起動します。
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 は、前の手順のノード名に置き換えます。
出力で、
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 GByteCtrl+C キーを押してデバッガを終了します。
単一クライアントのパフォーマンスを測定する
単一の Compute Engine クライアントから読み取りと書き込みのパフォーマンスをテストするには、fio（Flexible I/O テスター）コマンドライン ツールを使用します。
fio をインストールします。
Rocky 8
sudo dnf install fio -yUbuntu 20.04 と 22.04
sudo apt update sudo install fio次のコマンドを実行します。
fio --ioengine=libaio --filesize=32G --ramp_time=2s \ --runtime=5m --numjobs=16 --direct=1 --verify=0 --randrepeat=0 \ --group_reporting --directory=/lustre --buffer_compress_percentage=50 \ --name=read --blocksize=1m --iodepth=64 --readwrite=read
テストの完了には、約 5 分かかります。完了すると、結果が表示されます。構成によっては、VM の最大ネットワーク速度までのスループットと、TiB あたり数千の IOPS が期待できます。