《云數據中心網絡與SDN：技術架構與實現》——2.3.4　設備配置可編程

2.3.4　設備配置可編程

1. CLI

這個話題可算是老生常談了。CLI于網絡非常重要，尤其是對于運維，很多時候都需要逐臺設備地show，然后靠經驗來定位問題。不過，如果敲CLI非要到設備前去插console口連，那實在是一件沒有效率的事情，設備多了，人力的成本太高。最早的遠程登錄技術是Telnet，運維用自己本地的一臺服務器就可以登錄到遠端的設備上去敲命令行。不過Telnet是明文傳輸，命令很容易被截獲和篡改，后面為了安全提出了SSH。幾乎所有的網絡設備都支持Telnet和SSH，有了遠程登錄就可以寫一些自動化的工具用于設備的集中式管理了。基于shell來寫VLAN、ACL，可以說是網絡運維的基礎技能了。

遠程登錄只是個簡單的通道，設備上有什么就只能用什么。而RPC（Remote Procedure Call，遠程過程調用）可以使得這個遠程通道上有一些自定義的能力，在遠端可以任意地調用這些能力。相比于SSH+shell，RPC+高級編程語言能夠描述更為復雜的運維邏輯，但是RPC需要對設備端的系統進行升級，傳統的網絡設備都不支持。隨著云計算的發展，自動化變得越來越重要，Devops概念日漸盛行，數據中心的網絡運維自然也要向更好的自動化方向發展。目前流行的Devops工具，包括基于RPC+Ruby的Puppet/Chef以及基于Python+SSH的Ansible，已經被廣泛地用于云中，網絡設備為了支持與云中其他資源的聯合編排，也開始在設備中集成這些能力。

無論是傳統的SSH+shell還是目前的Devops，只是CLI多穿了一件衣服，那么它們算不算是SDN呢？從嚴格的意義上來講自然不是，大抵上只能歸為自動化運維。不過，目前很多SDN控制器還在大量地使用CLI，這并不是因為SDN控制器的能力不行，而是由于廠商設備對其他接口協議的支持時至今日仍然不夠成熟，很多情況下只有用CLI才能解決實際的問題。

CLI用在SDN中，最大的問題有兩個：①不支持事務性配置，雖然可以通過RPC來包裝一些狀態機制，但是沒有形成標準化；②機器的可讀性很差，程序想要看設備的狀態只能用show，返回來一大堆字符串根本不適合機器去做解析。為了在SDN中更好地對設備進行管理和配置，必須要解決CLI存在的這兩個問題，目前以NETCONF為OVSDB最為常見。

2. NETCONF/YANG

NETCONF并不是什么新鮮的東西，Juniper從2003年開始提，2006年就出了RFC第一稿。從配置的角度來看，做網絡實際上就是在配置一個分布式的數據庫，網絡的正常運行依賴于不同設備上數據間的配合，因此一個好的網絡配置協議需要有良好的機制來維護這些數據的狀態。SNMP已經被證明只適合做監測而不適合做大規模的配置，Puppet這些為IT編排而生的工具在網絡領域也并不夠專業，因此上述機制的實現需要新設計一套專用的、標準化的RPC。NETCONF就是為此而生的，NETCONF的RPC能夠實現諸多良好的狀態特性，比如配置的分階段提交、分時生效、回滾、持久化，以及數據的加鎖等。有了這些專用的RPC，網絡配置的底層語法是做好了，但光有底層是不夠的，還需要有合適的高層語言來對網絡配置的語義進行統一的建模。相比于SNMP BER的人不可讀性以及CLI 字符的機器不可讀性，NETCONF在數據格式上選用了人類和機器均可讀的XML，XML自身有建模語言XSD和DSDL，然而它們都是為靜態文檔設計的，不能有效地滿足NETCONF對語意的要求，于是YANG被提出并成了NETCONF指定的數據建模語言。

NETCONF確實是個非常好的配置協議，良好的事務性設計使得NETCONF有能力集中式地把網絡和業務給配起來的。再加上YANG提供的可擴展性，理論上只要廠商愿意做擴展，那么用NETCONF配置BGP路由表、MPLS標簽轉發表甚至OpenFlow流表都是可行的。不過由于XML解析的速度存在瓶頸，再加上支持事務性對于數據庫的影響，因此NETCONF還是更適合實時性要求不高的配置類工作，而不適合對實時性要求較高的控制類工作。

