前幾年大家講 SDN 比較多的是怎樣利用控制器，像 OpenDayLight、ONOS 這些東西，其實(shí)在講怎樣做一個 Driver、怎樣做控制。大概從去年開始，SDN 開始跨入應(yīng)用的時代，現(xiàn)在大家更多地在講實(shí)際要做的事情、應(yīng)用場景是什么。由于大家對 SDN 有多種不同的理解，在本文中我想把話題聚焦一下，落到云數(shù)據(jù)中心的網(wǎng)絡(luò)運(yùn)維這個點(diǎn)上，分享一些運(yùn)維中的實(shí)際例子。沒有大的篇章，只說說我們遇到的那些苦與樂。

因?yàn)楸疚脑掝}的場景是云數(shù)據(jù)中心，所以我們有必要先看一下云數(shù)據(jù)中心里面的網(wǎng)絡(luò)是什么樣子。

簡單來說，云數(shù)據(jù)中心的網(wǎng)絡(luò)環(huán)境發(fā)生了如上圖所示的三大變化，網(wǎng)絡(luò)由物理的變?yōu)樘摂M的;流量由南北的變成了東西的;配置由靜態(tài)的變成了動態(tài)的。以前數(shù)據(jù)中心的網(wǎng)絡(luò)比較簡單，那時數(shù)據(jù)中心的網(wǎng)絡(luò)運(yùn)維也比較干凈;后來隨著虛擬化技術(shù)的進(jìn)入，這個網(wǎng)絡(luò)變得復(fù)雜起來。由于業(yè)務(wù)形態(tài)和網(wǎng)絡(luò)模型的變化，流量隨之由南北向?yàn)橹髯兂闪藮|西向?yàn)橹?，這個變化也是目前運(yùn)維技術(shù)特別頭疼的題目。***一個讓運(yùn)維人員頭疼的變化是，網(wǎng)絡(luò)配置的變更隨著業(yè)務(wù)的發(fā)展已經(jīng)變得動態(tài)且無休止。

此外，眾所周知還有一些中國特色的網(wǎng)絡(luò)，比如互聯(lián)互通的問題，以及抗 DDoS 的產(chǎn)品和服務(wù)需求巨大。本文試圖厘清在這樣的網(wǎng)絡(luò)環(huán)境下怎樣解決運(yùn)維的難題。

那些熟悉的“車禍現(xiàn)場”

讓我們先看幾個運(yùn)維人員特別熟悉的“車禍現(xiàn)場”吧。

***個比較常見的問題是沒有收到報警但是用戶報障。當(dāng)然，這并不是云數(shù)據(jù)中心網(wǎng)絡(luò)特有的現(xiàn)象，只不過是在云數(shù)據(jù)中心這個問題更加突出。以前運(yùn)維看到的網(wǎng)絡(luò)是“租戶—數(shù)據(jù)中心—運(yùn)營商”，現(xiàn)在看到的網(wǎng)絡(luò)在數(shù)據(jù)中心和租戶之間多了一個“云平臺”——這里增加了一個復(fù)雜的拓?fù)鋵?。一般情況下網(wǎng)絡(luò)和服務(wù)器可能是兩個團(tuán)隊，現(xiàn)實(shí)情況下網(wǎng)絡(luò)的健壯性要高于服務(wù)器，當(dāng)出現(xiàn)網(wǎng)絡(luò)風(fēng)暴的時候，***被打趴下的往往是服務(wù)器——以及上面的租戶。這就是為什么網(wǎng)絡(luò)沒有報警而用戶卻在報障。

第二個問題是常見的 Loading 故障定位。運(yùn)維人員經(jīng)常要和開發(fā)團(tuán)隊去討論到底是網(wǎng)絡(luò)的問題還是應(yīng)用的問題，往往耗費(fèi)很大精力比如用數(shù)據(jù)證明交換機(jī)上沒有 error、能否看到 TCP 會話、甚至借助 Web 統(tǒng)計工具的結(jié)果來區(qū)分故障邊界。

[[182400]]

第三個常見的問題是 UDP 4789。盡管 VxLAN 已經(jīng)標(biāo)準(zhǔn)化并且很多地方都在用，但實(shí)際上網(wǎng)絡(luò)運(yùn)維人員并不能看到 HTTP、DNS、ARP 等包頭信息。這也給運(yùn)維工作帶來了很大的挑戰(zhàn)。

第四個常見的問題略坑。運(yùn)維人員在故障響應(yīng)的時候，往往會在交換機(jī)上做一些臨時的變更，比如創(chuàng)建一個 SVI、增/減一個 VLAN 之類;在應(yīng)急處理完畢之后常常忘記回滾這些操作，“手術(shù)后不小心留在患者體內(nèi)的紗布”在未來的某一天就會變身成新的故障。道理都懂，“我們應(yīng)該用自動化、用機(jī)器減少這些人為的失誤”。

