以前のバージョンと比較した高可用性とサイト復元の変更点

[アーティクル]
04/04/2023

適用対象: Exchange Server 2013 SP1

Exchange 2013 では DAG およびメールボックスデータベースコピーのほか、単一アイテム回復、アイテム保持ポリシー、時間差データベースコピーなどの機能を使用して、高可用性、サイトの復元、および Exchange ネイティブデータ保護が実現されています。高可用性プラットフォーム、Exchange Information Store、および拡張ストレージエンジン (ESE) が強化され、可用性が向上し、管理が容易になり、コストが削減されます。以下のような点が改善されました。

Exchange 2010 での IOPS の削減: これにより、容量と IOPS の観点から、より大きなディスクを可能な限り効率的に活用できます。
可用性管理: 可用性管理によって内部監視機能および回復指向の機能が緊密に統合され、障害の未然防止、サービスの予防的復元、サーバーフェールオーバーの自動開始に役立つほか、管理者にアクションを実行するよう警告を出すこともできます。サーバーとコンポーネントの稼動時間だけでなく、エンドユーザーエクスペリエンスの監視および管理に重点を当てることで、サービスを継続的に利用できるようにしています。
マネージドストア: マネージドストアは、Exchange 2013 で新しく書き換えられた Information Store プロセスの名前です。新しい Managed Store は C# で作成されて Microsoft Exchange Replication サービス (MSExchangeRepl.exe) に緊密に統合されているため、回復性が向上し、可用性がより高くなっています。
ディスクごとの複数のデータベースのサポート: Exchange 2013 には、同じディスク上の複数のデータベース (アクティブコピーとパッシブコピーの組み合わせ) をサポートし、容量と IOPS の観点から可能な限り効率的に大規模なディスクを利用できる拡張機能が含まれています。
AutoReseed: 自動再シード機能を使用すると、ディスク障害後にデータベースの冗長性をすばやく復元できます。ディスクに障害が発生した場合、そのディスクに格納されているデータベースコピーが、アクティブデータベースコピーから同じサーバー上の予備ディスクにコピーされます。障害が発生したディスクに複数のデータベースコピーが格納されていた場合は、予備ディスク上に自動的に再シードされます。この結果、アクティブデータベースが複数のサーバーに存在し、データが並行してコピーされるので、迅速に再シードできます。
ストレージ障害からの自動復旧: この機能は、Exchange 2010 で導入されたイノベーションを継続して、システムが回復性または冗長性に影響を与える障害から回復できるようにします。 Exchange 2010 のバグチェック動作に加えて、Exchange 2013 には、長い I/O 時間の追加の回復動作、MSExchangeRepl.exe による過剰なメモリ消費、およびシステムが不適切な状態でスレッドをスケジュールできない重大なケースが含まれています。
遅延コピーの機能強化: 自動ログ再生ダウンを使用して、遅延コピーを一定の範囲で管理できるようになりました。遅延コピーは、ページの修正プログラムの適用やディスク領域の不足のシナリオなど、さまざまな状況でログファイルを自動的に再生します。時間差コピーに対してページパッチが必要であることが検知されると、ログが自動的に時間差コピーに対して再生され、ページパッチが実行されます。ラグコピーは、ディスク領域のしきい値が低い場合や、ラグされたコピーが特定の期間だけ使用可能なコピーとして検出された場合にも、この自動再生機能を呼び出します。さらに、遅延コピーでは Safety Net を使用できるため、復旧やアクティブ化が容易になります。
単一コピーアラートの機能強化: Exchange 2010 で導入された単一コピーアラートは、個別のスケジュールされたスクリプトではなくなりました。この機能は、システム内の可用性管理コンポーネントに統合され、Exchange のネイティブな機能になりました。
DAG ネットワークの自動構成: DAG ネットワークは、構成設定に基づいてシステムによって自動的に構成できます。手動構成オプションに加え、DAG で MAPI とレプリケーションネットワークを区別して DAG ネットワークを自動的に構成することも可能です。

