FSx for OpenZFSのストレージ容量使用率をパーセンテージでアラーム通知する
はじめに
みなさんこんにちは、クラウド事業本部コンサルティング部の浅野です。
Amazon FSx for OpenZFSではストレージ容量をあらかじめプロビジョニングする必要があり、容量が逼迫した際にはCloudWatch Alarm等で通知を受け取り、運用者がストレージ容量を拡張する対応が必要です。
ただし、アラームの閾値を絶対値(Byte)で設定していると、ストレージ容量を変更するたびにCloudWatch Alarmも合わせて更新しなければならず、二重管理の手間が生じます。
理想的には、計算式を用いてアラームの閾値をパーセンテージで定義することで、ストレージ容量が変わってもアラーム設定を変更しなくて済む運用を実現したいです。
本記事では、FSx for OpenZFSのストレージ使用率を計算式(Metric Math)で定義し、ストレージ容量を更新した後もアラームが適切に機能するか確認してみます。
構成
以下の構成でストレージ容量を監視し、メール通知を設定しました。

今回は検証に必要な下記のリソースをCDKを用いて用意しました。
- VPC
- CIDR: 192.168.0.0/24
- サブネット: プライベート(Isolated)サブネット×1
- VPCエンドポイント
- SSM / SSM Messages(インターフェース型)
- S3(ゲートウェイ型)
- セキュリティグループ
- VPCエンドポイント用(HTTPS: 443)
- EC2用(アウトバウンド全許可)
- FSx用(EC2からのNFSポート: 111, 2049, 20001-20003)
- FSx for OpenZFS
- デプロイメントタイプ: SINGLE_AZ_2
- 初期ストレージ容量: 64GiB
- スループット: 160 MB/s
- 圧縮: LZ4
- 自動バックアップ: 無効
- EC2
- OS: Amazon Linux 2023
- インスタンスタイプ: t3.micro
- EBS: 20GiB(gp3)
- SSM Session Manager経由で接続
- SNSトピック
- ストレージアラームの通知先(サブスクリプション・アラーム設定はコンソールから)
CDKスタック
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as fsx from 'aws-cdk-lib/aws-fsx';
import * as iam from 'aws-cdk-lib/aws-iam';
import * as sns from 'aws-cdk-lib/aws-sns';
export class DemoFsxStorageAlarmStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// VPC
const vpc = new ec2.Vpc(this, 'FsxStorageAlarmVpc', {
ipAddresses: ec2.IpAddresses.cidr('192.168.0.0/24'),
maxAzs: 1,
natGateways: 0,
restrictDefaultSecurityGroup: false,
subnetConfiguration: [
{
cidrMask: 26,
name: 'Private',
subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
},
],
});
// VPCエンドポイント用セキュリティグループ
const vpcEndpointSg = new ec2.SecurityGroup(this, 'VpcEndpointSg', {
vpc,
description: 'Security group for VPC Endpoints',
allowAllOutbound: true,
});
vpcEndpointSg.addIngressRule(
ec2.Peer.ipv4(vpc.vpcCidrBlock),
ec2.Port.tcp(443),
'Allow HTTPS from VPC'
);
// SSM用VPCエンドポイント
vpc.addInterfaceEndpoint('SsmEndpoint', {
service: ec2.InterfaceVpcEndpointAwsService.SSM,
subnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
securityGroups: [vpcEndpointSg],
});
vpc.addInterfaceEndpoint('SsmMessagesEndpoint', {
service: ec2.InterfaceVpcEndpointAwsService.SSM_MESSAGES,
subnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
securityGroups: [vpcEndpointSg],
});
// S3ゲートウェイエンドポイント
vpc.addGatewayEndpoint('S3Endpoint', {
service: ec2.GatewayVpcEndpointAwsService.S3,
subnets: [{ subnetType: ec2.SubnetType.PRIVATE_ISOLATED }],
});
// EC2用セキュリティグループ
const ec2Sg = new ec2.SecurityGroup(this, 'Ec2Sg', {
vpc,
securityGroupName: 'fsx-storage-alarm-ec2-sg',
description: 'Security group for EC2',
allowAllOutbound: true,
});
// FSx用セキュリティグループ
const fsxSg = new ec2.SecurityGroup(this, 'FsxSg', {
vpc,
securityGroupName: 'fsx-storage-alarm-sg',
description: 'Security group for FSx Storage Alarm',
allowAllOutbound: false,
});
// EC2からのNFSアクセス許可
fsxSg.addIngressRule(ec2Sg, ec2.Port.tcp(111), 'NFS RPC');
fsxSg.addIngressRule(ec2Sg, ec2.Port.tcp(2049), 'NFS');
fsxSg.addIngressRule(ec2Sg, ec2.Port.tcpRange(20001, 20003), 'NFS mount/status/lock');
// FSx for OpenZFS(SINGLE_AZ_2 最小構成)
const fileSystem = new fsx.CfnFileSystem(this, 'FsxOpenzfs', {
fileSystemType: 'OPENZFS',
storageCapacity: 64,
subnetIds: [vpc.isolatedSubnets[0].subnetId],
securityGroupIds: [fsxSg.securityGroupId],
openZfsConfiguration: {
deploymentType: 'SINGLE_AZ_2',
throughputCapacity: 160,
rootVolumeConfiguration: {
dataCompressionType: 'LZ4',
nfsExports: [
{
clientConfigurations: [
{
clients: '192.168.0.0/24',
options: ['rw', 'async', 'crossmnt', 'no_root_squash'],
},
],
},
],
},
automaticBackupRetentionDays: 0,
},
tags: [
{
key: 'Name',
value: 'fsx-storage-alarm',
},
],
});
// EC2(Amazon Linux 2023 / SSM接続用)
new ec2.Instance(this, 'Ec2', {
vpc,
vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),
machineImage: ec2.MachineImage.latestAmazonLinux2023(),
securityGroup: ec2Sg,
role: new iam.Role(this, 'Ec2Role', {
assumedBy: new iam.ServicePrincipal('ec2.amazonaws.com'),
managedPolicies: [
iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),
],
}),
blockDevices: [
{
deviceName: '/dev/xvda',
volume: ec2.BlockDeviceVolume.ebs(20, {
volumeType: ec2.EbsDeviceVolumeType.GP3,
}),
},
],
});
// SNSトピック(アラーム通知先 / サブスクリプション・アラーム設定はコンソールから)
new sns.Topic(this, 'FsxStorageAlarmTopic', {
topicName: 'fsx-storage-alarm-topic',
});
}
}
やってみた
上記CDKスタックをデプロイしました。
作成したSNSトピックのサブスクリプション登録から通知したいメールアドレスを手動で登録します。
手順は割愛します。以下のようにSNSトピックにメールアドレスがサブスクリプション登録できたら終了です。

