微信号:greatops

介绍:高效运维公众号由萧田国及朋友们维护,经常发布各种广为传播的优秀原创技术文章,关注运维转型,陪伴您的运维职业生涯,一起愉快滴发展.

【学在GOPS】中国移动浙江公司的云化之路、DCOS 生产实践

2016-07-27 07:14 钟储健

本文根据〖2016 全球运维大会•深圳站〗现场演讲嘉宾分享内容整理而成,编辑同学为吴召军@腾讯。

欢迎关注“高效运维(微信ID:greatops)”公众号,以抢先赏阅干货满满的各种原创文章。


讲师简介  

钟储健

在浙江移动做了十多年的IT运维,从最早的网络运维到浙江移动第一个中间件管理员,一直活跃在运维一线,最近几年负责生产环境管控、高可用管理、连续性应急、技术架构管控等工作,目前主要专注在私有云的建设。

在浙江移动业务开发外包为主、系统复杂、可用性和稳定性要求高的情况下,运维压力可想而知,因而不断在寻找技术手段来解放运维。

我今天分享的题目是《中国移动浙江公司在MESOS方面的生产实践》,我分享一下我们为什么会去用MESOS来构建我们的企业内部私有云的平台。主要分三部分:

一、为什么使用MESOS

二、浙江移动云化的阶段

三、基于MESOS的DCOS实践

四、实践经验

一、为什么使用MESOS

1、云计算驱动企业IT架构演进

我以前一直是在做运维,从网络、中间件、主机,传统行业里面各种都涉及过。

在我们以前的系统里面,基本上我们的很多开发是外包的,我们的系统是竖井式、烟囱式的建设,每个系统都需要考虑它的高可用、部署、生产环境的管理等各种各样的问题。

我做运维之后,其实后面有一段时间转型主要是去解决系统的高可用问题。

我们的系统有一段时间上了新的系统之后,非常不稳定,出现各种各样的问题,我们就在思考:

怎么去把系统的可用性、健壮性、稳定性这些方面加强?

我们也成立了专门的生产环境管理小组,针对生产环境中存在的这些问题,我们做了很多的工作。

当时,这也都是针对各个系统,哪个系统有问题就针对哪个系统去做优化。我们的系统有一百多个,工作量很大,整个系统的部署架构、部署环境用的开发语言、开发框架都不一样。所以,给我们的运维带来很大的挑战。

所以,我们从2012年开始做云计算,那时候主要做的还是虚拟化,但是虚拟化做了之后并不能真正地解决我们的问题。

我们真正地提出企业内部云的架构其实是2014年、2015年,我们的目标是构建一个企业统一的私有云平台来打破应用竖井的状况。

我们的系统,上了虚拟化之后,发现跟我们原先的运维模式其实并没有多大的一个变化,也没带来太多的好处,除了系统资源的分配更快之外,其实对我们应用的架构、应用运维并没有太大好处。

所以,我们就在思考,我们光有底层的虚拟化IaaS层还不够,我们要建立PaaS层的服务、SaaS层的服务。

2、典型的云计算的平台

AWS,大家很熟悉,公有云的云计算的标杆。

Google的云计算,Google云计算有两块:公有云和私有云,我这里列的是私有云平台。

Google的私有云平台是基于Borg这一整套系统,Google在设计企业内部数据中心调度系统的时候,那个时候还没有虚拟化,所有的东西是它自己做的开发。

我们目前的很多技术都来源于这套技术,比如我们现在广泛在用的Hadoop等全部是来源于这个Borg。

二、浙江移动云化的阶段

1、云化历程

这个片子讲的是我们浙江移动在我们的云化上面的一个历程。

  • 第一个阶段:一开始我们主要是以小机为主,典型的IOE架构,各个系统也是竖井式的建设。


  • 第二个阶段:在2009年我们引入了x86服务器,把我们的硬件标准化,对我的设施构建相对的标准化,它的周期也相对缩减。以前小机从采购、安装、实施,整个周期是非常长的,x86之后,基本上以月的周期为单位。


  • 第三个阶段:在2013年左右,我们引入了VMware,后面我们有KVM的引入,KVM就是做虚拟化的资源池。做虚拟化还是把一台机器虚拟化成几个物理机,对我的应用部署来说、对我的应用架构来说,其实看到的跟物理机小机x86看到的没有什么区别。

