推奨されるアーキテクチャ


(この記事は 2014 年 4 月 21 日に The Exchange Team Blog に投稿された記事 The Preferred Architecture の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

先日私は、Microsoft Exchange Conference (MEC、英語)担当したセッション (英語) の中で Exchange Server 2013 のマイクロソフトが推奨するアーキテクチャ (以下「PA」) について発表しました。PA は、Exchange 2013 にとって最適と思われる展開アーキテクチャを実現するために Exchange エンジニアリング チームが策定した規範的なアプローチです。Office 365 で展開するアプローチと非常によく似ています。

Exchange 2013 のオンプレミス展開では、さまざまなアーキテクチャを選択することができますが、今回はマイクロソフトがこれまで最も検証を重ねてきたアーキテクチャについて解説します。他の展開アーキテクチャもサポートされていますが、推奨されるものではありません。

PA は、いくつかのビジネス要件を考慮して設計されています。たとえば、アーキテクチャでは以下のことを実現できる必要があります。

  •   データセンター内の高可用性とデータセンター間のサイトの復元
  •   各データベースの複数のコピーのサポートと、それによる迅速なアクティブ化
  •   メッセージング インフラストラクチャのコスト削減
  •   障害ドメイン周辺の最適化と複雑さの軽減による可用性の向上

PA は具体的な規範を示すものであるため、当然ながら、すべてのお客様が展開できるとは限りません (たとえば、複数のデータセンターを持たないお客様には当てはまりません)。また、異なるビジネス要件やニーズを抱えるお客様には、ここで示すものとは別のアーキテクチャが必要になります。ただし、こうした例外に該当するお客様がオンプレミスでの Exchange の展開を希望する場合にも、実際のニーズと大きく離れている箇所以外は可能な限り PA に沿って展開することで、メリットが得られます。代案として、Office 365 を使用することも可能です。Office 365 を使用すると、サーバーを展開、管理しなくても PA を活用できます。

PA について詳しくお話する前に、このアーキテクチャの基盤となる重要な概念を取り上げておきます。その概念とは「簡潔性」です。

簡潔性

障害は必ず発生するものです。どんなテクノロジを駆使しても、この事実を覆すことはできません。ディスク、サーバー、ラック、ネットワーク機器、ケーブル、変電設備、発電機、オペレーティング システム、アプリケーション (Exchange など)、ドライバー、およびその他のサービスなど、IT 関連のサービスや製品において、障害の影響を受けることがない要素は間違いなく存在しません。

障害の発生を抑える手段の 1 つとして、冗長性を組み込むという方法があります。これは、1 つのエンティティで障害が発生する可能性が高い場合に複数のエンティティを使用する方法で、Web サーバー アレイやディスク アレイなどで採用されています。ただし、冗長化は非常にコストがかかります (単純な比例関係でコストが増加します)。たとえば、2007 のリリースまで Exchange の中核を成していた SAN ベースのストレージ システムのコストと複雑さによって Exchange チームのストレージ スタックに対する予算が増大したため、ストレージの重要な要素が直接アーキテクチャに組み込まれるように Exchange アプリケーションを強化することになりました。チームでは、すべての SAN システムで最終的に障害が発生すること、また、SAN テクノロジを使用した冗長性の高いシステムの実装には多大なコストがかかることを把握していました。これを受けて、Exchange が強化され、高コストかつスケールアップ方式の高パフォーマンス SAN ストレージとそれに関連する周辺機器が不要になりました。現在では、ごく一般的なディスク コントローラーを使用した JBOD 構成で、一般的な低パフォーマンス SAS/SATA ドライブを搭載した低コストかつスケールアウト方式のサーバー上で実行することができます。このアーキテクチャにより、あらゆるストレージ関連の障害から Exchange を回復できるだけでなく、リーズナブルな価格で大規模なメールボックスを展開できるようになりました。

Exchange にレプリケーション アーキテクチャを構築し、ごく一般的なストレージに対して Exchange を最適化すると、ストレージの視点から、発生する障害モードが予測可能になります。このアプローチの対象はストレージ レイヤーだけではありません。このアプローチにより、NIC や電源装置などの冗長コンポーネントをサーバー ハードウェアから取り除くこともできます。ディスク、コントローラー、マザーボードのいずれかで障害が発生しても、最終的に他のデータベース コピーがアクティブ化されてデータを継承するという、同じ結果になる必要があります。

ハードウェアまたはソフトウェアのアーキテクチャの複雑化が進むにつれ、障害イベントの予測は困難になります。しかし、障害の管理とは、規模を問わず回復を予測可能にすることにほかなりません。そのためには、障害モードを予測できる必要があります。複雑な冗長化の例として、アクティブ/パッシブのネットワーク機器のペア、複雑なルーティング構成を使用したネットワーク上の集約ポイント、ネットワーク チーミング、RAID、複数のファイバー配線などが挙げられます。複雑な冗長性の排除は、文面からはイメージしにくいと思います。冗長性を排除して可用性を向上できる方法としては、複雑な冗長モデルからソフトウェアベースの冗長モデルに移行し、予測可能な障害モードを作成する方法があります。

必要に応じて、PA で冗長性を排除し、複雑さを軽減して、アーキテクチャを予測可能な回復モデルにします。障害が発生すると、影響を受けるデータベースの他のコピーがアクティブ化されます。

PA には、注目すべき 4 つのポイントがあります。

  1. 名前空間の設計
  2. データセンターの設計
  3. サーバーの設計
  4. データベース可用性グループ (DAG) の設計

名前空間の設計

以前、名前空間の計画負荷分散の原則の記事で、Exchange 2013 で採用できるさまざまな構成について概説しました。名前空間に関して言えば、制限付きモデル (ユーザーが特定のデータセンターを操作するように制限される) または無制限モデル (いずれのデータセンターへの接続も制限されない) のいずれかを展開できます。

推奨されるアプローチは、無制限モデルを採用し、サイト復元データセンターのペアに対してクライアント プロトコルごとに 1 つの名前空間を展開することです (ここで、各データセンターは独自の Active Directory サイトを表すと見なされます。詳細については、以下を参照してください)。例を次に示します。

  •   autodiscover.contoso.com
  •   HTTP クライアント: mail.contoso.com
  •   IMAP クライアント: imap.contoso.com
  •   SMTP クライアント: smtp.contoso.com

namespacedesign
1: 名前空間の設計

セッション アフィニティを利用しない構成内で、名前空間ごとに 2 つのデータセンター間で負荷分散されます。これにより、データセンター間でプロキシ転送されるトラフィックが半分になります。トラフィックは、DNS ラウンドロビンや Geo-DNS、または同様のソリューションを自由に指定して活用することで、ペアのサイト復元データセンター間で均等に分散されます。マイクロソフトでは、ソリューションがシンプルであるほど、複雑さが解消されて管理しやすくなると考えているため、DNS ラウンドロビンの利用をお勧めしています。

環境内にサイト復元データセンターのペアが複数存在する場合は、世界全体で単一の名前空間を指定するか、地域別の名前空間を使用して特定のデータセンターのペアごとにトラフィックを制御するかを決定する必要があります。最終的には、ネットワーク トポロジと、無制限モデルの使用に伴うコストが判断基準となります。たとえば、データセンターが北米およびヨーロッパに配置されている場合は、その地域間のネットワーク リンクにコストがかかるだけでなく待機時間が長くなるおそれもあるため、ユーザーの負担と運用上の問題を招きかねません。この場合、地域ごとに 1 つの名前空間を使用した制限付きモデルを展開したほうが合理的です。

サイト復元データセンターのペアの設計

高可用性サイト復元のアーキテクチャを実現するには、適切に接続された複数のデータセンターが必要です (ネットワークのラウンドトリップ待ち時間が短いものが理想です。待ち時間が長いと、レプリケーションとクライアントの機能に悪影響を及ぼします)。また、データセンターは、異なるプロバイダーが提供する冗長ネットワーク パスで接続する必要があります。

1 つの Active Directory サイトを複数のデータセンターにわたって拡張することは可能ですが、PA では以下の 2 つの理由から、各データセンターを独自の Active Directory サイトにするようにお勧めしています。

  1. シャドウ冗長セーフティ ネットを使用したトランスポート サイト復元は、DAG のメンバーが複数の Active Directory サイト存在する場合にのみ実現できます。
  2. サブネット間のラウンド トリップ待ち時間が 10 ミリ秒を超える場合には、別の Active Directory サイトにサブネットを配置する必要があります。これについては、ガイドが公開されています。

サーバーの設計

PA に使用されるサーバーは、すべて複数の役割を持つ物理サーバーです。次の 2 つの理由により、仮想ハードウェアではなく、物理ハードウェアを展開します。

  1. サーバーは、最悪の障害モードのときにリソースの 80% を使用するようにスケーリングされます。
  2. 仮想化を実行すると、管理レイヤーが追加されてより複雑になり、追加の回復モードが導入されます。Exchange には同等の機能が標準で備わっているため、付加価値が発生するわけではありません。

複数の役割を持つサーバーを展開すると、すべてのサーバーでハードウェア、インストール プロセス、構成オプションが同じになり、アーキテクチャが簡素化されます。サーバー間で一貫性を確保することも、管理性向上につながります。複数の役割を持つサーバーでは、サーバーの大規模なプール全体でクライアント アクセスとメールボックスのリソースが分散されるため、サーバーのリソースをより効率的に活用できます。負荷分散されるプールとデータベース可用性グループ (DAG) に対して使用できるサーバーの数が多いと、クライアント アクセスと DAG の耐障害性も向上します。

PA では、ごく一般的なサーバー プラットフォーム (サーバー シャーシ内に 12 基の大型フォーム ファクター ドライブ ベイを備えた 2U サーバーなど) を使用します。メールボックスの数やサイズ、サーバーの拡張性に応じて、サーバーごとに追加のドライブを導入できます。

各サーバーには、オペレーティング システム、Exchange バイナリ、プロトコル/クライアント ログ、およびトランスポート データベースに対して 1 つの RAID1 ディスク ペアを構成できます。残りのストレージは JBOD として構成され、7.2K RPM の連続的に追加された大容量 SCSI (SAS) ディスクが使用されます (SATA ディスクも使用可能ですが、SAS (および同等のもの) ではより高性能の I/O を利用できるほか、年間の障害発生率が低くなります)。各ディスクの暗号化には Bitlocker が使用されているため、保存時にデータ暗号化を使用でき、データ交換に伴ってデータが漏えいするリスクが緩和されます。

各ディスクの容量と I/O ができるだけ効率的に使用されるようにするには、ディスクごとに 4 つのデータベース コピーを展開します。通常の実行時のコピーのレイアウト (「Exchange 2013 Server Role Requirements Calculator (英語)」での計算による) では、ディスクごとにアクティブ化されるコピーは 1 つだけになります。

ServerDesign
2: サーバーの設計

ディスク プール内の 1 つ以上のディスクがホット スペアとして予約されます。ディスクで障害が発生すると、ホット スペアがアクティブ化されてデータベース コピーの再シードが開始され、AutoReseed が有効になり、速やかにデータベースの冗長性が復元されます。

データベース可用性グループ (DAG) の設計

サイト復元データセンターのペアごとに、1 つ以上の DAG が構成されます。

DAG の構成

名前空間モデルと同様に、サイト復元データセンターのペア内の各 DAG は、アクティブなコピーを使用した無制限モデルで動作します。そのため、DAG 内のすべてのサーバーで負荷が均等に分散されます。このモデルには 2 つのメリットがあります。

  1. DAG メンバーごとにサービス スタック全体が検証されます (クライアント接続、レプリケーション パイプライン、トランスポートなど)。
  2. 障害シナリオ時に、できるだけ多くのサーバー間で負荷が分散されます。これにより、DAG 内の残りのメンバーのリソース使用率のみが急増するようになります。

各データセンターは対称となり、各データセンターの DAG 内のメンバー サーバーが同じ数になります。つまり、各 DAG に偶数のサーバーが含まれ、クォーラム調停にミラーリング監視サーバーが使用されることになります。

DAG は Exchange 2013 の基本的なビルディング ブロックです。DAG のサイズについては、より規模の大きい DAG のほうが冗長性およびリソースが強化されます。PA の目標は、大規模な DAG を展開し (通常、8 つのメンバーの DAG から開始し、要件に応じてサーバー数を増やします)、既存のデータベース コピーのレイアウトに対して拡張性の面で懸念が生じたときに、新しい DAG を作成するだけで対応できるようにすることです。

DAG のネットワーク設計

Exchange 2007 で連続レプリケーションが導入されて以来、Exchange では、クライアント トラフィックとレプリケーション トラフィックを切り離すために、複数のレプリケーション ネットワークの利用を推奨してきました。2 つのネットワークを展開すると、特定のトラフィックを別のネットワークから切り離すことができ、特定のイベントの際に (再シード イベントなど) ネットワーク インターフェイスが飽和状態になるのを防止します (これは 100 MB インターフェイスに発生する問題です。1 GB インターフェイスでも一部発生します)。しかし、この方法を採用したお客様の多くは、基礎となるネットワーク アーキテクチャのどちらのネットワークにも同じ銅製のケーブルを使用するなど、論理面以外では 2 つのネットワークを切り離していませんでした。

10 GB ネットワークが普及すると、PA では、クライアント トラフィックとレプリケーション トラフィックを切り離す、以前のガイダンスから脱却しました。サーバーで障害が発生しても、ネットワークで障害が発生しても、どちらの場合にも同様に DAG 内の別のサーバーでデータベース コピーがアクティブ化されるような、障害を問わない標準的な回復モデルを実現することが最終的な目標であるため、1 つのネットワーク インターフェイスで十分です。このアーキテクチャの変更によりネットワーク スタックがシンプルになり、ハートビートの漏話を防ぐ必要がなくなります。

ミラーリング監視サーバーの配置

最終的には、ミラーリング監視サーバーの配置により、アーキテクチャに自動的なデータセンターのフェールオーバー機能を組み込むかどうか、またはサイトの障害時に手動でアクティブ化してサービスを有効化する必要があるかどうかが決まります。

お客様の組織に、DAG が展開されたサイト復元データセンターのペアに影響を及ぼすネットワーク障害から切り離された、ネットワーク インフラストラクチャを持つ第 3 の場所がある場合は、その場所に DAG のミラーリング監視サーバーを展開することをお勧めします。この構成により、データセンター レベルの障害イベントが発生した際、どのデータセンターが停止したかにかかわらず、DAG が他のデータセンターへのデータベースのフェールオーバーを自動的に実行できるようになります。

DAG Design
3: DAG (3 つのデータセンター) の設計

お客様の組織に第 3 の場所がない場合は、サイト復元データセンターのペアのいずれかのデータセンターにミラーリング監視サーバーを配置します。サイト復元データセンターのペア内に複数の DAG が存在する場合は、同じデータセンターのすべての DAG に対してミラーリング監視サーバーを配置します (通常、このデータセンターには、ユーザーの大多数が物理的に配置されています)。また、各 DAG のプライマリ アクティブ マネージャー (PAM) も同じデータセンターに配置するようにします。

データの耐障害性

データの耐障害性は、複数のデータベース コピーを展開することで確保されます。PA では、サイト復元データセンターのペア全体でデータベース コピーが分散されます。これにより、メールボックスのデータがソフトウェアやハードウェアの障害に加えて、データセンターの障害からも保護されます。

各データベースに 4 つのコピーがあり、各データセンターに 2 つのコピーがあります。つまり、PA では最低で 4 つのサーバーが必要になります。これら 4 つのコピーのうち、3 つは高可用性データベース コピーとして構成されます。4 番目のコピー (アクティブ化を最優先するコピー) は時間差データベース コピーとして構成されます。サーバーの設計により、データベースのコピーはそれぞれ他のコピーと切り離されます。これにより、DAG に関するこちらのブログ記事 (英語) で説明されているように、障害ドメインが削減されてソリューション全体の可用性が高まります。

時間差データベース コピーの目的は、まれに発生するシステム全体の重大な論理的破損に対して、回復メカニズムを構築することです。個別のメールボックスまたはメールボックスのアイテムの回復は対象としていません。

時間差データベース コピーの再生ラグ タイムは、ReplayLagTime によって 7 日間に設定されます。また、再生ラグ マネージャーも有効になり、時間差コピーの動的ログ ファイルを再生できます。この機能により、時間差データベース コピーの自動再生が可能になり、次のシナリオで可用性が高くなります。

  •   ディスク領域不足のしきい値に達した場合
  •   時間差コピーに物理的な損傷が生じ、ページを修正する必要がある場合
  •   24 時間以上利用できる正常なコピー (アクティブまたはパッシブ) が 3 つ未満の場合

この方法で時間差データベース コピーを使用するときには、時間差データベース コピーは特定の時点のバックアップを保証するものではないと理解しておくことが重要となります。時間差データベース コピーには可用性のしきい値があり、通常 90% 前後です。これは、ディスクの障害、(自動再生により) HA コピーとなる時間差コピー、および時間差データベース コピーが再生キューを再構築する期間が原因で、時間差コピーが格納されるディスクが失われる期間があるためです。

意図しない操作 (または攻撃) によってアイテムが削除されないように、単一アイテムの回復またはインプレース保持のテクノロジが使用されます。また、削除済みアイテムの保存期間が、定義されたアイテムレベルの回復 SLA 以上の値に設定されます。

これらすべてのテクノロジを駆使することで、PA では従来のバックアップが不要になり、Exchange ネイティブ データ保護が採用されています。

まとめ

PA では、Exchange 2013 で強化された機能を活用して、Exchange 展開環境の可用性や耐障害性を維持しながら簡潔性を高めています。中には、PA に沿って展開することで、従来よりも可用性と耐障害性を向上できるシナリオもあります。

Ross Smith IV
Office 365 カスタマー エクスペリエンス担当
主任プログラム マネージャー

Skip to main content