Site recoveryのアプリケーション整合性復旧ポイント
「メモリ内のデータと処理中のすべてのトランザクションが追加でキャプチャされます」
と記載があるので、
・アプリケーション整合性復旧ポイントを使って、VMを復旧させたら、メモリも同じ状態で復旧するのか？と思いましたが、違うようです。VSS Writerという機能を使って、メモリ上のデータを、うまいことデータ整合性を保ちつつ、ディスクに書き込む（フラッシュ）しているようです。
アーキテクチャ
以下、MSサポート回答
————————————————————-
VSS はメモリ上のデータをダンプ（ファイルに出力すること）するような機能ではなく、VSS Writer と呼ばれるアプリケーションごとに実装されるコンポーネントと連動し、アプリケーションごとのメモリ上のデータをディスクにフラッシュすることで静止点の確保 (データの整合性を担保) をしております。
そのため、OS 上のすべてのメモリ上の情報を保持するものではございませんが、OS の起動ならびに SQL Server などの VSS 対応サービスの起動を保証した静止点を確保することが可能です。
（以下、2023年8月9日追記）
[ご質問 1]
たとえばSQL serverのトランザクション中のデータがメモリ上に展開されている状態で
アプリケーション整合性復旧ポイントが取得された場合で、そのポイントからVMを復旧した場合、
メモリ上に展開されていたSQL serverのトランザクション中のデータは、メモリ上に展開されていない状態で、
VMが復旧するという理解であっておりますでしょうか。
[MS回答 1]
ご認識の通りです。
初めに、アプリケーション整合性復旧ポイントは、取得された時点のメモリ ダンプを取得および復旧後にデータをメモリ上に展開するものではなく、取得時点のメモリ上のトランザクションを処理します (SQL Server の DB として利用されているディスクへ処理結果を書き込みます)。
トランザクションの処理後、ディスク書き込まれたデータを復旧ポイントとして取得いたします。
SQL としてはメモリ上のトランザクションが処理された後に復旧ポイントを取得するため、整合性が担保されます。
(*) 以前の回答で “メモリデータの保持" と記載いたしましたが、正確には “トランザクションの処理による整合性の保持" を指しております。
[ご質問 2]
「メモリ上のデータをディスクにフラッシュする」に記載がある
「ディスク」というのは、site recoveryの対処としているSQL 仮想マシンのディスクを指しているという理解であっておりますでしょうか。
私は、この「ディスク」を、service recoveryコンテナ上にあるディスクのことかと思っておりました。
[MS回答 2]
フラッシュ先のディスクは、SQL 仮想マシンのディスクで認識相違ございません。
アプリケーション整合性復旧ポイントでは、メモリ上のトランザクションの処理結果をディスクにフラッシュさせ、DB の整合性を担保しております。
また、ディスクへのフラッシュ後、対象ディスクはレプリケーションされ、レプリケーションされたデータから復旧ポイントが作成されます。
[ご質問内容]
復旧ポイントの作成に当たって、裏側ではVSSというテクノロジーが使われているご説明いただきましたが、
VSSは、いわゆるスナップショット的な技術をベースにされていると認識しています。
スナップショットでは、スナップショットキャプチャ先（今回の例では西日本リージョンのVMのディスク）が
障害が発生してしまった場合は、復旧できないと認識いているのですが、
ASRでは、元データである西リージョンのVMのディスクが障害が発生した場合でも
なぜ（どのような仕組みで）復旧できるのでしょうか。
[MS回答]
以下、一部インラインにて回答させていただきます。
> VSSは、いわゆるスナップショット的な技術をベースにされていると認識しています。
VSS は、正確には、スナップショットを作成する機能ではなく、アプリケーション (今回の場合 DB) の静止点を確保するための機能となります。
静止点を確保することで、アプリケーション (今回の場合 DB) の整合性を担保して、トランザクション処理 (ディスクへの書き込み) を行います。
※ この時点で VSS としての役割は完了しております。
VSS によってトランザクションが完了した後、ASR の動作としては、トランザクション処理によりディスクの変更 (書き込み) が発生するため、変更分のデータをフェールオーバー先 (ターゲット リージョン) のディスクに転送します。(* 1)(* 2)
ターゲット リージョン上のディスクにレプリケーション データが書き込まれた後、レプリケーション ポリシーで指定された間隔にてアプリケーション整合性復旧ポイントが作成されます。また、クラッシュ整合性復旧ポイントも 5 分間隔で作成されます。
アプリケーション整合性の場合、VSS にて静止点を確保した際の断面 (タイミング) を ASR の機能で取得しているため、復旧ポイントは静止点が確保されたタイミングのものが作成されます。
> スナップショットでは、スナップショットキャプチャ先（今回の例では西日本リージョンのVMのディスク）が
> 障害が発生してしまった場合は、復旧できないと認識いているのですが、
> ASRでは、元データである西リージョンのVMのディスク障害が発生した場合でも
> なぜ（どのような仕組みで）復旧できるのでしょうか。
ASR では、上述のフローで作成された復旧ポイントを利用し、ターゲット リージョンへのフェールオーバーを実現しております。
事前にターゲット リージョン上に VM のディスクの変更分 (レプリケーション データ) を転送しているため、ソース リージョン (今回の場合西日本) でディスク等の障害が発生したとしても、ターゲット リージョンでの復旧が可能となっております。(* 3)
(* 1) ターゲット リージョン上のディスクにレプリケーション データを転送する場合、フェールオーバー元 (ソース リージョン) にあるキャッシュ ストレージ アカウントを経由します。
(* 2) ターゲット リージョン上のディスクは、レプリカ マネージド ディスクと呼ばれます。このディスクは、ディスク名に -ASRReplica のサフィックスが付与されています。
(* 3) 前述の通り、復旧ポイントを選択してフェールオーバーを行うため、目標復旧時点 (RPO) はクラッシュ整合性復旧ポイントを利用する場合は最短 5 分、アプリケーション整合性を利用する場合は最短 1 時間となります。
[ご質問 1]
> VSS は、正確には、スナップショットを作成する機能ではなく、アプリケーション (今回の場合 DB) の静止点を確保するための機能となります。
https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-faq
こちらの記事に「アプリケーション整合性復旧ポイントは、アプリケーション整合性スナップショットから作成されます。」
とありますが、この「アプリケーション整合性スナップショット」とは先のご説明でいうとの部分を指しておりますでしょうか。
「ASR機能によってターゲットリージョンに転送される変更分のレプリケーションデータ」という理解であっておりますでしょうか。
[回答 1]
おおよそご認識の通りでございます。
ターゲット リージョン上のレプリカ マネージド ディスクにレプリケーション データが転送された後、レプリカ マネージド ディスクのスナップショットを作成し、そのスナップショットから復旧ポイントを作成します。
このため、レプリカ マネージド ディスクのディスク スナップショットと復旧ポイントは、同じものと考えていただければと存じます。
[ご質問 2]
>ご参考) レプリケーション プロセス
>Azure VM でレプリケーションを有効にすると、次のことが行われます。
>継続的なレプリケーションが VM に対して開始されます。 ディスクへの書き込みは、ソースの場所のキャッシュ ストレージ アカウントにすぐに転送されます。
いただいた説明と、こちらの記事を参照すると
レプリケーションされるデータは、変更分のデータのみだと認識したのですが、
レプリケーションを有効にした時点のディスクのデータは、どの時点で、
ターゲットリージョンのレプリカ マネージド ディスクに格納されるのでしょうか。
「ASR の動作としては、トランザクション処理によりディスクの変更 (書き込み)
[回答 2]
レプリケーション有効化後に、初期レプリケーションという処理が行われ、レプリカ マネージド ディスクの作成およびレプリカ マネージド ディスクへのレプリケーション データの送付が実施されます。
アプリケーション整合性復旧ポイント作成時間を制御できるか
[ご質問 1]
アプリケーション整合性復旧ポイントの取得間隔を２４時間に設定する
要件が出ておりますが、アプリケーション整合性復旧ポイントが作成される時間を
深夜の指定した時間に設定することは可能でしょうか。
アプリ整合性復旧ポイントはパフォーマンスに影響しますか?
こちらの記事を見ると、アプリケーション整合性復旧ポイントの作成には
リソースを消費するので、利用者がいない時間に設定できないかと考えております。
[回答 1]
恐れ入りますが、アプリケーション整合性復旧ポイントは、ある一定の時刻に取得するようなスケジュールは行えず、実行間隔のみを指定可能でございます。
記載いただいた “深夜" の時間帯にレプリケーションを開始し、かつ取得間隔を 24 時間とした場合も、厳密に 24:00:00 後の取得を保証していないことや、レプリケーションの停止等が発生した場合に再開時からの 24 時間後となることから、取得間隔での取得タイミングの調整は実現できないと判断いたします。
このため、基本的にはアプリケーション整合性復旧ポイントの取得においては、取得時刻の指定はできないものと認識いただければと存じます。
※ Azure Site Recovery での取得時刻の指定につきましては、開発部門へ機能追加のリクエストをさせていただきます。
また、代替案として、バックアップ/リストアの形式となりますが、Azure Backup を利用し、アプリ整合性でのバックアップ取得をスケジュールいただくことが可能です。
アプリ整合性でのバックアップ方法の詳細をご希望でございましたら、お手数ですが、Azure Backup 観点で新規起票いただけますようお願いいたします。
[ご質問 1]
＞恐れ入りますが、アプリケーション整合性復旧ポイントは、ある一定の時刻に取得するようなスケジュールは行えず、実行間隔のみを指定可能でございます。
記載いただいた “深夜" の時間帯にレプリケーションを開始し、かつ取得間隔を 24 時間とした場合も、厳密に 24:00:00 後の取得を保証していないことや、レプリケーションの停止等が発生した場合に再開時からの 24 時間後となることから、取得間隔での取得タイミングの調整は実現できないと判断いたします。
こちらについて追加で確認させてください。
取得時間のコントロールは困難だと理解したのですが、
最初のアプリケーション整合性復旧ポイントが作成されるタイミングはどのように考えればよいでしょうか。
初回レプリケーション完了直後とかに作成される感じでしょうか。
[回答 1]
ご認識の通りです。初期レプリケーションにて、アプリケーション整合性復旧ポイントが作成されます。
補足
たしかに最初にアプリケーション整合性復旧ポイントが作成されるのは①初期レプリケーションのタイミングだが、作成されたアプリケーション整合性復旧ポイントの時間は、①の時間よりも、前の時間になっている
たとえば１０時にレプリケーション有効化して、１１時にレプリケーションが完了したとする。
テストフェールオーバ/フェールオーバができるのは１１時以降だが、テストフェールオーバー/フェールオーバで選択できるアプリ整合性復旧ポイントの起点は10時10分とかになっている（要は10時10分時点のVMの状態に復元できるということ）
アプリケーション整合性復旧ポイント作成時のリソースへの負荷
[質問 2]
アプリケーション整合性復旧ポイントをが作成時の処理について以下をご教示いただきましたが、
「取得時点のメモリ上のトランザクションを処理します (SQL Server の DB として利用されているディスクへ処理結果を書き込みます)。
トランザクションの処理後、ディスク書き込まれたデータを復旧ポイントとして取得いたします。
SQL としてはメモリ上のトランザクションが処理された後に復旧ポイントを取得するため、整合性が担保されます。」
対象のSQL severの処理が一時的に止まるなど、サービスへの影響は発生しますでしょうか。
こちらでパフォーマンスに影響が出る可能性があると記載されているだけなので、
サービスが停止するなどは発生しないと認識しておりますが、念のため確認させてください。
[質問 2について]
一時的に I/O が停止するといったパフォーマンスへの影響が発生する可能性はございますが、SQL Server サービスが停止することはございません。
[質問 2（更問）]
> >[回答 2]
> >一時的に I/O が停止するといったパフォーマンスへの影響が発生する可能性はございますが、SQL Server サービスが停止することはございません。
> 「こちらの一時的にI/Oが停止する」という点がお客様的に引っかかり、検討が止まっております。
こちらについてより詳細な情報をおしえていただけないでしょうか。
I/Oというのは、ディスクIO?それとも他のポイント？具体的に何の影響があるか？
[回答]
I/O は、ディスク I/O を指しております。VSS により静止点を確保するため、静止点の確保中（※）は ディスク I/O が停止します。停止している間は I/O が処理されないため、その分時間当たりの I/O の処理数は減少するというパフォーマンスへの影響が発生する可能性がございます。
ただし、VSS による静止点は最低でも 1 時間に 1 回の取得なので、例えば 1 時間当たりの I/O 処理数でみた場合、その影響は小さいと考えられます。
※ SQL Server に関連する I/O の停止 (静止点の確保) は基本的に 60 秒未満となるように動作しております。
[質問]
> ・ASRの処理によって、どれだけVMに負荷を与えているか確認する方法はあるか
[回答]
Azure Site Recovery の動作に関する全てのプロセスを網羅した公開情報はございませんが、タスク マネージャーより関連プロセスの CPU、メモリ負荷を確認いただくことが可能です。
・ タスク マネージャー > Details > Name および Image path name 列
アプリケーション整合復旧ポイントを作成するために、対象VM側で何か設定が必要か
[質問 3]
アプリケーション整合性復旧ポイントを取得する上で
対象サーバ側で何か設定は必要でしょうか。（SQL Server上での設定など）
[質問 3について]
SQL Server VSS Writer サービスが稼働していれば、追加の設定等の必要はございません。
(SQL Server VSS Writer サービスは、SQL Server インストール時に導入されます。)
SQL Server VSS Writer のサービス名は “SQLWriter" でございますので、サービスの状態が “実行中" であることをご確認下さい。
(*) レプリケーション有効化後、アプリケーション整合性の取得に関するエラー 153006 が発生した場合は、次のトラブルシューティングをご参考下さい。
また、必要に応じて、弊社サポートまでご連絡いただければ原因調査をさせていただきます。
エラー ID 153006 – 過去 “X" 分間に、VM で使用可能なアプリ整合性復旧ポイントはありません
[ご質問 2]
>(*) レプリケーション有効化後、アプリケーション整合性の取得に関するエラー 153006 が発生した場合は、次のトラブルシューティングをご参考下さい。
また、必要に応じて、弊社サポートまでご連絡いただければ原因調査をさせていただきます。
エラー ID 153006 – 過去 “X" 分間に、VM で使用可能なアプリ整合性復旧ポイントはありません
今回環境はSQL server 2022を使用しております。
いただいたリンクを見ますとsql server 2008,2016,2017が該当するように見えましが、
SQL server 2022でも、上記エラーが発生する可能性があるのでしょうか。
[回答 2]
SQL server 2022 でも上記エラー (153006) は発生する可能性がございます。
本エラーは、結果としてアプリ整合性復旧ポイントが取得できなかった場合に出力されるものであるため、SQL server のバージョンに依存いたしません。
アプリ整合性が取得できない事象の発生要因は多岐に渡りますので、事象発生時は、まずは記載させていただいたトラブルシューティングをご確認いただければと存じます。
弊社サポートにお問い合わせいただければ、原因調査させていただきますので、その際はお気兼ねなくご相談下さい。