四、云計算網絡性能優化方案

　　針對上述產生性能問題的原因，可以從以下幾個方面來對云計算網絡進行優化。將Tunnel加封裝、解封裝的功能Offload到支持SDN的TOR交換機上，這樣一方面去掉了服務器上加解封裝的開銷，另外更重要的是網卡仍然可以通過TSO做TCP報文分片加速。

　　所有的流表都是預先加而非動態報文學習，減少Flow學習帶來的沖擊。同時通過合理地設置默認流表項（Default Entry）來有效減少流表項數量。有人對流表為什么可以預先加不理解，其實很簡單，云計算平臺掌握了所有的信息，包括一個租戶有多少個VM，每個VM都 掛在哪個交換機的哪個端口下面，每個VM的MAC和IP各是多少，默認網關是什么，同一個租戶之間VM的通信使用哪個Tunnel，需要對某個VM應用何 種策略等等。有了這些信息，就足以構建起轉發面所需要的流表，既然能預先配置，為什么需要動態學習？為什么需要Flood呢？

　　將流表項查找也Offload到TOR SDN交換機，使用Linux Bridge做內部VM交換或者為了安全可控，讓報文無論如何先送到TOR交換機，交換機處理后再送回去。這樣延時會稍微大一點點兒。這一步根據用戶情況 可選，也可以只做前面兩步，流表查找仍然使用服務器內部的OVS。

　　更進一步，將基本的無狀態Firewall、基于L2-L4的Load Balancer等（當然，如果是有狀態的Firewall或者四層之上的Firewall/Load Balancer，交換機就搞不定了）也都在TOR交換機上面實現，把OpenStack中獨立的網絡節點服務器完全省掉了。當然這一步對交換機的要求比 較高，不是都能做到。如果做不到沒關系，仍然放到服務器內部做。但這一步如果做了，對性能提升也會很明顯。

　　L3 Gateway是所有云計算平臺所共同面臨的瓶頸，比如OpenStack，有專門的網絡節點（Server）來充當L3 Gateway，用于支持租戶的虛擬Router，由于所有需要路由的報文都要經過這些虛擬Router來轉發，充當L3 Gateway的Server就成了瓶頸。有的硬件SDN交換機可以支持這種情況下的L3 Gateway，而且可以做成全分布式的，這樣就不再存在性能瓶頸。

　　通過在TOR上啟用ARP代理，幫助答復ARP請求，這樣就可以避免ARP廣播。

　　當然這只是理論分析，還需要實踐檢驗，目前這方面的實踐很少。盛科網絡在這方面做了嘗試，用自己的SDN交換機V350為多家云服務提供商（如 UCloud、99Cloud等）提供了基于硬件交換機的云計算網絡解決方案，實現了上述優化措施，并將提交自己的plugin到OpenStack。 UCloud與盛科共同推出了云計算網絡解決方案（如圖3所示）。

　　當然并非所有云平臺都是基于OpenStack的，那是否別的云平臺也可以使用硬件交換機代替vSwitch呢？答案是肯定的，其實UCloud的云平臺就 并非OpenStack。另外，對于網絡虛擬化，有人是用VLan做的，有人用Tunnel overlay技術，這并不影響使用vSwitch還是物理交換機。

　　當然，即便是這樣，仍然會有人說，雖然虛擬交換機確實會導致CPU利用 率有點高，但高點就高點，也沒什么；雖然虛擬交換機會導致更多的帶寬損耗，但損耗點也沒關系，反正我的網絡也不需要那么高帶寬，所以我真沒必要使用硬件 SDN方案。這話聽起來也有道理，但換個角度想想，公有云的基礎架構成本非常高昂，公有云服務商要想賺錢，必須要在保證用戶體驗的前提下降低成本。怎么降 低？如果能夠在一個Server內放更多的虛機，自然就可以降低成本，所以如果能把網絡處理的消耗轉移到物理交換機，讓網絡設備去處理網絡功 能，Server專注于計算，那就可以省出更多資源來放置更多虛擬機。而所有這一切并不需要引入額外的設備，用得不爽了可以隨時切換回原有方案，讓SDN TOR交換機只執行普通TOR功能，可以說基本沒有什么負面影響，何樂而不為呢？說到底，還是因為大家都被虛擬機廠商影響太深，有了先入為主的成見，特別 是在很多人對網絡不是很了解的前提下。

　　五、結語

　　當前，很多從事 云計算的技術人員都是從企業內部的運維和系統研發人員直接轉過來的。在傳統網絡時代，網絡對他們來說只是個工具，會操作就行。但到了云計算時代，對云計算平臺的開發人員來說，就不僅僅是會用這么簡單了，而是提出了更高的要求，需要相關從業人員精通網絡原理，這樣才能讓云計算網絡的性能、可擴展性、對業務的 支持都做到最優，現在流行的DevOps概念就體現了這種要求。

　　因此，對這些人來說，深入了解網絡技術就變得必不可少。但無論如何，云計算讓網絡應用變得精彩，讓應用創新變得更容易；網絡是云計算的基石，沒有網絡就沒有云計算，那么，付出一點學習的代價又算得了什么呢？