淺談SDN架構下的運維工做

導讀	目前國內的網絡運維還處於初級階段，工做人員天天就像救火同樣，每天疲於奔命。運維人員只能埋頭查找系統運行的日誌，耗時耗力，老眼昏花不說，有時候忙了半天還一無所得，做爲運維工程師的你，有木有遇到過相似苦逼的經歷?

目前國內的網絡運維還處於初級階段，工做人員天天就像救火同樣，每天疲於奔命。「什麼破網絡怎麼又斷了」，「我去，服務器宕機啊」，「這個網速慢的跟烏龜爬的同樣」，這些埋怨聲天天都在運維人員耳邊迴盪。運維人員只能埋頭查找系統運行的日誌，耗時耗力，老眼昏花不說，有時候忙了半天還一無所得，做爲運維工程師的你，有木有遇到過相似苦逼的經歷?

傳統網絡的運維痛點

傳統的網絡運維天天都是針對不一樣的廠商設備敲不一樣的命令行，從 Cisco、Juniper、到華爲、華三，變化的只是換一種命令show / display 、no/undo。網絡管理分散，網絡和雲管平臺、安全、IT/業務系統互相獨立，須要分別維護，效率低;網絡結構，配置、拓撲、鏈路狀態的不可視化，運維人員只能依賴經驗和記憶，變動調整網絡，這爲網絡留下了大量隱患;管理模式單一，基於單設備或單機架構管理，錯漏多、排障難等等。當網絡出現問題時，公司的各個大小部門都在埋怨運維部門，但是運維人員也很無辜，天天面對繁雜的工做不說，最後出了問題也只能「打碎牙齒和着血往肚子裏面咽」，成了名符其實的「背鍋俠」。

運維部門天天都要制定不一樣的規章制度，較大規模的公司會有本身的開發人員對開源軟件和開源產品作二次開發。在傳統的網絡中，隨着企業業務上漲，該公司的網絡運維部門規模也會跟着擴大。一個典型的網絡運維部門，開始團隊只有十幾人，當四五年後，業務系統變得複雜，網絡設備涉及的種類愈來愈多，運維人員也愈來愈多，基本翻了兩倍。他們天天都須要7*24小時值班，哪怕是已經下班回家的工做人員也是手機不離身。處理舊的故障時會有故障模板。當遇到新的故障時，除了要辛辛苦苦找方法解決，最後還要再寫新的故障模板。因而，運維人員的故障模板庫愈來愈來越長，愈來愈複雜。然只能嘆息「吾心甚累!」

網絡的發展

網絡在發生什麼樣的變化?咱們只能看到網絡的變化，才能看到網絡運維須要對應作什麼變化。

從1974年TCP/IP協議的發佈，到今天的SDN,網絡技術一直在發展。在這期間產生了快速以太網、MPLS、SDN技術、Openflow 1.0以及後續的版本、Open Daylight的發佈等，促進了網絡的發展。

20世紀60年代，不少大學和研究機構都在致力於新的通訊技術，其中有一家美國國防部最爲突出，當時爲實現迂迴的通訊傳輸方式，分組交換方式便應運而生了。到20世紀60年代下半葉，已有大量的人員投入分組交換和分組通訊的研究中。後來爲給互聯計算機中提供可靠的通訊，到1982年全球性的組織提出了TCP/IP協規範，1990年左右不管是局域網仍是廣域網，都開始傾向TCP/IP協議。

互聯網投入商用是從1995年開始，當時互聯網服務供應商數目劇增，1996年IPv6規範出爐，載入RFC。

1995年開始作快速以太網標準，1997年IETF成立MPLS工做組。2005年中國出現了電信級以太網概念，同年，全球骨幹網絡基礎建設大規模興起。

2006年了SDN 誕生，從誕生至今，在中國商用落地的項目並很少。2009年的時候，Openflow1.0 正式發佈，在全球掀起了一陣風潮，你們開始意識到網絡要改變了。2011年開始 ONF 的成立又掀起另外一股浪潮。2012年穀歌B4全面運行，2013年 OpenDaylight 發佈，2014年 ONOS 發佈。各行各業的玩家開始進入SDN領域。

那SDN是什麼

