[Amazon FSx for NetApp ONTAP] FabricPoolを利用している環境でデータを定期スキャンするシステムを導入する際の対応方法を考えてみた

FabricPoolを利用している環境でデータを定期スキャンするシステムを導入したい

こんにちは、のんピ(@non____97)です。

皆さんはAmazon FSx for NetApp ONTAP(以降FSxN)のFabricPoolを利用している環境に対して、データを定期スキャンするシステムを導入したいなと思ったことはありますか? 私はあります。

FSxNにはFabricPoolと呼ばれるアクセス頻度に基づいてストレージの階層化を行う機能があります。こちらを活用することで、高価 かつ サイズの縮小ができないSSDの物理ストレージ使用量を抑えることが可能です。

世の中にはファイルサーバーをマウントして定期的にスキャンを行う製品があります。(ファイル検索システム、個人情報管理システム、アンチマルウェアソフトなど)

上述のFabricPoolでColdと判定する条件は最後にアクセスされてからの日数です。

そのため、導入したシステムのスキャンにより、毎日のように実際のデータブロックをアクセスするのであれば、FabricPoolによるコスト削減効果は受けづらいと考えます。

このような環境ではどのような対応方法が考えられるでしょうか。整理してみたので紹介します。

いきなりまとめ

• ボリューム内のデータを定期スキャンするシステムとFabricPoolの相性は悪い
• 回避策はいくつかある
  1. スキャン間隔 > FabricPoolのCooling daysとなるように、Tiering Policyを設定
  2. SnapMirrorの転送先に対してスキャン
  3. 定期的にTiering Policyを「全てキャパシティプールストレージに階層化するポリシーAll」と「最終アクセス日に基づいて階層化するポリシーAuto」とを切り替える
• 各パターンごとに考慮事項がある
• 優先度はパターン1 > パターン2 > パターン3で考えると良い
• 定期スキャンするシステムを導入する場合は以下を考慮するべき
  • スキャン方式
  • スキャン頻度
  • FabricPoolでColdデータとして判定する最終アクセス日からの日数
  • パフォーマンスへの影響

対応パターンの整理

概要

考えられる対応パターンは以下の3つです。

1. スキャン間隔 > FabricPoolのCooling daysとなるように、Tiering Policyを設定
2. SnapMirrorの転送先に対してスキャン
3. 定期的にTiering Policyを「全てキャパシティプールストレージに階層化するポリシーAll」と「最終アクセス日に基づいて階層化するポリシーAuto」とを切り替える

「1. スキャン間隔 > FabricPoolのCooling daysとなるように、Tiering Policyを設定」は、スキャン間隔が十分に空いているのであれば、その間に階層化してしまおうという発想です。

スキャン間隔とTiering PolicyのCooling daysを調整するだけとお手軽で非常に簡単です。

「2. SnapMirrorの転送先に対してスキャン」は、バックアップやDR用途で使用しているSnapMirrorを有効活用しようという発想です。

SnapMirrorの転送先に対してスキャンをするので、本番のFSxNのパフォーマンス影響は少ないでしょう。

「3. 定期的にTiering Policyを「全てキャパシティプールストレージに階層化するポリシーAll」と「最終アクセス日に基づいて階層化するポリシーAuto」とを切り替える」は、頻繁にスキャンされてしまうなら強制的に階層化をしてしまおうという発想です。

SSDのプロビジョニングサイズを極力抑えたい場合に使えそうです。

それぞれ懸念点は以下のとおりです。

パターン1の懸念点

パターン1の懸念点は以下のとおりです。

1. スキャンをした際にONTAPがシーケンシャルリードと判定することが前提
2. キャパシティプールストレージ上のデータの読み取りリクエストをする際の課金が高額になる可能性がある
3. キャパシティプールストレージ上のデータのスキャンに時間がかかる可能性がある
4. Tiering PolicyがAutoやSnapshot Onlyの場合、aggregateの使用率が50%を超過しなければ、階層化されない

「1. スキャンをした際にONTAPがシーケンシャルリードと判定することが前提」から説明します。

「SSDからキャパシティプールストレージに書き込まれたデータは以降、キャパシティプールストレージから移動しない」という訳ではありません。アクセス方法とTiering Policy、Cloud Retrieval Policyに応じて書き戻されます。Tiering PolicyごとのデフォルトのSSDへ書き戻す条件は以下のように異なります。

抜粋 : About FabricPool tiering policies

たとえば、Tiering PolicyがAutoの場合、ONTAPがスキャン処理をランダムリードと判定してしまった場合は、SSDに書き戻されてしまいます。

