金山运维肖力:如何将业务迁移到虚拟化环境并稳定运行

原创
运维 系统运维
肖力,金山西山居系统运维经理,前盛大游戏研究员,有15年工作经验,10年游戏行业运维经验,5年KVM虚拟化运维经验,有40款游戏虚拟化项目成功实施经验。维护有微信订阅号:“KVM虚拟化实践”著有《深度实践KVM》一书。本文介绍肖力在长期的虚拟化项目实践中的经验,主要介绍如何将已有的业务迁移到虚拟化环境。

 

高招微课是由51CTO高招发起,面向IT行业内的工程师以及程序员在线交流分享的课堂,让我们用心去感受技术领域不一样的干货。

51CTO高招微课 

 

 

第三讲

 

肖力,金山西山居系统运维经理,前盛大游戏研究员,有15年工作经验,10年游戏行业运维经验,5年KVM虚拟化运维经验,有40款游戏虚拟化项目成功实施经验。维护有微信订阅号:“KVM虚拟化实践”著有《深度实践KVM》一书。

 

以下是正文:   

 

大家好,本次介绍我在长期的虚拟化项目实践中的经验,主要介绍如何将已有的业务迁移到虚拟化环境。

 

先简单介绍下,我维护有一个订阅号“KVM虚拟化实践”可以一起交流,共同讨论学习。

将已有的业务迁移到虚拟化环境。是很大的挑战,不仅要求我们熟悉虚拟化技术,更要求我们熟悉业务,将业务迁移到虚拟化环境其实还是一个项目实施的过程,考验我们的协调沟通及项目把控能力。

我分为四个部分介绍如何将业务迁移到虚拟化环境:

  

 

1、虚拟化项目实施方法及业务压力模型的建立:介绍虚拟化项目的实施经验及流程,介绍如何建立自己的业务压力模型,如何根据自己的业务压力模型进行软硬件选型。

2、虚拟化技术选型及实战:介绍KVM虚拟化技术在实践方面的经验。

3、虚拟化项目的监控、报警、应急响应、灾备方法。

4、将业务迁移到公有云方法:介绍公有云选择及业务迁移到公有云方法,将业务迁移到公有云也是业务虚拟化的一种形式,只是我们不用在关心虚拟化技术。

 

在我们决定做虚拟化的时候,虚拟化项目该如何起步?

当上级或者我们自己准备将业务迁移到虚拟化环境上的时候,会面临许多问题,例如:  

 

从那一项具体业务开始;
软硬件如何选型;
技术方案如何确定;
万一出了问题应该怎么办;
在虚拟化的过程中如何保证业务稳定。

 

那么,我们首先应该解决那个问题呢?这时候我们应该静下心来想一想,虚拟化到底能给我们企业带来什么。

从我的虚拟化实践来看,归根结底虚拟化给企业带来两点好处: 

 

节省成本;
快速部署。

 

 

(1)节省成本

大多数时候,我们选择虚拟化就是为了节省成本,举一个非常典型的案例,我们曾经虚拟化过一款游戏,这款游戏在虚拟化之前,使用五百多台物理机,当时运行了两年多,已经收支平衡,换句话说就是不盈利了,面临着马上被结项的命运。

这个时候,我们部署了虚拟化,将这款游戏按照一比七的比例,全部迁移到虚拟化环境。通过虚拟化技术,将五百多台物理机压缩到七十多台宿主机上,极大的节省了游戏的成本,这款游戏又开始盈利了。

(2)快速部署

虚拟机在宿主机层面看就是一个镜像文件,我们要得到另外一台虚拟机,只需要将镜像文件复制一份就可以了,通常是几分钟,最多十几分钟。

而一台物理机,上架、插电源、拉网线、安装操作系统,最快都要一个多小时,这是从小时到分钟的数量级的差距。通过虚拟化可以大大提示部署效率。

想好了虚拟化能带给我们什么之后,下一步就是说服老板和同事协助我们进行虚拟化,有了老板和同事支持,我们才能顺利的推进虚拟化项目进行。

#p#

(1)说服老板的秘诀。

