Software Switching 優化

最近又看了幾個在twitter上, 關於軟件網絡不規模化, 或是效能不足的爭論. 說實在的, 我覺得這個爭論實在是無意義.  拿軟件網絡跟硬件網絡相比, 就好像拿雞蛋和炸彈相比, 一個是給人吃的,  另一個是要人命的, 風馬牛不相干. 看來看去,  都好像是廠家在市場訊息上,  彼此較勁. 過去我一直想往市場部門移動, 現在想想. 好險沒去成. 當工程師還是比較好, 置身事外看看戲也是不錯, 不然我可能忍不住就會直接在網上罵起髒話來. 我也不要去讚揚或是貶低不同陣營的看法, 對於技術, 我一直希望用客觀和實際應用的場景, 去評斷價值. 畢竟每一條代碼都是工程師用寶貴的時間所寫出來的,  不應該被市場或是銷售等相關議題後的目的, 去被貶低或是傷害. 工程師是一個辛苦且需受人尊敬的職業, 就如當初我第一天加入特戰部隊時, 指揮官說的. 你們的兵種, 是全世界最受尊敬的種類, 不要被別人看不起, 也不要自己褻瀆了你的臂章.

回歸主題,  對於虛擬化之後, 網絡在Hypervisor之內的效能, 被現今網絡或是系統技術人員自動去分割成不同技術領域之後,  這些細節的確是很難在雙方有共識的情況之化去被討論. 所以網絡人員用硬件的架構去看待軟件的網絡技術, 系統軟件人員用不懂網絡佈署的架構角度, 去看待軟件網絡, 說到這邊, 我真對軟件網絡叫屈啊. 軟件網絡弟兄, 你們沉冤太久了.  事實上,  如果你想真的弄清楚軟件網絡的價值,  還真需同時具備多方面的技術知識, 不然在技術討論上很容易就出現盲點或是偏執.

這邊先澄清一個重要的概念,  這之中最大的問題會落在Virtual Machine, Softwre Switching 和Hypervisor System的三角關係. 或是說這因該只是Virtual Machine 和 Hypervisor之間的關係, 因為Software Switching 只是Hypervisor內的一個程序模塊.  基本上, 你可能需要知道,  Virtual Machine只是Hypervisor上的一個應用(Application), 這個應用進行所有的工作都是由Hypervisor 操作系統所支撐的,  也就是說,  當討論到Hypervisor系統優化的時候, 必須以操作系統的角度去思考, 當然這也包含軟件網絡的主題.

在一般x86的系統內, 所有的application其實都是交由CPU作為直接運算處理, 並且由程序來判斷該需要資源或是其他用途的分配. 在一個默認沒有任何優化的狀況下, Hypervisor應用的網絡的程序狀態就會如下圖般：

也就是說,  這其實就是應用(  virtual machine ) 會按照傳統OSI 7 Layer的作法, 並且結合由Hypervisor所提供的網絡程序進行每個layer的數據處理, 當然這些處理全是經過Hypervisor系統程序呼叫CPU的資源進行的. 由於Hypervisor本身需要處理很多程序的, 在加上網絡這個密集的程序請求, CPU的工作自然負擔加重, 網絡效能及穩定當然也就沒那麼好了.

如果想要改善網絡這方面的效能的話, 當然就是找尋一些可以offload系統機制的方式, 只要Hypervisor系統可以了解這些機制, 自然就可以將工作卸載到這些機制上. 今日在Hypervisor上最常見的機制,  無非是使用網卡的TSO, GSO,  LRO等等相關機制. 當然網卡當然必須要能support這些機制,  才能卸載來自於應用 ( virtual machine )的網絡程序請求.

透過Driver與系統的溝通, Hypervisor可以知道有哪些機制可以對網絡數據進行卸載, 從上圖的表示可以看出來, 透過這些機制, 原本需要呼叫Hypervisor網絡程序進行L4～L2的網絡fragmentation的工作, 可以完全卸載到網卡上, 也就是說, 網路程序可以從系統上被縮減, 並且交由網卡進行硬體的處理. 這就是我們常見的TSO機制. 這個方法可以大幅將低CPU對於網絡處理的耗損及透過網卡的處理, 增進Performance.

PS: 每一個L4 Segment最大可支援64K Bytes, 而Ethernet的MTU為1518 Bytes. 一般來說我們計算替換率可能使用一個比較中立的值進行計算, 大約為32K Bytes. 如果以上圖應用數據包 8K來算, 透過TSO可以減少5次對於Hypervisor系統的網絡程序的請求, 降低84%的CPU程序需求對於單一數據.

在實際測試中, 有開啟這個機制和沒開啟, 我個人看過差距最大可以到達6倍左右. 一般來說也有2倍以上的差距,  當然在還是在你使用什麼樣的Hypervisor, 系統規格等等有所不同. 當然這還就算是最佳化了嘛？當然還不是, 因為就算降低了網絡程序對系統的消耗, 但是還是存在網絡程序在CPU上的分配問題, 因為你的網絡流量不是一個8K的數據包而已！！！

一般來說,  當網絡程序被setup之後, 通常是咬在一個CPU被執行, 這樣對於那個CPU來說還是造成一定的負擔, 最終還是影響到網絡效能, 可能導致吞吐到達一個瓶頸點之後就上不去了. 這個問題還是回到了, 網卡的Driver對於CPU工作的分配的優化是沒有信息的, 所以為了要讓網絡的程序可以在CPU之間被負載均衡, 還另外要驅動Receive Side Scaling ( RSS )的機制去驅動負載均衡的工作, 這個部分在我之前的測試上, 有30％的改善增進.
PS: 我使用vSphere 5.5 ＋ NSX vSwitch ＋STT Tunnel, 得到了雙向16Gbps的吞吐量, 對於網絡虛擬化使用隧道來說, 這個值算是相當理想的.

