随着互联网业务的迅猛发展，数据中心基础架构也在不断向前快速迭代，随之而来的问题是如何管理好这张庞大的数据中心网络。本文立足于新一代的25/100G数据中心架构之上，分析了目前运维层面的挑战，提出了面向网络运维全流程的技术升级，针对于流程中的每个环节讲解了对应的运维技术。希望可以通过本文给读者一些新的启发和灵感。
一、新时代需要新技术
随着云计算、AI、大数据等技术的快速发展，一些新的业务形态呈现在大家的面前，比如今年受疫情影响而爆火的在线教育，直播带货等。业务应用的革新得益于基础设施的不断发展和完善，上半年“新基建”的概念异常火爆，与之相关几大领域的股票也都在疯狂上涨。
2020年4月20日上午，国家发改委召开4月份例行新闻发布会，首次就“新基建”概念和内涵作出正式的解释。
“新型基础设施是以新发展理念为引领，以技术创新为驱动，以信息网络为基础，面向高质量发展需要，提供数字转型、智能升级、融合创新等服务的基础设施体系。”这是发改委给出的“新基建”定义。
新型基础设施主要包括3个方面内容，即信息基础设施、融合基础设施以及创新基础设施。其中信息基础设施中的数据中心作为通信网络和算力的基础是我们今天要讨论的重点。
在上一期的技术盛宴直播活动中已经跟大家分享了数据中心网络架构的演进历程，也重点介绍了新一代数据中心架构的设计建议，今天我们聚焦在运维层面来聊一聊新一代数据中心网络运维技术。
首先作者认为运维能力和架构一样也是需要更新迭代的，原因体现在两个方面：
第一是业务驱动，25/100G时代的数据中心承载了一些基于RDMA技术的业务，比如高性能计算、高性能存储等。这些业务对延时和丢包非常敏感，因此要求我们对网络设备要做到更加精细化的状态监控，由此可见传统的SNMP技术可能将要被新的运维手段所替代。
第二是技术驱动，主流的25G数据中心架构都会采用单芯片的盒式交换机来进行集群内的组网，由于芯片选型发生了变化，因此对应的运维技术也会有一些改变。具体来说就是我们可以享受到新型芯片带来的技术红利，比如基于IFA（IFA，In-band Flow Analyzer）的可视化运维能力等。
综合以上分析，作者认为新一代的数据中心需要新的运维技术来协助我们管理好这张庞大的数据中心网络。
二、面向网络运维全流程的技术升级
我们对很多公司的网络架构以及运维流程做了调研和分析，总结了一些通用的问题供大家参考和讨论。
标准化的运维流程大概分为五步：网络交付，网络配置管理，网络监控，问题定位和故障处理。下面我们来分析一下每个流程中都有哪些问题亟待解决。
网络交付
对于配置管理的流程大家并不陌生，SSH、Telnet等基于CLI的配置管理。但面向海量的网络设备如果进行重复性的机械动作，往往会消耗大家比较多的精力，影响运维的效率。
网络监控
在部署基于RDMA的业务之前，采用SNMP协议实现对网络设备的监控是比较主流的做法；但随着RDMA的应用越来越多，我们对网络设备运行状态需要掌握的更加精细和及时，而SNMP以分钟为周期的时效性和可监控的维度、颗粒度都会显得有些不足。
问题定位
以丢包问题为例，问题定位就是说我们知道了有丢包事件发生，需要定位出哪个包丢了，在哪里丢的，为什么丢。这些信息以前都没有很好的技术手段来帮助我们识别。基于ECMP的组网，加上网络设备本身又是黑盒，我们连数据包真实转发的物理路径都无从得知，更何况是问题定位呢。
故障处理
目前大多数运维模式都属于救火式的被动响应，业务先报障，运维团队接到CASE后做对应处理，对其处理的方式往往是需要依靠运维工程师的经验。在人工智能快速发展的时代，如果还一味的依靠人工来解决问题，是不是有些不够智能呢？
综合以上的分析，我们在整体运维流程的基础上进行了面向网络运维的全方位技术升级。
在考虑成本和效率的前提下，我们在每个运维流程中都应用了新的技术来解决新时代下的新问题。
图1 运维全流程与运维新技术的对应关系
下面我们逐一分析在不同运维流程中，我们应当采用哪些新的运维技术来帮助我们更有效地管理好这张庞大的数据中心网络。
三、网络上线交付
零配置自动部署管理（ZAM，Zero-configuration Automatic Manage）
上文提到在网络初始化交付环节中存在大规模交付的效率问题，那么应用什么技术可以提高这项工作的效率呢？
ZAM零配置自动部署管理技术可以很好的解决这个问题。
交换机到货安装上架并加电后，识别到空配置会自动进入ZAM模式，通过DHCP的两个Option字段获取到TFTP的Server地址以及要下载的脚本文件。基于自身的SN码获取到属于自身的版本、补丁、数据配置，自动重启后，可以分钟级完成整机房的网络设备交付。
在网络上线交付环节应用ZAM技术大大降低了对人的依赖，提高准确率的同时，节约了人工刷版本、刷配置的时间，是满足快速交付的重要手段。
图2 零配置自动部署管理技术流程
四、网络配置与管理
Ansible
网络承载的业务不会是一成不变的，为了满足复杂多样的需求可能会进行业务的调整变更。面对业务变更，往往需要运维工程师同时操作大量的网络设备，此时如果依靠工程师逐台登陆设备下发命令，大量的重复性工作一方面会导致运维效率低下，另一方面也很难避免产生一些人为配置失误，因此需要一种便捷的运维管理工具帮助工程师解决批量配置管理网络设备的问题。
社区中开源的运维管理工具有很多，都可以帮助运维人员批量完成特定任务，减少重复性工作，比如Puppet、SaltStack、Ansible等。在对比了这三个运维管理工具之后，我们发现Ansible更加轻量化，更容易被广泛应用起来。
图3 运维管理工具对比
从上述对比表中，我们不难发现Ansible的技术特点：
无客户端
这是Ansible被广泛应用的一个最大原因，被管设备上（如交换机）只需要支持SSH和Python2.5以上版本即可，不需要额外按照Ansible的客户端进行适配；
模块化
Ansible也可以视作没有服务端，我们可以通过调用特定模块，完成特定任务；
安全
基于OpenSSH的实现，加密远程传输中的数据；
支持Playbooks编排任务
这个是Ansible的最大特色，Playbooks可以帮助运维人员将复杂任务碎片化，且能够进行批量地部署复杂任务。Playbooks的编写也基于易读的YAML语法，操作容易。
五、网络精细化监控
gNMI
（gRPC Network Management Interface）
提到网络状态监控，相信大家脑海中首先涌现的就是SNMP技术。的确，SNMP作为传统的网络监控手段已经被大家应用了很多年，但面对高性能计算、大数据、AI等业务就会有些力不从心。
首先从业务特征和需求来看，高带宽业务会出现微突发的现象，因此需要我们能够实时地监控设备的运行状态。比如RDMA业务，需要对关键信息做监控，缓存队列等实时状态数据。
因此我们建议采用gRPC框架实现对网络设备的精细化监控。
图4 gRPC工作流程
gRPC是谷歌发布的基于HTTP2.0承载的高性能开源软件框架，提供了支持多种编程语言的管理网络配置和纳管的方式。开源使大家更专注于业务层面内容，减少对底层协议框架的关注。gRPC采用了ProtoBuffer（PB）来做数据的序列化与反序列化封装，用HTTP 2.0作为数据传输协议。
gRPC的传输效率非常高，也得益于这两大核心技术。
Protocol Buffers：高效的数据格式，传送二进制码，消耗少，传输快
HTTP2.0：多路复用连接，二进制帧传输，首部压缩
在网络精细化监控这一环节中，越来越多的客户开始应用gRPC来统一运维接口，拉齐设备的能力特性，提升效率，更加主动的感知网络状态，提早发现问题，防患于未然。关于gRPC技术的更详细介绍，可以查阅前几期的技术盛宴文章，由于篇幅的原因，作者在此不做深入展开。
六、问题定位
带内流量分析
（IFA，In-band Flow Analyzer）
网络运维流程中最棘手环节就是故障问题的定位。
以RDMA业务为例，该业务特征是对延时和丢包极其敏感，一旦发生了丢包就会大大降低业务性能，影响很大。因此我们除了能够感知端到端的延时，还需要能检测到异常抖动，知道在哪一跳出现了异常。
而在当前的多核心Scale-out（横向扩展）组网架构下，网络中存在了大量的ECMP（等价多路径），每个业务流在每跳具体转发到哪个物理端口上，依赖芯片Hash（哈希）的结果，这个对运维来说是不直观的，我们希望给定一个业务流瞬间就知道每跳选择了哪个物理接口。
基于上述业务诉求，IFA技术的应用给广大运维同学带来了福利。它可以用来精确确定特定流量的路径及转发时延等信息，并封装成UDP报文发送给服务器进行分析。
图5 IFA技术原理
具体实现：
在入口首跳设备上进行指定会话的识别，通过采样后，开始插入INT头部；
后续转发节点插入Metadata数据，包含设备id、入出端口、时间戳等；
尾跳设备重新构造UDP报文，并把采样报文封装到UDP报文的payload中，然后把UDP报文上送到监控服务器上。输入文字
最终IFA的部署，可以常规的日常开启，但是也可以针对发生故障时按需调用。
一些敏锐的读者看到这里会提出一个疑问，RDMA业务既然对于路径和丢包敏感，那么我们只上送那些路径发生变化以及时间超过阈值的报文到服务器，再加以分析处理不就可以吗？
图6网络流量分析技术流程
没错，如果将所有的报文上送服务器确实会额外增加了服务器成本，不利于整网TCO优化，这种本末倒置的做法可能会直接导致IFA技术无法落地应用。
因此我们需要在流量到达服务器之前做一级过滤，将那些路径和延时正常的报文都过滤掉，只上送异常报文到分析服务器，就可以大大降低了服务器的压力。在这个过滤处理环节，我们建议采用基于可编程芯片的交换机来实现，因其强大的硬件处理能力可以获得更好的价值收益。
图7 基于可编程网元的网络可视化方案
六、故障处理
基于意图的网络
（IBN，Intent-based Network）
谈到故障处理，我们需要先分析一下目前的运维模式。一般对于故障的处理流程都是先由业务方提交Case报障，运维团队在系统上接到Case再去定位问题，分析原因，解决问题，属于被动的救火式运维。迫于业务的紧急性，有的时候会让运维工作陷入很大的压力当中。
基于意图网络的智能分析平台可以很好的帮助我们改变目前的运维模式，化被动为主动。
图8 智能分析平台架构
该平台内置多个模块，包括数据采集平台、AI引擎、大数据分析平台以及智能分析器。可以实现网络及应用可视化，问题分析，故障预测等功能。
针对问题分析这一功能，可以帮助我们识别三大类故障，其中包括接入类、应用类以及网元类。基于问题的分析，该平台也会提出调优及处理建议，帮助我们快速解决问题，恢复业务。
图9 基于IBN的故障自动识别
关于IBN的详细内容，未来会单独做一期技术盛宴和大家一起分享，在这里先抛砖引玉一下，大家敬请期待后续的专题讲解。
七、小结
看到这里，相信大家对新一代的数据中心运维技术也有所了解了。
锐捷网络互联网数据中心ENA（Easy Network Architecture，简单网络架构）解决方案正是基于单核心Box+多平面组网的基础架构，面向运维全流程做升级迭代，从架构和运维两个层面持续演进。
本文中提到的运维特性已经在锐捷网络数据中心交换机产品中全部体现，这些是锐捷人长期深入业务场景、观察研究、不断打磨精品的具体呈现。我们深知，看清用户痛点，以极简的方式辅助用户成功，这才是技术研发的第一要义。同时也希望每一位技术盛宴的读者与我们分享您的真知灼见，我们共同发现、共同讨论、共同成功！
本文作者：墨染尘香
锐捷网络互联网系统部解决方案架构师
