データベース可用性グループについて

  • [アーティクル]

 

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2015-03-09

データベース可用性グループ (DAG) は、Microsoft Exchange Server 2010 に組み込まれている、高可用性およびサイト復元のフレームワークの基本コンポーネントです。DAG とは、一連のデータベースをホストし、個々のサーバーまたはデータベースに影響を与える障害からデータベース レベルを自動回復させる、最大 16 台のメールボックス サーバーからなるグループのことです。

DAG はメールボックス データベースのレプリケーション、データベースおよびサーバーの切り替え、フェールオーバー、および Active Manager と呼ばれる Exchange 2010 内部コンポーネントの境界です。Active Manager は DAG のすべてのサーバーで実行され、切り替えとフェールオーバーを管理します。Active Manager の詳細については、「アクティブ マネージャーについて」を参照してください。

DAG 内のサーバーは、DAG 内の他のサーバーからのメールボックス データベースのコピーをホストできます。サーバーは DAG に追加されると、DAG 内の他のサーバーと連動して、ディスク障害やサーバー障害などのメールボックス データベースに影響を与える障害からの自動的な回復を提供します。

目次

データベース可用性グループのライフサイクル

高可用性を実現するためのデータベース可用性グループの使用

サイト復元を実現するためのデータベース可用性グループの使用

データベース可用性グループ使用時のクライアントの動作

データベース可用性グループのライフサイクル

DAG によって、増分展開という Exchange 2010 の機能が活用できます。これは、Exchange をインストールした後に、すべてのメールボックスのサーバーおよびデータベースに、サービスとデータの可用性を展開するための機能です。Exchange 2010 を展開した後、DAG を作成し、メールボックス サーバーを DAG に追加して、DAG メンバーの間でメールボックス データベースをレプリケートできます。

注意

サーバーとソリューションが Exchange 2010 のシステム要件 に準拠している場合は、物理メールボックス サーバーと仮想メールボックス サーバーを組み合わせた DAG を作成することがサポートされます。すべての Exchange 高可用性構成の場合と同様、スケジュールされた停止またはスケジュールされていない停止時に必要な負荷を処理するように DAG のすべてのメールボックス サーバーが適切にサイジングされていることを確認する必要があります。

New-DatabaseAvailabilityGroup コマンドレットを使用して DAG が作成されます。Active Directory に空のオブジェクトとして最初に DAG が作成されます。このディレクトリ オブジェクトは、サーバー メンバーシップ情報などの DAG に関連する情報を格納するために使用されます。最初のサーバーを DAG に追加すると、フェールオーバー クラスターが DAG 用に自動作成されます。このフェールオーバー クラスターは DAG によって排他的に使用される DAG 専用のものである必要があります。このクラスターの他の目的での使用はサポートされていません。

フェールオーバー クラスターが作成されるほか、ネットワーク障害またはサーバー障害がないかサーバーを監視するインフラストラクチャが開始されます。フェールオーバー クラスターのハートビート機構とクラスター データベースは、データベース マウント状態、レプリケーション状態、および最終マウント位置など、急速に変化する DAG 関連情報を追跡および管理するために使用されます。

DAG には作成時に一意の名前が付けられ、1 つまたは複数の静的 IP アドレスが割り当てられるか、動的ホスト構成プロトコル (DHCP) を使用するよう構成されます。DatabaseAvailabilityGroupIPAddresses パラメーターを使用して、単一の IP アドレスまたは IP アドレスのコンマ区切りリストを指定できます。

この例では、3 台のサーバーがある DAG を示します。2 台のサーバー (EX1 および EX2) が同じサブネット上 (10.0.0.0) にあり、3 台目のサーバー (EX3) が別のサブネット上 (192.168.0.0) にあります。

New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

注意

DatabaseAvailabilityGroupIPAddresses パラメーターを「0.0.0.0」の値で構成すると、DAG (クラスター) は、IP アドレスまたは IP アドレス リソースに DHCP を使用するように構成されます。

DAG1 のクラスターは、EX1 が DAG に追加される際に作成されます。クラスターの作成中に、Add-DatabaseAvailabilityGroupServer コマンドレットによって DAG 向けに構成された IP アドレスが取得され、EX1 で見つかったサブネットのいずれにも一致しない IP アドレスは無視されます。この例では、DAG1 のクラスターは IP アドレス「10.0.0.5」で作成され、「192.168.0.5」は無視されています。

