《怎樣構建基于SDN網絡的自動化運維系統？》要點：
本文介紹了怎樣構建基于SDN網絡的自動化運維系統？，希望對您有用。如果有疑問，可以聯系我們。

作者簡介：

張永福

大河云聯 資深網絡架構師

一名從事傳統網絡工作十幾年的老網工,從網絡產品代理商到系統集成商再到 CISCO 廠商,始終未能逃脫出火熱的一線,最終還是只懂的搬磚,不懂java、Python 等高級技能.為了能解放自己,解放更多的一線運維人員,從2016年6月開始加入大河云聯從事 SDN 網絡相關工作,專注于 SDN 網絡自動化運維架構設計.

前言

我是來自大河云聯的張永福,今天的下午場是基礎架構.之前五六年的時間,我一直在 Cisco 廠商做運維,去年加入大河云聯做SDN網絡架構設計和自動化運維系統設計.構建基于SDN網絡的自動化運維系統這個話題談得有點早,SDN 在中國剛剛起步,明年和后年,會有更多人接觸到 SDN 這個新技術的運維.希望更多現有的運維人員可以參與到 SDN 網絡運維,使中國的 SDN 更快的發展.

今天分享以下幾部分內容：

1. 網絡技術演講
2. 傳統網絡運維現狀
3. SDN 網絡運維
4. SDN 自動化運維
5. SDN 運維體系架構

1、網絡技術演進

1.1 歷史回顧

網絡已經發展了幾十年,我們進行簡單梳理,可以分為如下三個階段.

• 第一階段,是從七幾年到八幾年,這個階段網絡正在做什么?1974年開始,TCP/IP 協議的發布,開始了如何讓網絡更大范圍連接的工作.
• 第二階段,從1995年開始做快速以太網標準,1997年IETF成立MPLS工作組.在第二階段中,2005年對于中國網絡是很關鍵的一年,這一年中國電信?CN2?開始一期建設.在這一年出現電信級以太網概念,對大部分人可能不太熟悉這個名詞,但它確實是里程碑式的概念提出.2005年左右,全球骨干網絡基礎建設大規模興起.
• 第三階段,2006年 SDN 誕生,2006年至今,SDN 的概念提出已有11年時間,在中國商用落地的項目并不多.2009年的時候,Openflow1.0 正式發布,在全球掀起了一陣風潮,大家好像看到一絲希望,網絡開始改變了.Openflow1.0 發布后,接著幾年沒有任何動作.2011年開始 ONF 的成立帶動了一把新的浪潮,2012年谷歌B4全面運行,2013年 OpenDaylight 發布,2014年 ONOS 發布.各行各業的玩家開始進入SDN領域.

1.2 SDN的興起

左側 Linux 基金會、ONF、ON.LAB,是國際知名的三個 SDN 相關的組織.中間部分是開源項目,包括 ONOS、ODL、OPNFV,現在 ONAP 正在進行 OPEN-O 和 ECOMP 兩個項目的代碼合并.

右側是相關廠商,包括 Barefoot、bigswitch等,這些都是做SDN芯和盒子的硬件廠商.這幾年,這些國際部分SDN發展都很快,最右側是近幾年的初創公司,包括Viptela、velocloud,最后兩個是做CX、IX、DX業務.

在國際上,不管是開源組織、開源項目、初創公司還是與SDN相關的項目,在國內發展確實比較緩慢,我沒有列出國內SDN相關的公司,能商用落地的少之又少.

2、傳統網絡運維現狀

SDN 運維到底涉及什么?傳統網絡運維,滿墻的運維規章制度只是給人看的,能真正落實執行多少,大家比較清楚.貼了再多的制度,而網絡運維人員在做什么呢?

針對不同廠商的硬件設備敲不同的命令行,從 Cisco、juniper、到華為、華三,變化的只是換一種命令show / display 、no/undo.網絡運維在整個運維體系里背鍋背得最嚴重,上層業務出現問題,會時不時的把這個鍋扔到網絡運維,網絡運維沒地方扔,要么自己背,要么挖掘機來背.