Cloud retrieval policyをneverに設定して、一度キャパシティプールストレージに階層化されたデータはSSDに書き戻さないという設定も可能です。

抜粋 : About FabricPool tiering policies

ただし、このような設定を組み込んでしまうと、キャパシティプールストレージ階層化後に高頻度アクセスが求められた場合に、パフォーマンスに影響が出ると考えます。

そのため、スキャンはシーケンシャルリードであることが望ましいです。

なお、Tiering PolicyがSnapshot Onlyの場合はあまり関係ないと思います。こちらのTiering PolicyはSnapshot上しか存在しないデータブロック = アクティブファイルシステム(AFS)上には存在しないファイルなので、スキャンをかけてもキャパシティプールストレージに階層化されたデータブロックはスキャン対象外になると思います。

続いて、「2. キャパシティプールストレージ上のデータの読み取りリクエストをする際の課金が高額になる可能性がある」です。

キャパシティープールストレージ上のデータを読み書きする際には、リクエストに応じて課金が発生します。

キャパシティープールの読み取りリクエストの課金は0.0004 USD/1,000 requestです。もし、キャパシティプールストレージ上の全てのデータブロックにアクセスするのであれば、それなりの読み取りリクエスト数があるのではと推測します。

スキャン時にどの程度の読み取りリクエストが発生するかは要検証ですが、注意すべき点として把握しておくと良いでしょう。

ちなみに、FSxNにはインメモリキャッシュやNVMeキャッシュなどキャッシュの仕組みはあります。キャッシュに残っているのであればキャパシティプールストレージから読み込むのではなくキャッシュから返すため、読み取りリクエストのコストを抑えることができます。

抜粋 : Amazon FSx for NetApp ONTAP のパフォーマンス - FSx for ONTAP

ただし、スキャンの量によっては全てのキャッシュを追い出してしまう可能性が考えられます。キャッシュとスキャンの相性は悪いので、このシチュエーションにおいてはキャッシュの効果は期待はしない方が良いと考えます。

次に、「3. キャパシティプールストレージ上のデータのスキャンに時間がかかる可能性がある」です。

キャパシティプールストレージはオブジェクトストレージベースです。そのため、SSDと比較するとどうしてもパフォーマンスは出ません。スキャン完了時間のリミットがあるのであれば、Tiering Policyを調整しましょう。

最後に、「4. Tiering PolicyがAutoやSnapshot Onlyの場合、aggregateの使用率が50%を超過しなければ、階層化されない」です。

こちらは懸念点というよりかは留意事項です。

Tiering PolicyがAutoやSnapshot Onlyの場合、Coldと判定されてもすぐには階層化されません。aggregateの使用率(≒SSDの物理使用率)が50%を超過しなければ階層化されません。

ストレージ容量を超えないようにしてください FSx for ONTAP の階層化機能は、階層化の開始と停止時にトリガーされる特定のしきい値を維持します。これらのしきい値は、プライマリストレージ階層の使用済み容量を基準としています。

注:プライマリストレージ階層のストレージ容量使用率が 80% を超えないようにすることをお勧めします。階層化が正しく機能し、新しいデータを保存する余地があることを確認するには、ストレージ容量を 80% 以下に維持してください。プライマリストレージ階層のストレージ容量使用率が常に 80% を超えている場合は、ファイルシステムの SSD ストレージ容量を更新してください。

以下のガイドラインでは、さまざまな使用シナリオにおける階層化の処理方法について説明しています。

• プライマリストレージ階層の使用率が 50% 以下: 全階層化ポリシーが適用されたボリュームのみが、容量プールストレージにデータが階層化されます。自動階層化ポリシーとスナップショット専用ポリシーでは、プライマリストレージ階層が十分に活用されていない場合は階層化が不要になるため、データを階層化しません。
• プライマリストレージ階層の使用率が 50% を超える: 自動階層化ポリシーとスナップショット専用ポリシーでは、階層化の最小冷却日数の設定に基づいてデータが階層化されます。デフォルトの階層化最小冷却日数は 31 日です。
• プライマリストレージ階層の使用率が 90% 以上: キャパシティプール階層からのコールドデータは、読み取り時に自動階層化ポリシーおよびスナップショット専用ポリシーのためにプライマリストレージ階層に移動されなくなりました。キャパシティプール階層にデータを保持すると、プライマリストレージ階層のスペースを節約できます。
• プライマリストレージ階層の使用率が 98% 以上: プライマリストレージ階層の使用率が 98% 以上になると、すべての階層化機能が停止します。

FSx for ONTAP のストレージデータ階層化ポリシーを変更する | AWS re:Post

要するに「SSDに余裕がある場合は、読み書きリクエストに課金が発生するキャパシティプールストレージに無理に階層化しない」という思想です。

