YY遊戲私有云平臺實踐 (轉自InfoQ )

 

做者 風河 發佈於 2016年1月13日 | 討論

 

編者按：YY遊戲的頁遊早在2013年就在雲平臺上運行，其Cloud 1.0已經支撐幾十萬的同時在線用戶。日前，YY遊戲雲平臺進行了Cloud 2.0的改造，其主要目標是支撐端遊，同時也將繼續服務頁遊、手遊的運營。

此次架構升級是一次徹底重構——拋棄OpenStack，網絡、計算、存儲業務都是本身實現。做爲YY遊戲雲平臺的負責人，風河在本文裏主要描述了YY遊戲須要建設一個什麼樣的雲平臺，以及如何建設這個雲平臺的。

YY遊戲的業務需求變遷

YY遊戲早在2013年就運行在雲平臺上。在開發雲平臺以前，遊戲運營面臨的問題是：

 

• 頁遊開服快、密度大、週期短，致使運維變動頻繁。

• 傳統開服、合服涉及大量的運維人工操做，例如安裝服務器、配置網絡、部署遊戲、配置數據庫等。

• 用物理機開服，資源分配不合理，一個物理機上分配較多遊戲進程，會致使風險太高；分配較少進程，又致使成本浪費。

   

• 數據備份、監控、故障轉移在傳統模式下都成爲挑戰。

針對這些痛點，咱們在OpenStack的基礎上，開發了第一代雲平臺，即Cloud 1.0。雲平臺上線後，資源管理更加靈活，在性能和成本之間取得良好均衡，並極大的加強了運維自動化能力。目前Cloud 1.0支撐了幾十萬同時在線的遊戲用戶，截至到2015年12月，YY雲平臺接入遊戲50多款，資源總數約15,000個。

以下是Cloud 1.0的基礎架構，它包括雲主機、雲DB、雲存儲、雲緩存、雲網關五大核心產品。用戶可經過控制面板訪問它們，也可經過API在應用程序裏來調用它們。

隨着雲平臺規模愈來愈龐大，慢慢暴露了OpenStack的一些弱點，好比結構複雜、可靠性通常、擴展性弱，致使咱們在雲的可控性方面大爲被動，從而產生了第二代雲平臺的需求。

那麼咱們須要一個什麼樣的雲呢？首先，它是基於私有云。其次，這個私有云必定知足咱們業務的特色，好比遊戲行業與金融行業，業務特色大相徑庭。再次，這個雲必定要可管理、可擴展、可控。對於一個平臺服務，它存在性能短板、運行故障並不可怕，可怕的是出問題後用戶沒法跟蹤和定位，從而失去可控性。

雲平臺架構的演進

在Cloud 1.0裏，咱們並無實現租戶網絡，不一樣的遊戲廠家都接入同一Flat網絡，這對隱私和安全都不利。網絡架構以下：

上述圖裏，雲網關是遊戲平臺裏一個重要產品，請參考騰訊遊戲的TGW。簡言之雲網關有兩個重要做用，一是收斂公網IP，節省IP成本；二是集中安全防禦，下降單個雲主機被DDoS的可能性。咱們全部的雲主機都只有內網IP，運行在雲網關後面。除了雲主機外，還有云DB、雲緩存、雲存儲等配套產品，都是遊戲服務須要的。

在Cloud 2.0裏，重點解決租戶網絡（VPC）的實現問題。出於前面提到的緣由，咱們並不打算採用OpenStack的租戶網絡方案。在充分調研和學習的基礎上，自主設計了一套基於硬件的解決方案，其中VPC、子網、路由、雲網關都採用硬件實現。架構圖以下：

咱們看到圖裏標明瞭3個租戶，實際上咱們會有數K個租戶，每一個租戶都有本身的虛擬私有網絡，也就是租戶網絡（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，在網關上進行一對一的映射。

圖裏描述的接入交換機、匯聚交換機、網關都是獨立的物理設備。可是，匯聚層和網關層也能夠是PC服務器集羣，既充當VxLAN網關，又實現NAT功能。

雲平臺架構選型與實現

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

怎樣實現VPC

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

在跟同行公司的交流中，咱們得知業界在實現VPC時也有非硬件的解決方案。好比阿里雲在VSwitch層面作了大量工做，用軟件對流表隔離的方式來實現彼此獨立的租戶網絡。這種方案比較靈活，對硬件設備的依賴少，不過開發週期長，在生產環境裏不容易搞穩定，咱們暫不考慮此方案。

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

圖的下半部分，Hypervisor表明計算節點的宿主機，它們接入獨立的管理網絡，這只是一個物理的二層網絡，非虛擬網。管理網絡裏除了有宿主機外，還有控制器、管理數據庫、分佈式存儲等。控制器的做用不言自明。分佈式存儲是VM運行的數據支撐層，咱們的VM不論是操做系統自身，仍是數據盤，都運行在分佈式存儲上。這樣既保證數據安全，又知足雲平臺的特性，好比VM快速啓動和遷移。

