Exchange Server 2010

[アーティクル]
11/10/2015

Microsoft Exchange Server 2010 で高可用性を確保する

William R. Stanek

Exchange Server 2010 の高可用性機能
データベース可用性グループについて

メールボックスデータベースとデータベースに含まれるデータは、すべての Exchange 組織に不可欠です。メールボックスデータベースの高可用性を確保するため、Exchange Server 2007 では、ローカル連続レプリケーション、シングルコピークラスター、クラスター化メールボックスサーバーなど、さまざまなレプリケーションとクラスタリングのオプションが用意されていました。これらの機能によって可用性が以前のバージョンよりも向上しましたが、実装に関する問題が少なからずありました。1 つは、可用性を高める方法がそれぞれ異なる方法で管理されていたことです。シングルコピークラスターの場合、クラスター内のすべてのメールボックスで共有記憶域が使用されました。クラスターを実装するには、Exchange Server の管理者は Windows フェールオーバークラスタリングを構成する必要がありました。この作業は非常に複雑で、長い稼働時間を実現するには管理者が長時間作業しなければならないこともありました。連続レプリケーションの場合、組み込みの非同期レプリケーションを使用してデータのコピーが作成され、このコピーの管理にはトランザクションログの配布と再生の機能が使用されました。クラスター化されていない環境ではローカル連続レプリケーションを使用してローカルコピーを作成し、クラスター化されている環境ではクラスター連続レプリケーションまたはスタンバイ連続レプリケーションを使用していたので、連続レプリケーションによって管理方法が異なっていました。

Exchange Server 2010 では、高可用性がコアアーキテクチャに統合されたので、可用性を高める方法がまったく異なります。この新しい方法によって、サービスの可用性、データの可用性、および自動回復を実現するエンドツーエンドのソリューションが提供されます。この結果、これまで使用されていた多数の異なるソリューションの代わりに、1 つの主要な高可用性ソリューションを使用できるようになりました。このソリューションがデータベース可用性グループ (DAG) です。

DAG では、サーバーレベルではなくデータベースレベルで自動フェールオーバーと回復が行われ、メールボックスデータベースのコピーが複数格納された複数のメールボックスサーバーを展開する場合もクラスターは不要です。このような変更により、高可用性メールボックスサーバーソリューションの構築にクラスターハードウェアを用意したり、高度なスキルが必要なクラスター構成を行う必要がなくなりました。DAG では高可用性を実現するための基本コンポーネントが提供され、同じ DAG に含まれるメールボックスデータベースでは自動的にフェールオーバーが行われます。DAG は複数の Active Directory サイトに拡張できます。しかもメールボックスサーバーの関連するアーキテクチャが変更されているので、1 つのメールボックスデータベースを複数の Active Directory サイト間で移動できます。したがって、ある Active Directory サイトのメールボックスデータベースを別の Active Directory サイトにフェールオーバーできます。

ここで言うデータベースのコピーはメールボックスデータベースのみを対象としていることに注意する必要があります。パブリックフォルダーデータベースの冗長性と高可用性を確保するには、パブリックフォルダーのレプリケーションを使用します。クラスター連続レプリケーションでは、同じクラスター内に複数のパブリックフォルダーデータベースのコピーを保持することはできませんが、DAG に含まれるサーバー間ではパブリックフォルダーデータベースをレプリケートできます。

DAG について詳しく説明する前に、Exchange Server 2010 で変更された他の高可用性のオプションについて見てみましょう。

Exchange Server 2010 の高可用性機能の概要

以前のバージョンの Exchange Server は、クラスターリソース管理モデルを使用するクラスターアプリケーションとして機能していました。この方法では、メールボックスサーバーの高可用性を実装する場合、まず Windows フェールオーバークラスターを作成し、次に Exchange セットアップをクラスター化されたモードで実行しました。セットアッププロセスの一環として Exchange クラスターリソース DLL (exres.dll) が登録され、クラスター化メールボックスサーバーを作成できるようになりました。これに対し、Exchange Server 2010 は、クラスターアプリケーションとして機能しないので、可用性を高めるためにクラスターリソース管理モデルは使用されなくなりました。Exchange クラスターリソース DLL と、この DLL で提供されるすべてのクラスターリソースは存在しなくなりました。Exchange Server 2010 では、内部に用意された独自の高可用性モデルが使用されます。このモデルでも Windows フェールオーバークラスタリングの一部のコンポーネントは使用されていますが、Exchange Server 2010 で完全に管理されています。