Exchange 2010 と比較した IOPS の減少

Exchange 2010 では、パッシブデータベースコピーのチェックポイントの深さが低く、高速フェールオーバーに必要です。さらに、パッシブコピーは 5 MB のチェックポイントの深さを維持するためにデータの積極的な事前読み込みを実行します。チェックポイントの深さが低く、これらの積極的な読み取り前操作を実行した結果、パッシブデータベースコピーの IOPS は、Exchange 2010 のアクティブコピーの IOPS と同じでした。

Exchange 2013 では、システムはパッシブコピー (100 MB) で高いチェックポイントの深さを使用したまま、高速なフェールオーバーを提供できます。パッシブコピーのチェックポイントの深さは 100 MB であるため、それほど積極的ではなくなったように調整解除されます。チェックポイントの深さを増やし、積極的な事前読み込みを緩和した結果、パッシブコピーに対する IOPS は Exchange 2013 のアクティブコピー IOPS の約 50% です。

パッシブコピーのチェックポイントの深さをより高く設定すると、その他の変更も必要になります。 Exchange 2010 のフェールオーバーでは、データベースがパッシブコピーからアクティブコピーに変換されると、データベースキャッシュがフラッシュします。 Exchange 2013 では、ESE ログ記録のコードが書き直されて、パッシブからアクティブへの移行を通じてキャッシュが保持されるようになりました。 ESE がキャッシュをフラッシュする必要がないので、フェールオーバーは高速になります。

もう 1 つの変更点は、バックグラウンドデータベースメンテナンス (BDM) プロセスに対する変更です。 BDM はコピーあたり毎秒約 1 ～ 2 MB を処理するようになりました。

これらの変更により、Exchange 2013 では Exchange 2010 と比較して IOPS が大幅に減少しました。

可用性管理

マネージド可用性は、組み込みのアクティブな監視と Exchange 2013 高可用性プラットフォームの統合です。マネージド可用性を使用すると、システムはサービス正常性に基づいてデータベースをフェールオーバーするタイミングを決定できます。マネージド可用性は、Exchange 2013 のクライアントアクセスサーバーとメールボックスサーバーの役割に展開される内部インフラストラクチャです。マネージド可用性には、常に作業を行っている 3 つのメイン非同期コンポーネントが含まれています。 1 つ目のコンポーネントはプローブエンジンであり、サーバーで測定を行い、データを収集します。これらの測定値の結果は、2 番目のコンポーネントであるモニターに流れます。モニターには、収集されたデータで正常と見なされるものに基づいて、システムによって使用されるすべてのビジネスロジックが含まれています。モニターは、パターン認識エンジンと同様に、収集したすべての測定値についてさまざまなパターンを探し出し、対象が正常かどうかの決定を下すことができます。最後に、回復アクションを担当するレスポンダーエンジンがあります。何かが異常な場合、最初のアクションは、そのコンポーネントの回復を試みすることです。これには、複数ステージの復旧アクションが含まれる場合があります。たとえば、最初の試行はアプリケーションプールの再起動、2 つ目はサービスの再起動、3 回目の試行はサーバーの再起動、それ以降の試行はトラフィックを受け入れなくなったようにサーバーをオフラインにする場合があります。復旧アクションが失敗した場合、システムはイベントログ通知を通じて問題を人間にエスカレートします。

可用性管理は、次の 2 つのサービスの形で実装されています。

Exchange Health Manager Service (MSExchangeHMHost.exe): これは、ワーカープロセスの管理に使用されるコントローラープロセスです。必要に応じて、ワーカープロセスの構築、実行、開始、および停止に使用されます。また、ワーカープロセスがクラッシュした場合の回復や、ワーカープロセスが単一障害点になることを防ぐためにも使用されます。
Exchange Health Manager Worker プロセス (MSExchangeHMWorker.exe): これは、ランタイムタスクの実行を担当するワーカープロセスです。

可用性管理においては、永続的なストレージを使用してその機能を実行します。