所以如果一台hypervisor可以製造出16Gbps的吞吐量, 那就vSwitch的技術我想就沒有什麼需要好質疑的. 因為vSwitch是支持一台hypervisor上的VM, 並不是一個機櫃上的hypervisor, 這是硬件交換機地盤. 在網絡虛擬化的議題上,  端到端的隧道其實需要透過硬件交換機所建構的高速穩定的IP網絡,  當然如果我拿16Gbps 在Hypervisor優化後的數據去跟一台背板是500Gbps以上ASIC的交換機做比較, 我想我一定是吹到風受寒, 被馬踢到重傷, 被牛頂到內臟破裂, 符合風馬牛的狀態才會做的事.

所以轉發能力,  這點我想短時間內Hypervisor因該還是無法與硬件交換機比擬. 但是如我上述的, 軟件所建構的網絡在利用物理網絡的高轉發性能之後, 與物理網絡設備最大的差異就是在控制平面的規模. 在x86 Server下, 切出一塊256MB的空間作為信息存放是一個極為輕鬆的工作, 但是在物理交換機上, 卻是一個極為昂貴的不可能. 所以對於網絡虛擬化來說, 訴求的是一個控制規模化, 但是效能合理化的組合. 但是硬件網絡追求的是效能極大化但是規模有限的組合, 我相信也很多人不同意這個說法, 因為大家所面臨的問題不一樣, 所以當然看法也不同. 不過軟件網絡的概念其實給傳統網絡的人帶來了一定的思考衝擊,  所以還是一句老話,  守舊沒什麼不好, 不好你就不守了. 創新也沒什麼困難, 怕難就不創新了~ 青菜蘿蔔, 香蕉芭樂～喜歡就好

最後感謝我廣州的同事, Jonathan Peng, 他從Google上發現並且提供給我的這兩張圖, 比我原本自己構思的圖還要好, 這圖真的是很容易的幫助理解.

網路的東西南北

前一陣子連續出差, 加上許多的內部會議, 搞的差點想去撞牆把自己搞昏之後就可以休息一下. 但是家中還有嗷嗷待哺的嬰兒需要爸爸幫他洗屁屁, 所以只有咬牙繼續撐下去.  不過這兩個月來, 不論在公司內部還是外部, 我都收到一樣類似的老問題那就是：（認識我的人都知道, 我現在只有談數據中心的網路比較多)

- SDN和網絡虛擬化有什麼不一樣, 你們為什麼用網絡虛擬化來替代SDN的主題

其實這是一個講了很多年的問題了, 說到鬍鬚打結可能還是說不清楚, 因為在問這個問題的人, 他其實已經接收了部分技術訊息而產生疑惑, 所以如果我還用純協議技術的角度作為討論的切入, 其實只會越搞越混亂.  但是我之前還老是想不通用什麼更好的方法來解釋這個部分, 直到有一天看到麻將的東西南北, 這才給我了一點啟發. 

現在我們先不講上面那兩個是什麼東西, 我們就先討論一下, 我們認識20多年的網絡對於數據交換的路徑是什麼型態？.............................. 還能有什麼型態,  不就是我們傳統認識的三層架構, 數據從access -> distribution -> core layer做數據路徑端到端的交換.  如果你是這樣想, 那你完全命中我想問的問題. 沒錯, 所以你可以很清楚的了解, 今天我們所有的以物理網絡設備為基礎的通信路徑都是以南北向為數據流的方向. 所以L2的通信在跨交換機的時後, 是南北向透過ethernet trunking穿過distrbution layer作為數據交換點, L3通信在跨subnet的時候, 也是通過distrbution/core layer作為南北向的數據交換點, 把問題在延伸的大一點, 你的L4的ACL control 也是透過北向的路由器或是防火牆作為政策過濾的把關者,  執行過濾之後才回歸到南向去. 所以做出一個簡單的總結, 你總是需要有什麼東西在北向幫你作為數據交換/過濾的點, 才能完成你的端到端的通信. 

作為一般用戶網路存取的架構, 上面的三層式架構大概短期也不需要有什麼太大的變化. 作為數據中心內部的需求而言, 尤其是服務器虛擬化後的IAAS數據中心, 這個問題可能就很大了. 我別用太複雜的技術觀點來說明這其中的問題, 只提出兩個問題,  有實務經驗的人馬上就知道這其中的痛苦.

1) 路徑都是通過北向作為數據交換的點, 造成多餘的配置複雜和增加數據旅行的延遲. 

2) 在提供IAAS雲服務的數據中心, 這架構限制的租戶網絡配置的擴展性和之後的一致性. 

所以這也是網絡虛擬化為什麼會在服務器虛擬化市場成熟後的幾年才被大幅討論, 甚至開始應用起來. 因為在虛擬化後的數據中心之內, 南北向的數據交換或是配置的確已經走到了傳統網絡配置的極限, 越來越多的營運問題陸續浮上檯面, 所以才有人開始關注這個議題. 但是網絡虛擬化對於南北向的問題有什麼幫助呢？不就是建立隧道打通物理二層限制, 透過controller實現SDN的概念嘛？我想網絡虛擬化和SDN的差別從這裡就開始有所不同了. 

SDN所討論的是, 如何集中控制平面的設定到一個中央處理單元( Controller ), 但對於轉發的路徑還有物理層上的限制並沒有針對性的議題, 所以我們可以把它想成, 這是一個簡化設定的實現, 但是如我之前的文章所提及的, 他依然在實際應用的規模上出現的很大的限制. 但是網絡虛擬化也不是隧道這種很膚淺的技術概念所可以實現的, 或是多加了一個controller作為策略配置的工具, 他所包含的其實是更多的深層的營運問題需要被解決的技術, 這邊我也會替大家來解說我個人的想法.

東邊到西邊：

這個部分我過去沒有在一般的演講的場合講過這個思維, 但是隨著越來越多人詢問這方面的問題, 我想現在因該是最佳的時機來討論這個概念.  網絡虛擬化另一個重要的課題就是網絡功能分散化. 過去網絡功能都是在南北向被實現, 所以造成了上述的兩個問題. 但是我們想要相同的結果, 又不要被那些問題所困擾, 網絡功能在東西向被實現成為了一個契機. 但是如台灣人說的, 唱的比說的好聽, 這種分散式的網絡處理有這麼容易嘛？過去20年來這些網絡大廠為什麼沒有去實現？我不知道該如何回答這個問題, 只能說套用老祖宗的經驗 "時候到了", 沒有服務器虛擬化後所造成的網絡問題,  這個東西大概也沒有機會可以誕生.  