CloudWatch Alarmの作成
今回は、マネジメントコンソールからストレージ使用率を監視するための計算式を含んだCloudWatch Alarmを作成します。
まず「CloudWatch」コンソールから「アラーム」>「アラームの作成」を選択します。

「メトリクスの選択」を押下し、名前空間「FSx」を選択します。


「ファイルシステムメトリクス」を選択します。

CDKで作成した「ファイルシステムID」の「UsedStorageCapacity」と「StorageCapacity」を選択し、「グラフ化したメトリクス」へ移動します。

「数式を追加」から「一般」>「パーセンテージ」を選択すると先ほど選択した「UsedStorageCapacity」と「StorageCapacity」を元にパーセンテージに変換する計算式が自動で適用されます。

この時、計算式が以下のように「100 x (使用済みストレージ容量 / ストレージ容量)」となるように注意してください。
e1 = 100 × m1 (UsedStorageCapacity) / m2 (StorageCapacity)
| ID | メトリクス名 | 統計 | 期間 |
|---|---|---|---|
| m1 | UsedStorageCapacity | Average | 5分 |
| m2 | StorageCapacity | Average | 5分 |
※ 「m1」と「m2」が逆になっていないか要確認し、任意で上記の計算式「式1」にラベルを付与できます。
適切に計算式が適用されたら「メトリクスの選択」を選択します。

選択した計算式に対して以下の設定でアラームを作成します。
- 計算式ラベル: FSx for OpenZFS ストレージ使用率(パーセント)
- 期間: 5分
- しきい値の種類: 静的
- アラーム条件: 以上(>=)
- しきい値: 10 (10%を意味する)
- その他の設定
- アラームを実行するデータポイント: 3 / 3
- 欠落データの処理: 欠落データを見つかりませんとして処理
今回は最低「15分」以上の監視を行ってからアラームを発火する構成にしています。

最後にアラームアクションを作成したSNSトピック宛に通知するように設定し、アラーム名称を適宜付与して作成すれば終了です。
- アラーム状態トリガー: アラーム状態
- 次のSNSトピックに通知を送信: 既存のSNSトピックを選択
- 通知の送信先: {CDKで作成したSNSトピックを選択}
- Eメール(エンドポイント): サブスクリプション登録したメールアドレスが表示されているか確認
- アラーム名称: 任意(今回は 「demo-fsx-alarm」に設定)

