皆さんこんにちは。
ネットワールドでストレージ製品を担当している多川です。
今日はたまにお問い合わせを受けるUnityのReplicationで、ファイルシステムをThickで構成した場合の検証を行いました。
検証環境はこちらです。
Thickファイルシステムを選択すると、Poolからファイルシステム容量がアロケートされます。
それでは準備をしていきます。
今回はさらに、Thickファイルシステム上にデータをある程度書き込んだ状態でReplicationを行います。
Replicationセッションを作っていきます。
最後まで作成できましたね。
そのまま初期同期の状況を見ていきましょう。
Replication先のPool使用率が99%になってしまいました。
空き容量が少なくなっているため警告も出てしまっていますね。
暫く待つと失敗してしまいました。
Replication先（Destination側）ではPool上でファイルシステム容量のアロケート後、さらに書き込まれたデータ量の分がPool空き容量から消費されてしまう挙動のようです。
Replicationセッションを削除してみます。
Replicationセッションを削除したことで、ファイルシステムが作成されてからの差分（＝Sourceファイルシステムに書き込まれていたデータ容量）が消えて、純粋なファイルシステムの容量のみとなりました。
UnityのReplicationはSnapshotをベースに行われるため、このような動作になると考えられます。
この挙動から以下のように動いていると考えられます。
注意点としてはThickで作成したファイルシステムは後からThinに変更できませんので、もし間違ってThickで作ってデータを書いてしまった場合、新しいThinファイルシステムを作ってデータ移行が必要となってしまいます。
ちなみにThinファイルシステムで同じ条件でReplicationするとどうなるでしょうか。
特に問題なくReplicationできてしまいましたね。
Thinの挙動は以下のようになります。
以上のことからUnityでReplicationする場合はThinがおすすめです。
ということで、今回はUnityのThick Replicationの注意点のご紹介でした！
それではまた次回お会いしましょう。
Networld Techのブログ一覧はこちら！
