暂停帧对网络连接的潜在影响是什么?
适用场景
ONTAP 9
问题解答
以太网流量控制的目的:
以太网流量控制是一种机制,可使遇到性能瓶颈的网络设备请求相邻设备停止传输。
- 以太网流量控制定义了一种通常称为 " 暂停 " 帧的以太网数据包。
- 它们只能在直接连接的设备之间进行交换,并且只能在以太网( DataLink )层中定义。
- 因此,以太网暂停帧不与 IP , TCP , NFS , CIFS 或任何其他更高级别的协议关联,也不能与这些协议关联。
如果没有以太网流量控制,则如果接收设备无法像传输设备发送信息那样快速地处理信息,则最终必须开始丢弃传入数据。
- 这会迫使传输客户端不得不重新传输,并且发生原因 会因多种原因造成痛苦的延迟。
通过以太网流量控制,收件人可以请求将传输设备 " 暂停 " 一小段时间,以尝试避免这些丢弃。
- 在某些情况下,这样可以提高网络传输的效率。
- 但是,以太网流量控制并不总是能够有效地防止出现性能问题。
- 在某些(通常很少见)情况下,以太网流量控制可能会对性能产生更大的发生原因 影响,而不是由为防止重新传输而设计的影响。
注意:以太网流量控制在 1 Gbps 或更快的设备上很常见。在更现代的 100 Mbps 设备上也可能会出现这种情况,尽管此处不支持以太网流量控制规范。
示例:
- 假设我们有一个包含存储控制器,交换机和客户端计算机的基本网络。
- 此外,假设存储控制器已配置为发送以太网流量控制数据包,而交换机已配置为在存储控制器所插入的接口上接收(侦听)以太网流量控制数据包。
- 最后,假设客户端未配置为完全支持以太网流量控制。
- 请注意,交换机为每个接口设置了以太网流量控制(存储控制器所插入的接口设置一个,客户端所插入的接口设置可能不同)。
停止 / 暂停流量:
- 在这种情况下,存储控制器现在可以向交换机发送暂停帧。
- 如果存储控制器达到无法像交换机发送信息那样快速处理信息的程度,则现在允许存储控制器向交换机发送暂停帧( Xoff )。
- 交换机在收到暂停帧时应停止传输。现在,交换机应开始将需要发送到存储控制器的流量置于(队列)状态一小段时间。现在,存储控制器可以处理先前收到的数据。
恢复流量:
- 每个暂停 /Xoff 帧都包含一个值(称为 "Quanta" ),该值请求相邻设备在特定时间段内停止传输。
- 当此时间到期或从接收器(本示例中为存储控制器)收到不同的以太网流量控制数据包时,传输器(在此示例中为交换机)应恢复传输。
- 根据 IEEE 标准,交换机应评估 Quanta 值,并根据 Quanta 值和接口速度的组合保持 " 暂停 " 状态。
- 但是,接口预期保持 " 暂停 " 状态的时间量取决于传输设备的固件,因此可能不遵循此规则。
计算接口应保持暂停状态的时间量:
- 暂停帧或 Xoff 帧会显示在
ifstat -a -v
命令的输出中。 - 在 10 Gbps 中,
ifstat –a
此命令可能会列出 " 暂停 " 帧;在 1 Gbps 中,此帧通常会列为 Xoff 和 Xon 。
- 暂停帧包括请求的暂停时间,其形式为一个称为 "quanta" 的双字节无符号整数( 0 到 65535 )。
- 此两字节无符号整数是请求的暂停持续时间。
- 每个 "quanta" 等于 512 位时间。
- " 位时间 " 是指发送位数据所需的秒数。由于接口的额定速率为 " 每秒位数 " ,因此 " 位时间 " 与接口线速度相反。
用于 1 Gbps ( 1 , 000 , 000 , 000 bps )接口 | " 位时间 " 为每位 1/1 , 000 , 000 , 000 秒 |
1Gbps 链路,接口预期停止传输计算的最长时间 | 最大 quanta 值 * 512 / ( 10^9 ) = 65535 * 512/1000000000 = 0.03355392 秒 = 33.55 毫秒 |
对于 10 Gbps , 接口预期停止传输计算的最长时间 |
65535 * 512/10^10 = 3.355 毫秒 |
支持 此协议的 100 Mbps 接口 | 100Mbps 接口应暂停最多 335.5 毫秒 |
可以将设备或网络元素配置为发送和接收暂停帧。
- 在 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.5 毫秒。
- 每个 Xon 都将释放存储系统端口以恢复传输。但是,无法确定 Xon 是在 Xoff 之后 0.1 毫秒, Xoff 之后 1 毫秒还是在 Xoff 之后 33.4 毫秒收到的。
因此,从存储系统到网络的所有传输的最大 * 潜在 * 保留时间为
: 1326 * 33.5 毫秒 = 44 , 421 毫秒 = 44.4 秒。
如果考虑 ‘Percentage of packets ' ,则可能显得微不足道: 1326/224000 = 0.7%
- 请注意,收到的暂停帧只会对传输的帧产生影响(通过临时暂停接收方本来会发送的传输)。
- 端口可以像交换机选择发送端口一样快速地继续从交换机接收。
- 无法确定在流量未暂停时要发送的数据包数量。
- 在考虑端口可能无法传输的时间时,视角截然不同,可能更相关: 44.4 秒 /141 秒 = 31%
- 因此,在这 141 秒的时间间隔内,客户端可能无法从存储系统上的此端口接收响应,时间高达 31% 。
- 也可能会在每个 ‘Xoff ' 后立即出现一个 ‘Xon ' ,
- 在这种情况下,传输流量只会在很短的时间内停止。
- 这种情况很可能仍未引起注意。
因此,就这些统计信息而言, 1326 个暂停帧的影响介于 ‘none ' 和 44.4 秒之间。由于流量控制暂停帧针对单个端口并由其操作,因此暂停帧不会传递到上层协议层。PKT 不会包含暂停帧。交换机的大多数端口镜像跟踪也不包含任何暂停帧。只有 ‘在线 ' 数据包捕获才能确实揭示真正的影响。
暂停帧表示发送暂停帧的设备遇到问题。如果计算结果确认端口可能暂停的最长时间是数据捕获时间的很大一部分,则应考虑调查发送暂停帧的设备为何遇到困难。
如果暂停帧可能会停止流量的最长时间只是捕获数据所需时间的一小部分,则暂停帧的存在不应引起太多关注。但是,暂停帧的存在仍然表明,发送暂停帧的设备遇到了一定程度的困难。
该协议的最初目的是,在相邻接口传输速度可能足以使接口溢出时,允许该接口暂停其邻居(缆线另一端的接口)。如果先暂停相邻接口,则可以防止接收接口被覆盖。虽然这有时可能有助于解决此问题,但也可能意味着接收接口(及其所在节点)不会注册除暂停帧之外的任何问题描述 证据。因此,如果需要了解发送暂停帧的原因,您可能需要禁用以太网流量控制。然后,如果问题描述 继续运行,您可能会看到其他计数器或行为,这些计数器或行为会告诉您不堪重负的组件是位于 NIC , PCI 总线还是操作系统中。
追加信息