データベース可用性グループの設計例
適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3
トピックの最終更新日: 2010-10-01
最大 16 個のメールボックス サーバーを含めることが可能なデータベース可用性グループ (DAG) の機能を、物理的に複数の場所と Active Directory サイト間にまたがって DAG を拡張可能にする機能と組み合わせることで、DAG のアーキテクチャ設計の可能性が大きく広がりました。
さまざまな環境内で以下のような DAG の設計例を使用できます。
小規模オフィスや支社の展開に適した 2 メンバーの DAG
同じデータセンターに全メンバーを配置して単一のデータセンターに高可用性を実現する 4 メンバーの DAG
1 つのプライマリ データセンター内に 2 メンバー、第 2 データセンター内に 2 メンバーを配置することで、単一データセンター内での高可用性、および当該データセンターのサイトの復元を実現する 4 メンバーの DAG
DAG に対して使用する設計およびメールボックス データベース コピーの配布は、組織のサービス レベル契約 (SLA)、および組織の SLA に規定されたメールボックス サービスとデータの目標回復時間と目標回復ポイントに基づいて実施されます。
目次
単一データセンターと Active Directory サイト内の 2 メンバーの DAG
単一のデータセンター/Active Directory サイトにおける 4 メンバーの DAG
2 つのデータセンター/Active Directory サイトにおける 4 メンバーの DAG
2 つのデータセンター/Active Directory サイトにおける 2 つの 4 メンバー DAG
追加の投票のための DAG のデータベースを含まないメールボックス サーバーの使用
高可用性とサイト復元に関連する管理タスクについては、「高可用性とサイト復元の管理」を参照してください。
単一データセンターと Active Directory サイト内の 2 メンバーの DAG
2 メンバーの DAG は、高可用性を提供できる最小限の DAG です。2 メンバーの DAG は、メールボックス サービスとデータに対しては何らかの形の高可用性が必要であるが、サイトの復元は必要でない組織に最適です。この構成は、2 台の Exchange サーバーのみを使用して、クライアント アクセス サーバー、メールボックス サーバー、ハブ トランスポート サーバーの各役割に冗長性をもたせることが可能であるため、小規模オフィスと支社の展開で特に効果を発揮します。次の図は、この構成を示しています。
2 メンバーのデータベース可用性グループ
.gif "2 メンバーのデータベース可用性グループ")
この構成について以下のようないくつかの注目すべき側面があります。
この設計では、クライアント アクセス サーバー、メールボックス サーバー、およびハブ トランスポート サーバーの各役割のみを同じ場所に配置します。ユニファイド メッセージング サーバーの役割を同じ場所に配置することはサポートされていますが、パフォーマンスの理由から、その構成はお勧めしません。
クライアント アクセス サーバーとハブ トランスポート サーバーの各役割に対して高可用性を実現するには、クライアントとこれらのサーバーの役割の間で何らかの負荷分散を使用する必要があります。これらのサーバーの役割は DAG のメンバーであるメールボックス サーバーと同じ場所に配置されるため、Windows ネットワーク負荷分散を使用できません (ネットワーク負荷分散と Windows フェールオーバー クラスタリングは同じサーバーにインストールできないため)。代わりに、Windows 以外のネットワーク負荷分散ソリューションを使用する必要があります (たとえば、ハードウェア負荷分散やサード パーティのソフトウェア ベースの負荷分散など)。
偶数のメンバーを含めたすべての DAG と同様に、2 メンバーの DAG にはクォーラムを維持するミラーリング監視サーバーが必要になります。監視サーバー (図にはありません) は、現在も以後も DAG のメンバーにならない Windows サーバーです。たとえば、この構成を使用する小さな組織では、ファイル サーバーやディレクトリ サーバーを監視サーバーとして使用する可能性があります。クォーラムの投票者の半数以上が使用可能で通信状態であるかぎり、クォーラムは維持されます。監視サーバーを含む 2 メンバーの DAG では、3 つのクォーラム投票者が提供されます(各 DAG メンバーおよび監視サーバーは、使用可能で通信状態になったときにいつでも投票できます)。したがって、2 メンバーの DAG は、1 つの投票者 (たとえば、DAG メンバーのいずれか、あるいはミラーリング監視サーバーのみ) に障害が発生したり停止してもサービスを中断することなく生き延びることができます。ただし、投票者のうち 2 つ (たとえば 1 つの DAG メンバーと監視サーバー) が損失した場合には、クォーラムが失われ、サービスが中断します。
ページのトップへ
単一のデータセンター/Active Directory サイトにおける 4 メンバーの DAG
単一のデータセンターの展開での 4 メンバーの DAG は、2 メンバーの DAG や 3 メンバーの DAG よりも障害に対して優れた復元性を備えています。本来、より大規模な DAG はサービスを中断させることなく多くの障害に耐えられるため、より優れた復元性を備えています。2 メンバーまたは 3 メンバーの DAG では、2 つ以上の投票者を失うと、クォーラムを失い、サービスが低下しますが、定義上 5 つのクォーラム投票者を持つ 4 メンバーの DAG では、2 つの投票者を失っても、クォーラムは失われず、サービスも低下しません。
次の図は、すべてのメンバーを単一データセンターに配置した、4 メンバーの DAG を示しています。
4 メンバーのデータベース可用性グループ
.gif "4 メンバーのデータベース可用性グループ")
4 メンバーの DAG を使用すると、各データベースのコピーを最大 4 つまで作成できます。これは、柔軟性を備えたメールボックスの保護などの別のデータ保護シナリオを使用するのに十分なデータベース コピー数です。柔軟なメールボックスの保護により、Microsoft Exchange Server 2010 の高可用性と ESE (Extensible Storage Engine) 復元機能を、遅延メールボックス データベース コピー、保持ポリシー、回復可能なアイテム フォルダー、保留ポリシーなどの組み込みの保護機能と組み合わせて、RAID (Redundant Array of Independent Disks) の使用やデータ バックアップ作成といった他の形式の保護の必要性を低減できます。柔軟性を備えたメールボックス保護の詳細については、「バックアップ、復元、および障害復旧について」を参照してください。バックアップ用レプリケーションの使用と JBOD (Just a Bunch Of Disks) の使用の詳細については、「メールボックス サーバーの記憶域設計」を参照してください。
ページのトップへ
2 つのデータセンター/Active Directory サイトにおける 4 メンバーの DAG
2 つのデータセンター間にまたがる 4 メンバーの DAG は、両方のデータセンターに対して、メールボックス サービスとデータに対する高可用性とサイトの復元を提供します。この構成を以下の図に示します。
2 つのサイトにまたがる 4 メンバーのデータベース可用性グループ
.gif "2 サイト間のデータベース可用性グループ")
この構成について以下のようないくつかの注目すべき側面があります。
DAG のミラーリング監視サーバーは、プライマリ データセンターに配置する必要があります。一般に、プライマリ データセンターは、ユーザー人口の大多数を含めたデータセンターです。プライマリ データセンター内のミラーリング監視サーバーを使用すると、ワイド エリア ネットワーク (WAN) が停止した場合にユーザー人口の大多数に対して継続して機能を提供することが可能になります。複数の DAG を使用して、WAN が単一障害点にならないようにし、WAN の障害時に複数のデータセンターに対してサービスおよびデータ アクセスが機能を維持できるようにします。詳細については、次の例を参照してください。
1 つの DAG メンバー サーバーのレプリケーション ネットワークから別の DAG メンバー サーバーの MAPI ネットワーク、またはその逆のトラフィック、または DAG 内の複数のレプリケーション ネットワーク間のトラフィックを許可する直接ルーティングは存在しません。たとえば、DAG メンバーそれぞれの MAPI ネットワークと他の DAG ネットワークそれぞれのレプリケーション ネットワークの間のトラフィックをブロックしたいと仮定します(上の図では、MBX1A の MAPI ネットワークは、MBX1B または MBX2B のレプリケーション ネットワークと一切のネットワーク接続ができないようにする必要があります)。ルーターのアクセス制御リスト (ACL) を使用すると、このトラフィックをブロックすることができます。また、レプリケーション ネットワークで動的ホスト構成プロトコル (DHCP) を使用している場合は、DHCP を使用して DAG メンバーの静的ルートを構成できます。
この DAG 構成はサイト復元の提供を目的としているため、Exchange クライアント アクセス名前空間 (Microsoft OfficeOutlook Web App、自動検出、Microsoft Exchange ActiveSync、Outlook Anywhere、POP3、IMAP4、SMTP、および RPC クライアント アクセス アレイ) の TTL (Time to Live) 値を、外部と内部の両方の DNS ゾーンで 5 分に指定する必要があります。
この例では、Exchange サーバーの役割は専用のハードウェア上で展開されます。クライアント アクセス サーバーおよびハブ トランスポート サーバーの役割は、DAG 内のメールボックス サーバーと同じ場所には配置できないため、Windows ネットワーク負荷分散を使用して、クライアント アクセス サーバーおよびハブ トランスポート サーバーの役割を負荷分散します。
ページのトップへ
2 つのデータセンター/Active Directory サイトにおける 2 つの 4 メンバー DAG
上の例で示したように、2 つのデータセンターにまたがった単一の 4 メンバーの DAG を使用すると、メールボックスのサービスおよびデータの高可用性とサイト復元を提供できます。しかし、WAN の障害が発生した場合、プライマリ データセンターのみが、投票者の過半数を含んでいるためサービスを維持できます。投票者が少数派のデータセンターはマジョリティを失い、そのデータセンターの DAG メンバーはクォーラムを失ってオフラインになります。
それぞれがアクティブにローカル ユーザーにサービスを提供しているデータセンターが複数存在する環境で高可用性メールボックス サーバーを展開する場合は、次の図に示すように、複数の DAG を展開して各 DAG に異なるデータセンターの投票者の過半数を含めるようにします。
2 つのサイトにまたがる 2 つの 4 メンバー DAG
.gif "2 つのアクティブ データ センター間の 2 つの DAG")
DAG1 および DAG2 には偶数のメンバーが含まれているため、それぞれ監視サーバーを使用します。複数の DAG で同じ監視サーバーを使用できますが、個別のデータセンターで複数の監視サーバーを使用して、WAN の障害時に各データセンターのローカル ユーザーに対してサービスを維持します。
Portland に配置されたユーザーは、PDXMBX3 または PDXMBX4、あるいはその両方にアクティブ メールボックス データベースを、REDMBX3 または REDMBX4、あるいはその両方にパッシブ データベース コピーを持ちます。同様に、Redmond に配置されたユーザーは、REDMBX1 または REDMBX2、あるいはその両方にアクティブ メールボックス データベースを、PDXMBX1 または PDXMBX2、あるいはその両方にパッシブ データベース コピーを持ちます。Redmond と Portland の間ですべてのネットワーク接続が失われた場合、次のことが起こります。
DAG1 では、メンバーの REDMBX1 および REDMBX2 がマジョリティとなり、それぞれ DAG1 の監視サーバー HUB1 と通信できるため、Redmond のユーザーにサービスを提供し続けます。
DAG2 では、メンバーの PDXMBX3 および PDXMBX4 がマジョリティとなり、それぞれ DAG2 の監視サーバー HUB2 と通信できるため、Portland のユーザーにサービスを提供し続けます。
ページのトップへ
追加の投票のための DAG のデータベースを含まないメールボックス サーバーの使用
前述のとおり、大規模な DAG ほど、サービスの中断なしにより多くの障害に耐えることができるため、本質的により優れた復元性を提供します。DAG メンバーの障害に対処する際の復元性を高めることが可能な設計戦略の 1 つは、DAG のプライマリ データセンターの既存のハブ トランスポート サーバーを活用することです。この戦略では、メールボックス サーバーの役割を (データベースまたはデータベース コピーなしで) ハブ トランスポート サーバーに追加し、そのサーバーを DAG に追加します。このシナリオでは、メールボックス サーバーの役割は投票およびクォーラムの目的のみに使用されます。DAG の投票者が多いほど、DAG はより多くの投票者の障害に耐え、クォーラムを維持することができます。
たとえば、2 つのデータセンターにまたがる 4 メンバーの DAG について考察します。プライマリ データセンターには 2 つの DAG メンバーと監視サーバーが含まれ、セカンダリ データセンターには 2 つの DAG メンバーが含まれています。次の図に示すように、5 つのクォーラム投票者が存在します。したがって、この DAG では 2 つの投票者を失ってもまだクォーラムを維持できます。DAG が 3 つ目の投票者を失うと、クォーラムを失い、サービスの復元のために手動の管理操作が必要になります。
監視サーバーを含む 4 メンバーの DAG
.gif "5 つの投票者による 4 メンバー のデータベース可用性グループ")
この例では同じサーバーを使用して、メールボックス サーバーの役割をハブ トランスポート サーバー REDHUB1、REDHUB2、および PDXHUB1 に追加し、次にこれらのサーバーを DAG1 に追加します (これらのサーバーで Windows フェールオーバー クラスタリングの実行が可能であると仮定)。
データベースを含まない 3 つのメールボックス サーバーを使用している 7 メンバーの DAG
.gif "7 つの投票者による 7 メンバー のデータベース可用性グループ")
この時点では、これらのサーバー上で運用環境のメールボックス データベースは作成しません。また、これらのサーバーにいかなるデータベース コピーのレプリケートも行いません。この構成では、既定のメールボックス データベースを削除して、Microsoft Exchange Information Store サービス (必要に応じて無効化することも可能) を停止します。
注意
Microsoft Exchange Information Store サービスは、データベースを含まないメールボックス サーバーがクォーラム投票に参加するためには必要ではありませんが、メールボックス サーバーがクォーラムおよび DAG 機能に参加するためには、Microsoft Exchange Replication サービスが実行されている必要があります。
データベースを含まないメールボックス サーバーを DAG のメンバーとして追加した後、それらのサーバーは DAG のクォーラムの参加者となります。この構成では、DAG1 には 7 つのクォーラム投票者が含まれます。その結果、3 つのサーバーを失ってもまだクォーラムを維持できます。
ページのトップへ
© 2010 Microsoft Corporation.All rights reserved.