智能运维：如何打造人工智能所需求的低时延基础数据中心

本期嘉宾：锐捷网络互联网系统部技术副总监权熙哲

演讲会议：1024学院旗下品牌iTechClub主办·华东区第十一届互联网技术精英高峰论坛

整理编辑：小猿

2017年AI的突然爆发重构了很多企业的服务方式，尤其是在对数据的利用上。

英国皇家航空学会高级会员(FRAeS)丁秋林教授曾经提出信息链、智能链、智慧链的概念及相互间的关系。

信息链与智能链

以数据为基础，对数据的整合处理形成了信息，而对信息的标签化利用就形成了知识。

其实传统大数据产业，就一直聚焦在解决这一链条的问题。

云计算的发展和网络带宽的提升，让以往收集海量数据的工作变得容易起来，如今大数据的应用几乎遍布各个产业，大数据服务也早以成为这一代互联网最底层的基础设施。

但AI的发展还在此链条之上。

在仅关注智能链的情况下（智慧链离我们还有些远），对于知识的利用形成了智能，对于智能的功能整合形成了智能模块，最终进行封装并商业落地形成了智能产品。

所谓编程的核心其实就是把逻辑可视化，并将这个逻辑赋予计算机执行，但效率显然还不够高。

以AlphaGo为例，不但巨量的落子可能性选择造成了传统编程的困难，而且要战胜顶级棋手需要的不仅仅是知识，而是智能。

知识来自于老师，仅仅能让计算机无限逼近顶级棋手，只有智能才能跨过这个门槛。

所以AI在基础的信息链不断完善的情况下，终于蓬勃发展，最终到达了今天的局面。

但我们不应该忘了，其基础还是信息链。对于很多创业公司来说，把深度学习相关的算法研究透彻并非难以实现，但你不能生个孩子不让他上学，还指望他成为天才吧？

于是，基础的高性能的数据中心成为了第一道绕不开的门槛。

AI研发所需要的基础设施，大概可以归纳为三点：

大数据，计算力，算法。

计算力好说，计算力是个拼钱的东西。GPU、FPGA都已经相当强大，英伟达的Tesla V100所提供的计算力已经可以媲美若干年前的超级计算机了。

算法，是个拼人才的东西。主要取决于开发人员对于TensorFlow、Caffe、Theano、Torch、DMTK等相关主流框架的掌握程度，卷积神经网络、Recursive neural network（应用：时序数据集中）、neural autoregressive topic model（应用：自然语言处理）等算法的理解程度。

但大数据可以划分为一个单独的产业，涉及一条漫长的链条，大概可以分为：数据采集、数据存储与管理、数据分析与挖掘、数据运维、数据应用。

三者综合起来，对数据中心来说有两点支撑相对更加关键：低时延和无丢包。

时延产生的原因

目前的网络基础架构产生时延的原因可以归纳为五点：

光电传输时延、数据串行时延、主机处理时延、设备转发时延、重新排队时延。

其中光电传输时延，修仙还未成功的凡人暂时不需要关注。

数据串行时延和设备转发时延取决于芯片技术，要看硅谷怎么想，而且这之中的信号传输和芯片pipeline转发时延是固化的。

主机处理时延和重新排队时延产生的原因比较多，用户态和内核态之间的多次内存拷贝、中断处理；高带宽TCP/IP协议处理占用CPU过高都是原因，也是大家主要关注的优化点。

RDMA + RoCE解决方案

锐捷网络提供的解决方案是RDMA + RoCE，这也是当前当前比较主流的方向。

其中，RDMA的性能主要体现在两个方面：

1.Zero copy

常规的应用在向用户提供静态数据时，流程是这样的：kernal把数据从disk读出来，然后把它传输给user级的application，然后application再次把同样的内容再传回给处于kernal级的socket。这种场景下，application实际上只是作为一种低效的中间介质，用来把disk file的data传给socket。

data每次穿过user-kernel boundary，都会被copy，这会消耗cpu，并且占用RAM的带宽。

zero copy是请求kernel直接把disk的data传输给socket，而不是通过应用程序传输。所以提高了应用程序的性能，并且减少了kernel和user模式的上下文切换。

2.Kernelbypass&Protocoloffload

不需要内核参与，数据通路中没有繁琐的处理报头逻辑，不仅会使延迟降低，而且也大大节省了CPU的资源。

根据百度系统部提供的数据，与TCP相比，应用RDMA以后在语音识别训练方向上提速2倍，在机器翻译训练方向上提速15倍。

而RoCE是RDMA承载协议，比iWARP产业生态更加健全，主流网卡厂商都已支持，部署和运维更加方便，而且设备成本更低。

网络阻塞或者丢包

在以太网中，每个网络设备都会尽力的把数据转发给下游的设备。当下游设备处理能力不足的时候，网络就会出现拥塞或者丢包，所以网络本身是不可靠的，无论是TCP或者RDMA协议，网络拥塞和丢包重传都会让业务性能受到影响，尤其是RDMA协议对网络丢包的容忍度更低。

这里采用的是PFC + ECN的流控技术。

PFC是一种基于队列的反压协议，将以太链路上的流量区分为不同的等级，基于每条流量单独发送“不许可证”。

相对于PAUSE帧而言，PFC可以将链路虚拟出8条不同等级的虚拟通道，当某条通道出现拥塞后不会影响其他通道。

ECN是一种基于流的端到端流控技术，是在交换机出口（egress port）发起的拥塞控制机制，效果上会优于PFC。

当交换机的出口buffer达到设定的阈值时，交换机会改变数据包头中的ECN位来给数据打上ECN标签，当带ECN标签的数据到达接收端以后，接收端会生成CNP（Congestion Notification Packet）并将它发送给发送端。CNP包含了导致拥塞的flow或QP的信息，当发送端收到CNP后，会采取措施降低发送速度。

之所以采用PFC+ECN的机制来治理网络拥塞，是为了针对PFC固有的缺陷问题，业内一般常用的解决方案是优先触发ECN报文，用来减少网络中PFC的数量，在PFC生效前完成流量的降速。

智能运维

运维管理的难易程度几乎和架构本身的优劣程度一样重要。原始的运维手段，集群规模越大，工作越繁杂，故障率越高。

在大会上，锐捷网络的演讲嘉宾权熙哲讲道，运维人员的终极目标是“一边喝咖啡一边做运维”。

在某些领域其实不太可能，除非你喜欢半夜喝咖啡[/搞怪脸]，但极大的减少运维工作量，降低运维工作难度还是很可能的。

在这一点上，锐捷网络提供了两种工具，一是buffer水线可视化，其架构图如下：

而另一个工具叫做报文路径可视化，实现方式是在报文传输节点添加 INT （In-band Network Telemetry）信息，包括Switch-ID，时间戳，Residence-time，Ingress-port, Egress-port, Queue ID等，从而可以确定报文去向、传输耗时、报文在每台交换机的选路信息、报文在交换机内部的状态等。

最后，锐捷网络也展望了关于在AI技术应用以后，运维未来的几个发展方向，分别是：

流量特征自分析、流量模型自学习、流量转发自调度、故障自诊断、故障自恢复。

祝广大运维同志，都能早日实现凌晨喝着咖啡悠闲的运维！