次に EX2 が追加され、Add-DatabaseAvailabilityGroupServer コマンドレットで DAG 向けに構成された IP アドレスを再取得します。EX2 が EX1 と同じサブネット上にあるため、クラスターの IP アドレスは変更されません。

次に EX3 が追加され、Add-DatabaseAvailabilityGroupServer コマンドレットで DAG 向けに構成された IP アドレスを再取得します。EX3 に「192.168.0.5」と一致するサブネットがあるため、アドレス「192.168.0.5」はクラスター グループの IP アドレス リソースとして追加されます。また、各 IP アドレス リソースのネットワーク名リソースに OR の依存関係が自動的に構成されます。「192.168.0.5」というアドレスは、クラスター グループが EX3 に移動する際に、クラスターによって使用されます。

ネットワーク名リソースがオンラインになる際に、Windows フェールオーバー クラスタリングによって、ドメイン ネーム システム (DNS) 内のクラスターに IP アドレスが登録されます。さらに、Active Directory にクラスター名オブジェクト (CNO) が作成されます。クラスターの名前、IP アドレス、および CNO は、DAG のセキュリティ保護と内部通信のため、システムによって内部でのみ使用されます。管理者とエンドユーザーは、何らかの理由で DAG 名または IP アドレスとインターフェイスしたり接続したりする必要はありません。

DAG は、1 つの名前および 1 つ以上の IP アドレスのほか、ミラーリング監視サーバーとミラーリング監視ディレクトリも使用するよう構成されます。ミラーリング監視サーバーとミラーリング監視ディレクトリは、システムによって自動的に指定されるか、管理者によって手動で指定されます。

DAG は既定で、DAG 内のサーバー間でのメールボックス データベースのレプリケートに、組み込みの連続レプリケーション機能を使用するよう設計されています。Exchange 2010 で、サードパーティ レプリケーション API をサポートするサードパーティ データ レプリケーションを使用している場合、ThirdPartyReplication パラメーターで New-DatabaseAvailabilityGroup コマンドレットを使用して、DAG をサードパーティ レプリケーション モードで作成する必要があります。このモードを有効にすると、無効にすることはできません。

DAG が作成されると、メールボックス サーバーを DAG に追加できます。DAG に 1 番目のサーバーが追加されると、DAG が使用するためにクラスターが形成されます。DAG は、特にクラスター ハートビート、クラスター ネットワーク、およびクラスター データベースなど、Windows フェールオーバー クラスタリング テクノロジを限定的に使用します。クラスター データベースは、アクティブとパッシブ、マウントとマウント解除の切り替えなど、データベース状態を変更するデータの格納に使用されます。2 台目以降の各サーバーが DAG に追加される際、それが基になるクラスターに追加され、システムによってクラスターのクォーラム モデルが自動的に調整されて、サーバーが Active Directory の DAG オブジェクトに追加されます。

メールボックス サーバーが DAG に追加されると、DAG でのデータベース レプリケーションにネットワーク暗号化やネットワーク圧縮を使用するかどうかなど、さまざまな DAG プロパティを構成できます。また、DAG ネットワークの構成および追加の DAG ネットワークの作成を行うことができます。

DAG にメンバーを追加して DAG を構成した後、各サーバー上のアクティブ メールボックス データベースを他の DAG メンバーにレプリケートできます。メールボックス データベースのコピーを作成した後、さまざまな組み込みの監視ツールを使用してコピーの正常性と状態を監視できます。また、データベースとサーバーの切り替えも実行できます。

DAG の作成、DAG メンバーシップの管理、DAG プロパティの構成、メールボックス データベース コピーの作成と監視、および切り替えの実行の詳細については、「高可用性とサイト復元の管理」を参照してください。

データベース可用性グループのクォーラム モデル