SDN是Software Defined Network的縮寫，也就是軟件定義網絡。SDN是一種網絡架構，將網絡的控制平面與轉發平面分離，並經過開放和可編程接口直接對控制平面進行編程。SDN的核心理念就是但願經過應用程序來控制轉發行爲，徹底經過軟件來定義整個網絡。

SDN架構分爲應用層，控制層和基礎設施層：

應用層包括各類不一樣的業務和應用，負責各類網絡資源的編排;
控制層也就是SDN的控制軟件，負責處理各類數據轉發資源，維護網絡拓撲、狀態信息，進行網絡全局管理;
基礎設施層包含了各類網絡設備，負責數據的處理、轉發和狀態收集。
SDN是對現有網絡架構從新構建的技術。傳統網絡架構是由交換器、路由器等網絡基礎設施定義的網絡流量的傳輸，就像城市道路上的車流同樣，在沒有GPS導航前，每一個十字路口如何轉向，基本是司機根據當前看到的狀況走自認爲最短最好的路徑，但高峯時段每每塞成一鍋粥。而SDN是從全城動態交通情況，根據每輛車的需求(如時間最短、費用最省、不走高速等)來安排調度每輛車如何到達目的地，從全局視角調度，也保證了每輛車的最優線路。

SDN技術因其架構的開放性和靈活部署及編程能力，成爲下一代網絡核心技術的首選。不管是Google對於其DC(數據中心)系統完成的SDN改造，仍是IT巨頭微軟和阿里巴巴分享的SDN雲服務經驗，無一例外都爲此技術的應用描繪了美好的前景。基於SDN的網絡虛擬化，可以將業務的邏輯網絡拓撲與物理網絡拓撲解耦，極大提高業務交付速度，簡化網絡運維，同時可以知足運營商、政企對於下降網絡成本、提高業務創新速度的訴求。

SDN給運維帶來的優點

傳統網絡由具備集成控制和數據轉發平面的設備組成，所以每一個盒子都須要獨立配置和管理。即便對網絡進行簡單更改也可能須要數週甚至數月才能完成，由於必須對每臺設備進行更改。但隨着物聯網(IoT)，雲計算和移動性的興起，SDN架構中控制和數據平面的分離使控制可以從設備中抽象出來並集中化，以便網絡管理員能夠集中控制管理底層複雜基礎設施。從理論上講，全部網絡節點只須要轉發或數據平面來推送數據包。SDN給運維帶來的優點具體以下：

減小開銷

因爲網絡管理員再也不須要從一個設備到另外一個設備來更改網絡配置，所以他們能夠更有效地進行必要的更改。不只能夠經過集中控制有效地控制網絡配置，還能夠自動化許多配置。

總體的集中式網絡管理

SDN方法的最大好處之一是能夠經過單個設備控制全部網絡組件。物理和虛擬設備均可以經過單個API進行控制，使得網絡管理員的生活更加輕鬆。

啓用「無網絡影響的網絡實驗「

SDN爲網絡帶來的靈活性容許管理員「跳過」SNMP所施加的限制並嘗試網絡配置，而網絡也不會受到影響。

更詳細，粒度安全

虛擬化，雲計算和移動設備爲信息安全帶來了重大挑戰。SDN控制器提供單點控制，其中信息安全策略和規則能夠在整個組織中分發。此外，SDN控制器還提供了一個附加點，能夠放置安全策略來解決特定的軟件和應用程序漏洞。

提升應對網絡威脅的能力

SDN經過爲IT人員提供網絡活動的實時可見性，幫助他們應對安全事件。您還能夠對網絡進行編程，以自動響應某些類型的事件，從而減輕人爲依賴。例如，假設有一臺筆記本電腦檢測到有人正在發送惡意軟件或攻擊另外一個系統。SDN容許您對網絡進行編程，以根據設備地址或應用程序等屬性有選擇地阻止特定流量。

提升對網絡的可見度

總體提升組織網絡的可見性是軟件定義網絡的最大好處之一。首先，集中控制能夠識別網絡安全性，性能和挑戰。全部這些均可以在不干擾網絡活動的狀況下進行分析。經過找出帶寬或安全挑戰的源頭，能夠在網絡中斷以前防止中斷和停機。

可擴展性

