Exchange サーバーの再起動を可用性管理の観点で調査する


こんにちは。
Exchange サポートの小間です。

今回は Exchange 2013 の可用性管理について、トラブル シューティング手法を紹介いたします。

先日も可用性管理についてのブログ記事とその翻訳版が公開されました。
Exchange 2013 を運用する上で大変有用な情報ですので、これらの記事は是非ご一読ください。

これらの記事ではレスポンダーによるサービス再起動を主な例に説明をしていますが、皆さまからのお問い合わせの中でより重大な問題となるのが、レスポンダーによるサーバーの強制再起動があります。
ここでは、Exchange 2013 のメールボックス サーバーが予期しない再起動をしていたことを想定して、可用性管理の観点でどのように調査を行うのかを紹介いたします。


はじめに

Exchange 2013 では、可用性管理 (Managed Availability) という機能が追加されました。
この機能では、Exchange サーバーが自分自身を監視し、問題を検知した場合にはサービスを継続して提供するために必要な回復アクションをすべて自動で行います。

これから可用性管理の観点での調査を行うにあたり、最低限の知識としては可用性管理の 3 つのコンポーネントと役割を理解する必要があります。

  •  プローブ
    Exchange サーバーの監視を行います
  •  モニター
    プローブの監視結果を集計します
  •  レスポンダー
    モニターによる集計結果に基づき、回復アクションやエスカレーションを行います

より詳しくは TechNet をご参照ください。

TITLE: 可用性管理
URL: https://technet.microsoft.com/ja-jp/library/dn482056(v=exchg.150).aspx


ステップ 1 – Exchange サーバーが再起動していたことを確認する

サーバーの監視ツールなどで Exchange サーバーが再起動していたことを確認します。
場合によっては、ブルー スクリーンが発生している状況を目撃するかもしれません。


ステップ 2 – RecoveryActionResults ログを確認する

予期せぬ再起動が発生している状況なので、ダンプが出力されている場合はダンプ解析をすることはもちろん有効ですが、一般的に可用性管理の機能で問題が発生している場合は MSExchangeHMWorker.exe が wininit.exe を終了したことくらいしか分かりません。
まずはどのレスポンダーがサーバーを再起動したのかを確認するため、RecoveryActionResults ログを確認します。

次のステップで紹介する ProbeResult ログなどを含む可用性管理に関するログは、大量に出力されますので事象発生から時間が経ってしまっていると既にログが残っていない場合があります。
そのため、問題が発生したら早めにログを確認・保存することをお勧めします。

RecoveryActionResults ログは、イベント ビューアーの [アプリケーションとサービス ログ] – [Microsoft] – [Exchange] – [ManagedAvailability] 以下に保存されています。
今回はサーバー再起動の後のタイミングで以下のログが記録されていました。

ActionId が ForceReboot となっていますので、サーバーの強制再起動が行われたことが分かります。
Requester は StoreServiceKillServer となっていますが、これがサーバーを再起動したレスポンダーの名前です。
名前から判断して、Microsoft Exchange インフォメーション ストア サービスが関連していそうなことが感じ取れます。

監視結果に問題があったためにレスポンダーが動作している状況になりますが、これだけの情報では何が問題だったかの根本原因は分かりません。
しかし場合によっては、原因追求よりもサーバー再起動をしないようにすることの方が重要なこともあります。そのような場合は、レスポンダーを個別に無効にできます。
スッテプ 3 に進む前に、レスポンダーを無効にする方法を確認したいと思います。


レスポンダーを無効にする

レスポンダーを無効にするには、レスポンダーの Identity (フル ネーム) が必要です。先ほど確認した StoreServiceKillServer だけでは足りません。
レスポンダーの Identity は、レスポンダーの定義から確認することができます。以下のようにコマンドを実行します。

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/responderdefinition | % {[XML]$_.toXml()}).Event.UserData.EventXml | ?{$_.Name -like “<レスポンダー>”} | fl ServiceName,Name,Enabled

例) コマンドを実行しているサーバーで StoreServiceKillServer の定義を確認する
(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/responderdefinition | % {[XML]$_.toXml()}).Event.UserData.EventXml | ?{$_.Name -like “StoreServiceKillServer”} | fl ServiceName,Name,Enabled

ServiceName と Name の組み合わせが、レスポンダーの Identity です。Enable はレスポンダーが有効か無効かを示しており、1 は有効となります。
これで準備が整ったのでレスポンダーを無効にしたいのですが、組織全体で無効にするか、サーバー単位で無効にするかで、使用するコマンドが変わります。

特定のレスポンダーを組織全体で無効にする場合は、以下のコマンドを実行します。

Add-GlobalMonitoringOverride -Identity <ServiceName>\<Name> -ItemType Responder -PropertyName Enabled -PropertyValue 0 -ApplyVersion “<Exchange サーバーのバージョン番号>”

例) 組織全体で Exchange 2013 CU8 の StoreServiceKillServer を無効にする
Add-GlobalMonitoringOverride -Identity Store\StoreServiceKillServer -ItemType Responder -PropertyName Enabled -PropertyValue 0 -ApplyVersion “15.0.1076.9”

組織全体で無効にしたレスポンダーを有効にする場合は、以下のコマンドを実行します。

Remove-GlobalMonitoringOverride -Identity <ServiceName>\<Name> -ItemType Responder -PropertyName Enabled

例) 無効にした StoreServiceKillServer を有効にする
Remove-GlobalMonitoringOverride -Identity Store\StoreServiceKillServer -ItemType Responder -PropertyName Enabled

