作者簡介：

張天鵬（Neeke），雲杉網路聯合創始人兼CTO

負責公司的產品和技術研發工作，曾任美國 Juniper 公司高階研發經理，負責當時世界最大防火牆 SRX 的研發。專注於 SDN、NFV 和雲端計算領域的相關產品和技術，對於 SDN 在雲端計算業務中的實施和應用有豐富的經驗。

一、背景介紹

在這幾年和各個雲的對接以及面向我們的客戶、合作伙伴，幫他們解決網路故障檢修以及提供網路的整體方案過程中，我們深切的感受到如果想給一個雲提供一個高質量的 SLA 是非常不容易的。

今天我們聚焦在一個很小的點，即如何用 Flow 的技術去做網路的虛擬化、視覺化並提高運維效率以及解決雲的內網安全的問題。

二、業務雲化的三大難題

雲的網路實際上是從傳統的業務網路不斷的向雲端遷移和演進的過程。相比傳統 IT 架構而言，雲非常大，要解決網路虛擬化必須引入 SDN、OpenFlow 或者各種比較複雜的技術。事實上，從邏輯上，資料中心、雲平臺、租戶網路是緊密耦合在一起的。

舉一個例子，兩個 VM 的通訊有可能是在一個伺服器內部，也有可能跨了機櫃甚至資料中心等等，但是租戶並不關心這個過程，他只關心網路的效能是否OK、連線是否正常。

但云的運維者必須非常瞭解這個過程，否則你就沒有辦法做 trouble shooting。由於雲規模的“大”隨之而來的效能、高可用的難題便浮現出來，具體表現為：

• Scale 的問題：一般雲的規模都會比較大，比如 100～200 個機櫃左右。
• VTEP 終結點：終結點在 Server/Tor – – 交換機上這會帶來兩個問題，效能和管理的問題。
• 流量模型複雜：網路通訊到底是二層還是三層，等等。

在長時間跟很多雲溝通以後，大家形成了這樣一個共識：在設計雲的網路時，除了生產網路還應該考慮監控網路。

實際上監控網路後端的核心是一個分析平臺，通過探針採集把雲平臺各種流包能夠抓取過來，按照分析需求把採集到的流量匯入相應的分析叢集。但是不同的探針點在雲平臺裡的部署難度是不一樣的：

• 在南北向的介面做流量分光相對容易；
• 在接入層做做流量映象/分光比較難。首先是架構設計上沒有預留映象的介面；其次做分光會引起業務中斷，所以很難實施；
• 在 Open vSwitch 上引流會對租戶網路效能有影響。

在我看來這是一個探針部署的問題，探針的部署應該是非侵入式的，最好是一個開源、開放的框架，這樣 load 會比較輕。

三、雲網分析的設計理念

那麼從運維的角度來說，目前這樣一個 Scale 比較大的網路分析的要求有哪些？

1. 雲網分析的需求

• 視覺化，這裡麵包括虛擬網路和物理網路。什麼意思呢？就是不但能把租戶的拓撲呈現出來，而且能把租戶的流量對映到物理交換機上並做出關聯分析、能做歷史回溯，當有異常發生的時候立刻展現出來。
• 擴充套件性。現在很多市場上的分析的產品，實際上就是一個分析能力有限的盒子，但是雲的規模在不斷擴大，堆盒子的做法顯然是不可持續的，最好的是一個彈性開放的架構；同時能和現有的很多分析工具結合在一起，而不需要自己開發。
• 快速定位。從業務和運維的角度來講，最重要的要把運維和業務的邊界劃分清楚。當別人告訴你出現問題的時候，你能迅速定位出來這是誰的問題。
• 智慧。所謂智慧主要是一個自動化的呈現和報告。我們原來在設計的時候定了一個規格，大概能處理 10,000 個 IP ，但我們有一個 Scale 不大的金融行業客戶的雲裡有 60,000 個 IP 超過 3000 個業務。在這樣的一個場景裡面，他的運維不可能把每一個業務都看一遍，他希望能夠有一些智慧的發現。另外，一些行為分析在做 DPI 的時候也需要智慧的聯動。

2. 技術選型

在不改變原有生產網路的前提下部署監控網路的難點不一而足，具體到我們經歷過的 Case 有以下四個方面需要重點考量。

• 探針的選擇，SFlow、Netflow/IPFIX、分光、映象等各有優缺點。我們要考慮哪一種是最適合自己的。在雲環境裡當一個使用者給你報障的時候，你需要快速定位出來，這個時間不能太長，否則使用者會無法接受。
• 資料的儲存，雲的流量非常大，尤其是東西向的流量。基礎設施應該有能力做一些處理，再把流量送到後端。如果沒有這種基礎架構，現有的分析工具很難進行工作。
• 多分析工具的支援，由於客戶現有的業務和運維環境，我們不可能要求客戶更改或重新開發相關的工具和外掛，因此必須支援原有的分析工具。
• 雲感知與流量獲取，在虛擬化環境裡面資源經常在發生遷移，你怎麼跟雲的平臺資源做聯動，然後感知到目前問題發生的原因。

我們選擇用 Flow 的方式來處理，根據我們的實踐 Flow 做雲網分析有較大的優勢。並且我們通過分析從 Flow 中採集到的資料，發現很多有意思的事情。

• 輕量，Flow 只把五元組、連線狀態、位元組數、握手關閉、持續時間等資訊，大概一個 Flow 有幾百個位元組。
• 適合行為分析，按需與 DPI 結合。
• 隱私安全，無需看使用者資料。

用 Flow 做雲網分析的過程中，一個很關鍵的技術點是探針。

四、 軟體定義探針

通過 SDN 的能力我們把智慧探針（Traffic Intelligence）部署在生產網路中，使用 Flow 的技術我們能及時發現哪些流量有問題，一旦發現有問題便拎出它的包再放大——採用 DPI 分析。整個過程不看使用者的 payload 檔案而只看 Packet “指紋”特徵，這便是我們的 SDN。

這個是我們的一個軟體架構，最底層是 Flow 的採集，這其中有一個快取，在上面是資料關聯，實際上資料從採集一直到展示出來是一個層層處理的過程。

當資料處理到達 Elastic Search 以後，我們對上提供 Restful API，這樣使用者自己可以開發應用或者第三方的合作伙伴一起開發應用，從而更好地利用我們的分析結果。

說了這麼多，還是舉個例子證明一下吧。首先是我們與合作伙伴對上海一家客戶幾個月的 Flow 資料做了點分析。

在這些 Flow 資料上做了大概 22 種攻擊流量建模，得出來的其中一個結果就是這樣。這個圖下半部分大家能看到紅線的資料是 0、藍線是有數值的，這股流量只進不出，說明這是網路攻擊。大家再對比一下這幅圖中間部分的正常流量曲線資料，實際上底部所示的攻擊流量是非常的小。

這其實更說明了我們 Flow 分析的價值，因為在一個雲的內部網路流量非常大，而我們能從如此巨大的流量（上百G）中發現細微的流量（幾個包、1000 多個位元組）異常。經過我們這麼一查，使用者的問題就找到了。

綠盟基於我們的分析平臺把各種安全模型全部統計出來，最典型的像檢測 DDOS 攻擊和惡意掃描。

但是這兩種攻擊是完全不一樣。DDOS 攻擊流量大很容易被發現，而惡意掃描通常都是非常小的一個包，比如一個雲網絡裡面有三臺虛擬機器給每個人的遠端桌面（3389 埠）發了一個包，雖然只有三個包，但是這種行為很惡劣，在這種情況下把它檢測出來其實難度還是比較大的。