Exchange Server 2007に適したストレージ・システムの構成設計には，物理設計と論理設計の2つが必要だ。一般的には，キャパシティ（容量），パフォーマンス（性能），ランニング・コスト（初期導入コストや保守費用）を考慮して，ハードウエアを選択する。忘れてはならないのは，運用保守やセキュリティの考慮である。「障害は発生しない」と考えるのではなく，大小を問わず「障害は発生しうる」ものとして設計しよう。
物理設計：「SAN」にするか「DAS」にするか？
物理設計ではまず，SAN（Storage Area Network）に対応したハイエンド・ストレージを選択するか，DAS（Direct Attached Storage，ここではサーバーの内蔵ディスクやSCSIなどで接続する外付けディスクを指す）を選択するかを考慮する。
SANとDASのどちらを使用するかは，各組織のITインフラ戦略によるところが大きい。Exchange Server以外のアプリケーションとストレージ資源を共有したい場合は，SANの方が効率的である。またSANで利用する大型ストレージには，スナップショットといった高速バックアップ用の機能が搭載されている。ただし当然のことながら，SANストレージは初期導入コストや運用保守コストなどが高価である。できればDASと組み合わせて導入したい。
対障害性を高めるためには，ストレージ装置側で実現するハードウエア・レベルのデータ・レプリケーション，またはExchange Server 2007に内蔵されるようなアプリケーション・レベルでのデータ・レプリケーション機能を利用するのが望ましい。Exchange Server 2007には，「ローカル連続レプリケーション（LCR）」や「クラスタ連続レプリケーション（CCR）」といった，アプリケーション・レベルのレプリケーション機能が搭載されている。これらアプリケーション・レベルのデータ・レプリケーションは，安価に実装できる点と，短時間での障害復旧が可能になる点が特徴である。
なお，Exchange Server 2007では，iSCSI以外のNAS（Network Attached Storage）に対応していない。ストレージ・システムの選択肢としてSANとDASだけを挙げて，NASを挙げなかったのはこのためだ。
データベースとトランザクション・ログの保存先
物理設計で注意したいのは，データベースとトランザクション・ログの保存先を分けることだ。Exchange Server 2007のデータベースはランダムI/Oで読み書きを行うが，一方のトランザクション・ログはシーケンシャルI/Oで書き込みを行う。従って，データベースとトランザクション・ログのファイルを同一の物理ディスク上に置くことは，パフォーマンスを低下させるので，必ず避けたい。また，データベースとトランザクション・ログを異なる物理ディスク上に配置することで，耐障害性も高まる。
Exchange Server 2003以前のバージョンと同様に，Exchange Server 2007でも，データベース・ファイルの保存先ボリュームはRAID5（パリティ付きストライピング）で，トランザクション・ログ・ファイルの保存先ボリュームはRAID1（ミラーリング）で構成するのが一般的である。
また，データベースと同じLUN（論理ユニット）に配置する必要があるコンテンツのインデックスは，ランダムI/Oで読み書きが行われる。マイクロソフトは，「Exchange Serverはメッセージの到達時にインデックスを作成するので，ディスクへのI/Oにあまり影響を与えない」としている。しかし，電子メールのメッセージ量が増加した場合に，ストレージへの負荷がかかることが予測される。負荷に応じて必要な処理能力を備えたストレージ・システムを導入するか，ストア・データベース当たりのメール・ボックス数を減らすなどの検討が必要である。
OSのページング・ファイルについても考慮が必要だ。一般に，ページ・フォルトによるディスクへのアクセスが連続する場合，処理の遅延を招く。Exchange Serverのパフォーマンスを高めるためには，キュー・データベースやプロトコルのログ・ファイル，コンテンツの変換処理を行うフォルダなどは，ページング・ファイルが保存されるのとは異なるLUNに配置したい。
論理設計：使用可能なドライブ文字数に注意
Exchange Server 2007では，最大50個までのデータベースまたはストレージ・グループ（ストレージ・グループは複数のデータベースをグループ化したもので，複数のデータベースが1つのトランザクション・ログを共有する）を作成できる。そこで考慮しなければならない点は，使用可能なドライブ文字数である。
先に述べたように，データベースとトランザクション・ログは，別々の物理ディスクに置くことが望ましい。そうなると，データベースやストレージ・グループと，それらのトランザクション・ログごとに，1つのドライブが必要になり，ドライブ文字数が不足する可能性が出てくる。
ドライブ文字数が不足しそうな場合は，「ボリューム・マウント」機能を使用する。図3-1のように，Windows Server 2003では，NTFSのリパース・ポイント機能を利用して，任意のNTFSフォルダに別のドライブをマウントできる。図3-2では，「Second Storage Group」というドライブを，リパース・ポイントを利用して別ディスクに作成した例である。
 |
