【Unity380F】遠隔地における筐体間でのOracle領域リモートコピーについて

Q1.

>日次でSRC側でOracleホットバックアップデータをDST側にリモートコピーする運用を考えています。

>日次で送られるリモートコピーのデータは差分データのみで毎回フルコピーは発生しない認識ですが正しいでしょうか？

Unityのレプリケーションは、ソース側の差分をリモート側に転送する　というのが基本となります。ここでの差分とは、ストレージのブロックレベルの差分ですので、アプリケーションやOSが何をしているのか？まではストレージとしては意識していません。あくまでストレージ上の変更されたブロックのみを送る、という意味合いになります。

ちなみに「Oracleホットバックアップデータ」とは何を意味しているでしょう？　Oracleをホットバックアップモードにする（BEGIN / END BACKUPを行う）という意味合いでしょうか？

仮にそうだとして、日次で転送ということですと、

たとえば深夜0時にBEGIN BACKUPしてから、DBのデータ領域をUnity レプリケーションでコピーしはじめて、すぐにEND BACKUPを行う、というイメージでしょうか？

（実際には、その後ログスイッチを発生させて、アーカイブログ領域も別タイミングでレプリケーションする、という運用も必要になるかと思います）。

もしこういった運用を検討されているようでしたら、レプリケーションだけでなく、スナップショットを活用して、例えば、Oracleのホットバックアップ実施→ローカルスナップ取得→ホットバックアップ終了→スナップショットをリモートに転送　というようなあわせ技も検討されてはいかがでしょう？

• ローカルにスナップを持つことにより、ローカルからの戻しも可能
• スナップによる世代管理も可能になる
• レプリケーションを日次ではなく、（1時間など）より短い単位で定期的に実施して一回の転送時間を短くすることができる、と同時に、レプリケーションターゲットもリカバリ用に用いることができる（日次のスナップよりも直近の戻しポイントが確保できる。ただしホットバックアップ状態ではないですが）
• リモート側でのスナップの利用が可能（Q2と関連します）

などが考えられるかと思います。

Q2.

>コピーされたDST側で以下の運用があります。

>　  <<中略>>

>　この作業により、SRCからコピーされたLUN情報がDST側を更新するため、差分が発生します。

Unityレプリケーションを実施中、つまりSRCとDSTでセッションを作成している場合、ターゲット側（DST側）はホストから触れない状態になっていたかと思います（Unityに詳しい方、間違っていたら訂正願います）。

DST側を直接マウントしたい場合には、たとえばレプリケーションのセッションを削除するとか、フェイルオーバするような処理が必要になります。セッション削除した場合であれば、次回はまた初期同期が必要ですし、フェイルオーバしたら、もともとのSRCはその間利用できなくなったり、DSTで作業した内容がSRC側に反映されたりしてしまいます。

こういった場合、DSTを直接利用するのではなく、DSTから作成したスナップショットを活用されたほうが良い気がします。

@miuramak さん

早速のご連絡ありがとうございます。大変助かります！！

>たとえば深夜0時にBEGIN BACKUPしてから、DBのデータ領域をUnity レプリケーションでコピーしはじめて、すぐにEND BACKUPを行う、というイメージでしょうか？
→はい。ご認識の通りのことを考えております。