XML 構成ファイルを使用して、ワーカープロセスのスタートアップ中に作業項目の定義を初期化します。
レジストリを使用して、ブックマークなどのランタイムデータを格納します。
Crimson Channel イベントログインフラストラクチャを使用して、作業項目の結果を格納します。

可用性管理の詳細については、「可用性管理」を参照してください。

管理ストア

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

旧バージョンの Exchange の単一 Store インスタンスに関する別の問題は、プロセッサのコア数が 8 から 12 なら Extensible Storage Engine (ESE) の拡張が良好であるものの、その数を超えるとプロセッサ間通信およびキャッシュ同期の問題によって拡張に悪影響が生じるというものです。 16 以上のコアシステムを使用できる現在の大規模なサーバーでは、ESE の 8 ~ 12 コアのアフィニティを管理し、他のコアをストア以外のプロセス (アシスタント、Search Foundation、Managed Availability など) に使用するという管理上の課題が課されます。その上、以前のアーキテクチャは Store プロセスのスケールアップを制限していました。

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

詳細については、「管理ストア」を参照してください。

ボリュームごとに複数のデータベース

Exchange 2013 のストレージの機能強化は、主に多数のディスク (JBOD) 構成に対して設計されていますが、サポートされているすべてのストレージ構成で使用できます。そのような機能の 1 つは、同じボリューム上で複数のデータベースをホストできることです。この機能は、大規模なディスク用の Exchange 最適化に関する機能です。これらの最適化により、容量、IOPS、再シード時間の観点から大きなディスクをはるかに効率的に使用できます。これは、JBOD ストレージ構成での実行に関連する課題に対処することを目的としています。

データベースのサイズは管理可能である必要があります。
再シード操作は高速かつ信頼性が高くなければなりません。
ストレージの容量は増加しますが、IOPS は増加しません。
パッシブデータベースコピーをホストするディスクは IOPS の面で十分に活用されていません。
時間差コピーには非対称のストレージ要件があります。
ディスクの空き容量が少ない状態から回復する場合、敏捷性は限られています。

ストレージ容量は引き続き増加する傾向にあり、間もなく 8 TB のドライブが利用できるようになります。 8 TB のドライブを Exchange の最大データベースサイズのベストプラクティスガイドライン (2 TB) と組み合わせて使用すると、5 TB を超えるディスク容量が無駄になります。 1 つの解決策は、データベースを大きくすることですが、場合によっては、運用上管理できない再シード時間や、ネットワーク経由でその量のデータをコピーする信頼性が損なわれるなど、長い再シード時間が発生するため、管理が困難になります。

また、Exchange 2010 モデルでは、パッシブコピーを格納するディスクは IOPS の観点から十分に活用されていません。時間差パッシブコピーの場合、アクティブコピーおよび時間差でないパッシブコピーの格納に使用されるディスクと比較して、IOPS の観点からディスクが十分に活用されていないだけでなく、そのサイズの観点から非対称でもあります。

継続的で長期にわたる実践から、Exchange 2013 が大容量ディスク (8 TB) を JBOD 構成でより効率的に使用できるように最適化されました。 Exchange 2013 では、ディスクごとに複数のデータベースを配置して、同じサイズのディスクに時間差コピーを含む複数のデータベースコピーを格納できます。目標は、存在する複数のボリュームにユーザーを分散し、通常の運用中に、各 DAG メンバーが同じボリューム上にアクティブ、パッシブおよび時間差コピー (オプション) の組み合わせをホストする対称的なデザインを提供することです。

ボリュームごとに複数のデータベースを使用する構成の例を、以下に図示します。

ボリュームごとに複数のデータベース。

