Amazon FSx for OpenZFSのSingle-AZ HAのフェイルオーバー時間を確認してみた
Single-AZで十分だけれども単一ノード障害時の影響は抑えたい
こんにちは、のんピ(@non____97)です。
皆さんAmazon FSx for OpenZFS(以降FSxZ)を使用しているとき、Single-AZで十分だけれども単一ノード障害時の影響は抑えたいなと思ったことはありますか? 私はあります。
そのため、通常のSingle-AZでデプロイする場合はノードは一つのみです。そのため、ノード障害時ののダウンタイムが長期化しやすいと言えます。
また、メンテナンス時にも15分ほどのダウンタイムが発生するようです。
Patching occurs infrequently, typically once every month during the maintenance window that you specify. Patching should require only a portion of your 30-minute maintenance window. We recommend scheduling your maintenance window during idle periods when there is minimal load on your file system. While patching is in progress, you should expect that your Single-AZ (non-HA) file systems will be unavailable, typically for less than 15 minutes. Your Single-AZ (HA) and Multi-AZ (HA) file systems will remain available and automatically fail over and fail back between the preferred file server and the standby file server. For more information, see Failover process for FSx for OpenZFS.
対応としてMulti-AZを選択しようにもコスト的に許容できないこともあるでしょう。加えて以下記事で紹介されているとおり、Multi-AZでデプロイする場合はエンドポイント IPv4 アドレス範囲を指定する必要があります。
要するにフローティングIPアドレスを使用することとなります。つまりはFSxZがあるVPC外からアクセスする際には以下記事で紹介しているようにNLBやTransit Gateway、Resource型VPCエンドポイントを用意する必要があります。
これらの設計や構築コスト、ランニングコストが気になる方もいるでしょう。
もし、Single-AZでも良いのであれば、HAのSingle-AZでデプロイする形が良いでしょう。
Amazon FSx for NetApp ONTAP(以降FSxN)では以下記事で紹介しているとおり、Single-AZであっても内部に2つのノードが存在しています。
それと同じような形です。
料金的な比較や実際のダウンタイムを計測してみます。
いきなりまとめ
- Single-AZ HAでデプロイすることで、メンテナンスや単一ノード障害時の影響をダウンタイムを60秒×2回に抑えることが可能
料金比較
まず、料金比較です。2025/9/30時点の東京リージョンにおけるMulti-AZ Intelligent-Tiering以外のデプロイオプションごとの料金は以下のとおりです。
| Single-AZ non HA | Single-AZ HA | Multi-AZ | |
|---|---|---|---|
| SSD サイズ | 0.108 USD/GB | 0.108 USD/GB | 0.216 USD/GB |
| バックアップストレージ | 0.050 USD/GB | 0.050 USD/GB | 0.050 USD/GB |
| SSD IOPS | 0.0068 USD/IOPS | 0.0144 USD/IOPS | 0.0288 USD/IOPS |
| スループットキャパシティ | 0.350 USD/MBps | 0.70 USD/MBps | 1.0955 USD/MBps |
参考 :
Single-AZ non HAとSingle-AZと比べて、SSD IOPSとスループットキャパシティのみ料金単価が倍増していることが分かります。これはノードが単純に2つ増えたのみで裏側のストレージについては変動がないためだと考えます。
また、Single-AZ HAはMulti-AZと比べて、SSDストレージサイズやSSD IOPS以外の料金単価が半額であることが分かります。スループットキャパシティについては63%ほどの料金となっています。
このことからMulti-AZではToo muchな場合はSingle-AZ HAを選択すると良いでしょう。
FSxNとの比較もしてみます。FSxNのキャパシティプールストレージや第二世代ファイルシステムを出すと話がややこしくなるので、ここでは省略しています。
| FSxZ Single-AZ HA | FSxN Single-AZ | FSxZ Multi-AZ | FSxN Multi-AZ | |
|---|---|---|---|---|
| SSD サイズ | 0.108 USD/GB | 0.15 USD/GB | 0.216 USD/GB | 0.30 USD/GB |
| バックアップストレージ | 0.050 USD/GB | 0.050 USD/GB | 0.050 USD/GB | 0.050 USD/GB |
| SSD IOPS | 0.0144 USD/IOPS | 0.0204 USD/IOPS | 0.0288 USD/IOPS | 0.0408 USD/IOPS |
| スループットキャパシティ | 0.70 USD/MBps | 0.906 USD/MBps | 1.0955 USD/MBps | 1.511 USD/MBps |
参考 :
バックアップストレージの料金単価以外はFSxZの方が安いことが分かります。
加えて、SSDサイズのミニマムはFSxZが64GiBで、FSxNが1,024GiBです。
「FSxNではストレージサイズがToo much、EFSではレイテンシーやデータ転送量に対する課金が気になる。」といったときにはFSxZは十分選択肢に入るのではないでしょうか。
なお、SSD IOPSに対する課金はFSxNの場合と異なり、ベースラインを超過した分への課金ではなく、全体の料金に対してかかります。そのため、SSDサイズが大きくなるとSSD IOPS料金分のコスト的にFSxNの方が有利になります。
例) SSDサイズが1,024GiBの場合のSSDサイズとSSD IOPSにかかる料金
| FSxZ Single-AZ HA | FSxN Single-AZ | |
|---|---|---|
| SSDサイズ | 0.108 USD/GB × 1,024GiB = 110.592 USD | 0.15 USD/GB × 1,024GiB =153.6 USD |
| SSD IOPS | 0.0144 USD/IOPS × 1,024 GiB × 3 IOPS = 44.2368 USD | 0 (ベースラインを超過していないため) |
| 合計 | 154.8288 USD | 153.6 USD |
低レイテンシーかつ細かいIOが頻発するシンプルなNFSファイルサーバーにおいて、FSxNとFSxZのどちらを使用するか迷っている場合はコスト試算をしてみましょう。
SLA
Single-AZ HAファイルシステムのSLAは99.9%です。
Single-AZ SLA for Amazon FSx for OpenZFS HA and Amazon FSx for NetApp ONTAP Single-AZ File Systems
AWS will use commercially reasonable efforts to make each Amazon FSx for OpenZFS HA and Amazon FSx for NetApp ONTAP Single-AZ File System available with a Single-AZ Uptime Percentage as shown in the table below during any monthly billing cycle:
Single-AZ Uptime Percentage Service Credit Percentage Less than 99.9% but greater than or equal to 99.0% 10% Less than 99.0% but greater than or equal to 95.0% 25% Less than 95.0% 100%
Single-AZ non HAは99.5%なので、SLAレベルでも変化があるということですね。
やってみた
検証環境の作成
実際に触ってみます。
検証環境は以下のとおりです。
FSxZは以下のようにSingle-AZ HAでデプロイします。
他のオプションは以下のとおりです。
作成が完了したらNFSでマウントします。
$ sudo mount -t nfs -o noatime,nfsvers=4.2,sync,nconnect=16,rsize=1048576,wsize=1048576 fs-013e10b46352f967a.fsx.us-east-1.amazonaws.com:/fsx/ /mnt/fsxz
$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
fs-013e10b46352f967a.fsx.us-east-1.amazonaws.com:/fsx nfs4 64G 0 64G 0% /mnt/fsxz
ちなみにFSxZのENIは2つありましたが、エンドポイント IPv4 アドレスは一つだけでした。
エンドポイント IPv4 アドレスははセカンダリIPアドレスとして付与されています。フェイルオーバーするタイミングでセカンダリIPアドレスのつけ外しをしているのでしょうか。
> aws ec2 describe-network-interfaces --network-interface-ids eni-0f8e33c21923c1f30 eni-0597847d12e3edda7
{
"NetworkInterfaces": [
{
"Attachment": {
"AttachTime": "2025-09-30T04:10:42+00:00",
"AttachmentId": "eni-attach-018e3036fc78487b9",
"DeleteOnTermination": false,
"DeviceIndex": 1,
"NetworkCardIndex": 0,
"InstanceOwnerId": "385076128341",
"Status": "attached"
},
"AvailabilityZone": "us-east-1a",
"Description": "[Do not detach or untag] Amazon FSx network interface for fs-013e10b46352f967a",
"Groups": [
{
"GroupId": "sg-01b3ef4ae0cc354de",
"GroupName": "default"
}
],
"InterfaceType": "interface",
"Ipv6Addresses": [],
"MacAddress": "0e:b0:8a:18:77:d9",
"NetworkInterfaceId": "eni-0597847d12e3edda7",
"OwnerId": "<AWSアカウントID>",
"PrivateDnsName": "ip-10-10-0-6.ec2.internal",
"PublicDnsName": "",
"PrivateIpAddress": "10.10.0.6",
"PrivateIpAddresses": [
{
"Primary": true,
"PrivateDnsName": "ip-10-10-0-6.ec2.internal",
"PrivateIpAddress": "10.10.0.6"
}
],
"RequesterId": "470192892696",
"RequesterManaged": false,
"SourceDestCheck": true,
"Status": "in-use",
"SubnetId": "subnet-0e3df3b25ce3b6bb9",
"TagSet": [
{
"Key": "AmazonFSx.FileSystemId",
"Value": "fs-013e10b46352f967a"
}
],
"VpcId": "vpc-07a0a78e0fe1d581c",
"DenyAllIgwTraffic": true,
"Operator": {
"Managed": false
}
},
{
"Attachment": {
"AttachTime": "2025-09-30T04:10:42+00:00",
"AttachmentId": "eni-attach-0d602d347121038b8",
"DeleteOnTermination": false,
"DeviceIndex": 1,
"NetworkCardIndex": 0,
"InstanceOwnerId": "385076128341",
"Status": "attached"
},
"AvailabilityZone": "us-east-1a",
"Description": "[Do not detach or untag] Amazon FSx network interface for fs-013e10b46352f967a",
"Groups": [
{
"GroupId": "sg-01b3ef4ae0cc354de",
"GroupName": "default"
}
],
"InterfaceType": "interface",
"Ipv6Addresses": [],
"MacAddress": "0e:e3:fe:7b:02:79",
"NetworkInterfaceId": "eni-0f8e33c21923c1f30",
"OwnerId": "<AWSアカウントID>",
"PrivateDnsName": "ip-10-10-0-8.ec2.internal",
"PublicDnsName": "",
"PrivateIpAddress": "10.10.0.8",
"PrivateIpAddresses": [
{
"Primary": true,
"PrivateDnsName": "ip-10-10-0-8.ec2.internal",
"PrivateIpAddress": "10.10.0.8"
},
{
"Primary": false,
"PrivateDnsName": "ip-10-10-0-7.ec2.internal",
"PrivateIpAddress": "10.10.0.7"
}
],
"RequesterId": "470192892696",
"RequesterManaged": false,
"SourceDestCheck": true,
"Status": "in-use",
"SubnetId": "subnet-0e3df3b25ce3b6bb9",
"TagSet": [
{
"Key": "AmazonFSx.FileSystemId",
"Value": "fs-013e10b46352f967a"
}
],
"VpcId": "vpc-07a0a78e0fe1d581c",
"DenyAllIgwTraffic": true,
"Operator": {
"Managed": false
}
}
]
}
スループットキャパシティを320MBpsに変更
スループットキャパシティを変更することでフェイルオーバーが発生します。
Multi-AZ (HA) and Single-AZ (HA) file systems automatically fail over from the preferred file server to the standby file server under the following conditions:
- The preferred file server becomes unavailable.
- The file system's throughput capacity is changed.
- The preferred file server undergoes planned maintenance.
Multi-AZ (HA) file systems will also fail over if an Availability Zone disruption occurs.
When failing over from one file server to another, the new active file server automatically begins serving all file system read and write requests. A failover typically takes less than 60 seconds from the detection of the failure on the active file server to the promotion of the standby file server to active status. Upon completion of the failover, you continue to have access to your data without manual intervention. When the preferred file server is fully recovered and becomes available, Amazon FSx automatically fails back to it, usually in less than 60 seconds.
Availability and durability for Amazon FSx for OpenZFS - FSx for OpenZFS
ダウンタイムは60秒未満×2回のようですね。
スループットキャパシティを320MBpsに変更してフェイルオーバーをします。
スループットキャパシティ前から以下のようにpingとfioでICMPレベルでのネットワーク断とファイル書き込みの断、スループットキャパシティ更新完了のタイミングを確認します。
> ping fs-013e10b46352f967a.fsx.us-east-1.amazonaws.com -i 0.2 | \
while read line; do \
echo "$(date +"%Y-%m-%d %H:%M:%S.%3N"): $line"
done
> sudo fio \
--directory=/mnt/fsxz/ \
--name fio_rw_4MiB_block_4GiB_4jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=4M \
--size=4G \
--numjobs=4 \
--runtime=900 \
--eta-newline=5 \
--time_based=1 \
--group_reporting \
--norandommap
> while true; do
echo "$(date +"%Y-%m-%d %H:%M:%S"): $(aws fsx describe-file-systems --file-system-ids fs-013e10b46352f967a --query 'FileSystems[0].OpenZFSConfiguration.ThroughputCapacity' --output text) MBps"
sleep 5
done
2025-09-30 13:46:45にスループットキャパシティ変更のリクエストを投げたところ、14:06に完了しました。おおよそ変更までは20分です。
> while true; do
echo "$(date +"%Y-%m-%d %H:%M:%S"): $(aws fsx describe-file-systems --file-system-ids fs-013e10b46352f967a --query 'FileSystems[0].OpenZFSConfiguration.ThroughputCapacity' --output text) MBps"
sleep 5
done
.
.
(中略)
.
.
2025-09-30 14:06:20: 160 MBps
2025-09-30 14:06:28: 160 MBps
2025-09-30 14:06:37: 160 MBps
2025-09-30 14:06:45: 320 MBps
2025-09-30 14:06:54: 320 MBps
2025-09-30 14:07:02: 320 MBps
この時のpingの結果ですが、特に疎通に失敗するタイミングはありませんでした。
$ ping fs-013e10b46352f967a.fsx.us-east-1.amazonaws.com -i 0.2 | \ while read line; do \
echo "$(date +"%Y-%m-%d %H:%M:%S.%3N"): $line"
done
2025-09-30 04:46:33.610: PING fs-013e10b46352f967a.fsx.us-east-1.amazonaws.com (10.10.0.7) 56(84) bytes of data.
2025-09-30 04:46:33.611: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=1 ttl=127 time=0.248 ms
2025-09-30 04:46:33.805: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=2 ttl=127 time=0.217 ms
2025-09-30 04:46:34.015: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=3 ttl=127 time=0.255 ms
2025-09-30 04:46:34.225: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=4 ttl=127 time=0.234 ms
2025-09-30 04:46:34.435: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=5 ttl=127 time=0.263 ms
2025-09-30 04:46:34.645: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=6 ttl=127 time=0.300 ms
2025-09-30 04:46:34.855: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=7 ttl=127 time=0.238 ms
2025-09-30 04:46:35.065: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=8 ttl=127 time=0.261 ms
2025-09-30 04:46:35.276: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=9 ttl=127 time=0.253 ms
2025-09-30 04:46:35.485: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=10 ttl=127 time=0.234 ms
2025-09-30 04:46:35.695: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=11 ttl=127 time=0.258 ms
2025-09-30 04:46:35.905: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=12 ttl=127 time=0.260 ms
2025-09-30 04:46:36.115: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=13 ttl=127 time=0.265 ms
2025-09-30 04:46:36.325: 64 bytes from ip-10-10-0-7.ec2.internal (10.10.0.7): icmp_seq=14 ttl=127 time=0.267 ms
.
.
(以下略)
.
.
一方、fioについては2回ほど書き込みができないタイミングが存在しました。
$ sudo fio \
--directory=/mnt/fsxz/ \
--name fio_rw_4MiB_block_4GiB_4jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=4M \
--size=4G \
--numjobs=4 \
--runtime=900 \
--eta-newline=5 \
--time_based=1 \
--group_reporting \
--norandommap
fio_rw_4MiB_block_4GiB_4jobs: (g=0): rw=randwrite, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=psync, iodepth=1
...
fio-3.32
Starting 4 processes
Jobs: 4 (f=4): [w(4)][0.8%][w=144MiB/s][w=36 IOPS][eta 14m:53s]
Jobs: 4 (f=4): [w(4)][1.4%][w=148MiB/s][w=37 IOPS][eta 14m:47s]
.
.
(中略)
.
.
Jobs: 4 (f=4): [w(4)][71.6%][w=104MiB/s][w=26 IOPS][eta 04m:16s]
Jobs: 4 (f=4): [w(4)][72.2%][w=120MiB/s][w=30 IOPS][eta 04m:10s]
Jobs: 4 (f=4): [w(4)][73.0%][w=120MiB/s][w=30 IOPS][eta 04m:03s]
Jobs: 4 (f=4): [w(4)][73.6%][eta 03m:58s]
Jobs: 4 (f=4): [w(4)][74.2%][eta 03m:52s]
Jobs: 4 (f=4): [w(4)][74.9%][eta 03m:46s]
Jobs: 4 (f=4): [w(4)][75.6%][eta 03m:40s]
Jobs: 4 (f=4): [w(4)][76.3%][eta 03m:33s]
Jobs: 4 (f=4): [w(4)][76.9%][eta 03m:28s]
Jobs: 4 (f=4): [w(4)][77.6%][eta 03m:22s]
Jobs: 4 (f=4): [w(4)][78.1%][w=160MiB/s][w=40 IOPS][eta 03m:17s]
Jobs: 4 (f=4): [w(4)][78.8%][w=148MiB/s][w=37 IOPS][eta 03m:11s]
.
.
(中略)
.
.
Jobs: 4 (f=4): [w(4)][96.7%][w=140MiB/s][w=35 IOPS][eta 00m:30s]
Jobs: 4 (f=4): [w(4)][97.4%][w=112MiB/s][w=28 IOPS][eta 00m:23s]
Jobs: 4 (f=4): [w(4)][98.0%][eta 00m:18s]
Jobs: 4 (f=4): [w(4)][98.7%][eta 00m:12s]
Jobs: 4 (f=4): [w(4)][99.3%][eta 00m:06s]
Jobs: 4 (f=4): [w(4)][100.0%][eta 00m:00s]
Jobs: 4 (f=4): [w(4)][100.0%][eta 00m:00s]
Jobs: 4 (f=4): [w(4)][100.0%][eta 00m:00s]
Jobs: 4 (f=4): [w(4)][100.0%][eta 00m:00s]
fio_rw_4MiB_block_4GiB_4jobs: (groupid=0, jobs=4): err= 0: pid=2766: Tue Sep 30 05:01:50 2025
write: IOPS=32, BW=130MiB/s (136MB/s)(116GiB/912961msec); 0 zone resets
clat (msec): min=16, max=40103, avg=121.48, stdev=601.66
lat (msec): min=16, max=40103, avg=121.78, stdev=601.66
clat percentiles (msec):
| 1.00th=[ 51], 5.00th=[ 69], 10.00th=[ 70], 20.00th=[ 70],
| 30.00th=[ 75], 40.00th=[ 81], 50.00th=[ 90], 60.00th=[ 101],
| 70.00th=[ 121], 80.00th=[ 140], 90.00th=[ 190], 95.00th=[ 241],
| 99.00th=[ 321], 99.50th=[ 342], 99.90th=[ 409], 99.95th=[ 460],
| 99.99th=[17113]
bw ( KiB/s): min=32768, max=335578, per=100.00%, avg=145454.65, stdev=11131.49, samples=6684
iops : min= 8, max= 81, avg=35.41, stdev= 2.72, samples=6684
lat (msec) : 20=0.01%, 50=1.05%, 100=58.69%, 250=35.89%, 500=4.33%
lat (msec) : 750=0.01%, >=2000=0.02%
cpu : usr=0.23%, sys=0.27%, ctx=29943, majf=0, minf=37
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,29674,0,0 short=0,1,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=130MiB/s (136MB/s), 130MiB/s-130MiB/s (136MB/s-136MB/s), io=116GiB (124GB), run=912961-912961msec
2回目については途中fioの実行が完了したので正確な時間は不明ですが、1回目のダウンタイムは45秒程度でした。60秒以内に収まっていますね。
スループットキャパシティを160MBpsに変更
もう一度計測してみましょう。
スループットキャパシティを160MBpsに変更します。
変更したタイミングは14:56:12です。
完了したタイミングは15:16:39でした。やはり20分でした。
> while true; do
echo "$(date +"%Y-%m-%d %H:%M:%S"): $(aws fsx describe-file-systems --file-system-ids fs-013e10b46352f967a --query 'FileSystems[0].OpenZFSConfiguration.ThroughputCapacity' --output text) MBps"
sleep 5
done
.
.
(中略)
.
.
2025-09-30 15:15:14: 320 MBps
2025-09-30 15:15:22: 320 MBps
2025-09-30 15:15:30: 320 MBps
2025-09-30 15:15:39: 160 MBps
2025-09-30 15:15:47: 160 MBps
2025-09-30 15:15:56: 160 MBps
2025-09-30 15:16:04: 160 MBps
この時のfioの結果は以下のとおりです。
$ sudo fio \
--directory=/mnt/fsxz/ \
--name fio_rw_4MiB_block_4GiB_4jobs \
--ioengine=psync \
--direct=1 \
--rw=randwrite \
--bs=4M \
--size=4G \
--numjobs=4 \
--runtime=1800 \
--eta-newline=5 \
--time_based=1 \
--group_reporting \
--norandommap
fio_rw_4MiB_block_4GiB_4jobs: (g=0): rw=randwrite, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=psync, iodepth=1
...
fio-3.32
Starting 4 processes
Jobs: 4 (f=4): [w(4)][0.4%][w=100MiB/s][w=25 IOPS][eta 29m:53s]
Jobs: 4 (f=4): [w(4)][0.7%][w=156MiB/s][w=39 IOPS][eta 29m:47s]
Jobs: 4 (f=4): [w(4)][1.1%][w=140MiB/s][w=35 IOPS][eta 29m:40s]
Jobs: 4 (f=4): [w(4)][1.4%][w=200MiB/s][w=50 IOPS][eta 29m:35s]
.
.
(中略)
.
.
Jobs: 4 (f=4): [w(4)][31.1%][w=172MiB/s][w=43 IOPS][eta 20m:40s]
Jobs: 4 (f=4): [w(4)][31.4%][w=200MiB/s][w=50 IOPS][eta 20m:34s]
Jobs: 4 (f=4): [w(4)][31.8%][w=180MiB/s][w=45 IOPS][eta 20m:28s]
Jobs: 4 (f=4): [w(4)][32.1%][w=200MiB/s][w=50 IOPS][eta 20m:21s]
Jobs: 4 (f=4): [w(4)][32.4%][w=76.0MiB/s][w=19 IOPS][eta 20m:16s]
Jobs: 4 (f=4): [w(4)][32.8%][eta 20m:10s]
Jobs: 4 (f=4): [w(4)][33.1%][eta 20m:04s]
Jobs: 4 (f=4): [w(4)][33.4%][eta 19m:58s]
Jobs: 4 (f=4): [w(4)][33.8%][eta 19m:51s]
Jobs: 4 (f=4): [w(4)][34.1%][eta 19m:46s]
Jobs: 4 (f=4): [w(4)][34.4%][eta 19m:40s]
Jobs: 4 (f=4): [w(4)][34.8%][eta 19m:34s]
Jobs: 4 (f=4): [w(4)][35.1%][w=136MiB/s][w=33 IOPS][eta 19m:28s]
Jobs: 4 (f=4): [w(4)][35.4%][w=176MiB/s][w=44 IOPS][eta 19m:22s]
Jobs: 4 (f=4): [w(4)][35.8%][w=28.0MiB/s][w=7 IOPS][eta 19m:16s]
Jobs: 4 (f=4): [w(4)][36.1%][w=16.0MiB/s][w=4 IOPS][eta 19m:11s]
Jobs: 4 (f=4): [w(4)][36.4%][w=20.0MiB/s][w=5 IOPS][eta 19m:05s]
.
.
(中略)
.
.
Jobs: 4 (f=4): [w(4)][45.0%][w=16.0MiB/s][w=4 IOPS][eta 16m:30s]
Jobs: 4 (f=4): [w(4)][45.3%][w=16.0MiB/s][w=4 IOPS][eta 16m:24s]
Jobs: 4 (f=4): [w(4)][45.7%][w=16.0MiB/s][w=4 IOPS][eta 16m:18s]
Jobs: 4 (f=4): [w(4)][46.0%][w=16.0MiB/s][w=4 IOPS][eta 16m:12s]
Jobs: 4 (f=4): [w(4)][46.3%][eta 16m:06s]
Jobs: 4 (f=4): [w(4)][46.7%][eta 16m:00s]
Jobs: 4 (f=4): [w(4)][47.0%][eta 15m:54s]
Jobs: 4 (f=4): [w(4)][47.4%][eta 15m:47s]
Jobs: 4 (f=4): [w(4)][47.7%][eta 15m:42s]
Jobs: 4 (f=4): [w(4)][48.0%][eta 15m:36s]
Jobs: 4 (f=4): [w(4)][48.3%][w=64.1MiB/s][w=16 IOPS][eta 15m:30s]
Jobs: 4 (f=4): [w(4)][48.7%][w=8200KiB/s][w=2 IOPS][eta 15m:23s]
Jobs: 4 (f=4): [w(4)][49.0%][w=4100KiB/s][w=1 IOPS][eta 15m:18s]
Jobs: 4 (f=4): [w(4)][49.3%][w=4100KiB/s][w=1 IOPS][eta 15m:12s]
Jobs: 4 (f=4): [w(4)][49.7%][w=12.0MiB/s][w=3 IOPS][eta 15m:06s]
.
.
(中略)
.
.
Jobs: 4 (f=4): [w(4)][67.3%][w=8200KiB/s][w=2 IOPS][eta 09m:48s]
Jobs: 4 (f=4): [w(4)][67.6%][w=4100KiB/s][w=1 IOPS][eta 09m:43s]
^Cbs: 4 (f=4): [w(4)][67.8%][w=12.0MiB/s][w=3 IOPS][eta 09m:39s]
fio: terminating on signal 2
Jobs: 3 (f=3): [w(1),_(1),f(1),w(1)][67.8%][w=8192KiB/s][w=2 IOPS][eta 09m:39s]
fio_rw_4MiB_block_4GiB_4jobs: (groupid=0, jobs=4): err= 0: pid=11127: Tue Sep 30 06:16:33 2025
write: IOPS=20, BW=80.9MiB/s (84.8MB/s)(96.4GiB/1220159msec); 0 zone resets
clat (msec): min=12, max=46890, avg=189.56, stdev=630.62
lat (msec): min=13, max=46891, avg=189.85, stdev=630.62
clat percentiles (msec):
| 1.00th=[ 47], 5.00th=[ 68], 10.00th=[ 70], 20.00th=[ 70],
| 30.00th=[ 70], 40.00th=[ 80], 50.00th=[ 81], 60.00th=[ 100],
| 70.00th=[ 112], 80.00th=[ 140], 90.00th=[ 239], 95.00th=[ 827],
| 99.00th=[ 2165], 99.50th=[ 2500], 99.90th=[ 3171], 99.95th=[ 3373],
| 99.99th=[17113]
bw ( KiB/s): min=28638, max=393216, per=100.00%, avg=128372.47, stdev=17294.67, samples=6297
iops : min= 5, max= 96, avg=31.26, stdev= 4.21, samples=6297
lat (msec) : 20=0.16%, 50=1.76%, 100=62.16%, 250=26.55%, 500=3.16%
lat (msec) : 750=0.50%, 1000=2.34%, 2000=1.79%, >=2000=1.56%
cpu : usr=0.14%, sys=0.16%, ctx=24949, majf=0, minf=41
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,24681,0,0 short=0,5,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=80.9MiB/s (84.8MB/s), 80.9MiB/s-80.9MiB/s (84.8MB/s-84.8MB/s), io=96.4GiB (103GB), run=1220159-1220159msec
今回も2回ダウンタイムが発生し、いずれも40秒から50秒程度のダウンタイムでした。
CloudWatchメトリクスでファイルシステムへのIOPSを確認したところ、フェイルオーバーのタイミングのデータポイントが存在しないことが分かります。
フェイルオーバーが発生したかどうか後追いをしたい場合に役立ちそうです。
ちなみにCloudTrailでModifyNetworkInterfaceAttributeやFSxZのENIについてのイベントを確認しましたが、該当するイベントはありませんでした。要するに、セカンダリIPアドレスの付け替えをしている様子は確認できませんでした。
Single-AZでもメンテナンスや単一ノード障害に対する耐性が欲しい場合に
Amazon FSx for OpenZFSのSingle-AZ HAのフェイルオーバー時間を確認してみました。
Single-AZでもメンテナンスや単一ノード障害に対する耐性が欲しい場合にはSingle-AZ HAでデプロイすると良いでしょう。
また、スループットキャパシティの変更をする際やメンテナンスウィンドウを設定する場合はダウンタイムの時間を把握しておきたいですね。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
