數(shù)據(jù)中心自動化運維技術(shù)探索之NETCONF

【NETCONF】NETCONF協(xié)議提供了業(yè)務配置部署自動化的解決方案。NETCONF是如何出現(xiàn)的？為什么需要開發(fā)NETCONF？NETCONF能干什么？發(fā)展趨勢又是怎樣的？本文針對以上幾個問題，對數(shù)據(jù)中心運維自動化技術(shù)進行一些介紹和探討。

發(fā)布時間：2018-10-17
點擊量：
點贊：

分享至

我想評論

數(shù)據(jù)中心交換機實現(xiàn)運維自動化，零配置上線技術(shù)（ZAM）只是完成了交換機預先可知的固定配置，主要是一些基本的互通以及登錄相關(guān)配置。未來的業(yè)務是變化的，所以具體的與業(yè)務相關(guān)的配置還需要根據(jù)具體需求配置或更新。NETCONF（Network Configuration Protocols，網(wǎng)絡配置協(xié)議）協(xié)議提供了業(yè)務配置部署自動化的解決方案。

那么NETCONF是如何出現(xiàn)的？為什么需要開發(fā)NETCONF？NETCONF能干什么？發(fā)展趨勢又是怎樣的？本文將針對以上幾個問題，對數(shù)據(jù)中心運維自動化技術(shù)進行一些介紹和探討。

SNMP的問題

要談NETCONF，SNMP是無法繞過去的。SNMP（Simple Network Management Protocol ，簡單網(wǎng)絡管理協(xié)議）最早由IETF在20世紀80年代晚期（1980s）開發(fā)，自誕生之日起，SNMP就被用來監(jiān)控（如告警、性能管理）網(wǎng)絡設(shè)備，大多數(shù)專業(yè)的網(wǎng)絡設(shè)備都有SNMP agent代理，這些代理被激活和配置后用于和SNMP管理 NMS（Network Management System，網(wǎng)絡管理系統(tǒng)）通信。

一套完整的SNMP系統(tǒng)主要包括管理信息庫（MIB）、管理信息結(jié)構(gòu)（SMI）及SNMP報文協(xié)議。

MIB

MIB，管理信息庫，匯總存儲著資源與OID的唯一對應關(guān)系，NMS根據(jù)查詢的資源在MIB中找到對應的OID，通過SNMP查詢報文將讀取的OID信息發(fā)送至網(wǎng)絡設(shè)備，網(wǎng)絡設(shè)備根據(jù)OID查詢對應的資源信息，最終封裝為SNMP響應報文發(fā)送給NMS。

如圖一所示，查詢資源iso.org.dod.internet.mgmt.mib.ip.ipInReceives對應的OID即為：1.3.6.1.2.1.4.3。

▲圖一：MIB樹形層次結(jié)構(gòu)

SMI

SMI，管理信息結(jié)構(gòu)，是SNMP中定義被管理的網(wǎng)絡實體（即網(wǎng)絡設(shè)備）中特定數(shù)據(jù)的語言。定義了數(shù)據(jù)類型、對象模型，以及寫入和修改管理信息的規(guī)則等內(nèi)容。

SNMP報文

SNMP規(guī)定了5種協(xié)議數(shù)據(jù)單元PDU（SNMP報文），用來在管理進程和代理之間的信息交換。

如圖二所示：

• get-request，用于從代理進程處提取一個或多個參數(shù)值；

• get-next-request，用于從代理進程處提取緊跟當前參數(shù)值的下一個參數(shù)值；

• set-request，用于設(shè)置代理進程的一個或多個參數(shù)值；

• get-response，用于代理向管理進程返回的一個或多個參數(shù)值；

• trap，代理進程主動發(fā)出的報文，通知管理進程有某些事件發(fā)生。

▲圖二：SNMP五種報文操作

從SNMP協(xié)議設(shè)計中可以看出，盡管具有一些配置的功能，但SNMP本身并不是面向配置的協(xié)議，也不適合開發(fā)用于配置的客戶端應用。大量的運維實踐也證明，SNMP更多是作為網(wǎng)絡設(shè)備狀態(tài)監(jiān)控的工具，而在配置管理層面，SNMP還不具備成為一個成熟工具的能力。

而且即便在網(wǎng)絡設(shè)備監(jiān)控層面，SNMP也還存在著其他的問題，比如：

• 性能差，效率低；

• 基于UDP協(xié)議傳輸，可靠性較差，只能依靠本身機制確保可靠性，影響性能；

