管理ストア

  • [アーティクル]

製品: Exchange Server 2013

Exchange Serverのすべての以前のバージョン (Exchange Server 4.0 から Exchange Server 2010 まで) では、メールボックス サーバーの役割に対する Information Store プロセス (Store.exe) の単一インスタンスの実行がサポートされています。 この単一のストア インスタンスは、サーバー上のすべてのデータベース (アクティブ、パッシブ、ラグド、復旧) をホストします。 以前の Exchange アーキテクチャでは、メールボックス サーバーでホストされているさまざまなデータベース間に分離がほとんど存在しない場合があります。 1 つのメールボックス データベースに関する問題は、他のすべてのデータベースに悪影響を与える可能性があり、メールボックスの破損によるクラッシュは、そのサーバーでホストされているすべてのユーザーのサービスに影響する可能性があります。

以前のバージョンの Exchange で 1 つのストア インスタンスを使用するもう 1 つの課題は、拡張ストレージ エンジン (ESE) が 8 ~ 12 プロセッサ コアに十分にスケーリングされるが、そのしきい値を超えると、プロセッサ間通信とキャッシュ同期の問題が負のスケールにつながるということです。 16 以上のコア システムを使用できる現在の大規模なサーバーでは、ESE の 8 コアから 12 コアのアフィニティを管理し、他のコアをストア以外のプロセス (アシスタント、Search Foundation、Managed Availability など) に使用するという管理上の課題を課すことを意味します。 その上、以前のアーキテクチャは Store プロセスのスケールアップを制限していました。

Store.exe プロセスは、Exchange Server自体が進化するにつれて年を通じてかなり進化してきましたが、単一のプロセスとして、最終的にはスケーラビリティが制限され、単一の障害点を表しています。 これらの制限により、Store.exe は Exchange 2013 でなくなり、マネージド ストアに置き換えられます。

管理ストア

管理ストアは、Exchange Server 2013 における Information Store (Store とも呼ばれる) プロセスの名前です。 管理ストアは、ストレージ プロセスの分離とより迅速なデータベース フェールオーバーを実現するコントローラー/ワーカー プロセス モデルを使用します。 また、管理ストアには、以前のバージョンの Exchange Server での動的バッファー アルゴリズムの代わりとなる新しい静的データベース キャッシング メカニズムも含まれます。 マネージド ストアで使用されるマルチプロセス モデルでは、1 つのストア サービス コントローラー プロセス (この場合は MSExchangeIS Microsoft.Exchange.Store.Service.exe)、マウントされたデータベースごとに 1 つのワーカー プロセス (この場合は Microsoft.Exchange.Store.Worker.exe) があります。 データベースをマウントすると、そのデータベースに対してのみサービスを提供する新しいワーカー プロセスのインスタンスが生成されます。 データベースをマウント解除すると、そのデータベースのワーカー プロセスは削除されます。

たとえば、1 台のサーバーに 40 個のデータベースをマウントした場合、その管理ストアでは 41 個のプロセスが実行されます。つまり、各データベースに対して 1 つずつ、およびストア サービス プロセス コントローラーに対して 1 つ存在します。

ストア サービス プロセス コントローラーは薄型で信頼性が高いですが、停止または終了すると、すべてのワーカー プロセスが終了します (サービス コントローラー プロセスがなくなったことを検出して終了します)。 ストア プロセス コントローラーは、サーバー上のすべてのストア ワーカー プロセスの状態を監視します。 Microsoft.Exchange.Store.Service.exe の強制的または予期しない終了は、アクティブなすべてのデータベース コピーの即時フェールオーバーを引き起こします。 また、管理ストアは Microsoft Exchange Replication Service (MSExchangeRepl.exe) およびアクティブ マネージャーと密接に統合されています。 コントローラー プロセス、ワーカー プロセス、およびレプリケーション サービスは一緒に機能して、より高い可用性および信頼性を提供します。

  • Microsoft Exchange Replication Service プロセス (MSExchangeRepl.exe)

    • Store へのマウントおよびマウント解除操作を担当する

    • Store、Extensible Storage Engine (ESE)、可用性管理レスポンダーによって報告されたストレージ障害またはデータベース障害に対する回復処理を開始する

    • 予期しないデータベース エラーを検出する

    • 管理タスク用の管理インターフェイスを提供する

  • ストア サービス プロセス/コントローラー (Microsoft.Exchange.Store.Service.exe)

    • レプリケーション サービスから受け取るマウントおよびマウント解除操作に基づく各ワーカー プロセスの有効期限を管理する

    • Windows サービス コントロール マネージャーからの受信要求を処理する

    • ストア ワーカー プロセスの問題 (たとえば、ハング、予期しない終了など) が検出された場合に障害項目をログに記録する

    • フェールオーバー イベントの応答としてストア ワーカー プロセスを終了する

  • ストア ワーカー プロセス (Microsoft.Exchange.Store.Worker.exe)

    • データベース上のメールボックスの RPC 操作の実行を行う

    • ワーカー プロセス内の RPC エンドポイント インスタンスはデータベース GUID である

    • データベースにデータベース キャッシュを提供する

静的データベース キャッシング アルゴリズム