不過，對于YANG實際上是存在很多爭議的。YANG第一稿RFC的提出是在2010年，當時業界并沒有引起什么轟動，只是知道這是為了NETCONF新設計的一個建模語言。YANG的全稱是Yet Another Next Generation，可相比于SMI、XSD和UML，除了改變了語法并做了一些簡化以外，在網絡領域YANG似乎也沒有表現出什么明顯的技術優勢。被OpenDaylight采納用于MD-SAL APP的建模，成了YANG的一個重大轉折。對于傳統網工來說，YANG module和SNMP中的MIB路子類似，相比于OpenFlow中全新的資源模型來說要好接受一些，再加上OpenDaylight提供的YANG-TOOLs能夠實現YANG module到Java的自動映射，進一步省去了網工們在編程語言上的學習成本。隨著OpenDaylight的推廣，YANG順理成章地火了一把。

不過YANG在一個地方是有優勢的，那就是它在IETF的網管專業有一個專門的工作組，負責提出標準的YANG模型來增強各個廠家的互操作性，以便未來對網絡進行統一的建模。對于運營商和OTT來說，這自然是求之不得的，但大多數廠商對這件事其實是沒有什么感覺的，雖然本質上設備里還是那么一套東西，但真要改造起來可是個巨大的工程。除非用戶要求，否則既然之前沒有開放給你，為什么現在要主動開放給你？不過，統一YANG模型這件事對于網絡的用戶來說意義重大，還是需要用戶主動去推進，然后從市場層面來帶動廠商。總體來說，這件事在大形勢上是樂觀的，但統一究竟要花上多長的時間，還要看各方的博弈。值得一提的是，OpenConfig作為一個由Google主導、致力于YANG標準化的開源項目，可以進行長期的關注。

NETCONF還有一個小兄弟叫RESTCONF，數據建模還是用的YANG，不過把NETCONF的RPC映射到了RESTful API。其好處是HTTP的通用性更強，缺點是RESTful的操作受限于CRUD，相比于RPC在靈活性上有很大差距，因此在映射RPC的過程中損失了NETCONF的一些優秀機制，如數據加鎖等。RESTCONF的流行同樣也是受OpenDaylight所提攜，當然也得益于它自身操作上的簡單性。

3. OVSDB

除了NETCONF/RESTCONF以外，OVSDB也是比較流行的配置協議。實際上這個說法是有一點問題的，OVSDB是OVS的數據庫，它的管理協議在RFC中叫作“The Open vSwitch Database Management Protocol”，這里討論的是后者，下面將其簡稱為OVSDB MgP。OVSDB是一個關系型的數據庫，支持事務，具備ACID的特性，因此OVSDB MgP對于事務也有著良好的支持。OVSDB MgP相比于NETCONF，RPC方面是類似的，數據格式上用的是JSON解析的速度比XML還要快一些，由于OVSDB MgP是專門為了OVSDB設計的，而OVSDB中的表以及表間關系都是固定的，因此OVSDB MgP也沒有綁定專用的數據建模語言。

對于OVSDB MgP，同樣有幾個常見的誤解。

OVSDB MgP只能配虛擬交換機。很多白盒廠家都是基于OVS來做設備的OS的，因此白盒基本上都支持OVSDB MgP。一些傳統廠商如Juniper、Arista的設備雖然不是基于OVS的，但也都支持OVSDB MgP，主要是為了和對接虛擬化環境做裸機的接入。

OVSDB MgP只能配端口、隧道這些，沒有辦法配流表或者轉發表。RFC里面沒有對數據模型做限定，通過擴展兩端的OVSDB Server和Client，是可以通過OVSDB MgP交互任何信息的。

OVS就是OpenFlow交換機，OVSDB MgP必須配合OpenFlow使用。不連接控制器的時候，OVS可以當做一個傳統的二層交換機來用，然后用OVSDB MgP進行統一配置端口、VLAN，不需要依賴于OpenFlow。而且根據上一條中所說，對OVSDB擴展后OVSDB MgP是可以配置流表的，很多SDN方案里面只有OVSDB MgP，而沒有使用OpenFlow。

另外，OF-CONFIG和OVSDB MgP兩者都可以用來配置OpenFlow交換機，因此也是比較容易混淆的。OF-CONFIG是ONF為OpenFlow配套提出的管理協議，OF-CONFIG用的是NETCONF的RPC，在上面做了自己的數據模型，和OpenFlow是強綁定的。OVSDB MgP是IETF中為OVS設計的管理協議，有自己的RPC，數據模型依賴于OVSDB，和OpenFlow沒有強綁定關系。

關于設備配置可編程，最后再說一點。雖然提到網絡配置通常是對交換機、路由器這些進行配置，但上述所提到的腳本、Devops、NETCONF/RESTCONF、OVSDB也是可以用來配置控制器的，數據模型建好了都是可以做的。但也千萬不要被一些“NETCONF萬能論”的說法搞暈了，真正做控制該用OpenFlow還用OpenFlow，該用BGP還用BGP。

SDN 網絡 邊緣數據中心管理 EDCM

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。