虚拟化专家肖力:五年游戏虚拟化运维实践 |运维帮首发

Posted 运维帮

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了虚拟化专家肖力:五年游戏虚拟化运维实践 |运维帮首发相关的知识,希望对你有一定的参考价值。

点击上方
“运维帮”
可关注我们!


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

  1. 为什么要搞游戏虚拟化

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

  3. 游戏虚拟化如何实施

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

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

  6. 虚拟化的存储方式

  7. 虚拟机资源限制

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

  9. 软硬件选型


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


为什么要搞游戏虚拟化

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

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

游戏业务的压力模型

游戏业务主要分为两类模型:

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存储,性价比高,性能基本也能满足自己的要求。

总的来说,存储的选择需要考虑以下三点:

  • 业务性能要求

  • 预算

  • 自己对技术的熟悉程度

分布式文件系统


虚拟化专家肖力:五年游戏虚拟化运维实践 |运维帮首发

这种方式其实是集群虚拟化的一个变种,就是用普通的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使用,应该设置报警,肯定是碰到性能问题了。

磁盘、网络方面,虚拟化磁盘、网络是两个难点,一般在上线之前,应对其性能进行压力测试,得到极限数据,然后根据极限数据设置报警阀值。

灾备及应急响应

虚拟化的灾备有两种思路,应用层灾备及虚拟化层灾备,一般建议在应用层灾备。虚拟化层灾备的手段是多份的镜像复制及快照,这个往往要消耗大量的资源,多份复杂是以牺牲几倍的磁盘空间为代价,快照是以牺牲性能为代价。往往应用层做了很少的改动,虚拟化层是不能感知的,只是是全部备份,或者快照。



灾备还要注意,定期演练非常重要,一方面是验证自己的灾备几种,一方面也是让参与的人能熟悉灾备过程,这样当发生问题的时候,就可以很快的恢复业务。

软硬件选型

软件方面,当然是稳定版本,但是在稳定版本的基础上,内核版本越高越好,为什么呢?因为内核版本越高,对CPU的上下文切换和中断优化的越好,越有利于提高宿主机转化率。Windows系统也一样,Windows虚拟机建议尽量使用比较新的版本。

硬件方面越强悍越好,内存越大越好,硬件越强悍,可以虚拟的虚拟机越多,从长时间综合看,肯定是节省成本的。另外,一台宿主机,使用上一段时间,我们往往发现内存是瓶颈点,所有一开始的时候,尽量内存配置点一点,可以避免随后的内存瓶颈。


作者简介

肖力

西山居系统运维经理,前盛大游戏研究员

十五年的运维工作经验,十年的游戏行业从业经验,五年的KVM虚拟化运维经验,实施过四十多款的游戏项目虚拟化。

作者的KVM虚拟化运维新书《KVM虚拟化运维及性能优化》,目前正处于收尾阶段,预计九月初出版。

作者维护有微信订阅号“KVM虚拟化实践”,欢迎关注。


---------------------------------------------

关注运维帮获取很多技术咨询




以上是关于虚拟化专家肖力:五年游戏虚拟化运维实践 |运维帮首发的主要内容,如果未能解决你的问题,请参考以下文章

虚拟化项目的监控灾备及案例 | 肖力说KVM

干货 | SSD在KVM虚拟化的测试和使用实践

KVM虚拟化集群技术概述

阿里HBase 电信云堤 美团DBA架构,运维帮助力WOT2016运维大会

单机虚拟化技术及生产环境实践

抓住成本和效率,AIOps 在 360 的探索实践之路