3 Apprentice
•
630 メッセージ
0
1183
Unity async Replicationでフェイルオーバー後の処理が差分同期になると記述のあるドキュメントについて
Unity Async ReplicationのドキュメントでFailover後の処理(Failback、Resync)が差分同期になると明確に記載のあるドキュメントはありますでしょうか。
意図としましては数TBを利用している本番Volumeを想定したフェイルオーバー、フェイルバックの試験をお客様が実施する際に初回同期になることがないかどうかがドキュメントに明記されていればご案内したいと思っていますが、明確な記載が見つけられなかったため情報をいただけると助かります。
Uehara Y.
Community Manager
Community Manager
•
5.1K メッセージ
0
2019年12月12日 19:00
katamariさん
実際の障害発生時を想定してunplanned Failoverの確認を行うということですね。
今回は数TBの本番ボリュームを想定しているということなのでかなり注意をして試験をしてください。（個人的には本番ボリュームを利用して試験はしない方がいいと思います・・・）
まず、unplanned Failoverをした場合のFailback処理は基本的に初回同期（full sync）です。前述のドキュメントP.15にも以下のように明記されています。
ただ、条件は実は複雑で、Unity レプリケーションのフェイルオーバー動作に関してのパターン3で議論されているように、unplanned Failoverをした後に元ターゲット（FO後はソースになっている）から元ソース（FO後はターゲット）に対してレプリケーションを再開させることが出来て、かつ両Unityにcommon baseが残っていればそれは差分同期になったりします。
このように結構条件が複雑なのですが、考慮しないといけないポイントは2つあると思っています。一つ目はunplanned Failoverをした場合にはfull syncが必要となる場合があるという点。
あとはそれ以上に重要なのがレプリケーションがターゲット側（FO後はソースになるもの）のcommon baseの状態まで一度戻ってから処理される点で、これが二つ目です。つまり、前回同期完了をしてからソース側に書き込まれた情報はなくなってしまう可能性があります（ある意味DL相当の動きをすることになります）。そのようなこともありunplanned Failoverを実施しようとすると以下のようなメッセージがUnisphere上表示されます。
フェイルオーバーは、デスティネーション ストレージ リソースから開始します。
- レプリケーション使用におけるソース ストレージ リソースへのアクセスはブロックされます。
- デスティネーション ストレージ リソースが読み取り/書き込みモードで使用可能になります。
- 最後の同期以降に行ったストレージ リソース データの変更はデスティネーションで利用できません。
レプリケーション セッションをフェイルオーバーしますか?
このように一歩間違えるとただの試験が大惨事になりかねないので、本番環境以外に試験環境を作成してテストを行う、どうしても本番環境を利用するのであれば、Faiover with Syncを利用する、もしもunplanned Failoverをするのであれば、ソースへの書き込みを運用上止めた上で、unplanned Failoverをする直前にマニュアルでReplicationの同期を行っておく等の対応をすることをお勧めします。
Uehara Y.
Community Manager
Community Manager
•
5.1K メッセージ
0
2019年12月11日 19:00
katamariさん
今回は試験ということなので、ソース側がからFailover with Syncを行うという前提で回答をします。
色々と見てみましたが、一番ご希望に近い記述は、KB496492 - Dell EMC Unity: FAQ for Unity Replications (User Correctable) にある以下部分だと思います。
For Unity 4.x, Failback removes access to DR site, and then sync the changes from DR to Prod. Once the Sync completes, allow access to Prod site. If there has been significant change accumulated on DR, it may take a long time to sync and cause long DU. Unity 5.x introduces a new option "Keep remote data by discarding all the local changes", which will discards any changes made on the destination site and allow the failback to finish quickly.
まぁ、これもあまりぱっとした書き方ではないですよね・・・
とはいえ、Dell EMC Unity: Replication Technologiesというホワイトペーパーから理論的な動作確認をしても、同じ結論を導いて裏付けとすることは可能です。
ポイントは、P.32 3.2.4 Asynchronous Replication Internal Snapshotで説明されている、ソースとターゲット両方が持つ「common base」と呼ばれる全く同じ情報を持ったスナップショットの存在です。
このスナップショットを基準として、ソース側とターゲット側の両方で、「common base」の情報が作成された後に「どの情報が書き換えられた、もしくは追加されたか？」＝「差分情報」として持つことが出来ます。
その「差分情報」をターゲット側からソース側に差分同期として送るのがUnity 4.xまでのFailbackです。
Unity 5.xからは、4.xまでの動作に加え、Faioverを行った際に「common base」が作成された以降に、ターゲット側で書き換えられた/追加された情報を全て破棄するというオプションも追加されています（上記ドキュメントのP.36~38 Failover with Sync, Faiover, and Failbackセクションに記述があります）。
katamari
3 Apprentice
3 Apprentice
•
630 メッセージ
0
2019年12月12日 17:00
Uehara Y.さん
ご回答ありがとうございます。
ちなみに今回はunplanned Failoverを想定しています。
同じドキュメントを参照していましたが、Dell EMC Unity: Replication TechnologiesのP.46に5.0で追加されたトポロジの説明部分ではあるのですが、以下記載がありましたので明記されているかなと感じましたがイマイチ条件が違う気もしています。
In each of these examples, the original configuration is restored after the failback or resume operation completes. All of the replication updates leverage the internal replication common base snapshots to replicate only the changed data.
unplanned failoverでも、DR側からのresumeもしくはFailbackに関しては、差分同期になると読めるのですが認識はあっていますでしょうか。
katamari
3 Apprentice
3 Apprentice
•
630 メッセージ
0
2019年12月12日 20:00
Uehara Y.さん
ご回答ありがとうございます！
私もUnityの単独操作だけでの試験であれば基本的には問題ないと思ってはいますが、回線切断や、機器停止など不意な試験の操作によりfailiver処理で仮にcommon baseに不整合が起きた場合、初期同期になる可能性は無きにしもあらずのため、特に本番環境の場合の試験時の操作にはfailover with syncを使った方が無難ですよね。
仮にfullsyncになってしまった場合、2-3日はDRサイト側をメインに利用せざるを得なくなるためそう思います。
katamari
3 Apprentice
3 Apprentice
•
630 メッセージ
1
2019年12月19日 18:00
検証レベルでまとめておきます。
社内で動作検証する限りではfailover with syncではなく、failoverを実施して完了後に
resyncもしくはFailback処理をUnityの操作だけで実施した場合は差分同期になります。
恐らく、Common Baseのスナップが残っているからだと考えられます。