最早東西向的網絡概念,  就是透過STT/VxLAN/GRE 所建立的L2 邏輯網絡, 或稱為overlay network. 在我過去幾年在這方面的工作經驗, 這方式的確解決了部分問題, 但是對於產業或是應用環境上,  不是太吸引人. 這個問題是整體的, 不是片面的. 所以我所屬的公司, 在過去的兩年內陸續開發了分散式的三層路由器, 分散式的ACL等網絡功能分散化, 把原本需要在北向被執行的功能, 全部拉回在本地所屬的hypervisor被執行, 及透過隧道的媒介,  分散式的運算後的結果可以直接在HV-HV之間發送, 無需透過北向作為數據交換的點, 甚至跨Hypervisor平台也可以得到同樣的結果. 分散運算後的北向只負責提供配置, 完全不干涉數據的轉發和學習.  這個技術所帶來的好處就可以更簡化邏輯網絡結構上的配置, 讓網絡跟你的大腦的想法更貼近, 並且降低南北向數據流所帶來的延遲, 管理員不再需要每天在南跟北之間來回進行大腦奔波, 最後跟我一樣, 需要買特殊眼鏡才能繼續工作. 

所以網絡虛擬化又被別人成為下一代的SDN, 對於我來說, 我還是不想說SDN這個名詞, 因為這個字眼被市場過度炒作及浮濫, 所以當別人問我在做什麼的時候, 我的標準回答都是"Network Virtualization".  

為什麼只有Hypervisor的環境去實現這個網絡虛擬化的議題, 物理網絡為什麼不也使用這個技術呢? 其實誰要去implement這個技術都無所為,  重點在於, 業務需求在哪裡? 如果未來物理服務器也會飛來飛去的時候, 也會動態的改變策略的時候, 我相信物理網絡設備也會有這種東西向分散式配置的需求的. 

所以當下次如果有人在問我網絡虛擬化跟SDN有什麼不同的時候, 我認識的人我會先打他一頓在跟他說, 我不認識的人我會很有禮貌的請他看看這篇文章. 因為技術其實很多時候是白板筆打架打出來的, 工程師嘴巴爭吵吵出來的, 如此的技術才有實戰可用的價值, 沒有被挑戰過的技術, 也只能是溫室的花朵, 一捏就碎. 

What is Network Function Virtualization ( NFV ) ?

Recently, I got the many inquiries about the NFV, but I believe the asker who also has no much idea what NFV works for ? Because I can't get the clear point to map his business objective in this topic, more is just trying to map concept and products. What is relationship between NFV and Network VIrtualization/SDN ? We can say that has dependence or not, Because this topic crosses many fields that includes hardware/software/system/platform/control and data panel. I don't think we can fix this topic into simple description.

Basically, I am not fully technical expert in this field, because it is the consolidation from multiple technical areas. But clearly, network function virtualization can be treated as network service component transformation, not the hot topic of network virtualization. The concept model is from telecom industry and design for long term efficiency/economy  business operation purpose. ( All the request what I received is almost from mobile service company). Some aggressively telecom company has started the experimental trail. Recently, I saw the news that AT&T has started trail and expect to reduce the rely on proprietary devices in future.  （http://www.bloomberg.com/news/2013-09-23/at-t-shifting-to-lower-cost-software-defined-networking.html )

Basically, Telecom service company hopes to  virtualize the service component from vendor proprietary hardware to run on open/customizable hardware. We can refer the experience from open compute project in the global industry, new X86 processor can offer more and more features and network application enhancement. These experience may take NFV vision more practical. Besides, the cost of ASIC design is increased and less features support on network application. From these industry change,  it may be not the dream of NFV in Telecommunication. 

Recently, SDN/Network Virtualization is becoming the hot topic in the network market, and people think that is fundamental of NFV. But my personally understanding on SDN/Network Virtualization is not the core part of NFV, it cloud be just option. NFV story has its own background purpose, not the new technology. I personally don't like to have that in my technical product pitch, because if you know the NFV story, then you can understand NFV spirit, that is not the offer what I can give today. 

NFV can't virtualize full telecom services, people in the NFV design also understand this, so the reasonable use case is more important, if they want to get it success.  

So if you understand above the use cases, you can understand the functions can be run into X86 system. It shouldn't be difficult to be virtualized into virtual appliance. Why does telecom company want to virtualize these function components? Nothing more than life cycle of proprietary hardware is too short,  they need to do re-investment, redesign for same function in certain period,  power consumption, space allocation is also the considered on business cost. It is all the business critical topic for the low profit telecom services. Innovation is the way to make business more efficiency. Until here, you may understand what " Network Function Virtualization" is, not related to Network Platform Virtualization. 

Who will be benefited after NFV ? Major beneficial is probably telecom service company, and next is commercial hypervisor company. But I believe there is no free lunch, because this kind critical system must be pass series function, performance and compatibility testing to measure the competence of virtual appliance. 

Once telecom service company get the function virtualization, the next consideration is about the virtual environment operation. The cloud dc operation and traditional function support system ( OSS/BSS) must be considered at the same time, because NFV is just to virtualize the service component, no change the function operate model. Some points may be aware 

1) In each NFV topic, the network is always discussed. That's why I mention SDN/Network virtualization is the option. I don't know the the network platform virtualization is suitable to be leveraged in NFV environment, because network platform virtualization originally is designed for  virtualized/cloud datacenter networking. We don't know the NFV will  meet the same issue what network platform virtualization address, so that is open here for further real environment discussion. 

2) Performance is also the concern in virtualization environment, but fortunately the vswitch technology is quite flexible to leverage various offload technologies in hardware level, for example: Linux NAPI or Intel DPDK 

3) Automation is the key, if the NFV environment wants to be scaled. 

4) OSS/BSS support will be kept as same, because NFV is to virtualize service component, not change the original telecom service profoliio. 

5) Security level shouldn't be decreased, but after virtualization, this topic is becoming difficult to manage. so network platform vitalization/SDN may be the solution to keep security level and visibility. 

Last, I think the NFV is probably the 1st step to optimize the service infrastructure component, because less and less system is not running on x86 system. Cost/Application on CPU is becoming more colorful than ASIC design. so what is the butterfly effort after NFV, I think we may see in not longer future, I hope to see that in the decade. 

NFV ( Network Function VIrtualization ) 是啥？

最近已經連續了一段時間一直收到NFV的詢問, 但是到底什麼是NFV, 我相信連問我的人可能也搞的不是很清楚. 因為從整個對話的過程中,  我很難找到一個客觀的重點, 多半也還都是在概念性和商業產品中找尋一個可能應對的達陣點. 事實上, NFV跟網絡虛擬化/SDN是不是有密不可分的關係, 可以說有, 也可以說沒有. 因為模糊的交叉區塊實在太模糊, 同時間也跨了硬體/軟體/系統/平台/效能/控制/數據轉發 等等等...... 太多的領域, 實在很難的有系統性的做出一個結論.

基本上, 我在這個主題也算是半個門外漢, 因為這是另一個跨領域多方面的集合. 如果Openstack是管理系統多方面集合的一個架構的話, NFV因該可以說是在網絡功能系統上的多方集合架構的代稱. 當然這個概念主要是由Telecom公司為了長期營運需求上所建構的概念模型. (嚴格來說, 我所收到的request幾乎都是來自於手機服務公司的詢問). 比較積極的電信公司甚至已經開始這方面的投資及試驗. 從最近的消息來看, ATT已經開始在這方面開始了相關工作, 期望未來能夠降低對於私有硬體的依賴. （http://www.bloomberg.com/news/2013-09-23/at-t-shifting-to-lower-cost-software-defined-networking.html )

基本上,  理想的概念是把現行電信網絡服務依賴廠家私有硬體的現況, 轉向虛擬化後至開放硬體或是可自行訂製化的硬體平台. 其實從過去幾年Open Compute Project越來越受到全球業界重視的結果下, 加上新一代的x86 processor 可提供越來越多的功能和效能對於網絡應用改善, 其實這個概念看起來似乎也不是不行. 並且現在ASIC在開發的成本越來越貴及功能支援越來越少, 從這個需求的結果下來看, 電信公司的這個概念也並非是發白日夢而已. 

ps: 2009年我一個在珪谷的朋友就曾經告訴我, CPU將逐步取代FPGA/ASIC的效能優勢, 我當時認為他是神經病, 他告訴我重點在與處理程序的步驟, CPU就可以處理到極好了. 現在看起來是當時我的無知比較多, 深受台灣硬體為上的思想毒害.

近兩年, SDN/Network Virtualization 議題在市場上的快速發展,  讓NFV這個概念看起來似乎有越來越靠譜的趨勢. 但是我個人認為, SDN/Network Virtualization的議題, 只是NFV周圍的附屬技術範圍, 不是主軸. NFV的發展有他一定的背景目的, 並非某些銷售/市場人員為了銷售的浮誇說法,  這也是我不太喜歡跟客戶討論這個議題, 因為我沒有東西可以建議給您. 但是blog上, 我可以比較輕鬆的說出我的想法, 看倌自己思考就好, 沒有Rick的什麼鬼人格保證. 

我看了一下那些是目前電信公司對於NFV比較有興趣的use cases, 看完之後, 我發現這個功能的確是在技術和集成上比較靠譜的方向

如果你可以理解上述所列出的一些常見的use case, 相信您因該可以理解這些功能原本幾乎都是搭設在x86的系統平台之上, 所以porting 到virtual appliance並不是太難的問題. 電信公司為什麼要對這些功能作虛擬化, 不外乎就是商業產品EOS/L的速度太快, 每段時間都需要重新投資相同的功能, 加上空間/能源上的開銷, 讓低毛利的電信服務業需要重新思考快速增長的基礎建設的進化. 所以看到這邊您因該可以理解什麼是 "Network Function" Virtualization, 而不是我們從其他地方延伸過來的"Network Platform Virtualization" 或是 "SDN" base Network. 

我覺得NFV在商業上最大的受益者除了電信公司之外, 另外就是Hypervisor的商業軟件公司. 但是天下沒有白吃的午餐, 上述功能在進行虛擬化的功能, 在功能提供商和商業Hypervisor廠商仍有一連串的相容測試, 效能評估等多重指標需要被衡量. 

但是一旦扯到了服務/功能虛擬化到virtual appliance之後,  為了讓這個架構可以被更順暢的被營運,  很多傳統和較新Cloud概念被需同時間被考量. 在Virtualization的議題之下, 有許多的點我個人覺得是需要被注意的

1) 在每個關於NFV的議題上, Network總是第一個被提出來討論的. 事實上這也是為什麼Network  Virtualization/SDN是這個概念上的附屬議題.  基本上, 我不知道Network Platform Virtualization是否適合在NFV上被提出來討論, 因為Network Virtualization主要的目的是在Cloud Computing的網絡的場景上. NFV所處的環境是否有複雜到跟Cloud Computing一樣, 這個我無法確認,  因為我沒有經驗. 但是就NFV在幾個電信公司所發出的白皮書來看, 他們目前跟ONF的概念合作上是比較密切的, 我覺得或是SDN（openflow hop-by-hop) 可能是現在可以觀察的方向之一. 

2) 效能也是常常被考量的範圍, 就現在比較常見的hypervisor來說, Linux NAPI是常被使用的一個方法, 或是Intel 推出新型的的DPDK架構可能也可以大幅改善效能的表現.  

3) 虛擬化後的虛擬環境管理平台也是一個重點, 並且如果要建構一個大型的NFV環境, 沒有automation 的能力, 要怎麼維運. 

4) OSS/BSS的兼顧和相容, 並竟這是Network Function Virtualization, 不是Cloud DC, 所以功能雖然被虛擬化, 但是對於原本OSS/BSS的support不好有太多的改變. 

