《怎樣構(gòu)建基于SDN網(wǎng)絡(luò)的自動化運維系統(tǒng)？》要點：
本文介紹了怎樣構(gòu)建基于SDN網(wǎng)絡(luò)的自動化運維系統(tǒng)？，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者簡介：

張永福

大河云聯(lián) 資深網(wǎng)絡(luò)架構(gòu)師

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

前言

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

今天分享以下幾部分內(nèi)容：

1. 網(wǎng)絡(luò)技術(shù)演講
2. 傳統(tǒng)網(wǎng)絡(luò)運維現(xiàn)狀
3. SDN 網(wǎng)絡(luò)運維
4. SDN 自動化運維
5. SDN 運維體系架構(gòu)

1、網(wǎng)絡(luò)技術(shù)演進

1.1 歷史回顧

網(wǎng)絡(luò)已經(jīng)發(fā)展了幾十年,我們進行簡單梳理,可以分為如下三個階段.

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

1.2 SDN的興起

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

右側(cè)是相關(guān)廠商,包括 Barefoot、bigswitch等,這些都是做SDN芯和盒子的硬件廠商.這幾年,這些國際部分SDN發(fā)展都很快,最右側(cè)是近幾年的初創(chuàng)公司,包括Viptela、velocloud,最后兩個是做CX、IX、DX業(yè)務(wù).

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

2、傳統(tǒng)網(wǎng)絡(luò)運維現(xiàn)狀

SDN 運維到底涉及什么?傳統(tǒng)網(wǎng)絡(luò)運維,滿墻的運維規(guī)章制度只是給人看的,能真正落實執(zhí)行多少,大家比較清楚.貼了再多的制度,而網(wǎng)絡(luò)運維人員在做什么呢?

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

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

3、SDN網(wǎng)絡(luò)運維

3.1 DCN網(wǎng)絡(luò)架構(gòu)變遷

網(wǎng)絡(luò)在發(fā)生什么樣的變化?我們只能看到網(wǎng)絡(luò)的變化,才能看到網(wǎng)絡(luò)運維需要對應(yīng)做什么變化.

這是 DCN 網(wǎng)絡(luò)架構(gòu)變遷,也是典型傳統(tǒng)的三層組網(wǎng)拓撲,相信大部分網(wǎng)絡(luò)運維人員現(xiàn)在維護的網(wǎng)絡(luò)基本上都是這種網(wǎng)絡(luò).

這是基于 FABIC 設(shè)計的虛擬網(wǎng)絡(luò)架構(gòu),接觸 SDN 比較多的人應(yīng)該知道這張圖,這是 Facebook 前幾年提出的DCN架構(gòu)圖,現(xiàn)在 Facebook 已經(jīng)實現(xiàn)了基于 FABIC 的架構(gòu)設(shè)計.為什么采用這種方式,原因是現(xiàn)在 CLOUD、NFV 等虛擬化技術(shù)發(fā)展太快.

普通的三層組網(wǎng)架構(gòu)無法滿足現(xiàn)有的虛擬化業(yè)務(wù)發(fā)展.本來云就是一個很復(fù)雜的虛擬化架構(gòu),無法用傳統(tǒng)網(wǎng)絡(luò)架構(gòu)支撐它,于是慢慢衍生出基于FABIC這樣的軟硬結(jié)合的虛擬網(wǎng)絡(luò)架構(gòu).

3.2 骨干網(wǎng)絡(luò)架構(gòu)發(fā)展

骨干網(wǎng)絡(luò)技術(shù)演進,我們今天主要說的是區(qū)域骨干網(wǎng)絡(luò)架構(gòu)系統(tǒng).

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

這是基于?SDN?設(shè)計的網(wǎng)絡(luò)架構(gòu)圖,也可以在?internet?上找到,這是?Google?前幾年的設(shè)計圖.底層是轉(zhuǎn)發(fā)網(wǎng)元,分為不同的?Site,中間是控制面.在中間層的時候,controller?使用不同的功能模塊實現(xiàn)對底層網(wǎng)元的控制.流量的調(diào)度和優(yōu)化在最上層的?TE server?上做.