このモードでは、すべての DAG が Windows フェールオーバー クラスターです。フェールオーバー クラスターではクォーラムという概念が使用され、クラスター メンバーの一部のみ (すべてのメンバーであることも、大多数のメンバーであることもある) が同時に機能していることを確認するため、投票者の総意が使用されます。クォーラムは Exchange 2010 での新しいコンセプトではありません。前のバージョンの Exchange でも、高可用性メールボックス サーバーはフェールオーバー クラスターとそのクォーラムの概念を使用しています。クォーラムはメンバーとリソースの共有表示を表します。クォーラムという用語は、すべてのクラスター メンバー間で共有されるクラスター内の構成を表す物理データを説明する目的でも用いられます。結果としてすべての DAG では、クォーラムを保持するために、基盤となるフェールオーバー クラスターが必要となります。クラスターがクォーラムを喪失すると、すべての DAG 操作は終了し、DAG でホストされているマウント済みのすべてのデータベースはマウント解除されます。この場合は管理者が介入し、クォーラムの問題を解決して DAG 操作を復元する必要があります。

クォーラムは次のように、一貫性を確保し、分割を回避するためのタイ ブレーカーとして機能し、クラスターの応答を確保するために重要です。

  • 一貫性の確保   各メンバーが、常に他のメンバーと共通のクラスターを表示できるのが、Windows フェールオーバー クラスターの基本要件です。クラスター ハイブは、クラスターに関連するすべての構成情報の最終リポジトリとして動作します。クラスター ハイブをローカルで DAG メンバーに読み込みことができない場合は、クラスター サービスが開始されません。これは、そのメンバーが他のメンバーと共通のクラスターを表示するという要件に適合することが保証できないためです。

  • タイ ブレーカーとしての機能   クォーラム監視リソースは、偶数のメンバーが含まれる DAG 内で使用されます。このリソースの用途は、スプリット ブレイン現象のシナリオを回避し、DAG のメンバーの 1 つのコレクションのみが公式と見なされるようにすることです。クォーラムでミラーリング監視サーバーが必要な場合、ミラーリング監視サーバーと通信できる DAG のメンバーは、ミラーリング監視サーバーの witness.log ファイルにサーバー メッセージ ブロック (SMB) ロックをかけることができます。(ロッキング ノードと呼ばれる) ミラーリング監視サーバーをロックする DAG メンバーは、クォーラムのための追加票を保持しています。ロッキング ノードとやり取りする DAG メンバーが大多数であり、このメンバーはクォーラムを保持しています。ロッキング ノードとやり取りできない DAG メンバーは少数です。このメンバーはロッキング ノードとやり取りできないため、クォーラムを失います。

  • 応答の確保   応答の確保のため、クォーラム モデルは、クラスター実行時には常に十分な数の分散システムのメンバーを動作可能で通信可能な状態にしておき、クラスターの最新状態のレプリカを 1 つ以上保証できるようにしています。メンバーを通信状態にしたり、特定のレプリカが保証されているかどうかを確認するのに、特に時間はかかりません。

偶数のメンバーが含まれる DAG は、フェールオーバー クラスターのノードとファイル共有マジョリティ クォーラム モードを使用します。この場合、タイ ブレーカーとして機能する外部のミラーリング監視サーバーが使用されます。このクォーラム モードでは、各 DAG メンバーが投票権を取得します。また、ある DAG メンバーに荷重投票権を提供する (1 票ではなく 2 票というように) ためにミラーリング監視サーバーが使用されます。既定で、各 DAG メンバーのシステム ディスクにクラスター クォーラム データが格納され、ディスク間で一貫性が保たれます。ただし、クォーラム データのコピーはミラーリング監視サーバーに格納されません。ミラーリング監視サーバー上のファイルは、どのメンバーがデータの最新コピーを持っているかを追跡するために使用されますが、ミラーリング監視サーバーにはクラスター クォーラム データのコピーがありません。このモードでは、クォーラムを保持するために、投票者 ( DAG メンバーとミラーリング監視サーバー) の大多数が動作可能で、相互に通信できる必要があります。大多数の投票者が相互に通信できない場合は、DAG の基盤となるクラスターがクォーラムを喪失します。この場合は、管理者が介入して DAG を再度動作可能にする必要があります。