| 図3-1：NTFSのリパース・ポイントを作成した画面 [画像のクリックで拡大表示] |
 |
| 図3-2：リパース・ポイントを使って「Seconda Storage Group」というドライブを別のディスク上に作成した [画像のクリックで拡大表示] |
ストレージの容量とパフォーマンス
メール・ボックス・サーバーの容量を見積もる際には，パフォーマンスだけでなく，次回「（第4回）バックアップとリストアを考慮したExchangeサーバー設計（3月29日公開））」で述べるバックアップ設計も念頭において計算する必要がある。
まずパフォーマンスについては，マイクロソフトの技術資料「Optimizing Storage for Exchange Server 2003」で記載されているように，ディスク装置への読み書きの待機時間（Latency）が20ミリ秒を超えないように設計することが望ましい。これはExchange Server 2003向けの資料であるが， Exchange Server 2007の場合も同様である。
つまり，ディスク装置のパフォーマンスに合ったユーザー数を決定し，その上で，各メール・ボックスの容量を検討すれば，適切なサイジングが分かるはずである。しかし，このようなアプローチは現実的ではない。通常は，ユーザーのメール・ボックス容量に対する要件があってから，サイジングが図られるものである。つまり，各メール・ボックスの容量を決定した後に，サーバー当たりのユーザー数（メール・ボックス数）を決定するわけである。
ここで，注意すべき点をいくつか紹介しよう。SANストレージ・システムを使用する場合は，ディスク・グループの構成やLUNの割り当てがパフォーマンスに大きく影響する。特に，他のアプリケーション・サーバーとSANストレージ・システムを共有する場合は注意が必要である。この問題に関しては，各ストレージ・ベンダーの専門家に相談されることをお勧めしたい。
また，Exchange Server 2007は，Exchange 2000/2003と同様に，通常バックアップ（完全バックアップ）を実行すると，トランザクション・ログのファイルが削除される（図3-3）。
 |
| 図3-3：メール・ボックス・ストアのデータベースをバックアップする画面 [画像のクリックで拡大表示] |
また，Exchange 2000/2003と同様に，Exchange Server 2007では「循環ログ（古いトランザクション・ログから自動的に上書きする機能）」が無効に設定されている（図3-4）。よって，通常バックアップを取得するまで，トランザクション・ログが増え続けることになる（図3-5）。全体のストレージ容量を計算する際には，トランザクション・ログの増加量と通常バックアップのスケジュールを考慮する必要があるのだ。
 |
| 図3-4：循環ログの設定画面 |
 |
