虚拟化专家肖力：五年游戏虚拟化运维实践(1)

虚拟化专家肖力：五年游戏虚拟化运维实践(1)

本文是我五年游戏虚拟化运维实践的总结，主要分享以下几项内容：

为什么要搞游戏虚拟化

那些游戏适合/不适合虚拟化

游戏虚拟化如何实施

实施过程中要解决那些问题

实施过程中有那些虚拟化技术要点

虚拟化的存储方式

虚拟机资源限制

虚拟化运维中的监控、报警、灾备及应急响应要点是什么

软硬件选型

说到底就是一句话，如何将游戏迁移到虚拟化环境中，并稳定运行。

为什么要搞游戏虚拟化

为什么要搞游戏虚拟化，或者说虚拟化给游戏带来什么。

第一点，也是最重要的一点是可以节省成本。举一个例子，假设有一款游戏，有一个区组，有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虚拟化详细的技术在这里就不介绍了，只介绍一些在游戏虚拟化中的注意点。在介绍之前先来看下游戏业务的压力模型。

---

---