3.3 SDN NetDevOps

網(wǎng)絡(luò)工程師對 DevOps 的理解不如做系統(tǒng)開發(fā)的工程師,這里就需要不同工種的協(xié)同工作.上面是 DevOps 能力環(huán),從規(guī)劃、代碼到測試、發(fā)布完成一個全流程閉環(huán),另外一個是 DevOps 關(guān)聯(lián)的的研發(fā)、測試和運維三個部門工作關(guān)聯(lián)圖,交集的地方就是 DevOps.

重點談?wù)?Network,這是針對后續(xù)幾年,相信在國內(nèi)是很大的空缺.DevOps 面向的人群更多的是系統(tǒng)開發(fā)、系統(tǒng)運維,原有的網(wǎng)絡(luò)系統(tǒng)是屬于傳統(tǒng)網(wǎng)工做的.

現(xiàn)在國內(nèi)傳統(tǒng)網(wǎng)工會腳本的都不多,能否讓傳統(tǒng)網(wǎng)絡(luò)和 DevOps 結(jié)合起來?答案是可以,現(xiàn)有的傳統(tǒng)網(wǎng)絡(luò)可以和 DevOps 結(jié)合,形成 NetDevOps.在 SDN 出現(xiàn)后,NetDevOps 可以發(fā)揮更大的優(yōu)勢.

在?SDN?系統(tǒng)里,有獨立的中央控制器和上層應(yīng)用層,轉(zhuǎn)發(fā)層只是作為最底層的數(shù)據(jù)轉(zhuǎn)發(fā),業(yè)務(wù)編排在控制器做,控制器是純軟件系統(tǒng),這套系統(tǒng)可以實現(xiàn)對外API對接,這時候?DevOps?可以真正體現(xiàn)出價值.

傳統(tǒng)網(wǎng)絡(luò)如何和?DevOps?結(jié)合?現(xiàn)有的傳統(tǒng)網(wǎng)絡(luò)設(shè)備是閉環(huán)系統(tǒng),目前大部分的網(wǎng)絡(luò)設(shè)備還是基于?CLI?命令行,新的硬件?OS?系統(tǒng)支持?PCEP、NETCONF?等協(xié)議,DevOps?和?Network?只能結(jié)合到這里,無法跟業(yè)務(wù)層做關(guān)聯(lián)和適配.

3.4 SDN的運維工作

SDN 運維工作,主要包括兩方面,一是日常運維工作,二是工程項目.日常運維工作和現(xiàn)在傳統(tǒng)網(wǎng)絡(luò)的運維相似,包括值班監(jiān)控、一二線故障處理、各種會議、各種報告以及跨部門溝通.

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

運維里還有一個重要的部分,引入工程項目.這里的工程項目指的不是網(wǎng)絡(luò)運維、網(wǎng)絡(luò)設(shè)計的項目,指的是與軟件開發(fā)、軟件架構(gòu)設(shè)計以及架構(gòu)優(yōu)化相關(guān)的,統(tǒng)稱為工程項目.

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

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

在SDN里,不僅僅是網(wǎng)絡(luò)設(shè)備,不需要你直接敲命令、登陸設(shè)備,他的操作、運維、管理很多要靠系統(tǒng)完成,系統(tǒng)是需要開發(fā)的.如果你的大部分時間被日常運維占用,犧牲的是你的經(jīng)驗.

3.5 SDN運維工具

SDN 運維的常用工具,在傳統(tǒng)運維和系統(tǒng)運維也會使用,包括 Cacti、Smokeping、Nagios、Zabbix,我們更傾向于開源,傳統(tǒng)網(wǎng)絡(luò)更傾向于閉源,需要網(wǎng)絡(luò)工程師學(xué)習(xí)更多的開源軟件,自己做二次開發(fā),做出適合自己日常運維的工具.

4、SDN自動化運維

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

4.1 運維服務(wù)質(zhì)量設(shè)計

運維服務(wù)質(zhì)量,在傳統(tǒng)的網(wǎng)絡(luò)運維里,網(wǎng)絡(luò)工程師經(jīng)常提出 SLA.作為運維人員沒必要關(guān)心 SLA,SLA 是服務(wù)質(zhì)量協(xié)議.運維人員需要關(guān)注的是 SLI 和 SLO,我們需要找到服務(wù)質(zhì)量的指標是什么,根據(jù)指標制定目標.

