[Amazon FSx for NetApp ONTAP] ファイル単位のSnapRestoreのメリットを確認してみた
cpコマンドでリストアする場合と比較してSnapRestoreするメリットを知りたい
こんにちは、のんピ(@non____97)です。
皆さんはcpコマンドでリストアする場合と比較してSnapRestoreするメリットを知りたいなと思ったことはありますか? 私はあります。
以下記事で指定したディレクトリ配下のみSnapRestoreすることのは一筋縄では行かないこと紹介しました。
では、頑張ってSnapRestoreするメリットはなんでしょうか。cpコマンドの方がONTAP CLIを使わずに簡単にリストアできます。その簡便性を上回るメリットはあるのでしょうか。
パッと思いつくのはリストア速度でしょうか。
cpコマンドはSnapshotで保持している実データをコピーして新しいデータブロックに書き込むのに対して、SnapRestoreはSnapshotで保持している実データにポインタに振り向ける形で行われます。要するに実データブロックへの大量の書き込みが不要であるため、高速にリストアできるイメージがあります。
Snapshot取得時の挙動やリストア時の挙動の簡単なイメージ図は以下をご覧ください。
抜粋 : 5分で分かった気になれる Amazon FSx for NetApp ONTAPのSnapshot というタイトルで登壇しました #jawsug_asa | DevelopersIO
実際にどのぐらいの差があるのか確認してみましょう。
いきなりまとめ
- cpコマンドやエクスプローラーの
以前のバージョン
機能でリストアする場合と比較してSnapRestoreするメリットは以下- リストア速度が高速
- リストア時の実データブロックの消費量が少ない
リストア速度の比較
テスト用ファイルの作成
早速リストア速度の比較をしましょう。
テスト用の1GiBファイルを作成します。
$ sudo mount -t nfs svm-04f22e3a82142d131.fs-0e64a4f5386f74c87.fsx.us-east-1.amazonaws.com:/vol1 /mnt/fsxn/vol1
$ sudo dd if=/dev/urandom of=/mnt/fsxn/vol1/random_pattern_binary_block_1GiB bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.67561 s, 161 MB/s
作成には6秒ほどかかったようです。
作成したファイルのコピーを作成します。
$ time sudo cp -p /mnt/fsxn/vol1/random_pattern_binary_block_1GiB /mnt/fsxn/vol1/random_pattern_binary_block_1GiB_copry1
real 0m6.396s
user 0m0.016s
sys 0m0.646s
$ ls -lh /mnt/fsxn/vol1
total 2.1G
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1
こちらも6秒ほどかかったようです。
この6秒が基準ですね。
Snapshotの取得
Snapshotを取得します。
::> snapshot show -volume vol1
There are no entries matching your query.
::> snapshot create -vserver svm -volume vol1 -snapshot test.2024-09-22_0156
::> set diag
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y
::*> snapshot show -volume vol1 -fields afs-used, size, create-time, state
vserver volume snapshot create-time size state afs-used
------- ------ -------------------- ------------------------ ----- ----- --------
svm vol1 test.2024-09-22_0156 Sun Sep 22 01:56:47 2024 160KB - 2.01GB
現時点ではAFSは2.01GBであることが分かります。
cpコマンドによるリストア
それでは、cpコマンドによるリストアを行います。
time sudo cp -p /mnt/fsxn/vol1/.snapshot/test.2024-09-22_0156/random_pattern_binary_block_1GiB /mnt/fsxn/vol1/random_pattern_binary_block_1GiB_test.2024-09-22_0156
real 0m6.768s
user 0m0.016s
sys 0m0.916s
6秒かかりました。
通常のファイルコピーと速度は変わらないことが分かります。
SnapRestore
それではSnapRestoreを行います。
NFSクライアント側で以下コマンドを叩き、1秒間隔でマウントポイント配下を一覧するようにループさせます。
while true; do date; ls -lh /mnt/fsxn/vol1; sleep 1s; done
SnapRestoreをします。
::*> date show -node FsxId0e64a4f5386f74c87-01 -fields date
(cluster date show)
node date
------------------------- -------------------------
FsxId0e64a4f5386f74c87-01 9/22/2024 02:09:43 +00:00
::*> snapshot restore-file -vserver svm -volume vol1 -snapshot test.2024-09-22_0156 -path /random_pattern_binary_block_1GiB_copry1 -restore-path /random_pattern_binary_block_1GiB_copry1_test.2024-09-22_0156
02:09:43
以降にSnapRestoreを実行しています。
SnapRestore後、NFSクライアントで実行していたコマンドの様子を確認します。
.
.
(中略)
.
.
Sun Sep 22 02:09:41 UTC 2024
total 3.1G
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_test.2024-09-22_0156
Sun Sep 22 02:09:42 UTC 2024
total 3.1G
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_test.2024-09-22_0156
Sun Sep 22 02:09:43 UTC 2024
total 3.1G
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_test.2024-09-22_0156
Sun Sep 22 02:09:44 UTC 2024
total 4.1G
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1_test.2024-09-22_0156
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_test.2024-09-22_0156
Sun Sep 22 02:09:45 UTC 2024
total 4.1G
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1_test.2024-09-22_0156
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_test.2024-09-22_0156
.
.
(以下略)
.
.
02:09:44
にはSnapRestore対象のファイルがリストアされていることが分かります。要するに遅くとも1秒以内にはリストアが完了しています。
cpコマンドによるリストアのリストア時間はリストア対象のファイルサイズに大きく依存します。そのことから大容量ファイルをリストアしたい場合はSnapRestoreによるリストアをまず検討すると良いでしょう。
リストア後の使用済みサイズの確認
現在の使用済みサイズの確認
SnapRestoreのメリットは実はリストア速度だけではありません。
ボリューム上に存在しているファイルは4GiB分あります。
$ ls -lh /mnt/fsxn/vol1
total 4.1G
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1_test.2024-09-22_0156
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_test.2024-09-22_0156
ONTAP CLIでボリューム内のデータの物理使用量を確認します。
::*> volume show -volume vol1 -fields size, size-used-by-snapshots, available, used, logical-used
vserver volume size available used size-used-by-snapshots logical-used
------- ------ ---- --------- ------ ---------------------- ------------
svm vol1 16GB 12.16GB 3.04GB 4.36MB 4.04GB
::*> snapshot show -volume vol1 -fields afs-used, size, create-time, state
vserver volume snapshot create-time size state afs-used
------- ------ -------------------- ------------------------ ------ ----- --------
svm vol1 test.2024-09-22_0156 Sun Sep 22 01:56:47 2024 4.36MB - 2.01GB
はい、3.04GBです。
dfコマンドでも3.1GBと表示されています。
$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
svm-04f22e3a82142d131.fs-0e64a4f5386f74c87.fsx.us-east-1.amazonaws.com:/vol1 nfs4 16G 3.1G 13G 20% /mnt/fsxn/vol1
この論理使用量と物理使用量の差である1GiBはSnapRestoreによって発生しているものです。
この記事の冒頭で説明したように、SnapRestoreはSnapshotで保持している実データにポインタに振り向ける形で行われます。
図にすると以下のとおりです。
今回のシチュエーションだと、SnapRestoreしたファイルはSnapshot領域と同じデータブロックを見ていることになります。また、SnapRestore元のファイルが残っており、AとBのデータブロックに対する変更は発生していないため、多くのデータブロックが複数の場所から参照されています。つまり、データの持ち方として無駄がありません。
一方、cp時のデータブロックのイメージは以下のとおりです。
cp時に新規データブロックにコピーを作成するので、内容は同じであっても別途ファイルサイズ分の物理領域が必要になります。
Snapshotの削除
Snapshot自体は削除してファイルは削除されないことを確認します。
SnapRestoreで使用したSnapshotを削除します。
::*> snapshot delete -vserver svm -volume vol1 -snapshot test.2024-09-22_0156
Warning: Deleting a Snapshot copy permanently removes data that is stored only in that Snapshot copy. Are you sure you want to delete Snapshot copy "test.2024-09-22_0156" for volume "vol1" in Vserver "svm" ?
{y|n}: y
::*> snapshot show -volume vol1 -fields afs-used, size, create-time, state
There are no entries matching your query.
::*> volume show -volume vol1 -fields size, size-used-by-snapshots, available, used, logical-used
vserver volume size available used size-used-by-snapshots logical-used
------- ------ ---- --------- ------ ---------------------- ------------
svm vol1 16GB 12.16GB 3.04GB 0B 4.04GB
NFSクライアントからファイルの様子を見てみましょう。
$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
svm-04f22e3a82142d131.fs-0e64a4f5386f74c87.fsx.us-east-1.amazonaws.com:/vol1 nfs4 16G 3.1G 13G 20% /mnt/fsxn/vol1
$ ls -lh /mnt/fsxn/vol1
total 4.1G
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1_test.2024-09-22_0156
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_test.2024-09-22_0156
はい、SnapRestoreしたrandom_pattern_binary_block_1GiB_copry1_test.2024-09-22_0156
は削除されていません。
ファイルの削除
ファイルの削除を行い、物理使用量の変化を確認します。
まず、リストア元のファイルを削除します。
$ sudo rm /mnt/fsxn/vol1/random_pattern_binary_block_1GiB_copry1
$ ls -lh /mnt/fsxn/vol1
total 3.1G
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_copry1_test.2024-09-22_0156
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_test.2024-09-22_0156
$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
svm-04f22e3a82142d131.fs-0e64a4f5386f74c87.fsx.us-east-1.amazonaws.com:/vol1 nfs4 16G 3.1G 13G 21% /mnt/fsxn/vol1
dfの結果は3.1GBのままですね。
ONTAP CLIでも確認します。
::*> volume show -volume vol1 -fields size, size-used-by-snapshots, available, used, logical-used
vserver volume size available used size-used-by-snapshots logical-used
------- ------ ---- --------- ------ ---------------------- ------------
svm vol1 16GB 12.18GB 3.01GB 0B 3.01GB
はい、物理使用量は3.1GBのままです。
次にSnapRestoreでリストアされたファイルを削除します。
$ sudo rm /mnt/fsxn/vol1/random_pattern_binary_block_1GiB_copry1_test.2024-09-22_0156
$ ls -lh /mnt/fsxn/vol1
total 2.1G
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB
-rw-r--r--. 1 root root 1.0G Sep 22 01:50 random_pattern_binary_block_1GiB_test.2024-09-22_0156
$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
svm-04f22e3a82142d131.fs-0e64a4f5386f74c87.fsx.us-east-1.amazonaws.com:/vol1 nfs4 16G 2.1G 14G 14% /mnt/fsxn/vol1
dfの結果が2.1GBになりましたね。
ONTAP CLIからも確認します。
::*> volume show -volume vol1 -fields size, size-used-by-snapshots, available, used, logical-used
vserver volume size available used size-used-by-snapshots logical-used
------- ------ ---- --------- ------ ---------------------- ------------
svm vol1 16GB 13.19GB 2.01GB 0B 2.01GB
はい、3.01GBから2.01GBに減っています。
要するに先ほど削除したファイルに含まれるデータブロックはボリューム内で重複保持されていなかったことになります。
おまけ : 以前のバージョンでリストアした時の速度
テスト用ファイルの作成
おまけとして以前のバージョン
機能でリストアした時の速度も確認します。
環境は以下記事で用意したものを再利用します。
適当にランダムな文字列で埋められた8GBのファイルを作成します。
> $path = "\\SMB-SERVER.corp.non-97.net\share\dir1\dir2\fsutil_8GiB.txt"
> $size = 8GB
> $stopwatch = [System.Diagnostics.Stopwatch]::StartNew()
> $buffer = New-Object byte[] 1024
> $rng = New-Object System.Security.Cryptography.RNGCryptoServiceProvider
> $fs = [System.IO.File]::Create($path)
> try {
$remaining = $size
while ($remaining -gt 0) {
$count = [Math]::Min($remaining, $buffer.Length)
$rng.GetBytes($buffer, 0, $count)
$fs.Write($buffer, 0, $count)
$remaining -= $count
}
} finally {
$fs.Close()
}
> $stopwatch.Stop()
> $elapsedTime = $stopwatch.Elapsed
> Write-Host "実行時間: $($elapsedTime.TotalSeconds) 秒"
実行時間: 118.5596013 秒
2分ほどかかりました。
現在のボリュームの状態を確認しておきます。
::*> volume show -volume vol_ntfs -fields size, size-used-by-snapshots, available, used, logical-used
vserver volume size available used size-used-by-snapshots logical-used
------- -------- ---- --------- ------ ---------------------- ------------
svm vol_ntfs 32GB 22.36GB 8.03GB 340KB 8.03GB
Snapshotの取得
Snapshotの取得をします。
::*> snapshot create -vserver svm -volume vol_ntfs -snapshot test.2024-09-22_0958
::*> snapshot show -volume vol_ntfs -fields afs-used, size, create-time, state
vserver volume snapshot create-time size state afs-used
------- -------- -------------------- ------------------------ ----- ----- --------
svm vol_ntfs test.2024-08-30_0648 Fri Aug 30 06:48:54 2024 356KB - 588KB
svm vol_ntfs test.2024-09-22_0958 Sun Sep 22 09:58:00 2024 144KB - 8.04GB
2 entries were displayed.
以前のバージョンでリストア
それでは以前のバージョンでリストアをします。
分かりやすいように作成したファイルfsutil_8GiB.txt
は事前に削除しておきます。
リストア中は以下のように進捗を確認できます。
24秒ほどで完了しました。3回ほど試しましたが、いずれも24秒でした。
ファイルを削除しなかった場合も3回ほど計測しましたが、21秒〜23秒でした。大きな差はないように思います。
SnapRestore
次にSnapRestoreの場合のリストア時間を計測します。
現在のボリュームの状態は以下のとおりです。
::*> volume show -volume vol_ntfs -fields size, size-used-by-snapshots, available, used, logical-used
vserver volume size available used size-used-by-snapshots logical-used
------- -------- ---- --------- ------ ---------------------- ------------
svm vol_ntfs 32GB 22.36GB 8.04GB 33.50MB 8.09GB
fsutil_8GiB.txt
を削除します。
削除後のボリュームの状態は以下のとおりです。
::*> volume show -volume vol_ntfs -fields size, size-used-by-snapshots, available, used, logical-used
vserver volume size available used size-used-by-snapshots logical-used
------- -------- ---- --------- ------ ---------------------- ------------
svm vol_ntfs 32GB 23.96GB 6.44GB 7.95GB 6.44GB
::*> snapshot show -volume vol_ntfs -fields afs-used, size, create-time, state
vserver volume snapshot create-time size state afs-used
------- -------- -------------------- ------------------------ ----- ----- --------
svm vol_ntfs test.2024-08-30_0648 Fri Aug 30 06:48:54 2024 356KB - 588KB
svm vol_ntfs test.2024-09-22_0958 Sun Sep 22 09:58:00 2024 7.95GB
- 8.04GB
2 entries were displayed.
SnapRestoreを行う前に、SMBクライアントで1秒間隔でディレクトリ内のファイル一覧を表示する以下スクリプトを実行しておきます。
while ($true) {
Get-Date
Get-ChildItem -Path "\\SMB-SERVER.corp.non-97.net\share\dir1\dir2\" |
Select-Object Mode, LastWriteTime, Length, Name |
Format-Table -AutoSize |
Out-String -Stream |
?{$_ -ne ""}
Start-Sleep -Seconds 1
}
それではSnapRestoreを行います。
::*> date show -node FsxId0e64a4f5386f74c87-01 -fields date
(cluster date show)
node date
------------------------- -------------------------
FsxId0e64a4f5386f74c87-01 9/22/2024 12:22:48 +00:00
::*> snapshot restore-file -vserver svm -volume vol_ntfs -snapshot test.2024-09-22_0958 -path /dir1/dir2/fsutil_8GiB.txt -restore-path /dir1/dir2/fsutil_8GiB.txt
SMBクライアントで実行していたスクリプトの実行結果を確認します。
.
.
(中略)
.
.
Sunday, September 22, 2024 12:22:46 PM
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 8/30/2024 6:42:03 AM 9 test3.txt
Sunday, September 22, 2024 12:22:47 PM
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 8/30/2024 6:42:03 AM 9 test3.txt
Sunday, September 22, 2024 12:22:48 PM
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 8/30/2024 6:42:03 AM 9 test3.txt
Sunday, September 22, 2024 12:22:49 PM
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 8/30/2024 6:42:03 AM 9 test3.txt
Sunday, September 22, 2024 12:22:50 PM
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 9/22/2024 9:48:38 AM 8589934592 fsutil_8GiB.txt
-a---- 8/30/2024 6:42:03 AM 9 test3.txt
Sunday, September 22, 2024 12:22:51 PM
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 9/22/2024 9:48:38 AM 8589934592 fsutil_8GiB.txt
-a---- 8/30/2024 6:42:03 AM 9 test3.txt
.
.
(以下略)
.
.
12:22:48
以降にSnapRestoreを行い、12:22:50
にはSnapRestore対象のファイルを確認できました。そのため遅くとも2秒以内にはリストアができていることが分かります。
やはり速いですね。
基本的にはSnapRestoreを使っていきたい
ファイル単位のSnapRestoreのメリットを確認してみました。
平たく言うとリストア速度とストレージの利用効率性です。こちらに魅力を感じるようであれば積極的にSnapRestoreを使っていくと良いでしょう。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!