1、何為云計算平臺

說到云計算平臺，不得不提開放平臺。去年以來，開放平臺這個字眼可謂是炙手可熱。自Facebook、Apple將開放平臺的成功演繹至極致，中國互聯網界便掀起了一股“開放潮”，新浪、百度、淘寶、360、人人、騰訊等互聯網巨頭，甚至是當當和京東等電子商務巨頭，都放言“逐鹿”開放平臺。

開放平臺有三層含義：

應用平臺，為用戶提供應用的統一入口，如Apple、Google、騰訊WebQQ的Appstore。

商務平臺，為第三方開發者提供統一的商務接口，減少和不同平臺接口之間的商務溝通成本。

云計算平臺，通過技術能力的開放，為第三方應用提供實時可伸縮的計算資源、海量用戶運維和客服、信息安全等后臺支持和應用托管，可以在整個平臺實現第三方應用的單一實例，如Google的GAE、Amazon的EC2、騰訊的opensns.qq.com。

無疑，這三者中，云計算平臺才能真正解決第三方開發者面臨海量用戶的諸多挑戰，對第三方開發者有著莫大的吸引力，可以實現互聯網巨頭們寡頭經濟和長尾經濟兩手硬的如意算盤，被視為未來互聯網的制勝利器。因此，各互聯網巨頭也不惜投入巨資建設云計算平臺爭奪市場。據互聯網公開的資料，騰訊的云計算平臺 opensns.qq.com開始建設僅4個月就取得出人意料的收獲：

已有108多款第三方應用跑在騰訊云計算平臺上；

4個月應用總安裝次數超過3億次；

日活躍用戶總數達到2千5百萬，最高同時在線用戶超過400萬；

有三款應用平均日登錄超過千萬，超過10款應用平均日登錄過百萬；

單個游戲月度分成收入超過1000萬；

2、VLAN和IP規劃面臨挑戰

那么，和原有僅支撐內部應用的數據中心相比，云計算平臺的數據中心會面臨什么樣的新挑戰？

顯然，由于云計算平臺的核心是諸多第三方應用的托管，業務隔離是首當其沖的要解決問題，否則無法確保第三方應用及數據的安全性。

從網絡的角度，業務隔離必須要從接入層能夠將各業務的服務器分開。網絡大師們不暇思索的給出了解決方案：VLAN。

不料，問題馬上來了。VLAN的規模如何確定，IP網絡劃分按照什么粒度進行？

云計算平臺是典型的長尾經濟商業模式，這也就意味著托管的應用數量龐大，大部分應用的規模較小，但誰也無法預知一覺醒來哪個應用的用戶數量會暴漲，因此計算資源的伸縮性要求很大。

如果VLAN和IP網絡的粒度較粗，由于大部分應用規模較小，這會帶來IP地址等資源的巨大浪費。

如果VLAN和IP網絡的粒度較細，意味著當應用長大時會分割在不同的VLAN和網絡中，如果涉及HA、虛機遷移等特殊需求還可能需要將業務進行跨 VLAN和網絡的整合和遷移，這會招致業務部門的不滿。更糟糕的是，服務器虛擬化技術發展很快，當服務器虛擬化1：4的時候，意味著網絡設備硬件端口規模不變的情況下網絡容量變成原來的4倍，如果服務器虛擬化在1：4的基礎上進一步變成1：10網絡容量就會猛增為最初的10倍，很輕易就會擊穿VLAN和 IP網絡的規劃，應用也將被迫進行的跨VLAN和IP網絡的遷移，應用的中斷將不可避免。

可是VLAN和IP網絡的粒度放大到什么程度才合適那？似乎暫時沒有答案。長尾應用和服務器虛擬化的發展很難準確預知。

網絡大師們總是追求完美的，希望應用盡可能避免遷移，于是，另一個方案出臺了。

網絡大師們現在不劃分細顆粒的VLAN和IP網絡了，干脆創建一個大VLAN，應用的隔離通過PVLAN進行，這樣IP網絡的劃分問題也迎刃而解了。似乎一切都完美了。