| 図3-5：ストレージ・グループ内のトランザクション・ログ・ファイル [画像のクリックで拡大表示] |
また，ローカル連続レプリケーション（LCR）やクラスタ連続レプリケーション（CCR）を使用する場合は，必要なストレージ容量が2倍になる。特に，LCRを有効にした場合は，循環ログを有効にできない仕様になっているので，バックアップ設計などと合わせて，全体のストレージ容量を決定していただきたい。
「削除済みアイテム」と「削除済みメール・ボックス」の保存期間
各ユーザーのメール・ボックス容量に基づいて，ストア・データベースのサイズを計算する際に忘れてはならないことは，「削除済みアイテム」と「削除済みメール・ボックス」の保存期間である。それぞれ，期間が長くなれば，それだけストア・データベースのサイズは大きくなる。既定の保存期間は，それぞれ14日と30日である。
ストレージ・グループとストア・データベース
パフォーマンスと可用性を追求するなら「分散」
ユーザーのメール・ボックスを配置する上で重要なことは，パフォーマンスと可用性の確保である。パフォーマンスを優先するならば，複数のLUNに対してそれぞれ異なるストレージ・グループを配置するのが望ましい。また，ユーザーのメール・ボックスを物理的に異なるストア・データベースに配置することは，可用性の向上にもつながる。局所的なストレージ障害が発生した場合でも，「部門内全員がメールを送れない」といった事態が起きるのを回避できるからだ。
ストレージの利用効率を上げるなら「集中」
一方で，ストレージ・システムの効率性を上げたいというニーズもあるだろう。そういう場合は，同じ配布グループに所属するユーザーのメール・ボックスを，なるべく同一のストア・データベースに配置するとよい。
Exchange Serverでは，同じストア・データベース内の複数のメール・ボックスに対してメッセージを送ると，ストア・データベース内に1つのメッセージとポインターが作成される。各メール・ボックスからは，そのポインターを通してメッセージを参照する仕組みである。これは，Exchange Server 4.0から実装されている「シングル・インスタンス・ストレージ」と呼ばれる機能で，ストレージの利用量を節約する利点を持つ。
なお，メール・ボックスを移動すると，シングル・インスタンス・ストレージが機能しなくなる場合がある。この問題の詳細については，マイクロソフトの技術情報「Exchange single-instance storage and its effect on stores when moving mailboxes」を参照していただきたい。
クラスタとストレージ・システム
Exchange Server 2007のクラスタでは，図3-6のように，ストレージ・グループごとにクラスタ・リソース（独立して起動または停止できる，クラスタの最小レベルの管理単位）が作成される。そのため，特定のストレージ・グループのリソースに障害が発生した場合でも，他のリソースへの影響を抑えられる。ストレージ・グループごとに障害範囲を局所化できるだけでなく，保守作業などにおいても，特定のストレージ・グループのリソースだけをオフラインにできる。
 |
| 図3-6：ストレージ・グループごとに作成されるクラスタ・リソース [画像のクリックで拡大表示] |
また，データベースの保守用領域を確保することも，重要な設計ポイントである。Exchange Server 2007でも，Exchange 2003/2000と同様に，データベース・ファイルの検証や変更，修復の際に，「Exchange Serverデータベース・ユーティリティ（Eseutil.exe）」を使用できる。
例えば，データベースをオフラインで最適化する場合には，新しく最適化されたデータベースのサイズの110％に相当する空きディスク容量が必要となる。そこで，万一に備えて，保守用に十分な領域を確保しておくことを強く推奨する。Eseutilに関する詳細は，マイクロソフトの技術資料「Eseutil」を参照していただきたい。
ハブ・トランスポート/エッジ・トランスポート・サーバー用のストレージ
ハブ・トランスポート・サーバーとエッジ・トランスポート・サーバーには，それぞれメッセージを一時的に保持するための「キュー・データベース」が存在する（図3-7）。キュー・データベースのファイルは，ディスクI/Oを分散させる目的で，システム・ファイルとは異なるLUNに移動できる。その場合は，Exchange Server 2007のプログラムをインストールしたディレクトリ（例：「C:\Program Files\Microsoft\Exchange Server\Bin」）にある「EdgeTransport.exe.config」というファイルに記載されている「QueueDatabasePath」と「QueueDatabaseLoggingPath」を変更する（図3-8）。
 |
| 図3-7：ハブ・トランスポート・サーバー上のキュー・データベース [画像のクリックで拡大表示] |
 |
| 図3-8：キュー・データベースとキュー・トランザクション・ログの場所の設定 [画像のクリックで拡大表示] |
詳細な手順は，Exchange Server 2007のヘルプ・ファイルにある「キュー・データベースの場所を変更する方法」を参照していただきたい。キュー・データベースのディレクトリは，「NETWORK SERVICE」に対して，「フル・コントロール」のアクセス許可が与えられていなければならない（図3-9）。場所を変更する場合は，移動先のディレクトリに必要なアクセス許可を必要がある。そうしなければ，「Microsoft Exchange Transport」サービスが正常に起動しないのでご注意いただきたい。
 |
| 図3-9：キュー・データベースが存在するディレクトリのセキュリティ設定 |
|
