クラスタにサーバーを追加していて、iowaitが各サーバーで増加しているため、Netappが提供できるもののIO=制限に達している可能性があります。
しかし、これをどのように定量化しますか? Netapp CLIツールを使用して現在のIO=統計を表示するにはどうすればよいですか? "stats show"は認識していますが、 "io"オブジェクトなどは表示されません。Netappが何を想定しているのかを知る方法配信できるようにするには?
誰かが私よりもNetappの経験が豊富な場合は、助けをいただければ幸いです。
ありがとう!
これらは、NetAppファイラーのパフォーマンスを監視するためのいくつかのオプションです。 DataOntapのバージョンによって異なります。 sysconfigを実行すると、バージョンが表示されます。 OnCommand Performance Managerをクラスター化されたOntapのGUIツールとして使用できます。クラスター化されたOntapのもう1つのオプションは、パフォーマンスモニターとしてのQoSです。 7モードの場合は、systatまたはstatitコンソールコマンドを使用できます。
Netappサポートサイトの My AutoSupport の部分を確認してください。分析できるパフォーマンスデータと、いくつかのヘルスチェックがあります。
パフォーマンスの問題では、簡単な答えはありません。
IOPSのカウンターがあり、sysstat -x
で表示できます。
stats show system
は、NFS/FCP/CIFS opsなどのリストを提供します。
それだけでは、これらのことはかなり恣意的です-「数が多すぎる」IOPの数をどのようにして知ることができますか?
私が最も有用な指標を見つけるのは、一貫性のポイントを見ることです。もう一度、sysstat -x
に戻ります。ファイラーの書き込み方法IOそれらはNVRAMキャッシュを満たします。このキャッシュは定期的にフラッシュされ、データはバーストでディスクに書き込まれます。
発生した整合性ポイントのtypeは、システムが「満足」しているかどうかを示す良い指標です。 https://kb.netapp.com/support/index?page=content&id=3014024
T means your system is idle. (triggered by timer - not much happened for 10s, so it thought it better destage anyway)
S or Z is a 'forced' cp because of a snapshot/snapmirror op. (and usually isn't a problem)
F or H or L means your system is getting busy. (F is nvram filling with write data, H/L represent high and low watermarks for memory)
B or b means your system is struggling. (Back to back CPs, which means your hitting the limits of your ability to write to disk.
これは、ほぼ完全に書き込みについてですIOただし、システムが苦労する可能性があるもう1つの理由は、読み取りIOです。書き込みは簡単にキャッシュできます。読み取りはすぐにフェッチする必要があります。 。
統計表示カウンターはdisk_data_read
とdisk_data_written
を提供します。 sysstat -x
は、同じことと、ディスク使用率の概念を提供します。 (ただし、警告-その使用率は「クロスシステム」であるため、「コールド」なものと平均化された本当にホットなアグリゲートがある場合は表示されません)。
stats show volume
を実行して、ボリュームごとのIO=統計を取得することもできます。これにより、読み取り/書き込みの合計と、それらがどのボリュームに移動するかがわかります。 「読み取り」、「書き込み」、および「その他」を区別します。「その他」は非常に重要で、問題がある場合があります。
Netappは、パフォーマンスとI/Oの問題をトラブルシューティングするためにデータを収集できるperfstatと呼ばれるツールも提供しています。
さて、私はあなたがio-statsを実行してサーバー側で「iowait」を見て、この結論を「Netappは遅くなるかもしれない」と思いました。 Netappに目を向けると、理論を証明するためのすべてのものが見つかります。私は約束します。
Netappストレージからの情報が不足しているためではありません。しかし、探しているものがわからない場合は、問題のポイントに到達しません(ストレージに関連する問題/パフォーマンスの問題がある場合)。
そのため、別のアプローチをお勧めします。サーバーからストレージに目を向けます-I/Oフローをだましますまず、サーバーはどのように接続されていますか?ファイバーチャネルSAN?NFS/iSCSI(IPベース)?
「iowait」が表示される時間を確認してください。「iowait」はio-busyなしまたは少し表示されていますか?そして、低LUN使用率で? ->これはバックアップの実行に関連している可能性がありますか?
どのサーバーが接続されていますか?ほとんどのVMWare?
I/O特性(読み取り/書き込み)比率はどうですか?
整列されていないI/Oに問題がありますか?
I/Oキューはサーバー側でどのように構成されますか?
サーバーからストレージへと分析し、その逆は行わないでください。構成/ストレージトポロジの明確な図から開始します。これは、(ストレージ)の問題があるかどうか、およびそれがどこにあるかを確認するためのアイデアを提供するのにも役立ちます。
OnCommand Unified Managerに付属のPerformance Advisorツールが必要です。このソフトウェアはすべてのネットアップのお客様に無料です。コントローラ、アグリゲート、ボリューム、およびLUNレベルでIOPS情報を監視します。