可用性管理

適用対象: Exchange Server 2013 SP1

ユーザーの電子メール エクスペリエンスの向上は常に、メッセージング システム管理者の主要な目的です。 Microsoft Exchange Server 2013 組織の可用性と信頼性を確保するには、システムのすべての側面をアクティブに監視し、検出された問題を迅速に解決する必要があります。 以前のバージョンの Exchange では、通常、Microsoft System Center 2012 Operations Manager などの外部アプリケーションを使用してデータを収集し、収集されたデータを分析した結果として検出された問題の復旧アクションを提供するために重要なシステム コンポーネントを監視します。 Exchange 2010 以前のバージョンには、管理パックの形式で正常性マニフェストと相関エンジンが含まれていました。 これらのコンポーネントにより、Operations Manager は、特定のコンポーネントが正常か異常かの判断を行うようになりました。 さらに、Operations Manager では、Exchange 2010 に組み込まれている診断コマンドレット インフラストラクチャも使用して、システムのさまざまな側面に対して代理トランザクションを実行しました。

Exchange 2013 では、組み込みの監視と回復アクションを提供する Managed Availability という機能を使用して、エンド ユーザー エクスペリエンスをネイティブに監視および保持するための新しいアプローチが採用されています。

マネージド 可用性 ( Active Monitoring または Local Active Monitoring とも呼ばれます) は、組み込みの監視と回復アクションと Exchange 高可用性プラットフォームの統合です。 可用性管理は、問題が発生してシステムで発見されると、すぐにそれを検出して回復するように設計されています。 Exchange での以前の外部監視向けソリューションやテクニックとは異なり、可用性管理は、問題の根本原因の識別や通知を試みません。 その代わりに、次に示すユーザー エクスペリエンスの主要な 3 つの領域に対応する回復局面に力を集中します。

  • 可用性: ユーザーはサービスにアクセスできますか?
  • 待機時間: ユーザーのエクスペリエンスはどうですか?
  • エラー: ユーザーは必要な操作を実行できますか?

Exchange 2013 のサーバー ロールの統合とその他のアーキテクチャの変更には、以前のバージョンの Exchange で使用されていた監視手法と正常性モデルに対する新しいアプローチが必要です。 マネージド 可用性は、ネイティブの正常性監視と回復ソリューションを提供することで、これらの変更に対処するように設計されています。 これは、切り離されたシステム個々の断片を監視するのではなく、エンド ツー エンドのユーザー エクスペリエンスを監視し、回復指向のアクションを通してエンドユーザーのエクスペリエンスを保護します。

マネージド可用性は、すべての Exchange 2013 サーバーで実行される内部プロセスです。 1 秒ごとに数百もの正常性メトリックをポーリングし、分析します。 異常が検出されても、ほとんどの場合は自動的に修正されます。 しかし、可用性管理のみでは修正できない問題が発生する場合もあります。 そのような問題が起きた場合、可用性管理はイベント ログを介して問題を管理者にエスカレートします。

マネージド可用性は、次の 2 つのサービスの形式で実装されます。

  • Exchange Health Manager Service (MSExchangeHMHost.exe): このサービスは、ワーカー プロセスを管理するために使用されるコントローラー プロセスです。 これを使ってワーカー プロセスを必要に応じて構築、実行、開始、および停止します。 また、ワーカー プロセスが停止した場合の回復や、ワーカー プロセスが単一障害点になることを防ぐためにも使用されます。

  • Exchange Health Manager Worker プロセス (MSExchangeHMWorker.exe): このサービスは、マネージド可用性フレームワーク内でランタイム タスクを実行するワーカー プロセスです。

可用性管理では、永続的なストレージを使用してその機能を実行します。

  • \bin\Monitoring\config フォルダーにある XML ファイルを使って、プローブと監視の一部の作業項目の構成設定を格納します。
  • Active Directory を使って、グローバル オーバーライドを格納します。
  • Windows レジストリを使って、ブックマークなどのランタイム データ、ローカル (サーバー固有の) オーバーライドを格納します。
  • Windows クリムゾン チャネル イベント ログ インフラストラクチャを使用して、作業項目の結果を格納します。
  • 正常性メールボックスは、プローブ アクティビティに使われます。 複数の正常性メールボックスが、サーバーに存在する各メールボックス データベースに作成されます。

