カーテンの後ろのそのSANに注意を払わない

むかしむかし、私は独自のSQLサーバーを構築し、ドライブ構成、RAIDレベルなどを制御していました。データ、ログ、tempdb、バックアップの分離（予算次第！）の伝統的なアドバイスは常に非常に重要な部分でしたSQLサーバーの設計プロセス。

現在、エンタープライズレベルのSANを使用して、データ、バックアップ、およびファイル共有用の論理ドライブに分割された、新しいSQLサーバー用の特定の量のドライブスペースを要求しています。確かに仕事が楽になりますが、「カーテンの後ろ」で実際に何が起こっているのかを実際に覗くことができないので、完全に快適に感じられない部分があります。

私の理解では、SANチームは異なる「タイプ」のドライブを異なるように構成することはありません（ランダムアクセス用のデータドライブとストリーミング書き込み用のログドライブの最適化）。この一部はSAN製品自体に依存する場合があります（HP XP12000およびHP XP24000があります）が、HPソフトウェアがあらゆる種類の動的パフォーマンス構成（IOホットスポットを監視し、その場で再構成する）アプリチームとDBAがそのようなことを心配する必要がないように、それらのLUNを最適化します）。「膨大な数のスピンドルにすべてのサーバーの負荷を分散させる」などの何か。

私の質問/議論：

1. SANチームに敵を立てずに、SQLサーバーが不適切に構成されたストレージに苦しんでいないことを自分とアプリケーション開発者に安心させるにはどうすればよいですか？perfmon統計を使用するだけですか？sqlioのような他のベンチマーク？

2. これらのSANドライブにテストをロードすると、実際に稼働するときに表示されるものの信頼できる反復可能な測定値が本当に得られますか？（SANソフトウェアが異なる時点で異なる「動的に構成」する可能性があると仮定します。）

3. SANの一部（Exchangeサーバーなど）のヘビーIOは、SQLサーバーに影響しますか？（各サーバーに専用ディスクを提供していないと仮定しますが、そうではないと言われています）

4. さまざまな機能の論理ドライブ（データvsログvs tempdb）に論理ドライブを分離することは、ここで役立ちますか SAN はこれらの異なるIOアクティビティを認識し、それらを異なる方法で最適に構成しますか？

5. 私たちは今、ちょっとしたスペースクランチをしています。アプリケーションチームは、データアーカイブなどをトリミングするように言われます。スペースの問題により、SANチームは、サーバーのパフォーマンスに影響を与える可能性のある内部ストレージ（RAIDレベルなど）の構成方法について異なる決定を下しますか？

ご意見をお寄せいただきありがとうございます（このSFの質問で簡単に説明した類似のトピック）

SANチームに敵を立てずに、SQLサーバーが不適切に構成されたストレージに苦しんでいないことを自分とアプリケーション開発者に安心させるにはどうすればよいですか？perfmon統計を使用するだけですか？sqlioのような他のベンチマーク？

要するに、おそらく本当に確実な方法はないでしょう。私が言いたいのは（私はSAN管理者です）、アプリケーションが期待通りに機能していれば心配しないでください。SAN / Disk IOのパフォーマンスに関連すると思われるパフォーマンスの問題が見られるようになった場合は、問い合わせるのが賢明かもしれません。私はあなたのように多くのHPストレージを使用しませんが、IBM / NetAppの世界では、「貧弱な」構成を可能にする多くのオプションはないという経験から言えます。最近のエンタープライズストレージのほとんどは、RAIDアレイの構築から多くの当て推量を取り除いており、実際にそれを間違えることはありません。同じRAIDグループ内でドライブの速度と容量が混在していない限り、ほとんどの場合、ディスクが正常に動作していることを安心できます。

これらのSANドライブにテストをロードすると、実際に稼働するときに表示されるものの信頼できる反復可能な測定値が本当に得られますか？（SANソフトウェアが異なる時点で異なる「動的に構成」する可能性があると仮定します。）

負荷テストには十分な信頼性が必要です。1つのボックスの負荷テストを行うとき、そのパフォーマンスは同じストレージを使用する他のシステムによって影響される可能性がある（そして影響を受ける）共有SAN /ディスクアレイ上にあることに注意してください。

SANの一部（Exchangeサーバーなど）のヘビーIOは、SQLサーバーに影響しますか？（各サーバーに専用ディスクを提供していないと仮定しますが、そうではないと言われています）

できる。それは、すべてのディスク、またはサーバーがどのディスク上にあるかに関するものではありません。すべてのデータは、ディスクコントローラーを介して提供され、次にSANスイッチを介して提供されます。表示されるパフォーマンスは、ディスクコントローラーの接続方法、および対応するディスクシェルフ、および対応するSANに大きく依存します。アレイ全体が4gbpsファイバーの単一ストランドでバックボーンSANに接続する場合、明らかにパフォーマンスに影響があります。トランクリンクを使用して負荷分散された2つの冗長SANにアレイが接続されている場合、交換だけでは帯域幅を使い果たすことはできません。考慮する必要があるもう1つのことは、アレイが可能なIO /秒の数です。接続されているアレイとSANが正しくスケーリングされている限り、

さまざまな機能の論理ドライブ（データvsログvs tempdb）に論理ドライブを分離することは、ここで役立ちますか SANはこれらの異なるIOアクティビティを認識し、それらを異なる方法で最適に構成しますか？

これはおそらく好みの問題であり、ストレージ管理者がどのように構成するかに大きく依存します。同じアレイまたはボリューム内の3つのLUNを提供できますが、その場合はいずれにしても同じです。異なるアレイ、異なるボリューム（物理的に異なるディスク）の個々のLUNを提供した場合、それらを分離する価値があるかもしれません。

私たちは今、ちょっとしたスペースクランチをしています。アプリケーションチームは、データアーカイブなどをトリミングするように言われます。スペースの問題により、SANチームは、サーバーのパフォーマンスに影響を与える可能性のある内部ストレージ（RAIDレベルなど）の構成方法について異なる決定を下しますか？

ストレージ管理者が空き容量を増やすためにRAIDレベルを変更するとは思わない。もしそうなら、彼はおそらく解雇されるべきです。スペースの問題により、構成が異なる場合がありますが、通常はパフォーマンスに影響する方法ではありません。どれだけのスペースを確保できるかについて、もう少しきつくなるかもしれません。これらは、プロセスの実行中にアレイのパフォーマンスを妨げる可能性のあるデータ重複除外（アレイがサポートしている場合）などの機能を有効にしますが、24時間ではありません。

SANチームには、アプリがホットスポットであるかどうかを明らかにするのに役立つツールが必要です。明らかに、あなたも自分の側で監視し、測定する必要があります。

私の経験のほとんどはEMCですのでYMMVです。ただし、ほとんどのSAN機器には以下が適用されます。

アレイに入るポートは非​​常に多くあります。ゾーンを定義できる間にSANスイッチが存在する場合があります。アレイが本質的に大きなストレージプールであるからといって、IOパフォーマンスを心配する必要はありません。

したがって、IOの問題が発生していると感じた場合は、ボトルネックのある場所を絞り込む必要があります。HBAとアレイの間のどこかにある場合、HBAが最大になっているか、またはスイッチ/アレイ側のSANポートがオーバーサブスクライブされているかを把握できます。さらに、コールドスタートとホットランニングの両方から、SANチームにアプリのアクセスパターンを監視させる必要があります。

明らかに、基礎となるストレージは、キャッシュのレベルに関係なく、ある時点でディスクをヒットしなければならないため、低速の大きなRAID5と高速のRAID10の実行に違いをもたらします。

HTH。特定の問題がある場合、掘り下げるのに時間がかかる可能性があるため、オフラインでpingを実行できます。

SANチームに敵を立てずに、SQLサーバーが不適切に構成されたストレージに苦しんでいないことを自分とアプリケーション開発者に安心させるにはどうすればよいですか？perfmon統計を使用するだけですか？sqlioのような他のベンチマーク？

何らかのベンチマークを行う前に知っておくべき最初のことは、自分のワークロードを実行するために必要な許容範囲です。したがって、新しいシステムをチェックアウトする前に、自分のものをベンチマークしてください。こうすると、ピーク負荷（バックアップ？）中に最大56MB / sをプッシュしていることがわかった場合、SANに接続されたディスクアレイがシミュレートされたピーク負荷の下で110MB / sだけをプッシュすることがわかります。制限はI / Oチャネルにはならないことを保証します。

新しいディスクアレイをチェックアウトするとき、この種のパフォーマンステストを行いました。新しいアレイでは、ファイバーチャネル（SCSI）ドライブの代わりにSATAドライブが使用されたため、環境で動作することを確認する必要がありました。私は深く疑っていました。しかし、特徴付けを行った後、新しいシステムにはピーク時のI / Oオーバーヘッドが十分にあり、より信頼性の高いディスクで測定されたピークに対応できることがわかりました。びっくりしました。

これらのSANドライブにテストをロードすると、実際に稼働するときに表示されるものの信頼できる反復可能な測定値が本当に得られますか？（SANソフトウェアが異なる時点で異なる「動的に構成」する可能性があると仮定します。）

