系统的数据中心的架构设计图 数据中心 操作系统

DC/OS 详细介绍

DC/OS 是 Mesosphere 开源的数据中心操作系统。可轻松的部署和运行有状态和无状态的容器、大数据以及传统应用。该系统基于 Apache Mesos 构建，其经验来自 Mesosphere, Yelp, Twitter, Airbnb, 以及很多创新的公司。

管理界面截图：

技术不断演进迭代，企业面临着众多挑战，例如：快速开发服务，收集和分析海量数据，接下来是如何对海量数据做出快速响应等挑战。可以预见，软件是企业直面这些众多挑战的重要因素，当然软件也驱动了个各种设备，汽车，银行系统等等。

建立一个支持快速部署服务的现代数据中心平台是一个日益复杂的挑战。IT组织面临巨大的压力来实现这些目标，同时还要关注传统中的需求，比如：保持敏捷性，高效率，安全性，服务质量和运营方面等。为了满足不断增长的业务需求，IT组织和服务提供商正在转向数据中心操作系统（DC/OS）。

DC/OS是一个开源软件项目，可在数据中心和云端的所有服务器上抽象计算资源。DC/OS由Apache Mesos分布式系统内核提供支持，这是一个可扩展的二层调度程序，它可以集中基础设施资源并跨多个分布式应用共享资源。DC/OS利用Mesos，Marathon和相关组件，为运行应用服务和大型数据平台提供高弹性和可扩展的解决方案

现代应用状况

容器化技术已成为IT公司的头等大事。其中很大一部分是由于软件运行发生变化，软件如何快速开发和部署。如果开发商应该开始容器之旅，运营商需要弄清楚如何运行在生产环境中。现在，这个谈话已经从容器方式转变成为世界各地现代应用程序提供强大而可扩展的编排系统。

速度和敏捷性在当今的数字化环境中至关重要因素。未来几年各种设备产生的海量数据会令人难以置信。为了加快创新步伐，公司正在迅速从传统的应用转型为微服务。

而传统的应用程序会绑定单个虚拟机或裸机服务器，现代应用程序完全解耦：由许多容器化的微服务应用和有状态的大数据引擎组成。大部分公司广泛使用开源软件，受益于社区贡献，让自己的开发团队专注于自己业务价值实现。

并不是每个公司都有Google，Facebook，Twitter，Apple或Uber的资源优势。这些公司花费了巨大人力和财力在平台建设上，并需要强大的性能，弹性，可用性和安全性去处理最先进的应用程序。

DC/OS为企业和服务提供商提供了一个平台，可以获得同样的好处 - 一个运行容器和平台服务的平台，共享统一的基础设施。DC/OS技术在生产中拥有比任何其他开放源代码软件更多的容器支持。

什么是DC/OS

DC/OS的核心是Mesos分布式系统内核，在对生产环境最苛刻的环境（如Twitter和Apple）中通过了测试和验证。DC/OS利用Mesos进行集群资源管理，以处理作业调度，资源管理和抽象，高可用性以及其他基础设施级流程。

资源调度只是架构的一部分，它的上层技术是Mesos，然后构成了完整的DC/OS平台。这些包括本地容器平台（Marathon）;DC/OS安装程序，Universe软件包存储库; GUI和CLI进行管理和监控;以及许多其他功能，包括网络，存储，安全，负载平衡和服务发现。

DC/OS是唯一将所有这些组件捆绑在一起并成为分布式软件部署的开源项目。DC/OS使每个公司都有能力成为Mesos受益者。做的事情只是自己工作的小部分。

好处包括：

●生产验证：基于Mesos和Marathon，是业界最成熟，最具企业级的容器编排平台。

●二层调度：Mesos具有两层调度设计，允许平台服务通过自动分发任务和容器来智能地调度工作负载，从而提高利用率。

●有状态服务：复杂的分布式系统可以在几分钟内部署。

●自动故障恢复：针对所有类型的应用程序，服务和工作负载内置高可用性和容错能力。

●资源效率：容器实现了性能隔离，消除了静态分区环境并解放了更高的服务器利用率。在DC/OS上运行Spark，Kafka和Cassandra，可以动态地扩缩容各种计算资源

●简化操作：通过基于GUI/CLI的监控和管理来控制整个数据中心资源。DC/OS提供了一个单一GUI界面和互操作接入，用于管理应用程序和有状态服务的连续生命周期。

●写一次，在任何地方运行：DC/OS提供了一个抽象层，无论部署在裸机，虚拟机，私有云或公共云上，都能提供标准用户体验。

拥有充满活力的用户群体，合作伙伴和贡献者使我们能够将DC/OS视为新的需求，出现用例。

DC/OS是开源技术，但它也是一个完整的生态系统。保持高速发展势头，建立一个充满活力的社区是很重要的。合作伙伴包括云计算提供商，如微软，领先的系统集成商，如埃森哲，以及世界上最创新的消费者技术公司，如Yelp。DC/OS目前由Mesosphere组织，提供社区提交者的贡献和路线图。

使用DC/OS 1.9，增加了诸如Pods和GPU支持等令人兴奋的新功能，以加强现代数据丰富的应用程序的企业级解决方案。这使得传统遗留应用程序的工作负载能够进行机器学习。DC/OS现在允许您分离和预留GPU资源，和神经网络与CPU相比提高高达10-20％。此外，增强的监控，日志记录和故障排除功能使生产中的运行容器更加容易。

超越容器

容器技术已经存在了一段时间。 Apache Mesos在2010年开始使用容器。自2000年初以来，Google决定使用容器而不是Borg的虚拟机，使用容器的资源管理系统。随着分布式系统和微型服务器的兴起，通过引入简化的容器管理工具，最近出现了人气的激增。

DC/OS与其他受欢迎的容器技术（如Kubernetes和Docker Datacenter）能够脱颖而出是如下原因：

1.DC/OS不单单支持Docker，也适用于所有基于OCI容器技术。DC/OS和它的容器编排平台（Marathon）是运行Docker容器的出色平台。然而现代平台需要更多灵活性。DC/OS支持新兴的容器格式，如AppC和OCI。