虽然在虚机上可以做迁移,但是对于整体的应用架构其实没有带来根本性的好处,因为它是有一些限制的,特别是跨机房的迁移需要大的网络来支撑。

  • 第四个阶段:我们在应用上做了很多改造,因为虚拟化还是不能解决应用的扩展性的问题,我的应用架构如果不支持横向扩展的话,还是不能充分地利用硬件的资源。

我们第四个阶段做了很多应用的分布式的改造,当时这个改造基本上是以集群单位去扩展,我的能力不够的情况下可以新部署一组集群,马上可以扩上去,但是跟底层的技术平台其实关系不大。

做了虚拟化,又做了应用的分布式的改造,但是我们发现应用的部署周期,包括扩容的周期,业务量不足的情况下要去扩容,发现这个周期还是很长,要去分配虚拟机,创建虚拟机很快,但是上面要部署应用,要去建用户,要去安装应用的环境,要去发布这个包,还要把这个应用加入到这个集群里面,要做一些测试,这个周期还是比较长的。

所以,后来我们去寻找能够应用扩展的这些方案,我们希望能够像Google的数据中心一样有统一的调度,把整个数据中心作为一体,上面的资源能够做调度。

2、存在的问题

我们做了很多基于IaaS层的云化,有很多先天性的不足:

1、静态部署。部署还是和原先一样是静态的;

2、虚拟化只能大切小不能小聚大。虚拟化是把大切小,物理机把它虚拟化成很多小机器,但是它不能把多台机器聚合成一个大的计算机来运算;

3、不能维持应用环境的自动化封装。在之前做的很多工作,怎么去管理线上的环境,我们的环境有开发环境,有测试环境,有准发布环境,有生产环境,有四套环境。

一个应用上线要走四套环境,每个环境的部署都不一样,每个系统的环境也不一样,特别是生产环境的管理,一百多个系统,每个系统都是各自部署的架构;

4、应用的快速部署开通受到极大制约。最大的痛点是应用的扩容。

在碰到业务高峰的时候,比如说我们上一个新业务,第二天的压力突然上来了,我现网的资源不能满足要求,怎么办?

我要去扩容的话,一个是扩机器,部署这个环境,部署完之后,重点是要把它加到线上去,很多应用都要做上线的操作,因为很多配置在应用的配置环境里面。

对于这种压力突然上来的情况下,比如对于一个新业务能量的评估如果没有做到位的话,第二天很可能这个系统就过载了,提供不了服务了;

5、传统虚拟化只能实现虚机级弹性伸缩,效果极其有限。这种弹性收缩还得依赖于我的应用是不是支持,有很多云计算的厂商做了很多虚拟机的自动扩容动作,但是虚拟机是扩了,应用怎么办?

其实这是一个很难解决的问题,事先把应用的包在虚拟机上先部署好,打包好,但是你去扩容的话,还是会涉及到平时上线版本的更新,你扩了之后,一些配置的修改,包括加入到生产的集群里面,你到底可不可用?这些都是一的问题;跨机房的部署怎么办?我虚机的话,我如果要跨机房迁移的话,需要大型的网络;

6、资源利用率低。虚机的分配,虚机分配里面某个应用基本上不能跟其他的资源去共享,内存很难去做共享。特别是应用,如果说分布式的能力不足的情况下,虚机的扩展性就更加受限。

IaaS层的虚拟化不能解决我们的问题,我们就需要从PaaS层去考虑。我在给大家列了三代PaaS,这三代PaaS不是说哪一代比哪一代更新或者更好,只是说它出现的时间问题。

  • 第一代的PaaS很典型的就Google App Engine、SAE,为开发人员提供软件开发和运行的环境。

  • 第二代PaaS,Cloud Foundry、OpenShift也是到目前为止做得比较好的一个PaaS平台。允许企业内部基于Cloud Foundry构建自己的PaaS平台,提供平台的开发运行环境,将我的开发运行环境进行标准化。

  • 第三代PaaS就是我今天要讲的数据中心操作系统,其实这个就是以谷歌的Borg为代表,其实我们就是想做到谷歌数据中心调度的这种机制。