Exchange Server 5.5 で導入され、Exchange Server 2003、Exchange Server 2007、Exchange Server 2010 のインフォメーション ストアでも使用された動的バッファー割り当てと呼ばれるデータベース キャッシュ アルゴリズムも Exchange 2013 から削除されます。 Exchange 2013 では、データベース キャッシュを決定するためのシンプルで簡単なアルゴリズムが使用されます。 マネージド ストアでは、フェールオーバーが発生したときにデータベース間でキャッシュが動的に再割り当てされなくなり、内部キャッシュ管理が大幅に簡素化されます。 代わりに、各データベース キャッシュ (たとえば、各ストア ワーカー プロセス) に割り当てられるメモリは、ローカル データベース コピーの数と MaximumActiveDatabases の値 (構成されている場合) に基づいています。 MaximumActiveDatabases の値が現在のデータベース コピーの数を超える場合、キャッシュの計算はデータベース コピーの数に基づきます。

Exchange 2013 によって使用される静的アルゴリズムは、物理 RAM に基づいて各ストア ワーカー プロセスの ESE キャッシュにメモリを割り当てます。 このメモリは、データベースの 最大キャッシュ ターゲットと呼ばれます。 サーバー メモリの合計の 25% は ESE キャッシュに割り当てられます。 このメモリの割合は、 サーバー キャッシュ サイズ ターゲットと呼ばれます。

注:

サーバー キャッシュ サイズ ターゲット、および ESE キャッシュ用のストアに割り当てられたメモリの量は、Active Directory の InformationStore オブジェクトの msExchESEParamCacheSizeMax 属性を使用してオーバーライドできます (構成される値は、すべてのストア プロセスに割り当てる 32 KB ページの数です)。

静的なこのキャッシュの量は、アクティブ コピーおよびパッシブ コピーに割り当てられます。 ストア ワーカー プロセスに最大キャッシュ ターゲットが割り当てられるのは、アクティブ データベース コピーを提供する場合のみです。 パッシブ データベース コピーの場合、最大キャッシュ ターゲットの 20% が割り当てられます。 残りは Store によって予約され、データベースがパッシブからアクティブに移行する場合にワーカー プロセスに割り当てられます。

最大キャッシュ ターゲットの計算は Store 起動時にのみ行われます。 そのため、データベースまたはデータベース コピーを追加または削除する場合、その結果に応じてキャッシュを調整できるように、Store コントローラー サービス (MSExchangeIS) を再起動する必要があります。 サービスが再起動されない場合、新しく作成されたデータベースのキャッシュ サイズターゲットは、サービスの起動前に作成されたデータベースよりも小さくなります。 この場合、データベース キャッシュ サイズ ターゲットの合計は、MSExchangeIS が再起動するまで、サービス キャッシュ サイズ ターゲットを上回る可能性が高くなります。

データベース キャッシュ計算の例

以下は、メールボックス サーバーのメモリおよびデータベース構成に基づいたデータベース キャッシング計算の例です。

例 1

この例では、メールボックス サーバーに 48 GB のメモリがあり、2 つのアクティブ データベースと 2 つのパッシブ データベースがホストされています。 さらに、 MaximumActiveDatabases パラメーターは構成されていません。 この構成では、データベース キャッシュの容量は、アクティブ データベース コピーのワーカー プロセスにはそれぞれ 3 GB、パッシブ データベース コピーのワーカー プロセスにはそれぞれ 0.6 GB が割り当てられます。 以下にこれらの値の算出方法を示します。

サーバー キャッシュ サイズ ターゲットを算出するため、メモリ容量を 25% で乗算します。

48 GB X 25% = 12 GB

データベース最大キャッシュ ターゲットを算出するため、サーバー キャッシュ サイズ ターゲットをアクティブ データベースとパッシブ データベースの合計数で除算します。

12 GB / 4 データベース = 3 GB

パッシブ データベース コピーに使用するメモリ容量を決定するため、データベース最大キャッシュ ターゲットを 20% で乗算します。

3 GB X 20% = 0.6 GB

サーバー キャッシュ サイズ ターゲットに割り当てられた 12 GB のメモリのうち、7.2 GB はデータベース ワーカー プロセスで使用され、4.8 GB は、アクティブなコピーになった場合に備えて、2 つのパッシブ データベース コピー用にインフォメーション ストアによって予約されます。 その場合は、最大キャッシュ ターゲット 3 GB を使用します。

例 2

この例でも、メールボックス サーバーに 48 GB のメモリがあり、2 つのアクティブ データベースと 2 つのパッシブ データベースがホストされていますが、MaximumActiveDatabases パラメーターが値 2 で構成されています。 この構成では、データベース キャッシュの容量は、アクティブ データベース コピーのワーカー プロセスごとに 5 GB、パッシブ データベース コピーのワーカー プロセスごとに 0.2 GB です。 以下にこれらの値の算出方法を示します。

サーバー キャッシュ サイズ ターゲットを算出するため、メモリ容量を 25% で乗算します。

48 GB X 25% = 12 GB

データベースの最大キャッシュ ターゲットを取得するには、サーバー キャッシュ サイズ ターゲットを、アクティブなデータベースの合計数とパッシブ データベースの合計数に 20% を乗算して除算します。

12 GB / (2A + (2P X 20%)) = 5 GB

パッシブ データベース コピーに使用するメモリ容量を決定するため、データベース最大キャッシュ ターゲットを 20% で乗算します。

5 GB X 20% = 1 GB

サーバー キャッシュ サイズ ターゲットに割り当てられた 12 GB のメモリのうち、12 GB はデータベース ワーカー プロセスで使用され、2 つのパッシブ データベース コピーのメモリはインフォメーション ストアによって予約されません( MaximumActiveDatabases は値 2 で構成されているため、 サーバーにアクティブなデータベース コピーが既に 2 つあります)。