• 私有MIB導致多廠家設(shè)備統(tǒng)一管理難度大。

正是由于SNMP的各種不足和缺陷，才導致了NETCONF的產(chǎn)生。

NETCONF的由來

在2001、2002年，IAB（Internet Architecture Board，互聯(lián)網(wǎng)架構(gòu)委員會），組織了幾次關(guān)于網(wǎng)絡管理的專題工作會議，將網(wǎng)管以及協(xié)議開發(fā)者組織起來針對當時的主流網(wǎng)管協(xié)議（SNMP、CLI等）存在的問題進行了討論，會議結(jié)果最終形成了RFC 3535。在這份文檔中，針對當時網(wǎng)絡管理中存在的問題，提出了14項需求，其中比較關(guān)鍵的幾項有：

• 易用性；

• 明確區(qū)分配置數(shù)據(jù)、描述操作狀態(tài)的數(shù)據(jù)和統(tǒng)計數(shù)據(jù)；

• 面向服務和網(wǎng)絡的配置管理，而不是單個設(shè)備的管理；

• 配置數(shù)據(jù)的導入導出脫離原始人員操作；

• 基于文本進行配置；

• 標準化數(shù)據(jù)模型等等。

針對RFC 3535中羅列的需求，2003年成立了NETCONF工作組，NETCONF的設(shè)計遵循RFC 3535。2006年NETCONF核心RFC 4741發(fā)布，2011年更新版的RFC 6241發(fā)布（廢除RFC 4741）。

NETCONF簡介

NETCONF協(xié)議，顧名思義是安裝、編輯和刪除網(wǎng)絡設(shè)備配置的標準協(xié)議。從上文NETCONF由來也可看出，NETCONF主要解決的問題之一就是網(wǎng)絡設(shè)備的配置管理、下發(fā)、更改等問題。NETCONF如何來實現(xiàn)對網(wǎng)絡設(shè)備配置的管理，我們先來看下NETCONF的架構(gòu)設(shè)計。

NETCONF架構(gòu)

NETCONF使用C/S結(jié)構(gòu)，面向連接，協(xié)議報文使用XML格式。

▲圖三：NETCONF 協(xié)議架構(gòu)

從圖三中可以看出NETCONF協(xié)議內(nèi)部分為4層，由下至上分別是安全傳輸層，消息層，操作層和內(nèi)容層。

• 安全傳輸層

NETCONF所具備的一大優(yōu)勢在于從協(xié)議層面就規(guī)定其傳輸層必須使用帶有安全加密的通信協(xié)議，如SSH，TLS等。對比其他明文傳輸協(xié)議，NETCONF協(xié)議層面就對數(shù)據(jù)安全性做了保障。由于NETCONF協(xié)議規(guī)定必須要支持SSH，所以目前SSH是NETCONF使用比較廣泛的傳輸層協(xié)議。

• 消息層

消息層提供了一種簡單的、不依賴于傳輸協(xié)議的RPC和通告封裝機制。

client采用<rpc>元素封裝操作請求信息，并通過一個安全的、面向連接的會話將請求發(fā)送給服務器，而服務器將采用<rpc-reply>元素封裝RPC請求的響應信息（即操作層和內(nèi)容層的內(nèi)容），然后將此響應信息發(fā)送給請求者。另外，服務器可以采用<notification>元素向客戶端通告事件。

• 操作層

操作層是承載在消息層上的具體操作內(nèi)容，這些具體操作僅能承載在<rpc>和<rpc-reply>消息上，<notification>消息無操作層內(nèi)容。

NETCONF協(xié)議規(guī)定了9種簡單的RPC操作，如表一所示：

▲表一：RPC基本操作

除了以上9種基本操作，NETCONF也支持用戶自定義RPC操作，這里不做展開描述。

• 內(nèi)容層

內(nèi)容層主要用來描述網(wǎng)絡管理所涉及的配置數(shù)據(jù)和通知數(shù)據(jù)等。但是NETCONF并沒有對于內(nèi)容層的數(shù)據(jù)結(jié)構(gòu)模型做標準化定義，那如何來描述內(nèi)容層的相關(guān)數(shù)據(jù)呢，2006年，在NETCONF首個版本RFC 4741發(fā)布的同時，一種專門為NETCONF準備的數(shù)據(jù)建模語言YANG（RFC 6020）也同時發(fā)布。目標是對NETCONF數(shù)據(jù)模型、操作進行建模，覆蓋NETCONF協(xié)議的操作層和內(nèi)容層。

