ポーズフレームがネットワーク接続に与える影響は何ですか?
環境
- ONTAP 9
- イーサネット
回答
イーサネットフロー制御の目的:
イーサネットフロー制御は、パフォーマンスボトルネックが発生しているネットワークデバイスが、隣接デバイスの送信停止を要求できるようにするメカニズムです。
- イーサネットフロー制御は、通常「ポーズ」フレームと呼ばれるイーサネットパケットのタイプを定義します。
- これらは、直接接続されたデバイス間でのみ交換でき、イーサネット(DataLink)レイヤでのみ定義されます。
- そのため、イーサネットポーズフレームは、IP、TCP、NFS、CIFS、またはその他の 上位レベルのプロトコルには関連付けられず、関連付けることもできません。
イーサネットフロー制御を使用しない場合、受信側デバイスが送信側デバイスと同じ速度で情報を処理できないと、最終的には受信データの破棄を開始する必要があります。
- これにより、送信クライアントは再送信する必要があり、さまざまな理由で原因の遅延が発生する可能性があります。
イーサネットフロー制御を使用すると、受信者は送信デバイスに短時間の「一時停止」を要求し、これらの廃棄を回避することができます。
- 場合によっては、より効率的なネットワーク転送が可能になります。
- ただし、イーサネットフロー制御は、パフォーマンスの問題を回避するのに必ずしも効果的ではありません。
- 特定の(通常はまれな)状況では原因、イーサネットフロー制御は、防止するように設計された再送信によって引き起こされるよりも、パフォーマンスへの影響が大きくなる可能性があります。
注: イーサネットフロー制御は、1 Gbps以上の機器で一般的に使用されます。イーサネットフロー制御仕様は、イーサネットフロー制御仕様をサポートすることを意図していなかったにもかかわらず、より現代的な100 Mbps機器にも採用されている可能性があります。
例:
- ストレージコントローラ、スイッチ、およびクライアントマシンで構成される基本的なネットワークがあるとします。
- さらに、ストレージコントローラがイーサネットフロー制御パケットを送信するように設定されており、スイッチが ストレージコントローラが接続されているインターフェイスでイーサネットフロー制御パケットを受信(リッスン)するように設定されているとします。
- 最後に、クライアントがイーサネットフロー制御をサポートするように設定されていないとします。
- スイッチには、インターフェイスごとにイーサネットフロー制御の設定があることに注意して ください(ストレージコントローラが接続されているインターフェイスに対して1つの設定があり、クライアントが接続されているインターフェイスに対しては異なる可能性があります)。
トラフィックの停止/一時停止:
- このシナリオでは、ストレージコントローラがポーズ フレームをスイッチに送信できるようになります。
- ストレージコントローラが、スイッチが送信しているほど速く情報を処理できない状態になった場合、ストレージコントローラはポーズフレーム(Xoff)をスイッチに送信できるようになります。
- このポーズフレームを受信すると、スイッチは送信を停止することが予想されます。これで、スイッチは、ストレージコントローラに送信する必要があるトラフィックを一時的に保持(キュー)し始めます。これで、ストレージコントローラは以前に受信したデータを処理できるようになります。
トラフィックの再開:
- 各PAUSE/XOFFフレームには、隣接デバイスに一定期間の送信を停止するように要求する値(「Quanta」と呼ばれます)が含まれています。
- 送信機(この例ではスイッチ)は、この時間が経過したとき、または受信機(この例ではストレージコントローラ)から別のイーサネットフロー制御パケットを受信したときに、送信を再開する必要があります。
- IEEE規格に基づいて、スイッチはquanta値を評価し、quanta値とインターフェイスの速度の組み合わせに基づいて「一時停止」を維持することが期待されています。
- ただし、インターフェイスが「一時停止」状態になると予想される時間は、送信側デバイスのファームウェアによって異なり、このルールに従わない場合があります。
インターフェイスが一時停止状態になると予想される時間を計算します。
- ポーズフレーム(Xoffフレーム)は
ifstat -a -v
、コマンドの出力に表示されます。 - 10Gbpsでは、
ifstat –a
コマンドは「ポーズ」フレームをリストすることがあります。1Gbpsでは、通常、XoffおよびXonとしてリストされます。
- ポーズフレームには、要求される一時停止時間の期間が含まれます。この期間は、「quanta」と呼ばれる2バイト符号なし整数(0~65535)の形式です。
- この 2バイト符号なし整数は、ポーズの要求された期間です。
- 各「quanta」は512ビット時間に等しくなります。
- 「ビット時間」は、ビットのデータを送信するのにかかる秒数として定義されます。インターフェイスのレートは「ビット/秒」であるため、「ビット時間」はインターフェイスの回線速度の逆数です。
1Gbps (1,000,000,000 bps) インターフェイスの場合 | 「ビット時間」は1ビットあたり1、000、000、000秒です。 |
1Gbps リンク、インターフェイスが計算の送信を停止すると予想される最大時間 | 最大クアンタ値* 512 /(10^9) = 65535 * 512/1000000000 = 0.03355392秒= 33.55ms |
10Gbpsの場合、 インターフェイスが計算の送信を停止すると予想される最大時間 |
65535 * 512 / 10^10 = 3.355ミリ秒 |
プロトコルをサポートする100Mbpsインターフェイスの場合 | 100Mbpsインターフェイスは、 最大335.5msの間一時停止すると予想されます。 |
デバイスまたはネットワーク要素は、ポーズフレームを送受信するように設定できます。
- 1Gbpsインターフェイスで、ストレージコントローラの「送信」統計にXoff(または一時停止)が表示されている場合は、次の手順を実行します。
- ストレージコントローラがスイッチポートに一時停止を指示しています
- その後、ストレージコントローラは最大33.5ミリ秒の間パケットの受信を停止します。
ストレージコントローラの「受信」統計にXoff(または一時停止)が表示される場合
- スイッチは、パケット送信を停止するようにストレージコントローラに指示しています。
- この場合、 ストレージコントローラは、そのインターフェイス上で最大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、Xoff後に1ms、Xoff後に33.4msのいずれを受信したかを判断することはできません。
したがって、ストレージシステムからネットワークへのすべての送信が保持される最大*潜在*時間は、
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バス、またはオペレーティングシステムにあるかどうかを示す他のカウンタまたは動作が表示されることがあります。