mesos

3 月，跳不动了？>>> 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

################## 1. 环境准备 ##################################### 1. 使用mesosphere的rpm源安装相关软件 rpm -Uvh http://repos.mesosphere.io/el/7/noarch/RPMS/mesosphere-el-repo-7-1.noarch.rpm yum -y install mesos marathon yum -y install mesosphere-zookeeper 2. 配置zookeeper touch /var/lib/zookeeper/myid echo 1 > /var/lib/zookeeper/myid # 机器在zk中ID为1 vi /etc/zookeeper/conf/zoo.cfg # 2888是主从监视等内部交换数据，3888为选举leader用的,clientPort表示客户端连接端口，一般为2181 server.1=192.168.1.110:2888:3888 3. 配置mesos主从部分 # 主mesos echo 192.168.1.110 | sudo tee /etc/mesos-master/ip cp /etc/mesos-master/ip /etc/mesos-master/hostname #

Mesos相关笔记 简介 Mesos是Apache下的开源分布式资源管理框架,它被称为是分布式系统的内核。 Mesos最初是由加州大学伯克利分校的AMPLab开发的,后在Twitter得到广泛使用。 组件 Mesos-master Mesos master,主要负责管理各个framework和slave,并将slave上的资源分配给各个framework Mesos-master是整个系统的核心,负责管理接入mesos的各个framework(由frameworks_manager管理)和slave(由slaves_manager管理),并将slave上的资源按照某种策略分配给framework(由独立插拔模块Allocator管理)。 Mesos-slave Mesos slave,负责管理本节点上的各个mesos-task,比如:为各个executor分配资源 Mesos-slave负责接收并执行来自mesos-master的命令、管理节点上的mesos-task,并为各个task分配资源。 mesos-slave将自己的资源量发送给mesos-master,由mesos-master中的Allocator模块决定将资源分配给哪个framework 当前考虑的资源有CPU和内存两种,也就是说,mesos-slave会将CPU个数和内存量发送给mesos-master

目前Apache Spark支持三种分布式部署方式，分别是standalone、spark on mesos 和 spark on YARN ，其中，第一种类似于MapReduce 1.0所采用的模式，内部实现了容错性和资源管理，后两种则是未来发展的趋势，部分容错性和资源管理交由统一的资源管理系统完成：让Spark运行在一个通用的资源管理系统之上，这样可以与其他计算框架，比如MapReduce，公用一个集群资源，最大的好处是降低运维成本和提高资源利用率（资源按需分配）。本文将介绍这三种部署方式，并比较其优缺点。 standalone模式 ，即独立模式，自带完整的服务，可单独部署到一个集群中，无需依赖任何其他资源管理系统。从一定程度上说，该模式是其他两种的基础。借鉴Spark开发模式，我们可以得到一种开发新型计算框架的一般思路：先设计出它的standalone模式，为了快速开发，起初不需要考虑服务（比如master/slave）的容错性，之后再开发相应的wrapper，将stanlone模式下的服务原封不动的部署到资源管理系统yarn或者mesos上，由资源管理系统负责服务本身的容错。目前Spark在standalone模式下是没有任何单点故障问题的，这是借助zookeeper实现的，思想类似于Hbase master单点故障解决方案。将Spark

Spark运行模式简介 注：重点是Standalone模式，然后是YARNcluster和YARN client模式。 1. Standalone模式 即独立模式，自带完整的服务，可单独部署到一个集群中，无需依赖任何其他资源管理系统 。从一定程度上说， 该模式是其他两种的基础 。借鉴Spark开发模式，我们可以得到一种开发新型计算框架的一般思路：先设计出它的standalone模式，为了快速开发，起初不需要考虑服务（比如master/slave）的容错性，之后再开发相应的wrapper，将standalone模式下的服务原封不动的部署到资源管理系统yarn或者mesos上，由资源管理系统负责服务本身的容错。目前Spark在standalone模式下是没有任何单点故障问题的，这是借助zookeeper实现的，思想类似于Hbase master单点故障解决方案。将Spark standalone与MapReduce比较，会发现它们两个在架构上是完全一致的： 　　1) 都是由master/slaves服务组成的，且起初master均存在单点故障，后来均通过zookeeper解决； 　　2) 各个节点上的资源被抽象成粗粒度的slot，有多少slot就能同时运行多少task。不同的是， MapReduce将slot分为map slot和reduce slot，它们分别只能供Map

本文由 网易云 发布。 作者：刘超，网易云首席解决方案架构师 最近总在思考，为什么在支撑容器平台和微服务的竞争中，Kubernetes 会取得最终的胜出，事实上从很多角度出发三大容器平台从功能方面来看，最后简直是一摸一样。（可参考 《容器平台选型的十大模式：Docker、DC/OS、K8S 谁与当先？》 ） 经过一段时间的思索，以及采访了从早期就开始实践 Kubernetes 的 网易云 架构师们后，我把反思所得总结为今天的这篇文章。 一、从企业上云的三大架构看容器平台的三种视角 如图所示，企业上云的三大架构为 IT 架构、应用架构和数据架构，在不同的公司，不同的人、不同的角色，关注的重点不同。 对大部分的企业来讲，上云的诉求是从 IT 部门发起的，发起人往往是运维部门，他们关注计算、网络、存储，试图通过云计算服务来减轻 CAPEX 和 OPEX。 有的公司有 ToC 的业务，因而累积了大量的用户数据，公司的运营需要通过这部分数据进行大数据分析和数字化运营，因而在这些企业里面往往还需要关注数据架构。 从事互联网应用的企业，往往首先关注的是应用架构，是否能够满足终端客户的需求，带给客户良好的用户体验。业务量上往往会有短期内出现爆炸式增长的现象，因而关注高并发应用架构，并希望这个架构可以快速迭代，从而抢占风口。 在容器出现之前，这三种架构往往通过虚拟机云平台的方式解决。当容器出现之后