云數據中心網絡運維的苦與樂
前幾年大家講 SDN 比較多的是怎樣利用控制器，像 OpenDayLight、ONOS 這些東西，其實在講怎樣做一個 Driver、怎樣做控制。大概從去年開始，SDN 開始跨入應用的時代，現在大家更多地在講實際要做的事情、應用場景是什么。由于大家對 SDN 有多種不同的理解，在本文中我想把話題聚焦一下，落到云數據中心的網絡運維這個點上，分享一些運維中的實際例子。沒有大的篇章，只說說我們遇到的那些苦與樂。
因為本文話題的場景是云數據中心，所以我們有必要先看一下云數據中心里面的網絡是什么樣子。
簡單來說，云數據中心的網絡環境發生了如上圖所示的三大變化，網絡由物理的變為虛擬的;流量由南北的變成了東西的;配置由靜態的變成了動態的。以前數據中心的網絡比較簡單，那時數據中心的網絡運維也比較干凈;后來隨著虛擬化技術的進入，這個網絡變得復雜起來。由于業務形態和網絡模型的變化，流量隨之由南北向為主變成了東西向為主，這個變化也是目前運維技術特別頭疼的題目。***一個讓運維人員頭疼的變化是，網絡配置的變更隨著業務的發展已經變得動態且無休止。
此外，眾所周知還有一些中國特色的網絡，比如互聯互通的問題，以及抗 DDoS 的產品和服務需求巨大。本文試圖厘清在這樣的網絡環境下怎樣解決運維的難題。
那些熟悉的“車禍現場”
讓我們先看幾個運維人員特別熟悉的“車禍現場”吧。
***個比較常見的問題是沒有收到報警但是用戶報障。當然，這并不是云數據中心網絡特有的現象，只不過是在云數據中心這個問題更加突出。以前運維看到的網絡是“租戶—數據中心—運營商”，現在看到的網絡在數據中心和租戶之間多了一個“云平臺”——這里增加了一個復雜的拓撲層。一般情況下網絡和服務器可能是兩個團隊，現實情況下網絡的健壯性要高于服務器，當出現網絡風暴的時候，***被打趴下的往往是服務器——以及上面的租戶。這就是為什么網絡沒有報警而用戶卻在報障。
第二個問題是常見的 Loading 故障定位。運維人員經常要和開發團隊去討論到底是網絡的問題還是應用的問題，往往耗費很大精力比如用數據證明交換機上沒有 error、能否看到 TCP 會話、甚至借助 Web 統計工具的結果來區分故障邊界。
第三個常見的問題是 UDP 4789。盡管 VxLAN 已經標準化并且很多地方都在用，但實際上網絡運維人員并不能看到 HTTP、DNS、ARP 等包頭信息。這也給運維工作帶來了很大的挑戰。
第四個常見的問題略坑。運維人員在故障響應的時候，往往會在交換機上做一些臨時的變更，比如創建一個 SVI、增/減一個 VLAN 之類;在應急處理完畢之后常常忘記回滾這些操作，“手術后不小心留在患者體內的紗布”在未來的某一天就會變身成新的故障。道理都懂，“我們應該用自動化、用機器減少這些人為的失誤”。
第五個常見的問題是環路。網絡風暴在虛擬網絡里會進一步放大，尤其是虛擬交換機的性能和物理交換機無法相比，本來不足以構成威脅的問題此時也成了大問題。
第六個常見的問題是后端主機莫名故障。排查下來發現很可能是因為 DNS 配置不當所致;其他還有一些常見問題諸如 IP 的管理、多線接入流量統計的問題等等，本文不再贅述。
一個真實的部署場景
下面介紹一個實際的部署場景。
我們要面對的通常是基于 OpenStack 或者 VMWare 的云環境。控制器通過云平臺的網絡模塊如 Neutron、NSX 來獲取我們想要的項目、資源和網絡的元數據，比如物理服務器、租戶、Subnetwork 等。除了元數據，我們還會獲取交換機的配置和狀態信息。此外我們還會通過分光或鏡像的方式獲取一些網包，一般來講云的環境里會有較多的網絡重疊，我們需要全量的包頭以保留更多的信息。
總體來說交換機上的信息都是傳統網工所熟悉的。通過控制器 Web 頁面，我們可以對服務器(比如 KVM 宿主機)上的虛擬交換機執行自動化網絡診斷，例如最基本的虛擬端口 VLAN 配置正確性檢查等;對于虛擬機之間的東西向流量，我們可以在宿主機上插入 DFI 內核模塊，或者在服務器上啟動一個虛擬機用于數據采集，這樣就能拿到 OvS 的全部網包了。拿到數據之后我們選擇輸出網流(當然我們也可以輸出網包)，為什么是網流呢?
因為大多數情況下理想和現實是有差距的：對于網絡監控來說，服務器往往不會預留端口，又或者網卡不夠用。而轉成網流之后的數據量非常小(當然這會占用生產網絡的一點點帶寬)，這樣我們就可以把采集到的信息導給監控網絡了。當需要更細粒度分析的時候我們可以選擇輸出網包。這里的網流你可以認為是為云數據中心定義的增強版 NetFlow。***一步是網流吐到分析節點進行更多的處理。
說到網流，不得不說包頭，這個在下面的篇幅展開。
起承轉合四式組合拳
多數人面對的也不可能都是 BAT 那么大量級的服務器，我們的 DeepFlowTM 云網分析最小可以支持一臺交換機、一臺 2U 高密度服務器(一個控制器三個節點)。在本文所述的部署場景中，當用戶報障的時候我們可以通過一下簡單的四步操作，快速定位問題。
- 首先控制器 Web 頁面上可以觸發對 OvS 的自動化網絡檢查，把排障范圍進一步縮小。
- 其次可以集中執行多個端口的網絡監聽，這有點像 Splunk 的做法，將信息匯總分析。
- 當 tcpdump 依然無法定位故障的時候，我們可以通過在 OvS 上構造一個包，通過分析回包定位故障;這里有技術挑戰的地方在于回包不能對虛擬機的業務有實際的影響。
- ***當我們排除了 Overlay 網絡層面的問題后，可以通過關聯 Underlay 網絡路徑進一步對物理網絡進行檢查。
通過以上四步檢測，多數情況下故障都能被排查到。這樣該網絡處理的問題就網絡團隊解決，是應用出現的問題就找開發團隊處理去吧。
云網分析的技術棧
雖然目前運維界都在談自動化，但我們希望更進一步——要有一個智能的解決方案，這樣運維人員才能有一個好的睡眠。經過幾年的摸爬滾打和不懈的努力，我們基于 Flow 的原理設計了這樣一個技術棧，如圖所示這是一個閉環。
幾年之前大家談的控制器，開源 Driver(OpenDayLight、ONOS等) 其實已經做的挺好了，但他們并不是 product ready 的。我們做 DeepFlowTM 是限定在云數據中心網絡監控分析的應用場景之下，控制器把從網流特征中提取出來的配置 deploy 到生產網絡中。
基于 OvS 比較常見的 DPDK、FD.io 最近也很流行，在協議棧部分我們專注在高性能方面。同樣的網絡環境，我們利用高性能技術可以更快、更多地采集到數據。
在大數據方面，我們主要是通過實時流處理和機器學習技術，從中提取特征并反饋給控制器部分。就這樣，從一段數據中提取特征、制定規則、下發網絡、再觀察/采集數據，如此循環。
關于大數據分析
我們做了一些基礎的工作來解決運維場景的問題。比如前面提到由于 SVI 帶來的 IP 沖突問題、網絡的環路、審計日志等問題。關于大規模實時流處理業界已經講過太多，本文從略。從網工的角度，我們并不關心 Payload 文件的內容。但是在虛擬化網絡中細粒度計量變得比較困難，Netflow 已經無法滿足。前面提過，在 OvS 層我們會把一個 Flow 對應的近百個字段完整地采集下來，通過和云平臺對接實現映射關系的還原后再分析，能輕松應對 ECMP、浮動 IP 等應用場景。
以大家熟知的 IPv4 希爾伯特圖為例，DeepFlowTM 提供的 IP 活躍度功能即可實現類似的展現：用戶可自行設定某個網段，網段中所有IP地址的活躍時長或分配量可輕松地全局展示。
關于包頭
從監控分析的角度來說，業界已經做到了 DPI 的層面，似乎很難再做出什么有新意的東西，但業務在不斷變化，對網絡監控的需求也是水漲船高。我們從軟件的角度做了基于 X86、可擴展的高性能。
為什么我們能在一條很微小的 Flow 里保存那么多的字段數據?從包到流的聚合最重要的是壓縮比。我們能做到對同一個 Flow 在不追求***性能的前提下壓縮比達到90%以上。在現在主流硬件設備的默認配置下，我們處理數據的能力是 100Gbps 起，存儲時間是30天起。對網絡故障的歷史回溯能力自然不可同日而語。
作者簡介：向陽，云杉網絡研發總監、網絡架構師。2013年獲清華大學計算機科學與技術博士學位，師從吳建平教授并獨立實現了世界上***個基于關聯分析的 BGP 劫持檢測系統，因此摘得 Internet Measurement Conference( IMC，網絡測量領域國際***會議)社區貢獻獎。2015年獲得清華大學博士后證書，主要研究方向為云數據中心網絡架構，獲得了多項網絡安全、云數據中心相關專利。2013年起加入云杉，負責云杉 DeepFlowTM 云網分析的架構設計和核心功能實現。
