Persistent-50 高性能ファイルシステムは、強力な機能を備えています!



人生の多くのことでいえることですが、選択肢が多いほど、決断を下すことが難しくなります。クラウドでワークロードを実行すると、いくつかの決定が容易になりますが、それによってワークロードが完全になくなるわけではなく、クラウドの最適な設計方法を選択する必要があります。これらの決定は、どの AWS のサービス、リソース、または設定があなたに最適であるかに重点を置いています。Amazon FSx for Lustre に永続的なファイルシステムが備わったところで、どのユニットあたりのスループット設定がワークロードに最適であるか疑問に思われた方も多いことでしょう。このブログ記事では、FSx for Lustre persistent-50 ファイルシステムのパフォーマンスについてご紹介します。ここでは、並列ファイルシステムのパフォーマンスを評価するのに一般的に使用されるファイルシステムベンチマークアプリケーションである IOR を使用します。これで、読み取りおよび書き込み操作を使ってさまざまなファイルシステムコンポーネントをテストします。そうすることで、persistent-50 ファイルシステムが、これらのファイルシステムのアドバタイズされたユニットごとのスループット値をはるかに超えて、非常に高いスループットをどのように実現できるかを知ってもらえればと思います。

FSx for Lustre の永続的ファイルシステムにあまり詳しくない場合は、AWS の同僚が書いたこの最近のブログ記事を読むことをお勧めします。

どのようにして高性能が達成されるか

FSx for Lustre の (スクラッチまたは永続的) ファイルシステムを作成する場合、ファイルシステムの合計ストレージ容量を選択します。ファイルシステムがサポートできるスループットは、そのストレージ容量に比例します。スクラッチデプロイタイプのファイルシステムの場合、ユニットあたりのスループットはストレージ容量の TiB あたり 200 MB/s です。簡単で、決断する必要はありません。デプロイタイプの永続的ファイルシステムの場合、ストレージ容量の TiB あたり 50 MB/s (persistent-50)、100 MB/s (persistent-100)、または 200 MB/s (persistent-200) を選択できます。これらのユニットごとのスループットオプションの料金はそれぞれ異なりますが、予算とパフォーマンスのニーズに最適なスループットレベルを柔軟に選択できます。

ファイルシステムの全体的なスループットに寄与する 3 つのコンポーネントがあります。ネットワークスループット、インメモリキャッシュとディスクスループットです。Amazon FSx for Lustre ユーザーガイドのパフォーマンスセクションには、すべてのデプロイタイプのファイルシステムのディスク、インメモリキャッシュ、ネットワークスループットを示した素晴らしい表があります。次の (表 1) はその表のサブセットであり、永続的ファイルシステムのスループットとキャッシュ情報のみを示しています。

表 1 – FSx for Lustre の永続的ファイルシステムのパフォーマンス

ファイルシステムのユニットごとのスループットを選択すると、そのファイルシステムで使用できるベースラインディスクスループットを実際に選択していることになります。これは通常、ファイルシステムの最も遅いパフォーマンスのコンポーネントです。バーストディスクスループット、インメモリキャッシュ、およびファイルシステムのベースラインと可変ネットワークパフォーマンスにより、ベースラインディスクスループットよりも大幅に高いスループットレートで動作することができます。これにより、実際に選択したユニットごとのスループットよりもはるかに高いスループットを利用できます。

通常、ファイルベースのワークロードは急上昇し、短期間に高レベルのスループットを駆動しますが、長期間にわたって低レベルのスループットを駆動します。このようなタイプのワークロードは、FSx for Lustre のバーストモデルに最適です。ワークロードの一貫性が高い場合は、ニーズに合わせた永続的なユニットごとのスループットを選択してください。ただし、必要に応じてバーストスループットを利用できることに注意してください。最近では、いつ標準を超えるスループットレベルを使用する可能性のある出来事が発生するかは知る由もありません。

テスト方法

Persistent-50 ファイルシステムがベースラインを超えてバーストする様子をお見せします。

最初に、2.4 TiB の persistent-50 ファイルシステムを作成します。表 1 の値に基づいて、永続的ファイルシステムで使用できるスループットとインメモリキャッシュは、次の表 (表 2) に示されています。

表 2 – 2.4-TiB ファイルシステムの FSx for Lustre 永続的ファイルシステムのパフォーマンス

