[Amazon FSx for NetApp ONTAP] ボリュームを間違って削除した時にありがたいボリュームリカバリーキューの紹介

[Amazon FSx for NetApp ONTAP] ボリュームを間違って削除した時にありがたいボリュームリカバリーキューの紹介

ボリューム削除時にはボリュームリカバリーキューを意識しよう
Clock Icon2023.03.31

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

げげげっ! ボリュームを間違えて削除してしまった!

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

皆さんはAmazon FSx for NetApp ONTAP(以降FSx for ONTAP)のボリュームを間違えて削除してしまったことはありますか? 私はありません。しかし、今後しでかしそうな予感がしています。

というのもFSx for ONTAPのボリュームには削除保護がありません。

マネジメントコンソールからボリュームを削除しようとすると、以下のようにボリュームを本当に削除しても良いか確認が入ります。

マネジメントコンソールからボリュームの削除

しかし、AWS CLIから削除しようとすると、すんなり削除の処理が走ります。(オプションを指定しない場合、削除前にバックアップの処理が走ります)

# ボリュームの削除
$ aws fsx delete-volume --volume-id fsvol-06bed1a4386995178
{
    "VolumeId": "fsvol-06bed1a4386995178",
    "Lifecycle": "DELETING"
}

# ボリュームのステータスの確認
$ aws fsx describe-volumes --volume-id fsvol-06bed1a4386995178
{
    "Volumes": [
        {
            "CreationTime": "2023-02-12T09:05:31.824000+00:00",
            "FileSystemId": "fs-05f72eb8f8d03c709",
            "Lifecycle": "DELETING",
            "Name": "vol_timezone",
            "OntapConfiguration": {
                "FlexCacheEndpointType": "NONE",
                "JunctionPath": "/vol_timezone",
                "SecurityStyle": "UNIX",
                "SizeInMegabytes": 128,
                "StorageEfficiencyEnabled": false,
                "StorageVirtualMachineId": "svm-0404cd705c847e961",
                "StorageVirtualMachineRoot": false,
                "TieringPolicy": {
                    "Name": "NONE"
                },
                "UUID": "6d9092cb-aab4-11ed-946a-5191ab1a5297",
                "OntapVolumeType": "RW",
                "SnapshotPolicy": "timezone-test",
                "CopyTagsToBackups": false
            },
            "ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-05f72eb8f8d03c709/fsvol-06bed1a4386995178",
            "VolumeId": "fsvol-06bed1a4386995178",
            "VolumeType": "ONTAP"
        }
    ]
}

# ボリュームが削除されたことを確認
$ aws fsx describe-volumes --volume-id fsvol-06bed1a4386995178

An error occurred (VolumeNotFound) when calling the DescribeVolumes operation: Volume 'fsvol-06bed1a4386995178' does not exist.

そのため、ボリュームIDのコピペミスなどをすると大惨事になりやすいです。

バックアップも取っていなければ諦めるしかないのか...

そんなことはありません。ONTAPにはボリュームリカバリーキューというありがたい機能が存在します。

以降、ボリュームリカバリーキューの紹介をします。

いきなりまとめ

  • ボリュームリカバリーキューとはボリュームタイプが RW または DP のボリュームを削除した場合、そのボリュームを部分的に削除された状態にする機能
  • デフォルトではボリュームは一定時間(デフォルトは12時間)リカバリキューに保持されたあと、完全に削除される
  • リカバリーキュー内に保存されている期間であればボリュームを復旧させることが可能
    • Snapshotも保持される
  • リカバリーキュー内に保存されている期間はそのボリュームが残るためスペースを消費する
    • ボリュームの削除目的がSSDの空き容量確保であれば、ボリュームリカバリーキューからボリュームを完全に削除する必要がある
  • ボリュームを削除すると以下の情報が削除されるためリカバリーキューからリカバリーした場合は再設定する必要がある
    • ジャンクションマッピング
    • LUN マッピング
    • Snapshot policy
    • Export policy
    • QoS policy
    • quota policy rules
  • リカバリーしたボリュームをオンラインにすると同じAggregate内の全てのボリュームのパフォーマンスが一時的に低下することがある
    • 大量にボリュームをリカバリーして、一気にオンラインするというのは避けた方が良い
  • リカバリーしてもStorage Efficiencyによるデータ削減量は維持される
  • リカバリーしても階層化は維持される
    • リカバリーするタイミングでキャパシティプールストレージ上のデータがSSDに書き戻される事象は発生しない
  • リカバリーするとStorage Efficiencyの優先度が低くなることがあるかも
    • 優先度が低い場合は自動バックグラウンド重複排除の対象でなくなる
    • volume efficiency promoteで優先度を上げることで対応する
  • リカバリーキューの保持期間をデフォルトの12時間から変更することも可能
    • ただし、変更には権限レベルがdiagnosticである必要
    • diagnosticNetAppのサポートがない限り使用してはいけない
    • 既にリカバリーキュー内にあるボリュームには影響を与えない
    • volume-delete-retention-hoursを0に指定すると、リカバリーキューに保持されず、即座にボリュームが削除される
  • ボリューム削除時に-forceを指定するとリカバリーキューに保持されず削除される
  • FlexGroupボリュームもリカバリーキューからリカバリー可能

ボリュームリカバリーキューとは

ボリュームリカバリーキューとはボリュームタイプが RW または DP のボリュームを削除した場合、そのボリュームを部分的に削除された状態にする機能です。

デフォルトではボリュームは一定時間(デフォルトは12時間)リカバリキューに保持されたあと、完全に削除されます。 リカバリーキュー内に保存されている期間であればボリュームを復旧させることが可能です。

裏を返せば、リカバリーキュー内に保存されている期間はそのボリュームが残るためスペースを消費します。

リカバリキュー内で使用されているアグリゲートスペース

リカバリキュー内のボリュームは、引き続きアグリゲートスペースを消費します。アグリゲートスペースを消費'volume show-footprint'しているボリュームについて混乱を避けるため、コマンドの出力には、すべての権限レベルで部分的に削除されたボリュームが含まれます。

ボリュームリカバリキューの使用方法 - NetApp

そのため、「ボリュームを削除してSSDの空きを確保したい」といったときは注意が必要です。

なお、ボリュームを削除すると以下の情報がボリュームから削除されるので、リカバリーする場合は別途設定し直す必要があります。

  • ジャンクションマッピング
  • LUN マッピング
  • Snapshot policy
  • Export policy
  • QoS policy
  • quota policy rules

また、ボリュームの名前がボリューム名_DSIDに変更されます。

やってみた

テスト用ファイルの作成

ボリュームリカバリーキューを試してみましょう。

せっかくなのでボリューム内にファイルを作成して、リカバリーした際もそのファイルを保持していることを確認します。

前準備としてvol_recovery_testというボリュームを作成します。

# ボリュームの作成
::> volume create -vserver SVM -volume vol_recovery_test -aggregate aggr1 -size 16GB -state online -policy default -tiering-policy none -junction-path /vol_recovery_test
[Job 1338] Job succeeded: Successful

# ボリュームが作成されたことを確認
::> volume show -vserver SVM -volume vol_recovery_test -fields state, type, size, available, used, junction-path
vserver volume            size state  junction-path      available used  type
------- ----------------- ---- ------ ------------------ --------- ----- ----
SVM     vol_recovery_test 16GB online /vol_recovery_test 15.20GB   340KB RW

ボリューム作成後、現在のSSDの空き容量と、SSDとキャパシティプールストレージの使用量を確認しておきます。

# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
                                       Available
Vserver        Aggregate      State         Size Type    SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM            aggr1          online     808.3GB ssd     non-snaplock

::> vserver show-aggregates -vserver SVM -instance

       Vserver: SVM
     Aggregate: aggr1
         State: online
Available Size: 808.3GB
Aggregate Type: ssd
 Snaplock Type: non-snaplock
Is NVE Capable: false

# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space

      Aggregate : aggr1
      Performance Tier
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Volume Footprints                             52.18GB         6%
      Aggregate Metadata                             1.30GB         0%
      Snapshot Reserve                              45.36GB         5%
      Total Used                                    98.84GB        11%

      Total Physical Used                           56.31GB         6%


      Total Provisioned Space                       100.1TB
                                                                11301%


      Aggregate : aggr1
      Object Store: FSxFabricpoolObjectStore
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Logical Used                                  867.6MB          -
      Logical Referenced Capacity                   867.6MB          -
      Logical Unreferenced Capacity                      0B          -

      Total Physical Used                           867.6MB          -



2 entries were displayed.

NFSクライアントから作成したボリュームをマウントして10GiBのファイルを作成します。

# マウントポイントの作成
$ sudo mkdir -p /mnt/fsxn/vol_recovery_test

# ボリュームのマウント
$ sudo mount -t nfs svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test /mnt/fsxn/vol_recovery_test/

# マウントされているか確認
$ df -hT -t nfs4
Filesystem                                                                                Type  Size  Used Avail Use% Mounted on
svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test nfs4   16G  320K   16G   1% /mnt/fsxn/vol_recovery_test

# 10GiBのファイルの作成
$ sudo dd if=/dev/urandom of=/mnt/fsxn/vol_recovery_test/test-file bs=512M count=20
20+0 records in
20+0 records out
10737418240 bytes (11 GB) copied, 82.7229 s, 130 MB/s

# ファイル作成後のボリュームの空き容量の確認
$ df -hT -t nfs4
Filesystem                                                                                Type  Size  Used Avail Use% Mounted on
svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test nfs4   16G   11G  5.1G  67% /mnt/fsxn/vol_recovery_test

