本文是我五年游戲虛擬化運維實踐的總結，主要分享以下幾項內容：

為什么要搞游戲虛擬化

那些游戲適合/不適合虛擬化

游戲虛擬化如何實施

實施過程中要解決那些問題

實施過程中有那些虛擬化技術要點

虛擬化的存儲方式

虛擬機資源限制

虛擬化運維中的監控、報警、災備及應急響應要點是什么

軟硬件選型

說到底就是一句話，如何將游戲遷移到虛擬化環境中，并穩定運行。

為什么要搞游戲虛擬化

為什么要搞游戲虛擬化，或者說虛擬化給游戲帶來什么。

***點，也是最重要的一點是可以節省成本。舉一個例子，假設有一款游戲，有一個區組，有40臺服務器，40臺服務器根據高度的不同，通常占用3-5個機柜，就算是3個機柜吧。現在假設能按照1：5的比例去做虛擬化，那么40臺服務器就可以被壓縮到8臺，8臺服務器最多只占用一個機柜，這樣我們節省了至少32臺服務器，2個機柜!對硬件成本的節約是非常驚人的。

第二點，資源隔離，虛擬化一個重要的特點就是實現了資源隔離，假設我們要在同一臺物理機上部署兩款游戲，這個是非常困難的，因為有端口、配置文件的沖突，甚至兩款游戲的維護時間也是不一樣的，如果一款游戲維護的時候需要重啟服務器，會影響另外一款游戲的運行。使用虛擬化就可以很好的解決這個問題，我們可以在同一臺宿主機上的兩臺虛擬機分別部署一款游戲，不會有任何沖突，虛擬化的隔離性可以很好的解決這個問題。

第三點，快速部署。從宿主機角度看，虛擬機就是一個鏡像文件，要得到另外一臺虛擬機，只需要將鏡像文件復制一份就可以，這個通常是幾分鐘，最多十幾分鐘。而我們要得到一臺物理機，從上架、插電源線網線、安裝操作系統，及時一個熟練手都要個把小時。這個完全是一個數量級的差別。

虛擬機的快速部署特別適合手游頁游，因為大家知道手游頁游有一個特點就是開區并組非常頻繁，虛擬化剛好可以滿足這個需求，這也是為什么大部分手游頁游都喜歡用虛擬化的原因。

那些游戲適合/不適合虛擬化

那么那些游戲適合虛擬化呢，***種是單進程的游戲，這個主要是一些比較老的端游，游戲開發的時候還沒有多核CPU的概念，這類游戲特別適合虛擬化。

第二種是生命周期進入中后期，人數比較穩定，消耗的壓力也***將幾個區組整合到一臺宿主機，就可以達到整合資源的目的。

虛擬化整合資料案例

舉一個例子，我曾經做過一款游戲，使用500多臺物理機，這款游戲當時已經收支平衡，換句話說已經不爭錢了，面臨著馬上被結項的命運，因為實施了虛擬機，按照1：7的比例進行整合，將500多物理臺服務器，壓縮到了70多臺宿主機上，大大的節省了游戲的運營成本。這個游戲項目又開始盈利了，又能在生存一段時間。

第三種是手游和頁游，上面已經介紹過了。尤其是手游，開發周期很短，程序沒有時間精力去做系統層面的優化，只能通過虛擬化進行擬補。

那么是不是所以游戲都適合虛擬化呢，壓力特別高的游戲就不適合虛擬化，如果在物理機上壓力已經非常高了，我們就很難通過虛擬化在對游戲進行整合了，這類游戲就不適合虛擬化。

游戲虛擬化如何實施

游戲虛擬化的實施建議按照以下步驟實施，可以保證游戲比較平穩的遷移到虛擬化平臺上。

首先需要去做業務性能需求評估，主要是評估業務的壓力狀況，性能數據可以去看監控平臺，也可以用腳本去抓取，得到業務的壓力模型后，根據壓力模型就可以設計業務的虛擬化方案。

虛擬化方案的設計主要是宿主機如何選型，虛擬化比例如何確定。然后我們會搭建一個測試環境，進行測試。