「階層化がされない!」という場合はSSDの物理使用率を確認しましょう。

パターン2の懸念点

パターン2の懸念点は以下のとおりです。

1. SnapMirrorの転送先とスキャンシステムが別リージョンや別AZである場合、リージョン間やAZ間の転送料金が高額になる可能性がある
2. スキャン結果を元にファイルを移動させたり、暗号化したりなど書き込みを伴う機能は使用できない
3. キャパシティプールストレージ上のデータの読み取りリクエストをする際の課金が高額になる可能性がある
4. キャパシティプールストレージ上のデータのスキャンに時間がかかる可能性がある

まず、「1. SnapMirrorの転送先とスキャンシステムが別リージョンや別AZである場合、リージョン間やAZ間の転送料金が高額になる可能性がある」です。

SnapMirrorの転送先は通常使っているAZやリージョンと異なる場所であることが多いと思います。AZやリージョンを跨いで通信する場合は転送量に基づいて課金が発生します。また、Transit Gatewayで接続するのであれば、Transit Gatewayのデータ処理料金についての課金も発生します。それぞれの料金をまとめると以下のとおりです。

参考 :

• オンデマンドインスタンスの料金 - Amazon EC2 (仮想サーバー) | AWS
• 料金 - AWS Transit Gateway | AWS

どのぐらいの課金が発生するかはスキャン方式と、スキャン頻度、スキャン対象のデータ量に大きく依存します。あらかじめコスト試算することをお勧めします。場合によってはスキャンサーバーをSnapMirrorの転送先と同じAZに構築するのも手です。

次に「2. スキャン結果を元にファイルを移動させたり、暗号化したりなど書き込みを伴う機能は使用できない」です。

SnapMirrorの転送先ボリュームは読み取り専用です。ファイルの中身を書き換えたり、ファイルを別ディレクトリに移動させたりすることはできません。

そのため、スキャン結果を元にファイルを移動させたり、暗号化したりなど書き込みを伴う機能は使用できません。

スキャン結果を元に通知を行うというのは可能だとは思います。ただし、スキャン対象がSnapMirrorでレプリケーションされたボリュームなので、DNS名、ジャンクションパス、ファイル共有名が異なる可能性があります。通知を受け取った場合は、「SnapMirrorの転送元上で指しているファイルは何なのか」を整理する必要があります。

3つ目と4つ目の懸念点はパターン1のものと同様なので省略します。

パターン3の懸念点

1. キャパシティプールストレージ上では追加の重複排除が効かないため、物理ストレージ消費量増大に繋がる
2. 頻繁にアクセスするデータについてはパフォーマンスに影響が出る可能性がある
3. スキャンをした際にONTAPがシーケンシャルリードと判定することが前提
4. キャパシティプールストレージ上のデータの読み取りリクエストをする際の課金が高額になる可能性がある
5. キャパシティプールストレージ上のデータのスキャンに時間がかかる可能性がある

まず、「1. キャパシティプールストレージ上では追加の重複排除が効かないため、物理ストレージ消費量増大に繋がる」です。

以下記事で紹介しているとおり、キャパシティプールストレージ上では追加の重複排除は効きません。

Tiering PolicyをAllに切り替える間隔が短いと、ポストプロセス重複排除が実行される前に階層化されてしまいます。結果としてキャパシティプールストレージの物理使用量増大に繋がり、コストも増加してしまいます。

ポストプロセス重複排除の実行状況やTSSEの説明は以下記事をご覧ください。

次に、「2. 頻繁にアクセスするデータについてはパフォーマンスに影響が出る可能性がある」です。

この対応パターンはアクセス頻度に関係なく、問答無用でキャパシティプールストレージに階層化するものです。

キャパシティプールストレージは先述のとおり、オブジェクトストレージベースです。SSDよりかはパフォーマンスは出ません。頻繁にアクセスされるデータブロックも一度キャパシティプールストレージに階層化されてしまうため、パフォーマンス影響が出ると考えます。

3つ目と4つ目、5つ目の懸念点はパターン1のものと同様なので省略します。

対応パターンの決定方法

対応パターンを決めるにあたってインプットとなる要素は以下の3点です。

1. スキャン方式
   • 「常に全データブロックをスキャン」、「2回目以降はメタデータで差分があったファイルの全データブロックのみスキャン」など
2. スキャン頻度
   • 「週一」や「毎日」など
   • フルスキャンと簡易スキャンがあるのであれば、それぞの実行頻度を整理
3. FabricPoolでColdデータとして判定する最終アクセス日からの日数
   • どの程度アクセスされないデータブロックはキャパシティプールストレージに階層化しても良いか