5) 安全性, 就是功能被虛擬化之後, 依然需要提供如過去在硬體架構相同及別的安全水平. 但是虛擬化之後,  這方面就變的棘手很多, 透過SDN/Network Virtualization控制這個部分, 可能也是選項之一. 

所以簡單來說,  我認為NFV對於電信公司未來的營運來說,  可能是基礎建設升級的第一步, 畢竟現在很少操作系統不是x86的平台, CPU比ASIC更有效率的時代也逐漸的來臨. 並不知道最後NFV能走多遠,  第二步, 第三步會是什麼樣子, 但是對於已經停擺很久的網絡應用世界來說, 的確是一個有趣的議題, 我也很想看看下一個10年, 是否還能產生另一次的革命！

Open VSwitch 簡單說～

在網絡虛擬化的議題內, 大部分的人因該都聽過OpenVSwitch這個開源項目 (簡稱 OVS), 尤其以Nicira為最早開始使用OVS作為網絡虛擬化交換的Edge. 你如果去Google上去Search一下網絡虛擬化的廠商, 大部分的廠商也都使用OVS作為網絡交換的Edge 軟件.  到底OVS有什麼好的地方？

OVS主要是設計在Server Hypervisor上運行的網絡交換機軟件, 到了今天（2013-09-16), 經過11個版本的revision之後, 已經達到了是具有在生產環境運型品質的軟件. 這個軟件當初設計的目的主要是為了VM-VM在同一個Hypervisor的網絡通訊或是轉送VM的數據包到物理的網絡. 當然他也支持一些標準的管理介面. 如 sFlow, Netflow, IPFIX, RSPAN, CLI 等, 當然也支持開放的程式化接口, 如Openflow或是OVSDB管理協議.