奇数のメンバーが含まれる DAG は、フェールオーバー クラスターのノード マジョリティ クォーラム モードを使用します。このモードでは、各メンバーが票を取得し、各メンバーのローカル システム ディスクを使用してクラスター クォーラム データが格納されます。DAG の構成が変更されると、その変更が別のディスクにも反映されます。メンバーの半数 (切り捨て) + 1 のディスクで変更が行われた場合にのみ、その変更はコミットされたと見なされて永続的なものになります。たとえば、DAG のメンバー数が 5 である場合は、2 + 1、つまり合計 3 のメンバーで変更が行われる必要があります。

クォーラムでは、投票者の大多数が互いに通信できる必要があります。メンバー数が 4 である DAG の場合を考えてみましょう。この DAG には偶数のメンバーが含まれるため、外部のミラーリング監視サーバーを使用して 5 番目のタイ ブレーク票がいずれかのクラスター メンバーに提供されます。大多数の投票者 (およびクォーラム) を保持するには、3 つ以上の投票者が互いに通信できる必要があります。 サービスおよびデータ アクセスを中断せずにオフラインにできるのは、常に 2 つの投票者までです。3 つ以上の投票者がオフラインになると、DAG がクォーラムを喪失し、問題が解決されるまでサービスとデータ アクセスが中断されます。

ページのトップへ

高可用性を実現するためのデータベース可用性グループの使用

DAG によるメールボックス データベースの高可用性の実現方法を理解するため、5 つのメンバーを持つ DAG を使用する次の例を考えてみます。この DAG を以下の図に示します。

5 つのメンバーが含まれる DAG

データベース可用性グループ

上の図では、緑のデータベースがアクティブ メールボックス データベースのコピー、青のデータベースがパッシブ メールボックス データベースのコピーです。この例では、データベース コピーは各サーバーでミラー化されていませんが、複数のサーバーに分散されています。これによって、DAG 内の 2 台のサーバーで同じデータベース コピーのセットを持つことがなくなり、DAG が障害に対して優れた復元性を持つようになります。この障害には、定期的な保守のため他のコンポーネントが使用できない間に発生する障害が含まれます。

上の例の DAG を使用して、次のシナリオで複数のデータベースおよびサーバーの障害に対する復元性について説明します。

最初は、すべてのデータベースとサーバーが正常です。EX2 にオペレーティング システム更新プログラムをインストールする必要があります。サーバーの切り替えを実行すると、他のメールボックス サーバー上にある DB4 のコピーがアクティブになります。サーバーの切り替えを実行すると、現在のサーバーのスケジュールされた停止に備えて、DAG 内のすべてのアクティブ メールボックス データベースのコピーが、現在のサーバーから他の 1 つ以上のメールボックス サーバーに移動されます。Exchange 管理シェルで以下のコマンドを実行することで、サーバーの切り替えを迅速に実行できます。

Move-ActiveMailboxDatabase -Server EX2

この例では、EX2 (DB4) にアクティブ メールボックス データベースが 1 つしかないので、アクティブ メールボックス データベースのコピーが 1 つだけ移動します。以下の図に示すように、上記のコマンドの ActivateOnServer パラメーターを省略することで、最適な新しいアクティブ コピーおよび EX5 にあるコピーが選択されるようにします。

保守のためのサーバー オフラインが含まれる DAG

サーバーがオフラインのデータベース可用性グループ

EX2 での保守の実行時に、EX3 で致命的なハードウェア障害が発生しオフラインになります。オフラインになる前に、EX3 は DB2 のアクティブ コピーをホストします。この障害から回復するため、システムは自動的に、EX1 でホストされている DB2 のコピーを 30 秒以内にアクティブ化します。これを以下の図で説明します。

保守のためのサーバー オフラインおよび障害が発生したサーバーが含まれる DAG

サーバーがオフラインで失敗している DAG

EX2 でスケジュールされた保守を完了した後、サーバーをオンラインにします。EX2 が使用可能になると DAG の他のメンバーに通知され、EX2 上でホストされている DB1、DB4、および DB5 のコピーが自動的に各データベースのアクティブ コピーと同期されます。これを以下の図で説明します。

自身のデータベース コピーと同期する復元サーバーが含まれる DAG

復元したサーバーがデータベースを再同期している DAG

EX3 で障害の発生したハードウェア コンポーネントが新しいコンポーネントと置き換えられると、EX3 がオンラインになります。EX3 が使用可能になると、DAG の他のメンバーに通知され、EX3 上でホストされている DB2、DB3、および DB4 のコピーが自動的に各データベースのアクティブ コピーと同期されます。これを以下の図で説明します。

