メールボックスの格納域の設計プロセス
適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3
トピックの最終更新日: 2016-11-28
記憶域設計プロセスを以下の 3 つのステップに分割することをお勧めします。以下のセクションでは、メールボックスの記憶域要件、ベスト プラクティスなど、各設計手順に関する詳細な情報を示します。
手順 1: 入力の記憶域要件を収集する
複数の Exchange 2010 アーキテクチャの要因が、メールボックスの記憶域設計に影響します。次の表に、メールボックスの記憶域設計に影響する最も重要な要因を示します。
メールボックスの記憶域設計内のアーキテクチャの要因
| 設計要因 | 説明 | 記憶域設計の影響 |
|---|---|---|
メールボックス数 |
特定のメールボックス サーバー上にホストされるメールボックスの最大数です。 |
パフォーマンス メールボックスの数が多いほど、サーバーあたりの配信され、開かれているメッセージの数が多くなります。これにより、より多くのログおよびデータベース I/O が生成されます。 容量 メールボックスの数が多いほど、メールボックスの内容を格納するための容量が増えます。これは、サーバーあたりのデータベースの数とデータベースのサイズに影響します。メールボックスの数が多いほど、1 日に各サーバーで生成されるログの数も増えます。 信頼性 通常、メールボックス サーバーにホストされているメールボックスの数が多いほど、高可用性に対するニーズが高まります。 |
メールボックスの同時実行 |
メールボックス サーバーに同時に接続しているユーザーの割合が、1 時間にわたって測定されます。 |
パフォーマンス 同時実行の割合が高いほど、サーバーあたりに配信され、開かれているメッセージの数が多くなります。これにより、より多くのログおよびデータベース I/O が生成されます。一般に、標準のインフォメーション ワーカーの記憶域サイズには、100% の同時実行が使用されます。 容量 同時実行の割合が高いほど、1 日に各サーバーで生成されるログの数も増えます。 |
メールボックスのサイズ |
メールボックスあたりの最大メールボックス クォータです。たとえば、最大メールボックス サイズは 10 GB です。これには、プライマリ メールボックス、個人用アーカイブ、および回復可能なアイテム (収集) データに必要な容量が含まれます。 |
パフォーマンス プライマリ メールボックスが大きいほど、たとえば Microsoft Office Outlook Web App でのフル Microsoft Outlook オフライン フォルダー ファイル (.ost) 同期および新しいビュー作成など、不定期のデータベース操作用に処理するコンテンツが増えます。これにより、生成されるログおよびデータベース I/O がわずかに増える可能性があります。 容量 メールボックスが大きいほど、メールボックスの内容を格納するための容量が増えます。これは、サーバーあたりのデータベースの数とデータベースのサイズに影響します。 |
メールボックスの利用状況プロファイル |
メールボックス サーバー上でのユーザーの利用状況特性です。通常、1 日に送受信されるメッセージ、およびキロバイト (KB) 単位の平均メッセージ サイズとして定義されます。 |
パフォーマンス メールボックスの利用状況プロファイルを集中的に使用するほど、生成されるログおよびデータベース I/O が増えます。 容量 メールボックスの利用状況プロファイルを集中的に使用するほど、1 日に各サーバーで生成されるログの数も増えます。 |
電子メール クライアントの種類 |
たとえば Outlook 2003 キャッシュ Exchange モード、Windows Mobile、Microsoft Exchange ActiveSync、Microsoft Office Outlook Web App など、さまざまな電子メール クライアントの種類と割合です。 |
パフォーマンス 異なるクライアントは、サーバー上で異なるパフォーマンス特性を示します。 |
電子メール クライアント拡張機能 |
Office Communicator、Windows デスクトップ サーチ クライアントなど、電子メール クライアントの機能を拡張する Microsoft およびサード パーティ製アプリケーションです。 |
パフォーマンス 実装に応じて、電子メール クライアントの拡張機能アプリケーションがメールボックス サーバー データベース I/O に与える影響は、小さい場合から非常に大きい場合まであります。 |
サーバー アプリケーション |
たとえば、サード パーティのモバイル デバイス アプリケーション、ウイルス対策アプリケーションなど、Exchange メールボックス サーバーに対してローカルまたはリモートで実行するアプリケーションです。 |
パフォーマンス 実装に応じて、サーバー アプリケーションが、メールボックス サーバー データベース I/O に与える影響は、小さい場合から非常に大きい場合まであります。 |
高可用性の要件 |
Exchange 2010 の高可用性が使用されているかどうか、およびどのように構成されているか (たとえば、コピー数、サイト数、時間差コピー) を示します。 |
パフォーマンス 高可用性ソリューションでは、ログのレプリケーションによって生成された追加のログ ボリューム I/O を処理するために、非高可用性ソリューションよりも少し多く I/O が必要となる可能性があります。 容量 高可用性を使用すると、必要なデータベース ファイルの記憶域の量が (コピー数に応じて) 増加します。循環ログを使用する場合は、ログの容量が減少する場合があります。高可用性を使用すると、1 日に各サーバーで生成されるログの数が増えます。 信頼性 高可用性を展開すると、実行可能なストレージ オプションの数が増加します。高可用性展開で複数のデータベース コピーを使用する場合、信頼性が低いストレージ、RAID のないストレージ、または JBOD (Just a Bunch Of Disks) を使用できる可能性があります。 |
前の表で説明した機能の詳細については、以下のトピックを参照してください。
手順 2: I/O と容量の要件に基づいてストレージ アーキテクチャを設計する
Exchange 2010 の入力の記憶域要件を収集したら、I/O と容量の要件に基づいてストレージ アーキテクチャを設計する必要があります。ストレージ アーキテクチャを構成するには複数の方法があります。ストレージ アーキテクチャの要件を手動で計算できます。または、Exchange 2010 Mailbox Server Role Requirements Calculator を使用できます。要件を手動で計算するには、メールボックスの記憶域設計についてより深く理解する必要があります。これについては、後から「メールボックス サーバーの役割の要件を手動で計算する」に一覧されたトピックで示します。Mailbox Server Role Calculator を使用する場合、情報を入力すると、設計の推奨ベスト プラクティスが得られます。
メールボックス サーバーの役割の要件を手動で計算する
メールボックス サーバーの役割のアーキテクチャを導き出すために、次の手順を完了します。
高可用性モデルを決定するには、「高可用性の要因について」を参照してください。
データベースおよびログ容量の要件を計算するには、「メールボックス データベースおよびログの容量の要因について」を参照してください。
メモリ要件を確認するには、「メールボックス データベース キャッシュについて」を参照してください。
データベースおよびログ パフォーマンスの要件を計算するには、「データベースとログのパフォーマンス要因について」を参照してください。
要件に基づいて論理ユニット番号 (LUN) アーキテクチャを決定するには、「Exchange 2010 LUN のアーキテクチャについて」を参照してください。
要件に基づいてストレージ アーキテクチャを決定するには、「格納域の構成について」を参照してください。
CPU の要件を確認するには、「メールボックス サーバーのプロセッサ容量計画」を参照してください。
この情報が全体としてどうなるのかを表示するには、Exchange 2010 メールボックス サーバーの役割の設計例 を確認します。
Mailbox Server Role Requirements Calculator を使用する
Exchange 2010 Mailbox Server Role Requirements Calculator を使用すると、一連の入力要素を指定することで、メールボックス サーバーの役割の要件を確認できます。計算用シートで、メモリ、ストレージ (I/O パフォーマンス、容量、および記憶域構成)、最適な LUN レイアウト、CPU メガサイクルの要件を確認できます。Exchange 2010 メールボックス サーバーの最適なソリューションを設計するには、多数の変数を考慮する必要があり、計算用シートを用いると設計プロセスでの作業が容易になります。この計算用シートの詳細については (および計算用シートをダウンロードするには)、Exchange Server チーム ブログの記事「Exchange 2010 Mailbox Server Role Requirements Calculator」を参照してください (このサイトは英語の場合があります)。
注意
各ブログのコンテンツおよびその URL は予告なしに変更されることがあります。各ブログのコンテンツは現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。スクリプトの例やコードなどを含め、「Microsoft 開発者サービス契約」の規定に従って活用してください。
手順 3: 記憶域のパフォーマンスと信頼性を検証する
運用環境にストレージ ソリューションを実装する前に、ソリューションが正しく構成されているかどうかを検証することが重要です。ここでは、テスト済みのソリューションが含まれるプログラムから始めて、Exchange のストレージ ソリューションを正しくテストするためのガイダンスを示します。
また、ストレージ ソリューションの管理、テスト、および監視に役立つさまざまなツールについて説明します。I/O パフォーマンスの理解とトラブルシューティングの詳細については、「データベースとログのパフォーマンス要因について」を参照してください。
Exchange Solution Reviewed Program
ストレージ ソリューションを選択するときは、記憶域用 Microsoft Exchange Solution Reviewed Program (ESRP) で確認された、ESRP-Storage と呼ばれるソリューションを選択することをお勧めします。ESRP-Storage は Exchange 専用のテストとベスト プラクティス発行フレームワークであり、既知の優れた Exchange ストレージ ソリューションの作成を支援するプロセスを確認します。ESRP-Storage の目標は以下のとおりです。
ストレージ ベンダーに、Exchange 記憶域テストとベスト プラクティス発行の規範となるガイダンスを提供します。
ストレージ ソリューションが Exchange のベスト プラクティスを満たすように、ストレージ ソリューションを確認する機構を開発します。
Exchange の展開を対象とした、適切にテストされ、高品質のストレージ ソリューションを顧客に提供します。
詳細については、Microsoft Exchange Solution Reviewed Program (ESRP)を参照してください (このサイトは英語の場合があります)。
注意
ESRP-Storage は、Microsoft の証明書、資格、またはロゴ プログラムではありません。
記憶域はさまざまな方法で構成できるため、テスト済みの構成を評価し、ベスト プラクティスを使用することで、コストを削減し、展開までの時間を短縮することができます。
記憶域のテスト
ソリューションをテストする前に、テストの目的を理解するためにいくつかの作業を行う必要があります。記憶域のテストを正しく行うには、次のことが重要になります。
テストの目的を決定します。たとえば、パフォーマンス、スループット、および容量について、必要な値を検討します。
運用環境で使用する記憶域に接続されているサーバーと同じ数のサーバーでテストします。これには Exchange 以外のサーバーが含まれます。
運用レベルを満たす容量の物理ディスクを使用して、運用サイズのデータベースでテストします。ほとんどの物理ディスクのパフォーマンス特性は、データ セットのサイズに基づいて変化します。
記憶域がトランザクション I/O の要件を満たすことを確認し、許容される待ち時間内でのソリューションの最大パフォーマンスを確認します。
バックアップと復元に関するサービス レベル契約 (SLA) を満たすためのバックアップ スループットおよびパフォーマンス要件を、記憶域が満たしていることを確認します。
記憶域関連のツール
Microsoft Exchange Server Jetstress ツールは Exchange I/O の特性を正確にシミュレートします。これにはストレス テストとパフォーマンス テストの両方が含まれ、許容される待ち時間内での LUN の最大パフォーマンスを示します。Exchange Load Generator を使用して Microsoft Office Outlook クライアントをシミュレートします。
両方のツールが Outlook をシミュレートします。Outlook クライアントのシミュレートは、サーバー ディスクの待ち時間だけでなく、実際のクライアントの待ち時間を測定する唯一の方法です。ツールをダウンロードする方法など、これらのツールの詳細については、「パフォーマンスとスケーラビリティの評価用ツール」を参照してください。
重要
Exchange Jetstress ツールは、サーバーに運用データを格納する前に、システムで使用する必要があります。Jetstress は、運用データが格納されているシステムで使用しないでください。
重要
Exchange Load Generator は、運用環境でなく、テスト環境で使用するためのものです。
サーバーの記憶域の稼働状態を監視する
ストレージ ソリューションの監視は、データの破損やダウンタイムにつながるハードウェアやソフトウェアの警告およびエラー状況を事前に特定するために不可欠です。
ストレージ ソリューションの監視に役立つツールを以下に示します。これらのツールは、Exchange 管理コンソールの [ツールボックス] ノードにあります。
ベスト プラクティス アナライザー ツール
パフォーマンス モニター
パフォーマンス トラブルシューティング ツール
また、Microsoft System Center Operations Manager 2007 を使用して、Exchange 組織のさまざまな面のほか、ストレージ ソリューションを監視することもできます。
パフォーマンス モニター (perfmon.exe) は、Exchange 2010 用の Microsoft 管理コンソール (MMC) パフォーマンス スナップインです。Perfmon は MSExchangeIS パフォーマンス オブジェクトを使用してカウンター情報を取得し、ストレージ ソリューションの状態を判断するための情報を提供します。詳細については、「パフォーマンスとスケーラビリティのカウンターとしきい値」(英語) を参照してください。
ストレージ ソリューションの稼働状態を監視する
多数のストレージ ソリューションには、パフォーマンスの指標を確認する方法があります。これらの指標を監視することによって、Exchange に影響が及ぶ前にパフォーマンスの問題を早期に把握できます。ストレージ ベンダーによる System Center Operations Manager 2007 の統合が利用可能な場合は、理解しやすい独自の指標の作成に役立つことがあります。監視する一般的な指標には以下のものがあります。
ディスク使用率 物理ディスクがどの程度ビジー状態になっているかを示します。
読み取りキャッシュのヒット率 記憶域コントローラーのキャッシュがどれだけ適切に使用されているかを示します。
書き込み保留中の要求 コントローラーがどのくらいの頻度で物理ディスクを待つかを示します。
記憶域プロセッサの使用率 記憶域コントローラー プロセッサがどの程度ビジー状態になっているかを示します。
© 2010 Microsoft Corporation.All rights reserved.