無料のMitrendサービスを使用したスト​​レージパフォーマンスのエクスプレス分析の例

パフォーマンスの問題の研究と解決策の検索は、多くの人がよく知っています。 I / O統計用の多数の視覚化および解析ツールがあります。 現在、インターネットサービスに基づくマイニングの自動化が勢いを増しています。

この投稿では、これらのサービスの1つ（Mitrend）に基づいて、ストレージパフォーマンスの問題を分析する例を共有し、それを解決する方法を提案したいと思います。 私の意見では、この例は興味深い研究であり、私の意見では、幅広いIT読者に役立つかもしれません。

そのため、顧客はEMCに、SANに展開されたVNX5500ハイブリッドストレージシステムのパフォーマンスを確認するように依頼しました。 VMwareサーバーは、インフラストラクチャタスクからファイルボールやデータベースサーバーに至るまで、すべてが回転するストレージシステムに接続されています。 この迅速な評価の理由は、VNXに接続されたサーバーに展開されたアプリケーションのフリーズに関する苦情でした。

前処理には、無料で利用可能なMitrendサービスを使用しました。
このサービスの詳細な説明はこの投稿の目的ではないため、すべての人にこのサービスの詳細を学んでもらいます。Web サイトにアクセスして、自分で確認してください。

Mitrendは、調査中のシステムからI / O統計を含む入力ファイルを受け取り、最も頻繁に要求されるパラメーターのグラフを作成し、予備分析を行います。その結果は後で使用されます。



このような分析の一例は、システムのさまざまなコンポーネントがさまざまな時点でどれだけ忙しいかを示すヒートマップです。 実際、これはシステムとそのコンポーネントの概略図であり、それぞれに負荷のグラフが構築されます。 それを一般的に見ると、潜在的に問題のある場所を見ることができます。 この場合、書き込みキャッシュが問題であることがわかります。 グラフは次のとおりです。



書き込みキャッシュの廃棄は高レベルで、通常の「腰痛」からレッドゾーン（90％を超える）が発生します。

これは、パフォーマンスの問題の典型的な症状です。 一種の「高温」。 この場合、このような状況につながるものを正確に調査し、解決策を概説する必要があります。

ディスク、プロセッサー、入出力ポート、ディスクバスはロードされません。 レコードキャッシュが「詰まっている」という事実の中で、これは少し奇妙です。







次に、ディスクをさらに詳しく見てみましょう。 わかりやすくするために、さまざまな種類のディスクをカラフルな線で囲み、以下の凡例に署名しました。 分析ファイル自体では、これは凡例なしで表示されます。



一般的なディスクシステムを詳しく見てみましょう。各200 GBの3つのフラッシュドライブのうち、2つは183 GBの有効容量でFAST Cacheに構成され、3つ目はホットスタンバイになります。 つまり ホットスタンバイを備えた非常に信頼性の高いミラーフラッシュキャッシュ。 その作業の有効性は、以下のグラフで見ることができます：



システムには、まったく使用されていない5つの900 GBのディスクがあります。 これらはシステムディスクであるため、パフォーマンスの問題を引き起こすという意見があるため、習慣から外さないようにしています。 このテーマに関する私の意見は、あなたが有意義にそれを行えば使用できるということです。 パフォーマンスの問題は通常、まったく異なる理由によります。

通常、異なるタイプのディスクがハイブリッドプールに結合されるため、システム自体がデータを配置するのに適した場所を決定します（FAST VPを使用）。 しかし、この場合、実装を実行する専門家は、この重要な問題について彼女を信頼せず、ドライブのタイプごとにデータを厳密に分割しました。 したがって、ディスクは2つの個別のグループ（プール0とプール1）に分割されます。これは、パフォーマンスの観点からディスクを分離し、重要でないアプリケーションが速度を必要とするアプリケーションに影響しないようにするためです。

プール0（RAID5）は、重要なアプリケーションサーバー用に設計されており、SAS 10kドライブで構成されています。

プール1（RAID6）-これらはユーザーの「ボール」であり、あらゆる種類の要求の厳しいパフォーマンス環境です。 NL SAS 7.2kドライブで構成されています。

ディスクグループの概要を調べると、プールグループ1でFAST Cacheが無効になっていることがわかります。