这块有MESOS、Yarn,Yarn主要是从Hadoop那边发展出来。第三代PaaS是要解决开发部署的问题,也要解决我的应用快速部署、提供应用弹性的能力。

3、数据中心操作系统

数据中心操作系统作为第三代PaaS的核心,我们去跟我们的Linux操作系统去比较,Linux是一个单机的操作系统,在数据中心操作系统的目的是说要把我的数据中心作为一个计算机来调度,那就是一个数据中心的操作系统。

其实就是说,操作系统化有这种资源管理、进程管理、任务调度、文件系统,对应到的数据中心操作系统,就有对应的解决方案。

这张图是以MESOS为例,资源管理用MESOS,进程管理用Docker来解决。

我们建设数据中心操作系统的一个目标或者说数据中心操作系统有哪些特征?我们的目标是:

1、数据中心级的弹性伸缩。要实现数据中心级的弹性,能够做到资源的动态分配,很灵活的去扩展,去做机房的调度。我的应用不需要去考虑底层的调度、高可用这些问题。

2、自动化调度、故障自愈。应用系统在出现问题的情况下,传统的解决方案有HA的解决方案,有集群的解决方案,来处理我们的硬件故障、应用系统的故障。

3、细粒度的资源分配。基于虚机的分配方式,资源的分配率还是以一台机器的力度去分配,部署应用之后,部署了虚机之后,真正去扩容、缩容的时候,扩容、缩容的代价是很大的,特别是缩容,现网的某一个应用用了十台机器,你再去缩一下,资源不够的时候,你还得把它再重新进行分配和扩容。

4、高资源的利用率。从我们这边来看,利用率是很低的,我可以举一个例子,比如说某些应用,它的访问量很小,可能是一个面向后台的管理系统,但是从应用的部署上来说要保证它的高可用,至少是两台机器,做负载均衡或者HA,对重要的系统可能还要去做容灾。每天访问量只有几次的这种应用,你也得至少给它两台虚拟机做部署,这个利用率肯定不会很高。

5、快速部署。应用在一个新的系统上线或者新的业务需要上线,在我的系统能力不足的情况下,我需要扩容,我怎么能够做到快速的部署我们希望这个数据中心操作系统来解决这个问题。

4、数据中心操作系统典型解决方案

Google内部用的是Borg,它开源出来的就是Kubernetes, MESOS也是起源于Borg,MESOS的作者最早在Borg实习的时候看到Borg这套系统非常好,他根据Borg写了一套开源的调度系统,就是MESOS。

类似MESOS这个资源调度的开源软件,其实还有一个比较像的是Yarn,为了统一大数据的调度,整个调度机制其实跟MESOS也很像。

Kubernetes由于是Google主导和开源出来的,现在非常火,我后面会讲到我们为什么会用MESOS。

Swarm是Docker公司容器的编排工具。

其他的还有传统的PaaS产品,像CF,CF是一整套的解决方案,从应用的开发到部署、运行。

5、应用案例分析

这张图是我个人做的一个比较,这是去年做的,现在不一定准确,大致列到这里给大家一个参考。

MESOS的使用规模很大,非常成熟,这是我们看中的一点。

Kubernetes我们去年在选型的时候,Kubernetes刚开源,它只能管理一百个节点左右,现在差不多是一千个节点,整体还是在快速的发展中。

我们认为,它部署到我们线上的环境还有距离,特别是在去年的时候。所以,我们当时选择了MESOS。

MESOS还有一个优势是它的两级调度框架,MESOS提供资源调度的一个平台,你可以在上面开发自己调度的框架,包括可以长期运行的任务、后台的任务、大数据的任务,都可以在上面做一个框架运行。