此外，這種集中化的靈活性容許包含更多選項，由於SDN容許程序員編寫公共接口並管理多個設備，而無需瞭解網絡上每一個設備的複雜功能。

更有效地使用網絡資源

在傳統網絡中，肯定數據如何傳播的網絡控制平面位於硬件中。在SDN基礎設施中，控制平面是獨立於網絡硬件操做的軟件功能。這種網絡和數據控制平面的邏輯分離使SDN可以支持高級應用和服務，包括大數據分析，同時跟上不斷增加的網絡服務需求。

提升正常運行時間和可靠性

SDN程序內置的靈活性和冗餘能夠消除在部署網絡期間可能發生的人爲錯誤。此外，SDN支持大多數物理和虛擬網絡設備的虛擬化，容許您在網絡的一個組件上執行升級或替換，而無需使整個系統脫機。在發生停機時，SDN支持對配置進行快照，從而能夠快速地從升級致使的中斷中恢復。

網絡的將來將愈來愈依賴於軟件，SDN在應對傳統網絡方法所面臨的許多挑戰方面邁出了一大步。IT經過提升可見性和安全性，同時簡化和自動化操做，將網絡運營帶到現代領域。

SDN運維工具的改變

在傳統網絡運維中，運維規章制度定了那麼多，運維人員能作到的其實也就那麼多，針對不一樣廠商的硬件設備敲不一樣的命令行，出現問題查查日誌，寫寫故障報告。SDN網絡的主要特色是集羣化、採虛擬的軟件網絡數據流，經過圖形化的方式簡易呈現，方便業務上線，以及後期內容的維護。那麼SDN這麼牛，難道就不須要運維工具了嗎，答案固然是否認的!

在 SDN 系統裏，有獨立的中央控制器和上層應用層，轉發層只是做爲最底層的數據轉發，業務編排在控制器作，控制器是純軟件系統，這套系統能夠實現對外API對接，這時候 DevOps 就派上用場了。

DevOps促進開發人員，運營團隊和基礎架構專業人員之間的溝通和協做，以實現統一和自動化的IT開發，實施和管理。同時，SDN容許工程師將軟件控制應用於網絡元素，集中管理和配置大量虛擬和物理基礎架構。

1. SDN與NetDevops相遇

DevOps(Development和Operations的組合詞)是一組過程、方法與系統的統稱，用於促進開發(應用程序/軟件工程)、技術運營和質量保障(QA)部門之間的溝通、協做與整合。它是一種重視「軟件開發人員(Dev)」和「IT運維技術人員(Ops)」之間溝通合做的文化、運動或慣例。透過自動化「軟件交付」和「架構變動」的流程，來使得構建、測試、發佈軟件可以更加地快捷、頻繁和可靠。它的出現使軟件行業日益清晰地認識到：爲了按時交付軟件產品和服務，開發和運營工做必須緊密合做。

2. DevOps和自動化網絡需求

DevOps利用小型applet(或微服務)中應用程序的組件化，這些applet 能夠分佈在一系列數據中心資源(即公共雲或私有云)中。容器(例如，Docker)正在成爲快速引入新微服務流行方式。

微服務和DevOps應用程序須要快速配置計算和存儲網絡資源，使其可以快速運行，根據須要進行擴展，以高可靠性執行並保證服務的安全性。網絡須要管理工具來知足開發和自動化的需求——減小停機時間和處理時的複雜性，同時又不須要發送Opex的數據。。

網絡負責爲DevOps應用程序快速配置適當的資源，並在保護和管理這些快速遷移的應用程序方面發揮關鍵做用。然而，微服務的敏捷性和快速變化的要求挑戰了傳統網絡的能力。應用程序的分解意味着手動網絡的移動部件太多 - 所以網絡自動化相當重要。使用DevOps預先測試網絡資源的能力對於減小應用程序部署時間很是重要(例如，返回修復網絡問題)。基本理想：開發人員沒必要擔憂網絡資源，包括IP地址或防火牆規則。

3. SDN，DevOps和自動化相遇的地方

軟件定義的網絡優化了開發和自動化的網絡，使部署複雜應用程序的IT組織可以快速提供網絡資源和服務(包括安全策略)。SDN支持對網絡進行集中管理，並將(手動)配置的挑戰從人員轉移到技術上，下降運營成本。

