Amazon FSx for NetApp ONTAP で Quality of Service を使用する

このブログは 2023 年 3 月 28 日に James Kuhlke（Principal Solutions Architect）によって執筆された内容を日本語化したものです。原文はこちらを参照してください。

クラウド上にファイルシステムを構築する場合の大きな利点の 1 つは、管理者が従来の大規模ストレージコントローラーに制約されなくなることです。これによって、導入の敷居がさがり、ワークロードごとに個別のファイルシステムをプロビジョニングすることができます。ただし、ワークロードを集中管理されたファイルシステムにまとめなければならない場合があります。この例として、管理の簡素化や、コストの削減、複数の小規模なワークロードがバースト目的で大規模なファイルシステムのパフォーマンスを利用できるようにすることなどが挙げられます。

この場合、特定のワークロードがパフォーマンスのフェアシェアを超えないように注意する必要があります。これは、ファイルシステム上の他のワークロードに影響を与える可能性があり、よく「ノイジーネイバー」と呼ばれます。その他の例として、同じファイルシステム上のクローニングされたワークロードがあり、本番ワークロードは開発環境とテスト環境にクローンされます。開発者がクローンのベースとなる本番ワークロードのパフォーマンスに影響を与えないようにするには、どうすればよいでしょうか。

Amazon FSx for NetApp ONTAP（FSx for ONTAP）は、お客様がクラウド上でフルマネージドの ONTAP ファイルシステムを作成して、実行できるようにするストレージサービスです。FSx for ONTAP には、ファイルシステムを共有するオブジェクトにパフォーマンスの制限を設定できる Quality of Service （QoS）機能が組み込まれているため、各ワークロードに必要なパフォーマンスを確保することができます。QoS により、お客様はマルチワークロードやマルチテナントのファイルシステムを提供しながら、ノイジーネイバーの問題を回避するポリシーを簡単に作成できます。また、競合がない場合でも、ワークロードが一定量以上のリソースを消費しないようにすることもできます。また、QoS はアプリケーションに一貫した予測可能なパフォーマンスを提供し、予測不可能な IO パターンを制限して、サービスプロバイダーがパフォーマンスに関する SLA を提供できるようにします。

このブログでは、QoS の 3 つの具体的なユースケースについて説明します。それぞれのユースケースで、ワークロード、ワークロードがファイルシステムに与える影響、ワークロードに適用された場合の QoS の効果について検証します。また、パフォーマンスへの影響を軽減するために QoS を実装するコマンドを紹介し、お客様のワークロードで使用する方法について説明します。

ユースケース１：ノイジーネイバー

QoS ポリシーを使用すると、特定のワークロードで実行できる IOPS またはスループットの「上限」を設定できます。また、Amazon Elastic Compute Cloud（Amazon EC2）や、Amazon Elastic Block Store （Amazon EBS）のバーストクレジットメカニズムと似ている機能を持つシステムを有効にすることもできます。これにより、ワークロードがベースラインを下回っているときにクレジットを蓄積し、そのクレジットを使用して一時的にバーストリミットを上回って動作することができます。ボリュームや、ファイル、LUN、SVM、qtree にパフォーマンス上限を設定でき、1 つのポリシーに複数のワークロードを追加することができます。以下の図で上限の効果を確認します。

図 1 は、3 つのワークロードの例を示しています。ワークロード 2 は、ファイルシステム全体の利用可能なパフォーマンスを占有しています。これは、ワークロードが最初に実行されたことで優先されたか、または需要が高いことが原因である可能性があります。ワークロード 2 のパフォーマンスニーズにより、ワークロード 1 と ワークロード 3 のパフォーマンスが不足します。

図 1: QoS を設定しないワークロード

図 2 は、ワークロード 2 に対して QoS の上限が設定されており、ファイルシステム全体の利用可能なパフォーマンスを消費しないようにしています。QoS の上限により、ワークロード 2 が追加のリソースが消費していても、ワークロード 1 とワークロード 3 は影響を受けません。

図 2: QoS を設定したワークロード

QoS ポリシーを設定しない FSx for ONTAP のテストセットアップを見てみましょう。FSx for ONTAP ファイルシステムのボリュームを、3 台の Amazon EC2（EC2）インスタンスがそれぞれマウントしています。

