Oracle Cloud Infrastructure(OCI)のブロック・ボリュームのバックアップサイズを縮小しよう
はじめに
先日(06/15)にブロック・ボリュームで SCSI UNMAP がサポートされたと リリースノート に記載されました
そこで、本記事ではSCSI UNMAPを行うことで、どれだけのバックアップ・サイズが縮小できるのかを検証してみたいと思います
なぜバックアップ・サイズが縮小されるのか？
SCSI UNMAPコマンドは、未使用領域を再利用するためにSSDドライブに送信できるTRIMコマンドに似ています。
SCSI UNMAPコマンドを送信して、アプリケーションまたはファイル・システムによって削除または使用されなくなったブロックを破棄して
解放するようにストレージ・サブシステムに指示します。
このコマンドを送信しない場合、ストレージ・サブシステムはブロックが使用されなくなったことを認識せず、すべてのバックアップに
これらのブロックを含め、新しいボリュームへのクローンを作成します。ストレージ・サブシステムがブロックのUNMAPコマンドを
受信すると、対応するブロックは破棄されて解放されるため、今後のバックアップおよびクローンから除外されます。
引用： SCSI UNMAPのサポート
と記載されているように、SCSI UNMAPコマンドを利用することで、ファイルを削除し使用しなくなったブロックを開放するようにストレージ・サブシステムに通知し、バックアップ対象から除外することが可能となります
その結果、バックアップ・サイズが縮小されることとなります
バックアップ・サイズの検証
環境
- OS は Oracle Linux 8 を使用
- 512GB の新規に作成したブロック・ボリュームをアタッチ
- ファイルシステムは XFS とし、/mnt/vol01 にマウント
- ディレクトリ、ファイルは何も作成しない
1. ブロック・ボリュームのバックアップを取得
ディレクトリ、ファイルは何も存在しません
|
1 2 |
# ls -lth /mnt/vol01 | head total 0 |
メタ情報の関係か4GBほど消費されていますが、ほぼ空の状態です
|
1 2 3 |
# df -h /mnt/vol01 Filesystem Size Used Avail Use% Mounted on /dev/mapper/volg01-lv_data 512G 3.6G 509G 1% /mnt/vol01 |
バックアップ・サイズが 1GB であることが確認できます
2. ダミーのテキストファイルを作成した後にバックアップを取得
以下のコマンドを実行し、 1GB のテキストファイルを 100 個作成します
|
1 |
# for i in $(seq -f '%03g' 1 100); do base64 /dev/urandom | head -c 1024M > /mnt/vol01/dummy-${i}.txt ; done |
1GB のファイルが作成されています（抜粋）
|
1 2 3 4 5 6 7 8 9 10 11 |
# ls -lth /mnt/vol01 | head total 100G -rw-r--r--. 1 root root 1.0G Jun 26 04:45 dummy-100.txt -rw-r--r--. 1 root root 1.0G Jun 26 04:44 dummy-099.txt -rw-r--r--. 1 root root 1.0G Jun 26 04:44 dummy-098.txt -rw-r--r--. 1 root root 1.0G Jun 26 04:44 dummy-097.txt -rw-r--r--. 1 root root 1.0G Jun 26 04:44 dummy-096.txt -rw-r--r--. 1 root root 1.0G Jun 26 04:44 dummy-095.txt -rw-r--r--. 1 root root 1.0G Jun 26 04:44 dummy-094.txt -rw-r--r--. 1 root root 1.0G Jun 26 04:43 dummy-093.txt -rw-r--r--. 1 root root 1.0G Jun 26 04:43 dummy-092.txt |
パーティションも 100GB 使用されていることが確認できます
|
1 2 3 |
# df -h /mnt/vol01 Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg01-lv_data 512G 104G 409G 21% /mnt/vol01 |
バックアップ・サイズも 100GB増加 したことが確認できます
3. ダミーファイルを削除した後にバックアップを取得
ダミーファイルを削除します
|
1 |
# rm -f /mnt/vol01/dummy-* |
ファイルが削除され、パーティションの使用率も元に戻っています
|
1 2 3 4 5 6 |
# ls -lth /mnt/vol01 | head total 0 # df -h /mnt/vol01 Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg01-lv_data 512G 3.6G 509G 1% /mnt/vol01 |
ファイルを削除しただけだと、バックアップ・サイズに変動はありません
4. UNMAP コマンドを手動で発行した後にバックアップを取得
ドキュメントに記載があるように、 fstrim コマンドを実行して、UNMAP コマンドをバックエンドに発行し、ファイルシステムによって削除されたブロックを開放します
|
1 2 |
# fstrim -v /mnt/vol01 /mnt/vol01: 511.8 GiB (549482930176 bytes) trimmed |
バックアップ・サイズが 51GB に縮小することが確認できましたが、なぜ 1GB に戻らないかの理由はドキュメントに記載があります
UNMAPは非決定的なコマンドであり、このコマンドを使用するときに、要求されたすべてのブロックがただちに破棄されるという保証はありません。
そのため、今回は約半分の 50GB が破棄されたため、バックアップ・サイズが 51GB になったということになります
まとめ
以上のように、UNMAP コマンドを発行することにより、バックアップ・サイズが縮小されることが確認できましたが、以下の注意点がございます
- 2023年6月14日より前にアタッチされたボリュームの場合、再アタッチなどの作業が必要
- すべての削除・未使用ブロックが開放されるとは限らず、実際の使用サイズでバックアップが取得される保証はありません
- ファイルシステムの削除・未使用ブロックが大量にある場合、 UNMAP コマンドが完了するのに時間がかかります
- UNMAP コマンドの時間は、ブロック・ボリュームの パフォーマンス・レベル や、ファイルシステムによって異なります
- UNMAP コマンドを使用しても、保証されたIOPSおよびスループットは影響しませんが、UNMAP コマンドの完了時間は影響を受けます
他にも注意点や自動実行の方法などがございますので、 ドキュメント を確認していただき、UNMAP コマンドの利用を検討していただければと思います
