コーヒーが好きな 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 へのデータコピーが行われているようです。詳しくは以下ブログを参照ください。
ボリュームサイズをどれくらい増やすか
さて、ボリュームサイズが足りないことが分かったので、どれくらいボリュームサイズを増やすか計算してみましょう。
ユーザーデータが占める割合 + スナップショット領域の 5% < 98%
となればいいので、少し余裕をもって
ユーザーデータが占める割合 80% + スナップショット領域 5% ≒ 85%
としてみましょうか。
- 計算式
- ボリュームサイズ：ユーザーデータが占める割合（今回は LUN に割り当てる容量）= 100%：80%
- x：150GiB = 1：0.8
- x = 150/0.8 = 187.5GiB
よって、187GiB くらいに増やしてみようと思います。
ボリュームサイズを 187GiB に増やすと、計算上は以下のような状態になるはずです。
ボリュームサイズを増やす
今回はマネジメントコンソールからボリュームサイズを増やしてみます。
ボリュームの詳細画面で [アクション] - [ボリュームを更新] をクリックします。
ボリュームサイズを 187GiB にして、その他の項目は変更せず「更新」をクリックします。
更新中の青いバーが表示されます。
ブラウザを再読み込みすると、ボリュームサイズがすぐに 187GiB に更新されました。
モニタリングタブで使用可能なストレージ容量を見ると、使用可能なストレージ容量がグッと増えています。
ストレージディストリビューションからも、使用可能なボリューム容量が 14.47% まで増えていることが分かります。
ボリュームに格納できるファイル数に関するメトリクスである inode も増えています。
手動バックアップが成功することを確認する
ボリュームサイズの拡張が完了しましたので、手動でバックアップを取得し成功するかどうか確認します。
ボリュームの詳細画面で [アクション] - [バックアップを作成] をクリックします。
バックアップ名を入力し、「バックアップを作成」をクリックします。
青いバーでバックアップの作成中ステータスであることが表示されます。
今回は 6 分程度待つと、バックアップの取得が完了しました。
バックアップタブではボリュームのサイズが 160GiB のままですね。画面上部のボリューム詳細画面では 187GiB になっています。マネジメントコンソール上で反映されるまで少し時間がかかるのかもしれません。
ちなみに、ボリュームサイズの拡張とバックアップ取得をおこないましたが、LUN のサイズは変えていないので、Windows Server からの見え方は 150GiB のまま変わりありません。
おわりに
FSxN のバックアップは
ユーザーデータが占める割合 + スナップショット領域の 5% > 98%
だと失敗することと、ボリュームを適切にサイジングすることでバックアップを正常取得できるようにする手順を紹介してきました。
どなたかのお役に立てば幸いです。
3