自身のデータベース コピーと同期する修復されたサーバーが含まれる DAG

メンバーがデータベース コピーを再同期している DAG

ページのトップへ

サイト復元を実現するためのデータベース可用性グループの使用

DAG はデータセンター内での高可用性を実現するだけでなく、構成内の 1 つ以上のデータセンターに拡張できます。これにより、1 つまたは複数のデータセンターでサイトが復元できます。上記の例の図では、DAG が単一のデータセンターおよび単一の Active Directory サイトにあります。メールボックス サーバーおよび必要なサポート リソース (1 つ以上の Active Directory サーバー、および 1 つ以上のハブ トランスポート サーバーとクライアント アクセス サーバー) を展開し、この DAG を第 2 データセンター (および第 2 Active Directory サイト) に拡張するには、増分展開を使用できます。この場合は、次の図のように、メールボックス サーバーを DAG に追加します。

2 つの Active Directory サイト間にわたる DAG

2 つの Active Directory サイト間にわたる DAG

この例では、Redmond データセンター内の各アクティブ データベースのパッシブ コピーが、Dublin データセンターの EX6 上で構成されます。ただし、サイト復元を実現する DAG 構成の例は、他にもたくさんあります。次に例を示します。

  • EX6 は、パッシブ データベース コピーのみをホストするのではなく、すべてのアクティブ コピー、またはアクティブ コピーとパッシブ コピーの組み合わせをホストできます。

  • EX6 のほか、複数の DAG メンバーを Dublin データセンターに展開し、別の障害に対して保護することができます。この構成によって追加容量も提供されるため、Redmond データセンターで障害が発生しても、Dublin データセンターを使用することでずっと多くのユーザー群をサポートできます。

サイト復元のための複数のデータベース可用性グループの使用

上記の例では、1 つの DAG を複数のデータセンターに拡張して、片方または両方のデータセンターでのサイト復元を実現していました。DAG の拡張先である各データセンターにアクティブ ユーザー群がある環境で、サイト復元に 1 つの DAG を使用する場合は、広域ネットワーク (WAN) 接続に単一障害点があります。これはクォーラムで、大多数の投票者がアクティブであり相互に通信できる必要があるためです。

上記の例では、大多数の投票者が Redmond データセンターに配置されています。Dublin データセンターがアクティブ メールボックス データベースをホストしており、Dublin データセンターにローカル ユーザー群が含まれる場合、WAN が停止すると Dublin ユーザーのメッセージング サービスが停止します。WAN 接続が切断されると、Redmond データセンターの DAG メンバーのみがクォーラムを保持して引き続きメッセージング サービスを提供することになります。

アクティブ ユーザー群が含まれる複数のデータセンターでサイト復元が必要な場合に、WAN が単一障害点にならないようにするには、複数の DAG を展開し、各 DAG が別々のデータセンターに大多数の投票者を持つようにする必要があります。WAN が停止すると、接続が復元されるまでレプリケーションがブロックされます。各 DAG が引き続き自身のローカル ユーザー群に対してサービスを提供するため、ユーザーはメッセージング サービスを利用できます。

ページのトップへ

データベース可用性グループ使用時のクライアントの動作

DAG は、高可用性とサイト復元の両方に使用できます。DAG 使用時のクライアントの動作は、クライアントがメールボックス データへのアクセスに使用するクライアントおよびプロトコルの種類とバージョンによって異なります。たとえば、サイト間でデータベース フェールオーバーが発生した場合、その動作と使用される再接続ロジックは、POP3 および IMAP4 クライアントと、Microsoft Outlook 2010 クライアントでは異なります。

次のセクションで、さまざまなシナリオにおけるクライアントの動作とロジックについて説明します。動作については、次の前提に基づいて説明します。

  • 各 Active Directory サイトにクライアント アクセス サーバー アレイが 1 台含まれており、各サイトに 2 台以上のクライアント アクセス サーバーが含まれる環境である。

  • ハードウェア ベース、またはソフトウェア ベースの適切な負荷分散装置が取り付けられており、クライアント アクセス サーバー アレイの前に構成されている。

  • 適切な名前空間および証明書の計画と構成 (必要な DNS レコードを含む) が完了している。

