あなたがまともな場合 NetAppの監視、もちろん、重要なことを監視する必要があります。（ほとんどのアプリケーションでは）ボリューム（またはLUN）での要求の待機時間です。
簡単に入手できます– LogicMonitorを使用すると、ボリュームごとにグラフ化され、自動的にアラートが表示されます。 しかしもちろん、問題があると、焦点は次のように変わります。 なぜ 待ち時間があります。 通常、これは、IOバウンドであるアグリゲート内のディスクの制限です。 再割り当ての必要がないと仮定すると（ディスクは均等にロードされます-それを決定する方法については別の記事を書きます）、どのレベルのディスクビジーネスが許容できるかをどのように判断できますか？ 以下のようなパフォーマンスを視覚化することが、この投稿の目的です。
ディスクの定格は250IOpsですが、それは、そのレベルより前に遅延が影響を受けないという意味ではありません。 ディスクが100％ビジーに近づくと、各リクエストのレイテンシーが増加します。 （これは理にかなっています-ディスクをビジー状態に保つ唯一の方法は、作業をキューに入れて待機させることです-もちろん、これらの要求の応答時間は長くなります。）
環境内のワークロードに応じてレイテンシがどのように増加するかをプロットすることは良いことです。
これを実行する方法の簡単な例：
レイテンシーが本当に問題であるかどうかを確認します（問題ではない場合、多くの場合、ストレージのパフォーマンスを非難します）。
この場合、このボリュームでは明らかにパフォーマンスが低下している期間が発生しています。
ここでの実際のトラブルシューティングの次のステップは、ディスクのバランスが取れているかどうか、またはアグリゲートに再割り当てが必要かどうかを確認することです。 ディスクのバランスが取れていると仮定すると、集約内の任意のディスク（パリティディスクを除く）を代表として使用できます。
この集合体のディスクを見ると、ビジー状態のディスクがありますが、100％ビジー状態ではありません。
また、ディスクのビジー状態を追跡するXNUMX秒あたりの操作数も確認できます。
したがって、上記のグラフを見ると、ディスクのビジー状態が遅延を追跡していることがわかりますが、それをより明確に把握できれば便利です。
したがって、これはLogicMonitorが直接（まだ）実行できないことですが、そこに到達するための支援を得ることができます。 ボリュームの合計レイテンシーと、同じアグリゲート上の非パリティディスクのディスク操作の両方を示すダッシュボードカスタムグラフを作成する必要があります。これは次のように定義されます。
次に、次のようなグラフが作成されます。
これを散布図に変換するには、虫眼鏡をクリックしてSmartGraphを表示し、データを（便利な[ダウンロード]ボタンを使用して）csv形式でダウンロードします。
ExcelまたはOpenOfficeでデータを開きます。 IOpsで並べ替えます。 データ範囲としてXNUMXつの列IOpsとLatencyを使用して、タイプScatterplotのグラフを追加します。 最初の行はラベルですが、最初の列はラベルではありません。 いくつかの軸のタイトルを付けてください。次のような素敵なプロットで終了する必要があります。
したがって、このNetAppでは、このワークロードを使用すると、パフォーマンスは100秒あたり約50 IOpsまで良好であり、その時点で遅延が大幅に変動することがわかります。 したがって、パフォーマンスが重要な場合は、各スピンドルのビジー状態をXNUMX％未満に抑えてください。 このパフォーマンスプロファイルはワークロードに固有であることに注意してください–読み取りと書き込みの比率。 転送のサイズなど
では、分析を行って、レイテンシに悪影響を与えるIOpsの範囲でディスク使用率が見られる場合はどうでしょうか。 ネットアップにストレージを備えたVMwareまたはその他の仮想化システムを実行している場合は、VMのゲストファイルシステムをネットアップの予想される4Kブロックに合わせていることを確認してください。
それ以外の場合は、ワークロードを移動する必要があります–ボリュームを他のアグリゲートまたはファイラーに転送します。 または、アグリゲートに物理ディスクを追加します。 しかし、あなたの決定を裏付けるデータを持つことは常に良いことです。