PAUSE フレームがネットワーク接続に及ぼす潜在的な影響は何ですか?
環境
- ONTAP 9
- イーサネット
回答
イーサネットフロー制御の目的:
イーサネット フロー制御は、パフォーマンスのボトルネックが発生しているネットワーク デバイスが、隣接デバイスに送信を停止するように要求できるメカニズムです。
- イーサネット フロー制御は、通常「PAUSE」フレームと呼ばれるイーサネット パケットのタイプを定義します。
- これらは直接接続されたデバイス間でのみ交換可能であり、イーサネット (データリンク) 層でのみ定義されます。
- したがって、イーサネット PAUSE フレームは、IP、TCP、NFS、CIFS、またはその他の上位レベルのプロトコルには関連付けられておらず、関連付けることもできません。
イーサネット フロー制御がない場合、受信デバイスが送信デバイスの送信と同じ速度で情報を処理できない場合、最終的には受信データを破棄する必要があります。
- これにより、送信クライアントは再送信を余儀なくされ、さまざまな理由で大きな遅延が発生する可能性があります。
イーサネット フロー制御を使用すると、受信側は送信デバイスに短時間「一時停止」するように要求して、このような破棄を回避することができます。
- 場合によっては、これによりより効率的なネットワーク転送が可能になります。
- ただし、イーサネット フロー制御は、パフォーマンスの問題を防ぐのに必ずしも効果的であるとは限りません。
- 特定の(通常はまれな)状況では、イーサネット フロー制御により、防止するように設計された再送信による影響よりも大きなパフォーマンスの影響が生じる可能性があります。
注:イーサネットフロー制御は、1Gbps以上の速度の機器で一般的に使用されるようになります。また、イーサネットフロー制御仕様は100Mbps以上の速度でのサポートを想定してはいませんが、より新しい100Mbpsの機器でも使用されている場合があります。
例:
- ストレージコントローラ、スイッチ、クライアントマシンで構成される基本的なネットワークがあると仮定します。
- さらに、ストレージコントローラはイーサネットフロー制御パケットを送信するように設定され、スイッチはストレージコントローラが接続されているインターフェースでイーサネットフロー制御パケットを受信(リッスン)するように設定されていると仮定します。
- 最後に、クライアントがイーサネット フロー制御をまったくサポートするように構成されていないと仮定します。
- スイッチには、各インターフェイスのイーサネット フロー制御の設定があることに注意してください (ストレージ コントローラが接続されているインターフェイスに対して 1 つの設定があり、クライアントが接続されているインターフェイスに対しては異なる設定になる可能性があります)。
交通の停止/一時停止:
- このシナリオでは、ストレージ コントローラはスイッチに PAUSE フレームを送信できるようになります。
- ストレージ コントローラがスイッチからの情報送信と同じ速度で情報を処理できない状態に達した場合、ストレージ コントローラはスイッチに PAUSE フレーム (Xoff) を送信できるようになります。
- スイッチは、PAUSEフレームを受信すると、送信を停止します。スイッチは、ストレージコントローラに送信する必要のあるトラフィックを一定時間保持(キューイング)し始めます。これにより、ストレージコントローラは以前に受信したデータを処理できるようになります。
交通再開:
- 各PAUSE/XOFFフレームには、隣接デバイスに一定時間送信を停止するよう要求する値(「Quanta」と呼ばれる)が含まれています。
- 送信側(この例ではスイッチ)は、この時間が経過するか、受信側(この例ではストレージコントローラ)から別のイーサネットフロー制御パケットを受信すると、送信を再開することが想定されています。IEEE
- 規格に基づき、スイッチはQUANTA値を評価し、QUANTA値とインターフェース速度の組み合わせに基づいて「一時停止」状態を維持することが想定されています。
- ただし、インターフェースが「一時停止」状態を維持する時間は送信デバイスのファームウェアに依存し、このルールに従わない場合があります。
インターフェースが一時停止状態のままであると予想される時間を計算します。
- PAUSEフレームまたはXOFFフレームは、
ifstat -a -v
コマンド。10Gbps - では、
ifstat –a
コマンドは 'PAUSE' フレームをリストする場合があります。1Gbps では通常、Xoff と Xon としてリストされます。
- PAUSE フレームには、要求されている一時停止時間の期間が、「クォンタ」と呼ばれる 2 バイトの符号なし整数 (0 ~ 65535) の形式で含まれます。
- この 2 バイトの符号なし整数は、一時停止の要求された期間です。
- 各「量子」は 512 ビット時間に相当します。
- 「ビットタイム」とは、1ビットのデータを送信するのにかかる秒数として定義されます。インターフェースは「ビット/秒」で評価されるため、「ビットタイム」はインターフェースの回線速度の逆数となります。
1Gbps (1,000,000,000 bps)インターフェースの場合 | 「ビット時間」は1ビットあたり1,000,000,000秒である |
1Gbpsリンク、インターフェースが送信を停止すると予想される最大時間の計算 | 最大量子値 * 512 / (10^9) = 65535*512/1000000000 = 0.03355392秒 = 33.55ミリ秒 |
10Gbpsの場合、インターフェースが送信を停止すると予想される最大時間計算 |
65535*512/10^10 = 3.355ミリ秒 |
プロトコルをサポートする100Mbpsインターフェースの場合 | 100Mbpsインターフェースは最大335.5ms一時停止することが予想される。 |
デバイスまたはネットワーク要素は、PAUSE フレームの送信と受信の両方を行うように構成できます。
- 1Gbps インターフェイスで、ストレージ コントローラの「送信」統計に Xoff (または PAUSE) が表示された場合:
- ストレージ コントローラはスイッチ ポートに PAUSE を指示しています。
- その後、ストレージ コントローラは最大 33.5 ミリ秒間パケットの受信を停止する必要があります。
ストレージコントローラが「受信」統計にXoff(またはPAUSE)をリストする場合
- スイッチはストレージ コントローラにパケットの送信を停止するように指示します。
- その後、ストレージ コントローラはそのインターフェイスでの送信を最大 33.5 ミリ秒間停止する必要があります。
タイマーが切れる前に「一時停止」されたポートが 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フレームはストレージシステムポートを解放し、送信を再開します。ただし、XonフレームがXoffフレームの0.1ms後に受信されたのか、1ms後に受信されたのか、それとも33.4ms後に受信されたのかを特定することはできません。
したがって、ストレージ システムからネットワークへのすべての送信が保持される最大 *潜在的な* 時間は次のようになります。
1326 * 33.5ミリ秒 = 44,421ミリ秒 = 44.4秒。
「パケットの割合」を考えると、1326/224000 = 0.7%と一見些細なことのように見えるかもしれません。
- 受信したPAUSEフレームは、送信フレームにのみ影響します(受信側が本来送信するはずだったフレームの送信を一時的に停止する)。
- ポートは、スイッチが送信する速度に応じて、スイッチからのフレームの受信を継続できます。
- トラフィックが一時停止されていなかった場合、送信されたパケットの数を判断する方法はありません。
- ポートが送信できなかった時間を考慮すると、視点は全く異なり、より関連性が高い可能性があります。44.4秒/141秒=31%
- したがって、この 141 秒間隔中の 31% の時間、クライアントはストレージ システム上のこのポートからの応答を受信できなかったことになります。
- また、各「Xoff」の直後に「Xon」が続く可能性もある。
- その場合、送信トラフィックはごく短時間だけ停止したはずであり、
- おそらく気づかれずに済んだだろう。
したがって、これらの統計情報の場合、1326個のPAUSEフレームの影響は「なし」から44.4秒の範囲になります。フロー制御PAUSEフレームは個々のポートを対象とし、個々のポートによって処理されるため、PAUSEフレームは上位プロトコル層に渡されません。PKTTにはPAUSEフレームは含まれません。スイッチからのほとんどのポートミラーリングトレースにも、PAUSEフレームは含まれません。真の影響を確実に明らかにするには、「回線上」のパケットキャプチャを行う必要があります。
PAUSEフレームは、PAUSEフレームを送信しているデバイスに問題が発生していることを示しています。計算の結果、ポートが一時停止していた可能性のある最大時間が、データのキャプチャ時間の大部分を占めていることが確認された場合は、PAUSEフレームを送信しているデバイスに問題が発生している原因を調査することを検討してください。
PAUSEフレームによってトラフィックフローが停止した最大時間が、データがキャプチャされた時間のごく一部である場合、PAUSEフレームの存在はそれほど問題にはなりません。ただし、PAUSEフレームが存在することは、PAUSEフレームを送信しているデバイスに何らかの問題が発生していることを示します。
このプロトコルの本来の目的は、隣接インターフェイスの送信速度がインターフェイスの負荷を上回る可能性がある場合に、インターフェイスが隣接インターフェイス (ケーブルの反対側のインターフェイス) を一時停止できるようにすることでした。最初に隣接インターフェイスを一時停止すると、受信側インターフェイスの負荷が増大するのを防ぐことができます。これは状況の改善に役立つ場合もありますが、受信側インターフェイス (およびそれが含まれるノード) が PAUSE フレーム以外の問題の証拠を登録しないという事態も引き起こす可能性があります。したがって、PAUSE フレームが送信される理由を理解する必要がある場合は、イーサネット フロー制御を無効にする必要がある場合があります。その後も問題が解決しない場合は、負荷が増大しているコンポーネントが NIC、PCI バス、またはオペレーティング システムにあるかどうかを示す他のカウンターや動作が確認できる場合があります。