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

Networld Tech
3 Argentium

[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にどれだけ空き容量を持たせるかというのが設計要素の1つとなります。
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つ使用します。

WS000456.JPG(取得者: 「レプリケーション」 という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空き容量がない状態でデータ差分量が多くなると、同じことが起こりえます。)

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

WS000458.JPG

Thickで作ったFilesystemでReplicationを設定します。Destination Poolの空きは442.5GBありますが...

WS000459.JPG

  初期同期をしていますが、Destination Filesystemの「使用済み(%)」は0のまま、一方でPoolの「使用済み(%)」が99%まで増えてしまっています。

WS000460.JPG

そして最終的にはPool使用率が100%に到達し、初期同期がエラーでストップ!!

(ちゃんと?)その旨のメッセージも表示されました。


ということで、クイズ形式でUnityの仕様の紹介と、設計時のポイントについて書かせていただきました。目指せ、無停止システム!(でも人間社会は一度立ち止まって考えることも大事ですよね、と思います。)
そんなわけで今回はこの辺で!
最後までお読みいただきありがとうございました。


Networld Techのブログ一覧はこちら!
https://www.dell.com/community/ストレージ-Wiki/tkb-p/storage-wiki-jp/label-name/EvalReport

バージョン履歴
改訂番号
5/5
最終更新:
‎02-14-2020 04:47 PM
更新者:
 
寄稿者: