ポーズフレームがネットワーク接続に与える影響は何ですか?
環境
ONTAP 9
回答
イーサネットフロー制御の目的:
イーサネットフロー制御は、パフォーマンスのボトルネックが発生しているネットワークデバイスが、隣接デバイスの送信停止を要求するメカニズムです。
- イーサネットフロー制御は、通常「ポーズ」フレームと呼ばれるイーサネットパケットのタイプを定義します。
- 交換できるのは直接接続されたデバイス間だけで、イーサネット( DataLink )レイヤでのみ定義されます。
- したがって、イーサネットポーズフレームは関連付けられず、 IP 、 TCP 、 NFS 、 CIFS 、またはその他の上位レベルのプロトコルに関連付けることはできません。
イーサネットフロー制御を使用しない場合、受信デバイスが送信デバイスの送信速度に合わせて情報を処理できない場合は、最終的に受信データの破棄を開始する必要があります。
- これにより、送信側クライアントは再送信を必要とし、原因 が面倒な遅延を招く原因がいくつかあります。
イーサネットフロー制御を使用すると、受信者は送信デバイスの「一時停止」を短時間要求し、これらの廃棄を回避することができます。
- 場合によっては、これによりネットワーク転送の効率が向上することもあります。
- ただし、イーサネットフロー制御は、パフォーマンス上の問題を回避するために必ずしも効果的ではありません。
- 特定の状況(通常はまれ)では、イーサネットフロー制御は、防止するように設計された再送信によって発生したパフォーマンスの影響よりも原因 のパフォーマンスに大きく影響します。
注:イーサネットフロー制御は、 1 Gbps 以上の機器で一般的に使用されます。また、イーサネットフロー制御仕様がサポートされていない場合でも、より最新の 100 Mbps 機器に搭載されていることがあります。
例:
- ストレージコントローラ、スイッチ、およびクライアント・マシンを備えた基本的なネットワークを構築しているとします。
- さらに、ストレージコントローラがイーサネットフロー制御パケットを送信するように設定され、スイッチがストレージコントローラが接続されたインターフェイスでイーサネットフロー制御パケットを受信(リスン)するように設定されているとします。
- 最後に、クライアントがイーサネットフロー制御をサポートするように設定されていないとします。
- スイッチには、各インターフェイスのイーサネットフロー制御が設定されていることに注意してください(ストレージコントローラが接続されているインターフェイスの設定、クライアントが接続されているインターフェイスの設定が異なる可能性があります)。
トラフィックの停止 / 一時停止:
- このシナリオでは、ストレージコントローラからスイッチにポーズフレームを送信できるようになりました。
- ストレージコントローラが、スイッチから送信される情報の処理速度が一定のポイントに達すると、ストレージコントローラはポーズフレーム( Xoff )をスイッチに送信できるようになります。
- このポーズフレームを受信すると、スイッチは送信を停止します。スイッチは、ストレージコントローラに短時間送信する必要があるトラフィックの保持(キュー)を開始します。これで、ストレージコントローラは以前に受信したデータを処理できるようになります。
トラフィックの再開:
- 各ポーズ / Xoff フレームには、隣接デバイスに特定の期間の送信を停止するように要求する値(「 Quanta 」と呼ばれる)が含まれています。
- 送信側(この例ではスイッチ)は、この時間が経過すると送信を再開するか、受信側(この例ではストレージコントローラ)から別のイーサネットフロー制御パケットを受信した場合に送信を再開することが想定されています。
- IEEE 規格に基づいて、スイッチはクアンタ値を評価し、インターフェイスのクアンタ値と速度の組み合わせに基づいて「一時停止」したままにすることが期待されています。
- ただし、インターフェイスが「一時停止」状態になるまでの時間は、送信側デバイスのファームウェアによって異なり、このルールに従わない場合があります。
インターフェイスが一時停止されると予測される時間を計算しています。
- コマンドの出力
ifstat -a -v
には、ポーズフレーム( Xoff フレーム)が表示されます。 - 10Gbps
ifstat –a
では、「ポーズ」フレームと表示されます。 1Gbps では、通常 Xoff と Xon と表示されます。
- ポーズフレームには、要求されている一時停止時間の期間が、「クアンタ」と呼ばれる 2 バイトの符号なし整数( 0 ~ 65535 )の形式で含まれます。
- この 2 バイトの符号なし整数値は、要求されたポーズ期間です。
- 各「 quanta 」は 512 ビット回に等しい。
- 「ビット時間」は、データの送信にかかる秒数として定義されます。インターフェイスは「ビット / 秒」で評価されるため、「ビット時間」はインターフェイス回線速度の逆です。
1Gbps ( 1 、 000 、 000 、 000 bps )インターフェイスの場合 | 「ビット時間」は、ビットあたり 1 、 000 、 000 、 000 秒です |
1Gbps リンク。インターフェイスが計算の送信を停止するまでの最大時間 | 最大クアンタ値 *512/ ( 10^9 ) = 65535 * 512/1000000000 = 0.03355392 秒 = 33.55 ミリ秒 |
10Gbps の 場合、インターフェイスが送信計算を停止する予定の最大時間 |
65535 * 512/10^10 = 3.355ms |
プロトコルをサポートする 100Mbps インターフェイスの場合 | 100Mbps インターフェイスは、最大 335.5ms の間停止することが予想されます |
デバイスまたはネットワーク要素は、ポーズフレームの送受信の両方を行うように設定できます。
- 1Gbps インターフェイスで、ストレージコントローラの「 Transmit 」統計で Xoff (またはポーズ)が表示される場合は、次の手順を実行します。
- ストレージコントローラが、スイッチポートを一時停止するように指示しています
- その後、ストレージコントローラは最大 33.5ms のパケットの受信を停止します。
ストレージコントローラの「 Receive 」統計に Xoff (または一時停止)が表示される場合
- スイッチが、パケットの送信を停止するようストレージコントローラに指示しています
- その場合、ストレージコントローラは、このインターフェイスでの最大 33.5ms の送信を停止します。
タイマーが切れる前に「一時停止」ポートが Xon パケットを受信すると、ポートはただちに送信を再開できます。
潜在的な影響の計算:
例:
-- interface e0b (0 hours, 2 minutes, 21 seconds) --
RECEIVE
Frames/second: 4655 | Bytes/second: 416k | Errors/minute: 0
Discards/minute: 0 | Total frames: 186k | Total bytes: 31954k
Total errors: 0 | Total discards: 0 | Multi/broadcast: 0
No buffers: 0 | Non-primary u/c: 0 | Tag drop: 0
Vlan tag drop: 0 | Vlan untag drop: 0 | CRC errors: 0
Runt frames: 0 | Fragment: 0 | Long frames: 0
Jabber: 0 | Alignment errors: 0 | Bus overruns: 0
Queue overflows: 0 | Xon: 1326 | Xoff: 1326
Jumbo: 0 | Reset: 0 | Reset1: 0
Reset2: 0 | TBI mode: 0 | Pad odd: 0
Pad even: 0
TRANSMIT
Frames/second: 2993 | Bytes/second: 4009k | Errors/minute: 0
Discards/minute: 0 | Total frames: 224k | Total bytes: 285m
Total errors: 0 | Total discards: 0 | Multi/broadcast: 2
Queue overflows: 0 | No buffers: 0 | Frames queued: 0
Buffer coalesces: 0 | MTUs too big: 0 | Max collisions: 0
Single collision: 0 | Multi collisions: 0 | Late collisions: 0
Timeout: 0 | Xon: 0 | Xoff: 0
Jumbo: 0
LINK_INFO
Current state: up | Up to downs: 0 | Auto: on
Status interrupt: 0 | Speed: 1000m | Duplex: full
Flowcontrol: full
収集される統計は合計 141 秒( 2 分 21 秒)です。
- 1326 Xoff フレームを受信しました。
- Xoff フレームごとに、最大 33.5ms の送信が停止した可能性があります。
- 各 Xon はストレージシステムポートを解放して送信を再開します。ただし、 Xoff 後に Xon が 0.1 ミリ秒、 Xoff 後に 1 ミリ秒、 Xoff 後に 33.4 ミリ秒のいずれを受信したかを判断することはできません。
そのため、
ストレージシステムからネットワークへの全伝送が保持される最大 * 潜在時間 * 時間は、 1326 * 33.5ms = 44 、 421ms = 44.4 秒となります。
「パケットの割合」を考慮すると、 1326/224000 = 0.7% のように見える場合があります
- 受信したポーズフレームは、送信されたフレームにのみ影響を与えます(受信者が送信した送信を一時的に停止することによって)。
- ポートは、スイッチが送信を選択すると、スイッチからの受信をできるだけ早く継続できます。
- トラフィックが一時停止していない場合に送信されるパケット数を特定する方法はありません。
- ポートが送信を妨げられていた時間を考えると、パースペクティブは大きく異なり、関連性が高くなります。 44.4 秒 /141 秒 =31%
- したがって、この 141 秒間の間に、クライアントはストレージシステム上のこのポートから応答を受信できませんでした。
- また、各「 Xoff 」の直後に「 Xon 」が続く可能性もあります。
- この場合、送信トラフィックはごく短時間停止されます。
- これは、気づかれないままになっている可能性があります。
したがって、これらの統計情報の場合、 1326 ポーズフレームの影響は、「 none 」から 44.4 秒の間になります。フロー制御ポーズフレームは、個々のポートを対象として動作するため、ポーズフレームは上位プロトコルレイヤに渡されません。pktt にはポーズフレームは含まれません。スイッチからのほとんどのポートミラートレースには、ポーズフレームは含まれません。実際の影響が明らかになるのは、「ネットワーク上」のパケットキャプチャだけです。
ポーズフレームは、ポーズフレームを送信するデバイスに問題が発生していることを示します。ポートが一時停止した可能性のある最大時間が、データがキャプチャされた時間のかなりの部分であることを計算で確認した場合は、ポーズフレームを送信しているデバイスで問題が発生している理由を調査することを検討してください。
ポーズフレームがトラフィックフローを停止する最大時間の長さが、データがキャプチャされた時間のごく一部である場合、ポーズフレームの存在はそれほど重要ではありません。ただし、ポーズフレームが存在することから、ポーズフレームを送信するデバイスである程度の難易度が発生していることがわかります。
プロトコルの本来の目的は、ネイバーがインターフェイスをオーバーランするのに十分な速度で送信している可能性があったときに、インターフェイスがネイバー(ケーブルのもう一方の端のインターフェイス)を一時停止できるようにすることでした。最初にネイバーインターフェイスを一時停止すると、受信インターフェイスが過負荷になるのを防ぐことができます。これは状況に役立つ場合もありますが、受信インターフェイス(およびそれが含まれるノード)にポーズフレーム以外の問題 の証拠が登録されないことを意味することもあります。そのため、ポーズフレームが送信される理由を理解する必要がある場合は、イーサネットフロー制御を無効にする必要があります。その後、問題 が継続している場合は、過負荷のコンポーネントが NIC 、 PCI バス、またはオペレーティングシステムにあるかどうかを示すカウンタや動作が表示されることがあります。