至于SLA,這是和用戶之間承諾遵守的協(xié)議,我們在傳統(tǒng)網(wǎng)絡(luò)里更多的關(guān)心網(wǎng)絡(luò)時延和網(wǎng)絡(luò)丟包率,我們需要考量更多的服務(wù)指標,很多跟上層應(yīng)用做關(guān)聯(lián).

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

4.2 監(jiān)控告警設(shè)計

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

如果你維護的是全國性乃至全球性的網(wǎng)絡(luò),你需要分布式采集.現(xiàn)在大河云聯(lián)的SDN控制器管理著分布在全球?qū)⒔?00個轉(zhuǎn)發(fā)節(jié)點,對于這種規(guī)模,無法采用集中式,需要根據(jù)自己的業(yè)務(wù)分布點,制定不同區(qū)域性的分布采集,包括存儲.部署中央存儲和分布式存儲,分布采集后實時同步到中央存儲,同時需要在本地存儲后做備份.

功能模塊方面,只提到數(shù)據(jù)分析,為什么監(jiān)控告警和告警通道之間增加了一層分析,你在底層做采集的時候,采集的是原始數(shù)據(jù),規(guī)則是通過原有系統(tǒng)的規(guī)則,從監(jiān)控告警到告警通道,做一個中間層,這是根據(jù)自己網(wǎng)絡(luò)情況做的自定義的規(guī)則.

4.3 監(jiān)控告警分析

告警統(tǒng)計分析,拿到告警原始數(shù)據(jù)后,如何更好的展現(xiàn)出來,如何把有用的信息實時同步.實時告警不像傳統(tǒng)網(wǎng)絡(luò)只有底層轉(zhuǎn)發(fā),這涉及業(yè)務(wù)系統(tǒng)的實時監(jiān)控和網(wǎng)元實時監(jiān)控,包括操作系統(tǒng)穩(wěn)定性的監(jiān)控,都會統(tǒng)一的在一個監(jiān)控平臺做.

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

4.4 日志統(tǒng)計分析

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

日志包括全套SDN系統(tǒng),從上層控制系統(tǒng),中層操作系統(tǒng)、存儲、業(yè)務(wù)編排,底層轉(zhuǎn)發(fā)網(wǎng)元,這里的網(wǎng)元包括多種類型,最后是底層傳輸.這是傳統(tǒng)網(wǎng)絡(luò)不會涉及的,傳統(tǒng)網(wǎng)絡(luò)的網(wǎng)絡(luò)運維人員只會關(guān)注網(wǎng)絡(luò)設(shè)備,在 SDN 系統(tǒng)里,日志采集以及運維管理包含底層傳輸和上層應(yīng)用.

4.5 流量統(tǒng)計分析

流量統(tǒng)計分析,現(xiàn)在網(wǎng)管系統(tǒng)和運維人員關(guān)注設(shè)備流量、端口流量,SDN 需要關(guān)注整條鏈路端口,更重要的是業(yè)務(wù)流量,SDN 最大的特點是能夠跟業(yè)務(wù)系統(tǒng)做到關(guān)聯(lián),能夠通過運維系統(tǒng)查看所有業(yè)務(wù)相關(guān)的流量信息.

4.6 系統(tǒng)分析

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

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

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

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

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

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

5、SDN運維體系架構(gòu)

自動化運維架構(gòu)體系,前面已經(jīng)提到了很多內(nèi)容了在這里做以架構(gòu)概覽做下總結(jié).

目前從SDN系統(tǒng)來講從最底層的資源,網(wǎng)絡(luò)設(shè)備、轉(zhuǎn)發(fā)網(wǎng)元、設(shè)備、服務(wù)器,采集部分開始,主要涵蓋 SNMP 的采集,對傳統(tǒng)設(shè)備 Netconf 命令下發(fā),對新設(shè)備 Openflow 的協(xié)議,對CLI的管理.

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

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

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

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

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

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/2387.html