怎樣構建基於SDN網絡的自動化運維系統？

本文來自：http://greatops.net/?id=189

前言

我是來自大河雲聯的張永福，今天的下午場是基礎架構。之前五六年的時間，我一直在 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等。最上層為不同的權限用戶入口。

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

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