作者：余何,陈秋浩,等
出版社：电子工业出版社有限公司
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Mesos 实战试读：
推荐序一
世界著名的曼宁出版社（Manning）出版了不少广受欢迎的计算机丛书，如搜索领域的Lucene in Action、Elasticsearch in Action，现在，他们又出版了这本云计算领域的Mesos in Action。
Mesos是一个开源的集群任务调度管理系统。现在随着分布式系统的广泛应用，越来越多的任务运行在集群上，而不是在单台服务器上。在x86 PC服务器集群上运行任务的好处是：单台服务器成本低，集群可以随着负载的增加添加服务器，水平扩展scale out，而不是过去使用昂贵服务器的scale up。随着集群规模的扩大，节点数越多，某个节点出现问题的概率就越大，当某个节点出现问题时，如何保证在这个节点上运行的任务能够顺利执行完成，成为一个技术难题。另外，如何管理集群，如何分发任务、监控任务执行过程等都是挑战。如果对于运行在集群上的任务，工程师还是需要在各台服务器上部署和管理，工作量将非常大，现在有些大规模集群的服务器数量已经超过万台。理想的情况是，工程师不需要关心集群里具体的每台服务器，而是把整个集群看成是一个计算、存储资源，把任务提交给集群的管理系统，由集群的管理系统去分发任务、监控任务执行，当某台服务器出现故障时，集群管理系统自动把任务派发到其他服务器上运行。这样的集群管理系统可以看作集群操作系统，甚至是数据中心操作系统。Google在这方面做了大量的实践，在2009年发表的The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines文章中，把整个数据中心看成一台计算机，所有的资源都由数据中心操作系统进行调度管理。
在20世纪80年代，学术界就开始了集群任务调度管理系统的研究，美国威斯康辛大学的研究人员开发了Condor系统，后来演进成开源的HTCondor系统。Google在1998年成立之初，就使用PC服务器抓取、索引、检索全世界的网页，服务器数量巨大，他们先是开发了WorkQueue系统，也就是一个任务队列，工程师把需要集群运行的任务提交给这个任务队列，由任务队列把任务下发到集群的服务器，并监控任务的运行，如果服务器出现故障，就把任务重新下发到新的服务器上。后来，他们在WorkQueue的基础上开发了Borg系统，Borg就是Google的集群任务调度管理系统。10年前我在Google工作的时候，每天需要在集群上运行的任务，都是通过Borg来提交、管理的，非常方便。那时候，Google的一个集群就已经有2万台服务器的规模，一个数据中心有10个这样的集群，20万台服务器。我加入腾讯后，也开发了这样的系统。这种系统的资源隔离采用了容器技术（操作系统之上的资源隔离），而不是虚拟机（物理服务器之上的资源隔离），以实现更小的系统开销，更方便的管理。现在容器技术也正在被广泛使用，成为虚拟机之外的可选技术路线。
Mesos也是一个这样的系统。Mesos由著名的美国加州大学伯克利分校的AMPLab发明，AMPLab是Algorithms,Machines and People（算法、机器和人）实验室的缩写。AMPLab的研究成果非常多，现在应用广泛的大数据处理框架Spark就是AMPLab的发明，AMPLab的研究人员还包括了著名的美国科学院及工程院院士、发明了RAID（磁盘阵列）和RISC（简约指令架构）的David Patterson教授。Mesos系统也在Twitter、Airbnb和苹果公司得到应用。
本书译者之一余何是IT专家，他曾在平安科技工作多年，有着丰富的大规模集群系统的开发、运维、管理经验，经历了多个云计算、大数据系统在金融行业的应用，在2015年出版了《PaaS实现与运维管理》一书，由他作为经验丰富的实战者来翻译这本书是最合适不过的了。
相信这本书会为对大规模分布式系统、集群任务调度管理、云计算和大数据感兴趣的读者带来受益。[1]陈军日志易CEO[1].陈军先生拥有18年IT及互联网研发管理经验，曾就职于Cisco、Google、腾讯和高德软件，历任高级软件工程师、专家工程师、技术总监、技术副总裁等职务，负责过Cisco路由器研发、Google数据中心系统及搜索系统研发、腾讯数据中心系统和集群任务调度系统研发、高德软件云平台系统研发及管理，对数据中心自动化运维和监控、云计算、搜索、大数据和日志分析具有丰富的经验。他拥有美国南加州大学计算机硕士学位，发明了4项计算机网络及分布式系统的美国专利。
推荐序二
余何兄是我的老朋友了，在运维领域耕耘多年，不仅运维能力强，而且善于总结乐于分享，也是GOPS全球运维大会金牌讲师。我和余何兄最开始是在圈子中互相关注，之后在一次论坛上偶遇，一番交流下来，一拍即合，一同走上了追求快乐运维的道路。我们的共识是“一起愉快地玩耍”，让运维变得更加轻松，让运维人员更加健康地生活。
但凡一个好的产品，都是从0到1，而不是从0到无穷、从0到包罗万象，这其中的道理就是专注。专注于做好一件事，提供稳定兼容的接口，这就是一个好产品的伊始。在运维平台领域，由于其需求范围广、组织差异大，很难有那么一个产品能够满足一切，而短时间满足一切又很可能意味着bug多多，因此，我们应该问自己，你到底需要什么？
刚好，Mesos就是这样一个产品：专注于做好一件事，专注于资源管理。关于其上的应用任务调度，无论是服务、批处理还是大数据，它都提供了稳定而兼容的接口，从而让用户在其上按照自己的需求，不断迭代实现，最后形成自己的产品。其在提高集群资源利用率，服务自动化部署等方面的表现，尤其令人称赞。
希望余何兄组织翻译的本书，能得到您的喜爱，为Mesos在中国的继续壮大添砖加瓦。为了我们共同的运维事业，一起加油！萧田国高效运维社区发起人开放运维联盟主席国内第一个DevOps Master
推荐序三
我一直在关注国内IT运维的发展，在不同的业务领域、企业规模下，运维的标准与规则参差不齐，真正掌握运维真知的人绝不仅意味着玩转创新技术、流行框架，更重要的是如何真正解决企业问题，如何保证落地与实现。国内第一本PaaS原创畅销书作者“众生的大师兄”余何有着十多年运维实战经验，经历了中国运维发展的各个阶段，在电信、金融以及物流领域都有所耕耘，今天由他领衔翻译的《Mesos实战》同样保持了高水准，相信一定会广受欢迎。
Mesos并没有什么吸引眼球的华丽外表，在起步阶段由于具备一定门槛，同时效能只能在具备一定规模后才能体现，因此一直没有快速地在运维领域流行起来。倒是OpenStack借助云计算概念、K8s背靠谷歌这个亲爹在社区内刮起了一股大的旋风，回头再来看看近几年商业化的过度炒作，连一向低调的运维领域也产生了泡沫。回到问题的本身，为什么要使用Mesos，我会站在和译者一样的角度考虑，我们必须考虑绕不过的环节，上层的应用，我们需要对遗留应用架构系统进行兼容吗？需要。Mesos是一个通用性资源管理框架，能够适配各种计算类型的服务，正因为如此，向上的任务调度才稍显复杂，为了做好兼容，我们必须做更多工作。
资源管理策略Dominant Resource Fairness（DRF）是Mesos的核心，是将Mesos比作分布式系统Kernel的根本所在。Mesos能够保证集群内所有用户都能够平等地使用集群内资源，这里的资源包括CPU、内存、磁盘等。在通用性方面，Mesos只负责提供资源给上层任务调度framework，而不负责具体任务管理，于是可让各种类型计算任务使用集群资源。关于准入门槛，如果仅部署一套Mesos，我们几乎什么也干不了，为了使用好它，我们需要不同的Mesos framework，像Marathon,chronos等，在特殊场景下，甚至需要开发自己的framework，除此之外磁盘、网络等问题也需要着重考虑。如果没有强大的意志力，初学者大多会望而却步。还好有“众生的大师兄”这样一位谆谆不倦的运维发展践行者，带着对运维未来美好发展的憧憬，坚持不懈的推行运维理念与实践，我也希望本书能够帮助Mesos在运维社区中快速流行与成熟，大家都能有所贡献与分享，真正解决我们企业内部遇到的运维问题。肖力云技术社区创始人
译者序
云计算时代，对开源产品的选择，很容易陷入一个误区，用商业化方式进行判断，选择最“热门畅销”的产品，而忽视了自身需求及组织能力，从而导致目标的偏离。2014年，我与小伙伴们开始考察一系列平台产品并进行研究，当时我们的需求很明确，提升资源利用率与运维效率，没有其他（专注，专注，再专注）。我们的组织能力也很明确，深入理解操作系统，能够像使用黑魔法一样改变操作系统的行为，具有工程设计能力，能很快地驯服与改造各种开源产品。基于以上两点，经历了一段考察期后，我们最终选择了Mesos。
Mesos很难让人一下子就亲近，她绝不是让你一见钟情的那种，她没有华丽外表让你如痴如醉，也没有什么直接功能让你耍酷摆炫，你需要花很长一段时间去理解她，你需要有应用场景，有资源节约型需求，有大规模机器集群管理，有多种计算类型，之后在不断的运用中，才慢慢发现Mesos的奥妙之处，一步步坠入到她的爱河中。Mesos专注于数据中心资源管理，专注于做好一件事，干净、简洁，如同操作系统内核一样，它是数据中心资源管理的Kernel。
很多人问我Mesos是否可以解决运维领域的可靠性问题、资源管理问题，从此天下太平、安枕无忧，作者在书中也有一点这种态度。但很遗憾，实际运维环境是相当复杂的，这种神一样的工具几乎不可能存在。不同的管理结构有着不同的权限层级，不同的应用类型有着不同的服务级别，不同的组织环境有着不同的流程规范，一言以蔽之，没有什么固定的工具可以解决不断变化的运维问题。
要保持运维水平的不断提升，最后发现这是一个组织行为学问题，是理念、人、流程、工具的结合体。组织的理念是什么？人的专业要求有哪些？对人的投入有哪些？组织理念文化又是如何影响着人，匹配的流程与工具又是什么？是这一切决定了最终的运维水平。精益思想对运维理念是一种启示，工程师文化强调了所需要的人才，ITIL是运维流程上的最佳实践，工具则是连接人与流程的桥梁。Mesos能否在企业发挥最大效应，看的不是Mesos，而是组织自身。余何2016.11 于深圳软件产业基地序
如果你想看到一个人抓狂的样子，你可以走到一个在数据中心手动配置并供应数十台服务器的人面前，然后说道：“哇！持续追踪在那些机器运行了什么东西，肯定非常容易，也非常好玩。”
或者找一个身上常年带着传呼机以便响应服务器中断的人，并说：“这听起来像一份毫无压力的工作呀。至少它保证你夜晚能睡个好觉。”
当然，事实上，管理服务器和其他数据中心基础架构一直以来都很困难和沉闷，给负责配置这些机器并响应机器故障的可怜男女带来了无数个不眠之夜。由于过去20年来公司越来越依赖于信息技术，经常会在每个服务器（或近些年的虚拟机）上配备一个应用程序，因此实际操作变得越来越困难。服务器数量动辄从一位数升级到两位数，有时甚至上升到三位数。
接着由Google、Facebook和Twitter等热门服务助燃的互联网呈爆炸式增长。由数以十亿计的智能手机、平板和其他设备助燃的移动互联网也立刻随后跟上。在任何特定时间里，数以百万计的用户可能同时在一个网站或APP中，而旧式计算技术无法再切入这样的世界。
在数据中心内，单一服务器的数据库（甚至所有单一服务器的服务）很快被分布式系统取代，其能以之前无法想象的容量来处理数据和流量。复杂庞大的应用程序也经常被微服务取代——把多组单一用途的服务分开管理，接着通过API进行连接，最终构造成用户端的应用。虽然伸缩性提升了，但构建这些系统的学习曲线和管理系统复杂性也都随之提升。
Google有个极好的方法，即在它自己的数据中心内使用一个叫Borg的系统来解决这个问题，表面上让大多数员工——如系统管理员和开发者——像管理一台大计算机的方式来管理数以万计的服务器。在Borg简化Google的操作几年后，开源的Apache Mesos项目粉墨登场并以相似的方式改变了其用户的生活。忽然之间，部署、运行和管理复杂分布式系统的过程变得非常简单。所有东西共享同样的机器组，而Mesos只需要轻松处理跑腿活儿——以可用的资源来匹配工作负载的需求。
最初我是作为一名Twitter的软件工程师来亲身体验这第一手转变的，在那里Mesos帮助攻克难堪的“失败之鲸”（fail whale,Twitter服务宕机标志）并帮助Twitter达到伸缩性和可靠性的新高度。当2012年我到Airbnb工作时，它还只是一家建立了4年的创业公司，Mesos又一次帮助我们的基础架构随着用户基数扩大成长——但是并不包括它的复杂性。Mesos和其前景深深触动了我，于是我决定建立Mesosphere这个公司，致力于让Mesos为主流企业所用。
随着Mesos趋于热门和Mesosphere的扩张，我们把目标设为雇用最好的Mesos工程师和从业者。当我们看到Roger Ingnazio在Pupet实验室建立一个基于Mesos的持续集成平台的工作成果时，我们知道我们必须拥有它。在知名公司运行可伸缩的生产系统是非常宝贵的经验，而且自从加入Mesosphere后，Roger的经验给我们基于Mesos的数据中心操作系统技术和我们的用户体验带来很多帮助。
Roger的《Mesos实战》让对Mesos和其技术生态系统感兴趣的人皆受益于他的经验。这本书是运行Mesos集群和安装你的第一个framework（计算框架）的极佳指导，它同时也探索了更高级的主题，例如掌握强大的Mesos framework（包括容器编排用的Marathon和大数据分析用的Spark），甚至包括构建你自己的framework。
无论你是在准备部署Mesos，还是你已经运行了它，并想进一步提升你的知识，你都难以找到一个比Roger更好的导师，或者一本比《Mesos实战》更好的书。FLORIAN LEIBERTMesosphere联合创始人、CEO
自序
Benjamin Hindman主导的团队于2009年在加州大学伯克利分校创立了Apache Mesos这个研究项目。Ben和他的团队想要通过允许多个应用共享一个单一的计算集群来提升数据中心的效率，就像多个应用可以在你的笔记本或工作站共享处理器、内存和硬盘驱动器一样。但他们想要在由许多服务器组成的现代数据中心上实现这个想法。经过10000行C++代码的最初实现后，他们在2010年发布了一篇论文《Mesos：一个数据中心内部细粒度资源共享平台》（Mesos:A Platform for FineGrained Resource Sharing in the Data Center）。
没过多久，Ben加入Twitter并使用Mesos来更好地扩展其基础架构，终结了Twitter难堪的“fail whale”时期——成名后Twitter的服务器处理能力跟不上用户的需求增长。虽然Twitter没有公开披露其庞大基础架构中的服务器数量，但根据其展示的在线资源和第一手资料，这个数量大约在每个集群有10000个Mesos节点。
2010年12月，Mesos项目进入Apache孵化器，作为Apache软件基金会的分支，使得项目获得ASF付出的全面支持。Apache Mesos项目于2013年6月从孵化器中得以完善，现在已经是一个高等级的项目。
2013年，Ben和Florian Leibert及Tobi Knaup一起创立了Mesosphere公司。Mesosphere的旗舰产品，数据中心操作系统（DCOS），通过为那些想要像Airbnb、Apple和Netflix一样轻易地使用Mesos来部署应用和扩展基础架构的企业提供全方位解决方案，将开源项目成功地商业化。Mesos持续成为开源Mesos项目的主要贡献者，并为开源社区提供Mesos安装包和工具。
我对于Mesos生态系统和大规模基础架构的初次涉足始于2014年，那时我开始想要使用Mesos在多个Jenkins（热门的持续集成框架）实例之间共享资源。其时，Mesos看起来像是留给那些已经知晓它的人去使用的，因为虽然那时有大量可用的线上资源，但是很难被找到，而且没有一个权威可信的来源。彼时也没有任何书籍涉及Mesos。我写了几篇关于我的工作经验的博客，其他人看起来好像跟我一样：对这个项目都想了解多一些，但不知道从何入手。
2015年1月，Manning出版社找到我并问我是否有兴趣写一本关于Mesos的书。我之前从未写过书，这个请求一开始让我有点不知所措。但我也把它当作一个好机会来写一本工具书，因为当我刚开始使用Mesos时，我确实希望拥有这么一本书来指导我。幸运的是，Manning的团队给我这份自由来实现这个想法。
希望你在使用《Mesos实战》的过程中，能发现它是一个部署和管理Mesos集群和提升你基础架构整体效率的宝贵资源，而且它能够帮助你的团队或你的客户更快捷便利地部署应用到生产中。Roger Ignazio于美国俄勒冈州，波特兰第1部分你好，MesosApache Mesos是什么？ Mesos与传统数据中心架构的区别是什么？容器与虚拟机的区别是什么？为什么你有可能会使用Mesos？这些是我在第一部分要回答的问题。我们将通过对比传统数据中心与相关的新技术来学习Apache Mesos项目。你也将看到一个Mesos实践示例，它在集群上运行着一个Apache Spark数据处理作业。1 初识Mesos
本章内容
■ Mesos介绍
■ 比较Mesos与传统数据中心
■ 明白为何以及何时使用Mesos
■ 用Mesos分布式架构进行工作
传统上说，数据中心内的物理机、虚拟机是典型的计算单元。它们被各种配置管理工具划分，随后在其上部署应用。这些机器通常被组织成集群来提供单一的服务，系统管理员管理其日常运作。集群最终会达到它请求处理的最大容量，随后更多的机器将在线加入进来处理负载。
2010年，一个旨在解决扩容问题的项目在美国加州大学伯克利分校诞生。这个软件项目就是现在所知的Apache Mesos，它在某种程度上对CPU、内存、磁盘资源进行抽象，从而允许整个数据中心如同单台大服务器般运转。无需虚拟机和操作系统，Mesos创造了一个单独底层的集群为应用提供所需资源。如图1.1所示一个简化的例子。图1.1 framework通过Mesos来共享数据中心的资源
本书将介绍Apache Mesos，一个开源的集群管理工具，它让运维和开发人员更多地关注应用本身，而不是其下的服务器资源。你将看到如何在你的环境中启动和运行Mesos，如何共享资源和处理异常，以及可能最重要的是如何将它作为一个平台来部署应用。1.1 遇见Mesos
Mesos通过引入一层抽象，提供了一种像管理单台大服务器般的方法来管理整个数据中心。较关注一个应用在一个特定服务器上运行而言，Mesos的资源隔离机制支持多租户，该功能允许多个应用运行在同一机器上，从而更加高效地利用计算资源。
为了更好地理解这个概念，你可以认为Mesos与当今虚拟化解决方案类似：像hypervisor一样抽象物理CPU、内存、磁盘资源，之后以虚拟机形式呈现。Mesos做相同的事情，但其将资源直接提供给应用。以另一种方式来理解Mesos是在多核处理器场景中：当你在笔记本上启动一个应用程序时，它运行在一个或多个处理器核中，但多数情况下运行在哪一个核上并不重要。Mesos将这个概念应用到数据中心中。
除了提升整体资源的利用率外，Mesos还一开始就支持分布式、高可用及容错。通过使用容器技术，如Linux control groups（cgroups）和Docker,Mesos实现了进程间隔离，允许多个应用运行在同一机器上。你也许曾搭建过三个集群，分别运行着Memcached、Jenkins CI和Ruby on Rails应用，现在你只需部署一个Mesos集群就可以运行所有的应用了。
在接下来的几个小节中，你将看到Mesos如何运作来提供所有的这些功能，以及它与传统数据中心的区别。1.1.1 理解它如何工作
通过对资源供给、两层调度、资源隔离几个概念的整合，Mesos提供了一种方法让整个集群像一台超级计算机一样运行任务。在进一步深入之前，让我们看一下图1.2，该图演示了Mesos为应用的运行提供资源的逻辑流。在这个特殊例子里我们引用了Apache Spark数据处理framework。图1.2 Mesos将有效的CPU、内存及磁盘突出作为资源供给framework
让我们逐一分解：
➊ Mesos slave将它有效的CPU、内存及磁盘以资源供给的形式提供给Mesos master。
➋ Mesos master的分配模块（或者调度算法）决定为哪一个framework（或应用程序）提供资源。
➌ 在这个特殊示例中，Spark scheduler在集群中没有任何要运行的作业。它拒绝了Mesos master的资源供给，允许master将资源提供给那些可能有工作需要运行的framework。
➍ 考虑现在有一个用户提交了Spark作业到集群中运行，scheduler接受了这个作业并等待一个资源供给来满足工作负载。
➎ Spark scheduler从Mesos master接受一个资源供给，随后在Mesos slave上启动一个或多个任务。这些任务在容器内运行，容器提供的隔离机制让各类任务可以运行在同一个Mesos slave上。
看上去很简单，不是吗？现在你已经学到了Mesos如何以资源供给形式来向framework通告资源，两层调度如何允许framework依据需求情况来接受或者拒绝资源供给，下面让我们进一步了解这些基础概念。
注意：在未来的版本中正在努力将Mesos slave重命名为agent。因为本书采用的版本是Mesos 0.22.2，为了防止造成不必要的混淆，书中的术语均以该版本为准。更多的信息请见https://issues.apache.org/jira/browse/MESOS-1478。
资源供给
如同其他的许多集群管理器一样，Mesos集群由一组称为master和slave的机器组成。集群中的每一个Mesos slave以资源供给的形式通告它有效的CPU、内存和存储资源，如图1.2所示，这些资源供给定期地从slave发送给Mesos master，通过调度算法的处理后，再提供给运行在Mesos集群上的framework调度器。
两层调度
在Mesos集群中，资源调度的职责是由Mesos master的分配模块和framework的调度器共同承担的，这就是所谓的两层调度概念。如前所述，资源供给从Mesos slave发送到master的分配模块，随后分配模块负责将资源提供给不同的framework调度器，framework调度器依据工作负载情况来决定接受还是拒绝。
分配模块是Mesos master中的一个可插拔组件，它所实现的算法决定在什么时候将哪一个资源分配给哪一个framework。组件的模块化性质能让工程师为他们组织定制自己的资源共享策略。默认情况下，Mesos使用了伯克利大学开发的DRF（Dominant Resource Fairness）算法：
简而言之，DRF试图在所有用户间最大化它们最小资源的分配。例如，如果用户A是耗CPU型任务，用户B是耗内存型任务，DRF企图在A的CPU资源与B的内存资源之间实现平衡。在单资源场景下，[1][2]DRF将回退到max-min fairness算法。
Mesos默认使用的DRF算法适合于绝大多数部署场景。因此你没有必要再写一份自己的分配算法，本书也不会再深入讨论DRF。如果读者对此DRF研究感兴趣的话，请阅读在线文档www.usenix.org/legacy/events/nsdi11/tech/full_papers/Ghodsi.pdf。
资源隔离
Mesos支持多租户功能，也就是多个进程能同时在一台Mesos slave上运行，通过利用Linux cgroups及Docker容器技术实现了进程间隔离。framework使用Mesos的容器化来执行任务。如果你对容器不熟悉，可以认为它们是hypervisor在一个物理主机上运行多个虚拟机的轻量级方法，不同的是容器不需要运行整个操作系统而承担额外负载。
注意：除了容器和cgroups,Mesos还为遵循POSIX标准的操作系统提供了另外一种隔离方法：posix/cpu、posix/mem和posix/disk。值得注意的是，这种隔离方法并不隔离资源，而是对资源的使用进行监视。
现在你已经对Mesos的工作机制有了更加清晰的理解，接下来你将弄清楚Mesos技术与传统数据中心的区别。更具体地说，下一节将介绍以应用为中心的数据中心概念，在那将着重在应用本身，而不是在其下的操作系统及服务器。1.1.2 虚拟机和容器的比较
当考虑在传统数据中心部署应用时，虚拟机会立即浮现在脑海里。最近这些年，虚拟化提供商（以Vmvare、OpenStack、Xen和KVM为例）的服务在企业组织内部已变得非常普遍。类似于hypervisor抽象一台物理服务器资源给多台虚拟机共享，Mesos也提供了一层抽象，尽管在不同级别实现。资源将直接分配给应用本身，依次被容器消费。
为了说明这一点，请考虑图1.3，它对基础架构资源的各层进行了比较，其上部署了4个应用。图1.3 基于虚拟机和基于容器的应用部署对比
虚拟机
当想到基于虚拟机部署应用时，应考虑运维操作系统的开销：安装软件、应用安全更新、管理用户权限、识别与修复配置信息变化，这些步骤还将继续。当你更关心应用部署本身时，要知道在整个操作系统之上运行应用到底有什么附加的好处？何况操作系统本身也是有开销的，它消耗了CPU、内存、磁盘资源。在应用系统大量扩容的场景下，这将变得非常浪费资源。Mesos依据以应用为中心的方法来管理数据中心，采用轻量级的容器，能极大地简化基础架构资源栈及应用部署。
容器
如之前所见，Mesos使用容器技术实现进程间的资源隔离。在Mesos的环境中，最重要的两个资源隔离方法分别是构建在Linux内核之上的cgroups和Docker容器。
2007年左右，Linux内核2.6.24版本开始支持cgroups，它让进程可以运行在沙箱内与其他进程隔离。在Mesos环境中，cgroups对运行态进程进行资源限制，确保它们不会影响同系统上的其他进程。在使用cgroups之前，进程所依赖的包文件、库文件（特定版本的Python，可运行的C++编译器等）必须已经安装在操作系统上。如果你的工作负载、包文件、库文件及工具集都是标准化的，或者它们彼此不易产生冲突，这也不会是一个问题。图1.4示范了如何使用Docker技术来克服这些冲突类的问题，如何以一种更好的隔离性方式来运行应用与负载工作。图1.4 虚拟机、Docker容器及Linux cgroups之间的比较
通过使用包括cgroups、namespaces的Linux内核底层原语，Docker可以像虚拟机般构建和部署容器。应用程序及其所依赖的全部文件都被打包在容器内并部署到了操作系统上。它使用了运输行业的概念——工业标准集装箱，通过遵循标准来部署应用。这种新的软件单元交付方式较虚拟机部署更加轻便，近些年来越来越流行。
你并不需要了解所有的实现细节，以及使用Mesos构建与部署容器的错综复杂信息。如果你想了解更多的信息，请参考以下在线资源：
● Linux control groups: www.kernel.org/doc/documentation/cgroup-v1/cgroups.txt。
● Docker: https://docs.docker.com。1.1.3 知道何时及为何使用Mesos
运行大规模应用不再是只有大企业可以做到的了，人员不多的创业公司也能够轻松创建吸引百万用户的APP。重新构建应用和数据中心不是一件简单的事情，但是在资源栈中某些组件是非常适合运行到Mesos上的。通过使用这些技术和将它们（以及它们的负载）迁移到Mesos集群上，你将更加容易地进行资源扩容及让数据中心更具效率。
注意：本书涵盖的是Mesos 0.22.2版本，它提供了一个环境运行无状态、分布式应用。Mesos从0.23版本开始，将开始支持持久化资源，包括有状态的framework，更多的信息请参看 https://issues.apache.org/jira/browse/MESOS-1554。
举例说明，考虑无状态、分布式及有状态的相关技术适合与不适合在Mesos上运行的情况如表1.1所示。表1.1适合与不适合在Mesos上运行的技术
实现Mesos的真正价值在于运行无状态的服务和应用，在应用正在处理进入的负载时，集群中的节点在任意时刻离线也不会对整个服务造成影响，服务或许可以运行一个作业来将这个结果报告给其他系统。如前所述，这类应用包括Ruby on Rails、Jenkins CI slave节点。
在Mesos上以framework形式运行分布式数据库（例如Cassandra和Elasticsearch）和分布式文件系统（例如Hadoop分布式文件系统）已取得了不错进展。但是其可行性是建立在正确的冗余级别上的。虽然某些分布式数据库和文件系统具备数据复制和容错功能，但是如果整个Mesos集群出现异常（例如自然灾害、冗余电路、制冷系统异常，或者人为失误），你的数据仍将无法被抢救回来。在真实的世界中，你应该对风险进行评估，权衡在Mesos集群上部署持久化数据服务的利弊。
如前所述，Mesos适合运行无状态、分布式服务。在本书写作之时，需将数据持久化到磁盘中的有状态应用并不适合于在Mesos之上运行。虽然可以这样做，但并不建议某些数据库服务在Mesos上运行，例如MySQL、PostgreSQL。如果你需要持久化数据，推荐使用传统的数据库集群方式，部署在Mesos集群之外。1.2 为什么我们要重新思考数据中心
在数据中心中部署应用一般会涉及一台或者多台服务器资源。虚拟化技术的引入并逐渐变成主流，方便我们在一台服务器上运行多个虚拟机，从而能够更好地使用物理资源。但这种方式运行应用意味着每一个虚拟机上将跑一个操作系统，这将造成更多的资源消耗，以及带来额外的维护成本。
本节将阐述我们需要重新思考如何管理数据中心的两个主要原因：资源静态分配的管理开销，以及将重心放在应用而不是基础设施的需求。1.2.1 资源划分
当你考虑传统的基于虚拟机方式部署应用和集群静态分配时，你马上会意识到这是一种低效的部署方式，在运维管理上也是非常繁重的。通过最大化数据中心服务器的资源使用率，运维团队也将投资收益比最大化了，保证了总成本在尽可能合理的范围内。
在计算机界，团队一般指的是集群，这个术语常常用来表述一组共同工作的服务器作为单一系统来提供某种服务。传统上这类服务的部署方式是以节点为中心的，即你必须使用一定数量的机器来提供一个给定的服务。但随着基础架构资源的扩展及服务供给的增长，这种静态资源的分配方式将变得难以为继。
考虑到当这些服务资源的需求翻倍时，为继续扩容，系统管理员需要分配新的虚拟机并将它们加入到集群中。运维团队很可能提前意识到将来需要更多额外资源，于是将集群的能力直接扩容到之前的三倍。尽管你很好地完成了服务的扩容工作，但现在集群中的某些机器是空闲的，等待着被使用。如果任意一集群中的虚拟机突然异常，它可能需要立即恢复在线来保证服务的总容量，如图1.5所示。图1.5 在数据中心中资源静态分配的三个应用
现在考虑通过Mesos来解决如上扩容场景的问题，如图1.6所示，你能看到使用了数据中心里同样的服务器，但这次是着重在应用上，而不再是虚拟机。应用可以在任意拥有有效资源的机器上运行。如果你需要扩容，你只需要将机器添加到Mesos集群中，而不是将机器添加到多个应用集群中。如果某个单一的Mesos节点离线了，对Mesos集群中的任何服务都不会产生影响。图1.6 在Mesos集群中运行的三个应用
考虑一下在成百上千台服务器时的差异，你不再是去试着猜测需要多少台服务器，以及如何将它们分配到静态的应用集群中，而是允许这些服务按照它们的需求动态地请求计算、内存、存储资源。你将新的机器添加到Mesos集群中完成扩容，Mesos集群中的应用扩展到新基础设施上运行。以一种单一、大机器集群的方式运维有如下的优势：
● 你能够很轻松地对应用集群进行容量管理；
● 你能够更少地去关注服务到底在什么位置运行；
● 你能够从几个节点快速地扩容到上千个节点；
● 一些服务器宕机时不会严重影响到其中任何一个服务。1.2.2 应用部署
正如我们上面讨论的，在Mesos上部署应用的一个主要不同点，或者说优势是支持多租户。不像虚拟化hypervisor在一台物理服务器上运行多个虚拟机，Mesos允许多个应用在隔离的环境中运行。它使用了Linux cgroups或Docker容器技术。整个数据中心变成了一个平台来部署应用，而不再是多套环境（开发、预生产、生产）。
Mesos在那里通常被当作或者说扮演了一个分布式内核的角色，而Mesos framework帮助用户来执行长运行态服务，以及调度任务，类似于init、Corn系统这种周期性执行任务。你将在后面学到这些framework（Marathon、Chronos和Aurora）的更多知识，以及如何在其上部署应用。
考虑一下到目前为止我所描述的功能：Mesos提供了非常易用的容错能力。当一台服务器离线时，Mesos集群会自动在另一处服务器上启动之前异常失败的服务，而不是让系统管理员手工地卷入进来。只有在大量机器同时离线的时候系统管理员才需要介入，因为那可能是一个大问题。正因如此，在正确的位置放置和资源冗余充足的情况下，日常维护可以在任何时候进行。1.3 Mesos分布式架构
为了提供规模化服务，Mesos提供了一套分布式、容错性架构来完成资源的细粒度分配。这套架构包括三个组件：master、slave及运行在其上的应用本身（通常称为framework）。Mesos依赖于Apache ZooKeeper，一个分布式的数据存储系统，专用于集群内的协调同步leader投票选举，以及Mesos master、slave和framework间的leader发现。
在图1.7，你能够看见这些架构组件如何在一起工作，从而提供一个稳定的平台来部署应用。在接下来的章节中我将分解开来一一加以阐述。1.3.1 masters
Mesos master的职责是管理集群中在每台机器上运行的Mesos slave守护进程。通过ZooKeeper和master之间协调哪个节点是主master，哪些节点作为备用存在，它们将在主master离线时接管服务。
主master节点使用可插拔的分配模块或调度算法来分发资源供给至各种调度器，从而决定将什么资源提供给某一特定的framework。调度器依据其上是否有任务需要执行来决定接收或拒绝资源供给。
Mesos集群至少要求有一个master节点。在生产环境为了保证高可用性，推荐采用三个甚至更多的master节点。你可以将ZooKeeper在与master相同的机器上运行，或者使用独立ZooKeeper集群。在第3章我们将更加详细地讨论Mesos master的部署。图1.7 Mesos架构图，包括一个或多个master、sIave和framework1.3.2 slaves
在集群中负责执行framework任务的服务器被称为Mesos slave节点，它们访问ZooKeeper来确定主master节点，将CPU、内存、存储资源以资源供给的形式宣告给主master。当调度器从主master接收资源供给后，在slave节点上启动一个或多个执行器，执行器负责运行framework的任务。
Mesos slave也能够基于属性与资源进行配置，从而允许它们定制特定环境。属性配置是键值对形式，可以包含类似于节点所在机房位置信息。资源配置可以替代Mesos自动探测发现slave节点的有效资源，并由用户指定具体的CPU、内存、磁盘资源信息。属性配置与资源配置的示例信息如下：
在属性配置中对Mesos节点的数据中心、节点位置、操作系统进行了说明，在资源配置中用户指定了该节点提供的CPU、内存和磁盘资源。在日常维护中，这些信息对保证应用在线运行不受影响特别有用。使用这些配置信息，数据中心的运维人员可以在整个机柜甚至整排机柜离线日常维护时不影响用户。第4章在Mesos slave配置章节将对此进行详细讨论。1.3.3 frameworks
如你前面所了解到的，framework是表示Mesos应用的术语，它负责在集群上调度与执行任务。framework由两个组件组成：调度器与执行器。
提示：本书写作时存在的framework清单请见附录B。
调度器
调度器是典型的长运行态服务，负责与Mesos Master连接，接收或拒绝资源供给。Mesos将调度的职责委派给了framework，而不是试着由自己调度所有的任务执行。调度器基于当下是否有任务需要运行来决定是否接受或拒绝资源供给。调度器通过与ZooKeeper通信来探测主master的存在，之后将其自己注册到master中。
执行器
执行器是在Mesos slave上启动的一个进程，负责运行framework的任务。在本书写作之时，Mesos内建的执行器允许framework执行shell脚本、Docker容器等。Mesos支持多种编程语言执行器，新的执行器可以与framework绑定在一起，当任务需要它时由Mesos slave从framework获取。
如你所看到的，Mesos提供了一个分布式、高可用的架构，master负责整个集群的调度工作，slave将有效资源通知调度器，并在集群中执行任务。1.4 小结
在这一章中，你了解了Apache Mesos这个项目、它的架构，以及它是如何解决数据中心伸缩性问题的，它又是如何让集群变得简单。你也学习到了在应用部署上Mesos与传统数据中心的区别，为什么以应用为中心的方法能够让资源更加有效。我们也讨论了在什么地方（不在什么地方）使用Mesos来应对负载，你在哪儿可以获得帮助，获得更多你需要的信息。这里有如下一些事项请谨记：
● Mesos从底层系统抽象化CPU、内存、磁盘资源，将多个服务器展现成一个大机器。
● Mesos slaves以资源供给的形式宣告它有效的CPU、内存、磁盘资源。
● Mesos framework 由两个主要组件组成：调度器和执行器。
● 容器使用轻量级方法实现了进程间的资源隔离。
在下一章节，我将带着你通过运行一个真实例子来了解Mesos如何让资源更具有效率，你如何在自己的数据中心内将应用运行到Mesos生态系统上。2 使用Mesos管理数据中心资源
本章内容
■ 通过真实示例介绍Mesos
■ 对独立和通用集群进行对比
■ 在Mesos集群上启动Spark job
■ 探索framework与Mesos间的交互
前一章介绍了Mesos项目，它是如何工作的，它与传统数据中心架构有什么区别。这一章将通过一个真实场景来探讨Mesos的益处：演示多个应用间如何采用Mesos来共享资源，并将用Apache Spark作为范例，它是一个流行的数据处理framework。
如果你对Spark并不熟悉，请不必担心：接下来的场景中将使用Spark来演示Mesos是如何在多个应用间分发工作负载和实现资源共享的。我们用Spark作为案例来学习在通用的Mesos集群上进行资源共享和工作负载调度，了解通用模式与数据中心内的静态资源分配有什么区别。我们将对Mesos和Spark的Web界面做一个简单介绍，也许你将在这个过程中对Spark也有所了解吧，谁知道呢？接下来就让我们开始吧。2.1 Spark简要介绍
引用项目主页的原话，“Apache Spark是一个快速、通用的大规模数据处理引擎”，它与另外一个流行项目Hadoop一同活跃在大数据领域，常用于数据科学分析。在很多案例中，Spark执行任务无论是在内存中还是在磁盘上，比Hadoop的MapReduce更加快速与更具高效。
Spark同时提供了各种流行编程语言的API，包括Python、Scala和Java，除了支持类MapReduce的批处理外，同时支持流式处理、交互查询、机器学习库。
Spark历史简介
2009年，Matei Zaharia在加州大学伯克利分校AMPLab实验室开始了Spark的开发，这个组织同时支持着Mesos的开发。事实上，Matei 也是Mesos的联合创造人。
2010年Spark开源后，被捐赠给了Apache软件基金会，2013年在Apache内进行孵化，到了2014年升级为顶级项目。
2013年Matei作为联合创始人成立了Databricks公司，在Spark成功之后寻求将其商业化的机会，帮助客户们解决大数据方面的问题。Databricks目前仍然是Spark开源项目的最大贡献者。
在最基础的层面上，Spark需要集群管理器来分配工作负载，并访问一个Hadoop兼容的数据源。一般情况下，Spark支持如下几种类型的集群管理器：
● Spark独立版；
● Mesos；
● Hadoop YARN；
● 仿分布式（在本地的笔记本或者工作站上运行）。
虽然可以将Spark在本地运行，使用笔记本或工作站中的多核CPU，但这常常仅作为开发环境使用：CPU核的数量限制了执行器的数量，当你建立一个生产环境Spark集群时，有两个选择：部署一个独立版的静态分区的Spark集群到提前准备好的一批服务器上，或者使用一个类似于Mesos或YARN的集群管理器来运行Spark任务。
为了更好地说明如Mesos这样的通用集群器，我们将在2.1.1节中以Spark独立版集群来对比Mesos。2.1.1 独立集群上的Spark
在图2.1中，你看到Spark driver连接到了一个集群管理器——Spark master，它轮流将任务分发到各个工作节点。图2.1 独立模式Spark的组件与架构
在图2.1中，Spark Driver是实际发起Spark作业的机器，SparkContext是Spark的主入口点，它负责连接到集群管理器，并在集群中运行任务，同时它还负责创建Spark的分布式数据集。如你所见，在Spark集群中的两个工作节点只为仅有的一个目的：它们是专门运行Spark任务的机器，仅此而已。
我们在第1章学到，Mesos提供了一种优秀方法来在一个集群上运行多个应用，在一个工作节点上启动多个任务。你能使用Mesos实现跨多个应用的资源共享，而不是启动一个或者多个静态分区的Spark集群。让我们看看在Mesos上运行Spark是一个怎样的情形。2.1.2 Mesos上的Spark
虽然启动Spark来使用一个独立集群并不是什么问题，但考虑一下多个团队需要他们自己的Spark集群，或者考虑更深一层，在数据中心内要有多个静态的分区集群。
如果你在物理机器上部署这些静态集群，显然你投入了一定数量的成本在工作负载上，而这些负载是没有办法实现资源共享的。同样的，如果你在IaaS云端启动一个静态的分区集群，如亚马逊AWS云上，你很可能因为这些云端机器的空置而浪费金钱。不管你是在本地机房还是在云端，细粒度的资源共享可以帮助你提升资源利用率，从而提升整个数据中心的效率。
为了举例说明这点，让我们看一下图2.2，你有两个独立集群服务于两个应用：Spark（数据处理的例子在这一点上）和Jenkins，一个流行的开源持续集成framework。Jenkins的使用在这个例子中并不是特别重要，重要的是，它的一些其他应用程序需要在多个服务器上运行。图2.2 形象化两个静态的分区或者固定的集群
如图2.2所示，你有两个静态的分区集群，一个是Spark，另一个则是Jenkins，每一个集群包括它自己的集群管理器（Spark master和Jenkins master）和两个工作节点来启动或构建任务。你也能够清晰地看到静态分区（或称为资源储藏室，如果你愿意的话）中两台服务器出现异常，这样就没有任何办法在两个集群间共享计算机资源。但很可能这两个服务都不会同时将资源使用到100%的使用率，如果Spark集群在工作负载50%时就发现资源不足，而Jenkins集群只要50%的资源即满足负载需求，那么Spark可以通过从两台服务器变成三台服务器资源而受益。
现在，让我们考虑在一个类似于Mesos的通用集群管理器上运行这些应用，从而实现细粒度的资源共享，如图2.3所示，通过Mesos使用Linux cgroups技术将每一个framework的执行器进行了隔离，你可以在一个Mesos slave上共享计算资源并运行多个工作负载。因此，在大规模机器的现代数据中心内，跨机器间的资源共享将大幅提升资源利用率。
现在你已经花一些时间明白了Spark怎样使用Mesos作为其集群管理器，为什么使用类似于Mesos的通用集群管理器能通过实现资源共享来提升效能。让我们看看Spark是如何在Mesos集群上运行的，在我们进入到第3章介绍Mesos的安装与配置之前，这将让我们更好地明白Mesos是如何运行任务的。图2.3 Mesos为两个应用管理集群资源2.2 在Mesos上运行Spark job
本章之前讨论的独立模式Spark集群的架构，很可能与你期望的其他分布式系统一样：一个主调度器和一个或多个工作节点。图2.3示例说明了你如何使用Mesos来避免将你的数据中心静态划分为多个集群，你的工作负载需要一个单一的通用集群，而不是各自进行计算资源的申请。接下来让我们通过一个例子进行Mesos实践，来说明Mesos如何为类似于Spark的framework进行任务分发负载。
注意：本节是关于在Mesos上下文内运行的Spark，并不是Spark的入门知识。尽管我们展示了如何在Mesos上运行Spark作业，但你在此节并没有学到Spark在现实世界中如何使用数据处理作业。如果你对Spark的更多知识感兴趣，请参考Spark主页http://spark.apache.org和Spark in action一书。2.2.1 在集合中寻找素数
为了演示Spark是如何连接到Mesos集群、接受资源供给、启动执行器执行任务的，我们将使用一个简单的Spark作业。这个作业创建一个从1到100,000,000的整型数据集，之后使用Spark找到集合中的哪些整数是素数（素数是不等于1，只能被1和自己整除的整数）。
Spark将使用Mesos作为集群管理器来调度与分发任务到有效的计算资源节点上，而不是启动一个独立模式的Spark集群来运行作业。在Mesos集群中运行Spark之前，让我们先讨论下framework与Mesos集群交互过程中所发生的事件次序。图2.4展示了Spark注册成为Mesos的一个framework，接受从Mesos master过来的资源供给，最后在Mesos slave上启动任务。
在图2.4中发生了一系列事件，我们将在本章随后的内容中具体分析，现在最重要的是理解下面的流程：
➊ sparkcontext连接ZooKeeper，来确定Mesos master中的leader。
➋ sparkcontext作为一个framework，注册到Mesos master的leader中。
➌ sparkcontext从Mesos master的leader中接收资源供给，随后启动任务来执行数据处理操作。
从图2.4了解了这些事件及它们产生的顺序后，让我们花一些时间来启动Spark作业，观察集群中真实的输出内容。在我们启动一个Mesos集群并运行后（我们将在第3章介绍），开始安装Spark、运行相关的示例。图2.4 当Spark在Mesos上运行任务时产生的事件
提示：在Mesos上安装Spark的指引请参考 http://spark.apache.org/docs/latest/running-on-mesos.html。2.2.2 获取与打包代码
Spark job的示例代码作为本书的增补材料在GitHub和manning.com均有效，最简单的获取示例代码的方法是从Git仓库中克隆的：
接下来，你需要使用spark-submit命令行工具将Spark作业及其依赖的内容打包到一个Java归档文件（JAR）中，因为这个例子是用Scala语言编写的，所以你还需要有较新版本的Java开发环境库（JDK）及Scala安装在系统中。我们将这台服务器作为入门机器。
在一切都准备好后，使用sbt打包示例程序，它是Scala的构建工具，类似于Java社区的Maven、Ant。如果sbt在系统中没有安装，请在 www.scala-sbt.org/release/tutorial查找Linux、Mac OS X，以及Windows各平台的安装指引。
通过运行下面命令来进行打包：
$ sbt package
在打包完成之后，你可以将作业提交到Mesos集群中，虽然在本
试读结束[说明：试读内容隐藏了图片]