中国移动浙江公司数据中心操作系统（DCOS）实践

背景

中国移动浙江公司数据中心自2009年开始从小型机为主的架构开始了X86化、IaaS资源池化、PaaS资源池化的发展历程，数据中心在向云计算转型过程中软硬件管理的能力和效率上面临着诸多挑战：

1) 应用的快速部署开通受到极大制约：大部分应用系统有开发、测试、准发布和生产四个部署环境，各部署环境不一致，代码从开发到上线环节多、部署复杂、容易出错，无法满足业务快速上线的要求 。

2) 系统弹性扩展能力不足：应用系统部署以虚拟机为单位构建，系统的扩容需要经历虚拟机分配、软件安装、应用部署、测试、割接入网等环节，在业务量突增时无法进行快速的扩展；系统的缩容不能随意进行，导致资源存在一定的预留和浪费。

3) 现有资源利用率较低：资源池 CPU平均利用率仅为10-20%左右，显著低于先进数据中心50-70%的利用率。

4) 应用系统仍旧“烟囱式”的建设：以虚拟机为基础的资源池化在应用系统架构上并没有改变竖井化的建设模式，应用与平台没有解耦，高可用、监控运维等无法标准化。

针对在云化和系统运维中碰到的上述问题，我们在2014年3月就开始关注Docker容器化技术并在核心系统中进行了试点。2015年业界开始流行数据中心操作系统（DCOS：Data Center Operating System）的概念，正好与我们私有云架构中规划的弹性计算相契合，因而提出以开源技术为核心建设DCOS验证网，对新一代云计算技术体系架构下的数据中心解决方案、产品选择、集成交付和运维保障进行全面验证：

1) 为整个数据中心提供分布式调度与协调功能，统一协调各类资源，实现数据中心级的弹性伸缩能力。

2) 提供一个高效率、可靠、安全的管理数据中心的平台，确保各类资源随着应用的需求动态调度，同时简化应用程序的开发、部署难度。

图：中国移动浙江公司私有云架构

技术选型

数据中心操作系统（DCOS）是为整个数据中心提供分布式调度与协调功能，实现数据中心级弹性伸缩能力的软件堆栈，它将所有数据中心的资源当做一台计算机来调度。

大规模应用的数据中心操作系统有：Google Borg/Omega系统和Twitter、Apple、Netflix等公司基于Mesos构建的系统。

可以用于数据中心操作系统构建的开源解决方案有：

1) Mesos：Mesos最早由美国加州大学伯克利分校AMPLab实验室开发，后在Twitter、Apple、Netflix等互联网企业广泛使用，成熟度高。其中，Mesosphere公司DCOS产品，就是以Mesos为核心，支持多领域的分布式集群调度框架，包括Docker容器集群调度框架Marathon、分布式 Cron（周期性执行任务）集群调度框架Chronos和大数据的主流平台Hadoop和Spark的集群调度框架等，实现系统的资源弹性调度。

2) Apache Hadoop YARN：Apache Hadoop YARN一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度。

3) Kubernetes：Kubernetes是Google多年大规模容器管理技术的开源版本，面世以来就受到各大巨头及初创公司的青睐，社区活跃。

4) Docker Machine + Compose + Swarm：Docker公司的容器编排管理工具。

5) 此外，CloudFoundry/OpenShift等PaaS产品也可以作为DCOS的解决方案。

（注：按照公开文档和使用经验做简单比较，未做详细验证）

根据对适合构建DCOS的各种技术架构的评估，我们选择以Mesos为基础的方案。其优点是成熟度高、使用两级调度框架、适合多种应用场景、支持混合部署、应用与平台耦合度低。

建设历程

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

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

2015年8月提出数据中心操作系统的设想，建设DCOS验证网。

2015年11月4日中国移动浙江公司DCOS验证网上线，成功支撑手机营业厅“双11”活动，12月10日CRM系统试点迁移到DCOS。

DCOS技术方案

1. 技术架构

中国移动浙江公司DCOS方案采用了以容器为基础封装各类应用和运行环境，以Mesos、Marathon为核心实现容器资源的分布式调度与协调，以Haproxy、Confd、Etcd实现服务注册和业务的引流。架构如下：

(点击放大图像)

a) 应用封装

应用封装采用Docker做为应用容器引擎，Docker是轻量级虚拟化技术，它在标准的LXC之上融合AUFS分层镜像管理机制，并以应用为单元进行“集装封箱”，实现的相关应用封装能力如下：

1) Docker容器技术可以部署应用到可移植的的容器中，这些容器独立于硬件、语言、框架、打包系统，帮助实现持续集成与部署。一个标准的Docker容器包含一个软件组件及其所有的依赖 ，包括二进制文件、库、配置文件、脚本等。

