はじめに
前回は、FlashArray のスナップショットとリストア機能の概要をご紹介しました。連載 2 回目の今回は、より詳細な挙動と検証結果についてご紹介します。
スナップショットとコピー機能の動作
図 1 は、本番ボリューム（vol 1）からスナップショット（snap 1）を作成、そのスナップショットから新規にボリュームを作成（vol 2 – 以降、コピーボリューム ）した状態です。
スナップショットおよびコピー機能は、実データの配置はそのままにメタデータのみを作成するため、処理は一瞬で終わります。実データは本番ボリューム、スナップショット、コピーボリューム間で共有しているため、スナップショットおよびコピー機能による容量消費はありません。
次に（図 2 参照）、本番ボリューム（vol 1）またはコピーボリューム（vol 2）に書き込みが発生することで、既存のスナップショット（snap 1）との差分のみ容量を消費します。このとき、スナップショットのメタデータから実データへのポインタは変更されないため、スナップショットなしの状態と比較しても I/O 量の増加（オーバーヘッド）がなく、性能への影響はありません。
次に（図 3 参照）、任意のスナップショット（snap 1）を指定して対象ボリューム（vol 1）をリストアしたとします。この時、リストアに使用したスナップショットは削除されず、そのまま残るため、次回のリストアやコピーで使用可能です。このリストア処理は、対象ボリュームのメタデータから実データのポインタを変更するのみで、実データの配置はそのままで、I/O 量の増加もありません。そのため、リストア処理も一瞬で終わり、性能に影響もありません。リストア前に使用していた実データは無効フラグが立ち、空き容量としてカウントされるため、新規の書き込み発生時に再使用されます。
次に（図 4 参照）、コピーボリューム（vol 2）のソースであるスナップショット（snap 1）と、更にそのソースである本番ボリューム（vol 1）も削除したとします。それでもコピーボリュームの vol 2 は削除されずに残ります。この時も実データの配置はそのままであり、性能に影響はありません。
このように、コピー機能で作成したボリュームは、ソースとなるボリュームおよびスナップショットと依存関係がなく、独立したボリュームとして運用可能です。
スナップショットの検証結果
それでは、以下の環境で高負荷な I/O ワークロードを流しながら、大量のスナップショットの作成と削除を実行し、その性能への影響を見てみましょう。
- 環境
- ピュア・ストレージ FlashArray//M50R2 – Purity//FA 5.1.1
- Red Hat Enterprise Linux（VM）x 4台
- VM x 1 台にボリューム（LUN）x 2 をRaw Device Mapping（RDM）で接続
- 合計してボリューム（LUN）x 8 を FlashArray//X50R2 から提供
- 上記、VM x 4 からボリューム x 8 に Vdbench を使用して負荷を生成
- I/O ワークロード：16KB read 70% write 30% で 40,000 IOPS
- Vdbench
- スナップショットの作成
- 一度に、ボリューム x 8 のスナップショットを作成
- その後、1 秒間隔で 10 回繰り返し
- 約 10 秒の間に、合計スナップショット x 80 が作成される
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
[oracle@ora3 CloneDB]$ more 04_snap.sh #!/bin/sh PURE_IP=192.168.168.60 SNAP_NAME=snap COUNT=“1 2 3 4 5 6 7 8 9 10” for i in ${COUNT} do ssh pureuser@${PURE_IP} “purevol snap –suffix ${SNAP_NAME}-${i} iwamoto-vdb-1 iwamoto-vdb-2 iwamoto-vdb-3 iwamoto-vdb-4” sleep 1 done ssh pureuser@${PURE_IP} “purevol list –snap iwamoto-vdb-*” |
- スナップショットの削除
- 前の検証で作成した 80 スナップショットを同時に削除
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
[oracle@ora3 CloneDB]$ cat 05_snap_del.sh #!/bin/sh PURE_IP=192.168.168.60 SNAP_NAME=snap COUNT=“1 2 3 4 5 6 7 8 9 10” for i in ${COUNT} do ssh pureuser@${PURE_IP} “purevol destroy iwamoto-vdb-1.${SNAP_NAME}-${i}; purevol eradicate iwamoto-vdb-1.${SNAP_NAME}-${i}” ssh pureuser@${PURE_IP} “purevol destroy iwamoto-vdb-2.${SNAP_NAME}-${i}; purevol eradicate iwamoto-vdb-2.${SNAP_NAME}-${i}” ssh pureuser@${PURE_IP} “purevol destroy iwamoto-vdb-3.${SNAP_NAME}-${i}; purevol eradicate iwamoto-vdb-3.${SNAP_NAME}-${i}” ssh pureuser@${PURE_IP} “purevol destroy iwamoto-vdb-4.${SNAP_NAME}-${i}; purevol eradicate iwamoto-vdb-4.${SNAP_NAME}-${i}” done ssh pureuser@${PURE_IP} “purevol list –snap iwamoto-vdb-*” |
以下のグラフ（図 5）が検証結果です。オレンジ色のグラフが IOPS、水色のグラフが Vdbench から見たレスポンスタイムを示します。検証結果のとおり、IOPS はもちろんレスポンスタイムにも影響がなく、1.0 ms 以下を維持しています。
次回予告
次回は、スナップショットでバックアップを取得するスケジューリングと世代数管理を自動化したり、複数ボリューム間で一貫性のあるスナップショットを簡単に取得できる便利な機能「保護グループ（Protection Group）」についてご紹介します。
