Partager via

データセンターから学んだこと: 管理可用性

  • Article

原文の記事の投稿日: 2012 年 9 月 22 日 (土曜日)

Exchange 展開を成功させるうえで監視機能は重要な要素です。これまでのリリースでは、相関エンジンの開発に力を入れ、System Center Operations Manager (SCOM) 製品グループと密接に協力することによって、Exchange 環境に包括的なアラート ソリューションを提供してきました。

従来から、監視機能の役割は、データを収集し、収集したデータに基づいて必要に応じたアクションを実行することです。たとえば、SCOM のコンテキストにおいては、Exchange 管理パックでデータを収集するために次の各種メカニズムを採用してしていました。

監視の種類 Exchange 2010
実行されていないサービス 正常性マニフェスト ルール
パフォーマンス カウンター 正常性マニフェスト カウンター ルール
Exchange のイベント 正常性マニフェスト イベント ルール
Exchange 以外のイベント 正常性マニフェスト イベント ルール
スクリプト、コマンドレット 正常性マニフェスト スクリプト ルール
Test コマンドレット Test コマンドレット

Exchange Server 2013 の監視機能の目標

Exchange 2013 の開発開始時の重要課題の 1 つは、あらゆる Exchange 展開 (小規模な内部設置型展開から Office 365 という世界最大規模のものまで) を対象にエンド ツー エンドの監視機能を向上させることでした。そこで次の 3 つの目標を想定しました。

  1. Office 365 サービスで培った知識と経験を内部設置型展開のユーザーに活用すること  Exchange 製品グループはおよそ 6 年間 Exchange Online を運用してきました。採用している運用モデルをデベロッパー オペレーション モデル (DevOps) といいます。このモデルでは、サービス内で正常に動作していない機能があったり、ユーザーから未知の問題が報告されたりすると、その機能の開発者に直接問題がエスカレートされます。問題の原因が何であれ、開発者に直接エスカレートしてソフトウェアの問題を解決することによって、ソフトウェア開発のアカウンタビリティを確保しています。

    このモデルを採用した結果、多くのことを学びました。たとえば、Exchange 2010 管理パックには約 1100 個のアラートがあります。ところが、何年かするうちに、それらのアラートのうち Office 365 で役に立つのは 150 個程度だということがわかりました (そこでそれ以外は無効にしています)。また、開発者はエスカレーションを受けると、(コード修正、新しい回復ワークフロー、アラートの微調整などによって) 一層問題解決に取り組む傾向にあることもわかりました。同じ問題のトラブルシューティングのために何度も作業を中断したり、呼び出されたりしたくないからです。DevOps モデルには、毎週、前の週に発生した問題を待機担当者に申し送りするプロセスがあります。その結果、IIS アプリケーション プールのリセットなどを行う自社用回復ワークフローが開発されました。Exchange 2013 以前は、このような回復ワークフローを独自の自社用エンジンで処理していました。この知識は内部設置型製品に活用されていませんでした。Exchange 2013 では、回復ワークフロー エンジンをコンポーネント化し、判明した情報を内部設置型製品のユーザーと共有できるようにしました。

  2. エンド ユーザー エクスペリエンスに基づく監視  監視に使用してきた多くの手法が環境の運用にあまり有効ではないこともわかりました。そこで、ユーザー中心の視点に基づいた監視アプローチへシフトしています。

    過去のリリースでは、各コンポーネント チームがそれぞれのシステムのさまざまなコンポーネントを統合して正常性モデルを開発していました。たとえば、トランスポートは SMTP-IN、SMTP-OUT、トランスポート エージェント、カテゴライザー、ルーティング エンジン、ストア ドライバーなどで構成されています。コンポーネント チームはこのようなコンポーネントそれぞれに関するアラートを作成しました。こうして管理パックにはストア ドライバーが失敗したことを知らせるアラートが含まれます。しかし、そのようなアラートには、エンド ツー エンドのユーザー エクスペリエンスに関する情報やそのエクスペリエンスにどんな不具合があるかという情報が不足していました。そこで Exchange 2013 では、このモデルを逆転させてみました。システム レベルの監視は重要なので残します。ただし、サービスの管理において最も重要なのは、ユーザーにとってどんなことが起こっているかです。そのため、モデルを逆転させて、ユーザー エクスペリエンスを監視することを目指しています。

  3. ユーザー エクスペリエンスを保護する回復重視のコンピューティング  過去の Exchange リリースでは、監視する対象はシステムとコンポーネントにあり、エンド ユーザー エクスペリエンスを自動的に回復および復元する方法ではありませんでした。