最后，所有容器引擎都使用现代Linux操作系统中的Linux cgroups和命名空间。用户不必考虑容器引擎的实际实现或隔离资源的机制。

2.DC/OS对于容器操作，不仅仅是容器编排。 Marathon容器技术流程平台包含一系列功能强大的功能，用于管理整个容器生命周期。很多正在使用Marathon用户包括Verizon，三星，Yelp，Autodesk，迪士尼，Mattermark等。

3.DC/OS有一个独一无二的两层调度器，可以运行许多分布式 系统作为服务。通过从核心资源调度程序中分离解决方案特定的调度逻辑，集群资源可以在诸如Marathon，Spark，Kafka，Cassandra和Jenkins等众多平台之间共享资源。

有状态的服务特别受益于这种体系结构，因为框架调度器可以处理诸如节点配置和跨故障区域的数据的智能复制等操作任务，从而提高可用性和数据持久性。

数据中心的应用市场

通过抽象所有数据中心资源，DC/OS可以将微服务的打包，部署和操作等复杂操作进行简洁化处理。对于现代CI/CD到大数据串联的场景不会在复杂，也不需要以前那些高度专业化的部署和运营技能。从前需要花费数天，甚至数周的时间来部署有状态的分布式应用程序是很常见的。

DC/OS Universe是一个包（Package）仓库，包括开源和商业软件交付。通过点击按钮，您可以轻松部署各种平台服务，如Cassandra，Chronos，Elasticsearch，HDFS，Jenkins，Kafka，Marathon-LB，Spark等。安装时间以分钟而不是数天或数周计算。

如果您正在寻找的应用程序不在Universe中，请可以自行打包应用程序并上线应用商城。DC/OS还提供了为私有定制应用程序部署离线本地Universe的功能。

传统意义上，数据服务框架一般很难使用，通常需要数千行代码。必须严格实施，并达到高可用性等功能，以确保框架能够生产就绪。

Mesosphere新开发的开源组件叫包SDK，用于在DC/OS上构建新的有状态服务。使用SDK，开发人员可以使用持续卷，容器和配置方式来编写大约100行代码的状态服务。 
该SDK是Mesosphere为DC/OS（如Kafka，Cassandra和HDFS）编写时留下来的经验产物。使用DC/OS SDK编写将极大提高生产率，并通过与合作伙伴和相关软件运营商进行配合，制定共同标准，开发和上线时间从几个月缩短到几天。

企业级DC/OS

虽然Mesosphere完全继续支持Mesos，Marathon和新兴的DC/OS社区，我们也是一家向全球2000企业提供产品和服务的软件公司。 Mesosphere Enterprise DC/ OS通过提供关于安全性，性能，网络，合规性，监控和多租户支持的关键企业功能来增强开源DC/OS项目。

深入解析DC/OS 1.8

– 高可靠的微服务及大数据管理平台

 

大家好，欢迎大家参加这次DC/OS的技术分享。

先做个自我介绍，刘超，Linker Networks首席架构师，Open DC/OS社区贡献者，长期专注于OpenStack, Docker, Mesos等开源软件的企业级应用与产品化。

从事容器方面工作的朋友可能已经听说过DC/OS，往往大家误解DC/OS就是marathon + mesos，其实DC/OS包含很多的组件，DC/OS 1.8九月份发布了，此次分享给大家做一个介绍。

一、DC/OS的基本思想

所谓的DC/OS，全称为数据中心操作系统，其基本的思想就是使得运维人员操作整个数据中如操作一台电脑一样。

DC/OS使用了哪些技术可以做到这一点呢？

如图，左面是普通的Linux操作系统，右面是DC/OS，在这里做了一个对比。

无论是哪种操作系统，都需要管理外部的硬件设备，最重要的四种硬件资源即CPU，内存，存储，网络。

最初使用汇编语言写程序的前辈，还是需要指定使用那些硬件资源的，例如指定使用哪个寄存器，放在内存的哪个位置，写入或者读取那个串口等，对于这些资源的使用，需要程序员自己心里非常的清楚，要不然一旦JUMP错了位置，程序就无法运行。这就像运维数据中心的一台台物理机的前辈一样，那个程序放在了哪台机器上，使用多少内存，多少硬盘，都需要心里非常的清楚。

为了将程序员从对硬件的直接操作中解放出来，提升程序设计的效率，从而有了操作系统这一层，实现对于硬件资源的统一管理。某个程序使用哪个CPU，哪部分内存，哪部分硬盘，程序只需要调用API就可以了，由操作系统自行分配和管理，其实操作系统只做了一件事情，就是调度。对应到数据中心，也需要一个调度器，将运维人员从指定物理机或者虚拟机的痛苦中解放出来，这就是Mesos。Mesos即使数据中心操作系统的内核。

在使用操作系统的时候，我们可以开发驱动程序来识别新的硬件资源，可以开发内核模块(例如openvswitch.ko)来干预对于硬件资源的使用，对于Mesos，同样可以开发isolator来识别新的硬件资源例如GPU，也可以开发Executor来干预资源的使用。

在内核之上，就是系统服务，例如systemd，是用来维护进程运行的，如果systemctl enable xxx，则保证服务挂掉后自动重启。对于DC/OS，保持服务long run的是marathon，但是仅仅只有marathon还不够，因为服务是启动在多台机器上的，而且服务之间是有依赖关系的，一个服务挂掉了，在另外一台机器启动起来，如何保持服务之间的调用不需要人工干预呢？这需要另外的技术，称为服务发现，多是通过DNS，负载均衡，虚拟机IP等技术实现的。

使用操作系统，需要安装一些软件，于是需要yum之类的包管理系统，使得软件的使用者和软件的编译者分隔开来，软件的编译者需要知道这个软件需要安装哪些包，包之间的依赖关系是什么，软件安装到什么地方，而软件的使用者仅仅需要yum install就可以了。DC/OS就有这样一套包管理软件，和其他的容器管理平台需要自己编译Docker镜像，自己写yml，自己管理依赖不同，DC/OS的软件使用者只需要dcos package install就可以安装好软件了，软件的配置，节点数目，依赖关系都是有软件编译者设置。