说服老板有两个秘诀:“画饼”和“挖坑”,往往老板比较好说服,因为虚拟化能给企业带来真金白银的好处。比如如果企业现在有2000台服务器,即使按照一比二这样一个比例实施虚拟化,立马就可以节省50%服务器,50%的机柜。

所以,我们其实也不是在画饼,这个饼真实存在,并且可以吃到的。但是画饼的时候,要挖一个“坑”,因为在业务迁移虚拟化的时候,难免碰到这样或者那样的问题,碰到问题的时候,我们需要老板的支持,在做虚拟化迁移之前,我们就要和老板说好,虚拟化会给企业带来巨大的利益,实施过程中我们会做好各种预案,充分做好测试,但是也难免会碰到问题,万一碰到问题的时候需要老板支持我们,力挺我们。

(2)说服同事支持的秘诀。

往往说服同事支持很困难,因为大部分同事都是多一事不如少一事这样的心态,如果业务在物理机上已经非常稳定了,大部分人肯定不愿意再折腾一次了。这时候说服同事的办法就是树立一个样板,用事实说话,让大家看到业务可以在虚拟化平台上稳定运行。

如何选择第一个虚拟化项目。

选择第一个虚拟化项目非常重要,和打仗一样,首战必胜,这是一个战略问题,如果第一个虚拟化项目失败了,后面的工作就很难开展,万事开头难,那么如何选择第一个虚拟化项目呢?适合虚拟化的业务有那些特征了呢?


(1)单进程

但进程的业务非常适合虚拟化,现在的CPU都是多核,单进程的业务只使用一个核,通过虚拟化就可以很好的将多个单进程的业务整合在一起,尤其是通过应用层很难进程优化的业务。

(2)利用率非常低

常年CPU利用率在20%以下,这种业务通过虚拟化也非常好整合,将几个业务整合到一台宿主机上,可以提高整体的利用率。

(3)频繁变动的业务

这种业务搞虚拟化的动力最强,因为虚拟化快速部署的特点确实能解决他们的痛点。对运维来说,能节省成本他们不一定有动力,但是说能快速简单实现,他们动力很足。

(4)非核心业务

一开始虚拟化的时候,最好不要选核心业务,否则出了问题,压力会很大。核心业务应在口碑树立起来之后,在逐步进行虚拟化。

第一个虚拟化项目应该从自己企业内部找一个最符合以上条件的业务,来进行虚拟化,以提高虚拟化的成功率。

另外,并不是所有的业务都适合虚拟化,那有哪些业务不适合虚拟化呢?

压力特别高的业务不建议搞虚拟化,如果在物理机上CPU利用率已经80%了,就很难通过虚拟化进行压缩。

虚拟化项目实施应该遵循哪些流程,能保证比较稳定的将业务迁移到虚拟化环境?

从我个人长期的实践来看,虚拟化实施最好循序渐进,稳扎稳打,遵循以下的步骤,可以保证比较稳定的业务迁移到虚拟化环境。

(1)业务性能评估及压力模型建立

项目启动的时候,首先面临的是虚拟化比例如何确定,到底是1虚5,还是1虚7比较合适,宿主机的配置如何确定,这些都需要依靠数据决定,所以我们首先需要收集现有业务的压力数据,根据压力数据分析业务的压力模型。业务压力模型建立方法,后面还有详细介绍,有了压力模型,虚拟化比例和宿主机选型就非常好确定。

(2)测试环境测试

虚拟化比例和宿主机确定好之后,然后应该进行测试,测试包括系统方面的测试和业务方面的测试,系统方面测试主要测试宿主机和虚拟机的压力瓶颈点,看看宿主机和虚拟机最大的负载点在那里,为以后使用做到心里有底。

业务测试包括业务的功能测试和性能测试,功能测试主要测试业务在虚拟机上运行有没有问题,性能测试主要测试业务在虚拟机上能够承担的最高负载,比如游戏行业能负载多少人数,web,数据库能负载多少连接或者io,这个要根据每个业务的不同,使用业务应用层的测试方法进行测试。

通过测试,一方面我们可以测试稳定性,一方面可以得到业务在虚拟机上的最大负载,取得这些数据,我们就可以做到对以后的虚拟机使用心中有数。

(3)小规模部署

测试环境测试没有问题,并且取得相关数据后,就可以在生产环境部署,先应该在生产环境小规模的进行部署,并且测试2周到一个月。小规模部署最好是业务压力比较小的一台虚拟机测试2周到一个月,没有问题后在找业务压力最大的一组进行虚拟化,在测试2周到一个月。

(4)全面部署

小规模部署没有问题后,就可以逐步的进行全面虚拟化部署,按部就班的将业务迁移到虚拟化环境,直至进入最终的虚拟化运维。

下面介绍下业务压力模型的构建方法。

下定决心做虚拟化之后,面临的下一个问题是到底虚拟化比例如何确定,宿主机的配置如何选型,这时候就需要根据自己的业务特点,建立压力模型,根据压力模型确定虚拟化比例,宿主机、虚拟机的配置。

#p#

那么如何建立压力模型呢?这个要用数据说话,数据来自于长期的监控指标及高峰时的数据收集。

一般我们会去看监控系统至少60天之内的数据,尽量做到每台服务器的压力数据都收集下,如果数量比较多,可以抽取压力比较大的一部分机器提炼压力模型。

另外,在业务高峰期的几个小时,可以考虑使用脚本收集比较密集的数据,一般监控平台收集的是1到5分钟的数据,通过脚本可以收集5-30秒间隔的数据,提高我们数据收集的精度,脚本其实就是使用sar、iostat、vmstat等命令编写。

所有的数据收集完成以后,就可以根据数据提炼出业务的压力模型。

有了压力模型,根据压力模型就非常好确定虚拟化的比例和宿主机选型了。

下面再分享一些生产环境的虚拟化技术经验。

虚拟化中CPU技术要点:

我最喜欢的是CPU技术是CPU绑定,CPU绑定是一个非常神奇的技术,最神奇的地方就是可以在线去做,在实战中多次解决了性能问题。

CPUhost-passthrough技术。

CPU host-passthrough技术主要是将物理CPU的特性全部传给虚拟CPU,根据应用的不同,对CPU的性能提升也不同。

另外还有一个好处,就是在虚拟机中可以看到和物理机一模一样品牌型号的CPU,对于一些公有云来说,用户体验比较好。但是使用CPUhost-passthrough技术也要注意,这个技术不支持在不同型号CPU的宿主机之间在线迁移虚拟机。


虚拟化中内存技术要点:

KSM相同内存页合并,或者叫内存压缩技术,虚拟化的时候一般建议关掉。为什么呢?一 方面KSM不停在扫描内存,会消耗CPU资源。

另外一方面,分给虚拟机的内存,我们希望是分给多少,能利用多少,打开KSM就是为了内存超用,如果真的超用了,当压力大的时候,就会出现内存不够用的情况,这个使用就会严重影响大量的SWAP交互

网络方面主要解决两个问题,可管理性和性能,可管理性主要依靠Open vSwitch这个纯软件的交换机,ovs可以和物理交换机进行协议层面的通讯。

性能有硬件和软件的优化方案,硬件主要是使用万兆万卡和SRIOV,软件是VIRTIO、网卡独占等技术。

今天时间关系就不详细介绍了,大家可以看下我的博客:http://xiaoli110.blog.51cto.com/1724/1558984

关于虚拟机时间漂移

所有的虚拟机,比如KVM,包括VMWare,XEN,HyperV,都有一个问题,就是因为虚拟机的时钟是模拟出来的,一般虚拟机的走时要比物理机快一些。

当然,因为虚拟化的流行,这个问题在最新的操作系统上优化的越来越好。一般在生成环境,所有的虚拟机建议都配置精确时钟和NTP,以保证走时准确。有些业务,对时间精度要求非常高,更要注意虚拟机时间的配置。

关于磁盘

一般虚拟机磁盘镜像格式建议使用qcow2或者lvm,因为这两种格式有个共同的特定,就是可以动态的扩容,快照,并且支持精简模式,使用管理起来非常方便。

#p#

