YY游戲私有云平臺實踐

編者按：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還在開發階段，在實現過程中肯定還會遇到各種問題和困難。期待它上線后能改善現有的問題，帶來更好的性能、擴展性和安全性。如果您對我們的技術方案有任何疑問或意見，歡迎跟我探討。