Exchange 2010 のテスト済みソリューション: Cisco Unified Compute System Blade Server と EMC CLARiiON Storage 上で Hyper-V を実行している 3 つのサイトのメールボックス 32400 件

 

Rob Simpson、プログラム マネージャー、Microsoft Exchange; Boris Voronin、シニア ソリューション エンジニア、Exchange ソリューション エンジニアリング、EMC; Mike Mankovsky、Microsoft ソリューション アーキテクト、Cisco

日付

2011 年 6 月

Exchange 2010 ソリューションのテスト

Exchange 2010 ソリューションのテストでは、Microsoft と参加するサーバー、ストレージ、およびネットワークの各パートナーが、顧客向けの一般的なシナリオや、Microsoft Exchange Server 2010 の展開を計画する顧客が直面する主な設計上の決定点を調査します。この一連のホワイト ペーパーでは、Microsoft のサーバー、ストレージ、およびネットワークの各パートナーによって提供されるハードウェア上に、適切に設計された費用対効果の高い Exchange 2010 ソリューションを展開する場合の例を示します。

このドキュメントは、Microsoft ダウンロード センターからダウンロードできます。

適用対象

Microsoft Exchange Server 2010 Service Pack 1 (SP1)

Windows Server 2008 R2

Windows Server 2008 R2 Hyper-V

目次

• はじめに

• ソリューションの概要

• 顧客の要件

  • メールボックス プロファイルの要件

  • 地理的な場所の要件

  • サーバー保護およびデータ保護の要件

• 設計上の前提条件

  • サーバー構成の前提条件

  • ストレージ構成の前提条件

• ソリューションの設計

  • 高可用性の戦略を決定する

  • メールボックスのストレージ容量の要件を推定する

  • メールボックス I/O の要件を推定する

  • ストレージの種類を決定する

  • DAS または SAN ストレージ ソリューションを選択する

  • ストレージ ソリューションを選択する

  • メールボックスのメモリ要件を推定する

  • 必要なデータベース キャッシュを計算する

  • メールボックスの CPU 要件を推定する

  • メールボックスの要件をまとめる

  • サーバー モデルを決定する

  • サーバー モデルの CPU 処理能力を計算する

  • 必要な物理的メールボックス サーバーの数を決定する

  • 通常の運用シナリオと障害シナリオにおけるメールボックス サーバーあたりのアクティブなメールボックスの数を決定する

  • クライアント アクセス サーバーの役割とハブ トランスポート サーバーの役割を個別の物理サーバーに展開するかどうかを決定する

  • 必要なクライアント アクセスおよびハブ トランスポートの物理的組み合わせサーバーの数を決定する

  • 必要な物理サーバーの合計数を決定する

  • サーバー仮想化を使用するかどうかを決定する

  • 仮想化を使用して物理サーバーの数を削減できるかどうかを確認する

  • Hyper-V ルート サーバーの CPU 処理能力を計算する

  • 仮想化のオーバーヘッドを考慮して利用可能なメガサイクルを調整する

  • VM の CPU 処理能力を決定する

  • プライマリ メールボックス サーバー VM の CPU 処理能力を確認する

  • セカンダリ メールボックス サーバー VM の CPU 処理能力を確認する

  • プライマリ メールボックス サーバー VM ごとに必要なメモリを決定する

  • セカンダリ メールボックス サーバー VM ごとに必要なメモリを決定する

  • クライアント アクセス サーバーとハブ トランスポート サーバーの組み合わせごとに必要なメモリを決定する

  • Hyper-V ルート サーバーごとに必要なメモリを決定する

  • データベース可用性グループを設計する

  • データベース コピーのレイアウト設計

  • データセンターのアクティブ化調整モード

  • ファイル共有監視機能の配置を決定する

  • 名前空間を計画する

  • クライアント アクセス サーバー アレイと負荷分散戦略を決定する

  • ハードウェア負荷分散モデルを決定する

  • ストレージの設計を決定する

• ソリューションの概要

  • 論理ソリューションの図

  • 物理ソリューションの図

  • Hyper-V ルート サーバー構成の概要

  • クライアント アクセス サーバーとハブ トランスポート サーバーの構成

  • メールボックス サーバーの構成

  • データベース レイアウト

  • ストレージ ハードウェアの概要

  • ストレージの構成

• ソリューションの検証方法

  • ストレージの設計の検証方法

  • サーバー設計の検証

  • 機能検証テスト

  • データベースの切り替えの検証

  • サーバーの切り替えの検証

  • サーバーのフェールオーバーの検証

  • データセンターの切り替えの検証

  • プライマリ データセンター サービスの復元の検証

  • テスト設備

• ソリューション検証結果

  • 機能の検証結果

  • ストレージ設計の検証結果

  • サーバー設計の検証結果

• 終わりに

• 追加情報

はじめに

このドキュメントでは、Cisco Unified Computing System ブレード サーバーおよび EMC CLARiiON ストレージ ソリューション上 32,400 のメールボックスを展開している顧客の環境で、Windows Server 2008 R2 Hyper-V テクノロジと共に稼働する Exchange Server 2010 ソリューションを設計、テスト、および検証する方法の例について説明します。大規模な Exchange 2010 環境を設計する場合の主な課題の 1 つは、サーバーおよびストレージで使用可能な現在のオプションを調査することと、ソリューションの予測される使用期間全体にわたり最高の価値をもたらすハードウェアを適切に選択することです。このドキュメントの段階的な手順に従うことで、これらの主な課題に対処するための重要な設計上の決定点を確認しながら、顧客の中心的なビジネスの要件を確実に満たすことができます。顧客向けに最適なソリューションが決定されると、標準的な検証プロセスによって、そのソリューションが通常の運用、保守、および障害のシナリオをシミュレートした運用環境のワークロードに耐えられることが保証されます。

Exchange 2010 ソリューションのテスト

ソリューションの概要

以下の表は、このソリューションにおける主な Exchange コンポーネントとハードウェア コンポーネントです。

Exchange コンポーネント

Exchange コンポーネント	値または説明
目標のメールボックス数	32400
目標の平均メールボックス サイズ	2 ギガバイト (GB) (600 メガバイト (MB) の初期サイズでシン プロビジョニング)
目標の平均メッセージ プロファイル	1 日あたり 100 メッセージ
データベース コピーの数	3
ボリューム シャドウ コピー サービス (VSS) バックアップ	なし
サイトの復元	○
サイトの数	3
データベース可用性グループ (DAG) モデル	アクティブ/アクティブ分散 (複数の DAG)
仮想化	Hyper-V
Exchange サーバーの数	4 つの仮想マシン (VM)
物理サーバーの数	2

ハードウェア コンポーネント

ハードウェア コンポーネント	値または説明
サーバー パートナー	Cisco
サーバー モデル	M200
サーバーの種類	ブレード
プロセッサ	Intel Xeon X5570
ストレージ パートナー	EMC
ストレージ モデル	CX4-480
ストレージの種類	ストレージ エリア ネットワーク (SAN)
ディスクの種類	450 GB 15,000 SAS 3.5"
負荷分散パートナー	Cisco
ハードウェア負荷分散モデル	ACE

Exchange 2010 ソリューションのテスト

顧客の要件

Exchange ソリューションの設計で最も重要な最初の手順の 1 つは、適切な設計上の決定を行う上で重要なビジネス要件と技術要件を正確にまとめることです。以下のセクションでは、このソリューションに関する顧客の要件について説明します。

Exchange 2010 ソリューションのテスト

メールボックス プロファイルの要件

メールボックス プロファイルの要件は、設計上の他のすべてのコンポーネントに影響を与える可能性があるため、できる限り正確に決定してください。Exchange を初めて使用する場合、状況によっては経験を頼りに推測する必要があります。Exchange 環境が既に存在する場合、Microsoft Exchange Server Profile Analyzer ツールを使用してこの情報の大部分を収集できます。以下の各表は、このソリューションのメールボックス プロファイルの要件の概要です。

メールボックス数の要件

メールボックス数の要件	値
メールボックス数 (リソース メールボックスを含むメールボックスの合計数)	30000
メールボックス数の予測される増加率 (%) (ソリューションの使用期間全体にわたり予測されるメールボックス数の増加)	8%
予測されるメールボックスの同時実行 % (任意の時点でアクティブなメールボックスの最大数)	100%
目標のメールボックス数 (増加率 x 予測同時実行を考慮したメールボックス数)	32400

メールボックス サイズの要件

メールボックス サイズの要件	値
メールボックスの平均サイズ (MB)	600 MB
メールボックス アーカイブ の平均サイズ (MB)	該当なし
メールボックス サイズ (MB) の予測される増加率 (%) (ソリューションの使用期間全体にわたり予測されるメールボックス サイズの増加)	230%
目標の平均メールボックス サイズ (MB)	2,048 MB

メールボックス プロファイルの要件

メールボックス プロファイルの要件	値
目標のメッセージ プロファイル (1 日あたりにユーザーごとに送受信されるメッセージの平均合計数)	1 日あたり 100 メッセージ
目標の平均メッセージ サイズ (KB)	75
MAPI キャッシュ モードの割合	100
MAPI オンライン モードの割合	0
Outlook Anywhere キャッシュ モードの割合	0
Microsoft Office Outlook Web App の割合 (Exchange 2007 以前のバージョンの Outlook Web Access)	0
Exchange ActiveSync の割合	0

Exchange 2010 ソリューションのテスト

地理的な場所の要件

メールボックス ユーザーとデータセンターの分布を理解することは、高可用性およびサイトの復元に関する設計上の決定を行う上で重要です。

以下の表は、Exchange システムを使用するユーザーの地理的な分布の概要です。

ユーザーの地理的な分布

メールボックス ユーザーのサイトの要件	値
メールボックス ユーザーを含む主要なサイトの数	3
サイト 1 のメールボックス ユーザーの数	10800
サイト 2 のメールボックス ユーザーの数	10800
サイト 3 のメールボックス ユーザーの数	10800

以下の表は、Exchange の電子メール インフラストラクチャをサポートする可能性のあるデータセンターの地理的な分布の概要です。

データセンターの地理的な分布

データセンターのサイトの要件	値
データセンターの合計数	3
データセンター 1 の近くにあるアクティブなメールボックスの数	10800
データセンター 2 の近くにあるアクティブなメールボックスの数	10800
データセンター 3 の近くにあるアクティブなメールボックスの数	10800
Exchange が複数のデータセンター内に存在する必要性	○

Exchange 2010 ソリューションのテスト

サーバー保護およびデータ保護の要件

環境におけるサーバー保護およびデータ保護の要件も、高可用性とサイトの復元に関する設計上の決定に役立つため、定義することが重要です。

以下の表は、サーバー保護の要件です。

サーバー保護の要件

サーバー保護の要件	値
サイト内でのサーバーまたは VM の同時障害の数	1
サイト障害時におけるサーバーまたは VM の同時障害の数	0

以下の表は、データ保護の要件です。

データ保護の要件

データ保護の要件	値または説明
Exchange 環境の外部で Exchange データベースのバックアップを維持する必要性 (サード パーティのバックアップ ソリューションなど)	X
Exchange 環境の内部で Exchange データベースのコピーを維持する必要性 (Exchange ネイティブ データ保護など)	○
プライマリ データセンターでメールボックス データの複数のコピーを維持する必要性	○
セカンダリ データセンターでメールボックス データの複数のコピーを維持する必要性	X
Exchange データベースの時間差コピーを維持する必要性	X
時間差コピー期間 (日)	該当なし
データベース コピーの目標数	3
削除済みアイテム フォルダーの保存期間 (日)	14

Exchange 2010 ソリューションのテスト

設計上の前提条件

このセクションでは、一般的に顧客の要件の一部としては収集されないが、設計および設計の検証の両方に不可欠な情報を提供します。

Exchange 2010 ソリューションのテスト

サーバー構成の前提条件

以下の表は、通常の運用状態と、サイトのサーバー障害またはサーバー保守の状態に応じたピーク CPU 使用率の目標値を表しています。

サーバー使用率の目標値

ターゲット サーバー CPU 使用率の設計上の前提条件	値
メールボックス サーバーの通常運用	<70%
クライアント アクセス サーバーの通常運用	<70%
ハブ トランスポート サーバーの通常運用	<70%
複数のサーバーの役割 (クライアント アクセス サーバー、ハブ トランスポート サーバー、およびメールボックス サーバー) の通常運用	<70%
複数のサーバーの役割 (クライアント アクセス サーバーとハブ トランスポート サーバー) の通常運用	<70%
メールボックス サーバーのノード障害	<80%
クライアント アクセス サーバーのノード障害	<80%
ハブ トランスポート サーバーのノード障害	<80%
複数のサーバーの役割 (クライアント アクセス サーバー、ハブ トランスポート サーバー、およびメールボックス サーバー) のノード障害	<80%
複数のサーバーの役割 (クライアント アクセス サーバーとハブ トランスポート サーバー) のノード障害	<80%
メールボックス サーバーのサイト障害	<80%
クライアント アクセス サーバーのサイト障害	<80%
ハブ トランスポート サーバーのサイト障害	<80%
複数のサーバーの役割 (クライアント アクセス サーバー、ハブ トランスポート サーバー、およびメールボックス サーバー) のサイト障害	<80%
複数のサーバーの役割 (クライアント アクセス サーバーとハブ トランスポート サーバー) のサイト障害	<80%

Exchange 2010 ソリューションのテスト

ストレージ構成の前提条件

以下の表に、ストレージ構成を設計する場合のデータ構成および入出力 (I/O) の前提条件を示します。

データ構成の前提条件

データ構成の前提条件	値または説明
データ オーバーヘッド係数	20%
1 週あたりのメールボックス移動	1%
専用の保守または復元の論理ユニット番号 (LUN)	X
LUN の空き領域	20%
ログ配布の圧縮の有効化	○
ログ配布の暗号化	○

I/O 構成の前提条件

I/O 構成の前提条件	値または説明
I/O オーバーヘッド係数	20%
追加の I/O 要件	なし

Exchange 2010 ソリューションのテスト

ソリューションの設計

以下のセクションでは、このソリューションを設計するための詳細な手順について説明します。この手順では、顧客の要件と設計上の前提条件を取り上げ、Exchange 2010 環境を設計する場合に判断する必要のある主な設計上の決定点について確認します。

Exchange 2010 ソリューションのテスト

高可用性の戦略を決定する

Exchange 2010 環境の設計において、高可用性の戦略に関する設計上の決定点の多くが、他の設計コンポーネントに影響を与えます。高可用性の戦略は、設計プロセスの最初の手順で決定することをお勧めします。また、この手順を開始する前に以下の情報を確認することを強くお勧めします。

• 高可用性の要因について

• 高可用性とサイト復元の計画

• バックアップ、復元、および障害復旧について

手順 1:サイトの復元が必要かどうかを決定する

複数のデータセンターがある場合、Exchange インフラストラクチャを単一のデータセンターに展開するか、2 つ以上のデータセンターに分散するかを決定する必要があります。組織の回復サービス レベル契約 (SLA) で、プライマリ データセンターの障害後に必要とされるサービスのレベルが定義されます。この情報が、ここでの決定事項の基盤となります。

* 設計上の決定点 *

このソリューションでは、物理的なデータセンターは 3 箇所にあります。SLA には、電子メールを含むすべてのミッション クリティカルなサービスについてデータセンターの復元が必要であることが記載されています。Exchange 2010 の設計においては、複数のサイトへの展開、およびメッセージング サービスとデータに関するサイトの復元が基盤となります。

手順 2:メールボックス ユーザーの場所とデータセンターの場所との関係を決定する

この手順では、すべてのメールボックス ユーザーが主に 1 つのサイトに存在しているのか、または、メールボックス ユーザーが多くのサイトに分散しており、その各サイトがデータセンターに関連付けられているかどうかを確認します。メールボックス ユーザーが多くのサイトに分散しており、そのサイトに関連付けられたデータセンターが存在する場合、メールボックス ユーザーとそのサイトに関連付けられたデータセンターとの間でアフィニティを維持する必要があるかどうかを決定します。

* 設計上の決定点 *

この例では、3 つのデータセンターは、それぞれ各支社と同じ場所に存在します。通常の運用状態では、ユーザーの場所とメールボックスのプライマリ アクティブ コピーの場所とのアフィニティは維持するという要求があります。

手順 3:データベース分散モデルを決定する

顧客は、Exchange インフラストラクチャを複数の物理的な場所に展開することに決定しているため、どのデータベース分散モデルが組織のニーズに最も適合するかを決定する必要があります。以下の 3 つのデータベース分散モデルがあります。

• アクティブ/パッシブ分散   プライマリ データセンターにアクティブなメールボックス データベース コピーが展開され、セカンダリ データセンターにはパッシブ データベース コピーのみが展開されます。セカンダリ データセンターはスタンバイ データセンターとして機能し、通常の運用状態では、このデータセンターにホストされるアクティブなメールボックスはありません。プライマリ データセンターに影響を与える停止状態が発生した場合、手動でセカンダリ データセンターに切り替えられ、プライマリ データセンターがオンラインに復帰するまでアクティブ データベースはセカンダリ データセンターにホストされます。

  アクティブ/パッシブ分散

• アクティブ/アクティブ分散 (単一の DAG)   アクティブなメールボックス データベースが、プライマリ データセンターとセカンダリ データセンターに展開されます。対応するパッシブ コピーは、代替データセンターに配置されます。すべてのメールボックス サーバーが単一の DAG のメンバーです。このモデルでは、2 つのデータセンター間のワイド エリア ネットワーク (WAN) 接続が潜在的な単一障害点です。WAN 接続が切断されると、いずれかのデータセンターのメールボックス サーバーは、クォーラムが失われるためにエラー状態に移行します。

  アクティブ/アクティブ分散 (単一の DAG)

• アクティブ/アクティブ分散 (複数の DAG)   このモデルでは、複数の DAG を利用して、単一障害点となる WAN 接続を排除します。1 つの DAG は、アクティブ データベース コピーをプライマリ データセンター内に保持し、対応するパッシブ データベース コピーをセカンダリ データセンター内に保持しています。もう 1 つの DAG は、アクティブ データベース コピーをセカンダリ データセンター内に保持し、対応するパッシブ データベース コピーをプライマリ データセンター内に保持しています。WAN 接続が切断されても、ローカル メールボックス ユーザーは、引き続き各サイトのアクティブ コピーを通じてデータベースを使用できます。

  アクティブ/アクティブ分散 (複数の DAG)

* 設計上の決定点 *

この例では、アクティブなメールボックス データベースは、データセンターの 3 つの場所にそれぞれ展開されるため、データベース分散モデルは複数の DAG を使用するアクティブ/アクティブ モデルになります。複数の DAG を使用するアクティブ/アクティブ データベース分散モデルを展開する場合には、他にもいくつかの設計上の考慮事項がありますが、それについては後の手順で説明します。

手順 4:バックアップおよびデータベースの復元戦略を決定する

Exchange 2010 の新機能と主要部分の変更により、展開と構成を正しく行えば、ネイティブ データ保護機能を使用でき、従来のデータ バックアップが不要になります。バックアップは、通常、障害回復、誤って削除されたアイテムの回復、データの長期保存、および特定時刻のデータベースの回復に使用されます。Exchange 2010 では、従来のバックアップを必要とせずに、以下のすべてのシナリオに対応できます。

• 障害回復   ハードウェア障害またはソフトウェア障害の発生時には、DAG 内の複数のデータベース コピーにより、フェールオーバーがデータの損失なく短時間で行われるため、高可用性を実現できます。DAG を複数のサイトに拡張し、データセンターの障害からの復元に利用することもできます。

• 誤って削除されたアイテムの回復   Exchange 2010 の新しい回復可能なアイテム フォルダーを使用し、フォルダーに保留ポリシーを適用すると、すべての削除済みデータと変更済みのデータを特定の期間、保持することができるため、アイテムをより簡単に回復できます。詳細については、「メッセージングのポリシーと準拠」、「回復可能なアイテムについて」、および「保持タグおよびアイテム保持ポリシーについて」を参照してください。

• データの長期保存   バックアップはアーカイブ目的で行われる場合もあります。通常、テープを使用して、ある特定時刻のデータのスナップショットを法令遵守の要件に従って、長期間保存します。Exchange 2010 の新しいアーカイブ機能、複数のメールボックスの検索機能、およびメッセージ保持機能により、エンド ユーザーがアクセス可能な方法で長期間、データを効率的に保存する仕組みが得られます。詳細については、「個人アーカイブについて」、「複数のメールボックスの検索について」、および「保持タグおよびアイテム保持ポリシーについて」を参照してください。

• データベースの特定時刻のスナップショット   組織で、メールボックス データの過去の特定時刻のコピーが必要な場合は、Exchange の機能を使用して DAG 環境で時間差コピーを作成できます。これは、DAG でデータベース全体をレプリケートする論理的な破損が発生し、過去の時点に戻る必要が生じた、稀なイベントで有効です。管理者が誤ってメールボックスまたはユーザー データを削除した場合にも役立ちます。

Exchange 2010 に組み込まれた機能を従来のバックアップの代替として使用するには、いくつかの技術的な根拠や問題を考慮する必要があります。この決定を行う前に、「バックアップ、復元、および障害復旧について」を参照してください。

* 設計上の決定点 *

現在の Exchange 実装に基づくこの例では、従来のバックアップ ソリューションの主な用途は、誤って削除されたメール アイテムの回復です。単一アイテムの回復に対する要求の 80% は、過去 15 日未満のメッセージを対象としています。したがって、削除済みアイテムの保存期間は 14 日になります。従来の VSS バックアップは、単一アイテムの復元には必要ではなく、目標回復時間が満たされないため、Exchange ネイティブ データ保護および削除済みアイテム フォルダーの保存期間の機能がデータベースの復元戦略として使用されます。

手順 5:必要なデータベース コピーの数を決定する

データベースの復元戦略を定義する場合、次に重要な決定事項は、展開するデータベース コピーの数を決定することです。RAID (Redundant Array of Independent Disks) や従来の VSS ベース バックアップのような、従来の形式のデータベース保護を終了する前に、少なくとも 3 つのメールボックス データベースのコピーを展開することを強くお勧めします。

この決定を行う前に、「メールボックス データベース コピーについて」を参照してください。

* 設計上の決定点 *

この例では、従来の VSS バックアップ ソリューションは展開されないため、目標回復時間と目標回復時点の要件を確実に満たすように、少なくとも 3 つのデータベース コピーが展開されます。2 つのコピーはプライマリ データセンターに配置され、3 番目のコピーはサイトの復元に対応するために代替データセンターに配置されます。

手順 6:データベース コピーの種類を決定する

データベース コピーには、次の 2 種類があります。

• 高可用性データベース コピー   このデータベース コピーは、再生ラグ タイムがゼロとして構成されます。名前が示すとおり、高可用性データベース コピーはシステムによって最新の状態に維持され、システムが自動的にアクティブ化することができ、メールボックス サービスとデータの高可用性を提供するために使用されます。

• 時間差データベース コピー   このデータベース コピーは、一定期間トランザクション ログの再生を遅らせるように構成されます。時間差データベース コピーは、特定の時点の保護を行うように設計されており、ストアの論理的破損、管理エラー (たとえば、接続を解除されたメールボックスの削除や破棄)、および自動化エラー (たとえば、接続を解除されたメールボックスの一括破棄) からの回復に使用できます。

* 設計上の決定点 *

この例では、3 つのメールボックス データベース コピーのすべてが高可用性コピーとして展開されます。SLA では、データの時間差コピーは要求されません。過去に論理的破損が発生したことがなく、メッセージング データを操作する他のアプリケーションは使用しないため、時間差コピーは必要ありません。この他に時間差コピーが必要になる場合として、単一の削除済みアイテムを回復する場合が考えられますが、削除済みアイテム フォルダーの保存期間の機能を使用すれば、はるかに簡単で効率的にこの要件を満たすことができます。

手順 7:メールボックス サーバーの復元戦略を決定する

Exchange 2010 では、メールボックスの復元機能が再設計されました。自動フェールオーバー保護は、サーバー レベルではなくメールボックス データベース レベルで提供されるようになりました。DAG 内のメールボックス サーバーに、アクティブ データベース コピーとパッシブ データベース コピーを戦略的に分散できます。サーバー単位でアクティブ化する予定のデータベース コピーの数を決定することは、Exchange 2010 の容量を計画する上で中心的な要素です。さまざまなデータベース分散モデルを展開できますが、一般的には以下のいずれかをお勧めします。