第五個常見的問題是環(huán)路。網(wǎng)絡(luò)風(fēng)暴在虛擬網(wǎng)絡(luò)里會進(jìn)一步放大，尤其是虛擬交換機(jī)的性能和物理交換機(jī)無法相比，本來不足以構(gòu)成威脅的問題此時也成了大問題。

第六個常見的問題是后端主機(jī)莫名故障。排查下來發(fā)現(xiàn)很可能是因?yàn)?DNS 配置不當(dāng)所致;其他還有一些常見問題諸如 IP 的管理、多線接入流量統(tǒng)計的問題等等，本文不再贅述。

一個真實(shí)的部署場景

下面介紹一個實(shí)際的部署場景。

我們要面對的通常是基于 OpenStack 或者 VMWare 的云環(huán)境。控制器通過云平臺的網(wǎng)絡(luò)模塊如 Neutron、NSX 來獲取我們想要的項(xiàng)目、資源和網(wǎng)絡(luò)的元數(shù)據(jù)，比如物理服務(wù)器、租戶、Subnetwork 等。除了元數(shù)據(jù)，我們還會獲取交換機(jī)的配置和狀態(tài)信息。此外我們還會通過分光或鏡像的方式獲取一些網(wǎng)包，一般來講云的環(huán)境里會有較多的網(wǎng)絡(luò)重疊，我們需要全量的包頭以保留更多的信息。

總體來說交換機(jī)上的信息都是傳統(tǒng)網(wǎng)工所熟悉的。通過控制器 Web 頁面，我們可以對服務(wù)器(比如 KVM 宿主機(jī))上的虛擬交換機(jī)執(zhí)行自動化網(wǎng)絡(luò)診斷，例如最基本的虛擬端口 VLAN 配置正確性檢查等;對于虛擬機(jī)之間的東西向流量，我們可以在宿主機(jī)上插入 DFI 內(nèi)核模塊，或者在服務(wù)器上啟動一個虛擬機(jī)用于數(shù)據(jù)采集，這樣就能拿到 OvS 的全部網(wǎng)包了。拿到數(shù)據(jù)之后我們選擇輸出網(wǎng)流(當(dāng)然我們也可以輸出網(wǎng)包)，為什么是網(wǎng)流呢?

因?yàn)榇蠖鄶?shù)情況下理想和現(xiàn)實(shí)是有差距的：對于網(wǎng)絡(luò)監(jiān)控來說，服務(wù)器往往不會預(yù)留端口，又或者網(wǎng)卡不夠用。而轉(zhuǎn)成網(wǎng)流之后的數(shù)據(jù)量非常小(當(dāng)然這會占用生產(chǎn)網(wǎng)絡(luò)的一點(diǎn)點(diǎn)帶寬)，這樣我們就可以把采集到的信息導(dǎo)給監(jiān)控網(wǎng)絡(luò)了。當(dāng)需要更細(xì)粒度分析的時候我們可以選擇輸出網(wǎng)包。這里的網(wǎng)流你可以認(rèn)為是為云數(shù)據(jù)中心定義的增強(qiáng)版 NetFlow。***一步是網(wǎng)流吐到分析節(jié)點(diǎn)進(jìn)行更多的處理。

說到網(wǎng)流，不得不說包頭，這個在下面的篇幅展開。

起承轉(zhuǎn)合四式組合拳

多數(shù)人面對的也不可能都是 BAT 那么大量級的服務(wù)器，我們的 DeepFlowTM 云網(wǎng)分析最小可以支持一臺交換機(jī)、一臺 2U 高密度服務(wù)器(一個控制器三個節(jié)點(diǎn))。在本文所述的部署場景中，當(dāng)用戶報障的時候我們可以通過一下簡單的四步操作，快速定位問題。

1. 首先控制器 Web 頁面上可以觸發(fā)對 OvS 的自動化網(wǎng)絡(luò)檢查，把排障范圍進(jìn)一步縮小。
2. 其次可以集中執(zhí)行多個端口的網(wǎng)絡(luò)監(jiān)聽，這有點(diǎn)像 Splunk 的做法，將信息匯總分析。
3. 當(dāng) tcpdump 依然無法定位故障的時候，我們可以通過在 OvS 上構(gòu)造一個包，通過分析回包定位故障;這里有技術(shù)挑戰(zhàn)的地方在于回包不能對虛擬機(jī)的業(yè)務(wù)有實(shí)際的影響。
4. ***當(dāng)我們排除了 Overlay 網(wǎng)絡(luò)層面的問題后，可以通過關(guān)聯(lián) Underlay 網(wǎng)絡(luò)路徑進(jìn)一步對物理網(wǎng)絡(luò)進(jìn)行檢查。

通過以上四步檢測，多數(shù)情況下故障都能被排查到。這樣該網(wǎng)絡(luò)處理的問題就網(wǎng)絡(luò)團(tuán)隊解決，是應(yīng)用出現(xiàn)的問題就找開發(fā)團(tuán)隊處理去吧。

