web-dev-qa-db-ja.com

IOPSに基づくストレージ要件の基準は十分ですか?

問題の現在のシステムはSBS2003を実行しており、新しいハードウェアでSBS 2008に移行される予定です。現在、システム内のすべてのアレイで、1秒あたり平均200〜300のディスク転送が見られます。アクティビティの大部分を確認しているアレイは6ディスク7200RPMRAID 6であり、トラフィックが多い時間(アイドル時間は多くの場合10〜20%、応答時間はピーク時20〜50ミリ秒)の間、追いつくのに苦労します。いくつかの大まかな計算に基づいて、これは理にかなっています(70/30の読み取り/書き込み比率でこのアレイの平均〜245 IOPS)。

10Kディスクの単一のRAID10アレイを使用して、はるかに単純なディスク構成を使用することを検討しています。上記の計算に同じパラメーターを使用すると、583の平均ランダムIOPS /秒​​が得られます。

付与されたSBS2008は2003と同じ獣ではありませんが、ディスクパフォ​​ーマンスの点では似ていると仮定したいと思います(Exchange 2007はディスク上で簡単であり、ISAサーバー)。

提案されたシステムがパフォーマンスの点で十分であると信じているのは正しいですか、それとも何かが足りないのですか? Exchangeなどのさまざまな製品の推奨ディスク構成について多くのことを読みましたが、スピンドルをログ専用にするなどのことをよく言及しています。この背後にある理由は理解していますが、ランダムI/Oのオーバーヘッドが十分すぎる場合、それは本当に重要ですか?私は常に少なくともOS用に別々のスピンドルを持っていましたが、単一の優れたパフォーマンスのアレイがあれば、コストと複雑さを本当に減らすことができました。

皆さんに私の仕事をさせないために、この質問の一般的なバージョンは次のとおりです。新しいシステムの予測IOPS値がある場合、「ベストプラクティス」を無視して、この値だけを使用してストレージを指定するだけで十分です。 「構成? (同様のテクノロジーが与えられ、DASからSANなどに移行しない)

2
Boden

さまざまなスピンドルに関するベストプラクティスを無視しません。これが私の理由です。 OSの場合、OSを別のスピンドルに配置すると、I/Oパフォーマンスとは関係のないバックアップ、復元、およびアップグレードの点でメリットがあります。ログに関しては、Exchangeストアとログを異なるスピンドルに配置する理由は2つあります。 1つ目はバックアップです。バックアップが別々のスピンドルにある場合、両方を削除するにはさらに壊滅的なイベントが必要です。これは良いことです。 2番目はやや微妙です。 Exchangeは基本的に、ログファイルへの書き込みとデータストアへの書き込みを交互に行います(これは単純化しすぎていますが、今のところ十分です)。これら2つが同じスピンドル上にある場合、OSにそれらを交互に切り替えるように強制します。つまり、ディスクは時間のかかるシーク状態でより多くの時間を費やし、連続した読み取り/書き込み状態ではるかに少ない時間を費やします。基本的に、ディスクは実際に何かを行うのではなく、適切なセクターを見つけようとして動き回っています。これにより、ディスクの実際のパフォーマンスが大幅に低下する可能性があります。これは、デフラグを実行した後、ディスクのパフォーマンスが向上する理由でもあります。

3