• すべてのコピーをアクティブにする設計   このモデルでは、メールボックス サーバーの役割は、サーバー上のすべてのデータベース コピーをアクティブにできるようにサイズ調整されます。たとえば、1 つのメールボックス サーバーに 4 つのデータベース コピーをホストするとします。通常の運用状態では、このサーバーには 2 つのアクティブ データベース コピーと 2 つのパッシブ データベース コピーが格納されます。障害時または保守時には、4 つのすべてのデータベース コピーがメールボックス サーバーでアクティブになります。このソリューションは、通常はペアで展開されます。たとえば、4 台のサーバーを展開する場合、第 1 のペアはサーバー MBX1 と MBX2 であり、第 2 のペアはサーバー MBX3 と MBX4 です。また、このモデルに基づいて設計する場合、通常の運用状態では使用可能なリソースの 40% 以下になるように各メールボックス サーバーをサイズ調整します。3 つのデータベース コピーと 6 台のサーバーが存在するサイトの復元の展開では、このモデルを 3 台 1 組のサーバーに展開できます (3 番目のサーバーはセカンダリ データセンターに存在します)。このモデルでは、アクティブ/パッシブ サイト復元モデルを使用したソリューションに、3 台のサーバーからなるビルディング ブロックが提供されます。

  このモデルは、以下のシナリオで使用できます。

  • 障害ドメイン (ラック、ブレード エンクロージャ、ストレージ アレイなど) でプライマリ データセンターのデータベース コピーを簡単に分離する必要のあるアクティブ/パッシブ複数サイト構成

  • 増加の予測に基づいて論理的スケール単位の簡単な追加を保証するアクティブ/パッシブ複数サイト構成

  • DAG の任意の 2 台のメールボックス サーバーが同時に失われた場合に引き続き使用する必要のない構成

  このモデルでは、単一サイトの展開ではペアで、複数サイトの展開では 3 つのセットでサーバーを展開する必要があります。以下の表は、このモデルのデータベース レイアウトの例です。

  すべてのコピーをアクティブにする設計

  上の表の内容は以下のとおりです。

  • C1 = 通常の運用時のアクティブ コピー (アクティブ化優先順位値 1)

  • C2 = 通常の運用時のパッシブ コピー (アクティブ化優先順位値 2)

  • C3 = サイト障害時のパッシブ コピー (アクティブ化優先順位値 3)

• 対象とする障害シナリオ用の設計   このモデルでは、メールボックス サーバーの役割は、サーバー上のデータベース コピーのサブセットをアクティブにできるように設計されます。サブセット内のデータベース コピーの数は、設計の対象とする特定の障害シナリオに応じて変化します。この設計の主な目的は、アクティブなデータベースの負荷を、DAG 内で引き続き稼働しているメールボックス サーバー全体に均等に分散することです。

  このモデルは、通常、以下のシナリオで使用します。

  • 3 つ以上のデータベース コピーを保持するすべての単一サイトの構成

  • DAG の任意の 2 台のメールボックス サーバーが同時に失われた場合に引き続き使用する必要のある構成

  このモデルの DAG 設計では、3 ～ 16 台のメールボックス サーバーが必要です。以下の表は、このモデルのデータベース レイアウトの例です。

  対象とする障害シナリオ用の設計

  上の表の内容は以下のとおりです。

  • C1 = 通常の運用時のアクティブ コピー (アクティブ化優先順位値 1)

  • C2 = 通常の運用時のパッシブ コピー (アクティブ化優先順位値 2)

  • C3 = 通常の運用時のパッシブ コピー (アクティブ化優先順位値 3)

* 設計上の決定点 *

前の手順では、複数の DAG を使用するアクティブ/アクティブ データベース分散モデルを展開することを決定しました。このモデルの各 DAG は、プライマリ データセンターに高可用性データベース コピーを 2 つのみ保持するアクティブ/パッシブ構成であるため、すべてのコピーをアクティブにする設計のメールボックス サーバーの復元戦略が最も適しています。

手順 8:データベース可用性グループの数を決定する

DAG は、Exchange 2010 に組み込まれている、高可用性およびサイト復元のフレームワークの基本コンポーネントです。DAG は最大 16 台のメールボックス サーバーからなるグループで、一連のレプリケートされたデータベースをホストし、個々のサーバーまたはデータベースに影響を与える障害からデータベース レベルでの自動回復を可能にします。

DAG はメールボックス データベースのレプリケーション、データベースおよびサーバーの切り替えとフェールオーバー、および Active Manager と呼ばれる内部コンポーネントの境界です。Active Manager は、切り替えとフェールオーバーを管理する Exchange 2010 のコンポーネントです。Active Manager は、DAG のすべてのサーバー上で実行されます。

計画の観点から、展開する DAG の数を最小限に抑えることをお勧めします。以下の場合、複数の DAG の使用を考慮する必要があります。

• 16 台を超えるメールボックス サーバーを展開する場合

• 複数のサイトにアクティブなメールボックス ユーザーが存在する場合 (アクティブ/アクティブ サイト構成)

• DAG レベルの個別の管理上の境界が必要な場合

• 個別のドメインにメールボックス サーバーがある場合(DAG はドメイン境界)

* 設計上の決定点 *

前の手順で、アクティブ/アクティブ データベース分散モデルを展開することを決定しました。各サイトにアクティブなメールボックス ユーザーが存在する単一の DAG を展開することができました。しかし、一方のサイトの DAG メンバーと他方のサイトの DAG メンバーとの接続が一時的に切断されると、そのサイトのクラスターはクォーラムを失い、正常に動作しなくなります。そのため、3 つの DAG を展開します。各 DAG には、プライマリおよびセカンダリのデータベース コピーをホストするプライマリ データセンターのメールボックス サーバーが含まれます。各 DAG には、3 番目のデータベース コピーをホストするいずれかの代替データセンターのサーバーも含まれます。結果として、この設計は、各データセンターが 1 つの DAG のプライマリ コピーとセカンダリ コピーをホストし、さらにもう 1 つの DAG の 3 番目のコピーをホストする 3 つのアクティブ/パッシブ DAG になります。

手順 9:DAG ごとのメールボックス サーバーの数を決定する

この手順では、DAG 設計をサポートするために必要なメールボックス サーバーの最小数を決定する必要があります。この数は、作業負荷を処理するために必要なサーバーの数とは異なる可能性があるため、サーバーの数の最終決定は後の手順で行います。

* 設計上の決定点 *

前の手順で、3 つのアクティブ/パッシブ DAG を展開し、すべてのコピーをアクティブにするサーバーの復元戦略を設計することを決定しました。各 DAG は、サーバー 3 台 を 1 組 (プライマリ サイトに 2 台、代替サイトに 1 台) として展開する必要があります。3 つの DAG が展開されるため、DAG 設計をサポートするために必要なサーバーの最小数は、9 台です。作業負荷を処理するために必要なサーバーの数に応じて、ソリューションでは 9 台、18 台、または 27 台のサーバーを用意します。以下の表は、考えられる構成の概要です。

DAG ごとのメールボックス サーバーの数

DAG1 プライマリ データセンター	DAG1 セカンダリ データセンター	DAG2 プライマリ データセンター	DAG2 セカンダリ データセンター	DAG3 プライマリ データセンター	DAG3 セカンダリ データセンター	メールボックス サーバーの合計数
2	1	2	1	2	1	9
4	2	4	2	4	2	18
6	3	6	3	6	3	27

Exchange 2010 ソリューションのテスト

メールボックスのストレージ容量の要件を推定する

多くの要因が、メールボックス サーバーの役割のストレージ容量の要件に影響します。詳細については、「メールボックス データベースおよびログの容量の要因について」を参照することをお勧めします。

以下の手順では、メールボックス容量の要件を計算する方法について説明します。これらの要件を使用して、容量の要件を満たすストレージ ソリューションの選択肢を決定します。後のセクションで、選択したストレージ プラットフォームでストレージ レイアウトを適切に設定するために必要な追加の計算について説明します。

Microsoft では、この作業の大半を自動的に処理する、メールボックス サーバーの役割の要件計算用シートを作成しました。この計算ツールをダウンロードするには、「Exchange 2010 メールボックス サーバーの役割の要件計算用シート」を参照してください。計算用シートの使用方法の詳細については、「Exchange 2010 メールボックス サーバーの役割の要件計算用シート」を参照してください。

手順 1:ディスク上のメールボックス サイズを計算する

合計のストレージ要件を決定する前に、ディスク上のメールボックス サイズを知る必要があります。1 GB のクォータを持つ完全なメールボックスは、1 GB を超えるディスク領域が必要です。その理由は、送受信禁止の制限、ユーザーが 1 日あたりに送受信するメッセージの数、削除済みアイテム フォルダーの保存期間 (予定表版ログおよび単一アイテムの回復を有効または無効にした状態)、およびメールボックスごとのデータベースの平均的な 1 日単位の変動を考慮する必要があるためです。メールボックス サーバーの役割の要件計算用シートでは、これらの計算が自動的に行われます。また、以下の情報を使用して手動で計算を行うこともできます。

以下の計算を使用して、このソリューションで 2 GB のメールボックスの制限があるメールボックスのディスク上のメールボックス サイズを決定します。

• スペース = 1 日あたり 100 メッセージ × 75 ÷ 1024 MB = 7.3 MB

• 削除済みアイテム収集機能 = (1 日あたり 100 メッセージ × 75 ÷ 1024 MB × 14 日) + (2048 MB × 0.012) + (2048 MB × 0.058) = 246 MB

• ディスク上のメールボックス サイズ = メールボックスの上限 + スペース + 削除済みアイテム収集機能

  = 2048 + 7.3 + 246

  = 2,301 MB

手順 2:データベース ストレージ容量の要件を計算する

この手順では、すべてのメールボックス データベースに必要な高レベルのストレージ容量を決定します。計算される容量には、データベース サイズ、カタログ インデックス サイズ、および 20% の空き領域が含まれます。

すべてのデータベースに必要なストレージ容量を決定するには、以下の計算式を使用します。

• データベース サイズ = (メールボックス数 × ディスク上のメールボックス サイズ × データベース オーバーヘッド増加係数) + (20% データ オーバーヘッド)

  = (32400 × 2301 × 1) + (14910480)

  = 89,462,880 MB

  = 87,366 GB

• データベース インデックス サイズ = データベース サイズの 10%

  = 87366 × 0.10

  = 8,737 GB

• 合計データベース容量 = (データベース サイズ) + (インデックス サイズ) ÷ 0.80 (20% のボリューム空き領域を追加)

  = (87366 + 8737) ÷ 0.8

  = 120,128 GB

手順 3:トランザクション ログ ストレージ容量の要件を計算する

領域割り当ての問題が原因でメールボックス サーバーのダウンタイムが生じることがないようにするには、トランザクション ログのサイズも、バックアップ セット中に生成されるすべてのログを記録できるように設定する必要があります。このアーキテクチャがバックアップ アーキテクチャとしてメールボックスの復元機能と単一アイテムの回復機能を活用しているとして、コピーの失敗が 3 日間修復されない場合、1 日のログ生成量の 3 倍をログの容量として割り当てる必要があります(コピーが失敗すると、ログの切り捨てが行われません)。サーバーが 3 日以内にオンラインに復帰しない場合、一時的にコピーを削除し、切り捨ての発生を許可する必要がある場合があります。

すべてのトランザクション ログに必要なストレージ容量を決定するには、以下の計算式を使用します。

• ログ ファイル サイズ = (ログ ファイル サイズ × 1 日あたりのメールボックスごとのログの数 × 障害インフラストラクチャの交換に要する日数 × メールボックス ユーザーの数) + (1% のメールボックス移動オーバーヘッド)

  = (1 MB × 20 × 4 × 32400) + (32400 × 0.01 × 2048 MB)

  = 3,255,552 MB

  = 3,179 GB

• 合計ログ容量 = ログ ファイル サイズ ÷ 0.80 (20% のボリューム空き領域を追加)

  = (3179) ÷ 0.80

  = 3974

手順 4:合計ストレージ容量の要件を決定する

以下の表に、このソリューションにおける高レベルのストレージ容量の要件を示します。後の手順で、この情報を使用して、展開するストレージ ソリューションを決定します。後の手順では、特定のストレージの要件についてより詳しく確認します。

ストレージ容量の要件の概要

ディスク領域の要件	値
ディスク上のメールボックスの平均サイズ (MB)	2301
必要なデータベース容量 (GB)	120128
必要なログ容量 (GB)	3974
必要な合計容量 (GB)	124102
3 つのデータベース コピーに必要な合計容量 (GB)	372306
3 つのデータベース コピーに必要な合計容量 (TB)	364
各サイトに必要な合計容量 (TB)	122

Exchange 2010 ソリューションのテスト

メールボックス I/O の要件を推定する

Exchange 環境を設計する場合、データベースおよびログのパフォーマンス要因を理解する必要があります。「データベースとログのパフォーマンス要因について」を参照することをお勧めします。

手順 1:合計メールボックス I/O の要件を計算する

ストレージを適切にサイズ調整するために必要な重要なトランザクション I/O メトリックスの 1 つとして、各メールボックス ユーザーによって使用される 1 秒あたりのデータベース I/O (IOPS) を理解する必要があります。ストレージのサブシステムは、シーケンシャル I/O をランダム I/O よりもずっと効率的に処理できるので、シーケンシャル I/O のみの操作は、メールボックス サーバーごとの IOPS の計算に影響しません。これらの操作には、バックグラウンドのデータベースの保守、ログのトランザクション I/O、およびログのレプリケーション I/O が含まれます。この手順では、以下の計算式を使用して、すべてのメールボックス ユーザーをサポートするために必要な合計 IOPS を計算します。

• 予測されるメールボックス ユーザーあたりの IOPS = 0.10

• 必要な合計 IOPS = メールボックス ユーザーあたりの IOPS × メールボックスの数 × I/O オーバーヘッド係数

  = 0.10 × 32400 × 1.2

  = 3888

手順 2:サイトごとの合計メールボックス I/O の要件を計算する

これは複数サイトの展開であるため、各サイトのストレージを適切にサイズ調整するために、サイトごとの IOPS の要件を考慮する必要があります。前の手順で、各サイトでは、プライマリ DAG のプライマリおよびセカンダリのデータベース コピーと、代替 DAG の 3 番目のデータベース コピーをホストすることを決定しました。このモデルでの最悪のシナリオは、プライマリ DAG の 10,800 のメールボックスと、代替 DAG の 10,800 のメールボックスが特定のサイトのストレージでアクティブである場合に発生する単一サイト障害です。次の計算を実行します。

• サイトごとに必要な合計 IOPS = メールボックス ユーザーあたりの IOPS × メールボックスの数 × I/O オーバーヘッド係数

  = 0.10 × 21600 × 1.2

  = 2592

Exchange 2010 ソリューションのテスト

ストレージの種類を決定する

Exchange 2010 では、パフォーマンス、信頼性、および高可用性の向上が図られており、組織では広範なストレージ オプションに基づいて Exchange を実行できます。

使用可能なストレージ オプションを検討する場合、パフォーマンス、容量、管理性、およびコストの各要件のバランスをとることが、Exchange のストレージ ソリューションを効果的に実現するために不可欠です。

Exchange 2010 のストレージ ソリューションの選択の詳細については、「メールボックス サーバーの記憶域設計」を参照してください。

Exchange 2010 ソリューションのテスト

DAS または SAN ストレージ ソリューションを選択する

Exchange 2010 では、広範なストレージ オプションを使用できます。オプション選択のリストは、DAS (Direct-Attached Storage) ソリューション (ローカル ディスクの使用を含む) または SAN ソリューションのどちらを展開するかを決定することで、絞り込むことができます。どちらを選択するにしても多くの選択基準があるため、希望のストレージ ベンダーと協力して、独自のビジネス要件と総保有コスト (TCO) 要件を満たすソリューションを決定する必要があります。

* 設計上の決定点 *

この例では、SAN インフラストラクチャを展開し、環境内のすべてのデータを格納するために SAN を使用します。SAN ストレージ ソリューションを継続的に使用して、Exchange 2010 を展開するオプションを検討します。

Exchange 2010 ソリューションのテスト

ストレージ ソリューションを選択する

以下の手順を使用してストレージ ソリューションを選択します。

手順 1:適したストレージ ベンダーを特定する

この例では、EMC のストレージを長年使用しており、EMC のストレージ ソリューションを Exchange 2010 の展開に使用します。EMC Corporation は、CLARiiON や Symmetric などの高性能なストレージ アレイを提供しています。

手順 2:適するベンダーで使用できるオプションを確認する

EMC CLARiiON ファミリでは、エンタープライズ フラッシュ ドライブ、ファイバー チャネル、Serial ATA (SATA) などの複数層のストレージを提供しています。複数の層を単一の管理インターフェイスで管理できるため、コストが削減されます。

CLARiiON Virtual Provisioning には、ストレージ管理の簡略化や容量使用率の改善など、従来のシン プロビジョニングより優れた機能があります。ホストに大規模な容量を提供し、必要に応じて共有プールの領域を使用できます。

CLARiiON CX4 Series には、容量、機能性、およびパフォーマンスのさまざまなレベルに対応した 4 つのモデルがあります。以下の表は、各モデルの機能を表しています。

CLARiiON CX4 Series の機能

機能	CX4 モデル 120	CX4 モデル 240	CX4 モデル 480	CX4 モデル 960
最大ディスク数	120	240	480	960
ストレージ プロセッサ	2	2	2	2
ストレージ プロセッサあたりの物理メモリ	3 GB	4 GB	8 GB	16 GB
最大書き込みキャッシュ	600 MB	1.264 GB	4.5 GB	10.764 GB
システムあたりの最大イニシエーター	256	512	512	1024
高可用性ホスト	128	256	256	512
最小フォーム ファクター サイズ	6U	6U	6U	9U
最大標準 LUN	1024	1024	4096	4096
SnapView スナップショット	○	○	○	○
SnapView クローン	○	○	○	○
SAN コピー	○	○	○	○
MirrorView/S	○	○	○	○
MirrorView/A	○	○	○	○
RecoverPoint/S	○	○	○	○
RecoverPoint/A	○	○	○	○

手順 3:ディスクの種類を選択する

この例では、450 GB のファイバー チャネル ディスク (15,000 RPM) を選択します。これらのディスクが提供する良好な I/O パフォーマンスおよび容量によって、Exchange の初期のユーザー要件が満たされます。

手順 4:アレイを選択する

この例では、122 TB の使用可能なストレージを提供して 2,592 IOPS を実現する必要があります。上記の表のどのオプションでも IOPS の要件に対応できるため、決定は容量の要件に基づきます。CLARiiON CX4 モデル 240 では、RAID 5 構成の 450 GB のディスクによって約 100 TB の容量しか使用できません。EMC CLARiiON CX4 モデル 480 は、必要な容量と I/O パフォーマンスを提供して Exchange 2010 のすべての要件を満たすため、このモデルを選択します。

Exchange 2010 ソリューションのテスト

メールボックスのメモリ要件を推定する

メモリを適切にサイズ調整することは、良好な Exchange 環境を設計するための重要な手順です。「メモリの構成と Exchange のパフォーマンスについて」および「メールボックス データベース キャッシュについて」を参照することをお勧めします。

Exchange 2010 ソリューションのテスト

必要なデータベース キャッシュを計算する

ESE (Extensible Storage Engine ) は、データベース キャッシュを使用することで入出力 (I/O) 操作を減らします。一般的に、利用可能なデータベース キャッシュの容量が多いほど、Exchange 2010 メールボックス サーバーで生成される I/O は少なくなります。ただし、データベース キャッシュを追加しても、それ以上 IOPS が大きく減少しなくなるポイントがあります。したがって、必要なデータベース キャッシュの最適な容量を決定せずに Exchange サーバーに物理メモリを大量に追加すると、コストのわりにパフォーマンス上の利点をほとんど得ることができない結果となる可能性があります。

前の手順で完了した IOPS の推定によって、メールボックスあたりのデータベース キャッシュの最小容量を推測できます。これらの最小容量は、「メールボックス データベース キャッシュについて」の表「メッセージ アクティビティおよびメールボックス データベースのキャッシュに基づいた、メールボックスあたりの IOPS の予測値」に要約されています。

以下の表は、さまざまなメッセージ プロファイルに対応するユーザーあたりのデータベース キャッシュです。

ユーザーあたりのデータベース キャッシュ

メールボックスごとの 1 日あたりの送受信メッセージ (平均メッセージ サイズは約 75 KB)	ユーザーあたりのデータベース キャッシュ (MB)
50	3 MB
100	6 MB
150	9 MB
200	12 MB

この手順では、環境全体の高レベルのメモリ要件を決定します。後の手順で、この結果を使用して、メールボックス サーバーごとに必要な物理メモリの容量を決定します。次の計算を実行します。

• データベース キャッシュ = プロファイル固有のデータベース キャッシュ × メールボックス ユーザーの数

  = 6 MB × 32400

  = 194,400 MB

  = 190 GB

Exchange 2010 ソリューションのテスト

メールボックスの CPU 要件を推定する

メールボックス サーバーの容量の計画は、Exchange 2010 のメールボックス データベース復元モデルが新しくなったため、以前のバージョンの Exchange から大幅に変更されました。詳細については、「メールボックス サーバーのプロセッサ容量計画」を参照してください。

以下の手順では、アクティブ データベース コピーとパッシブ データベース コピーの高レベルなメガサイクル要件を計算します。これらの要件を後の手順で使用して、作業負荷の処理に必要なメールボックス サーバーの数を決定します。必要なメールボックス サーバーの数は、メールボックス サーバーの復元モデルとデータベース コピー レイアウトに応じて変化します。

メガサイクル要件を使用して Exchange メールボックス サーバーでサポートできるメールボックス ユーザーの数を決定することは、厳密な方法ではありません。テスト環境や運用環境では、複数の要因が予期しないメガサイクルの結果につながることがあります。メガサイクルは、Exchange メールボックス サーバーでサポートできるメールボックス ユーザーの概数を見積もる場合にのみ使用する必要があります。設計プロセスの容量計画の段階では、常に過大にならないように控えめに見積もることをお勧めします。

以下の計算は、次の表に要約されている公開済みのメガサイクルの推定に基づいています。

メガサイクルの推定

1 日にメールボックスあたりで送受信されるメッセージ	アクティブ メールボックス データベースのメールボックスあたりのメガサイクル	リモート パッシブ メールボックス データベースのメールボックスあたりのメガサイクル	ローカル パッシブ メールボックスのメールボックスあたりのメガサイクル
50	1	0.1	0.15
100	2	0.2	0.3
150	3	0.3	0.45
200	4	0.4	0.6

手順 1:アクティブ メールボックスの CPU 要件を計算する

この手順では、以下の計算式を使用して、アクティブ データベース コピーをサポートするために必要なメガサイクルを計算します。

• 必要なアクティブ メールボックスのメガサイクル = プロファイル固有のメガサイクル × メールボックス ユーザーの数

  = 2 × 32400

  = 64800

手順 2:アクティブ メールボックスのリモート データベース コピーの CPU 要件を計算する

各データベースの 3 つのコピーが含まれる設計では、リモート サーバーでデータベース コピーを維持するために必要な配布ログに関連するプロセッサ オーバーヘッドがあります。このオーバーヘッドは、通常、サービス対象の各リモート コピーのアクティブ メールボックス メガサイクルの 10% です。以下の計算式を使用して要件を計算します。

• 必要なリモート コピーのメガサイクル = プロファイル固有のメガサイクル × メールボックス ユーザーの数 × リモート コピーの数

  = 0.1 × 32400 × 2

  = 6480

手順 3:ローカル パッシブ メールボックスの CPU 要件を計算する

各データベースの 3 つのコピーが含まれる設計では、各データベースのローカル パッシブ コピーの維持に関連するプロセッサ オーバーヘッドがあります。この手順では、ローカル パッシブ データベース コピーをサポートするために必要な高レベルのメガサイクルを計算します。これらの数値は、サーバーの復元戦略とデータベース コピー レイアウトに一致するように、後の手順で調整します。以下の計算式を使用して要件を計算します。

• 必要なローカル パッシブ メールボックスのメガサイクル = プロファイル固有のメガサイクル × メールボックス ユーザーの数 × パッシブ コピーの数

  = 0.3 × 32400 × 2

  = 19440

手順 4:合計 CPU 要件を計算する

以下の計算式を使用して合計要件を計算します。

• 必要な合計メガサイクル = アクティブ メールボックス + リモート パッシブ + ローカル パッシブ

  = 64800 + 6480 + 19440

  = 90720

  メールボックスあたりの平均メガサイクル = 90720 ÷ 32400 = 2.8

Exchange 2010 ソリューションのテスト

メールボックスの要件をまとめる

以下の表は、この環境で必要なメガサイクルの概算とデータベース キャッシュの要約です。この情報は、ソリューションに展開するサーバーを決定するために後の手順で使用します。

メールボックスの要件のまとめ

メールボックスの CPU 要件	値
環境全体に必要な合計メガサイクル	97200
環境全体に必要な合計データベース キャッシュ	190 GB

Exchange 2010 ソリューションのテスト

サーバー モデルを決定する

以下の手順を使用して、サーバー モデルを決定します。

手順 1:適したサーバー ベンダーを特定する

このソリューションの場合、適したサーバー プラットフォームは Cisco Unified Computing System です。これは、単一のシステムにコンピューティング、ネットワーク、ストレージ アクセス、および仮想化を統合したデータセンター プラットフォームで、TCO を削減して柔軟性を向上するように設計されています。このシステムでは、待機時間の短い 10 ギガビットのイーサネット統合ネットワーク ファブリックと、エンタープライズ クラスの x86 アーキテクチャ サーバーが統合されています。Cisco Unified Computing System は、アーキテクチャ、テクノロジ、パートナーシップ、およびサービスに対するシステム アプローチによって、データセンター リソースを効率化し、サービス提供の規模を調整するほか、セットアップ、管理、電力、冷却、配線を必要とするデバイスの数を削減します。

手順 2:適するベンダーで使用できるオプションを確認する

Cisco Unified Computing System は、4 つの主要なシステム コンポーネントで構成されるブレード サーバー システムです。これらのシステム コンポーネントは、ファブリック相互接続、シャーシ、ファブリック エクステンダー (I/O モジュール)、およびブレード サーバーです。

このソリューションでは、以下のブレード サーバー モデルを選択できます。

オプション 1: B200 ブレード サーバー