它作为企业内部的一个整体资源调度平台就比较合适,所以我们当时选择了MESOS这套方案。

三、中国移动浙江公司DCOS建设实践

1、DCOS建设历程

  • 1、2014年3月开始关注Docker容器化技术,2014年8月启动Docker应用的技术验证。

  • 2、2014年11月将核心系统CRM的一个完整集群迁移到容器运行,Docker正式投入生产。

2014年就是想解决生产环境部署的问题,把我们的最核心系统上到容器之后,觉得还是没有解决我们的问题。应该说,我们原先的系统比较重,整个开发、发布、部署这个流程本身就比较复杂。

引入这个容器之后,并没有带来好处,那个时候也没有一些成熟的容器管理工具,做容器的管理都需要自己开发。虽然我们当时研究了很长时间,非常想使用容器来解决我们生产上的不足、快速扩容的问题,但是当时没有实现。

  • 3、2015年8月,提出数据中心操作系统的设想,建设DCOS验证网,使用MESOS+Marathon+Docker方案。

在2015年的时候,我们跟一些互联网公司进行交流,当时提出访问谷歌内部的调度系统做数据中心操作系统的设想。

  • 4、2015年11月4日中国移动浙江公司DCOS验证网上线,11月11日支撑手机营业厅“双11”活动。我们最后选择了MESOS方案进行建设,“双11”的时候我们搞了活动,整个系统就是在MESOS上运行。

  • 5、2015年12月10日上线CRM应用。12月把我们核心的前台CRM应用,这是我们企业内部的CRM系统上线到我们的MESOS平台上。

2、基于MESOS的DCOS实现

1、资源调度

我们选了MESOS这个产品,MESOS是一个两级调度的框架,它有一个MESOS master作为主控的节点,在物理机或者虚拟机上部署Mesos  slave。

在master上面有任务调度框架,Mesos  slave把资源商报给MESOS  master,调入框架根据上报的资源情况会向master申请需要的资源。最后,执行器会把这个任务给调度起来。

在MESOS上可以运行很多框架,有长期运行的任务,还有定期调度的框架,还有Hadoop的调度在这上面运行。

2、任务调度

因为我们要做的是业务的应用,是长期运行的任务,我们用的是马拉松的调度框架。

马拉松是MESOS上面的一个调度框架,它做的是任务调度,具体到我们的系统里面,因为我们的任务是在容器里面运行的,它就做容器的调度,需要多少的资源,需要拉起多少容器,MESOS负责底层资源的分配。

3、应用封装

应用封装

用Docker封装,现在Docker也很火,具体的我就不展开讲了。

服务发现与注册

MESOS的这套解决方案,像CF这些服务与发现都是平台解决的,MESOS的服务与发现有很多解决方案,有马拉松和HAProxy等,我们当时选的是Haproxy解决方案。我们的任务调度起来之后,容器的实例会通过马拉松的事件注册,监听到容器变化的话,把容器的实例注册到HAProxy,注册到负载均衡的列表里面,就可以做任务的分发。

4、DCOS架构图

这是我们MESOS的一个架构图,做上角是MESOS的Cluster,包括马拉松等是部署在一起的。右面是用HAProxy做负载均衡,HAProxy本身的高可用其实也有几个解决方案,我们现网是用硬件的负载均衡去做。

另外一个就是前面加硬件负载均衡的话,是为了保证跟我们现网的环境一致,因为我们现网的应用都是接在硬件负载均衡上面,我们迁移的话,其实就在硬件的负载均衡做一个指向,指到我们MESOS平台上,指到我们HAProxy上。

右下角是MESOS的Stave的节点,上面跑的是具体的应用,这个容器的具体应用封装在容器里面,容器的变化实时注册到我的负载均衡上,会注册到HAProxy上面,这样就实现应用的注册。左下角是持续集成和构建这一块。

5、功能架构图

最下面一层是物理机或者虚拟机构成的计算节点,我们现在因为整个资源池是统一的做了虚拟化,所以我们目前是跑在虚拟机上,跟跑在物理机基本上没有什么区别。