Exchange Server 2013 の監視機能 - 管理可用性

管理可用性は、Exchange の高可用性ソリューションに組み込まれた監視と回復のインフラストラクチャです。問題が発生して発見されると、管理可用性がそれを検出して回復します。

管理可用性はユーザー中心の機能です。主な評価対象として、可用性、エクスペリエンス (ほとんどのクライアント プロトコルでは待機時間として測定されます)、エラーの有無の 3 つがあります。これら 3 つの側面を理解するために、Outlook Web App (OWA) を使用しているユーザーの例で考えてみましょう。

この場合の可用性は、単にユーザーが OWA フォーム ベース認証 Web ページにアクセスできるかどうかです。できない場合、エクスペリエンスに不具合があるので、ヘルプデスクへのエスカレーションが生成されます。エクスペリエンスは、ユーザーが OWA にログインできる場合のエクスペリエンスの状況であり、たとえば、インターフェイスは読み込まれるか、ユーザーがメールにアクセスできるか、などです。最後の側面である待機時間は、ユーザーがログインでき、インターフェイスにアクセスできるとして、ブラウザーにメールが表示されるのにどれくらい時間がかかるかで評価されます。エンド ユーザー エクスペリエンスはこれらの側面で成り立っています。

Exchange 2013 が従来のリリースと大きく違う点の 1 つは、Exchange 2013 の監視ソリューションは問題の根本原因を知らせることを目的としない点です (だからといって、データがログに記録されなかったり、ダンプが生成されなかったり、根本原因を検出できなかったりするわけではありません)。重要なのは、従来のリリースでは根本原因を効果的に "伝える"ことができなかった点です。的確な場合もありましたが、的確でない場合も多かったのです。

管理可用性のコンポーネント

Exchange 2013 では、サーバーの役割に管理可用性が組み込まれています。これには 3 つの主要な非同期コンポーネントが含まれます。1 つ目のコンポーネントは "プローブ エンジン"です。プローブ エンジンはサーバーを監視します。その情報は 2 つ目のコンポーネント "モニター"へ送られます。モニターには、正常と判断される項目をエンコードしたビジネス ロジックが含まれています。これはパターン認識エンジンと見なすこともでき、さまざまな測定項目のさまざまなパターンを監視して正常かどうかの判断を行います。3 つ目のコンポーネントは "レスポンダー エンジン"であり、次の図の「回復 (Recover)」の部分に相当します。異常が検出された場合、最初のアクションはそのコンポーネントを回復しようとすることです。管理可用性は、複数の段階で回復アクションを実行します。たとえば、第 1 段階ではアプリケーション プールの再開を試行し、第 2 段階ではサービスの再開を試行し、第 3 段階ではサーバーの再起動を試行し、最終段階ではサーバーをオフラインにしてそれ以上トラフィックを受け入れないようにします。これらのアクションがすべて失敗すると、管理可用性はイベント ログ通知によって問題を人的対応へエスカレートします。