Cisco Unified Computing System B200 ブレード サーバーは、標準の半分の幅で 2 個のソケットを備えたブレード サーバーです。このシステムでは、2 個の Intel Xeon 5500 または 5600 シリーズ プロセッサ、最大 96 GB の DDR3 メモリ、ホットスワップ可能な 2 台の小型 SAS ディスク ドライブ (オプション)、および最大で 1 秒あたり 20 ギガビット (Gbps) の I/O スループットに対応する単一のメザニン コネクタを使用します。このサーバーは、運用レベルの仮想化および他の主要な作業負荷に関して、簡易性、パフォーマンス、および密度のバランスに優れています。

オプション 2: B250 ブレード サーバー

Cisco Unified Computing System B250 拡張メモリ ブレード サーバーは、標準幅で 2 個のソケットを備えたブレード サーバーで、Cisco 拡張メモリ テクノロジを搭載しています。このシステムでは、2 個の Intel Xeon 5500 または 5600 シリーズ プロセッサ、最大 384 GB の DDR3 メモリ、2 台の小型 SAS ディスク ドライブ (オプション)、および最大で 40 Gbps の I/O スループットに対応する 2 つのメザニン接続をサポートします。このサーバーは、仮想化および大規模なデータセット ワークロード向けに、パフォーマンスと容量が向上しています。

オプション 3: B440 ブレード サーバー

Cisco Unified Computing System B440 ブレード サーバーは、大規模なデータセットおよびトランザクション集中型のデータベース、エンタープライズ リソース プランニング (ERP) プログラム、意思決定支援システム (DSS) などのエンタープライズ アプリケーションを支援するように設計されています。Cisco Unified Computing System B440 は、Intel Xeon 7500 シリーズ プロセッサのスケーラブルなパフォーマンスと信頼性の機能に基づいて、ワークロード仮想化の範囲を拡張し、統合された単純なインフラストラクチャ内にパフォーマンス集中型のスタンドアロン アプリケーションを集約します。Cisco Unified Computing System B440 では、最大 32 の処理コアと 256 GB のメイン メモリがサポートされ、最大 40 Gbps の統合 I/O スループットが実現します。

手順 3:サーバー モデルを選択する

Intel Xeon X5570 プロセッサを搭載した Cisco Unified Computing System B200 を選択します。その理由は、このブレード サーバーが、この展開に関して処理能力、メモリ容量、およびフォーム ファクターのバランスの点で最も適しているためです。Exchange 2010 の展開においては、スケーラビリティやコストなどのすべての関連要素を考慮すると、通常、2 ソケットのサーバー プラットフォームが適しています。Cisco Unified Computing System B250 では、メモリ構成と I/O スループットをさらに向上できますが、このソリューションではその必要はありません。

Exchange 2010 ソリューションのテスト

サーバー モデルの CPU 処理能力を計算する

前の手順で、アクティブなメールボックス ユーザーの数をサポートするために必要なメガサイクルを計算しました。以下の手順では、各サーバーでサポートできるアクティブなメールボックスの数を決定するため、サーバー モデルとプロセッサでサポートできる利用可能なメガサイクル数を決定します。

手順 1:サーバーおよびプロセッサのベンチマーク値を確認する

メガサイクル要件は、ベースラインのサーバーとプロセッサ モデルに基づくため、ベースラインを基準としてサーバーの利用可能なメガサイクルを調整する必要があります。これを行うには、SPEC (Standard Performance Evaluation Corporation) が管理する独立したパフォーマンス ベンチマークを使用します。SPEC は、最新世代の高性能コンピューターに適用できる標準化された関連ベンチマークのセットを確立、維持、および保証するために設立された非営利法人です。

サーバーとプロセッサのベンチマーク値を取得するプロセスを簡略化するため、Exchange Processor Query ツールを使用することをお勧めします。このツールによって、使用する予定のプロセッサの SPECint 2006 処理速度値を確認する手動の手順が自動化されます。このツールを実行するには、コンピューターをインターネットに接続する必要があります。このツールは、予定のプロセッサ モデルを入力として使用し、Standard Performance Evaluation Corporation の Web サイトに対してクエリを実行して、その特定のプロセッサ モデルのすべてのテスト結果データを Web サイトから入手します。また、このツールは、各メールボックス サーバーで使用する予定のプロセッサの数に基づいて SPECint 2006 の平均処理速度値を計算します。次の計算を実行します。

• プロセッサ = Intel X5570 2.93 GHz

• SPECint_rate2006 値 = 256

• プロセッサ コアあたりの SPECint_rate2006 値 = 256 ÷ 8

  = 32

手順 2:調整メガサイクルを計算する

前の手順で、メールボックスごとのメガサイクルの推定に基づいて環境全体に必要なメガサイクルを計算しました。この推定は、SPECint_rate2006 の値が 150 (8 コア サーバー、つまりコアあたり 18.75) であるベースライン システム (HP DL380 G5 x5470 3.33 GHz、8 コア) に基づいて測定されました。

この手順では、選択したサーバーとプロセッサで利用可能なメガサイクルをベースライン プロセッサに対して調整し、容量計画において必要なメガサイクルを使用できるようにする必要があります。

Cisco B200-M1 Intel X5570 2.93 GHz プラットフォームのメガサイクルを決定するには、以下の計算式を使用します。

• コアあたりの調整メガサイクル = (コアあたりの新しいプラットフォームの値) × (ベースライン プラットフォームのコアあたりの Hz) ÷ (コアあたりのベースラインの値)

  = (32 × 3330) ÷ 18.75

  = 5683

• サーバーあたりの調整メガサイクル = コアあたりの調整メガサイクル × コアの数

  = 5683 × 8

  = 45466

手順 3:メールボックス サーバーあたりの利用可能なメガサイクルを計算する

サーバーあたりの調整メガサイクルが判明したため、目標の最大プロセッサ使用率に合わせて調整する必要があります。前の手順で、最大負荷時または障害シナリオにおいてプロセッサ使用率が 80% を超えないようにすることを決定しました。次の計算を実行します。

• 利用可能な調整メガサイクル = サーバーあたりの利用可能なメガサイクル × 目標の最大プロセッサ使用率

  = 45466 × 0.80

  = 36372

各サーバーには、36,372 メガサイクルの使用可能な容量があります。

Exchange 2010 ソリューションのテスト

必要な物理的メールボックス サーバーの数を決定する

以下の手順を使用して、必要な物理的メールボックス サーバーの数を決定します。

手順 1:単一のメールボックス サーバーでサポートされるアクティブなメールボックスの最大数を決定する

メールボックス サーバーでサポートされるアクティブなメールボックスの数を決定するには、次の計算を実行します。

• アクティブなメールボックスの数 = サーバーあたりの利用可能なメガサイクル ÷ メールボックスあたりのメガサイクル

  = 36372 ÷ 2.8

  = 12990

手順 2:各 DAG に要求される負荷の処理に必要なサイトごとのメールボックス サーバーの最小数を決定する

各 DAG には、10,800 のアクティブなメールボックスがあります。DAG のすべてのメールボックスをサポートするために必要なメールボックス サーバーの最小数を決定するには、次の計算を実行します。

• 必要なサーバーの数 = DAG あたりのメールボックスの合計数 ÷ サーバーあたりのアクティブなメールボックス

  = 10800 ÷ 12990

  = 0.83

10,800 のメールボックスのワークロードを処理するためには、各 DAG に最低 1 台のメールボックス サーバーが必要です。

手順 3:各 DAG のメールボックスの復元戦略をサポートするために必要なサーバーの数を決定する

前の手順で、アクティブ/パッシブ DAG ですべてのコピーをアクティブにする設計を使用することを決定しました。このモデルでは、DAG ごとに 3 台 1 組のセットでメールボックス サーバーの役割を展開する必要があります。

メールボックス サーバーおよび DAG の数

DAG1 プライマリ データセンター	DAG1 セカンダリ データセンター	DAG2 プライマリ データセンター	DAG2 セカンダリ データセンター	DAG3 プライマリ データセンター	DAG3 セカンダリ データセンター	メールボックス サーバーの合計数
2	1	2	1	2	1	9
4	2	4	2	4	2	18
6	3	6	3	6	3	27

DAG 設計に従って、各 DAG に最低 3 台の物理的メールボックス サーバー、つまり 3 つのすべての DAG で合計 9 台の物理的メールボックス サーバーが必要です。

Exchange 2010 ソリューションのテスト

通常の運用シナリオと障害シナリオにおけるメールボックス サーバーあたりのアクティブなメールボックスの数を決定する

以下の手順を使用して、通常の運用シナリオと障害シナリオにおけるメールボックス サーバーあたりのアクティブなメールボックスの数を決定します。

手順 1:通常の運用時におけるメールボックス サーバーあたりのアクティブなメールボックスの数を決定する

通常の運用時に各メールボックス サーバーでホストされるアクティブなメールボックスの数を決定するには、次の計算を実行します。

• サーバーあたりのメールボックスの数 = DAG のメールボックスの合計数 ÷ プライマリ データセンターのメールボックス サーバーの数

  = 10800 ÷ 2

  = 5400

手順 2:プライマリ データセンターのメールボックス サーバーの障害時におけるメールボックス サーバーあたりのアクティブなメールボックスの数を決定する

プライマリ データセンターの 1 つのメールボックス サーバーに障害が発生すると、障害サーバー上の 5,400 のアクティブなメールボックスが、引き続き稼働しているサーバー上でアクティブになります。このシナリオでは、稼働を続けるメールボックス サーバーに 10,800 のアクティブなメールボックスが割り当てられます。

手順 3:プライマリ データセンターの両方のメールボックス サーバーの障害時におけるメールボックス サーバーあたりのアクティブなメールボックスの数を決定する

プライマリ データセンターがオフラインになると、プライマリ データセンターの 10,800 のアクティブなメールボックスは、セカンダリ データセンターでアクティブになります。このシナリオでは、セカンダリ データセンターの単一のサーバーに 10,800 のアクティブなメールボックスが割り当てられます。

Exchange 2010 ソリューションのテスト

クライアント アクセス サーバーの役割とハブ トランスポート サーバーの役割を個別の物理サーバーに展開するかどうかを決定する

サーバーの台数が少ない環境に展開するクライアント アクセス サーバーの役割とハブ トランスポート サーバーの役割の数を決定する場合、両方の役割を同じ物理マシンに展開することを検討してもよいでしょう。この方法を使用すると、管理する物理マシンの数、更新および維持するサーバー オペレーティング システムの数、および購入する必要のある Windows と Exchange のライセンスの数を削減できます。クライアント サクセス サーバーの役割とハブ トランスポート サーバーの役割を組み合わせることによるもう一つの利点は、設計プロセスの単純化です。役割を単独で展開する場合、メールボックス サーバーの 4 つの論理プロセッサごとにハブ トランスポート サーバーの 1 つの論理プロセッサを展開し、メールボックスの 4 つの論理プロセッサごとにクライアント アクセス サーバーの 3 つの論理プロセッサを展開することをお勧めします。この方法は、特に物理サーバーの複数の障害シナリオまたは保守シナリオにおいて十分なクライアント アクセス サーバーおよびハブ トランスポート サーバーを提供する必要がある場合、作業が複雑になる可能性があります。クライアント アクセス サーバー、ハブ トランスポート サーバー、およびメールボックス サーバーを類似した物理サーバーまたは類似した VM に展開する場合、サイト内のメールボックス サーバーごとにクライアント アクセス サーバーおよびハブ トランスポート サーバーの組み合わせ 1 組を展開できます。

* 設計上の決定点 *

このソリューションでは、ハブ トランスポート サーバーの役割とクライアント アクセス サーバーの役割をまとめて同じ物理マシンに配置することを決定しました。これによって、管理するオペレーティング システムの数を削減すると同時に、サーバーの復元を簡単に計画できるようになります。

Exchange 2010 ソリューションのテスト

必要なクライアント アクセスおよびハブ トランスポートの物理的組み合わせサーバーの数を決定する

前の手順で、各サイトに 3 台のメールボックス サーバーが必要であることを確認しました (そのサイトのアクティブなメールボックスをホストする DAG の 2 台のメールボックス サーバーと、その DAG のプライマリ データセンターの障害時にサイトの復元をサポートする代替 DAG の 1 台のメールボックス サーバー)。

以下の表のように、メールボックス サーバーごとに、クライアント アクセス サーバーおよびハブ トランスポート サーバーの組み合わせ 1 組を展開することをお勧めします。

必要なクライアント アクセスおよびハブ トランスポートの物理的組み合わせサーバーの数

サーバーの役割の構成	推奨されるプロセッサ コアの比率
メールボックス: クライアント アクセス サーバーとハブ トランスポート サーバーの役割の組み合わせ	1:1

同じサイトに複数の DAG が存在する場合、必要なクライアント アクセスおよびハブ トランスポートの組み合わせサーバーの数を決定する前に、最悪の障害シナリオについて調査する必要があります。このソリューションでの最悪の障害シナリオは、プライマリ DAG の 2 台のメールボックス サーバーのいずれかが失われ、別のサイトのアクティブなメールボックスが同じサイトでホストされている場合に同時にサイト障害が発生する場合です。この場合、サイトでは 21,600 のアクティブなメールボックスが 2 台のメールボックス サーバーで実行されるため、以下の図のように、各サイトに最低 2 つのクライアント アクセス サーバーとハブ トランスポート サーバー の組み合わせが必要です。

クライアント アクセス サーバーとハブ トランスポート サーバー

Exchange 2010 ソリューションのテスト

必要な物理サーバーの合計数を決定する

これまでの手順で、以下の図に示すように、3 つのデータセンターで 32,400 のアクティブなメールボックスに対応するクライアント アクセス、ハブ トランスポート、およびメールボックスのサーバーの役割をサポートするために、15 台の物理サーバーが必要であることを確認しました。

必要な物理サーバーの数

Exchange 2010 ソリューションのテスト

サーバー仮想化を使用するかどうかを決定する

Exchange でサーバー仮想化を検討する場合、いくつかの重要な要素があります。仮想化でサポートされる構成の詳細については、「Exchange 2010 のシステム要件」を参照してください。

以下の理由がある場合、Exchange で仮想化の使用を検討してください。

• サーバーの能力の使用率が低いことが予想され、より効率的な使用を望む場合、仮想化によって購入するサーバーの数を少なくできる可能性がある。

• 同じ物理サーバーにクライアント アクセス、ハブ トランスポート、およびメールボックスのサーバーの役割を展開する場合、Windows ネットワーク負荷分散 (NLB) の使用する必要がある。

• 組織がすべてのサーバー インフラストラクチャで仮想化を使用している場合、企業の標準ポリシーに合わせるために Exchange も仮想化を使用する必要がある。

この環境で仮想化を使用する必要があるかどうかを決定するには、予測されるプロセッサ使用率を検討し、サーバーを十分に活用できない可能性が高いかどうかを判別します。

手順 1:通常の運用状態におけるメールボックス サーバーの予想 CPU 使用率を決定する

単一のメールボックス サーバーにおける 5,400 のアクティブなメールボックスの CPU 使用率を決定するには、次の計算を実行します。

• プロセッサ使用率 (通常の運用のピーク時) = 必要なメガサイクル ÷ 利用可能なメガサイクル

  = (5400 × 2.8) ÷ 45466

  = 33.2%

手順 2:最悪の障害状態におけるメールボックス サーバーの予想 CPU 使用率を計算する

単一のメールボックス サーバーにおける 10,800 のアクティブなメールボックスの CPU 使用率を決定するには、次の計算を実行します。

• プロセッサ使用率 (障害状態のピーク時) = 必要なメガサイクル ÷ 利用可能なメガサイクル

  = (10800 × 2.8) ÷ 45466

  = 66.5%

* 設計上の決定点 *

サーバーの使用率は、最悪の障害シナリオの場合でも目標の 80% を下回ると予測されるため、仮想化を使用してサーバー数を削減する余地があります。これについて、以下の手順で詳細に検討します。

Exchange 2010 ソリューションのテスト

仮想化を使用して物理サーバーの数を削減できるかどうかを確認する

以下の手順では、仮想化を使用してこのソリューションで必要な物理サーバーの数を削減できるかどうかを確認します。仮想化プラットフォームとして Microsoft Hyper-V を使用します。

手順 1:既存の物理サーバー数に仮想化を追加する

このテストの時点では、Microsoft Hyper-V は、VM あたり最大 4 個の仮想プロセッサをサポートしています。物理的な設計では、プライマリ DAG のメールボックス サーバーの役割は、合計 16 個の論理プロセッサを搭載した 2 台の物理サーバー全体に展開されました。仮想化を追加することで、プライマリ DAG のメールボックス サーバーの役割は、4 つの VM に展開されます。各 VM は、それぞれ 4 個の仮想プロセッサを備えており、合計 16 個の仮想プロセッサが使用されます。

物理的な設計では、代替 DAG のメールボックス サーバーの役割は、8 個の論理プロセッサを搭載した 1 台の物理サーバーに展開されました。仮想化を追加することで、代替 DAG のメールボックス サーバーの役割は、2 つの VM に展開されます。各 VM は、それぞれ 4 個の仮想プロセッサを備えており、合計 8 個の仮想プロセッサが使用されます。

物理的な設計では、クライアント アクセス サーバーとハブ トランスポート サーバーの組み合わせは、合計 16 個の論理プロセッサを搭載した 2 台の物理サーバーに展開されました。仮想化を追加することで、クライアント アクセス サーバーとハブ トランスポート サーバーの組み合わせは、4 つの VM に展開されます。各 VM は、それぞれ 4 個の仮想プロセッサを備えており、合計 16 個の仮想プロセッサが使用されます。

8 個の論理プロセッサを搭載した Hyper-V ルート サーバーを使用する場合、各 Hyper-V ルート サーバーに 1 つのメールボックス サーバー VM と 1 つのクライアント アクセスおよびハブ トランスポートの組み合わせサーバー VM を展開するのがベスト プラクティスです。

これで、このソリューションでは以下の図のように、各サイトの 5 台の物理サーバー上で 10 台の VM が稼働することになります。

仮想マシン

手順 2:物理サーバー数を削減する

前の手順の計算から、最悪の場合の負荷のメガサイクル要件は、4 台の物理サーバーで処理できると予測されます。この手順では、物理サーバー数を 5 台から 4 台に削減し、代替 DAG のメールボックス サーバーを残りの 4 台の物理サーバーに再分散します。4 台の物理サーバー全体で対称性を維持するには、2 つのメールボックス サーバー VM (4 個の仮想プロセッサを搭載) を 4 つのメールボックス サーバー VM (2 個の仮想プロセッサを搭載) に変更する必要があります。

これで、以下の図に示すように、各サイトの 4 台の物理サーバー上で 12 の VM が稼働することになります。

仮想マシン

仮想マシン

手順 3:各 VM に割り当てる仮想プロセッサの数を決定する

この手順では、各 VM に必要な仮想プロセッサの数を推定します。以下の手順では、計算によってその前提条件を検証します。

プライマリ DAG の 4 つのメールボックス サーバー VM は、それぞれ通常の運用状態において DAG の 10,800 のアクティブなメールボックスの 25% (それぞれ 2,700 のメールボックス) をサポートします。サーバー障害の発生時には、残りのメールボックス サーバー VM で 5,400 のアクティブなメールボックスをサポートする必要があります。

サイト障害の発生時には、プライマリ DAG の 4 つのメールボックス サーバー VM は、それぞれが DAG の 10,800 のアクティブなメールボックスの 25% (2,700 のメールボックス) をサポートします。このシナリオでは、メールボックスは、データベースの 3 番目および最後のコピー上で実行されます。サーバー障害または VM 障害の発生時には、残りの VM が 5,400 のアクティブなメールボックスをサポートする必要はありません。メールボックスの最大数は、常に 2,700 になります。

代替 DAG の VM の仮想プロセッサの数をプライマリ DAG の VM の数の半分にするのが合理的です。このソリューションでは、プライマリ DAG の VM に 4 個の仮想プロセッサを割り当てて、代替 DAG の VM に 2 個の仮想プロセッサを割り当てます。

論理プロセッサと仮想プロセッサの比率を 1:1 に維持する場合、クライアント アクセスおよびハブ トランスポートの各組み合わせサーバーに対して 2 個の仮想プロセッサが残ります。メールボックス サーバーのコアとクライアント アクセスおよびハブ トランスポートの組み合わせサーバーのコアの比率を 1:1 に維持しようとすると、クライアント アクセスおよびハブ トランスポートの各組み合わせサーバーに 4 個の仮想プロセッサを割り当てることになるからです。この結果、仮想プロセッサの数がルート サーバーの物理プロセッサの数を超えるシナリオになります。これは、オーバーサブスクリプションと呼ばれます。ほとんどの環境では、オーバーサブスクリプションを使用しないことをお勧めします。しかし、このソリューションでは、代替 DAG のメールボックス サーバー VM が使用されるのは、サイト障害の発生時だけです。このイベントの発生率は低いため、わずかなオーバーサブスクリプションは問題ありません。

以下の表に、推奨される仮想プロセッサの割り当てを示します。

仮想プロセッサの割り当て

仮想マシン	仮想プロセッサ数
クライアント アクセスおよびハブ トランスポートの組み合わせ	3
メールボックス (プライマリ DAG)	4
メールボックス (代替 DAG)	2
合計	9

Exchange 2010 ソリューションのテスト

Hyper-V ルート サーバーの CPU 処理能力を計算する

前の手順で、アクティブなメールボックス ユーザーの数をサポートするために必要なメガサイクルを計算しました。以下の手順では、各仮想サーバーでサポートできるアクティブなメールボックスの数を決定するため、サーバー モデルとプロセッサでサポートできる利用可能なメガサイクル数を決定します。

Exchange 2010 ソリューションのテスト

仮想化のオーバーヘッドを考慮して利用可能なメガサイクルを調整する

ルート サーバーに VM を展開する場合、ハイパーバイザーおよび仮想化スタックをサポートするために必要なメガサイクルを検討する必要があります。このオーバーヘッドは、サーバーによって異なり、さまざまなワークロードに応じて変化します。以下の計算に示すように、利用可能なメガサイクルの 10% という控えめな見積もりを使用します。

• 利用可能な調整メガサイクル = 利用可能なメガサイクル × 0.90

  = 45466 × 0.90

  = 40919

各サーバーの VM には、40,919 メガサイクルの使用可能な処理能力があります。

論理プロセッサあたりの使用可能な処理能力は、5,115 メガサイクルです。

Exchange 2010 ソリューションのテスト

VM の CPU 処理能力を決定する

前の手順で、以下の表のように、3 種類の VM に対する仮想プロセッサの割り当てを決定しました。

仮想プロセッサの割り当て

仮想マシン	仮想プロセッサ数
クライアント アクセスおよびハブ トランスポートの組み合わせ	3
メールボックス (プライマリ DAG)	4
メールボックス (代替 DAG)	2
合計	9

手順 1:仮想プロセッサあたりの利用可能なメガサイクルを決定する

8 個の論理プロセッサを持つルート サーバー上で 9 個の仮想プロセッサが実行されるため、仮想プロセッサのメガサイクル容量は、論理プロセッサのメガサイクル容量と一致しません。この手順では、仮想プロセッサあたりの利用可能なメガサイクルを計算します。

• 仮想プロセッサあたりのメガサイクル = 論理プロセッサあたりのメガサイクル × (論理プロセッサの数 ÷ 仮想プロセッサの数)

  = 5115 × (8 ÷ 9)

  = 4547

手順 2:VM あたりの利用可能なメガサイクルを決定する

この手順で VM あたりの利用可能なメガサイクルを決定するには、以下の表を参照してください。

VM あたりの利用可能なメガサイクル

仮想マシン	仮想プロセッサ数	仮想プロセッサあたりのメガサイクル	利用可能なメガサイクル
クライアント アクセスおよびハブ トランスポートの組み合わせ	3	4547	13641
メールボックス (プライマリ DAG)	4	4547	18188
メールボックス (代替 DAG)	2	4547	9094

手順 3:VM ごとに利用可能なメガサイクルの目標値を決定する

プロセッサの使用率が 80 % を超えないということを設計の前提としているため、次の表のように、利用可能なメガサイクルを調整して、80 % の目標を反映します。

VM ごとの利用可能なメガサイクルの目標値

仮想マシン	利用可能なメガサイクル	プロセッサの最大使用率	利用可能なメガサイクルの目標値
クライアント アクセスおよびハブ トランスポートの組み合わせ	13641	80%	10913
メールボックス (プライマリ DAG)	18188	80%	14550
メールボックス (代替 DAG)	9094	80%	7275

Exchange 2010 ソリューションのテスト

プライマリ メールボックス サーバー VM の CPU 処理能力を確認する

プライマリ メールボックス サーバー VM の CPU 処理能力を確認するには、次の手順を実行します。

手順 1:最大の負荷がかかる状態でのメガサイクル要件を決定する

プライマリ メールボックス サーバーに最大の負荷がかかる状態は、サーバーの障害時または保守の実施時に、5,400 個のメールボックスがプライマリ メールボックス サーバー上でアクティブになっており、2 番目と 3 番目のリモート コピーが保持されている場合です (たとえば、パッシブ コピーの更新中であるが、アクティブ メールボックスがターゲット サーバーに戻っていない回復イベントの後)。この手順では、次の計算を実行してプライマリ メールボックス サーバー VM のメガサイクル要件を決定します。

• 必要なメールボックス メガサイクル = (メールボックス ユーザー数 x プロファイル固有のメガサイクル) + リモート データベース コピー数 x (メールボックス ユーザー数 x プロファイル固有のメガサイクル x 10%)

  = (5400 × 2) + 2 × (5400 × 2 × 0.1)

  = 10800 + 2160

  = 12960