測試包含兩部分，系統綜合測試和業務壓力測試。系統綜合測試主要是測試宿主機、虛擬機磁盤、網絡各方面的性能瓶頸點，取得極限數據，做到使用的時候心中有數。業務測試主要是測試游戲程序能否在虛擬機上運行起來，從客戶端能否正常登錄游戲，正常的玩游戲，一臺虛擬機***可以負載多少游戲人數。

測試沒有問題后，進入小規模的部署，一般是先開一個體驗服，跑2周時間，然后找人數最少的一個區組，跑2周到4周，然后在找人數最多的一個區組，跑2周到4周，沒有問題后，逐步的將游戲遷移到虛擬化環境，直至進入最終的虛擬化運維。

關于測試時間一個慘痛教訓的案例

當時我們有一款游戲，是一款比較老的端游，前期做了大量的機器人壓力測試，都沒有問題，又開了體驗服測試，也沒有問題，然后在生產環境上了人數最少的一個區組，跑了一周，也沒有問題，這時候覺得應該沒有問題了，有點急躁，一下子上來好幾個區組，這些區組虛擬化一周以后很穩定，但是到了第二周的周四，開始出現頻繁的游戲進程宕掉，玩家大面積掉線的情況。這時候就非常被動，只能硬著頭皮去解決了，現在回想起來，如果當時***個生產環境虛擬化的區組能測試的時間長一些，讓這個問題提早暴露出來，至少影響面要小的很多。

游戲虛擬化實施過程中要解決那些問題

***點是穩定性，穩定性尤其在游戲行業特別重要，因為穩定性是和收入掛鉤的，沒有了穩定性就沒有了收入，搞任何的節省成本都沒有意義的。

第二點是快速的管理維護，穩定性解決之后，面臨的下一個問題就是如何快速的得到一臺或者一批虛擬機，如何快速的完成虛擬機從生成、維護、到銷毀的生命周期管理，這時候往往需要一個管理平臺。管理平臺可以使用開源產品，比如oVirt，OpenStack等等，也可以自己開發。

第三點是與業務的緊密結合，***是虛擬機生成的時候，游戲程序也能跑起來，這個有兩種解決辦法，一種是針對不同游戲制作不同的專用鏡像，這樣當虛擬機生成的時候，游戲程序就在里面，但是這種方案在游戲頻繁發布版本的時候比較被動，因為每次發布版本都要更新鏡像。另外一種辦法是，使用比較通用的鏡像，在虛擬機生成的時候，將游戲程序和配置文件塞進虛擬機，當虛擬機生成啟動后，自動完成配置。

第四點是要做好監控報警，應急響應。任何事物都有兩面性，搞虛擬化之后，當出現故障的時候，影響面要大很多。一款游戲，原來在物理機上的時候，一臺物理機故障，影響最多一個區組，當實施了虛擬化之后，一臺宿主機故障，影響的是好幾個游戲區組，這就要求我們做好應急響應和監控報警，早點發現并解決問題，甚至當問題將要發生的時候就能提前預防。

實施過程中有那些虛擬化技術要點

KVM虛擬化詳細的技術在這里就不介紹了，只介紹一些在游戲虛擬化中的注意點。在介紹之前先來看下游戲業務的壓力模型。

#p#

游戲業務的壓力模型

游戲業務主要分為兩類模型：

GS(Game Server)類：主要是CPU密集型，CPU、內存、網絡消耗高，磁盤IO消耗低。

DB(數據庫)類：主要是IO密集型，CPU、內存消耗低，網絡、磁盤IO消耗高。

游戲業務的IO還有兩個特點：

網絡IO是小包，我們更關注發包率pps

磁盤IO更多是隨機小塊寫，我們更關注IOPS

游戲虛擬化中CPU技術要點

在游戲虛擬化中，我最喜歡的是CPU技術是CPU綁定，CPU綁定是一個非常神奇的技術，最神奇的地方就是可以在線去做，在實戰中解決多次解決了性能問題。

一個CPU綁定的案例

當時有一款游戲，已經虛擬化了好幾個月了，一直很穩定，有一個周末，游戲搞活動，玩家激增，有玩家有反饋游戲有玩游戲卡的情況。我登錄宿主機一看，發現宿主機部分CPU利用率非常高，宿主機是32核，前面幾個核CPU利用率已經90%以上，但是后面幾個核壓力比較低，只有30-40%，我立即做了一個在線的CPU綁定，人工將CPU利用率拉平，解決了這個問題。