上記の構成では、対称設計が提供されます。 4 つのサーバーはすべて、サーバーごとに 1 つのディスクでホストされている同じ 4 つのデータベースを持ちます。キーは、持っている各データベースのコピー数が、ディスクあたりのデータベースコピー数と等しい必要があるということです。上記の例では、各データベースの 4 つのコピーがあります。1 つのアクティブコピー、2 つのパッシブコピー、および 1 つの遅延コピーです。各データベースには 4 つのコピーがあるため、適切な構成はボリュームごとに 4 つのコピーを持つ 1 つです。さらに、アクティブ化の基本設定は、DAG と各サーバー間でバランスが取るように構成されます。たとえば、アクティブコピーのアクティブ化優先値は 1、最初のパッシブコピーのアクティブ化優先値は 2、2 番目のパッシブコピーのアクティブ化優先値は 3、遅延コピーのアクティブ化優先値は 4 です。

ディスクごとに複数のデータベースを使用すると、存在するボリュームにユーザーをより適切に分散できるほか、再シードを必要とする障害 (ディスク障害など) の発生時に、データ保護の復元に要する時間が短くなるという利点があります。

データベースが大きくなるほど、データベースの再シードに要する時間は長くなります。たとえば、2 テラバイトデータベースの再シードには 23 時間かかる場合があります。一方、8 テラバイトデータベースには 93 時間 (ほぼ 4 日間) かかる場合があります。どちらのシードも約 20 MB/秒で行われます。これは一般的に、非常に大きなデータベースは運用で許容可能な時間内にシードできないということを意味します。

ディスクごとに 1 つのデータベースコピーのシナリオの場合、シード処理は、常に 1 つのソースからディスクをシード処理するため、実質的にソースバインドされます。ボリュームを複数のデータベースコピーに分割し、指定したボリューム上のパッシブデータベースのアクティブコピーを個別の DAG メンバーに格納します。システムは、ディスクの再シードのコンテキストでソースバインドされなくなりました。障害が発生したディスクが置き換えられると、複数のソースから再シードできます。これにより、システムは、これらのデータベースのデータ保護を短時間で再シードおよび復元できます。

ボリュームごとに複数のデータベースを使用する場合、次のベストプラクティスと要件に従うことをお勧めします。

物理ディスクごとに 1 つの論理ディスクのパーティションを使用する必要があります。ディスク上に複数のパーティションを作成しないでください。各データベースコピーと付随するファイル (トランザクションログやコンテンツインデックスなど) は、1 つのパーティションの一意のディレクトリにホストされている必要があります。
1 つのボリュームに構成されたデータベースコピーの数は、各データベースのコピーの数と一致する必要があります。たとえば、データベースのコピーが 4 つある場合、ボリュームごとに 4 つのデータベースコピーを使用する必要があります。
データベースコピーには、同じネイバーが必要です。 (たとえば、すべてのサーバーで同じディスクを共有する必要があります)。
DAG にまたがるアクティブ化の優先順位をバランス調整し、指定されたディスク上にある各データベースコピーのアクティブ化優先順位の値が一意になるようにする必要があります。

AutoReseed

自動再シード、または AutoReseed は、ディスクの障害、データベース破損の発生、またはデータベースコピーの再シードが必要なその他の問題に対応するために通常は管理者によって行われる操作の代わりとなる機能です。 AutoReseed は、ディスクの障害発生後にシステムでプロビジョニング済みの予備のディスクを使用して、自動的にデータベースの冗長性を復元するように設計されています。

詳細については、「AutoReseed」を参照してください。 AutoReseed の構成手順の詳細については、「データベース可用性グループの AutoReseed の構成」を参照してください。

ストレージ障害からの自動回復

ストレージ障害からの自動回復の機能は Exchange 2010 で導入された新技術を継続したもので、復元力または冗長性に影響する障害からシステムを回復できます。 Exchange 2010 のバグチェック動作に加えて、Exchange 2013 には、長い I/O 時間の追加の回復動作、Microsoft Exchange レプリケーションサービスによる過剰なメモリ消費 (MSExchangeRepl.exe)、スレッドをスケジュールできない重大なケースが含まれています。

JBOD 環境においても、クラッシュやハングといったストレージアレイコントローラーの問題が発生する場合があります。 Exchange 2010 には、ハング I/O の検出や拡張された復元を提供する回復機能が組み込まれました。次の表にこれらの機能を表示します。