磁盘的驱动VirtIO是标配,VirtIO是一种半虚拟化的驱动,可以跳过用户空间的虚拟化层,大大提高通讯效率。

磁盘缓存方式,常见的有四种:writeback,writethrough,none,unsafe。

实际上是在虚拟化层和宿主机的文件系统这一 层,开不开cache的各种组合,现在CentOS系列上默认是writeback模式,这种模式启用了宿主机文件系统的缓存,性能会好很多。 

我们在生产环境比较保守,一般在单机虚拟化的时候,使用writethrough方式,以数据安全为第一位,在集群虚拟化,就是需要虚拟机迁移的场景,使用none方式。因为虚拟机要迁移,必须使用none方式。

下面介绍下虚拟化的存储方式:

单机虚拟化

单机虚拟化的形式是一台宿主机虚拟几台虚拟机,虚拟机的计算、存储、网络都在这台宿主机内,是一种非常灵活的虚拟化方式,他不对原有的环境做任何改变,一台宿主机,放到机房,虚拟化就搞起来了。

虚拟化集群

这种虚拟化方式由商业存储和若干计算节点组成,虚拟机镜像在商业存储上,虚拟机使用计算节点的计算、内存、网络资源。因为有了共享存储,就可以做虚拟机的在线迁移,配置虚拟机搞可用,配置计算资源的动态平衡。

关于商业存储的选择。

目前常见的存储分为文件存储和块存储,快存储又分为ISCSI,FC。不管是那种存储,一般建议生产环境都是双控制器,一般支持双控制的存储,从软件到硬件都是双冗余的,没有单点故障。

另外,NFS和ISCSI一直有争论,这个看自己对那种技术更熟悉,更喜欢。

FC的存储成本比较高,但是性能也最好,我个人喜欢ISCSI存储,性价比高,性能基本也能满足自己的要求。

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

 

业务性能要求
预算
自己对技术的熟悉程度

 

分布式文件系统:

这种方式其实是集群虚拟化的一个变种,就是用普通的pcserver替换商业存储,这种方式的好处是可以规模做的非常大,并可以动态扩展,一般公有云都是这样的架构。

#p#

三种存储方式在虚拟化中的应用场景:  

 

单机虚拟化;
压力比较高,虚拟机比例比较低的游戏;
一个机房虚拟机比较少的情况。

 

集群虚拟化

压力中低等,虚拟化比例在1:7以上的游戏;

虚拟机数量多,强调快速部署,强调高可用的业务。  

 

分布式文件系统虚拟化;
总体磁盘IO 1000iops以下;
和商业集群存储组合使用。

 

另外,SSD在虚拟化存储中使用越来越多,SSD和软件结合的软件定义存储方式也越来越热。以后有时间,给大家介绍一些相关的案例。

虚拟机资源限制

一般在生产环境,需要给虚拟机做资源限制,因为我们不希望一台虚拟机消耗的资源过多,造成其他虚拟机饿死,虚拟机的资源限制主要是通过CGroup去做,CGroup可以配置的选项非常多,也非常灵活,就是配置起来稍微复杂一些。

Libvirt在CGroup上包了一层,通过修改虚拟机的xml文件,就可以完成对虚拟机的资源限制,通过Libvirt限制虚拟机的详细介绍,请参考我的博客文档,介绍的比较详细:

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

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

#p#

监控报警

硬件故障报警,我现在主要是使用带外管理卡报警,新一代服务器,带外管理卡监控已经非常完善,CPU 、内存、磁盘、网卡、风扇、电源任何硬件故障都会报警,通过邮件,或者写脚本和自己的监控平台结合,可以很好的解决硬件报警的问题。

CPU方面,建议每个核的CPU利用率也监控起来,经常会碰到一种情况,就是整体的CPU利用率不高,可能只有20-30%,但是有一两个核已经100%了,这时候其实已经碰到压力瓶颈了,但是通过整体的CPU利用率是发现不了的。

内存方面,swap利用情况建议也监控起来,作为虚拟化来说,一般不希望宿主机使用swap分区,所以swap的使用要监控起来,方便出问题的时候排查,如果有大量的swap使用,应该设置报警,如果报警肯定是碰到性能问题了。

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

