Microsoft Exchange Server 2013d0.awsstatic.com/International/ja_JP/Whitepapers/...Exchange Server...

AWS クラウドで使用する

Microsoft Exchange Server 2013:

クイックスタートリファレンスデプロイメント

Mike Pfeiffer

2015 年 1 月前回の更新: 2015 年 9 月 (リビジョン)

アマゾンウェブサービス – AWS クラウドで使用する Microsoft Exchange Server 2013

2015 年 9 月

2/50 ページ

目次ここで取り上げる内容 ..................................................................................................................................................... 4

クイックスタートアーキテクチャの概要 ...................................................................................................................... 7

Exchange Server 用の Microsoft 推奨アーキテクチャ ..................................................................................................... 8

パフォーマンスを考慮した設計.................................................................................................................................... 10

プロセッササイズ ....................................................................................................................................................... 11

メモリサイズ .............................................................................................................................................................. 15

ストレージサイズ ....................................................................................................................................................... 15

ストレージに関するその他の考慮事項 .................................................................................................................... 19

ストレージとサーバーのパフォーマンスを検証する ............................................................................................. 19

ログのレプリケーションとネットワークトラフィック.......................................................................................... 21

高可用性をもたらす設計 ............................................................................................................................................... 21

リージョンとアベイラビリティーゾーン ................................................................................................................ 21

Active Directory ドメインサービス ............................................................................................................................ 22

名前空間の設計と計画 ............................................................................................................................................... 24

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

クライアントアクセスの負荷分散 ............................................................................................................................ 30

デプロイのサンプルシナリオ ....................................................................................................................................... 32

メールボックス 250 個 .............................................................................................................................................. 33

メールボックス 250 個に対するクイックスタートアーキテクチャのデプロイシナリオ................................ 33

メールボックス 250 個に対する推奨アーキテクチャデプロイシナリオ .......................................................... 35

メールボックス 2,500 個 ........................................................................................................................................... 36


2015 年 9 月

3/50 ページ

追加の考慮事項 .............................................................................................................................................................. 38

ネットワークセキュリティ ....................................................................................................................................... 38

セキュリティグループ ........................................................................................................................................... 38

ネットワーク ACL ................................................................................................................................................... 39

エッジトランスポートサーバー ............................................................................................................................ 39

リバースプロキシサーバー.................................................................................................................................... 40

リモート管理........................................................................................................................................................... 42

保管時の暗号化 .......................................................................................................................................................... 43

Amazon EC2 インスタンス用のトランスポートの制限 ............................................................................................ 44

バックアップオプション ........................................................................................................................................... 44

自動デプロイ .................................................................................................................................................................. 45

テンプレートのカスタマイズ ................................................................................................................................ 45

設定後のタスク .............................................................................................................................................................. 47

参考文献と参考資料 ....................................................................................................................................................... 48

フィードバックをお寄せください ................................................................................................................................ 50

ドキュメントの改訂 ....................................................................................................................................................... 50


2015 年 9 月

4/50 ページ

ここで取り上げる内容このクイックスタートリファレンスデプロイメントガイドには、Microsoft Exchange Server 2013 環境をアマゾ

ンウェブサービス (AWS) クラウドに構築する際のアーキテクチャ上の考慮事項と設定が含まれます。

Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Virtual Private Cloud (Amazon VPC) といった、可用性の高

い Exchange Server アーキテクチャを個々の AWS アベイラビリティーゾーンにデプロイするのに必要な AWS

サービスを構築および設定する方法を説明します。さらに、正しく設定されたインフラストラクチャを計画どおりに繰り返しデプロイするために役立つ、サン

プルの AWS CloudFormation テンプレートを提供します。このテンプレートは自動化されており、これを起動

すると、Microsoft Active Directory Domain Services (AD DS) と Microsoft Exchange Server 2013 のインフラストラ

クチャが Amazon VPC 内の複数のアベイラビリティーゾーンにデプロイされます。AD DS を既にデプロイ済み

であれば、提供されている 2 番目のテンプレートを使用して、この Microsoft Exchange Server インフラストラ

クチャを既存の VPC に作成できます。自動化されたテンプレートを起動すると、AWS 上で Microsoft Exchange Server 2013 を実行するために必要な

最小限のインフラストラクチャが構築されます。このインフラストラクチャでは、250 のメールボックスをサ

ポートする小規模のデプロイメントに対して高い可用性が提供されます。これ以外にも、Microsoft が

Exchange Server に関して推奨しているアーキテクチャに合わせて 2 種類のデプロイメントシナリオ (メール

ボックス数 250 と 2,500) が用意されています。このアーキテクチャを利用すると、耐障害性が向上し、従来

のようなバックアップが不要になります。これらのシナリオは、実際の要件に応じたインフラストラクチャ

を構築する際の参考にしてください。

Exchange Server 2013 用 AWS CloudFormation テンプレートは米国西部 (オレゴン) リージョン内で起動してくだ

さい。

http://docs.amazonwebservices.com/AWSCloudFormation/latest/UserGuide/Welcome.html


2015 年 9 月

5/50 ページ

このスタックの作成には、約 3 時間かかります。コスト。このクイックスタートリファレンスデプロイメントの実行中に生じた AWS サービスの利用料金は、

すべてお客様のご負担になります。このガイドの公開時点で、デフォルト設定でテンプレートを作成し実行

するためのコストは、1 時間あたり約 5.50 USD です。ただし、価格は変更される場合があります。詳細につ

いては、使用する各 AWS サービスの料金表ページを参照してください。ライセンス。このクイックスタートをデプロイする前に、Microsoft Exchange Server 2013 のライセンスを取得

する必要があります。Microsoft Exchange Server 2013 は、ソフトウェアアシュアランスによる Microsoft

ライセンスモビリティプログラムを通じてライセンスを取得し、デプロイすることができます。開発および

テスト環境の場合は、Amazon EC2 ハードウェア専有インスタンスを使用して、Exchange Server の既存の MSDN

ライセンスを活用できます。詳細については、MSDN on AWS を参照してください。このガイドは、IT インフラストラクチャのアーキテクト、管理者、および DevOps 担当者を対象としています。

このガイドを読むことにより、AWS クラウドで Exchange Server 2013 をサポートするために必要なインフラス

トラクチャの作成方法を理解できます。このクイックスタートをデフォルトの入力パラメータでデプロイすると、図 1 に示されている Exchange Server 2013 環境が AWS クラウド上に構築されます。

最初にクイック起動を試します

Exchange Server 2013 を本稼働用にデプロイする前に AWS で試験的に実行する場合は、

クイック起動オプションを使用してください。このオプションでは、あらかじめ構成済みの

設定を含む AMI を使用して、図 1 に示される Exchange Server アーキテクチャがお客様の AWS

アカウントに約 15 分以内にセットアップされます。クイック起動のデプロイメントには、

Exchange Server 2013 の 60 日のトライアルライセンスが含まれます。デプロイメントの実行中に

使用された AWS サービスについては、料金をお支払いいただく必要があります。試用が終了し

たら、長期間使用できる標準ライセンスにアップグレードできます。デプロイメントをカスタマ

イズする場合は、このガイドの手順に従って Exchange Server 2013 アーキテクチャをシステムに

ブートストラップしてください。

http://aws.amazon.com/windows/mslicensemobility/http://aws.amazon.com/windows/mslicensemobility/http://aws.amazon.com/windows/msdn/


2015 年 9 月

6/50 ページ

図 1: AWS 上の Exchange Server 2013 クイックスタートアーキテクチャ


2015 年 9 月

7/50 ページ

クイックスタートアーキテクチャの概要このクイックスタートを使用すると、AWS 上に Exchange Server 2013 のインフラストラクチャを作成するこ

とができます。デフォルト設定では、Microsoft Exchange Server を実行するための最小限のインフラストラク

チャがデプロイされます。このインフラストラクチャでは、250 のメールボックスをサポートする小規模の

デプロイメントに対して高い可用性が提供されます。このクイックスタートで使用される AWS の主要コンポ