ファイル作成後、ONTAP CLIからもSSDの空き容量と使用量を確認します。

# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
                                       Available
Vserver        Aggregate      State         Size Type    SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM            aggr1          online     798.2GB ssd     non-snaplock

# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space

      Aggregate : aggr1
      Performance Tier
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Volume Footprints                             62.29GB         7%
      Aggregate Metadata                             1.31GB         0%
      Snapshot Reserve                              45.36GB         5%
      Total Used                                    109.0GB        12%

      Total Physical Used                           66.56GB         7%


      Total Provisioned Space                       100.1TB
                                                                11301%


      Aggregate : aggr1
      Object Store: FSxFabricpoolObjectStore
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Logical Used                                  867.6MB          -
      Logical Referenced Capacity                   867.6MB          -
      Logical Unreferenced Capacity                      0B          -

      Total Physical Used                           867.6MB          -



2 entries were displayed.

ファイル作成前と比較して、確かにSSDが10GiB分消費されていますね。

ボリュームの削除

それではボリュームの削除をします。

ふと、Snapshotはリカバリキューからリカバリーした場合も残るのか気になったので、事前にSnapshotを取得します。

# Snapshotの取得
::> snapshot create -vserver SVM -volume vol_recovery_test -snapshot recovery_test

# 取得したSnapshotの確認
::> snapshot show -vserver SVM -volume vol_recovery_test
                                                                 ---Blocks---
Vserver  Volume   Snapshot                                  Size Total% Used%
-------- -------- ------------------------------------- -------- ------ -----
SVM      vol_recovery_test
                  recovery_test                            144KB     0%    0%

ボリュームを削除します。

# ボリュームをオフラインに変更
::> volume offline -vserver SVM -volume vol_recovery_test

Warning: Volume "vol_recovery_test" on Vserver "SVM" must be unmounted before being taken offline or restricted.
         Clients will not be able to access the affected volume and related junction paths after that.  Do you still
         want to unmount the volume and continue? {y|n}: y
Volume "SVM:vol_recovery_test" is now offline.

# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test

Info: Volume "vol_recovery_test" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
      The space used by the volume will be recovered only after the retention period of 12 hours has completed. To
      recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
      vol_recovery_test_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
      recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
      <volume_name>" command.

Warning: Are you sure you want to delete volume "vol_recovery_test" in Vserver "SVM" ? {y|n}: y
[Job 1341] Job succeeded: Successful

# ボリュームが削除されたことを確認
::> volume show -vserver SVM -volume vol_recovery_test -fields state, type, size, available, used, junction-path
There are no entries matching your query.

# 削除したボリュームのSnapshotを認識できないことを確認
::> snapshot show -vserver SVM -volume vol_recovery_test
There are no entries matching your query.

ボリュームを削除後、SSDの空き容量と使用量を確認します。

# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
                                       Available
Vserver        Aggregate      State         Size Type    SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM            aggr1          online     798.2GB ssd     non-snaplock

# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space

      Aggregate : aggr1
      Performance Tier
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Volume Footprints                             62.30GB         7%
      Aggregate Metadata                             1.31GB         0%
      Snapshot Reserve                              45.36GB         5%
      Total Used                                    109.0GB        12%

      Total Physical Used                           66.59GB         7%


      Total Provisioned Space                       100.1TB
                                                                11301%


      Aggregate : aggr1
      Object Store: FSxFabricpoolObjectStore
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Logical Used                                  867.6MB          -
      Logical Referenced Capacity                   867.6MB          -
      Logical Unreferenced Capacity                      0B          -

      Total Physical Used                           867.6MB          -



2 entries were displayed.

ボリュームを削除しましたが、SSDの使用量は変わっていませんね。

ボリュームのリカバリー

ボリュームリカバリーキューから削除したボリュームをリカバリーします。

ボリュームリカバリーキューの操作は権限レベルがadvanced以上である必要があります。

# admin では recovery-queue がない
::> volume ?
  analytics>                  The analytics directory
  autosize                    Set/Display the autosize settings of the flexible volume.
  clone>                      Manage FlexClones
  create                      Create a new volume
  delete                      Delete an existing volume
  efficiency>                 Manage volume efficiency
  encryption>                 The encryption directory
  expand                      Expand the size of a volume by adding constituents
  file>                       File related commands
  flexcache>                  Manage FlexCache
  modify                      Modify volume attributes
  mount                       Mount a volume on another volume with a junction-path
  offline                     Take an existing volume offline
  online                      Bring an existing volume online
  qtree>                      Manage qtrees
  quota>                      Manage Quotas, Policies, Rules and Reports
  reallocation>               Commands for measuring and optimizing data layout
  rehost                      Rehost a volume from one Vserver into another Vserver
  rename                      Rename an existing volume
  restrict                    Restrict an existing volume
  show                        Display a list of volumes
  show-footprint              Display a list of volumes and their data and metadata footprints in their associated
                              aggregate.
  show-space                  Display space usage for volume(s)
  size                        Set/Display the size of the volume.
  snaplock>                   Manages SnapLock attributes of a SnapLock volume
  snapshot>                   Manage snapshots
  unmount                     Unmount a volume

# 権限レベルを advanced に変更
::> set advanced

Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

# recovery-queue が存在することを確認
::*> volume ?
  analytics>                  The analytics directory
  autosize                    Set/Display the autosize settings of the flexible volume.
  clone>                      Manage FlexClones
  conversion>                 *The conversion directory
  create                      Create a new volume
  delete                      Delete an existing volume
  efficiency>                 Manage volume efficiency
  encryption>                 The encryption directory
  expand                      Expand the size of a volume by adding constituents
  file>                       File related commands
  flexcache>                  Manage FlexCache
  flexgroup>                  *Manage FlexGroup operations
  make-vsroot                 *Designate a non-root volume as a root volume of the Vserver
  modify                      Modify volume attributes
  mount                       Mount a volume on another volume with a junction-path
  offline                     Take an existing volume offline
  online                      Bring an existing volume online
  qtree>                      Manage qtrees
  quota>                      Manage Quotas, Policies, Rules and Reports
  reallocation>               Commands for measuring and optimizing data layout
  recovery-queue>             *Manage volume recovery queue
  rehost                      Rehost a volume from one Vserver into another Vserver
  rename                      Rename an existing volume
  restrict                    Restrict an existing volume
  show                        Display a list of volumes
  show-footprint              Display a list of volumes and their data and metadata footprints in their associated
                              aggregate.
  show-space                  Display space usage for volume(s)
  size                        Set/Display the size of the volume.
  snaplock>                   Manages SnapLock attributes of a SnapLock volume
  snapshot>                   Manage snapshots
  unmount                     Unmount a volume

::*> volume recovery-queue ?
  modify                      *Modify attributes of volumes in the recovery queue
  purge                       *Purge volumes from the recovery queue belonging to a Vserver
  purge-all                   *Purge all volumes from the recovery queue belonging to a Vserver
  recover                     *Recover volumes from the recovery queue belonging to a Vserver
  recover-all                 *Recover all volumes from the recovery queue belonging to a Vserver
  show                        *Show volumes in the recovery queue

移行は権限レベルをadvancedにして作業をします。

ボリュームリカバリーキューに削除したボリュームがあるか確認します。

# ボリュームリカバリーキューの確認
::*> volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
SVM       vol_recovery_test_1098
                      Fri Mar 31 13:51:38 2023               12

::*> volume recovery-queue show -instance

           Vserver Name: SVM
            Volume Name: vol_recovery_test_1098
  Deletion Request Time: Fri Mar 31 13:51:38 2023
Volume Delete Retention: 12
   Volume Instance UUID: e63103cd-cf7b-11ed-b946-e1cdfb9c8ff0

ありましたね。こちらのボリュームをvolume recovery-queue recoverでリカバリーします。

# ボリュームリカバリーキュー内のボリュームのリカバリー
::*> volume recovery-queue recover -vserver SVM -volume vol_recovery_test_1098
Notice: When you bring a recovered volume online, there may be a temporary drop in performance for all volumes in the same aggregate.

Volume recovery successful for volume "vol_recovery_test_1098" in Vserver "SVM".

# リカバリーしたボリュームの確認
::*> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume                 size state   junction-path available used type
------- ---------------------- ---- ------- ------------- --------- ---- ----
SVM     vol_recovery_test_1098 16GB offline -             -         -    RW

# リカバリーしたボリュームのSnapshotの確認
::*> snapshot show -vserver SVM -volume vol_recovery_test*
There are no entries matching your query.

Info: Unable to get information for Snapshot copies of volume "vol_recovery_test_1098" on Vserver "SVM". Reason: Volume
      not online.

ボリュームがリカバリーされましたね。

ただし、ボリューム名がリカバリーキュー内の時のままになっていたり、オフライン状態になっていたりします。

NetAppのKBにもリカバリー後に行う処理として紹介されています。

Post recovery steps:

After using the recover command, the following steps must still be performed on the volume:

  1. Rename the volume using volume rename command.
  2. Set up a junction, if required, running the volume mount command.
  3. Create mappings for LUNs in the volume, if required, run the lun map command.
  4. Associate a snapshot policy, an export policy with the volume, if required, with the volume modify command.
  5. Add new quota policy rules for the volume, if required, with the quota policy rule command.
  6. Add a QOS policy for the volume, if required, run the volume modify command.

Note: When you bring a recovered volume online, there might be a temporary drop in performance for all volumes in the same aggregate.

How to use the Volume Recovery Queue - NetApp Knowledge Base

必要に応じて設定をしましょう。