また、いくつかの機能が分散化されました。これまでは、各サーバーに SCOM エージェントを配置し、すべての測定項目を中央の SCOM サーバーへ送っていました。SCOM サーバーではすべての測定項目を評価して正常かどうかを判断する必要がありました。大規模な環境では、複雑な相関関係の処理が集中します。そのため、アラートの発行に時間がかかるなどの影響がありました。1 つの場所にすべてを集中させると非効率的です。そこで個々のサーバーに島のような役割を持たせ、それぞれのサーバーがそれぞれのプローブを実行し、自己監視し、自己回復アクションを実行し、必要に応じてエスカレートするようにしました。

ma1
図 1: 管理可用性のコンポーネント

 

プローブ

プローブ インフラストラクチャは次の 3 つのフレームワークで構成されます。

  1. プローブは、各コンポーネント チームによって構築された "代理トランザクション"です。これらは過去のリリースの test コマンドレットに似ています。プローブは代理エンド ツー エンド ユーザー トランザクションを実行することによってサービスの状態を測定します。
  2. チェックは受動的監視メカニズムです。実際のユーザー トラフィックを測定します。
  3. 通知フレームワークでは、プローブの実行を待たずに即座にアクションを実行できます。これによって、問題を検知したらすぐに対応できます。通知フレームワークは通知ベースです。たとえば、証明書が期限切れになる場合、通知イベントが発行され、証明書の更新が必要であることが通知されます。

モニター

プローブで収集されたデータはモニターへ送られます。プローブとモニターは必ずしも 1 対 1 で対応するものではなく、多数のプローブから 1 つのモニターへ送られるデータもあります。モニターはプローブの結果を確認して結論を導き出します。この結論は正常か正常でないかの二者択一です。

前述のとおり、Exchange 2013 の監視機能はエンド ユーザー エクスペリエンスを中心にしています。これを実現するには環境内の各層を監視する必要があります。

ma2
図 2: ユーザー エクスペリエンスをチェックするための各層の監視

 

この図が示すとおり、4 種類のチェックを行っています。1 番目のチェックはメールボックスの自己テストです。このプローブは、ローカル プロトコルまたはインターフェイスがデータベースにアクセスできるかどうかを確認します。2 番目のチェックはプロトコルの自己テストです。メールボックス サーバーのローカル プロトコルの動作を確認します。3 番目のチェックはプロキシの自己テストです。クライアント アクセス サーバーで実行され、プロトコルのプロキシ機能の動作を確認します。最後の 4 番目のチェックはエンド ツー エンド エクスペリエンスを総合的に (プロトコル プロキシから格納機能まで) 確認します。各チェックはそれぞれ異なる間隔で検出を実行します。

各層の監視では依存関係も処理します。Exchange 2013 には相関エンジンがないので、プローブごとの一意のエラー コードと依存関係に関与しないプローブを使用して依存関係を見分けます。たとえば、メールボックスの自己テストとプロトコルの自己テストが両方同時に失敗したとします。これはストアがダウンしていることを意味するでしょうか。必ずしもそうではありません。この場合、メールボックス サーバーのローカル プロトコル インスタンスに不具合があることを示しています。では、プロトコルの自己テストは正常で、メールボックスの自己テストが失敗する場合はどうでしょうか。この場合は "格納" 層に問題があることを示しており、ストアまたはデータベースがオフラインである可能性があります。

監視の観点から見ると、これによってアラート発行の対象を細かく制御できるようになりました。たとえば、OWA の正常性を評価する場合、メールボックスの自己テストは失敗してもプロトコルの自己テストが正常な場合はアラートの発行を延期し、メールボックスの自己テストとプロトコルの自己テストの両方のモニターが正常でない場合にアラートを発行するようにできます。

レスポンダー

レスポンダーは、モニターから生成されるアラートに基づいて応答を実行します。モニターで異常が検出されない限り、レスポンダーは実行しません。

さまざまな種類のレスポンダーがあります。

  • 再開レスポンダー  サービスを終了して再開します。
  • アプリケーション プール リセット レスポンダー  IIS アプリケーション プールをリサイクルします。
  • フェールオーバー レスポンダー  Exchange 2013 メールボックス サーバーをサービス停止にします。
  • バグ チェック レスポンダー  サーバーのバグ チェックを開始します。
  • オフライン レスポンダー  コンピューターのプロトコルをサービス停止にします。
  • エスカレート レスポンダー  問題をエスカレートします。
  • 専用コンポーネント レスポンダー 