2) Docker容器可以封装任何有效负载，可以在任何服务器之间进行一致性运行。开发者构建的应用只需一次构建即可多平台运行。

b) 资源调度

使用Mesos作为资源调度框架，其核心工作原理如下：

1) Mesos Master负责将资源分配给各个框架，而各个框架的Scheduler进一步将资源分配给其内部的各个应用程序。

2) Mesos和不同类型的Framework通信，每种Framework通过各自的Scheculer发起task给Mesos slave，对Mesos集群进行调度管理。

3) Framework的Executor执行其Scheculer发起的task。

c) 任务调度

由于Mesos仅负责分布式集群资源分配，不负责任务调度。因此，需引入Marathon来基于Mesos来做任务调度，Marathon用来调度长期运行的服务。Mesos集群可以混合运行不同类型的任务 ，其任务调度示意图如下：

1) Marathon基于Mesos的任务调度为动态调度，即每个任务在执行之前是对具体服务器和绑定端口均为未知。

2) Mesos集群上混合运行着包括Marathon在内各种调度框架的任务，当某台服务器宕机以后，Marathon可把任务迁移到其他服务器上，实现容错。

d) 服务注册及引流

通过Haproxy、Confd、Etcd配合实现数据中心应用的动态服务注册与引流，其中Etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。HAProxy提供高可用性、负载均衡的解决方案。其主要的架构流程如下：

1) Marathon通过Mesos启动Docker容器时，Marathon将容器启动信息通知Etcd服务。

2) Etcd服务将已经启动容器信息注册到Etcd键值库中。

3) Confd监测到Etcd中相关的服务变化，Confd就会根据变化的情况更新Haproxy的cfg配置文件并执行重新加载命令，使相关变化生效，同样当容器停止时也会触发Haproxy更新cfg配置文件并重新加载，达到动态服务注册。

4) 业务请求通过HAProxy分发到Docker容器中的应用。

e) 自动弹性扩缩容

Marathon的扩缩容默认只能根据用户需要进行手动调整，我们结合多年的系统运维经验，实现基于并发数、响应时间、CPU和内存使用率等容量指标进行自动弹性扩缩容调度的模块。结合前面提到的HAProxy、Confd、Etcd动态服务注册和引流能力，实现应用的自动弹性扩缩容能力。

2. 功能框架

以开源技术Mesos 、Marathon 、Docker、HAProxy为引擎，在其上开发了DCOS控制台、资源管理模块、鉴权模块、统一日志中心、弹性扩缩容调度模块、监控管理模块、持续集成平台。DCOS的功能框架如下：

(点击放大图像)

1) DCOS Dashboard

2) 资源管理模块：服务目录管理、规则管理、CMDB信息；

3) 监控管理模块：监控数据采集、日志管理、告警管理和事件管理；

4) 弹性扩缩容调度模块：基于CPU使用率、内存使用率、服务并发数、响应时间等容量数据，通过定制的调度算法实现服务的自动弹性扩缩容；

5) 统一日志中心：采用Elasticsearch、Logstash、Graylog构建，实现对容器日志的统一存储及检索；

6) 鉴权模块：用户管理、用户组管理、权限策略管理和统一认证接口；

7) 持续集成平台：镜像构建、集成测试、流程管理和上线管理。

DCOS应用

在对DCOS平台验证网充分测试验证后，我们选取手机营业厅系统作为业务试点，迁移至DCOS平台。

手机营业厅是面向中国移动客户提供快速便捷的查询、办理和交费等自助服务的客户端软件及系统，中国移动浙江公司手机营业厅注册用户2500万，日活跃用户数300万。

DCOS平台采用93个主机节点，其中平台部分由5个节点构成Mesos Master Cluster，8个节点构成HAproxy Cluster，计算节点由80个Mesos Slave节点组成，平台和计算节点均跨机房部署，该平台可在1分钟内轻松扩展到1000个以上Docker容器。

下图为DCOS控制台，手机营业厅WEB和APP两个应用模块在DCOS资源池中动态调度，容器数量的变化显示了两个应用模块的弹性扩缩容情况：

效果总结

1) 高性能高稳定性

双十一期间，运行在DCOS架构的浙江移动手机营业厅系统承受的并发数最高峰值接近6万次/秒，成为浙江移动首个在单日实现10亿级PV的业务系统。

2) 高资源利用率

DCOS相较于虚拟机有着基于CPU、内存的更细粒度的资源调度，多个计算框架或应用程序可共享资源和数据，提高了资源利用率。

3) 高效的跨数据中心的资源调度

DCOS平台展现了其在线性动态扩展、异地资源调度等方面的优异性能，1分钟内快速扩展到1000+的容器（如果应用更轻量启动速度还可以更快），平台和计算节点完全跨机房分布式调度。

4) 自动弹性扩缩容

