你的SDN只是一場學術笑話？

現在人生覺得被SDN這個名詞搞的很煩, 因為我心中想的目標跟大家在談的內容已經開始背道而馳了. 我終於可以理解Martin過去跟我說的, “ I know nothing about SDN ".  ＠＠ 當時我只能用訝異去看待這個Openflow協議主要發起人之一回應.

過去我嘗試去跟我所在區域市場的人群們, 釐清可production思考的方向的時候,  我發現多數群眾們已經進入宗教式狂熱並超越我的理解範圍, 這感覺就像是數年的市場討論"雲“ 這個議題, 就算到今天為止, 我相信眾人依然無法解釋何謂"雲", 在數年後,  可能大家也依然無法解釋他們今天所談的SDN到底是什麼東西, 能真正在生產環境上幹些什麼事？

如果你要用Openflow解釋SDN, 那Openflow的最早發起團隊已經告訴你哪是一條行不通的路, 他們只是在學術上提供一個新的控制協議,  但是他們並沒有提供你一個Network Operation System. 如果你看過我在這個時間點之前所寫的文章, 我希望你能在這一時先全部忽略掉, 因為在這篇文章的這一秒開始, 我完全想用一個技術人員的思考模式來解釋這個主題, 而不是一個廠商代表.

關於Software Defined Network這個議題, 我想用一個計算機的架構來解釋這個部分. 基本上, 計算機上有幾個重要的單元, 如：中央處理器（CPU), 動態記憶體 (DRAM),  匯流排 (Bus) 和 I/O單元.  如果把這些原件套入到SDN的範圍之內;

中央處理器 - Openflow Controller
I/O - 就如日常使用的輸入/輸出裝置, Openflow協議就如這個I/O行為一樣, 在北向進行指令下達或是收集更新資訊
以上我個人稱之為母體, 沒有母體進行運算, 根本不可能有結果產生. 但是母體產生的結果,  並需要有元件執行~

動態記憶體 - 也就是運算的結果會被store在這, 這個地方也就是網路設備的FIB, 網絡設備必須要有這個訊息才能執行需要的工作.
匯流排 - 也就是元件之間通信的渠道, 這實際網絡的配置上就是你的cable.

所以我們拼湊一下以上的原件:

CPU <--- I/O指令---> 網路設備1 (<-動態記憶體示意)----|
                    |----------> 網絡設備2 ------------------------|----|   匯流排連線
                    |----------> 網絡設備3-------------------------|----|
                    |----------> 網絡設備n-------------------------|----|

你可以發現到, 所有運算的的壓力全部落在北向的CPU組件. 但是回到Openflow最初的概念理念, 正是要最佳化網絡設備的轉發能力, 所以才把運算單元全部脫鉤到北向去嗎？就這個點來說, 是沒有錯. 但是就一個面來說, 這個點並沒有考慮到運算壓力的問題. 不是把轉發表算一算丟給設備就算了, 後面還有一缸子的狀態需要被維持或是更新或是繼續演算, 如果運算單元不aware這個狀態, 那一堆網路標準協議上的工作機制不就作廢? 大型網絡的運作最好有這麼容易簡化. 你以為道士拿個鈴甩一甩, 行屍就會乖乖的一直跳嗎？他要是沒有維持其中的狀態的話, 行屍很快就變殭屍把你吃掉.

到此為止, 如果你看懂我想表達的意思, 你大概可以理解, 現在市場上談的SDN多半都是道行不深的神棍在招攬生意. 其實回頭再看這件事, 這因該不是一門所謂網絡技術的學問, 而是一門distribution computing的科學. 當你把運算單元集中化之後,  如何重新分散運算單元的演算. 就像我給你一顆超級CPU, 可能有一百個內核, 對你來說跟一般CPU沒有兩樣, 因為操作系統根本不支援. 所以當我們在看一個SDN議題的時候, 其實看端出來的菜, 就可以判斷這是道士還是神棍.  講的是一個不能落地的框架, 還是一個有目標的場景. 用的是一個符合運算科學的邏輯架構, 還是一個胡說八道市場訊息. 我想看官門自己需要多琢磨一下.

