昨天,我们提到了,为了在数据中心网络的吞吐量和无丢包之间找到平衡点,我们需要合理配置交换机的流控触发水线,避免交换机发起流控过迟而无法避免丢包,或过早发起流控而使得上下游服务器无法充分利用网络资源。
极少数的交换机厂商为了解决这个问题,付出高昂成本,在交换机内部增加了边缘推理单元,以实现自动调整交换机水线,试图达到充分利用网络资源的效果,但并没有得到市场的认可。这是因为——
上图是一个典型的自动控制的闭环。瓦特利用这种闭环控制的原理,使得蒸汽机成为了人们容易驾驭的安全可靠的机器,从而引发了工业革命。可以认为,人类数百年来工业时代的辉煌,是离不开这个闭环的。
但是,传统闭环控制带来的数据孤岛,也使得自动化系统“只见树木,不见森林”的矛盾越发突出。将这种基于数据孤岛的自动控制应用在分布式的网络中,背离了SDN全局控制的理念,无法解决PFC死锁、应用与会话可视等问题,也没有办法将带内遥测(INT)等实现全局检测的先进探测技术,通过大数据的手段应用于网络控制,最终的结局必然是被市场无情地抛弃。
正如中国和西方国家同时提出“工业4.0”、“工业互联网”、“中国制造2025”等先进理念那样,在网络的管控中,我们也需要利用AI及大数据技术,打破闭环,构建全局控制系统,进而实现数据驱动的社会化大生产,甚至推进下一轮的社会变革。
基于这方面考虑,我们需要通过大数据的应用来进行从云到网的全局调整,也就是实现业务的自动驾驶。
以RoCE业务的丢包为例。丢包的原因是网络拥塞,而网络拥塞实际上是有先兆的。
如图,4个配置25G网卡的MAPR存储节点,向1个配置100G网卡的TensorFlow计算节点发送数据,这时,交换机的缓存使用量是稳定的:
这是一个岁月静好的网络。
但是,如果网络的存储池中增加了一个MAPR节点,计算池中增加了一个Kafka节点呢?
显然,Tensorflow节点向4个MAPR节点拉取数据,同时Kafka节点向1个MAPR节点拉取数据时,会引起交换机之间100GE链路的拥塞。
左边的交换机的缓存使用量会上升。
这个时候,如果我们打开交换机的INT功能,可以检测到什么?
首先,INT可以实时报告缓存使用量。显然,这个使用量随着拥塞的发生而迅速增加。
另一方面,INT还可以实时报告转发路径的时延。由于缓存数据需要排队发送,显然,排队的数据包的时延大大增加了。
这样一来,如果网络大数据分析器支持使用INT进行网络分析,可以在交换机缓存用量到达水线之前分析出拥塞的发生,甚至与云平台联动,深入发掘出拥塞发生的根源——两侧网络中节点数的增加,并且给出调整建议。
如果我们将网络节点视为割裂的孤岛,也没有利用INT这种实时数据采集的手段,是没有办法解决上面案例中的问题的。
我们要知道,大数据与数理统计的本质区别,就是数据量和实时性的提升,触发了从量变到质变。因此,如果需要构建真正应用驱动,自动驾驶的智能运维网络,是离不开全局大数据的采集和分析的!
明天,我们还将分享更多酷炫的案例!