還沒等網絡大師們喘上兩口氣，就發現這個方案似乎也行不通。

首先，從技術角度，單個VLAN的規模是有限制的，由于大量生成樹節點的計算會對作為根節點的三層設備的CPU產生沖擊，通常一個二層網絡難以超過 2000臺服務器（包括虛擬機）的規模。這樣規模的網絡對云計算平臺來說太小，需要建設多個網絡模塊，整個數據中心的網絡結構的層次要增加，跨模塊的網絡性能又成為另外一個浮起的瓢。

其次，在服務器虛擬化的環境下，由于目前交換機還無法直接通過端口區分虛擬機，如果想使用PVLAN隔離虛擬機，服務器虛擬化平臺就必須支持PVLAN TRUNK，或者說母機內置的虛擬交換機必須支持PVLAN TRUNK。目前業界僅Cisco的Nexus1000v可以支持，但限于vmware平臺，而更受互聯網行業青睞的開源解決方案尚無蹤影。

前一個問題，即將出臺的IETF的Trill標準，或者現在業界已有的解決方案，如Cisco的Fabric Path，可以在某種程度上解決，但后一個問題，網絡大師們就無解了。

正當網絡大師們行將崩潰的時候，一根救命稻草飄然而至，那就是即將發布的IEEE的802.1Qbg、Qbh標準。不管Qbg和Qbh雙方如何爭相表明己方的優勢，事實上兩者的最終目標是一致的，那就是要在接入交換機上通過虛擬端口的方式提供虛擬機在網絡端口層面上的感知。

于是，當Qbg和Qbh商用后，接入層交換機就可以使用PVLAN的手段進行業務隔離，不管是物理機還是虛擬機。

然而事情還沒結束，Qbg和Qbh并不是原有的交換機和服務器網卡所能支持的。交換機可以在建設數據中心時適當超前選擇hardware ready的設備，當標準出來軟件升級即可，甚至可以在原有數據中心更換接入層交換機。可是服務器的網卡選擇并不是由網絡大師們確定的，互聯網企業定制的服務器要更換新型網卡也不是那么容易，更何況現存的大量服務器更換網卡幾乎不太可能。最重要的一點，目前沒有任何網絡設備廠商承諾Qbg和Qbh會有 PVLAN的特性支持，也許他們目前的重點是確保能夠成為標準之一，還顧不上這樣的細節。

終于，網絡大師兩眼一黑，昏倒在地。

3、VLAN+ACL卷土重來

網絡大師被速效救心丸救醒，因為云計算平臺正在建設中，網絡規劃不可缺少。

吸取了之前的經驗和教訓，網絡大師們決定暫時拋開那些尚未發布的標準，立足于目前可用的技術。

于是，VLAN和IP網絡劃分又開始了，這次網絡大師們仍然決定做一個盡可能大的二層網絡，所不同的是，不再考慮PVLAN的隔離方式，而采用VLAN ACL的方式進行訪問控制實現隔離，虛擬機的母機和接入層交換機采用vlan trunk的方式連接。這樣現有的交換機和虛擬化平臺都可以支持，唯一需要新增加的，就是ACL管理的工具系統，這對于研發能力超強的互聯網企業，算是小菜一碟了。

還有一個對于網絡大師們是好消息的事情是，業界有些網絡設備廠商已經開始支持基于標簽的訪問控制，比如Cisco的TrustSec，可以將訪問控制的矩陣規模極大的縮小，雖然需要新的網絡設備型號才能完全支持，但至少事情已經在網絡大師們可控制的范圍內了。

網絡大師們興沖沖的帶著最新的方案去和業務部門研討，希望得到業務部門的支持，趕緊把ACL管理系統開發出來。

業務部門的一席話差點又讓網絡大師眼前一黑：“我們現在在服務器上用IPTables和Ptables做業務隔離，如果性能會不夠，再考慮別的方式”。

原文鏈接：http://network.51cto.com/art/201105/262209.htm