ーネントには、次の AWS サービスが含まれます。

• Amazon VPC – Amazon Virtual Private Cloud (VPC) サービスを使用すると、AWS クラウドの分離されたプ

ライベートセクションをプロビジョニングし、お客様が定義した仮想ネットワークで AWS サービスお

よびその他のリソースを開始することができます。独自の IP アドレス範囲の選択、サブネットの作成、

ルートテーブル、ネットワークゲートウェイの設定など、仮想ネットワーク環境全体をお客様がコン

トロールできます。

• Amazon EC2 – Amazon Elastic Compute Cloud (EC2) サービスを使用すると、さまざまなオペレーティン

グシステムで仮想マシンインスタンスを起動することが可能になります。既存の Amazon マシンイメ

ージ (AMI) から選択することも、独自の仮想マシンイメージをインポートすることもできます。

• Amazon EBS – Amazon Elastic Block Store (Amazon EBS) は、AWS クラウドの Amazon EC2 インスタンスで

使用する永続的なブロックレベルのストレージボリュームを提供します。コンポーネントに障害が発

生した場合でも高い可用性と耐久性を提供できるように、各 Amazon EBS ボリュームはアベイラビリ

ティーゾーン内で自動的にレプリケートされます。Amazon EBS ボリュームは、ワークロードの実行に

必要な低レイテンシーの安定したパフォーマンスを提供します。

• Amazon Route 53 (オプション) – Amazon Route 53 サービスでは、アクティブ/アクティブ構成、アク

ティブ/パッシブ構成、混合構成の DNS (ドメインネームシステム) フェイルオーバーを設定してアプ

リケーションの可用性を高めることができます。同じ機能を実行する複数のリソースがある場合 (複数

の Exchange Server など)、リソースの正常性をチェックし、正常なリソースのみを使用して DNS クエ

リに応答するように Amazon Route 53 を設定できます。このクイックスタートでは、図 1 に示されて

いるすべてのリソースがデプロイされます。Amazon Route 53 サービスは、AWS CloudFormation スタ

ックの起動後に、手動で設定することができます。

http://aws.amazon.com/documentation/vpc/http://aws.amazon.com/documentation/ec2/http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.htmlhttp://aws.amazon.com/documentation/route53/


2015 年 9 月

8/50 ページ

AWS クラウドに Windows ベースの環境をデプロイする場合、クイックスタートでは、次のベストプラクティ

スをサポートするアーキテクチャが利用されます。

• 重要なワークロードは、高可用性実現のために最低 2 つのアベイラビリティーゾーンに配置する。こ

の場合、重要なワークロードは、Active Directory ドメインコントローラー、Exchange サーバー、リモ

ートデスクトップ (RD) ゲートウェイ (インターネット経由のリモート管理用、必要に応じて)、

Exchange エッジトランスポートサーバー、NAT (ネットワークアドレス変換) ゲートウェイ (アウトバ

ウンドのインターネットアクセス用) です。

• 内部アプリケーションサーバーなどのインターネット接続以外のサーバーは、インターネットからこ

れらのインスタンスへの直接アクセスを回避するためにプライベートサブネットに配置する。このク

イックスタートでは、ドメインコントローラーとマルチロール Exchange サーバーは、各アベイラビリ

ティーゾーンの Amazon VPC プライベートサブネットに配置されます。

• RD ゲートウェイは、インターネット経由のリモート管理のために各アベイラビリティーゾーンのパ

ブリックサブネットにデプロイする。リバースプロキシサーバーなどのその他のコンポーネントも、

必要に応じてこれらのパブリックサブネットに配置できます。このクイックスタートでは、環境内

でインターネット E メールを送受信できるように、オプションで Exchange エッジトランスポートロ

ール (SMTP ゲートウェイ) をパブリックサブネットにデプロイすることもできます。

Exchange Server 用の Microsoft 推奨アーキテクチャ最小限のインフラストラクチャによる高可用性の実現に加え、Exchange Server 2013 用の Microsoft 推奨アー

キテクチャ (Exchange PA) の検討をお勧めします。Exchange PA では専用物理サーバーで Exchange を実行する

ことが求められていますが、あらゆる環境で有益となるような設計上の特徴も多数含まれています。

Exchange PA に含まれている設計要件は次のとおりです (出典: Microsoft Exchange チームブログ)。

• データセンター内の高可用性とデータセンター間のサイトの復元

• 各データベースの複数のコピーのサポートと、それによる迅速なアクティベーション

http://blogs.technet.com/b/exchange/archive/2014/04/21/the-preferred-architecture.aspx


2015 年 9 月

9/50 ページ

• メッセージングインフラストラクチャのコスト削減

• 障害ドメイン周辺の最適化と複雑さの軽減による可用性の向上

AWS アベイラビリティーゾーンは、物理的に独立したデータセンターであると考えることができます。AWS

上の Exchange Server のデプロイメントを設計する際に Exchange PA に従うことで、単一の AWS アベイラビリ

ティーゾーンでも AWS リージョン内の複数ゾーンでも高可用性を実現できます。

図 2: Exchange PA に基づいた AWS 上の Exchange Server 2013 のアーキテクチャ


2015 年 9 月

10/50 ページ

Exchange PA に従うと、各データベースのコピーが 4 つ (各アベイラビリティーゾーンに 2 つ) 必要になり

ます。これは、250 ユーザーの小規模デプロイメントであっても、Exchange PA では少なくとも 4 台のサーバ

ーが求められていることを意味します。これら 4 つのコピーのうち、3 つは高可用性 (HA) コピーとして構

成されます。4 番目のコピーは時間差データベースコピーとして構成されます (ReplayLagTime パラメータ

ーを最大 14 日に設定)。

Exchange PA に基づいてソリューションを設計すると、そのアーキテクチャで提供される可用性は最大になり

ますが、相当規模のインフラストラクチャが求められることに注意してください。このガイドには、どの程

度のインフラストラクチャが必要になるかを把握できるように、サンプル設計シナリオを掲載しています。

これらのシナリオを参考にして、独自の設計をカスタマイズすることもできます。

パフォーマンスを考慮した設計新しい Microsoft Exchange Server デプロイメントの容量計画の大部分を占める中心的な要素は、Exchange Server

メールボックスロールと、対象となる使用シナリオに必要な Exchange Server メールボックスの数、アクティ

ビティ、サイズです。これを念頭に置いたうえで、新しいすべての Exchange Server デプロイメントで使用で

きる最初の計画ツールは、Exchange 2013 Server Role Requirements Calculator です。このガイドの執筆時点での

最新バージョンは、v6.6 です。

Exchange 2013 Server Role Requirements Calculator v6.6 は、Microsoft TechNet ギャラリーからダウンロードできます。

以下の各セクションでは、この計算ツールの中で AWS クラウドインフラストラクチャに関連する

エリアについて説明します。ここに記載されていないエリアについては、専用ハードウェアを使用して

Exchange Server 環境をデプロイする場合と同様に設定してください。

https://gallery.technet.microsoft.com/office/Exchange-2013-Server-Role-f8a61780


2015 年 9 月

11/50 ページ

プロセッササイズゲストオペレーティングシステムでは、仮想化ホストの物理ハードウェアのプロセッサ仕様をある程度確認で

きます。仮想マシンの場合、ハイパーバイザーによってタスクのスケジュールが制御されるため、提示される

仮想 CPU タイプとコア数の実際のパフォーマンスは、専用の物理ハードウェアとは異なります。計測可能な

パフォーマンスメトリックスを生成するには、設計内で Amazon EC2 インスタンスを定義する際に、CPU

オーバーヘッドを考慮する必要があります。

Microsoft Exchange 2013 Server Role Requirements Calculator スプレッドシートに含まれる [Input] タブのいくつ

かのフィールドは、プロセッサのパフォーマンスに関連しています。これらの入力により、次の項目が決定さ

れます。

• 仮想化のコストに基づいて、任意のオーバーヘッド (%) を最終的なプロセッサパフォーマン

スの算定値から差し引くかどうか。