OVS今日廣泛的應用在多種的服務器虛擬平台, 如KVM, VirtualBOX, XCP, XenServer 或是ESX (商業廠商特別製作的Virtual Appliance). 當然OVS的Source Code也可以在Linux 2.6.32以後的Linux核心內被編譯(Compile). 當然現行主要支持的Linux 核心版本主要還是 3.3 的版本. 目前對於Debian, Ubuntu, Fedora的Linux, 是比較常被使用, 也比較容易在官網或是谷歌搜尋引擎上找到相關的資訊.  我自己其實是一個很懶的人, 我懶的每次都去complie source code, 加上我比較常用的是ubuntu的linux, 所以索性就使用OVS Source Code去製作一個屬於ubunut的套件. 關於如何製作套件,  在OVS的Source Code的說明文檔裡, 都有介紹. (如果要製作ubuntu的套件, 就參考INSTALL.Debian的檔案）

我個人最常使用的組合是 KVM+Libvirt+OVS, 但是Libvirt對於OVS的native support是在0.9.11以後的版本才開始支援. 但是很令人討厭的是,  支持Libvirt的圖型化UI管理工具, 並不支援OVS, 所以現在的方式還是修改VM的XML內容, 來attach VM的網卡到OVS Bridge.

br1 是透過OVS建立的Bridge, 但是Virt-Manager不支援, 所以沒法bridge~沒搞頭～

所以為了要讓VM的網卡可以順利attach到OVS上, 最簡單的方法就是更改VM XML文檔內的網路配置.  因為已經安裝了Libvirt, 所以可以直接使用 virsh edit "VM-name" 的指令去開啟VMˇ的XML文˙檔.  參考下例把網絡的部份更動成以下的配置, 再來Destroy VM instance 然後再Restart VM.  (這裡就不介紹如何建立OVS bridge和port了, 可以參考官方網站)

因為我的br1 mapping 到 hypervisor的eth1, 這個端口是接物理交換機的VLAN Trunk, 所以我要這個端口打上vlan tag 10, 讓VM可以和VLAN 10的裝置溝通.
使用指令為: ovs-vsctl set port vnet0 tag=10

寫道這裡,  我發現我越來越偏離主題, 我的出發點因該是要討論什麼是OVS, 不是寫OVS的操作手冊才對. 所以回歸後續我想說的部份. 就是很多人也一定會有的問題就是, OVS只能支援Linux嘛？其實答案是否定的.  其實OVS可以支持多個操作系統和硬體的平台, 只是多半的開發是在Linux上進行的, 基本上只要是POSIX ( Portable Operating System Interface)的系統, 都可以集成. 目前也聽說有一些成功port到FreeBSD, Windows或是Non-POSIX的平台上.

當然商品比較這種事情, 一直都市場上所喜愛的主題之一.  所以Opensource的東西每次都是墊底拿出來比較的,  因為沒太多人懂,  沒人在意,  所以最好欺負.  不過關於OVS, 如果拿來跟VMware的Distributed VSwitch和Cisco的Nexus 1000V相比, 總的來說真的只有被欺負的份. 其中差異點最大的部分主要是在於, OVS本身並沒有中央管理的模組, 每一個OVS都是單機處理的模式. 相較於VMware使用vCenter, Cisco Nexus 1000V使用VEM的管理模組來說, 單就OVS的管理面來看, 就鳥掉了.

為了解決OVS本來在方面上的不足,  OVS支持兩個Open的管理協議. 由於Openflow本身是設計於虛擬網絡的遠端管理,  所以擅長於管理flow base的轉發狀態管理. OVSDB則是擅長於交換機端口的狀態管理. 如次一來便可以解決上述的管理不足問題. 這樣上面那隻鳥因該就可以唱出美妙的歌聲了. 目前OVS在這比較具有代表性的架構, 因屬VMware NSX MH ( 原為Nicira NVP）的系統, 當然他在架構上又重新做了優化, 讓不單只是管理的面向, 在規模, 效能及可見度上, 重新詮釋系統架構. 這點也是其他虛擬網路系統設計者目前正在關注的方式.

Openstack 是鄰家男孩？還是洪水猛獸？

對於今年的IT市場來說, 其中最火的話題之一, 因該也少不了Openstack. 但是對於整體在亞太區的市場裡, 或是我自己所居住的地方 "台灣", 對於這個名詞的議題, 因該還是相當陌生, 甚至在很多人還搞不清楚的狀況下, 就急於發表對於Openstack相關的負面訊息.  (我想這些人可能連Openstack的畫面都沒看過). 其實對於一個免費, 沒有過度市場的商業宣傳, 沒有太多服務公司商業支援的一個Open Source的社群來說,  反而更引起群眾的注意. 連Open Source的Linux好像都還沒有過這種不一樣的市場特殊對待經驗.

但是如果你以為Openstack只是一個像Open Office小型的開源項目(我忘了誰曾經對我舉過這個例子來比喻Openstack, 但是當下引來一群哄堂大笑), 那我想基本上又是一個商業操作的愚弄. 用商業的角度來對付一個不商業的開源社群, 就如我上面下的標題一樣, 對他是洪水猛獸. 對於一個非真正在技術領域打轉的人來說, 這並不能完全責怪他, 因為這已經超出他所能理解的範圍了.

對於Openstack組織的壯大, 超乎過去我們所理解的速度, 從只是社群的愛好者, 變成商業公司積極參與並貢獻代碼的結論來看,  這個組織的理念, 一定包含了破壞性創新的概念, 不然如何吸引商業公司, 甚至公開聲明以Openstack作為商轉的管理平台.

現行參與openstack的商業公司的 list 

http://www.openstack.org/foundation/companies/

看完以上的介紹之後, 你可能會懷疑我是Openstack的信徒或是抱持著另外的商業目的. 這裡我必須很誠實的說, 我只是玩家, 不是專業的開發人員, 也不是廠商的打手. 就像我常常在網絡上看到的標題, 我只介紹好東西. 而且是免費的喔! 有說明手冊, 也有軟體下載, 但是沒有提供保固. 

因為他是開源的項目, 怎麼提供保固?  

Q: 那沒有保固, 我怎麼敢用？  

A: 嗯, 那你可以找具有類似功能的商業軟體廠家

Q: 這東西不是講的很厲害, 所以我想用看看啊?

A: 嗯, 因該要請你看看手冊啊, 這完全提供給您DIY的, 該有的東西大致上也少不了. 

Q: 不要花錢的, 可以讓我們省下很多經費啊!

A: 如果您的支援團隊可以搞定這個架構, 那當然可以省錢啊. 前提是, 支援團隊需要有系統優化開發及維運的能力 (又不是Open Office, 只要下一步按幾次就好) 

PS: 我這裡對Open Office項目的作者致上歉意, 我不是故意消費你們, 您的東西我在家也天天在使用,  是相當好用的東西, 只是想到之前那個比喻, 我實在忍不住) 

所以事實上, 雖然這個開源項目到今天已經如此有名氣了,  但是很多人對於Openstack的能力和認知還是有很大的誤解. 基本上, 我一直很想把這個事情說清楚, 但是已經壓到喘不過氣的工作和很差的組織能力, 讓我拖了很久, 直到這次在VMWorld 2013我參加了我同事的 Dan Wendlandt的Session, 聽完他的介紹, 我才能比較有組織的思考這個部分. 

ps: Dan Wendlandt是Openstack Quantum這個項目的發起人之一, 這個項目在 Havana的release會改名為Neutron

Openstack不是一個商品/產品

- 他只是一個由Openstack組織所提供的一個管理框架的軟體, 主要包含了分配系統, 和Compute, Network, Storage, Image, Authentication等不同功能的module. 這個框架系統今日還並不完美, 如果要使用這個框架到可以完全應用在生產環境上, 您可能還需要Openstack Service支援的廠商, 或是透過你自己修改系統至您的理想環境或規模. 

Openstack只是一個框架, 他沒有特別的商業廠家偏好

- 其實一直過去有個錯誤的觀念是, Nova 特別偏好KVM, Quantum 特別偏好Nicira NVP等, 事實上, 是因為當時只有這些方案去積極的支持Openstack的框架. 我想到今天為止, 願意支持Openstack的方案已經超過兩年前我第一次接觸Openstack時的數倍(可能有數十倍了)之多. 所以任何廠商只要為這個框架寫屬於他產品的plugin, 基本是都可以被框架應用. 但是只有分配的API系統是由Openstack組織自行開發, 這也是避免有特定廠商操作的問題. Openstack組職的董事都是透過定期選舉出來的, 以保持一定的公平性. 

PS:  Nova 為支持Hypervisor的Module, 如KVM, VMware ESX或是XenServer系統

Quantum(Neutron): 為支援Network 的Module, 如Nicira NVP, Cisco Nexus, NEC, 等

Openstack每半年一次的release是Early Beta

- Openstack組織每半年都會release一個新的版本出來, 但是這版本跟我們過去在商業廠家認知的GA狀態是不一樣的, 因為這個release並沒有任何的QA或是壓力測試. 畢竟他是Open Source. 但是不代表這就是沒人愛的小孩, 透過開源專案組職回報bug/fix的機制, 去應對所發生的問題. 當然這部份的工作也就分到使用者/愛好者/貢獻者身上了. 

Openstack是一個standard的 API

- 我個人對於開源項目standard的名詞非常感冒, 因為沒有認證組職去認證何謂standard. 基本上, 在Openstack所提供的API可以被視為是一個公版, 使用者可以透過這個公版去微幅修改自己所需要的結果, 像在RackSpace和HP的版本裡,  就有著他們自己的元素在. 

Openstack只針對服務提供商的雲端數據中心環境

- 嚴格來說, 大致上可以這麼說, 因為需要有能力的團隊支持.  但是在北美地區, 已陸續開始有大型的企業正在實施導入Openstack作為Private Cloud的管理平台, 當然他們也會聘僱一些專業Openstack的服務公司與他們一起進行專案項目. 並非只有獨力完成.

本文對於想認識Openstack這個雲端管理框架有迷惑或有興趣的同好, 能有入門基礎的認知, 能在市場混淆的訊息的大海中, 理出一些頭緒. 節省一些時間, 去思考自己是否需要這個框架. 如果有任何指教, 在麻煩您留言在我的小地方. 

什麼是網絡虛擬化？

在2012年, 網路界最熱門的議題就是Software Defined Network, 但這是一個非常發散的議題. SDN就像很多年前我們談Cloud一樣, 知道怎麼拼, 但老是搞不清楚這倒底在搞些什麼東西. 在2013年, 這些議題感覺稍微收斂了一點, 我們開始陸續聽到, Network Virtualization或是Network Functions Virtualization或是其他類似的討論. 在我所拜訪的許多客戶中, 許多人都問到這些技術的方向, 及未來展望.  當然我很有禮貌的回答了一些我個人的看法, 但根本的來說, 我也不知道那是什麼！

一些新的網路名詞在現今的市場上, 有不同的解釋, 其實訊息很不一致. 所以根本上, 我無法回覆多數人的問題, 如果能有一個比較明確的想法, 而不單只是協定, 或是一個不知道應用支撐的網路架構刻劃..哪這樣我們比較容易能激出一些討論的火花. 

對於我來說, 因為本身工作的關係. 網路虛擬化是一個很明確的主題, 就是"在高度服務器虛擬化的數據中心內, 建立可程式化的網絡架構", 並且"將原本在網絡硬體上轉送的intelligent, 轉移到離服務最近的Server Hypervisor上".

其實每次一談到這個部分的時候, 大家都會對這個說法開始產生相當大的質疑. 就是~

1) 這種作法讓已經管理到快昏倒的網絡變得更複雜了！