资源调度和任务调度有MESOS和马拉松,服务和发现,最上面是封装。在之上我们做了一些开发,开发管理平台,比较核心的是弹性扩缩的一个模块,因为是统一的一个分布系统,我要对日志做统一的采集。

物理的部署

我们最早上的是单机房,现在是双机房的一个部署。MESOS这个节点是5个节点,像HAProxy现在是8个节点,计算资源80个节点。

整个平台和计算节点都是跨机房部署,所有的这些组件,包括HAProxy、MESOS,全部是用容器化进行部署。

容器化部署对迁移和扩展,我们当时同单机房扩展到双机房的时候,机房部署基本上把容器拉起来,然后改了一些配置,基本上就完成了。

这是具体的版本,我们去年上的时候还没有升级,后面会做一些升级的动作。

我们上的第一个系统是手机营业厅,当时我们支撑了“双11”的抢购活动,当时还是40个计算节点,所有的压力上来之后,40个节点,1000个容器,全部跑满,手机营业厅有一个接入层和业务处理层,对平台来说是两个应用,每个应用500个容器,基本上全部跑满。

7、控制台

最上面是整个的计算节点信息,整个DCOS的内存和使用情况,还有各个组件的使用情况。下面是应用的容器的数量,下面的几条线就是我们目前部署的几个应用,主要是我们的CM和手机营业厅,总共是四个应用模块的部署情况。

8、数据中心容器视图

统容器的视图

这个视图比较清楚地可以看到容器的部署情况,每个不同的颜色就是不同应用的一个容器。如果这个容器有变动的话,它大小会有变化,做这张图是为了直接地对我们的系统有一个概况。

四、实践经验

1、自动弹性扩缩容

我们整个系统基于开源软件,我们除了做了管理平台之外,我们做了一个比较大的工作是自动弹性扩缩容。对于容器的数量,应用能跑多少容器是手工调整的,我们做了一个自动弹性扩缩容的模块。

可以看到,中间的两条线,容器数量的变化其实就是它在做这种自动弹性扩缩容,其实最核心的一个监控指标其实是指业务并发的数量。

但是,光监控并发数可能不够,因为数据库故障的时候或者说后台系统其他的服务故障时候,可能压力也上来了。那么,就需要根据根据指标做一个综合的判断。

2、Marathon  Etcd联动实现服务发现注册

Etcd只是个独立的服务注册发现组件,只能通过在宿主机上部署Etcd发现组件,通过其发现宿主机的容器变化来发现,属于被动的发现,往往会出现发现延迟时间较长的问题,我们通过修改Etcd组件的发现接口,实现与Marathon的Event事件接口进行对接,达到Marathon的任何变动都会及时同步给Etcd组件,提高了系统的发现速度,并且避免在每个宿主机上部署Etcd 发现组件。

这个方案当时是参考了一篇文章中讲的一个解决方案,我们就对它做了一个改造,我不是直接去监控这个容器,我是去监控马拉松事件,通过马拉松事件直接进行通知,这样更加迅速,更加高效。

3、数据中心切换的功能

这是什么意思呢?

我在两个数据中心之间可以把应用进行整体的一个切换,比如说我原先的应用,我调度起来的时候,它的应用是随机分布在两个机房的,我需要对某个机房进行版本的升级,我可以把这个应用从这个机房整体迁移到另外一个机房。

最后讲一下,你上MESOS的话,它是有条件的,它带来应用的快速扩展能力,它其实是有一些要求的。

比如说,你有这个状态的话,你去缩容的时候,如果说这个状态数据是用户的汇报的话,就可能把这个用户剔出了,如果是带着数据的话,如果要缓存本地数据或者数据库,MySQL如果要跑在上面的话,它要连存储,你做这个扩展的时候,需要把这个存储挂到每台的DCOS的虚拟机或者物理机上面。

在接入层的改造很简单,就是把原先的用户会话信息保存到缓存,所有的分发,在我的接入层的实例上不再保存用户的会话状态,他所有的请求我是可以分发到任意一个实例,这样扩容或者缩容对整个用户的会话就没有任何影响。