非常に興味深いことに、基盤となるレプリケーションテクノロジの多くは存続しており、これらのテクノロジは進化し、機能が大きく変化しています。Exchange Server 2010 ではストレージグループが廃止されたので、連続レプリケーションはデータベースレベルで実行されます。また、サーバーメッセージブロック (SMB) を使用してログ配布とシードが行われるのではなく、管理者が定義した単一の TCP ポートを使用してデータが転送されます。この際、パッシブコピーを使用して、閉じられたログファイルをアクティブコピーからプルするのではなく、アクティブコピーによってログファイルがパッシブコピーにプッシュされ、データストリームは暗号化によってセキュリティで保護されるか、レプリケートされたデータのサイズを減らすために圧縮されます。以前のバージョンの Exchange Server ではデータベースのアクティブコピーだけをシードと再シードに使用できましたが、Exchange Server 2010 では、メールボックスデータベースのアクティブコピーとパッシブコピーの両方をシードと再シードのソースに指定できるので、より簡単にデータベースのコピーを別のメールボックスサーバーに追加できます。

もう 1 つの重要な変更点は、データのレプリケート方法に関するものです。Exchange Server 2007 では、Microsoft Exchange Replication Service によって、データベースのパッシブコピーにログが再生され、I/O の読み取り操作の削減に使用される読み取り/書込み操作のキャッシュが構築されました。しかし、データベースのパッシブコピーをアクティブにしたときに、データベースをマウントしていた Microsoft Exchange Information Store サービスでキャッシュが使用可能にされなかったので、データベースキャッシュは失われていました。つまり、準備の整ったキャッシュがないコールド状態でパッシブコピーがアクティブになり、アクセスできるようになっていました。コールド状態とは、サーバーの再起動後やキャッシュを実行していたサービスの再起動後のデータベースキャッシュと同じ状態です。コールド状態になっていたので、サーバーにはキャッシュされた読み取り/書き込み操作が存在しませんでした。この状況では、通常、サーバーのディスク I/O を削減できるくらいキャッシュのサイズが増加するまで、読み取り I/O 操作の回数が増加しました。これに対して、Exchange Server 2010 では、Microsoft Exchange Information Store サービスによってログが再生されてマウント操作が処理されるので、パッシブコピーがアクティブになりアクセスできるようになったときにキャッシュを使用できます。この結果、切り替えやフェールオーバーが発生した後に、サーバーでキャッシュを使用して読み取り I/O 操作を削減できる可能性が高くなります。

可用性の高いメールボックスサーバーでは、電子メールメッセージはメールボックスで受信されれば安全です。しかし、転送中の電子メールメッセージの保護となると話は別です。メッセージの処理中にハブトランスポートサーバーで障害が発生して回復できないと、メッセージは失われます。Exchange Server 2007 では、データの損失を防止する手段として、トランスポート収集機能が導入されました。この機能によって、ローカル連続レプリケーションまたはクラスター連続レプリケーションでメールボックスが保護されている受信者に最近配信されたメッセージのキューが、ハブトランスポートサーバーで保持されるようになりました。メッセージは、管理者が定義した期間制限やサイズ制限に達するまでトランスポート収集で保持されました。フェールオーバーが発生すると、クラスター化メールボックスサーバーによって、Active Directory サイト内のすべてのハブトランスポートサーバーに、トランスポート収集のキューからメールを再送信することが要求されました。この方法により、クラスターのフェールオーバー中にメールが失われることがなくなりました。この方法は効果的でしたが、これを使用できるのは連続レプリケーション環境のメッセージ配信だけで、メッセージがハブトランスポートサーバーとエッジトランスポートサーバーの間で転送されているときに発生するメッセージの損失には対処していませんでした。

Exchange Server 2010 では、このような弱点にいくつかの方法で対処しています。トランスポート収集ではフィードバックを受信して、配信およびレプリケートされたメッセージが特定されるようになりました。ハブトランスポートサーバーでは、DAG 内のレプリケートされたメールボックスデータベースに送信されたメッセージのコピーが保持されます。メッセージを表すトランザクションログがメールボックスデータベースのすべてのコピーに正常にレプリケートされて検査されたことがハブトランスポートサーバーに通知されるまで、このコピーはトランスポートキュー (mail.que) に保持されます。通知されると、トランスポート収集のログが切り詰められるので、トランスポート収集のキューには、トランザクションログがレプリケートされていないメッセージのコピーだけが保持されるようになります。また、ある Active Directory サイトのメールボックスデータベースが別の Active Directory サイトにフェールオーバーすると、トランスポート収集による再配信要求がフェールオーバー元とフェールオーバー先の両方のサイトに送信されます。