>もしこういった運用を検討されているようでしたら、レプリケーションだけでなく、スナップショットを活用して、例えば、Oracleのホットバックアップ実施→ローカルスナップ取得→ホットバックアップ終了→スナップショットをリモートに転送　というようなあわせ技も検討されてはいかがでしょう？
→そうですね。ぜひ取り入れたいです。今回はDST側(遠隔地)でDB起動が要件に入っているので。
　お手数ですが、頂いた内容について以下教えて下さい。
　・ローカルにスナップショットを持つ場合、更新されただけスナップショットが膨らんでいくと思いますが、サイズについて、何か見積もりできるよな参考情報などありますでしょうか？
　・このスナップショットはストレージのどの部分に確保されるのでしょうか？1つのプールで構成している場合は、このプール内に確保されますでしょうか？
　・合わせ技を使う事で、DST側でDBを起動して、何かしら更新などをしても、コピーセッションが切れていないので、次回以降のSRCからのレプリケーションは差分コピーになるという事でしょうか？
　・DST側にコピーしたBEGIN/ENDのFULLデータとスナップショットデータを利用して、そのコピーされたスナップショットをマウントしてDBを起動することが可能という事でしょうか？
　　それとも、DST側にコピーしたBEGIN/ENDのFULLデータからDST側で新たにスナップショットを作成して、そのスナップショットを利用してDBを起動することが可能という事でしょうか？

理解不足で大変申し訳ございませんが、DST側でスナップショットを利用してDBを起動することと、SRC側からの差分コピーの関係がいまいち理解できておらず、ご教授頂けると助かります。
ご確認よろしくお願いいたします。

>→そうですね。ぜひ取り入れたいです。今回はDST側(遠隔地)でDB起動が要件に入っているので。

以下、私の方で勝手に想定したイメージになります：

こんな感じで考えました。

• ソースとターゲットのLUNは、一定間隔でReplicationを続ける（例：RPO 1h)。これは差分転送になります。
• ソースから日次でローカルスナップを作成し、それをDST側に送る（Snapshot Shipping)
  • 見かけ上はスナップがDSTに転送されますが、実際には Replication Session を通って必要な差分が転送されます。このため、Replication側で一定間隔で常に差分を転送しておくことにより、Snapshot Shippingが早く完了します
• DST側でDBを起動する際は、リモートスナップを使用する
• DST側でレプリケーションターゲットを直接利用するのは、ソース側が全壊したときなど、DST側である程度長期運用するような場合

（ASMやRACの有無で、DBの起動については難易度が変ってくるかと思います）

ちなみに、この構成であれば、Oracleと連携してローカルスナップ作成→リモートに転送、リモートでオラクルDB起動という流れを AppSyncで自動化できるかと思います。この場合両方のUnityに対してAppSyncの有償ライセンスが必要になるのと、AppSyncサーバは１台しか構成できないため、災害などでこれが使えなくなると、復旧は手動になるというリスクはあります。

>　・ローカルにスナップショットを持つ場合、更新されただけスナップショットが膨らんでいくと思いますが、サイズについて、何か見積もりできるよな参考情報などありますでしょうか？

こちらは、杓子定規に言うなら、データの更新量に依存する、という回答になってしまいます。既存システムが存在していて、それの更新量が測定できるようなら参考にできると思います。
よくわからないときは、経験則で１日で20%の差分が発生する、というような前提で見積もる場合も多いです。

>　・このスナップショットはストレージのどの部分に確保されるのでしょうか？1つのプールで構成している場合は、このプール内に確保されますでしょうか？

オリジナルのLUNと同じプール内に確保されます

>　・合わせ技を使う事で、DST側でDBを起動して、何かしら更新などをしても、コピーセッションが切れていないので、次回以降のSRCからのレプリケーションは差分コピーになるという事でしょうか？

ご認識のとおりです。リモートスナップを利用している間もUnity Replication のセッションはそのままで、差分転送を続けることができます。

>　・DST側にコピーしたBEGIN/ENDのFULLデータとスナップショットデータを利用して、そのコピーされたスナップショットをマウントしてDBを起動することが可能という事でしょうか？
>　　それとも、DST側にコピーしたBEGIN/ENDのFULLデータからDST側で新たにスナップショットを作成して、そのスナップショットを利用してDBを起動することが可能という事でしょうか？

リモートスナップは、DSTのある時点でのスナップショット　という位置づけになります。
つまり、どちらからもDBを起動することはできます。