接入层改造

在内部的服务,内部还有很多服务的调用,A要调B,B要调C,如果说内部的服务用HTP的协议,还是可以采用前面的负载均衡的方案。

内部调用改造

另外一个,如果说用服务化的方案,这块的扩缩容的方案可以交给服务化框架去解决。

我们后面会把现有的CRM做自动化的改造,我们现在是一整个单体的应用会拆成订单中心、用户中心、账户中心,这块也是用的服务化的框架,它本身服务的注册就用服务化的框架去解决。

我平常去给它扩容、缩容的话,跟它服务的注册这块就没有直接的关系。

现在这个图是我们当时做的对现有业务的一个改造方案,当时没有用这个服务框架,当时是把服务的状态信息通过马拉松去注册,这是一个基于中间的方案。

总结一下MESOS带来的好处

1、资源的利用率。所有的应用其实是共享了整个计算资源池子,如果有一百台物理机,我的应用是在这个池子里面进行共享。

2、跨数据中心。整个MESOS框架的调配机制,它不需要二次网络,它是基于三次网络,所以不需要对网络进行改良,只要在三层的带宽上满能够互动就可以了。

3、弹性的扩缩容。对于我们带来最大的好处就是这一块,我们原先最大的问题就是资源的扩容周期很长,现在基本上扩容就是一应用的启动时间。

像我手机的应用基本上是在1分钟之内,像传统的CRM应用,整个应用比较庞大,整个启动周期会慢一些,这个扩容时间完全取决于这个应用本身启动的时间。

4、高可用和容灾。业务的高可用和容灾,本身由系统来解决。整个MESOS的解决方案,我们当时为什么选择这个,还有一个很重要的原因,它对于应用的耦合性最低,如果不去做扩容、缩容的操作,把整个平台全部停掉对于整个应用是没有任何影响的,我们做过这种测试。

因为它容器起来之后,业务就在容器里运行,真正相关的就是一个前端的HAProxy业务的分发上面,如果说是内部的服务调用的话,如果基于服务化框架的话,如果不使用HAProxy,其实跟整个平台都没有直接的调用关系。所以,它跟平台的耦合性是最低的。

时间关系,我的介绍就到这里,这个二维码是我们的公众号,大家有兴趣可以添加一下,所有相关的资源我们都会在上面进行分享。我今天的介绍就到这里,谢谢大家。

提问

提问1:我想大概问一下,我们这个系统投入下来,投入了多少?你怎么跟领导去申请?我也觉得挺好,但是你怎么把大家都说服?

钟储健:当时我们做这个项目的时候,因为我原先带着一个尊敬的运维团队,完全是运维团队在那里做起来,当时没有说要去申请什么项目、申请什么资源,当时就是一个研究和试验的性质来做的。

当时我们搭完之后,发现整个的效果超出预期,原先我们是打算做一两个小系统的试验,但是验证完之后发现整体的状况是超出我们的预期。

所以,我们直接把手机营业厅这个系统牵到上面,整个效果出来之后,自然后面的投入就追加上来了。

我是华丽的分割线

参加GOPS2016上海站,老司机带你飞~

2    70  多位运维顶级大咖,已经到位

平均一屉灌汤包的钱,就能听一场演讲

8折优惠仅剩5天,欲购从速!



↓↓↓ 点击"阅读原文" 【直接报名】

 
高效运维 更多文章 都是套路:高并发系统的降级特技 没有无条件的心有灵犀,能表达清楚自己就挺牛逼 为PostgreSQL讨说法丨为什么说Uber不应该切换成MySQL? 【学在GOPS】七千万在线用户的异地调度,怎么做到平滑无感知的? 跨数据中心Docker镜像复制的开源实现 | Harbor Registry
猜您喜欢 我为什么坚持写博客? Android M doze特性预研 阿里缩招(从3000人大幅砍到400人)降薪,互联网寒冬要来了吗? PingCAP 第14期 NewSQL Meetup Android开发技术周报 Issue#9