名前	チェック	アクション	しきい値
ESE データベースのハング IO 検出	ESE は突出した I/O をチェックします	クリムゾンチャネルで障害項目を生成してサーバーを再起動します	240 秒
障害項目チャネルのハートビート	障害項目がクリムゾンチャネルに対して書き込みと読み取りができることを確認します	レプリケーションサービスはクリムゾンチャネルにハートビートを送信して障害のあるサーバーを再起動します	30 秒
システムディスクのハートビート	サーバーのシステムディスクの状態を確認します	システムディスクに対して非バッファー I/O を定期的に送信し、ハートビートがタイムアウトするとサーバーを再起動します	120 秒

Exchange 2013 では、その他の重大な状況への新しい対処方法を含めることで、サーバーおよびストレージの復元機能を拡張しています。次の表で、これらの状況と動作について説明します。

名前	チェック	アクション	しきい値
問題があるシステムの状態	スレッド (非管理スレッドを含む) をスケジュールできない	サーバーを再起動する	302 秒
実行時間の長い I/O	I/O 操作の遅延の測定	サーバーを再起動する	41 秒
レプリケーションサービスのメモリ使用量	MSExchangeRepl.exe のワーキングセットの測定	クリムゾンチャネルにサービス終了要求と共にイベント 4395 を記録する MSExchangeRepl.exe の終了を開始するサービスの終了が失敗した場合は、サーバーを再起動する	4 ギガバイト (GB)
システムイベント 129 (バスリセット)	システムイベントログでイベント 129 をチェックする	サーバーを再起動する	イベントが発生した場合
クラスターデータベースのハングアップ	グローバル更新マネージャーの更新プログラムがブロックされた場合	サーバーを再起動する	イベントが発生した場合

時間差コピーの機能強化

時間差コピーの機能強化には、セーフティネットとの統合および特定のシナリオにおけるログファイルの自動再生が含まれます。セーフティネットはトランスポートの機能で、Exchange 2010 のトランスポート収集と呼ばれた機能に代わるものです。セーフティネットは、メールボックスサーバー上のトランスポートサービスに関連付けられた配信キューという点においてトランスポート収集に似ています。このキューは、メールボックスサーバー上のアクティブなメールボックスデータベースに正常に配信されたメッセージのコピーを格納します。メールボックスサーバー上のそれぞれのアクティブなメールボックスデータベースには、配信されたメッセージのコピーを格納する自身のキューがあります。セーフティネットが、正常に配信されたメッセージのコピーを期限切れで自動的に削除するまで保存する期間を指定できます。

セーフティネットは、DAG 環境におけるシャドウ冗長性から一部の責任を引き継ぎます。配信されたメッセージが、DAG の他のメールボックスサーバーにあるメールボックスデータベースのパッシブコピーにレプリケートされるのを待機している間は、DAG 環境では、シャドウ冗長がシャドウキューの配信されたメッセージの別のコピーを保持する必要はありません。配信されたメッセージのコピーは既にセーフティネットに保存されていますので、必要に応じてシャドウ冗長はメッセージをセーフティネットから再配信できます。

Safety Net の導入により、遅れたデータベースコピーのアクティブ化が容易になります。たとえば、2 日間の時間差がある時間差コピーがあると仮定します。その場合、セーフティネットを 2 日間で構成します。時間差コピーを使用する必要がある状況になると、それに対するレプリケーションを一時停止して、それを 2 回コピーします (データベースの時間差の性質を保持して、必要になった場合のために追加のコピーを作成するためです)。次に、コピーを作成して必要な範囲以外のログファイルをすべて破棄します。コピーをマウントすると、直近 2 日間のメールを再配信するようセーフティネットに対して自動要求をトリガーします。セーフティネットでは、破損のポイントが導入された時点以降、これ以上の破損は起こりません。直近 2 日間のメールを取り戻すことはできますが、当然、損失の大きいフェールオーバーで普通に失われたデータを除きます。