下圖即是一個NETCONF的RPC報文中各層內(nèi)容的示意。

▲圖四：NETCONF RPC報文示例

NECONF操作

那在這個架構(gòu)下NETCONF到底是如何實現(xiàn)設(shè)備配置管理的？

我們來看一次NETCONF交互的流程：

▲圖五：NETCONF交互流程示意

在Client和Server建立NETCONF會話后，兩端先通過<hello>報文互相通知對端本端對于NETCONF的支持能力，即Capability。同步完成后Client端發(fā)起RPC操作，Server端運行后將應答消息封裝入<rpc-reply>回復給Client端。對于設(shè)備配置，就是在Client端發(fā)起RPC配置相關(guān)的操作。

NETCONF定義的9項基本RPC操作中有4項與配置直接相關(guān)，包括：

• <get-config>；

• <edit-config>；

• <copy-config>；

• <delete-config>。

還剩余2項與配置權(quán)限相關(guān)，2項會話關(guān)閉和1項狀態(tài)數(shù)據(jù)查詢。從這里也能看出NETCONF對于配置管理的重視。

可是這些好像還是沒法體現(xiàn)NETCONF比SNMP好在哪？SNMP存在的問題如何解決的？

這里不得不引出NETCONF中另外一個重要的組成部分YANG。

YANG

YANG（Yet Another Next Generation），無法用中文給出恰當?shù)姆g。從YANG的標準文檔RFC 6020中，我們可以明確它的定位： A Data Modeling Language for the Network Configuration Protocol （NETCONF），NETCONF的數(shù)據(jù)建模語言。

為什么要YANG

NETCONF需要對設(shè)備的配置（configuration）和狀態(tài)（state）做操作，例如編輯配置，獲取狀態(tài)，而NETCONF的內(nèi)容層并沒有定義標準化的數(shù)據(jù)模型。同時操作層除了定義9種基本的RPC操作，還允許自定義RPC，自定義的RPC和具體操作內(nèi)容都需要進行建模，YANG就是用來完成這個建模的。

YANG使用modules和submodule進行數(shù)據(jù)建模。一個YANG module，如圖六所示，定義了具有垂直結(jié)構(gòu)的數(shù)據(jù)，這些數(shù)據(jù)可以被用做基于NETCONF的操作，包括配置、狀態(tài)數(shù)據(jù)的描述，還有RPC操作等。它使得NETCONF的Client和Server之間能有完整的數(shù)據(jù)描述。

▲圖六：YANG module舉例

怎么用YANG

YANG建模得到的數(shù)據(jù)具備樹形結(jié)構(gòu)。其中每一個節(jié)點都有一個名字，都有一個值或者一些子節(jié)點。YANG文件為這些節(jié)點，以及節(jié)點之間的交互提供明確清晰的描述，即數(shù)據(jù)模型路徑。

網(wǎng)絡設(shè)備對于NETCONF的支持，就是在設(shè)備注冊YANG的數(shù)據(jù)模型路徑，使設(shè)備能夠根據(jù)YANG文件的數(shù)據(jù)模型路徑獲取數(shù)據(jù)或者寫入配置。

那么對于運維人員來說只需拿到設(shè)備廠商的YANG模型，根據(jù)YANG模型的要求將相關(guān)的配置或數(shù)據(jù)參數(shù)填入，即可通過NETCONF發(fā)起相關(guān)RPC操作，完成配置或數(shù)據(jù)讀取任務。

通過YANG和NETCONF，就實現(xiàn)了基于可編程技術(shù)的網(wǎng)絡配置和管理，為自動化運維提供了基礎(chǔ)。

NETCONF與SNMP對比

介紹完NETCONF，我們再回頭看下NETCONG與SNMP的簡單對比：

▲表二：SNMP&NETCONF對比

相比SNMP，NETCONF具備以下優(yōu)勢：

• 簡單易用，YANG模型簡單易學，可讀性好，且可直接映射到XML；

• 清晰區(qū)分配置數(shù)據(jù)和狀態(tài)數(shù)據(jù)，對于不同數(shù)據(jù)，存儲在不同數(shù)據(jù)庫中，互相區(qū)分明確；

• 可以統(tǒng)一管理整個網(wǎng)絡所有設(shè)備，而不再是基于單臺設(shè)備管理；

• 自動化的配置下發(fā)和數(shù)據(jù)收集，降低人工誤操作幾率；

• 標準化數(shù)據(jù)模型（建模語言）；