手順 2:プライマリ メールボックス サーバー VM が最大の負荷がかかる状態をサポートできるかどうかを確認する

この手順では、利用可能なメガサイクルが必要なメガサイクルを上回るかどうかを確認します。必要なメガサイクルが 12,960 であるのに対し、利用可能なメガサイクルは 14,550 なので、プライマリ メールボックス サーバー VM には 5,400 個のアクティブなメールボックスをサポートするだけの十分な能力があります。

Exchange 2010 ソリューションのテスト

セカンダリ メールボックス サーバー VM の CPU 処理能力を確認する

セカンダリ メールボックス サーバー VM の CPU 処理能力を確認するには、次の手順を実行します。

手順 1:最大の負荷がかかる状態でのメガサイクル要件を決定する

セカンダリ メールボックス サーバーに最大の負荷がかかる状態は、サイトの障害時に、2,700 個のメールボックスはプライマリ メールボックス サーバー上でアクティブになっており、2 番目と 3 番目のリモート コピーが保持されてる場合です (たとえば、元のプライマリ コピーとセカンダリ コピーが更新中で、元のサイトがオンラインに復帰しようとしているが、アクティブ メールボックスが元のサイトに戻っていない)。この手順では、セカンダリ メールボックス サーバー VM のメガサイクル要件を決定するために次の計算を実行します。

• 必要なメールボックス メガサイクル = (メールボックス ユーザー数 x プロファイル固有のメガサイクル) + リモート データベース コピー数 x (メールボックス ユーザー数 x プロファイル固有のメガサイクル x 10%)

  = (2700 × 2) + 2 × (2700 × 2 × 0.1)

  = 5400 + 1080

  = 6480

手順 2:プライマリ メールボックス サーバー VM が最大の負荷がかかる状態をサポートできるかどうかを確認する

この手順では、利用可能なメガサイクルが必要なメガサイクルを上回るかどうかを確認します。必要なメガサイクルが 6,480 であるのに対し、利用可能なメガサイクルは 7,275 なので、セカンダリ メールボックス サーバー VM には 2,700 個のアクティブなメールボックスをサポートするだけの十分な能力があります。

Exchange 2010 ソリューションのテスト

プライマリ メールボックス サーバー VM ごとに必要なメモリを決定する

プライマリ メールボックス サーバー VM ごとに必要なメモリを決定するには、次の手順を実行します。

手順 1:障害発生時の最悪のシナリオに対応するサーバーごとのデータベース キャッシュ要件を決定する

前の手順で、すべてのメールボックスのデータベース キャッシュ要件を 190 GB にし、アクティブなメールボックスごとに必要な平均キャッシュを 6 MB にすることを決定しました。

障害発生時の最悪のシナリオに対応できるように設計するには、障害が発生していないメールボックス サーバー VM 上の 5,400 個のアクティブなメールボックスに基づいて必要なデータベース キャッシュを計算します。

• データベース キャッシュに必要なメモリ = アクティブなメールボックス数 x メールボックスごとの平均キャッシュ

  = 5400 × 6 MB

  = 32,400 MB

  = 31.6 GB

手順 2:障害発生時の最悪のシナリオに対応するメールボックス サーバーごとの合計メモリ要件を決定する

この手順では、次の表を参考にして推奨メモリ構成を決定します。

メモリ要件

サーバーの物理メモリ (RAM)	データベース キャッシュ サイズ (メールボックス サーバーの役割のみ)
24 GB	17.6 GB
32 GB	24.4 GB
48 GB	39.2 GB

メールボックス サーバーの役割用の 31.6 GB のデータベース キャッシュをサポートする推奨メモリ構成は 48 GB になります。

Exchange 2010 ソリューションのテスト

セカンダリ メールボックス サーバー VM ごとに必要なメモリを決定する

セカンダリ メールボックス サーバー VM ごとに必要なメモリを決定するには、次の手順を実行します。

手順 1:障害発生時の最悪のシナリオに対応するサーバーごとのデータベース キャッシュ要件を決定する

前の手順で、すべてのメールボックスのデータベース キャッシュ要件を 190 GB にし、アクティブなメールボックスごとに必要な平均キャッシュを 6 MB にすることを決定しました。

障害発生時の最悪のシナリオに対応できるように設計するために、セカンダリ メールボックス サーバー VM 上の 2,700 個のアクティブなメールボックスに基づいて必要なデータベース キャッシュを計算します。

• データベース キャッシュに必要なメモリ = アクティブなメールボックス数 x メールボックスごとの平均キャッシュ

  = 2700 × 6 MB

  = 16,200 MB

  = 15.8 GB

手順 2:障害発生時の最悪のシナリオに対応するメールボックス サーバーごとの合計メモリ要件を決定する

この手順では、次の表を参考にして推奨メモリ構成を決定します。

メモリ要件

サーバーの物理メモリ (RAM)	データベース キャッシュ サイズ (メールボックス サーバーの役割のみ)	データベース キャッシュ サイズ (メールボックス サーバーの役割とハブ トランスポート サーバー役割などの複数のサーバー役割。)
24 GB	17.6 GB	14 GB
32 GB	24.4 GB	20 GB
48 GB	39.2 GB	32 GB

メールボックス サーバーの役割用の 15.8 GB のデータベース キャッシュをサポートする推奨メモリ構成は 24 GB になります。

Exchange 2010 ソリューションのテスト

クライアント アクセス サーバーとハブ トランスポート サーバーの組み合わせごとに必要なメモリを決定する

クライアント アクセスとハブ トランスポートの組み合わせサーバー VM のメモリ構成を決定する際は、次の表を参考してください。

インストールしたサーバーの役割に基づいた Exchange 2010 サーバーのメモリ構成

Exchange 2010 サーバーの役割	サポートされる最小値	推奨される最大値
クライアント アクセス サーバーとハブ トランスポート サーバーの役割の組み合わせ (同じ物理サーバー上で実行しているクライアント アクセスとハブ トランスポートのサーバーの役割)	4 GB	1 コアあたり 2 GB (最小 8 GB)

クライアント アクセスとハブ トランスポートの組み合わせサーバー VM には 3 つの仮想プロセッサがあるので、各クライアント アクセスとハブ トランスポートの組み合わせサーバーの VM には 6 GB のメモリが割り当てられます。

Exchange 2010 ソリューションのテスト

Hyper-V ルート サーバーごとに必要なメモリを決定する

Hyper-V ルート サーバーごとに必要なメモリを決定するには、次の計算を実行します。

• ルート サーバー メモリ = ルート オペレーティング システム メモリ + クライアント アクセスとハブ トランスポートの組み合わせサーバーの VM メモリ + プライマリ メールボックス サーバー VM メモリ + セカンダリ メールボックス サーバー VM メモリ

  = 4 GB + 6 GB + 48 GB + 24 GB

  = 82 GB

ルート サーバーの物理メモリ要件は 82 GB になります。推奨物理メモリ構成に合わせるため、ルート サーバーは 96 GB に事前設定されます。

Exchange 2010 ソリューションのテスト

データベース可用性グループを設計する

前の手順で、このソリューションに 3 つの DAG を設定し、各 DAG が 3 か所の物理的な場所のうちの 2 か所にまたがるようにすることを決定しました。負荷に対応し、DAG 要件を満たすために必要なメールボックス サーバーの数を決定したので、DAG の設計を進めることができます。

DAG 設計

Exchange 2010 ソリューションのテスト

データベース コピーのレイアウト設計

データベース コピーのレイアウトを設計するには、次の手順を実行します。

手順 1:DAG 内の一意の Exchange データベースの数を決定する

展開する最適な Exchange データベースの数を決定するには、Exchange Server 2010 メールボックス サーバーの役割の要件計算用シートを使用します。[Input (入力)] タブに適切な情報を入力し、[Automatically Calculate Number of Databases / DAG (データベース/DAG 数を自動計算する)] で [Yes (はい)] を選択します。メールボックスのサイズ制限フィールドには、2,048 MB のフル プロビジョニングされたメールボックス クォータを使用します。

DAG 内の Exchange データベース

[Role Requirements (役割の要件)] タブにはデータベースの推奨数が表示されます。このソリューションの場合、この計算シートでは、各 DAG には最低でも 24 の一意のデータベースを配置することが推奨されます。

* 設計上の決定点 *

この計算シートでの推奨に従い、DAG ごとに 24 のデータベースを展開します。

手順 2:通常の運用状態でのデータベース レイアウトを決定する

DAG ごとに 24 個の一意のデータベースを配置し、DAG 内に 8 台のサーバーを配置するので、プライマリ サイト内の各 4 台のサーバーは通常の運用状態で 6 つのアクティブなデータベース コピーをホストすることになります。

次の表のように、まず、アクティブなデータベース コピーを 4 台のサーバーに追加します。

通常の運用状態でのデータベース レイアウト

データベース	MBX1	MBX2	MBX3	MBX4
DB1-6	A1
DB7-12		A1
DB13-18			A1
DB19-24				A1

上の表の内容は以下のとおりです。

• A1 = アクティブなデータベース コピー

前の手順で、運用効率の向上のためメールボックス サーバーの回復性戦略を設計することを決定しました。メールボックス サーバーをペアで展開します。

DAG 内にメールボックス サーバー 4 台を配置するので、サーバー 1 と 2 がペアとなり、サーバー 3 と 4 がペアとなります。この手順では、次の表のように各ペアの代替サーバーにパッシブなデータベース コピー (P1) を追加します。

パッシブなコピーを追加した通常の運用状態でのデータベース レイアウト

データベース	MBX1	MBX2	MBX3	MBX4
DB1-6	A1	P1
DB7-12	P1	A1
DB13-18			A1	P1
DB19-24			P1	A1

上の表の内容は以下のとおりです。

• A1 = アクティブなデータベース コピー

• P1 = パッシブなデータベース コピー

手順 3:サイト内のサーバーの障害発生時または保守時のデータベース レイアウトを決定する

サーバーの障害発生時または保守イベント時には、P1 コピーが代替サーバー上でアクティブになります。次の表は、保守のために MBX2 と MBX4 を停止させたときの状態を表しています。

サイト内のサーバーの障害発生時または保守時のデータベース コピー レイアウト

上の表の内容は以下のとおりです。

• A1 = アクティブなデータベース コピー

• P1 = パッシブなデータベース コピー

手順 4:サイトの復元性をサポートするためにセカンダリ データセンターにデータベース コピーを追加する

この手順では、次の表のように、セカンダリ データセンター内の DAG メンバーに 3 番目のデータベース コピーを追加し、サイトの復元を可能にします。

サイトの復元をサポートするためにセカンダリ データセンターに追加されたデータベース コピー

データベース	SiteA MBX1	SiteA MBX2	SiteA MBX3	SiteA MBX4	SiteB MBX5	SiteB MBX6	SiteB MBX7	SiteB MBX8
DB1-6	A1	P1			P2
DB7-12	P1	A1				P2
DB13-18			A1	P1			P2
DB19-24			P1	A1				P2

上の表の内容は以下のとおりです。

• A1 = アクティブなデータベース コピー

• P1 = ローカルのパッシブなデータベース コピー

• P2 = リモートのパッシブなデータベース コピー

手順 5:サイトの障害発生時のデータベース レイアウトを決定する

プライマリ データセンターの障害発生時には、次の表のように、P2 コピーがセカンダリ サイトでアクティブになります。プライマリ サイトがオンラインに復帰するまで、データベースのコピーは 1 つしかないことに注意してください。

サイトの障害発生時のデータベース レイアウト

上の表の内容は以下のとおりです。

• A1 = アクティブなデータベース コピー

• P1 = パッシブなデータベース コピー

• P2 = パッシブなデータベース コピー

Exchange 2010 ソリューションのテスト

データセンターのアクティブ化調整モード

データセンターのアクティブ化調整 (DAC) モードは、DAG に影響を与える致命的な障害 (例: いずれかのデータセンターの全面的な障害) が発生したときに DAG のアクティブ化動作を制御するために使用します。DAC モードを有効にしていないときに DAG 内の複数サーバーに影響を与える障害が発生した場合、障害発生後に DAG メンバーの過半数を復元する際 DAG は再開してデータベースのマウントを試みます。データセンターが複数ある構成では、この動作はスプリット ブレイン シンドロームを起こす可能性があります。これは、すべてのネットワークが機能せず、DAG メンバーが相互にハートビート信号を受信できなくなる状況です。スプリット ブレイン シンドロームは、ネットワーク接続がデータセンター間で切断された場合にも発生します。スプリットブレイン シンドロームは、DAG メンバーの過半数 (および偶数のメンバーを持つ DAG の場合は、DAG ミラーリング監視サーバー) が使用可能で、相互に通信でき、DAG の運用が可能な状態を維持することで防止できます。詳細については、「データセンターのアクティブ化調整モードについて」を参照してください。

* 設計上の決定点 *

スプリット ブレイン シンドロームの発生を防止するために環境内の 3 つすべての DAG に対して DAC モードを有効にします。

Exchange 2010 ソリューションのテスト

ファイル共有監視機能の配置を決定する

Exchange 2010 では、DAG は Windows フェールオーバー クラスタリングから最小限のコンポーネント セットを使用します。このようなコンポーネントの 1 つがクォーラム リソースです。クォーラム リソースはクラスターの状態を決定し、メンバーシップを決定する際の調停のための手段を提供します。各 DAG メンバーが、クラスターの基盤となる DAG の構成について一貫性のある情報を持っていることが重要です。クォーラムは、クラスターに関連するすべての構成情報の最終リポジトリとして動作します。また、クォーラムは、スプリット ブレイン シンドロームを回避するためのタイブレーカーとして使用されます。スプリット ブレイン シンドロームは、DAG メンバーが相互に通信できないが、利用可能な状態で稼動しているときに発生する状態です。スプリット ブレイン シンドロームは、DAG メンバーの過半数 (および偶数のメンバーを持つ DAG の場合は、DAG ミラーリング監視サーバー) が使用可能で、相互に通信でき、DAG の運用が可能な状態を維持することで防止できます。

ミラーリング監視サーバーは、ファイル共有監視をホストする DAG の外部にあるサーバーで、DAG のメンバーの数が偶数の場合に、クォーラムの達成および保持に使用されます。DAG のメンバーの数が奇数の場合は、ミラーリング監視サーバーを使用しません。DAGの作成時、ファイル共有監視は、DAG の最初のメンバーと同じサイト内の (メールボックス サーバーの役割がインストールされていない) ハブ トランスポート サーバー に既定で追加されます。メールボックス サーバーの役割を実行している VM と同じルート サーバーにある VM でハブ トランスポート サーバーが実行されている場合は、ファイル共有監視の場所を別の高可用性サーバーに移動することをお勧めします。ファイル共有監視は、ドメイン コントローラーに移動できますが、セキュリティに影響するため、やむを得ない場合をのぞき避けてください。

DAG が複数のサイトにまたがるソリューションでは、セカンダリ サイト用に代替のファイル共有監視を定義することをお勧めします。これにより、DAC モードを有効にすると、サイトに障害が発生してもクラスターがクォーラムを維持できるようになります。

* 設計上の決定点 *

3 つの DAG を展開することを決定したため、すべての DAG に複数のサイトのメンバーが含まれるようになるので、それぞれ 3 つのプライマリ監視ディレクトリと代替監視ディレクトリを定義する必要があります。これらのディレクトリは各サイト内のファイル サーバー上に配置されます。

Exchange 2010 ソリューションのテスト

名前空間を計画する

Exchange 2010 組織を計画するときの最も重要な決定事項の 1 つは、組織の外部名前空間の構成方法です。名前空間は、通常ドメイン ネーム システム (DNS) 内のドメイン名で表現される論理的な構造です。名前空間を定義するときには、さまざまな場所のクライアントとそのメールボックスを格納するサーバーについて考慮する必要があります。クライアントの物理的な場所のほかに、クライアントによる Exchange 2010 への接続方法も評価する必要があります。これらの条件の内容に基づいて必要な名前空間の数を決定します。通常、名前空間は DNS 構成と整合します。インターネットに直接接続する 1 台以上のクライアント アクセス サーバーがある地域の各 Active Directory サイトに、固有の名前空間を設定することをお勧めします。これは通常、mail.contoso.com や mail.europe.contoso.com などの A レコードによって DNS 内で表現されます。

詳細については、「クライアント アクセス サーバーの名前空間について」を参照してください。

外部名前空間を構成するにはさまざまな方法がありますが、通常、以下の名前空間モデルのいずれかを使用することで要件を満たすことができます。

• 統合データセンター モデル   このモデルは 1 つの物理サイトで構成されます。すべてのサーバーが 1 つの物理サイト内に配置され、mail.contoso.com などの 1 つの名前空間が設定されます。

• プロキシ サイトを持つ単一の名前空間   このモデルは、複数の物理サイトで構成されます。1 つのサイトにのみ、インターネットに直接接続するクライアント アクセス サーバーが含まれます。他のサイトはインターネットに公開されません。このモデル内のサイトには、mail.contoso.com などの 1 つの名前空間のみが設定されます。

• 単一の名前空間と複数のサイト   このモデルは、複数の物理サイトで構成されます。各サイトには、インターネットに直接接続するクライアント アクセス サーバーを含めることができます。また、インターネットに直接接続するクライアント アクセス サーバーを含む単一のサイトのみとなる場合もあります。このモデル内のサイトには、mail.contoso.com などの 1 つの名前空間のみが設定されます。

• 地域別の名前空間   このモデルは、複数の物理サイトと複数の名前空間で構成されます。たとえば、ニューヨークにあるサイトは mail.usa.contoso.com、トロントにあるサイトは mail.canada.contoso.com、ロンドンにあるサイトは mail.europe.contoso.com という名前空間を持ちます。

• 複数フォレスト   このモデルは、複数の名前空間を持つ複数のフォレストで構成されます。このモデルを使用する組織は、たとえば、Contoso と Fabrikam という 2 つのパートナー企業で構成されている可能性があります。名前空間には、mail.usa.contoso.com、mail.europe.contoso.com、mail.asia.fabrikam.com、および mail.europe.fabrikam.com が含まれる場合があります。

* 設計上の決定点 *

このシナリオでは、複数のサイト内にアクティブなメールボックスを持つ組織に最適であるため、地域別の名前空間モデルを選択します。

このモデルの利点は、大部分のユーザーが、メールボックス サーバーと同じ Active Directory サイト内のクライアント アクセス サーバーに接続できるためプロキシ処理が削減されるという点です。これにより、エンド ユーザーの操作性とパフォーマンスが向上します。インターネットに直接接続するクライアント アクセス サーバーを含まないサイトにメールボックスがあるユーザーは、プロキシ処理されます。

また、このソリューションには次の構成要件があります。

• 複数の DNS レコードを管理する必要があります。

• 複数の証明書を取得、構成、および管理する必要があります。

• インターネットに直接接続する各サイトに Microsoft Forefront Threat Management Gateway コンピューターまたはその他のリバース プロキシやファイアウォール ソリューションが必要になるため、セキュリティの管理がさらに複雑になります。

• ユーザーは、独自の地域名前空間に接続する必要があります。このため、ヘルプ デスクへの問い合わせや必要なトレーニングが増える場合があります。

Exchange 2010 ソリューションのテスト

クライアント アクセス サーバー アレイと負荷分散戦略を決定する

Exchange 2010 では、クライアント アクセス サーバーの役割に RPC クライアント アクセス サービスと Exchange アドレス帳サービスが導入され、アクティブなメールボックス データベース コピーが別のメールボックス サーバーに移動したとき (たとえば、メールボックス データベースの障害時や保守イベント時) のメールボックスのユーザー エクスペリエンスが向上しています。Microsoft Outlook やその他の MAPI クライアントからのメールボックス アクセスの接続エンドポイントが、メールボックス サーバーの役割からクライアント アクセス サーバーの役割へと移りました。したがって、内部および外部の Outlook 接続は両方とも、フォールト トレランスを実現するためにサイト内のすべてのクライアント アクセス サーバーにわたって負荷分散される必要があります。MAPI エンドポイントを、特定のクライアント アクセス サーバーではなくクライアント アクセス サーバーのグループと関連付けるために、クライアント アクセス サーバー アレイを定義できます。Active Directory サイトごとに 1 つの アレイしか構成できないので、アレイは複数の Active Directory サイトにまたがることはできません。詳細については、「RPC クライアント アクセスについて」および「Understanding Load Balancing in Exchange」を参照してください。

* 設計上の決定点 *

この設計では、クライアント アクセス サーバーの役割を実行する 4 台のサーバーを 3 つのサイトに展開するので、合計 3 つのクライアント アクセス サーバー アレイが存在することになります。各サイト内のクライアント アクセス サーバーアレイにわたって負荷を分散させるために、ハードウェア負荷分散ソリューションを使用します。

Exchange 2010 ソリューションのテスト

ハードウェア負荷分散モデルを決定する

ハードウェア負荷分散モデルを決定するには、次の手順を実行します。

手順 1:適したハードウェア負荷分散ベンダーを特定する

この例では、最適なベンダーとして Cisco を選択します。このソリューションでは、サーバー、ネットワーク、およびストレージ接続コンポーネントに Cisco ユニファイド コンピューティング システムを既に選択しており、Cisco Application Control Engine (ACE) 製品ラインは Cisco ユニファイド コンピューティング システムと連携して動作するためです。

Cisco ACE 製品ラインは、高可用性と拡張性を備えたデータセンター ソリューションを提供し、このソリューションは Exchange 2010 アプリケーション環境にとって有用です。Cisco ACE 製品には、相互運用性のほかに、次の利点があります。

• パフォーマンス、スケーラビリティ、スループット、およびアプリケーションの可用性

• 標準ベースの設計

• デバイスのパーティション化による仮想アーキテクチャ

• 役割ベースの管理と一元管理

• ディープ パケット インスペクションを経由するセキュリティ サービス、アクセス制御リスト (ACL)、ユニキャスト リバース パスのフォワーディング、およびネットワーク アドレス変換 (NAT)/ポート アドレス変換

手順 2:適するベンダーで使用できるオプションを確認する

Cisco ACE 製品ラインには、Exchange 2010 アプリケーション環境に適した高可用性と拡張性を備えたデータセンター ソリューションのニーズを満たす 2 つのハードウェア負荷分散モデルがあります。この 2 つのモデルは、Cisco ACE 4710 アプライアンスおよび Cisco Catalyst 6500/Cisco 7600 ルーティング プラットフォーム内の統合サービス モジュールです。

Cisco ACE 4710 アプライアンスは、1 ラック ユニット (1RU) フォーム ファクターで最大 4 Gbps スループットを実現します。また、ソフトウェア ライセンスによるアップグレードが可能であるため、長期にわたって投資の保護と拡張性を実現します。基盤となる Cisco ACE 4710 は Cavium Nitrox Octeon アクセラレータ カードを搭載した 1U ラック シャーシで、Cisco EtherChannel を使用してバンドルし、スイッチに接続できる 4 個のギガビットのイーサネット ポートを提供します。Cisco ACE 4710 は既定で、1 台の管理者デバイスと 5 台のユーザー デバイスによる仮想化、1 Gbps の帯域幅、1 秒あたり 1000 のセキュリティ ソケット レイヤー (SSL) トランザクション、 および 1 秒あたり 100 メガビット (Mbps) の圧縮をサポートします。このソリューションは、以下のソフトウェア ライセンスのアップグレードにより、新しい機器を導入することなく拡張できます。

• スループット   既定の 1 Gbps のスループットは 2 Gbps または 4 Gbps に増やすことができます。

• 仮想デバイス   仮想デバイスの数は 5 から 20 に増やすことができます。

• 1 秒あたりの SSL トランザクション   1 秒あたりの SSL トランザクションの値は 1,000 から 5,000 または 7,500 に増やすことができます。

• 圧縮   圧縮によりスループットを 500 Mbps、1 Gbps、または 2 Gbps に増やすことができます。

• 役割ベースのアクセス制御   Application Network Manager GUI またはコマンド ライン インターフェイス (CLI) を介して一元化された役割ベースの管理を提供します。

• 高可用性   冗長構成 (アプライアンス内、およびコンテキスト間) をサポートします。

Cisco Catalyst 6500 シリーズ スイッチまたは Cisco 7600 シリーズ ルーター用の Cisco ACE モジュールは、1 スロット モジュール フォーム ファクターで最大 16 Gbps スループットを実現し、ACE 4710 アプライアンスと同様、ソフトウェア ライセンスによるアップグレードが可能です。1 台の Cisco Catalyst 6500 シリーズ スイッチまたは Cisco 7600 シリーズ ルーターには、最大 4 つの Cisco ACE モジュールを設置できます。各モジュールは、複数の独立した事業単位の業務プロセスをサポートし、スイッチまたはルーターから利用できる広範な接続オプションを利用できます。システム管理者はアプリケーション要件を決定し、適切なネットワーク サービスを仮想コンテキストとして割り当てます。各コンテキストには、次のポリシー、インターフェイス、リソース、および管理者の独自のセットが含まれます。

• スループット   負荷分散サービスは、最大 16 Gbps のスループット処理能力と 1 秒あたり 345,000 件のレイヤー 4 接続を提供します。

• 仮想デバイス   仮想デバイスの数は 5 から 250 まで増やすことができます。

• 1 秒あたりの SSL トランザクション   1 秒あたりの SSL トランザクションは、ACE20 モジュール上ではライセンスによって 15,000 SSL セッションに、ACE30 モジュール上では 30,000 セッションに増やすことができます。

• 圧縮   圧縮は ACE30 モジュール上で 6 Gbps に増やすことができます。