次に、最新の Amazon Linux 2 AMI を使用して 4 つの m5n.8xlarge インスタンスを起動します。このインスタンスタイプは、ネットワークパフォーマンスが変動しないため意図的に選択しました。3 つの長期実行テストが、小規模な Amazon EC2 インスタンスの変動するネットワークパフォーマンスから影響を受けたくありません。EC2 インスタンスからファイルシステムまで一貫したネットワークパフォーマンスが必要です。

以下は、ユーザーデータスクリプトの例です。最新の AWS CLI、Lustre クライアント、IOR、いくつかのパッケージをインストールし、2.4 TiB の persistent-50 ファイルシステムを /fsx としてマウントします。このスクリプトはファイルシステムのストライプカウントやサイズを変更しないため、すべてのテストでデフォルトの Lustre ストライプ設定 (ストライプカウント 1、ストライプサイズ 1,048,576 バイト) を使用します。

#cloud-config
repo_update: true
repo_upgrade: all

runcmd:
- curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
- unzip awscli-bundle.zip
- ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws
- sudo export PATH=/usr/local/bin:$PATH

- amazon-linux-extras install -y epel lustre2.10
- yum groupinstall -y "Development Tools"
- yum install -y fpart parallel tree nload git libaio-devel openmpi openmpi-devel

- cd /home/ec2-user
- git clone https://github.com/hpc/ior.git
- export PATH=$PATH:/usr/lib64/openmpi/bin
- export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib64/openmpi/lib/
- cd ior
- ./bootstrap
- ./configure
- make
- sudo cp src/ior /usr/local/bin
- cd /home/ec2-user

- filesystem_id=
- mount_point=/fsx
- availability_zone=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
- region=${availability_zone:0:-1}
- mount_name=$(aws fsx describe-file-systems --file-system-ids ${filesystem_id} --query 'FileSystems[*].LustreConfiguration.MountName' --output text --region ${region})
- mkdir -p ${mount_point}
- echo "${filesystem_id}.fsx.${region}.amazonaws.com:/${mount_name} ${mount_point} lustre defaults,noatime,flock,_netdev 0 0" >> /etc/fstab
- mount -a -t lustre
- chown ec2-user:ec2-user ${mount_point}

3 番目に、4 つのインスタンスすべてから、512 GiB のデータを persistent-50 ファイルシステムに並行して継続的に書き込む IOR スクリプトを実行します。以下は、IOR 書き込みスクリプトの例です。クライアント EC2 インスタンスのキャッシュをバイパスし、インスタンスごとに 8 つのスレッドを使用します。

# IOR - write test
instance_id=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
mpirun --npernode 8 --oversubscribe ior --posix.odirect -t 1m -b 1m -s 16384 -g -v -w -i 100 -F -k -D 0 -o /fsx/ior-${instance_id}.bin

次の Amazon CloudWatch グラフのスクリーンショットは、ファイルシステムの合計スループットを示しています。IOR 書き込みテストは、ファイルシステムのバーストと可変スループットを短期間使用しており、全体的なスループットは一貫して 604 MB/s です。テストの残りの部分では、ベースラインスループットが 117 MB/s の persistent-50 ファイルシステムから 149 MB/s を取得しました。これらの結果と理論上の数値との比較については、上記の表 2 を参照してください。

第 4 に、バーストクレジットが補充されるのを待つのではなく、テストしたばかりのものと同じ新しい 2.4 TiB の persistent-50 ファイルシステムを作成し、4 つすべての EC2 インスタンスにマウントします。これには約 5 分しかかからないので、すぐに次のテストに取りかかれます。1 つのインスタンスから、8 つの 8 GiB ファイル、合計 64 GiB のデータを作成する IOR スクリプトを実行します。次に、4 つのインスタンスすべてから IOR スクリプトを実行し、インスタンスごとに 8 つのスレッドを使用してこれらのファイルから継続的に読み取ります。以下は、IOR スクリプトの例です。

# IOR - write test from one instance
mpirun --npernode 8 --oversubscribe ior --posix.odirect -t 1m -b 1m -s 8192 -g -v -w -i 1 -F -k -D 0 -o /fsx/ior.bin

# IOR - read test from all instances
mpirun --npernode 8 --oversubscribe ior --posix.odirect -t 1m -b 1m -s 8192 -g -r -i 10000 -F -k -D 60 -o /fsx/ior.bin