在最外层，DC/OS像普通的操作系统一样，有统一的界面和命令行。通过它们，可以管理安装包，管理节点，运行任务等。DC/OS不仅仅是运行容器的平台，如果仅仅运行容器，就是容器管理平台，而非数据中心操作系统。通过DC/OS，你可以在每台机器上运行一个命令来进行统一的配置，而无需登录到每台机器上去。你可以运行容器应用和大数据分析应用并共享资源，并且可以相互发现，这更加符合现代互联网应用，微服务和大数据不可分割。而且Mesos的架构非常开放，你可以通过开发Framework, Executor, Modules, Hooks等，轻松干预微服务或者大数据任务的执行过程，来定制化你的应用。这也符合操作系统微内核的概念。

二、DC/OS的内核模块Mesos

Mesos架构如下

这个图比较的著名了，也有很多文章介绍这个图，详情可以看文章http://mesos.apache.org/documentation/latest/architecture/，这里不做过多的介绍。

从图中可以看到，Mesos有Framework(Framework里面有Scheduler), Master(Master里面有allocator), Agent, Executor, Task几部分组成。这里面有两层的Scheduler，一层在Master里面，allocator会将资源公平的分给每一个Framework，二层在Framework里面，Framework的scheduler将资源按规则分配给Task。

 

Mesos的这几个角色在一个任务运行的生命周期中，相互关系如下：

 

Agent会将资源汇报给Master，Master会根据allocator的策略将资源offer给framework的scheduler。Scheduler 可以accept这个资源，运行一个Task，Master将Task交给Agent，Agent交给Executor去真正的运行这个Task。

 

这个图相对比较的简略，真正详细的过程比这个复杂很多，大家可以参考这篇博客，在代码级别分析了整个任务运行的过程，还画了一个泳道图。

 

要研究Mesos，熟悉整个过程非常重要，这样一个任务运行出现问题的时候，才能比较好的定位问题在哪里，如果解决。Mesos将一个简单的任务的运行过程，分成如此多的层次，如此多的角色来做，是为了双层调度和灵活配置，这是一个内核应该做的事情。

 

我们如何干预一个Task的运行过程呢？

第一、写一个Framework

如果你想完全自己控制Task的运行，而非让Marathon来运行并保持一个无状态的Task长运行，就需要自己写一个Framework，在你的Framework里面，三个Task之间的关系你可以自己定义，而非像Marathon一样，Task * 3，3个任务不分彼此，你的Framework可以控制这三个Task一主两备，可以控制三个Task的启动顺序，可以将一个先启动的Task的IP，位置等通过环境变量告知另外两个Task。

写一个Framework需要写一个Scheduler，实现一些接口，如文档http://mesos.apache.org/documentation/latest/app-framework-development-guide/中所述。

然后使用使用MesosSchedulerDriver来运行这个Scheduler。

其实Mesos这些模块之间的通信都是通过Protocol Buffer定义消息来交互的，然而如果让Framework的开发人员还要学会如何使用Protocol Buffer消息和Mesos Master通信，是很痛苦的事情，所以MesosSchedulerDriver帮助你做了这个事情，你只需要实现Scheduler定义的接口就可以了，不需要了解这些接口是谁调用的，调用了接口之后，消息如何传给Mesos Master。

所有的接口里面，最重要的是resourceOffers函数，根据得到的offers(每个slave都有多少资源)，创建一系列tasks，然后调用MesosSchedulerDriver的launchTasks函数，MesosSchedulerDriver会将这些tasks封装为LaunchTasksMessage发送给Mesos Master。

 

第二、写一个Allocator

通过上面的描述，Mesos有两层调度，第一层就是Allocator，将资源分配给Framework。

Mesos允许用户通过自己写Module的方式，写一个so，然后启动的时候加载进去，然后在命令行里面指定使用so中的哪个Module。

当然写Allocator的不多，因为Mesos的DRF算法是Mesos的核心，如果不用这个算法，还不如不用mesos。

Mesos源码中默认的Allocator，即HierarchicalDRFAllocator的位置在$MESOS_HOME/src/master/allocator/mesos/hierarchical.hpp，而DRF中对每个Framework排序的Sorter位于$MESOS_HOME/src/master/allocator/sorter/drf/sorter.cpp，可以查看其源码了解它的工作原理。

HierarchicalDRF的基本原理

如何作出offer分配的决定是由资源分配模块Allocator实现的，该模块存在于Master之中。资源分配模块确定Framework接受offer的顺序，与此同时，确保在资源利用最大化的条件下公平地共享资源。

由于Mesos为跨数据中心调度资源并且是异构的资源需求时，资源分配相比普通调度将会更加困难。因此Mesos采用了DRF（主导资源公平算法 Dominant Resource Fairness）

Framework拥有的全部资源类型份额中占最高百分比的就是Framework的主导份额。DRF算法会使用所有已注册的Framework来计算主导份额，以确保每个Framework能接收到其主导资源的公平份额。

 

举个例子

考虑一个9CPU，18GBRAM的系统，拥有两个用户，其中用户A运行的任务的需求向量为{1CPU, 4GB}，用户B运行的任务的需求向量为{3CPU，1GB}，用户可以执行尽量多的任务来使用系统的资源。

 

在上述方案中，A的每个任务消耗总cpu的1/9和总内存的2/9，所以A的dominant resource是内存；B的每个任务消耗总cpu的1/3和总内存的1/18，所以B的dominant resource为CPU。DRF会均衡用户的dominant shares，执行3个用户A的任务，执行2个用户B的任务。三个用户A的任务总共消耗了{3CPU，12GB}，两个用户B的任务总共消耗了{6CPU，2GB}；在这个分配中，每一个用户的dominant share是相等的，用户A获得了2/3的RAM，而用户B获得了2/3的CPU。

 