灾备及应急响应

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

往往应用层做了很少的改动,虚拟化层是不能感知的,只是全部备份,或者快照。

但是在应用层灾备就简单很多,只需要备份改动的部分,消耗的资源很少,而且速度很快。一般我们在生产环境的做法是,备份虚拟机的xml文件,当故障发生时,提供一台配置一模一样的虚拟机,如果有需要mac地址也保持一致,然后交给业务方进行恢复。

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

软硬件选型

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

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

下面分享最后一项内容,就让我对公有云选择的一些经验:

用户选择公有云的主要因素有以下5条:

1、市场

主要是价格,其中有些公司和某些公有云就有合作,或者就是老板强制指定必须使用某款公有云。

2、云主机稳定性

选择公有云,对用户来说,最终用的就是云主机,所以云主机的稳定性也是重要因素,不可以出现云主机三天两头崩溃、重启,甚至数据丢失。

一般稳定性公有云都能做到。

3、网络覆盖及网络质量

在云上业务都是基于网络,网络质量是一个很关键的因素,网络质量包含多个因素:

覆盖范围,覆盖范围越广越好。

延时,丢包,抖动,就是延时、丢包符合要求,网络抖动不能很频繁。

这个因素往往容易被忽略。

4、大数据分析、RDS、运维工具支持

如果公有云能提供API,提供一套方便业务部署监控的工具,对用户也有一定的吸引力,尤其是运维。

5、如果能提供物理机云主机的混合云是一个杀手级的解决方案。

业务压力非常高,就需要物理机的支持,现在可以看到好多公有云也开始支持物理机的租用。

将业务迁移到云上,其实和虚拟化的过程是一样的,按照前面介绍的流程去做,可以保证比较稳定的完成,而且虚拟化的具体技术还不用我们关心。

最后,总结下今天分享的内容:

在企业内部实施虚拟化,最重要的是口碑,如果一个项目接一个项目成功实施,就会越做越顺利,相反,如果连续失败1,2项目,虚拟化就推行不下去了。

我的分享结束了,欢迎大家提问,感谢!

接下来是QA环节

1、企业现有一大堆dell服务器,业务也比较多并杂,您建议选择那种整合的虚拟化方案或私有云方案?

答:这个问题非常好。如果是过老的机器,不建议当宿主机使用。具体的虚拟化方案是很复杂的问题,要根据业务、预算、应用来选择。

2、一个关于vpc网络的问题。当私有云有多个无法汇聚网段的时候,经常出现vpn网络不稳定,尤其网络物理链路中断后,也不能自动恢复vpn链接,估计可能的问题有哪些?

答:可以考虑使用专线的方式,如果基于公网不能保证稳定性。

为大家推荐关注:

更多内容等你来

高招CTO训练营

微信ID:gaozhao51ct

(长按二维码关注互动联系我们) 

 

 

责任编辑:火凤凰 来源: 51CTO.com
相关推荐

2015-05-27 15:20:02

肖力运维

2017-10-16 00:17:56

云计算信息管理迁移

2012-08-24 09:07:25

IBMdW

2021-07-13 09:45:48

CentOSAlmaLinux命令

2011-09-07 09:30:57

服务器虚拟机

2020-01-13 15:22:42

ERP云平台迁移

2023-08-23 09:00:00

区块链以太坊

2021-01-28 09:00:00

SQL数据库NoSQL

2012-10-29 09:27:16

2015-03-20 13:40:17

2010-01-22 16:08:11

IT运维管理

2020-08-11 11:08:24

云端云计算业务迁移

2020-12-08 10:01:48

DropboxNginxEnvoy

2011-06-28 13:29:01

2022-03-04 18:14:26

CentOSLinux

2017-12-02 21:33:43

2016-01-04 15:08:45

神州信息

2015-08-10 13:40:56

运维网站

2020-12-15 10:44:47

Progressive实习CIO

2019-07-16 10:33:36

云计算云安全IT安全
点赞
收藏

51CTO技术栈公众号