云網(wǎng)分析的技術(shù)棧

雖然目前運(yùn)維界都在談自動化，但我們希望更進(jìn)一步——要有一個智能的解決方案，這樣運(yùn)維人員才能有一個好的睡眠。經(jīng)過幾年的摸爬滾打和不懈的努力，我們基于 Flow 的原理設(shè)計了這樣一個技術(shù)棧，如圖所示這是一個閉環(huán)。

幾年之前大家談的控制器，開源 Driver(OpenDayLight、ONOS等) 其實(shí)已經(jīng)做的挺好了，但他們并不是 product ready 的。我們做 DeepFlowTM 是限定在云數(shù)據(jù)中心網(wǎng)絡(luò)監(jiān)控分析的應(yīng)用場景之下，控制器把從網(wǎng)流特征中提取出來的配置 deploy 到生產(chǎn)網(wǎng)絡(luò)中。

基于 OvS 比較常見的 DPDK、FD.io 最近也很流行，在協(xié)議棧部分我們專注在高性能方面。同樣的網(wǎng)絡(luò)環(huán)境，我們利用高性能技術(shù)可以更快、更多地采集到數(shù)據(jù)。

在大數(shù)據(jù)方面，我們主要是通過實(shí)時流處理和機(jī)器學(xué)習(xí)技術(shù)，從中提取特征并反饋給控制器部分。就這樣，從一段數(shù)據(jù)中提取特征、制定規(guī)則、下發(fā)網(wǎng)絡(luò)、再觀察/采集數(shù)據(jù)，如此循環(huán)。

關(guān)于大數(shù)據(jù)分析

我們做了一些基礎(chǔ)的工作來解決運(yùn)維場景的問題。比如前面提到由于 SVI 帶來的 IP 沖突問題、網(wǎng)絡(luò)的環(huán)路、審計日志等問題。關(guān)于大規(guī)模實(shí)時流處理業(yè)界已經(jīng)講過太多，本文從略。從網(wǎng)工的角度，我們并不關(guān)心 Payload 文件的內(nèi)容。但是在虛擬化網(wǎng)絡(luò)中細(xì)粒度計量變得比較困難，Netflow 已經(jīng)無法滿足。前面提過，在 OvS 層我們會把一個 Flow 對應(yīng)的近百個字段完整地采集下來，通過和云平臺對接實(shí)現(xiàn)映射關(guān)系的還原后再分析，能輕松應(yīng)對 ECMP、浮動 IP 等應(yīng)用場景。

以大家熟知的 IPv4 希爾伯特圖為例，DeepFlowTM 提供的 IP 活躍度功能即可實(shí)現(xiàn)類似的展現(xiàn)：用戶可自行設(shè)定某個網(wǎng)段，網(wǎng)段中所有IP地址的活躍時長或分配量可輕松地全局展示。

關(guān)于包頭

從監(jiān)控分析的角度來說，業(yè)界已經(jīng)做到了 DPI 的層面，似乎很難再做出什么有新意的東西，但業(yè)務(wù)在不斷變化，對網(wǎng)絡(luò)監(jiān)控的需求也是水漲船高。我們從軟件的角度做了基于 X86、可擴(kuò)展的高性能。

為什么我們能在一條很微小的 Flow 里保存那么多的字段數(shù)據(jù)?從包到流的聚合最重要的是壓縮比。我們能做到對同一個 Flow 在不追求***性能的前提下壓縮比達(dá)到90%以上。在現(xiàn)在主流硬件設(shè)備的默認(rèn)配置下，我們處理數(shù)據(jù)的能力是 100Gbps 起，存儲時間是30天起。對網(wǎng)絡(luò)故障的歷史回溯能力自然不可同日而語。

作者簡介：向陽，云杉網(wǎng)絡(luò)研發(fā)總監(jiān)、網(wǎng)絡(luò)架構(gòu)師。2013年獲清華大學(xué)計算機(jī)科學(xué)與技術(shù)博士學(xué)位，師從吳建平教授并獨(dú)立實(shí)現(xiàn)了世界上***個基于關(guān)聯(lián)分析的 BGP 劫持檢測系統(tǒng)，因此摘得 Internet Measurement Conference( IMC，網(wǎng)絡(luò)測量領(lǐng)域國際***會議)社區(qū)貢獻(xiàn)獎。2015年獲得清華大學(xué)博士后證書，主要研究方向?yàn)樵茢?shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)，獲得了多項(xiàng)網(wǎng)絡(luò)安全、云數(shù)據(jù)中心相關(guān)專利。2013年起加入云杉，負(fù)責(zé)云杉 DeepFlowTM 云網(wǎng)分析的架構(gòu)設(shè)計和核心功能實(shí)現(xiàn)。