Recovery Services ダッシュボードを使用する
この記事では、Azure Site Recovery を、Site Recovery に組み込まれている監視機能を使用して監視する方法について説明します。 以下を監視できます。
- Site Recovery によってレプリケートされたマシンの正常性と状態。
- マシンのテスト フェールオーバーの状態。
- 構成とレプリケーションに影響する問題とエラー。
- オンプレミス サーバーなどのインフラストラクチャ コンポーネント。
開始する前に
開始する前に、監視に関する一般的な質問を確認することをお勧めします。
ダッシュボードでの監視
コンテナーで [概要] を選択します。 Recovery Services ダッシュボードには、コンテナーのすべての監視情報が 1 か所にまとめられています。 Site Recoveryサービスと Azure Backup サービス には、どちらにも専用のページがあり、それらを切り替えることができます。
ダッシュボードから、さまざまな領域にドリルダウンすることができます。
[レプリケートされたアイテム] で [すべて表示] を選択すると、コンテナー内のすべてのサーバーが表示されます。
ドリルダウンするには、各セクションの状態の詳細を選択します。
[インフラストラクチャ ビュー] では、レプリケートされているマシンの種類ごとに監視情報を並べ替えます。
レプリケートされたアイテムの監視
[レプリケートされたアイテム] セクションでは、レプリケーションが有効にされているコンテナー内のすべてのマシンの正常性を監視します。
State | 詳細 |
---|---|
Healthy | レプリケーションは正常に進行しています。 エラーや警告の症状は検出されていません。 |
警告 | レプリケーションに影響を及ぼす可能性がある警告の症状が少なくとも 1 件検出されています。 |
Critical | 重大なレプリケーション エラーの症状が少なくとも 1 件検出されました。 これらのエラー症状は、通常、レプリケーションがスタックしていること、またはデータ変更速度に処理速度が追い付いていないことを示します。 |
適用なし | 現在、サーバーはレプリケートを行っていないものと思われます。 たとえば、マシンがフェールオーバーされた可能性があります。 |
テスト フェールオーバーの監視
[フェールオーバー テスト成功] では、コンテナー内のマシンのフェールオーバーの状態を監視します。
- レプリケートされたマシンについて、少なくとも半年に 1 回はテスト フェールオーバーを実行することをお勧めします。 それによって、フェールオーバーが想定どおりに機能し、運用環境の中断が発生していないことを確認できます。
- フェールオーバーとその後のクリーンアップが正常に完了したときにはじめて、テスト フェールオーバーが成功したと見なされます。
State | 詳細 |
---|---|
テストをお勧めします | このマシンは、保護が有効にされてから、まだテスト フェールオーバーが実施されていません。 |
正常に実行されました | このマシンは、テスト フェールオーバーが少なくとも 1 回成功しています。 |
適用なし | このマシンは現在、テスト フェールオーバーの対象ではありません。 たとえばフェールオーバーされたマシンや、初回レプリケーション/テスト フェールオーバー/フェールオーバーが進行中のマシンが該当します。 |
構成の問題の監視
[構成の問題] では、正常にフェールオーバーする機能に影響する可能性があるすべての問題を監視します。
- 構成の問題 (ソフトウェア更新プログラムの提供状況を除く) は、既定では 12 時間ごとに実行される定期的な検証コントロール操作によって検出されます。 "構成の問題" のセクション見出しの横にある更新アイコンを選択することにより、検証コントロール操作を強制的にすぐ実行できます。
- リンクを選択すると詳細情報が表示されます。 特定のマシンに影響を及ぼす問題については、[ターゲット構成] 列の [要注意] を選択します。 この詳細情報には、修復に関するアドバイスが含まれます。
State | 詳細 |
---|---|
不足している構成 | 復旧ネットワーク、リソース グループなど、必要な設定が不足しています。 |
不足しているリソース | 指定されたリソースが見つからないか、サブスクリプションで利用できません。 たとえばリソースが削除されているか、移行されています。 監視対象リソースには、ターゲット リソース グループ、ターゲット VNet/サブネット、ログ/ターゲット ストレージ アカウント、ターゲットの可用性セット、ターゲット IP アドレスが含まれていました。 |
サブスクリプション クォータ | 使用可能なサブスクリプション リソース クォータの残量が、コンテナー内のすべてのマシンをフェールオーバーするために必要な残量と比較されます。 リソースが不足していると、クォータ残量不足が報告されます。 VM のコア数、VM ファミリのコア数、ネットワーク インターフェイス カード (NIC) の数がクォータによって監視されます。 |
ソフトウェア更新プログラム | 新しいソフトウェア更新プログラムの提供状況、ソフトウェア バージョンの期限切れに関する情報です。 |
エラーを監視する
[エラーの概要] では、コンテナー内のサーバーのレプリケーションに影響を及ぼす可能性がある現在アクティブなエラーの症状を監視し、影響を受けているマシンの数を監視します。
- このセクションの先頭には、オンプレミスのインフラストラクチャ コンポーネントに影響を及ぼしているエラーが表示されます。 たとえば、オンプレミスの構成サーバー上の Azure Site Recovery プロバイダーまたは Hyper-V ホスト からハートビートが受信されていないことが示されます。
- 次に、レプリケート対象サーバーに影響を与えているレプリケーション エラーの症状が表示されます。
- テーブルのエントリは、最初にエラーの重大度の高い順に、次に影響を受けたマシンの数の多い順に、並べ替えられます。
- 影響を受けているサーバーの数は、基になる 1 つの問題が複数のマシンに影響している可能性があるかどうかを理解するのに役立ちます。 たとえば、ネットワークの不具合によって、Azure にレプリケートされるすべてのマシンが影響を受ける可能性があります。
- 1 台のサーバーで複数のレプリケーション エラーが発生する場合があります。 その場合、そのサーバーは、影響を受けるサーバーの一覧でエラーの症状ごとにカウントされます。 問題が解決すると、レプリケーション パラメーターは改善し、マシンからエラーがクリアされます。
インフラストラクチャの監視
[インフラストラクチャ ビュー] では、レプリケーションに関係するインフラストラクチャ コンポーネントと、サーバーと Azure サービス間の接続の正常性を監視します。
緑色の線は、接続が正常な状態であることを示します。
エラー アイコンが重ねて表示されている赤い線は、接続性に影響するエラー症状が少なくとも 1 つ存在することを示します。
エラー アイコンをマウス ポインターでポイントすると、エラーと影響を受けるエンティティの数が表示されます。影響を受けるエンティティのフィルター処理された一覧を表示するには、アイコンをクリックします。
インフラストラクチャを監視するためのヒント
オンプレミスのインフラストラクチャ コンポーネント (構成サーバー、プロセス サーバー、VMM サーバー、Hyper-V ホスト、VMware マシン) で、Site Recovery プロバイダーまたは Site Recovery エージェントの最新バージョンが実行されていることを確認してください。
インフラストラクチャ ビューのすべての機能を使用するためには、これらのコンポーネントで更新プログラムのロールアップ 22 が実行されている必要があります。
インフラストラクチャ ビューを使用するためには、実際の環境に合った適切なレプリケーション シナリオを選んでください。 ビューをドリルダウンすることで、より詳しい情報を把握できます。 表示されるシナリオを次の表に示します。
シナリオ State 表示可能 オンプレミス サイト間のレプリケーション すべての状態 いいえ Azure リージョン間の Azure VM レプリケーション レプリケーション有効/初期レプリケーション進行中 はい Azure リージョン間の Azure VM レプリケーション フェールオーバー済み/フェールバック いいえ Azure への VMware レプリケーション レプリケーション有効/初期レプリケーション進行中 はい Azure への VMware レプリケーション フェールオーバー済み/フェールバック いいえ Azure への Hyper-V のレプリケーション フェールオーバー済み/フェールバック いいえ レプリケートするマシンが 1 つの場合にインフラストラクチャ ビューを表示するには、コンテナー メニューの [レプリケートされたアイテム] を選択してサーバーを選択します。
復旧計画の監視
[復旧計画] では、計画の数の監視、新しい計画の作成、および既存の計画の編集を行います。
ジョブの監視
[ジョブ] では、Site Recovery 操作の状態を監視します。
- Azure Site Recovery のほとんどの操作は非同期的に実行され、操作の進行状況を追跡するために追跡ジョブが作成されて使用されます。
- ジョブ オブジェクトは、操作の状態と進行状況を追跡するために必要なすべての情報を持っています。
ジョブは次のように監視します。
[dashboard](ダッシュボード) >[Jobs](ジョブ) セクションで、完了したジョブ、進行中のジョブ、入力を待っているジョブの概要を、直近 24 時間分見ることができます。 任意の状態を選択して、関連するジョブについての詳細情報を取得できます。
[すべて表示] を選択すると、直近 24 時間のすべてのジョブが表示されます。
Note
コンテナー メニューの >[Site Recovery Jobs](Site Recovery ジョブ) からもジョブの情報にアクセスできます。
[Site Recovery ジョブ] リストに、ジョブの一覧が表示されます。 トップ メニューで、特定のジョブのエラーの詳細を把握したり、特定の条件でジョブの一覧をフィルター処理したり、選択されたジョブの詳細を Excel にエクスポートしたりすることができます。
ジョブを選択すると、さらに詳しい情報を表示できます。
仮想マシンの監視
[レプリケートされたアイテム] には、レプリケートされたマシンの一覧が表示されます。
情報の表示とフィルター処理を行うことができます。 上部のアクション メニューでは、特定のマシンを対象に操作を実行することができます (テスト フェールオーバーの実行、特定のエラーの表示など)。
RPO、ターゲット構成の問題、レプリケーション エラーなど、他の列を表示するには、[列] を選択します。
レプリケーションの正常性、特定のレプリケーション ポリシーなど、特定のパラメーターに基づいて情報を表示するには、[フィルター] を選択します。
テスト フェールオーバーなどの操作を開始したり、関連付けられている特定のエラーの詳細を確認したりするには、その対象となるマシンを選択します。
いずれかのマシンを選択すると、さらに詳しい情報が表示されます。 詳細には次のものが含まれます。
- レプリケーション情報:マシンの現在の状態と正常性。
- RPO (復旧ポイントの目標):仮想マシンの現在の RPO と、RPO が最後に計算された日時。
- 復旧ポイント:マシンの利用可能な最新の回復ポイント。
- フェールオーバーの準備:対象のマシンに関してテスト フェールオーバーが実行されたかどうかや、マシン上で実行されているエージェントのバージョン (モビリティ サービスを実行しているマシンの場合)、構成上の問題を示します。
- エラー:現在マシンで観察されているレプリケーション エラーの症状と考えられる原因/対策の一覧。
- イベント:マシンに影響を与える最近のイベントの時系列での一覧。 エラーの詳細が、現在観察できるエラーの症状を示しているのに対し、イベントは、マシンに影響を与えた問題の履歴レコードになります。
- インフラストラクチャ ビュー:Azure にマシンをレプリケートするシナリオに関して、インフラストラクチャの状態を表示します。
電子メール通知に登録する
次に示したような重大なイベントに関して、メール通知の受け取りを登録することができます。
- レプリケートされたマシンが重大な状態に陥った。
- オンプレミスのインフラストラクチャ コンポーネントと Site Recovery サービスとの間の接続が失われた。 コンテナーに登録されているオンプレミス サーバーと Site Recovery との間の接続は、ハートビート機構を使って検出されます。
- フェールオーバーに失敗した。
Note
ASR の電子メール通知を有効にしても、追加コストは発生しません。
登録の手順は次のとおりです。
コンテナー >[監視] セクションで、[Site Recovery イベント] を選択します。
[メール通知] を選択します。
[電子メールの通知] で通知をオンにし、送信先を指定します。 すべてのサブスクリプション管理者に通知を送信できるほか、必要に応じて特定のメール アドレスを対象にすることもできます。
Azure Site Recovery に関する組み込みの Azure Monitor アラート
Azure Site Recovery では、Azure Monitor を介して既定のアラートを提供し、さまざまな Azure サービス間で一貫したアラート管理エクスペリエンスを得られるようにします。 Azure Monitor ベースのアラートを使用すると、Azure Monitor でサポートされている通知チャネル (電子メール、Webhook、ロジック アプリなど) にアラートをルーティングできます。 また、計画メンテナンス期間中の通知を抑制するなど、Azure Monitor で提供されるその他のアラート管理機能を使用することもできます。
Note
登録が有効になるまで 24 時間待機してから、機能をテストすることをお勧めします。
アラートのシナリオ
Azure Site Recovery は、次のいずれかの重大なイベントが発生するたびに既定のアラート (Azure Monitor 経由で表示) を送信します。
- Azure VM、Hyper-V、VMware レプリケーションのディザスター リカバリーの失敗アラートの有効化
- Azure VM、Hyper-V、VMware レプリケーションの、レプリケーションの正常性に関する重大な問題のアラート
- Azure VM および Hyper-V レプリケーションの Azure Site Recovery エージェント バージョンの期限切れアラート
- Hyper-V レプリケーションの "Azure Site Recovery エージェントに接続できません" アラート
- Azure VM、Hyper-V、VMware レプリケーションのフェールオーバー失敗アラート
- Azure VM レプリケーションの自動認定期限切れアラート
Azure Site Recovery を使用してテスト VM のアラートの動作をテストするには、キャッシュ ストレージ アカウントのパブリック ネットワーク アクセスを無効にし、"レプリケーションの正常性に重大な問題があります" アラートが生成されるようにします。
Note
"アラート" は、ルールの構成なしで既定で生成されます。 しかし、生成されたアラートに対する "通知" (メール通知など) を有効にするには、次のセクションで説明するように、アラート処理ルールを作成する必要があります。
Recovery Services コンテナーで Azure Site Recovery のアラートを管理する
[Recovery Services コンテナー]>[設定]>[プロパティ]>[監視の設定] の下でアラート設定を表示できます。 Site Recovery の組み込みのアラートは既定で有効ですが、Site Recovery のアラートの片方または両方のカテゴリを無効にできます。 Site Recovery のクラシック アラートをオプトアウトし、組み込みのアラートのみを使用するには、このチェック ボックスをオンにします。 これを行わないと、クラシックと組み込みで重複するアラートが生成されます。
ビジネス継続性センターで Azure Site Recovery のアラートを管理する
アラート設定を管理するには、[ビジネス継続性センター]>[監視とレポート]>[警告] オプションに移動します。 [アラートの管理]>[リソースの組み込みのアラート設定の管理] オプションを選択します。
Backup と Site Recovery のクラシック アラートを使用して、すべてのサブスクリプションにわたるすべてのコンテナーの大規模なビューを取得します。 [更新] を選択すると、各コンテナーのアラート設定を更新できます。 Azure Monitor のアラートのみを取得し、クラシック アラートを無効にすることも選択できます。 既定で有効な組み込みアラートの特定のカテゴリを無効にすることも選択できます。 設定を更新し、[更新] を選択して保存します。
バックアップ センターで Azure Site Recovery のアラートを管理する
重要
このセクションでは、以前のアラート ソリューション (クラシック アラートと呼ばれます) について説明します。 複数の利点がある Azure Monitor ベースのアラートを使用するよう切り替えることをお勧めします。 切り替え方法の詳細については、Azure Monitor ベースのアラートへの切り替えに関する記事を参照してください。
アラートの設定を管理するには、次を実行します。
- Site Recovery の組み込みアラートを管理するには、[アクションを起こすには、ここをクリック] を選択します。
- [アラートの管理] を選択して、アラートの構成を表示します。 [ルールの作成] を選択して、アラートをさまざまな通知チャネルにルーティングするアラート処理ルールを作成します。
- どのコンテナーで Backup と Site Recovery のクラシック アラートが構成されているかを確認します。 クラシック アラートがオンの場合は、[クラシック アラートのバックアップ] と [Site Recovery のクラシック アラート] の 2 つの列に [はい] と表示されます。 監視のエクスペリエンスを向上させるために、[更新] を選択して Azure Monitor ベースのアラートに切り替えることをお勧めします。
- Azure Monitor のアラートのみを受け取り、クラシック アラートを無効にするようにオプションを選択します。 既定で有効な組み込みアラートの特定のカテゴリを無効にすることも選択できます。 セキュリティ アラートを無効にすることはできません。 設定を更新し、[更新] を選択して保存します。
生成された Azure Site Recovery アラートを Recovery Services コンテナーで表示する
特定のコンテナーに対して生成されたアラートを、コンテナー エクスペリエンスを介して表示するには、次の手順に従います。
- Azure portal で、使用している Recovery Services コンテナーに移動します。
- [アラート] セクションを選択し、[サービスの監視] = [Azure Site Recovery] のフィルターを設定して、Azure Site Recovery 固有のアラートを表示します。 他のフィルターの値をカスタマイズし、特定の時間範囲 (最大 30 日) のアラート、コンテナーやサブスクリプションのアラート、重大度およびアラートの状態 (ユーザー応答) を表示できます。
- いずれかのアラートを選択すると、影響を受ける VM、考えられる原因、推奨される操作などの詳細を確認できます。
- イベントが軽減されたら、その状態を [終了] か [確認済み] に変更できます。
生成された Azure Site Recovery アラートを Azure Monitor で表示する
アラートが生成されると、Azure Monitor ポータルで表示し、管理できるようになります。 次の手順のようにします。
Azure portal で [Azure Monitor]>[アラート] に移動します。
[サービスの監視] = [Azure Site Recovery] のフィルターを設定し、Azure Site Recovery 固有のアラートを表示します。 他のフィルターの値をカスタマイズし、特定の時間範囲 (最大 30 日) のアラート、コンテナーやサブスクリプションのアラート、重大度およびアラートの状態 (ユーザー応答) を表示することもできます。
いずれかのアラートを選択すると、詳細を確認できます。 たとえば、影響を受ける VM、考えられる原因、推奨される操作などです。
イベントが軽減されたら、その状態を [終了] か [確認済み] に変更できます。
生成された Azure Site Recovery のアラートをビジネス継続性センターで表示する
[ビジネス継続性センター]>[監視とレポート]>[警告] ブレードの下でアラート設定を管理できます。 [重大度] と [カテゴリ] の順にアラートが表示されます。 ハイパーリンクまたは [影響を受けるリソースの表示] を選択して、アラートの詳細ビューを表示します。
[アラートを表示する] を選択してアラートの詳細を取得し、アクションを実行します。
Azure Monitor、ビジネス継続性センター、Recovery Services コンテナーと同様に、バックアップ センターからもアラートを表示できます。
アラートの電子メール通知を構成する
Azure Site Recovery 向けに、組み込みの Azure Monitor アラートの電子メール通知を構成するには、Azure Monitor でアラート処理ルールを作成する必要があります。 アラート処理ルールは、特定の通知チャネル (アクション グループ) に対して送信するアラートを指定します。
アラート処理ルールを作成するには、次の手順に従います。
[Azure Monitor]>[アラート] の順に選択し、上部のウィンドウで [アラート処理ルール] を選択します。
[作成] を選択します
アラート処理ルールの [スコープ]>[スコープの選択] で、サブスクリプション内のすべてのリソースにルールを適用できます。 フィルターを適用すると、スコープに対して他のカスタマイズも行えます。 たとえば、特定の重要度のアラートに対して通知を生成することもできます。
[ルールの設定] で [アクション グループの適用] と [アクション グループの作成] を選択します (または既存のアクション グループを使用します)。 アクション グループは、アラートの通知の送信先です。 たとえば、メール アドレスです。
アクション グループの作成において、[基本] タブでアクション グループの名前、サブスクリプション、そのグループを作成するリソース グループを選択します。
[通知] タブで、通知の送信先として [電子メール/SMS メッセージ/プッシュ/音声] を選択し、受信者の電子メール ID と、その他の情報を必要に応じて入力します。
[確認と作成]>[作成] を選択してアクション グループをデプロイします。 アクション グループを作成すると、アラート処理ルールの作成に戻ります。
Note
作成されたアクション グループは [ルール設定] ページに表示されます。
[スケジュール] タブで [常に] を選択します。
[詳細] タブで、アラート処理ルールを作成する対象のサブスクリプションとリソース グループを指定し、作成するルールの名前も指定します。
必要に応じてタグを追加し、[確認と作成]>[作成] の順に選択します。 アラート処理ルールは数分以内にアクティブになります。
電子メール以外のチャネルの通知を構成する
Azure Monitor アクション グループでは、Webhook、ロジック アプリ、関数などの他の通知チャネルにアラートをルーティングできます。 Azure Monitor でサポートされているアクション グループの詳細に関する記事を参照してください。
プログラマティック インターフェイスを介して通知を構成する
Azure Monitor でサポートされている次のインターフェイスを使用して、アクション グループとアラート処理ルールを管理できます。
計画メンテナンス期間中の通知を抑制する
メンテナンス期間のように、Azure Site Recovery の操作が失敗することが予想されるシナリオがあります。 そのような期間中に通知を抑制する要件がある場合は、抑制アラート処理ルールを設定し、それを特定の期間に実行できます。
抑制アラート処理ルールを作成するには、前のセクションで説明した通知ベースのアラート処理ルールと同じ手順を実行しますが、以下の違いがあります。
[ルールの設定] で、[通知を表示しない] を選択します。 同じスコープに対して、抑制アラート処理ルールとアクション グループ アラート処理ルールの両方が適用されている場合、抑制ルールが優先されます。
[スケジュール] で、アラートを抑制する期間を入力します。
価格
組み込みの Azure Monitor アラートでは、重大な操作や失敗のアラートは既定で作成されます。 これらのアラートはポータルか、ポータル以外のインターフェイスを介して表示できます。追加料金は発生しません。 ただし、これらのアラートを通知チャネル (電子メールなど) にルーティングする場合、Free レベル (1 か月あたり 1,000 メール) を超える通知に対してはわずかなコストが発生します。 Azure Monitor の価格を確認する。
次のステップ
Azure Monitor を使用した Site Recovery の監視について確認します。