Exchange 2016 の推奨アーキテクチャ


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

 

推奨アーキテクチャ (PA) は、Exchange Server 2016 にとって最適と思われる展開アーキテクチャを実現するために Exchange エンジニアリング チームが策定した推奨されるベスト プラクティスです。Office 365 で展開するアプローチと非常によく似ています。

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

PA は、アーキテクチャで実現できる以下の要件など、いくつかのビジネス要件を考慮して設計されています。

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

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

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

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

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

名前空間の設計

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

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

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

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

Office Online サーバー ファームの場合、レイヤー 7 において Cookie ベースの永続性を使用してセッション アフィニティ―を保持するロード バランサーによって、名前空間がデータセンターごとに展開されます。

図 1: 推奨アーキテクチャでの名前空間の設定

 

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

図 2:地理的に分散された制限なし名前空間

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

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

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

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

サーバーの設計

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

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

PA では、ごく一般的なサーバー プラットフォームを使用します。一般的なプラットフォームは以下のとおりです。

  • 2U、デュアルソケット サーバー (20~24 個のコア)
  • 最大 96GB のメモリ
  • バッテリ バックアップ対応の書き込みキャッシュ コントローラー
  • サーバー シャーシ内に 12 基以上の大型フォーム ファクター ドライブ ベイを装備

メールボックスの数やサイズ、サーバーの拡張性に応じて、サーバーごとに追加のドライブを導入できます。

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

Exchange データベースを格納する各ディスクは、ReFS でフォーマットされており (整合性機能は無効)、 DAG は、AutoReseed が ReFS でディスクをフォーマットするように構成されています。

Set-DatabaseAvailabilityGroup <DAG> -FileSystem ReFS

各ディスクの暗号化には Bitlocker が使用されており、保存時にデータを暗号化できるため、データ盗難やデータ交換時のデータ漏えいなどの懸念が緩和されます。

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

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

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

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

DAG の構成

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

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

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

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

DAG のネットワーク設計

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

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

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

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

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

データの耐障害性

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

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

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

時間差データベース コピーの再生ラグ タイムは、ReplayLagTime によって 7 日間に設定されます。また、可用性に問題が発生した場合、再生ラグ マネージャーも有効になり、時間差コピーの動的ログ ファイルを再生できます。

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

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

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

Office Online サーバーの設計

Exchange 2016 サーバーをホストする各データセンターには、最低 2 つの Office Online サーバーを展開することをお勧めします。各 Office Online サーバーには 8 プロセッサ コア、32GB のメモリ、ログ ファイルを格納するための最低 40GB の容量が必要です。

注意: Office Online サーバー インフラストラクチャは Exchange だけで使用するものではありません。そのため、ハードウェアに関するガイダンスでは、SharePoint および Skype for Business での使用についても考慮されています。サーバー サイズが特定の展開に適切であるかを、Office Online サーバー インフラストラクチャを使用している他のチームに確認してください。

特定のデータセンター内の Exchange サーバーは、次のコマンドレットによって、ローカルの Office Online サーバー ファームを使用するように構成されています。

Set-MailboxServer <East MBX Server> –WACDiscoveryEndPoint https://oos-east.contoso.com/hosting/discovery

まとめ

Exchange Server 2016 では、以前のバージョンの Exchange で導入された各機能に引き続き重点を置いています。具体的には、サーバー ロール アーキテクチャの複雑さを軽減し、推奨アーキテクチャと Office 365 の設計原則に従い、Exchange Server 2013 との共存機能を改善しています。

これらの変更は、可用性や耐障害性を保持しながら、Exchange の展開を単純化します。中には、PA に沿って展開することで、従来よりも可用性と耐障害性を向上できるシナリオもあります。

Ross Smith IV

プリンシパル プログラム マネージャー

Office 365 カスタマー エクスペリエンス担当

Skip to main content