以上的这个分配可以用如下方式计算出来：x和y分别是用户A和用户B的分配任务的数目，那么用户A消耗了{xCPU，4xGB}，用户B消耗了{3yCPU，yGB}，在图三中用户A和用户B消耗了同等dominant resource；用户A的dominant share为4x/18，用户B的dominant share为3y/9。所以DRF分配可以通过求解以下的优化问题来得到：

max(x,y) #(Maximize allocations)
 subject to
 x + 3y <= 9 #(CPU constraint)
 4x + y <= 18 #(Memory Constraint)
 2x/9 = y/3 #(Equalize dominant shares)

最后解出x=3以及y=2，因而用户A获得{3CPU，12GB}，B得到{6CPU， 2GB}。

 

HierarchicalDRF核心算法实现在Src/main/allocator/mesos/hierarchical.cpp中HierarchicalAllocatorProcess::allocate函数中。

 

概况来说调用了三个Sorter(quotaRoleSorter, roleSorter, frameworkSorter)，对所有的Framework进行排序，哪个先得到资源，哪个后得到资源。

 

总的来说分两大步：先保证有quota的role，调用quotaRoleSorter，然后其他的资源没有quota的再分，调用roleSorter。

 

对于每一个大步分两个层次排序：一层是按照role排序，第二层是相同的role的不同Framework排序，调用frameworkSorter。

 

每一层的排序都是按照计算的share进行排序来先给谁，再给谁。

 

这里有几个概念容易混淆：Quota, Reservation, Role, Weight

• 每个Framework可以有Role，既用于权限，也用于资源分配
• 可以给某个role在offerResources的时候回复Offer::Operation::RESERVE,来预订某台slave上面的资源。Reservation是很具体的，具体到哪台机器的多少资源属于哪个Role
• Quota是每个Role的最小保证量，但是不具体到某个节点，而是在整个集群中保证有这么多就行了。
• Reserved资源也算在Quota里面。
• 不同的Role之间可以有Weight

 

在allocator算法结束之后，便调用Master::Offer，最终调用Framework的Scheduler的resourceOffers，让Framework进行二次调度。同上面的逻辑就串联起来。

 

第三、写一个Hook

你可以写hook模块，讲代码插在很多关键的步骤，从而改写整个Executor或者Docker或者Task的启动的整个过程。

 

可以干预的hook的地方定义在mesos/hook.hpp中。

 

Class hook定义如下：

其中比较常用的是slavePrelaunchDockerHook，可以在Docker启动之前做一些事情，比如准备工作。

还有slaveRemoveExecutorHook，这个可以在executor结束的时候，做一些事情，比如清理工作。

 

第四、创建Isolator

当你有一种新的资源需要管理，并且每个Task需要针对这个资源进行隔离的时候，写一个Isolator就是有必要的了。

例如默认的容器并不能动态指定并限制任务硬盘使用的大小，所以mesos-containerizer就有了"disk/du"来定时查看任务使用的硬盘大小，当超出限制的时候采取操作。

Src/slave/containerizer/mesos/containerizer.cpp里面列出了当前支持的isolator，你也可以实现自己的isolator，并且通过modules参数load进去。

 

Isolator定义了以下函数

 

在运行一个容器的最后，会调用每一个isolator的isolate函数，通过这个函数，可以对资源进行一定的限制，例如写入cgroup文件等，但是对于硬盘使用量，其实没有cgroup可以设置，需要过一段时间du一些，这就需要实现watch函数，过一段时间查看一下硬盘使用量，超过后做一定的操作。

 

第五、写一个Executor

如果运行一个普通的容器，或者命令行，则不需要实现Executor，仅仅Mesos默认的Executor就能够实现这个功能。如果你需要在Executor里面做很多自己定制化的工作，则需要自己写Executor。

 

写一个Executor需要实现一些接口，最重要的就是launchTask接口，然后MesosExecutorDriver将这个Executor运行起来。

 

就像Framework一样，Executor也是通过protocol buffer协议和Mesos-Agent进行沟通，通过MesosExecutorDriver，你不需要关心协议的事情，仅仅需要实现接口即可。

 

三、DC/OS的核心模块

下面的图描述了DC/OS的部署架构图：

在DC/OS看来，所有的节点分为三个区域，一个是管理区域，主要处理对于服务的管理方面的操作，如增删查改，启停扩缩等。为了高可用，Master节点可以是多个，在多个Master节点之前，需要有一个负载均衡器。第二个是对外服务区域，也即外界能够访问DC/OS内部的服务的区域，这个区域里面的服务多为对外的Nginx之类的，也会有marathon-lb来做外部的负载均衡器，所有对外服务区域的节点之外还需要一个负载均衡器。第三个区域是内部服务区域，用于部署内部服务，如数据库，消息总线等，这些内部节点不能对外访问。

 

第一、Admin Router

AdminRouter是一个反向代理，正是它将对外的区域和对内的区域完全隔离开来，在admin router之外，可以通过公网访问，在admin router之内全部是私网地址，这样提供了安全的统一访问机制。

 

安装完毕Open DC/OS之后，安装一个dcos的命令行工具，通过这个工具可以ssh到master的节点上。

1. eval `ssh-agent -s`
2. ssh-add .ssh/aws01.pem
3. dcos node ssh --master-proxy --leader

在这个节点上/etc/systemd/system路径下面有三个systemd的service，Open DC/OS的所有组件都是用systemd进行管理的。

1. ip-10-0-7-1 system # ls -l | grep adminrouter
2. lrwxrwxrwx. 1 root root 135 Oct 3 08:00 dcos-adminrouter-reload.service -> /opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/dcos.target.wants_master/dcos-adminrouter-reload.service
3. lrwxrwxrwx. 1 root root 133 Oct 3 08:00 dcos-adminrouter-reload.timer -> /opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/dcos.target.wants_master/dcos-adminrouter-reload.timer
4. lrwxrwxrwx. 1 root root 128 Oct 3 08:00 dcos-adminrouter.service -> /opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/dcos.target.wants_master/dcos-adminrouter.service

