Share via

可用性管理

  • [アーティクル]

ユーザーの電子メール エクスペリエンスの向上は常に、メッセージング システム管理者の主要な目的です。 Exchange Server組織では、システムのすべての側面をアクティブに監視し、検出された問題を迅速に解決する必要があります。 これを実現するために、可用性管理と呼ばれる機能により、エンドユーザーのエクスペリエンスを維持する組み込みの監視と回復アクションが提供されます。

可用性管理

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

  • 可用性: ユーザーはサービスにアクセスできますか?

  • 待機時間: ユーザーのエクスペリエンスはどうですか?

  • エラー: ユーザーは必要な操作を実行できますか?

可用性管理は、ネイティブな正常性の監視と回復ソリューションを提供します。 これは、切り離されたシステム個々の断片を監視するのではなく、エンド ツー エンドのユーザー エクスペリエンスを監視し、回復指向のアクションを通してエンドユーザーのエクスペリエンスを保護します。

マネージド可用性は、すべての Exchange サーバーで実行される内部プロセスです。 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のマネージド可用性のコンポーネント。

プローブ

1 つ目のコンポーネントはプローブと呼ばれています。 プローブは、サーバー上の測定とデータの収集を行います。

プローブには、リカレント プローブ、通知、チェックの 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 番目のコンポーネントであるモニターに渡ります。 モニターには、収集したデータに基づいて、システムによって使用されるビジネス ロジックのすべてが含まれています。 モニターは、パターン認識エンジンと同様に、収集したすべての測定値についてさまざまなパターンを探し出し、対象が正常かどうかの決定を下すことができます。

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

  • 正常: モニターは正常に動作しており、収集されたすべてのメトリックは通常の動作パラメーター内にあります。

  • 異常: モニターは正常ではなく、レスポンダーを介して復旧を開始したか、エスカレーションによって管理者に通知します。

管理上の観点から、モニターには、Exchange 管理シェルに表示される追加の状態があります。

  • 機能低下: モニターが 0 から 60 秒の間に異常な状態にある場合は、機能低下と見なされます。 モニターの正常でない状態が 60 秒を超えると、モニターは異常と見なされます。

  • 無効: モニターは管理者によって明示的に無効になっています。

  • 利用不可: Exchange Health サービスは、各モニターの状態を定期的に照会します。 クエリに対する応答がない場合、モニターの状態は "使用不可能" になります。

  • 修復: 管理者は、修復状態を設定して、修正アクションが人間によって処理中であることをシステムに示します。これにより、システムと人間は、修正アクションが実行されると同時に発生する可能性がある他のエラー (データベース コピーの再シード操作など) を区別できます。

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

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

レスポンダー

最後に、回復とエスカレーションのアクションを担当する レスポンダーがあります。 その名前が示すように、レスポンダーはモニターによって生成されたアラートに対して何らかの応答を実行します。 何かが異常な場合、最初のアクションは、そのコンポーネントの回復を試みすることです。 これには、複数ステージの復旧アクションが含まれる場合があります。たとえば、最初の試行はアプリケーション プールの再起動、2 つ目はサービスの再起動、3 回目の試行はサーバーの再起動、それ以降の試行はトラフィックを受け入れなくなったようにサーバーをオフラインにする場合があります。 復旧アクションが失敗した場合、システムはイベント ログ通知を通じて問題を人間にエスカレートします。

レスポンダーは、アプリケーション ワーカー プールのリセットやサーバーの再起動など、さまざまな回復アクションを実行します。 レスポンダーには、さまざまな種類があります。

  • 再起動レスポンダーサービスを終了して再起動します。

  • アプリケーション プール リセット レスポンダーインターネット インフォメーション サービス (IIS) のアプリケーション プールを停止して再起動します。

  • フェールオーバー レスポンダー データベースまたはサーバーのフェールオーバーを開始します。

  • バグ チェック レスポンダー サーバーのバグチェックを開始することによって、サーバーを再起動します。

  • オフライン レスポンダー サーバーのプロトコルをサービス停止 (クライアントからの要求を拒否) にします。

  • オンライン レスポンダー サーバーのプロトコルを稼働状態に戻します (クライアントからの要求を受け付ける)。

  • エスカレート レスポンダー イベント ログを介して管理者に問題をエスカレートします。

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

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

正常性セット

可用性管理をレポートの観点から見ると、正常性には 2 つのビューがあります。1 つは内部ビューで、もう 1 つは外部ビューです。

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

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

正常性グループ

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

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

  • 顧客タッチ ポイント リアルタイムのユーザー操作に影響するコンポーネント。プロトコル、インフォメーション ストアなど。

  • サービス コンポーネント 直接的なリアルタイムのユーザー操作を伴わないコンポーネント。Microsoft Exchange Mailbox Replication サービス、オフライン アドレス帳の生成プロセス (OABGen) など。

  • サーバー コンポーネント ディスク領域、メモリ、ネットワークなど、サーバーの物理リソース。

  • 依存関係の可用性 Active Directory、DNS などの必要な依存関係にアクセスするサーバーの機能。

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

  • アクティブなアラート エスカレーション レスポンダーは Windows イベント ログにイベントを書き込み、それらは SCOM 内でモニターによって使用されます。 これらは [アクティブなアラート] ビューにアラートとして表示されます。

  • 組織の正常性 このビューには、Exchange 組織の正常性の全体的な正常性のロールアップの概要が表示されます。 これらのロールアップには、個々のデータベース可用性グループの正常性、および特定の Active Directory サイト内の正常性が表示されます。

  • サーバーの状態 関連する正常性セットの組み合わせが正常性グループとして集計され、このビューに表示されます。

Overrides

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

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

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

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

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

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

管理者が通常、マネージド 可用性に関して行う主な運用タスクは 3 つあります。

  • システム正常性の抽出または表示。

  • 正常性セットの表示、プローブ、モニター、レスポンダーの詳細の表示。

  • オーバーライドの管理。

マネージド可用性の 2 つの主要な管理ツールは、Windows イベント ログと Exchange 管理シェルです。 マネージド可用性では、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 つ以上のサーバー コンポーネントの状態の表示に使用します。