時間差コピーは、自動ログ再生を起動してログファイルを再生することで、特定のシナリオで自身を管理できるようになりました。

低ディスク容量のしきい値に達した場合
時間差コピーに物理的な破損があり、ページパッチが必要な場合
使用可能な正常なコピーが 3 つ未満 (アクティブまたはパッシブのみ、遅延したデータベースコピーはカウントされません) が 24 時間を超える場合

Exchange 2010 では、時間差コピーにはページパッチは利用できませんでした。 Exchange 2013 では、自動ログ再生機能によって時間差コピーのページパッチが利用できます。時間差コピーに対してページパッチが必要であることが検知されると、ログが自動的に時間差コピーに対して再生され、ページパッチが実行されます。ラグコピーは、ディスク領域のしきい値が低い場合や、ラグされたコピーが特定の期間だけ使用可能なコピーとして検出された場合にも、この自動再生機能を呼び出します。

遅延コピーのログ再生動作は既定では無効で、有効にするには次のコマンドを実行します。

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

有効にすると、コピーが 3 つ未満の場合にログ再生が発生します。次の DWORD レジストリ値を変更することで、既定値の 3 を変更できます。

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

低ディスク容量のしきい値に対するログ再生を有効にするには、次のレジストリエントリを構成する必要があります。

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

これらのレジストリ設定を構成した後、Microsoft Exchange DAG 管理サービスを再開して、変更を有効にします。

たとえば、特定のデータベースに 4 つのコピー (3 つの高可用性コピーと 1 つの遅延コピー) があり、既定の設定が ReplayLagManagerNumAvailableCopies に使用されている環境を考えてみましょう。何らかの理由 (一時停止など) により時間差でないコピーのサービスが停止していると、自動的に時間差コピーが 24 時間内のログファイルを再生します。

単一コピーの警告の機能強化

サーバーが確実に動作していて、メールボックスデータベースコピーが正常であることを確認するのは、Exchange 2013 メッセージングの毎日の運用における主な目的です。ハードウェア、Windows オペレーティングシステム、および Exchange サービスをアクティブに監視する必要があります。しかし、Exchange 2013 メールボックスの復元環境で実行する場合、DAG およびメールボックスデータベースコピーの正常性と状態を監視することが重要です。データ冗長性のリスク管理を行い、レプリケートされたデータベースがただ 1 つのコピーになった期間を監視することは特に重要です。これは、独立ディスクの冗長アレイ (RAID) を使用せず、代わりに JBOD 構成をデプロイする環境では重要です。 RAID 環境では、単一のディスクの障害がアクティブメールボックスデータベースのコピーに影響を及ぼすことはありません。ただし、JBOD 環境では、1 つのディスク障害によってデータベースのフェールオーバーがトリガーされます。

Exchange 2010 では、スクリプト CheckDatabaseRedundancy.ps1 が導入されました。その名前が示すように、スクリプトの目的は、少なくとも 2 つの構成済み、正常なコピー、および現在のコピーがあることを検証することで、レプリケートされたメールボックスデータベースの冗長性を監視し、レプリケートされたデータベースの正常なコピーが 1 つだけ存在する場合にイベントログ生成を通じて管理者に警告することでした。この場合、冗長性を決定するときにアクティブコピーとパッシブコピーの両方がカウントされます。

以下は、コピーが 1 つしかない状態の例の一部です。

アクティブコピーからパッシブコピーへのレプリケートの失敗。
すべてのパッシブコピーの失敗。これには、ログのコピーまたは再生でコピーが背後にある正常な状態に加えて、FailedAndSuspended 状態と Failed 状態が含まれます。遅延コピーは、ログをラグ期間まで再生するのに 10 分以内であれば、後ろとは見なされません。
アクティブコピーの現在のログ世代を正確に把握するシステムの障害。

