技術盛宴|資料中心自動化運維技術探索之NETCONF
資料中心交換機實現運維自動化，零配置上線技術（ZAM）只是完成了交換機預先可知的固定配置，主要是一些基本的互通以及登入相關配置。未來的業務是變化的，所以具體的與業務相關的配置還需要根據具體需求配置或更新。NETCONF（Network Configuration Protocols，網路配置協議）協議提供了業務配置部署自動化的解決方案。
那麼NETCONF是如何出現的？為什麼需要開發NETCONF？NETCONF能幹什麼？發展趨勢又是怎樣的？本文將針對以上幾個問題，對資料中心運維自動化技術進行一些介紹和探討。
SNMP的問題
要談NETCONF，SNMP是無法繞過去的。SNMP（Simple Network Management Protocol ，簡單網路管理協議）最早由IETF在20世紀80年代晚期（1980s）開發，自誕生之日起，SNMP就被用來監控（如告警、效能管理）網路裝置，大多數專業的網路裝置都有SNMP agent代理，這些代理被啟用和配置後用於和SNMP管理NMS（Network Management System，網路管理系統）通訊。
一套完整的SNMP系統主要包括管理資訊庫（MIB）、管理資訊結構（SMI）及SNMP報文協議。
MIB
MIB，管理資訊庫，彙總儲存著資源與OID的唯一對應關係，NMS根據查詢的資源在MIB中找到對應的OID，通過SNMP查詢報文將讀取的OID資訊傳送至網路裝置，網路裝置根據OID查詢對應的資源資訊，最終封裝為SNMP響應報文傳送給NMS。
如圖一所示，查詢資源iso.org.dod.internet.mgmt.mib.ip.ipInReceives對應的OID即為：1.3.6.1.2.1.4.3。
圖一 ：MIB樹形層次結構
SMI
SMI，管理資訊結構，是SNMP中定義被管理的網路實體（即網路裝置）中特定資料的語言。定義了資料型別、物件模型，以及寫入和修改管理資訊的規則等內容。
SNMP報文
SNMP規定了5種協議資料單元PDU（SNMP報文），用來在管理程序和代理之間的資訊交換。
如圖二所示：
- get-request，用於從代理程序處提取一個或多個引數值；
- get-next-request，用於從代理程序處提取緊跟當前引數值的下一個引數值；
- set-request，用於設定代理程序的一個或多個引數值；
- get-response，用於代理向管理程序返回的一個或多個引數值；
- trap，代理程序主動發出的報文，通知管理程序有某些事件發生。
圖二：SNMP五種報文操作
從SNMP協議設計中可以看出，儘管具有一些配置的功能，但SNMP本身並不是面向配置的協議，也不適合開發用於配置的客戶端應用。大量的運維實踐也證明，SNMP更多是作為網路裝置狀態監控的工具，而在配置管理層面，SNMP還不具備成為一個成熟工具的能力。
而且即便在網路裝置監控層面，SNMP也還存在著其他的問題，比如：
- 效能差，效率低；
- 基於UDP協議傳輸，可靠性較差，只能依靠本身機制保證可靠性，影響效能；
- 私有MIB導致多廠家裝置統一管理難度大。
正是由於SNMP的各種不足和缺陷，才導致了NETCONF的產生。
NETCONF的由來
在2001、2002年，IAB（Internet Architecture Board，網際網路架構委員會），組織了幾次關於網路管理的專題工作會議，將網管以及協議開發者組織起來針對當時的主流網管協議（SNMP、CLI等）存在的問題進行了討論，會議結果最終形成了RFC 3535。在這份文件中，針對當時網路管理中存在的問題，提出了14項需求，其中最關鍵的幾項有：
- 易用性；
- 明確區分配置資料、描述操作狀態的資料和統計資料；
- 面向服務和網路的配置管理，而不是單個裝置的管理；
- 配置資料的匯入匯出脫離原始人員操作；
- 基於文字進行配置；
- 標準化資料模型等等。
針對RFC 3535中羅列的需求，2003年成立了NETCONF工作組，NETCONF的設計遵循RFC 3535。2006年NETCONF核心RFC 4741釋出，2011年更新版的RFC 6241釋出（廢除RFC 4741）。
NETCONF簡介
NETCONF協議，顧名思義是安裝、編輯和刪除網路裝置配置的標準協議。從上文NETCONF由來也可看出，NETCONF主要解決的問題之一就是網路裝置的配置管理、下發、更改等問題。NETCONF如何來實現對網路裝置配置的管理，我們先來看下NETCONF的架構設計。
NETCONF架構
NETCONF使用C/S結構，面向連線，協議報文使用XML格式。
圖三：NETCONF 協議架構
從圖三中可以看出NETCONF協議內部分為4層，由下至上分別是安全傳輸層，訊息層，操作層和內容層。
安全傳輸層
NETCONF所具備的一大優勢在於從協議層面就規定其傳輸層必須使用帶有安全加密的通訊協議，如SSH，TLS等。對比其他明文傳輸協議，NETCONF協議層面就對資料安全性做了保障。由於NETCONF協議規定必須要支援SSH，所以目前SSH是NETCONF使用最廣泛的傳輸層協議。
訊息層
訊息層提供了一種簡單的、不依賴於傳輸協議的RPC和通告封裝機制。
client採用<rpc>元素封裝操作請求資訊，並通過一個安全的、面向連線的會話將請求傳送給伺服器，而伺服器將採用<rpc-reply>元素封裝RPC請求的響應資訊（即操作層和內容層的內容），然後將此響應資訊傳送給請求者。另外，伺服器可以採用<notification>元素向客戶端通告事件。
操作層
操作層是承載在訊息層上的具體操作內容，這些具體操作僅能承載在<rpc>和<rpc-reply>訊息上，<notification>訊息無操作層內容。
NETCONF協議規定了9種簡單的RPC操作，如表一所示：
| 基本 操作 |
說明 |
| < get > |
獲取 配置資料或狀態資料。 |
| < get-config > |
獲取 配置資料。 |
| < edit-config > |
修改 配置 資料（包括合併 、替換、 建立 、刪除等操作 ）。 |
| < copy-config > |
用 一個完整資料庫替換目標資料庫 。 |
| < delete-config > |
刪除 資料庫，<running/>庫不能被刪除 。 |
| < lock > |
鎖定 裝置配置資料庫， 獨佔 資料庫修改許可權 ， 以免多使用者操作情況發生。 |
| < unlock > |
取消裝置 配置資料庫鎖定，只能取消本使用者的鎖定 。 |
| < close-session > |
請求正常中止 NETCONF會話 。 |
| < kill-session > |
強制 中止NETCONF會話 ， 需管理員許可權 。 |
表一：RPC基本操作
除了以上9種基本操作，NETCONF也支援使用者自定義RPC操作，這裡不做展開描述。
內容層
內容層主要用來描述網路管理所涉及的配置資料和通知資料等。但是NETCONF並沒有對於內容層的資料結構模型做標準化定義，那如何來描述內容層的相關資料呢，2006年，在NETCONF首個版本RFC 4741釋出的同時，一種專門為NETCONF準備的資料建模語言YANG（RFC 6020）也同時釋出。目標是對NETCONF資料模型、操作進行建模，覆蓋NETCONF協議的操作層和內容層。
下圖即是一個NETCONF的RPC報文中各層內容的示意。
圖四：NETCONF RPC報文示例
NECONF操作
那在這個架構下NETCONF到底是如何實現裝置配置管理的？
我們來看一次NETCONF互動的流程 ：
圖五：NETCONF互動流程示意
在Client和Server建立NETCONF會話後，兩端先通過<hello>報文互相通知對端本端對於NETCONF的支援能力，即Capability。同步完成後Client端發起RPC操作，Server端執行後將應答訊息封裝入<rpc-reply>回覆給Client端。對於裝置配置，就是在Client端發起RPC配置相關的操作。
NETCONF定義的9項基本RPC操作中有4項與配置直接相關，包括
- <get-config>；
- <edit-config>；
- <copy-config>；
- <delete-config>。
還剩餘2項與配置許可權相關，2項會話關閉和1項狀態資料查詢。從這裡也能看出NETCONF對於配置管理的重視。
可是這些好像還是沒法體現NETCONF比SNMP好在哪？SNMP存在的問題如何解決的？
這裡不得不引出NETCONF中另外一個重要的組成部分YANG。
YANG
YANG（Yet Another Next Generation），無法用中文給出恰當的翻譯。從YANG的標準文件RFC 6020中，我們可以明確它的定位： A Data Modeling Language for the Network Configuration Protocol （NETCONF），NETCONF的資料建模語言。
為什麼要YANG
NETCONF需要對裝置的配置（configuration）和狀態（state）做操作，例如編輯配置，獲取狀態，而NETCONF的內容層並沒有定義標準化的資料模型。同時操作層除了定義9種基本的RPC操作，還允許自定義RPC，自定義的RPC和具體操作內容都需要進行建模，YANG就是用來完成這個建模的。
YANG使用modules和submodule進行資料建模。一個YANG module，如圖六所示，定義了具有垂直結構的資料，這些資料可以被用做基於NETCONF的操作，包括配置、狀態資料的描述，還有RPC操作等。它使得NETCONF的Client和Server之間能有完整的資料描述。
圖六：YANG module舉例
怎麼用YANG
YANG建模得到的資料具備樹形結構。其中每一個節點都有一個名字，都有一個值或者一些子節點。YANG檔案為這些節點，以及節點之間的互動提供明確清晰的描述，即資料模型路徑。
網路裝置對於NETCONF的支援，就是在設備註冊YANG的資料模型路徑，使裝置能夠根據YANG檔案的資料模型路徑獲取資料或者寫入配置。
那麼對於運維人員來說只需拿到裝置廠商的YANG模型，根據YANG模型的要求將相關的配置或資料引數填入，即可通過NETCONF發起相關RPC操作，完成配置或資料讀取任務。
通過YANG和NETCONF，就實現了基於可程式設計技術的網路配置和管理，為自動化運維提供了基礎。
NETCONF與SNMP對比
介紹完NETCONF，我們再回頭看下NETCONG與SNMP的簡單對比：
| SNMP |
NETCONF |
|
| Data models |
Defined in MIBs |
Defined in YANG |
| Data modeling Language |
SMI |
YANG |
| Management Operations |
SNMP |
NETCONF |
| RPC Protocol |
BER |
XML |
| Transport Stack |
UDP |
S S H TCP |
表二：SNMP&NETCONF對比
相比SNMP，NETCONF具備以下優勢：
簡單易用，YANG模型簡單易學，可讀性好，且可直接對映到XML；
清晰區分配置資料和狀態資料，對於不同資料，儲存在不同資料庫中，互相區分明確；
可以統一管理整個網路所有裝置，而不再是基於單臺裝置管理；
自動化的配置下發和資料收集，降低人工誤操作機率；
標準化資料模型（建模語言）；
擴充套件性好，除了標準操作，還可以自定義操作，實現獨特管理功能；
基於SSH協議，提供配置鎖定等機制，資料安全性高。
NETCONF問題
NETCONF協議因其良好的易用性和擴充套件性，已經隨著SDN技術的逐步落地得到了越來越廣泛的使用，主流裝置廠商裝置均可以支援NETCONF功能。
但是這樣是否就完美解決了網管運維面臨的問題呢？答案顯然是否定的。原因在於：
- 各廠商裝置支援NETCONF基本都使用私有YANG模型， 不同廠商裝置不能識別其他廠商YANG檔案；
- 對於使用NETCONF運維平臺的使用者，需要學習熟悉各廠商的NETCONF文件和YANG檔案；
- NETCONF YANG Model整體的標準化程序十分緩慢。
為了解決這些現實問題，業界的裝置使用者們推出了另外一種標準化方案。
OpenConfig
為了遮蔽使用NETCONF時不同廠商裝置的差異，由Google發起，AT&T，British Telecom，Facebook， Apple" target="_blank" rel="nofollow,noindex">Apple ，Microsoft 等參與成立了 OpenConfig 工作組，希望能建立一個與裝置廠商無關的開放模型，用於網路配置和策略。目前國內的騰訊、百度和阿里等公司也已經加入了 OpenConfig 工作組。
OpenConfig標準化
OpenConfig的目的是基於實際案例的操作需求，使用YANG語言編譯一組中立的通用資料模型，以最終實現基於可程式設計技術的網路自動化運維。
OpenConfig具備以下幾個主要特徵：
- 沿用NETCONF協議框架；
- 使用YANG作為建模語言；
- 不修改底層資料傳輸，只關注上層的資料表達和資料建模。
也就是說OpenConfig更多的是要成為一個建模的標準。
OpenConfig本身是基於標準化的NETCONF協議框架和建模語言YANG來開發，在YANG Model維度進行標準化，相當對於YANG模型做了規範，需要各廠家裝置全部需要能夠識別OpenConfig YANG Model的YANG檔案，這樣，不同廠商的裝置就可以通過統一模型的YANG檔案來管理，不同的只是YANG檔案中填入的引數。
通俗的理解，OC （OpenConfig）YANG就是希望做成一種類似公有的YANG模型，如圖七所示。
圖七：OC YANG模型
OpenConfig生態情況
目前OpenConfig還不是一個官方標準組織，甚至還不是一個正式的組織，很多的成員還都是通過郵件邀請的。它由Google倡導，Microsoft、AT&T、英國電信等都是它的擁護者，國內BAT均已加入。
圖八：OpenConfig生態
OpenConfig目前還沒有釋出標準RFC，但已經成為NETCONF的下一個發展趨勢，各大網路裝置廠商都已經開始了OpenConfig的開發工作。
目前，由於在網路管理、配置下發以及開放性等方面的優勢，NETCONF基本已經成為實現資料中心運維自動化的主流協議。同時各大網路裝置廠商也紛紛將NETCONF加入功能支援列表裡。雖然由於私有YANG的問題導致在實際應用中還存在一些問題，但OpenConfig已經為解決這些問題提供了明確可行的思路。隨著OpenConfig的逐步落地，資料中心自動化運維技術將迎來新一波浪潮。
銳捷網路的資料中心交換機產品，包括RG-N18000-X系列核心交換機、RG-S6510系列25G TOR、RG-S6220-H系列萬兆TOR都已支援NETCONF和OpenConfig YANG。2018年上半年釋出的OpenConfig YANG模型也已全部完成適配，目前正在配合國內公有云提供商進行測試。
感謝您關注銳捷網路技術乾貨文章！現誠邀您參與有獎調研，您寶貴的意見和建議將幫助我們在技術探索與分享上持續精進。
點選下方連結參與調研。
http://survey.ruijie.com.cn/jq/29323915.aspx 