淺談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的管理。
SDN運維體系架構
中間的儲存是獨立分開的，中間有日誌、配置庫、知識庫，在儲存部分獨立分開。功能方面包括監控告警和資料採集，資料分析和統計，流程管理和專案管理，有很大一部分是資源管理，資源管理包括文件配置，這部分主要基於CMDB，功能非常強大，如何結合SDN系統用起來，要根據自己網路底層和控制器開發做制定。
SDN現在越被大多數公司採用，那對於企業來說如何培養出一個合適的SDN運維小能手呢?一般公司會選擇培訓現有的員工，因為他們覺得培訓現有員工比尋找和招聘新員工更具經濟效益。投資現有員工需要積極主動的自上而下戰略，提供大量培訓機會。其次從個人的角度來說網路專業人士應該把握好自己的未來和職業生涯。並不是每個網工都需要成為程式設計師。相反，SDN需要更廣泛的網路概念和基礎知識。要理解軟體系統是如何工作的，但並不意味著你必須編寫程式碼，可需要了解整個生態系統是如何運作的，以及事情是在哪裡完成的。除了這些基礎知識，網路專業人員還應利用任何學習的機會，建議網路專業人士在制定計劃後需要堅持下去。仔細規劃並專注於自己的軌跡，不要被外界情況所影響。