管理者にとって、データベースの正常なコピーが 1 つだけになっている状態を把握することは最優先なため、CheckDatabaseRedundancy.ps1 スクリプトは、可用性管理の DataProtection 正常性セットに含まれる、統合されたネイティブな機能に置き換えられました。

ネイティブの機能は依然としてイベントログ通知を通して管理者に警告を出します。Exchange 2013 は、Exchange 2013 の警告を Exchange 2010 と区別するために、次のイベント ID を使用します。

イベント 4138 (赤色の警告)
イベント 4139 (緑色の警告)

Exchange 2013 では、ネイティブの機能が強化され、同一のサーバー上の複数のデータベースが 1 つのコピーの状態になったときに発せられる不要な警告が少なくなっています。 Exchange 2010 では、1 つのコピーの警告はデータベースごとのレベルで生成されていました。その結果、サーバー全体にわたる問題が発生して複数のデータベースや複数のデータベースコピーに影響が及ぶと、大量の警告が発生していました。コントローラーの問題、メモリの問題などのいくつかの障害はサーバー全体にわたるため、ある程度高い確率で、そのような大量の警告が 1 つのサーバーインシデントについて発生していました。 Exchange 2013 では、警告はサーバー単位で生成されるようになりました。停止がサーバー全体に影響し、データの冗長性が複数のデータベースコピーに対するリスクとなった場合、サーバーごとに 1 つの警告が生成されるようになりました。

DAG ネットワークの自動構成

DAG ネットワークは、レプリケーショントラフィックまたは MAPI トラフィックのいずれかに使用する 1 つまたは複数のサブネットの集合です。 DAG ごとに、最大 1 つの MAPI ネットワークと 0 または 1 つ以上のレプリケーションネットワークが含まれます。 Exchange 2010 では、最初の DAG ネットワーク (DAGNetwork01 や DAGNetwork02 など) は、クラスターサービスによって列挙されるサブネットに基づいて、システムによって作成されていました。複数のネットワークが使用されている環境で、指定されたネットワーク (MAPI ネットワークなど) のインターフェイスが同じサブネット上にあった場合、管理者が実行する必要がある追加の構成はほとんどありませんでした。ただし、指定されたネットワークのインターフェイスが複数のサブネット上にある環境では、管理者は DAG のネットワークの折りたたみと呼ばれるタスクを実行する必要がありました。

Exchange 2013 では、DAG ネットワークの折りたたみは不要になりました。 Exchange 2013 では、MAPI とレプリケーションネットワークを区別するために同じ検出メカニズムを使用していますが、必要に応じて DAG ネットワークの折りたたみを自動的に行うようになりました。

さらに、DAG ネットワークが既定でシステムによって自動的に管理されるようになりました。 Exchange 管理センター (EAC) を使用して DAG ネットワークプロパティを表示するには、EAC を使用して DAG のプロパティを変更するか、 Set-DatabaseAvailabilityGroup コマンドレットを使用して ManualDagNetworkConfiguration パラメーターをに設定することで、手動ネットワーク制御用に DAG を構成する True必要があります。

最適なコピー選択に対する変更

最適なコピー選択 (BCS) は、個別のデータベースの最適なコピーを見つけてアクティブにするための内部のアルゴリズム処理で、アクティブにする可能性のあるコピーとその正常性および状態の一覧が渡されます。アクティブマネージャーは、既存のアクティブなデータベースコピーに障害が発生した場合または管理者がターゲットを指定せずに切り替えを実行した場合に、新しいアクティブなデータベースとなる最適で利用可能な (ブロックされていない) コピーを選択します。 Exchange 2010 では、BCS プロセスが各データベースコピーの複数の側面を評価して、アクティブ化する最良のコピーを判別しました。これらには次のようなものがあります。

キューの長さをコピー
再生キューの長さ
データベースの状態
コンテンツインデックスの状態

Exchange 2013 では、アクティブマネージャーは同じ BCS の確認および段階を実行してレプリケーションの正常性を判断しますが、正常性状態の降順の制約の使用も含めるようになりました。これらの変更の結果、BCS は最適なコピーおよびサーバーの選択 (BCSS) と呼ばれるようになりました。

