Veeam V11新機能 CDPレプリケーション検証（検証編）
前回と前々回で記載した通り、Veeam V11では、vSphere環境のVMレプリケーション保護機能を拡張し、新たにCDP（Continuous Data Protection=継続的データ保護）機能を追加しました。
Veeam CDPについてや、利用用途についてご紹介した第1回のブログは以下をご覧ください。
Veeam CDPのセットアップ手順、Veeam CDPを実行するうえで理解しておきたいVAIOやCDP Proxyについてご紹介した第2回のブログは以下をご覧ください。
3章のうち第3回となる今回は、第2回で作成したProxyやポリシーを用いて検証を行います。
目次[非表示]
1. Veeam CDP レプリケーション 2つのポリシー動作について
ここまでVeeam CDPのコンポーネントや機能についてご紹介してきました。
保護対象となるOracleのアプリケーション連携オプションを利用したCDPレプリケーションの実行と、レプリカサイトへShort TermポリシーとLong Termポリシーとでそれぞれのフェイルオーバーポイントで切り替えを行った際のOracle更新データの値が指定ポイントで切り替えられているのか、またそのときのOracle起動に違いがないのか、といったポイントでCDPレプリケーションの検証を行いました。
検証イメージが以下の図の通りです。
1-1. Veeam CDP動作ポリシー
今回のCDPポリシースケジュールは以下のように定義してみました。
・Short Term Retention：1分間隔の実行で8時間ジャーナル保持
（検証では、Short Termポリシーを1分に設定したので、切り替えるポイントも1分単位の指定となります。）
・Long Term Retention：1時間の間隔で3日間保持（Oracle VSS Writer連携オプション：有効）
（検証では、Long Termポリシーを1時間に設定したので、切り替えるポイントも1時間単位の指定となります。）
■事前のCDP転送状態を確認
Oracleデータが更新されている状態で、CDP転送が行われているときの転送状態を見ておきます。下図のように、ポリシー定義に沿った動作状態であることを確認しました。
（CDP動作中にdelayがない状態）
■更新Oracleデータ値の事前確認
今回の環境には、サンプルのテーブルを作成し、バッチで更新データと更新日時が書き込まれるように作成しました。
下図が実際に検証用に書き込んだときのデータとなるシリアル値となります。
（下図の値が14:30時間帯に追加されたデータ値「2133237」～「2133889」）
（この時間内で指定したポイントで起動されてきたデータ値がこの範囲でフェイルオーバーされていればCDP転送が有効に動作されているはずです。）
2. 2つのフェイルオーバータイプの実行と確認
2-1. Short Term Retentionポイントでのフェイルオーバー動作確認
秒～分単位（今回は1分おきの設定）のRPOポイント指定でレプリケーション切替実行時に起動したときのOracleデータが、指定ポイント時間の更新データ範囲の値でフェイルオーバーされているのかを確認しました。
レプリカ側へCDPフェイルオーバーを実行：指定ポイントは「14:30:00」
2-2. Short Term Retentionポイントでのフェイルオーバー動作確認の結果
＊レプリカVM起動後にOracleコミットデータ値を確認したところ「2133525」でした。
この結果はフェイルオーバータイミング(14:30)に更新されたデータのほぼ中間のデータ値であり、CDPの低RPOが有効に働いていることが分かります。
（Oracle データ値を確認）
また、レプリカ起動時にOracleアーカイブログのリカバリ機能が実行されていたことが確認できました。
このことにより、CDP Short Term Retentionポリシーのポイントを利用したフェイルオーバーでは、Oracle自動修復が必要となりますが低RPOでの復旧が可能であることが確認できました。
（赤枠＝自動修復の実行log）
2-3. Long Term Retentionポイントでのフェイルオーバー動作確認
Oracle VSS Writerを使用しOracleキャッシュがフラッシュされた更新データの転送を行います。そのデータを時間単位（今回は1時間おきの設定）のRPOポイント指定でレプリケーション切替実行時に起動したときのOracleデータが、指定ポイント時間の更新データ範囲の値にはいっているのか確認します。
■事前確認：切替ポイントとなる時間帯の更新されたOracleデータの値をオリジナルVM側で確認しておきましょう。
下図の値が14:34の時間帯に追加されたデータの値「2300000」となっていました。
それ以降の更新がなかったことから、Long Termポリシーの切替ポイントである15:00のOracleデータ値も同データ値となるはずです。
※この時間内で指定したポイントで起動されてきたデータ値がこの値でフェイルオーバーされていれば、SnapShot連携のレプリケーション転送が有効に動作されているとみます。
レプリカ側へCDPフェイルオーバーを実行：指定ポイントは「15:00:43」
2-4. Long Term Retentionポイントでのフェイルオーバー動作確認の結果
Veeamによるフェイルオーバー実施にてレプリカのOSおよびOracleサービスの起動を確認することができました。
さらにOracleにコミットされているデータ値も、指定したLong Term Retentionポイント時点のコミットされているオリジナルデータ値である「2300000」でレプリカ側も起動されていたことも確認できました。
（Oracleデータ値）
※またShort Term Retentionポリシーのフェイルオーバー時で実行されていたOracleアーカイブログのリカバリ機能は、Long Term Retentionポイントでは実行されることなくきれいに起動されていたことが確認できました。
このことにより、CDP Short Term Retentionとは違い、Oracle VSS連携がなされ整合性のとれたフェイルオーバーができているといえる結果となりました。
（自動修復logなし、修復なしで通常起動された）
2-5. 検証結果
2つの切替動作確認を行い、Short Term, Long Term それぞれのリテンションポイントによってアプリケーション静止点の違いからレプリカ起動時のアプリケーション動作にも違いがありましたが、どちらの場合でもレプリカ起動に問題はなく、レプリケーションとして正しく動作されていることが確認できました。
3. まとめ
このような結果から、レプリケーションを用いた低RPOを実現するときの選択肢としてCDPレプリケーションは有効な手段となり、DB保護についても低RPOであるShort Term RetentionやVSS連携を利用できるLong Term Retentionといった異なった２つのタイプのフェイルオーバー選択が可能となっていることで、レプリケーション利用用途に広く対応できる有効な製品となったことが確認できました。
また、想定する利用用途としては大量にデータ容量を保有しているファイルサーバーなどがあると思います。この場合SnapShotベースのレプリケーションやバックアップでは失敗してしまうケースがあることから、CDPのような保護ソリューションは有効な手段になるでしょう。
是非一度お試しいただいて利用検討をしてみてはいかがでしょうか。
これまでの内容についてはこちら
2.Veeam CDPレプリケーション検証（セットアップ編）
3.Veeam CDPレプリケーション検証（検証編）
関連情報