図 3: Amazon EC2 インスタンス

以下のコマンドを実行して、3 台のサーバがそれぞれにマウントした個々の 100 GB ボリュームに負荷を発生させることで、図 1 の状況を検証します。

sudo fio --name=fio --filename=/mnt/fsx/fs1/file1 --size=16GB --direct=1 --rw=randrw --bs=4k --ioengine=libaio --iodepth=256 --runtime=120000 --numjobs=2 --time_based --group_reporting --name=IOPS-test-job --eta-newline=1

これにより、各サーバーに 4 KB のブロックサイズでランダムなリード/ライトを行う 2 つのワーカーが作成されます。

図 4: ノイジーネイバーの発生前

上のグラフに示すように、各ワークロードは同じレベルのリクエストを生成しているため、各ワークロードには約 7K IOPS が割り当てられ、すべてのワークロードがフェアに利用できています。ただし、Vol1 に接続されているサーバー 1 で、32 スレッドを作成するように変更することができます。これにより、図 1 のノイジーネイバーの状況が再現され、Vol1 は 16 倍の I/Oリクエストを処理してファイルシステムを独占することになります。

sudo fio --name=fio --filename=/mnt/fsx/fs1/file1 --size=16GB --direct=1 --rw=randrw --bs=4k --ioengine=libaio --iodepth=256 --runtime=120000 --numjobs=32 --time_based --group_reporting --name=IOPS-test-job --eta-newline=1

図 5 は、サーバー 2 と サーバー 3 はそのままで、サーバー 1 が 32 スレッドを作成するように変更した状況を示しています。最初の立ち上がり後、サーバ 2 と サーバー 3 のパフォーマンスが 20:30 頃に大幅に低下していることがわかります。ワークロードのプロファイルは同じですが、サーバ 1 からのノイジーネイバーの影響が発生しています。サーバ 1 がファイルシステムのすべてのパフォーマンスを効率的に奪っているため、サーバ 2 と サーバー 3 はパフォーマンス上の問題を抱えています。

図 5: ノイジネイバーの発生後

ここで、以下の ONTAP CLI コマンドを使用して、これらのワークロードに上限の QoS を適用してみましょう。

qos policy-group create policy1 -vserver svm01 -max-throughput 10000IOPS,300MB/s -is-shared false

この例では、以下を使用して「共有なしグループ」を作成しました。

-is-shared false

つまり、そのポリシーをアタッチしたオブジェクトは個別に制限されます。一方で共有グループを使用する場合は、ポリシーに配置されたすべてのワークロードは、ポリシーで指定されたスループットを共有します（ワークロードが上限を超えないようにするなど）。

以下のコマンドでポリシーの概要を確認することもできます。

qos policy-group show

::> qos policy-group show -policy-group policy1

              Policy Group Name: policy1
                        Vserver: svm01
                           Uuid: 63ab2b0a-bc09-11ec-81f5-abba8ceb7752
             Policy Group Class: user-defined
                Policy Group ID: 1664
             Maximum Throughput: 10000IOPS,300MB/s
             Minimum Throughput: 0
            Number of Workloads: 0
              Throughput Policy: 0-10000IOPS,300MB/s
                      Is Shared: false
       Is Policy Auto Generated: -

上記のコマンドは、最大スループットが 300 MB/秒で、10,000 IOPS が実行でき、共有をしないポリシーを svm01 に作成します。このポリシーは、まだオブジェクトに適用されていません。以下のコマンドを実行してボリュームにポリシーを設定します。この設定は、ファイルや、LUN、 qtree にも適用できます。

volume modify -volume <volumename> -qos-policy-group policy1

このポリシーを削除するには、以下のコマンドを使用してポリシーを none に戻します。

volume modify -volume <volumename> -qos-policy-group none

現在アタッチしているポリシーで、IOPS とスループットを調整することもできます。

qos policy-group modify policy1 -max-throughput 1000IOPS,200MB/s

これをワークロード 1 にアタッチして、IOPS を 1,000 に制限してみましょう。

volume modify -volume vol1 -vserver svm01 -qos-policy-group policy1

以下のコマンドで QoS 統計情報を表示します。

qos statistics volume performance show

