本文是我五年游戏虚拟化运维实践的总结，主要分享以下几项内容：
为什么要搞游戏虚拟化
那些游戏适合/不适合虚拟化
游戏虚拟化如何实施
实施过程中要解决那些问题
实施过程中有那些虚拟化技术要点
虚拟化的存储方式
虚拟机资源限制
虚拟化运维中的监控、报警、灾备及应急响应要点是什么
软硬件选型
说到底就是一句话，如何将游戏迁移到虚拟化环境中，并稳定运行。
为什么要搞游戏虚拟化
为什么要搞游戏虚拟化，或者说虚拟化给游戏带来什么。
***点，也是最重要的一点是可以节省成本。举一个例子，假设有一款游戏，有一个区组，有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虚拟机建议尽量使用比较新的版本。
硬件方面越强悍越好，内存越大越好，硬件越强悍，可以虚拟的虚拟机越多，从长时间综合看，肯定是节省成本的。另外，一台宿主机，使用上一段时间，我们往往发现内存是瓶颈点，所有一开始的时候，尽量内存配置点一点，可以避免随后的内存瓶颈。