Microsoft Outlook の動作とロジック

通常、すべてのバージョンの Outlook は、1 つのデータセンターおよび 1 つの Active Directory サイト内でデータベース フェールオーバーが発生した場合、同じように動作します。Exchange で前のバージョンの Exchange 2010 と異なる点は、Outlook がメールボックス サーバーの Exchange ストアに直接接続しなくなったことです。代わりに、Outlook (および他の MAPI クライアント) がクライアント アクセス サーバーの役割上の RPC クライアント アクセスとアドレス帳サービスに接続し、ユーザーの Outlook がクライアント アクセス サーバー アレイに接続するよう構成されます。こうして、クライアントが個々のクライアント アクセス サーバーに接続されます。こうして メールボックス サーバーから Outlook 接続が分離されることによって、次のようなメリットがあります。

  • データベース フェールオーバーの発生時に、Outlook がクライアント アクセス サーバー アレイ内の同じサーバーに接続されたままとなります。この状態であれば、クライアント アクセス サーバー上で実行される Active Manager クライアントは、DAG の Active Manager から、どの DAG メンバーがアクティブ データベース コピーをホストしているかを認識します。次に、クライアント アクセス サーバーがそのメールボックス サーバーと接続し、Outlook に Exchange サーバーとの接続が表示されます。

  • スケジュールされた停止、またはスケジュールされていない停止によってクライアント アクセス サーバー アレイ内のクライアント アクセス サーバーの 1 つが使用できなくなると、アレイ内の残りのクライアント アクセス サーバーがクライアントの読み込みを処理します。Outlook は、個々のクライアント アクセス サーバーではなく、クライアント アクセス サーバー アレイと接続するよう構成されているため、ユーザーの Outlook プロファイルに影響することなく、クライアント アクセス サーバー アレイのメンバーで個々に障害が発生したり、メンバーが手動でオフラインにされたりする場合があります。これは、自動的に発生する場合 (アレイの前のロード バランサー ソリューションが実行する監視に基づく自動アレイ再構成など) も、手動で実行できる場合もあります。

また、Outlook のすべてのバージョンは、2 つのデータセンターと 2 つの Active Directory サイト間で発生する切り替えでは同じように動作します。データセンターの切り替えには、プライマリ データセンターの IP アドレスからセカンダリ データセンターの IP アドレスへの変更が含まれます。この IP アドレスは、クライアント アクセスの名前空間 (Microsoft Office Outlook Web App、SMTP、POP3、IMAP4、自動検出、Exchange Web サービス、RPC クライアント アクセスなど) が使用する IP アドレスです。この結果、ユーザーの Outlook プロファイルで使用される名前空間は変更されず、自動検出はクライアントを引き続き同じクライアント アクセス サーバー アレイの名前空間にポイントします。

サイト間でデータベース障害が発生した後の Outlook の動作は、1 つの Active Directory サイトでのデータベース障害発生後、またはデータセンターの切り替え後の動作とは異なります。

Outlook バージョンの動作の例

次の例では、サイト間でデータベース障害が発生した後の Outlook 2010、Office Outlook 2007 および Office Outlook 2003 の動作について説明します。それぞれの例で使用されるトポロジは、2 つの Active Directory サイト (Redmond と Portland) に拡張されている 4 つのメンバーを含む DAG です。ユーザーのメールボックスは DB1 上でホストされ、各サーバーにレプリケートされます。それぞれの例では、DB1 のアクティブ コピーが MBX2 から MBX3 へフェールオーバーされます。

サイト間のデータベース障害が発生した後の Outlook の動作を示すトポロジ例

データベース可用性グループでの Outlook の動作

各クライアントは、CAS1 でそのホーム サーバーとして構成され、Redmond が Outlook プロファイル サイトとなります。クライアントが Redmond に置かれているため、DB1 の RPCClientAccessServer プロパティは CAS1 用に構成され、Redmond が優先データベース サイトとなります。DB1 は MBX2 上でエラー、MBX3 上でアクティブとなっているため、Portland がマウントされたデータベース サイトです。

Outlook 2010 と Outlook 2007 の例