また、注意書きの通り、リカバリーしたボリュームをオンラインにすると同じAggregate内の全てのボリュームのパフォーマンスが一時的に低下することがあるようです。大量にボリュームをリカバリーして、一気にオンラインするというのは避けた方が良いかもしれません。

ボリュームの名前の変更や、オンライン状態への変更、ジャンクションパスへのマウントをします。

# 権限レベルを admin に戻す
::*> set admin

# ボリューム名を変更
::> volume rename -vserver SVM -volume vol_recovery_test_1098 -newname vol_recovery_test
[Job 1343] Job is queued: Rename vol_recovery_test_1098 to vol_recovery_test.                                           
[Job 1343] Job succeeded: Successful

# ボリューム名が変更された子を確認
::> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume            size state   junction-path available used type
------- ----------------- ---- ------- ------------- --------- ---- ----
SVM     vol_recovery_test 16GB offline -             -         -    RW

# ボリュームをオンラインに
::> volume online -vserver SVM -volume vol_recovery_test
Volume "SVM:vol_recovery_test" is now online.

# ボリュームがオンラインになったことを確認
::> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume            size state  junction-path available used    type
------- ----------------- ---- ------ ------------- --------- ------- ----
SVM     vol_recovery_test 16GB online -             5.10GB    10.10GB RW

# Snapshotを認識できるようになったことを確認
::> snapshot show -vserver SVM -volume vol_recovery_test
                                                                 ---Blocks---
Vserver  Volume   Snapshot                                  Size Total% Used%
-------- -------- ------------------------------------- -------- ------ -----
SVM      vol_recovery_test
                  recovery_test                            400KB     0%    0%

# ジャンクションパスへのマウント
::> volume mount -vserver SVM -volume vol_recovery_test -junction-path /vol_recovery_test

# マウントできたことを確認
::> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume            size state  junction-path      available used    type
------- ----------------- ---- ------ ------------------ --------- ------- ----
SVM     vol_recovery_test 16GB online /vol_recovery_test 5.10GB    10.10GB RW

特に詰まることなく各設定変更ができました。また、ボリュームをオンラインにすることでSnapshotを認識できるようになりましたね。

NFSクライアントからリカバリーしたボリューム内のファイルを認識できることを確認します。

# マウントできていることを確認
$ df -hT -t nfs4
Filesystem                                                                                Type  Size  Used Avail Use% Mounted on
svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test nfs4   16G   11G  5.1G  67% /mnt/fsxn/vol_recovery_test

# ボリューム内にファイルがあることを確認
$ ls -l /mnt/fsxn/vol_recovery_test/
total 10527052
-rw-r--r-- 1 root root 10737418240 Mar 31 04:39 test-file

# Snapshot ディレクトリにもアクセスできることを確認
$ ls -lR /mnt/fsxn/vol_recovery_test/.snapshot
/mnt/fsxn/vol_recovery_test/.snapshot:
total 4
drwxr-xr-x 2 root root 4096 Mar 31 04:37 recovery_test

/mnt/fsxn/vol_recovery_test/.snapshot/recovery_test:
total 10527052
-rw-r--r-- 1 root root 10737418240 Mar 31 04:39 test-file

ボリューム内のファイル、Snapshotディレクトリ内のファイルどちらも認識できましたね。

なお、ボリュームリカバリー後の、SSDの空き容量と使用量を確認しましたが、目立った変化はありませんでした。

# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
                                       Available
Vserver        Aggregate      State         Size Type    SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM            aggr1          online     798.2GB ssd     non-snaplock

# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space

      Aggregate : aggr1
      Performance Tier
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Volume Footprints                             62.30GB         7%
      Aggregate Metadata                             1.31GB         0%
      Snapshot Reserve                              45.36GB         5%
      Total Used                                    109.0GB        12%

      Total Physical Used                           66.67GB         7%


      Total Provisioned Space                       100.1TB
                                                                11301%


      Aggregate : aggr1
      Object Store: FSxFabricpoolObjectStore
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Logical Used                                  867.6MB          -
      Logical Referenced Capacity                   867.6MB          -
      Logical Unreferenced Capacity                      0B          -

      Total Physical Used                           867.6MB          -



2 entries were displayed.

ボリュームリカバリーキューからリカバリーしてもStorage Efficiencyによるデータ削減量は維持されるのか

テスト用ファイルの作成

ボリュームリカバリーキューからリカバリーしてもStorage Efficiencyによるデータ削減量は維持されるのか気になってきました。

現在はStorage Efficiencyは有効化していますが、重複排除・圧縮は効いていません。

# Storage Efficiencyが有効化されているか確認
::> volume efficiency show -vserver SVM -volume vol_recovery_test

                                     Vserver Name: SVM
                                      Volume Name: vol_recovery_test
                                      Volume Path: /vol/vol_recovery_test
                                            State: Enabled
                                           Status: Idle
                                         Progress: Idle for 00:48:13
                                             Type: Regular
                                         Schedule: -
                           Efficiency Policy Name: auto
                           Blocks Skipped Sharing: 0
                             Last Operation State: Success
                     Last Success Operation Begin: Fri Mar 31 13:39:21 2023
                       Last Success Operation End: Fri Mar 31 13:39:28 2023
                             Last Operation Begin: Fri Mar 31 13:39:21 2023
                               Last Operation End: Fri Mar 31 13:39:28 2023
                              Last Operation Size: 2.00GB
                             Last Operation Error: -
                                  Changelog Usage: 0%
                                Logical Data Size: 10.10GB
                               Logical Data Limit: 640TB
                             Logical Data Percent: 0%
                                       Queued Job: -
                     Stale Fingerprint Percentage: 0
                                      Compression: false
                               Inline Compression: true
                          Storage Efficiency Mode: efficient
                               Constituent Volume: false
                                    Inline Dedupe: true
                                  Data Compaction: true
                Cross Volume Inline Deduplication: false
            Cross Volume Background Deduplication: false
                         Extended Compressed Data: true

# 重複排除・圧縮量を確認 
# (TSSEのボリュームの圧縮の効果はAggregateレベルで確認する必要があるため、compression-space-save や compression-space-saved-percent は必ず0になる)
::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared, compression-space-saved, compression-space-saved-percent
vserver volume            available total   used    percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared compression-space-saved compression-space-saved-percent
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- ------------------- ----------------------- -------------------------------
SVM     vol_recovery_test 5.10GB    15.20GB 10.10GB 66%          0B              0%                      0B                 0%                         0B                  0B                      0%

もし、維持されない場合ボリュームをリカバリーしたタイミングでSSDが溢れてしまうなんてことが起きてしまいそうです。

実際に確認してみましょう。

検証用に0埋めされた5GiBのファイルを作成します。

# テスト用ファイルの追加
$ sudo dd if=/dev/zero of=/mnt/fsxn/vol_recovery_test/zero_block_file bs=512MB count=10
10+0 records in
10+0 records out
5120000000 bytes (5.1 GB) copied, 33.3181 s, 154 MB/s

# ボリュームの使用量の確認
$ df -hT -t nfs4
Filesystem                                                                                Type  Size  Used Avail Use% Mounted on
svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test nfs4   16G   14G  2.0G  87% /mnt/fsxn/vol_recovery_test

なんだか思ったより削減されていませんね。

ONTAP CLIからも確認します。

::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared, compression-space-saved, compression-space-saved-percent
vserver volume            available total   used    percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared compression-space-saved compression-space-saved-percent
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- ------------------- ----------------------- -------------------------------
SVM     vol_recovery_test 2.11GB    15.20GB 13.09GB 86%          1.76GB          12%                     1.76GB             12%                        60KB                0B                      0%

1.76GBしか重複排除により削減されていませんでした。

全て0で埋められたデータであるため、重複排除量は5GiBであって欲しいところです。

試しに手動でStorage Efficiencyをかけてみます。

::> volume efficiency start -vserver SVM -volume vol_recovery_test

Error: command failed: Failed to start efficiency on volume "vol_recovery_test" of Vserver "SVM": Cannot perform
       efficiency operations on deprioritized volume. To be able to perform efficiency operations, run the (privilege:
       advanced) "volume efficiency promote" command first.

Storage Efficiencyの優先度が低くなっているようですね。これもリカバリーキューからリカバリーした影響でしょうか。

同じパラメーターのボリュームを用意して、そのボリュームに同じようにテストファイルを作成し、重複排除が効いているか確認します。

# ボリュームの作成
::> volume create -vserver SVM -volume vol_recovery_test_2 -aggregate aggr1 -size 16GB -state online -policy default -tiering-policy none -junction-path /vol_recovery_test_2
[Job 1345] Job succeeded: Successful

# ボリュームが作成されたことを確認
::> volume show -vserver SVM -volume vol_recovery_test_2 -fields state, type, size, available, used, junction-path
vserver volume              size state  junction-path        available used  type
------- ------------------- ---- ------ -------------------- --------- ----- ----
SVM     vol_recovery_test_2 16GB online /vol_recovery_test_2 15.20GB   296KB RW

テスト用ファイルを追加します。

# テスト用ファイルの追加
$ sudo dd if=/dev/urandom of=/mnt/fsxn/vol_recovery_test_2/test-file bs=512M count=20
20+0 records in
20+0 records out
10737418240 bytes (11 GB) copied, 81.7745 s, 131 MB/s

$ sudo dd if=/dev/zero of=/mnt/fsxn/vol_recovery_test_2/zero_block_file bs=512MB count=10
10+0 records in
10+0 records out
5120000000 bytes (5.1 GB) copied, 33.3641 s, 153 MB/s

