アクティブ マネージャーについて
適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3
トピックの最終更新日: 2015-03-09
Microsoft Exchange Server 2010 には、アクティブ マネージャー と呼ばれる新しいコンポーネントが備わっており、Exchange の以前のバージョンでクラスター サービスとの統合によって提供されていたリソース モデルとフェールオーバー管理機能に代わる機能を提供します。Exchange では、高可用性に対してクラスター リソース モデルが使用されなくなりました。クラスター化メールボックス サーバーとして知られている構成要素など、exres.dll によって提供されていたすべての Exchange クラスター リソースは存在しなくなりました。Exchange では、Windows フェールオーバー クラスターが使用されますが、Exchange にはクラスター グループはありません。また、クラスター内に記憶域リソースはありません。そのため、クラスター管理ツールを使用してクラスターを確認する場合、中核となるクラスター リソース (IP アドレス、ネットワーク名、および必要があればクォーラム リソース) のみ表示されます。クラスター ノードとネットワークも存在しますが、これらは、クラスターまたはクラスター ツールではなく、Exchange によって管理されます。
アクティブ マネージャーは役割として、すべてのメールボックス サーバー上で実行されます。高可用性の構成がされていないメールボックス サーバーでは、アクティブ マネージャーの役割は、スダンドアロン アクティブ マネージャーの 1 つのみです。データベース可用性グループ (DAG) のメンバーであるサーバーでは、アクティブ マネージャーの役割は、プライマリ アクティブ マネージャー (PAM) とスタンバイ アクティブ マネージャー (SAM) の 2 つがあります。PAM は、DAG 内のアクティブ マネージャーで、どのコピーをアクティブまたはパッシブにするのかを決定します。PAM は、トポロジの変更通知を取得し、サーバーの障害に対応します。PAM 役割を持つ DAG メンバーは、必ずクラスターのクォーラム リソース (既定のクラスター グループ) を現在所有しているメンバーです。クラスターのクォーラム リソースを所有するサーバーに障害が発生すると、PAM 役割は、自動的に存続しているサーバーに移動し、存続しているサーバーがクラスターのクォーラム リソースの所有権を取得します。また、保守やアップグレードのために、クラスターのクォーラム リソースをホストするサーバーをオフラインにする必要がある場合は、まず、PAM を DAG の別のサーバーに移動する必要があります。PAM は、データベース コピー間でのアクティブの指定の移動をすべて制御します (特定のタイミングでは、1 つのコピーのみアクティブにすることが可能で、そのコピーはマウントまたはマウント解除が可能です)。PAM は、ローカル データベースの障害およびローカル インフォメーション ストアの障害の検出といった、ローカル システム上の SAM 役割の機能も実行します。
SAM は、RPC クライアント アクセス サービスまたはハブ トランスポート サーバーなどのアクティブ マネージャー クライアント コンポーネントを実行している他の Exchange のコンポーネントに、どのサーバーがメールボックス データベースのアクティブ コピーをホストするかについての情報を提供します。SAM は、ローカル データベースおよびローカル インフォメーション ストアの障害を検出します。データベースがレプリケートされている場合は、PAM にフェールオーバーを開始するよう要求し、障害に対応します。SAM は、フェールオーバーのターゲットを決定しません。また、PAM 内のデータベースの場所の状態を更新することもしません。アクティブなデータベース コピーの場所の状態にアクセスして、受信したデータベースのアクティブ コピーについてのクエリに応答します。
注意
Exchange 2010 は、クラスター化されたアプリケーションではありません。代わりに、クラスター、グループ、クラスター ネットワーク (ハートビート)、ノード管理、クラスター レジストリ、およびいくつかの制御コード関数のために、clusapi.dll に実装されたクラスター ライブラリ関数を使用します。さらに、アクティブ マネージャーは、アクティブ データとパッシブ データ、およびマウントされたデータなど、クラスター データベース内の現在のメールボックス データベース情報を格納します。情報は直接クラスター データベースに格納されますが、その他のコンポーネントによって直接アクセスされることはありません。
Exchange 2010 では、Microsoft Exchange レプリケーション サービスは定期的にすべてのマウントされたデータベースの状態を監視します。また、I/O エラーや障害がないか、Extensible Storage Engine (ESE) も監視します。このサービスで障害を検出すると、アクティブ マネージャーに通知されます。その後、アクティブ マネージャーは、マウントする必要があるデータベース コピーと、アクティブ マネージャーがそのデータベースのマウントに必要とする機能を決定します。さらに、最後にマウントされたデータベースのコピーに基づいて、メールボックス データベースのアクティブ コピーを追跡し、追跡結果の情報をクライアントの接続先のクライアント アクセス サーバー上にある RPC クライアント アクセス コンポーネントに提供します。
アクティブ マネージャーの最適なコピーの選択
レプリケートされたメールボックス データベースに影響する障害が発生したとき、アクティブ マネージャーは複数のステップによって、障害が発生したデータベースのコピーからアクティブ化するための最適なコピーを選択し、障害から回復します。この通常のプロセスは、次の順序で発生します。
アクティブ マネージャーが障害を検出します。
PAM が、最適なコピーの選択 (BCS) と呼ばれる内部アルゴリズムを実行します。
最終ログからのコピーの試行 (ACLL) と呼ばれるプロセスが実行されます。これにより、フェールオーバーの前に、アクティブなデータベース コピーをホストしていたサーバーから、不足しているログ ファイルのコピーを試みます。
ACLL プロセスが完了すれば、PAM はリモート プロシージャ コール (RPC) 経由で、Microsoft Exchange Information Store に対してマウント要求を発行します。この時点で、以下のいずれかの状態となります。
データベースがマウントされ、クライアントが利用できる状態になります。
データベースがマウントされず、PAM が次に最適なコピーがあれば、それに対してステップ 3 および 4 を実行します。
PAM は、最適なコピーを検索するときに、別々の条件セットを最大 10 個まで使用し、アクティブ化する最適なコピーを決定します。最適なコピーを見つけた後に、ACLL が実行されます。ACLL プロセスの完了後、不足しているログ ファイルがすべて以前のアクティブ コピーからコピーされた場合は、データベースはデータを消失することなくマウントされます。これは、ロスレス フェールオーバーと呼ばれます。ACLL プロセスが失敗した場合は、AutoDatabaseMountDial の設定値を参照します。AutoDatabaseMountDial の詳細については、「Set-MailboxServer」を参照してください。消失ログの数が、AutoDatabaseMountDial の構成値の範囲内であれば、データベースはマウントされます。消失ログの数が、AutoDatabaseMountDial の構成値の範囲外であれば、消失したログ ファイルが回復されるまで、または、管理者が明示的にデータベースをマウントして消失するデータが増えることを受け入れるまで、データベースはマウントされません。データベースが自動的にマウントされない場合、PAM は次に最適なコピーが利用できればそれを選択します。最初に選択されたデータベース コピーが自動的にマウントされない理由は、少なくとも 3 つあります。
不足しているログ ファイルの数が、AutoDatabaseMountDial に構成された値よりも大きい。
マウントが試行されたサーバーに対して、アクティブなデータベース数のソフト最大値が構成されており、アクティブなデータベース コピーの数がサーバー上でその最大数に達していた。
データベース コピーがアクティブ化を中断されている。
最適なコピー選択プロセス
アクティブ マネージャーは、アクティブ化の候補となる可能性のあるデータベース コピーの一覧を作成して、最適なコピー選択プロセスを開始します。到達できないデータベース コピーや、(Set-MailboxServer コマンドレットの DatabaseCopyAutoActivationPolicy プロパティを使用して) 管理者によりアクティブ化をブロックされているデータベース コピーは無視され、選択プロセスでは使用されません。この一覧の順序は、Exchange 2010 のバージョンによって異なります。
Exchange 2010 の RTM (Release to Manufacturing) 版では、アクティブ マネージャーは、コピー キューの長さを主キーとして使用し、結果の一覧を並べ替えます。この計算は (コピーの観点からは) LastLogInspected に基づいています。このため、候補のコピーの一覧は、LastLogInspected の値が最も大きいもの (コピー キューの長さが最小のコピー) から順に並べ替えられます。この後、アクティブ マネージャーは ActivationPreference の値を 2 次キーとして使用し、この一覧の 2 回目の並べ替えを実行します。ActivationPreference の値が最も小さいコピーが、一覧でより上位の優先順位となります。
Exchange 2010 Service Pack 1 (SP1) では、この動作は RTM 版とほぼ同じですが、自動データベース マウント ダイヤルの値が "ロスレス" に構成されているサーバーでは異なります。ロスレス設定が使用されていると、アクティブ マネージャーは ActivationPreference の値を主キーとして使用し、結果の一覧を昇順に並べ替えます。この動作は仕様であり、切り替えや StartDagServerMaintenance.ps1 実行時などの移動操作によって、データベースの不均衡を最小限に抑えることを目的としています。
次に、アクティブ マネージャーは、状態が Healthy、DisconnectedAndHealthy、DisconnectedAndResynchronizing、または SeedingSource のメールボックス データベース コピーを一覧から探し、順序に関する 10 個の条件セットを使用して、一覧上の各コピーがアクティブ化できるかどうかを評価します。アクティブ マネージャーは、アクティブ化の候補が次の 1 番目の条件セットに合うどうかを判断します。
Healthy 状態のコンテンツのインデックスを持っている。
コピー キューの長さが 10 ログ ファイル未満。
再生キューの長さが 50 ログ ファイル未満。
この 1 番目の条件セットに合うデータベース コピーがない場合は、アクティブ マネージャーは次の 2 番目の条件セットに合うデータベース コピーを探します。
クロール状態のコンテンツのインデックスを持っている。
コピー キューの長さが 10 ログ ファイル未満。
再生キューの長さが 50 ログ ファイル未満。
この 2 番目の条件セットに合うデータベース コピーがない場合は、アクティブ マネージャーは次の 3 番目の条件セットに合うデータベース コピーを探します。
Healthy 状態のコンテンツのインデックスを持っている。
再生キューの長さが 50 ログ ファイル未満。
この 3 番目の条件セットに合うデータベース コピーがない場合は、アクティブ マネージャーは次の 4 番目の条件セットに合うデータベース コピーを探します。
クロール状態のコンテンツのインデックスを持っている。
再生キューの長さが 50 ログ ファイル未満。
この 4 番目の条件セットに合うデータベース コピーがない場合は、アクティブ マネージャーは次の 5 番目の条件セットに合うデータベース コピーを探します。
- 再生キューの長さが 50 ログ ファイル未満。
この 5 番目の条件セットに合うデータベース コピーがない場合は、アクティブ マネージャーは次の 6 番目の条件セットに合うデータベース コピーを探します。
Healthy 状態のコンテンツのインデックスを持っている。
コピー キューの長さが 10 ログ ファイル未満。
この 6 番目の条件セットに合うデータベース コピーがない場合は、アクティブ マネージャーは次の 7 番目の条件セットに合うデータベース コピーを探します。
クロール状態のコンテンツのインデックスを持っている。
コピー キューの長さが 10 ログ ファイル未満。
この 7 番目の条件セットに合うデータベース コピーがない場合は、アクティブ マネージャーは次の 8 番目の条件セットに合うデータベース コピーを探します。
- Healthy 状態のコンテンツのインデックスを持っている。
この 8 番目の条件セットに合うデータベース コピーがない場合は、アクティブ マネージャーは次の 9 番目の条件セットに合うデータベース コピーを探します。
- クロール状態のコンテンツのインデックスを持っている。
この 9 番目の条件セットに合うデータベース コピーがない場合は、アクティブ マネージャーは、Healthy、DisconnectedAndHealthy、DisconnectedAndResynchronizing、または SeedingSource の状態を持つ任意のデータベース コピーのアクティブ化を試みます (10 番目の条件セット)。この 10 番目の条件セットに合うデータベース コピーが見つからない場合は、データベース コピーを自動的にアクティブ化することはできません。
1 つ以上の条件セットに合う 1 つ以上のコピーが見つかれば、ACLL プロセスが実行され、これから新しいアクティブ コピーとなるコピーに、元のソースからすべてのログ ファイルがコピーされます。ACLL プロセスが完了したら、PAM がマウント要求を発行し、データベースがマウントされクライアントが利用できる状態になるか、データベースがマウントされず PAM が次に最適なコピーが利用できればそれを検索します。
最適なコピー選択の例
次に、アクティブ マネージャーの最適なコピー選択とアクティブ化のプロセスに関するいくつかの例を説明します。
例 1: 基本シナリオ
この例では、メールボックス データベース DB1 のコピーが 4 つ存在します。DB1 は現在 Server1 でアクティブですが、Server1 にハードウェア障害が発生します。次の表では、Server2、Server3、および Server4 にある DB1 のデータベース コピーの現在の状態を示します。
| データベース コピー | アクティブ化優先順位 | コピー キューの長さ | 再生キューの長さ | コンテンツ インデックスの状態 | データベースの状態 | アクティブ化がブロックされているか |
|---|---|---|---|---|---|---|
Server2\DB1 |
2 |
4 |
0 |
Healthy |
Healthy |
いいえ |
Server3\DB1 |
3 |
2 |
2 |
Healthy |
DisconnectedAndHealthy |
いいえ |
Server4\DB1 |
4 |
10 |
0 |
クロール |
Healthy |
いいえ |
コピー キューの長さに基づいて (必要な場合はアクティブ化優先順位を使用して) 利用可能なコピーを並べ替えると、一覧は次のような順序となります。
Server3\DB1
Server2\DB1
Server4\DB1
この一覧からは、2 つのデータベース コピーのみが、アクティブ化のための 1 番目の条件セットに合っています。
Server3 のコピー。データベースの状態は DisconnectedAndHealthy、コピー キューの長さは 10 未満、再生キューの長さは 50 未満、およびコンテンツ インデックスは正常。
Server2 のコピー。データベースの状態は Healthy、コピー キューの長さは 10 未満、再生キューの長さは 50 未満、およびコンテンツ インデックスは正常。
これら 2 つの中では、Server3 のコピーが、コピー キューの長さが最小となっています。したがって、不足しているデータ量が最も少ないため、Server3 がアクティブ化を試みるコピーとして選択されます。
Server3 のコピーがアクティブ化された後、Server3 の Microsoft Exchange レプリケーション サービスが ACLL プロセスを実行し、以前のアクティブ サーバー (この場合 Server1) から、不足しているログ ファイルのコピーを試みます。ACLL プロセスの完了時に、PAM は ACLL プロセスから結果を通知されます。すべてのログのコピーに成功した場合は、データベースがアクティブ コピーとしてマークされ、データが消失することなくマウントされます。1 つ以上のログが不足している場合は、AutoDatabaseMountDial パラメーターの値が参照されます。データの消失が構成された値以内であれば、このデータベースがアクティブ コピーとしてマークされ、データの消失がある状態でマウントされます。この後、消失したデータの大部分は、トランスポート収集により回復されます。
アクティブ マネージャーがマウント要求を Information Store に送信せず、マウント操作が成功しなかった場合、アクティブ マネージャーは上記の並べ替えられた一覧に戻って、次に最適なコピー (この場合 Server2) のアクティブ化を試みます。
例 2: 2 つのコピーのコピー キューの長さが同じ場合
この例では、メールボックス データベース DB2 のコピーが 4 つ存在します。DB2 は現在 Server1 でアクティブですが、Server1 にハードウェア障害が発生します。次の表では、Server2、Server3、および Server4 にある DB2 のデータベース コピーの現在の状態を示します。
| データベース コピー | アクティブ化優先順位 | コピー キューの長さ | 再生キューの長さ | コンテンツ インデックスの状態 | データベースの状態 | アクティブ化がブロックされているか |
|---|---|---|---|---|---|---|
Server2\DB2 |
2 |
2 |
0 |
Healthy |
Healthy |
いいえ |
Server3\DB2 |
3 |
2 |
2 |
Healthy |
DisconnectedAndHealthy |
いいえ |
Server4\DB2 |
4 |
10 |
0 |
クロール |
Healthy |
いいえ |
コピー キューの長さに基づいて (必要な場合はアクティブ化優先順位を使用して) 利用可能なコピーを並べ替えると、一覧は次のような順序となります。
Server2\DB2
Server3\DB2
Server4\DB2
この一覧からは、2 つのデータベース コピーのみが、アクティブ化のための 1 番目の条件セットに合っています。
Server2 のコピー。データベースの状態は Healthy、コピー キューの長さは 10 未満、再生キューの長さは 50 未満、およびコンテンツ インデックスは正常。
Server3 のコピー。データベースの状態は DisconnectedAndHealthy、コピー キューの長さは 10 未満、再生キューの長さは 50 未満、およびコンテンツ インデックスは正常。
これら 2 つの中では、Server2 にあるコピーのコピー キューの長さは Server3 にあるコピーと等しくなっていますが、Server2 にあるコピーのアクティブ化優先順位の値がより小さい状況です。したがって、Server2 のコピーが一覧の最上位となり、不足しているデータ量が最も少なく、アクティブ化優先順位の値が最も小さいため、アクティブ化を試みるコピーとして選択されます。
例 3: 複数のコピーのデータベースの状態が同じで、コンテンツ インデックスの状態が異なる場合
この例では、メールボックス データベース DB3 のコピーが 4 つ存在します。DB3 は現在 Server1 でアクティブですが、Server1 にハードウェア障害が発生します。次の表では、Server2、Server3、および Server4 にある DB3 のデータベース コピーの現在の状態を示します。
| データベース コピー | アクティブ化優先順位 | コピー キューの長さ | 再生キューの長さ | コンテンツ インデックスの状態 | データベースの状態 | アクティブ化がブロックされているか |
|---|---|---|---|---|---|---|
Server2\DB3 |
2 |
0 |
3 |
クロール |
Healthy |
いいえ |
Server3\DB3 |
3 |
0 |
3 |
Healthy |
DisconnectedAndHealthy |
いいえ |
Server4\DB3 |
4 |
0 |
0 |
Healthy |
Healthy |
いいえ |
コピー キューの長さに基づいて (必要な場合はアクティブ化優先順位を使用して) 利用可能なコピーを並べ替えると、一覧は次のような順序となります。
Server2\DB3
Server3\DB3
Server4\DB3
上記のサーバーでホストされている 3 つのデータベース コピーのすべてが、アクティブ化の条件に合っています。Server2 にはアクティブ化優先順位により小さな値が設定されていますが、そのコンテンツ インデックスの状態はクロールです。この結果、アクティブ マネージャーが (コンテキスト インデックスの状態が Healthy であるという条件を含む) 1 番目の条件セットを使用してこの一覧を検査すると、コンテンツ インデックスの状態が Healthy である Server3 のデータベース コピーが優先されます。
例 4: 最適なコピー選択に対する AutoDatabaseMountDial の影響について
この例では、メールボックス データベース DB4 のコピーが 4 つ存在します。DB4 は現在 Server1 でアクティブですが、Server1 に障害が発生し、その結果 Server1 が再起動されます。次の表では、Server2、Server3、および Server4 にある DB4 のデータベース コピーの現在の状態を示します。DAG 内のすべてのメールボックス サーバーで AutoDatabaseMountDial パラメーターがロスレス (コピー キューの長さが 0) に構成されています。
| データベース コピー | アクティブ化優先順位 | コピー キューの長さ | 再生キューの長さ | コンテンツ インデックスの状態 | データベースの状態 | アクティブ化がブロックされているか |
|---|---|---|---|---|---|---|
Server2\DB4 |
2 |
0 |
4523 |
Healthy |
Healthy |
いいえ |
Server3\DB4 |
3 |
100 |
25 |
クロール |
Healthy |
いいえ |
Server4\DB4 |
4 |
6 |
62 |
Healthy |
Healthy |
いいえ |
自動データベース マウント ダイヤル設定がロスレスに設定されているため、アクティブ マネージャーはコピー キューの長さではなくアクティブ化優先順位を並べ替えの主キーとして使用します。アクティブ化優先順位に基づいて利用可能なコピーを並べ替えると、一覧は次のような順序となります。
Server2\DB4
Server3\DB4
Server4\DB4
どのデータベースも 1 番目、2 番目または 3 番目の条件セットに合っていませんが、Server3 のデータベース コピーが 4 番目の条件セット (コンテンツ インデックスがクロール状態であり、再生キューの長さが 50 未満) に合っています。Server3 のデータベース コピーは、コピー キューの長さが 100 ですが、Server1 が再起動をまだ完了していないため、ACLL プロセスはこれらの不足しているログ ファイルを Server3 にコピーできません。ACLL プロセスは PAM に、不足しているデータ量が AutoDatabaseMountDial パラメーターに構成された値以内に収まらないことを通知します。この結果、PAM は次に最適で利用可能なコピーを選択します。
上記のシナリオでは、Server2 と Server4 のデータベース コピーが 6 番目の条件セット (データベースとコンテンツ インデックスが正常であり、コピー キューの長さが 10 未満) に合っています。Server2 のデータベース コピーの方が、利用可能なコピーの並べ替え済み一覧で上位にあるため、次に試行されます。ACLL プロセスが Server2 で実行されますが、ネットワーク上で Server1 がまだ通信できない状態にあるため、ACLL はログをコピーできません。しかし、コピー キューの長さが AutoDatabaseMountDial パラメーターに対して構成された値以内に収まっているため、ACLL は成功メッセージを PAM に送信し、PAM は RPC 経由でデータベース マウント要求を発行します。
© 2010 Microsoft Corporation.All rights reserved.