• 役割ベースのアクセス制御   Application Network Manager GUI または CLI を介して一元化された役割ベースの管理を提供します。

• 高可用性   冗長構成 (シャーシ内、シャーシ間、およびコンテキスト間) をサポートします。

手順 3:ハードウェア負荷分散モデルを選択する

アプリケーションの可用性の最大化、包括的なアプリケーション セキュリティの提供、仮想アーキテクチャの提供、および投資の価値と保護の実現という理由から、Cisco ACE 4710 アプライアンスを選択します。

• アプリケーションの可用性の最大化   Cisco ACE 4710 は、拡張性の高いレイヤー 4 の負荷分散とレイヤー 7 のコンテンツ スイッチングによって可用性を強化することにより、ビジネス継続性とエンド ユーザーへのサービスの提供を確実にし、また、アプリケーションまたはデバイス障害の影響も最小限に抑えます。

• 包括的なアプリケーション セキュリティ   Cisco ACE 4710 は、サーバーの最終防御線として機能し、ディープ パケット インスペクション、ネットワークとプロトコル セキュリティ、および拡張性の高いアクセス制御などの機能によりアプリケーションの脅威やサービス拒否攻撃 (DoS) からサーバーを防御します。

• 仮想化アーキテクチャ   仮想化アーキテクチャは、Cisco ACE の主要な設計要素であり、市場のその他のソリューションと一線を画す Cisco ACE 製品の特長となっています。IT 管理者は、1 台の Cisco ACE 4710 アプライアンス上に最大 20 の仮想デバイスを構成できます。これには、アプリケーション展開の増大に伴う管理対象デバイス数の低減、所要電力と冷却コストの大幅な削減、および新しいアプリケーションのサービス開始までの時間短縮といった利点が挙げられます。

Exchange 2010 ソリューションのテスト

ストレージの設計を決定する

ストレージ ソリューションを適切に設計することは、Exchange 2010 メールボックス サーバーの役割を正しく展開するための重要な側面です。詳細については、「メールボックス サーバーの記憶域設計」を参照してください。

手順 1:ストレージの要件を要約する

次の表は、前の設計手順で計算または決定したストレージの要件を要約したものです。

ディスク容量の要件の概要

ディスク領域の要件	値
2 GB のメールボックス (MB) のディスク上のメールボックス サイズ	2301
必要なデータベース容量の合計 (GB)	120128
必要なログ容量の合計 (GB)	3974
必要な合計容量 (GB)	124102
3 つのデータベース コピーに必要な合計容量 (GB)	372306
3 つのデータベース コピーに必要な合計容量 (TB)	364
サイトごとに必要な容量の合計 (テラバイト)	122

手順 2:仮想またはシン プロビジョニングを使用するかどうかを決定する

顧客の多くは Exchange 2010 への移行時にメールボックスのクォータを大幅に増やすことの必要性を感じています。しかし、メールボックスのサイズが数百メガバイトから数ギガバイトに増大するまでにしばらく時間がかかることもあります。このような場合、組織によっては、ディスク ストレージの価格が低下するまで、追加のストレージの購入を延期した方が賢明かもしれません。

ストレージ ベンダーの多くは、何らかのシン プロビジョニング ソリューションを提供しており、顧客はこれを使用することにより、物理的に使用可能なストレージ容量より多くのストレージの容量を Exchange サーバーに備えることができ、その結果サービスの中断やダウンタイムが発生することなく物理的ストレージを動的に追加して増大する需要を満たすことができるようになります。シン プロビジョニング ソリューションは、ストレージの容量の初期割り当てを削減することで TCO を低減し、データの増大に対応するために必要な手順を削減することで管理を簡略化します。

EMC ユニファイド ストレージで実装しているシン プロビジョニングは、EMC の仮想プロビジョニング機能によって提供されます。この機能では、ホット スペアリング、プロアクティブ スペアリング、混乱のないシン プール拡張がサポートされており、さらにダウンタイムを発生させることなくシン LUN から従来のシック LUN に移行することも、従来のシック LUN からシン LUN に移行することも可能です。 このような柔軟性が、EMC ユニファイド ストレージの仮想プロビジョニングの実装と一般的シン プロビジョニングの実装との大きな違いになります。

* 設計上の決定点 *

現在の Exchange の実装では、既に 200 MB のメールボックス クォータが定義されています。Exchange 2010 への移行後、メールボックスのサイズは最初の 12 か月から 18 か月の間に約 300 % 増大することが予測されます。計画として、平均 600 MB のメールボックスを収容するのに十分な容量を備えたストレージを購入します。Exchange 2010 の実装期間にわたり、平均メールボックス サイズはほぼ 2 GB になるものと予想されます。2 GB のメールボックス クォータに要する費用は高額となるため、シン プロビジョニングを実装し、初期メールボックス クォータとして 600 MB を展開可能にします。基盤となる物理的ストレージは、その後の予算サイクルの中で拡張し、予想される重要に対応します。

手順 3:ログとデータベースを同一の LUN 上に共存させるかどうかを決定する

Exchange 2010 の展開で、EMC ユニファイド ストレージ上にシン プロビジョニングを使用する場合、ベスト プラクティスとしてログ ファイルとデータベース ファイルを分離することをお勧めします。メールボックスのサイズは増大するが、メッセージ プロファイル (1 日に送受信されるメッセージ) のサイズは増大しないことが予測される場合は、データベース LUN を徐々に増やす必要がありますが、ログ LUN は増やす必要はありません。シン プロビジョニングされた LUN 上にログを保存することは有益ではありません。

また、データベース LUN とログ LUN を分離することにより柔軟性が得られ、これらの LUN をそれぞれ異なるディスク タイプ上に配置したり、異なるレベルの RAID を使用したりできるようになります。

* 設計上の決定点 *

EMC のベスト プラクティスに従って、データベースとログを別々の LUN に分離します。メッセージ プロファイルは、今後 3 年間にわたってほぼ一定した状態であることが予測されるため、ログをシン プロビジョニングされた LUN 上に置くことは何のメリットもありません。

手順 4:LUN ごとのデータベースの数を決定する

VSS ベースのバックアップと復元は LUN レベルで処理されるので、LUN ごとのデータベースの数は、バックアップ戦略によって通常決定されます。前の手順で、データベースの復元性戦略の一環として VSS ベースのバックップを含めないことを決定しました。LUN ごとのデータベースの数は、他の要因に基づいて決定します。ベスト プラクティスとして、通常は LUN ごとに単一のデータベースを展開することをお勧めします。LUN ごとに複数のデータベースを設定すると、以下の状態が発生する場合があります。

• 正常なデータベースに影響を及ぼすデータベースの過負荷

• 正常なデータベースに影響を及ぼす 1 つのデータベースに対するシード操作

• アクティブなデータベースに影響を及ぼすパッシブなデータベースの入出力処理

* 設計上の決定点 *

LUN ごとに複数のデータベースを展開するための要件が存在しないため、ストレージの設計は LUN モデルごとに単一のデータベースに基づいて行います。

手順 5:プライマリ データセンターのメールボックス サーバー用にサーバーごとの LUN 数を決定する

前の手順で、各プライマリ メールボックス サーバーは、6 つのアクティブなデータベースと 6 つのパッシブなデータベースをサポートすることを確認しました。次の表のように、各プライマリ データセンターのメールボックス サーバー用に合計 24 の LUN が存在することになります。

メールボックス サーバーごとに必要な LUN 数

LUN の種類	サーバーごとの LUN
アクティブなデータベースの LUN	6
アクティブなログ LUN	6
パッシブなデータベースの LUN	6
パッシブなログ LUN	6
LUN の合計数	24

手順 6:セカンダリ データセンターのメールボックス サーバー用にサーバーごとの LUN 数を決定する

前の手順で、各セカンダリ メールボックス サーバーは 6 つのパッシブなデータベースをサポートすることを確認しました。次の表のように、各セカンダリ データセンターのメールボックス サーバー用に合計 12 の LUN が存在することになります。

メールボックス サーバーごとに必要な LUN 数

LUN の種類	サーバーごとの LUN
パッシブなデータベースの LUN	6
パッシブなログ LUN	6
LUN の合計数	12

手順 7:ストレージのビルディング ブロックを定義する

ストレージの残りの設計手順を簡略化するために、ビルディング ブロックという考え方を採用します。このソリューションでは、各データベースは 450 個の アクティブなメールボックスをサポートします。各メールボックス サーバーは、 6 つのデータベース LUN と 6 つのログ LUN 上に 6 つのデータベース、つまり 2,700 個のアクティブなメールボックスをサポートします。12 の LUN で 2,700 個のメールボックスを 1 単位としてサポートするビルディング ブロックを使用します。

手順 8:ビルディング ブロックの IOPS 要件を決定する

この手順では、ビルディング ブロック内の 2,700 のアクティブなメールボックス ユーザーをサポートするために必要なトランザクション IOPS を計算します。その後の手順で、IOPS 要件を使用して、初期およびフル プロビジョニングされたメールボックス クォータに基づいて、ビルディング ブロックに対して展開するスピンドルの最大数および最小数を決定します。次の計算を実行します。

• ビルディング ブロックに必要なトランザクション IOPS の合計 = メールボックス ユーザーごとの IOPS x メールボックス数 x I/O オーバーヘッド係数

  = 0.10 × 2700 × 20%

  = 324 IOPS

手順 9:ディスク上の初期メールボックス サイズを決定する

前の手順で、2,048 MB のメールボックス クォータ制限に対するディスク上のメールボックス サイズを 2,301 MB と計算しました。シン プロビジョニングを使用するため、ディスク上の初期メールボックス サイズを計算します。この値は、初期容量要件を決定するために後続する手順で使用します。

次の計算を実行し、600 MB のメールボックス クォータに基づいて、このソリューションに対するディスク上の初期メールボックスを決定します。

• スペース = 1 日あたり 100 メッセージ × 75 ÷ 1024 MB = 7.3 MB

• 削除済みアイテム収集機能 = (1 日あたり 100 メッセージ x 75 ÷ 1024 MB x 14 日) + (600 MB x 0.012) + (600 MB x 0.058) = 144.2 MB

• ディスク上のメールボックス サイズ = メールボックスの上限 + スペース + 削除済みアイテム収集機能

  = 600 MB + 7.3 MB + 144.2 MB

  = 752 MB

手順 10:ビルディング ブロックのデータベース容量の初期要件を決定する

次の計算を実行し、初期メールボックス クォータが 600 MB である 2,700 個のメールボックスに必要なストレージの初期要件を決定します。

• データベース ファイル容量 = (メールボックス数 x ディスク上のメールボックス サイズ x データベース オーバーヘッドの増大係数) + (20% のデータ オーバーヘッド)

  = (2700 × 752 × 1) + (406080)

  = 2,436,480 MB

  = 2,379 GB

• データベース カタログ容量 = データベース ファイルの容量の 10%

  = 238 GB

• データベース容量の合計 = (データベース ファイル サイズ) + (インデックス サイズ) ÷ 0.80 (20% のボリューム空き領域を確保するため)

  = (2379 + 238) ÷ 0.8

  = 3,271 GB

ビルディング ブロック内の 6 つのデータベースには、3,271 GB の初期のストレージ容量が必要になります。

手順 11:ビルディング ブロックのフル プロビジョニングされたデータベースの容量の要件を決定する

次の計算を実行し、メールボックス クォータが 2,048 MB である 2,700 個のメールボックスに必要なフル プロビジョニングされたストレージの容量を決定します。

• データベース ファイル容量 = (メールボックス数 x ディスク上のメールボックス サイズ x データベース オーバーヘッドの増大係数) + (20% のデータ オーバーヘッド)

  = (2700 × 2301 × 1) + (1242540)

  = 7,455,240 MB

  = 7,281 GB

• データベース カタログ容量 = データベース ファイルの容量の 10%

  = 728 GB

• データベース容量の合計 = (データベース ファイル サイズ) + (インデックス サイズ) ÷ 0.80 (20% のボリューム空き領域を確保するため)

  = (7281 + 728) ÷ 0.8

  = 10,011 GB

ビルディング ブロック内の 6 つのデータベースには、10,011 GB のフル プロビジョニングされたストレージの容量が必要になります。

手順 12:ビルディング ブロックのログ容量の要件を決定する

次の計算を実行し、ビルディング ブロック内の 2,700 個のメールボックスに必要なログ ストレージの容量を決定します。

• 必要なビルディング ブロックのログ容量 = メールボックス ユーザー数 x 1 日あたりのメールボックスごとのログの数 x ログ サイズ x (障害が発生したインフラストラクチャの交換に必要な日数) + (メールボックス移動の割合オーバーヘッド)

  = (2700 × 20 × 1024 × 4) + (2700 × 0.01 × 2048)

  = 216,054 MB

  = 211 GB

• ログ容量の合計 = ログ容量 ÷ 0.80 (20 ％ のボリュームの空き領域を確保するため)

  = 211 ÷ 0.80

  = 264

ビルディング ブロック内の 6 つのログ セットには、264 GB のストレージの容量が必要になります。

手順 13:ビルディング ブロックの IOPS 要件をサポートするために必要なスピンドル数を決定する

この手順では、IOPS 要件をサポートするために必要なスピンドル数を決定します。次の手順では、容量の要件を満たすスピンドル数を決定します。

前の手順で、2,700 のメールボックスからなるビルディング ブロックをサポートするために必要な IOPS を 324 と決定しました。この手順では、次の計算を実行して、IOPS 要件を満たすために必要なディスク数を計算します。

• ディスク数 = (ユーザー IOPS x 読取り比率) + 書き込みペナルティ x (ユーザー IOPS x 書き込み比率) ÷ 選択したディスク タイプの IOPS 能力

  = (324 × 0.6) + 4 × (324 × 0.4) ÷ 155

  = 4.6

IOPS 要件は、RAID 5 構成で 5 台のディスクを備えることで満たすことができます。

手順 14:ビルディング ブロックのデータベース容量の初期要件をサポートするために必要なスピンドル数を決定する

前の手順で、600 MB の初期プロビジョニングされたメールボックスの 2,700 のメールボックス ビルディング ブロックには、3,271 GB のストレージの容量が必要であることを決定しました。CX4 モデル 480 での RAID 5 構成の 450 GB スピンドルごとに使用可能な容量は、約 402 GB になります。必要なディスクの数を決定するには、次の計算を実行します。

• ディスク数 = (必要な容量の合計) ÷ (RAID 5 構成のスピンドルごとに使用可能な容量)

  = 3271 GB ÷ 402 GB

  = 8.1

データベース容量の初期要件は 9 台のディスクで満たすことができます。

シン プロビジョニングを使用して EMC ユニファイド ストレージ上にストレージを展開する場合の EMC ベストプラクティスは、5 台のディスクの倍数で RAID 5 シン プールを構成することです。2,700 個のメールボックスからなる 1 つのビルディング ブロックに対して 10 のディスクを割り当てると、将来的な増大に対して十分対応できます。

手順 15:ビルディング ブロックのフル プロビジョニングされたデータベース容量の要件をサポートするために必要なスピンドル数を決定する

前の手順で、2,048 MB の初期プロビジョニングされたメールボックスの 2,700 のメールボックス ビルディング ブロックには、10,011 GB のストレージの容量が必要であることを決定しました。CX4 モデル 480 での RAID 5 構成の 450 GB スピンドルごとに使用可能な容量は、約 402 GB になります。必要なディスクの数を決定するには、次の計算を実行します。

• ディスク数 = (必要な容量の合計) ÷ (RAID 5 構成のスピンドルごとに使用可能な容量)

  = 10,011 GB ÷ 402 GB

  = 24.9

フル プロビジョニングされたデータベース容量の要件は 25 のディスクで満たすことができます。

手順 16:ビルディング ブロックのログ容量の要件をサポートするために必要なスピンドル数を決定する

前の手順で、2,700 のメールボックス ビルディング ブロックには、264 GB のログ ストレージ容量が必要であることを決定しました。CX4-480 で RAID 1/0 構成の 450 GBの 2 つのドライブを使用すると、402 GB の使用可能なストレージ容量が確保されます。推奨される 2 台のディスク構成によって、2,700 のメールボックス ビルディング ブロックのログ容量の要件が満たされます。

手順 17:シン プール戦略を決定する

ビルディング ブロックの IOPS と容量の要件をサポートするために必要なスピンドル数を決定しました。次に仮想プロビジョニングまたはシン プロビジョニングを使用する際に、このビルディング ブロックのアレイ上で LUN をプロビジョニングする最適な方法を決定する必要があります。

Exchange に使用するシン プールの設計に使用できる主要なモデルは、次の 3 つです。

• 単一ストレージ プール   Exchange のすべてのデータベースとログ用に大規模なストレージ プールを 1 つ備えるのが最もシンプルな方法であり、これは最も効率的なスペースの活用方法です。ただし、同一の物理アレイ上に同じデータベースのコピーを複数置く場合、単一のシン プールの使用はお勧めしません。

• サーバーごとに 1 つのストレージ プール   Exchange メール サーバーごとに 1 つのストレージ プールを備えることは、アレイ上に LUN をレイアウトする際により詳細な制御が可能になります。ストレージ プールを適切に設計すると、データベース コピーが個々のスピンドル セットから分離されることになり、シード/再シード、バックアップ、オンライン保守 (バックグラウンドのデータベース保守) などの処理中に悪影響を及ぼすことがあるディスクの競合問題を最小限に抑えることが可能になります。ただし、設置しているメールボックス サーバーの台数によっては、このモデルを使用した場合、多くのシン プールが存在することになり、管理が困難になる可能性があります。

• データベース コピーごとに 1 つのストレージ プール   データベース コピーごとに 1 つのストレージ プールを備えると、各データベース コピーが、アレイ上の異なるスピンドル セット上で分離されます。組織の多くは 2 つから 4 つのデータベース コピーを展開しているため、シン プール数が管理可能な数に維持されます。このモデルでは、複数のメールボックス サーバーは同じシン プール内にデータベース LUN を配置します。特定のメールボックス サーバー上でのシード/再シード、バックアップ、オンライン保守 (バックグラウンドのデータベース保守) などの処理が、別のメールボックス サーバー上でのパフォーマンスに影響を与える可能性があります。

* 設計上の決定点 *

サーバー モデルごとに 1 つのストレージ プールを備えることの利点を説明しましたが、これは各サイト内に 8 つのシン プールを備えることになり、合計 24 のシン プールを備えることになります。複雑化しないようにするために、データベース コピーごとに 1 つのストレージ プールを使用し、これにより各サイトに 3 つのシン プールが備えられることになり、各データベース コピーが一意のスピンドル セット上に確実に存在するようになります。また、これにより、データの増大に伴いストレージを増設しなければならない状況下でも、データベース コピーのスピンドルの分離が確実に維持されます。

手順 18:シン プールごとの初期スピンドル数を決定する

1 番目のシン プールには、サイト内の 4 つのプライマリ データセンターのメールボックス サーバーそれぞれからの 2,700 のメールボックスのビルディング ブロックが含まれます。前の手順で、このビルディング ブロックの IOPS と容量の要件をサポートするために 10 スピンドルが必要であることを決定しました。10,800 個のアクティブなメールボックスをサポートする 1 番目のシン プールには、40 のスピンドルが必要になります。

2 番目のシン プールにも、サイト内の 4 つのプライマリ データセンターのメールボックス サーバーそれぞれからの 2,700 のメールボックスのビルディング ブロックが含まれます。10,800 個のパッシブなメールボックスをサポートする 2 番目のシン プールには、40 のスピンドルが必要になります。

3 番目のシン プールにも、サイト内の 4 つのプライマリ データセンターのメールボックス サーバーそれぞれからの 2,700 のメールボックスのビルディング ブロックが含まれます。10,800 個のパッシブなメールボックスをサポートする 3 番目のシン プールには、40 のスピンドルが必要になります。

データベース容量の初期要件をサポートするには、サイトごとに合計 120 のスピンドルが必要になります。

手順 19:シン プールごとにフル プロビジョニングされたスピンドル数を決定する。

1 番目のシン プールには、サイト内の 4 つのプライマリ データセンターのメールボックス サーバーそれぞれからの 2,700 のメールボックスのビルディング ブロックが含まれます。前の手順で、この構成要素の IOPS とフル プロビジョニングされた容量の要件をサポートするために 25 のスピンドルが必要であることを決定しました。10,800 個のアクティブなメールボックスをサポートする 1 番目のシン プールには、100 のスピンドルが必要になります。

2 番目のシン プールにも、サイト内の 4 つのプライマリ データセンターのメールボックス サーバーそれぞれからの 2,700 のメールボックスのビルディング ブロックが含まれます。10,800 個のパッシブなメールボックスをサポートする 2 番目のシン プールには、100 のスピンドルが必要になります。

3 番目のシン プールにも、サイト内の 4 つのプライマリ データセンターのメールボックス サーバーそれぞれからの 2,700 のメールボックスのビルディング ブロックが含まれます。10,800 個のパッシブなメールボックスをサポートする 3 番目のシン プールには、100 のスピンドルが必要になります。

フル プロビジョニングされたデータベース容量の要件をサポートするには、サイトごとに合計 300 のスピンドルが必要になります。

手順 20:すべてのログ LUN をサポートするために必要なスピンドルの数を決定する

前の手順で、2,700 のメールボックス ビルディング ブロックそれぞれに、ログ LUN 要件をサポートするために 2 つのスピンドルが必要であることを決定しました。

プライマリ データセンターのメールボックス サーバー上にアクティブなメールボックス データベースをサポートするビルディング ブロックは 4 つあります。10,800 個のアクティブなメールボックスをサポートするログ LUN には、8 つのスピンドルが必要になります。

プライマリ データセンターのメールボックス サーバー上にパッシブなメールボックス データベースをサポートするビルディング ブロックは 4 つあります。10,800 個のパッシブなメールボックスをサポートするログ LUN には、8 つのスピンドルが必要になります。

セカンダリ データセンターのメールボックス サーバー上にパッシブなメールボックス データベースをサポートするビルディング ブロックは 4 つあります。10,800 個のパッシブなメールボックスをサポートするログ LUN には、8 つのスピンドルが必要になります。

単一のサイト内でログ LUN 要件をサポートするには、24 のスピンドルが必要になります。

手順 21:最初に必要なスピンドル数をストレージ アレイがサポートできることを確認する

この手順では、次の計算を実行して、選択したストレージ アレイによって必要な合計スピンドル数をサポートできることを確認します。

• サイトごとに必要な合計スピンドル = データベース LUN に必要なスピンドル + ログ LUN に必要なスピンドル

  = 120 + 24

  = 144

10 個のディスク アレイ エンクロージャを搭載した CX4-480 には 150 のスピンドルがあり、要件を満たしています。

手順 22:フル プロビジョニングされた環境をサポートするために必要なスピンドルの数を決定する

この手順では、次の計算を実行して、フル プロビジョニングされた環境をサポートするために必要なスピンドルの合計数を計算します。

• サイトごとに必要な合計スピンドル = データベース LUN に必要なスピンドル + ログ LUN に必要なスピンドル

  = 300 + 24

  = 324

22 個のディスク アレイ エンクロージャを搭載した CX4-480 には 330 のスピンドルがあり、要件を満たしています。

Exchange 2010 ソリューションのテスト

ソリューションの概要

ここまでは、Exchange 2010 ソリューションを検討する際の設計上の決定について説明しました。次のセクションでは、このソリューションの概要を説明します。

Exchange 2010 ソリューションのテスト

論理ソリューションの図

このソリューションは、複数サイト トポロジ内に展開される合計 36 台の Exchange 2010 サーバーで構成されます。36 台のサーバーのうちの 12 台のサーバーは、クライアント アクセス サーバーの役割とハブ トランスポート サーバーの役割の両方を実行しています。それ以外の 24 台のサーバーはメールボックス サーバーの役割を実行しています。各サイトにはクライアント アクセスとハブ トランス ポートの組み合わせサーバー 4 台を備えたクライアント アクセス サーバー アレイがあります。DAG は 3 つ存在し、それぞれに 8 台のメールボックス サーバーが含まれます。各サイト内のファイル サーバーは、各 DAG 用のプライマリおよび代替ファイル共有監視サーバーをホストします。

論理ソリューションの図

Exchange 2010 ソリューションのテスト

物理ソリューションの図

3 つのサイトのそれぞれに 4 台の Cisco B200 ブレード サーバーを設置します。これらのブレード サーバーは、冗長化された Cisco Fabric Interconnect 6120 および Cisco MDS 9134 スイッチ経由で EMC CLARiiON CX4 モデル 480 に接続します。冗長化された Cisco Nexus 5010 イーサネット スイッチは基盤となるネットワーク インフラストラクチャを提供します。クライアント トラフィックは、冗長化された Cisco ACE 4710 負荷分散デバイスを経由して各サイト内のクライアント アクセス サーバー アレイ全体にわたって負荷分散されます。

物理的なソリューションの図

Exchange 2010 ソリューションのテスト

Hyper-V ルート サーバー構成の概要

次の表は、このソリューションで使用される物理サーバーのハードウェアの概要です。

Cisco ユニファイド コンピューティング システムの概要

項目	説明
ブレード サーバー	4 × B200 M1
プロセッサ	2 × Intel Zeon x5570 (2.93 GHz)
メモリ	96 GB RAM (12 × 8 GB DIMM)
コンバージド ネットワーク アダプター	M71KR-Q (2 × 10 ギガビット イーサネットと 2 × 4 Gbps ファイバー チャネル)
内部ブレード ストレージ	2 × 146 GB SAS 10,000 RPM ディスク (RAID 1)
シャーシ	5108 (6 RU)
ファブリック エクステンダー	2 × 2104XP
ファブリックの相互接続	2 × 6120XP
ファブリックの相互接続の拡張モジュール	2 × 8 ポート 4 Gbps ファイバー チャネル