FSx マウント & データ追加
CloudWatchアラームの作成と通知構成が作成できたので、EC2にSSM接続してデータを追加します。
# マウント用ディレクトリ作成
sudo mkdir -p /mnt/fsx
# FSxをマウント(DNS名は実際の値に置き換え)
sudo mount -t nfs -o nfsvers=4.1 {FSxのDNS名}:/fsx /mnt/fsx
# マウント確認
df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 459M 0 459M 0% /dev/shm
tmpfs 184M 416K 183M 1% /run
/dev/nvme0n1p1 20G 1.8G 19G 9% /
tmpfs 459M 0 459M 0% /tmp
/dev/nvme0n1p128 10M 1.3M 8.7M 13% /boot/efi
tmpfs 92M 0 92M 0% /run/user/0
fs-07761954ddb3710b8.fsx.ap-northeast-1.amazonaws.com:/fsx 64G 0 64G 0% /mnt/fsx
64GiBのファイルシステムがマウントされました。
続いて以下のコマンドでテストデータを7GiB追加してみます。
# ランダムデータで7GiBのファイルを生成
sudo dd if=/dev/urandom of=/mnt/fsx/testdata bs=1M count=7168 status=progress
7402946560 bytes (7.4 GB, 6.9 GiB) copied, 31 s, 239 MB/s
7168+0 records in
7168+0 records out
7516192768 bytes (7.5 GB, 7.0 GiB) copied, 31.8958 s, 236 MB/s
# データ追加後の使用量を確認
df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 459M 0 459M 0% /dev/shm
tmpfs 184M 408K 183M 1% /run
/dev/nvme0n1p1 20G 1.8G 19G 9% /
tmpfs 459M 0 459M 0% /tmp
/dev/nvme0n1p128 10M 1.3M 8.7M 13% /boot/efi
fs-07761954ddb3710b8.fsx.ap-northeast-1.amazonaws.com:/fsx 64G 7.1G 57G 11% /mnt/fsx
上記にてデータを追加してストレージ使用率が「10%」を超えたことが確認できました。
CloudWatch アラームが発火されるのを待ちます。
CloudWatch アラームの確認
以下のタイムフローでストレージ使用量のアラームが確認できました。
- 10:25(UTC): データ追加開始
- 10:33(UTC): ストレージ容量10%超過
- 10:48(UTC): アラームアクション
- 10:48(UTC): メールアドレス宛に通知
以下のようにアラームの発火が確認できました。

また、メール本文は以下の通りです。

ストレージ容量の更新
上記のアラームを受けてFSx for OpenZFSのストレージ容量を更新します。
64GiB -> 75GiBに更新します。
マネジメントコンソールから「FSx」>「ファイルシステム」>「作成したファイルシステム」を選択して、
「アクション」>「ストレージ容量を更新」を選択します。

今回は絶対値指定を行うので、「入力タイプ」を「Absolute」に選択し「75GiB」を指定して、更新します。

更新すると「作成したファイルシステム」の詳細画面から「更新」タブを開くと「ストレージキャパシティ」と「IOPSモード」が「進行中」ステータスで表示されており、更新中であることが確認できます。

しばらく待ち、ステータスが「完了済み」になったらストレージ容量の更新が完了です。

CloudWatch アラームの画面でもストレージ容量を変更したことにより、「アラーム」状態から「OK」になったことが確認できました。

ストレージ容量を更新してから再度アラームを発火
EC2内に戻り、容量更新後のストレージ使用状況を確認してみます。
# ストレージ更新後の使用量を確認
df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 459M 0 459M 0% /dev/shm
tmpfs 184M 408K 183M 1% /run
/dev/nvme0n1p1 20G 1.8G 19G 9% /
tmpfs 459M 0 459M 0% /tmp
/dev/nvme0n1p128 10M 1.3M 8.7M 13% /boot/efi
fs-07761954ddb3710b8.fsx.ap-northeast-1.amazonaws.com:/fsx 75G 7.1G 68G 10% /mnt/fsx
アラームを再度発火させるためにデータを追加します。
# データを「1GiB」追加する
sudo dd if=/dev/urandom of=/mnt/fsx/testdata bs=1M count=1024 status=progress
844103680 bytes (844 MB, 805 MiB) copied, 3 s, 281 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.93001 s, 273 MB/s
# 使用状況を確認
df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 459M 0 459M 0% /dev/shm
tmpfs 184M 408K 183M 1% /run
/dev/nvme0n1p1 20G 1.8G 19G 9% /
tmpfs 459M 0 459M 0% /tmp
/dev/nvme0n1p128 10M 1.3M 8.7M 13% /boot/efi
fs-07761954ddb3710b8.fsx.ap-northeast-1.amazonaws.com:/fsx 75G 8.1G 67G 11% /mnt/fsx
再度使用率が「10%」を超過したので、以下のようにアラームが発火し、再度メール通知が行われたことが確認できました。


最後に
今回はCloudWatch Alarmを使用してFSx for OpenZFSのストレージ使用率をパーセンテージで監視し、ストレージ容量を更新した後もアラームが適切に機能することを確認しました。
絶対値(Byte)での閾値指定では、ストレージ容量を変更するたびにアラーム設定も更新する必要がありますが、計算式でパーセンテージを定義することで、その手間を省くことができます。FSx for OpenZFSのストレージ監視を検討されている方の参考になれば幸いです。
今回は以上です。







