YY為什麼放棄OpenStack?YY遊戲使用雲平台的經驗及雲計算隨想

1、為什麼放棄OpenStack

YY遊戲第一代雲平台完全基於OpenStack構建。計算服務使用Nova和KVM，網路服務使用Neutron和Provider Network，沒有使用分散式塊存儲服務。Cloud 1.0出現過一些問題，但也承載了數款遊戲的運行，其中不乏峰值流量很高的遊戲。促使我們遠離OpenStack的原因，主要還在於這個系統不成熟、不穩定、擴展性差。

從全局來看，OpenStack存在的問題包括：

• 項目龐大複雜，過多的模塊、擴展、功能讓這個產品很難部署使用，出錯時也難以調試。

• 發布質量一般。目前是按時間周期發布，每個版本的維護時間過短，且舊版本不支持無縫升級到新版本。整個項目不太注重生產環境的可用性。

• 項目的代碼量仍然在持續增長，但是不注重代碼質量和功能完整性。很多部分實現的功能成為遺留代碼。

• 可控性差，對運維的素質要求非常高。

如下是我們在生產環境中面臨的具體問題：

• 由於Neutron租戶網路存在l3-agent瓶頸，無法實現生產環境可用的租戶隔離網路。

• Metadata服務存在明顯的性能問題。Metadata 服務網路結構複雜，容易導致VM創建或者重啟失敗。

• 直到IceHouse版本，仍然不能在線無縫升級。升級不方便加上舊版本的維護時間短，不適合生產環境大規模使用。

• 授權體系一直是軟肋。默認的policy.json不安全，也不支持全局動態配置許可權。

自身的Bug影響穩定性，上游社區不重視。已知的Bug包括：

• Keystone性能Bug。

• Neutron定時任務執行稍有異常就清空OVS配置。

• Neutron DHCP 伺服器（Dnsmasq）性能問題。

• 在某些情況下，動態遷移（Live Migration）不支持按Region遷移。

• 動態遷移的實現沒有考慮超時和網路不通時如何進行恢復。

這些原因的存在，促使我們最終下定決心開發第二代雲平台，從零開始打造一套適合自己的企業私有雲系統。

2、Cloud 2.0研發思路

典型的雲計算平台包括三個核心部分：虛擬計算、虛擬存儲和虛擬網路。

• 虛擬計算通過內核虛擬化方式，將計算資源如CPU、內存等虛擬成若干個獨立子系統，從而提高資源利用效率。

• 虛擬存儲將傳統的硬體存儲作為服務抽象出來，雲主機以網路方式掛載，可以按需使用，並具備高性能、高可用性、彈性伸縮的特點。

• 虛擬網路將大的物理網路虛擬成若干個獨立的邏輯二層網路，彼此隔離，每個邏輯網路又可以再劃分為三層子網，從而實現虛擬私有雲（VPC）。

上述三個部分，虛擬計算和虛擬存儲都有相對成熟的解決方案，前者用libvirt/KVM可以實現，後者典型的有Ceph分散式存儲。而虛擬網路的實現，雖然市場上有很多軟體、硬體方案，但並沒有達成統一標準，成熟度不高。而且每個業務公司的需求不同，虛擬網路在架構、設備、控制器方面的需求都不同，定製化程度比較高。但虛擬網路又是整個雲平台的核心基礎，沒有虛擬網路支持，無法實現VPC，雲的意義就不大。

在Cloud 2.0中，重點解決租戶私有網路（VPC）的實現問題。出於前面提到的原因，我們並不打算採用OpenStack的租戶網路方案。在充分調研和學習的基礎上，我們自主設計了一套基於硬體的解決方案，其中VPC、子網、路由、雲網關都採用硬體實現。Cloud 2.0雲網路基本架構如圖2-1所示。

圖2-1 YY遊戲Cloud 2.0雲網路基本架構示意圖

我們看到圖2-1中標明了3個租戶，實際上會有數千個租戶，每個租戶都有自己的虛擬私有網路，也就是租戶網路（VPC）。每個VPC保持獨立性，彼此隔離。我們採用VXLAN技術來實現VPC，因為傳統的VLAN有規模限制（4K），我們不能做一個將來無法擴展的平台。而VXLAN的16M規模可以充分滿足需求。