CPUhost-passthrough技術

CPU host-passthrough技術主要是將物理CPU的特性全部傳給虛擬CPU，根據應用的不同，對CPU的性能提升也不同。另外還有一個好處，就是在虛擬機中可以看到和物理機一模一樣品牌型號的CPU，對于一些公有云來說，用戶體驗比較好。但是使用CPUhost-passthrough技術也要注意，這個技術不支持在不同型號CPU的宿主機之間在線遷移虛擬機。

游戲虛擬化中內存技術要點

KSM相同內存頁合并，或者叫內存壓縮技術，游戲虛擬化的時候一般建議關掉。為什么呢?因為游戲業務是高壓力應用，對CPU、內存的壓力非常高，一方面KSM不停在掃描內存，會消耗CPU資源，另外一方面，分給游戲虛擬機的內存，我們希望是分給多少，能利用多少，打開KSM就是為了內存超用，如果真的超用了，當游戲壓力大的時候，就會出現內存不夠用的情況，這個使用就會有大量的SWAP交互，嚴重影響虛擬機的性能，影響玩家的游戲體驗。

關于虛擬機時間漂移

所以的虛擬機，不光是KVM，包括VMWare，XEN，HyperV，都有一個問題，就是因為虛擬機的時鐘是模擬出來的，一般虛擬機的走時要比物理機快一些。當然，因為虛擬化的流行，這個問題在***的操作系統上優化的越來越好。一般在生成環境，所有的虛擬機建議都配置精確時鐘和NTP，以保證走時準確。有些游戲，對時間精度要求非常高，更要注意虛擬機時間的配置。

關于磁盤

一般虛擬機磁盤鏡像格式建議是qcow2或者lvm，因為這兩種格式有個共同的特定，就是可以動態的擴容，快照，并且支持精簡模式，使用管理起來非常方便。

磁盤的驅動VirtIO是標配，VirtIO是一種半虛擬化的驅動，可以跳過用戶空間的虛擬化層，大大提高通訊效率。

磁盤緩存方式，常見的有四種，writeback,writethrough,none,unsafe，實際上是在虛擬化層和宿主機的文件系統這一層，開不開cache的各種組合，現在CentOS系列上默認是writeback模式，這種模式啟用了宿主機文件系統的緩存，性能會好很多。我們在生產環境比較保守，一般在單機虛擬化的時候，使用writethrough方式，以數據安全為***位，在集群虛擬化，就是需要虛擬機遷移的場景，使用none方式，因為虛擬機要遷移，必須使用none方式。

關于網絡

見前段時間發布的《KVM虛擬化網絡優化技術總結》已經非常詳細的介紹了。

虛擬化的存儲方式

單機虛擬化

單機虛擬化的形式是一臺宿主機虛擬幾臺虛擬機，虛擬機的計算、存儲、網絡都在這臺宿主機內，是一種非常靈活的虛擬化方式，他不對原有的環境做任何改變，一臺宿主機，放到機房，虛擬化就搞起來了。

商業存儲集群

這種虛擬化方式由商業存儲和若干計算節點組成，虛擬機鏡像在商業存儲上，虛擬機使用計算節點的計算、內存、網絡資源。因為有了共享存儲，就可以做虛擬機的在線遷移，配置虛擬機搞可用，配置計算資源的動態平衡。

關于商業存儲的選擇

目前常見的存儲分為文件存儲和塊存儲，快存儲又分為ISCSI，FC。不管是那種存儲，一般建議生產環境都是雙控制器，一般支持雙控制的存儲，從軟件到硬件都是雙冗余的，沒有單點故障。

另外，NFS和ISCSI一直有爭論，這個看自己對那種技術更熟悉，更喜歡。

FC的存儲成本比較高，但是性能也***，我個人喜歡ISCSI存儲，性價比高，性能基本也能滿足自己的要求。

總的來說，存儲的選擇需要考慮以下三點：

業務性能要求

預算

自己對技術的熟悉程度

#p#

分布式文件系統