次の図に示すように、可用性管理は、常時稼働する 3 つの主要非同期コンポーネントを含みます。

Exchange Server 2013 のマネージド可用性。

1 つ目のコンポーネントはプローブと呼ばれています。 プローブは、サーバー上の測定とデータの収集を行います。 これらの測定値の結果は、2 番目のコンポーネントである モニターに流れます。 モニターには、収集されたデータで正常と見なされるものに基づいて、システムによって使用されるすべてのビジネス ロジックが含まれています。 モニターは、パターン認識エンジンと同様に、収集したすべての測定値についてさまざまなパターンを探し出し、対象が正常かどうかの決定を下すことができます。 最後に、回復とエスカレーションのアクションを担当する レスポンダーがあります。 何かが異常な場合、最初のアクションは、そのコンポーネントの回復を試みすることです。 この復旧作業には、複数ステージの復旧アクションが含まれる場合があります。たとえば、最初の試行はアプリケーション プールの再起動、2 つ目はサービスの再起動、3 回目の試行はサーバーの再起動、それ以降の試行はトラフィックを受け入れなくなったようにサーバーをオフラインにする場合があります。 復旧アクションが失敗した場合、システムはイベント ログ通知を通じて問題を人間にエスカレートします。

プローブには、リカレント プローブ、通知、チェックの 3 つの主要なカテゴリがあります。 リカレント プローブは、エンド ツー エンドのユーザー エクスペリエンスをテストするためにシステムによって実行される代理トランザクションです。 チェックは、ユーザー トラフィックを含むパフォーマンス データの収集を実行し、収集されたデータを、ユーザーエラーの急増を判断するために設定されたしきい値に対して測定するインフラストラクチャです。 この測定機能により、ユーザーが問題が発生したときにチェック インフラストラクチャが認識されます。 最後に、通知ロジックを使用すると、システムは、プローブによって収集されたデータの結果を待機することなく、重要なイベントに基づいてすぐにアクションを実行できます。 これらの例外または条件は、大きなサンプル セットなしで検出および認識できます。

リカレント プローブは数分ごとに実行され、サービス正常性のいくつかの側面を確認します。 このプローブは、Exchange ActiveSync 経由の電子メールを監視対象メールボックスに送信したり、RPC エンドポイントに接続したり、メールボックスに対するクライアント アクセスの接続を確認したりします。

すべてのプローブが Microsoft.Exchange.ActiveMonitoring\ProbeDefinition クリムゾン チャネルでの Health Manager サービスの起動時に定義されます。 各プローブ定義には多くのプロパティがありますが、最も関連するプロパティは次のとおりです。

  • 名前: プローブの名前。プローブのモニターの SampleMask で始まります。
  • TypeName: プローブのロジックを含むプローブのコード オブジェクト型。
  • ServiceName: このプローブを含む正常性セットの名前。
  • TargetResource: プローブが検証しているオブジェクト。 このプロパティ名は、プローブの結果 ResultName になるように実行されるときに、プローブの名前に追加されます。
  • RecurrenceIntervalSeconds: プローブが実行される頻度。
  • TimeoutSeconds: 失敗するまでにプローブが待機する時間。

何百もの反復プローブがあります。 これらのプローブの多くはデータベース単位のため、データベースの数が増えるほど、プローブの数も増えます。 ほとんどのプローブは、コード内で定義されるため、直接検出することはできません。

繰り返しプローブの基本は次のとおりです。 各 RecurrenceIntervalSeconds を 開始し、正常性の何らかの側面を確認 (またはプローブ) します。 コンポーネントが正常な場合、プローブは 、ResultType が 3 の Microsoft.Exchange.ActiveMonitoring\ProbeResult チャネルに情報イベントを渡して書き込みます。 チェックが失敗またはタイムアウトした場合、プローブは失敗し、エラー イベントを同じチャネルに書き込みます。 ResultType が 4 の場合はチェックが失敗し、ResultType が 1 の場合はタイムアウトしたことを意味します。多くのプローブは、タイムアウトすると、MaxRetryAttempts プロパティの値まで再実行されます。

注:

ProbeResult クリムゾン チャネルは何百ものプローブが数分おきに起動してイベントをログに記録することによって非常に忙しくなる可能性があるため、実稼働環境のイベント ログに対して負荷のかかる問い合わせを実行すると、Exchange サーバーのパフォーマンスに重大な影響が出る可能性があります。