對不起, 我激動了~ 因為飛機delay, 肚子很餓, 所以脾氣不好～

NSX Service Composer

一個人在一個區域做一個什麼都連在一起的產品, 實在有點吃不消. 但是人生就是這個樣子, 沒事抱怨一下也就算了,  畢竟生活的現實還是需要去面對的, 最近除了花時間在工作的項目之外, 最多時間還是跟女兒玩, 其他的事情也沒太多搭理.

最近獲得了一個喘息的時間,  飛到新加坡參加了NSX vSphere的培訓,  終於可以有時間充充電, 以免老是在放電的狀態. 已過去在Nicira的工作經驗,  這個培訓並不是一個太艱難的內容, 尤其是在所謂網絡虛擬化的內容上, 但是課程內容我感到最有興趣的NSX Service Composer的功能. 這個在過去我並沒有太專心放心思在這個功能上.  因為我也拿不到第三方相對應的方案, 所以放在我工作計劃角落很久了,  沒有去太在意它.

在2013的VMworld, VMware宣布了新的EcoSystem. 到了今年, 可以預期的是, 這個生態環境的集成已經陸陸續續開始要Get Ready, 所以Service Composer也快要可以到登場的時候, 當然本次的培訓也納入這個元素, 實際上機操作了一下, 感覺也就更為深刻.

什麼是Service Composer, 今天我所能提供的第一步消息就是第三方的安全方案集成.  過去在安全領域的經驗裡, 鮮少有廠家願意談太多第三方集成方案的生態環境,  因為大家各自有一片專業領域需要protect. 對於VMware來說, 它是一個虛擬infrastructure的廠家, 急需要的在這個基礎建設上, 融入更多的功能元素提供給他的用戶群, 但是自己本身又不具備L4以上的安全能力, 所以催生了這個元件的產生.  這個元件並不是要讓VMware成為一個安全產品的公司,  而是提供給他的用戶更多的選擇在這個基礎上, 就像寶馬的車如果只給你冷氣,  不給你音響和電動座椅, 你可能會氣到七竅生煙, 還會咒罵他賣得很貴.

廢話說太多了,  到底Service Composer想做些什麼事？ 簡單的來說, 就是集成第三方的功能完成ACL的判斷, 有時我會叫他是個ACL Orchestration. 假設今天我要集成一個防毒系統;

1) 先註冊防毒系統的管理平台到vCenter和NSX-V Manager (僅限於VMware NSX生態環境內的合作夥伴).
2) 部署防毒系統的Agent到vSphere Hypervisor上, 這主要是在分散式的環境下,  可以在本地就直接execution, 無需再拉到北向的filter engine, 這個好處就跟分散式網路一樣, 卸載北向壓力, 減少昂貴Box的採購.
3) 建立Security Group 1 確認策略保護的目標, 並在建立一個Security Policy去調用第三方的集成功能. ( 當發現安全威脅的時候,  第三方的功能會提供結果標簽供系統參考 )
4) 建立Security Group 2, 確認當安全系統發生告警時, 能根據所提供的標簽把有風險的virtual machine放進到動態的成員名單內. 在建立一個Security Policy, 告知系統當成員名單需要被執行隔離(Quarantine )
5) 當防毒系統將病毒清理之後,  第三方掃毒引擎會remove 標簽, 此時virtual machine會被釋放回到一般的工作區域.

以上大概是先建立腳本, 然後再腳本之內,  先對應的策略可以動態被建立, 並且根據實際狀況進行動態的工作執行. 所以由此可以簡化在相關問題發生的時候, Compsor可以依據你所設定的腳本, 進行程式化的動態工作.  對於安全功能自動化來說, 這組件算是降低了管理員的壓力, 也更能彰顯VMware基礎建設的價值, 不然老是被人家嫌軟件貴, 心裏也不是太好受.

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）的系統, 當然他在架構上又重新做了優化, 讓不單只是管理的面向, 在規模, 效能及可見度上, 重新詮釋系統架構. 這點也是其他虛擬網路系統設計者目前正在關注的方式.