特定のレスポンダーをサーバー単位で無効にする場合は、以下のコマンドを実行します。

Add-ServerMonitoringOverride -Identity <ServiceName>\<Name> -ItemType Responder -PropertyName Enabled -PropertyValue 0 -ApplyVersion “<Exchange サーバーのバージョン番号>” -Server <無効にするサーバー名>

例) 特定の Exchange 2013 CU8 サーバーの StoreServiceKillServer を無効にする
Add-ServerMonitoringOverride -Identity Store\StoreServiceKillServer -ItemType Responder -PropertyName Enabled -PropertyValue 0 -ApplyVersion “15.0.1076.9” -Server MBX03

特定のサーバーで無効にしたレスポンダーを有効にする場合は、以下のコマンドを実行します。

Remove-ServerMonitoringOverride -Identity <ServiceName>\<Name> -ItemType Responder -PropertyName Enabled -Server <有効にするサーバー名>

例)
Remove-ServerMonitoringOverride -Identity Store\StoreServiceKillServer -ItemType Responder -PropertyName Enabled -Server MBX03

なお、上記コマンドで指定している 15.0.1076.9 というバージョン番号は、Exchange 2013 CU8 のバージョン番号です。
CU の適用によってバージョンが変わった場合は、バージョンアップ後のバージョン番号を指定してコマンドを再度実行する必要があります。
指定するバージョン番号は以下のコマンドで確認できます。

$serverVersion = (Get-ExchangeServer $env:computername).AdminDisplayVersion
$serverVersion.Major.ToString() + “.” + $serverVersion.Minor.ToString() + “.” + $serverVersion.Build.ToString() + “.” + $serverVersion.Revision.ToString()

レスポンダーが無効化されたかどうかは、先ほどのレスポンダーの定義を確認したコマンドを再実行することで確認できます。
Enabled が 0 になっていれば無効化されています。

無効化の設定を行うことでレスポンダーの再定義が行われますが、再定義には環境によって数分から数十分程度の時間がかかりますので、すぐに無効化されたことを確認できない場合があります。
再定義中は Enabled が 1 のままだったり、コマンドの結果が出力されなかったり、コマンド自体がエラーになる場合があります。
その場合は時間をおいて再度確認してください。


なお、可用性管理によってサーバーの再起動が行われるような状況になっている場合、複数のレスポンダーがサーバーの再起動を試行していることも考えられます。
そのため 1 つのレスポンダーを無効にしても、他のレスポンダーによって再起動が実行される可能性があります。


ステップ 3 – ProbeResult ログを確認する

先にレスポンダーを無効にする方法を紹介しましたが、多くの Exchange サーバーの管理者の方は根本原因を追求したいと思われるでしょう。
そのような時は、ProbeResult ログを調査することで可用性管理の機能による監視結果を確認することができます。

ProbeResult ログは、イベント ビューアーの [アプリケーションとサービス ログ] – [Microsoft] – [Exchange] – [ActiveMonitoring] 以下に保存されています。
今回は以下のログが記録されていました。

詳細を表示すると「MSExchangeIS service is not running」となっていますので、Microsoft Exchange インフォメーション ストア サービスが起動していないようです。
「StoreServiceProbe/MSExchangeIS」とも記載されているので、このプローブはサービスが起動しているかどうかを監視しているものと考えられます。
ここまでの調査結果をまとめると、Microsoft Exchange インフォメーション ストア サービスが起動していないために、対処としてサーバー再起動が実行されたということになります。


ステップ 4 – 問題に対処する

サーバー再起動によってサービスが起動するようになれば、可用性管理の動作としては大成功です。
もしもサーバー再起動後もまだサービスが起動していない場合は、手動でサービスを起動できるか確認する必要があります。

なぜサービスが起動していなかったのかを調べたい場合や、手動でもサービスが起動していない場合は、サービスに何が起きているのかを調べる必要があります。
その内容は今回の趣旨とは異なりますので割愛します。
参考までに、今回はデモのために Microsoft Exchange インフォメーション サービスを停止して無効にしていました。


おわりに

可用性管理のトラブル シューティング手法を紹介しましたが、今回は概要をお伝えするために多くの内容を省略しています。
例えば、プローブがエラーになったからと言ってすぐにサービスの再起動が行われるわけではありません。

今回のデモでは確認していませんが、実際にはサーバー再起動が行われる前にまずはサービスの再起動が行われています。
サービスの再起動も、監視結果が何回か連続して失敗している状況でなければ実行しないなど、可用性管理では監視結果を集計して回復アクションを実行します。
サーバーの再起動が行われるのは最後の手段です。

また、今回はイベント ログを用いた方法を紹介しましたが、紹介していない他のイベント ログを含め、可用性管理に関する多くの情報がイベント ログには記録されています。
Exchange 管理シェルにもコマンドが用意されていますので、それらはまた別の機会の紹介したいと思います。

多くの管理者の方は、意図しないところでサービスやサーバーの再起動が行われることを製品の問題であると考えるでしょう。
しかし実際には、可用性管理の機能によって、Exchange サーバー自身が可用性を向上しようとした結果である可能性が大いにあります。

可用性管理の機能は Office 365 での経験を基に設計されているので、必ずしもお客様の環境には合わない監視項目があるかもしれませんが、まずは今回ご紹介したような方法で調査を行ってみることをお勧めいたします。

今後も当ブログおよびサポート チームをよろしくお願いいたします。


Skip to main content