# ボリュームの使用量の確認
$ df -hT -t nfs4 | grep _2
svm-0404cd705c847e961.fs-05f72eb8f8d03c709.fsx.us-east-1.amazonaws.com:/vol_recovery_test_2 nfs4   16G   11G  5.1G  67% /mnt/fsxn/vol_recovery_test_2

リカバリーしたボリュームと比較して使用量が3GBほど差が出ていますね。

ONTAP CLIからも確認します。

::> volume show -volume vol_recovery_test_2 -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume              available total   used    percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ------------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM     vol_recovery_test_2 5.08GB    15.20GB 10.12GB 66%          4.77GB          32%                     4.77GB             32%                        0B

::> volume efficiency show -vserver SVM -volume vol_recovery_test_2

                                     Vserver Name: SVM
                                      Volume Name: vol_recovery_test_2
                                      Volume Path: /vol/vol_recovery_test_2
                                            State: Enabled
                                           Status: Idle
                                         Progress: Idle for 00:08:19
                                             Type: Regular
                                         Schedule: -
                           Efficiency Policy Name: auto
                           Blocks Skipped Sharing: 0
                             Last Operation State: Success
                     Last Success Operation Begin: Fri Mar 31 16:20:17 2023
                       Last Success Operation End: Fri Mar 31 16:20:25 2023
                             Last Operation Begin: Fri Mar 31 16:20:17 2023
                               Last Operation End: Fri Mar 31 16:20:25 2023
                              Last Operation Size: 2.21GB
                             Last Operation Error: -
                                  Changelog Usage: 0%
                                Logical Data Size: 14.89GB
                               Logical Data Limit: 640TB
                             Logical Data Percent: 0%
                                       Queued Job: -
                     Stale Fingerprint Percentage: 0
                                      Compression: false
                               Inline Compression: true
                          Storage Efficiency Mode: efficient
                               Constituent Volume: false
                                    Inline Dedupe: true
                                  Data Compaction: true
                Cross Volume Inline Deduplication: false
            Cross Volume Background Deduplication: false
                         Extended Compressed Data: true

重複排除により4.77GBほど削減できていました。

そうなると、やはりリカバリーキューからリカバリーした影響が高そうです。

NetAppのKBを確認すると、優先度の低いボリュームは自動バックグラウど重複排除の対象でなくなるようです。

AFF では、自動ポリシーが設定されているすべてのボリュームが監視され、節約量が少ないボリュームや頻繁に上書きされるボリュームの優先順位が解除されます。

  • 優先度が下がったボリュームは、自動バックグラウンド重複排除の対象ではなくなります。
  • 優先度が下がったボリュームの変更ロギングは無効になり、ボリューム上のメタデータは切り捨てられます。

advanced volume efficiency promote 権限レベルのコマンドを使用すると、優先度が下がったボリュームを昇格させて、自動バックグラウンド重複排除の対象に戻すことができます。

優先順位の低い FlexVol をプロモートする方法 - NetApp

こちらに従い、volume efficiency promoteでボリュームの優先度を上げて自動バックグラウンド重複排除の対象に戻してあげます。

# 権限レベルを advanced に変更
::> set advanced

Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

# ボリュームの優先度を上げる
::*> volume efficiency promote -vserver SVM -volume vol_recovery_test
Volume "vol_recovery_test" of Vserver "SVM" has been made available for automatic deduplication scheduling.

# Storage Efficiencyの実行
::> volume efficiency start -vserver SVM -volume vol_recovery_test
The efficiency operation for volume "vol_recovery_test" of Vserver "SVM" has started.

# Storage Efficiencyによるデータ削減量の確認
::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume            available total   used    percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM     vol_recovery_test 2.11GB    15.20GB 13.09GB 86%          1.76GB          12%                     1.76GB             12%                        60KB

volume efficiency promoteにより、ボリュームの優先度を上げたことにより、volume efficiency startを受け付けるようになりました。

しかし、待ってもなかなか重複排除が進みません。

NetApp公式ドキュメントを確認すると-scan-old-dataを付与することで既に保存済みのデータブロックに対して重複排除をかけることができそうでした。

You can run the efficiency operations manually on the data that exists in non-temperature sensitive storage efficiency volumes prior to enabling deduplication, data compression, or data compaction with ONTAP versions earlier than ONTAP 9.8. You can run these operations by using the volume efficiency start -scan-old-data command.

Run efficiency operations manually on existing data

実際に試してみます。

# Storage Efficiencyの実行
::> volume efficiency start -vserver SVM -volume vol_recovery_test -scan-old-data

Warning: This operation scans all of the data in volume "vol_recovery_test" of Vserver "SVM". It might take a
         significant time, and degrade performance during that time.
Do you want to continue? {y|n}: y
The efficiency operation for volume "vol_recovery_test" of Vserver "SVM" has started.

# Storage Efficiencyの状態の確認
::> volume efficiency show -vserver SVM -volume vol_recovery_test

                                     Vserver Name: SVM
                                      Volume Name: vol_recovery_test
                                      Volume Path: /vol/vol_recovery_test
                                            State: Enabled
                                           Status: Active
                                         Progress: 3221504 KB Scanned
                                             Type: Regular
                                         Schedule: -
                           Efficiency Policy Name: auto
                           Blocks Skipped Sharing: 0
                             Last Operation State: Success
                     Last Success Operation Begin: Fri Mar 31 15:54:28 2023
                       Last Success Operation End: Fri Mar 31 15:54:28 2023
                             Last Operation Begin: Fri Mar 31 15:54:28 2023
                               Last Operation End: Fri Mar 31 15:54:28 2023
                              Last Operation Size: 0B
                             Last Operation Error: -
                                  Changelog Usage: 0%
                                Logical Data Size: 14.84GB
                               Logical Data Limit: 640TB
                             Logical Data Percent: 0%
                                       Queued Job: -
                     Stale Fingerprint Percentage: 0
                                      Compression: false
                               Inline Compression: true
                          Storage Efficiency Mode: efficient
                               Constituent Volume: false
                                    Inline Dedupe: true
                                  Data Compaction: true
                Cross Volume Inline Deduplication: false
            Cross Volume Background Deduplication: false
                         Extended Compressed Data: true

# Storage Efficiecnyによるデータ削減量の確認
::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume            available total   used    percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM     vol_recovery_test 2.19GB    15.20GB 13.01GB 85%          1.84GB          12%                     1.84GB             12%                        64KB

::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume            available total   used    percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM     vol_recovery_test 2.48GB    15.20GB 12.71GB 83%          2.16GB          15%                     2.16GB             15%                        76KB

::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume            available total   used    percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM     vol_recovery_test 4.05GB    15.20GB 11.14GB 73%          3.70GB          25%                     3.70GB             25%                        124KB

# Storage Efficiencyの状態の確認
::> volume show -volume vol_recovery_test -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume            available total   used    percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM     vol_recovery_test 5.07GB    15.20GB 10.13GB 66%          4.77GB          32%                     4.77GB             32%                        160KB

::> volume efficiency show -vserver SVM -volume vol_recovery_test

                                     Vserver Name: SVM
                                      Volume Name: vol_recovery_test
                                      Volume Path: /vol/vol_recovery_test
                                            State: Enabled
                                           Status: Idle
                                         Progress: Idle for 00:03:51
                                             Type: Regular
                                         Schedule: -
                           Efficiency Policy Name: auto
                           Blocks Skipped Sharing: 0
                             Last Operation State: Success
                     Last Success Operation Begin: Fri Mar 31 15:56:44 2023
                       Last Success Operation End: Fri Mar 31 16:17:11 2023
                             Last Operation Begin: Fri Mar 31 15:56:44 2023
                               Last Operation End: Fri Mar 31 16:17:11 2023
                              Last Operation Size: 14.77GB
                             Last Operation Error: -
                                  Changelog Usage: 0%
                                Logical Data Size: 14.91GB
                               Logical Data Limit: 640TB
                             Logical Data Percent: 0%
                                       Queued Job: -
                     Stale Fingerprint Percentage: 0
                                      Compression: false
                               Inline Compression: true
                          Storage Efficiency Mode: efficient
                               Constituent Volume: false
                                    Inline Dedupe: true
                                  Data Compaction: true
                Cross Volume Inline Deduplication: false
            Cross Volume Background Deduplication: false
                         Extended Compressed Data: true

すると、ジワジワと重複排除によるデータ削減量が増えていきました。最終的には先に作成したボリュームと同じく4.77GBのデータ量を削減することができました。

ボリュームの削除とリカバリー

手間取りましが、この状態でボリュームの削除とリカバリーを行います。

まず、ボリュームの削除です。

# ボリュームをオフラインに変更
::> volume offline -vserver SVM -volume vol_recovery_test

Warning: Volume "vol_recovery_test" on Vserver "SVM" must be unmounted before being taken offline or restricted.
         Clients will not be able to access the affected volume and related junction paths after that.  Do you still
         want to unmount the volume and continue? {y|n}: y
Volume "SVM:vol_recovery_test" is now offline.

# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test

Info: Volume "vol_recovery_test" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
      The space used by the volume will be recovered only after the retention period of 12 hours has completed. To
      recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
      vol_recovery_test_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
      recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
      <volume_name>" command.

Warning: Are you sure you want to delete volume "vol_recovery_test" in Vserver "SVM" ? {y|n}: y
[Job 1348] Job succeeded: Successful

# ボリュームが削除されたことを確認
::> volume show -vserver SVM -volume vol_recovery_test -fields state, type, size, available, used, junction-path
There are no entries matching your query.