• 仮想マシンで利用できるようにするプロセッサコアの数。

• メールボックスロールをデプロイするターゲットプラットフォームの SPECint2006 パフォーマ

ンス評価 (オプション)。

Microsoft Exchange Server 2013 の実行を計画する際には、他の仮想化プラットフォームの場合と同様、ハイパ

ーバイザーの CPU オーバーヘッドを考慮する必要があります。CPU オーバーヘッドは、選択されたインスタ

ンスタイプによって異なります。これに加え、Amazon EC2 インスタンスで最大限のパフォーマンスを実現す

るために、AWS では継続的なイノベーションが行われ、新しいインスタンスタイプも順次追加されてい

ます。このため、Server Role Requirements Calculator を使用して、ハイパーバイザーの CPU 調整係数を 10%

から始めることをお勧めします。独自のロードテストを実行して設計を検証し、必要に応じてこの値を調整

することもできます。Server Role Requirements Calculator を使用して CPU 要件の設計を開始する前に、計画し

たプロセッサの SPECint2006 評価値 (Rate Value) を調べる必要があります。

SPECint2006 評価値の確認に役立つ Exchange Processor Query Tool が、Microsoft Exchange Server チームから提供

されています。このガイドの執筆時点で、このツールの最新バージョンは、v1.1 です。

Exchange Processor Query Tool v1.1 は、Microsoft TechNet ギャラリーからダウンロードできます。

http://gallery.technet.microsoft.com/Exchange-Processor-Query-b06748a5


2015 年 9 月

12/50 ページ

このツールは、特定のプロセッサ番号を入力として受け取り、SPECint2006 ベースラインでこのプロセッサ番

号が含まれるシステムを探します。指定されたプロセッサに対して、パフォーマンス評価の平均値が出力さ

れます。

Processor Query Tool のステップ 2 では、最も近いプロセッサの値を使用することをお勧めします。

たとえば、R3 インスタンスタイプでは Intel Xeon E5-2670 v2 (以前は Ivy Bridge) プロセッサが使用されてい

ます。r3.2xlarge インスタンスタイプの使用を計画していた場合、ステップ 2 ではプロセッサモデルとして

[Intel Xeon E5-2670 v2] を指定します。

Processor Query Tool のステップ 3 では、SPECint2006 ベースラインで指定されたプロセッサ番号を含むシステ

ムを照会します。すると、図 3 に示されているように、そのプロセッサに関するパフォーマンス評価の平均

値が返されます。

図 3: Processor Query Tool のステップ 1～5


2015 年 9 月

13/50 ページ

次に、仮想化サーバーをデプロイすることを示す必要があります。ステップ 6 および 7 では、図 4 に示され

ているように、選択したインスタンスタイプの SPECint2006 評価値を調べます。

図 4: Processor Query Tool のステップ 6～8 この例では、R3 インスタンスプロセッサモデルの平均評価値として 809 が表示されています。仮想プロセッ

サと物理プロセッサの比率として 1:1 を定義し、選択したインスタンスタイプの仮想コア数を入力します。

この例では、インスタンスタイプは r3.2xlarge、vCPU 数は 8 です。インスタンスの最終的な SPECint2006

評価値は 324 です。次に、Server Role Requirements Calculator に進み、必要な値を入力します。[Input] タブのステップ 1 で、設計に

サーバーロール仮想化 (Server Role Virtualization) を利用することを示します。

図 5: [Input] タブの [Server Role Virtualization]


2015 年 9 月

14/50 ページ

[Input] タブで、ステップ 5 の [Server Configuration] セクションまでスクロールダウンし、コア数と

SPECint2006 評価値を入力します。

図 6: [Input] タブの [Server Configuration]

[Server Configuration] セクションのすぐ下で、ハイパーバイザーの CPU 調整係数 (Hypervisor CPU Adjustment

Factor) を定義できます。

図 7: [Input] タブの [Processor Configuration] 設計に応じてその他の入力値を定義したら、計算ツールの [Role Requirements] タブを使用して、予測さ

れたサーバー CPU 使用率が許容範囲内かどうかを調べます。この値は 80% 未満に維持することをお勧め

します。

図 8: [Role Requirements] タブの [Recommended RAM Configuration]

CPU 使用率が推奨しきい値以下になるように推定値を引き下げるには、さらに多くの Exchange Server

インスタンスのデプロイや、より適したインスタンスタイプの選択が必要になる場合もあります。


2015 年 9 月

15/50 ページ

メモリサイズ Microsoft Exchange Server の最小メモリ要件は、推奨マルチロール設定に対して 8 GiB です。Server Role

Requirements Calculator の [Role Requirements] タブにある [Recommended RAM Configuration] の出力値は、

[Input] タブで指定したターゲットメールボックスの数とサイズに基づき、8 GiB 以上になります。

AWS には、異なるメモリ設定オプションで、さまざまなインスタンスタイプが用意されています。一般的な

ベストプラクティスは、要件に基づいて、要件と一致するメモリ設定またはやや低いメモリ設定のインスタ

ンスタイプを選択することです。たとえば、30.5 GiB のメモリを提供する r3.xlarge を開始点として選択する

ことができます。デプロイメントの要件によっては、より高いメモリ設定のインスタンスタイプ (r3.2xlarge

など) への切り替えが必要になる可能性もあります。

図 9: [Role Requirements] タブの [Recommended RAM Configuration]

Exchange Server エッジトランスポートロール用には、4 GiB が最小要件です。ストレージサイズターゲットのデプロイメントシナリオをサポートするために必要な合計ストレージ容量は、プライマリおよ

びアーカイブメールボックスの数とサイズ、それ以外のメールボックス使用プロファイルのパラメータ、デ

ータベースストレージのオーバーヘッド、ボリュームの空き容量 (%)、各データベースのコピー数 (データベ

ースアベイラビリティーグループ (DAG)) など、さまざまなパラメータを適用して計算します。

図 10 に示されているように、Server Role Requirements Calculator の [Input] タブでは、カスタムの最大データ

ベースサイズの指定が必要になる場合があります。カスタムサイズを指定することで、最終的な設定に

Amazon EBS ボリュームの最大サイズを超過するようなボリュームが含まれないように調整できます。

図 10: [Input] タブで [Custom] に指定された [Maximum Database Size]


2015 年 9 月

16/50 ページ

各 Amazon EBS ボリュームは、インスタンスにある 26 のマウントポイント (/dev/sda1 および xvdb ～ xvdz)

のうちいずれかにアタッチされます。オペレーティングシステムのルートボリュームは、/dev/sda1 にマウ

ントされます。追加の Amazon EBS ボリュームまたはホストベースのインスタンスストレージを、残り 25 の

マウントポイントにアタッチすることができます。最終的な設定でインスタンスごとに Amazon EBS ボリュ

ームの最大マウントポイント数を超えない範囲で、複数インスタンスの追加が必要になる場合もあります。

Amazon EBS ボリュームは、次の 3 種類から選択できます。

• 汎用 (SSD) - Amazon EC2 インスタンスで使用されるデフォルトのボリュームです。ソリッドステートド

ライブ (SSD) を利用しており、幅広いワークロードに対応します。汎用 (SSD) ボリュームには、ボリュ

ームサイズに関係なく、ボリュームあたり 3,000 IOPS までバーストする性能があります。また、この

ボリュームタイプでは、3 IOPS/GiB という安定したベースラインと、ボリュームあたりのスループッ

トとして最大 128 MiB/秒を実現できます。

• プロビジョンド IOPS (SSD) - レイテンシーの低い安定したパフォーマンスのストレージを提供し、

大量の I/O を伴うワークロードが生じるアプリケーション用に設計されているボリュームです。

ソリッドステートドライブ (SSD) を利用しており、1 GiB あたり最大 30 IOPS をサポートします。

これにより、134 GiB という小容量のボリュームに 4,000 IOPS をプロビジョニングすることができ

ます。また、500 IOPS のプロビジョニングで、ボリュームあたり最大 128 MiB/秒のスループットを実

