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

分布式文件系统

这种方式其实是集群虚拟化的一个变种，就是用普通的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虚拟机建议尽量使用比较新的版本。

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

---

---