新しい会話を開始

Solved!

ソリューションへ移動

1 Rookie

 • 

11 メッセージ

30

2024年1月23日 02:04

Destinationのスナップショットを使用してSourceのボリュームをリストア

先日質問させていただいた投稿と併せた質問になります。

Unity XT Destination側Snapshotを使用してSource側の世代管理を行う

https://www.dell.com/community/ja/conversations/%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8-%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3/unity-xt-destination%E5%81%B4snapshot%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%A6source%E5%81%B4%E3%81%AE%E4%B8%96%E4%BB%A3%E7%AE%A1%E7%90%86%E3%82%92%E8%A1%8C%E3%81%86/65a73d32792ba45dca625e95


2台のUnityXT、1台のホスト(Windowsサーバー)があったとき、1つのボリュームに対して、

Destination側で取得したスナップショットを経由してリストアする運用を行いたく、下記2回の試験を行いました。

<実施して失敗したリストア試験>

(1).Windowsサーバーから見えている対象のボリューム(Source側)にテキストファイル配置

(2).Failover

(3).  テキストファイル作成前のSnapshotを使用してDestination側にてリストア

(4).  Failback

(5).再度Windowsサーバーから対象のボリューム(Source側)を見るも、ボリューム内部の表示状態はリストア前後で変化なし(テキストファイルが存在するまま)

<実施して成功したリストア試験>

(1).Windowsサーバーから見えている対象のボリューム(Source側)にテキストファイル配置

(2).Windowsサーバーのディスクの管理画面より、対象のボリュームをオフラインにする

(3).Failover

(4).  テキストファイル作成前のSnapshotを使用してDestination側にてリストア

(5).  Failback
(6).Windowsサーバーのディスクの管理画面より、対象のボリュームをオンラインにする

(7).再度Windowsサーバーから対象のボリューム(Source側)を見ると、リストア前に作成したテキストファイルが消えている(=テキストファイル作成前のSnapshotの状態になっている)

上記2回の試験結果より、

Windowsサーバーの方でリストア後のボリューム状態を最新に保つには、ディスクのオンライン/オフラインの切り替えが必須になるのかと感じたのですが、これは想定通りの動作(=仕様通り)なのでしょうか?

Destination側のリストアで世代管理できるものの、この運用だとSource側のディスクの状態は最新に保たれないのでディスクのオンライン⇔オフラインの操作は免れない

或いは

ディスクのオンライン⇔オフライン操作を避けたければ、やはりSource側でスナップショットを取得してSource側にてリストアする運用になる

のでしょうか?

Moderator

 • 

6.5K メッセージ

2024年1月24日 00:54

S.Banさん

 

Windowsサーバーの方でリストア後のボリューム状態を最新に保つには、ディスクのオンライン/オフラインの切り替えが必須になるのかと感じたのですが、これは想定通りの動作(=仕様通り)なのでしょうか?
→想定通りではないと思います。Unity での動作として説明ができないです。
どちらかというとWindows側で古い情報を持ち続けていたのではないでしょうか。

 

Destination側で取得したスナップショットを正として運用を行うのであれば、検証されたように
Failbackした後にWindowsのディスクのオンライン・オフラインをする形にする、
もしくはUnity側での作業でソースからFailover with Syncをするのではなく、
ターゲット側からのFailoverをする、(そうすればFailover、Resumeのタイミングでソースのデータはターゲットデータに書き換えられます)等を試してみてはどうでしょうか。

 

 

参考:

実際のReplication Failover時のメッセージ(Target 側からのFailoverを選択した場合。)
From target
Failover will be initiated from the destination storage resource.
   - Pause I/O to the source storage resource because the failover will block access for replication use.
   - The destination storage resource will be made available in read/write mode.
   - Any source storage resource data changes made since the last synchronization will not be available on the destination.
   - The source storage resource’s data will be overwritten with the destination storage resource’s data upon resume or failback.

We recommend that you consider performing the failover from the source storage resource’s system if it is available, because that will perform a synchronization before the failover operation.

1 Rookie

 • 

11 メッセージ

2024年1月24日 02:40

@ayas​ さん

いつもありがとうございます。

>どちらかというとWindows側で古い情報を持ち続けていたのではないでしょうか。

おそらくはUnityの内部動作としてはボリューム状態は最新の状態(操作によって行われた変化は反映されているはず)ということですよね

Windowsサーバー側が見かけ上ボリュームを最新の状態に見せてないということかと思います。

ここのWindowsサーバー側の動作も含めるとオペレーションにはやはりディスクのオンライン⇔オフライン切り替えは取り入れるべきなのかなと感じました。

>ターゲット側からのFailover

最新のsource側のデータ状況が最後にレプリケーションを行った地点から変化があった場合、こちらの方法ではその最新のSourceデータ状況は失われるということですね

一旦、Failbackした後にWindowsのディスクのオンライン・オフラインをする形で運用を進めたいと思います。

前回に引き続きご回答頂きありがとうございました。

イベントは見つかりませんでした!

Top