可以看到dcos-adminrouter.service是指向/opt/mesosphere/packages下面的一个路径，Open DC/OS的所有组件都是安装在这个路径下面的。

 

在/opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/nginx/conf这个路径下面，有一个文件nginx.master.conf，打开这个文件，就能看到熟悉的对于nginx的配置。

1. upstream mesos {
2.     server leader.mesos:5050;
3. }
4. 
       
   
5. upstream marathon {
6.     server master.mesos:8080;
7. }
8. 
       
   
9. location /mesos/ {
10.     access_by_lua 'auth.validate_jwt_or_exit()';
11.     proxy_set_header Host $http_host;
12. //mesos/;
13. }

1.  

1. location /marathon/ {
2.     # Enforce access restriction. Auth-wise, treat /marathon*
3.     # equivalently to /service/marathon*.
4.     access_by_lua 'auth.validate_jwt_or_exit()';
5.     proxy_set_header Host $http_host;
6. //marathon/;
7. }

从这个配置文件可以看出，所有对内的访问marathon的页面，访问mesos的页面，都是通过leader.mesos进行，这个域名是mesos-dns给出的，对应的是内部的IP地址，如果从外部访问marathon或者mesos的页面，则必须通过admin router，通过http://admin-router-external-ip/marathon或者http://admin-router-external-ip/mesos来访问。

 

第二、Mesos-DNS

对于数据中心操作系统来讲，服务发现和负载均衡是最最核心的功能，只有有了这些功能，才能使得服务的物理布局，服务之间的依赖关系，服务挂掉之后的自动修复不需要用户关心，才能使得用户像用一台电脑一样使用整个数据中心。

如果服务之间的相互调用不使用IP地址，而使用域名的话，问题会简单很多。

如图所示，对于Mesos上运行的每一个Task，Mesos-DNS都可以通过调用Mesos-Master的API得到，并且为每个Task分配一个域名和IP的对应项。如果一个Task需要访问另一个Task，则需要配置域名即可，无论Task如何挂掉，如何分配到其他的节点上运行，域名都不会变，当然Task的IP可能会变，但是不用担心，Mesos-DNS会更新它。每个Mesos-Agent只需要配置/etc/resolv.conf指向mesos-dns就可以了。

 

当一个Task运行的时候，Mesos-DNS会创建一个域名<task>.<service>.mesos对应：

• Mesos-Agent的IP地址
• 如果是Mesos Containerizer的话，返回的是Task内部容器的IP

 

另外<task>.<service>.slave.mesos还会提供所在的物理机的IP地址。这样通过hostport和Mesos-DNS所给的域名，可以实现服务的发现。

 

第三：marathon-lb

 

使用DNS虽然可以实现服务的自发现，但是不容易实现服务的负载均衡和弹性伸缩，而marathon-lb实现了这些功能。

Marathon-lb是一个基于haproxy的负载均衡器，但是它会监听marathon event bus，每当注册到marathon-lb上的服务数目变化的时候，marathon-lb也会自动更新haproxy的配置文件，从而实现负载均衡。Marathon-lb可以如图中实现对外的负载均衡，也可以实现对内的服务之间相互调用的负载均衡。

 

Marathon的安装可以在界面中universe里面搜索marathon-lb安装，也可以通过命令行执行dcos package install Marathon-LB进行安装，默认安装的对外的负载均衡器。

 

我们在服务里面创建如下的应用：

1. {
2. id": "nginx",
3. container": {
4. type": "DOCKER",
5. docker": {
6. image": "nginx:1.7.7",
7. network": "BRIDGE",
8. portMappings": [
9. hostPort": 0, "containerPort": 80, "servicePort": 10000 }
10.       ],
11. forcePullImage":true
12.     }
13.   },
14. instances": 1,
15. cpus": 0.1,
16. mem": 65,
17. healthChecks": [{
18. protocol": "HTTP",
19. path": "/",
20. portIndex": 0,
21. timeoutSeconds": 10,
22. gracePeriodSeconds": 10,
23. intervalSeconds": 2,
24. maxConsecutiveFailures": 10
25.   }],
26. labels":{
27. HAPROXY_GROUP":"external"
28.   }
29. }

在这个应用里面，servicePort为10000则说明我们注册到marathon-lb上的外部端口为10000, labels里面写的是external，也即注册到外部的负载均衡器上。

 

这个时候，我们访问public slave上的10000端口，就能看到启动的nginx的页面http://54.254.148.129:10000/，内部其他的应用可以通过http://marathon-lb.marathon.mesos:10000来访问这个nginx

如果我们访问public slave上的haproxy的配置页面http://54.254.148.129:9090/haproxy?stats，可以看到如下的映射关系。

对外marathon-lb监听10000端口，对内映射为10.0.1.78上的20215端口，如果我们从服务页面上查看，的确启动的nginx是监听20215端口的。

 

接下来我们部署marathon-lb-autoscale，它监控haproxy，发现RPS(request per seconds)超过一定的数目，就对应用进行弹性扩展。

1. {
2. id": "marathon-lb-autoscale",
3. args":[
4. --marathon", "http://leader.mesos:8080",
5. --haproxy", "http://marathon-lb.marathon.mesos:9090",
6. --target-rps", "100",
7. --apps", "nginx_10000"
8.   ],
9. cpus": 0.1,
10. mem": 16.0,
11. instances": 1,
12. container": {
13. type": "DOCKER",
14. docker": {
15. image": "brndnmtthws/marathon-lb-autoscale",
16. network": "HOST",
17. forcePullImage": true
18.     }
19.   }
20. }

 

接下来，我们部署应用siege向nginx发送请求

1. {
2. id": "siege",
3. args":[
4. -d1",
5. -r1000",
6. -c100",
7. http://marathon-lb.marathon.mesos:10000/"
8.   ],
9. cpus": 0.5,
10. mem": 16.0,
11. instances": 1,
12. container": {
13. type": "DOCKER",
14. volumes": [],
15. docker": {
16. image": "yokogawa/siege",
17. network": "HOST",
18. privileged": false,
19. parameters": [],
20. forcePullImage": false
21.     }
22.   }
23. }

 

siege到10，给nginx加压。

过一段时间就会发现marathon-lb-autoscale已经有动作了。

将一个nginx变成8个nginx

 

当我们将siege从10个变回0个的时候。

 

第四、Minuteman

Minuteman是一个内部的东西向的负载均衡器，可用于设置VIP，多个实例使用同一个VIP来进行负载均衡。

在创建服务的时候，选择Load Balanced，则下面会出现一行地址：nginxdocker.marathon.l4lb.thisdcos.directory:80，这个就是minuteman分配的VIP。

 

当服务创建好了之后，通过curl http://nginxdocker.marathon.l4lb.thisdcos.directory:80就可以访问这个服务，但是我们如果ping这个域名却是不通的，而且对于的IP地址也是很奇怪的IP地址，这个IP就是VIP.

 

这是怎么做到的呢？minuteman的load balancer是基于Netfilter的，在dcos的slave节点上，我们能看到多出来了四个iptables规则。其中前两个规则是在raw表里面的，后两个规则是在filter表里面的。

1. -A PREROUTING -p tcp -m set --match-set
2. -A OUTPUT -p tcp -m set --match-set
3. -A FORWARD -p tcp -m set --match-set
4. -A OUTPUT -p tcp -m set --match-set

根据iptbles的规则raw表中的规则会被先执行，一旦到达了filter表的minuteman的包就都过滤掉了。

NFQUEUE的规则表示将对于包的处理权交给用户态的一个进程。--queue-balance表示会将包发给几个queue，然后用户态进程会使用libnetfilter_queue连接到这些queue中，将包读出来，根据包的内容做决策后放回内核进行发送。

 

在每一个Mesos-Agent节点上都运行这一个minuteman的进程，监听这些queue，我们可以通过访问API查看VIP的映射关系，curl http://localhost:61421/vips。

 

我们可以看到VIP的11.112.175.214后面跟着两个节点10.0.1.78:27003和10.0.1.78:4989，正好对应nginx的两个实例。

 

四、DC/OS的微服务及大数据的管理机制

DC/OS是基于Mesos的，Mesos的灵活框架机制可以使得DC/OS既能够部署容器，也能够部署大数据框架，大数据框架在不运行任务的时候，几乎不占用资源，从而真正实现微服务和大数据框架的资源共享。

前面我们部署容器的时候，都是自己准备marathon的json进行部署的，这就需要使用服务的人和设计服务的人同样的专业。

DC/OS采用了一种package管理机制，将运行一个微服务或者框架所需要的各种配置制作成模板，模板由专业人士制作好上传到package repository，使用者就不需要那么专业，只要运行dcos package install安装即可。

 

Mesosphere提供了官方的package repository，名为universe，地址为https://universe.mesosphere.com/repo，在github上可以找到对应的代码https://github.com/mesosphere/universe。

 

 

对于一个package，往往包含下面的部分：

• package.json：这里面保存了一些metadata的数据，例如对于spark
1. "name": "spark",
2. "description": "Spark is a fast and general cluster computing system for Big Data. Documentation: https://docs.mesosphere.com/current/usage/service-guides/spark/",
3. "licenses": [
4.     {
5. name": "Apache License Version 2.0",
6. url": "https://raw.githubusercontent.com/apache/spark/master/LICENSE"
7.     }
8. ],
9. "tags": [
10. bigdata",
11. mapreduce",
12. batch",
13. analytics"
14. ],
• config.json：保存一些配置项，例如对于spark
15. "name": {
16. default": "spark",
17. description": "The Spark Dispatcher will register with Mesos with this as a framework name. This service will be available at http://<dcos_url>/service/<name>/",
18. type": "string"
19. },
20. "cpus": {
21. default": 1,
22. description": "CPU shares",
23. minimum": 0.0,
24. type": "number"
25. },
26. "mem": {
27. default": 1024.0,
28. description": "Memory (MB)",
29. minimum": 1024.0,
30. type": "number"
31. },
32. "role": {
33. description": "The Spark Dispatcher will register with Mesos with this role.",
34. type": "string",
35. default": "*"
36. },
• marathon.json.mustache：是一个模板，里面的一些变量会替换为config.json里面的内容，最终变成可以直接发送给marathon的请求。以spark为例
37. "id": "{{service.name}}",
38. "cpus": {{service.cpus}},
39. "mem": {{service.mem}},
40. "container": {
41. type": "DOCKER",
42. docker": {
43. image": "{{resource.assets.container.docker.spark_docker}}",
44. network": "HOST",
45. forcePullImage": true
46.     }
47. },
• resource.json：是一些资源，如image，tar.gz文件等
48. "assets": {
49. container": {
50. docker": {
51. spark_docker": "mesosphere/spark:1.0.2-2.0.0"
52.         }
53.     }
54. },

所有的这些配置都像模板一样已经预先写好，安装的时候界面上一点，或者一行命令就安装好了。

当然你如果点击Advanced Installation，则所有的配置都可以定制化

 

就像yum里面一样，将mysql-server的yum包的制作者和mysql的使用者分开，普通用户作为使用者，不需要了解太多的细节，用就是了。

 

如果想在数据中心里面使用package管理，可以生成自己的local universe，里面放入自己的应用，只要专业人士设计一次，便可以多次使用。也可以一次安装多个软件形成一个group，里面包含微服务的，也包含大数据的，两者可以通过服务发现相互访问。

 

我们在这里先安装一个spark的软件

 

最初安装完毕spark，却发现只有一个docker

Spark不是一个集群计算框架吗，怎么会只有一个Docker呢？这就是mesos对大数据框架管理的特殊之处。在spark不运行任务的时候，就仅仅占用这一个docker，其实是一个框架。

安装过程如图所示：

1. dcos package install spark会将请求提交给admin router
2. admin router会将请求提交给cosmos，也即package管理的服务
3. cosmos将config.json, resource.json, marathon.json组合成为一个marathon请求提交给marathon
4. marathon将请求交给mesos-master，然后交给mesos-agent
5. mesos-agent启动一个容器运行spark
6. 启动的spark容器会注册到mesos里面成为一个新的framework

 

真正运行spark任务的时候，才会有其他占用资源的任务被创建出来。

1. dcos spark run --submit-args='-Dspark.mesos.coarse=true --driver-cores 1 --driver-memory 1024M --class org.apache.spark.examples.SparkPi https://downloads.mesosphere.com/spark/assets/spark-examples_2.10-1.4.0-SNAPSHOT.jar 30'

 

 

Spark运行过程如图：

1. dcos spark run将任务提交给admin router
2. admin router将任务提交给spark framework
3. spark framework将任务提交给mesos-master
4. mesos-master将任务分发给mesos-agent进行分别处理
5. 任务运行完毕后，所有mesos-agent上占用的资源又都释放了。

 

正是这种模式，才实现微服务和大数据框架的共享资源，与此相对应的是使用Docker来部署spark集群，然后集群自管理，不归mesos管理。这样在创建spark集群的时候，就需要指定spark worker占用的资源，比如16G，然而这16G资源则无论spark是否在计算，都会被占用，都不会被其他的框架使用。

 

五、DC/OS 1.8的新功能

对于最新的DC/OS 1.8，有一个博客https://dcos.io/blog/2016/introducing-dc-os-1-8-ga/index.html描述了最新的功能。

 

其中第一个重要的功能为Mesos 1.0 and the Universal Container Runtime，也即可以使用mesos-containerizer来运行Docker的镜像了。这也是DC/OS对于容器的管理越来越独立的体现。

 

我们在mesos-agent所在的机器上可以查看

1. ip-10-0-1-78 dcos.target.wants_slave # ps aux | grep mesos-agent
2. root 1824 0.6 0.3 1069204 46948 ? Ssl Oct03 9:57 /opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004/bin/mesos-agent
/opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004下面，在/opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004/dcos.target.wants_slave/dcos-mesos-slave.service里面是mesos-slave的启动参数的设置，通过mesos的文档，我们知道对于mesos的参数可以使用环境变量进行设置。
1. ip-10-0-1-78 dcos.target.wants_slave # cat dcos-mesos-slave.service
2. [Unit]
3. Description=Mesos Agent: DC/OS Mesos Agent Service
4. 
       
   
5. [Service]
6. Restart=always
7. StartLimitInterval=0
8. RestartSec=5
9. KillMode=control-group
10. Delegate=true
11. LimitNOFILE=infinity
12. TasksMax=infinity
13. EnvironmentFile=/opt/mesosphere/environment
14. EnvironmentFile=/opt/mesosphere/etc/mesos-slave-common
15. EnvironmentFile=/opt/mesosphere/etc/mesos-slave
16. EnvironmentFile=/opt/mesosphere/etc/proxy.env
17. EnvironmentFile=-/opt/mesosphere/etc/mesos-slave-common-extras
18. EnvironmentFile=-/var/lib/dcos/mesos-slave-common
19. EnvironmentFile=-/var/lib/dcos/mesos-resources
20. EnvironmentFile=-/run/dcos/etc/mesos-slave
21. ExecStartPre=/bin/ping -c1 ready.spartan
22. ExecStartPre=/bin/ping -c1 leader.mesos
23. ExecStartPre=/opt/mesosphere/bin/bootstrap dcos-mesos-slave
24. ExecStartPre=/opt/mesosphere/bin/make_disk_resources.py /var/lib/dcos/mesos-resources
25. ExecStartPre=/bin/bash -c 'for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 2 > $i; echo -n "$i: "; cat $i; done'
26. ExecStart=/opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004/bin/mesos-agent
  
在文件/opt/mesosphere/etc/mesos-slave-common中配置了大量的mesos-agent的参数
1. MESOS_MASTER=zk://zk-1.zk:2181,zk-2.zk:2181,zk-3.zk:2181,zk-4.zk:2181,zk-5.zk:2181/mesos
2. MESOS_CONTAINERIZERS=docker,mesos
3. MESOS_LOG_DIR=/var/log/mesos
4. MESOS_MODULES_DIR=/opt/mesosphere/etc/mesos-slave-modules
5. MESOS_CONTAINER_LOGGER=org_apache_mesos_LogrotateContainerLogger
6. MESOS_ISOLATION=cgroups/cpu,cgroups/mem,disk/du,network/cni,filesystem/linux,docker/runtime,docker/volume
7. MESOS_DOCKER_VOLUME_CHECKPOINT_DIR=/var/lib/mesos/isolators/docker/volume
8. MESOS_IMAGE_PROVIDERS=docker
9. MESOS_NETWORK_CNI_CONFIG_DIR=/opt/mesosphere/etc/dcos/network/cni
10. MESOS_NETWORK_CNI_PLUGINS_DIR=/opt/mesosphere/active/cni/
11. MESOS_WORK_DIR=/var/lib/mesos/slave
12. MESOS_SLAVE_SUBSYSTEMS=cpu,memory
13. MESOS_EXECUTOR_ENVIRONMENT_VARIABLES=file:///opt/mesosphere/etc/mesos-executor-environment.json
14. MESOS_EXECUTOR_REGISTRATION_TIMEOUT=10mins
15. MESOS_CGROUPS_ENABLE_CFS=true
16. MESOS_CGROUPS_LIMIT_SWAP=false
17. MESOS_DOCKER_REMOVE_DELAY=1hrs
18. MESOS_DOCKER_STOP_TIMEOUT=20secs
19. MESOS_DOCKER_STORE_DIR=/var/lib/mesos/slave/store/docker
20. MESOS_GC_DELAY=2days
21. MESOS_HOSTNAME_LOOKUP=false
22. GLOG_drop_log_memory=false