ボリュームを削除後、SSDの空き容量と使用量を確認します。

# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
                                       Available
Vserver        Aggregate      State         Size Type    SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM            aggr1          online     787.6GB ssd     non-snaplock

# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space

      Aggregate : aggr1
      Performance Tier
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Volume Footprints                             72.80GB         8%
      Aggregate Metadata                             6.88GB         1%
      Snapshot Reserve                              45.36GB         5%
      Total Used                                    119.5GB        13%

      Total Physical Used                           68.51GB         8%


      Total Provisioned Space                       100.1TB
                                                                11302%


      Aggregate : aggr1
      Object Store: FSxFabricpoolObjectStore
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Logical Used                                  867.6MB          -
      Logical Referenced Capacity                   867.6MB          -
      Logical Unreferenced Capacity                      0B          -

      Total Physical Used                           867.6MB          -



2 entries were displayed.

10GBのボリュームを追加していることを加味すると、削除後もボリュームの使用量は変わっていないことが分かります。

削除したボリュームをリカバリーキューからリカバリーします。

# 権限レベルを advanced に変更
::> set advanced

Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

# ボリュームリカバリーキューの確認
::*> volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
SVM       vol_recovery_test_1098
                      Fri Mar 31 16:45:58 2023               12

# ボリュームリカバリーキュー内のボリュームのリカバリー
::*> volume recovery-queue recover -vserver SVM -volume vol_recovery_test_1098
Notice: When you bring a recovered volume online, there may be a temporary drop in performance for all volumes in the same aggregate.

Volume recovery successful for volume "vol_recovery_test_1098" in Vserver "SVM".

# リカバリーしたボリュームの確認
::*> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume                 size state   junction-path available used type
------- ---------------------- ---- ------- ------------- --------- ---- ----
SVM     vol_recovery_test_1098 16GB offline -             -         -    RW
SVM     vol_recovery_test_2    16GB online  /vol_recovery_test_2
                                                          5.08GB    10.12GB
                                                                         RW
2 entries were displayed.

# ボリューム名を変更
::*> volume rename -vserver SVM -volume vol_recovery_test_1098 -newname vol_recovery_test
[Job 1350] Job is queued: Rename vol_recovery_test_1098 to vol_recovery_test.                                           
[Job 1350] Job succeeded: Successful

# ボリュームをオンラインに
::*> volume online -vserver SVM -volume vol_recovery_test
Volume "SVM:vol_recovery_test" is now online.

# ジャンクションパスへのマウント
::*> volume mount -vserver SVM -volume vol_recovery_test -junction-path /vol_recovery_test

# リカバリーしたボリュームの確認
::*> volume show -vserver SVM -volume vol_recovery_test* -fields state, type, size, available, used, junction-path
vserver volume            size state  junction-path      available used    type
------- ----------------- ---- ------ ------------------ --------- ------- ----
SVM     vol_recovery_test 16GB online /vol_recovery_test 5.07GB    10.13GB RW
SVM     vol_recovery_test_2
                          16GB online /vol_recovery_test_2
                                                         5.08GB    10.12GB RW
2 entries were displayed.

# Storage Efficiencyによるデータ削減量の確認
::*> volume show -volume vol_recovery_test* -fields total, used, available, percent-used, sis-space-saved, sis-space-saved-percent, dedupe-space-saved, dedupe-space-saved-percent, dedupe-space-shared
vserver volume            available total   used    percent-used sis-space-saved sis-space-saved-percent dedupe-space-saved dedupe-space-saved-percent dedupe-space-shared
------- ----------------- --------- ------- ------- ------------ --------------- ----------------------- ------------------ -------------------------- -------------------
SVM     vol_recovery_test 5.07GB    15.20GB 10.13GB 66%          4.77GB          32%                     4.77GB             32%                        160KB
SVM     vol_recovery_test_2
                          5.08GB    15.20GB 10.12GB 66%          4.77GB          32%                     4.77GB             32%                        0B
2 entries were displayed.

リカバリーした場合もStorage Efficiencyによるデータ削減量は維持してくれることが分かりました。

リカバリー後のボリュームがStorage Efficiencyの優先度が下がっているか確認

再度リカバリー後のボリュームがStorage Efficiencyの優先度が下がっているかを確認します。

# Storage Efficiencyの手動実行
::*> volume efficiency start -vserver SVM -volume vol_recovery_test
The efficiency operation for volume "vol_recovery_test" of Vserver "SVM" has started.

# Storage Efficiencyの状態の確認
::*> volume efficiency show -vserver SVM -volume vol_recovery_test

                                     Vserver Name: SVM
                                      Volume Name: vol_recovery_test
                                      Volume Path: /vol/vol_recovery_test
                                            State: Enabled
                                           Status: Idle
                                         Progress: Idle for 00:00:34
                                             Type: Regular
                                         Schedule: -
                           Efficiency Policy Name: auto
                           Blocks Skipped Sharing: 0
                             Last Operation State: Success
                     Last Success Operation Begin: Fri Mar 31 17:03:24 2023
                       Last Success Operation End: Fri Mar 31 17:03:24 2023
                             Last Operation Begin: Fri Mar 31 17:03:24 2023
                               Last Operation End: Fri Mar 31 17:03:24 2023
                              Last Operation Size: 0B
                             Last Operation Error: -
                                  Changelog Usage: 0%
                                Logical Data Size: 14.89GB
                               Logical Data Limit: 640TB
                             Logical Data Percent: 0%
                                       Queued Job: -
                     Stale Fingerprint Percentage: 0
                                      Compression: false
                               Inline Compression: true
                                 Compression Type: adaptive
                          Storage Efficiency Mode: efficient
                               Constituent Volume: false
                                    Inline Dedupe: true
                                  Data Compaction: true
                Cross Volume Inline Deduplication: false
            Cross Volume Background Deduplication: false
                         Extended Compressed Data: true

volume efficiency startできてしまいました。リカバリー後に優先度が下がったのは偶然だったのでしょうか。

階層化ポリシーをAllにしたボリュームのリカバリー

階層化ポリシーの変更

次に階層化ポリシーをAllにしたボリュームをリカバリーした際の挙動を確認します。

リカバリー時にキャパシティプールストレージにあるデータもSSDに一度書き込まれるのか気になりますね。

まず、階層化ポリシーをAllに変更します。

# 現在の階層化ポリシーの確認
::> volume show -vserver SVM -volume vol_recovery_test -fields tiering-policy
vserver volume            tiering-policy
------- ----------------- --------------
SVM     vol_recovery_test none

# 各階層の使用量の確認
::> volume show-footprint -vserver SVM -volume vol_recovery_test

                                       Vserver: SVM
                                   Volume Name: vol_recovery_test
                                   Volume MSID: 2156877944
                                   Volume DSID: 1098
                                  Vserver UUID: 49892dec-8ccc-11ed-946a-5191ab1a5297
                                Aggregate Name: aggr1
                                Aggregate UUID: b7e5d9c9-8ccb-11ed-946a-5191ab1a5297
                                      Hostname: FsxId05f72eb8f8d03c709-01
                Tape Backup Metadata Footprint: -
        Tape Backup Metadata Footprint Percent: -
                       Deduplication Footprint: 60.13MB
               Deduplication Footprint Percent: 0%
             Temporary Deduplication Footprint: -
     Temporary Deduplication Footprint Percent: -
          Cross Volume Deduplication Footprint: -
  Cross Volume Deduplication Footprint Percent: -
Cross Volume Temporary Deduplication Footprint: -
Cross Volume Temporary Deduplication Footprint Percent: -
                         Volume Data Footprint: 10.18GB
                 Volume Data Footprint Percent: 1%
            Flexible Volume Metadata Footprint: 92.66MB
    Flexible Volume Metadata Footprint Percent: 0%
                           Delayed Free Blocks: 155.0MB
                   Delayed Free Blocks Percent: 0%
              SnapMirror Destination Footprint: -
      SnapMirror Destination Footprint Percent: -
                              Volume Guarantee: 0B
                      Volume Guarantee Percent: 0%
                       File Operation Metadata: -
               File Operation Metadata Percent: -
                               Total Footprint: 10.49GB
                       Total Footprint Percent: 1%
                     Containing Aggregate Size: 907.1GB
                                 Name for bin0: Performance Tier
                     Volume Footprint for bin0: 10.34GB
                 Volume Footprint bin0 Percent: 100%
                                 Name for bin1: FSxFabricpoolObjectStore
                     Volume Footprint for bin1: 0B
                 Volume Footprint bin1 Percent: 0%
                 Total Deduplication Footprint: 60.13MB
         Total Deduplication Footprint Percent: 0%
Footprint Data Reduction by Auto Adaptive Compression: 94.41MB
Footprint Data Reduction by Auto Adaptive Compression Percent: 0%
                Total Footprint Data Reduction: 94.41MB
        Total Footprint Data Reduction Percent: 0%
Effective Total after Footprint Data Reduction: 10.39GB
Effective Total after Footprint Data Reduction Percent: 1%

# 階層化ポリシーをAllに変更
::> volume modify -vserver SVM -volume vol_recovery_test -tiering-policy all
Volume modify successful on volume vol_recovery_test of Vserver SVM.

# 階層化ポリシーがAllになったことを確認
::> volume show -vserver SVM -volume vol_recovery_test -fields tiering-policy
vserver volume            tiering-policy
------- ----------------- --------------
SVM     vol_recovery_test all

