国产91免费_国产精品电影一区_日本s色大片在线观看_中文在线免费看视频

CNTXJ.NET | 通信界-中國通信門戶 | 通信圈 | 通信家 | 下載吧 | 說吧 | 人物 | 前瞻 | 智慧(區塊鏈 | AI
 國際新聞 | 國內新聞 | 運營動態 | 市場動態 | 信息安全 | 通信電源 | 網絡融合 | 通信測試 | 通信終端 | 通信政策
 專網通信 | 交換技術 | 視頻通信 | 接入技術 | 無線通信 | 通信線纜 | 互聯網絡 | 數據通信 | 通信視界 | 通信前沿
 智能電網 | 虛擬現實 | 人工智能 | 自動化 | 光通信 | IT | 6G | 烽火 | FTTH | IPTV | NGN | 知本院 | 通信會展
您現在的位置: 通信界 >> 工業自動化 >> 技術正文
 
技術盛宴|暢談數據中心網絡運維自動化
[ 通信界 | 華為技術 | www.6611o.com | 2018/11/18 11:16:51 ]
 

首先,讓我們假想一個場景:

由于業務發生變更,需要為一個 POD 里面的幾十臺交換機修改 QoS 配置。作為網絡運維人員,應該怎樣處理這項工作呢?

如果需要變更的對象是整個數據中心幾百臺甚至幾千臺交換機,又該怎樣處理這項工作呢?

當下,互聯網行業已經普遍采用 DevOps 的體系流程。靠人力去一臺設備一臺設備的更改配置,已經不再是正確的思維方式。原因不僅僅是浪費時間 —— 要知道,人如果要長時間保持注意力集中,大腦需要耗費大量的能量,很難保證不出現遺漏或者錯誤。而機器卻不會。

因此,正確的方法是利用 DevOps 的流程,讓機器來完成這項工作。例如采用基于 Python 的 SSH 庫 Paramiko 或 Netmiko,以及 Ansible 或 SaltStack 等自動化工具編寫運維腳本。

Netmiko 庫和 Ansible 等運維工具雖然可以通過程序化的腳本對網絡設備實現批量管理,但仍然需要運維工程師對網絡設備的 CLI 很熟悉,預先在腳本中建立需要被執行的 Command 列表。

CLI

CLI 最大的問題就是在不同廠商的設備之間,甚至在不同版本之間存在較大差異。比如在某 C 廠商交換機上配置邊緣端口,不同的 OS 版本命令并不相同:而對于另一些廠商,配置命令則差異更大。例如在某 E 品牌 交換機上配置邊緣端口的命令為:這意味著:如果設備版本升級,就可能需要更改運維腳本的代碼。為了避免廠商綁定,網絡內通常也會同時存在多個廠商的設備,相應地,也可能需要準備多種運維腳本或者讓運維腳本變得很復雜 —— 先判斷設備型號和版本號,再運行相應的 Command-list。

所以 CLI 并不適合用來作為一種 API。雖然采用自動化工具處理 Commands 可以節省網絡運維人員的工作量,但是技術門檻和維護成本都比較高。SNMP 似乎是一種更好的選擇。

SNMP 的歷史很悠久,第 1 個與之相關的 RFC 1065 發布于 1988 年,距今已有 30 年。在 SNMP 架構中,一個網絡設備以守護進程的方式運行 SNMP Agent,而 NMS(網絡管理系統)和網絡運維人員所使用的各種 SNMP 管理工具則稱為 SNMP Manager。SNMP Agent 能夠響應來自 SNMP Manager 的各種請求信息

SNMP Agent 會維護一個 MIB(管理信息庫),里面保存著大量的 OID (對象標識符)。一個 OID 是一對唯一的 Key-Value,SNMP Manager 向 SNMP Agent 查詢或修改若干 Key 所對應的 Value,就可以實現信息采集或者網絡設備的配置修改。

上圖是一個 MIB 示例,請注意標黃色的部分。OID 1.3.6.1.2.1.2.2.1.5 用來以 bps 為單位評估接口流量,它屬于 RFC 1213 標準 MIB,名稱為 ifSpeed,只讀。因為這個 MIB 并不是我從正在運行的設備上取下來的,所以當前的 Value 為空。

需要注意的是,SNMP Manager 側的 MIB 并不是必需的。如果使用數字 OID 1.3.6.1.2.1.2.2.1.5,SNMP Manager 可以直接從 SNMP Agent get 接口流量帶寬,而不需要安裝完整的 MIB。

現在 SNMP 在網絡監控領域已經被廣泛使用,利用 Zabbix、Nagios、Cacti 等開源的 SNMP 管理工具采集網絡設備接口流量帶寬和其他設備信息,同時也有大量的基于 Python 的 SNMP 庫用來實現運維開發,例如 PySNMP、 EasySNMP、 Net-SNMP等等,并且它們都可以集成到 Ansible 和 SaltStack 等自動化運維工具上。

看上去還不錯,但實際上 SNMP 仍然不是一個合適的 API,因為它存在幾個問題:

○太古老,并發性能不好

○基于 UDP 協議傳輸,比較不可靠。雖然在應用層有 Response 機制保證丟包之后的重復 get/ set,但代價就是性能和運行時間都受到影響

○最致命的問題是,各廠商都大量的使用私有 MIB,卻不存在一個可以自動發現網絡設備當前所采用的 MIB 的機制。網絡運維人員必須分別向設備廠商索取網絡設備的 MIB,耗費大量的時間整理自己需要的 OID,再手工導入到自動化運維平臺或者腳本當中

所以 SNMP 仍然只適合用來做信息采集,提供告警和可視化報表,但自動化運維的 API 則需要考慮其他的選項。站在網絡運維人員的角度,這個 API 應該滿足以下要求:

○容易使用 —— Usability 是所有產品的核心價值

○需要能夠清晰地區分“配置數據”,“設備運行狀態數據”和“統計數據”

○需要能夠分別從各個網絡設備獲取上述 3 種數據,并且可以方便地對比不同設備的數據

○可以讓網絡運維人員統一地管理整個網絡的所有設備,而不是一臺一臺的單獨管理

○對不同廠商的設備都能夠使用同一種配置方法

○配置變更對網絡業務的影響要盡可能的小

○能夠提供一個標準化的,對設備 Pulling 和 Pushing 配置文件的流程,以滿足對設備配置的備份和恢復的業務需求

○能夠很方便地,持續地,檢查設備配置文件的一致性

○能夠提供基于文本的配置方式,并且不會導致配置的亂序,例如不能攪亂 ACL 規則的順序

能夠滿足這些要求的網絡設備的北向 API 接口就是 Netconf。

Netconf 是 IETF 發布的標準協議,它的全稱是 Network Configuration Protocal。從名字就可以看出來,Netconf 的作用是基于網絡來安裝、操作和刪除設備的配置。在 Netconf 的架構中,網絡設備充當 Netconf Server 的角色,而運維人員的這一側則是 Netconf Client。此外,和 OSI 標準模型一樣,Netconf 也是分層結構。

它有 4 個層次,從下到上依次為:

●安全傳輸層

安全傳輸層在 Netconf Client 和 Netconf Server 之間提供安全的端到端連接。與 SNMP 采用非面向連接的 UDP 協議不同,Netconf 采用面向連接的 TCP 協議,通常是 SSH 協議,保證連接的可靠性和安全性。

●消息層

消息層也稱為 RPC(遠程過程調用)層。Netconf Server(網絡設備)上面部署了 Netconf 應用,Netconf Client 需要調用 Server 上的應用所提供的函數/方法,但由于 Client 和 Server 不在同一個內存空間,無法直接調用,所以需要通過網絡來表達調用的語義,并傳達調用的數據。這個過程,稱為 RPC。它提供了一個簡單的,與安全傳輸層無關的機制來封裝操作層和內容層的數據:

○RPC 調用: 元素所封裝的消息

○RPC 結果: 元素所封裝的消息

○事件通知: 元素所封裝的消息

●操作層

操作層定義了如圖所示的 9 種基礎操作集,其中:

用來對設備進行取值操作

用于配置設備參數

和是在對設備進行操作時,為防止并發產生混亂的鎖行為和用于結束一個會話操作

●內容層

顧名思義,內容層就是用來表達配置數據和狀態數據,網絡運維人員只需要關注數據本身,而不需要去關注設備的相關命令。基礎網絡設備在內容層所采用的數據格式通常是 XML,但也有廠商的數據格式采用了 JSON。

雖然網絡運維人員不再需要關注設備的相關命令了,但仍然無法直接使用 Netconf 配置設備,還需要考慮配置結構。

什么叫“配置結構”呢?

假如我們現在要將交換機的 10# 端口劃入 VLAN 20。從上面兩個配置示例可以發現銳捷交換機和 H 品牌交換機的配置結構有明顯差異,所以無法直接使用 XML 或者 JSON 修改它們的設備配置。

為了解決配置結構的問題,需要將 XML 和 JSON 數據格式抽象成一個統一的標準的模型,這就是 YANG。YANG 的全稱是 Yet Another Next Generation,沒有恰當的中文來翻譯它。通俗的講,YANG 是表達 Netconf 所操作的配置數據和狀態數據的模板,它描述什么才是符合設備期望的數據。有了 YANG Model,配置結構就交給它去處理,網絡運維人員就只需要做一個完形填空即可。

這個過程在邏輯上,與向 SNMP 的 OID 填充/讀取 Value 差不多。

Netconf 和 YANG Model 的出現,為網絡自動化帶來了極大的便利。配合自動化的程序,可以實現動態向網絡設備下發配置,將數據面和控制面分離,組成軟件定義的網絡。事實上,Netconf 也是 OpenDayLight 等開源 SDN Controller 所廣泛使用的南向接口之一。 此外,Ansible 也集成了 Netconf 的 Module,并且可以通過 Python 來擴展 ncclient 和 nxpy 等庫,實現功能擴展。

但 Netconf 就是我們在尋找的理想的 API 嗎?

站在網絡運維者的角度,答案卻是否定的。

原因在于很多廠商雖然支持 Netconf,但有一些 Key-Value 卻存在差異。比如為了表達“端口”,有些廠商用 intf 作為 Key,但另外一些廠商卻用 interface 作為 Key。另一個例子就是 Uptime,設備運行時間,各家廠商的設備返回的時間格式更是五花八門。這為網絡運維人員處理數據的工作造成了很大的麻煩,不得不耗費大量的時間和精力去閱讀設備廠商的 Netconf 文檔,去編寫大量的正則表達式。

還有,雖然主流的 SDN Controller 的南向接口都支持 Netconf,但是在實際部署時,卻無法用單一的 Controller 去控制多廠商的網絡設備。通常都是各個廠商使用自己的 SDN Controller 控制自己的設備,然后再用 REST API 與用戶的 SDN Controller 對接。

上文所提到的網絡運維人員所關心的 9 大問題,Netconf 幾乎都能滿足,但距離完全滿足還有一些差距。

有一個解決辦法,就是利用 NAPALM。

NAPALM

NAPALM 是一個 Python 庫,它的全稱是 Network Automation and Programmability Abstraction Layer with Multivendor support,多廠商支持的網絡自動化和可編程抽象層。

目前 Ansible 集成了 3 個 NAPALM 模塊,分別是:

○napalm_parse_yang:用于從設備或文件中解析配置/狀態數據

○napalm_diff_yang:用于比較 2 個 YANG 對象的差異

○napalm_translate_yang:用于將 YANG 對象轉譯成設備原始的配置

從設備取出原始配置數據/狀態數據之后,可以使用 NAPALM 將其翻譯成標準格式的 NAPALM 數據。反之,也可以將標準格式的 NAPALM 數據翻譯成設備原始配置數據,并 Push 到網絡設備里面,以修改設備的配置文件。

讀到這里,也許您已經猜到我將要說什么了……

是的,NAPALM 還是不能徹底解決網絡自動化所面臨的問題。

因為各廠商 Netconf 的數據表達存在很多差異,所以 NAPALM 必須要依賴第三方的 Module 來完成原始數據的解析和翻譯。如果要解析廠商 A 的某個 OS 系統的配置,就需要一個 OSA_Module;如果要解析廠商 B 的某個 OS 系統的配置,則需要 OSB_Module。所以目前 NAPALM 支持的 OS 類型還比較少,僅限于某幾個國外品牌廠商的 OS 系統。

即使是這幾個國外品牌廠商,NAPALM 目前也無法實現完整的功能集。所以 Google 等網絡設備的大用戶一直在致力于推廣一個能夠替代 Netconf 的標準化接口: OpenConfig。

IETF 已經為 Netconf 和 YANG Model 發布了很多 RFC,從 2006 年的 Netconf RFC 4741,2010 年的 YANG Model RFC 6020,到現在已經超過 10 年。而最新的一個 RFC 在什么時候呢?就在幾天之前的 2018 年 4 月 3 日,3 家設備廠商聯合提交了一個 OSPF YANG Model 的草案 —— 標準化的進展太慢了。

也許,這就是問題所在 —— Netconf 標準是由網絡設備廠商推動的,內耗太大。各個設備廠商都希望在軟件定義網絡的時代繼續保持硬件設備的重要性,并且能夠體現自己公司產品的差異化優勢。

但是從網絡運維者的角度考慮,這顯然不合理,因為設備廠商所推動的 Netconf 標準并不是他們真正想要的。所以 Google,AT&T,British Telecom,Facebook,Apple,Microsoft 等互聯網服務提供商成立了 OpenConfig 工作組,希望提供一個中立于設備廠商的標準 API。目前國內的騰訊、百度和阿里等互聯網服務提供商也已經加入了 OpenConfig 工作組。

OpenConfig 沿用了 Netconf 的協議框架,但是它不太關注底層的數據傳輸,而是更關注上層的數據表達和數據建模。這意味著:不管是 A 廠還是 B 廠,所有的數據都必須符合 OpenConfig YANG Model,并且 Key-Value 都必須是 OpenConfig 所規定的標準格式!

OpenConfig 的另外一個核心要點是:雖然網絡設備可能支持豐富的功能特性,甚至是設備廠商私有的功能特性,但是 OpenConfig 只關心與互聯網行業用戶通用的運維工作和網絡設計工作相關的功能,例如 BGP、OpenFlow、Telemetry 等等。OpenConfig 不會為設備廠商的私有特性定義 YANG Model,也不會為設備廠商所特有的 Key-Value 做定義,所以不會出現不兼容的情況。

但反過來講,OpenConfig 也不會為了兼容某些設備廠商而讓 YANG Model 過于簡單,所以設備廠商需要讓自己的功能滿足 OpenConfig YANG Model 的要求,具備 Model 所定義的所有的 Key,并且能夠為所有的 Key 提供對應的 Value。

在 Key-Value 格式固定之后,網絡運維人員對數據的解析工作就非常方便了。只要網絡設備支持標準的 OpenConfig YANG,NAPALM 就可以對原始數據進行解析,不再依賴第三方 Module 就可以管理多廠商多 OS 的網絡,進而實現真正的網絡自動化

使用 OpenConfig 的另一個好處就是可以簡化 SDN 網絡架構,用戶使用一個控制器集群就可以同時控制多個廠商的網絡設備,不再需要使用設備廠商的商用控制器做中繼。

OpenConfig 工作組在 2015 年已經向 IETF 提交了 2 個 YANG 標準草案,雖然目前還沒有標準的 RFC 發布,但是它現已成為網絡自動化技術的發展趨勢,因此各大網絡設備廠商都開始了 OpenConfig 的開發工作。銳捷的數據中心交換機支持 Netconf YANG 和 OpenConfig YANG,目前正在國內配合公有云提供商進行標準化 SDN 的測試工作。

 

1261作者:華為技術 來源:華為技術 編輯:顧北

 

聲明:①凡本網注明“來源:通信界”的內容,版權均屬于通信界,未經允許禁止轉載、摘編,違者必究。經授權可轉載,須保持轉載文章、圖像、音視頻的完整性,并完整標注作者信息并注明“來源:通信界”。②凡本網注明“來源:XXX(非通信界)”的內容,均轉載自其它媒體,轉載目的在于傳遞更多行業信息,僅代表作者本人觀點,與本網無關。本網對文中陳述、觀點判斷保持中立,不對所包含內容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔全部責任。③如因內容涉及版權和其它問題,請自發布之日起30日內與本網聯系,我們將在第一時間刪除內容。 
熱點動態
普通新聞 中信科智聯亮相2023中國移動全球合作伙伴大會
普通新聞 全球首個基于Data Channel的新通話商用網絡呼叫成功撥通
普通新聞 中國聯通:以優質通信服務 助力“一帶一路”共建繁華
普通新聞 楊杰:未來五年,智算規模復合增長率將超過50%
普通新聞 長沙電信大樓火災調查報告發布:系未熄滅煙頭引燃,20余人被問責
普通新聞 鄔賀銓:生態短板掣肘5G潛能發揮,AI有望成“破局之劍”
普通新聞 工信部:加大對民營企業參與移動通信轉售等業務和服務創新的支持力
普通新聞 摩爾線程亮相2023中國移動全球合作伙伴大會,全功能GPU加速云電腦體
普通新聞 看齊微軟!谷歌表示將保護用戶免受人工智能版權訴訟
普通新聞 聯想王傳東:AI能力已成為推動產業升級和生產力躍遷的利刃
普通新聞 APUS李濤:中國的AI應用 只能生長在中國的大模型之上
普通新聞 外媒:在電池競賽中,中國如何將世界遠遠甩在后面
普通新聞 三星電子預計其盈利能力將再次下降
普通新聞 報告稱華為5G專利全球第1 蘋果排名第12
普通新聞 黨中央、國務院批準,工信部職責、機構、編制調整
普通新聞 榮耀Magic Vs2系列正式發布,刷新橫向大內折手機輕薄紀錄
普通新聞 GSMA首席技術官:全球連接數超15億,5G推動全行業數字化轉型
普通新聞 北京聯通完成全球首個F5G-A“單纖百T”現網驗證,助力北京邁向萬兆
普通新聞 中科曙光亮相2023中國移動全球合作伙伴大會
普通新聞 最高補貼500萬元!哈爾濱市制定工業互聯網專項資金使用細則
通信視界
鄔賀銓:移動通信開啟5G-A新周期,云網融合/算
普通對話 中興通訊徐子陽:強基慧智,共建數智熱帶雨
普通對話 鄔賀銓:移動通信開啟5G-A新周期,云網融合
普通對話 華為輪值董事長胡厚崑:我們正努力將5G-A帶
普通對話 高通中國區董事長孟樸:5G與AI結合,助力提
普通對話 雷軍發布小米年度演講:堅持做高端,擁抱大
普通對話 聞庫:算網融合正值挑戰與機遇并存的關鍵階
普通對話 工信部副部長張云明:我國算力總規模已居世
普通對話 鄔賀銓:我國互聯網平臺企業發展的新一輪機
普通對話 張志成:繼續加強海外知識產權保護工作 為助
普通對話 吳春波:華為如何突破美國6次打壓的逆境?
通信前瞻
亨通光電實踐數字化工廠,“5G+光纖”助力新一
普通對話 亨通光電實踐數字化工廠,“5G+光纖”助力新
普通對話 中科院錢德沛:計算與網絡基礎設施的全面部
普通對話 工信部趙志國:我國算力總規模居全球第二 保
普通對話 鄔賀銓院士解讀ChatGPT等數字技術熱點
普通對話 我國北方海區運用北斗三號短報文通信服務開
普通對話 華為云Stack智能進化,三大舉措賦能政企深度
普通對話 孟晚舟:“三大聚力”迎接數字化、智能化、
普通對話 物聯網設備在智能工作場所技術中的作用
普通對話 軟銀研發出以無人機探測災害被埋者手機信號
普通對話 AI材料可自我學習并形成“肌肉記憶”
普通對話 北斗三號衛星低能離子能譜儀載荷研制成功
普通對話 為什么Wi-Fi6將成為未來物聯網的關鍵?
普通對話 馬斯克出現在推特總部 收購應該沒有懸念了
普通對話 臺積電澄清:未強迫員工休假或有任何無薪假
普通對話 新一代載人運載火箭發動機研制獲重大突破
推薦閱讀

聚焦场景化创新 华为擎云亮相中国联通合作伙伴大会

万里数据库GreatDB亮相上合组织数字经济论坛 与哈萨克斯坦人工智能发展协会签署合作协议

3个月迁移、存储成本直降87%!OceanBase助河北移动酬金业务驶入快车道

新紫光集团三周年:智变跃升,交出硬核答卷

亚信科技:助力马来西亚探寻人工智能“崛起时刻”

友商截单?去看苏超?车主是谁?……雷军回应一切,很全! | 次世代车研所

效率跃升300%?鸿蒙电脑定义AI时代商务办公新体验

闪存普惠,一步到位 | 华为商业市场极简全闪数据中心Pro+重磅发布

开源鸿蒙持续壮大 三大运营商全面入局 多元成果亮相HDC2025

数码视讯助力广东卫视、深圳卫视两个4K超高清频道开播
Copyright @ Cntxj.Net All Right Reserved 通信界 版權所有
未經書面許可,禁止轉載、摘編、復制、鏡像