业务驱动网络技术革新带来的是“天使”还是“魔鬼”？
随着互联网业务的蓬勃发展，大数据、AI（人工智能）和RDMA（Remote Direct Memory Access，远程内存直接访问）等技术已经获得广泛应用，带来数据中心流量持续增长的同时，要求基础网络提供端到端低延时无损转发，推动以太网交换机芯片的快速升级。
?芯片性能升级：从传统的10G以太网到当下普及的25G以太网，甚至有用户已经开始着手部署基于100G以太网的HPC（High Performance Computing，高性能计算）集群；
?运维特性的丰富：芯片提供了更多配套的增强能力，比如全共享缓存区（Shared Buffer）、INT（In-band Network Telemetry，带内网络遥测）、PFC（Priority-based Flow Control，基于优先级的流量控制)、ECN（Explicit Congestion Notification，显示拥塞通告机制）、MOD（Mirror-On-Drop，丢包镜像）、TCB（Transient Capture Buffer，瞬态捕获缓冲）等等。
以RDMA技术为例，交换机需要通过各种特性的复杂组合，才能更好地支撑其稳定运行，与业务的“轻耦合”，带来了运维难度的提升
运维的巨人之剑
在网络设备技术日益复杂的背景下，要实现业务的可靠运行，需要对网络设备内部深度掌控，实现全面的可视化。在DevOps（Development and Operations，开发运维）自动化运维当道的今天，交换机北向接口的选择变得非常重要。
传统的CLI（Command-Line Interface，命令行界面）、SNMP（Simple Network Management Protocol，简单网络管理协议）等手段，无论在性能、效率、自动化能力上显然不能很好的满足自动化运维需求。借鉴业界一些互联网巨头的实践，以及对gRPC（Google Remote Procedure Call，谷歌RPC）的更深入了解，可以预见，未来基于gRPC技术的运维接口有望可以作为最重要的自动化运维手段。在开始跟大家分享gRPC之前，我们先分析一下当前数据中心交换机运维具体遇到了哪些瓶颈。
交换机运维遇到的瓶颈
从运维自动化的角度，对交换机产生的需求无非是以下几种动作： ?Get：主动获取状态和配置信息
运维平台按需从交换机设备上获取关键配置信息或者软、硬件状态信息，配置信息如BGP配置、安全配置等，状态信息如接口流量、接口状态、Buffer队列长度、丢包等等；满足机房巡检、故障排查等需求。
?Set：主动下发配置
运维平台按需对交换机下发变更配置，比如Shutdown端口、配置IP地址、配置水线阈值等；满足日常的业务变更需求。
?Alarm：主动上报异常状态
交换机内部，当满足一定触发条件后主动上报运维平台的Notification信息，比如CPU利用率超过安
全阈值、队列水线达到阈值、端口Up/Down等；满足对异常状态的告警需求。
?Push：主动周期上报关键状态信息
设备端周期性主动上报一些状态信息，比如接口流量、队列水线、接口错包等；满足关键指标的持续监控需求。
针对于上述的四种日常操作，无论是基于传统的CLI + Syslog、SNMP，还是基于比较流行的Netconf、OpenConfig，目前看都只能满足部分需求。同时，在性能、兼容性、扩展性、标准化等方面遇到瓶颈，只能同时采用多种运维接口组合来满足自动化运维平台的快速、持续集成。这几种运维接口简单分析如下：
表1：四种运维接口的能力分析
基于以上分析，简单总结如下：
表2：四种运维接口的优劣势总结
从上面的总结中可以看到，目前常见的几种北向接口都还不够完美，无法满足未来多厂商组网下的统一运维和持续集成。从另外一个层面看，上述的北向接口总体上已经不容易改变、且不可控，即对于运维同学来说，没有更好的主动权，无法重新定义。那么对于运维同学来讲，什么是理想的北向运维接口呢？
未来理想的北向运维接口
基于上述分析总结起来，我们认为需要有一个契机可以重新定义北向运维接口，完美地支撑运维自动化平台的持续、简单、统一集成，未来理想的运维北向接口应该具备以下特征：
?厂家无关性：
以运维平台为中心定义的标准化模型，不需要区分各个厂家设备进行持续的适配、变更。 ?YANG模型标准化：
基于自身运维体系定义的统一标准YANG模型，持续迭代、演进，不受限于OpenConfig组织或者厂家私有YANG模型。
?全面的运维能力：
全面完善地支持Get、Set、Alarm及Push能力，同时，在统一的接口上进行四种能力下发和订阅。 ?单一的运维接口：
重新定义单一的运维接口，自动化运维平台可以通过唯一的标准接口实现对各厂商的统一管理。 从技术细节上，未来运维北向接口应该具备以下能力： ?结构化北向接口：
借鉴Netconf和OpenConfig的协议分层架构，将数据编码、能力模型、远程调用、数据传输、安全等模块都分开，通过分层协议架构实现解耦合，保证标准接口的快速迭代。
?直观、高效的数据描述：
可以基于JSON语言实现数据模型的描述，取代XML及Protocol Buffer的数据描述，简化编写复杂度，提高可读性。同时，数据模型的变更不需要影响底层数据的序列化传输，比如Protocol Buffer。
?统一树状YANG模型：
基于交换机能力模型，针对不同功能模块实现树状的YANG建模，比如BGP、OSPF、安全、Interface等，在不同功能模块下实现Get、Set、Alarm、Push能力的整合。
?高效的数据传输：
采用二进制序列化和反序列化，提供传统文本方式高效的数据传输；可以复用单一的TCP连接实现多流传输，提升效率。
?基于RPC实现远程调用解耦：
基于RPC框架实现的接口进行远程调用，实现交换机与运维平台的解耦合，彼此透明、独立。 ?安全可靠的数据传输：
远程的RPC调用需要完善的Authentication机制；数据传输本身需要安全加密。
虽然上面的描述只是对未来北向运维接口的设想，但是对于交换机设备进行全面统一的管理是实实在在的刚需，以运维平台为核心统一满足Get、Set、Alarm和Push操作。现实中是否存在这样的接口呢？基于gRPC + Protocol Buffer也许是一个可能的选择。
基于gRPC框架的统一运维接口设计
基于gRPC + Protocol Buffer的运维模型如下：
?控制器订阅/解订阅实时性/周期性事件。
?交换机保存/删除订阅的服务器地址，端口号和订阅事件。
?交换机基于订阅的事件，构造对应数据的JSON格式，使用Protobuf封装报文，通过gRPC协议往服务器发送Proto Request消息。
?服务器端收到Proto Request消息，使用Protobuf解封装报文，还原出JSON格式的数据结构，进行业务处理。
?服务器端处理完数据后，需要使用Protobuf封装应答数据，通过gRPC协议往交换机发送Proto Reply消息。
?交互机收到Proto Reply消息，则结束本次的gRPC交互。
框架的统一运维接口设计中，gRPC是一个关键的传输框架，但不是全部。 ?Data：最终要传输的数据，包括指令，支撑Get、Set、Alarm和Push操作；
?统一YANG模型：基于JSON进行数据模型的统一描述，以网络架构及运维需求整合的统一YANG树模型；
?gRPC：统一的北向接口，通过RPC方法，把数据的发送或获取，像调用本地对象一样调用远端的对象；
?Protocol Buffer：定义RPC接口服务（.proto文件），同时完成数据的序列化和反序列化封装，提升数据的传输效率，降低带宽需求；
? Netty + HTTP/2：在可靠的网络连接上提供双向的流复用，配合Netty简化网络编程。
gRPC是一个基于HTTP/2协议的高性能、开源和通用的RPC框架，其中最重要也是落地最困难的就是统一YANG模型的建立。OpenConfig虽然定义了大量标准YANG模型，解决了统一、兼容的问题，但是这种标准工作组的方式无法满足当下基础网络运维快速迭代的需求。所以呼吁头部互联网公司牵头梳理形成事实的统一YANG模型，大家在此基础上进行不断的补充、完善。从此降低运维平台多方对接的成本，把目标聚焦在运维能力需求本身。
总结
基于gRPC + Protocol Buffer的北向运维接口，已经在我们的交换机中实现应用，满足部分Feature的运维需求。例如对交换机Buffer的全面管理，包括对Ingress/Egress端口/队列缓存的实时监控、端口/队列缓存超阀值次数等指标的周期采集，最高频率可以达到秒级；对入/出端口缓存不足丢包、端口Buffer超限等问题可以自动触发Alarm上报等，很好地满足了运维对可视化和实时性的要求。但是离真正取代SNMP等协议还有很长的一段路要走，但是相信未来会基于gRPC实现更多运维能力的统一管控。
技术盛宴丨数据中心网络运维的巨人之剑 - 图文
