Partager via

管理可用性機能のレスポンダー

  • Article

(この記事は 2015 年 3 月 2 日に Office Blogs に投稿された記事 Managed Availability Responders の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

 

管理可用性機能の最後に控える重要な要素が、レスポンダーです。以前の記事でご説明したように、プローブ (英語) は、ユーザーのエクスペリエンスに関する正確な情報をモニター (英語) に渡します。レスポンダーは、モニターの判断に基づいて状況を修復します。調整機能によって実行が制限されない場合、レスポンダーはサービスの再起動、IIS アプリ プールのリセット、あるいは Exchange の開発者によって症状の解決に有効だと判断されたその他の回復アクションを開始します。レスポンダーがトリガーされるタイミングについては、管理可用性機能のモニター (英語) に関する記事の「Responder Timeline」セクションを参照してください。

 

定義と結果

プローブやモニターと同様に、レスポンダーにも定義用と結果用のイベント ログ チャネルがあります。定義は Microsoft-Exchange-ActiveMonitoring/ResponderDefinition チャネルから確認できます。以下に、重要なプロパティの一部をご紹介します。

  TypeName: このレスポンダーがトリガーされた場合に実行される回復アクションの完全なコード名。

  Name: レスポンダーの名前。

  ServiceName: このレスポンダーが属する正常性セット。

  TargetResource: このレスポンダーの処理対象となるオブジェクト。

  AlertMask: このレスポンダーのモニター。

  ThrottlePolicyXml: このレスポンダーの実行が許可される頻度。詳細については、次のセクションで説明します。

結果は Microsoft-Exchange-ActiveMonitoring/ResponderResult チャネルから確認できます。モニターが回復アクションを実行するように指示したかどうかにかかわらず、レスポンダーは定期的に結果を出力します。ResponderResult イベントの RecoveryResult の値が 2、IsRecoveryAttempted の値が 1 である場合は、レスポンダーが回復アクションを試行したことを示します。通常は、レスポンダーの結果を確認せずに直接 Microsoft-Exchange-ManagedAvailability/RecoveryActionResults を確認してよいのですが、まずは Microsoft-Exchange-ManagedAvailability/RecoveryActionLogs イベント ログ チャネルのイベントについてご説明します。

 

調整機能

レスポンダーが回復アクションを試行する場合、最初に調整機能の制限に照らしてチェックを行います。これにより、RecoveryActionLogs チャネルに 2 種類のイベントのいずれかが記録されます。調整機能によって実行が許可された場合は 2050、実行が却下された場合は 2051 と表示されます。以下は 2051 のイベントの例です。

[Details] タブでは、以下のような項目を確認できます。

ActionId

RestartService

ResourceName

MSExchangeRepl

RequesterName

ServiceHealthMSExchangeReplEndpointRestart

ExceptionMessage

Active Monitoring Recovery action failed. An operation was rejected during local throttling. (ActionId=RestartService, ResourceName=MSExchangeRepl, Requester=ServiceHealthMSExchangeReplEndpointRestart, FailedChecks=LocalMinimumMinutes, LocalMaxInDay)

LocalThrottleResult

<LocalThrottlingResult IsPassed="false" MinimumMinutes="60" TotalInOneHour="1" MaxAllowedInOneHour="-1" TotalInOneDay="1" MaxAllowedInOneDay="1" IsThrottlingInProgress="true" IsRecoveryInProgress="false" ChecksFailed="LocalMinimumMinutes, LocalMaxInDay" TimeToRetryAfter="2015-02-11T14:29:57.9448377-08:00"> <MostRecentEntry Requester="ServiceHealthMSExchangeReplEndpointRestart" StartTime="2015-02-10T14:29:55.9920032-08:00" EndTime="2015-02-10T14:29:57.9448377-08:00" State="Finished" Result="Succeeded" /> </LocalThrottlingResult>

GroupThrottleResult

<not attempted>

TotalServersInGroup

0

TotalServersInCompatibleVersion

0

最初のいくつかのフィールドは見当がつくかと思います。この例は、サービスを再起動する RestartService の回復アクションです。ResourceName を基に、回復アクションが対象を選択します。RestartService の回復アクションの場合は、再起動するサービスの名前になります。RequesterName は、ResponderDefinition または ResponderResult のチャネルに表示されているレスポンダーの名前です。

LocalThrottleResult プロパティはもう少し興味深いものです。回復アクションはサーバーごとに調整されます。つまり、同じサーバーに対して同じ回復アクションがあまり頻繁に実行することはありません。同様に、グループごとにも調整されており、同じ DAG (メールボックスの役割の場合) または AD サイト (クライアント アクセスの役割の場合) に対して同じ回復アクションがあまり頻繁に実行されることはありません。-1 という値は、このレベルの調整が行われていないことを示します。たとえば、1 日に許可されているアクションが 1 回の場合は MaxAllowedInOneHour を指定する意味はありません。この例では、MSExchangeRepl リソースが既に過去 60 分間に回復アクションの対象となっており、回復アクションが LocalMinimumMinutes の調整によって許可されませんでした。ローカル調整によって回復アクションの試行がブロックされたため、グループ調整は試行されていません。以下の表では、このイベントについて出力される各制限について説明しています。

GroupThrottleResult にも同じフィールドが設定されており、グループ内に属する他のサーバーに対して実行された回復アクションの詳細が表示されます。

アクションが調整機能によって制限されなかった場合、Microsoft-Exchange-ManagedAvailability/RecoveryActionResults チャネルには、回復アクションが開始されたことを示すイベント 500 が記録されます。回復アクションが正常に完了すると、イベント 501 が記録されます。これが最も一般的なケースで、通常はこのようになることが望ましいとされます。これらのイベントと共に、実行された回復アクション、制限がかからなかった調整に関する詳細が記録されます。開始されて正常に完了しなかった回復アクションも、調整による制限の対象となります。回復アクションの詳細については、サービスに対する管理可用性機能の処理 (英語) に関する記事を参照してください。

 

調整による制限の確認

回復アクションに対してどの調整が行われるかを確認するには、レスポンダーが回復アクションを開始してから RecoveryActionsLogs チャネルで調整機能の設定を確認する方法もありますが、開始前でも確認できる場所が 2 つあります。1 つ目は Microsoft-Exchange-ManagedAvailability\ThrottlingConfig イベント ログ チャネル、2 つ目はこの記事の最初のセクションで紹介した、Microsoft-Exchange-ActiveMonitoring/ResponderDefinition イベント ログ チャネルです。ThrottlingConfig チャネルの方が、各レスポンダー定義を確認しなくても、グループ化された特定の回復アクションを実行できるすべてのレスポンダーを 1 か所で確認できるので便利です。以下は、ThrottlingConfig イベント ログ チャネルのイベントの例です。

Identity

RestartService/Default/*/*/msexchangefastsearch

RecoveryActionId

RestartService

ResponderCategory

Default

ResponderTypeName

*

ResponderName

*

ResourceName

msexchangefastsearch

PropertiesXml

<ThrottleConfig Enabled="True" LocalMinimumMinutesBetweenAttempts="60" LocalMaximumAllowedAttemptsInOneHour="-1" LocalMaximumAllowedAttemptsInADay="4" GroupMinimumMinutesBetweenAttempts="-1" GroupMaximumAllowedAttemptsInADay="-1" />

スロットリング構成の Identity はその次の 5 つのフィールドが連結されたものであるため、それぞれのフィールドについてご説明します。RecoveryActionId はレスポンダーの調整の種類です。これは、レスポンダー定義の ThrottlePolicyXml プロパティで指定された ThrottleEntries ノードの名前と一致します。ResponderCategory は現時点では未使用で、常に Default と表示されます。ResponderTypeName はレスポンダーの TypeName プロパティであり、ResourceName はレスポンダーの処理対象となるオブジェクトです。この例では、RestartService の回復アクションを使用して MSExchangeFastSearch プロセスを再起動するレスポンダーの調整機能は、サーバーに対して 1 日に最大 4 回の実行を許可しています。ただし、そのサーバーに対してこの回復アクションを再び実行するまでには 60 分以上経過している必要があります。グループ調整機能は使用されていません。

調整による制限を確認するもう 1 つの方法は、Microsoft-Exchange-ActiveMonitoring/ResponderDefinition イベントです。これには、上書きされた内容も含まれます。以下は、ResponderDefinition イベントの ThrottlePolicyXml プロパティの値です。

<ThrottleEntries> <RestartService ResourceName="MSExchangeFastSearch"> <ThrottleConfig Enabled="True" LocalMinimumMinutesBetweenAttempts="60" LocalMaximumAllowedAttemptsInOneHour="-1" LocalMaximumAllowedAttemptsInADay="4" GroupMinimumMinutesBetweenAttempts="-1" GroupMaximumAllowedAttemptsInADay="-1" /> </RestartService> </ThrottleEntries>

これらの属性名と値は ThrottlingConfig イベントの PropertiesXml の値と一致します。

 

調整による制限の変更

場合によっては、回復アクションの発生頻度を変更する必要があります。たとえば、顧客からサービス停止の報告を受けたときに、サービスを再起動すれば修復されるものの制限に引っかかっている場合や、アプリケーション プールのリセットが特に思わしくないサードパーティ製のアプリケーションを使用している場合などが挙げられます。調整機能の設定を変更するには、他の管理可用性の上書きを実行できる Add-ServerMonitoringOverride コマンドレットや Add-GlobalMonitoringOverride コマンドレットを使用します。これらのコマンドレットの使用方法については、管理可用性のカスタマイズ (英語) に関する記事にまとめられています。このコマンドレットでは、調整機能の設定を変更するために PropertyName パラメーターで特殊な構文がサポートされています。XML Blob 全体を指定して上書きする代わりに (この方法でも実行できますが、後から判読しにくくなります)、PropertyName として ThrottleAttributes.LocalMinimumMinutesBetweenAttempts などのプロパティを使用できます。以下はその例です。

Add-GlobalMonitoringOverride -ItemType Responder -Identity Search\SearchIndexFailureRestartSearchService –PropertyName ThrottleAttributes.LocalMinimumMinutesBetweenAttempts -PropertyValue 240 -ApplyVersion "15.00.1044.025"

ActiveSyncSelfTestRestartWebAppPool レスポンダーによるアプリ プールのリセットを許可する頻度を 1 時間に 1 回から 2 時間に 1 回に変更する場合には、以下のコマンドを実行します。

Add-GlobalMonitoringOverride -ItemType Responder -Identity ActiveSync.Protocol\ActiveSyncSelfTestRestartWebAppPool -PropertyName ThrottleAttributes.LocalMinimumMinutesBetweenAttempts -PropertyValue 120 -ApplyVersion “Version 15.0 (Build 1044.25)”

MSExchangeIS サービスがクラッシュし、すべてのサーバーで 1 日に 1 回の頻度で起動できないときに、サーバーを再起動する回復アクションを DAG に対して 60 分に 1 回以上の間隔で実行する場合には、以下のコマンドを実行します。

Add-GlobalMonitoringOverride -ItemType Responder -Identity Store\StoreServiceKillServer -PropertyName ThrottleAttributes.GroupMinimumMinutesBetweenAttempts -PropertyValue 60 -ApplyVersion “15.00.1044.025”
Add-GlobalMonitoringOverride -ItemType Responder -Identity Store\StoreServiceKillServer -PropertyName ThrottleAttributes.GroupMaximumAllowedAttemptsInADay -PropertyValue -1 -ApplyVersion “15.00.1044.025”

LocalMaximumAllowedAttemptsInADay の値が既に 1 に設定されているため、各サーバーは最大でも 1 日に 1 回の頻度で再起動されます。上書きする内容が正確に入力されると、ResponderDefinition イベントの ThrottlePolicyXml の値が更新され、ThrottlingConfig チャネルに新しいエントリが追加されます。

例が少々わかりにくいかもしれませんが、Exchange の開発者は Office 365 で Exchange を運用してきた経験に基づいて調整機能の設定値を選ぶため、適切な例を挙げることは困難です。これらの値をあまり頻繁に変更したいとは思わないでしょうが、通常、モニターや回復アクションを完全に無効化するよりは効果的です。お客様のシナリオにおいて、実際に調整による制限の上書きを実行する必要があった場合は、ぜひこちら (英語) からご意見、ご感想をお聞かせください

Abram Jackson
Exchange Server 担当プログラム マネージャー