彻底解决应用的扩缩容问题，容量管理从“给多少用多少”向“用多少给多少”转变，被动变主动。应用的扩缩容时间从传统集成方式的2-3天缩短到秒级分钟级，可以根据业务负载自动弹性扩缩容。

5) 敏捷开发、快速部署

容器和DCOS技术的结合通过将应用和它的依赖进行封装，隐藏了数据中心硬件和软件运行环境的复杂性，让开发、测试、生产的运行环境保持一致，降低应用的开发、发布难度。传统的部署模式“安装->配置->运行”转变为“复制->运行”，实现一键部署。

6) 高可用性、容灾

DCOS平台所有组件采用分布式架构，应用跨机房分布式调度。自动为宕机服务器上运行的节点重新分配资源并调度，保障业务不掉线，做到故障自愈。

问题和经验总结

1. 经验

1) Marathon自动弹性扩缩容调度

Marathon的扩缩容默认只能根据用户需要进行手动调整，我们结合多年的系统运维经验，实现基于并发数、响应时间、CPU和内存使用率等容量指标进行自动弹性扩缩容调度的算法。

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

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

3) DCOS平台组件容器化改造

为提高DCOS平台的可维护性，我们将DCOS平台的相关组件全部进行Docker化，相关组件运行环境和配置信息都打包到Docker镜像中，实现快速部署、迁移和升级。

2. 应用迁移经验

应用要在DCOS平台上动态的扩展和伸缩，对应用的要求是无状态化。

以常见的三层架构为例，WEB层负责展现，APP层负责处理业务逻辑和数据库进行交互，WEB层使用负载均衡进行请求分发，WEB到APP层有多种调用方式，如下图所示：

1) WEB层应用无状态改造

去HTTP Session：不再采用传统的HTTP Session保存会话的方式；

将客户端与WEB端的交互改成http+json短连接方式；

使用缓存服务器来保存用户的会话信息。

如下所示：

通过以上的应用改造使应用的状态数据与应用分离，WEB实例的启动和停止不会导致用户会话数据的丢失。

2) APP层应用改造

APP层要支持动态的伸缩，除了APP层实现无状态化外，取决于WEB到APP的RPC调用方式：

HTTP协议：同WEB层一样使用负载均衡方案HAProxy+Confd+Etcd；

服务化框架：使用服务化框架服务的发现和注册功能，注意需要将容器外的IP和端口上报给配置中心；

未实现服务发现的RPC调用：对于没有服务发现和注册功能的传统应用则需进行改造。我们以移动的CRM系统为例，CRM系统使用EJB技术实现，APP层没有服务注册的能力，改造后的架构图如下所示：

Zookeeper保存APP实例的实时分布数据，Marathon负责监控APP实例的运行状态，并在状态发生变化时通知给Zookeeper进行修改APP实例分布数据，WEB层根据分组策略获取一组的APP实例分布信息，根据该信息轮训调用组内的APP实例。

分组

为保证APP负载的均衡我们采用分组策略，我们将所有Zookeeper内的APP实例根据Hash算法进行分组，每个组内保持着一定数量的APP实例，每个WEB请求按照路由策略均衡分发到组内APP实例上。

扩缩容调度

垂直调度：因为每次弹性扩缩都会对WEB访问APP的路由表进行更新，当频繁更新时有可能会造成服务访问的短时异常，为避免该问题我们采用垂直调度机制，每个APP组根据弹性调度算法进行垂直扩缩操作，不影响其他组的运行。

水平调度： 对APP层整体服务能力进行评估，当能力变化值大于一个组的服务能力时，需要进行水平扩缩操作，以组为单位进行水平扩缩。

3. 问题

1) Marathon Exit容器清理

弹性扩缩容会导致宿主机上产生大量的Exit状态的Docker容器，清除时较消耗资源，影响系统稳定性。默认Mesos只有基于时长的清除策略，比如几小时，几天后清除，没有基于指定时间的清除策略，比如在系统闲时清除，也无法针对每个服务定制清除策略。

解决方案：修改Marathon的源码程序，添加Docker容器垃圾清理接口，可以对不同服务按指定策略将Exit状态的Docker容器进行清理。

2) Docker DeviceMapper dm-thin问题

在CentOS6.5上，我们发现Docker在使用DeviceMapper时会不定时出现Linux Kernel Crash的情况。

解决方案：通过修改dm-thin.c内核源码修复。

后续计划

通过将公司两大核心系统迁移到DCOS，对于使用Mesos和Docker来构建企业私有云的弹性计算平台得到了充分的验证，后续将继续完善弹性调度功能、复杂应用编排、持续集成等能力。同时对Kubernetes、Swarm与Mesos的集成方案进行跟踪、测试和比较，构建高效稳定的DCOS平台能力。