本文讲的是DC/OS关键技术与应用场景【编者的话】文章首先对数据中心操作系统内的主要技术，包括Mesos、Yarn、Kubernetes和容器进行了阐述。根据国内外电信运营商的现状和面临的问题，提出了一种解决方案，并对技术实现及选型建议进行了讨论。最后对电信运营商应用DC/OS关键技术的案例进行了简要介绍。

引言

随着越来越多的平台、架构、系统、组件和工具等通过开源社区、小微型初创项目而衍生，不再由IT或互联网巨头独自垄断，这为IT领域各项技术的快速、活跃发展提供了良好的温床，开源技术的迅速发展、活跃的社区力量，使得一些理念如DC/OS（数据中心操作系统）以及技术如Mesos、Kubernetes和容器等应运而生，并广泛地得到了实验和迭代改进。

DC/OS关键技术

DC/OS问世之前，如谷歌（Google）等互联网企业就内部资源调度和分配、负载，已逐步展开了探索，形成了一些如Borg等的生产化项目。而在2014年，由Mesosphere实现了第一个可进行统一调度所有数据中心及云资源的软件堆栈，并称为DC/OS。目前已投入实际生产使用的DC/OS包括Google的Borg/Omega系统和推特（Twitter）、苹果（Apple）、网飞（Netflix）等公司基于Mesos构建的系统。而在2016年4月，Mesosphere将自己的DC/OS代码进行了开源，其中包含超过30项组件技术，最为典型的有Apache Mesos与Marathon。下文将对可用于DC/OS构建的开源技术包括Mesos、Yarn、Kubernetes和Docker进行简要阐述。

Mesos

Mesos是开源资源统一管理和调度平台，其实现逻辑如图1所示，由美国加州大学伯克利分校AMPLab开发，后应用于Twitter、Apple、Netflix等企业。其亮点在于两层调度的架构可以做到“大集群”、减小“中心节点”的压力以及在同一个集群中可接入多种应用、框架，提高分布式集群的利用率。

由于Mesos上的元数据可通过各个计算节点重新注册而进行重构，因此可通过Zookeeper解决单点故障问题。轻量级的Mesos架构包括以下4个组件。

• Mesos管理节点
  系统的核心，负责管理接入Mesos的各个框架和计算节点，并将计算节点上的资源按某种策略（默认使用DRF（dominant resource fairness，主导资源公平）算法）分配给不同的框架。
• Mesos计算节点
  接收并执行来自管理节点的命令、管理节点上的任务并为各个任务分配资源。
• 框架
  计算框架，以注册的方式接入Mesos以便其进行统一管理和资源分配。
• 执行器
  主要用于启动内部任务。

Yarn

Yarn是新的Hadoop MapReduce框架，实现思路如图2所示。其主要为了解决Hadoop1.0扩展性较差、不支持多计算框架的问题，本质是一个资源管理架构。Yarn减小了JobTracker的资源消耗，并且让监测每一个工作子任务状态的程序更安全、更分布式化；对于资源的表示以内存为单位，较旧版本更合理。其亮点在于可以更快地进行MapReduce计算，实现对多架构的支持以及架构升级的简便性。

较1代MapReduce的设计思路，Yarn将JobTracker两个主要的功能，即资源管理和任务调度/监控，分解为独立组件资源管理器和应用管理节点。资源管理器全局管理所有应用程序计算资源的分配，每一个应用的应用管理节点负责相应的调度和协调。

Kubernetes

Kubernetes是Google多年大规模容器管理技术的开源版本，其实现思路如图3所示。其亮点在于具有容器编排能力、相对轻量级及易于管理运行Docker的容器。Kubernetes使用Docker对程序进行包装、实例化、运行，并以集群的方式运行、管理跨机器的容器，同时解决了Docker跨机器容器之间的通信问题。

Kubernetes框架包含以下组件。

• Kubernetes管理节点：管理整个系统。
• Kubernetes API服务器：系统入口，封装了核心对象的操作。
• Kubernetes调度器：负责集群资源调度，为新建的Pod分配机器。
• Kubernete节点：运行节点，用于运行管理业务的容器。
• Kuberlet：负责管控容器，从服务器接收命令。
• Kubernetes代理：负责为Pod创建代理服务。
• Docker：Kubernetes节点是容器运行节点，需要运行Docker服务。

首先，Kubecfg将请求如创建Pod等，发送给Kubernetes应用客户端，并由其将该请求发送给API服务器。API服务器根据请求类型（如创建Pod时存储类型是pods）并依此选择何种REST存储API对请求作出处理。REST存储API对请求做相应的处理，并将处理结果存入高可用键值存储系统（ETCD）中，在API服务器响应Kubecfg的请求后，调度器会根据Kubernetes应用客户端获取集群中运行的Pod及从属节点的信息。依据从Kubernetes应用客户端获取的信息，调度器将未分发的Pod分发到可用的从属节点上。

Docker

