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

“云无界、端无边” OGeek 技术峰会 9月17日南京不见不散！了解详情 



 写点什么

背景

中国移动浙江公司数据中心自 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 的解决方案。

相关技术在调度级别、生态活跃、适用场景等方面的比较如下表所示：

产品名称

Mesos

Yarn

Kubernetes

Docker Machine+

Compose

+Swarm

CF/OpenShift

调度级别

二级调度

（Dominant Resource Fairness）

二级调度

（FIFO，Capacity Scheduler，Fair Scheduler）

二级调度（基于 Predicates 和 Priorities 两阶段算法）

一级调度（提供 Strategy 和 Filter 两种调度策略）

CF 一级调度（基于 Highest-scoring 调度策略）/OpenShift 使用 Kubernetes

生态活跃

活跃

非常活跃

活跃

一般

适用场景

通用性高，混合场景

大数据生态场景

目前较单一

较单一

成熟度

高

中

低

中

应用与平台耦合度

低

中

低

高

应用案例分析

Twitter、Apple、Airbnb、Yelp、Netflix、ebay、Verizon

Hadoop 生态圈应用很多

目前快速发展中，生产环境应用较少

很少

较少，应用与平台的耦合度较高

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

根据对适合构建 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 平台能力。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。