VM的數據包進入接入交換機（TOR）后，由TOR加上VXLAN頭部，並進行轉發。一般來說，如果是同一租戶同一子網的數據包，則由本地TOR直接轉發到鄰居TOR。如果是同一租戶不同子網的數據包，則先發給匯聚交換機，由匯聚交換機轉發到下一個TOR。匯聚交換機在這裡充當VXLAN網關的角色，負責VXLAN網路中不同子網間的路由。此外，如果數據包需要離開VXLAN，它還會剝離VXLAN頭部，將包轉發給網際網路網關。

數據包離開匯聚交換機后，到達網關就是普通的包。當然，由於支持多租戶，每個租戶的子網可能是重疊的，所以匯聚交換機和網關之間的通信走VRF。另外，VM默認都沒有公網IP地址，所以需要網關兼具如下功能。

• SNAT：從VM到公網的數據包由網關根據VRF進行源地址轉換。

• DNAT：VM的某個埠需要被外網訪問，由網關根據埠進行目的地址轉換。

• Floating IP：少數VM需要一個獨立的公網IP地址，在網關上進行一對一的映射。

圖2-1中描述的接入交換機、匯聚交換機、網關都是獨立的物理設備。但是，匯聚層和網關層也可以是PC伺服器集群，既充當VXLAN網關，又實現NAT功能。

VPC的實現是Cloud 2.0與1.0的主要區別。在Cloud 1.0中我們使用OpenStack的Provider Network網路類型，它就是一個大的混合網路。隨著規模的擴展，這種網路類型已經不能滿足需求。所以Cloud 2.0的建設重點是實現每個租戶擁有獨立的VPC。比如用戶A和B，擁有兩個互不相通、彼此隔離的二層網路。用戶A和B都可以自定義他們的網路地址段、路由、訪問控制策略。關於VPC的架構，借用如圖2-2所示AWS的一張圖來描述。

VPC有很多種實現方式，有軟體的也有硬體的，有VXLAN類型的也有NvGRE類型的。在Cloud 2.0設計階段，綜合考慮性能、穩定性、開發成本、上線時間等因素，我們決定第一期採用基於硬體的VXLAN來實現VPC。

在跟同行公司的交流中，我們得知業界在實現VPC時也有非硬體的解決方案。比如某大型雲平台在vSwitch層面做了大量工作，用軟體對流表隔離的方式來實現彼此獨立的租戶網路。這種方案比較靈活，對硬體設備的依賴少，不過開發周期長，在生產環境中不容易實現穩定性，我們暫不考慮此方案。

圖2-2 AWS VPC架構示意圖

VXLAN網路由接入交換機和匯聚交換機組成，數據包在它們之間傳輸時，會帶上VXLAN頭部，從而隔離成一個個獨立的二層網路。數據包在進入接入交換機之前，以及在離開匯聚交換機之後，都沒有VXLAN頭部，是普通的數據包。理論上，VXLAN網路規模可以達到16M，也就是16M個VPC實現。當然，由於VRF數量有限，在實際中並不能產生這麼多的VPC，除非這些VPC都不需要訪問公網。

在圖2-1的下半部分，Hypervisor代表計算節點的宿主機，它們接入獨立的管理網路，這只是一個物理的二層網路，非虛擬網。管理網路里除了有宿主機外，還有控制器、管理資料庫、分散式存儲等。控制器的作用不言自明。分散式存儲是VM運行的數據支撐層，我們的VM不管是操作系統自身還是數據盤，都運行在分散式存儲上。這樣既可保證數據安全，又可滿足雲平台的特性，比如VM快速啟動和遷移。

雲平台的三個核心部分中，虛擬網路是基礎，它的結構決定了整個雲平台的實現架構。如果搞定了虛擬網路，那麼實現虛擬計算、虛擬存儲問題都不大。這也就是為什麼在Cloud 2.0中，我們敢於拋棄OpenStack的原因。我們需要開發一套應用程序，完成對這三個核心繫統的調用、調度、監控和反饋。而這套應用程序就是自己的雲平台實現。

因為虛擬網路是我們前期設計的重點，所以本節也基本圍繞它來進行講解。虛擬網路的本質是控制器的實現，控制器是虛擬網路的靈魂。VXLAN網路中大量的數據交互，都需要控制器參與。

