[Amazon FSx for NetApp ONTAP] ファイル単位のSnapRestoreのメリットを確認してみた

基本的にはSnapRestoreを使っていきたい

のんピ

2024.09.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

cpコマンドでリストアする場合と比較してSnapRestoreするメリットを知りたい

こんにちは、のんピ(@non____97)です。

皆さんはcpコマンドでリストアする場合と比較してSnapRestoreするメリットを知りたいなと思ったことはありますか? 私はあります。

以下記事で指定したディレクトリ配下のみSnapRestoreすることのは一筋縄では行かないこと紹介しました。

では、頑張ってSnapRestoreするメリットはなんでしょうか。cpコマンドの方がONTAP CLIを使わずに簡単にリストアできます。その簡便性を上回るメリットはあるのでしょうか。

パッと思いつくのはリストア速度でしょうか。

cpコマンドはSnapshotで保持している実データをコピーして新しいデータブロックに書き込むのに対して、SnapRestoreはSnapshotで保持している実データにポインタに振り向ける形で行われます。要するに実データブロックへの大量の書き込みが不要であるため、高速にリストアできるイメージがあります。

Snapshot取得時の挙動やリストア時の挙動の簡単なイメージ図は以下をご覧ください。

1.ONTAPのSnapshotはPoint-in-Time方式.png
2.リストア時の挙動.png

抜粋 : 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で保持している実データにポインタに振り向ける形で行われます。

図にすると以下のとおりです。

3.SnapRestore時のデータブロック.png

今回のシチュエーションだと、SnapRestoreしたファイルはSnapshot領域と同じデータブロックを見ていることになります。また、SnapRestore元のファイルが残っており、AとBのデータブロックに対する変更は発生していないため、多くのデータブロックが複数の場所から参照されています。つまり、データの持ち方として無駄がありません。

一方、cp時のデータブロックのイメージは以下のとおりです。

4.cp時のデータブロック.png

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は事前に削除しておきます。

5.リストア.png

リストア中は以下のように進捗を確認できます。

7.リストア中の詳細.png

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)でした!

[Amazon FSx for NetApp ONTAP] ファイル単位のSnapRestoreのメリットを確認してみた

cpコマンドでリストアする場合と比較してSnapRestoreするメリットを知りたい

いきなりまとめ

リストア速度の比較

テスト用ファイルの作成

Snapshotの取得

cpコマンドによるリストア

SnapRestore

リストア後の使用済みサイズの確認

現在の使用済みサイズの確認

Snapshotの削除

ファイルの削除

おまけ : 以前のバージョンでリストアした時の速度

テスト用ファイルの作成

Snapshotの取得

以前のバージョンでリストア

SnapRestore

基本的にはSnapRestoreを使っていきたい

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS