状況を想像してください。データベースの新しいインスタンスまたは新しいバックアップタスク（RK）をデータベースサーバーに追加し、追加のサーバーをディスクアレイに接続しましたが、これらすべてのケースでパフォーマンスの低下が見つかりました。 さらに、さまざまな方法で行くことができます。
たとえば、データベースサーバーを追加してデータベースインスタンスを転送し、バックアップドライブを追加してRKを高速化し、プロセッサをアップグレードします。 ただし、ハードウェア容量の単純な増加は、材料と時間のコストの観点から最も利益が少ないことを覚えておく価値があります。 ITソリューションのロジックのレベルでこのような問題を解決する方がはるかに効率的です。
滑る理由
アレイのパフォーマンスの問題は、多くの場合、初期構成がそのアーキテクチャ、機能原理、および既存の制限を考慮していないという事実に関連しています。 たとえば、旧式のアレイのアキレス腱-内部バスのスループットが比較的低い-約200 Mb / s。 少し前まで、顧客の1人が、ディスクアレイの動作を分析し、最適化のための推奨事項を提示するように依頼しました。 実際、アレイはロードされませんでしたが、その速度は定期的に多くのことを望まれていました。 分析により、誤った構成が明らかになりました。一般に、日中、内部ディスクはほぼ同じようにロードされましたが、負荷のピークは不均等に分散されました。 その結果、内部タイヤの1つが過負荷になりました。 つまり、1つのコンポーネントの最大許容しきい値を超えたため、配列が「スキッド」しました。 インナータイヤに均等に負荷をかけるためにパーティションを再分割することで、生産性が30％向上しました。
このエラーは、サーバーをストレージシステムに接続するときに忍び寄ることもあります。 例は、ホストに提示される誤ったディスク容量構成です。 実際、最近のアレイの一部では、コマンドキュー（キューの深さ、QD）などのパラメーターに制限があります。 話をもう少し深くする価値があります。 SCSI-I規格では、SCSIサーバードライバーは1つのコマンドが実行されるのを待ってから、次のコマンドを送信する必要がありました。 SCSI-II標準以降では、SCSIドライバーは複数のコマンド（QD）をSCSIディスクに同時に送信できます。 並列サービスSCSIコマンドの最大数は、ディスクの最も重要な特性の1つです。 IOPS（1秒あたりの入出力操作）パラメーターは、SCSI LUNが実行できる1秒あたりの要求（SCSIコマンド）の数を示します。 QDとIOPSが互いに相容れない矛盾を起こす可能性があります。
サーバー側のI / O特性が受け入れられず、リクエストへの応答時間が非常に長く、アレイがロードされない状況は非常に現実的です。 その理由は、コマンドキューが誤って構成されている（許容されるものよりも高い）という事実にあります。実行の順番が近づくまで、コマンドは配列バッファーでハングします。 サーバーでは、長いサービス時間が登録されています。
QDが最適値を大幅に下回ると、パフォーマンスも低下します。 すばらしい応答時間とアンロードされた配列により、処理されるリクエストの数は非常に少なくなります。 この理由は、ストレージシステムにリクエストを送信する前にキューで長時間待機するためです。
IOPSをテールでキャッチ
応答時間がスケールから外れ、アレイがロードされない場合はどうすればよいですか？ または、配列からもう少し「絞り出す」だけの場合はどうでしょうか。
次のことができます。
- サーバーのキューの深さの設定を見て、最大許容コマンドキューとLUNアレイを比較します。 設定を調整します。
- 配列から統計を見てください。 LUNへのコマンドのキューが蓄積されている可能性があります。
- 1つのLUNを複数に分割し、構成に応じて、ストライプまたは少なくとも連結でホストに接続します。 連結は、負荷がすべてのLUNに分散される場合に役立ちます。
- アレイとホストのストライプユニットサイズを選択して、一般的なアプリケーション操作でアレイ内の物理ディスクのロードをできるだけ少なくします。
図 1.ストライプユニットサイズ
私たちの経験からの例：顧客でのサーバーとアレイの組み合わせは、宣言されたパフォーマンスレベルを示しませんでした。 分析の結果、サーバーに非常に大きな（数テラバイト）LUNが割り当てられていることが判明しました。アプリケーションは満足のいくものではなく、LUN自体が順番に過負荷になりました。 このLUNをいくつかに分割し、さまざまなボリュームに負荷の種類を分散することをお勧めします。 サーバー上には4つのインスタンスデータベースがあり、その結果、そのうちの1つは6倍速く、他の2つは速く動作し始めました。
多ければ多いほど良いというわけではありません
顧客企業のITスペシャリストは、特定のアプリケーション負荷プロファイルに最適なRAIDのタイプを常に理解しているわけではありません。 RAID 10は信頼性が高く、複数のディスクの損失に対して耐性があり、ランダム操作で優れた速度を示すことは誰もが知っています。 ほとんどの場合、この特定の非常に高価なオプションが選択されることは驚くことではありません。 ただし、アプリケーションの負荷プロファイルでランダム書き込み操作が少なく、読み取りまたは順次書き込み操作が多い場合は、RAID 5を使用することをお勧めします。同数のディスクで1.5または2倍高速に実行できます。 ある会社は、そのアプリケーションの1つのディスクI / Oパフォーマンスを改善するように依頼しました。 アプリケーションは、多くの読み取り操作と少数の書き込み操作を作成しました。 RAID 10はアレイ上で構成され、統計により、RAIDグループ内のディスクのほぼ半分がアイドル状態であることが示されました。 まったく同じ数の物理ディスクからRAID 5への移行により、アプリケーションの作業は1.5倍以上改善されます。
建設的なコメントを歓迎します。
パフォーマンスの問題は、コンピューティングコンプレックスを運営するほぼすべての企業に影響します。 ここに挙げた例は、唯一のものではありません。 アレイの不満足な操作に関連する多くの問題は、機器を構成するときにそのアーキテクチャとアプリケーションの負荷プロファイルを考慮することで回避できます。 同時に、コンピューティングコンプレックスの改善は、そのコンポーネント（サーバー、アレイ、ソフトウェア、またはデータ伝送ネットワーク）のいずれかに限定されるべきではありません。 複合体全体を全体として分析し、アレイだけでなくサーバーとアプリケーションの構成を変更した後に、最良の結果を得ることができます。