報告された LUN レイテンシがボリュームレイテンシよりも高いのはなぜですか?
環境
- ONTAP 9
- R2T(転送準備完了)
- XFER_RDY(転送準備完了)
回答
多くの場合、iSCSI(およびFCP)で測定されるレイテンシは基盤となるボリュームのレイテンシよりも大幅に高く、ボリュームレベルでの処理数は含まれるLUNで測定されるレイテンシよりも高くなります。
注: ボリュームレイテンシ(WAFLレイテンシ)はLUNレイテンシの一部にすぎないため、LUNレイテンシよりもボリュームレイテンシが低いと想定される動作です。この記事では、LUNレイテンシがボリュームレイテンシよりも大幅に高いシナリオに焦点を当てて説明します。
例:
- 読み取りが256KBのクライアントについて、ボリュームレイヤとLUNレイヤでの処理とレイテンシの比較
- iSCSIプロトコルを例に挙げますが、環境FCPも同じです。
LUNレイテンシ
cluster1::*> statistics show -object lun -instance /vol/vol_linux/lun1 -counter read_data|avg_read_latency|read_ops -raw Object: lun Instance: /vol/vol_linux/lun1 Start-time: 10/26/2020 00:55:36 End-time: 10/26/2020 00:55:36 Scope: svm_linux Counter Value -------------------------------- -------------------------------- avg_read_latency 215ms read_data 85.25MB read_ops 333
ボリュームレイテンシ
cluster1::*> statistics show -object volume -instance vol_linux -counter iscsi_read_data|iscsi_read_latency|iscsi_read_ops -raw Object: volume Instance: vol_linux Start-time: 10/26/2020 01:00:10 End-time: 10/26/2020 01:00:10 Scope: svm_linux Counter Value -------------------------------- -------------------------------- iscsi_read_data 85.25MB iscsi_read_latency 50034us iscsi_read_ops 1332
注: LUN処理サイズは256KBであり、ボリューム処理サイズは64KBであるため、ボリューム処理はLUN処理の4倍です。
- レイテンシが大きく異なる主な理由は、WAFLとボリュームレイヤで処理サイズが64KBに制限されることです。
- クライアントが64KBを超えるペイロードを使用して処理を送信する必要がある場合は、そのペイロードを複数のボリューム処理に分割する必要があります。
- このWAFLサイズ制限により、iSCSIセッションまたはFCPログインごとに設定がネゴシエートされ、1つのPDU(プロトコルデータユニット)で送信できるデータ量が指定されます。
- つまり、ボリュームレイテンシは単一の64KB PDUを処理するのにかかる時間を表しているだけですが、LUNレイテンシは複数の64KB PDUの合計処理時間を測定している可能性があります。
- LUNレイテンシ(iSCSI遅延またはFCP遅延)は、コマンドの最初のPDUを完全に受信してから、応答の最後のPDUがONTAPの出力キューに送信されるまで測定されます。
ONTAP 9
-
ONTAP 9では、このシリアル化された読み取りと書き込みの処理方法が最適化されています。
- 最大16個の64KBの並列PDUを同時に処理できるため、ほとんどの場合、LUNのレイテンシがネットワークラウンドトリップの影響を受けないようにする必要があります。
- 並行して実行することもできますが、同じ256KB iSCSI書き込みの場合、必ずしもすべてのPDUが常に並行して実行されるわけではありません。例:
- LUNレイテンシの最小値は、64KBのPDU処理時間(ボリュームレイテンシ)に相当します。
- LUNレイテンシの最大値は、 4×64KB PDU処理時間(ボリュームレイテンシ)+ 3ネットワークラウンドトリップの合計です。
- LUNレイテンシは 最小値 と 最大値の間に収まります。
- 一部の古いバージョンのONTAP 9では、SAN書き込みを並行して実行できない
- 並行して実行することもできますが、同じ256KB iSCSI書き込みの場合、必ずしもすべてのPDUが常に並行して実行されるわけではありません。例:
- 最大16個の64KBの並列PDUを同時に処理できるため、ほとんどの場合、LUNのレイテンシがネットワークラウンドトリップの影響を受けないようにする必要があります。
これらすべてを念頭に置いて、ONTAP 9では、LUNのレイテンシがLUNのレイテンシよりも大幅に高い2つの主なシナリオが考えられます。
- PDUが並行して実行されない
- ボリュームのレイテンシが低いかぎり、原因によるパフォーマンスへの影響はありません。
- ネットワークまたはクライアントが低速であるため、R2T/XFER_RDYが認識され、次のPDUが到着するまでに長い時間がかかる
- これにより、ボリュームのレイテンシが低い場合でも原因がパフォーマンスに影響します
注 :どちらのシナリオでも、ボリュームのレイテンシがまだ低いかぎり、ストレージパフォーマンス問題とはみなさないでください。
これら2つのシナリオを区別するにはどうすればよいですか?
qos statistics workload/volume latency show
次の2つのシナリオを区別するために使用できます。
例:
cluster1::*> qos statistics workload latency show -workload vol_linux-wid22068 Workload ID Latency Network Cluster Data Disk QoS NVRAM Cloud --------------- ------ ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- Vol_linux-wid22068 - 210ms 8ms 1ms 181ms 18ms 0ms 2ms 0ms
- PDUが並行して実行されない
- レイテンシがそれほど大きくないのは、
Network
- レイテンシがそれほど大きくないのは、
- ネットワークまたはクライアントが低速であるため、R2T/XFER_RDYが認識され、次のPDUが到着するまでに長い時間がかかる
- 高レイテンシの大部分は
Network
- 高レイテンシの大部分は
注:
- QoSレイテンシの内訳では、
Network
ネットワークやクライアントなどの外部コンポーネントによって生じるレイテンシを表します。 - からの高レイテンシがないかぎり
Network
、基盤となるボリュームのレイテンシよりも大幅に高くても、LUNレイテンシを考慮する必要はありません。
高いLUNレイテンシに対処するにはどうすればよいですか?