現することもできます。さらに、複数のボリュームをまとめてストライピングして、より容量の大

きい Amazon EC2 インスタンスにアタッチすれば、最大 48,000 IOPS または 800 MiB/秒を実現するこ

ともできます。

• マグネティック - すべての Amazon EBS ボリュームタイプの中で、GiB あたりのコストが最も低い

ボリュームです。マグネティックボリュームは磁気ドライブを利用しており、データアクセス頻度の

低いワークロードや、ストレージコストをなるべく低く抑えたい場合に最適です。マグネティックボ

リュームの平均パフォーマンスは約 100 IOPS であり、バースト時には数百 IOPS の実現も可能です。

マグネティックボリュームは、本稼働環境以外での Exchange データベースに対するオプションです。

本稼働環境で使用する場合、メールボックス数が少なく I/O デマンドが非常に低い場合を除いて、

マグネティックボリュームの利用はお勧めしません。


2015 年 9 月

17/50 ページ

安定しており予測可能な帯域幅のユースケースでは、EBS 最適化インスタンスまたは 10 ギガビットのネット

ワーク接続を持つインスタンスと、汎用 (SSD) ボリュームまたはプロビジョンド IOPS (SSD) ボリュームを使用

します。詳細については、AWS ドキュメントの「Amazon EBS ボリュームの種類」を参照してください。

Server Role Requirements Calculator を使用して、考えられる複数の設定を用意し、Microsoft Jetstress ツールの

Exchange Server バージョンを使用して、各設定のパフォーマンスを検証するという作業が必要になる可能性も

あります。

Amazon EBS ボリュームに加えて、一部の Amazon EC2 インスタンスには、インスタンスストレージが含まれて

います。インスタンスストレージは一時的なものです。設定されたインスタンスストレージは、インスタンス

が停止し、再起動されるたびに、新しいディスクとして表示されます。インスタンスが停止されると、インス

タンスストレージにあるデータはすべて失われます。インスタンスストレージは、インスタンスのランタイム

コストに含まれます。

インスタンスストアボリュームは、オペレーティングシステムのページングや一時ファイルストレージなど、

頻繁に変化する情報の一時ストレージとして最適です。

Microsoft Exchange Server のデータベースファイルをホストしないボリュームについて、Exchange Server インス

タンスが求めるボリュームの数とサイズを計画する際には、次の推奨事項を念頭に置いてください。

• ルートボリュームサイズには、パッチおよび診断ログに十分な容量を提供できるようなサイズを選

択してください。このクイックスタートでは、300 GiB のルートボリュームで Exchange マルチロー

ルサーバーがデプロイされます。AWS マネジメントコンソールまたは AWS CloudFormation テンプ

レートを使用してインスタンスを起動する際には、デフォルトのルートボリュームを変更すること

ができます。

• 最適なパフォーマンスを実現するためには、オペレーティングシステムのページングファイ

ルをオペレーティングシステムファイルとは別のボリュームに配置してください。インスタ

ンスストレージはこの目的での使用に適しています。

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.htmlhttp://www.microsoft.com/en-us/download/details.aspx?id=36849


2015 年 9 月

18/50 ページ

Server Role Requirements Calculator を使用してストレージを設計する場合、[Input] タブのステップ 4 で、各デ