通知は、正常性マネージャー フレームワークではなく、サーバー上の他のサービスによって実行されるプローブです。 これらのサービスは独自の監視を実行し、プローブの結果を直接書き込むことで、マネージド可用性フレームワークにデータをフィードします。 ProbeDefinition チャネルにはこれらのプローブは表示されません。このチャネルでは、Managed Availability フレームワークによって実行されるプローブのみが記述されるためです。 たとえば、ServerOneCopyMonitor Monitor は、MSExchangeDAGMgmt サービスによって書き込まれたプローブの結果によってトリガーされます。 このサービスは、独自の監視を実行し、問題があるかどうかを判断し、プローブの結果をログに記録します。 ほとんどの通知プローブには、モニターを異常にさせる赤いイベントと、モニターを再び正常にする緑色のイベントの両方をログに記録する機能があります。

チェックは、パフォーマンス カウンターが定義済みのしきい値を上回ったまたは下回ったイベントのみをログに記録するプローブです。 実際には、このプローブは通知プローブの特殊なケースであり、サーバー上のパフォーマンス カウンターを監視して、構成済みのしきい値を超えたときに ProbeResult チャネルにイベントを書き込むサービスが存在します。

異常と見なされるカウンターとしきい値を見つけるには、このチェック用のモニターを参照します。 Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor または Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor 型のモニターは、監視するプローブがチェック プローブであることを意味します。

モニターは、プローブによって収集されたデータに対してクエリを実行し、定義済みのルール セットに基づいてアクションを実行する必要があるかどうかを判断します。 モニターは、ルールまたは問題の特性に基づいて、レスポンダーを起動するか、問題をイベント ログのエントリを介して人的対応レベルにエスカレートできます。 さらに、モニターは、レスポンダーが実行された失敗後の時間と、回復アクションのワークフローを定義します。 モニターにはさまざまな状態があります。 システム状態の観点から見ると、モニターの状態は次の 2 つです。

  • 正常: モニターが正常に動作しており、収集されたすべてのメトリックが通常の動作パラメーター内にある
  • 異常: モニターは正常ではなく、レスポンダーを介して復旧を開始したか、エスカレーションによって管理者に通知します。

管理の観点から見ると、モニターには、シェルに表示されるさらに多くの状態があります。

  • 機能低下: モニターが 0 から 60 秒の間に異常な状態にある場合は、機能低下と見なされます。 モニターの正常でない状態が 60 秒を超えると、モニターは異常と見なされます。
  • 無効: モニターは管理者によって明示的に無効になっています。
  • 利用不可: Microsoft Exchange Health サービスは、各モニターの状態を定期的に照会します。 クエリに対する応答がない場合、モニターの状態は "使用不可能" になります。
  • 修復: 管理者は、修復状態を設定して、修正アクションが人間によって処理中であることをシステムに示します。これにより、システムと人間は、修正アクションが実行されると同時に発生する可能性がある他のエラー (データベース コピーの再シード操作など) を区別できます。

すべてのモニターには、その定義に SampleMask プロパティがあります。 モニターを実行すると、モニターの SampleMask と一致する ResultName を持つ ProbeResult チャネル内のイベントが検索されます。 これらのイベントは、反復プローブ、通知、またはチェックで検出されたものです。 モニターのしきい値に到達すると、異常と見なされます。 モニターの観点では、3 つすべてのプローブの種類が ProbeResult チャネルに書き込まれる種類と一致します。

1 つのプローブ エラーが必ずしもサーバーに問題があることを示しているわけではないことは注目に値します。 修正が必要な実際の問題の存在を正しく特定できるかどうかはモニターの設計にかかっています。 そのため、多くのモニターでは、異常になる前に複数のプローブ障害のしきい値が設定されます。 それでも、これらの問題の多くがレスポンダーによって自動的に修復される可能性があるため、人間の介在が必要な問題を見つける最良の場所は Microsoft.Exchange.ManagedAvailability\Monitoring クリムゾン チャネルです。 このチャネルには、最新のプローブ エラーが含まれています。

