作者簡介：

張永福

大河雲聯 資深網路架構師

一名從事傳統網路工作十幾年的老網工，從網路產品代理商到系統整合商再到 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等。最上層為不同的許可權使用者入口。

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

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

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