• （Unity Replication セッションを削除などすれば）DSTからDBを起動できます
• （Unity Replication セッションを張ったままで）リモートスナップからDBを起動できます

ここからはOracleの話題になりますが、
BEGIN/END BACKUPを利用する場合、LUNの構成や手順にご注意ください。
Oracle 10g 以降でしたら、以下がOracleのお作法に則った手順になります。

1. DBをホットバックアップ・モードに変更
　　SQL > ALTER DATABASE BEGIN BACKUP;

2. (アーカイブログ以外の）DB 関係ファイル領域のローカルスナップ作成

3. DBをホットバックアップ・モードから解除
　　SQL > ALTER DATABASE END BACKUP;

4. 現行のRedo ログをアーカイブ
　　SQL > ALTER SYSTEM ARCHIVE LOG CURRENT;

5. アーカイブログ領域のローカルスナップ作成

何が言いたいかと言うと、アーカイブログ領域とそれ以外は、スナップを作成するタイミングが異なるということです。
そのため、それらのLUNを分けて構成する必要があります。

ReplicationだけでなくSnapも使うことを推奨するのは、こういった背景もあります。

そもそも BEGIN/END BACKUP は本当に必要でしょうか？
Oracle 12c 以降を使われるなら、「ストレージスナップショット最適化」（英語マニュアルだと Storage Snapshot Optimization) という機能が利用できます。これを使えば BEGIN/END BACKUPせずに取得したストレージスナップショットに対して、あとからRECOVERコマンドでDBのりカバーができます（アーカイブログの適用もできます）。
詳しくは、こちらのブログが参考になるかもしれません（私が書いたものですが（笑））。

DST側で起動するDBの位置づけは「バックアップ用」でしょうか？それとも、スナップを取得した時点での「コピー」でしょうか？（後からアーカイブログを適用して最新の状態にしたいのか、それともある時点のコピーとして起動さえできれば良いのか？）

コピーで良いということであれば、そもそもホットバックアップや、RECOVERなどは不要と割り切っても良いかもしれません。
この場合は、DSTをマウントした後に、 SQL> startup でいきなりOracle DBを起動すれば、クラッシュリカバリにより整合性を保って起動してきます。その際アーカイブログも使わないので、これをReplicationする必要もなくなります。ただしOracleからのWrite IOの順を崩してはいけない（Redo、データ、および制御ファイルの間で）という決まりがありますので、複数LUNを使う場合はコンシステンシーグループを考慮ください。

これについて、Oracle社のサポートドキュメントもありますので、参考になるかと思います。
My Oracle Support "Supported Backup, Restore and Recovery Operations using Third Party Snapshot
Technologies (ドキュメントID 604683.1)"

>・DST側でDB起動する際、リモートスナップショットを使用して起動するとあります。これはソース側でsnapshotを取得する運用が必須という理解でよいでしょうか？

>・DSTへリモートコピーしたFULLデータLUNからsnapshotを作成して、そのsnapshotからDB起動とかは出来ないですよね？

Replication のみでも大丈夫とは思います。

ただ、Dell EMC Unity: Replication Technologies にもありますが、Replication は整合性を保つために内部的に Snapを使いますので、実際にはそこから snap を作成することになるのでは？と思います（ここはUnityの有識者に確認したいところです）。

個人的には、自分の好きなタイミングで明示的にスナップを作るほうが運用としてわかりやすい気はします。

リモート側にスナップの転送が完了した後は、不要であればローカル側のスナップは削除してしまっても構いませんし。。。

>・教えて頂いた構成にした場合、DST側でリモートスナップを使用してDB起動し、一時利用後はどのような操作になるのでしょうか？DST側のスナップショットを使用してDB起動した後の、後片付け(?)について注意などあれば教えて下さい。

そのDBをもう利用しない。スナップも要らない。ということでしたら、大まかには以下の順でよいかと思います：

• DBを停止
• 関連ボリュームをunmount
• スナップを削除