Mesos在去哪儿网的应用

Mesos在Qunar DevOps团队内部的应用。

平台介绍

咱们是在今年的5月份开始调研并尝试使用Mesos，第一个试点就是咱们的日志平台，咱们将日志分析所有托管在Mesos平台上。日志平台面向业务线开发、测试、运营人员，方便定位、追溯线上问题和运营报表。

这个是咱们平台的结构概览。

日志分析咱们使用ELK（Elasticsearch、Logstash、Kibana），这三个应该说是目前很是常见的工具了。并且方案成熟， 文档丰富，社区活跃（以上几点能够做为开源选型的重要参考点）。稍微定制了下Kibana和Logstash，主要是为了接入公司的监控和认证体系。

日志的入口有不少，如kernel、mail、cron、dmesg等日志经过rsyslog收集。业务日志经过flume收集，容器日志则使用mozilla的heka和fluentd收集。

这里稍稍给heka和fluentd打个广告，二者配合收集Mesos平台内的容器日志很是方便，能够直接利用MESOS_TASK_ID区分容器（此环境变量由Mesos启动容器时注入）。并且咱们也有打算用heka替换logstash。

Mesos技术栈

下面主要分享一下Mesos这块，咱们使用了两个框架：Marathon和Chronos，另外本身开发了一个监控框架Universe。

先说Marathon，eventSubscriptions是个好功能，经过它的httpcallback能够有不少玩法，群里常常提到的bamboo就是利用这个功能作的。利用好这个功能，作容器监控就很是简单了。

接着是Marathon的重启（更新），推荐设置一下minimumHealthCapacity，这样能够减小重启（更新）时的资源占用，防止同时PUT多个应用时耗光集群资源。

服务发现，Marathon提供了servicerouter.py导出haproxy配置，或者是bamboo，可是咱们如今没有使用这两个。 而是按协议分红了两部分，HTTP协议的服务是使用OpenResty开发了一个插件，动态加载Marathon（Mesos）内的应用信息，外部访问的 时候proxy_pass到Mesos集群内的一个应用，支持upstream的配置。

非HTTP的应用，好比集群内部的statsd的UDP消息，咱们就直接用Mesos DNS + 固定端口来作了。随即端口的应用依赖entrypoint拉取域名+端口动态替换。

带有UNIQUE attribute的应用，官方目前还没法作到自动扩容，从咱们的使用状况来看，基于UNIQUE方式发布的应用所有是基础服务，好比statsd、 heka（收集本机的Docker日志）、cAdvisor（监控容器）等，集群新加机器的时候Marathon不会自动scale UNIQUE实例的数量，这块功能社区正在考虑加进去。咱们本身写了一个daemon，专门用来监控UNIQUE的服务，发现有新机器就自动scale， 省的本身上去点了。

另一个问题，资源碎片化，Marathon只是个框架，关注点也不在这里。Mesos的UI里虽然有统计，可是很难反应真实的状况，因而咱们就本身写了 一个Mesos的框架，专门来计算资源碎片和真实的余量，模拟发布状况，这样咱们发布新应用或者扩容的时候，就知道集群内真实的资源余量可否支持本次发 布，这些数据会抄送一份给咱们的监控/报警系统。Chronos咱们主要是跑一些定时清理和监控的脚本。

Docker这块，咱们没有作什么改动，网络都使用host模式。Docker的监控和日志上面也提到了，咱们用的是cAdvisor和heka，很好很强大，美中不足的是cAdvisor接入咱们本身的监控系统要作定制。

咱们也捣鼓了一个Docker SSH Proxy，多是咱们更习惯用虚拟机的缘故吧，有时候仍是喜欢进入到容器里去干点啥的（其实业务线对这个需求更强烈），就是第一张图里的 octopus，模拟docker exec -it的工做原理，对接Mesos和Marathon抓取容器信息。这样开发人员在本身机器上就能SSH到容器内部debug了，也省去了申请机器帐号的 时间了。

应用方案

接着说说咱们的日志平台。这个平台的日志解析部分所有跑在Mesos上，平台自身与业务线整合度比较深，对接了一些内部系统，主要是为了考虑兼容性和业务线资源复用的问题，我尽可能省略与内部系统关联的部分，毕竟这块不是通用性的。

平台目前跑了有600+的容器，网络是Docker自带的host模式，天天给业务线处理51亿+日志，延时控制在60～100ms之内。

