什么是微突发？

转载

璇毅正 2019-07-30 10:36:32 博主文章分类：故障处理

什么是微突发？微突发的定义微突发是指端口在非常短的时间（毫秒级别）内收到非常多的突发数据，以至于瞬时突发速率达到平均速率的数十倍、数百倍，甚至超过端口带宽的现象。网管设备或网络性能监测软件通常是基于比较长的时间(数秒到数分钟)计算网络实时带宽。在这种情况下，看到流量速率通常是一条比较平稳的曲线（如图22-121所示）。但是，一秒钟对于一个高速收发数据包的接口来说是非常长的一个时间段。如果将数据更改为毫秒级进行观察，流量速率很可能是带锯齿的（如图22-122所示）。如果锯齿突变很大，就称为微突发。举个极端的微突发的例子：假设一个10GE链路上有平均1Gbps速率的流量，极端情况下可以是前100毫秒有10Gbps的流量，后面900毫秒的流量为0。这时，前100毫秒的10Gbps的流量对于设备而言就是微突发。图22-121 宏观流量速率图22-122 微观流量速率微突发的常见误解对于微突发的检测，通常有如下几种理解误区：为什么微突发的流量在交换机端口统计计数的Input peak rate中没有体现呢？这是因为交换机上任何报文速率的计算，都是用一段时间内的总报文数除以统计时间得到的。对于CE系列交换机而言，Input peak rate和Last 300 seconds input rate默认都是按照300s的周期计算的平均值，其中Input peak rate记录的是历史上的所有统计周期的平均速率中的最大值。端口统计计数的周期可以配置，但是最小也只能配置为10s。因此，秒级的端口统计计数周期，无法捕获到毫秒级的微突发流量，并在端口统计计数的Input peak rate中体现出来。那么，为什么端口统计计数的周期最小只能是10s呢？如果交换机按照10ms的周期统计端口流量，不就可以捕获到微突发了吗？这是因为端口的报文统计计数需要CPU去轮询芯片才能获得。交换机的端口数量可能非常可观（比如多机堆叠+40GE/100GE端口拆分），10ms的周期将导致轮询非常频繁，这将极大消耗CPU性能，从而导致交换机响应慢，甚至无响应。为什么出现微突发时交换机没有上报缓存超限告警呢？这是因为交换机要获取缓存的使用情况，只能依赖CPU的轮询机制，这就面临和端口速率计算类似的问题，CPU不能轮询太频繁，否则CPU利用率会升高，从而导致交换机响应慢，甚至无响应。网管7*24小时不停地监控端口流量，为什么网管上看到的流量曲线很平滑，没有看到微突发现象呢？这是因为交换机上报数据的精度、网管监控流量的周期都是秒级，因此精度为秒级的流量图无法展示出毫秒级的微突发流量。端口当前的利用率不高，速率不大，因此当前的突发也很小。这是错误的理解。平均速率和突发速率的关系，就如同速度与加速度，虽然名字很相似，但并没有简单的线性比例关系。端口的利用率不高，当前速率低，并不表示突发速率就小。交换机记录了拥塞丢包计数，所以是交换机引起了突发或拥塞丢包。这是错误的理解。突发流量是由业务终端产生的，除了少量协议报文外交换机不产生其他流量。但是，突发可能在交换机上加剧，例如多端口同时向单端口发送数据，收敛比不合理，导致突发的峰值叠加。所以要从流量来源和组网上着手，寻找突发的源头。终端服务器的业务是很随机的，不会有多大的突发。业务的随机性在微观程度可能体现出非常极端的两面性。一个极端是时时刻刻都有业务流量，流量总体平稳；另一个极端是一会儿有大量流量高速发送，一会儿又空闲下来没有数据发送，突发严重。业务的随机性也不等同于TCP发包的随机性。传统的TCP在有数据发送且发送窗口未满的时候，总是想要尽快抢占带宽把数据发送完，所以传统的TCP发包在微观上突发性普遍很强。同时服务器的端口带宽越高，往往突发也就越强。微突发的影响当微突发流量的瞬时速率超过交换机的转发能力时，交换机会将突发的数据进行缓存以便稍后发送。如果交换机没有足够的缓存，那么超出的数据只能丢弃，这就产生了拥塞丢包。图22-123 微突发影响图22-123是一个典型的毫秒级微突发场景。假设Port1、Port2都以10Gbps的线速速率分别向Port3发送5MB的数据，则总发送速率为20Gbps。而Port3的速率为10Gbps，仅为总发送速率的一半，因此只能将一半的数据（5MB）发送出去，另一半数据（5MB）则需要先缓存起来，待Port3有空闲能力时再发送。这时，由于交换机只有1MB的缓存，因此会有4MB的数据由于缓存不足而丢弃。在不考虑帧间隙、前导码、帧校验和、报文头等开销数据的情况下，这个突发持续的时间为5MB/10Gbps = 4ms。当前交换机整机缓存大小一般为1～20MB。这样，对于上述10GE端口线速二打一的场景，最大可承受的突发持续时间 < 16ms（20MB/10Gbps）。在实际的网络中，很多场景不是二打一而是多打一，因此对缓存的消耗会更严重，微突发时产生的拥塞丢包也就会更多。微突发的检测方法可以借助捕获报文软件和Wireshark软件来检测网络中是否存在微突发。如图22-124所示，使用Wireshark软件打开捕获报文软件记录的捕获到的报文文件，选择“统计 > I/O图表”，就可以看到流量图。图22-124 使用Wireshark软件查看流量图如图22-125所示，在IO图表中，需要将Y轴单位改为Bits，并将间隔改为1毫秒，这样就能看到毫秒级流量的突发。图22-125 Wireshark IO图表微突发的应对措施可以通过如下几种方法，来降低微突发的发生，缓解微突发的影响：针对传统TCP拥塞控制机制中存在的突发严重、过度消耗网络交换机缓存、有损线路上性能不佳、延时抖动大等问题，采用业界常用的改进技术，确保服务器不会过度、过快、突发过强地发包，从根源上减少微突发。在网络业务流量规划时，尽量避免多打一场景，避免收敛比过高的场景，及时扩容突发严重的出端口，消除突发瓶颈。对于CE12800E、CE5850EI、CE5855EI、CE5850HI、CE5880EI、CE6800系列交换机、CE7800系列交换机、CE8800系列交换机，在转发设备发生拥塞时，可以在发生拥塞的接口下执行qos burst-mode enhanced命令配置接口下缓存管理的突发模式为增强模式，以尝试缓解网络拥塞。在延时可控和缓存充足的情况下，在发生拥塞的转发设备的上游交换机下行接口通过qos queue queue-index shaping { percent cir cir-percent-value [ pir pir-percent-value ] | cir cir-value [ kbps | mbps | gbps ] [ cbs cbs-value [ bytes | kbytes | mbytes ] | pir pir-value [ kbps | mbps | gbps ] [ cbs cbs-value [ bytes | kbytes | mbytes ] pbs pbs-value [ bytes | kbytes | mbytes ] ] ] }命令开启流量×××功能，削弱流量的瞬时波峰，可以控制突发的程度。需要注意的是，此方案会导致报文转发时延加大。网络中所有设备的接口均通过dcb pfc enable [ pfc-profile-name ] [ mode { auto | manual } ]命令开启流量控制功能，从而在转发设备发生拥塞时，通知上游设备降低发包速率甚至停止发包，待拥塞解除以后再恢复报文的正常发送。需要注意的是，此方案会导致报文转发时延加大。