昨天，我们提到了，为了在数据中心网络的吞吐量和无丢包之间找到平衡点，我们需要合理配置交换机的流控触发水线，避免交换机发起流控过迟而无法避免丢包，或过早发起流控而使得上下游服务器无法充分利用网络资源。
极少数的交换机厂商为了解决这个问题，付出高昂成本，在交换机内部增加了边缘推理单元，以实现自动调整交换机水线，试图达到充分利用网络资源的效果，但并没有得到市场的认可。这是因为——
上图是一个典型的自动控制的闭环。瓦特利用这种闭环控制的原理，使得蒸汽机成为了人们容易驾驭的安全可靠的机器，从而引发了工业革命。可以认为，人类数百年来工业时代的辉煌，是离不开这个闭环的。
但是，传统闭环控制带来的数据孤岛，也使得自动化系统“只见树木，不见森林”的矛盾越发突出。将这种基于数据孤岛的自动控制应用在分布式的网络中，背离了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这种实时数据采集的手段，是没有办法解决上面案例中的问题的。
我们要知道，大数据与数理统计的本质区别，就是数据量和实时性的提升，触发了从量变到质变。因此，如果需要构建真正应用驱动，自动驾驶的智能运维网络，是离不开全局大数据的采集和分析的！
明天，我们还将分享更多酷炫的案例！