2) 軟體的效能怎麼跟硬體相比？

3) 為什麼我們需要這種概念？到底對我的業務有什麼好處？

說真的,  如果您是中小型的數據中心網絡環境, 那第一件事就是, 恭喜你~ 你可以在這邊選擇要不要繼續看下去. 因為你可能碰不到我們所針對的痛點. 如果您是營運商或是中大型的企業, 並且大幅使用Server Hypervisor作為支撐業務的基礎時, 那你可能已經遭遇我們所要談的主題. 

從數據上統計, 在虛擬環境上的虛擬網絡端口已經超越物理網絡端口的數量了. 所以也就是說, 你對虛擬網絡的管理策略的複雜度, 已經遠超於過去傳統網絡的認知及規模. 在我過去15年的工作生涯中, 看過不少大型網絡, 也參與不少數據中心的項目的建立及維運,  唯獨這兩三年在網絡的擴增速度是超越我過去10多年的經驗. 當然這是拜高度虛擬化的結果所賜. 

所以可想而知, 今天對於雲端服務的提供商來說, 在大量使用虛擬化服務器之後, 其實網絡一般來說都在很短的時間走到瓶頸. 首當其衝的就是管理面的問題, 如何管理多租戶的網絡, 並保持隔離, 服務加值, 即時反應租戶對於基礎建設的需求. 這些需求在25年前, 是網路設計者所未考慮到的, 網絡在經過多年演化後, 除了效能及部份功能的增加, 實質上並未有太明確的改變. （註：我在2003年第一次參加並且通過CCIE實驗室的考試之後, 在這10年中, 我在網絡部分空白了數年並專心在應用安全的議題上, 在回頭發現, 其實現今的網路本質運作, 並沒有革命性的概念改變.）

再來就是規模化的問題, 一般非營運商虛擬化的數據中心的環境, 很少遇到這個議題, 但簡單來說, VLAN數量限制, 導致網絡無法繼續有效的擴張. ToR交換機TCAM的限制導致規模化環境的網絡學習中斷, 都些都是在大型虛擬化的數據中心常見的問題.並成為進退兩難的問題.

這是因為如此, 在開始有人想打破傳統網絡的管理框架, 建立一個新的機制, 讓網絡像寫程式一樣, 可以快速產出用戶所需要的結果, 透過變數的定義, 可以自動計算新的需求並執行. 這個概念就是我們熟習的名詞SDN. 但是SDN的發展並不如原先預期的順利, 因為他主旨在於將control panel從硬體網絡設備內脫離出來, 並未考慮到data panel的轉發限制. 所以整個網絡還是侷限在一個特定的區域內, 並且所有data panel的學習都由openflow控制器管理, 所以規模化成為了另一個dead point. 但這樣評論SDN(或是openflow協議）, 並不是太公平. 他並非一無是處, 我也看過使用SDN作為流量工程應用的一些案例, 如 traffic redirection, security tap的應用模式, 所以只是在數據中心的整體架構來說, 這個概念在規模及投資的成本上不太適合而已.

但是對於網絡虛擬化的概念來說, 我們可以思考它為創新的網絡架構概念, 它利用今日網絡IP通訊的特性, 並同時考量SDN的經驗所發展出的一個新的方式. 它依然遵循過去"傳統" SDN將control panel 脫離的概念到x86為基礎的controller上, 並且同時透過安裝在Hypervisor內的虛擬交換機, 抽象化網絡data panel的轉發, 使用IP隧道作為端到端的通訊方式(VxLAN, STT, GRE) 等. 讓網絡在一個IP可通訊的物理條件上, 可透過API佈署L2-L4的虛擬網絡topology, 並且向上垂直整合L7的應用需求或是水平整合物理服務器的網絡通訊.  所以從這個觀點來思考, 你可以把你現在個IP網絡, 視為一個大型的網絡背板 (Network BackPlane), 而每一個安裝在Hypervisor內的虛擬交換機視為一張交換機內的Line Card. 這樣, 網絡虛擬化的模型因該在您的腦海裡可以刻畫出來了.

但是如果我們現在回頭看前面大家對我提出的問題, 這樣因該我就比較容易在這回答給各位讀者了:
1) 這種作法讓已經管理到快昏倒的網絡變得更複雜了！