次の表は、このソリューションで使用するストレージとネットワークのハードウェアの概要です。

LAN および SAN スイッチ

項目	説明
10 ギガビット イーサネット (GbE) スイッチ	2 × Nexus 5010 (固定 1 GbE/10 GbE ポート 8 個、固定 10 GbE ポート 12 個、データセンター ブリッジング)
ファイバー チャネル スイッチ	2 × MDS 9134 (固定 4 Gbps ポート 32 個)

次の表は、このソリューションで使用するソフトウェアについての情報を記載しています。

ソリューションのソフトウエアの概要

項目	説明
ハイパーバイザーのホスト サーバー	Windows Server 2008 R2 Hyper-V Enterprise
Exchange Server VM	Windows Server 2008 R2 Enterprise
Exchange Server 2010 メールボックス サーバーの役割	Enterprise Edition RU2
Exchange Server 2010 ハブ トランスポート サーバーとクライアント アクセス サーバーの役割	Standard Edition RU2
複数のパスと I/O バランシング	EMC PowerPath

Exchange 2010 ソリューションのテスト

クライアント アクセス サーバーとハブ トランスポート サーバーの構成

次の表は、このソリューションで使用するクライアント アクセスとハブ トランスポートの組み合わせサーバー構成をまとめたものです。

クライアント アクセス サーバーとハブ トランスポート サーバーの構成

コンポーネント	値または説明
物理または仮想	Hyper-V VM
仮想プロセッサ	3
メモリ	8 GB
ストレージ	ルート サーバーのオペレーティング システム ボリューム上の仮想ハード ディスク
オペレーティング システム	Windows Server 2008 R2
Exchange のバージョン	Exchange Server 2010 Standard Edition
Exchange 更新プログラムのレベル	Exchange 2010 更新プログラムのロールアップ 2
サードパーティ製のソフトウェア	なし

Exchange 2010 ソリューションのテスト

メールボックス サーバーの構成

次の表は、このソリューションで使用するプライマリ メールボックス サーバー (DAG 用にプライマリ サイト内のプライマリとセカンダリ データベース コピーをホストする) の構成の概要です。

プライマリ メールボックス サーバーの構成

コンポーネント	値または説明
物理または仮想	Hyper-V VM
仮想プロセッサ	4
メモリ	53 GB
ストレージ	ルート サーバーのオペレーティング システム ボリューム上の仮想ハード ディスク
オペレーティング システム	Windows Server 2008 R2
Exchange のバージョン	Exchange Server 2010 Enterprise Edition
Exchange 更新プログラムのレベル	Exchange 2010 更新プログラムのロールアップ 2
サードパーティ製のソフトウェア	なし

次の表は、このソリューションで使用するセカンダリ メールボックス サーバー (DAG 用にセカンダリ サイト内の第 3 のデータベース コピーをホストする) の構成の概要です。

セカンダリ メールボックス サーバーの構成

コンポーネント	値または説明
物理または仮想	Hyper-V VM
仮想プロセッサ	2
メモリ	24 GB
ストレージ	ルート サーバーのオペレーティング システム ボリューム上の仮想ハード ディスク
オペレーティング システム	Windows Server 2008 R2
Exchange のバージョン	Exchange Server 2010 Enterprise Edition
Exchange 更新プログラムのレベル	Exchange 2010 更新プログラムのロールアップ 2
サードパーティ製のソフトウェア	なし

Exchange 2010 ソリューションのテスト

データベース レイアウト

次の図は、通常の運用状態でこのソリューションで使用するデータベース コピー レイアウトの概要です。

データベース コピー レイアウト:1

データベース コピー レイアウト:2

データベース コピー レイアウト:3

Exchange 2010 ソリューションのテスト

ストレージ ハードウェアの概要

次の表は、このソリューションで使用するストレージ ハードウェアについての情報を記載しています。

EMC ユニファイド ストレージ NS-480 (インテグレーテッド CLARiiON CX4-480)

項目	説明
ストレージ	CLARiiON CX4-480 3 台 (1 サイトごとに 1 台)
ストレージ接続 (ファイバー チャネル、SAS、SATA、iSCSI)	ファイバー チャネル
ストレージ キャッシュ	32 GB (ストレージ ポートあたり 600 MB の読み取りキャッシュと 10,160 MB の書き込みキャッシュ)
ストレージ コントローラーの数	ストレージ フレームごとに 2 台
使用可能または使用されているストレージ ポートの数	ストレージ フレームごとに使用可能なポート 8 個 (ストレージ ポートあたり 4 個)、使用されているポート 4 個 (ストレージ ポートあたり 2 個)
ホストへのストレージ接続の最大帯域幅	8 × 4 Gbps
ソリューションでテストするディスクの合計数	432 (3 つのサイト全体でデータベース用に 360、ログ用に 72)
ストレージ内でホスト可能な最大スピンドル数	単一ストレージ アレイで 480

Exchange 2010 ソリューションのテスト

ストレージの構成

ソリューションで使用する各 CX4 モデル 480 ストレージ アレイは、次の表のように構成しました。

ストレージの構成