Docker 是一个开源的应用容器引擎，为开发者提供一个可将应用及依赖包打包至一个可移植的容器环境中，并发布到任意流行的 Linux 机器上。容器采用沙箱机制，容器间不存在接口。其亮点在于快速便捷的单次构建+导出运行模式及愈加丰富的生态系统。

Docker采用C/S模式，使用远程API来管理和创建Docker容器。Docker容器通过 Docker镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。Docker采用 C/S架构 Docker Daemon作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。客户端和服务端既可以运行在一个机器上，也可通过Socket或者RESTful API来进行通信。Docker Daemon一般在宿主主机后台运行，等待接收来自客户端的消息。Docker客户端则为用户提供一系列可执行命令，用户用这些命令实现跟Docker Daemon交互。

电信运营商DC/OS实现思路

现状与问题

云计算、大数据相关技术的普及推进了企业云化的建设和发展。虽然大部分国内外电信运营商已实现了IaaS资源池化和部分PaaS及应用资源池化，能够满足生产供给和部署。但大部分运营商的数据中心采用分隔式集群实现思路，包括以开源Yarn或定制版大数据资源调度，承载数据类作业的集群以及数据库、缓存集群等；缺乏迫切资源的跨域调度能力；同时目前的运营系统还存在的资源运行不均衡、时段运行不均衡等问题，具体包括：

• 应用难以实现灵活、快速地部署，应用系统的开发过程从开发到生产有不同的部署环境，对应的实现代码也面临着不同环境的开发和部署；
• 系统弹性伸缩能力不足，扩缩容需经过较多环节，无法实现快速、自动的伸缩，同时会造成资源的浪费；
• 现有资源利用率在15%左右，无法充分实现资源的有效利用；
• 应用系统仍旧面临“烟囱式”的建设等现实问题，应用与平台紧耦合，高可用、有效监控、智能运维难以标准化。

鉴于此，电信运营商需设计、研发一种架构，以解决资源调度等现实问题并提供微服务化的实现环境。

功能结构

一种可满足电信运营商需求的DC/OS的功能实现如图4所示，分为4部分内容，分别是业务调度层、应用服务层、资源管理层以及自动化运营工具。

业务调度层的主要功能包括集群管理、服务接入、服务命名、服务发现、服务目录管理、负载均衡、服务访问控制等。

应用服务层主要负责容器集群的管理和大数据集群的管理。

资源管理层的主要功能包括底层计算资源的管理以及对其上注册的任务的管理。

自动化运营工具包括监控和多租户管理两大功能，其中监控又细分为对资源、服务、容器、集群的监控。

技术实现框架

为实现如图4所示的功能架构，需要引入资源调度技术、容器技术等，在技术路线选择上，则以社区领域的开源技术为基础形成自有版本，并兼顾开源社区本身的发展。一种较为适合运营商的DC/OS技术架构如图5所示。

Mesos版本选型

开源DC/OS和商用DC/OS对比见表1。

选型建议：可使用开源技术和自行研发结合方式实现，其中对资源的统一管理和调度采用开源的Mesos或者开源的DC/OS 来支撑，从对比来看开源DC/OS 与ApahceMesos核心模块功能一致，开源 DC/OS增加了如框架的自动安装部署和门户等附加功能。

Kubernetes和Marathon框架整合

Kubernetes和Marathon对比见表2。

选型建议：Kubernetes和Marathon各有优点，且各自都有固定的生态圈，因此目前阶段无法选定对容器的编排和调度管理采用拿一个开源工具，因此在DC/OS平台需要长期跟踪和集成两个容器编排工具。

对大数据服务框架的集成和封装

通过Myriad实现大数据服务框架的集成。

电信运营商DC/OS案例分析

与DC/OS相关的Mesos、容器等技术在电信运营商领域获得了广泛的探索、研发与实践。

浙江移动DC/OS实现“双11”1折充值秒杀

中国移动以开源技术Mesos、Marathon、Docker、HA代理为引擎，在其上完成了自有数据中心操作系统DC/OS平台的设计、测试验证，平台采用93个主机节点，其中平台部分由5个节点构成Mesos管理节点集群，8个节点构成HA代理集群，计算节点由80个Mesos计算节点组成。为验证其对业务的承载能力，中国移动选取浙江移动手机营业厅作为试点，将其手机营业厅系统迁移到DC/OS平台上，用于重点解决秒杀场景。并在2015年11月11日，推出手机营业厅充值1折秒杀的活动，借以实验和测试平台对其业务的支撑。在当晚8点，DC/OS平台充分展现了其在应对业务高峰时的能力优势，顺利通过“双11”考验。

数据显示，“双11”活动期间，浙江移动手机营业厅系统承受的并发数峰值接近6万次/s，后台服务调用成功率均在99.95%以上，成为浙江移动首个在单日实现10亿级PV的业务系统，其平台CPU利用率从资源池的10%提高到40%~50%。