# ほとんどのデータがSSDからキャパシティプールに階層化されたことを確認
::> volume show-footprint -vserver SVM -volume vol_recovery_test

                                       Vserver: SVM
                                   Volume Name: vol_recovery_test
                                   Volume MSID: 2156877944
                                   Volume DSID: 1098
                                  Vserver UUID: 49892dec-8ccc-11ed-946a-5191ab1a5297
                                Aggregate Name: aggr1
                                Aggregate UUID: b7e5d9c9-8ccb-11ed-946a-5191ab1a5297
                                      Hostname: FsxId05f72eb8f8d03c709-01
                Tape Backup Metadata Footprint: -
        Tape Backup Metadata Footprint Percent: -
                       Deduplication Footprint: 60.13MB
               Deduplication Footprint Percent: 0%
             Temporary Deduplication Footprint: -
     Temporary Deduplication Footprint Percent: -
          Cross Volume Deduplication Footprint: -
  Cross Volume Deduplication Footprint Percent: -
Cross Volume Temporary Deduplication Footprint: -
Cross Volume Temporary Deduplication Footprint Percent: -
                         Volume Data Footprint: 10.18GB
                 Volume Data Footprint Percent: 1%
            Flexible Volume Metadata Footprint: 92.66MB
    Flexible Volume Metadata Footprint Percent: 0%
                           Delayed Free Blocks: 159.2MB
                   Delayed Free Blocks Percent: 0%
              SnapMirror Destination Footprint: -
      SnapMirror Destination Footprint Percent: -
                              Volume Guarantee: 0B
                      Volume Guarantee Percent: 0%
                       File Operation Metadata: -
               File Operation Metadata Percent: -
                               Total Footprint: 10.49GB
                       Total Footprint Percent: 1%
                     Containing Aggregate Size: 907.1GB
                                 Name for bin0: Performance Tier
                     Volume Footprint for bin0: 348.6MB
                 Volume Footprint bin0 Percent: 3%
                                 Name for bin1: FSxFabricpoolObjectStore
                     Volume Footprint for bin1: 10GB
                 Volume Footprint bin1 Percent: 97%
                 Total Deduplication Footprint: 60.13MB
         Total Deduplication Footprint Percent: 0%
Footprint Data Reduction by Auto Adaptive Compression: 3.11MB
Footprint Data Reduction by Auto Adaptive Compression Percent: 0%
                Total Footprint Data Reduction: 3.11MB
        Total Footprint Data Reduction Percent: 0%
Effective Total after Footprint Data Reduction: 10.49GB
Effective Total after Footprint Data Reduction Percent: 1%

階層化ポリシーをAllにすることで、10GB分のデータをキャパシティプールストレージに階層化されことを確認できました。

SSDの空き容量や使用量を確認すると、10GB分変動していました。

# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
                                       Available
Vserver        Aggregate      State         Size Type    SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM            aggr1          online     797.6GB ssd     non-snaplock

# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space

      Aggregate : aggr1
      Performance Tier
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Volume Footprints                             62.81GB         7%
      Aggregate Metadata                             1.51GB         0%
      Snapshot Reserve                              45.36GB         5%
      Total Used                                    109.5GB        12%

      Total Physical Used                           68.57GB         8%


      Total Provisioned Space                       100.1TB
                                                                11302%


      Aggregate : aggr1
      Object Store: FSxFabricpoolObjectStore
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Logical Used                                  10.93GB          -
      Logical Referenced Capacity                   10.91GB          -
      Logical Unreferenced Capacity                 21.69MB          -
      Space Saved by Storage Efficiency             99.22KB          -

      Total Physical Used                           10.93GB          -



2 entries were displayed.

ボリュームの削除とリカバリー

この状態でボリュームの削除とリカバリーを行います。

まず、ボリュームの削除です。

# ボリュームをオフラインに変更
::> volume offline -vserver SVM -volume vol_recovery_test

Warning: Volume "vol_recovery_test" on Vserver "SVM" must be unmounted before being taken offline or restricted.
         Clients will not be able to access the affected volume and related junction paths after that.  Do you still
         want to unmount the volume and continue? {y|n}: y
Volume "SVM:vol_recovery_test" is now offline.

# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test

Info: Volume "vol_recovery_test" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
      The space used by the volume will be recovered only after the retention period of 12 hours has completed. To
      recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
      vol_recovery_test_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
      recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
      <volume_name>" command.

Warning: Are you sure you want to delete volume "vol_recovery_test" in Vserver "SVM" ? {y|n}: y
[Job 1354] Job succeeded: Successful

# ボリュームが削除されたことを確認
::> volume show -vserver SVM -volume vol_recovery_test -fields state, type, size, available, used, junction-path
There are no entries matching your query.

ボリュームを削除後、SSDの空き容量とSSDとキャパシティプールストレージの使用量の確認

# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
                                       Available
Vserver        Aggregate      State         Size Type    SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM            aggr1          online     797.6GB ssd     non-snaplock

# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space

      Aggregate : aggr1
      Performance Tier
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Volume Footprints                             62.81GB         7%
      Aggregate Metadata                             1.51GB         0%
      Snapshot Reserve                              45.36GB         5%
      Total Used                                    109.5GB        12%

      Total Physical Used                           68.58GB         8%


      Total Provisioned Space                       100.1TB
                                                                11302%


      Aggregate : aggr1
      Object Store: FSxFabricpoolObjectStore
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Logical Used                                  10.93GB          -
      Logical Referenced Capacity                   10.91GB          -
      Logical Unreferenced Capacity                 21.69MB          -
      Space Saved by Storage Efficiency             99.22KB          -

      Total Physical Used                           10.93GB          -



2 entries were displayed.

ボリューム削除前後で変わりありませんね。これはリカバリーしても一度SSDに書き込まれるという挙動はしなさそうです。

削除したボリュームをリカバリーキューからリカバリーします。

# 権限レベルを advanced に変更
::> set advanced

Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

# ボリュームリカバリーキューの確認
::*> volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
SVM       vol_recovery_test_1098
                      Fri Mar 31 17:28:04 2023               12

# ボリュームリカバリーキュー内のボリュームのリカバリー
::*> volume recovery-queue recover -vserver SVM -volume vol_recovery_test_1098
Notice: When you bring a recovered volume online, there may be a temporary drop in performance for all volumes in the same aggregate.

Volume recovery successful for volume "vol_recovery_test_1098" in Vserver "SVM".

# 権限レベルを admin に変更
::*> set admin

# ボリューム名を変更
::> volume rename -vserver SVM -volume vol_recovery_test_1098 -newname vol_recovery_test
[Job 1356] Job is queued: Rename vol_recovery_test_1098 to vol_recovery_test.                                           [Job 1356] Job succeeded: Successful

# ボリュームをオンラインに
::> volume online -vserver SVM -volume vol_recovery_test
Volume "SVM:vol_recovery_test" is now online.

# ジャンクションパスへのマウント
::> volume mount -vserver SVM -volume vol_recovery_test -junction-path /vol_recovery_test

# リカバリーしたボリュームの確認
::> volume show -vserver SVM -volume vol_recovery_test -fields state, type, size, available, used, junction-path
vserver volume            size state  junction-path      available used    type
------- ----------------- ---- ------ ------------------ --------- ------- ----
SVM     vol_recovery_test 16GB online /vol_recovery_test 5.08GB    10.12GB RW

何事もなくリカバリーできました。

階層化ポリシーと各階層の使用量を確認します。

# 階層化ポリシーの確認
::> volume show -vserver SVM -volume vol_recovery_test -fields tiering-policy
vserver volume            tiering-policy
------- ----------------- --------------
SVM     vol_recovery_test all

# 各階層の使用量の確認
::> volume show-footprint -vserver SVM -volume vol_recovery_test

                                       Vserver: SVM
                                   Volume Name: vol_recovery_test
                                   Volume MSID: 2156877944
                                   Volume DSID: 1098
                                  Vserver UUID: 49892dec-8ccc-11ed-946a-5191ab1a5297
                                Aggregate Name: aggr1
                                Aggregate UUID: b7e5d9c9-8ccb-11ed-946a-5191ab1a5297
                                      Hostname: FsxId05f72eb8f8d03c709-01
                Tape Backup Metadata Footprint: -
        Tape Backup Metadata Footprint Percent: -
                       Deduplication Footprint: 60.13MB
               Deduplication Footprint Percent: 0%
             Temporary Deduplication Footprint: -
     Temporary Deduplication Footprint Percent: -
          Cross Volume Deduplication Footprint: -
  Cross Volume Deduplication Footprint Percent: -
Cross Volume Temporary Deduplication Footprint: -
Cross Volume Temporary Deduplication Footprint Percent: -
                         Volume Data Footprint: 10.18GB
                 Volume Data Footprint Percent: 1%
            Flexible Volume Metadata Footprint: 92.66MB
    Flexible Volume Metadata Footprint Percent: 0%
                           Delayed Free Blocks: 159.3MB
                   Delayed Free Blocks Percent: 0%
              SnapMirror Destination Footprint: -
      SnapMirror Destination Footprint Percent: -
                              Volume Guarantee: 0B
                      Volume Guarantee Percent: 0%
                       File Operation Metadata: -
               File Operation Metadata Percent: -
                               Total Footprint: 10.49GB
                       Total Footprint Percent: 1%
                     Containing Aggregate Size: 907.1GB
                                 Name for bin0: Performance Tier
                     Volume Footprint for bin0: 348.8MB
                 Volume Footprint bin0 Percent: 3%
                                 Name for bin1: FSxFabricpoolObjectStore
                     Volume Footprint for bin1: 10GB
                 Volume Footprint bin1 Percent: 97%
                 Total Deduplication Footprint: 60.13MB
         Total Deduplication Footprint Percent: 0%
