數據中心網絡運維的"巨人之劍"

【gRPC運維接口】本文主要介紹什么是理想的北向運維接口，基于gRPC + Protocol Buffer的北向運維接口，已經在銳捷交換機中實現應用，滿足部分Feature的運維需求。

發布時間：2019-04-29
點擊量：
點贊：

分享至

我想評論

業務驅動網絡技術革新帶來的是“天使”還是“魔鬼”？

隨著互聯網業務的蓬勃發展，大數據、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實現更多運維能力的統一管控。

關于gRPC協議本身的原理，我們后面的文章會進一步展開介紹，敬請期待。

本期作者：高亮

銳捷網絡互聯網系統部行業咨詢