Mesos资源调度与管理的深入分享与交流

starksummer 2016-10-26

周伟涛:基于Mesos的集群调度与管理(实录)

大家好,这里首先跟大家聊一些分布式系统的知识,然后说些我们搭建的Spark平台。分布式系统的原则: 可伸缩性, 没有单点失效, 高可靠性,数据本地性。 这是很常见的分布式系统的基本原则。这个大家可以参考王总以前的一篇 CSDN文章

我们公司内部搭建了一套基于Spark、Mesos、Hue、HDFS 等开源技术的多租户,高可用的集群环境。大致的架构是这样的, 用户可以一键将Docker化的Zeppelin利用Marathon发布到Mesos集群,发布成功后,Zeppelin将自动注册成为Mesos集群的Scheduler,自由地使用Mesos集群的资源;然后用户就可以使用zeppelin 页面使用 spark进行数据计算。另外,数据是存储在HDFS中的,Mesos上的Spark与HDFS进行了绑定,Spark会无缝使用HDFS中的数据。同时我们在HDFS层对多租户的数据进行了权限设置,保证用户之间的数据是不可见的。这个功能是对Hue进行hack实现的。在新用户创建时强制改变HDFS的umask。简单介绍几个工具:

1. Zeppelin是Apache正在孵化的一个Spark Notebook,在数据可视化方面方面做了很多工作。它对spark-SQL,R,Scala等语言都有支持,代码高亮等。 有与Mesos通信的接口。另外,我们team内部对Zeppelin做了些定制来使用它的ssl功能,并保证在我们集群对公网的服务发现。

2. Marathon,是Mesos的一个比较通用的scheduler,支持实例的横向扩展、rolling update、failover等,这样就保证了Zeppelin的高可用,同时它自身也可以通过zookeeper保证高可用。

3. Hue,是很常见的Hadoop工具大杂烩,这里就不多介绍了。

4. Mesos,其最大的好处是能够对分布式集群做细粒度资源分配,这里我会多介绍一些。贴一些王总总结的内容。

Mesos最大的好处是能够对分布式集群做细粒度资源分配。如下图所示,左边是粗粒的资源分配,右边是细粒的资源分配。

Mesos资源调度与管理的深入分享与交流

左边有三个集群,每个集群3台服务器,分别装3种分布式计算平台,比如上面装3台Hadoop,中间3台是Spark,下面3台是Storm,3个不同的框架分别进行管理。右边是Mesos集群统一管理9台服务器,所有来自Spark、Hadoop或Storm的任务都在9台服务器上混合运行。Mesos首先提高了资源冗余率。粗粒资源管理肯定带来一定的浪费,细粒的资源提高资源管理能力。

Hadoop机器很清闲,Spark没有安装,但Mesos可以只要任何一个调度马上响应。最后一个还有数据稳定性,因为所有9台都被Mesos统一管理,假如说装的Hadoop,Mesos会集群调度。这个计算资源都不共享,存储之间也不好共享。如果这上面跑了Spark做网络数据迁移,显然很影响速度。然后资源分配的方法就是resource offers,是在窗口的可调度的资源自己去选,Mesos是Spark或者是Hadoop等等。

这种方法,Mesos的分配逻辑就很简单,只要不停地报告哪些是可用资源就可以了。Mesos资源分配方法也有一个潜在的缺点,就是无中心化的分配方式,所以有可能不会带来全局最优的方式。但这个数据资源缺点对目前来讲并不是很严重。现在一个计算中心资源贡献率很难达到50%,绝大部分计算中心都是很闲的状态。下面具体举例说明怎么用Mesos资源分配。

Mesos资源调度与管理的深入分享与交流

如图所示,中间是Mesos Master,下面是Mesos Slave,上面是Spark和Hadoop运行在Mesos之上。Mesos Master把可用资源报告给Spark或Hadoop。假定Hadoop有一个任务想运行,Hadoop从Mesos Master上报的可用资源中选择某个Mesos Slave节点,然后这个任务就会在这个Mesos Slave节点上执行,这是任务完成一次资源分配,接下来Mesos Master继续进行资源分配。我们在搭建这个平台时面临的挑战有很多,这里挑几个主要的跟大家分享下:

1. 为了保证多租户的feature,需要打通Hue,HDFS,Mesos集群之间的账号。我们首先开发了一个提供oauth验证的账号中心,同时为Mesos集群搭建了LDAP,账号中心的账号与LDAP中的账户一一map,而Hue的账户是需要使用账号中心的oauth认证的,同时使用过Hue的同学应该清楚,Hue新用户登录时会自动创建HDFS目录,这样,HDFS,Mesos间的账号打通了。同时marathon支持按不同的用户部署实例,这样,不同的用户部署自己的zeppelin,启动自己的spark driver,访问自己的HDFS数据,全线贯通。

2. 其实我们前期是选择使用spark-notebook(scala play + highchart)来作为我们的spark web IDE的,但是,spark-notebook的一些状况与我们的需求不符,原因是notebook代码混乱,社区不活跃,spark-notebook是用scala play框架开发的,自己编译调试也挺费劲,同时spark-notebook是多租户,但是其多租户安全性不够,只能够满足团队内部的多租户,不符合我们的需求;而且,spark-notebook 的账号集成很难打通。而zeppelin是apache在孵化的项目,代码架构优雅(java+angularjs),单用户,我们为不同的用户启用不同的zeppelin,UI perfect。

3. Mesos集群资源混用的问题。我们的Mesos集群不仅运行spark这种无状态任务,也在运行着很多web服务等,但是Mesos不支持抢占,无法设置任务优先级,而spark默认是贪婪模式,这样就会出现spark运行时无法发布其他web任务到mesos集群上的情况。当前的解决方案是将Mesos集群静态划分,限制spark的运行范围。