比如，控制器要記錄每個VM的虛擬MAC，並下發到TOR，這樣VM在發起ARP查詢時，TOR才能進行ARP代答。再比如，某個VM的網路請求進入TOR時，TOR需要查表才能知道這個VM屬於哪個VXLAN。還有同一子網中的數據包在不同TOR之間的轉發，以及不同子網中的數據包在VXLAN網關里的路由轉發，都需要查控制器的表項來決定。

SDN（Software Defined Network，軟體定義網路）控制器是目前非常熱門的技術方向，有很多開源項目參與進來，但成熟的產品很少。它的開發工作量很大，華為公司研發敏捷控制器的部門就有一百多人。而我們的Cloud研發部門總共才十幾個人，很難有精力做一套自己的控制器，所以傾向於採取跟第三方公司合作的方式來完成。

我們期待的是一個簡單的控制器北向介面，它完成VPC、Subnet、Router、Port、Floating IP等網路基本要素的管理。而控制器自身的實現方式，目前對我們來說不是特別重要。比如有的控制器北向介面就是Neutron API，南向介面是自己實現的驅動，這也完全可以。

VPC的實現主要由硬體交換機驅動的VXLAN來完成。VPC除了有內網外，還需要跟外部通信，以及外部能訪問VPC的服務，這些都使用硬體網路設備來實現。控制器要完成對這麼多設備的串通聯調，是一個非常大的挑戰。

除了VPC的實現，Cloud 2.0還需要提供兩個核心能力，一個是管理API能力，一個是按需使用計費能力。我們在Cloud 1.0中已經提供了完整API，可以實現對資源的創建和管理。在Cloud 2.0中也一樣，用戶可以使用API來管理網路、伺服器、資料庫等雲資源。對遊戲廠家來說，這是其自動化運維的基礎。

計費我們在Cloud 1.0里做得不好，Cloud 2.0應該予以完美實現。用戶的計費模型里，縱軸是時間維度，橫軸是容量或能力維度。容量包括內存大小、磁碟大小、帶寬多少等，能力包括CPU計算性能、磁碟讀寫性能等。提供靈活的計費能力，按需使用，用多少算多少，對客戶無疑具有更大的吸引力。

關於系統的擴展性，主要存在於租戶規模上。如果租戶一直擴張，雖然內部VPC的16M規模可以充分滿足，但是網關的VRF數量會面臨不夠。參考業界的解決方案，今後如果租戶規模擴張到很大，我們也會考慮開發PC伺服器集群的VXLAN網關，來代替目前的硬體網關方案。

這個VXLAN網關實現了現在架構中的匯聚交換機和硬體網關的功能。VXLAN網關在設備層面基於高性能轉發架構，如Intel的DPDK，實現VXLAN Overlay網路L3GW功能；在控制層面是基於標準南向控制介面的SDN網元，支持的協議包括OpenFlow+NETCONF。在架構上它是一個伺服器集群，每個節點都能處理VXLAN封裝、卸載、路由等功能，以及網路地址轉換（NAT）。接入交換機的VXLAN數據包需要發給網關時，定址方式可以在控制器中由預定義的策略決定。理論上，集群支持無限的水平擴展，在保證性能的同時，保持了經濟性。

最後說說可控性。在Cloud 1.0中雖然使用了OpenStack，但卻遠沒達到掌控自如的程度。OpenStack龐大複雜，眾多的組件、複雜的交互關係，以及並不太好的軟體質量，讓我們望而止步。所以在Cloud 2.0中，我們的基本目標之一是可控。

現在，虛擬網路自主實現，以及虛擬計算和虛擬存儲，都有經過驗證的可行方案，只需要業務層做好整合，整個系統就具備可控性。過去的雲平台出了問題，難以發現原因，即使發現了也難以深層次跟蹤問題。而在Cloud 2.0中所有調用和調度都自己實現，出問題後跟蹤和分析能力得到大大提升。

內部IT基礎資源雲端化是當前互聯網行業的主要趨勢。雲平台將資源管理抽象出來，比如雲主機、雲DB等，以服務的方式提供給用戶，按需使用，從而帶來更大的靈活性與經濟性。YY遊戲早已建立面向內部業務使用的雲平台，例如升龍部署系統[1]。