随后，中国移动陆续将CRM核心业务逐步迁移，在2016年4月底DC/OS已成功承载其16套应用系统，涵盖CRM营业厅、手机营业厅等多套核心系统。

Verizon的DC/OS支撑自有系统和应用

Verizon公司作为国际电信运营商巨头之一，不仅重视电信运营商基础业务如语音及数据服务，同时也提供面向用户的应用托管业务以及Verizon内部服务如云服务、用户托管应用等。而这些年OTT的兴起，令传统通信业务逐渐减少，也令Verizon公司对其他非电信业务更加重视。但其传统的电信业数据中心架构仍是集群化的、计算资源孤岛式的，无法实现应用的自动化部署、扩缩容，因此需要一种较有限的集群管理工具，并可以实现隔离、灰度升级、打包、资源弹性分配等能力。

鉴于此，在2013 年，Verizon为改变计算和存储资源的低利用率和随之而来的运营低效率问题，开始选择Docker容器技术以及用来管理Docker容器及服务器集群的Mesos技术重构其基础设施架构，以支撑Verizon网络上数以万计的工作任务。2014年底，Verizon建立了一种以Linux为核心，由遍布数据中心的普通服务器构成的集群。在应用了新技术后，在硬件资源和应用部署两方面均有有效的提升。具体如图6所示。

硬件资源

• 资源利用率提升：其数据中心的资源利用率由最初的10%~20%提高到50%以上。
• 提升集群使用有效性：参考集群的历史数据，哪些应用上云或者从云上下线了，从而将硬件采购做得更合理。
• 减少硬件资源规划计划：闲置的集群资源可提供给新业务，因此无需为新业务规划预期规模所使用的资源；进一步可根据所有应用的运营情况来增加硬件投入，按季度扩展集群规模。这种方法还可以使计划更具体和有效。

时间成本

• 应用快速部署：支持在72 s内部署50 000个Docker容器，应用集群部署与过往相比提高了一个数量级。
• 开发成本降低：无需关注机柜和硬件环境，应用实现短平快的开发。

Verizon计划在其Mesos集群上运行一些服务，第一批将被迁移到Mesos集群上的服务包括无线网络支撑系统和一些移动应用的后台以及FiOS网络支撑系统（光纤到户）。Verizon还计划将其 Hadoop和Spark分析任务从它们的专属集群上迁移到Mesos集群。其最终目标是希望该集群可达到如互联网巨头般的由廉价、单一的硬件设备组成的数据中心。

结束语

未来电信行业将会是一个IT、CT融合，电信运营商互联网化的趋势，IT所占比重会越来越大，电信行业的盈利模式也会从传统的提供通道到提供IT资源、提供服务的方向转变。近几年随着大数据、云计算、容器化、微服务、平台战略等新技术和新概念的层出不穷和快速发展，在业务支撑、架构能力、平台扩展性等方面对旧有的烟囱式建设的业务支撑系统提出了巨大的挑战。因此对现有业务和设备进行容器化改造，对数据中心乃至全网IT系统进行DC/OS改造，则成了一个必然的选择。

目前，DC/OS相关技术已在部分运营商有成功使用的案例，证明相关技术在运营商的业务和网络中具有不可忽视的作用，同时运营商也需从自身定位和转型战略的视角来看待DC/OS的发展，并选择自身合适的业务分步进行改造和迁移。

参考文献：

[1] HINDMAN B, KONWINSKI A, ZAHARIA M, et al. Mesos: aplatform for fine-grained resource sharing in the data center[C]//The 8th USENIX Conference on Networked Systems Design and Implementation, March 30-April 1, 2011, Boston, MA, USA. New York: ACM Press, 2011: 429-483.
[2] VAVILAPALLI V K, MURTHY A C, DOUGLAS C, et al. Apache Hadoop YARN: yet another resource negotiator[C]//Symposium on Cloud Computing, May 27-June 1, 2013, Valencia, Spain. New York: ACM Press, 2013: 1-16.
[3] BERNSTEIN D. Containers and cloud: from LXC to Docker to Kubernetes[J]. IEEE Cloud Computing, 2014, 1(3): 81-84.
[4] MERKEL D. Docker: lightweight Linux containers for consistent development and deployment[J]. Linux Journal, 2014(239).
[5] 程梦瑶. 王璞:定义下一代DCOS[J]. 软件和集成电路, 2016(4): 84-86.
CHENG M Y. WANG P: define the next-generation DCOS[J]. Software and Integrated Circuit, 2016(4): 84-86.
[6] 张基恒, 魏进武. 电信运营商私有云适应性分析[J]. 移动通信, 2015(13): 5-11.
ZHANG J H, WEI J W. Analysis on private cloud adaptability for telecom operators[J]. Mobile Communications, 2015(13): 5-11.

作者：张基恒、李大中、张呈宇、魏进武

原文链接：DC/OS关键技术与应用场景

原文发布时间为：2017-02-21

本文作者：张基恒、李大中、张呈宇、魏进武

本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。

原文标题：DC/OS关键技术与应用场景