コーヒーが好きな emi です。
以下のブログで、FSx for NetApp ONTAP（以降 FSxN と省略）に Windows Server で iSCSI 接続し、バックアップからボリュームをリストアしました。
この検証の際、ボリューム容量が足りずバックアップに一度失敗しました。その際の事象の確認結果と対処方法を記載します。
先に対処方法を確認したい方は 対処方法 をご覧ください。
事象とエラーメッセージ
こちらのブログ で E ドライブに相当する「fsxn_vol2」の手動バックアップを作成しようとした際、ボリューム容量が足りず一度失敗しました。
失敗したバックアップのライフサイクルの状態を確認すると、以下のように失敗メッセージが出ていました。
Amazon FSx could not create a backup of your volume because the volume is full. Please try again after increasing the size of the volume or freeing up space. For more information, please see the Amazon FSx user guide: https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/troubleshooting.html
（機械翻訳：ボリュームがいっぱいのため、Amazon FSxはボリュームのバックアップを作成できませんでした。ボリュームのサイズを増やすか、空き領域を確保してから再試行してください。詳細については、Amazon FSxユーザーガイドをご覧ください： https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/troubleshooting.html）
ボリュームの詳細確認
ボリュームがいっぱいであると記載されていますが、FSxN のボリュームである D ドライブ（fsxn_vol1）も E ドライブ（fsxn_vol2）もテスト用ファイルしか格納しておらず余裕があるように見えます。
volume show コマンドで確認してみます。
実行コマンド
volume show -volume fsxn_vol2 -fields size, available, used, percent-used実行結果
FsxId003039c51be2092f8::> volume show -volume fsxn_vol2 -fields size, available, used, percent-used
vserver volume size available used percent-used
--------------- --------- ----- --------- ------- ------------
sample-fsxn-svm fsxn_vol2 160GB 1.41GB 150.6GB 99%
FsxId003039c51be2092f8::>- size（ボリュームに割り当てたサイズ）：160GB
- available（利用可能容量）：1.41GB
- used（使用中容量）：150.6GB
- percent-used（ボリューム使用率）：99%
イメージは以下のような状態です。
原因の予測
E ドライブ（fsxn_vol2）はボリュームサイス 160GB でデプロイしていますが、iSCSI マウントする前に LUN を150GB で作成したのでその LUN の分がボリューム容量を確保してしまっています。
ユーザーからは空きがあるように見えますが、FSxN からは満タンに見えている状態です。
ちなみにボリュームのバックアップはボリュームの中に取得されるわけではないため、二倍の容量を確保する必要はありません。あくまでバックアップの操作をする際にボリューム容量に余裕がないとエラーになる、という事象のようです。
FSxN ボリュームのバックアップは裏で SnapMirror による S3 へのデータコピーが行われているようです。詳しくは以下ブログを参照ください。
バックアップ失敗の原因や背景の詳細は以下ブログの「原因と対処方法」をご参照ください。
2024/1/30 追記：以前は SSD ストレージ容量の不足であると記載していましたが、誤りでした。 iSCSI 接続のために LUN を構築する場合、LUN として確保した 150 GiB（≒93.8%） の領域が Used Size（使用中容量）に含まれ、更に Space Reserved for Snapshot Copies（スナップショット領域）が 5%（≒8GiB）加算され、合計 98.8% 利用中の状態になります。これにより Volume Full Threshold Percent のデフォルト値である 98% を上回り、後述の EMS エラーでバックアップが失敗した、という経緯です。
対処方法
「ボリュームがいっぱいでバックアップが取得できない」事象の対処法としては以下 3 つがあります。
1. ボリュームを適切にサイジングする
2. Volume Full Threshold Percent を 100% にする
3. SSD の空き容量を増やす
今回は 2. Volume Full Threshold Percent を 100% にするで対応します。
Volume Full Threshold Percent を 100% にする
「Volume Full Threshold Percent（ボリュームがフル閾値パーセント）」は、ボリュームがいっぱいであると判断される割合を示し、それを超えるとクリティカルな EMS エラーが生成される割合を示します。デフォルトの Volume Full Threshold Percent 値は 98% です。
EMS とは、NetApp ONTAP ネイティブの Events Management System（EMS）のことです。
Volume Full Threshold Percent を 100% にすることで、ボリュームがいっぱいになったことを EMS で検知しない（100% を超えることはないため）ようにする、という方法であると考えられます。
この方法は以下 re:Post で紹介されているものです。
EMS エラーが出ていなければ、ボリュームが満タンであってもバックアップができてしまうんですね。これでいいのかちょっと不思議ですが、ドキュメントに従いましょう。
では、Volume Full Threshold Percent を確認します。
volume show -volume fsxn_vol2 -fields space-full-threshold-percent実行結果
FsxId003039c51be2092f8::> volume show -volume fsxn_vol2 -fields space-full-threshold-percent
vserver volume space-full-threshold-percent
--------------- --------- ----------------------------
sample-fsxn-svm fsxn_vol2 98%
FsxId003039c51be2092f8::>space-full-threshold-percent が 98% になっています。
では、Volume Full Threshold Percent を 100% に変更します。
コマンド構文
vol modify -vserver <svm\_name> -volume <vol\_name> -space-full-threshold-percent 100実行コマンド
vol modify -vserver sample-fsxn-svm -volume fsxn_vol2 -space-full-threshold-percent 100実行結果
FsxId003039c51be2092f8::> vol modify -vserver sample-fsxn-svm -volume fsxn_vol2 -space-full-threshold-percent 100
Volume modify successful on volume fsxn_vol2 of Vserver sample-fsxn-svm.
FsxId003039c51be2092f8::>Volume Full Threshold Percent が 100% に変更されたことを確認します。
volume show -volume fsxn_vol2 -fields space-full-threshold-percent実行結果
FsxId003039c51be2092f8::> volume show -volume fsxn_vol2 -fields space-full-threshold-percent
vserver volume space-full-threshold-percent
--------------- --------- ----------------------------
sample-fsxn-svm fsxn_vol2 100%
FsxId003039c51be2092f8::>Volume Full Threshold Percent が 100% になっているのがわかります。
この状態でバックアップを再作成すると、うまくいきます。
「fsxn_vol2_bk_202310040543」という名前で作成したバックアップが成功しました。
補足：「3. SSD の空き容量を増やす」について
今回のケースではボリュームサイズの上限に引っかかっていますので、「3. SSD の空き容量を増やす」だけでは事象は改善されません。
おわりに
SSD ストレージ容量が足りないとバックアップが取得できない事象について、エラーメッセージの確認や対処を実施しました。どなたかのお役に立てば幸いです。
3
