図に使用される表記の凡例
システム構成¶
本システムは、DR発動時を想定して、地理的に離れた2つの拠点でサービスが継続できる仕組みとしています。
また本稿では、DRサイトではないシステムの大部分が収容されるサイトをメインサイトと呼称しています。
ただし費用を圧縮するために、通常とは異なり、DRサイトで障害が発生する事は考慮に入れていません。
DRサイトも完全に冗長化したい場合は、後述するメインサイトと全く同じ構成とする事で、DR時にも耐障害性を得る事ができます。
また、Exchangeの導入にあたって必要となるOSや.NET Frameworkなど、その他のミドルウェアなどは、Microsoftの公開している「Exchange 2013 のシステム要件」をご確認ください。
https://technet.microsoft.com/ja-jp/library/aa996719(v=exchg.150).aspx
尚、今回は5,000ユーザーを1台のサーバーで処理できると判断した前提で記載しています。
メールボックスのサイズやメール通数、平均メッセージサイズや、利用するセッション数などによっては、たとえ5,000ユーザーだったとしても、今回の構成ではパフォーマンスが不足する事も考えられます。
構成については、こちらで指針は出ていますが、構築するベンダー各社で過去事例も含めて試算できるはずですので、事前に相談される事をお薦めします。
また、パフォーマンスに問題が発生した場合は、こちらの値を変更する事によりチューニングする事もできるので参考にしてください。
https://technet.microsoft.com/ja-jp/library/mt741981(v=exchg.150).aspx
メインサイトシステムの構成¶
メインサイトでは、物理的に1台破損したとしても、パフォーマンスを含めてサービスを維持できる、所謂N+1構成としていますので、二重障害が発生しない限りにおいては、可用性が確保できます。
基本的な構成としては、SDPFのベアメタルサーバーのスペックを考慮し、1台のベアメタルサーバーに、２つのVMを用意し、まずは全てのExchangeの役割を１つのVMにインストールし、そのベアメタルサーバーを2台構成として冗長化することで、仮に通常利用時にDRサイトが動作しない状況になったとしても、メインサイトのみでサービスが継続できるようにしています。
この構成となる事から、今回はCASとMBXはサーバーを分割せず、１つの仮想マシンに導入することにします。
また、Exchangeの役割とは別ですが、ExchangeはMicrosoft Active Directoryとも密に連携します。
Active Directoryは通常社内にありますが、Exchangeは、その動作において、Active Directoryへ頻繁に読み書きを行いますし、ExchangeのActive Directory要件として、前出の「Exchange 2013 のシステム要件」にあるとおり、同一サイト内に読み書きできるActive Directoryを用意する必要がありますので、今回はSDPFにActive Directoryを配置することとして、社内のActive Directoryとはサイトを分けておこうと考えました。
このActive Directoryを先ほど用意した二つのVMの残りもう一つにインストールする事で、非常にシンプルな構成でありながら、完全な冗長性を担保する事ができるようになります。
尚、Active Directoryは頻繁に読み書きされるだけではなく、スキーマの拡張や組織単位（OU）の追加が必要となります。現在お使いのActive Directoryへの変更が必要となりますので、ご注意下さい。
https://technet.microsoft.com/ja-jp/library/bb125224(v=exchg.150).aspx
では、次に、ベアメタルサーバー間で冗長構成をとっていくために、各役割の設計をみていきましょう。
CAS¶
CASは2013から完全にステートレスな仕組みとなったため、負荷分散装置によって複数台に割り振る事が容易にできます。
今回はラウンドロビン方式でアクセスを割り振る事とします。ラウンドロビン方式は文字通り傘連判状のように、メインとなるサーバーを定めず、アクセスの都度、順番にサーバーへアクセスを割り振っていく方式です。
これによって平時は２台のCASへ均等にアクセスが割り振られ、１台に障害があった場合には、問題の無いCASにアクセスが集中する事になります。
今回の構成ではメインサイトでは2台のCASが存在するため、その2台で負荷分散を行い、DRサイトはDRが発令された後にDNSを切り替える運用とする事としました。
MBX¶
MBXは前述したデータベースを冗長化する事で可用性を確保できます。
上述した通り、ExchangeのMBXは専用のデータベースシステムを利用しています。そして、データベース可用性グループ（DAG）という機能で、そのデータベースを複数台組み合わせる事で、可用性を確保します。
ただし、このDAGという仕組みはSQL Serverと同じようにクォーラムモデルを採用しています。
クォーラムというのは、元々は定足数という意味で、合議制の議会を行う最低限度の出席数の事を指しますが、DAGのクォーラムも同じで、複数のメンバー（この場合はMBX）が正常に動作している事を投票で決めるための最低限の台数で構成されます。
要は多数決を行うため、最低数は３で、常に奇数である必要があります。偶数の場合はメンバーサーバーとは別に監視サーバーを用意するのですが、今回の構成ではメインサイトとDRサイトを合わせて3台のメンバーサーバーが存在しますので、ちょうどクォーラムを満たします。
尚、DAGやCAS/MBXの細かな役割については、こちらのサイトでまとまっていますので、理解の参考にしてください。
https://technet.microsoft.com/ja-jp/library/dd979799(v=exchg.150) https://technet.microsoft.com/ja-jp/library/aa996349(v=exchg.150)
ワンポイント
今回の構成の場合は、２つの役割が１つの仮想マシンに同居しますが実際には、CAS/MBX間では適切なDBに情報が格納されるようにメールトランスポートが行われます。メールトランスポート時には、Active Directoryに登録されているオブジェクトを元に判断を行い、適切に分散されますので、CASは負荷分散装置で負荷分散して、MBXはDAGを構成するだけで、Exchangeを構成するどこかのサーバーに障害が発生した場合にも、サービスを維持する事ができるようになります。
DRサイトのシステム構成¶
DRサイトは、1台のベアメタルサーバーで構築する事にします。
DRサイトの役割は、当然DR発動時のサービス継続性確保もありますが、通常時、MBXに問題が発生した場合にもクォーラムとしても機能します。
これにより、データは常に複数台へ冗長され続けるため、データ領域の多重障害への対応という意味で、DRサイトをデータバックアップサイトと見なす事もできるようになりますので、Exchangeのデータバックアップを考慮から外す事ができるようにもなります。
ただし、この構成で動作させる場合は、データベースの論理障害が発生した場合の考慮が必要になります。
幸い、ExchangeはDBの論理障害が発生している可能性がある事を示すログが出力されますので、今回の構成では、そのログを監視して、アラートがあがった場合にはSE作業でデータベースの復旧を行う事で対応する事にします。
DRサイトのCASもメインサイトと負荷分散構成にする事もできますが、今回の主な目的はDR対応になりますので、そこまで大がかりな構成にはせず、DR発動時にDNSを切り替える作業を運用として設計する事で対応する事にします。