最早遇到的问题是镜像，是把镜像作成代码库，仍是一个运行环境？或者更极端点，作一个通用的base image？结合Logstash、heka、statsd等应用特色后，咱们发现运行环境更适合，这些应用变化最大的常常是配置文件。因此咱们先剥离配 置文件到GitLab，版本控制交给GitLab，镜像启动后再根据tag拉取。

另外，Logstash的监控比较少，能用的也就一个metrics filter，写Ruby代码调试不太方便。索性就直接改了Logstash源码，加了一些监控项进去，主要是监控两个Queue的状态，顺便也监控了下EPS和解析延时。

Kafka的partition lag统计跑在了Chronos上，配合咱们每一个机房专门用来引流的Logstash，监控业务线日志的流量变得轻松多了。

容器监控最开始是本身开发的，从Mesos的接口里获取的数据，后来发现hostname：UNIQUE的应用Mesos常常取不到数据，就转而使用 cAdvisor了，对于Mesos/Marathon发布的应用，cAdvisor须要经过libcontainer读取容器的config.json 文件，获取ENV列表，拿到MESOS_TASK_ID和MARATHON_APP_ID，根据这两个值作聚合后再发到statsd里（上面提到的定制思 路）。

发布这块咱们围绕这Jenkins作了一个串接。业务线的开发同窗写filter并提交到GitLab，打tag就发布了。发布的时候会根据集群 规划替换input和output，并验证配置，发布到线上。本地也提供了一个sandbox，模拟线上的环境给开发人员debug本身的filter 用。

同时发布过程当中咱们还会作一些小动做，好比Kibana索引的自动建立，Dashboard的导入导出，尽最大可能减小业务线配置Kibana的时间。每 个应用都会启动独立的Kibana实例，这样不一样业务线间的ACL也省略了，简单粗暴，方便管理。没人使用的时候自动回收Kibana容器，有访问了再重 新发一个。

除了ELK，咱们也在尝试Storm on Mesos，感受这个坑还挺多的，正在努力的趟坑中。扫清后再与你们一块儿交流。

今天的内容就到这里，感谢你们。

Q&A

Q：Mesos和Yarn的区别在哪里？

A：Mesos的主要目标就是去帮助管理不一样框架（或者应用栈）间的集群资源。好比说，有一个业务须要在同一个物理集群上同时运 行Hadoop，Storm及Spark。这种状况下，现有的调度器是没法完成跨框架间的如此细粒度的资源共享的。Hadoop的YARN调度器是一个中 央调度器，它能够容许多个框架运行在一个集群里。可是，要使用框架特定的算法或者调度策略的话就变得很难了，由于多个框架间只有一种调度算法。好比 说，MPI使用的是组调度算法，而Spark用的是延迟调度。它们两个同时运行在一个集群上会致使供求关系的冲突。还有一个办法就是将集群物理拆分红多个 小的集群，而后将不一样的框架独立地运行在这些小集群上。再有一个方法就是为每一个框架分配一组虚拟机。正如Regola和Ducom所说的，虚拟化被认为是 一个性能瓶颈，尤为是在高性能计算（HPC）系统中。这正是Mesos适合的场景——它容许用户跨框架来管理集群资源。


Mesos是一个双层调度器。在第一层中，Mesos将必定的资源提供（以容器的形式）给对应的框架。框架在第二层接收到资源后，会运行本身 的调度算法来将任务分配到Mesos所提供的这些资源上。和Hadoop YARN的这种中央调度器相比，或许它在集群资源使用方面并非那么高效。可是它带来了灵活性——好比说，多个框架实例能够运行在一个集群里。这是现有的 这些调度器都没法实现的。就算是Hadoop YARN也只是尽可能争取在同一个集群上支持相似MPI这样的第三方框架而已。更重要的是，随着新框架的诞生，好比说Samza最近就被LinkedIn开 源出来了——有了Mesos这些新框架能够试验性地部署到现有的集群上，和其它的框架和平共处。

Q：基础架构里面，数据持久化怎么作的？使用是么架构的存储？

A：持久化剥离在集群外部，Mesos 0.23提供了持久化的支持，可是没敢上到生产环境中。

Q：Storm on Mesos，快可用了吗？是否跟Spark on Mesos作过比较？

A：Storm on Mesos的代码在GitHub能够找到，说实话只是基础功能，许多资源的控制和attributes的东西都没有作，并且咱们的测试发现storm on mesos的消息ack特别慢。不建议直接拿来就跑。

Q：发布用的业务镜像是怎么制做的，平台有相关功能支持吗？仍是用户手工作好上传？

