四、云計(jì)算網(wǎng)絡(luò)性能優(yōu)化方案

　　針對(duì)上述產(chǎn)生性能問題的原因，可以從以下幾個(gè)方面來對(duì)云計(jì)算網(wǎng)絡(luò)進(jìn)行優(yōu)化。將Tunnel加封裝、解封裝的功能Offload到支持SDN的TOR交換機(jī)上，這樣一方面去掉了服務(wù)器上加解封裝的開銷，另外更重要的是網(wǎng)卡仍然可以通過TSO做TCP報(bào)文分片加速。

　　所有的流表都是預(yù)先加而非動(dòng)態(tài)報(bào)文學(xué)習(xí)，減少Flow學(xué)習(xí)帶來的沖擊。同時(shí)通過合理地設(shè)置默認(rèn)流表項(xiàng)（Default Entry）來有效減少流表項(xiàng)數(shù)量。有人對(duì)流表為什么可以預(yù)先加不理解，其實(shí)很簡單，云計(jì)算平臺(tái)掌握了所有的信息，包括一個(gè)租戶有多少個(gè)VM，每個(gè)VM都 掛在哪個(gè)交換機(jī)的哪個(gè)端口下面，每個(gè)VM的MAC和IP各是多少，默認(rèn)網(wǎng)關(guān)是什么，同一個(gè)租戶之間VM的通信使用哪個(gè)Tunnel，需要對(duì)某個(gè)VM應(yīng)用何 種策略等等。有了這些信息，就足以構(gòu)建起轉(zhuǎn)發(fā)面所需要的流表，既然能預(yù)先配置，為什么需要?jiǎng)討B(tài)學(xué)習(xí)？為什么需要Flood呢？

　　將流表項(xiàng)查找也Offload到TOR SDN交換機(jī)，使用Linux Bridge做內(nèi)部VM交換或者為了安全可控，讓報(bào)文無論如何先送到TOR交換機(jī)，交換機(jī)處理后再送回去。這樣延時(shí)會(huì)稍微大一點(diǎn)點(diǎn)兒。這一步根據(jù)用戶情況 可選，也可以只做前面兩步，流表查找仍然使用服務(wù)器內(nèi)部的OVS。

　　更進(jìn)一步，將基本的無狀態(tài)Firewall、基于L2-L4的Load Balancer等（當(dāng)然，如果是有狀態(tài)的Firewall或者四層之上的Firewall/Load Balancer，交換機(jī)就搞不定了）也都在TOR交換機(jī)上面實(shí)現(xiàn)，把OpenStack中獨(dú)立的網(wǎng)絡(luò)節(jié)點(diǎn)服務(wù)器完全省掉了。當(dāng)然這一步對(duì)交換機(jī)的要求比 較高，不是都能做到。如果做不到?jīng)]關(guān)系，仍然放到服務(wù)器內(nèi)部做。但這一步如果做了，對(duì)性能提升也會(huì)很明顯。

　　L3 Gateway是所有云計(jì)算平臺(tái)所共同面臨的瓶頸，比如OpenStack，有專門的網(wǎng)絡(luò)節(jié)點(diǎn)（Server）來充當(dāng)L3 Gateway，用于支持租戶的虛擬Router，由于所有需要路由的報(bào)文都要經(jīng)過這些虛擬Router來轉(zhuǎn)發(fā)，充當(dāng)L3 Gateway的Server就成了瓶頸。有的硬件SDN交換機(jī)可以支持這種情況下的L3 Gateway，而且可以做成全分布式的，這樣就不再存在性能瓶頸。

　　通過在TOR上啟用ARP代理，幫助答復(fù)ARP請(qǐng)求，這樣就可以避免ARP廣播。

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

　　當(dāng)然并非所有云平臺(tái)都是基于OpenStack的，那是否別的云平臺(tái)也可以使用硬件交換機(jī)代替vSwitch呢？答案是肯定的，其實(shí)UCloud的云平臺(tái)就 并非OpenStack。另外，對(duì)于網(wǎng)絡(luò)虛擬化，有人是用VLan做的，有人用Tunnel overlay技術(shù)，這并不影響使用vSwitch還是物理交換機(jī)。

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

　　五、結(jié)語

　　當(dāng)前，很多從事 云計(jì)算的技術(shù)人員都是從企業(yè)內(nèi)部的運(yùn)維和系統(tǒng)研發(fā)人員直接轉(zhuǎn)過來的。在傳統(tǒng)網(wǎng)絡(luò)時(shí)代，網(wǎng)絡(luò)對(duì)他們來說只是個(gè)工具，會(huì)操作就行。但到了云計(jì)算時(shí)代，對(duì)云計(jì)算平臺(tái)的開發(fā)人員來說，就不僅僅是會(huì)用這么簡單了，而是提出了更高的要求，需要相關(guān)從業(yè)人員精通網(wǎng)絡(luò)原理，這樣才能讓云計(jì)算網(wǎng)絡(luò)的性能、可擴(kuò)展性、對(duì)業(yè)務(wù)的 支持都做到最優(yōu)，現(xiàn)在流行的DevOps概念就體現(xiàn)了這種要求。

　　因此，對(duì)這些人來說，深入了解網(wǎng)絡(luò)技術(shù)就變得必不可少。但無論如何，云計(jì)算讓網(wǎng)絡(luò)應(yīng)用變得精彩，讓應(yīng)用創(chuàng)新變得更容易；網(wǎng)絡(luò)是云計(jì)算的基石，沒有網(wǎng)絡(luò)就沒有云計(jì)算，那么，付出一點(diǎn)學(xué)習(xí)的代價(jià)又算得了什么呢？