この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
リストアするときは直接キャパシティプールストレージに書き込まれるのか気になる
こんにちは、のんピ(@non____97)です。
皆さんは階層化ポリシーがALLのAmazon FSx for ONTAPのボリュームをリストアしたときに、データが直接キャパシティプールストレージに書き込まれるのか気になったことはありますか? 私はあります。
以下記事で階層化ポリシーをALLにしていても、データは直接キャパシティプールストレージに書き込まれるのではなく、一旦プライマリストレージを経由することを紹介しました。
それでは、ボリュームをリストアする際はどうでしょう。
もし、ボリュームをリストアする際もプライマリストレージに一度書き込まれるのであれば、リストア時はかなり注意を払う必要があります。
例えば、階層化ポリシーがALLのボリュームに重複排除やデータ圧縮済みで50TBのデータを含む場合、このボリュームをプライマリストレージの空き容量が1TBのFSx for ONTAPファイルシステムにリストアするとなった場合は、プライマリストレージの空き容量を一気に消費してしまいます。
これは困りますね。
実際にそのような挙動をするのか検証してみました。
いきなりまとめ
- 階層化ポリシーが
ALLで全てのデータがキャパシティプールストレージにあるボリュームをリストアする場合でも、必ず一度プライマリストレージに書き込みが発生する - リストアするボリュームのキャパシティプールストレージに保存していたデータの総量が、リストア先のFSx for ONTAPのファイルシステムのプライマリストレージの空き容量を超えている場合、リストアに失敗する可能性がある
- リストア対象のボリュームにQoSポリシーを設定したとしても、リストア時に自動でQoSポリシーが割り当てられないため、帯域制御できない
- キャパシティプールストレージに大量のデータが書き込まれていたボリュームが複数ある場合、一斉にボリュームをリストアしてはならない
- 1ボリュームに大量のデータを保存するのではなく、複数のボリュームに分散させるのも手
検証環境
検証環境は以下の通りです。
階層化ポリシーをALLにして、データが全てがキャパシティプールストレージに書き込まれたことを確認してからボリュームをバックアップ・リストアします。
ボリュームをリストアした際、リストアされたデータが一旦プライマリストレージを経由するのか、それともキャパシティプールストレージに直接書き込まれるのかを確認します。
リソースは全てAWS CDKでデプロイします。以下記事の検証で使用したコードを再利用しています。
リポジトリはこちらです。
再利用するにあたって、ボリュームサイズと階層化ポリシーを変更しています。
./lib/fsx-for-ontap-stack.ts
// FSX for ONTAP volume
const volumeName = "fsx_for_ontap_volume_nfs";
const junctionPath = "/nfs";
new fsx.CfnVolume(this, "NFS Volume", {
name: volumeName,
ontapConfiguration: {
junctionPath,
sizeInMegabytes: "102400",
storageEfficiencyEnabled: "true",
storageVirtualMachineId: svm.ref,
securityStyle: "UNIX",
tieringPolicy: {
name: "ALL",
},
},
tags: [
{
key: "Name",
value: "fsx_for_ontap_volume_nfs",
},
],
volumeType: "ONTAP",
});テスト用ファイルの書き込み
それでは、EC2インスタンスからバックアップ・リストアのテストで使うファイルを書き込みます。
$ df -ht nfs4
Filesystem Size Used Avail Use% Mounted on
svm-0eb0473419837ab9d.fs-0cd2f70958932a1ca.fsx.us-east-1.amazonaws.com:/nfs 95G 256K 95G 1% /mnt/fsx
$ sudo dd if=/dev/urandom of=/mnt/fsx/testfile_1 bs=1M count=30720
30720+0 records in
30720+0 records out
32212254720 bytes (32 GB) copied, 248.588 s, 130 MB/s
$ df -ht nfs4
Filesystem Size Used Avail Use% Mounted on
svm-0eb0473419837ab9d.fs-0cd2f70958932a1ca.fsx.us-east-1.amazonaws.com:/nfs 95G 31G 65G 33% /mnt/fsx
$ ls -l /mnt/fsx/
total 31581132
-rw-r--r-- 1 nobody nobody 32212254720 Sep 25 08:42 testfile_14分ほど待つと、30GBのテストファイルが作成できました。
このボリュームのプライマリストレージとキャパシティプールストレージの使用量をCloudWatch メトリクスから確認します。
書き込み始めたタイミングでプライマリストレージの使用量の青いグラフが上昇し、その後下降しています。そして、下降したタイミングでキャパシティプールストレージの使用量のオレンジのグラフが大幅に上昇しています。
数分でテストファイル30GB全てのデータブロックがプライマリストレージからキャパシティプールストレージに移動することが確認できました。
ボリュームのバックアップ
テスト用ファイルを書き込んだボリュームのバックアップをします。
今回はAWS Backupではなく、FSxのコンソールから行います。AWS Backupを使ったボリュームのバックアップ方法は以下記事をご覧ください。
FSxのコンソールから対象のボリュームを選択し、アクション-バックアップの作成をクリックします。
バックアップの名前を入力し、バックアップの作成をクリックします。
数分待つと、バックアップのライフサイクルの状態が利用可能になりました。
ボリュームのリストア
ボリュームのバックアップを使ってリストアします。
バックアップを選択し、アクション-バックアップを復元をクリックします。
ボリューム名とジャンクションパスを入力してConfirmをクリックします。ボリュームサイズやストレージ効率のパラメーターは既に入力、設定されていました。
数分待つとボリュームがリストアできました。
それでは、リストアされたボリュームのプライマリストレージとキャパシティプールストレージの使用量をCloudWatch メトリクスから確認します。
メトリクスの描画が始まったタイミングからプライマリストレージの使用量の緑のグラフが15GB程度を差しています。その後は一時上昇して最終的には下降しています。そして、下降したタイミングでキャパシティプールストレージの使用量の赤のグラフが上昇しています。
どうやら、階層化ポリシーがALLで全てのデータがキャパシティプールストレージにあるボリュームをリストアする場合でも、必ず一度プライマリストレージに書き込みが発生するようですね。
リストア元のボリュームに対してQoSで帯域制御をかける
対応策を考えます。
CloudWatch メトリクスを確認するに、全てのデータがプライマリストレージに保存された状態でリストアされる訳ではないようです。
ということは、リストア元のボリュームに対してQoSで帯域制御をかけておけば、キャパシティプールストレージにリストアできるのではないでしょうか。
早速やってみます。
まず、QoSの設定をするためにFSx for ONTAPファイルシステムの管理パスワードを設定します。
ファイルシステムを選択し、アクション-ファイルシステムを更新をクリックします。
パスワードを入力して更新をクリックします。
パスワード設定後、EC2インスタンスからFSx for ONTAPファイルシステムにSSHで接続します。
$ ssh fsxadmin@management.fs-0cd2f70958932a1ca.fsx.us-east-1.amazonaws.com
The authenticity of host 'management.fs-0cd2f70958932a1ca.fsx.us-east-1.amazonaws.com (10.0.1.29)' can't be established.
ECDSA key fingerprint is SHA256:T9jmrw61DXTyf39TLru/pnDgUr2TZL+5eF7YOCWsWhk.
ECDSA key fingerprint is MD5:7e:be:30:31:87:01:2a:5d:62:35:2a:83:9a:b4:0e:79.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'management.fs-0cd2f70958932a1ca.fsx.us-east-1.amazonaws.com,10.0.1.29' (ECDSA) to the list of known hosts.
Password:
This is your first recorded login.
FsxId0cd2f70958932a1ca::>最大1MB/sのQoSポリシーを作成します。
FsxId0cd2f70958932a1ca::> qos policy-group create volume_policy -vserver fsx-for-ontap-svm -max-throughput 1MB/s
FsxId0cd2f70958932a1ca::> qos policy-group show -policy-group volume_policy
Policy Group Name: volume_policy
Vserver: fsx-for-ontap-svm
Uuid: 38e86883-3cb4-11ed-a316-550e5d64a51d
Policy Group Class: user-defined
Policy Group ID: 1461
Maximum Throughput: 1MB/s
Minimum Throughput: 0
Number of Workloads: 0
Throughput Policy: 0-1MB/s
Is Shared: true
Is Policy Auto Generated: -作成したQoSポリシーをボリュームにアタッチします。
FsxId0cd2f70958932a1ca::> volume modify -volume fsx_for_ontap_volume_nfs -qos-policy-group volume_policy
Volume modify successful on volume fsx_for_ontap_volume_nfs of Vserver fsx-for-ontap-svm.
FsxId0cd2f70958932a1ca::> volume show -volume fsx_for_ontap_volume_nfs -fields qos-policy-group
vserver volume qos-policy-group
----------------- ------------------------ ----------------
fsx-for-ontap-svm fsx_for_ontap_volume_nfs volume_policyこの状態でボリュームに書き込みをして、帯域制御が実際にかかっているのか確認します。
$ sudo dd if=/dev/urandom of=/mnt/fsx/testfile_2 bs=1M count=16
16+0 records in
16+0 records out
16777216 bytes (17 MB) copied, 15.5814 s, 1.1 MB/s16MBのファイルを書き込むのに15秒かかり、書き込み速度は1.1 MB/sでした。設定した通りに帯域制御が効いてますね。
それでは、このボリュームを再度バックアップし、リストアします。
リストアしたボリュームのプライマリストレージとキャパシティプールストレージの使用量をCloudWatch メトリクスから確認します。
メトリクスの描画が始まったタイミングからプライマリストレージの使用量の紫のグラフが15GB程度を差しています。その後は一時上昇して途中下降していまが、以降平行線になっています。下降したタイミングでキャパシティプールストレージの使用量の茶色のグラフが上昇していますが、こちらも途中で平行線になっています。
QoSによる帯域制御が効いていなさそうです。
ファイルシステムに接続して、リストアしたボリュームのQoSポリシーの割り当て状況を確認すると、何も割り当てられていませんでした。
FsxId0cd2f70958932a1ca::> volume show -volume fsx_for_ontap_volume_nfs_restored2 -fields qos-policy-group
vserver volume qos-policy-group
----------------- ---------------------------------- ----------------
fsx-for-ontap-svm fsx_for_ontap_volume_nfs_restored2 -どうやら同じFSx for ONTAPファイルシステムにリストアしたとしても、リストアしたボリュームにQoSポリシーは自動で割り当てられないようです。
対応策をあらためて考える
リストア対象のボリュームにQoSポリシーを割り当てて帯域制御をかけることはできないことが分かったので、あらためて対応策を考えてみます。
プライマリストレージの空き容量を圧迫しないようにするというポイントで考えると、以下2つのアプローチがあると思います。
- 大量のボリュームを一斉にリストアしない
- 別のFSx for ONTAPファイルシステム上でリストアして、SnapMirrorで本来のファイルシステムのボリュームに転送する
1つ目のアプローチから考えます。
大量のボリュームを一斉にリストアしてしまうと、そのボリュームで保持していたデータが一気にプライマリストレージに書き込まれてしまいます。
そのため、複数のボリュームがあり、全てのボリュームの総データサイズがプライマリストレージの空き容量を超えている場合は何回かに分けてリストアする必要があると考えます。リストアしたボリュームのデータがある程度キャパシティプールストレージに流れ、プライマリストレージに十分な空きがあることを確認した後に、別のボリュームをリストアするイメージです。
また、1つのボリュームに大量のデータを保存していると、1回のリストアで大量のデータがプライマリストレージに書き込まれます。リストア時のプライマリストレージへの大量書き込みを回避するために複数のボリュームにデータを分散させて保存させるのも手だと考えます。
2つ目のアプローチは1つ目と比較して、新規にFSx for ONTAPファイルシステムとSnapMirrorを設定する手間とコストがかなりかかります。
そのため、こちらはリストアしたいボリュームのデータサイズがプライマリストレージの空き容量を上回ってしまっている状況で使う奥の手だと思います。
SnapMirrorの設定は以下記事で検証しています。ご参考ください。
ちなみにコンソールやAWS CLIからはバックアップのデータサイズを確認することはできません。describe-backupsのSizeInMegabytesに記載されている値はバックアップしたボリュームでシンプロビジョニングしたサイズです。
実際の使用量を確認するには、バックアップ元のボリュームに保存されているデータサイズをCloudWatch メトリクスやONTAP CLIから事前に確認しておく必要があります。
リストア時はキャパシティプールストレージに保存しているデータサイズとプライマリストレージの空き容量を意識しよう
階層化ポリシーがALLで全てのデータがキャパシティプールストレージにあるボリュームをリストアする場合でも、必ず一度プライマリストレージに書き込みが発生する事象を紹介しました。
大量のデータをキャパシティプールストレージに保存しているボリュームをリストアする際は、要注意ですね。
バックアップからのリストアを意識してボリュームの設計をするのも必要かと思います。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
0
