FSx for NetApp ONTAP を iSCSI で利用する際のボリュームサイジングを考える～バックアップ取得とスナップショット領域を加味する

ボリュームのバックアップは「ユーザーデータが占める割合 + スナップショット領域の 5% > 98%」だと失敗します。iSCSI 接続しているとクライアント側からは空きがあるように見えるので、ちょっとややこしく感じました。

#Amazon FSx for NetApp ONTAP

#AWS

emi

2024.01.31

コーヒーが好きな emi です。

先日以下のブログで、FSx for NetApp ONTAP（以下、FSxN と省略）において「ボリュームサイズが足りないためにバックアップ取得に失敗する」事象と「Volume Full Threshold Percent を 100% にする」対処方法を記載しました。

本ブログでは、ボリュームサイズを増やすことによってバックアップ取得を可能にする対処方法と、FSxN を iSCSI で利用する際のボリュームサイジングについて記載します。

バックアップ可能なボリュームサイジング

ユーザーデータが占める割合 + スナップショット領域の 5% > 98%
だとバックアップに失敗します。

ボリュームスナップショットのために追加で消費される容量によってボリュームの使用率が 98% を超える場合は、バックアップスナップショットを作成することはできません。
バックアップの使用 - FSx for ONTAP

スナップショット領域の 5% は「Space Reserved for Snapshot Copies」や「Snapshot reserve」と表記されていることもあります。

FSxN でのボリュームのデプロイはシンプロビジョニングの仕組みであり、ボリュームサイズを大きくすること自体には料金がかかりません。詳細は以下ブログを参照ください。

ですので厳密にサイジングしなくても、あとから増やしたり減らしたりできます。

ボリュームサイズが足りなくてバックアップがエラーになっている状態を確認する

さて、冒頭で紹介したブログでも同じ事象を扱いましたが、再度エラー内容を確認してみましょう。

FSxN は以下の図のような構成でデプロイしていて、3 つの LUN は Windows Server に iSCSI 接続しています。FSxN を iSCSI 接続する手順については FSx for NetApp ONTAP に Windows Server で iSCSI 接続してみた | DevelopersIO を参照ください。

Windows Server に iSCSI 接続した直後は以下のようにディスクがオフラインになっています。

オンラインにしてフォーマットすると少し容量に誤差が出ます。

エクスプローラーから見ると、それぞれのボリュームがほぼ空き状態で見えます。

特に注目していただきたいのが、ボリューム名に「vol2」と含まれている 160GiB のボリュームです。150GiB の LUN を作成したので、Windows Server からは 150GiB の E ドライブとして見えています。
「vol2」は 160GiB でデプロイしており、その中で 150GiB の LUN を作成して iSCSI 接続しています。
この「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）

メトリクスを見てみます。ボリューム詳細を開き、モニタリングタブで「ストレージディストリビューション」を拡大します。

青の部分がユーザーデータで、ボリュームの 94.12% を占有しています。

左下の凡例で青の「ユーザーデータ」をクリックすると、ユーザーデータは Byte 単位で表示されていることが分かります。
161,695,449,088 Byte は約 150GiB なので、LUN としてデプロイした分がユーザーデータとして表示されているということが分かります。

オレンジの部分がスナップショットデータ領域です。スナップショットデータ領域はデフォルトで 5% に固定されています。

デフォルトのSnapshotコピーリザーブは、FlexVolの場合はディスクスペースの5%
Snapshotコピーリザーブとは
ボリュームのプロビジョニング中に Snapshot が無効になっている場合でも、 Snapshot リザーブは 5% に設定されます。
スナップショットが無効になっていても、 NAS ボリュームのスナップショット予約が 5% に設定されるのはなぜですか？ - NetApp

今回はボリュームサイズが 160GiB なので、160GiB × 0.05（5%）= 8GiB がスナップショット領域として確保されているというわけです。

緑の部分が使用可能なボリューム容量です。0.88% となっており、ごくわずかです。

その他のデータ領域がごくわずかに存在していますが、グラフに表示されないほどわずかです。システムが使用する領域なのかもしれません。

さて、確認してきた vol2 の状況を図で表してみると以下のような状態です。

バックアップ可能なボリュームサイジングで言及した通り、ボリュームの使用率が 98% を超えているとバックアップが取得できません。
iSCSI 接続していると Windows Server（クライアント）側からは 150GiB 空きのように見えるので、ちょっとややこしいなと思ったところです。

ちなみにボリュームのバックアップはボリュームの中に取得されるわけではないため、二倍の容量を確保する必要はありません。あくまでバックアップの操作をする際にボリューム容量に余裕がないとエラーになる、という事象です。
FSxN のバックアップは裏で SnapMirror による S3 へのデータコピーが行われているようです。詳しくは以下ブログを参照ください。