コンポーネント	値または説明
ストレージ格納装置の合計数	3
サイトごとのストレージ格納装置の合計数	1
格納装置ごとのディスクの合計数	150
格納装置ごとのストレージ プールの合計数	3
ストレージ プール (初期）ごとのディスクの合計数	40
データベース LUN (初期) ごとのディスクの合計数	10
ログ LUN ごとのディスクの合計数	2
格納域装置ごとに使用されるディスクの合計数	144
データベース (初期) 用の LUN サイズ	4,020 GB
ログ用の LUN サイズ	402 GB
データベース用の RAID レベル	5
ログ用の RAID レベル	1/0

次の表は、使用可能なストレージを設計し、3 台の CX4 モデル 480 ストレージ システム間の割り当てる方法を示しています。

CX4 モデル 480 ストレージ システム間のストレージの構成

データセンター	DAG	データベース	アレイ 1	アレイ 2	アレイ 3
1	1	DB1-24	C1、C2		C3
2	2	DB25-48	C3	C1、C2
3	3	DB49-72		C3	C1、C2

Exchange 2010 ソリューションのテスト

ソリューションの検証方法

運用環境に Exchange ソリューションを展開する前に、ソリューションを適切に設計、サイジング、構成していることを検証してください。この検証作業では、システムが期待どおりに稼働することを保証するための機能テストと、システムが適切なユーザー負荷を処理することを保証するためのパフォーマンス テストを実施する必要があります。このセクションでは、このソリューションのためのサーバーおよびストレージ設計を検証するために使用する手法とテスト方法を説明します。特に、次のテストについて詳細に説明します。

• パフォーマンス テスト

  • ストレージのパフォーマンスの検証 (Jetstress)

  • サーバーのパフォーマンスの検証 (Loadgen)

• 機能テスト

  • データベースの切り替えの検証

  • サーバーの切り替えの検証

  • サーバーのフェールオーバーの検証

  • データセンターの切り替えの検証

Exchange 2010 ソリューションのテスト

ストレージの設計の検証方法

Exchange Mailbox サーバーの役割に接続されたストレージ サブシステムのパフォーマンスと信頼性のレベルは、Exchange 展開の全体的な状態に重大な影響を及ぼします。また、ストレージのパフォーマンスが低いとトランザクションの待ち時間が長くなり、主に Exchange システムへのアクセス時にクライアント エクスペリエンスの低下を招きます。クライアント エクスペリエンスを最適な状態にするために、このセクションで説明する方法を用いてストレージのサイズと構成を検証してください。

ツール セット

Exchange のストレージのサイズと構成を検証する場合、Microsoft Exchange Server Jetstress ツールの使用をお勧めします。Jetstress ツールは、ESE (Jet とも呼ばれる) と直接対話することで、データベース レベルでの Exchange I/O の負荷をシミュレートすることを目的としています。ESE は、メールボックス サーバーの役割にメッセージング データを格納するために Exchange が使用するデータベース テクノロジです。Jetstress は、Exchange の必要なパフォーマンス制限の範囲内で、格納域サブシステムで利用できる最大 I/O スループットをテストするように構成できます。また、Jetstress はユーザー数とユーザーあたりの IOPS の目標プロファイルを受け付け、格納域サブシステムが目標のプロファイルでの許容可能なパフォーマンス レベルを維持できることを検証できます。テスト期間は調整可能であり、最小の期間で適切なパフォーマンスを検証するために実行することも、長期にわたってストレージ サブシステムの信頼性をさらに検証するために実行することもできます。

Jetstress ツールは、Microsoft ダウンロード センターの次の場所から入手できます。

• Microsoft Exchange Server Jetstress 2010 (64 ビット)

• Microsoft Exchange Server Jetstress 2010 (32 ビット)

サーバー ハードウェア上での Jetstress 検証テストの構成および実行方法については、Jetstress インストーラーに付属するドキュメントに記載されています。

ストレージの検証へのアプローチ

ストレージの構成には、主に次の 2 つの種類があります。

• DAS または内部ディスクのシナリオ

• SAN シナリオ

DAS または内部ディスクのシナリオでは、ディスク サブシステムにアクセス可能なサーバーは 1 台のみです。したがって、格納域サブシステムのパフォーマンス機能は個別に検証してください。

SAN シナリオでは、ソリューションで使用するストレージを多くのサーバーで共有するため、サーバーをストレージに接続するインフラストラクチャは、共有された依存関係となる場合もあります。この場合、追加のテストを実施し、他のサーバーが共有インフラストラクチャに与える影響を適切にシミュレートし、パフォーマンスと機能を検証する必要があります。

ストレージの検証のためのテスト ケース

ソリューションに対して以下のストレージの検証テスト ケースを既に実施しました。ただし、これらのテスト ケースはストレージの検証の出発点と考えてください。特定の展開には他の検証要件があり、追加のテストを実施することが必要になる可能性があります。したがって以下の一覧はすべてを網羅するものではありません。

• 最悪のケースのデータベースの切り替えシナリオの検証   このテスト ケースでは、I/O レベルは、最悪のケースの切り替えシナリオ (最小のサーバー数における考えられる最大のアクティブ コピー数) にあるストレージ サブシステムによって 処理されることが予測されます。ストレージ サブシステムが DAS かまたは SAN かによって、ストレージ サブシステム上のエンド ツー エンドのソリューションの負荷を許容できることを保証するため、このテストを複数のホスト上で実行することが必要になる可能性があります。

• ストレージの障害および回復シナリオ (たとえば、障害のあるディスクの交換および再構築) でのストレージのパフォーマンスの検証   このテスト ケースでは、障害発生および再構築シナリオ中の格納域サブシステムのパフォーマンスを評価し、Exchange クライアントの最適なエクスペリエンスを実現するために必要なパフォーマンス レベルの維持を保証します。同じことが DAS 対 SAN の展開の比較についても当てはまります。共有ストレージ サブシステムに複数のホストが依存している場合、障害および再構築の全体的な影響をシミュレートするために、これらのホストからの負荷をテストに含める必要があります。

結果を分析する

各テストを完了すると、Jetstress ツールによってレポート ファイルが生成されます。レポートの分析に役立てるために、Jetstress 2010 Test Summary Reports のガイドラインを参考にしてください

特に、レポートのテスト結果テーブル内のデータを調査する場合、次の表にあるガイドラインを参考にしてください。

Jetstress の結果分析

パフォーマンス カウンターのインスタンス	パフォーマンス テストのためのガイドライン
I/O Database Reads Average Latency (msec)	平均値は、20 ミリ秒 (msec) (0.020 秒) 未満にし、最大値は 50 ミリ秒未満にする必要があります。
I/O Log Writes Average Latency (msec)	ログ ディスクの書き込みはシーケンシャルであるため、平均書き込み待ち時間は 10 ミリ秒未満にし、最大値は 50 ミリ秒を超えないようにする必要があります。
% Processor Time	平均値は 80% 未満にし、最大値は 90% 未満にする必要があります。
Transition Pages Repurposed/sec (Windows Server 2003、Windows Server 2008、Windows Server 2008 R2)	平均値は 100 未満にする必要があります。

レポート ファイルには、Exchange システムによって実行される以下の I/O のさまざまなカテゴリが示されます。

• トランザクション I/O のパフォーマンス   この表は、データベースに対するユーザーの操作を表す I/O (Outlook が生成する I/O など) をレポートします。このデータは、テスト中に測定された I/O 合計から、バックグラウンドの保守 I/O とログ レプリケーション I/O を引くことで生成されます。このデータは、生成される実際のデータベース IOPS と、Jetstress パフォーマンス テストの成否を決定するために必要な I/O 待ち時間測定値を提供します。

• バックグラウンド データベース保守 I/O パフォーマンス   この表は、実行中の ESE データベース バックグラウンド保守のために生成された I/O をレポートします。

• ログ レプリケーション I/O パフォーマンス   この表は、シミュレートされたログ レプリケーションから生成された I/O をレポートします。

• 合計 I/O パフォーマンス   この表は、Jetstress テスト中に生成された I/O 合計をレポートします。

Exchange 2010 ソリューションのテスト

サーバー設計の検証

ストレージ サブシステムのパフォーマンスと信頼性を検証した後、メッセージング システム内のすべてのコンポーネントの機能、パフォーマンス、および拡張性を必ず検証してください。これにより、クライアント ソフトウェアと Exchange 製品との対話、および Exchange と対話するすべてのサーバー側製品の検証の精度が向上します。エンド ツー エンドのクライアント エクスペリエンスを許容可能なレベルにし、またソリューション全体が適切なユーザー負荷に耐えられるようにするには、このセクションで説明した方法をサーバー設計の検証に適用します。

ツール セット

エンド ツー エンドのソリューションのパフォマンスと拡張性を検証するには、Microsoft Exchange Server Load Generator ツール (Loadgen) の使用をお勧めします。Loadgen は、Exchange 展開に対しシミュレートされたクライアント作業負荷を生成することを目的としています。この作業負荷を用いることで、 Exchange システムのパフォーマンスを評価したり、Exchange システムに負荷がかかった状態でさまざまな構成の変更がソリューション全体にどのように影響を与えるかを評価できます。Loadgen は、Microsoft Office Outlook 2007 (オンラインおよびキャッシュ)、Office Outlook 2003 (オンラインおよびキャッシュ)、POP3、IMAP4、SMTP、ActiveSync、および Outlook Web App (Exchange 2007 およびそれ以前のバージョンの Outlook Web Access) クライアントの操作をシミュレートできます。1 種類のプロトコルの作業負荷を生成するためにも使用できます。また、これらのクライアント プロトコルを組み合わせることで、複数のプロトコルの作業負荷を生成できます。

Loadgen ツールは、Microsoft ダウンロード センターの次の場所から入手できます。

• Exchange Load Generator 2010 (64 ビット)

• Exchange Load Generator 2010 (32 ビット)

Exchange 展開に対する Loadgen テストの構成および実行方法については、Loadgen インストーラーに付属するドキュメントに記載されています。

サーバーの検証へのアプローチ

サーバーの設計を検証する際は、予測されるピーク時の作業負荷のもと最悪のケースのシナリオをテストします。Microsoft IT およびその他の顧客から収集した多くのデータ セットによると、ピーク時の作業負荷は一般的に、ピーク時を除く 1 日の平均作業負荷の 2 倍になります。これを作業負荷のピーク対平均値比と呼びます。

パフォーマンス モニター

このパフォーマンス モニターのスナップショットでは、運用環境のメールボックス サーバー上で長期にわたり実施されている Exchange 作業量を表すさまざまなカウンターが表示されており、1 秒あたりの RPC 操作の平均値 (ハイライトされている線) は、1 日の全体の平均を出したときに 約 2.386 になります。午前 10 時から午前 11 時までのピーク期間のこのカウンターの平均は、約 4,971 で、このピークと平均比率は 2.08 になります。

Exchange ソリューションがピーク平均の間に生成される作業負荷に確実に耐えられるようにするには、シミュレートされた作業日全体にわたって作業負荷を分散させるのではなく、ピーク平均レベルで一定量の負荷を生成するように Loadgen の設定を変更します。Loadgen タスクベースのシミュレーション モジュールは (Outlook シミュレーション モジュールと同様)、各タスクがシミュレートされた 1 日に 1 人の平均的なユーザーに対して発生する回数を定義したタスク プロファイルを使用します。

シミュレートされた日に実行する必要があるタスクの合計数は、構成済みのタスク プロファイル内のタスク カウントの合計を、ユーザー数に掛けることで算出されます。次に、Loadgen は、シミュレートされた日に実行するタスクの合計数を、シミュレートされた日の長さで割ることで、構成済みのユーザー セットに対するタスクの実行率を決定します。たとえば、シミュレートされた日に Loadgen が 1,000,000 個のタスクを実行する必要があり、さらにシミュレートされた日が 8 時間 (28,800 秒) の場合、Loadgen は必要な作業負荷の定義を満たすために 1,000,000 ÷ 28,800 = 34.72 個/秒のタスクを実行する必要があります。目的のピーク平均まで負荷量を増やすには、既定のシミュレートされた日の長さ (8 時間) をピークと平均の比率 (2) で割り、その値を新しくシミューレートされた日の長さとして使用します。

再度タスク率の例を使用すると、1,000,000 ÷ 14,400 = 69.44 個のタスク/秒になります。これにより、シミュレートされた日の長さは半分に減り、サーバーにかかる実際の作業負荷は 2 倍になり、ピーク平均作業負荷の目的を達成したことになります。Loadgen 構成ではテストの実行の長さの期間を調整しません。実行の長さの期間にはテスト期間を指定しますが、この期間は Exchange サーバーに対してタスクを実行する際の仕事率には影響しません。

サーバー設計の検証テスト ケース

ソリューションに対して以下のサーバー設計の検証テスト ケースを既に実施しました。ただし、これらのテスト ケースはサーバー設計の検証の出発点と考えてください。特定の展開には他の検証要件があり、追加のテストを実施することが必要になる可能性があります。したがって以下の一覧はすべてを網羅するものではありません。

• 通常の運用状態   このテスト ケースでは、通常の運用状態にある (シミュレートされた障害のない) すべてのコンポーネントでのソリューションの基本設計を検証します。目的の作業負荷はソリューションに対して生成され、ソリューションのパフォーマンス全体は追跡する測定基準に対して検証されます。

• 単一のサーバー障害または単一のサーバー保守 (サイト内)   このテスト ケースでは、1 台のサーバーを停止し、サーバーの予期しない障害または計画された保守作業のいずれかをシミュレートします。通常は停止したサーバーによって処理される作業負荷は、ソリューション トポロジ内の他のサーバーによって処理され、ソリューションのパフォーマンス全体が検証されます。

テストの実行とデータの収集

Exchange パフォーマンス データは、1 つのテストの実行の中、および複数のテストの間にばらつきがあるのが普通です。このばらつきを平均化するために、テストを複数回実行することをお勧めします。Exchange テスト ソリューションでは、テストの実行時間を 8 時間に設定し、独立したテストを最低 3 回実施しました。パフォーマンス データは、テストの実行時間である 8 時間分のデータを収集しました。パフォーマンス サマリー データは、(テストの最初の 2 時間と最後の 1 時間を除外した) 3 ～ 4 時間の安定期間から抽出しました。各 Exchange サーバーの役割について、テストの実行ごとにサーバー間のパフォーマンス サマリー データの平均をとり、各データ ポイントの 1 つの平均値を得ました。次に、各テストの実行の平均を出し、サーバーの役割が同じであるすべてのサーバーについて、実行したテスト全体で 1 つのデータ ポイントを得ました。

予測される負荷の検証

パフォーマンス カウンターを調べたりパフォーマンス検証分析を開始する前に、予測した作業負荷が実際の作業負荷に合っていることを確認してください。シミュレートした作業負荷が予測される作業負荷に合っているかどうかを確認する方法は多数ありますが、最も簡単で一貫性があるのは、メッセージの配信速度を調べる方法です。

予測したピーク メッセージ配信速度を計算する

すべてのメッセージ プロファイルは、1 日に送信される平均メッセージ数と、受信される平均メッセージ数の合計で構成されます。メッセージ配信速度を計算するには、1 日に受信される平均メッセージ数を次の表から選択してください。

ピーク メッセージ配信速度

メッセージ プロファイル	1 日の送信メッセージ	1 日の受信メッセージ
50	10	40
100	20	80
150	30	120
200	40	160

次の例では、各メールボックス サーバーにアクティブなメールボックスが 5,000 個あり、メールボックスのプロファイルが 1 日に 150 通のメッセージである (1 日に 30 通のメッセージを送信し、120 通のメッセージを受信する) ことを前提としています。

5000 個のアクティブなメールボックスのピーク メッセージ配信速度

説明	計算	値
メッセージ プロファイル	1 日の受信メッセージ数	120
メールボックス サーバーごとのアクティブなメールボックスの数	該当なし	5000
メールボックス サーバーごとの 1 日の受信メッセージの合計数	5000 × 120	600000
メールボックス サーバーごとの 1 秒間に受信されるメッセージの合計数	600000 ÷ 28800	20.83
ピーク負荷に対して調整されるメッセージ合計数	20.83 × 2	41.67

メッセージ プロファイルが 1 日 150 メッセージであるアクティブなメッセージボックスを 5,000 個 実行している各メールボックス サーバーに配信されるメッセージ数は、ピーク負荷の場合、1 秒間に 41.67 通であると予測されます。

実際のメッセージ配信速度を測定する

実際のメッセージ配信速度は、各メールボックス サーバー上の MSExchangeIS Mailbox(_Total)\Messages Delivered/sec カウンターを使用して測定できます。測定されたメッセージ配信速度が目標のメッセージ配信速度である 1 秒あたり 1 件または 2 件のメッセージの範囲内である場合、目的の負荷プロファイルは適切に実行されていると考えられます。

サーバーの検証:パフォーマンスと正常性基準

このセクションでは、Exchange 環境が正しくサイジングされ、長期にわたるピーク作業負荷期間中に正常な状態で稼働できるかどうかを判定するために使用するパフォーマンス モニター カウンターおよびしきい値について説明します。Exchange パフォーマンスに関連するカウンターの詳細については、「パフォーマンスとスケーラビリティのカウンターとしきい値」を参照してください。

Hyper-V ルート サーバー

Hyper-V ルート サーバーおよび VM 内で実行しているアプリケーションのパフォーマンスと正常性基準を検証するには、Hyper-V アーキテクチャと Hyper-V アーキテクチャがパフォーマンス監視にどのように影響するかについての基本的な知識が必要です。

Hyper-V には、仮想化スタック、ハイパーバイザー、およびデバイスの 3 つの主要コンポーネントがあります。仮想化スタックはエミュレートされたデバイスを処理し、VM を管理し、入出力サービスを提供します。ハイパーバイザーは仮想プロセッサをスケジュールし、割り込みを管理し、タイマ サービスを提供し、その他のチップレベルの機能を制御します。ハイパーバイザーはデバイスまたは I/O (ハイバーバイザー ドライバーがない場合など) を処理しません。デバイスは、ルート サーバーの一部であるか、または統合サービスの一部としてゲスト サーバーにインストールされます。ルート サーバーはシステム全体を把握し、VM を管理しているため、Windows Management Instrumentation (WMI) およびパフォーマンス カウンターを使用して監視情報も提供します。

プロセッサ

ルート サーバー上 (または、ゲスト VM 内) で物理プロセッサの使用率を検証するときは、標準的な Processor\% Processor Time カウンターはあまり有効ではありません。

それよりも、Hyper-V Hypervisor Logical Processor\% Total Run Time カウンターを調べてください。このカウンターは、ゲスト内で消費されたプロセッサ時間とハイパーバイザーの実行時間の割合を示すため、ハイパーバイザーとルート サーバー上で実行しているすべての VM の全プロセッサの使用率を測定するのに使用してください。このカウンターは、80 パーセントまたは設計した最大使用率の目標を超えないようにしてください。

カウンター	目標値
Hyper-V Hypervisor Logical Processor\% Total Run Time	<80%

ゲスト VM へのサービス提供にプロセッサ時間の何パーセントが消費されたかを調べる場合は、Hyper-V Hypervisor Logical Processor\% Guest Run Time カウンターを調べてください。ハイパーバイザー内での処理にプロセッサ時間の何パーセントが消費されたかを調べる場合は、Hyper-V Hypervisor Logical Processor\% Hypervisor Run Time カウンターを調べてください。このカウンターは 5 パーセント未満である必要があります。Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time カウンターは、仮想化スタック内での処理にプロセッサ時間の何パーセントが消費されたかを示します。このカウンターも 5 パーセント未満である必要があります。これらの 2 つのカウンターを使用して、使用可能な物理プロセッサ時間の何パーセントが仮想化をサポートするために使用されているかを確認できます。

カウンター	目標値
Hyper-V Hypervisor Logical Processor\% Guest Run Time	<80%
Hyper-V Hypervisor Logical Processor\% Hypervisor Run Time	<5%
Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time	<5%

メモリ

VM に割り当てられたメモリをサポートするために十分なメモリが Hyper-V ルート サーバーにあることを確認する必要があります。Hyper-V はルートのオペレーティング システム用に 512 MB (これは Hyper-V のリリースによって異なる場合があります) を自動的に確保します。十分なメモリがない場合、Hyper-V は最後の VM を起動しません。一般的には、Hyper-V ルートサーバー上のメモリの検証について留意する必要はありません。Exchange 役割をサポートするために VM に 十分なメモリが割り当てられていることの方を留意してください。

アプリケーションの正常性

すべての VM が正常な状態にあるかどうかを確認する簡単な方法は、Hyper-V 仮想コンピューター稼働状態の概要カウンターを調べることです。

カウンター	目標値
Hyper-V Virtual Machine Health Summary\Health OK	1
Hyper-V Virtual Machine Health Summary\Health Critical	0

メールボックス サーバー

メールボックス サーバーが適切なサイズに設定されているかどうかを検証する際には、プロセッサ、メモリ、ストレージ、および Exchange アプリケーションの正常性に注目します。このセクションでは、これらの各コンポーネントを検証する方法について説明します。

プロセッサ

設計プロセスでは、サーバーまたはプロセッサ プラットフォームに対して調整されたメガサイクル容量を計算しました。そのうえで、利用可能なメガサイクル容量の 80 % を超えずにサーバーがサポート可能なアクティブなメールボックスの最大数を決定しました。また、通常の運用状況とさまざまなサーバーの保守または障害発生シナリオでの予測される CPU 使用率も決定しました。

検証プロセスでは、最悪のシナリオの負荷が利用可能なメガサイクルの 80 % を超えないことを確認します。また、実際の CPU 使用率が、通常の運用状況とさまざまなサーバーの保守または障害発生シナリオで予想される CPU 使用率に近いことも確認します

Exchange の物理展開の場合、Processor(_Total)\% Processor Time カウンターを使用し、このカウンターが平均で 80 % 未満であることを確認します。

カウンター	目標値
Processor(_Total)\% Processor Time	<80%

Exchange の仮想展開の場合、VM 内で Processor(_Total)\% Processor Time カウンターを測定します。この場合、カウンターは物理的な CPU 使用率は測定しません。ハイパーバイザーによって提供される仮想 CPU の使用率を測定します。したがって、カウンターは、物理プロセッサの正確な数値を提供しないので、設計の検証には使用すべきではありません。詳細については、「Hyper-V:クロックが嘘をつく...どのパフォーマンス カウンターを信頼できますか?」を参照してください。

Microsoft Hyper-V 上で実行している Exchange 展開を検証する場合は、Hyper-V Hypervisor Virtual Processor\% Guest Run Time カウンターを使用します。このカウンターは、ゲスト オペレーティング システムが使用している物理 CPU 数の正確な値を示します。このカウンターは平均で 80 未満である必要があります。

カウンター	目標値
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%

メモリ

設計プロセスでは、各メールボックス サーバー上でアクティブなデータベースの最大数をサポートするために必要なデータベース キャッシュの数量を計算しました。そのうえで、データベース キャッシュとシステム メモリの要件をサポートするために最適な物理メモリ構成を決定しました。

目標の作業負荷をサポートするための十分なメモリが Exchange メールボックス サーバーあるかどうかを検証することは、簡単な作業ではありません。Exchange 内のメモリ マネージャーは、使用可能な物理メモリのほとんどすべてを使用するように設計されているので、使用可能なメモリ カウンターを使用して物理メモリの残量を調べることは役に立ちません。インフォメーション ストア (store.exe) はデータベース キャッシュの物理メモリの大部分を確保します。データベース キャッシュは、データベース ページをメモリに格納するために使用します。メモリ内でページにアクセスすると、データをディスクから取り出す必要がなくなり、読み取り I/O 処理が減ります。データベース キャッシュは書き込み I/O の最適化にも使用されます。

データベース ページが修正されると (ダーティ ページと呼ばれる)、ページは一定期間キャッシュ内にとどまります。キャッシュ内にとどまる時間が長いと、ディスクに変更が書き込まれる前に何度もページが修正される機会が増えます。キャッシュ内にダーティ ページを維持すると、同じ処理で複数のページがディスクに書き込まれる原因となります (書き込み結合と呼ばれます)。Exchange はシステム内で使用可能なメモリをできるだけ多く使用します。これは、Exchange メールボックス サーバー上には使用可能なメモリ数量が多くないからです。

Exchange メールボックス サーバーのメモリ構成が通常より小さいかどうかは、簡単にはわからないかもしれません。ほとんどの場合、メールボックス サーバーはこれまでどおり機能しますが、I/O プロファイルは予想を大きく上回る可能性があります。I/O 処理が多くなると、ディスクの読み取りおよび書き込みの待ち時間が長くなることがあり、アプリケーションの正常性やクライアントのユーザー エクスペリエンスに影響する可能性があります。結果セクションでは、メモリ カウンターへの参照はありません。潜在的なメモリ問題は、ストレージの検証とアプリケーションの正常性の各結果セクションで確認されます。このセクションでは、メモリ関連の問題の方がより簡単に検出されます。

ストレージ

Exchange メールボックス サーバーにパフォーマンス問題が発生している場合、これらの問題はストレージに関連する問題である可能性があります。ストレージの問題が発生している原因としては、前述したように、目標の I/O 要件をサポートするための十分なディスク数が存在しなかったり、過負荷状態が発生していたリ、ストレージの接続インフラストラクチャが適切に設計されていなかったり、あるいは、メモリの不足のように目標の I/O プロファイルを変更する要因が考えられます。

ストレージの検証の最初の手順では、データベースの待ち時間が目標のしきい値を下回ることを確認します。以前のリリースでは、論理ディスク カウンターによってディスクの読み取りおよび書き込みの待ち時間が決定されました。Exchange 2010 では、監視している Exchange メールボックス サーバーには、アクティブおよびパッシブなメールボックス データベース コピーの両方が格納されている可能性が高いと思われます。アクティブおよびパッシブなデータベース コピーの I/O 特性はそれぞれ異なります。I/O サイズはパッシブなコピーの方が大きくなるため、一般にパッシブなコピーでの待ち時間は極めて長くなります。パッシブなデータベースの待ち時間の目標値は、200 ミリ秒で、これはアクティブなデータベース コピーでの目標値の 10 倍です。しかし、パッシブなデータベースでの待ち時間が長くなっても、それがクライアント エクスペリエンスに影響することはないので、それほど心配することではありません。ただし、従来の論理ディスク カウンターを使用して待ち時間を測定する場合は、個別にボリュームを確認し、アクティブおよびパッシブなデータベースを含めたボリュームを分ける必要があります。そのため、Exchange 2010 の新しい MSExchange Database カウンターを使用することをお勧めします。

Exchange 2010 メールボックス サーバーでの待ち時間を検証する際、アクティブなデータベースについては、次の表のカウンターを使用することをお勧めします。

カウンター	目標値
MSExchange Database\I/O Database Reads (Attached) Average Latency	<20 ミリ秒 (msec)
MSExchange Database\I/O Database Writes (Attached) Average Latency	<20 ミリ秒
MSExchange Database\IO Log Writes Average Latency	<1 ミリ秒 (msec)

パッシブなデータベースについては、次の表のカウンターを使用することをお勧めします。

カウンター	目標値
MSExchange Database\I/O Database Reads (Recovery) Average Latency	<200 ミリ秒 (msec)
MSExchange Database\I/O Database Writes (Recovery) Average Latency	<200 ミリ秒
MSExchange Database\IO Log Read Average Latency	<200 ミリ秒

Microsoft Hyper-V 上で実行している Exchange 展開のディスクの待ち時間を検証する際は、VM 内の時間の概念が物理サーバー上と異なるために、I/O Database Average Latency カウンターが正確でない場合があるので注意してください (多くの時間ベースのカウンターについても同じことが言えます)。次の例では、I/O Database Reads (Attached) Average Latency は、同じシミュレートされた作業負荷について、VM 内では 22.8、物理サーバー上では 17.3 であることが示されています。時間ベースのカウンターの値が目標のしきい値を超える場合、サーバーは適切に実行しています。メールボックス サーバーの役割を VM 内に展開する際には、正常性の基準をすべて確認して、サーバーの正常性について決定してください。

仮想および物理メールボックス サーバーのディスク待ち時間カウンターの値

カウンター	仮想メールボックス サーバー	物理メールボックス サーバー
MSExchange Database/
I/O Database Reads (Attached) / Average Latency	22.792	17.250
I/O Database Reads (Attached) / sec	17.693	18.131
I/O Database Reads (Recovery) / Average Latency	34.215	27.758
I/O Database Writes (Recovery) / sec	10.829	8.483
I/O Database Writes (Attached) / Average Latency	0.944	0.411
I/O Database Writes (Attached) / sec	10.184	10.963
MSExchangeIS
RPC Averaged Latency	1.966	1.695
RPC Operations/sec	334.371	341.139
RPC Packets / sec	180.656	183.360
MSExchangeIS メールボックス
Messages Delivered / sec	2.062	2.065
Messages Sent / sec	0.511	0.514

ディスクの待ち時間に加え、Database\Database Page Fault Stalls/sec カウンターを確認します。このカウンターは、データベース キャッシュからの割り当てに使用できるページがないため、処理できないページ フォールトの割合を示します。このカウンターは正常なサーバーでは 0 である必要があります。

カウンター	目標値
Database\Database Page Fault Stalls/sec	<1

また、Database\Log Record Stalls/sec カウンターの値を確認します。この値は、ログ バッファーに空きがないために追加できないログ レコードの 1 秒あたりの数を示します。このカウンターは平均 10 未満である必要があります。

カウンター	目標値
Database\Log Record Stalls/sec	<10

Exchange アプリケーションの正常性

プロセッサ、メモリ、およびディスクに明白な問題が存在しない場合であっても、標準のアプリケーションの正常性カウンターを監視して Exchange メールボックス サーバーが正常な状態であることを確認することをお勧めします。

MSExchangeIS\RPC Averaged Latency カウンターは、データベースの待ち時間が長いことを示す他のカウンターが、実際に Exchange の状態およびクライアント エクスペリエンスに影響を与えているかどうかを示す最良の指標です。RPC の平均遅延時間が長い場合、RPC 要求が多いことに関係していることがよくあります。RPC 要求の数は常に70未満である必要があります。

カウンター	目標値
MSExchangeIS\RPC Averaged Latency	平均 10 ミリ秒未満
MSExchangeIS\RPC Requests	常に 70 未満

次に、トランスポート層が正常であることを確認します。トランスポート層に影響を与えるトランスポートのすべての問題またはトランスポートのダウンストリームの問題は、MSExchangeIS Mailbox(_Total)\Messages Queued for Submission カウンターで検出できます。このカウンターは、常に 50 未満である必要があります。このカウンターが一時的に増加することはありますが、カウンターの値が時間の経過につれて増加したり、15 分間を超えて高い値が持続することがないようにする必要があります。

カウンター	目標値
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission	常に 50 未満

次に、データベース コピーの保守が正常な状態であることを確認します。ログ配布またはログの再生のすべての問題は、MSExchange Replication(*)\CopyQueueLength カウンターおよび MSExchange Replication(*)\ReplayQueueLength カウンターを使用して識別できます。コピー キューの長さはパッシブ コピーのログ ファイル フォルダーにコピーされるのを待っているトランザクション ログ ファイルの数を示しており、常に 1 未満である必要があります。再生キューの長さは、パッシブ コピーに再生されるのを待っているトランザクション ログ ファイルの数を示しており、5 未満である必要があります。この値が高い場合、クライアント エクスペリエンスには影響を与えませんが、ハンドオフ、フェールオーバー、またはアクティブ化が実行される時にストア マウント時間が長くなります。

カウンター	目標値
MSExchange Replication(*)\CopyQueueLength	<1
MSExchange Replication(*)\ReplayQueueLength	<5

クライアント アクセス サーバー

クライアント アクセス サーバーが正常であることを確認するには、プロセッサ、メモリ、およびアプリケーションの正常性を確認します。重要なカウンターの詳細な一覧については、「クライアント アクセス サーバーのカウンター」を参照してください。

プロセッサ

物理的な Exchange 展開では、Processor(_Total)\% Processor Time カウンターを使用します。このカウンターは平均で 80 未満である必要があります。

カウンター	目標値
Processor(_Total)\% Processor Time	<80%

Microsoft Hyper-V 上で実行している Exchange 展開を検証する場合は、Hyper-V Hypervisor Virtual Processor\% Guest Run Time カウンターを使用します。これにより、ゲスト オペレーティング システムによって使用されている物理的な CPU 量の正確な値が得られます。このカウンターは平均で 80 未満である必要があります。

カウンター	目標値
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%

アプリケーションの正常性

MAPI クライアント エクスペリエンスが許容範囲内であることを確認するには、MSExchange RpcClientAccess\RPC Averaged Latency カウンターを使用します。このカウンターは 250 ミリ秒未満である必要があります。待ち時間が長い場合、RPC 要求が多いことに関係している可能性があります。MSExchange RpcClientAccess\RPC Requests カウンターは平均で 40 未満である必要があります。

カウンター	目標値
MSExchange RpcClientAccess\RPC Averaged Latency	<250 ミリ秒
MSExchange RpcClientAccess\RPC Requests	<40

トランスポート サーバー

トランスポート サーバーが正常であることを確認するには、プロセッサ、ディスク、およびアプリケーションの正常性を確認します。重要なカウンターの詳細な一覧については、「トランスポート関連のサーバー カウンター」を参照してください。

プロセッサ

物理的な Exchange 展開では、Processor(_Total)\% Processor Time カウンターを使用します。このカウンターは平均で 80 未満である必要があります。

カウンター	目標値
Processor(_Total)\% Processor Time	<80%

Microsoft Hyper-V 上で実行している Exchange 展開を検証する場合は、Hyper-V Hypervisor Virtual Processor\% Guest Run Time カウンターを使用します。これにより、ゲスト オペレーティング システムによって使用されている物理的な CPU 量の正確な値が得られます。このカウンターは平均で 80 未満である必要があります。

カウンター	目標値
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%

ディスク

ディスクのパフォーマンスが許容範囲内かどうかを確認するには、トランスポート ログおよびデータベースが含まれているボリュームの Logical Disk(*)\Avg. Disk sec/Read および Logical Disk(*)\Avg. Disk sec/Write カウンターを使用します。これらのカウンターは両方とも 20 ミリ秒未満にする必要があります。

カウンター	目標値
Logical Disk(*)\Avg.Disk sec/Read	<20 ミリ秒
Logical Disk(*)\Avg.Disk sec/Write	<20 ミリ秒

アプリケーションの正常性

ハブ トランスポート サーバーのサイズが適切で、正常な状態で実行中であることを確認するには、次の表に示された MSExchangeTransport Queues カウンターを調べます。これらすべてのキューは、さまざまな時にメッセージを受信します。キューの長さが、一定期間、高い値を維持していないこと、および増加し続けていないことを確認します。キューの長さが長くなると、ハブ トランスポート サーバーが過負荷の状態であることを示している可能性があります。または、ネットワークに問題があるか、またはメールボックス サーバーが過負荷の状態で新しいメッセージを受信できない可能性があります。Exchange 環境のその他のコンポーネントを調べて確認する必要があります。

カウンター	目標値
MSExchangeTransport Queues(_total)\Aggregate Delivery	<3000
MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length	<250
MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length	<250
MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length	<100
MSExchangeTransport Queues(_total)\Submission Queue Length	<100

Exchange 2010 ソリューションのテスト

機能検証テスト

機能検証テストには、以下のセクションの情報を使用できます。

Exchange 2010 ソリューションのテスト

データベースの切り替えの検証

データベースの切り替えは、個別のアクティブなデータベースを別のデータベース コピー (パッシブ コピー) に切り替えるプロセスであり、そのデータベース コピーが新しいアクティブなデータベース コピーになります。データベース切り替えは、データセンター内部とデータセンター間の両方で実行可能です。データベースの切り替えは、Exchange 管理コンソール (EMC) または Exchange 管理シェルを使用して実行されます。

データベースのパッシブ コピーが正常に別のサーバーでアクティブ化されたことを検証するには、次のコマンドを実行します。

Move-ActiveMailboxDatabase <DatabaseName> -ActivateOnServer <TargetServer>

成功基準:アクティブなメールボックス データベースが指定されたターゲット サーバーにマウントされている。この結果は以下のコマンドを実行して確認できます。

Get-MailboxDatabaseCopyStatus <DatabaseName>

Exchange 2010 ソリューションのテスト

サーバーの切り替えの検証

サーバー切り替えは、DAG メンバー上のすべてのアクティブなデータベースを 1 つまたは複数のその他の DAG メンバーに対してアクティブ化するプロセスです。データベース切り替えと同様に、サーバー切り替えはデータセンター内部とデータセンター間の両方で実行可能で、EMC とシェルの両方を使用して開始することができます。

• サーバーのデータベースのすべてのパッシブ コピーが、パッシブ コピーをホストしている他のサーバーで正常にアクティブ化されたことを検証するには、次のコマンドを実行します。

  Get-MailboxDatabase -Server <ActiveMailboxServer> | Move-ActiveMailboxDatabase -ActivateOnServer <TargetServer>
  

  成功基準:アクティブなメールボックス データベースが指定されたターゲット サーバーにマウントされている。これは以下のコマンドを実行して確認できます。

  Get-MailboxDatabaseCopyStatus <DatabaseName>
  

• アクティブなデータベースのそれぞれの 1 つのコピーが、データベースのパッシブ コピーをホストしている別のメールボックス サーバーで正常にアクティブ化されることを検証するには、次の操作を実行してサーバーをシャットダウンします。

  現在アクティブなサーバーの電源をオフにします。

  成功基準:アクティブなメールボックス データベースが DAG の別のメールボックス サーバーにマウントされている。これは以下のコマンドを実行して確認できます。

  Get-MailboxDatabaseCopyStatus <DatabaseName>
  

Exchange 2010 ソリューションのテスト

サーバーのフェールオーバーの検証

サーバーのフェールオーバーは、DAG メンバーが MAPI ネットワークをサービスできなくなるか、DAG メンバー上のクラスター サービスが残りの DAG メンバーに接続できなくなると行われます。

アクティブなデータベースのそれぞれの 1 つのコピーが、データベースのパッシブ コピーをホストしている別のメールボックス サーバーで正常にアクティブ化されることを検証するには、次のいずれかの操作を実行してサーバーをオフにします。

• サーバーの電源がオフになるまでサーバーの電源スイッチを押したままにする。

• サーバーから電源ケーブルを引き抜いて、サーバーの電源をオフにする。

成功基準:アクティブなメールボックス データベースが DAG の別のメールボックス サーバーにマウントされている。これは以下のコマンドを実行して確認できます。

Get-MailboxDatabase -Server <MailboxServer> | Get-MailboxDatabaseCopyStatus

Exchange 2010 ソリューションのテスト

データセンターの切り替えの検証

データセンターまたはサイトの障害は、サーバーまたはデータベースのフェールオーバーが行われる障害とは異なる方法で管理されます。高可用性構成では、システムによって自動復旧が開始され、通常は障害が発生してもメッセージング システムは完全に機能した状態にあります。反対に、データセンターの障害は、障害復旧イベントとみなされるため、クライアント サービスを復元して停止を終了するには、復旧を手動で実行および完了する必要があります。ここで実行するプロセスは、データセンターの切り替えと呼ばれます。多くの障害復旧シナリオと同様に、データセンター切り替えを事前に計画および準備すると、復旧プロセスを簡略化して停止期間を短縮できます。

データセンターの切り替えを実行するための詳細な手順を含む、詳細情報については、「データセンターの切り替え」を参照してください。

セカンダリ データセンターをアクティブ化するための初期決定を行った後、4 つの基本手順に従ってデータセンター切り替えの実行を完了します。

1. 部分的に実行中の (障害が発生した) データセンターを終了します。

2. セカンダリ データセンターの前提条件を検証して確認します。

3. メールボックス サーバーをアクティブにします。

4. クライアント アクセス サーバーをアクティブにします。

次のセクションでは、データセンターの切り替えを検証するための手順について説明します。

部分的に障害の発生したデータセンターを終了する (DAG が DAC モードであると仮定)

DAG が DAC モードの場合、プライマリ データセンター内の残りの DAG メンバーを終了するための具体的な操作は、障害の発生したデータセンターの状態によります。次のいずれかの操作を行います。

• 障害の発生したデータセンターのメールボックス サーバーにまだアクセスできる場合 (通常はあり得ません)、それぞれのメールボックス サーバーで次のコマンドを実行します。

  Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename>
  

• 障害の発生したデータセンターのメールボックス サーバーは利用できないが、プライマリ データセンターの Active Directory が機能している場合、ドメイン コントローラーで次のコマンドを実行します。

  Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
  

成功基準:障害が発生したサイト内のすべてのメールボックス サーバーが停止状態にある。これを確認するには、障害が発生したデータセンターのサーバーから次のコマンドを実行します。

Get-DatabaseAvailabilityGroup | Format-List

セカンダリ データセンターの前提条件を検証し確認する

どのプライマリ データセンターのサーバーが停止されているかを表すために、セカンダリ データセンターを更新する必要があります。セカンダリ データセンターのサーバーから次のコマンドを実行します。

Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly

この手順の目的は、セカンダリ データセンター内のサーバーに、サービスの復元時に使用できるメールボックス サーバーについて通知することです。

成功基準:障害が発生したデータ センター内のすべてのメールボックス サーバーが停止状態にある。これを確認するには、セカンダリ データセンターのサーバーから次のコマンドを実行します。

Get-DatabaseAvailabilityGroup | Format-List

メールボックス サーバーをアクティブにする (DAG が DAC モードであると仮定)

セカンダリ データセンター内の DAG メンバーをアクティブにする前に、セカンダリ データセンターのインフラストラクチャ サービスがメッセージング サービスをアクティブにするための準備ができていることを確認することをお勧めします。

DAG が DAC モードである場合、セカンダリ データセンター内のメールボックス サーバーのアクティブ化を完了する手順は、次のとおりです。

1. セカンダリ データセンター内の各 DAG メンバー上のクラスター サービスを停止します。Stop-Service コマンドレットを使用してサービス (たとえば、Stop-Service ClusSvc) を停止するか、または昇格されたコマンド プロンプトから net stop clussvc を使用できます。

2. セカンダリ データセンターのメールボックス サーバーをアクティブにするには、次のコマンドを実行します。

   Restore-DatabaseAvailabilityGroup -Identity <DAGname> -ActiveDirectorySite <insertsitename>
   

   このコマンドが成功した場合、クォーラム条件がセカンダリ データセンターのサーバーに縮小されます。データセンター内のサーバー数が偶数の場合、DAG は、DAG オブジェクトの設定によって識別されるように代替監視サーバーの使用に切り替えます。

3. データベースをアクティブにするには、次のコマンドのいずれかを実行します。

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinPrimarySite>
   

   または

   Move-ActiveMailboxDatabase -Server <DAGMemberInSecondarySite> -ActivateOnServer <DAGMemberinPrimarySite>
   

4. イベント ログを確認し、すべてのエラー メッセージと警告メッセージを確認してセカンダリ サイトが正常であることを確認します。データベースをマウントする前に、表示されたすべての問題を調査して解決する必要があります。

5. データベースをマウントするには、次のコマンドを実行します。

   Get-MailboxDatabase <DAGMemberInSecondarySite> | Mount-Database
   

成功基準:アクティブなメールボックス データベースがセカンダリ サイトのメールボックス サーバーにマウントされている。確認するには、次のコマンドを実行します。

Get-MailboxDatabaseCopyStatus <DatabaseName>

クライアント アクセス サーバーをアクティブにする

クライアントは、Exchange サービスとデータにアクセスするためサービス エンドポイントに接続します。このためインターネットに直接接続するクライアント アクセス サーバーのアクティブ化では、新しいサービス エンドポイント用に構成される新しい IP アドレスをポイントするように DNS レコードを変更します。クライアントは、次の 2 つの方法のどちらかで新しいサービス エンドポイントに自動的に接続します。

• クライアントは、引き続き接続を試みます。TTL (Time to Live) が元の DNS エントリに対して期限切れになった後、およびエントリがクライアントの DNS キャッシュから期限切れになった後は自動的に接続します。ユーザーは、コマンド プロンプトから ipconfig /flushdns コマンドを実行して、その DNS キャッシュを手動でクリアすることもできます。Outlook Web App を使用している場合、Web ブラウザーを閉じてから再起動し、ブラウザーが使用している DNS キャッシュをクリアする必要があります。Exchange 2010 SP1 では、このブラウザーのキャッシュの問題は Outlook Web App 仮想ディレクトリ owa の FailbackURL パラメーターを構成することで軽減できます。

• クライアントの起動または再起動では、スタートアップ時に DNS 参照を実行し、サービス エンドポイントの新しい IP アドレスを取得します。これは、セカンダリ データセンター内のクライアント アクセス サーバーまたはアレイです。

Loadgen を使用するシナリオを検証するには、次の操作を実行します。

1. クライアント アクセス サーバー アレイの DNS エントリを変更して、セカンダリ サイトのハードウェア負荷分散の仮想 IP アドレスをポイントするようにします。

2. すべての Loadgen サーバーで ipconfig /flushdns コマンドを実行します。

3. Loadgen テストを再開します。

4. セカンダリ サイトのクライアント アクセス サーバーが、負荷に対応するようになったことを確認します。

Outlook 2007 クライアントを使用するシナリオを検証するには、次の操作を実行します。

1. クライアント アクセス サーバー アレイの DNS エントリを変更して、セカンダリ サイトのハードウェア負荷分散の仮想 IP アドレスをポイントするようにします。

2. クライアントで ipconfig /flushdns コマンドを実行するか、または TTL が期限切れになるまで待ちます。

3. Outlook クライアントが再接続するのを待ちます。

Exchange 2010 ソリューションのテスト

プライマリ データセンター サービスの復元の検証

以前に障害が発生したデータセンターにサービスを復元するプロセスをフェールバックといいます。データセンターのフェールバックの実行に使用する手順は、データセンターの切り替えの実行に使用する手順と似ています。主な違いは、データセンターのフェールバックはスケジュールされており、停止期間が通常、はるかに短い点です。

Exchange のインフラストラクチャとの依存関係が再アクティブ化され、安定して機能し、検証されるまで、フェールバックを実行しないことが重要です。これらの依存関係が使用できないか、または正常でない場合は、フェールバック プロセスが必要な停止よりも長くなり、プロセスが完全に失敗する可能性があります。

メールボックス サーバーの役割は、プライマリ データセンターにフェールバックされる最初の役割である必要があります。次の手順で、メールボックス サーバーの役割のフェールバック プロセスを詳しく説明します (DAG が DAC モードであると仮定)。

1. DAG メンバーをプライマリ サイトに再度組み込むには、次のコマンドを実行します。

   Start-DatabaseAvailabilityGroup -Identity <DatabaseAvailabilityGroupIdParameter> -ActiveDirectorySite <insertsitename>
   

2. プライマリ データセンターのデータベース コピーの状態を確認するには、次のコマンドを実行します。

   Get-MailboxDatabaseCopyStatus
   

プライマリ データセンター内のメールボックス サーバーが DAG に組み込まれたら、データベース コピーを同期する必要があります。障害の性質、停止の長さ、停止中に管理者が行った操作に応じて、データベース コピーの再シードが必要になる場合があります。たとえば、停止中に、障害が発生したプライマリ データセンターからデータベース コピーを削除し、セカンダリ データセンター内に残存するアクティブなコピーのログ ファイルの切り詰めを許可する場合、再シードが必要になります。この時点では、各データベースは個別に同期できます。プライマリ データセンター内のレプリケートされるデータベース コピーが正常になったら、次の手順に進むことができます。

1. データセンターの切り替えプロセス中、DAG は代替監視サーバーを使用するように構成されました。プライマリ データセンター内で監視サーバーを使用するように DAG を再構成するには、次のコマンドを実行します。

   Set-DatabaseAvailabilityGroup -Identity <DAGName> -WitnessServer <PrimaryDatacenterWitnessServer>
   

2. プライマリ データセンターで再アクティブ化するデータベースは、セカンダリ データセンターでマウント解除する必要があります。次のコマンドを実行します。

   Get-MailboxDatabase | Dismount-Database
   

3. データベースがマウント解除されたら、クライアント アクセス サーバーの URL をセカンダリ データセンターからプライマリ データセンターに移動する必要があります。これには、URL の DNS レコードを、プライマリ データセンター内のクライアント アクセス サーバーまたはアレイをポイントするように変更します。

   重要

   クライアント アクセス サーバーの URL が移動され、DNS TTL およびキャッシュ エントリの期限が切れるまで、次の手順に進まないでください。クライアント アクセス サーバーの URL をプライマリ データセンターに移動する前にプライマリ データセンターのデータベースをアクティブにすると、構成が無効になります (たとえば、マウントされたデータベースが、Active Directory サイトにクライアント アクセス サーバーがない)。

4. データベースをアクティブにするには、次のコマンドのいずれかを実行します。

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinSecondSite>
   

   または

   Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
   

5. データベースをマウントするには、次のコマンドを実行します。

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Mount-Database
   

成功基準:アクティブなメールボックス データベースがプライマリ サイトのメールボックス サーバーに正常にマウントされている。確認するには、次のコマンドを実行します。

Get-MailboxDatabaseCopyStatus <DatabaseName>

Exchange 2010 ソリューションのテスト

テスト設備

テストは、ワシントン州レドモンドのマイクロソフト メイン キャンパスにある、最先端技術のエンタープライズ ソリューション検証ラボ「Microsoft Enterprise Engineering Center」において実施されました。

1 億 2500万米ドルを超えるハードウェアと、業界最先端の相手先ブランド供給業者 (OEM) との継続的な強力なパートナーシップにより、EEC ではほぼあらゆる運用環境を再現できます。EEC では、顧客、パートナー、およびマイクロソフト製品のエンジニア間の広範囲なコラボレーションを可能にする環境を提供します。これにより、マイクロソフトのエンド ツー エンド ソリューションは、顧客の高い期待に応えることができます。

Exchange 2010 ソリューションのテスト

ソリューション検証結果

以下のセクションは、機能およびパフォーマンス検証テストの結果をまとめたものです。

Exchange 2010 ソリューションのテスト

機能の検証結果

次の表は、機能検証テストの結果をまとめたものです。

機能の検証結果

テスト ケース	結果	コメント
データベースの切り替え	成功	エラーを発生させることなく完了
サーバーの切り替え	成功	エラーを発生させることなく完了
サーバーの障害	成功	エラーを発生させることなく完了
サイトの障害	成功	エラーを発生させることなく完了

Exchange 2010 ソリューションのテスト

ストレージ設計の検証結果

単一のストレージ フレーム上のサイトごとのすべてのディスクに対するテストから、CX4-480 が 150 メッセージを .15 IOPS および追加の 20% の余地を確保したユーザー プロファイルで構成された、8 台の Exchange VM にわたり 8,000 を超える Exchange 2010 トランザクション IOPS を処理することがわかります。パフォーマンスは、この構成に必要とされた目標のベースラインである 5,832 IOPS を超え、ピーク時の負荷に対する余地を残しています。ディスクの遅延は、Exchange 2010 パフォーマンスのマイクロソフト ベスト プラクティスを基準にして、すべて許容できるパラメーターの範囲内でした。

ストレージ設計の検証結果

データベース I/O	目標値	通常の運用状態の 4 台のメールボックス サーバー (メールボックス サーバーあたり 2,700 ユーザー)	切り替え状態の 4 台のメールボックス サーバー (メールボックス サーバーあたり 5,400 ユーザー)	合計
トランザクション IOPS の実測値 (I/O データベース読み取り/秒 + I/O データベース書き込み/秒)	1944 / 3888	3576 IOPS	4488 IOPS	8064 IOPS
I/O データベース読み取り/秒	該当なし	2193	2729	4922
I/O データベース書き込み/秒	該当なし	1439	1703	3142
I/O Database Reads Average Latency (msec)	<20 ミリ秒	14	18	16
I/O Database Writes Average Latency (msec)	データベースへの書き込みは非同期なため、クライアント遅延の指標としては不適切	14	18	16
I/O Log Writes/sec	該当なし	1238	1560	2798
I/O Log Reads Average Latency (msec)	<10 ミリ秒	2	2	2

Exchange 2010 ソリューションのテスト

サーバー設計の検証結果

以下のセクションは、テスト ケースのサーバー設計の検証結果をまとめたものです。

Loadgen の検証:テスト シナリオ

テスト	説明
通常の運用	1 つのサイトで 10,800 ユーザーの 100% の同時実行負荷をシミュレートしました。各メールボックス サーバーは 2,700 ユーザーを処理しました。
単一サーバーの障害または単一サーバーのメンテナンス (サイト内)	サイトごとに単一の Hyper-V ホスト サーバーの障害をシミュレートしました。5,400 ユーザーを処理する 1 台の VM がある単一の Hyper-V ホストに対して、100% の同時実行負荷が実行されました。3 台の組み合わされたクライアント アクセス サーバーおよびハブ トランスポート サーバーだけが負荷を処理しました。
サイトの障害	サイトの障害がシミュレートされ、スタンバイ メールボックス サーバー VM 上のセカンダリ イメージがアクティブ化されました。単一のサイトの 21,600 ユーザーに対して、100% の同時実行負荷が実行されました。

テスト ケース:通常の運用状態

このテスト ケースでは、通常の運用状態におけるピークの負荷を表します。通常の運用状態とは、すべてのアクティブおよびパッシブ データベースが、本来の計画通りのサーバー上にある状態を表します。このテスト ケースは最悪のケースの負荷を表していないので、重要なパフォーマンス評価テストではありません。これは、サーバーの障害または保守イベントがない状態で、この環境がどのように実行されるかを示す良い指標となります。このテストにおける目的は、通常の運用状態にピーク時の負荷がかかった状態で、Exchange 環境全体を評価することでした。すべての Exchange VM は通常の状態で運用されていました。Loadgen を構成し、ピーク時の負荷をシミュレートしました。ピーク時のモードで実行する 150 メッセージの動作プロファイルは、1 秒あたりの送信および受信メッセージを 2 倍生成すると予想されました。

予測される負荷の検証

メッセージ配信率は、テスト済みの負荷が目標の負荷に合うことを検証します。メッセージ配信率は目標値よりもわずかに高く、その結果負荷は目的のプロファイルよりもわずかに高くなっています。

カウンター	目標値	テストの結果
Message Delivery Rate Per Mailbox	15.0	15.2

Validation of Primary Mailbox Servers

次の表は、プライマリ メールボックス サーバー VM の検証結果を示します。

プロセッサ

プロセッサの使用率は予想どおり 70% を下回っています。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<70%	69

ストレージ

ストレージの結果は良好です。すべての遅延は目標を下回っています。

カウンター	目標値	テストの結果
MSExchange Database\I/O Database Reads (Attached) Average Latency	<20 ミリ秒	19
MSExchange Database\I/O Database Writes (Attached) Average Latency	<20 ミリ秒 <読み取りの平均	18
Database\Database Page Fault Stalls/sec	0	0
MSExchange Database\IO Log Writes Average Latency	<20 ミリ秒	5
Database\Log Record Stalls/sec	0	0

アプリケーションの正常性

Exchange は非常に正常で、アプリケーションの正常性の決定に使用されるカウンターはすべて目標値を十分に下回っています。

カウンター	目標値	テストの結果
MSExchangeIS\RPC Requests	<70	3.0
MSExchangeIS\RPC Averaged Latency	<10 ミリ秒	2.0
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission	0	2.0

セカンダリ メールボックス サーバーの検証

次の表は、セカンダリ メールボックス サーバー VM の検証結果を示します。

プロセッサ

プロセッサの使用率は予想どおり 70% を下回っています。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<70%	26

ストレージ

ストレージの結果は良好です。すべての遅延は目標を下回っています。

カウンター	目標値	テストの結果
MSExchange Database\I/O Database Reads (Recovery) Average Latency	<100 ミリ秒	0
MSExchange Database\I/O Database Writes (Recovery) Average Latency	<100 ミリ秒 <読み取りの平均	16
Database\Database Page Fault Stalls/sec	0	0
MSExchange Database\IO Log Writes Average Latency	<20 ミリ秒	3
Database\Log Record Stalls/sec	0	0

アプリケーションの正常性

セカンダリ メールボックス サーバーは 3 番目のパッシブ データベース コピーを保守するだけなので、標準の Exchange アプリケーションの正常性の指標はこのシナリオにはあてはまりません。

カウンター	目標値	テストの結果
MSExchangeIS\RPC Requests	<70	該当なし
MSExchangeIS\RPC Averaged Latency	<10 ミリ秒	該当なし
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission	0	該当なし

クライアント アクセス サーバーおよびハブ トランスポート サーバーの検証

次の表は、クライアント アクセス サーバー VM およびハブ トランスポート サーバー VM の検証結果を示します。

プロセッサ

プロセッサの使用率は予想どおり低くなっています。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<70%	48

ストレージ

ストレージの結果は良好です。遅延は非常に小さいので、メッセージ トランスポートに影響はありません。

カウンター	目標値	テストの結果
Logical/Physical Disk(*)\Avg.Disk sec/Read	<20 ミリ秒	0.001
Logical/Physical Disk(*)\Avg.Disk sec/Write	<20 ミリ秒	0.005

アプリケーションの正常性

RPC Averaged Latency の値が低いことから、クライアント アクセス サーバーの状態が正常で、クライアント エクスペリエンスに影響を与えないことが確認できます。

カウンター	目標値	テストの結果
MSExchange RpcClientAccess\RPC Averaged Latency	<250 ミリ秒	8
MSExchange RpcClientAccess\RPC Requests	<40	3

Transport Queues カウンターはすべて目標を下回っているため、ハブ トランスポート サーバーが正常で、要求されたメッセージを処理して配信できることを確認できます。

カウンター	目標値	テストの結果
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)	<3000	2.5
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length	<250	0
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length	<250	2.3
\MSExchangeTransport Queues(_total)\Submission Queue Length	<100	0
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length	<100	0.3