運維部門每天在制定不同的規章制度,有些規模的會有自己的開發人員對開源軟件和開源產品做二次開發.這些年,我一直參與大型網絡的運維,幾年前接觸過一個典型的網絡運維部門,開始他們團隊只有十幾人,當四五年后,業務系統變得更復雜,網絡設備涉及的種類越來越多,運維人員也越來越多,基本翻了兩倍.他們在做的就是 7*24 小時值班監控,告警不斷的響.不停的寫各種故障報告,編出各種各樣的故障報告模板.這是我們正常網絡運維在做的事情,這也是傳統運維的現狀.

3、SDN網絡運維

3.1 DCN網絡架構變遷

網絡在發生什么樣的變化?我們只能看到網絡的變化,才能看到網絡運維需要對應做什么變化.

這是 DCN 網絡架構變遷,也是典型傳統的三層組網拓撲,相信大部分網絡運維人員現在維護的網絡基本上都是這種網絡.

這是基于 FABIC 設計的虛擬網絡架構,接觸 SDN 比較多的人應該知道這張圖,這是 Facebook 前幾年提出的DCN架構圖,現在 Facebook 已經實現了基于 FABIC 的架構設計.為什么采用這種方式,原因是現在 CLOUD、NFV 等虛擬化技術發展太快.

普通的三層組網架構無法滿足現有的虛擬化業務發展.本來云就是一個很復雜的虛擬化架構,無法用傳統網絡架構支撐它,于是慢慢衍生出基于FABIC這樣的軟硬結合的虛擬網絡架構.

3.2 骨干網絡架構發展

骨干網絡技術演進,我們今天主要說的是區域骨干網絡架構系統.

這是中國某張骨干網架構圖,大概是二期的.本圖發展將近10年,有變化嗎?有,增加了點和線,看上去更像一張蜘蛛網.

這是基于?SDN?設計的網絡架構圖,也可以在?internet?上找到,這是?Google?前幾年的設計圖.底層是轉發網元,分為不同的?Site,中間是控制面.在中間層的時候,controller?使用不同的功能模塊實現對底層網元的控制.流量的調度和優化在最上層的?TE server?上做.

3.3 SDN NetDevOps

網絡工程師對 DevOps 的理解不如做系統開發的工程師,這里就需要不同工種的協同工作.上面是 DevOps 能力環,從規劃、代碼到測試、發布完成一個全流程閉環,另外一個是 DevOps 關聯的的研發、測試和運維三個部門工作關聯圖,交集的地方就是 DevOps.

重點談談 Network,這是針對后續幾年,相信在國內是很大的空缺.DevOps 面向的人群更多的是系統開發、系統運維,原有的網絡系統是屬于傳統網工做的.

現在國內傳統網工會腳本的都不多,能否讓傳統網絡和 DevOps 結合起來?答案是可以,現有的傳統網絡可以和 DevOps 結合,形成 NetDevOps.在 SDN 出現后,NetDevOps 可以發揮更大的優勢.

在?SDN?系統里,有獨立的中央控制器和上層應用層,轉發層只是作為最底層的數據轉發,業務編排在控制器做,控制器是純軟件系統,這套系統可以實現對外API對接,這時候?DevOps?可以真正體現出價值.

傳統網絡如何和?DevOps?結合?現有的傳統網絡設備是閉環系統,目前大部分的網絡設備還是基于?CLI?命令行,新的硬件?OS?系統支持?PCEP、NETCONF?等協議,DevOps?和?Network?只能結合到這里,無法跟業務層做關聯和適配.

3.4 SDN的運維工作

SDN 運維工作,主要包括兩方面,一是日常運維工作,二是工程項目.日常運維工作和現在傳統網絡的運維相似,包括值班監控、一二線故障處理、各種會議、各種報告以及跨部門溝通.

