容器 or 传统虚拟化?

小秦之前在一家国内互联网巨头公司工作,那时所在部门遇到了一个问题:机器的使用率不高。打个比方,如果一台主机的生命周期是5年,可能这台主机在其过保前其CPU使用率都始终是在一个非常非常低的水平,比如CPU平均使用率为百分之十(这个数字以及接下来提到的所有数字都不是真实数据,这里只是举这个数字方便我们下面进行计算)。

可能很多人认为机器使用率低是好事,说明程序优化的好,但实际上对于研发团队来说降低代码的资源占用率当然是好事,但是对于采购部门或者公司的预算来说就不是好事情了。毕竟资源闲着就说明多花了冤枉钱,假设一共有十万台主机(这个量级对于国内很多互联网公司都是低估的),那么百分之九十的资源浪费就相当于浪费了九万台主机,每台主机算它采购价十万,这样就浪费了九个亿。所以当时小秦所在的部门的一个任务就是提高主机的资源使用率。如何提高呢?经过分析,小秦所在部门的应用是内存消耗型的,所以打算和一些CPU消耗型的应用混部。但是混部的时候要保证这些应用不能互相影响(当然混部还有非常多的要考虑的地方,比如优先级等等,这里我们只讲本章关注的),比如CPU消耗型应用A所占用的内存规定是多少就只能是多少,否则会影响到同一台物理机上的内存消耗型业务。为了解决这个问题当时的做法是基于CGroup。本章下面介绍Docker的时候大家会看到CGroup是Docker的核心技术。可能有人会问通过虚拟化不是也能做到这一点吗?确实虚拟化也能实现这一点,但是虚拟化存在下面的一些问题:

1. 虚拟化本身消耗的资源过多,我们的最根本目的是为了省钱,所以相比之下虚拟化不是最好的选择
2. 我们的应用会的被频繁的启动、停止、更新。基于虚拟化的话启动、停止等操作速度太慢
3. 虚拟化提供了一个完全隔离的环境,这个是虚拟化的优点,但是对于我们这个完全是内部使用的环境来说这不是我们最需要的功能

因此我们选用了CGroup,大家可以看成是使用了容器来实现混部这么一个需求。对于这套系统的开发者来说其主要的工作量是用于控制系统的开发,比如我启动了一个应用A,这个应用A如何在集群中找到合适的主机启动,同时如何同步相关联监控、元数据管理等等。这一点上小秦想说的是:对于容器或虚拟化来说,控制系统的设计存在细微差别,但核心思想是一样的。

这就是小秦所切身经历的一个基于容器技术的一个例子,大家可以看到使用容器比使用虚拟化所带来的优点。但小秦必须指出一些现实的问题:

1. 当时小秦所在的公司规模很大,非常大。集群上跑的业务只有超大规模的互联网公司才会接触到。如果使用虚拟化比使用容器会多消耗百分之十到百分之三十的资源,对于当时小秦所在的公司确实是一笔很客观的数目,但是对于一般企业来说这个数目是否值得去做需要大家考虑
2. 虽然CGroup做了隔离,但这种隔离并不完全。不同部门在运行这些业务之前需要仔细划定业务优先级等信息(用云的术语来说就是超卖)。CGroup中内存方面的超卖一不小心就是OOM
3. 当时我们在这套系统上运行的业务系统和传统公司所运行的业务系统不太一样。举个可能夸张一些的例子,传统公司会习惯于在一台主机上运行LAMP(Linux+Apache+MySQL+PHP)来支持其业务,但如果要放到我们上面的系统里,就需要启动两个任务分别运行Apache+PHP、MySQL。同时其需要花时间、精力在上述系统的控制器的实现上
4. 考虑一下业务的长期发展。对于小秦当时所在的公司,底层服务已经能做到很好的scale-out了。其底层服务可以很好的应付宕机、突然假死等问题。比方说节点A宕机了,那么就丢弃节点A即可,业务不会受到影响。在这种情况下使用集群+容器的方法进行资源的调度是非常合适的。但是对于传统企业来说要做到这一点还需要时间,甚至可能其在接下来很多年里其业务量都达不到这个水平
5. 如果一个企业需要的是一个虚拟机,那么就不适合使用容器了。容器更倾向于PaaS而不是IaaS。大家一定要清楚这两者的区别,你买了PaaS的MySQL服务后对提供商说你想在上面再跑个Apache,提供商一定会让你再去买一个Apache容器。但如果你买了个IaaS,你想在上面干啥就能干啥,只不过安装部署等需要你自己完成。对于集中式的云服务提供商来说提供基于容器的PaaS是一个不错的选择,但对于传统企业来说就需要考虑考虑了。

所以小秦个人认为,对于容器技术比较适合在一些超大型公司使用。对于这些公司来说运行在容器集群之上的业务已经能做到宕机一台不担心,宕机十台也不担心的地步。或者当一些公司希望提供PaaS平台给外界使用的时候,基于容器也是一个不错的选择,但这和之前说的内部业务还存在区别,如果是提供基于容器的PaaS,则控制器必须考虑运行在容器上的客户业务的高可用、资源扩展等等,比如对于大型互联网公司来说,一个运行在容器上的MySQL挂了就挂了,没关系,但是对于来买你服务的客户来说他可不希望买到的一个MySQL容器没有任何的高可用。同时就拿后者来说,如果是MySQL,还得考虑MySQL的备份、性能诊断等等方面,从这个角度来说,如果要对外提供一个PaaS平台,或许更多的考虑并不在于是基于容器还是虚拟化,而是一些其它部分吧。慢慢的我们会看到一些软件其本身就是基于提供PaaS服务而设计的,小秦认为这也是一种方向。

所以小秦个人认为,目前容器还是超大规模公司特定业务的工具。

另外还有很多的文章是关于基于容器实现开发、测试、部署一条龙服务的。关于这一点小秦并没有实际的经验,如果容器真的能解决这个问题当然是太赞了,因为小秦目前所看到的一条龙都是少量自动化混杂着大量人肉的自动化,有些甚至还做的不如原来手工部署来的方便。但我想这个对于传统企业(很多企业是没有开发部门的)来说应该不是一个要考虑的事情。

希望写到这里,大家可以自己更多的思考下应该在实际的环境中使用容器还是使用虚拟化技术。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*