次のグラフは、この読み取りテストの合計スループットを示しています。繰り返しますが、IOR 読み取りテストでは、ファイルシステムのバーストと可変スループットを短期間使用しており、スループットは一貫して 638 MB/s です。テストの残りの部分では、117 MB/s のベースラインスループットを持つ persistent-50 ファイルシステムから 153 MB/s を取得します。これらの結果と理論上の数値との比較については、上記の表 2 を参照してください。

5 番目に、もう一度、新しい 2.4-TiB ファイルシステムを作成して、完全なバースト機能で開始します。ファイルシステムのネットワークパフォーマンスのみをテストしたいので、IOR を使用して、インメモリキャッシュに完全に常駐できるデータセットを作成します。1 つの EC2 インスタンスから、8 つの 675-MiB ファイル (合計 5.28 GiB のデータ) を作成します。次に、4 つのインスタンスすべてから IOR スクリプトを実行し、インスタンスごとに 8 つのスレッドを使用してこれらのファイルから継続的に読み取ります。今示しているのを含むすべての IOR スクリプトは、–posix.odirect フラグを使用して EC2 インスタンスのローカルキャッシュをバイパスします。これにより、すべての I/O リクエストがファイルシステムからネットワーク経由で送信されるようになります。以下は、IOR スクリプトの例です。

# IOR - write test from one instance
mpirun --npernode 8 --oversubscribe ior --posix.odirect -t 1m -b 1m -s 675 -g -v -w -i 1 -F -k -D 0 -o /fsx/ior.bin

# IOR - read test from all instances
mpirun --npernode 8 --oversubscribe ior --posix.odirect -t 1m -b 1m -g -r -i 2000000 -F -k -D 0 -z -o /fsx/ior.bin

結果は驚くべきものです。

短期間、ファイルシステムは一貫して 3170 MB/s の可変ネットワークスループットを提供し、続いて 625 MB/s の安定したベースラインネットワークスループットを提供しました。

ワークロードは、おそらくキャッシュ用に指定したメモリよりもはるかに大きい可能性がありますが、ワークロードの一部は、このようなファイルシステムのこのインメモリキャッシュと高い可変ネットワークスループットを利用できるはずです。

結果を見てください

ストレージ容量の TiB あたりわずか 50 MB/s という少ないストレージ容量に惑わされないようにしてください。persistent-50 ファイルシステムが物を言います。これらのテストの結果は、書き込み、読み取り、およびインメモリキャッシュ読み取りの各テスト中に、ファイルシステムのユニットごとのスループットよりもそれぞれ 5.15 倍、5.44 倍、および 27.05 倍高速にファイルシステムをバーストできたことを示しています。バースト以外の数値でさえ、書き込み、読み取り、およびインメモリキャッシュ読み取りテストで、ベースラインのユニットごとのスループットよりも 27.34% 、30.77% 、および 434.19% 高く、大幅に増加しました。

ファイルシステムのスループットはファイルシステムのストレージ容量に比例するため、通常の増加を考慮して必要となるストレージ容量の合計か、またはユニットごとのストレージスループット値の違いに基づいて必要となる合計スループットの 2 つの値のうち、大きい方に基づいてファイルシステムのサイズを決定することをいつもお勧めしています。POC 環境でワークロードをテストして、persistent-50 ファイルシステムを使用して実行できるかどうかを確認しましょう。I/O パターンに基づいて実際に得られるスループットは、ファイルシステムの作成時に選択したスループットよりも大幅に大きくなる可能性があることを覚えておいてください。

最後に考察すべきこと

次回は、FSx for Lustre ファイルシステムを作成します。そしてポインターをストレージのユニットごとのスループットのラジオボタン上で前後に動かし、計算を行い、persistent-50 ファイルシステムを使用してテストを行います。驚かれると思いますよ。

これらのテストを実行している様子を映した動画を見るには、FSx Lustre Resources ウェブページで、「Amazon FSx for Lustre: 永続的ストレージの概要」の動画をご覧ください。Amazon FSx for Lustre の永続的ファイルシステムの詳細については、Amazon FSx for Lustre のサイトとユーザーガイドをご覧ください。

このブログ記事をお読みいただき、ありがとうございました。ご質問やコメントは、コメント欄にご記載いただければ幸いです。