基於SDN的網絡能夠自動檢測流量變化，並根據應用類型，服務質量和安全規則等參數選擇經過網絡獲取的路徑數據。軟件控制平面管理和隱藏網絡複雜性，可以使10,000個交換機看起來像一個。SDN能夠指示網絡提供與其相關應用程序一致的服務，並支持快速部署大量新應用程序和微服務(例如，容器)。

SDN提供自動化網絡流程的能力，以快速爲DevOps應用程序提供網絡/安全資源。它能夠經過將(手動)配置的挑戰從人員轉移到技術來下降運營成本。許多超大規模的雲提供商 - 包括谷歌，蘋果，Facebook和微軟 - 已經部署了SDN技術，以幫助自動化其網絡的配置和管理。IT領導者應考慮部署SDN以知足其DevOps團隊和相關應用程序不斷變化的需求。

再談SDN 運維工做，SDN有那麼多優勢，那麼運維工做會不會很輕鬆呢?SDN運維工做主要包含兩個方面，一個是平常運維、二是工程項目。平常運維工做和傳統的網絡運維相似，值班監控，一二線故障解決，以及和各部門溝通。

重點是跨部門溝通，傳統的網絡運維由於不少設備和功能都是相互捆綁的，相關的功能函數並不對外開放，只有設備供應商本身清楚，因此運維經常是一個封閉的部門，和開發並不會有太多的交集。可是進入SDN的時代之後，運維會涉及到不少部門，例如測試、研發等。這時運維已再也不是封閉的，須要從一個新的角度去看待這個崗位，須要提早與開發部門、測試部門的網絡工程師作互動，這一點和DevOps的要求也是很符合的，即爲了按時交付軟件產品和服務，開發和運營工做必須緊密合做。

SDN運維用到的工具和傳統網絡運維相似，主要有 Cacti、Smokeping、Nagios、Zabbix。可是如今更加講究開源，開源更能促進SDN和網絡技術的發展，運維工程師能夠從中學到更多關於網絡的知識，對於網絡會擁有更多的自主管理權，工程師還能夠在開源的軟件上根據本身需求作二次開發，較傳統的封閉式運維大大減小網絡運維成本和提升運維效率。

SDN自動化運維

運維包括告警監控、變動、排障三個階段。在介紹告警以前談一下運維人員須要關心的SLO和SLI,其次會簡要分析監控，分析，變動和排障。

1. 運維服務質量設計

在傳統的網絡運維中，網絡工程師們都關注SLA,但做爲運維的人都會關注SLO和SLI。咱們須要找到服務質量的指標是什麼，根據指標制定目標。SLI是通過仔細定義的測量指標，它根據不一樣系統特色肯定要測量什麼，SLI的肯定是一個很是複雜的過程。SLI要回答要測量的指標是什麼，測量時系統狀態怎麼樣，如何彙總處理測量的指標，測量指標可否描述服務質量，測量指標的可信度。主要關注性能、可用性、質量、內部指標和因素人這幾個方面。SLO(服務等級目標)指定了服務所提供功能的一種指望狀態。SLO裏面應該包含全部可以描述服務應該提供什麼樣功能的信息。服務提供者用它來指定系統的預期狀態;開發人員編寫代碼來實現;客戶依賴於SLO進行商業判斷。SLO裏沒有提到，若是目標達不到會怎麼樣。網絡時延、丟包率以及端到端均可以做爲衡量的指標，咱們根據這個指標制定SLO。

SLA是一個涉及雙方的合約，雙方必須都要贊成並遵照這個合約。當須要對外提供服務時，SLA是很是重要的一個服務質量信號，須要產品和法務部門的同時介入。

2. 監控告警

SDN能更多的進行白盒監控，即經過對系統內部的性能指標進行監控瞭解系統的運行狀態。從南向接口看，SDN只須要監控少數幾種協議，監控相對簡單，而面對業務變動時更是能夠隨着API變動而變動。主要複雜度集中在控制平面和業務編排，監控業主要集中在控制平面健壯性，用戶業務情況以及控制轉發的一致性等方面。在大型網絡裏因底層鏈路故障致使的大量路徑計算和從新優化須要控制及時，反應要快。面向最終用戶的web接口又會須要對各類請求和配置變動作出實時響應和分析。