顧客との会話により、これはパフォーマンスが重要なプール0のリソースの優先度を上げることを目的として行われたことが明らかになりました。

これにも関わらず、ディスクがほとんどロードされていないプール0を使用しているアプリケーションから苦情が寄せられていることに注意してください。 さらに、このプールのすべての読み取り操作の80％およびすべての書き込み操作の91％がFAST Cacheによって処理されます。





つまり、FAST Cacheアプリケーションの驚くべき効果にもかかわらず、問題が発生しています。 なんで？ 先に進むために、LUNとそれらの間の負荷分散を見てみましょう。



最も負荷の高い3つのLUNは、RAID6の最も低速なNL-SASディスクに配置されていることがわかります。 それらについての苦情はありません。 ユーザーとの会話から、VNXに切り替えてからファイルサーバーがすぐに機能し始めたことに非常に満足していることがわかりました。

プール0のLUNについて苦情があります（上のグラフの緑）。 具体的には、以下の表にリストされている0から8までの番号を持つLUNについて説明しています。



ここで、LUNの使用率を見ると、プール0のLUNの使用率がかなり低いことがわかります。 下のグラフは、LUNの水平方向の番号を示しているため、どのLUNが「私たち」であるかを簡単に識別できます。 それらの中で最も「ロード」されているのは40％だけです。



システムは「平均的な善」で動作します。 10ミリ秒以内のボリュームの平均応答時間。 これは病院の平均気温です。

問題のあるLUNの負荷が低いという事実を背景に、問題は共通のリソースに対する競合であると結論付けることができます。



システムキャッシュの仕組みを見てみましょう。 キャッシュからの読み取りは非常に効率的です。



書き込みキャッシュの動作を分析すると、その負荷は60〜80％の指定フレーム内に維持され、最大90％以上の周期的なバーストが発生します。 これはあまり良くありません。



キャッシュを許容可能なレベルにクリアするために、システムが極端な手段に頼らなければならない頻度を見てみましょう。



これは、システムが記録のバーストを解決する時間がないことを意味します。 ただし、上限と下限をより快適なレベルに移動することにより、システム設定を変更できます。 たとえば、30〜50％。 しかし、これは患者の体温を下げることと同じです。 これを行うには、最初に診断と根本原因を作成する必要があります。 次に、プールを見て、強制的にキャッシュフラッシュが発生する原因を正確に理解してみましょう。



両方のディスクプールで、定期的な強制ドロップが発生することがわかります。 さらに、これがプール0（孤立したケース）で非常にまれに発生する場合、プール1ではこの状況は非常に困難です（1時間あたり数十および数百のイベント）。 しかし、私たちはまさにプール0に興味があります。すべてが順調ですよね。

私たちは解決策に近づきました。 ただし、先に進むために、VNXの書き込みキャッシュの完全性を管理するロジックを説明する必要があるため、余談です。 以下に説明します。


通常モードでは、システムは2つの境界-高水準点と低水準​​点の間のキャッシュを維持します。

下限は、それ以下の書き込みキャッシュがフラッシュされないしきい値です。キャッシュに含まれるデータは、読み取りまたは上書きが必要になる場合があるためです。 さらに、VNX書き込みキャッシュはその性質上、特定の数のデータブロックを保持します。それらは、物理ディスクへの書き込みのために、他の近くのブロックとの記録に結合できることを期待しています。 これにより、バックエンドの負荷が軽減されます。

上限は、ディスク上の書き込みキャッシュのフラッシュを有効にするためのしきい値です。 High Watermark Flushingモードがオンの場合、キャッシュからディスクへのデータは下位レベルにフラッシュされ、その後スタンバイモードに戻ります。

キャッシュを100％にしたくないのは、新しいエントリ用のスペースを提供できないためです。 したがって、上限を100％から安全な距離に維持しようとします。 通常、80％が正常です。 しかし、それは低くなる可能性があります。 それはすべて負荷の性質に依存します。

キャッシュが100％までいっぱいになった場合、High Watermarkフラッシュモードから、システムは強制キャッシュフラッシュまたは強制フラッシュを有効にします。