重點是跨部門溝通,如果你現在從事傳統網絡運維,你打交道的部門是有限的,這是一個相對封閉的部門.它跟上層、應用部門的關聯度很低,SDN化后會涉及很多部門,因為 SDN 的運維要參與測試、研發.這時候你的運維要提高一個層面,要更多的跟系統開發、軟件開發做互動,DevOps運維恰好也涵蓋了這三個方面.

運維里還有一個重要的部分,引入工程項目.這里的工程項目指的不是網絡運維、網絡設計的項目,指的是與軟件開發、軟件架構設計以及架構優化相關的,統稱為工程項目.

新的功能開發包括已有功能開發優化,這部分是網絡運維在做的.這個部門是由網工和軟工組成的SDN運維部門,也可以是一個虛擬團隊,這樣的工種搭配在SDN運維里非常常見.

在去年以前,谷歌 SRE 很出名,SRE 的書翻譯成中文,至今非常火.建議做網絡運維的人可以看看這本書.這本書提到這兩部分,里面有一段話說得特別好“任何一個運維工程師要有50%的時間用來開發、寫代碼”.

在SDN里,不僅僅是網絡設備,不需要你直接敲命令、登陸設備,他的操作、運維、管理很多要靠系統完成,系統是需要開發的.如果你的大部分時間被日常運維占用,犧牲的是你的經驗.

3.5 SDN運維工具

SDN 運維的常用工具,在傳統運維和系統運維也會使用,包括 Cacti、Smokeping、Nagios、Zabbix,我們更傾向于開源,傳統網絡更傾向于閉源,需要網絡工程師學習更多的開源軟件,自己做二次開發,做出適合自己日常運維的工具.

4、SDN自動化運維

運維包括告警監控、統計分析、運維自動化和運維系統的建設.SDN自動化運維系統,這個系統并不是一個平臺、一個工具,而是一個體系、一個方法.平臺是運維系統的一部分,運維自動化完全跟開發相關,它不在平臺內,平臺內更多的是監控告警、統計分析,做到運維系統的建設.運維自動化更多的與 DevOps 相關.

4.1 運維服務質量設計

運維服務質量,在傳統的網絡運維里,網絡工程師經常提出 SLA.作為運維人員沒必要關心 SLA,SLA 是服務質量協議.運維人員需要關注的是 SLI 和 SLO,我們需要找到服務質量的指標是什么,根據指標制定目標.

至于SLA,這是和用戶之間承諾遵守的協議,我們在傳統網絡里更多的關心網絡時延和網絡丟包率,我們需要考量更多的服務指標,很多跟上層應用做關聯.

網絡時延、丟包率以及端到端都可以作為衡量的指標,我們根據這個指標制定SLO,例如,你的時延要少于50毫秒,可用性要大于99.9%,這是運維人員需要關注的部分.

4.2 監控告警設計

運維平臺、運維系統里涉及的內容,一是監控告警設計,通常從最底層的采集、存儲、功能模塊開發、上層告警通道、用戶側.從采集來講,如果運維只是IDC或者城域網,這時候你需要集中采集、集中存儲.

如果你維護的是全國性乃至全球性的網絡,你需要分布式采集.現在大河云聯的SDN控制器管理著分布在全球將近100個轉發節點,對于這種規模,無法采用集中式,需要根據自己的業務分布點,制定不同區域性的分布采集,包括存儲.部署中央存儲和分布式存儲,分布采集后實時同步到中央存儲,同時需要在本地存儲后做備份.

功能模塊方面,只提到數據分析,為什么監控告警和告警通道之間增加了一層分析,你在底層做采集的時候,采集的是原始數據,規則是通過原有系統的規則,從監控告警到告警通道,做一個中間層,這是根據自己網絡情況做的自定義的規則.

4.3 監控告警分析

告警統計分析,拿到告警原始數據后,如何更好的展現出來,如何把有用的信息實時同步.實時告警不像傳統網絡只有底層轉發,這涉及業務系統的實時監控和網元實時監控,包括操作系統穩定性的監控,都會統一的在一個監控平臺做.

