2013年9月26日 星期四

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. 














2013年9月25日 星期三

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年, 是否還能產生另一次的革命!













2013年9月16日 星期一

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



2013年9月8日 星期日

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

2013年9月3日 星期二

什麼是網絡虛擬化?


在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給予指教.