4. 数据传输的网络资源问题。当前生产环境上的HDFS是架设在Mesos集群外的,但是spark与HDFS的数据传输量非常大,这就导致了Mesos集群的网络压力不可控。网络资源紧张。目前也没有太好的solution。team正在评估将HDFS集成到Mesos集群(非常困难)。

5. spark运行时的文件碎片。spark shuffle会在slave机器上产生大量的文件碎片,如果slave配置不够,就会直接导致机器inode 100%。为了提高文件系统性能,你需要修改你的spark config,将spark.shuffle.consolidateFiles设置为true。

6. spark在mesos上的资源占用有两种模式fine(细粒度)和coarse(粗粒度)。其中fine是default模式,按官方给出的文档,fine模式会提高资源利用率,但是在实际使用中我们发现,fine模式下,mesos集群有资源,spark仍然报资源不足,运行失败。而这时候改为coarse模式,问题就会消失。很古怪。

7. HDFS横向扩展问题。HDFS数据量上来之后,一个不可回避的问题就是加数据节点。由于我们崇尚小机器,多节点。HDFS节点配置都是2核2G,甚至一些是1核的,这在增加节点后的数据balance时就出现了HDFS name node被击垮的问题,内存不足。目前我们的解决方法是临时增加namenode的资源,在balance之后再把资源降下来。

8. 还有一个教训就是HDFS的datanode数据盘还是大一点比较好,好像HDFS对异构的datanode进行balance时,效果很差,数据根本没有推平。不知道别人有没有遇到这个问题。

QA——选集(篇幅做不到所有)

Q:Mesos在国内的生产环境部署情况如何,只局限于Spark。

王璞:Mesos在国内的企业用户还不少,爱奇艺、IBM、Intel等等都在用,其中爱奇艺的Mesos集群规模不小,他们最大的一个Mesos集群有400个节点左右,主要用于视频转码。

Q:Mesos设计的最大好处是可以提高资源利用率,业务扩展所容很高效,那能否兼容目前已有的服务呢?比如nginx、mysql、tomcat等?

周伟涛:无状态的比较好集成, nginx,tomcat。

Q:Mesos中部署无状态的服务,是使用Docker作为容器运行的吧?那是否只要Docker内可以解决的问题,都可以部署在Mesos中?

王璞:Mesos上运行nginx、tomcat这类web service应用没问题,我们一般把nginx或tomcat放到Docker里,然后由mesos调度运行。但是mysql这类有状态的存储类应用,目前mesos还支持得不好,Twitter刚开源了Mysos项目,把mysql跑在mesos上。

周伟涛:可以不用docker,mesos自身也有容器,cgroup隔离,都可以。

Q:目前mesos主要的应用场景有哪些?除了Jenkins。

周伟涛:Spark + Mesos; docker + mesos;saas or cass on mesos。

Q:zeppelin的使用有没有遇到扩展性的问题,我记得它是共享同一个sparkcontext?

周伟涛:有,我们是一个用户一个zeppelin。不是共享,这也是我们放弃spark-notebook的原因之一。

Q:YARN和Mesos有没有比较好的文章介绍它们之间的优劣的?

周伟涛:Mesos vs. YARN

  • Mesos只负责offer资源给framework,而Yarn自己来分配资源。
  • Yarn局限在Hadoop上了,没法作为别的机器管理。
  • Mesos管理CPU,Memory,Disk;而Yarn只管理Memory和CPU。
  • Mesos用lxc隔离,Yarn用进程(性能可能更好)。

Q:最近准备搭建分布式计算集群,请问自己搭建spark集群和直接使用数人的产品之间需要克服的困难有哪些呢?

周伟涛:自己搭建你需要读很多文档进行配置,然后,生产环境调优经验是关键。勤快人完全可以自己来。

王璞:用Mesos的好处是,部署Mesos以后,再跑Spark或Hadoop MapReduce的时候,就不需要部署Spark和Hadoop了,直接在Mesos上运行Spark或Hadoop任务。

Q:请问mesos和hdfs结合的难点在什么地方?

周伟涛:1. mesos不支持数据持久化;2. 网络隔离;3. 账户集成。

Q:方便说下hue集成ldap的详细么?我们也在考虑,rbac的调度。

周伟涛:hue的账户使用oauth验证,开发一个账号中心,账号中心同步LDAP账户。在详细的架构实现还真一言难尽啦。

Q:请问Yarn和mesos主要差别在哪里,为什么用mesos的很多,而用yarn的不多呢?

王璞:从功能上讲YARN和Mesos相似,只是Mesos更通用,可以支持在线和离线任务。一般YARN用于调度离线任务。

Q:关于spark-notebook与zeppelin,哪个更为看好?

周伟涛:我们前期跟了下spark-notebook社区,感觉只有andy一个人在搞,代码真心乱,版本控制有点儿差。zeppelin目前比较新,功能少,但是是apache孵化。

Q:是否有比较过有比较过ipython notebook和其他两个?

周伟涛:我比较过,前期也是受ipython notebook启发,才用spark notebook的,ipython notebook 配Pandas在数据可视化上也是不错的选择。

王璞:Zepplin和Spark notebook比起来,可能Zepplin更有希望吧,毕竟是Apache孵化的项目。

Q:mesos中的任务不存在抢占,没有优先级,如何实现服务自动扩容缩容呢?或者服务降级?

王璞:Twitter的Aurora支持任务优先级、任务抢占。

Q:服务所需使用的资源配置会受制于slave节点的配置吗?因为都是尽量使用低配的主机,如2核4G的,那如果服务需要更多资源,就需要人工评估资源使用率,从而决定启动多少个task吗?

http://www.csdn.net/article/2015-07-10/2825180

相关推荐