図 6 は、Vol1 が 1,000 IOPS に制限されていることがわかります。当初はポリシー 1 を 10,000 IOPS に設定していましたが、その後に modify を使って 1,000 IOPS に下げるよう設定しました。Vol2 と Vol3 は、ノイジーネイバーが発生する前の図 4 に示すように、約 7,000 IOPS に戻りました。

図 6: QoS 統計情報

ポリシーがアタッチされている状態で、modify コマンドで調整してみましょう。

qos policy-group modify policy1 -max-throughput 2000IOPS,200MB/s

数秒以内に影響を確認することができます。

図 7: 増加後の QoS 統計情報

QoS ポリシーを「ノイジーネイバー」ボリュームに 適用することで、ファイルシステムの他のワークロードに影響を与えないようにしました。これにより、必要なパフォーマンスを継続して確保することができます。

ユースケース２：開発ワークロードまたはクローンのワークロード

FSx for ONTAP の便利な機能として、ワークロードのクローン作成があります。NetApp FlexClone を使用することで、本番ワークロードのゼロスペースの効率的なコピーを作成することができ、開発者がテストに利用することができます。しかし、30 人の開発者がそれぞれ新しいクローンを作成する場合（ちなみにクローンは親に設定された制限を継承しません）、それらの組み合わせたテストが本番環境に影響を与えないようにするにはどうすればよいでしょうか。また、特定のオブジェクトグループで使用できる IOPS の総量を制限するにはどうすればよいでしょうか。

当初の共有なしのポリシーを、Vol2 に適用してみましょう。

volume modify -volume vol2 -vserver svm01 -qos-policy-group policy1

図 8: Vol2 に共有なしポリシーを適用した後の QoS 統計情報

Vol1 と Vol2 の両方がそれぞれ 2,000 IOPS を消費できるようになったことが確認できました。この例では、30 人の開発者と、30 個のボリュームがあり、他のワークロードを上回る可能性があります。

既存のポリシーでは共有値を変更できないため、新しいポリシーを作成する必要があります。そして、この新しいポリシーを指すようにボリュームを変更できます。

qos policy-group create policy1-shared -vserver svm01 -max-throughput 3000IOPS,200MB/s -is-shared true
volume modify -volume vol1 -vserver svm01 -qos-policy-group policy1-shared
volume modify -volume vol2 -vserver svm01 -qos-policy-group policy1-shared

図 9: Vol1 と Vol2 に共有ポリシーを適用した後の QoS 統計情報

これにより、Vol1 と Vol2 の両方が 2 つのボリューム間で 3,000 IOPS に共有して制限されました。別のワークロードを配置した場合、IOPS もそのワークロードと共有されます。これにより、グループ内で設定された制限までバーストできるボリュームのグループを作成することができます。これは、グループ内の他のワークロードがそのリソースを使用していない場合や、ワークロードのグループが他のワークロードに影響を与えないように制限できる場合に当てはまります。

ユースケース３：ストレージパフォーマンス階層

従来の多くのストレージアレイには、複数のストレージパフォーマンス階層があります。QoS を利用して、FSx for ONTAP に追加のストレージパフォーマンス階層が作成できます。「なぜそうする必要があるのか」という疑問があるかもしれません。アプリケーションのストレージ要件が変わると、多くの場合はパフォーマンス要件もそれに伴って調整されます。さらに、集中管理されたサービスプロバイダーのモデルで利用する場合、通常、 TB あたりの IOPS の数値を含むストレージ階層を提供します。「競合がないのに、なぜそんなことをするのか」や「リソースにまだ余裕がありそうなのに、なぜ使用しないのか」と思うかもしれません。まずその例として、特定のパフォーマンスプロファイルで特定のクラスのストレージを販売またはクロスチャージする集中管理されたストレージプロバイダーを考えてみましょう。これにより、各階層が指定された性能を確実に提供することができます。別の例としては、新規の追加ワークロードのデプロイが挙げられます。特定階層のパフォーマンスを制限しなければ、最初のワークロードはストレージファイルシステム全体のパフォーマンスを利用することに慣れてしまいます。ワークロードが追加されると競合が発生し、最初のワークロードは、システムの利用が空だったときの元のベースラインを下回ります。