ータセンターの [Server Disk Configuration] セクションを使用し、[Disk Type] の値として [7.2K RPM SATA 3.5"]

を選択します。システムボリュームについては、[Disk Capacity] を 100 GiB 以上に設定します。[Database +

Log] と [Restore Volume] については、この値を Amazon EBS ボリュームサイズの最大値である 1,000 GiB

に設定します。このディスクタイプは、Amazon EBS スタンダードボリュームのパフォーマンス特性に最も近

いものです。

図 11: [Input] タブの [Disk Configuration]

[Input] タブのステップ 3 で、[Backup Methodology] の値は [Software VSS Backup/Restore] または

[Exchange Native Data Protection] に設定する必要があります。

注意

Microsoft では、1 つのデータベース可用性グループ内でデータベースごとに 3 コピー以上を設定し

た場合を除き、[Exchange Native Data Protection] のみ (バックアップなし/レプリケーションのみ) の

使用は推奨されていません。Exchange PA に基づいたアーキテクチャについては、[Exchange Native

Data Protection] を選択できます。

図 12: [Input] タブの [Backup Configuration]


2015 年 9 月

19/50 ページ

ストレージに関するその他の考慮事項 Microsoft Exchange Server データベースとログファイルをサポートする Amazon EBS ボリュームのプロビジョニ

ングを行う場合、Microsoft では、これらの NTFS ボリュームをアロケーションユニットサイズ 64 KiB でフォー

マットすることが推奨されています。自動化された AWS CloudFormation テンプレートでは、デプロイメント

のサンプルシナリオ用に Amazon EBS ボリュームのプロビジョニングが自動的に行われます。推奨ベストプラ

クティスに基づくボリュームのフォーマットは、AWS によって行われます。これに加えて、Amazon EBS 最適化インスタンスは、Amazon EBS に対して所定のスループットを実現します。

Amazon EBS 最適化インスタンスにアタッチされると、汎用 (SSD) ボリュームの場合、1 年の 99.9% はベース

ラインパフォーマンスとバーストパフォーマンスの 10% 以内になるように設計されています。また、プロビ

ジョンド IOPS (SSD) ボリュームの場合、1 年の 99.9% は、プロビジョニングされたパフォーマンスの 10% 以

内になるように設計されています。詳細については、Amazon AWS ドキュメントの「Amazon EBS 最適化イン

スタンス」を参照してください。

Microsoft Exchange Server のデプロイメントでストレージを設定する際には、Microsoft で推奨されている

ベストプラクティスを参照してください。ストレージアーキテクチャの詳細と、ストレージ設定オプシ

ョンのベストプラクティスについては、Microsoft TechNet ライブラリの「Exchange 2013 記憶域構成オプ

ション」を参照してください。

ストレージとサーバーのパフォーマンスを検証する Microsoft Exchange Server メールボックスロールの設計を本稼働環境に配置する前に、ストレージサブシステ

ムをテストすることを検討してください。このテストでは、許容されるしきい値以下のレイテンシーで、必

要な IOPS がサポートされる設計であることを確認します。Exchange Server クライアントで許容されるエクス

ペリエンスを実現するには、ストレージサブシステムのパフォーマンスが重要になります。ストレージとサ

ーバーのパフォーマンスを検証するには、ツールとして Microsoft Exchange Server Jetstress 2013 と Microsoft

Exchange Load Generator 2013 を使用します。

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.htmlhttp://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.htmlhttp://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.htmlhttp://technet.microsoft.com/en-us/library/ee832792(v=exchg.150).aspxhttp://technet.microsoft.com/en-us/library/ee832792(v=exchg.150).aspxhttp://technet.microsoft.com/en-us/library/ee832792(v=exchg.150).aspx


2015 年 9 月

20/50 ページ

Microsoft Exchange Server Jetstress 2013 は、1 つまたは複数のデータベースに対する Exchange Server の現実的

な I/O パターンをシミュレートするために Microsoft Exchange Server チームから提供されている無料のツール

です。このツールは、指定されたテストデータベースをターゲットボリュームに作成し、クライアントアクセ

ス、バックグラウンドメンテナンス、トランザクションログのレプリケーションについて、シミュレート

されたトランザクションを実行します。ツールの動作は、GUI および設定 XML ファイルでカスタマイズでき

ます。シミュレーションの間は、さまざまな Exchange Server パフォーマンスカウンタの値が収集されます。

シミュレーションの最後には、データベースおよびトランザクションログの操作について、許容されるレイテ

ンシーのしきい値とパフォーマンスカウンタの値が比較されます。

Exchange Processor Query Tool v1.1 は、Microsoft TechNet ギャラリーからダウンロードできます。

Microsoft Exchange Load Generator 2013 を使用すると、さまざまなメッセージングクライアントソフトウェア

でのユーザー操作によって生成されるサーバーのワークロードをシミュレートすることによって、サーバ

ーのパフォーマンスを検証できます。これは、サーバーのサイズ決定やデプロイメント計画の検証を担当

する、サーバー管理者またはメッセージングデプロイメントエンジニアが利用できる、便利なツールです。

Exchange Load Generator は、予定されている負荷を各サーバーで処理できるかどうかを判断する際に役立

ちます。候補の Exchange Server デプロイメントに対して Exchange Load Generator を実行し、予想されるクライア

ント負荷に対する処理能力を検証することをお勧めします。Exchange Load Generator は、関係するすべての

システムのパフォーマンスに影響します。このため、このツールは、ターゲットデプロイメント用に

Exchange Server を完全に設定した後、本稼働のユーザーメールボックスや本稼働データを導入する前に実行

してください。

Exchange Load Generator 2013 は Microsoft Download Center からダウンロードできます。

http://www.microsoft.com/en-us/download/details.aspx?id=36849http://www.microsoft.com/en-us/download/details.aspx?id=40726


2015 年 9 月

21/50 ページ

ログのレプリケーションとネットワークトラフィック同じリージョン内の Amazon アベイラビリティーゾーンは高速リンクを経由して接続されます。Server Role

Requirements Calculator の [Input] タブのステップ 6 で [Network Link Type] に対して [Fast Ethernet] を選択

して、Exchange Server データベース可用性グループ (DAG) トランザクションログのレプリケーションの計画を

開始します。[Network Link Latency] はデフォルトの 50.00 のままにするか、より正確な値を設定するには一時

インスタンスの間に独自のテストを実行します。

図 13: [Input] タブのネットワーク設定

Exchange Client Network Bandwidth Calculator を使用すると、特定のクライアントのセットに対するネットワー

ク帯域幅の要件を予測できます。この計算ツールで使用される予測アルゴリズムは新たに組み込まれたもの

で、有意差検定と監視に基づいています。

Exchange Client Network Bandwidth Calculator は Microsoft TechNet Gallery からダウンロードできます。

高可用性をもたらす設計リージョンとアベイラビリティーゾーンインスタンスは、リージョンと呼ばれる複数の地理的場所にプロビジョニングできます。これらのリージョン

で Amazon EC2 インスタンスを作成することで、インスタンスを顧客に近づけることができます。たとえば、

ヨーロッパの顧客に近づけるため、または法的要件を満たすために、ヨーロッパでインスタンスを作成するこ

とができます。各リージョンにはアベイラビリティーゾーンがあります。アベイラビリティーゾーンは物理的に明確に区切

られた領域であり、他のゾーンの障害の影響を受けないように設計されています。アベイラビリティーゾー

ンは、同じリージョン内の他のゾーンに低価格かつ低レイテンシーのネットワーク接続を提供します。個別

のゾーンでインスタンスを作成することにより、障害がアベイラビリティーゾーン全体に影響を及ぼすこと

を防ぎ、アプリケーションを保護することができます。高可用性を実現するため、2 つ以上のアベイラビリ

ティーゾーンにまたがるように Exchange Server のデプロイを設計してください。

https://gallery.technet.microsoft.com/office/Exchange-Client-Network-8af1bf00


2015 年 9 月

22/50 ページ

企業のニーズに基づき、Exchange Server のデプロイが複数のリージョンにまたがるように設計することもで

きます。ただし、これを行うと設計が複雑になり、追加のネットワーキングやセキュリティに加えて、より

詳細なテストと継続的なモニタリングが必要になります。

Active Directory ドメインサービス Active Directory ドメインサービス (AD DS) は、Microsoft Exchange Server のデプロイの主要なコンポーネントで

す。Exchange Server は Active Directory と緊密に連携しています。Active Directory スキーマは、Exchange Server

による設定の保存先のオブジェクトに対して追加の属性をサポートするように拡張する必要があります。

また、複数の物理的な場所の間で内部メッセージをルーティングするために、Active Directory サイトトポロジ

が使用されます。Exchange PA に基づいたデプロイの設計では、各データセンターのペア (つまり各アベイラ

ビリティーゾーン) が個別の Active Directory サイトとして表されていることが前提となります。

AWS クラウドでの AD DS の使用方法は 3 通りあります。

• クラウドのみ – これは、このガイドの前半の図 1 および図 2 に示したアーキテクチャです。

このタイプのアーキテクチャは、Active Directory フォレスト全体が AWS クラウド内にのみ存在

することを意味します。クラウドのみの AD DS アーキテクチャでは、オンプレミスドメインコン

トローラーは存在しません。

• 従来のハイブリッドモデル – 既存の AD DS 環境を利用するハイブリッドアーキテクチャです。プラ

イベートのオンプレミスネットワークを AWS に拡張できるため、クラウド内のリソースは既存の AD

インフラストラクチャを活用できます。ハイブリッドアーキテクチャでは、AWS クラウド内の既存

の AD フォレストのドメインコントローラを利用することをお勧めします。これは主に、AWS 機能に

デプロイされていて、オンプレミスで停止が発生した場合に使用可能な Exchange サーバーを確保す

るために推奨されています。


2015 年 9 月

23/50 ページ

• AWS Directory Service を経由した AD Connector – AD Connector を使用すると、Directory Service のプロ

キシを AWS クラウドにプロビジョニングできます。VPN または AWS Direct Connect を経由して

AWS VPC からオンプレミス環境へのネットワーク接続を確保している場合、AD Connector を使用す

ると、Amazon Zocalo サイトや Amazon WorkSpaces を既存の AD DS 環境に簡単にプロビジョニン

グできます。ただし、AD Connector は AWS ベースの Exchange サーバーと併用しないでください。

Exchange サーバーは、書き込み可能なドメインコントローラーやグローバルカタログサーバーに

対し、これらが常駐している 1 つの Active Directory サイト内で、低レイテンシーで接続する必要が

あります。AD DS の実行にはクラウドのみのモデルまたは従来のハイブリッドモデルを使用して、

書き込み可能なドメインコントローラーとグローバルカタログを Exchange サーバーと同じアベイラ

ビリティーゾーンで使用できるようにすることをお勧めします。

Active Directory ドメインサービスのクイックスタートリファレンスデプロイメントでは、AWS に高可用性

AD DS 環境をデプロイする際のあらゆるベストプラクティスと推奨事項を取り上げています。このガイドで

提供されているマスター AWS CloudFormation テンプレートでは、その他のインフラストラクチャの基盤を

構築するため、最初に AD DS クイックスタートを起動します。これは、各アベイラビリティーゾーンの

Amazon VPC、パブリックサブネットとプライベートサブネット、NAT インスタンスとリモートデスクトップ

ゲートウェイ、およびドメインコントローラーの構築を行います。またこの自動デプロイの一環として、

Active Directory サイトとサービスも設定します。AD サイトはアベイラビリティーゾーンごとにプロビジョニ

ングし、同時に、各 Amazon VPC サブネットのオブジェクトを定義し、これらを適切な AD サイトにマッピン

グします。

Microsoft では、ドメインコントローラーが x64 (64 ビット) Windows プラットフォームで実行されている

場合、Active Directory グローバルカタログプロセッサコアとメールボックスロールのプロセッサコアを 1 対

8 の割合でデプロイすることを推奨しています。

https://s3.amazonaws.com/quickstart-reference/microsoft/activedirectory/latest/doc/Microsoft_Active_Directory_Quick_Start.pdf


2015 年 9 月

24/50 ページ

名前空間の設計と計画 Microsoft Exchange Server 2013 には名前空間の設計を簡略化する新しい機能が追加されています。

Exchange Server 2010 とは異なり、Exchange Server 2013 ではフェイルオーバーが発生した後に DAG と共にクラ

イアントの名前空間を移動する必要がありません。Exchange Server 2013 プロキシのクライアントアクセスロ

ールは、ユーザーのメールボックスのアクティブなデータベースコピーをホストしているメールボックスサー

バーにリクエストを転送します。サーバーがどの Active Directory サイトに常駐しているかは関係ありません。

これは、各データセンター、あるいはこの場合には各アベイラビリティーゾーンに対して一意の名前空間が必

要なくなったことを意味します。この新しいクライアントアクセスアーキテクチャに基づき、名前空間の設計には次の 2 つのモデルがあ

ります。

• バインドされていない名前空間 – このモデルでは、各アベイラビリティーゾーン内の Exchange

Server インフラストラクチャにアクセスを提供する、統合された名前空間を使用します。1 つの

アベイラビリティーゾーンが使用不可になった場合でも、クライアントは別の名前空間を使用し

なくても接続を維持できます。

• バインドされている名前空間 – このモデルでは、物理的な場所ごとに一意の名前空間を使用します。

アベイラビリティーゾーンは高速ネットワークリンクを経由して接続されているため、通常、名前空

間がバインドされているモデルを単一リージョンのデプロイで使用してもメリットがありません。

このモデルは、複数リージョンのデプロイで使用して、リージョン内のインフラストラクチャに地理

的に近いクライアントに名前空間を提供する際に検討してください。


2015 年 9 月

25/50 ページ

図 14: Amazon Route 53 でホストされているバインドされていない名前空間このクイックスタートは、2 つのアベイラビリティーゾーンにまたがる 1 つのリージョン内で、高可用性の

Microsoft Exchange Server インフラストラクチャを起動します。このアーキテクチャでは、単一のバインドさ

れていない名前空間 (mail.example.com など) の使用をお勧めします。AWS CloudFormation テンプレートを起

動し、スタックを作成した後は、バインドされていない統合された名前空間の設定に進みます。


2015 年 9 月

26/50 ページ

図 14 には、Amazon Route 53 ホストゾーンに加えて、アクティブ-アクティブフェイルオーバーレコードセ

ットと、エッジトランスポートサーバー上で実行されているリバースプロキシソリューションが示されてい

ます。このアーキテクチャでは、すべてのクライアントプロトコルは、単一のバインドされていない名前空

間により高い可用性が維持されます。Amazon Route 53、リバースプロキシ、およびエッジトランスポートの

設定オプションについては、このガイドの後半で詳しく説明します。名前空間の設計と計画の詳細については、Microsoft Exchange チームブログの「Namespace Planning in

Exchange 2013」をお読みください。

データベース可用性グループデータベース可用性グループ (DAG) は、メールボックスデータベースの高可用性とサイトの耐障害性を提供

するために Microsoft Exchange Server 2013 に組み込まれたコンポーネントです。DAG は、一連のデータベー

スをホストしている最大で 16 台のサーバーのグループです。DAG は、サーバー全体または個々のデータベ

ースに影響を及ぼす障害からの、データベースレベルでの自動復旧を可能にします。DAG 内のサーバーは、

DAG 内の他の任意のサーバーからのメールボックスデータベースのコピーをホストできます。DAG に追加さ

れたサーバーは DAG 内の他のサーバーと連携して、ディスク、サーバー、ネットワークの障害など、メール

ボックスデータベースに影響を及ぼす障害からの自動復旧を可能にします。単純な 2 ノードの DAG

Exchange Server の設計に Exchange PA を利用しない場合は、このクイックスタートが提供しているようなアー

キテクチャを実装できます。このアーキテクチャでは、複数のロールを持つ単一の Exchange Server を各アベ

イラビリティーゾーンにデプロイします。このモデルでは、各アベイラビリティーゾーン全体にまたがる単一

の DAG を設定します。

DAG を AWS にデプロイする際は、適切な IP アドレスを指定する必要があります。もちろん、各 DAG メン

バーにはオペレーティングシステムのプライマリ IP アドレスが必要になります。また、Exchange Server の

DAG では Windows Server フェイルオーバークラスタリング (WSFC) を使用するため、DAG メンバーが常駐

する各 Amazon VPC サブネット内に、DAG IP アドレスとして機能するセカンダリのプライベート IP アドレス

を割り当てる必要があります。DAG IP アドレスは、Windows フェイルオーバークラスタリングの IP アドレ

スリソースとして使用されます。

http://blogs.technet.com/b/exchange/archive/2014/02/28/namespace-planning-in-exchange-2013.aspxhttp://blogs.technet.com/b/exchange/archive/2014/02/28/namespace-planning-in-exchange-2013.aspx


2015 年 9 月

27/50 ページ

図 15: テンプレートのパラメータを使用してカスタマイズできる IP 設定

1 つの Elastic Network Interface (ENI) を使用して、複数のプライベート IP アドレスを Amazon EC2 インス

タンスに割り当てることができます。このクイックスタートが提供している AWS CloudFormation テンプ

レートは、この設定をサポートしています。

図 16: Exchange 管理シェルの DAG IP アドレスの表示図 16 は、このクイックスタートの起動に成功した後に作成された DAG のプロパティを示しています。

各インスタンスに対し、セカンダリのプライベート IP アドレスが DAG に静的に割り当てられています。

注意: Windows Server 2012 R2 で実行されている Exchange 2013 SP1 は、クラスターの管理アクセスポイント

(AAP) を使用しないで DAG をサポートしています。これは、クラスターが IP アドレスリソースを必要とし

ないことを意味します。AAP を使用しないで作成されるクラスターは、AdministrativeAccessPoint プロパテ

ィ値を None に設定して New-Cluster コマンドレットを実行することで作成できます。従来の AAP 設定の使

用を望まない場合には、このクラスター設定を使用できます。

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/MultipleIP.htmlhttps://technet.microsoft.com/en-us/library/Ee460973.aspx


2015 年 9 月

28/50 ページ

推奨アーキテクチャにおける DAG 設定

Exchange PA に従い、AWS で実行される Microsoft Exchange Server 2013 のデプロイを設計する場合は、単一の

DAG に含まれている各アベイラビリティーゾーン内に最低 2 つの Exchange サーバーを配置するモデルを使用

します。このアーキテクチャの主なメリットは以下のとおりです。

• 各アベイラビリティーゾーンだけでなく、AWS リージョン全体でメールボックスデータベースの高可用

性が得られます。

• 障害が発生した場合、サーバーの負荷は多数のサーバーに分散されるため、残りのサーバーのリ

ソースの利用が軽減されます。

• 各アベイラビリティーゾーンには少なくとも 2 つの Exchange サーバーが含まれているため、各デー

タベースのコピーは 4 つ以上になります。このモデルでは、3 つの高可用性 (HA) コピーと 1 つの遅

延コピーを実装できるため、従来のバックアップは必要ありません。これにより、Exchange ネイテ

ィブデータ保護 (バックアップを使用しないソリューション) を実装するのに十分なデータベースの

耐久性がもたらされるため、デプロイの総所有コスト (TCO) が削減されます。

AWS 上の DAG アーキテクチャでは、各アベイラビリティーゾーンで複数の DAG メンバーを利用する場合、

追加の計画と実装ステップが必要になります。前述のように、各 DAG メンバーには Amazon EC2 内でセカン

ダリのプライベート IP アドレスを割り当てる必要があります。このアドレスは、最終的に DAG と Windows

フェイルオーバークラスタリング専用になります。Amazon EC2 インスタンスはこれらのセカンダリ IP アド

レスを共有できないため、DAG メンバーを個別の Amazon VPC サブネットに配置できます。これにより、

DAG の各メンバーに対して DAG の IP アドレスを静的に定義できるようになります。

IP アドレスの要件をサポートするために、各 DAG メンバーをそれぞれの Amazon VPC サブネット内に配

置し、DAG を定義する際は、関連する各インスタンスに割り当てられているセカンダリのプライベート IP

アドレスを使用できます。これにより各 DAG メンバーは、必要に応じて定義済みの IP アドレスをオンライン

にすることができます。


2015 年 9 月

29/50 ページ

監視サーバーの配置

アベイラビリティーゾーン間でシームレスな自動フェイルオーバーを実現するために、監視サーバーを 3 番

目のアベイラビリティーゾーンに配置することをお勧めします。これにより、アベイラビリティーゾーンが

完全に停止した場合、それがどのアベイラビリティーゾーンであっても、クラスターのクォーラム、つまり

自動フェイルオーバーを維持し、達成できます。

図 17: 3 番目のアベイラビリティーゾーンへの監視サーバーの配置

3 番目のアベイラビリティーゾーンに監視サーバーを配置する設計は、このクイックスタートの起動後に手

動で実装する必要があります。デフォルトでは、このクイックスタートはオレゴンで起動します。このドキ

ュメントの執筆時点では、これには 3 つのアベイラビリティーゾーンが含まれます。デフォルトの設定を使

用してクイックスタートを起動した後に、必要に応じて 3 番目のアベイラビリティーゾーンに監視サーバ

ーを実装できます。


2015 年 9 月

30/50 ページ

DAG のネットワーク設計

Exchange Server 2010 のアーキテクチャでは、一般に、DAG 内に設定されているメールボックスサーバーごと

に複数のネットワークインターフェイスが含まれていました。これにより、クライアント (MAPI) 向けネットワ

ーク用の個々のネットワークインターフェイスと、データベースレプリケーション用の分離された専用レプリ

ケーションネットワークが提供されていました。近年の Microsoft Exchange Server 設計において高速ネットワークスループットが一般的になり、ネットワーク

インターフェイスは (物理的ではなく) 論理的な分離に過ぎないことが多くなるにつれ、Microsoft はクライア

ントトラフィックをレプリケーショントラフィックから分離させるという以前の方針を変えつつあります。

これにより、AWS への Exchange Server のデプロイの管理と初期設定が簡潔化されます。このモデルでは、

高いネットワークパフォーマンスを備えているか、10 ギガビットの接続が可能なインスタンスを利用するこ

とをお勧めします。

DAG のトピックは広範に及び、より規模が大きく複雑なデプロイではさまざまな設計上の考慮事項や運用手

順を理解する必要があります。このトピックについてさらに深く理解するには、Microsoft TechNet ライブラ

リの「データベース可用性グループ」のページをご覧になることをお勧めします。クライアントアクセスの負荷分散 Exchange Server 2013 における大きな変更の 1 つは、クライアントアクセスロールのアーキテクチャの再設

計です。Exchange Server 2013 には負荷分散 Layer でのセッションアフィニティ (スティッキーセッション)

は不要になりました。簡単に言うと、クライアントアクセスロールは、ユーザーのメールボックスデータベ

ースのアクティブなコピーをホストしているメールボックスサーバーに対してクライアント接続のプロキシ

を有効化できるようになりました。つまり、Exchange Server インフラストラクチャへのクライアント接続

には、確実に Layer 4 の負荷分散、つまり DNS 負荷分散を使用できます。

http://technet.microsoft.com/en-us/library/dd979799(v=exchg.150).aspx


2015 年 9 月

31/50 ページ

Amazon Elastic Load Balancing

Elastic Load Balancing は、受信アプリケーショントラフィックをクラウド内の複数の Amazon EC2 インスタン

スに自動的に分散させます。これはアプリケーションの耐障害性の向上を可能にし、アプリケーショントラ

フィックの分散に必要な負荷分散能力をシームレスに提供します。HTTPS/SSL 接続と HTTP/TCP 接続の両方に

使用できるポートリスナーは、25、80、443、465、587、および 1024-65535 です。POP や IMAP などの他のメ

ールプロトコルを負荷分散する必要がある場合は、このセクションの他のソリューションをご覧ください。

Amazon Route 53 を使用した DNS フェイルオーバー

Amazon Route 53 では、アクティブ/アクティブ構成、アクティブ/パッシブ構成、混合構成の DNS フェイル

オーバーを設定してアプリケーションの可用性を高めることができます。同じ機能を実行する複数のリソ

ースがある場合、リソースの正常性をチェックし、正常なリソースのみを使用して DNS クエリに応答するよ

うに Amazon Route 53 を設定できます。

DNS 負荷分散やフェイルオーバーを提供するには以下の構成が通常使用されます。

• アクティブ/アクティブフェイルオーバー: ほとんどの時間、すべてのリソースを稼働状態にする

には、この構成を使用します。リソースが利用できなくなると、Amazon Route 53 がそのリソースを異

常として検出し、以後、そのリソースはクエリへの応答に含まれなくなります。

• アクティブ/パッシブフェイルオーバー: ほとんどの時間、リソースのプライマリグループを稼働状態

にし、プライマリリソースがすべて利用できない状況になったときのためにリソースのセカンダリグ

ループを待機させるには、この構成を使用します。クエリへの応答で Amazon Route 53 が返すのは、

正常なプライマリリソースのみです。すべてのプライマリリソースで異常が発生した場合、

Amazon Route 53 は、DNS クエリへの応答として、正常なセカンダリリソースのみを返します。

Amazon Route 53 を使用すると、すべての外部 Exchange Server プロトコルに対してインターネット上で DNS フ

ェイルオーバーと負荷分散を低コストで簡単に提供できます。DSN レコードセットには低い有効期限 (TTL) 値

を使用してください。アベイラビリティーゾーンの機能停止という万一の場合には、正常な IP アドレスを解

決できるようになるまで、クライアントは一時的に切断されます。このため、DAG を使用している Exchange

データベースには高可用性も実装する必要があります。


2015 年 9 月

32/50 ページ

その他の負荷分散方法

AWS Marketplace には、サードパーティ製の負荷分散ソリューションが多数存在します。一般に使用されてい

るソリューションの例をいくつか示します。

• Citrix NetScaler VPX

• KEMP Virtual LoadMaster for AWS

• F5 BIG-IP Virtual Edition for AWS

一般的なガイダンスと詳細については、Microsoft Exchange チームブログの「Load Balancing

in Exchange 2013」をお読みください。

デプロイのサンプルシナリオ私たちは、AWS で Microsoft Exchange Server 2013 を実行するデプロイのサンプルシナリオを 3 つ作成してい

ます。これらは独自の要件を満たすための開始点として使用できます。このガイドの前半で説明した

Microsoft サイズ決定ツールを使用して独自の設計を作成し、検証テストを実行してください。ここで説明す

るシナリオは以下のとおりです。

• メールボックス 250 個 – 最初のシナリオでは、クイックスタートアーキテクチャを使用してメール

ボックス 250 個をサポートします。このアーキテクチャには、アベイラビリティーゾーンごとに 1

つの Exchange サーバーが必要です。

• メールボックス 250 個 – 2 番目のシナリオでは、Exchange PA に基づいたアーキテクチャを使用し

てメールボックス 250 個をサポートします。このアーキテクチャには、アベイラビリティーゾーン

ごとに 2 つの Exchange サーバーが必要です。

• メールボックス 2,500 個 – このシナリオはメールボックス 2,500 個をサポートし、アベイラビリテ

ィーゾーンごとに 4 つの Exchange サーバーを必要とします。

https://aws.amazon.com/marketplace/search/results/ref=dtl_navgno_search_box?page=1&searchTerms=Netscalerhttps://aws.amazon.com/marketplace/search/results/ref=gtw_navgno_search_box?page=1&searchTerms=kemphttps://aws.amazon.com/marketplace/pp/B00B9KW32I/ref=srh_res_product_title?ie=UTF8&sr=0-2&qid=1371498026383http://blogs.technet.com/b/exchange/archive/2014/03/05/load-balancing-in-exchange-2013.aspxhttp://blogs.technet.com/b/exchange/archive/2014/03/05/load-balancing-in-exchange-2013.aspx


2015 年 9 月

33/50 ページ

これらのシナリオは、プライベートサブネットに配置された複数ロールの Exchange サーバーインフラストラ

クチャのみに焦点を当てています。完全で高可用性の設計を実現するためにパブリックサブネットにエッジ

トランスポートとリバースプロキシインフラストラクチャをデプロイする場合は、このクイックスタートの

ガイダンスに従ってください。

注意各シナリオには、各 Exchange Server インスタンスに接続するための複数の Amazon EBS ボリュ

ームが必要です。デフォルトでは、AWS アカウントごとに 20 の Amazon EBS ボリュームのソフト

制限 (ボリュームタイプごと) が適用されます。必要に応じて、制限の引き上げをリクエストでき

ます。

また、これらのデプロイシナリオでは、Exchange データベースとログファイルに 1-TiB の

Amazon EBS ボリュームが使用されることが前提となっています。より大きなメールボックスを

サポートするには、さらに大きなボリュームをデプロイできますが、Server Role Requirements

Calculator を使用して、必要な IOPS を達成できることを検証してください。

メールボックス 250 個

メールボックス 250 個に対するクイックスタートアーキテクチャのデプロイシナリオ小規模または中規模のデプロイでは、最小限のインフラストラクチャを利用して高可用性を提供する、

つまり、アベイラビリティーゾーンごとに複数ロールの Exchange 2013 サーバーを 1 つ配置した設計を検討す

ることをお勧めします。図 18 は、Server Role Requirements Calculator の主な入出力の概要と、Exchange メール

ボックス 250 個をサポートする設計を作成するための Amazon EC2 インスタンスおよび Amazon EBS ボリューム

タイプに関する提案を示しています。

メールボックス 250 個のデプロイシナリオメールボックスのサイズ 20 GiB メールボックスごとの 1 日のアイテム送受信合計数

200

平均アイテムサイズ 75 KiB Exchange インスタンスタイプ r3.xlarge (4 vCPU、30.5 GiB) Exchange Server ごとに必要なメモリ 24 GiB サーバーの CPU 使用率 37%

https://aws.amazon.com/contact-us/ebs_volume_limit_request/


2015 年 9 月

34/50 ページ

メールボックス 250 個のデプロイシナリオ DAG の数 1 Exchange データベースの合計数 10 (データベースごとにメールボックス 28 個、10% の予

測成長率を含む) EBS ボリュームごとの Exchange データベースの数

1

Exchange Server インスタンスごとの EBS ボリュームの数

11 ボリューム (各 1 TiB、復元用ボリュームを含む)

DAG ごとの HA データベースコピーの数 2 DAG ごとの遅延データベースコピーの数 0 データオーバーヘッド率 20% (予期しないデータベースの増大に対応するため) バックアップ方法ソフトウェア VSS ベースのバックアップ EBS ボリュームタイプ汎用 (SSD) AZ ごとの Exchange Server インスタンスの数

1

Exchange Server インスタンスの合計数 2

図 18: メールボックス 250 個に対するデプロイのサンプルシナリオ

R3 メモリ最適化インスタンスタイプは、AWS で Microsoft Exchange Server 2013 を実行するのに適した候補で

すが、要件に基づいて最適なインスタンスタイプを選択できます。r3.xlarge、r3.2xlarge、および r3.8xlarge の

インスタンスタイプは Amazon EBS の最適化と高ネットワークパフォーマンスに対応し、r3.8xlarge のインス

タンスタイプは 10 ギガビットのネットワーク接続に対応しています。メモリ最適化 R3 インスタンスタイプ

はすべて、拡張ネットワーキングに対応しています。

r3.xlarge インスタンスタイプは 30.5 GiB のメモリを提供します。これは、図 18 に示すように、計算ツー

ルで推定される要件を大きく上回っています。

重要

Exchange ネイティブデータ保護には高可用性データベースのコピーが 2 つしかないためお勧めで

きず、独自のバックアップソリューションを実装する必要があります。この設計では最大で

750 GiB のメールボックスデータベースサイズを使用します。データベースの復元に対する目標復

旧時間 (RTO) の要件を満たすため、より低いデータベースサイズ制限を検討する必要が生じるこ

ともあります。この設計では、各 Exchange Server にはデータ復元専用の追加の Amazon EBS ボリ

ュームがプロビジョニングされています。


2015 年 9 月

35/50 ページ

Microsoft では、DAG に高可用性データベースのコピーが 2 つ以下しかない場合には、1 つのボリュームに複

数のデータベースを使用しないことを推奨しています。したがって、この設計では 1 つのボリュームに 1 つ

のデータベースのモデルを使用します。

注意

このクイックスタートでは、2 つのアベイラビリティーゾーンに対して 2 つの Exchange サーバー

をデプロイしてこの設計シナリオをサポートします。ただし、Exchange データベースに対してはサ

ーバーごとに 1 つの追加の Amazon EBS ボリュームしかプロビジョニングしません。この設計で必

要なボリューム数をサポートするには、デフォルトの Amazon EBS ボリューム制限を引き上げる必

要があるためです。これは、制限の引き上げをリクエストした後に、設定後に行う手動のタスクと

して処理できます。メールボックス 250 個に対する推奨アーキテクチャデプロイシナリオ

Exchange PA に従ったアーキテクチャを設計すると、耐障害性が向上し、従来のバックアップが不要になりま

す。図 19 は、Exchange PA に基づいたアーキテクチャでユーザー 250 人に対応したサンプルシナリオです。

Server Role Requirements Calculator からの主な入出力の概要と、Amazon EC2 インスタンスおよび Amazon EBS

ボリュームタイプに関する提案を示しています。

メールボックス 250 個のデプロイシナリオメールボックスのサイズ 20 GB メールボックスごとの 1 日のアイテム送受信合計数

200

平均アイテムサイズ 75 KiB Exchange インスタンスタイプ r3.xlarge (4 vCPU、30.5 GiB) Exchange Server ごとに必要なメモリ 16 GiB サーバーの CPU 使用率 23% DAG の数 1 Exchange データベースの合計数 40 (データベースごとにメールボックス 7 個、10% の予

測成長率を含む)


2015 年 9 月

36/50 ページ

メールボックス 250 個のデプロイシナリオ EBS ボリュームごとの Exchange データベースの数

4

Exchange Server インスタンスごとの EBS ボリュームの数

10 個のボリューム (各 1 TiB)

DAG ごとの HA データベースコピーの数 3 DAG ごとの遅延データベースコピーの数 1 (7 日のログ再生遅延) データオーバーヘッド率 20% (予期しないデータベースの増大に対応するため) バックアップ方法 Exchange ネイティブデータ保護 EBS ボリュームタイプ汎用 (SSD) AZ ごとの Exchange Server インスタンスの数

2

Exchange Server インスタンスの合計数 4

図 19: Exchange PA に基づいたメールボックス 250 個に対するデプロイのサンプルシナリオこの設計は、アベイラビリティーゾーンごとに 2 つの Exchange サーバーを提供します。したがって、

サーバーごとのメモリと CPU の要件は、前の 1 つのゾーンに 1 つのサーバーの設計に比べて軽減されてい

ます。メールボックス 2,500 個数千人規模のユーザーをサポートする設計の構築を始める場合、最小のインフラストラクチャ (複数ロールの

Exchange 2013 サーバー 2 つ) は実用的ではありません。一般的に、これは各インスタンスに接続する必要の

ある Amazon EBS ボリュームの数に起因します。通常、多数のメールボックスをサポートする設計では、アベ

イラビリティーゾーンごとに複数の Exchange サーバーをデプロイするためのスケールアウトが必要になる

ため、アーキテクチャについて Exchange PA に従うことを検討してください。


2015 年 9 月

37/50 ページ

図 20 は、Server Role Requirements Calculator の主な入出力の概要と、Exchange PA に基づいたアーキテクチャ

でメールボックス 2,500 個をサポートする設計を作成するための Amazon EC2 インスタンスおよび

Amazon EBS ボリュームタイプに関する提案を示しています。

2,500 のメールボックスのデプロイシナリオメールボックスのサイズ 5 GB メールボックスごとの 1 日のアイテム送受信合計数

200

平均アイテムサイズ 75 KiB Exchange インスタンスタイプ r3.2xlarge (8 vCPU、61 GiB)

Microsoft Exchange Server 2013d0.awsstatic.com/International/ja_JP/Whitepapers/...Exchange Server...

Documents

Transcript of Microsoft Exchange Server 2013d0.awsstatic.com/International/ja_JP/Whitepapers/...Exchange Server...