默认的mesos-containerizer的隔离只包括cpu和memory，然而在最新的mesos版本里面，多了provisioner这一层，在上面的配置里面隔离了MESOS_ISOLATION=cgroups/cpu,cgroups/mem,disk/du,network/cni,filesystem/linux,docker/runtime,docker/volume，从而可以启动docker的镜像了。

 

第二个最重要的功能是CNI, container network interface。

 

 

CNI要工作需要三部分：

首先DC/OS不需要外置的IPAM，而是由mesos-master的replicated_log负责管理分配IP地址，Mesos需要启动的时候，载入overlay network的modules。

在路径/opt/mesosphere/etc/mesos-slave-modules下面有文件overlay_slave_modules.json

1. ip-10-0-1-78 mesos-slave-modules # cat overlay_slave_modules.json
2. {
3. libraries":
4.   [
5.     {
6. file": "/opt/mesosphere/active/mesos-overlay-modules/lib/mesos/libmesos_network_overlay.so",
7. modules":
8.         [
9.           {
10. name": "com_mesosphere_mesos_OverlayAgentManager",
11. parameters" :
12.               [
13.                 {
14. key": "agent_config",
15. value" : "/opt/mesosphere/etc/overlay/config/agent.json"
16.                 }
17.               ]
18.           }
19.         ]
20.      }
21.   ]
22. }

其次需要载入CNI isolator，这个在MESOS_ISOLATION这个环境变量里面已经配置了。

最后还需要navstar服务来实现跨节点之间的IP互访问

每个mesos-agent的机器上都有opt/mesosphere/packages/navstar--589afdaef03114a17576ee648ae433a052f7a4b9/，都会运行一个navstar进程。

每个机器上都会创建网卡d-dcos，如果Docker容器使用CNI获取IP的容器都Attach到这个网卡上，而非docker0上。

每个机器上都会创建网卡m-dcos，如果mesos容器使用CNI获取IP的容器都Attach到这个网卡上。

每台机器的d-dcos和m-dcos的网段都不同。

每台机器都会创建一个vtep1024的网卡，作为VTEP，背后是vxlan。

每台机器都会创建默认的路由表，从本节点连接到其他的节点默认走vtep1024这个网卡。

1. 9.0.0.0/24 via 44.128.0.1 dev vtep1024
2. 9.0.1.0/24 via 44.128.0.2 dev vtep1024
3. 9.0.3.0/24 via 44.128.0.4 dev vtep1024

对DC/OS的网络的配置在/opt/mesosphere/etc/dcos/network/cni路径下

 

为了试验这两个新的功能，我们首先创建一个使用CNI的Mesos容器，但是启动的是Docker的Image nginx

1. {
2. id":"nginxmesos",
3. cmd":"env; ip -o addr; sleep 3600",
4. cpus":0.10,
5. mem":512,
6. instances":1,
7. ipAddress":{
8. networkName":"dcos"
9.    },
10. container":{
11. type":"MESOS",
12. docker":{
13. network":"USER",
14. image":"nginx",
15. portMappings":[
16.             {
17. host_port": 0,
18. container_port": 80,
19. protocol": "tcp"
20.             }
21.          ]
22.       }
23.    }
24. }

在日志里面，打印出来容器的IP地址是m-dcos网段的。

 

然后我们再启动一个使用CNI的Docker容器

1. {
2. id":"nginxmesos1",
3. cmd":"env; ip -o addr; sleep 3600",
4. cpus":0.10,
5. mem":512,
6. instances":1,
7. ipAddress":{
8. networkName":"dcos"
9.    },
10. container":{
11. type":"DOCKER",
12. docker":{
13. network":"USER",
14. image":"nginx",
15. portMappings":[
16.             {
17. host_port": 0,
18. container_port": 80,
19. protocol": "tcp"
20.             }
21.          ]
22.       }
23.    }
24. }

从日志我们看出，配置的IP是d-dcos网段的，而非docker0网段的。

 

从Mesos上我们看出这两个容器是在两个节点上的

 

登入Docker的容器，ping另外一个CNI的mesos的IP是没有问题的。

1. ip-10-0-1-78 cni # docker ps
2. CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3. e7908deb3017 nginx "/bin/sh -c 'env; ip " 28 minutes ago Up 28 minutes 80/tcp, 443/tcp mesos-b3fbe6d9-236a-4856-a986-9babbba9c02c-S2.e3c96fa7-b5ff-4af6-9099-bbed399c7c37
4. a992929fb0d1 nginx "nginx -g 'daemon off" 6 hours ago Up 6 hours 443/tcp, 0.0.0.0:4989->80/tcp mesos-b3fbe6d9-236a-4856-a986-9babbba9c02c-S2.fca41f8d-816c-49cd-9b19-ba059b95e885
5. 8032756dd66e nginx "nginx -g 'daemon off" 6 hours ago Up 6 hours 443/tcp, 0.0.0.0:27003->80/tcp mesos-b3fbe6d9-236a-4856-a986-9babbba9c02c-S2.c0fdd3db-6f17-41d3-ab05-6f2d4d0bfa13
6. ip-10-0-1-78 cni # docker exec -it e7908deb3017 bash
7. root@e7908deb3017:/# ip addr
8. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
9.     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
10.     inet 127.0.0.1/8 scope host lo
11.        valid_lft forever preferred_lft forever
12.     inet6 ::1/128 scope host
13.        valid_lft forever preferred_lft forever
14. 51: eth0@if52: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1420 qdisc noqueue state UP group default
15.     link/ether 02:42:09:00:03:82 brd ff:ff:ff:ff:ff:ff
16.     inet 9.0.3.130/25 scope global eth0
17.        valid_lft forever preferred_lft forever
18.     inet6 fe80::42:9ff:fe00:382/64 scope link
19.        valid_lft forever preferred_lft forever
20. root@e7908deb3017:/# ping 9.0.2.13
21. PING 9.0.2.13 (9.0.2.13): 56 data bytes
22. 64 bytes from 9.0.2.13: icmp_seq=0 ttl=62 time=0.709 ms
23. 64 bytes from 9.0.2.13: icmp_seq=1 ttl=62 time=0.535 ms