[Unity] 押忍★Unity設計道場!!

Hello World!!
こんにちは、ネットワールド DELL EMC担当の、井之頭六郎（仮）です。

今日はUnityの設計指南ネタとして、Pool, Snapshotまわりのお話を少々。

まずUnityのストレージアーキテクチャについて概説ですが、
UnityではPoolという1つ以上のRaid Groupから構成される、ストレージの容量のプールを構成します。
そしてNASの容量となるFilesystemや、Blockの容量となるLUNは、このPoolから容量を指定して作成されます。
ちなみに複数のPoolが作れます。
ThinでFilesystemやLUNを作成した場合は、実際に使われた容量がPoolから消費され、
Thickの場合は指定の容量が作成時にPoolから消費されます。
（今更当たり前のことをすみません。。）

では、ここからはちょっとクイズ形式で。

Q1.
Snapshotのデータはどこに保存されるでしょうか？

Q2.
Snapshotはとるのも一瞬、消すのも一瞬？

Q3.
(非同期)Replicationの差分転送はどうやって実現されている？

Unityマスターの方にはEasyモードかもしれませんが、以降でUnityの仕様説明もかねて、
回答と、設計時に注意すべき点について見ていきたいと思います！

A1.
（Filesystem/LUNのもとになっている）Poolの空き容量を使ってSnapshotが保存されます。

というわけで、Snapshot機能を利用する場合は、Poolにどれだけ空き容量を持たせるかというのが設計要素の１つとなります。
Poolの容量は、Snapshotのほかにもにもデータ保存以外の用途で色々と使用されるため、常に10%はあけといてね！、というのがメーカーさんの推奨になります。
UnityのBest Practice Guideにもばっちり書かれていますので、要チェックです！

A2.
とるのは一瞬（環境によっては数秒、数十秒かかるかもしれません）、
消すのも一瞬かというと、、、（特にNL-SASの場合）答えは否、です。

UnityのSnapshotはRedirect on Writeという方式で、Snapshotが取得されている最新版のデータに書き込みがあると、新たにデータを書き込むブロックを確保して、最新版のデータはここですよー、というポインタの向き先情報をそちらに書き換えます。
なので、Snapshotをとるときは実データに対して大きな処理をする必要がありません。
では、消すときは・・？というと
削除対象のSnapshotのポインタ情報を削除すればいいだけだから一瞬でしょ！と思うんですが、（なにやら）Unityが内部で色々処理をしているようで、ある程度Diskへの負荷がかかるようです。
※実際にどのような処理が走っているかは、ロジックが公開されていないので私もわかりません、ｽｲﾏｾﾝ！！
そのため、上の回答で括弧で書いたようにNL-SASオンリーのPoolでSnapshotを多用してしまうと、その削除処理で非常に高負荷になってしまう可能性があります。
そして、気づかぬうちに本来は消えているべきSnapshotの削除処理が追い付かないため、意図せずにSnapshot削除処理がどんどん滞留してしまいます。
これをSnapshotの残留思念、あるいはZombi snapと呼んだりします。（私が勝手に。）
そうなると、Snapshotの容量によりPoolの容量は圧迫されたり、常にDiskが高付加でレスポンスがもっさりしたり、、そしてこの状況が続くと、、、重大なサービス影響にもつながりかねません。というか実際そういう事例があるので、要注意ですね。
Pool容量の最低5%はFlashを積んでね！というのがメーカーの推奨となっているのです。
これまたBest Practiceに書いてあるのですが、伊達にBest Practice Guideやってないですね。
（Flash5%搭載してもFast VPで、Snapshotが全部NL-SASに載ってたら意味ないかもですが。。）

A3.
Snapshot機能を利用して

こちらは一般的な知識として知っている方は多かったでしょうか？
Unityでは(非同期)Replication用にSnapshotを2つ使用します。

（取得者: 「レプリケーション」というSnapshotがとられています。）

指定したRPOが経過すると差分同期が実施されますが、この時毎回Snapshotがとられていて、それをTarget側に転送しています。
RPOのタイミングでSnapshotを毎回とることで、RPOの間に更新されるデータをSnapshotという形で管理できるわけです！かしこいですね。
しかし、もしあなたがThickなProvisioningを検討している場合は、押さえておくべき重要ポイントがあります。
それはQ1で扱った、Snapshotはどの領域に保存されるかに関連しています。
なんとUnity、Replicationの初回同期もSnapshot転送として扱われるため、初回同期時は対象のFilesystem/LUNで使用している全容量が、Target側UnityにPoolの空き容量として確保されている必要があります。（初回同期なのに！？！？？？？って感じですよね。）
この時、もしThickでFilesystem/LUNを作成していると、その分の容量はPool上に確保されて、空き容量としてはカウントされないため、Replicationの同期をしようとしたらエラーでできなかった件。。という悲しい事態になりかねません。
（もちろん初回転送に限らず、十分なPool空き容量がない状態でデータ差分量が多くなると、同じことが起こりえます。）

そんなことにわかには信じがたいので、以降、検証してみた結果です。