-> 正是因為如此, 你才需要把現在依靠在網絡硬體上的intelligent脫離出來, 透過軟體的模式, 根據用戶/應用/架構的不同時空的需求, 去程式化的計算網絡所需要的能力, 然後再交付虛擬交換機根據更新的flow table去建立網絡通訊連線. 對於物理網絡來說, 因為不再牽涉configuration的intelligent, 所以僅需要維持低延遲, 高轉發的網絡特性. 而於所建立的邏輯網絡來說, 就像您常用的excel試算表一樣, 可以隨意新增/修改/刪除/拷貝您的設定, 然後計算後的結果回直接告訴你結果. 讓服務來引導網絡的設定, 跳脫讓人推著服務上線的概念

2) 軟體的效能怎麼跟硬體相比？
-> 其實這是一個比較大的迷思, 網絡虛擬化從來沒有提及去replace現今傳統網絡設備的價值, 然後完全交付給軟體作為轉發的基礎. 硬體的sillicon的開發在今日已經達到非常成熟的地步, 使用軟體的方式去取代現在硬體的成果, 無疑是腦袋壞去. 在今日虛擬交換機透過與網卡的driver的最佳化處理, 把原本在Server網卡上的效能作有效率的提升,  並且透過今日由成熟的硬體網絡設備所搭建的高速IP交換, 將Tunnel端到端的轉發變得更快速. 所以一台虛擬交換機在Hypervisor內所需要處理只是運行在Hypervisor內的VM, 並不是一個機櫃或是一個區段的流量, 這便是分散式網絡的概念. .

當然上述只提及到data panel轉發的效能, 我這邊也還想再強調control panel的部分. 因為傳統網絡的人員(我跟大家一樣, 也沒多新潮), 很在意data panel的效能. 但是在於網絡虛擬化的議題中, 其實control panel才是關鍵的核心, 也是大家常常忽略的部分. 因為使用一台x86架構的服務器作為整個網絡控制中心的中樞, 未免風險太大. 用兩台x86服務器作為HA, 未免在規模化的條件下又顯得不足, 所以Active-Active的Contrller Cluster便是一個網絡虛擬化急迫需要的技術.  在把這個技術推向服務生產環境中, 我相信這因該是一個不可忽略的主題, 甚至我覺得這個部分是今日所有相關廠商最大痛點. 全世界現在可能僅有VMware/Nicira 或是極少數廠商具有這樣的能力.
* 筆者現今工作於VMware/Nicira事業群, 上述說法可能有點老王自賣自誇, 但這些訊息的確是在實務上經過了多次經驗的檢視, 及與市場調研的良心建議. 各位看倌可斟酌參考.

3) 為什麼我們需要這種概念？到底對我的業務有什麼好處？
－> 對於營運商的雲端服務來說, 有幾個重點
 *) 自動化:  如果VM已經可以做到request on demand, 那網絡需要跟隨著服務的需求自動建立/更新/刪除. 不同步服務的網絡支援, 其實第一個影響的就是OPEX, 接下來可能又是客戶在等待上使用經驗, 最後累死的可能還是那些一起多年在這網絡領域工作的鄉親父老們.
*) 規模化: 軟體定義網路架構的方式, 最大的優點就是它比今日任何一個以物理網絡支撐的數據中心網絡的規模來的更大, 透過分散式網絡方式, 把負載分散到需要工作的單位, 對於營運商來說,  規模化成為商業成功不可或缺的一個要素
*) 管理簡化: 如果每一個交換機上的control plane是為一個大腦, 那網絡管理員在一個數據中心內就需要管理千百個對話, 就像股市操盤手在開盤時跟股市交易員互動的那樣瘋狂. 透過網絡虛擬化這種集中管理, 分散工作的機制, 就像交通的行控中心一樣, 可以Controller Cluster上就掌握整體網絡的狀態, 並且在錯誤發生的時候, 可以迅速定址錯誤的原因及排除.
*) 開放化: 因為營運商的數據中心內不再像過去只提供空間, 帶寬.. 等基礎的服務, 反而期待更多的基礎建設服務的提供給用戶使用. 每間商業產品公司有它私有領域的專長, 所以結合多家的產品技術並建構在開放的網絡平台上, 成為豐富營運商雲端服務一個很重要的賣點之一.  對於網路虛擬化概念來說, 這是因該也是必要的. 我想沒有一個營運商樂意看到自己只能使用一家著產品線, 或是完全無法朝多元化的整合前進.

-> 以上的功能都是針對營運商的, 對於企業來說, 有什麼好處
對於企業應用上來說, 今日主要都是針對它中大型的企業, 畢竟需求到達一定程度時候, 這個技術才顯現出實際的價值. 我相信以上三點對於中大型企業來說. 或多或少都有應用的場景. 在過過去兩年密集的在亞太地區商務旅行裡, 以訪談多數的企業用戶的經驗上, 看到了另一個可能性的機會
****** 企業應用發展流程 ********
在我過去訪談的中大型客戶裡, 多數人有著一個共同的問題. 當我們準備一個新的服務時, 我們需要花費很多的時間在測試, 驗證,  甚至上到生產環境上, 因為公司內部的網路是一個高度管控的策略, 所以平均一個項目可能需要浪費數個月的時間在等待而無法前進. 這對於企業來說的確是一個非常麻煩的問題,  這已經牽涉到生產力和效率的問題了. 更不用說上到生產環境之後, 連一個小的改動在考慮整體網絡的顧慮下,  比需等待數日/周進行評估. 對於他們與時間競賽的商業活動來說, 這的確成了累墜. 其實這個問題在eBay便曾是一個非常痛苦的問題, 無效率IT基礎建設流程, 大幅拖延了專案的進行, 直到引入網絡虛擬化的概念. 在不影響現行網絡運作及安全規範下, 大幅縮短專案開發時程, 同時也加強了整體公司在IT管理的統合能力.

這篇以什麼是網絡虛擬化為主體的文章, 是希望藉由這個管道, 讓大家能多了解現今實際技術的發展現狀及方向. 雖然舉了一些我比較熟習的例子, 但不重在商業產品推廣, 重點是希望能幫助大家不再在市場名詞中迷惑. 透過我有限的知識幫助大家能更清楚的了解新一代網絡的思考方式.  如果有任何的想法和意見, 都歡迎在我剛新成立的blog給予指教.