メールボックスの格納域の設計プロセス

[アーティクル]
03/03/2017

適用先: 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 の統合が利用可能な場合は、理解しやすい独自の指標の作成に役立つことがあります。監視する一般的な指標には以下のものがあります。

ディスク使用率 物理ディスクがどの程度ビジー状態になっているかを示します。
読み取りキャッシュのヒット率 記憶域コントローラーのキャッシュがどれだけ適切に使用されているかを示します。
書き込み保留中の要求 コントローラーがどのくらいの頻度で物理ディスクを待つかを示します。
記憶域プロセッサの使用率 記憶域コントローラープロセッサがどの程度ビジー状態になっているかを示します。