その名前が示すように、レスポンダーはモニターによって生成されたアラートに対して何らかの応答を実行します。 レスポンダーは、アプリケーション ワーカー プールをリセットしてサーバーを再起動するなど、さまざまな回復アクションを実行します。 レスポンダーには、さまざまな種類があります。

  • レスポンダーの再起動: サービスを終了して再起動します
  • AppPool レスポンダーのリセット: インターネット インフォメーション サービス (IIS) でアプリケーション プールを停止して再起動します
  • フェールオーバー レスポンダー: データベースまたはサーバーのフェールオーバーを開始します
  • バグチェック レスポンダー: サーバーのバグチェックを開始し、サーバーの再起動を引き起こします
  • オフライン レスポンダー: サーバー上のプロトコルをサービスから外します (クライアント要求を拒否します)
  • オンライン レスポンダー: サーバー上のプロトコルを運用環境に戻します (クライアント要求を受け入れます)
  • レスポンダーのエスカレート: イベント ログを使用して管理者に問題をエスカレートする

上記のレスポンダーに加えて、一部のコンポーネントには、コンポーネントに固有の特殊なレスポンダーがあります。

すべてのレスポンダーには調整動作が含まれます。これにより、レスポンダーアクションを制御するための組み込みのシーケンスメカニズムが提供されます。 調整動作は、レスポンダーの回復アクションの結果としてシステムが侵害されたり悪化したりしないように設計されています。 すべてのレスポンダーは、何らかの方法で調整されます。 調整が発生すると、レスポンダーのアクションに応じて、レスポンダーの回復アクションがスキップまたは遅延する可能性があります。 たとえば、バグチェック レスポンダーが調整されると、そのアクションはスキップされ、遅延されません。

正常性セット

可用性管理をレポートの観点から見ると、正常性には 2 つのビューがあります。1 つは内部ビューで、もう 1 つは外部ビューです。 内部ビューでは、正常性セットを使います。 Exchange 2013 の各コンポーネント (たとえば、Outlook Web App、Exchange ActiveSync、Information Store サービス、コンテンツ インデックス作成、トランスポート サービスなど) は、プローブ、モニター、レスポンダーを使用してマネージド可用性によって監視されます。 特定のコンポーネントのプローブ、モニター、レスポンダーのグループは、 正常性セットと呼ばれます。 正常性セットは、一連のプローブ、モニター、レスポンダーであり、そのコンポーネントが正常かどうかを判断します。 正常性セットの現在の状態 (正常か異常かなど) は、正常性セットのモニターの状態を使用して決定されます。 正常性セットのすべてのモニターが正常であれば、正常性セットの状態は正常です。 いずれかのモニターが異常な状態を示す場合、正常性セットの状態は、最も大きな異常を示すモニターによって判断されます。

サーバーの正常性または正常性セットの状態を表示する詳細な手順については、「Manage health sets and server health」を参照してください。

正常性グループ

可用性管理の外部ビューは、正常性グループで構成されます。 正常性グループは、System Center Operations Manager 2007 R2 および System Center Operations Manager 2012 に公開されます。

主要な正常性グループは、以下の 4 つです。

  • カスタマー タッチ ポイント: プロトコルやインフォメーション ストアなど、リアルタイムのユーザー操作に影響を与えるコンポーネント
  • サービス コンポーネント: Microsoft Exchange メールボックス レプリケーション サービスやオフライン アドレス帳生成プロセス (OABGen) など、直接、リアルタイムのユーザー操作を行わないコンポーネント
  • サーバー コンポーネント: ディスク領域、メモリ、ネットワークなど、サーバーの物理リソース
  • 依存関係の可用性: Active Directory、DNS などの必要な依存関係にアクセスするサーバーの機能。

Exchange 管理パックをインストールした場合、System Center Operations Manager (SCOM) は、Exchange 環境に関連する情報を参照する正常性ポータルとして機能します。 SCOM ダッシュ ボードでは、Exchange サーバーの状態を以下の 3 つのビューで確認できます。

  • アクティブなアラート: エスカレーション レスポンダーは、SCOM 内のモニターによって使用される Windows イベント ログにイベントを書き込みます。 これらのイベントは、[アクティブなアラート] ビューにアラートとして表示されます。
  • 組織の正常性: Exchange 組織の正常性の全体的な正常性のロールアップの概要がこのビューに表示されます。 これらのロールアップには、個々のデータベース可用性グループの正常性、および特定の Active Directory サイト内の正常性が表示されます。
  • サーバー正常性: 関連する正常性セットが正常性グループに組み合わされ、このビューにまとめられます。

