次の方法で共有

Site Recovery 監視に関する一般的な質問

  • [アーティクル]

この記事では、組み込みの Site Recovery 監視と Azure Monitor (Log Analytics) を使用する Azure Site Recovery 監視に関する一般的な質問に回答します。

全般

ログに記録される RPO 値は、最新の利用可能な復旧ポイントとどのように異なりますか。

Site Recovery では、マルチステップの非同期プロセスを使用して、Azure にマシンをレプリケートします。

  • レプリケーションの最後から 2 番目のステップで、マシンでの最新の変更とメタデータが、ログ/キャッシュ ストレージ アカウントにコピーされます。
  • これらの変更と、回復可能ポイントを識別するためのタグが、ターゲット リージョンのストレージ アカウントとマネージド ディスクに書き込まれます。
  • これで Site Recovery がマシンの回復可能ポイントを生成できるようになります。
  • この時点で、RPO はそれまでにストレージ アカウントにアップロードされた変更に対して満たされています。 つまり、この時点でのマシンの RPO は、回復可能ポイントに対応するタイムスタンプからの経過時間と等しくなります。
  • ここで Site Recovery は、ストレージ アカウントからアップロードされたデータを取得し、マシン用に作成されたレプリカ ディスクに適用します。
  • その後、復旧ポイントを生成し、このポイントをフェールオーバー時に復旧で利用できるようにします。
  • したがって、利用可能な最新の復旧ポイントは、既に処理されてレプリカ ディスクに適用された最新の復旧ポイントに対応するタイムスタンプを示します。

レプリケートするソース マシンまたはオンプレミスのインフラストラクチャ サーバーのシステム時刻が正しくないと、計算される RPO 値が正しくなくなります。 正確な RPO が報告されるようにするために、すべてのサーバーおよびすべてのマシン上のシステム クロックが正しいことを確認してください。

組み込みの Site Recovery ログ記録

コンテナーのインフラストラクチャ ビューに表示される仮想マシン数が、[レプリケートされたアイテム] に表示される合計数と異なるのはなぜですか。

コンテナーのインフラストラクチャ ビューは、レプリケーション シナリオによってスコープ設定されています。 このビューのカウントに含まれるのは、現在選択されているレプリケーション シナリオのマシンだけです。 また、Azure にレプリケートするように構成された VM だけがカウントの対象となります。 フェールオーバーされたマシンや、オンプレミス サイトにレプリケート バックされているマシンは、このビューではカウントされません。

[要点] のレプリケートされたアイテムの数が、ダッシュボード上のレプリケートされたアイテムの合計数と異なるのはなぜですか。

[要点] に表示される数には、初期レプリケーションが完了したマシンだけが含まれます。 レプリケートされたアイテムの合計には、初期レプリケーションが現在進行中のマシンも含めて、コンテナー内のすべてのマシンがカウントされます。

Azure Monitor ログ記録

Site Recovery ではどのくらいの頻度でリソース ログが Azure Monitor ログに送信されますか。

  • AzureSiteRecoveryReplicationStats と AzureSiteRecoveryRecoveryPoints は、15 分ごとに送信されます。
  • AzureSiteRecoveryReplicationDataUploadRate と AzureSiteRecoveryProtectedDiskDataChurn は、5 分ごとに送信されます。
  • AzureSiteRecoveryJobs は、ジョブのトリガーと完了時に送信されます。
  • AzureSiteRecoveryEvents は、イベントが生成されるたびに送信されます。
  • AzureSiteRecoveryReplicatedItems は、環境が変更されるたびに送信されます。 通常、データ更新の時間は、変更後 15 分です。

データはどのくらいの期間、Azure Monitor ログに保持されますか。

データ保持の詳細については、「Azure Monitor ログでのデータ保持とアーカイブ」を参照してください。

既定の保持期間は、Log Analytics ワークスペースの [使用量と推定コスト] セクションで変更できます。 [データ保有期間] をクリックし、範囲を選択します。

リソース ログのサイズはどれくらいですか。

通常、ログのサイズは 15 から 20 KB です。

Azure Site Recovery に関する組み込みの Azure Monitor アラート

Azure Site Recovery に関する組み込みの Azure Monitor アラートを使用する場合、コストはかかりますか?

組み込みの Azure Monitor アラートを使用すると、既定で重要な操作と失敗のアラートが生成されます (ポータルまたはポータル以外のインターフェイスで確認できます)。 ただし、これらのアラートを通知チャネル (メールなど) にルーティングする場合、Free レベル (1 か月あたり 1,000 件のメール)を超える通知に対してはわずかなコストが発生します。 Azure Monitor の価格を確認する。

Recovery Services コンテナーの Azure Site Recovery の現在の電子メール通知ソリューションは、引き続き動作しますか?

現在のところ、既存の電子メールによる通知ソリューションは、新しい組み込みの Azure Monitor アラート ソリューションと共存しています。 新しいエクスペリエンスに慣れ、その機能を使用するために、Azure Monitor ベースのアラートを試すことをお勧めします。

アラート ルール、アラート処理ルール、アクション グループの違いは何ですか?

  • アラート ルール: アラートが発生する条件を指定するユーザーが作成したルールを指します。
  • アラート処理ルール (以前の名前はアクション ルール): 特定の発生したアラートのルーティング先の通知チャネルを指定する、ユーザーが作成したルールを指します。 アラート処理ルールを使用して、しばらく通知を抑制することもできます。
  • アクション グループ: 発生したアラートをルーティングできる通知チャネル (メール、ITSM エンドポイント、ロジック アプリ、Webhook など) を指します。

組み込みの Azure Monitor アラートの場合、アラートは既定ですでに生成されているので、アラート ルールを作成する必要はありません。 これらのアラートを通知チャネルにルーティングするには、アラート処理ルールと、これらのアラートのアクション グループを作成する必要があります。 詳細情報

次のステップ

Site Recovery の組み込み監視または Azure Monitor を使用して監視する方法を学習してください。