• 擴展性好，除了標準操作，還可以自定義操作，實現(xiàn)獨特管理功能；

• 基于SSH協(xié)議，提供配置鎖定等機制，數(shù)據(jù)安全性高。

NETCONF問題

NETCONF協(xié)議因其良好的易用性和擴展性，已經(jīng)隨著SDN技術(shù)的逐步落地得到了越來越廣泛的使用，主流設(shè)備廠商設(shè)備均可以支持NETCONF功能。

但是這樣是否就完美解決了網(wǎng)管運維面臨的問題呢？答案顯然是否定的。原因在于：

• 各廠商設(shè)備支持NETCONF基本都使用私有YANG模型，不同廠商設(shè)備不能識別其他廠商YANG文件；

• 對于使用NETCONF運維平臺的使用者，需要學習熟悉各廠商的NETCONF文檔和YANG文件；

• NETCONF YANG Model整體的標準化進程十分緩慢。

為了解決這些現(xiàn)實問題，業(yè)界的設(shè)備使用者們推出了另外一種標準化方案。

OpenConfig

為了屏蔽使用NETCONF時不同廠商設(shè)備的差異，由Google發(fā)起，AT&T，British Telecom，F(xiàn)acebook，Apple，Microsoft 等參與成立了 OpenConfig 工作組，希望能創(chuàng)建一個與設(shè)備廠商無關(guān)的開放模型，用于網(wǎng)絡配置和策略。目前國內(nèi)的騰訊、百度和阿里等公司也已經(jīng)加入了 OpenConfig 工作組。

OpenConfig標準化

OpenConfig的目的是基于實際案例的操作需求，使用YANG語言編譯一組中立的通用數(shù)據(jù)模型，以最終實現(xiàn)基于可編程技術(shù)的網(wǎng)絡自動化運維。

OpenConfig具備以下幾個主要特征：

• 沿用NETCONF協(xié)議框架；

• 使用YANG作為建模語言；

• 不修改底層數(shù)據(jù)傳輸，只關(guān)注上層的數(shù)據(jù)表達和數(shù)據(jù)建模。

也就是說OpenConfig更多的是要成為一個建模的標準。

OpenConfig本身是基于標準化的NETCONF協(xié)議框架和建模語言YANG來開發(fā)，在YANG Model維度進行標準化，相當對于YANG模型做了規(guī)范，需要各廠家設(shè)備全部需要能夠識別OpenConfig YANG Model的YANG文件，這樣，不同廠商的設(shè)備就可以通過統(tǒng)一模型的YANG文件來管理，不同的只是YANG文件中填入的參數(shù)。

通俗的理解，OC （OpenConfig）YANG就是希望做成一種類似公有的YANG模型，如圖七所示。

▲圖七：OC YANG模型

OpenConfig生態(tài)情況

目前OpenConfig還不是一個官方標準組織，甚至還不是一個正式的組織，很多的成員還都是通過郵件邀請的。它由Google倡導，Microsoft、AT&T、英國電信等都是它的擁護者，國內(nèi)BAT均已加入。

▲圖八：OpenConfig生態(tài)

OpenConfig目前還沒有發(fā)布標準RFC，但已經(jīng)成為NETCONF的下一個發(fā)展趨勢，各大網(wǎng)絡設(shè)備廠商都已經(jīng)開始了OpenConfig的開發(fā)工作。

目前，由于在網(wǎng)絡管理、配置下發(fā)以及開放性等方面的優(yōu)勢，NETCONF基本已經(jīng)成為實現(xiàn)數(shù)據(jù)中心運維自動化的主流協(xié)議。同時各大網(wǎng)絡設(shè)備廠商也紛紛將NETCONF加入功能支持列表里。雖然由于私有YANG的問題導致在實際應用中還存在一些問題，但OpenConfig已經(jīng)為解決這些問題提供了明確可行的思路。隨著OpenConfig的逐步落地，數(shù)據(jù)中心自動化運維技術(shù)將迎來新一波浪潮。

銳捷網(wǎng)絡的數(shù)據(jù)中心交換機產(chǎn)品，包括RG-N18000-X系列核心交換機、RG-S6510系列25G TOR、RG-S6220-H系列萬兆TOR都已支持NETCONF和OpenConfig YANG。2018年上半年發(fā)布的OpenConfig YANG模型也已全部完成適配，目前正在配合國內(nèi)公有云提供商進行測試。

本期作者：劉臣平

銳捷網(wǎng)絡互聯(lián)網(wǎng)系統(tǒng)部行業(yè)咨詢