強制フラッシュモードは、ストレージへのすべての書き込み操作に大きな影響を与えます。 新しいデータはストレージシステムに追加の遅延で書き込まれます。 つまり ストレージシステムにデータブロックを書き込むには、最初にLRU（最長時間未使用）アルゴリズムなどを使用して、古いデータからスペースを解放する必要があります。

状況に戻りましょう。 明らかに、遅いプール1は書き込みキャッシュの点で弱点です。 RAID6の低速ディスクに到着したデータは、必要以上にキャッシュに残り、強制フラッシュでは、物理ディスクに切り替えるのに時間がかかりすぎます。

プール0はFAST Cacheを使用し、ほとんどの要求はフラッシュドライブから提供されることに注意してください。 強制フラッシュが到着するまで、フラッシュ応答時間は、データがNL-SASにフラッシュされる速さに依存し始めます。 弱いリンクが見つかったようです。 この結論が真実である限り、実際の仮説のテストは示すべきです。

それでは、「容疑者」のアリバイ-NL-SASディスク使用率の低下をどのように説明できますか？ 負荷値は時間間隔全体の平均であり、この場合は統計収集間隔が10分だったため、この時間中にデータ記録の短いバーストが発生し、アプリケーションの短い「フリーズ」が発生し、平均10分で負荷がそれほど大きくなかった可能性があります。 強制フラッシュが最も重要であることがわかったため、このディスクプールの「罪悪感」について疑いの余地はありません。

これについて何ができますか？

新しい世代のアーキテクチャを備えたシステムでの構成の古いアプローチが使用されるため、それ自体で行われた実装には計画エラーが含まれます。 顧客とのコミュニケーションは、問題が以前に採用された基準にあり、計画時に修正されていないことを明確にするのに役立ちました。 しかし、システムはすでに戦闘状態にあり、再構築できないため、アプリケーションの動作を中断させないために、オンライン再構成の分野で解決策を模索しています。

私は、個別にまたは一緒に、相互に補完することができる少なくとも3つの手段を見つけました。 実装の複雑さの程度でリストします。

1. ストレージシステムが定期的な負荷のバーストを解決するには、低/高ウォーターマークを30/50のレベルまで下げて、これらのバーストが正常に処理される方法を確認する必要があります。 理想的には、バースト中の書き込みキャッシュの充填が90％に達してはなりません。
2. プール1でFAST Cacheを有効にします。最も頻繁に更新されるデータは、低速ドライブからSSDに切り替わります。 SSDの書き込みキャッシュのフラッシュははるかに高速です。 これにより、強制フラッシュが発生する可能性が低くなります。
3. 無料のSAS 900GB 10kディスク（4個）にRAID10 RAIDグループを作成し、最も頻繁に更新されるLUNをプール1からそれらに転送します作成されたRAIDグループで、書き込みキャッシュをオフにします。

他の最適化方法もありますが、可能なアプローチの1つをよりコンパクトに示すために、この例を複雑にしないように具体的に試みました。

上記の変更はすべて元に戻すことができ、任意の順序で適用またはキャンセルできるため、これらの手段から始めることができます。

システムの動作をさらに研究する過程で、他の有用な結論を下すことができます。

あとがき

インテリジェントストレージシステムには、分析とパフォーマンスチューニングの両方のための豊富な組み込み機能があります。 ただし、詳細な手動分析とチューニングは、この投稿で表面的にのみ触れた非常に時間のかかるタスクです。 通常、管理者はストレージの操作とその最適化を完全に研究する時間はほとんどありません。 動的なワークロードとますます複雑になるITインフラストラクチャでは、新しいレベルの開発と自動化が必要です。

これらの問題を解決するために、あらゆるレベルでさまざまな技術が開発されています。

より便利で高速なパフォーマンス分析から、新しいインテリジェントで自己最適化システムまで。
以下に例を示します。

• 1. Mitrend-さまざまなメーカーのITインフラストラクチャの作業の自動分析。誰でも自由に利用できます
  2. SSDの自動階層型ストレージおよびキャッシュ： FAST VPおよびFAST Cache
  3.次世代システムには、各LUNのデータリセット速度のインテリジェントな自動調整を備えた適応VNX2キャッシュがあります（ ホワイトペーパー13ページを参照 ）。