Overrides

管理者はオーバーライドを使って、可用性管理のプローブ、モニター、レスポンダーのいくつかの側面を構成できます。 オーバーライドにより、可用性管理で使用するしきい値の一部を調整できます。 また、予想外のイベントが発生して既定値とは異なる構成設定が必要となった場合、緊急の処置をとるために使用することもできます。

オーバーライドは、1 つのサーバーに作成して適用できます (このプロセスは サーバーオーバーライドと呼ばれます)、またはサーバーのグループに適用できます (このプロセスは グローバルオーバーライドと呼ばれます)。 サーバー オーバーライドの構成データは、オーバーライドを適用するサーバー上の Windows レジストリに格納されます。 グローバル オーバーライドの構成データは、Active Directory に格納されます。

有効期間に制限のないオーバーライド、または特定の期間を対象とするオーバーライドを構成できます。 グローバル オーバーライドは、すべてのサーバーに適用するか、特定のバージョンの Exchange を実行しているサーバーのみに適用するように構成できます。

オーバーライドを構成しても、すぐには有効になりません。 Microsoft Exchange Health Manager サービスは、10 分ごとに構成データが更新されたかどうかをチェックします。 さらに、グローバル オーバーライドは、Active Directory のレプリケーションの待機時間にも左右されます。

サーバーまたはグローバルオーバーライドを表示または構成する詳細な手順については、「 マネージド可用性のオーバーライドを構成する」を参照してください。

管理タスクおよびコマンドレット

管理者は通常、可用性管理に関連する 3 つの主要な運用タスクを実行します。

  • システム正常性の抽出または表示。
  • 正常性セットの表示、プローブ、モニター、レスポンダーの詳細の表示。
  • オーバーライドの管理。

マネージド可用性の 2 つの主要な管理ツールは、Windows イベント ログとシェルです。 マネージド可用性では、Exchange ActiveMonitoring と ManagedAvailability の真紅のチャネル イベント ログに、次のような大量の情報がログに記録されます。

  • プローブ、モニター、レスポンダーの定義は、それぞれの *Definition イベント ログに記録されます。
  • プローブ、モニター、レスポンダーの結果は、それぞれの *Results イベント ログに記録されます。
  • レスポンダーの回復操作の開始時刻、操作が完了したと見なされる時刻 (成功したかどうかにかかわらず) などを含む回復操作の詳細は、RecoveryActionResults イベント ログに記録されます。

次の表に、可用性管理で使用される 12 個のコマンドレットを示します。

コマンドレット 説明
Get-ServerHealth 正常性セットとその現在の状態 (正常または異常)、正常性セットのモニター、サーバー コンポーネント、プローブのターゲット リソース、プローブまたはモニターの開始と終了の時間に関するタイムスタンプ、状態遷移時間など、生のサーバーの正常性に関する情報の取得に使用します。
Get-HealthReport 正常性セットとその現在の状態を含む正常性の表示の概要を取得に使用します。
Get-MonitoringItemIdentity 特定の正常性セットに関連するプローブ、モニター、レスポンダーの表示に使用します。
Get-MonitoringItemHelp プローブ、モニター、レスポンダーの一部のプロパティについての説明の表示に使用します。
Add-ServerMonitoringOverride プローブ、モニター、またはレスポンダーのローカルのサーバー固有のオーバーライドの作成に使用します。
Get-ServerMonitoringOverride 指定されたサーバーのローカル オーバーライドの一覧の表示に使用します。
Remove-ServerMonitoringOverride 特定のサーバーからのローカル オーバーライドの削除に使用します。
Add-GlobalMonitoringOverride サーバー グループのグローバル オーバーライドの作成に使用します。
Get-GlobalMonitoringOverride 組織内で構成されたグローバル オーバーライドの一覧の表示に使用します。
Remove-GlobalMonitoringOverride グローバル オーバーライドの削除に使用します。
Set-ServerComponentState 1 つ以上のサーバー コンポーネントの状態の構成に使用します。
Get-ServerComponentState 1 つ以上のサーバー コンポーネントの状態の表示に使用します。