特にスキャン方式は重要です。FSxNのメタデータは常にSSDに保存されています。スキャン対象がメタデータのみで実データブロックをスキャンしないのであれば、Coldと判定され階層化してくれます。

それぞれのインプットとの組み合わせ別に取りうるパターンは以下のとおりです。パターン1 > パターン2 > パターン3の優先度で考えると良いでしょう。

組み合わせ4と5、6の時にパターン1を選択するのが最もパフォーマンス、コスト効率が良いです。

変更量次第ではありますが、更新があった箇所だけスキャンするのでデータブロックがキャパシティプールストレージにあったとしても、読み取りリクエストにかかるコストは低いと考えます。

仮に頻繁に更新されてキャパシティプールストレージの読み取りリクエストが嵩んでいるのであれば、Cooling daysを長めに変更すると良いと考えます。

逆に最もパフォーマンスとコスト効率が悪いのは組み合わせ3です。

このような要求がある場合は、FabricPoolとの相性は悪いでしょう。SSDのプロビジョニングサイズを抑えるという目的は達成できるとは思います。しかし、その分パフォーマンスに悪影響が出たり、むしろキャパシティプールストレージの読み取りコストが嵩んでしまう可能性も十分考えられます。

ファイルサーバーをスキャンするような製品を導入する場合は、FabricPoolとの相性も加味して製品選定をすると良いでしょう。

製品導入の際にはFabricPoolへの愛称以外にも、その製品を導入した場合のパフォーマンス影響や、付与する必要がある権限、可用性なども考慮しましょう。

EventBridge SchedulerとStep Functionsを使って特定のボリュームのTiering Policyを定期的に切り替えてみた

検証環境

パターン1はTiering Policyの設定のみ、パターン2はSnapMirrorの転送先をスキャンするだけと導入は非常に簡単です。

パターン3だけ仕組みの導入が大掛かりなので、実際にやってみます。

検証環境は以下のとおりです。

定期的に指定したタグが付与されたFSxNのボリュームのTiering Policyを切り替えます。

スケジューリングはEventBridge Schedulerで、対象ボリュームの抽出とTiering Policyの切り替え処理はStep Functionsで行なっています。

ステートマシンのワークフローを図示すると以下のとおりです。

デプロイ

特定のボリュームのTiering Policyを定期的に切り替える仕組みはAWS CDKでデプロイします。使用したコードは以下リポジトリに保存しています。

今回は5分間隔でTiering PolicyをAllとAutoと切り替えるように設定します。

./parameter/index.ts

export const switchTieringPolicySchedulerStackProperty: SwitchTieringPolicySchedulerStackProperty =
  {
    env: {
      account: process.env.CDK_DEFAULT_ACCOUNT,
      region: process.env.CDK_DEFAULT_REGION,
    },
    props: {
      targetVolumeIds: ["fsvol-03e71e794717763bc", "fsvol-0f00406c5736b6cb8"],
      toTieringPolicies: [
        {
          tieringPolicy: {
            name: "ALL",
          },
          scheduleExpression: "cron(5/10 * * * ? *)",
          scheduleExpressionTimezone: "Asia/Tokyo",
        },
        {
          tieringPolicy: {
            name: "AUTO",
            coolingPeriod: 5,
          },
          scheduleExpression: "cron(0/10 * * * ? *)",
          scheduleExpressionTimezone: "Asia/Tokyo",
        },
      ],
    },
  };

デフォルトでは以下のように全てのボリュームのTiering PolicyがNoneです。

npx cdk deployで各種リソースをデプロイします。

デプロイしてしばらくすると、指定したボリュームのTiering PolicyがAllとなりました。

また、5分待つと指定したボリュームのTiering Policyが全てAutoとなりました。

Cooling daysも指定した5日が設定されています。

問題なく動作していますね。

なお、実際の切り替え間隔は数時間などある程度の余裕を持たせておくと良いと考えます。時間が短すぎるとキャパシティプールストレージにデータが階層化され切れないことが予想されます。短期的には問題ないかもしれないですが、長期的に見るとSSDの使用量が増加し、SSDの枯渇に繋がると考えます。

ボリューム内のデータを定期スキャンするシステムを導入する場合は影響範囲を理解しよう

Amazon FSx for NetApp ONTAPでFabricPoolを利用している環境でデータを定期スキャンするシステムを導入する際の対応方法を考えてみました。

ボリューム内のデータを定期スキャンするシステムを導入する場合は影響範囲を理解した上で行う必要があります。把握せずに導入してしまうと、パフォーマンスやコスト効率が悪くなることが考えられます。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!