谈谈基于gRPC技术的运维接口，数据中心网络运维的-巨人之剑-
业务驱动络技术革新带来的是天使还是魔鬼
随着互联业务的蓬勃发展，大数据、AI（人工智能）和RDMA（RemoteDirectMemoryAccess，远程内存直接访问）等技术已经获得广泛应用，带来数据中心流量持续增长的同时，要求基础络提供端到端低延时损转发，推动以太交换机芯片的速升级。
•芯片性能升级：从传统的10G以太到当下普及的25G以太，甚至有用户已经开始着手部署基于100G以太的HPC（HighPerformanceComputing，高性能计算）集群；
•运维特性的丰富：芯片提供了更多配套的增强能力，比如全共享缓存区（SharedBuffer）、INT（In-bandNetworkTelemetry，带内络遥测）、PFC（Priority-basedFlowControl，基于先级的流量控制)、ECN（ExplicitCongestionNotification，显示拥塞通告机制）、MOD（Mirror-On-Drop，丢包镜像）、TCB（TransientCaptureBuffer，瞬态捕获缓冲）等等。
以RDMA技术为例，交换机需要通过各种特性的复杂组合，才能更好地支撑其稳定运行，与业务的轻耦合，带来了运维难度的提升
运维的巨人之剑
在络设备技术日益复杂的背景下，要现业务的可靠运行，需要对络设备内部深度掌控，现全面的可视化。在DevOps（DevelopmentandOperations，开发运维）自动化运维当道的今天，交换机北向接口的选择变得非常重要。
传统的CLI（Command-LineInterface，命令行界面）、SNMP（SimpleNetworkManagementProtocol，简单络管理协议）等手段，论在性能、效率、自动化能力上显然不能很好的满足自动化运维需求。借鉴业界一些互联巨头的践，以及对gRPC（GoogleRemoteProcedureCall，谷歌RPC）的更深入了解，可以预见，未来基于gRPC技术的运维接口有望可以作为比较重要的自动化运维手段。在开始跟大家分享gRPC之前，我们先分析一下当前数据中心交换机运维具体遇到了哪些瓶颈。
交换机运维遇到的瓶颈
从运维自动化的角度，对交换机产生的需求非是以下几种动作：
•Get：主动获取状态和配置信息
运维平台按需从交换机设备上获取关键配置信息或者软、硬件状态信息，配置信息如BGP配置、安全配置等，状态信息如接口流量、接口状态、Buffer队列长度、丢包等等；满足机房巡检、故障排查等需求。
•Set：主动下发配置
运维平台按需对交换机下发变更配置，比如Shutdown端口、配置IP地址、配置水线阈值等；满足日常的业务变更需求。
•Alarm：主动上报异常状态
交换机内部，当满足一定触发条件后主动上报运维平台的Notification信息，比如CPU利用率超过安全阈值、队列水线达到阈值、端口UpDown等；满足对异常状态的告警需求。
•Push：主动周期上报关键状态信息
设备端周期性主动上报一些状态信息，比如接口流量、队列水线、接口错包等；满足关键指标的持续监控需求。
针对于上述的四种日常操作，论是基于传统的CLI+Syslog、SNMP，还是基于比较流行的Netconf、OpenConfig，目前看都只能满足部分需求。同时，在性能、兼容性、扩展性、标准化等方面遇到瓶颈，只能同时采用多种运维接口组合来满足自动化运维平台的速、持续集成。这几种运维接口简单分析如下：
表1：四种运维接口的能力分析
基于以析，简单总结如下：
表2：四种运维接口的劣势总结
从上面的总结中可以看到，目前常见的几种北向接口都还不够完美，法满足未来多厂商组下的统一运维和持续集成。从另外一个层面看，上述的北向接口总体上已经不容易改变、且不可控，即对于运维同学来说，没有更好的主动权，法重新定义。那么对于运维同学来讲，什么是理想的北向运维接口呢
未来理想的北向运维接口
基于上述分析总结起来，我们认为需要有一个契机可以重新定义北向运维接口，完美地支撑运维自动化平台的持续、简单、统一集成，未来理想的运维北向接口应该具备以下特征：
•厂家关性：
以运维平台为中心定义的标准化模型，不需要区分各个厂家设备进行持续的适配、变更。
•YANG模型标准化：
基于自身运维体系定义的统一标准YANG模型，持续迭代、演进，不受限于OpenConfig组织或者厂家私有YANG模型。
•全面的运维能力：
全面完善地支持Get、Set、Alarm及Push能力，同时，在统一的接口上进行四种能力下发和订阅。
•单一的运维接口：
重新定义单一的运维接口，自动化运维平台可以通过仅有的标准接口现对各厂商的统一管理。
从技术细节上，未来运维北向接口应该具备以下能力：
•结构化北向接口：
借鉴Netconf和OpenConfig的协议分层架构，将数据编码、能力模型、远程调用、数据传输、安全等模块都分开，通过分层协议架构现解耦合，保证标准接口的速迭代。
•直观、高效的数据描述：
可以基于JSON语言现数据模型的描述，取代外汇L及ProtocolBuffer的数据描述，简化编写复杂度，提高可读性。同时，数据模型的变更不需要影响底层数据的序列化传输，比如ProtocolBuffer。
•统一树状YANG模型：
基于交换机能力模型，针对不同功能模块现树状的YANG建模，比如BGP、OSPF、安全、Interface等，在不同功能模块下现Get、Set、Alarm、Push能力的整合。
•高效的数据传输：
采用二进制序列化和反序列化，提供传统文本方式高效的数据传输；可以复用单一的TCP连接现多流传输，提升效率。
•基于RPC现远程调用解耦：
基于RPC框架现的接口进行远程调用，现交换机与运维平台的解耦合，彼此透明、单独。
•安全可靠的数据传输：
远程的RPC调用需要完善的Authentication机制；数据传输本身需要安全加密。
虽然上面的描述只是对未来北向运维接口的设想，但是对于交换机设备进行全面统一的管理是在在的刚需，以运维平台为核心统一满足Get、Set、Alarm和Push操作。现中是否存在这样的接口呢基于gRPC+ProtocolBuffer也许是一个可能的选择。
基于gRPC框架的统一运维接口设计
基于gRPC+ProtocolBuffer的运维模型如下：
?控制器订阅解订阅时性周期性事件。
?交换机保存删除订阅的服务器地址，端口号和订阅事件。
?交换机基于订阅的事件，构造对应数据的JSON格式，使用Protobuf封装报文，通过gRPC协议往服务器发送ProtoRequest消息。
?服务器端收到ProtoRequest消息，使用Protobuf解封装报文，还原出JSON格式的数据结构，进行业务处理。
?服务器端处理完数据后，需要使用Protobuf封装应答数据，通过gRPC协议往交换机发送ProtoReply消息。
?交互机收到ProtoReply消息，则结束本次的gRPC交互。
框架的统一运维接口设计中，gRPC是一个关键的传输框架，但不是全部。
•Data：比较终要传输的数据，包括指令，支撑Get、Set、Alarm和Push操作；
•统一YANG模型：基于JSON进行数据模型的统一描述，以络架构及运维需求整合的统一YANG树模型；
•gRPC：统一的北向接口，通过RPC方法，把数据的发送或获取，像调用本地对象一样调用远端的对象；
•ProtocolBuffer：定义RPC接口服务（proto文件），同时完成数据的序列化和反序列化封装，提升数据的传输效率，降低带宽需求；
•Netty+HTTP2：在可靠的络连接上提供双向的流复用，配合Netty简化络编程。
gRPC是一个基于HTTP2协议的高性能、开源和通用的RPC框架，其中比较重要也是落地比较困难的就是统一YANG模型的建立。OpenConfig虽然定义了大量标准YANG模型，解决了统一、兼容的问题，但是这种标准工作组的方式法满足当下基础络运维速迭代的需求。所以呼吁头部互联牵头梳理形成事的统一YANG模型，大家在此基础上进行不断的补充、完善。从此降低运维平台多方对接的成本，把目标聚焦在运维能力需求本身。
总结
基于gRPC+ProtocolBuffer的北向运维接口，已经在锐捷交换机中现应用，满足部分Feature的运维需求。例如对交换机Buffer的全面管理，包括对IngressEgress端口队列缓存的时监控、端口队列缓存超阀值次数等指标的周期采集，比较高频率可以达到秒级；对入出端口缓存不足丢包、端口Buffer超限等问题可以自动触发Alarm上报等，很好地满足了运维对可视化和时性的要求。但是离真正取代SNMP等协议还有很长的一段路要走，但是相信未来会基于gRPC现更多运维能力的统一管控。
关于gRPC协议本身的原理，我们后面的文章会进一步展开介绍，敬请期待。
本期作者：高亮
锐捷络互联系统部行业咨询
往期精彩回顾
•【第二期】如何通过络遥测（NetworkTelemetry）技术现精细化络运维
•【第期】畅谈数据中心络运维自动化
•【第五期】流量可视化之ERSPAN的前世今生
•【第七期】运维可视化之INT功能详解
•【第八期】浅析RDMA络下MMU水线设置
•【第十期】数据中心自动化运维技术探索之交换机零配置上线
•【第十一期】浅谈数据中心100G光模块
•【第十五期】数据中心自动化运维技术探索之NETCONF
相关推荐：
畅谈数据中心络运维自动化
运维可视化之INT功能详解
了解gRPC技术，这一篇就够了
我们有充分的理由相信分布式数据库会成为行业的主流，会逐步影响越来越多的人。产品采用自研的一体化架构，兼顾分布式架构的扩展性与集中式架构的性能优势，用一套引擎同时支持 TP 和 AP 的混合负载，具有数据强一致、高可用、高性能、在线扩展、高度兼容 Oracle/MySQL、对应用透明、高性价比等特点。https://www.oceanbase.com/topic/techwiki-distributed-databasehttps://obcommunityprod.oss-cn-shanghai.aliyuncs.com/prod/blog/2024-12/4c65a288-9401-4eb3-bab3-04b3530c7555.png
页:
[1]