しばたです。
少し前の話ですがAmazon FSx for OpenZFS(以後FSx for OpenZFS)でMulti-AZ構成がサポートされました。
AWSからのアナウンスは以下となります。
更新内容
繰り返しになりますが従来FSx for OpenZFSではSingle-AZ構成のみ可能であったのがMulti-AZ構成の環境も作れる様になりました。
ただし、現時点ではすべてのリージョンが対象というわけでは無くSingle-AZ 2構成の利用が可能であった
- バージニア北部
- オハイオ
- オレゴン
- シンガポール
- 東京
- アイルランド
のみMulti-AZ構成がサポートされています。
実装について
特に明言されてはいませんがサポートされるリージョンや設定可能なスループットキャパシティからMulti-AZ構成はSingle-AZ 2をベースに冗長化しているものと推測されます。
(追記 : 記事公開後にMulti-AZ対応リージョンが増え、必ずしもSingle-AZ 2ベースとは言えなくなりました...)
Multi-AZ構成はHAクラスターにより実現されるとされていますがその具体的な実装は非公開です。
とはいえ挙動としてはFSx for WindowsやFSx for NetApp ONTAPと同様に、
- 2AZにまたがる2つのサブネットからそれぞれ「推奨サブネット」「スタンバイサブネット」を選択する
- 推奨サブネットでの動作を基本とし、推奨サブネットでの利用が不可になるとスタンバイサブネットに一時的にフェイルオーバーする
- 推奨サブネットが復旧すると自動でフェイルバックする
という動作をするとのことです。
フェイルオーバーの条件としては
- 推奨サブネットのファイルサーバーが利用不可になる
- スループットキャパシティの値が変更された
- 推奨サブネットのファイルサーバーが計画メンテナンスされる
- AZ障害が発生した
といったケースが挙げられています。
また、FSx for NetApp ONTAP同様にNFSエンドポイントに対してはフローティングIPが使われます。
ドキュメントを見る限りFSx for NetApp ONTAPと同様の制約になっている様です。
SLAについて
今回の更新に合わせてSLAの記述内容も更新されています。
従来からあるSLA 3レベルの定義自体は変わりありませんが、このうち「Multi-AZ SLA」の対象にFSx for OpenZFSが追加されており
- (1) Multi-AZ環境 : SLA 99.99%
- (3) Single-AZ環境 : SLA 99.5%
の扱いとなっています。
料金
本日時点でまだ日本語ページが更新されていなかったので英語版の料金ページをご確認ください。
なぜか東京リージョンのSingle-AZ 2環境の料金を参照できないため厳密に比較できなのですが、ざっくり
- ストレージキャパシティ単価は2倍
- バックアップストレージ料金は変わらず
- スループットキャパシティ単価は約3倍
- プロビジョンド SSD IOPS単価は約4倍
の価格感となっています。
試してみた
ここからは実際に環境を作って簡単な動作確認を行ってみます。
私の検証用AWSアカウントの東京リージョンに新規にファイルシステムを作ってみます。
VPC等のネットワークリソースは作成済みの状態からスタートします。
今回は「スタンダード作成」でウィザードを進めていきます。
ファイルシステムのデプロイタイプに「マルチAZ」が増えているのでこれを選びます。
その他のパラメーターはデフォルトのままにしています。
Multi-AZ構成の場合、2つの「推奨サブネット」「スタンバイサブネット」を指定してやります。
そしてフローティングIPのルート情報を更新する「ルートテーブル」も選びます。
「エンドポイントIPアドレス範囲」はVPCから割り当てる様にしています。
その他の指定項目は基本デフォルトのままとしています。
Multi-AZ構成特有のものは有りませんでした。
確認画面へ進み、指定内容に間違いがないことを確認して「ファイルシステムを作成」してやります。
今回は約10分で作成完了しました。
詳細を確認するとこんな感じです。
ネットワーク設定に「エンドポイントIPアドレス範囲」が10.0.255.224/28とVPC CIDR最後の/28が選ばれており、FSx for NetApp ONTAPより若干狭い範囲となっていました。
あと、理由は分かりませんが「ルートテーブル」指定が期待したものではなく「デフォルトルート」に対して紐づいていたので手動で設定を変更しておきました。
2023.09.04追記
サポートに問い合わせたところマネジメントコンソールの不具合だった様で現在は解消済みです。
(なぜか未指定のデフォルトルートテーブルが紐づいている)
(仕方ないので手動で割り当てなおす)
(今回はシンプルに追加だけしておいた)
割り当て直したあとのルートテーブルを確認するとこんな感じで、確かにNFSエンドポイントである10.0.255.234へのルートが推奨サブネットのENIになっています。
別途用意したEC2からNFSエンドポイントの名前解決するとこんな感じで10.0.255.234であることが確認できます。
# エンドポイントのIPアドレスを確認
$ dig fs-06734b89b4fa51655.fsx.ap-northeast-1.amazonaws.com +short
10.0.255.234あとは従来通りの操作でマウントして利用してください。
今回はAmazon Linux 2023 EC2インスタンスを用意して簡単な動作確認だけしていています。
# 適当にマウント
sudo mkdir /mnt/fsx
sudo mount -t nfs -o nfsvers=4.1 fs-06734b89b4fa51655.fsx.ap-northeast-1.amazonaws.com:/fsx/ /mnt/fsx/
# 簡単にファイル書き込み
echo "hello" > /mnt/fsx/hello.txt結果はこんな感じで特に問題無く使えています。
# マウントポイントを確認
$ df /mnt/fsx
Filesystem 1K-blocks Used Available Use% Mounted on
fs-06734b89b4fa51655.fsx.ap-northeast-1.amazonaws.com:/fsx 104857600 0 104857600 0% /mnt/fsx
# ファイルも参照できている
$ ls /mnt/fsx/
hello.txt
$ cat /mnt/fsx/hello.txt
helloフェイルオーバーを試してみた
続けてスループットキャパシティを変更することでフェイルオーバーを試してみました。
更新中に定期的にルートテーブルの内容を確認し、先ほど作ったhello.txtに対してcatコマンドを掛けておきました。
(正直あまり良い確認方法では無いですが良い方法を思いつかなかったのでご容赦を...)
更新作業自体は本日の11:32に開始してから約20分かかり下表の様な挙動となりました。
| 時間 | 内容 |
|---|---|
| 11:32 | 更新開始 |
| 11:44 | ルートテーブルのENIが切り替わる |
| 11:48 | ルートテーブルのENIがフェイルバックする |
| 11:53 | 更新終了 |
NFSエンドポイントに対するルートテーブルのENIは推奨サブネットにあるeni-08389b3afca436e45に向いているのが
途中でスタンバイサブネットにあるeni-0fc0eb2328e225b68に切り替わることでフェイルオーバーを実現、
4分ほどで推奨サブネット側にフェイルバックしました。
今回catコマンドで試した限りではフェイルオーバー時に軽く遅延が発生する程度で済みましたが、実際には一度はネットワーク断が起きているはずなので処理によっては中断されると思います。
バックアップについて
FSx for OpenZFSのバックアップを使いSingle-AZ→Multi-AZといった構成変更をすることはできませんでした。
- Multi-AZのバックアップ → Multi-AZにのみ復元可能
- Single-AZのバックアップ → Single-AZにのみ復元可能
- ただし Single-AZ 1 ←→ Single-AZ 2 の変換であれば可能
既存のSingle-AZ環境をMulti-AZにしたい場合は新規にMulti-AZ環境を用意してデータを移送するしかない様です。
最後に
以上となります。
待ち望んだ更新ですね。
これまで冗長構成を採れない点からFSx for OpenZFSの採用を見送ったケースも多かったのではないかと予想しますが、これからは安心して採用できますね。
2
