パフォーマンスのヒント - FSx for Lustre
Intelligent-Tiering のパフォーマンスに関する考慮事項

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

パフォーマンスのヒント

Amazon FSx for Lustre を使用する場合は、次のパフォーマンスのヒントに留意してください。サービスの制限については、「Amazon FSx for Lustre のサービスクォータ」を参照してください。

  • 平均 I/O サイズ - Amazon FSx for Lustre はネットワークファイルシステムであるため、各ファイルオペレーションはクライアントと Amazon FSx for Lustre の間でラウンドトリップされるため、レイテンシーのオーバーヘッドが小さくなります。このオペレーションあたりのレイテンシーのため、通常は平均 I/O サイズの増加に応じて全体のスループットが向上します。大量のデータにオーバーヘッドが分散するためです。

  • リクエストモデル -ファイルシステムへの非同期書き込みを有効にすることで、保留中の書き込みオペレーションは、Amazon FSx for Lustre に非同期で書き込まれる前に、Amazon EC2 インスタンスでバッファリングされます。非同期書き込みは、通常レイテンシーが低くなります。非同期書き込みを実行するとき、カーネルはキャッシュの追加のメモリを使用します。同期書き込みを有効にしているファイルシステムは、Amazon FSx for Lustre に同期リクエストを発行します。各オペレーションはクライアントと Amazon FSx for Lustre の間のラウンドトリップを通過します。

    注記

    選択したリクエストモデルでは、整合性 (複数の Amazon EC2 インスタンスを使用している場合) と速度にトレードオフがあります。

  • ディレクトリサイズの制限 – Persistent 2 FSx for Lustre ファイルシステムで最適なメタデータパフォーマンスを実現するには、各ディレクトリを 100K ファイル未満に制限します。ディレクトリ内のファイル数を制限すると、ファイルシステムが親ディレクトリのロックを取得するのに必要な時間が短縮されます。

  • Amazon EC2 インスタンス - 多数の読み取りおよび書き込みオペレーションを実行するアプリケーションは、そうでないアプリケーションよりも多くのメモリまたはコンピューティング容量ーを必要とします。コンピューティングを多用するワークロードのために Amazon EC2 インスタンスを起動するときは、アプリケーションが必要とする量のリソースを持つインスタンスタイプを選択します。Amazon FSx for Lustre ファイルシステムのパフォーマンス特性は、Amazon EBS 最適化インスタンスの使用に依存しません。

  • 最適なパフォーマンスを得るために推奨されるクライアントインスタンスの調整

    1. メモリが 64 GiB を超えるクライアントインスタンスタイプでは、次の調整を適用することをお勧めします。

      sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000
sudo lctl set_param ldlm.namespaces.*.lru_size=<100 * number_of_CPUs>

    2. 64 vCPU コアを超えるクライアントインスタンスタイプでは、次の調整を適用することをお勧めします。

      echo "options ptlrpc ptlrpcd_per_cpt_max=32" >> /etc/modprobe.d/modprobe.conf
echo "options ksocklnd credits=2560" >> /etc/modprobe.d/modprobe.conf
            
# reload all kernel modules to apply the above two settings
sudo reboot

      クライアントをマウントした後、次の調整を適用する必要があります。

      sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32
sudo lctl set_param mdc.*.max_rpcs_in_flight=64
sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50

    注: lctl set_param は再起動すると持続しないことが知られています。これらのパラメータはクライアント側から永続的に設定することはできないため、ブート cron ジョブを実装して、お勧めの調整を使用して設定することをお勧めします。

  • OSTs 間のワークロードバランス – 場合によっては、ワークロードがファイルシステムが提供できる総スループット (ストレージ 1 TiB あたり 200 MBps) を駆動していないことがあります。その場合は、CloudWatch メトリクスを使用して、ワークロードの I/O パターンの不均衡によってパフォーマンスが影響を受けるかどうかをトラブルシューティングできます。これが原因であるかどうかを特定するには、Amazon FSx for Lustre の最大 CloudWatch メトリクスを参照してください。

    場合によっては、この統計は 240 MBps のスループット (単一の 1.2 TiB Amazon FSx for Lustre ディスクのスループットキャパシティ) 以上の負荷を示します。このような場合、ワークロードはディスク全体に均等に分散されません。この場合、lfs setstripe コマンドを実行して、ワークロードが頻繁にアクセスしているファイルのストライピングを変更します。最適なパフォーマンスを得るには、ファイルシステムを設定するすべての OST で、スループット要件が高いファイルをストライプ化します。

    ファイルをデータリポジトリからインポートする場合は、別の方法を使用して、高スループットファイルを OST 全体で均等にストライプできます。そのためには、次の Amazon FSx for Lustre ファイルシステムを作成するときの ImportedFileChunkSize パラメータを変更できます。

    例えば、ワークロードが 7.0 TiB ファイルシステム (6 x 1.17 TiB OST で設定されている) を使用し、2.4 GiB ファイル間で高いスループットを駆動する必要があるとします。この場合、ImportedFileChunkSize の値を (2.4 GiB / 6 OSTs) = 400 MiB に設定できます。これにより、ファイルがファイルシステムの OST 全体に均等に分散されます。

  • Lustre メタデータ IOPS 用 クライアント – ファイルシステムにメタデータ設定が指定されている場合は、Amazon Linux Lustre 2023、Amazon Linux Lustre 2、Red Hat/Rocky Linux 8.9、8.10、または 9.x、CentOS 8.9 または 8.10、Ubuntu 22+ と 6.2、6.5、または 6.8 カーネル、または Ubuntu 20 のいずれかの OS バージョンで 2.15 クライアントまたは 2.12 クライアントをインストールすることをお勧めします。

Intelligent-Tiering のパフォーマンスに関する考慮事項

Intelligent-Tiering ストレージクラスを使用してファイルシステムを使用する際の重要なパフォーマンス上の考慮事項を以下に示します。

  • I/O サイズが小さいデータを読み取るワークロードは、Intelligent-Tiering ストレージ階層からのレイテンシーが高いため、I/O サイズが大きいワークロードと同じスループットを実現するために、より高い同時実行性を必要とし、より多くのリクエストコストが発生します。小さい IO サイズを使用する場合、より高い同時実行性とスループットをサポートするのに十分な大きさの SSD 読み取りキャッシュを設定することをお勧めします。

  • Intelligent-Tiering ファイルシステムでクライアントが駆動できる最大ディスク IOPS は、ワークロードの特定のアクセスパターンと、SSD 読み取りキャッシュをプロビジョニングしたかどうかによって異なります。ランダムアクセスのワークロードでは、データが SSD リードキャッシュにキャッシュされている場合、クライアントは通常、データがキャッシュにない場合よりもはるかに高い IOPS を駆動できます。

  • Intelligent-Tiering ストレージクラスは先行読み込みをサポートし、シーケンシャル読み込みリクエストのパフォーマンスを最適化します。可能な限り、データアクセスパターンを順番に設定して、データのプリフェッチとパフォーマンスの向上を可能にすることをお勧めします。