キャパシティプランニングのための正確なトレンドのランダムI / Oパフォーマンス

私が働いている場所には、Xen Hypervisorを使用して多くの仮想マシンをホストするために使用される多数の「ビッグアイアン」サーバーがあります。これらは通常、32GB RAM、デュアルクアッドコアプロセス、および大量のI / O容量を持つ高速ディスクで構成されます。

私たちは、既存のハードウェア構成が歯の中で少し長くなりつつあり、外に出て、より大きく、より速く、より光沢のある新しいハードウェアを調達する時が来ました。

前述のように、既存のキットは32GB RAMで展開されており、ホストに展開できるVMの数を事実上制限しています。

ただし、新しいハードウェアの調査では、単一のシャーシ内に64、72、または96GBのRAMを搭載した単一のマシン内でより多くのRAMを取得できることは明らかです。明らかに、これにより、指定されたホストにより多くのマシンを追加することができ、常に勝ちです。これまでに完了した分析は、制限要因がディスクサブシステムにシフトされることを示唆しています。

問題は、現在、どこにいるかを把握しようとしていることです...使用法のおかげで、I / O帯域幅、つまり、ランダムなI / O操作は完了できます。このポイントに達すると、iowaitは空ロケットになり、マシンのパフォーマンス全体が犬に行きます。

これは私が尋ねている質問の核心です、特に完了しているランダムI / O操作の数に関連して、既存のI / Oパフォーマンスを正確に追跡/追跡する方法を知っている人はいますか？

私が実際にメトリックを取得しようとしているのは、「この構成はX個のランダムI / O要求を正常に処理でき、現在（平均して）Z個の操作のピークでY個の操作を実行しています」です。

前もって感謝します！

sarここでうまく機能します。トランザクション数と1秒あたりの読み取り/書き込みセクターを収集します。これを使用して、比較的適切な精度でIOワークロードをリプレイできます（読み取り/書き込み比率とトランザクションサイズの観点から） IOが「ランダム」であるかどうかを決定する要因）。それは完全ではありませんが、私の経験では、あなたが見ているような見積もりをするのに十分な仕事をします。

したがって、これは監視と容量レポートの問題のように見えます。トレンドの統計情報の測定を開始する場合は、全面的に調べて、比較、相関などを行えるようにします。

ツールに関しては、オープンソースの世界には神経節、ゼノス、ナジオなどがあり、他の多くのベンダー製品もあります。

関心のあるKPIを追跡、測定、保存するように設定し、定期的にレポートすることができます。

RAM使用量に関するクエリを考えると、メモリの統計情報、スワップの使用量、CPUも含めるのが理にかなっているので、それらを同じ期間全体にわたって比較し、どれが制限されているかなどを確認できます。

データをキャプチャしたら、レポート用にすべての素敵な大きなDBに保存できます。たとえば、履歴データを確認できます。5秒間ごとに6か月間、1分ごと、5時間ごと、1時間ごとに、さらに遡って保存します。そのようなことはスクリプト化でき、cron、autosysなどを介して実行できます。

これらのレポートは、経営陣が望むものを提供します-すなわち。きれいなグラフのあるもの。

また、日常の管理については、コンソールを介してチャート/図のリアルタイム情報を見て、特定の瞬間のパフォーマンスを確認できます。

collectlを使用するのは、必要なすべての情報を単一のファイルにプルし、必要に応じて統計を再生できるためです。これにより、記録間隔ごとのIOPSの数、コンテキストスイッチ、メモリ統計が表示されます。これをディスクごとに分類するか、システムを全体的に見ることができます。Collectlはlustreもサポートしています。

これは、システム全体のパフォーマンスの概要を把握するための優れたツールです。幸運なことに、SATAディスクは通常、ランダムアクセスを行う際に200〜300 IOPSを超えています。

他のすべてのメトリックと同じ方法で、ディスクI / Oを記録およびグラフ化します。

• データは、SNMPを使用してホストから取得されます。NAS / SANボックスはこれをネイティブに行います。すべてのLinuxホストでnet-snmpを使用し、USB-DISKIO-MIBからこの情報を提供します。

• データは（RRD形式で）保存され、Cactiを使用してグラフ化されます。一部のディスクIOテンプレートは、通常の現在、平均、ピークの形式で表示されるトランザクション数とサイズを提供します。

これらのメトリックは、必ずしもホストでiostat/ dstat/ を使用するほど有限ではありませんsar。しかし、それは火事であり、忘れてしまいます。新しいマシンが試運転されると自動的にセットアップされ、中央に保管され、将来の参照のために利用可能なままです。

このデータを使用して、運用上の異常な傾向を警告し、キャパシティプランニングを実行するときは常にそれを振り返ります。

私が実際にメトリックを取得しようとしているのは、「この構成はX個のランダムI / O要求を正常に処理できる[..]」です。

これにはいくつかの問題があります。

• ランダムI / OをシーケンシャルI / Oから分離して定量化することは非常に困難です。2つの基本的な違いは、ディスクプラッタに格納されているブロックの物理的な場所にあるためです。多くの小さなトランザクションがおそらくディスクに点在する小さなファイルに関連していることに基づいて、トランザクションのサイズから経験に基づいた推測を行うことができます。しかし、保証はありません。それは可能性がある単一のファイルから順に、少量のデータを読んだり、ディスク上のブロックに隣接します。

• メトリックを記録すると、現在のコミットメントが何であるか、時間の経過とともにどのように変化するか、したがって将来どのように変化するかを非常によく把握できます。天井が何であるかはわかりません。少なくとも手遅れになる前に。これを判断するには、いくつかの計算（ハードウェア仕様から）、ベンチマーク（私はbonnie++自分が好きです）を行う必要があり、それらのdomUが何をしているか、何に使用されているかについてのロジスティックな考えを持つことが役立ちます。

ストレージバックエンド（IBM SVC / DS8000）によっては、ランダムIOPSに関連する統計をそこから直接プルできる場合があります。

サーバーから統計をプルするには、nmonを使用できます。（ビールのように）無料です。もともとAIX向けにIBMによって開発され、Linux上でも動作します。

人々がSARを使用する場合、少なくとも数秒ごとにデータをサンプリングすることを願っています。collectlを使用すると、1秒に1回サンプリングします。ランダムI / Oでのパフォーマンスを測定する限り、Robin Millerのdt（google it）のようなツールを使用すると、ランダムI / OのLOTを簡単に生成し、collectlで測定して自分の人数を確認できます1秒ごとに実行できます。通常、通常のディスクは、ほとんど回転遅延に基づいて、最大200〜300 I / O /秒を実行します。ディスクが適切な位置にくるまで1/2回転待つと、ブロックサイズの影響は最小限に抑えられ、他のすべてが圧倒されます。

btw-iowaitは最も誤解されている測定値の1つです。CPUロードとは関係ありません。I/ Oが発生している間、CPUが他に何もしていなかったことを意味します。実際、100％のiowaitを使用している場合、基本的に約100％のアイドル状態になります。

-マーク