PR

 マーク・トウェインはかつて「『正しい言葉』と『精密に正しい言葉』の違いは,『ホタル(lightning bug)』と『落雷(getting hit by lightning)』ぐらいに違う」と言った。それと同じ文脈で,私は前編の議論を続けたいと思う。

 その議論の中で私は,特定のアプリケーション向けにSANをうまく合わせる,あるいはひどく合わないものにするSANの特徴のいくつかについて書いた。Exchange Server向けのSANの構成の詳細をいくつか深く解説するとしよう。

SAN構成を決める3つの事項
 第1に,スピンドルについて話そう。Microsoftは長い間,トランザクション・ログとメールボックスのデータは,別々の物理ディスクを割り当てるという方法を推奨してきた。同社がExchange 2000 Serverを初めて出したときに,同社は推奨設定を拡大し,可能であれば各ストレージ・グループ内の各「.edb」ファイルと「.stm」ファイル用に個別の物理ディスクを割り当てることを含めた。この推奨設定は,SANの場合にもやはり当てはまる。Exchange専用の論理ボリュームに中にExchangeを構成することで,それに物理ディスクを専用に割り当てられれば,Exchangeの性能を上げられるだろう。あらゆるベンダーのサポート・エンジニア全員が,このアイデアに通じているわけではない。あなたの担当のエンジニアがディスク共有を提案してきたら,却下することだ。正しく言えば,ディスク共有が避けられないこともあることは確かにある。あいまいに性能が上がるというだけで,高価な追加ディスクのコストを正当化するのは難しいことがある。

 第2に検討することは,RAID(独立ディスク冗長アレイ)の構成だ。今SAN上にExchange用に2Tバイトのストレージが必要だとしよう。その容量を確保するにはいくつかの組み合わせがある。ここでは
(1)容量400Gバイトのハードディスク・ドライブ6台からなるRAID 5,
(2)250Gバイトのドライブが16台のRAID 1+0,
(3)146Gバイトのドライブが15台のRAID 0
――の構成があるとする。6ディスクのアレイは初期コストが一番低いように見えるが,スピンドル数が最少なので,恐らく性能も最低である。ドライブ数が他よりも少ないことから,耐障害回復性もいくらか劣るだろう。16ドライブと15ドライブのアレイは恐らく同程度のコストだが,性能面の特性は違う可能性がある。しかもそれはディスク数の違いによるものではなく,それぞれのRAIDタイプが最適化されているI/Oパターンの違いによるものだ。

 第3の検討事項は容量である。SANベンダーたちはよく性能値を引き合いに出す。ほんの少しだけ負荷をかけられたディスク上で性能をデモするために,Exchange Server 2003の「Jetstress」ツールを使う。少しの割合しかディスクを使わなければ,SANのコントローラとキャッシュ機構の差が有利に働く。つまり,あなたが物理ディスクいっぱいにデータを詰め込み,できるだけ少しずつ各物理ディスクを使うようにそれを動かさない限りは,実システムであなたのSANが本当にどうなるかは反映されないのだ。例えば,あなたの靴下をたんすの25個の引き出しに小分けにしまうようなもので,とても非現実的だ。もっとありそうなのは,長い時間がたって着実にあなたのディスクがいっぱいになり,何か性能テストをするならフルに近いディスク上で実施することだ。70~80%が埋まっていると理想的だろう。

SAN構成の決定は慎重に
 米Dellと米Hewlett-Packardの両社は,ストレージ容量の算出方法を提供している。それは,あるユーザー数をサポートするために,どのくらい多くのディスクが必要で,それをどう構成するべきかを見積もれるようにするものだ。あなたが自分の構成を計画する手始めとしてこれらの方法を使うことができる。

 しかし,ExchangeとSANの組み合わせに関する結論としては,先に私が上げた3つの要素を考慮しない限りは,あなたは特定の性能レベルを保証できない。少ないスピンドル数や,不適切なRAIDレベル,大容量データがロードされたディスク構成では,高性能というよりも,性能レベルが一定しない問題がある。初めからやればうまく避けられたはずの問題なのだが,それを直そうと追加投資する破目に陥る。