運維繫統中監控告警設計，一般從最底層的採集開始，自上而下設計，其次是存儲、功能模塊開發、上層告警通道、用戶側。從採集的方式上來講要根據網絡架構來選擇是採用集中式的，仍是分散式的。若是網絡中的轉發節點較多，那麼在這種狀況下就沒法採用集中式。須要根據本身的業務分佈點，制定不一樣區域性的分佈採集，包括存儲。部署中央存儲和分佈式存儲，分佈採集後實時同步到中央存儲，同時須要在本地存儲後作備份。

功能模塊方面經過在底層採集原始數據，根據原有系統的規則，從監控告警到告警通道，作一箇中間層，這網絡管理人員能夠根據本身網絡狀況作的自定義的規則。

拿到原始數據後，如何將數據更好的展示出來，將有用的信息實時同步。SDN中實時告警不像傳統網絡只在底層轉發，如今它能夠對業務系統和網元進行實時監控(操做系統的穩定性)。有了告警信息之後，對它進行分類，而後才能作接下來的告警分析。

3. 日誌統計分析

日誌統計分析，如今大可能是公司都使用ELK來分析。該軟件能夠根據本身的業務作不一樣的開發。

日誌包括整個SDN系統。從上層的控制系統，中層操做系統、存儲、業務編排，底層轉發網元，最後底層傳輸。這些在傳統的網絡中，運維人員是不會關心的，只會關心網絡設備。

4. 流量統計分析

流量統計分析，如今網管系統和運維人員關注設備流量、端口流量，SDN 須要關注整條鏈路端口，更重要的是業務流量，SDN 最大的特色是可以跟業務系統作到關聯，可以經過運維繫統查看全部業務相關的流量信息。

5. 變動

在傳統的網絡中，因爲時間還有業務對網絡不一樣的需求後，很難有統一的配置模板。各類臨時的配置在不一樣的設備上安家。如今的網絡維護人員不敢刪除上一個運維人員的設定。天長日久，人，設備、需求的變換會致使配置和實際情況脫節。SDN則基本擺脫了設備配置問題。基礎架構數據經過自發現和初始定義能夠在GUI上實現。業務數據經過GUI和API實現，軟件升級時，控制平面的前端、後端、業務編排、底層控制器各組件既能夠分開升級也能夠統一升級，對轉發也沒有明顯的影響。

6. 自動化排障

SDN排障更多的是與Devops結合，經過軟件化手段解決。一個好的故障處理系統可以自愈和關聯分析。當出現多個警告時，如何讓這些警告自動關聯，而後生成一個真正一個有用的。故障自愈就是在關聯之後，故障不須要人爲的干預就能夠自愈。

將來傳統的運維人員將何去何從

基於SDN技術的將來電信網絡架構的演進對運維流程產生了深入的影響，電信技術與IT技術的融合對參與系統的運維團隊也提出了技能方面的新要求。

對於SDN的運維人員除了要知道傳統的運維技能和運維工具之外，還要了解SDN運維體系目前從SDN系統來說從最底層的資源，網絡設備、轉發網元、設備、服務器。採集部分主要涵蓋 SNMP 的採集，對傳統設備Netconf命令下發，對新設備 Openflow 的協議，對CLI的管理。

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

SDN如今越被大多數公司採用，那對於企業來講如何培養出一個合適的SDN運維小能手呢?通常公司會選擇培訓現有的員工，由於他們以爲培訓現有員工比尋找和招聘新員工更具經濟效益。投資現有員工須要積極主動的自上而下戰略，提供大量培訓機會。其次從我的的角度來講網絡專業人士應該把握好本身的將來和職業生涯。並非每一個網工都須要成爲程序員。相反，SDN須要更普遍的網絡概念和基礎知識。要理解軟件系統是如何工做的，但並不意味着你必須編寫代碼，可須要瞭解整個生態系統是如何運做的，以及事情是在哪裏完成的。除了這些基礎知識，網絡專業人員還應利用任何學習的機會，建議網絡專業人士在制定計劃後須要堅持下去。仔細規劃並專一於本身的軌跡，不要被外界狀況所影響。

 

本文轉自：https://www.linuxprobe.com/sdn-network.html