Amazon FSx for NetApp ONTAPファイルシステムをMulti-AZにするかSingle-AZにするかの判断ポイントをまとめてみた
2024.02.02Multi-AZで構築するかSingle-AZで構築するか
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSxN)ファイルシステムをMulti-AZで構築するかSingle-AZで構築するか悩んだことはありますか? 私はあります。
前提として2024/2/1時点ではFSxNファイルシステム作成後にMulti-AZ構成からSingle-AZ構成へ、またその逆に変更することはできません。
そのため、「やっぱりMulti-AZ(or Single-AZ)にすれば良かった!変更したい!」となった場合は、新規作成したFSxNファイルシステムにSnapMirrorでデータ転送してあげるステップが必要になります。RDSやElastiCacheのように簡単に変更はできないということです。
大量のデータが投入された後での対応はなかなかの労力です。構築前にしっかり考えた上で決定したい要素です。
そこで、個人的なMulti-AZ構成とSingle-AZ構成の使い分けを紹介します。
いきなりまとめ
- こんな時はMulti-AZ構成を採用
- AZ障害時のRPO/RTOを短くしたい
- 少ないスループットキャパシティでもNVMeキャッシュを効かせたい
- こんな時はSingle-AZ構成を採用
- コストをともかく最優先したい
- AZ障害時のRPO/RTOが長くなっても構わない
- バックアップ or DR目的で別FSxNファイルシステムとのSnapMirrorを組む想定
- オンプレミスからDirect Connect経由でNFS/SMBでアクセスさせたいが、Transit VIFの用意ができない
- スケーリングアウトファイルシステムでなければ捌けられないほどのスループットが求められる
こんな時はMulti-AZ
まとめ
まずは、Multi-AZ構成を採用すると良い場面です。結論以下のとおりです。
- AZ障害時のRPO/RTOを短くしたい
- 少ないスループットキャパシティでもNVMeキャッシュを効かせたい
1. AZ障害時のRPO/RTOを短くしたい
Multi-AZ構成にするモチベーションの最たる理由です。
当然ですが、Single-AZ構成とする場合、そのAZ全体を巻き込む障害が発生した際には影響を受けやすいです。Multi-AZ構成とすることでAZ障害の影響を抑えることができます。
仮にSnapMirrorで別FSxNファイルシステムにレプリケーションしていたとしても、RPO/RTOはMulti-AZ構成には敵いません。これはSnapMirrorが非同期レプリケーションであるためです。同期間隔は最短5分(FlexVolumeの推奨は10分、FlexGroupの推奨は30分)です。
同期レプリケーションであるSnapMirror Synchronous、Active-Activeを実現するSnapMirror Business Continuitや、MetroClusterは2024/2/1時点ではFSxNでサポートされていません。
Multi-AZ構成の場合は、異なるAZ間でデータを同期的にレプリケーションします。
マルチ AZ デプロイのタイプ
マルチ AZ ファイルシステムは、シングル AZ ファイルシステムの可用性と耐久性の機能をすべてサポートしています。さらに、アベイラビリティーゾーンが利用できない場合でも、データに継続的な可用性を提供するように設計されています。マルチ AZ 配置では、ファイルサーバーの HA ペアは 1 つで、スタンバイファイルサーバーは同じ AWS リージョン 内のアクティブなファイルサーバーとは異なるアベイラビリティーゾーンにデプロイされます。ファイルシステムに書き込まれるすべての変更は、アベイラビリティーゾーン間で同期的にスタンバイにレプリケートされます。
. . (中略) . .
そのため、Multi-AZ構成の場合のAZ障害時のRPOは非常に短いと考えます。
RTOについても接続してくるクライアント次第ではありますが十分に短いと考えます。FSxNファイルシステムの内部的には通常60秒以内にフェイルオーバーが完了します。
あるファイルサーバーから別のファイルサーバーにフェイルオーバーすると、新しいアクティブファイルサーバーは、その HA ペアに対するすべてのファイルシステムの読み取りおよび書き込みリクエストを自動的に処理し始めます。マルチ AZ ファイルシステムの場合、優先ファイルサーバーが完全に復旧して利用可能になると、Amazon FSx は自動的にそのサーバーにフェイルバックします。通常、フェイルバックは 60 秒以内に完了します。シングル AZ とマルチ AZ のファイルシステムの場合、アクティブファイルサーバーでの障害検出からスタンバイファイルサーバーのアクティブステータスへの昇格までのフェイルオーバーの処理は、通常 60 秒以内に完了します。クライアントが NFS または SMB 経由でデータにアクセスするために使用するエンドポイント IP アドレスは同じであるため、フェイルオーバーは Linux、Windows、および macOS アプリケーションに対して透過的であり、手動による介入なしにファイルシステムオペレーションが再開されます。
SnapMirrorを組んでいる場合は、手動でSnapMirrorのカットオーバーやDNSレコードの切り替えなどのオペレーションが必要となります。いくら訓練したとしても、障害が発生してから60秒以内に切り替えるようにするのは難しいでしょう。
また、Multi-AZ構成の場合のSLAは99.99%です。
抜粋 : Amazon FSx Service Level Agreement
「SLAが99.99% = 99.99%停止しない」という訳ではありませんが、高いSLAを求められている場合は一つの目安になると考えます。
2. 少ないスループットキャパシティでもNVMeキャッシュを効かせたい
繰り返し同じデータアクセスが発生する場合、キャッシュを有効活用したいところです。ディスクアクセスするよりもキャッシュで返す方が高いパフォーマンスを出せるためです。
Multi-AZ構成の場合、スループットキャパシティがミニマムの128MBpsであってもNVMeキャッシュが効きます。
抜粋 : Impact of throughput capacity on performance
Single-AZ構成でNVMeキャッシュを使用する場合、スループットキャパシティが2,048MBps以上である必要があります。
抜粋 : Impact of throughput capacity on performance
「ネットワークやSSDのスループット、IOPSはそこそこで良いが、頻繁に同じデータにアクセスするワークロードであるためキャッシュを活用したい」という場面はMulti-AZ構成にすることを考えると良いでしょう。
なお、実際にどのぐらいのパフォーマンスが出るのか本番導入する前に検証されることをお勧めします。場合によってはSingle-AZ構成でスループットキャパシティを盛る方がコストパフォーマンスが良いこともあります。
こんな時はSingle-AZ
まとめ
続いて、Single-AZを採用すると良い場面です。先にまとめると以下のとおりです。
- コストをともかく最優先したい
- AZ障害時のRPO/RTOが長くなっても構わない
- バックアップ or DR目的で別FSxNファイルシステムとのSnapMirrorを組む想定
- オンプレミスからDirect Connect経由でNFS/SMBでアクセスさせたいが、Transit VIFの用意ができない
- スケーリングアウトファイルシステムでなければ捌けられないほどのスループットが求められる
1. コストをともかく最優先したい
Single-AZ構成を採用するベースとなる理由がコストです。
Single-AZ構成とMulti-AZ構成のコストを比較すると以下のようになります。
| - | Single-AZの場合 | Multi-AZの場合 | Single-AZ / Multi-AZ |
|---|---|---|---|
| プロビジョニングされたSSDサイズ | 0.150 USD/GB | 0.300 USD/GB | 50% |
| キャパシティプールストレージの物理使用量 | 0.0238 USD/GB | 0.0476 USD/GB | 50% |
| バックアップストレージサイズの物理使用量 | 0.050 USD/GB | 0.050 USD/GB | 100% |
| SnapLock ライセンス | 0.0244 USD/GB | 0.0244 USD/GB | 100% |
| スループットキャパシティ (スケールアップファイルシステム) | 0.906 USD/GB | 1.511 USD/GB | 59.96% |
| スループットキャパシティ (スケールアウトファイルシステム) | 0.906 USD/GB | - | - |
| SSD IOPS | 0.0204 USD/GB | 0.0408 USD/GB | 50% |
| キャパシティープールのReadリクエスト | 0.0004 USD/1,000リクエスト | 0.0004 USD/1,000リクエスト | 100% |
| キャパシティープールのWriteリクエスト | 0.0047 USD/1,000リクエスト | 0.0047 USD/1,000リクエスト | 100% |
参考 : Amazon FSx for NetApp ONTAP の料金 — AWS
多くの項目でSingle-AZ構成の方がMulti-AZ構成よりも安いです。以下の構成でのコストを試算します。
- データサイズ :
10TiB - SSDの割合 :
30% - Storage Efficiencyによるデータ削減量 :
30% - スループットキャパシティ :
256MBps - SSDの追加IOPS : なし
- キャパシティプールストレージのReadリクエスト :
2,000,000 - キャパシティプールストレージのWriteリクエスト :
1,000,000 - バックアップストレージ :
11TiB - SnapLock : なし
この時のSingle-AZ構成のコスト①は1,073.60 USDで、Multi-AZ構成のコスト②は1,670.46 USDでした。35%ほど安価です。
| - | ① | ② | ① / ② |
|---|---|---|---|
| SSDサイズ料金 | 322.56 USD | 645.12 USD | 50.00% |
| キャパシティプールストレージサイズ料金 | 119.42 USD | 238.84 USD | 50.00% |
| スループットキャパシティ料金 | 231.94 USD | 386.82 USD | 59.96% |
| SSDの追加IOPS料金 | 0.00 USD | 0.00 USD | 100.00% |
| キャパシティプールストレージのRead/Writeリクエスト料金 | 5.44 USD | 5.44 USD | 100.00% |
| バックアップストレージ料金 | 394.24 USD | 394.24 USD | 100.00% |
| 合計 | 1073.60 USD | 1670.46 USD | 64.27% |
全体のコストを占める割合が大きいバックアップストレージのコストはSingle-AZ構成とMulti-AZ構成でも同一です。より小規模な環境であれば、Single-AZ構成とMulti-AZ構成のコスト差は開くと考えます。
2. AZ障害時のRPO/RTOが長くなっても構わない
AZ障害時に要求されるRPO/RTOがMulti-AZ構成ほどでない場合もSingle-AZ構成とする方が良いでしょう。
RPOはバックアップ取得間隔に依存し、RTOはリストア作業時間時間に依存します。ポイントは以下の通りです。
- RPO
- AWS Backup : 最短1時間 + バックアップ完了までにかかる時間
- SnapMirror : 最短5分(推奨10分) + 転送完了までにかかる時間
- RTO
- AWS Backup : バックアップストレージの使用量に大きく依存
- SnapMirror : 元々のFSxNファイルシステム上にリストアするのであればデータ使用量に依存。転送先にフェイルオーバーするのであれば、切り替え作業に依存
RTOは実際のオペレーション次第ですが、検証の上で上述のRPO/RTOで十分であれば、Single-AZ構成を検討すると良いと考えます。
「RPO/RTOがどちらも12時間」ぐらいであれば、Single-AZ構成で十分でないかと考えます。
また、Single-AZ構成でも内部では2つのノードが動作しています。そのため、単一のノード障害に対しての耐久性があります。スループットキャパシティを変更した際のダウンタイムも非常に短いです。詳細は以下記事をご覧ください。
それの影響かSingle-AZ構成のFSxNファイルシステムであってもSLAは99.9%あります。
抜粋 : Amazon FSx Service Level Agreement
3. バックアップ or DR目的で別FSxNファイルシステムとのSnapMirrorを組む想定
バックアップやDR目的で別FSxNファイルシステムとのSnapMirrorを組む想定である場合もSingle-AZ構成を考えると良いでしょう。
Multi-AZ構成のファイルシステムだからと言ってバックアップを取得しないということはないと考えます。バックアップやDR目的でAWS BackupやSnapMirrorによる別ONTAPへのレプリケーションを検討すると考えます。AWS BackupとSnapMirrorの使い分けは以下記事をご覧ください。
SnapMirrorで別AZのFSxNファイルシステムにレプリケーションする構成にすると、先述のとおり非同期レプリケーションではありますが、擬似的なMulti-AZ構成になります。RPO/RTOが許すのであれば、こちらの方がコストが安くなると考えます。
実際にSingle-AZ構成のFSxNファイルシステムを2つ用意してSnapMirrorを組むパターンと、Multi-AZ構成でAWS Backupによるバックアップを取得するパターンのコストを比較します。
Single-AZ構成(SnapMirror転送元)①の設定値、Single-AZ構成(SnapMirror転送先)②の設定値、Multi-AZ構成③の設定値は以下の通りです。
条件は以下の通りです。
| - | ①設定値 | ②設定値 | ③設定値 |
|---|---|---|---|
| データサイズ | 10TiB | 10TiB | 10TiB |
| SSDの割合 | 30% | 10% | 30% |
| Storage Efficiencyによるデータ削減量 | 30% | 30% | 30% |
| スループットキャパシティ | 256MBps | 128MBps | 256MBps |
| SSDの追加IOPS | なし | なし | なし |
| キャパシティプールストレージのReadリクエスト | 2,000,000 | 2,000,000 | 2,000,000 |
| キャパシティプールストレージのWriteリクエスト | 1,000,000 | 1,000,000 | 1,000,000 |
| バックアップストレージ | なし | なし | 11TiB |
| SnapLock | なし | なし | なし |
①と②のコストの合計は1,107.91 USDで、③は1,670.46 USDです。34%ほど安価です。
| - | ① | ② | ③ | ① + ② | (① + ②) / ③ |
|---|---|---|---|---|---|
| SSDサイズ料金 | 322.56 USD | 153.60 USD | 645.12 USD | 476.16 USD | 73.81% |
| キャパシティプールストレージサイズ料金 | 119.42 USD | 153.54 USD | 238.84 USD | 272.96 USD | 114.29% |
| スループットキャパシティ料金 | 231.94 USD | 115.97 USD | 386.82 USD | 347.91 USD | 89.94% |
| SSDの追加IOPS料金 | 0.00 USD | 0.00 USD | 0.00 USD | 0.00 USD | 100.00% |
| キャパシティプールストレージのRead/Writeリクエスト料金 | 5.44 USD | 5.44 USD | 5.44 USD | 10.88 USD | 200.00% |
| バックアップストレージ料金 | 0.00 USD | 0.00 USD | 394.24 USD | 0.00 USD | 0.00% |
| 合計 | 679.36 USD | 428.55 USD | 1670.46 USD | 1107.91 USD | 66.32% |
なお、Multi-AZ構成でバックアップを取得しない場合のコストは1276.22 USDです。つまりは、Multi-AZ構成FSxNファイルシステム1台よりも、Single-AZ構成のFSxNファイルシステムを2台でSnapMirrorを組む方が安く上がります。
4. オンプレミスからDirect Connect経由でNFS/SMBでアクセスさせたいが、Transit VIFの用意ができない
Multi-AZ構成の場合、オンプレミスネットワークや別VPCからのNFS/SMBアクセスをルーティングするためにTransit Gatewayを使うことがほとんどです。
以下のようにNLBでルーティングする方法もありますが、推奨である「エンドポイントIPアドレスにVPCのCIDR範囲内とする構成」では使えないので、推奨されません。
VGWのゲートウェイルートテーブルを使ってもFSxNファイルシステムのフローティングIPアドレスにルーティングすることはできません。
システム要件として、オンプレミスからの閉域網経由で接続することも考えられます。Transit GatewayとオンプレミスとをDirect Connect Gateway経由で接続する場合、Transit VIFが必須となります。
まだまだTransit VIFをサポートしているDirect Connect デリバリーパートナーは少ない認識です。そのため、Direct Connect経由でMulti-AZ構成のFSxNファイルシステムに接続したくてもできない場面も十分考えられます。
Single-AZ構成ではフローティングIPアドレスは存在しないため、Transit Gatewayは必要ありません。つまりはPrivate VIF経由でのオンプレミスとの接続が可能です。要求されるRPO/RTO次第ではありますが、Single-AZ構成を検討しましょう。
余談ですが、Transit Gatewayはデータ転送量に応じても課金(0.02 USD/GB)が発生します。
Single-AZ構成のFSxNファイルシステムとクライアント間で大容量のトラフィックが流れる場合は、Transit Gatewayを導入していたとしても、Transit Gatewayを通らないようにルーティングするのも手です。(ネットワーク構成はカオスになる可能性も高まりますが)
5. スケーリングアウトファイルシステムでなければ捌けられないほどのスループットとSSDサイズが求められる
re:Invent 2023でスケーリングアウトファイルシステムがGAされました。2024/2/2時点ではSingle-AZのみのサポートで、Multi-AZでは使用できません。
Multi-AZ構成のスループットキャパシティの上限である4,096MBps以上の性能を出すことが可能になります。性能はHAペアの個数とHAペアの性能次第です。最大は36,864MBps(6HAペア、6,144MBps/HAペア)です。
抜粋 : Impact of throughput capacity on performance
SSDもHAペア毎にプロビジョニングされるため、1FSxNファイルシステムのSSDサイズの上限も192TiBから1PiBとなっています。
デプロイ後にHAペアの数を変更したり、スループットキャパシティを変更したりできないと制約事項は色々とありますが、超ハイパフォーマンスを求めるられる場合はスケーリングアウトファイルシステムの出番です。
注意点として、2024/2/2時点では東京リージョン、大阪リージョンでサポートされていません。
変更が効かない要素なので十分検討しよう
Amazon FSx for NetApp ONTAPファイルシステムをMulti-AZにするかSingle-AZにするかの判断ポイントをまとめてみました。
ベースとなるのはRPO/RTOとコストのバランスです。変更が効かない要素なので十分検討をしましょう。
個人的には、RPO/RTOが許容できるのであれば、「Single-AZで別のSingle-AZファイルシステムにSnapMirror」する構成を推しています。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