ここまでは、静的の QoS を見てきました。そのため、ワークロードのサイズを増減しても、QoS の値は変わりません。ただし、アダプティブ QoS は、適用されるオブジェクトのサイズに基づいて値を調整します。これは、割り当てられたサイズや使用されたサイズに基づくことができます。アダプティブ QoS では、必要に応じてスループットを制限できるようにするため、最大ブロックサイズも設定します。さらに、アダプティブ QoS は SVM レベルでは適用できませんが、ボリュームや、ファイル、LUN、FlexGroup レベルでは適用することができます。

以下のアダプティブ QoS コマンドを検討する際、ベースラインと、ベースラインを下回ることでボリュームがクレジットを生成した場合に到達できるピーク IOPS を設定します。また、使用するブロックサイズを定義することもできます。これは、IOPS 制限を組み合わせることで、スループットを制限することができます。例えば、クライアントが 64K のブロックサイズを使用していても、ブロックサイズを 4K に設定すると、クライアントは 4K の IO サイズに制限されます。1 TB あたり 1,000 の IOPS 制限を組み合わせると、1,000 IOPS * 4K IO サイズ、つまり、4 MBps のスループットの制限となるわけです。最後に、割り当て済みまたは使用済みのスペースに基づいて IOPS を設定することができます。

qos adaptive-policy-group create -policy-group adaptive-policy2 -vserver svm01 -expected-IOPS 1000 -block-size 4k -expected-IOPS-allocation allocated-space -peak-IOPS 1500 -peak-IOPS-allocation allocated-space

図 10: アダプティブ QoS ポリシー

静的な QoS ポリシーと同様に、アダプティブ QoS ポリシーを割り当てることができます。

volume modify -volume <volumename> -qos-policy-group -qos-adaptive-policy-group adaptive-policy2

このポリシーを削除するには、以下のコマンドを使用してポリシーを none に戻します。

volume modify -volume <volumename> -qos-adaptive-policy-group none

アダプティブ QoS ポリシーができたので、次のコマンドを使用して Vol2 に割り当ててみましょう。

vol modify -vserver svm01 -volume vol2 -qos-adaptive-policy-group adaptive-policy2

アダプティブ QoS ポリシーが有効になるまで、最大で 5 分かかる場合があることに注意してください。ボリュームのサイズは 100 GB で、ピーク IOPS は 1 TB あたり 1,500 であるため、ボリュームは 150 IOPS に制限されます。

図 11: QoS ポリシー：100 GB の Vol2 

Vol2 を 10 TB に変更すると、最大でピークが 150,00 IOPS 、ベースラインが 10,000 IOPS に増加します。これは、Vol1 と Vol3 によって発生する負荷により、ファイルシステムが対応できる範囲を超えています（図 11 を参照）。ただし、それでも 15,000 IOPS を超えることはないことがわかります（QoS ポリシーがアタッチされていない Vol3 とは異なります）。

図 12: QoS ポリシー：10 TB の Vol2

まとめると、FSx for ONTAP の 静的な QoS と、アダプティブ QoS の両方の機能を検証し、IOPS またはスループットに基づくワークロードに適用される上限を適用しました。アダプティブ QoS はワークロードのサイズに基づいて動的に変更されますが、静的な QoS は固定されています。どちらが適しているかは、状況によって異なります。アダプティブ QoS はストレージクラスモデルに適合し、静的な QoS は特定のワークロードがファイルシステムを占有しないようにするのに役立ちます。

まとめ

このブログでは、FSx for ONTAP で QoS を使用するメリットについて説明しました。QoS を使用することで、1 つのファイルシステム上で複数のワークロードをデプロイ、管理しながら、ワークロードに一貫したエクスペリエンスを提供することができます。QoS には多くの使用例がありますが、今回は以下の 3 つの具体例を説明しました。

1. 個々のワークロードが他のワークロードのパフォーマンスの問題を引き起こしている
2. ワークロードのグループの要求できるパフォーマンスを制限して、他のワークロードに影響を与えないようにする（例：テスト/開発、ワークロードの統合）
3. サービスプロバイダーや集中管理するチームが、特定のクラスのストレージをクロスチャージするために使用できる異なるパフォーマンス階層の作成

詳細については、次のユーザーガイドのページを参照してください：FSx for ONTAP

この記事をお読みいただき、ありがとうございます。FSx for ONTAP の詳細については 製品ページを参照してください。

翻訳はプロフェッショナルサービス本部の葉山が担当しました。