Redmond サイト内でクライアント アクセス サーバーが使用可能な場合、Outlook 2010 および Outlook 2007 は引き続き Redmond サイト内の RPC クライアント アクセス アレイに接続します。クライアントが使用しているクライアント アクセス サーバーは、MAPI RPC を使用して Portland サイト内のユーザー用メールボックス サーバーと通信します。

Redmond サイト内に使用可能なクライアント アクセス サーバーが存在しない場合、サービスおよびデータへのアクセスを回復するためには、Redmond から Portland へのデータセンターの切り替えを実行する必要があります。データセンターの切り替えを実行する手順の詳細については、「サーバー切り替えを実行する」を参照してください。

Outlook 2003 の例

Outlook 2003 が CAS1 と接続しようとすると、応答時に ecWrongServer も受信します。Outlook 2010 および Outlook 2007 とは異なり、Outlook 2003 には自動検出機能が含まれず、他の手段を使ってユーザーのプロファイルを更新する必要があります。MAPI プロファイルのリダイレクトは、Outlook 2003 によって使用されるメカニズムです。MAPI プロファイルのリダイレクトでは、元のソース サーバーがオンラインである必要があります。CAS1 が使用できず、アレイ内のその他のクライアント アクセス サーバーもすべて使用できない場合 (またはアレイに CAS1 しか含まれない場合)、Outlook 2003 は MAPI のリダイレクトを実行したり、手動操作なしでユーザーのメールボックス データベースに接続したりすることはできません。

パブリック フォルダー使用時の Outlook の動作とロジック

DAG のメンバーであるメールボックス サーバー上でパブリック フォルダー データベースをホストすることはできますが、パブリック フォルダー データベースは高可用性のために、連続レプリケーションではなくパブリック フォルダー レプリケーションを使用します。メールボックス データベースに障害が発生した後に、Outlook クライアントがパブリック フォルダー データベースに再接続する際の動作は、障害の種類だけでなく、パブリック フォルダーのレプリケーション構成設定と、パブリック フォルダー データベースの正常性と流れによって変わります。パブリック フォルダー データベース向けに連続レプリケーションを使用できないため、複数のパブリック フォルダー データベースを展開してそれを相互にレプリケートするよう構成することで、パブリック フォルダー データベースの高可用性を実現します。各フォルダーのレプリカを複数構成することをお勧めします。

Outlook 以外のクライアントの動作とロジック

通常、Outlook と MAPI 以外のクライアントとプロトコルの動作は、使用しているアプリケーションと障害のシナリオによって異なります。通常、Outlook と同様に、一般的な Exchange アプリケーションおよびクライアント (Outlook Web App、Microsoft Exchange ActiveSync、POP3、IMAP4、および Exchange Web サービスなど) は、1 つのデータセンターと 1 つの Active Directory サイト内で発生するデータベース フェールオーバーにおいて同じように動作します。同様に、データセンターの切り替え後に、このようなクライアントとプロトコル (SMTP と Windows PowerShell を含む) はすべて Outlook と同じように動作します。

サイト間のデータベース フェールオーバーが発生すると、これらのクライアントとプロトコル間で動作が変わります。次の表に、これらのクライアントの動作について示します。

一般的な Exchange クライアントでのサイト間のデータベース フェールオーバーの動作

クライアントまたはプロトコル 行動

Outlook Web App

手動によるリダイレクト。このシナリオでは、クライアントの名前空間が http://mailred.contoso.com から http://mailpdx.contoso.com に変更されています。ユーザーがログオン資格情報を入力すると、手動のリダイレクト ページを介して、Portland サイト内の CAS2 にリダイレクトされます。このリダイレクト ページには、正しくない URL が使用されたことと、正しい URL が https://mailpdx.contoso.com/owa である旨の説明が表示されます。

Exchange ActiveSync

プロキシまたはリダイレクト。このシナリオでは、クライアント デバイス上の Exchange ActiveSync プロトコルの実装とバージョンによって、クライアントの動作が決まります。

POP3 と IMAP4

プロキシ。このシナリオには、クライアント アクセス サーバー間のプロキシが常に含まれます。

Exchange Web サービス

自動検出を使用して新しい接続エンドポイントを決定します。

ページのトップへ

 © 2010 Microsoft Corporation.All rights reserved.