這種方式其實是集群虛擬化的一個變種，就是用普通的pc server替換商業存儲，這種方式的好處是可以規模做的非常大，并可以動態擴展，一般公有云都是這樣的架構。

三種存儲方式在游戲虛擬化中的應用場景

單機虛擬化

壓力比較高，虛擬機比例比較低的游戲

一個機房虛擬機比較少的情況

主要是端游

集群虛擬化

壓力中低等，虛擬化比例在1：7以上的游戲

虛擬機數量多，強調快速部署，強調高可用的游戲

主要是手游頁游

分布式文件系統虛擬化

總體磁盤IO 1000iops以下

和商業集群存儲組合使用

主要是gs類的游戲服務器

另外，SSD在虛擬化存儲中使用越來越多，SSD和軟件結合的軟件定義存儲方式也越來越熱，以后有時間，給大家介紹一些相關的案例。

虛擬機資源限制

一般在生產環境，需要給虛擬機做資源限制，因為我們不希望一臺虛擬機消耗的資源過多，造成其他虛擬機餓死，虛擬機的資源限制主要是通過CGroup去做，CGroup可以配置的選項非常多，也非常靈活，就是配置起來稍微復雜一些。

Libvirt在CGroup上包了一層，通過修改虛擬機的xml文件，就可以完成對虛擬機的資源限制，通過Libvirt限制虛擬機的詳細介紹，請參考我的博客文檔，介紹的比較詳細：

http://xiaoli110.blog.51cto.com/1724/1070201

虛擬化運維中的監控、報警、災備及應急響應要點是什么

監控報警

硬件故障報警，我現在主要是使用帶外管理卡報警，新一代服務器，帶外管理卡監控已經非常完善，CPU 、內存、磁盤、網卡、風扇、電源任何硬件故障都會報警，通過郵件，或者寫腳本和自己的監控平臺結合，可以很好的解決硬件報警的問題。

CPU方面，建議每個核的CPU利用率也監控起來，經常會碰到一直情況，就是整體的CPU利用率不高，可能只有20-30%，但是有一兩個核已經100%了，這時候其實已經碰到壓力瓶頸了，但是通過整體的CPU利用率是發現不了的。

內存方面，swap利用情況建議也監控起來，作為虛擬化來說，一般不希望宿主機使用swap分區，所以swap的使用要監控起來，方便出問題的時候排查，如果有大量的swap使用，應該設置報警，肯定是碰到性能問題了。

磁盤、網絡方面，虛擬化磁盤、網絡是兩個難點，一般在上線之前，應對其性能進行壓力測試，得到極限數據，然后根據極限數據設置報警閥值。

災備及應急響應

虛擬化的災備有兩種思路，應用層災備及虛擬化層災備，一般建議在應用層災備。虛擬化層災備的手段是多份的鏡像復制及快照，這個往往要消耗大量的資源，多份復雜是以犧牲幾倍的磁盤空間為代價，快照是以犧牲性能為代價。往往應用層做了很少的改動，虛擬化層是不能感知的，只是是全部備份，或者快照。

但是在應用層災備就簡單很多，只需要備份改動的部分，消耗的資源很少，而且速度很快。一般我們在生成環境的做法是，備份虛擬機的xml文件，當故障發生時，提供一臺配置一模一樣的虛擬機，如果有需要mac地址也保持一致，然后交給業務方進行恢復。

災備還要注意，定期演練非常重要，一方面是驗證自己的災備幾種，一方面也是讓參與的人能熟悉災備過程，這樣當發生問題的時候，就可以很快的恢復業務。

軟硬件選型

軟件方面，當然是穩定版本，但是在穩定版本的基礎上，內核版本越高越好，為什么呢?因為內核版本越高，對CPU的上下文切換和中斷優化的越好，越有利于提高宿主機轉化率。Windows系統也一樣，Windows虛擬機建議盡量使用比較新的版本。

硬件方面越強悍越好，內存越大越好，硬件越強悍，可以虛擬的虛擬機越多，從長時間綜合看，肯定是節省成本的。另外，一臺宿主機，使用上一段時間，我們往往發現內存是瓶頸點，所有一開始的時候，盡量內存配置點一點，可以避免隨后的內存瓶頸。