Amazon FSx for NetApp ONTAPとAmazon fSx for Windows File Serverの使い分けを整理してみた
2025.02.09「Windows Serverのファイルサーバーから移行するから」という理由のみでAmazon FSx for Windows File Serverを選択するのはもったいない
こんにちは、のんピ(@non____97)です。
皆さんはSMBのファイルサーバーを導入する際に、Amazon FSx for NetApp ONTAP(以降FSxN)にするか、Amazon FSx for Windows File Server(FSxW)にするのか悩んだことはありますか? 私はあります。
ファイルサーバーの移行の場合、移行元がWindows Serverであることは多いでしょう。
その場合、ついつい「Windows Serverのファイルサーバーから移行するからFSxWを選択する」としてしまいがちです。
しかし、個人的にはその選択は非常にもったいないと思います。
どちらのサービスを利用するか選択する際には以下資料が非常に参考になります。
これらの資料で紹介されているように、「Windowsだから」だけではなく、機能やコストを鑑みて選択するべきです。
今まで触っている中で、どのような場面でどちらのサービスを採用するのかの感覚が分かってきたので紹介します。
いきなりまとめ
- ざっくり以下のような使い分け
- FSxW : 小規模〜中規模 or 超高パフォーマンスで使用するファイルサーバー
- FSxN : 中規模〜大規模で利用するエンタープライズなストレージ
- 金銭的コストと運用にかかる人的コスト、要件に対する機能的な充足度合いを鑑みて決定しよう
- 求められる要件と、その重要度の整理
- その要件を満たすための構成を採用した場合の、ランニングコストの見積もり
- 運用体制的にオーバースペックではないか、学習コストをかけるほどのメリットを享受できるか
基本的な考え方
こんな時はAmazon FSx for Windows File Serverを使う
概要
まず、FSxWを採用する場面です。
一覧をまとめると以下のとおりです。
- SSDで求められるストレージサイズが1TiB弱未満
- HDDで十分であり、求められるストレージサイズが10TB未満
- FSxNの上限以上のパフォーマンスが求められる
- Multi-AZ構成とし、別ネットワークからアクセスさせたい場合にTransit GatewayやResource型VPCエンドポイントの用意が難しい
- クロスリージョンのバックアップを手間をかけず、低コストで転送したい
- NASアクセスの監査ログをCloudWatch LogsやData Firehoseで出力したい
- 連携するサービスがFSxNをサポートしていない場合
- 設計範囲を極力狭くしたい、学習コストを抑えたい
要するに「小規模〜中規模 or 超高パフォーマンスで使用するファイルサーバー」として使用します。
以降、それぞれについて説明します。
SSDで求められるストレージサイズが1TiB弱未満
FSxWのミニマムのSSDサイズは32GiBです。
一方、FSxWのミニマムのSSDサイズは1TiBです。
FSxWとFSxNどちらもプロビジョニングされたSSDのサイズによって課金が発生します。
2025/2/9時点の東京リージョンの場合のストレージサイズに関わる料金は以下のとおりです。大きな差はありません。
| 項目 | SSD 料金 | HDD or キャパシティプールストレージ料金 | バックアップ料金 |
|---|---|---|---|
| Single-AZ FSxW | 0.156 USD/GB | 0.016 USD/GB | 0.05 USD/GB |
| Single-AZ FSXN | 0.15 USD/GB | 0.0238 USD/GB | 0.05 USD/GB |
| Multi-AZ FSxW | 0.276 USD/GB | 0.03 USD/GB | 0.05 USD/GB |
| Multi-AZ FSxN | 0.30 USD/GB | 0.0476 USD/GB | 0.05 USD/GB |
参考 :
FSxNには後述するFabricPoolによる階層化や、より高性能な重複排除・圧縮処理があり、求められるストレージサイズに対して実際にプロビジョニングが必要なSSDのサイズが大きく減る傾向があります。
しかし、それを持ってしても、求められるストレージサイズが1TiB弱程度までであれば、FSxWの方が料金的には安くなるでしょう。
料金の安さが最優先の場合はFSxWを選択すると良いでしょう。
HDDで十分であり、求められるストレージサイズが10TB未満
FSxWではHDDを選択することが可能です。
FSxNでは2025/2/9時点ではHDDを採用することはできません。
もし、性能的にHDDで十分である場合、FSxWの方が料金的に安くなるでしょう。
料金の安さが最優先の場合はFSxWを選択すると良いでしょう。
しかし、以下記事で紹介しているとおり、求められるストレージサイズが10TiBを超えてくると、FSxNの方がコストが安くなってきます。
これはFSxNのFabricPoolによる階層化、および重複排除・圧縮の効果によってストレージに対するコストを抑えることができるためです。
また、スループットキャパシティの単価はFSxNの方が安いです。
FSxNの上限以上のパフォーマンスが求められる
2025/2/9時点の東京リージョンFSxNのスループットキャパシティの上限は2,048MBpsです。
一方、FSxWの場合は12,288MBpsです。
後述しますが、スループットキャパシティの料金はFSxNの方が1/2〜1/3程度安価です。
コストがかかってもFSxN以上の高スループット、高IOPSを単一のFSxWファイルシステムで達成させたい場合はFSxWを採用すると良いでしょう。
Multi-AZ構成とし、別ネットワークからアクセスさせたい場合にTransit GatewayやResource型VPCエンドポイントの用意が難しい
FSxNでMulti-AZ構成を採用する場合、別ネットワークからアクセスさせるにはTransit GatewayやResource型VPCエンドポイントが必要になります。
要件として「AZ障害時の業務継続」がある場合、「Direct Connect経由でアクセスさせたいがTransit VIFの用意が難しい」であったり、「Transit GatewayもResource型VPCエンドポイントも料金的に採用が難しい」といった際にはFSxWの方がマッチするかもしれません。
クロスリージョンのバックアップを手間をかけず、低コストで転送したい
2025/2/9時点ではFSxNではFSxの機能で取得されたボリュームバックアップをクロスリージョンで転送することができません。
| AWS Backup サポート | リージョン間のバックアップ | アカウント間のバックアップ | AWS Backup Audit Manager | 増分バックアップ | 継続的バックアップとポイントインタイムリストア | 完全な管理 | コールドストレージのライフサイクル | 項目レベルの復元 | 復元テスト | 論理エアギャップボールト |
|---|---|---|---|---|---|---|---|---|---|---|
| Amazon EC2 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||||
| Amazon S3 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| Amazon EBS | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||
| Amazon RDS インスタンス | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||||
| Amazon RDS クラスター | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| Amazon Aurora | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||
| Amazon EFS | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| FSx for Lustre | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| FSx for Windows File Server | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| FSx for ONTAP | ✓ | ✓ | ✓ | |||||||
| FSx for OpenZFS | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| AWS Storage Gateway | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| Amazon DocumentDB | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| Amazon Neptune | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| Amazon Redshift | ✓ | |||||||||
| Timestream | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||
| Windows VSS | ✓ | ✓ | ✓ | ✓ | ||||||
| Virtual Machine | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||
| AWS CloudFormation テンプレート | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||||
| Amazon DynamoDB | ✓ | ✓ | ||||||||
| AWS Backup 高度な機能ありの DynamoDB | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||
| Amazon EC2 インスタンスでの SAP HANA データベース | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
参考 : AWS Backup 機能の可用性 - AWS Backup
クロスリージョンでバックアップを転送する場合はSnapMirrorを用いて、Snapshotを転送する必要があります。
SnapMirrorを行うには転送先のFSxNファイルシステムを用意する必要があります。その分、どうしても設計導入および、ランニングコストがかかります。
SnapMirrorの方がRPO/RTOを短くすることはできるのですが、運用コストや金銭的ランニングコストを優先するのであれば、FSxWの方が良いでしょう。
参考までにAWS BackupとSnapMirrorの使い分けは以下のとおりです。
NASアクセスの監査ログをCloudWatch LogsやData Firehoseで出力したい
FSxWではNASアクセスの監査ログをCloudWatch LogsもしくはData Firehoseに出力させることが可能です。
一方、FSxNでは2025/2/9時点ではそのような機能は存在していません。NASアクセスの監査ログはFSxNのボリューム内にXML形式、もしくはEVTX形式で出力されます。
もし、監査ログを手軽にリアルタイムでログ監視する必要がある場合はFSxWを選択することになるでしょう。
FSxNの場合は手組みや3rdパーティ製品に頼ることになります。
連携するサービスがFSxNをサポートしていない場合
連携するAWSサービスや3rdパーティ製品がFSxNをサポートしていない場合もあります。
そんな時はFSxWを採用することになります。
よくあるのはFSxNのONTAPバージョンをユーザーがコントロールできず、自動でバージョンアップされてしまうところに起因するものです。
設計範囲を極力狭くしたい、学習コストを抑えたい
FSxNはONTAPという商用のストレージOSをマネージドサービスとして提供しており、設計/設定できる範囲が非常に広いです。
ONTAP CLIやONTAP REST APIなどで設定する箇所については、AWS公式ドキュメントに記載されていない内容も多くあり、自身でNetApp公式ドキュメントを参考にしながら対応をする場面の方が多いです。
私がFSxNネタだけで150本程度ブログを投稿できるぐらいには奥が深いです。
どうしてもONTAPに慣れていない方にはハードルが高いと思います。
FSxWについてはマネジメントコンソールとPowerShell Amazon FSx CLIでほとんど操作が可能です。
PowerShell Amazon FSx CLIについては以下記事をご覧ください。ONTAP CLIと比較すると、非常に設定できる範囲は狭いです。
「ONTAPは明らかにオーバースペックだ。設計範囲を極力狭くし、学習コストを抑えたい。」といった場合はFSxWを採用すると良いでしょう。
ちなみに、2024/11/27時点のデフォルトのONTAPロールの詳細な権限については以下GitHubリポジトリで管理しています。興味ある方は覗いてみてください。
こんな時はAmazon FSx for NetApp ONTAPを使う
概要
続いて、FSxNを採用する場面を紹介します。
一覧をまとめると以下のとおりです。
- 元々ONTAPを使用している
- ストレージサイズが1TB以上欲しいが、全てのデータにアクセスする訳ではない
- 書き込み速度を犠牲にせずにストレージの料金を抑えたい
- 重複排除率や圧縮率を向上させたい
- 求められるスループットが64MBps以上
- Single-AZでもメンテナンス時のダウンタイムを抑えたい
- ディレクトリ単位のストレージクォータを設定したい
- シャドウコピーが意図せず削除されるのを回避したい
- Snapshotから高速にリストアしたい
- 手間をかけず厳密に特定時点にリストアしたい
- バックアップだけでなく、アクティブファイルシステムやSnapshotに対してWORM機能が必要
- ノイジーネイバー対策としてQoSを設定したい
- クロスリージョンなDR環境において、厳格なRTO/RPO要件を少ない運用負荷で実現する必要がある
- キャッシュが効きやすいワークロード
- DFSを使わずに数百TBスケールのデータを保存したい
- NFSにも対応したい
- AWSのAPIでサポートされていない処理をPowerShellではなく、REST APIやそのラッパー経由で操作したい
- アンチマルウェアソフトを動作させたい
- 管理アクティビティの監査ログを保存したい
- オンプレミスなど別ネットワークからのアクセス時のレイテンシーが気になるのでキャッシュを配置したい
- Security Groupとは別に送信元IPアドレスや認証方法でアクセス許可を行いたい
- atimeをベースに何か処理をさせたい
- ADを用意せずにワークグループのSMBのファイルサーバーを提供したい
- 複製した環境を手間をかけず、短時間で用意したい
要するに「 中規模〜大規模で利用するエンタープライズなストレージ」として使用します。
以降、それぞれについて説明します。
元々ONTAPを使用している
元々ONTAPを採用しているのであれば、FSxN採用のハードルは高くないでしょう。
一部コマンドを使用できなかったり、System Managerで操作するにはBlue XPが必要だったりと運用面での使い勝手は変わってしまうことはありますが、ベースの知識を使いまわせるのは運用メリットとして大きいと考えます。
移行の際にはSnapMirrorを使えば短期間で簡単にデータを転送することが可能です。(送信元と送信先のONTAPバージョンの差異には注意)
逆に、元々ONTAPを使用していたところでFSxWを採用すると、機能不足に悩まされるでしょう。
ストレージサイズが1TB以上欲しいが、全てのデータにアクセスする訳ではない
FSxNではFabricPoolという階層化の機能があります。
これによって、一定期間参照されていないデータブロックを安価なキャパシティプールストレージに階層化をすることができます。これによってプロビジョニングするSSDのサイズを抑えることが可能です。
FSxWはSSDかHDDかのどちらかを選択する形になります。同様の階層化の機能はありません。
そのため、「一定期間アクセスがない場合は安価なストレージに移す」という処理は手組みするか、NIASなど3rdパーティ製品を導入する必要があります。
数TBある全てのデータに常に高速なスループット、IOPSを提供する場面は少ないと思います。
その場合、FSxNの方がコストを抑えられるでしょう。
書き込み速度を犠牲にせずにストレージの料金を抑えたい
FSxNではキャパシティプールストレージにデータを保存するように設定する(Tiering PolicyがAll)の場合であっても、SMBで操作する場合はデータを必ずSSDを経由します。
(NFSの場合はcloud write modeを有効化することで、キャパシティプールストレージに書き込むことも可能です)
そのため、書き込み性能はSSDの恩恵を受けることが可能です。
先述のとおり、FSxWの場合はSSDかHDDかのどちらかを選択する必要があります。コスト削減のため、HDDを選択すると、トレードオフとして書き込み性能が低下してしまいます。
書き込み性能を犠牲にせず、ストレージの料金を抑えたいのであれば、階層化機能があるFSxNを選択すると良いでしょう。
重複排除率や圧縮率を向上させたい
FSxNではStorage Efficiencyという機能によって、重複排除や圧縮、データコンパクションが行われます。
詳細は以下記事をご覧ください。
FSxWにも重複排除と圧縮の機能があります。
FSxWの重複排除と圧縮は定期的にファイルをチャンク単位で分割して重複排除をし、圧縮するという方式です。
FSxNの場合は4KB単位でインラインおよびポストで重複排除の判定を行い、8KB or 32KB単位で圧縮を行います。
4KB未満の複数のデータを1つのブロックにまとめるデータコンパクションという機能もFSxNのみになります。
データ削減処理を実行するタイミングや粒度が細かく、実施する種類も多いことからFSxNの方がデータ削減量は多くなりやすいです。
結果として、プロビジョニングするSSDのサイズが小さくなり、コスト削減につながります。
なお、FSxWのHDD場合、IOPSが足りず重複排除や圧縮の処理に失敗することがあります。HDDの場合は重複排除を有効化しないことをお勧めします。
求められるスループットが64MBps以上
先述のとおり、スループットキャパシティの単価はFSxNの方が安いです。
具体的には2025/2/9時点の東京リージョンの料金は以下のとおりです。
| 項目 | スループットキャパシティ料金 |
|---|---|
| Single-AZ FSxW | 2.53 USD/MBps |
| Single-AZ FSXN | 0.906 USD/MBps |
| Multi-AZ FSxW | 5.175 USD/MBps |
| Multi-AZ FSxN | 1.511 USD/MBps |
参考 :
Single-AZの場合は2.8倍、Multi-AZの場合に至っては3.4倍FSxWの方が高いです。
FSxWのミニマムのスループットキャパシティは32MBpsで、FSxNのミニマムのスループットキャパシティは128MBpsです。
FSxWのスループットキャパシティが64MBps以上の場合、FSxNのスループットキャパシティが128MBpであったとしても、スループットキャパシティの料金はFSxNの方が安くなります。
ストレージサイズはほどほどで、求められる性能が高い場合はFSxNを選択した方が安くなるでしょう。
Single-AZでもメンテナンス時のダウンタイムを抑えたい
FSxNはSingle-AZでも2つのノードが存在しています。
これにより、単一ノード障害や、メンテナンス時のダウンタイムが短くなります。
FSxWの場合Single-AZでデプロイすると、メンテナンス時に数十分使えないことが想定されます。
パッチの適用中は、シングル AZ ファイルシステムが使用できなくなります (通常 20 分間未満)。
FSx Windows ファイルシステムの の管理 - Amazon FSx for Windows File Server
Multi-AZにするまででもないけれども、単一ノード障害やメンテナンス時のダウンタイムの影響を抑えたいという場合は、FSxNを採用すると良いでしょう。
Multi-AZにするかSingle-AZにするかの判断ポイントは以下記事でまとめています。
なお、メンテナンスウィンドウはメンテナンスを開始する時間枠を指しており、メンテナンス開始から完了までの時間枠を指していません。30分の枠を指定する = メンテナンスが30分以内に開始するという訳ではないので注意してください。詳細は以下記事をご覧ください。
ディレクトリ単位のストレージクォータを設定したい
FSxNではディレクトリ単位のストレージクォータを設定することが可能です。
そのため、部門ごとにディレクトリを分割して、それぞれに異なるサイズを割り当てることが可能です。
FSxWではユーザー単位のストレージクォータしかかけることはできません。
要件として、ディレクトリ単位のストレージクォータを設定する場合はFSxNを採用することになります。
もし、ソフトクォータで良いのであれば、NIASなど3rdパーティ製品を導入する必要があります。
シャドウコピーが意図せず削除されるのを回避したい
FSxWではシャドウコピーが削除されることがあります。
シャドウコピーが削除されるシチュエーションは以下AWS公式ドキュメントにまとまっています。
最も古いシャドウコピーは、次のいずれかの状況で削除されます。
- 500 個のシャドウコピーがある場合、シャドウコピーに割り当てられている残りのストレージボリュームスペースに関係なく、次のシャドウコピーが最も古いシャドウコピーを置き換えます。
- 設定されているシャドウコピーの最大ストレージ量に達すると、シャドウコピーが 500 未満であっても、次のシャドウコピーが 1 つ以上の最も古いシャドウコピーを置き換えます。
どちらの結果も予想される動作です。シャドウコピーに割り当てられたストレージが不十分な場合は、割り当てたストレージを増やすことを検討してください。
すべてのシャドウコピーが欠落している
ファイルシステムに十分な I/O パフォーマンスキャパシティがない (ストレージを使用している、HDDストレージHDDのバーストキャパシティが不足している、スループットキャパシティが不足しているなど) と、使用可能な I/O パフォーマンスキャパシティでシャドウコピーを維持できないため、Windows Server によってすべてのシャドウコピーが削除される可能性があります。この問題を防ぐために、次のレコメンデーションを検討してください。
- HDD ストレージを使用している場合は、Amazon FSxコンソールまたは Amazon FSx API を使用してSSDストレージの使用に切り替えます。詳細については、「ファイルシステムのストレージタイプの管理」を参照してください。
- ファイルシステムのスループットキャパシティを、予想されるワークロードの 3 倍の値に増やします。
- 設定されているシャドウコピーの最大ストレージ容量に加えて、ファイルシステムに少なくとも 320 MB の空き容量があることを確認してください。
- ファイルシステムがアイドル状態になると予想される場合は、シャドウコピーをスケジュールします。
実際に私も何回かシャドウコピーが削除された場面に出くわした経験があります。
ファイルサーバーの利用部門と「定期的に取得されるシャドウコピーをx日分保持し、ユーザー自身でリストアすることができる」と合意している場合、合意している内容を満たせないことがあります。
今までの経験上、FSxNのSnapshot機能とはそのような場面に遭遇したことはありません。300TBほどのファイルサーバーであっても問題なく動作しています。
ユーザーとシャドウコピーについて強い合意をし、シャドウコピーが意図せず削除されるのを回避したいのであれば、FSxNを採用するのが安心と考えます。
なお、ONTAPでもSnapshotの自動削除機能を使用すると、ボリュームの使用率が超過したタイミングでSnapshotを削除します。
あまり使う場面はないと思いますが、有効化している場合は注意しましょう。
Snapshotから高速にリストアしたい
FSxNではSnapshotから高速にリストアをすることが可能です。
これはSnapshotで保持している実データにポインタに振り向ける形で行い、実データブロックへの大量の書き込みが不要であるためです。
エクスプローラーで以前のバージョンでリストアからリストアする場合、SnapRestoreと比較すると、どうしてもリストア速度は低下します。
手間をかけず厳密に特定時点にリストアしたい
以前のバージョンでリストアでリストアする場合、ディレクトリを指定したとしても、リストア時点に存在しなかったファイルを削除するといった処理は行われません。
仮にリストア時点に存在しなかったファイルを削除したい場合は、一度そのディレクトリ内のファイルやフォルダを削除する必要があります。
SnapRestoreの場合、ボリュームをSnapshot取得時点にリストアすることが可能です。Snapshot取得以降に変更されたファイルはSnapshot取得時点の状態に戻り、Snapshotに含まれないファイルは削除されます。
マルウェアによる感染やデータ分析など、元の状態に仕切り直す場合はSnapRestoreが使用できるFSxNの方が利便性が高いでしょう。
バックアップだけでなく、アクティブファイルシステムやSnapshotに対してWORM機能が必要
FSxNではSnapLockとTamperproof Snapshotによって、アクティブファイルシステムやSnapshotに対してWORMを提供することが可能です。
2025/2/9時点では、FSxWではそのような機能は提供されていません。FSxWではAWS Backupのボールトロック機能によってバックアップをWORMメディアにすることが可能です。
バックアップだけでなく、アクティブファイルシステムやSnapshotに対してWORM機能が必要な場合はFSxNを選択することになります。
ノイジーネイバー対策としてQoSを設定したい
FSxNではSVMやボリューム、qtree、ファイルに対してQoSをかけることが可能です。
2025/2/9時点では、FSxWではそのような機能は提供されていません。
ノイジーネイバー対策として、QoSをかけて他クライアントの性能に悪影響を与えないようにする必要があるのであれば、FSxNを採用することになります。
クロスリージョンなDR環境において、厳格なRTO/RPO要件を少ない運用負荷で実現する必要がある
FSxNではSnapMirrorを用いて非同期でブロック単位でレプリケーションすることが可能です。
SnapMirrorはクロスリージョンで組むことも可能です。
SnapMirrorは最短5分間隔(推奨10分)で実行することも可能であるため、5分のRPO(厳密には+Snapshotの取得とSnapshotの転送にかかる時間)を実現することが可能です。
RTOについては訓練次第ですが、1時間未満も十分狙えます。
短いRPO/RTOが求められる対応として、FSxWで同様にレプリケーションをする場合、DFSもしくはDataSyncを使用することになります。
DFSは経験上、一部ファイルが転送されていなかったり、大容量データの処理同期に時間がかかったりと思わぬ落とし穴が多い印象があります。
DataSyncで同期する場合は都度、差分のファイルをチェックする処理がかかるため、高頻度で同期をかけるには向いていません。また、DataSyncの転送料金も気になります。
クロスリージョンなDR環境において、厳格なRTO/RPO要件を少ない運用負荷で実現する必要があるのであれば、FSxNが無難なように感じています。
キャッシュが効きやすいワークロード
FSxNはFSxWと比較してスループットキャパシティあたりのキャッシュサイズ量が多いです。
| スループットキャパシティ | メモリ(FSxW) | インメモリキャッシュ(FSxN) | NVMeキャッシュ (Multi-AZ FSxN) |
|---|---|---|---|
| 32MBps | 4GB | - | - |
| 64MBps | 8GB | - | - |
| 128MBps | 8GB | 16GB | 150GB |
| 256MBps | 16GB | 32GB | 300GB |
| 512MBps | 32GB | 64GB | 600GB |
| 1,024MBps | 72GB | 128GB | 1,200GB |
| 2,048MBps | 144GB | 256GB | 2,400GB |
| 4,608MBps | 192GB | - | - |
| 6,144MBps | 256GB | - | - |
| 9,216MBps | 384GB | - | - |
| 12,288MBps | 512GB | - | - |
参考
- Amazon FSx for NetApp ONTAP のパフォーマンス - FSx for ONTAP
- FSx for Windows File Server のパフォーマンス - Amazon FSx for Windows File Server
FSxWはメモリサイズであり、インメモリキャッシュサイズではないですが、スループットキャパシティあたりのキャッシュサイズはFSxNの方が大きいことが分かります。
また、FSxNはMulti-AZの場合NVMeキャッシュも存在します。
キャッシュが効きやすいワークロードなのであれば、FSxNの方が安価に低レイテンシーなIOを提供できるでしょう。
DFSを使わずに数百TBスケールのデータを保存したい
FSxNではFlexVolumeで300TiB、FlexGroupで20PiBの名前空間を提供することが可能です。
FSxWの最大ストレージサイズは64TiBです。
もし、これよりも大きい名前空間を提供する必要がある場合、DFSを使う必要があります。
DFSの運用コストを回避したいのであれば、FSxNを採用することになります。
NFSにも対応したい
FSxNはNFSもサポートしています。
NFSしか喋ることができないクライアントに対して同一ファイルにアクセスさせたいのであれば、FSxNを採用することになります。
AWSのAPIでサポートされていない処理をPowerShellではなく、REST APIやそのラッパー経由で操作したい
FSxNではAWSのAPIでサポートされていない処理をONTAP CLIだけでなく、REST APIまた、そのラッパーで操作することが可能です。
FSxWの場合はそもそも設定可能な範囲がFSxNと比べて狭く、あまり気にする必要はないと思いますが、もしLambda関数からAWSのAPIでサポートされていない処理を行いたい場合はFSxNを採用すると良いでしょう。
アンチマルウェアソフトを動作させたい
FSxNではVscanによってリアルタイム or スケジュールでマルウェアスキャンを行うことが可能です。
2025/2/9時点では、FSxWではそのような機能は提供されていません。
マルウェア対策として、クライアントにインストールされたEPPやEDR製品によって対応するのでは不十分である場合はFSxNを採用することになるでしょう。
スケジュールスキャンで良い場合は、FSxWをマウントした領域にアンチマルウェアソフトによる定期スキャンをかければ良いかもしれません。ただし、差分スキャンをサポートしていない製品の場合、マウントした領域配下を毎回スキャンすることになるため、スキャン完了まで長時間要するでしょう。
Vscanの場合はスキャンされたファイルのキャッシュを保持します。一度スキャンされたファイルはファイルの実データおよびファイル名の変更がない限り、永続的にスキャンされません。つまりスケジュールスキャンであったとしても、短い時間でスキャンを完了させることが可能です。
管理アクティビティの監査ログを保存したい
FSxNではONTAP CLIなどAWSのAPI以外の操作を管理アクティビティの監査ログとして記録することが可能です。
2025/2/9時点では、FSxWではそのような機能は提供されていません。
もし、AWSのAPIを使用せずに設定変更をしたことを証跡として残す必要があるのであれば、FSxNを採用することになるでしょう。
オンプレミスなど別ネットワークからのアクセス時のレイテンシーが気になるのでキャッシュを配置したい
FSxNではFlexCacheというデータブロック単位のキャッシュボリュームを提供する機能が存在します。
クライアントからFSxNに直接アクセスするにはレイテンシーが大きすぎる場合は、クライアントの近くにキャッシュを配置することで読み込み性能を向上させることが可能になります。
また、書き込みとキャッシュにないデータの読み込みのみオリジンにアクセスするため、Site-to-Site VPNやDirect Connect、Transit Gatewayのデータ転送量も減ります。
FSxWはFSx File GatewayというFSxに存在するファイルデータに対するキャッシュ機能を提供するためのサービスがあるのですが、2024/10/28以降新規に利用することはできません。
Security Groupとは別に送信元IPアドレスや認証方法でアクセス許可を行いたい
1つのFSxファイルシステム上で複数の用途のSMBファイル共有を作成していると、SMBファイル共有毎に許可したい送信元IPアドレスや認証方法を変更したいことがあります。
そんな時はボリュームやqtreeごとにエクスポートポリシーを設定することで対応できます。
2025/2/9時点では、FSxWではそのような機能は提供されていません。ファイル共有のACLやファイルやフォルダのNTFS ACLの範囲で制御する必要があります。
atimeをベースに何か処理をさせたい
最終アクセス日時を元にファイルの整理を行いたいときがあります。例えば、atimeが1年以上経過しているファイルはアーカイブストレージに移動したり削除したりする製品などあります。
FSxNではファイルをオープンしたり、フォルダ内を参照するとatimeが更新されます。
FSxWではファイルをオープンしてもatimeは更新されません。
ADを用意せずにワークグループのSMBのファイルサーバーを提供したい
何かしらの事情でADを用意できない場合があります。
FSxNではADを用意しなくとも、ワークグループのSMBファイルサーバーとして動作させることが可能です。
FSxWの場合ワークグループのSMBファイルサーバーとして動作させることはできません。Managed Microsoft ADやAD Connector、AD DCなど何かしらのADが必要になります。
なお、本番利用でワークグループのSMBサーバーを使うのは控えましょう。移行をした際にアクセスできなくなる可能性があります。
ワークグループのSMBサーバーの認証で使用するローカルユーザやローカルグループは基本的に移行することが出来ません。
ローカルユーザーやローカルグループはSVM内で固有の情報です。そのため、SnapMirrorやDataSyncでACLの情報を転送しても、転送先のSVMにはそのSIDに紐づくローカルユーザーやローカルグループが存在しません。同じ名前でローカルユーザーやローカルグループを作成してもSIDは一致しません。結果として移行先でアクセスができない状況になります。
後からACLをドメインユーザーやドメイングループで管理するように変更するのも中々大変です。それであれば、最初からドメイン参加することをお勧めします。
既存データのコピーを手間をかけず、短時間で用意したい
開発や検証用の本番環境のデータのコピーを用意したいことがあります。
そのような場合はFSxNのFlexCloneが便利です。
FlexCloneを使用することで高速に、しかも余計なストレージを消費せずにクローンボリュームを作成することが可能です。
検証用途などで定期的にボリュームのデータを複製したい場合は、FSxNを採用すると良いでしょう。
金銭的コストと運用にかかる人的コスト、要件に対する機能的な充足度合いを鑑みて決定しよう
Amazon FSx for NetApp ONTAPとAmazon fSx for Windows File Serverの使い分けを整理してみました。
要するに、金銭的コストと運用にかかる人的コスト、要件に対する機能的な充足度合いを鑑みて判断しましょう。
まずは、求められる要件と、その重要度の整理をしましょう。
いくらコストが安いからといっても必須要件を満たせない場合は、選択の土俵に入りません。コストも大事ですが、重要度とのバランスを考えましょう。
その後、その要件を満たすための構成を採用した場合の、ランニングコストの見積もりを行います。この時点である程度どちらを採用するのか分かってくるはずです。
最後に、運用体制的にオーバースペックではないか、学習コストをかけるほどのメリットを享受できるかを判断します。要するに「本当にFSxNを採用して運用できるか」という簡単です。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