隨著主機、DB、緩存、存儲等獨立服務抽象出來，必然需要一個大的容器，將這些個體服務整合成一個整體。這個容器就是VDC，即虛擬數據中心。在傳統IT環境中，主機、DB、緩存、存儲伺服器都位於物理DC（數據中心）中。在雲端化進一步發展后，物理DC也將抽象出來，形成VDC，在更高的層次上為用戶提供基礎服務能力。

VDC不是很新的概念，Amazon AWS很早就提出了VPC（虛擬私有雲）。VDC跟VPC沒有本質的不同，VDC建立在VPC之上。也就是說，只有VPC得以實現，VDC才能產生。在VDC中，網路由用戶自己定義，包括二層網路、三層網路（子網）、路由、安全策略、負載均衡等，都由用戶控制。比如張三在他的VDC中自己聲明了一個192.168.1.0/24地址段，所有主機都使用這個地址段的IP地址；李四也在他的VDC中聲明了一個相同的或不同的地址段，並分配IP地址給主機。

VDC帶來的收益包括：

• 安全。每個VDC彼此隔離，一個VDC中的安全問題，不會影響到其他VDC。比如某台主機被黑，黑客難以滲透到這台主機所在VDC之外的其他VDC。

• 靈活。VDC中的每個資源，甚至包括VDC自身，都以服務的方式提供，用戶可以通過控制面板或者API的方式來使用這些資源。相比物理DC，其存在極大的靈活性。

• 經濟。VDC中的資源按需使用，對成本管控無疑有利。

• 易管理。對於大而雜的物理DC而言，最大的問題是容量管理。每個物理DC中都混合了多個業務，在統計它們的容量時很頭痛。而VDC與項目掛鉤，每個項目使用一個獨立的VDC，在容量管理方面就容易很多。可以統計出歷史容量報表，並根據業務發展趨勢（PCU、DAU等）自動做好容量規劃。容量管理對象包括CPU、內存、磁碟、帶寬等。

VDC內部資源包括各個抽象化的具體服務，如雲主機、雲DB等，如圖2-3所示。

圖2-3 VDC的服務組件

這些抽象化的個體服務位於虛擬私有網路中，用戶接入VDC后，訪問它們就如同在物理DC里一樣方便。第三方管理服務，比如部署系統、研發管理系統、監控系統、QA系統都實例化運行，在每個VDC中發揮作用。升龍部署系統有點類似於AWS的OpsWorks，是一個綜合部署與運維平台。

VDC的發展趨勢必然是跨物理DC。在分佈於各地的物理DC基礎上，抽象出面向用戶的VDC服務。而用戶甚至無須關注物理DC的分佈，只需要按正常方式使用VDC資源，由VDC自身來保證服務的架構、性能、擴展性，如圖2-4所示。

圖2-4 VDC在物理DC基礎上提供更靈活的服務能力

用戶的項目或者項目組接入專屬的VDC。VDC之間彼此隔離，並不能直接通信，如果需要通信可以走VPN隧道連接。位於辦公室的用戶，也可以通過VPN的方式接入生產網VDC。在YY遊戲雲平台上，每款遊戲都接入一個獨立的VDC。

隨著技術的發展，物理DC的硬體條件，包括空調、電力、安防、監控等，也可以逐步抽象成服務，為用戶的VDC提供更完善的基礎服務。在不久的將來，互聯網公司的VDC發展將全面取代物理DC，以實現更加靈活、

本文節選自YY遊戲雲平台組新書《自主實現SDN虛擬網路與企業私有雲》第二章，本書已經在各大圖書平台有售。

加入最活躍的kubernetes技術討論QQ群，502207183，並註明城市、行業、技術方向。

交流 分享 提升

雲技術社區成立於2014年，國內最大的雲技術交流平台，分享在雲計算/虛擬化項目實施中的資訊、經驗和技術，堅持乾貨。旗下運營：雲技術實踐、雲技術、桌面雲之雲潮湧動等公眾號，以及相關的微信群和QQ群，覆蓋雲計算領域的技術人群，加入雲技術社區微信、QQ群請點擊訂閱號菜單「群和活動」。