雲平臺包含三個關鍵部分：虛擬計算、虛擬網絡、虛擬存儲。這裏面虛擬網絡是基礎，它的結構決定了整個雲平臺的實現架構。若是把虛擬網絡搞定，那麼虛擬計算、虛擬存儲都問題不大，這也就是爲何在Cloud 2.0裏，咱們勇於拋棄OpenStack的緣由。咱們須要開發一套應用程序，完成對這三套底層系統的調用、調度、監控和反饋。而這套應用程序就是本身的雲平臺實現，它的架構參考以下：

由於虛擬網絡（又稱軟件定義網絡、SDN）一直是咱們的重點，因此本文談的也基本圍繞它進行。虛擬網絡實現的本質是控制器的實現，控制器是虛擬網絡的靈魂。VxLAN網絡裏大量的數據交互，都須要控制器參與。

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

關於SDN部分

SDN控制器是目前很是熱門的技術方向，有不少開源項目參與進來，但成熟的產品不多。它的開發工做量很大，華爲公司研發敏捷控制器的部門就有一百多人。而咱們的Cloud研發部門總共才十幾我的，很難有精力搞一套本身的控制器，因此傾向於採起跟第三方公司合做的方式來完成。

咱們期待的是一個簡單的控制器北向接口，它完成VPC、Subnet、Router、Port、Floating IP等網絡基本要素的管理，參考此說明。而控制器自身的實現方式，目前對咱們來講不是特別重要。好比有的控制器北向接口就是Neutron API，南向是本身實現的Drive，這個也徹底能夠。

咱們VPC的實現主要由硬件交換機驅動的VxLAN來完成。VPC除了有內網，還須要跟外部通訊，以及外部能訪問VPC的服務，這些都使用硬件網絡設備來實現。控制器要完成對這麼多設備的串通聯調，是一個很是大的挑戰。

兩個核心功能

除了VPC的實現，Cloud 2.0還須要提供兩個核心能力，一個是管理API，一個是按需使用的計費能力。咱們在Cloud 1.0裏已提供了完整API，能夠實現對資源的建立和管理。2.0裏也同樣，用戶可使用API來管理網絡、服務器、數據庫等雲資源。對遊戲廠家來講，這是他們自動化運維的基礎。

• 計費咱們在1.0裏作的很差，2.0應該予以完美實現。用戶的計費模型，縱軸是時間維度，橫軸是容量或能力維度。容量包括內存大小、磁盤大小、帶寬多少等，能力包括CPU計算性能、磁盤讀寫性能等。提供靈活的計費能力，按需使用，用多少算多少，無疑對咱們客戶具有更大的吸引力。這一點Vultr的平臺作的很是好，我在使用它們按需計費的能力後深覺方便，就在最近把Linode上用了5年的雲主機，遷移到了Vultr。

• 關於系統的擴展性，主要存在租戶規模上。若是租戶一直擴張，雖然內部VPC的16M規模能夠充分知足，可是網關的VRF數量會面臨不夠。參考業界的解決方案，從此若是租戶規模擴張到很大，咱們也會考慮開發PC服務器集羣的VxLAN網關，來代替目前的硬件網關方案。

• 這個VxLAN網關實現瞭如今架構裏的匯聚交換機和硬件網關的功能。VxLAN網關在設備層面基於高性能轉發架構，如Intel的DPDK，實現VxLAN Overlay網絡L3 GW功能；在控制層面是基於標準南向控制接口的SDN網元，支持的協議包括Openflow+Netconf。架構上它是一個服務器集羣，每一個節點都能處理VxLAN封裝、卸載、路由等功能，以及網絡地址轉換（NAT）。接入交換機的VxLAN數據包須要發給網關時，尋址方式能夠在控制器裏由預約義的策略決定。集羣理論上支持無限的水平擴展，在保證性能的同時，保持了經濟性。

• 最後說到可控性，在Cloud 1.0裏咱們雖然使用了OpenStack，卻遠沒達到掌控自如的程度。OpenStack龐大複雜，衆多的組件、複雜的交互關係、以及並不太好的軟件質量，讓咱們望而止步。因此在2.0裏，咱們的基本目標之一是可控。如今虛擬網絡自主實現，虛擬計算和虛擬存儲也有通過驗證的可行方案，那麼只須要業務層作好整合，整個系統就具有可控性。過去的雲平臺出了問題，難以發現緣由，即便發現了也難以深層次跟蹤問題。如今Cloud 2.0裏全部調用和調度都本身實現，出問題後跟蹤和分析能力要大爲提高。

小結

咱們的Cloud 2.0還在開發階段，在實現過程當中確定還會遇到各類問題和困難。期待它上線後能改善現有的問題，帶來更好的性能、擴展性和安全性。若是您對咱們的技術方案有任何疑問或