SAN接続のディスクアレイは共有されているため、パフォーマンスは1週間にわたって変動します。ピークI / O負荷がいつであるかがすでにわかっている場合は、ピークI / O負荷が発生する時間帯に一連の負荷テストを実行します。そうすることで、最も関心のある期間にどのようなI / Oオーバーヘッドが利用可能かをよりよく特徴付けることができます。ピーク時以外の負荷テストでは、「スナッピー」なものがどのようになるかを感じ取ることができます。真の境界チェックを提供します。

SANの一部（Exchangeサーバーなど）のヘビーIOは、SQLサーバーに影響しますか？（各サーバーに専用ディスクを提供していないと仮定しますが、そうではないと言われています）

Exchange LUNがSQL LUNとディスクを共有する場合、それらは完全に共有されます。XPではなくHP EVAを使用していますが、同じ「ディスクグループ」の用語を使用していると思います。同じディスクグループ内のLUNはディスクを共有するため、それらの物理デバイス上のI / Oを争います。ディスクグループに入れるディスクが多いほど、アレイがI / Oをジャグリングするために必要な余地が増えます。アレイ（少なくともEVAがこれを行い、より高価なXPも同じことを行うと推測します）は、論理LUNブロックを物理ディスク全体に非順次的に分散します。これにより、提案されていることを実行できます。これは、頻繁にアクセスされるブロックのグループを異なる物理デバイスに動的に分散して、並列性を高め、ディスクレベルでのI / O競合を減らします。

質問は、そのディスクグループが持っているI / Oバジェットの量と、それらのLUNを使用するアプリケーションがI / Oに対してオーバーサブスクライブされているかどうかです。これは、ストレージ管理者が追跡しなければならない質問です。ExchangeのピークI / O（おそらくバックアップ中）がSQLの負荷と一致せず、両方のシステムが共存できる可能性があります。

さまざまな機能の論理ドライブ（データvsログvs tempdb）に論理ドライブを分離することは、ここで役立ちますか SANはこれらの異なるIOアクティビティを認識し、それらを異なる方法で最適に構成しますか？

HPアレイの場合、異なるI / OパターンをLUNではなく異なるディスクグループに配置する必要があります。たとえば、データベースI / Oパターンは、Webサービスアクセスパターンと共存しないでください。異なるディスクグループ内にない限り、異なるLUNがパフォーマンスを著しく向上させることはありません。それらが同じディスクグループにある場合、唯一の本当の利点はオペレーティングシステムにあります。オペレーティングシステムはカーネルでI / Oスケジューリングを行い、ディスクサブシステムへの並列性を改善できます。とはいえ...

私の理解では、HPアレイはLUNのさまざまなアクセスパターンを認識していますが、実際の論理ブロックには細心の注意を払っています。ログを別のLUNに配置すると、その種のI / Oトラフィックを取得する論理ブロックに制限が課され、物理ディスク上の論理ブロックを正しくソートするタスクが容易になります。

私たちは今、ちょっとしたスペースクランチをしています。アプリケーションチームは、データアーカイブなどをトリミングするように言われます。スペースの問題により、SANチームは、サーバーのパフォーマンスに影響を与える可能性のある内部ストレージ（RAIDレベルなど）の構成方法について異なる決定を下しますか？

間違いなく。スペースが限られている場合、I / O専用のディスクグループを取得しません（ストレージ環境が7TBの物理ディスクを排他的に使用するのに十分な大きさでない限り、その時点でそうなる可能性があります） ）。Raid5 / Raid10の議論は、組織のポリシーに大きく依存しており、質問が最善の策です。

SANチームおよびベンダーとのダイアログを開いて、懸念に対処することをお勧めします。独自のベンチマークを実行する際に発生する問題の1つは、テストが実稼働環境、特にピーク時の負荷に影響を与えない可能性があることです。ほとんどのSANには大量のバッテリーバックアップキャッシュがあります。これは、多くの場合（特に合成ベンチマークを実行する場合）、RAMに書き込み、パフォーマンスが非常に高いことを意味します。

ご使用の環境と使用しているソリューションによっては、一部のベンダーCEが、彼が好む標準に合わせてSANを設定している場合があります。それはあなたが思っている以上に起こります。ソリューションが要件を満たしていると確信できるまでは、「SANチームがすべてを知っている」シェルを削ぎ落とす必要があります。

がんばろう。

私はかつてこのトピックに関する講演でオラクル会議に出席しました-データベースのための健全なSAN。

講演の要点は、このPDFファイルまたは著者のサイトで入手できます。