Footprint Data Reduction by Auto Adaptive Compression: 3.11MB
Footprint Data Reduction by Auto Adaptive Compression Percent: 0%
                Total Footprint Data Reduction: 3.11MB
        Total Footprint Data Reduction Percent: 0%
Effective Total after Footprint Data Reduction: 10.49GB
Effective Total after Footprint Data Reduction Percent: 1%

こちらもリカバリー前後と比較して変わりありません。階層化ポリシーがAllでも安心してリカバリーできますね。

リカバリーキュー内のボリュームの削除

SSDの空き容量を確保するためにリカバリーキュー内のボリュームを削除したい時があると思います。

もちろん、そのような操作も可能です。

1つのボリュームを削除したい場合はvolume recovery-queue purgeで、リカバリーキュー内の全てのボリュームを全て削除したい場合はvolume recovery-queue purge-allで行えます。

実際にvolume recovery-queue purgeを試してみます。

まず、ボリュームを削除します。

# ボリュームをオフラインに変更
::> volume offline -vserver SVM -volume vol_recovery_test

Warning: Volume "vol_recovery_test" on Vserver "SVM" must be unmounted before being taken offline or restricted.
         Clients will not be able to access the affected volume and related junction paths after that.  Do you still
         want to unmount the volume and continue? {y|n}: y
Volume "SVM:vol_recovery_test" is now offline.

# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test

Info: Volume "vol_recovery_test" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
      The space used by the volume will be recovered only after the retention period of 12 hours has completed. To
      recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
      vol_recovery_test_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
      recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
      <volume_name>" command.

Warning: Are you sure you want to delete volume "vol_recovery_test" in Vserver "SVM" ? {y|n}: y
[Job 1359] Job succeeded: Successful

ボリューム削除後、リカバリーキュー内のボリュームを削除します。

# 権限レベルを advanced に変更
::> set advanced

Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

# ボリュームリカバリーキューの確認
::*> volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
SVM       vol_recovery_test_1098
                      Fri Mar 31 17:50:59 2023               12

# リカバリーキュー内のボリュームの削除
::*> volume recovery-queue purge -vserver SVM -volume vol_recovery_test_1098
[Job 1361] Job succeeded: Successful

# リカバリーキュー内のボリュームが削除されたことを確認
::*> volume recovery-queue show
This table is currently empty.

リカバリーキュー内のボリュームが削除されましたね。削除時に特に警告はないようです。

削除後、SSDの空き容量とSSDとキャパシティプールストレージの使用量の確認します。

# 権限レベルを admin に変更
::*> set admin

# SSDの空き容量の確認
::> vserver show-aggregates -vserver SVM
                                       Available
Vserver        Aggregate      State         Size Type    SnapLock Type
-------------- -------------- ------- ---------- ------- --------------
SVM            aggr1          online     798.1GB ssd     non-snaplock

# SSDとキャパシティプールストレージの使用量の確認
::> aggr show-space

      Aggregate : aggr1
      Performance Tier
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Volume Footprints                             62.32GB         7%
      Aggregate Metadata                             1.41GB         0%
      Snapshot Reserve                              45.36GB         5%
      Total Used                                    109.0GB        12%

      Total Physical Used                           68.29GB         8%


      Total Provisioned Space                       100.1TB
                                                                11301%


      Aggregate : aggr1
      Object Store: FSxFabricpoolObjectStore
      Feature                                          Used      Used%
      --------------------------------           ----------     ------
      Logical Used                                  867.6MB          -
      Logical Referenced Capacity                   867.6MB          -
      Logical Unreferenced Capacity                      0B          -

      Total Physical Used                           867.6MB          -



2 entries were displayed.

階層化ポリシーがAllのボリュームを削除したのでSSDの変化は分かりづらいですが、キャパシティプールストレージの使用量が10.93GBから867.6MBと大きく減っていることが分かります。

ボリュームを削除してSSDの空きを確保したい場合に役立ちそうですね。

リカバリーキューの保持期間の変更

場合によってはリカバリーキューの保持期間を12時間から変更したい場面もあると思います。

そのような場合はvserver modify-volume-delete-retention-hoursで指定します。

こちらのオプションを指定する場合は権限レベルがdiagnosticである必要があります。

# advanced だと -volume-delete-retention-hours が指定できないことを確認
::*> vserver modify ?
   [-vserver] <vserver name>                                     Vserver
  [ -language <language_code> ]                                  Default Volume Language Code
  [ -snapshot-policy <snapshot policy> ]                         Snapshot Policy
  [ -comment <text (size 0..255)> ]                              Comment
  [ -quota-policy <text (size 1..32)> ]                          Quota Policy
  [ -aggr-list <aggregate name>, ... ]                           List of Aggregates Assigned
  [ -max-volumes {<integer>|unlimited} ]                         Limit on Maximum Number of Volumes allowed
  [ -admin-state {running|stopped|starting|stopping} ]           *Vserver Admin State
  [ -allowed-protocols {nfs|cifs|fcp|iscsi|ndmp|nvme}, ... ]     Allowed Protocols
  [ -disallowed-protocols {nfs|cifs|fcp|iscsi|ndmp|nvme}, ... ]  Disallowed Protocols
  [ -qos-policy-group <text> ]                                   QoS Policy Group
  [ -caching-policy <text> ]                                     Caching Policy Name
  [ -is-space-reporting-logical {true|false} ]                   Logical Space Reporting
  [ -is-space-enforcement-logical {true|false} ]                 Logical Space Enforcement
  [ -anti-ransomware-default-volume-state {disabled|dry-run} ]   Default Anti_ransomware State of the Vserver\'s Volumes


::*> set diag

Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y

# diagnostic だと -volume-delete-retention-hours が指定できることを確認
::*> vserver modify ?
   [-vserver] <vserver name>                                     Vserver
  [ -language <language_code> ]                                  Default Volume Language Code
  [ -snapshot-policy <snapshot policy> ]                         Snapshot Policy
  [ -comment <text (size 0..255)> ]                              Comment
  [ -quota-policy <text (size 1..32)> ]                          Quota Policy
  [ -aggr-list <aggregate name>, ... ]                           List of Aggregates Assigned
  [ -max-volumes {<integer>|unlimited} ]                         Limit on Maximum Number of Volumes allowed
  [ -admin-state {running|stopped|starting|stopping} ]           *Vserver Admin State
  [ -allowed-protocols {nfs|cifs|fcp|iscsi|ndmp|nvme}, ... ]     Allowed Protocols
  [ -disallowed-protocols {nfs|cifs|fcp|iscsi|ndmp|nvme}, ... ]  Disallowed Protocols
  [ -qos-policy-group <text> ]                                   QoS Policy Group
  [ -caching-policy <text> ]                                     Caching Policy Name
  [ -volume-delete-retention-hours <integer> ]                   *Volume Delete Retention Period
  [ -is-space-reporting-logical {true|false} ]                   Logical Space Reporting
  [ -is-space-enforcement-logical {true|false} ]                 Logical Space Enforcement
  [ -anti-ransomware-default-volume-state {disabled|dry-run} ]   Default Anti_ransomware State of the Vserver\'s Volumes

diagnosticは非常に強い権限です。そのため、NetAppのKBで紹介されている通り、NetAppのサポートがない限り使用してはいけません。

テクニカルサポートケースまたはプロフェッショナルサービス契約を通じてネットアップと連携 ネットアップのサポートがないかぎり、diagnostic権限レベルは絶対に設定しないでください

ONTAP でdiagnostic権限レベルを入力する方法 - NetApp

試しにリカバリーキューの保持期間を12時間から24時間に変更します。

# 現在のリカバリーキューの保持期間の確認
::*> vserver show -vserver SVM -fields volume-delete-retention-hours
vserver volume-delete-retention-hours
------- -----------------------------
SVM     12

# リカバリーキューの保持期間を24時間に変更
::*> vserver modify -vserver SVM -volume-delete-retention-hours 24

# リカバリーキューの保持期間を24時間に変更されたことを確認
::*> vserver show -vserver SVM -fields volume-delete-retention-hours
vserver volume-delete-retention-hours
------- -----------------------------
SVM     24

本当にリカバリーキューの保持期間が24時間になっているかリカバリーキュー内のボリュームを確認します。

まず、適当なボリュームを作成して削除して確認します。

# 権限レベルを admin に変更
::*> set admin

# ボリュームの作成
::> volume create -vserver SVM -volume vol_recovery_test_3 -aggregate aggr1 -size 16GB -state offline
Storage efficiency cannot be enabled on the volume "vol_recovery_test_3" of vserver "SVM" because the volume state is "offline". Bring the volume online, and then enable storage efficiency using the "volume efficiency modify" command.
[Job 1365] Job succeeded: Successful                                                                                    

# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test_3

Info: Volume "vol_recovery_test_3" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
      The space used by the volume will be recovered only after the retention period of 24 hours has completed. To
      recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
      vol_recovery_test_3_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
      recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
      <volume_name>" command.

Warning: Are you sure you want to delete volume "vol_recovery_test_3" in Vserver "SVM" ? {y|n}: y
[Job 1367] Job succeeded: Successful

ボリューム削除後、リカバリーキューを確認します。

# 権限レベルを advanced に変更
::> set advanced

Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

# リカバリーキューの確認
::*> volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
SVM       vol_recovery_test_3_1100
                      Fri Mar 31 18:16:53 2023               24

リカバリーキュー内のボリュームのRetention Hours24になりましたね。