転送中にメッセージの冗長性を確保するため、Exchange Server 2010 にはシャドウ冗長機能が追加されました。シャドウ冗長で使用される方法はトランスポート収集と似ています。ただし、シャドウ冗長では、メッセージの後続のホップすべてで配信が完了したことがトランスポートサーバーで確認されるまで、トランスポートデータベースからメッセージが削除されません。トランスポートサーバーで次のホップの配信を確認できない場合は、次のホップが配信されるようにメッセージが再送信されます。このようにすると、複数のサーバーにメッセージの重複コピーを作成するよりも使用する帯域幅が少なくなります。この方法で発生する追加のネットワークトラフィックは、トランスポートサーバー間での discard status message (破棄状態メッセージ) のやり取りだけです。discard status message (破棄状態メッセージ) は、Shadow Redundancy Manager (シャドウ冗長マネージャー) によって生成され、トランスポートデータベースから電子メールメッセージを破棄できるタイミングを示します。

シャドウ冗長は簡易メール転送プロトコル (SMTP) サービスの拡張機能です。SMTP で接続されている両方のサーバーでこの機能がサポートされていれば使用されます。ルーティングトポロジに冗長なメッセージパスが存在していると、シャドウ冗長によって、特定のハブサーバーやエッジトランスポートサーバーの状態への依存が解消されるので、任意のトランスポートサーバーを破棄できるようになります。この場合、トランスポートサーバーで障害が発生したり、保守のためにトランスポートサーバーをオフラインにする必要があれば、キューを空にしたりメッセージの損失を気にしたりせずに、サーバーの削除、置換、またはアップグレードによってサーバーを破棄できます。

Shadow Redundancy Manager (シャドウ冗長マネージャー) では、ハートビートという手法を使用して、シャドウメッセージがキューに入れられるサーバーの可用性を判断します。接続元のサーバーから XQUERYDISCARD メッセージが発行されると、接続先サーバーから破棄の通知が返されます。この通知のやり取りがハートビートです。

ハートビートのタイムアウト間隔に指定されている時間 (既定値は 300 秒) 内にプライマリサーバーへの接続を確立できない場合、サーバーでタイマーがリセットされ、最大 3 回 (ハートビートの再試行回数の既定値) 再試行されます。再試行回数の上限に達してもプライマリサーバーから応答を受信できない場合は、サーバーではプライマリサーバーで障害が発生したと認識され、シャドウメッセージの所有権が引き継がれて、メッセージが再送信されます。その後、メッセージは適切な配信先に配信されます。元のデータベースを格納している元のプライマリサーバーがオンラインに復帰した場合など、シナリオによってはメッセージが重複して配信されることがあります。Exchange Server には重複するメッセージを検出する機能があるので、Exchange メールボックスのユーザーがメッセージを重複して受信することはありませんが、Exchange Server 以外のメールボックスサーバーを使用する受信者は、メッセージを重複して受信することがあります。

DAG について

これまでに説明した多数の高可用性に関する機能強化は重要ですが、Exchange Server 2010 の管理方法に最も大きな影響を与える機能は、データベース可用性グループ (DAG) です。DAG は、Exchange Server 2010 の高可用性を実現する基本コンポーネントです。DAG の規則は単純です。各 DAG には、最大 16 台のメールボックスサーバーをメンバーとして含めることができます。各メールボックスサーバーがメンバーになれる DAG は 1 つだけで、各メールボックスサーバーではデータベースごとにコピーを 1 つだけホストできます。ホストされるコピーは、アクティブコピーとパッシブコピーのどちらでもかまいません。アクティブコピーは、実際に使用されユーザーがアクセスする点で、オフラインのパッシブコピーと異なります。同一サーバー上に同じデータベースのコピーを 2 つ作成することはできません。この規則に従えば、DAG 内の任意のサーバーで、DAG 内の他のサーバーにある任意のデータベースのコピーをホストできます。同時に複数のデータベースをアクティブにすることは可能ですが、特定のデータベースの複数のコピーを同時にアクティブにすることはできません。また、1 つのデータベースについて、DAG 内の他のサーバーでホストできるパッシブコピーは最大で 15 個です。