告警統計,需要對所有告警信息做分類管理,只有把有用的信息分類后,才能進行第二步分析.報表管理,很多 SLI 和 SLO 的來自于報表,不管是設備、鏈路、系統的可用性從何而來,這是通過告警統計分析報表功能輸出,你可以定月、定周對設備、鏈路做SLA需要的統計.

4.4 日志統計分析

日志統計分析,(左圖)引用了沒有做二次開發的圖,很多公司都在用ELK,這是ELK的分析功能,可以針對自己的業務系統做不同的定制開發,可以制定住不同的統計分析模塊.

日志包括全套SDN系統,從上層控制系統,中層操作系統、存儲、業務編排,底層轉發網元,這里的網元包括多種類型,最后是底層傳輸.這是傳統網絡不會涉及的,傳統網絡的網絡運維人員只會關注網絡設備,在 SDN 系統里,日志采集以及運維管理包含底層傳輸和上層應用.

4.5 流量統計分析

流量統計分析,現在網管系統和運維人員關注設備流量、端口流量,SDN 需要關注整條鏈路端口,更重要的是業務流量,SDN 最大的特點是能夠跟業務系統做到關聯,能夠通過運維系統查看所有業務相關的流量信息.

4.6 系統分析

系統分析,對于大部分運維人員來說比較容易理解,這是物理服務器資源和操作系統資源.

這幾個片子重點是 DevOps,控制器的開發和上線,用了這幾年比較熱的精益管理、敏捷開發,相信在座了解很多.

持續交付,指的是 SDN 控制器系統的持續交付,做到版本的快速迭代和實時響應,利用流程管理來打破研發、測試、運維之間的隔離墻.與運維相關的是自動化部署、自動化測試和集成測試.

自動化部署,可以集成到自動化運維平臺里,可以作為一個模塊集成到運維系統里,從發布、部署到交付運行,可以采用輕量簡潔的工具,例如目前比較流行的 ansible.

自動化測試,測試分為兩部分,一是自動化測試,二是集成測試.自動化測試主要對控制器開發、代碼的邏輯性,更多的是與研發部門的溝通.

集成測試,這比 DevOps 提到的多一個集成測試,因為 SDN 運行場景更多的轉發面的設計.自動化測試是驗證代碼的邏輯性,對部分場景需要用集成測試完成,包括功能性測試、異常測試和場景回歸.

5、SDN運維體系架構

自動化運維架構體系,前面已經提到了很多內容了在這里做以架構概覽做下總結.

目前從SDN系統來講從最底層的資源,網絡設備、轉發網元、設備、服務器,采集部分開始,主要涵蓋 SNMP 的采集,對傳統設備 Netconf 命令下發,對新設備 Openflow 的協議,對CLI的管理.

中間的存儲是獨立分開的,中間有日志、配置庫、知識庫,在存儲部分獨立分開.功能方面包括監控告警和數據采集,數據分析和統計,流程管理和項目管理,有很大一部分是資源管理,資源管理包括文檔配置,這部分主要基于CMDB,功能非常強大,如何結合SDN系統用起來,要根據自己網絡底層和控制器開發做制定.

故障自愈和關聯分析,如何讓告警信息形成關聯,出現10個告警時,能否在你的手機或者郵件上看到10個告警,真正有用的只有1個.故障自愈系統是在關聯分析后實現的,當出現10個故障,如何讓故障自動消失,不需要人為干預管理,這是自愈的功能.另外需要有安全策略貫通底層和上層.告警渠道可以包括郵件、WBE、微信、Call Center等.最上層為不同的權限用戶入口.

故障處理流程,在大部分的網絡運維里只有第一項,運維中心在做的是受理用戶故障申告以及接收監控系統告警,自動化運維平臺流程里會增加故障自愈系統,根據場景開發定制,輸出處理建議.

當你今天收到用戶和系統的申告,如何讓告警下一次不再出現,這需要我們工程師制定這樣的場景,根據處理邏輯形成閉環,逐步的完善自動化運維系統.

原文來自微信公眾號：高效運維

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/2387.html