BCSS には、Exchange 2013 の組み込みのマネージド可用性監視コンポーネントの一部であるいくつかの新しい正常性チェックが含まれています。新しくアクティブマネージャーによって追加で実行されるチェックが 4 つあります (実行される順に以下に示します)。

すべての正常: すべての監視コンポーネントが正常な状態にある影響を受けるデータベースのコピーをホストしているサーバーを確認します。
正常な状態まで: 影響を受けるデータベースのコピーをホストしているサーバーが、正常な状態で標準優先度のすべての監視コンポーネントを持っていることを確認します。
ソースよりすべて: 影響を受けるコピーをホストしている現在のサーバーよりも優れた状態の監視コンポーネントを持つ、影響を受けるデータベースのコピーをホストしているサーバーをチェックします。
ソースと同じ: 影響を受けるコピーをホストしている現在のサーバーと同じ状態の監視コンポーネントを持つ、影響を受けるデータベースのコピーをホストしているサーバーを確認します。

可用性管理の監視コンポーネント (フェールオーバーレスポンダー経由など) によってトリガーされたフェールオーバーの結果、BCSS が起動されると、ターゲットサーバーのコンポーネントの正常性は、フェールオーバーが発生したサーバー以上でなければならないという追加の必須の制約が強制されます。たとえば、Outlook Web Appの失敗によってフェールオーバーレスポンダーを介したマネージド可用性フェールオーバーがトリガーされる場合、BCSS は、Outlook Web Appが正常な影響を受けるデータベースのコピーをホストするサーバーを選択する必要があります。

DAG Management サービス

Exchange 2013 の RTM (Release To Manufacturing) 版の累積更新プログラム 2 (CU2) には、DAG のメンバーであるメールボックスサーバーの新しいサービスが含まれています。このサービスは、Microsoft Exchange DAG Management サービス (MSExchangeDAGMgmt) といいます。この新しいサービスには、以前は Microsoft Exchange Replication サービス (MSExchangeRepl) の中で実行されていた DAG 内部監視機能が含まれています。

クラスター管理アクセスポイントなしの DAG

Windows Server 2008 R2 または Windows Server 2012 を実行するすべての DAG には、MAPI ネットワークに含まれるすべてのサブネットに少なくとも 1 つの IP アドレスが必要です。 DAG に割り当てられた IP アドレスは、クラスター名を使用してクラスターへの名前解決および接続 (具体的には、現在クラスターコアリソースグループを所有するクラスターメンバーへの接続) を有効にするために、クラスターの管理アクセスポイント (クラスターネットワーク名とも呼ばれます) が設定された DAG のクラスターにより使用されます。 Windows Server 2012 R2 では、管理アクセスポイントを使用せずにフェールオーバークラスターを作成することができます。管理アクセスポイントを使用しない Windows フェールオーバークラスターには、次のような特性があります。

クラスターに割り当てられた IP アドレスがないため、クラスターコアリソースグループに IP アドレスリソースがありません。
クラスターに割り当てられているネットワーク名がないため、クラスターコアリソースグループにネットワーク名リソースがありません
クラスターの名前は DNS に登録されておらず、ネットワーク上では解決できません。
クラスター名オブジェクト (CNO) は Active Directory に作成されません。
Windows フェールオーバークラスターは、フェールオーバークラスター管理ツールを使用して管理できません。 Windows PowerShell を使用して管理し、PowerShell コマンドレットを個々のクラスターのメンバーに対して実行する必要があります。

Windows Server 2012 R2 以降で実行する場合、Exchange 2013 の Service Pack 1 (SP1) 以降を適用することで、クラスター管理アクセスポイントなしで DAG を作成できます。管理アクセスポイントなしで DAG を作成するには、Exchange 管理センターを使用するか、シェルを使用します。詳細については、「DAG の作成」および「データベース可用性グループを作成する」を参照してください。