Exchange 組織で最初の DAG を作成すると、Exchange Server によって Windows フェールオーバークラスターが作成されますが、Exchange Server のクラスターグループは存在せず、クラスター内に記憶域リソースはありません。DAG では、Windows フェールオーバークラスターのクラスターハートビート、クラスターネットワーク、およびクラスターデータベース機能のみが使用されます。クラスターハートビートは、障害の検出に使用します。各 DAG には、少なくとも 1 つのレプリケーショントラフィック用のネットワークに加え、少なくとも 1 つの MAPI と他のトラフィック用のネットワークが必要です。クラスターデータベースには、データベースの状態の変更など、重要な情報が格納されます。DAG にサーバーを追加すると、サーバーは基になっているクラスターに参加し、メンバーサーバーの数に基づいてクラスターのクォーラムモデルが自動的に適宜変更されます。

Active Manager (アクティブマネージャー) は、リソースモデルとフェールオーバー管理の機能を提供する Exchange Server 2010 のコンポーネントです。Active Manager (アクティブマネージャー) は DAG のメンバーであるすべてのメールボックスサーバーで実行され、特定のデータベースの中心的な役割を果たすコンポーネント (Primary Active Manager: プライマリアクティブマネージャー)、またはスタンバイしている補助的な役割を果たすコンポーネント (Standby Active Manager: スタンバイアクティブマネージャー) のいずれかとして機能します。プライマリマネージャーでは、アクティブにするデータベースとアクティブにするコピーを決定し、トポロジの変更通知を受信してサーバーの障害に対応します。また、クラスタークォーラムリソースも所有します。Primary Active Manager (プライマリアクティブマネージャー) として機能するサーバーで障害が発生すると、その役割が自動的に DAG 内の別のサーバーに引き継がれ、そのサーバーでクラスタークォーラムリソースが所有されます。

セカンダリマネージャーでは、レプリケートされたローカルデータベースとローカルインフォメーションストアの障害を検出し、プライマリマネージャーに障害の通知を発行して、フェールオーバーを開始するように依頼します。セカンダリマネージャーでは引き継ぎ先のサーバーが決定されず、データベースの場所の状態も更新されません。これらの処理はプライマリマネージャーで実行されます。アクティブなデータベースで障害が発生すると、Active Manager (アクティブマネージャー) では Best Copy Selection (最適なコピーの選択) アルゴリズムを使用してアクティブにするデータベースのコピーを選択します。このアルゴリズムでは、データベースのコピーを、データベースの状態、コンテンツインデックスの状態、コピーキューの長さ、および再生キューの長さに基づいて評価し、アクティブにする最適なデータベースを特定します。選択条件に複数のデータベースコピーが該当する場合は、アクティブ化優先順位の値が使用され、優先順位の値が最も小さいデータベースがアクティブになりマウントされます。

DAG にサーバーを追加すると、各サーバーのアクティブなデータベースを DAG 内の他のサーバーにレプリケートでき、データベースレプリケーション用のネットワーク暗号化やネットワーク圧縮など、その他の DAG のプロパティを構成できます。DAG 内では、メールボックスデータベースのコピーをホストする各メンバーサーバーにトランザクションログがレプリケートされ、メールボックスデータベースのコピーに再生されます。複数のデータベースコピーを作成したら、Exchange 管理コンソールや Exchange 管理シェルを使用して DAG のレプリケーションと正常性の状態を監視できます。障害時には自動的にデータベースのフェールオーバーが行われますが、手動で切り替えを開始することもできます。切り替え時には、アクティブコピーがマウント解除され、DAG 内の別のサーバーにあるパッシブコピーがマウントされてアクティブコピーになります。

正真正銘の簡略化

この記事で説明したように、コアへの高可用性機能の統合、可用性を高めるアーキテクチャの変更など、Exchange Server 2010 には可用性を高める多数の重要な機能強化が施されています。新機能や変更された機能の中で、私のお気に入りは DAG です。DAG によってクラスターの実装が本当に簡略化され、IT プロフェッショナルは最も重要なものであるデータに集中できます。この記事が皆さんのお役に立つことを願っています。また、私の新著『Exchange Server 2010 Administrator's Pocket Consultant』、『Windows 7 Administrator's Pocket Consultant』、および『Windows Server 2008 Administrator's Pocket Consultant, 2nd Edition』をご覧いただればさいわいです。

William R. Stanek (williamstanek.com、英語) は、先駆者的なテクノロジの専門家で、優秀なトレーナーや 100 冊以上もの優れた書籍の著者としても活躍しています。好評発売中の書籍と予約受付中の著書には、『Active Directory Administrator's Pocket Consultant』、『Group Policy Administrator's Pocket Consultant』、『Windows 7 Administrator's Pocket Consultant』、『Exchange Server 2010 Administrator's Pocket Consultant』、『Windows Server 2008 Inside Out』などがあります。Twitter (https://twitter.com/WilliamStanek、英語) で Stanek をフォローしてみてください。