オフライン レスポンダーは、クライアント アクセス サーバーからプロトコルの使用を削除するために使用します。このレスポンダーは、ロード バランサーの対象外になるように設計されています。このレスポンダーが呼び出されると、そのプロトコルはロード バランサーの正常性チェックに応答しなくなるので、ロード バランサーは負荷分散プールからそのサーバーまたはプロトコルを削除できます。これと対応するオンライン レスポンダーもあります。オンライン レスポンダーは、対応するモニターが正常に戻ると (関連する他のモニターが異常を示していない限り) 自動的に呼び出されます。オンライン レスポンダーは、単にプロトコルがロード バランサーの正常性チェックに応答するようにします。その結果、ロード バランサーはそのサーバーまたはプロトコルをロード バランサー プールに追加できるようになります。オフライン レスポンダーは、Set-ServerComponentState コマンドレットを使用して手動で呼び出すこともできます。管理者はこれを使用して、クライアント アクセス サーバーを手動でメンテナンス モードにできます。

エスカレート レスポンダーが呼び出されると、Exchange 2013 管理パックで検出できる Windows イベントが生成されます。これは、通常の Exchange イベントとは異なります。OWA の不具合やハードウェア I/O の発生を示すイベントではありません。この Exchange イベントは、正常性セットが正常な場合とそうでない場合があります。このようなシングル インスタンス イベントは、SCOM 内のモニターを操作するために使用します。この操作は、製品全体のいろいろな場所で発生するイベントではなく、エスカレート レスポンダー内で生成されるイベントに基づいて行います。別の見方をすれば、間接的なレベルの操作です。管理可用性は、SCOM 内のモニターをオンにするタイミングを決定します。管理可用性は、どのような場合にエスカレーションを行うか、つまり、どのような場合に人的対応を要するかを決定します。

レスポンダーは、サービス全体に異常がないことを確認できるように調整することもできます。調整機能はレスポンダーごとに異なります。

  • 一部のレスポンダーは、DAG または負荷分散 CAS プール内のサーバーの最小数に対応できます。
  • 一部のレスポンダーは、実行の時間間隔に対応できます。
  • 一部のレスポンダーは、レスポンダーが開始された回数に対応できます。
  • これらの組み合わせに対応できるものもあります。

レスポンダーによっては、調整時にレスポンダーのアクションが遅延したり、スキップされたりする場合があります。

回復シーケンス

モニターでは実行するレスポンダーの種類とそれを実行するタイムラインを定義するという点が重要です。これをモニターの回復シーケンスといいます。たとえば、OWA プロトコルのプローブ データ (プロトコルの自己テスト) によってモニターで異常が検出されたとします。この時点で、現在時刻が保存されます (これを T とします)。モニターは現在時刻に基づく回復パイプラインを開始します。モニターでは、回復パイプライン内に名前付き時間間隔で回復アクションを定義できます。メールボックス サーバーの OWA プロトコル モニターの場合、次のような回復シーケンスになります。

  1. T=0 の時点で、IIS アプリケーション プール リセット レスポンダーが実行されます。
  2. T=5 分の時点でモニターが正常に戻っていない場合、フェールオーバー レスポンダーが開始され、データベースがサーバーから移動されます。
  3. T=8 分の時点でモニターが正常に戻っていない場合、バグ チェック レスポンダーが開始され、サーバーが強制的に再起動されます。
  4. T=15 分の時点でモニターがまだ正常に戻っていない場合、エスカレート レスポンダーが開始されます。

回復シーケンス パイプラインは、モニターが正常になると終了します。次の名前付き時間アクションを開始する前に前の名前付き時間アクションが完了している必要はありません。また、1 つのモニターに複数の名前付き時間間隔を指定できます。