ルート サーバーの状態の検証

次の表は、Hyper-V ルート サーバーの検証結果を示しています。

プロセッサ

予想どおり、プロセッサの使用率は非常に低く、目標のしきい値を大きく下回っています。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time	<75%	66
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time	<5%	2
Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time	<80%	68
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time	<5%	3

アプリケーションの正常性

Virtual Machine Health Summary カウンターは、すべての VM が正常な状態であることを示しています。

カウンター	目標値	テストの結果
Hyper-V Virtual Machine Health Summary\Health Critical	0	0

テスト ケース:単一サーバーの障害または単一サーバーのメンテナンス (サイト内)

このテストにおける目的は、物理的な Hyper-V ルート サーバーの障害または保守運用状態にピーク時の負荷がかかった状態で、Exchange 環境全体を評価することでした。サイト内の いずれかの Hyper-V ルート サーバーで実行されているすべての VM はシャットダウンされ、ホストの保守状態をシミュレートします。これにより、データベース イメージ (コピー) は別のメールボックス サーバー VM に移動され、メールボックス サーバー VM あたり 5,400 ユーザーの運用状態が生成されました。クライアント アクセスおよびハブ トランスポート サーバーの組み合わせたもののうち、半分のみがクライアント アクセスおよびメールの配信を処理しました。

予測される負荷の検証

実際のメッセージ配信率は目標値を満たしました。

カウンター	目標値	テストの結果
サーバーごとのメッセージ配信率	30	30

Validation of Primary Mailbox Servers

次の表は、プライマリ メールボックス サーバー VM の検証結果を示します。

プロセッサ

プロセッサの使用率は、目標を若干上回りました。このテスト ケースはピーク時の負荷における障害の発生または保守のシナリオを表しているので、通常では起こりえないイベントです。プロセッサの使用率が長期間にわたってこのように高いことは望ましくありません。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%	83

ストレージ

ストレージの結果は許容範囲のようです。読み取りの平均待ち時間は目標を若干上回っています。データベース書き込みの平均待ち時間は、目標よりも高くなっています。これはピーク時の負荷において最悪ケースの障害が発生した場合のシナリオで、発生率の低いイベントです。待ち時間が長くても、アプリケーションの正常性カウンターが目標値を超えることはないので、ユーザー エクスペリエンスは依然として許容範囲内にあるはずです。待ち時間の遅延が長期間にわたってこのように長いことは望ましくありません。

カウンター	目標値	テストの結果
MSExchange Database\I/O Database Reads (Attached) Average Latency	<20 ミリ秒	20.5
MSExchange Database\I/O Database Writes (Attached) Average Latency	<20 ミリ秒	23
Database\Database Page Fault Stalls/sec	0	0
MSExchange Database\IO Log Writes Average Latency	<20 ミリ秒	8
Database\Log Record Stalls/sec	0	0

アプリケーションの正常性

カウンターは、Exchange が依然として適度に正常であることを示しています。負荷のピーク時において、ある程度の数のメッセージがキューに入り始めています。この状態が長期間にわたって継続することは望ましくありません。

カウンター	目標値	テストの結果
MSExchangeIS\RPC Requests	<70	9.0
MSExchangeIS\RPC Averaged Latency	<10 ミリ秒	2.0
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission	0	77

セカンダリ メールボックス サーバーの検証

次の表は、セカンダリ メールボックス サーバー VM の検証結果を示します。

プロセッサ

プロセッサの使用率は予想どおり 70% を下回っています。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<70%	21

ストレージ

ストレージの結果は良好です。すべての遅延は目標を下回っています。

カウンター	目標値	テストの結果
MSExchange Database\I/O Database Reads (Recovery) Average Latency	<100 ミリ秒	0
MSExchange Database\I/O Database Writes (Recovery) Average Latency	<100 ミリ秒 <読み取りの平均	21
Database\Database Page Fault Stalls/sec	0	0
MSExchange Database\IO Log Writes Average Latency	<20 ミリ秒	3
Database\Log Record Stalls/sec	0	0

アプリケーションの正常性

セカンダリ メールボックス サーバーは 3 番目のパッシブ データベース コピーを保守するだけなので、標準の Exchange アプリケーションの正常性の指標はこのシナリオにはあてはまりません。

カウンター	目標値	テストの結果
MSExchangeIS\RPC Requests	<70	該当なし
MSExchangeIS\RPC Averaged Latency	<10 ミリ秒	該当なし
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission	0	該当なし

クライアント アクセス サーバーおよびハブ トランスポート サーバーの検証

次の表は、クライアント アクセス サーバー VM およびハブ トランスポート サーバー VM の検証結果を示します。

プロセッサ

プロセッサの使用率は予想どおり 80% を下回っています。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%	74

ストレージ

ストレージの結果は良好です。遅延は非常に小さいので、メッセージ トランスポートに影響はありません。

カウンター	目標値	テストの結果
Logical/Physical Disk(*)\Avg.Disk sec/Read	<20 ミリ秒	0.001
Logical/Physical Disk(*)\Avg.Disk sec/Write	<20 ミリ秒	0.008

アプリケーションの正常性

RPC Averaged Latency の値が低いことから、クライアント アクセス サーバーの状態が正常で、クライアント エクスペリエンスに影響を与えないことが確認できます。

カウンター	目標値	テストの結果
MSExchange RpcClientAccess\RPC Averaged Latency	<250 ミリ秒	18
MSExchange RpcClientAccess\RPC Requests	<40	14

Transport Queues カウンターはすべて目標を下回っているため、ハブ トランスポート サーバーが正常で、要求されたメッセージを処理して配信できることを確認できます。

カウンター	目標値	テストの結果
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)	<3000	49
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length	<250	0
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length	<250	43
\MSExchangeTransport Queues(_total)\Submission Queue Length	<100	53
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length	<100	4

ルート サーバーの状態の検証

次の表は、Hyper-V ルート サーバーの検証結果を示しています。

プロセッサ

プロセッサの使用率は目標のしきい値に近く、ピーク時の負荷における障害または保守では予想される値です。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time	<75%	77
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time	<5%	2
Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time	<80%	79
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time	<5%	3

アプリケーションの正常性

Virtual Machine Health Summary カウンターは、すべての VM が正常な状態であることを示しています。

カウンター	目標値	テストの結果
Hyper-V Virtual Machine Health Summary\Health Critical	0	0

テスト ケース:サイトの障害と切り替え

このテスト ケースは、プライマリ サイトのアクティブなデータベースをセカンダリ サイトのパッシブ データベースに切り替えることでサイトの障害をシミュレートしており、その結果 1 つのサイトで 21,600 のメールボックスがアクティブになります。存続しているサイトの 4 台のプライマリ メールボックス サーバー VM は、それぞれ通常の負荷 (2,700 のアクティブなメールボックス) で実行しています。存続しているサイトの 4 台のセカンダリ メールボックス サーバー VM は、それぞれにつき 2,700 のアクティブなメールボックスを実行しています。各 Hyper-V ルート サーバーは 5,400 のアクティブなメールボックスをホストしています。

予測される負荷の検証

メッセージ配信率は目標値よりもわずかに高く、その結果負荷は目的のプロファイルよりもわずかに高くなっています。

カウンター	目標値	テストの結果
サーバーごとのメッセージ配信率	15	15.1

Validation of Primary Mailbox Servers

次の表は、プライマリ メールボックス サーバー VM の検証結果を示します。

プロセッサ

プライマリ メールボックス サーバー VM は通常の負荷で実行中で、プロセッサの使用率は予想どおり目標を下回っています。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<70%	63

ストレージ

ストレージの結果は良好です。すべての遅延は目標を下回っています。

カウンター	目標値	テストの結果
MSExchange Database\I/O Database Reads (Attached) Average Latency	<20 ミリ秒	12
MSExchange Database\I/O Database Writes (Attached) Average Latency	<20 ミリ秒	13
Database\Database Page Fault Stalls/sec	0	0
MSExchange Database\IO Log Writes Average Latency	<20 ミリ秒	4
Database\Log Record Stalls/sec	0	0

アプリケーションの正常性

Exchange は非常に正常で、アプリケーションの正常性の決定に使用されるカウンターはすべて目標値を十分に下回っています。

カウンター	目標値	テストの結果
MSExchangeIS\RPC Requests	<70	3.0
MSExchangeIS\RPC Averaged Latency	<10 ミリ秒	2.0
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission	0	3

セカンダリ メールボックス サーバーの検証

次の表は、セカンダリ メールボックス サーバー VM の検証結果を示します。

プロセッサ

プロセッサの使用率は目標の 80 ％ を若干上回っています。これは目標よりも高くなっていますが、他の Exchange の状態カウンターに影響を与えているようには見えません。このテストは発生率の低いサイト障害が発生した場合のピーク時の負荷をシミュレートしているため、この値は問題ありません。このレベルのプロセッサ使用率が長期間にわたって持続することは望ましくありません。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%	84

ストレージ

ストレージの結果は良好です。すべての遅延は目標を下回っています。

カウンター	目標値	テストの結果
MSExchange Database\I/O Database Reads (Attached) Average Latency	<20 ミリ秒	17
MSExchange Database\I/O Database Writes (Attached) Average Latency	<20 ミリ秒 <読み取りの平均	12
Database\Database Page Fault Stalls/sec	0	0
MSExchange Database\IO Log Writes Average Latency	<20 ミリ秒	3
Database\Log Record Stalls/sec	0	0

アプリケーションの正常性

カウンターは Exchange が正常であることを示しています。キューに入るメッセージは少ないです。

カウンター	目標値	テストの結果
MSExchangeIS\RPC Requests	<70	3
MSExchangeIS\RPC Averaged Latency	<10 ミリ秒	2
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission	0	106

クライアント アクセス サーバーおよびハブ トランスポート サーバーの検証

次の表は、クライアント アクセス サーバー VM およびハブ トランスポート サーバー VM の検証結果を示します。

プロセッサ

プロセッサの使用率は予想どおり 80% を下回っています。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<70%	63

ストレージ

ストレージの結果は良好です。遅延は非常に小さいので、メッセージ トランスポートに影響はありません。

カウンター	目標値	テストの結果
Logical/Physical Disk(*)\Avg.Disk sec/Read	<20 ミリ秒	0.002
Logical/Physical Disk(*)\Avg.Disk sec/Write	<20 ミリ秒	0.003

アプリケーションの正常性

RPC Averaged Latency の値が低いことから、クライアント アクセス サーバーの状態が正常で、クライアント エクスペリエンスに影響を与えないことが確認できます。

カウンター	目標値	テストの結果
MSExchange RpcClientAccess\RPC Averaged Latency	<250 ミリ秒	9
MSExchange RpcClientAccess\RPC Requests	<40	7

Transport Queues カウンターはすべて目標を下回っているため、ハブ トランスポート サーバーが正常で、要求されたメッセージを処理して配信できることを確認できます。

カウンター	目標値	テストの結果
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)	<3000	5
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length	<250	0
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length	<250	4
\MSExchangeTransport Queues(_total)\Submission Queue Length	<100	0
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length	<100	1

ルート サーバーの状態の検証

次の表は、Hyper-V ルート サーバーの検証結果を示しています。

プロセッサ

プロセッサの使用率は目標の 80 ％ を上回っています。このテストは発生率の低いサイト障害が発生した場合のピーク時の負荷をシミュレートしているため、この値は問題ありません。このレベルのプロセッサ使用率が長期間にわたって持続することは望ましくありません。

カウンター	目標値	テストの結果
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time	<75%	85
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time	<5%	2
Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time	<80%	87
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time	<5%	3

アプリケーションの正常性

Virtual Machine Health Summary カウンターは、すべての VM が正常な状態であることを示しています。

カウンター	目標値	テストの結果
Hyper-V Virtual Machine Health Summary\Health Critical	0	0

Exchange 2010 ソリューションのテスト

終わりに

このホワイト ペーパーでは、Cisco および EMC ハードウェア上に展開された複数のサイトに 32,400 個のメールボックスが存在するという顧客環境において、Exchange 2010 ソリューションの設計、テスト、および評価の方法の一例を提供しています。このドキュメントでは、重要なビジネスの要件を確実に満たすと同時に、主要な課題に取り組むための手助けとなる重要な設計上の決定点を段階的に説明しています。

Exchange 2010 ソリューションのテスト

追加情報

Exchange 2010 の完全なドキュメントについては、「Exchange Server 2010」を参照してください。

Cisco と EMC に関連する追加の情報については、次のリソースを参照してください。

• EMC CLARiiON CX4-480:EMC CLARiiON 仮想プロビジョニング

• EMC CLARiiON CX4-480:製品の概要

• Cisco ユニファイド コンピューティングとサーバー:UCS の概要

• Cisco ユニファイド コンピューティングとサーバー:B シリーズ ブレード サーバー

• Cisco ユニファイド コンピューティングとサーバー:UCS マネージャー

このドキュメントは、現状有姿のままで提供されています。このドキュメントに記載されている情報および図表 (URL 等のインターネット Web サイトに関する情報を含む) は、将来予告なしに変更することがあります。このドキュメントを使用する場合の危険性はお客様が負うものとします。

このドキュメントは、マイクロソフトの製品の知的財産権に関する法的な権利をお客様に許諾するものではありません。このドキュメントは、内部的な参照の目的でコピーして使用することができます。

Exchange 2010 ソリューションのテスト