A：Jenkins build的镜像，能够用Jenkins on Mesos这个框架，安装Docker和mesos插件就能够开始用了。

Q：作这么个平台用多大规模的团队开发的？用了多久？

A：开始2我的，最多的时候5我的，如今保持在4我的。从5月份到如今一点一点测试，扩容慢慢堆出来的。

Q：镜像存储单机应该是不行的，大家是怎么管理镜像的？

A：镜像放swift里了。

Q：Docker采用host方式，是什么考虑或者限制，效果怎么样？

A：平台自己就是大吞吐量的，bridge模式性能测试都偏低，就选择了host模式跑了。

Q：Mesos的调度算法是怎样的？有没有作容器的高可用？

A：双层调度，底层offer一个资源列表给framework，framework根据CPU和内存去列表中过滤，选中合适的slave部署，framework层的调度能够随意实现。Marathon已经帮忙作了高可用。

Q：使用效果如何？600容器部在多少台机器上，CPU和内存使用率多少？有什么提高资源使用率的策略吗？

A：效果达到预想了，600台分部在了混合集群上，有VM和实体机，所有折算的话大概30台左右吧，目前资源还有富余，主要是预留buffer。不推荐跑虚拟机，Mesos的资源分配就是一刀切，即便没用也算的，因此虚拟机利用率会很低。

Q：mesos在哪一层面实施了paxos投票？

A：leader的选举，mesos实际上是两套选举，即便zk挂了mesos master也能够本身选举leader。

Q：为何选择heka，而不是fluend，而后logstash有什么问题？

A：fluent和heka咱们都在用，都是收容器日志，heka能够从容器的ENV里读更多东西出来。换logstash主要看重了heka的监控，资源占用和处理速度。

Q：会涉及数据卷的迁移吗，有什么好解决方案？

A：目前平台里没有持久化的东西。这块不敢说用什么合适，咱们也没开始尝试。

Q：镜像作成代码库和运行环境具体是什么意思，为何运行环境方式合适？

A：镜像具体作成什么样要根据本身的应用来判断，咱们用的logstash、statsd什么的，都是配置文件描述流程的，因此咱们选择了运行环境的方式。

Q：镜方式像作成代码库和运行环境具体是什么意思？

A：代码库就是说你把你工程的代码，配置什么的都所有打成一个镜像。 运行环境就是有一些bin或者Java、PHP这些工具的，启动后才下载代码，配置。

Q：大家会不会遇到跨机房的MesOS问题啊，若是跨机房，怎么办？

A：有跨机房的状况，咱们机房间有logstash专门转发日志流量，统一管控。

Q：好比数据库初始化的脚本，作在镜像里合适仍是有其余方式比较好？

A：db的数据文件其实挺难脱离外层的应用单独说的，由于有业务线代码引发的schema变动，最好先解决db ci的问题，而后再考虑数据什么时候加载，能够映射上对应schema的时候，db文件能够先从swift等共享存储直接下载到本地使用，或者用脚本从新初始 化也能够，咱们的快速rebuild环境正在试验。业务线还不敢这么来。

Q：用运行环境方式，容器启动后再拉代码和配置，不符合Docker设计镜像的初衷吧，怎么作到一处打包处处运行，镜像不是完整可执行的？

A：主要是代码库版本和镜像的tag如何映射，为了简单点能够考虑启动后下载代码，若是代码已经编译好放到了共享存储里直接下载代码包也能够。咱们目前没有考虑过把代码库版本和镜像tag映射这个问题。

Q：Mesos资源统计会出现与实际不符，大家的解决思路是什么？

A：要看是什么资源了，Mesos的划资源的格子属于一刀切的方式，即便你没用满也会被纳入已使用的资源里，若是从这个角度看， 实际运行的资源和Mesos内上报的资源确实不一致，可是考虑到计算资源的周期性，突发性，仍是推荐以Mesos上报的资源为准。咱们本身跑在Mesos 上的监控framework自己也是这么作的。

Q：cAdvisor好像只能监控单机容器状况，那对于集群的容器监控，使用ca怎么处理呢？

A：咱们目前是cAdvisor聚合好之后发给咱们的公司的监控平台，由监控平台统一处理。最新版已经merge了许多storage-driver了，statsd值得试一下。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上内容根据2015年9月15日晚微信群分享内容整理。分享人 徐磊，现任职于去哪儿网OpsDev团队，曾任职于红帽HSS部门。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同窗加微信：liyingjiesx，进群参与，您有想听的话题能够给咱们留言。 来自：http://dockone.io/article/675