Systems Center Operations Manager (SCOM)

Systems Center Operations Manager (SCOM) は、Exchange 環境関連の正常性情報を確認するポータルとして使用します。エスカレート レスポンダーでアプリケーション ログにイベントが書き込まれると、SCOM ポータル内で異常が検出されます。SCOM ダッシュボードが改良され、次の 3 つの領域が用意されました。

  • アクティブ アラート
  • 組織の正常性
  • サーバーの正常性

Exchange Server 2013 SCOM 管理パックは、SCOM 2007 R2 と SCOM 2012 についてもサポートされる予定です。

オーバーライド

どのような環境でも既定値が最適な状態とは限らず、緊急アクションが必要な状況が存在する場合もあります。管理可用性には、環境全体またはサーバーごとにオーバーライドを有効にできる機能が含まれています。各オーバーライドは、指定期間内に設定することも、特定のバージョンのサーバーに適用することもできます。*-ServerMonitoringOverride コマンドレットと *-GlobalMonitoringOverride コマンドレットを使用すると、管理者はオーバーライドを設定、削除、表示できます。

正常性の判断

特定のコンポーネントのアーキテクチャと類似または関連しているモニターは、正常性セットとしてグループ化されます。正常性セットの正常性は、正常性セット内で評価が "最も悪い" モニターによって常に判断されます。たとえば、ある正常性セット内に 9 個のモニターがあってそのうちの 1 個が異常を示していれば、その正常性セットは異常と見なされます。特定の正常性セット内のモニター (および関連するプローブとレスポンダー) のコレクションは、Get-MonitoringItemIdentity コマンドレットを使用して確認できます。

正常性を確認するには、Get-ServerHealth コマンドレットと Get-HealthReport コマンドレットを使用します。Get-ServerHealth が正常性の生データを取得するのに対し、Get-HealthReport は正常性の生データを使用して現在の正常性のスナップショットを提供します。これらのコマンドレットは各層で実行できます。

  • 特定のサーバーの正常性を正常性セットごとに分割して表示できます。
  • 特定の正常性セットについてモニターごとの状態を確認できます。
  • 特定のサーバー セット (DAG メンバー、負荷分散 CAS アレイなど) の正常性の概要を表示できます

正常性セットは、さらに正常性グループという機能単位にグループ化されます。4 つの正常性グループがあり、SCOM 管理ポータル内のレポートに使用されます。

  1. カスタマー タッチ ポイント - 直接的なリアルタイムのユーザー操作を伴うコンポーネント (OWA など)。
  2. サービス コンポーネント - 直接的なリアルタイムのユーザー操作を伴わないコンポーネント (OAB の生成など)。
  3. サーバー コンポーネント - サーバーの物理的リソース (ディスク、メモリーなど)。
  4. 依存関係可用性 - 依存関係に対応するサーバーの能力 (Active Directory など)。

まとめ

管理可用性は各サーバー内でさまざまな正常性評価を実行します。これらの定期的なテストは、サーバー上の各種コンポーネントの正常性を確認し、それによってユーザー ロード前またはその間にサーバー (またはサーバー セット) の正常性を確立します。問題が検出されると、サーバーを正常な状態へ戻すための複数段階の是正措置が実行されます。サーバーが正常な状態に戻らない場合は、管理可用性からオペレーターへ注意を喚起するアラートを発行できます。

最終的に、管理可用性はユーザー エクスペリエンスを重視するものであり、問題が発生してエクスペリエンスに影響が出るとしても、それを最小限に抑えます。

Ross Smith IV 主席プログラム マネージャー Exchange カスタマー エクスペリエンス

  

Greg "Exchange 高可用性の主神" Thiel 主席プログラム マネージャー アーキテクトExchange Server

これはローカライズされたブログ投稿です。原文の記事は、「Lessons from the Datacenter: Managed Availability」を参照してください。