ちなみに、volume-delete-retention-hoursを0に指定すると、リカバリーキューに保持されず、即座にボリュームが削除されます。0を指定しないように注意してください。

リカバリキューを無効にします

volume-delete-retention-hoursがゼロに設定されている場合、この機能はその SVM に対して無効になります。その後のボリューム削除要求では、ボリュームが完全に破棄され、ボリュームはリカバリキューに保持されません。この機能を無効にすることはお勧めしません。

::*> vserver modify -vserver <vserver_name> -volume-delete-retention-hours 0

ボリュームリカバリキューの使用方法 - NetApp

リカバリーキュー内のボリュームの保持期間の変更

vserver modify-volume-delete-retention-hoursで指定した値は、既にリカバリーキュー内にあるボリュームの保持期間に影響を与えません。

リカバリーキュー内のボリュームの保持期間の変更したい場合は、volume recovery-queue modifyを実行します。

試しに現在リカバリーキュー内にあるボリュームの保持期間を24時間から1時間に変更します。

::*> volume recovery-queue modify -vserver SVM -volume vol_recovery_test_3_1100 -retention-hours 1

::*>  volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
SVM       vol_recovery_test_3_1100
                      Fri Mar 31 18:16:53 2023                1

リカバリーキュー内のボリュームの保持期間を取り敢えず延長したい場合に役立ちそうです。

ボリューム削除時に -force を指定する

NetAppのKBを眺めていると、リカバリーキューの保持期間が経過していないにも関わらず、ボリュームが削除されることがあるようです。

どうやら、ボリューム削除時に-forceを付与すると、そのような挙動をするようです。

試してみましょう。

# ボリュームの作成
::> volume create -vserver SVM -volume vol_recovery_test_4 -aggregate aggr1 -size 16GB -state offline
Storage efficiency cannot be enabled on the volume "vol_recovery_test_4" of vserver "SVM" because the volume state is "offline". Bring the volume online, and then enable storage efficiency using the "volume efficiency modify" command.
[Job 1370] Job succeeded: Successful                                                                                    

# -force を指定できるか確認
::> volume delete -vserver SVM -volume vol_recovery_test_4 -?
  [ -foreground {true|false} ]  Foreground Process (default: true)

# 権限レベルを advanced に変更
::> set advanced

Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

# -force を指定できることを確認
::*> volume delete -vserver SVM -volume vol_recovery_test_4 -?
  [[-force] [true]]             *Force Delete
  [ -foreground {true|false} ]  Foreground Process (default: true)

# -force を指定してボリュームを削除
::*> volume delete -vserver SVM -volume vol_recovery_test_4 -force
[Job 1372] Job succeeded: Successful

この状態でリカバリーキューを確認します。

::*> volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
SVM       vol_recovery_test_3_1100
                      Fri Mar 31 18:16:53 2023                1

確かに削除したボリュームvol_recovery_test_4がリカバリーキューに存在していないですね。

FlexGroupボリュームのリカバリー

FlexGroupボリュームもリカバリーキューからリカバリーできるか確認しておきます。

適当にFlexGroupボリュームを作成します。

# FlexGroupボリュームを作成
::> volume create -vserver SVM -volume vol_recovery_test_5 -aggr-list aggr1 -aggr-list-multiplier 4 -size 16GB

Notice: The FlexGroup volume "vol_recovery_test_5" will be created with the following number of constituents of size
        4GB: 4.

Warning: The constituent size is smaller than the recommended minimum constituent size of 100GB. You should ensure that
         the size of a 4 constituent FlexGroup volume be at least 400GB (429496729600B), or the performance of the
         FlexGroup volume will be less than optimal.
Do you want to continue? {y|n}: y

Warning: You are attempting to create a FlexGroup volume in Vserver "SVM", which currently uses 32-bit NFSv3 FSIDs and
         file IDs. This could result in collisions between different file IDs on the FlexGroup volume. Modify the
         Vserver to use 64-bit NFSv3 identifiers before using the FlexGroup volume with the commands "set advanced;
         vserver nfs modify -vserver SVM -v3-64bit-identifiers enabled".
Do you want to continue? {y|n}: y
[Job 1374] Job succeeded: Successful

# FlexGroupボリュームの確認
::> volume show -vserver SVM -volume vol_recovery_test_5*
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM       vol_recovery_test_5
                       -            online     RW         16GB    14.98GB    1%

# FlexGroupボリュームのメンバーボリュームの確認
::> volume show -vserver SVM -volume vol_recovery_test_5* -is-constituent true
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM       vol_recovery_test_5__0001
                       aggr1        online     RW          4GB     3.74GB    1%
SVM       vol_recovery_test_5__0002
                       aggr1        online     RW          4GB     3.74GB    1%
SVM       vol_recovery_test_5__0003
                       aggr1        online     RW          4GB     3.74GB    1%
SVM       vol_recovery_test_5__0004
                       aggr1        online     RW          4GB     3.74GB    1%
4 entries were displayed.

FlexGroupボリュームを削除します。

# ボリュームをオフラインに
::> volume offline -vserver SVM -volume vol_recovery_test_5
Volume "SVM:vol_recovery_test_5" is now offline.

# ボリュームの削除
::> volume delete -vserver SVM -volume vol_recovery_test_5

Info: Volume "vol_recovery_test_5" in Vserver "SVM" will be marked as deleted and placed in the volume recovery queue.
      The space used by the volume will be recovered only after the retention period of 24 hours has completed. To
      recover the space immediately, get the volume name using (privilege:advanced) "volume recovery-queue show
      vol_recovery_test_5_*" and then "volume recovery-queue purge -vserver SVM -volume <volume_name>" command. To
      recover the volume use the (privilege:advanced) "volume recovery-queue recover -vserver SVM -volume
      <volume_name>" command.

Warning: Are you sure you want to delete volume "vol_recovery_test_5" in Vserver "SVM" ? {y|n}: y
[Job 1379] Job succeeded: Successful

# ボリュームが削除されたことを確認
::> volume show -vserver SVM -volume vol_recovery_test_5* -is-constituent true
There are no entries matching your query.

ボリュームが削除されましたね。

リカバリーキューを確認して、FlexGroupボリュームをリカバリーします。

# 権限レベルを advanced に変更
::> set advanced

Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y

# ボリュームリカバリーキューの確認
::*> volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
SVM       vol_recovery_test_3_1100
                      Fri Mar 31 18:16:53 2023                1
SVM       vol_recovery_test_5_2156877948
                      Fri Mar 31 19:40:20 2023               24
2 entries were displayed.

# FlexGroupボリュームのリカバリー
FsxId05f72eb8f8d03c709::*> volume recovery-queue recover -vserver SVM -volume vol_recovery_test_5_2156877948
Notice: When you bring a recovered volume online, there may be a temporary drop in performance for all volumes in the same aggregate.

Volume recovery successful for volume "vol_recovery_test_5_2156877948" in Vserver "SVM".

# 権限レベルを admin に変更
FsxId05f72eb8f8d03c709::*> set admin

# ボリュームがリカバリーされていることを確認
FsxId05f72eb8f8d03c709::> volume show -vserver SVM -volume vol_recovery_test_5* -is-constituent true
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM       vol_recovery_test_5_2156877948__0001
                       aggr1        offline    RW          4GB          -     -
SVM       vol_recovery_test_5_2156877948__0002
                       aggr1        offline    RW          4GB          -     -
SVM       vol_recovery_test_5_2156877948__0003
                       aggr1        offline    RW          4GB          -     -
SVM       vol_recovery_test_5_2156877948__0004
                       aggr1        offline    RW          4GB          -     -
4 entries were displayed.

::> volume show -vserver SVM -volume vol_recovery_test_5*
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM       vol_recovery_test_5_2156877948
                       -            offline    RW         16GB          -     -

# ボリュームの名前変更
::> volume rename -vserver SVM -volume vol_recovery_test_5_2156877948 -newname vol_recovery_test_5
[Job 1387] Job is queued: Rename vol_recovery_test_5_2156877948 to vol_recovery_test_5.                                 
[Job 1387] Job succeeded: Successful

# ボリュームをオンラインに
::> volume online -vserver SVM -volume vol_recovery_test_5
Volume "SVM:vol_recovery_test_5" is now online.

FsxId05f72eb8f8d03c709::>
FsxId05f72eb8f8d03c709::> volume show -vserver SVM -volume vol_recovery_test_5*
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM       vol_recovery_test_5
                       -            online     RW         16GB    15.03GB    1%

# ボリュームの状態を確認
::> volume show -vserver SVM -volume vol_recovery_test_5* -is-constituent true
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
SVM       vol_recovery_test_5__0001
                       aggr1        online     RW          4GB     3.74GB    1%
SVM       vol_recovery_test_5__0002
                       aggr1        online     RW          4GB     3.74GB    1%
SVM       vol_recovery_test_5__0003
                       aggr1        online     RW          4GB     3.74GB    1%
SVM       vol_recovery_test_5__0004
                       aggr1        online     RW          4GB     3.74GB    1%
4 entries were displayed.

FlexGroup特有のポイントは特になく、すんなりとリカバリーできました。

ボリューム削除時にはボリュームリカバリーキューを意識しよう

Amazon FSx for NetApp ONTAPでボリュームリカバリーキューを使ってみました。

ボリュームを間違えて削除してしまった場合は、バックアップからリストアするよりも高速にリカバリーすることができます。

これはありがたいですね。

一方で、リカバリーキューがあることにより、ボリュームを削除しても即座にSSDが解放されないことに気をつける必要があります。その場合は十分注意した上でリカバリーキュー内のボリュームを削除しましょう。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.