后使用快捷导航没有帐号？
YARN & Mesos，论集群资源管理所面临的挑战
在国内，大部分的Spark用户都是由Hadoop过渡而来，因此YARN也成了大多Spark应用的底层资源调度保障。而随着Spark应用的逐渐加深，各种问题也随之暴露出来，比如资源调度的粒度问题。为此，7月2日晚，在CSDN & &Spark高端微信群中，一场基于YARN和Mesos的讨论被拉开，主要参与分享的嘉宾包括TalkingData研发副总裁阎志涛，GrowingIO田毅，AdMaster技术副总裁卢亿雷，Spark & &Committer、Mesos/Hadoop Contributor夏俊鸾，下面一起回顾。阎志涛——YARN和Hadoop捆绑以及资源分配粒度问题这里好多老朋友了，这里主要说说Spark on YARN的实践挑战。Talking Data最初引入Spark是2013年，当时主要的考虑是提高机器学习效率，于是在Spark&0.8.1的时候就引入了Spark，那个时候的环境是 Hadoop&CDH&4.3版本。最初用Spark就是跑一些基础的任务，其他任务还都是用MR+HIVE来完成。后来发现，对比Hadoop，Spark在开发和性能方面 确实具有明显优势，因此就开始将整个数据中心的计算全部迁移到了Spark平台。任务多了，而且需要并发的跑任务，因此就需要一个资源调度系 统。&CDH&4.3是支持YARN的，而Spark后边支持了YARN，因此比较自然地选择了YARN来做资源调度。具体做法是分不同的队列，通过对不同类型任务指定不同的队列，这样就可以并发执行不同的任务。结果遇到的第一个问题就是资源如何去划分？&多个队列的资源划分都是采用不同的资源百分比来实现。整个资源分配的粒度不够细，不过还可以用。&结果到了Spark&1.2的时候Spark就开始声明在后期大版本要废弃对YARN alpha的支持，而CDH&4.3的YARN就是alpha版本。于是到了Spark&1.3之后就面临了一个选择，后期所有的Spark版本必须自己修改去支持CDH&4.3，或者升级Hadoop到更新的版本 (CDH&5.x)，或者采用其他的资源调度方式。然而当下的Hadoop集群已有P级别的数据，带着数据升级是一个非常有风险的事情。于是我们开始考虑 用Mesos来做资源的调度和管理。我们的计划是CDH&4.3不升级，新的机器都用新的Hadoop版本，然后用Mesos来统一调度。另外，都引入 Tachyon作为缓存层，SSD作为shuffle的落地存储。如果用Mesos调度，我们对Hadoop版本的依赖就降低了。Hadoop升级风险有 点高。这算是我们遇到的最大的一个坑了。我这里关于YARN的吐槽就这么多，其余的使用Spark的坑，后边有机会再说吧。田毅——1.4.0中，Spark on YARN的classpath问题最近遇到了一个说大不大，说小不小的坑，大致情况是提交的spark&job遇到了各种各样的classpath问题——包括找不到class和不 同版本class冲突。尤其是升级到spark&1.4.0以后，在YARN上运行时经常遇到这个问题，今天主要是和大家分享一下 Spark&on&YARN环境下classpath的问题。总结了一下Spark在YARN上的class加载规则，供大家参考（以下内容针对 Spark1.4.0版本YARN&client模式）。Spark通过spark-submit向YARN集群提交job，在不修改spark相关启动脚本的情况下，下列因素决定了spark-submit提交的任务的classpath（可能有遗漏，请补充）。$SPARK_HOME/lib/datanucleus-*.jar&$SPARK_CLASSPATH&—driver-class-path&—jars&spark.executor.extraClassPath&spark.driver.extraClassPath这是个非常麻烦的问题，Spark做了这么多的配置方式，各个版本加载机制也不太一样，使用起来非常头疼，具体来看看spark-submit命令的执行机制：bin/spark-submit执行bin/spark-class执行bin/load-spark-env.sh执行conf/spark-env.sh执行java&-cp&…&org.apache.spark.launcher.Main生成Driver端的启动命令其中第5步是最近才改过来的，之前这一步是在shell里面实现的，这一改，想了解实现逻辑就只能看scala源码，对于部分开发者又变成了黑 盒……想了解详细过程的同学可以在spark-class命令里面加上set&-x，通过观看 org.apache.spark.launcher.Main的代码，可以得到Driver端classpath的加载顺序：-&$SPARK_CLASSPATH(废弃，不推荐）& & &-&配置—driver-class-path&or&spark.driver.extraClassPath & &-&$SPARK_HOME/conf& & &-&$SPARK_HOME/lib/spark-assembly-xxx-hadoopxxx.jar& & &-&$SPARK_HOME/lib/datanucleus-*.jar& & &-&$HADOOP_CONF_DIR& & &-&$YARN_CONF_& & &-&$SPARK_DIST_CLASSPATHDIRExecutor的class加载远比Driver端要复杂，我这里不详细说了，有兴趣的同学可以去看看spark-yarn模块的代码。Executor端classpath加载顺序：- spark.executor.extraClassPath& & &- $SPARK_HOME/lib/spark-assembly-xxx-hadoopxxx.jar& & &- $HADOOP_CONF_DIR& & &- `hadoop classpath`& & &- —jars这里特别需要注意加载顺序，错误的顺序经常会导致包裹在不同jar包中的不同版本的class被加载，导致调用错误。了解了加载顺序以后，推荐大家配置classpath按照如下方式：对Driver端，使用—driver-class-path来完成driver端classpath的控制，足够满足需求；对于Executor 端，如果使用—jars命令的话，要注意和Hadoop中与spark-assembly的类冲突问题，如果需要优先加载，通过 spark.executor.extraClassPath方式进行配置。这里稍微说一句题外话，我们这两天尝试了phoenix的4.4.0版本，对 于Spark处理后的DataFrame数据可以非常的方便通过Phoenix加载到HBase。只需要一句话：hc.sql(sql)
.format("org.apache.phoenix.spark")
.mode(SaveMode.Overwrite)
.options(Map("table" -& "XXX\_TABLE", "zkUrl" -& (zookeeper))).save()卢亿雷——YARN的资源管理机制先看两张YARN资源管理的图，一个是RM的图，一个NodeManage的图：&& &&& &1.&多类型资源调度 ——主要采用DRF算法2. 提供多种资源调度器&：FIFO&Fair&SchedulerCapacity&Scheduler3. 多租户资源调度器：资源按比例分配、层级队列划分方式、以及资源抢占方式这里举一个遇到的坑：有一次发现RM不能分配资源，看集群状态都是正常的，CPU、内存、磁盘、带宽都比较低。但是任务分配非常慢，查了RM的日志好长时间后找到一个线索： 07:29:15,438 WARN org.apache.hadoop.ipc.Server: Large response size 3552406 for callorg.apache.hadoop.yarn.api.ApplicationClientProtocolPB.getApplications from 10.10.10.239:48535 Call#146914 Retry#0org.apache.hadoop.yarn.api.ApplicationClientProtocolPB.getApplications from 10.10.10.239:48535 Call#146914 Retry#0发现是org.apache.hadoop.yarn.api.ApplicationClientProtocolPB.get这个API由于在 定期取集群状态，而由于集群的历史状态太多，导致每次取出状态的时候返回值太大，导致RM出现阻塞了。所以建议大家在检测集群状态的时候需要特别留意是否 取值太大了。另外就是如果集群有任何的异常，建议一定要先看LOG，LOG基本上可以告诉我们所有的事情。接下来我简单介绍一下我们Hadoop应用的场 景：我们目前拥有由原来几十台机器到现在超过1500台的服务器集群，每天需要完成超过100亿的采集请求，每天有上千亿数据的离线、流式、实时分析和计算。所以对我们的集群非常有挑战。&& && &从这个架构图我们可以发现我们其实基本上用了整个Hadoop生态系统的很多技术和系统。大家一定会问我们为什么会把Flink和Spark一起用。在昨天发的Hadoop & & & &Summit 2015有一些简单介绍了。这里，先给大家透漏一下我们做的一个比较：是测试的K-Means，这个数据还是有一些吃惊的。&& & & && & & &Flink除了兼容性外，性能竟然要比Spark要高。具体的分析报告下周我会给大家分享的。夏俊鸾——Mesos特性和现状&& & & &其实，Mesos在国外用得比较多，国内不是太多。从目前Mesos官网上看，比较大的就是airbnb和yelp。Mesos在spark 0.8版本的时候就有了，和standalone差不多一起诞生，YARN差不多到1.0才可用。其实在Spark & & & & & &出来的时候Mesos远比YARN稳定，而且也是伯克利自己的东西，支持的力度很大。目前Spark里面Mesos和YARN都支持两种调度模式，client和cluster。其中Mesos还支持粗力度和细力度 两种模式，细力度的模式下，在提交task的时候直接跟mesos & & & & & & master通信，使得Spark作业和其他框架作业共享资源。当然也包括其它的Spark作业，资源不独占。但是这样方式的坏处就是调度 overhead比较大，不适合交互式作业。粗力度的调度方式其实和目前YARN是一样的，有利于低延迟的作业。两种模式的测试数据我有的，下次可以分享 一下。由于不在Hadoop的生态内，Mesos还是比较悲剧的。Q（CSDN用户）：Spark生成parquet格式一般建议每个parquet多大？&& & & &田毅：这个我的建议是别弄太大，数据(压缩前)最好别超过128M，这个数不是绝对的，要看你的列数和压缩比。阎志涛：我们的都在几百兆，parquet主要还是看你读取出多少列来。如果读出的列很多，性能就不一定好了。Q（CSDN用户）：千万数据的join或者reduce过程中总是有任务节点丢失的情况？&& & & &田毅：这个是经常出现的问题，最常见原因还是GC导致的长时间卡住，导致心跳超时。可以参考intel他们最近在summit上分享的GC调优方面的实践。GC问题在1.4版本中已经得到改善，比如大量数据查重。 & & & & & &&
免责声明：
除非特别声明，文章均为网络转载，仅代表作者观点，与大数据中国网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。如果本文内容有侵犯你的权益，请发送信息至ab12-，我们会及时删除
随着大数据技术的不断提高，大数据应用的不断普及
在今天召开的大连软交会上#2014软交会#，韩国科学
站长推荐 /1
站群： 大数据技术精英
站群： 职业数据分析师
期待您的加入，与大家一起共创大数据的未来！
大数据行业交流
大数据求职招聘
服务电话：
微信联系：hb-0310
服务邮箱：ab12-
官方微信扫一扫
版权所有： 上传我的文档
 下载
 收藏
免责声明：本站大部分文章出于提供更多信息与网友共享而转载文章，文章版权属于原创者。谢谢合作！本人大部分资料均来自网络，请注意保护知识产权，请您下载后勿作商用，只可学习交流使用。 本人如有侵犯作者权益，请作者联系本人删除.本人不承担任何法律责任。谢谢合作！
 下载此文档
正在努力加载中...
Native Docker Clustering with Swarm
下载积分：3500
内容提示：Native Docker Clustering with Swarm
文档格式：PDF|
浏览次数：8|
上传日期： 01:21:24|
文档星级：
全文阅读已结束，如果下载本文需要使用
 3500 积分
下载此文档
该用户还上传了这些文档
Native Docker Clustering with Swarm
关注微信公众号Apache Kafka
A Kafka cluster has a much higher throughput compared to other message brokers such as ActiveMQ/RabbitMQ.
Apache Kafka is an open-source stream processing platform developed by the Apache Software Foundation written in Scala and Java. The project aims to provide a unified, high-throughput, low-latency platform for handling real-time data feeds. Its storage layer is essentially a "massively scalable pub/sub message queue architected as a distributed transaction log," making it highly valuable for enterprise infrastructures to process streaming data. Additionally, Kafka connects to external systems (for data import/export) via Kafka Connect and provides Kafka Streams, a Java stream processing library. -
Kafka was created at LinkedIn to handle large volumes of event data. Like many other message brokers, it deals with publisher-consumer and queue semantics by grouping data into topics. As an application, you write to a topic and consume from a topic. An important distinction, or a shift in design with Kafka is that the complexity moves from producer to consumers, and it heavily uses the file system cache. These design decisions, coupled with it being distributed from scratch, makes it a winner in many high volume streaming use cases. -
Java install
Apache Kafka needs a Java runtime environment:
$ sudo apt-get install default-jre
Create a User : "kafka"
This is an optional section.
Let's create a user called "kafka" including home directory and add it to the sudo group so that it can install Kafka's dependencies:
$ sudo useradd -m kafka
$ sudo adduser kafka sudo
Install ZooKeeper
ZooKeeper coordinates and synchronizes configuration information of distributed nodes.
Kafka cluster depends on ZooKeeper to perform operations such as electing leaders and detecting failed nodes. In other words, Kafka brokers need it to form a cluster, and the topic configuration is stored in ZK nodes, etc. Note that newer versions of Kafka have decoupled the clients - consumers and producers - from having to communicate with ZooKeeper. In Kafka 0.9 and 0.10, offsets are stored in topics by default instead of in ZK. Either way, we still need ZooKeeper to run Kafka brokers.
Actually, once we install Kafka, we can use the ZooKeeper that comes with Kafka. But in this chapter, we'll use ZooKeeper package that's available in Ubuntu's default repositories.
$ sudo apt-get install zookeeperd
Now, ZooKeeper is installed, and it will be started as a daemon automatically.
ZK itself does not need much hand-holding once set up. We just have to make sure the instances are up and are monitored.
We can see it's listening on port 2181:
$ sudo netstat -nlpt | grep ':2181'
10462/java
Or we can check the 2181 port using telnet:
$ telnet 52.8.9.227 2181
Trying 52.8.9.227...
Connected to 52.8.9.227.
Escape character is '^]'.
We can see ZooKeeper is working and it responded back with "imok" to "ruok"!
The ZooKeeper directory structure looks like this:
We may start zookeeper in the following way:
$ sudo bin/zkServer.sh start
ZooKeeper JMX enabled by default
Using config: /etc/zookeeper/conf/zoo.cfg
Starting zookeeper ... STARTED
The usage of bin/zkServer.sh is like this:
$ bin/zkServer.sh {start|start-foreground|stop|restart|status|upgrade|print-cmd}
Apache Kafka is a scalable and fault-tolerant distributed message broker, and it can handle large volumes of real-time data efficiently. Compared to other message brokers such as RabbitMQ or ActiveMQ, it has a much higher throughput.
Kafka's pub/sub messaging system is probably the most widely used feature, however, we can also use it for log aggregation since it provides persistent storage for published messages.
Kafka has 5 components:
Topic: A topic is a category or feed name to which messages are published by the message producers. Topics are partitioned and each partition is represented by the ordered immutable sequence of messages. Each message in the partition is assigned a unique sequential ID (offset).
Broker: A Kafka cluster consists of servers where each one may have server processes (brokers). Topics are created within the context of broker processes.
Zookeeper: Zookeeper serves as the coordinator between the Kafka broker and consumers.
Producers: Producers publish data to the topics by choosing the appropriate partition within the topic.
Consumers: Consumers are the applications or processes that subscribe to topics and process the feed of published messages.
Install Kafka
Kafka is available from .
$ mkdir -p ~/kafka
$ cd kafka
$ wget http://www-us.apache.org/dist/kafka/0.10.2.0/kafka_2.10-0.10.2.0.tgz
Change directory to "kafka", and then extract the file with "--strip 1" option to extract files directly into the directory:
$ tar xvzf kafka_2.10-0.10.2.0.tgz --strip 1
The files in kafka directory look like this:
Kafka server configuration
To be able to delete topics, take off '#' from ~/kafka/config/server.properties:
# Switch to enable topic deletion or not, default value is false
delete.topic.enable=true
Start Kafka server (broker)
To start server, we ned to run kafka-server-start.sh
$ ~/kafka/bin/kafka-server-start.sh ~/kafka/config/server.properties
Now, we can check listening ports:
ZooKeeper : 2181
Kafka : 9092
$ netstat -nlpt
After starting Kafka Broker, type the command jps on a terminal and we would see the following response:
23057 QuorumPeerMain
23350 Kafka
As we can see from the output, now two daemons running on the terminal where QuorumPeerMain is ZooKeeper daemon and another one is Kafka daemon.
Stopping Kafka server (broker)
After performing all the operations, we can stop the server using the following command:
$ bin/kafka-server-stop.sh config/server.properties
Big Data & Hadoop Tutorials
AWS (Amazon Web Services)
Redis In-Memory Datastore
Powershell 4 Tutorial
Git/GitHub Tutorial
Subversion
Please enable JavaScript to view the
Ph.D. / Golden Gate Ave, San Francisco / Seoul National Univ / Carnegie Mellon / UC Berkeley / DevOps / Deep Learning / Visualization
Sponsor Open Source development activities and free contents for everyone.
Thank you.
Elasticsearch search engine, Logstash, and Kibana
DevOps / Sys Admin Q & A
AWS (Amazon Web Services)
Redis In-Memory Database
Git/GitHub Tutorial
Subversion
Powershell 4 Tutorial
DevOps / Sys Admin Q & A
AWS (Amazon Web Services)飞驰在Mesos的涡轮引擎上 - 简书
飞驰在Mesos的涡轮引擎上
回想起第一次接触Mesos, 当时有很多困惑: "这到底是用来做啥的？跟YARN比有什么优势？有哪些大公司在使用么?"。
然而现在技术日新月异地发展, Mesos这个生态圈也开始被越来越多的团队熟悉关注, 像k8s,Swarm之类的重量级竞品一个个地涌现。
在踩了或多或少的坑, 现在重新回到这个问题, 简而言之:
Q1: 这到底是用来做啥的?
通俗地讲, 就是把N台机器当做1台机器使用
Q2: 跟YARN比有什么优势？
更加通用, 不局限在数据分析领域
Q3: 有哪些大公司在使用么?
做技术预研的时候因为看到苹果在用, 心里倍儿踏实
Mesos在团队的变迁史
(一) 为Spark而Mesos
我们的分析团队一直都是在传统的CDH上跑Hadoop生态。对新业务评估时决定拥抱Spark, 但CDH升级困难, Spark版本滞后, 使用起来也远比Hadoop繁琐。最后我们决定基于Mesos从头构建新的数据分析基础环境。
但是Mesos上缺乏我们必须的HDFS和HBase。经过讨论我们决议了两种方案。
将HDFS,HBase和Mesos独立部署在裸机上, 如下图
前期方案一
(前期方案一)
但实际使用时会因为HDFS和HBase并非在Mesos的隔离环境下运行, 与Mesos会竞争系统资源。基于这样的考虑,我们否决了这种方案。
HDFS和HBase也运行在Mesos中。这种方案避免了上述问题, 但也意味着我们需要自己实现这两个服务在Mesos中的部署。团队的大神担起了这个任务, 制作了HDFS和HBase的Docker镜像,
通过marathon部署在Mesos中。
前期方案二
(前期方案二)
基于这样的部署形式, 团队顺利地过渡到Spark生态, 让我们的分析系统更加飞快地运转。
(二) 好马还需配好鞍, 这个鞍叫DC/OS
DC/OS可谓Mesos生态里的Cloudera。但由于其商业收费, 对于我们这样的初创团队一直都是"可远观而不可亵玩"。直到其开放了社区版, 我们才得以略窥一斑。
在没有引入DC/OS之前, 对于管理Mesos集群我们碰到以下几个痛点:
没有自动化运维脚本。新增、删除节点、变更配置均需要手工介入。
没有直观的可视化图表来查看各项运行指标。Mesos自带的界面相对比较简单,体验不佳。
没有集中的日志管理。
安装一些通用的服务比较繁琐。
通过DC/OS管理Mesos集群, 可以轻松地使用Bootstrap节点方便地管理各个节点, 其服务也都通过systemd来管理依赖, 避免了手工管理的繁琐。通过, 可以很方便地配置安装节点, 以下是范例:
agent_list:
- 10.10.11.48
- 10.10.11.29
- 10.10.11.56
- 10.10.10.188
- 10.10.11.57
- 10.10.11.88
- 10.10.11.89
- 10.10.10.113
- 10.10.10.168
# Use this bootstrap_url value unless you have moved the DC/OS installer assets.
bootstrap_url: file:///opt/dcos_install_tmp
cluster_name: maxleap
exhibitor_storage_backend: zookeeper
exhibitor_zk_hosts: 10.10.10.125:.10.149:.10.122:2181
exhibitor_zk_path: /dcos_uat
log_directory: /genconf/logs
master_discovery: static
master_list:
- 10.10.10.187
- 10.10.10.176
- 10.10.10.164
process_timeout: 600
resolvers:
- 10.10.10.156
ssh_key_path: /genconf/ssh_key
ssh_port: 22
ssh_user: root
oauth_enabled: 'false'
telemetry_enabled: 'false'
#roles: slave_public
#weights: slave_public=2
UI简洁易用, 比较常用的一些功能大多都已包含。通过使用Universe的包管理器, 我们可以很方便地一键安装各种常见服务。
(DC/OS图示)
DC/OS默认也给我们安装了mesos-dns, 我们可以使用DNS的A记录轮询来实现简陋的服务发现。通过marathon部署服务现在可以直接使用服务名.marathon.mesos直接定位服务所在节点。
在某些场合下这已经足够好用。Universe集成的HDFS也使用了DNS来定位各类型的节点, 这样带来的很大的方便就是像core-site.xml,hdfs-site.xml这样的配置文件就相对稳定(之前我们使用主机hostname来管理, 当节点发生变动时需要所有程序变更配置文件)。
接下来我们开始尝试改造之前的基础服务。
综上的几个优点, 我们将之前Spark的HDFS切换到Universe提供的版本, 这个版本的好处是其自己实现了一个Mesos的framework来实现HA, 其数据也使用了Mesos的持久化卷。美中不足的是其使用了mesos原生的隔离, 而没有使用docker, 鉴于国内的网络环境, 其下载速度惨不忍睹。为此我们搭建了Universe私服, 改写了所有的资源文件指向到内网, 加快了部署速度。官方的教程很详细, 这里是。
对于HBase, 我们也重新制作了docker镜像。以下是Dockerfile:
# 基于debian的oracle-jdk8
FROM 10.10.10.160:8010/zero/java:8
MAINTAINER wcai
HBASE_VERSION="1.2.1" \
HADOOP_VERSION="2.5.2" \
HBASE_HOME="/hbase" \
HADOOP_CONF_DIR="/etc/hadoop" \
JAVA_LIBRARY_PATH="/usr/lib/hadoop" \
HBASE_CLASSPATH="/etc/hadoop" \
HBASE_MANAGES_ZK="false"
apt-get update -y && \
apt-get install curl -y && \
mkdir -p /var/log/hbase && \
curl -o /tmp/hbase.tar.gz
/apache/hbase/${HBASE_VERSION}/hbase-${HBASE_VERSION}-bin.tar.gz && \
tar xvzf /tmp/hbase.tar.gz -C /tmp/ && \
rm -f /tmp/hbase.tar.gz && \
mv /tmp/hbase* ${HBASE_HOME} && \
rm -rf ${HBASE_HOME}/docs \
${HBASE_HOME}/bin/*.cmd \
${HBASE_HOME}/conf/*.cmd \
${HBASE_HOME}/*.txt && \
curl -o /tmp/hadoop.tar.gz /apache/hadoop/core/hadoop-${HADOOP_VERSION}/hadoop-${HADOOP_VERSION}.tar.gz && \
tar xvzf /tmp/hadoop.tar.gz -C /tmp && \
rm -f /tmp/hadoop.tar.gz && \
mv /tmp/hadoop* /tmp/hadoop && \
mv /tmp/hadoop/lib/native /usr/lib/hadoop && \
rm -rf /tmp/hadoop && \
mkdir -p ${HADOOP_CONF_DIR} && \
apt-get remove curl -y && \
apt-get clean && \
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
WORKDIR ${HBASE_HOME}
# 默认集成的hdfs配置, 也可通过marathon的uris挂载进去。
COPY ./conf/* /etc/hadoop/
ENTRYPOINT [ "bin/hbase" ]
HMaster的marathon配置范例:
"id": "/hbase/master",
"-Dhbase.master.port=6000",
"-.port=6010",
"-Dhbase.zookeeper.quorum=master.mesos",
"-Dzookeeper.znode.parent=/hbase",
"-Dhbase.rootdir=hdfs:///hbase",
"-Dhbase.cluster.distributed=true",
"instances": 1,
"cpus": 1,
"mem": 2048,
"container": {
"type": "DOCKER",
"docker": {
"image": "10.10.10.160:8010/zero/hbase:1.2.1",
"forcePullImage": true,
"network": "HOST"
HRegion的marathon配置范例:
"id": "/hbase/region",
"regionserver",
"-Dhbase.regionserver.port=6020",
"-.port=6021",
"-Dhbase.zookeeper.quorum=master.mesos",
"-Dzookeeper.znode.parent=/hbase",
"-Dhbase.rootdir=hdfs:///hbase",
"-Dhbase.cluster.distributed=true",
"instances": 4,
"constraints": [["hostname", "UNIQUE"]],
"cpus": 1,
"mem": 1024,
"container": {
"type": "DOCKER",
"docker": {
"image": "10.10.10.160:8010/zero/hbase:1.2.1",
"forcePullImage": true,
"network": "HOST"
以上仅为范例, 其他类型的实例也可类似启动, 如backup, thrift2, rest等, 在此略过。
另外可以进一步定制entrypoint, 启动的端口可以通过marathon管理的PORT?来定义。甚至可以让marathon给你随机安排端口。
虽然Universe自带了Spark的dispatcher服务,默认使用了dist-url的方式, 但我们想让Spark运行时全部在docker中。(老板~ 再来几串Dockerfile)
首先是mesos基础镜像
FROM 10.10.10.160:8010/zero/java:8
MAINTAINER wcai
# 0.28.0-2.0.16.debian81
# 0.28.1-2.0.20.debian81
# 0.28.2-2.0.27.debian81
MESOS_PACKAGE_VERSION="0.28.1-2.0.20.debian81" \
MESOS_NATIVE_LIBRARY="/usr/lib/libmesos.so" \
MESOS_NATIVE_JAVA_LIBRARY="/usr/lib/libmesos.so"
# 顺带把hdfs的native-lib也集成进去
COPY lib/* /usr/lib/
apt-key adv --keyserver hkp://:80 --recv E56151BF && \
echo "deb /debian jessie main" | tee /etc/apt/sources.list.d/mesosphere.list && \
apt-get update && \
apt-get install --no-install-recommends -y --force-yes mesos=${MESOS_PACKAGE_VERSION} && \
apt-get clean && \
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* && \
ln -snf /opt/jdk/bin/java /etc/alternatives/java
CMD [ "bash" ]
然后是Spark的
FROM 10.10.10.160:8010/zero/mesos:0.28.1
MAINTAINER wcai
SPARK_HOME="/opt/spark" \
SPARK_VERSION="2.0.0" \
HADOOP_VERSION="2.6"
apt-get update -y && \
apt-get install curl -y && \
curl -o /tmp/spark.tar.gz /apache/spark/spark-${SPARK_VERSION}/spark-${SPARK_VERSION}-bin-hadoop${HADOOP_VERSION}.tgz && \
tar xvzf /tmp/spark.tar.gz -C /opt && \
mv /opt/spark* /opt/spark && \
rm -rf /tmp/spark.tar.gz \
$SPARK_HOME/jars/*yarn*.jar \
$SPARK_HOME/bin/*.cmd \
$SPARK_HOME/data \
$SPARK_HOME/examples \
$SPARK_HOME/python \
$SPARK_HOME/yarn \
$SPARK_HOME/R \
$SPARK_HOME/licenses \
$SPARK_HOME/CHANGES.txt \
$SPARK_HOME/README.md \
$SPARK_HOME/NOTICE \
$SPARK_HOME/LICENSE \
$SPARK_HOME/conf/* && \
apt-get remove curl -y && \
apt-get clean && \
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
# 如果你想加入一些自己的配置
COPY ./spark-defaults.conf $SPARK_HOME/conf/spark-defaults.conf
ENV TZ=Asia/Shanghai
WORKDIR $SPARK_HOME
CMD [ "bash" ]
最后是spark-mesos-dispatcher的
FROM 10.10.10.160:8010/zero/spark:2.0.0
MAINTAINER wcai
PORT0="8081" \
PORT1="7077" \
SPARK_DISPATCHER_NAME="spark" \
ZK="master.mesos:2181" \
ZK_MESOS_ROOT="mesos"
COPY ./entrypoint.sh /usr/local/bin/entrypoint
CMD [ "entrypoint" ]
其中的entrypoint脚本
#! /bin/sh
export PATH=$PATH:$HADOOP_PREFIX/bin
if [ -z ${LIBPROCESS_IP} ]; then
export LIBPROCESS_IP=$(ip addr show eth0 | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | head -1)
export SPARK_LOCAL_IP=${LIBPROCESS_IP}
if [ -z ${LIBPROCESS_IP} ]; then
echo "error: LIBPROCESS_IP is blank."
export MESOS_MASTER="mesos://zk://${ZK}/${ZK_MESOS_ROOT}"
echo "************************************************************"
echo "LIBPROCESS_IP: ${LIBPROCESS_IP}"
echo "MASTER: ${MESOS_MASTER}"
echo "WEBUI PORT: ${PORT0}"
echo "RPC PORT: ${PORT1}"
echo "************************************************************"
$SPARK_HOME/bin/spark-class \
org.apache.spark.deploy.mesos.MesosClusterDispatcher \
--master ${MESOS_MASTER} \
--host ${LIBPROCESS_IP} \
--port ${PORT1} \
--webui-port ${PORT0} \
--name "${SPARK_DISPATCHER_NAME}" \
--zk ${ZK} \
--properties-file ${SPARK_HOME}/conf/spark-defaults.conf
大功告成, 只需要在marathon中启动dispatcher。spark-submit时指定spark.mesos.executor.docker.image为spark的docker镜像即可。你可以制作不同版本的spark镜像, 随意切换。(麻麻再也不用担心我追不上spark官方的升级速度了)
(三) marathon-lb, 你值得拥有
Mesos的资源专供数据分析团队使用是相当浪费的。为此团队开始尝试将公司的其他服务陆续迁移进来。
公司已有的Rest API大多都是docker容器形式部署在各个服务器上。本来的计划是通过marathon部署, 使用域名做服务发现, 然后nginx反向代理到公网。但实际实施中踩了个坑。因为nginx的配置域名的upstream很成问题, 一旦指向的ip变动就会导致解析失败。尝试使用网上的各种方法(如配置resolver设置upstrem变量, 改用tengine的ngx_http_upstream_dynamic_module) 都无法完美解决这个问题。
最后团队还是决定引入marathon-lb, 替代原先基于mesos-dns的服务发现。
marathon-lb其实是一个HAProxy的包装, 它能动态地绑定marathon的服务。我们以internal形式部署, 某个服务如果需要做服务发现负载匀衡, 只需要加一个label为HAPROXY_GROUP: internal即可, 非常方便。这样最终的形态就变成如下的架构:
引入marathon-lb之后的部署架构图
(部署架构)
在小范围的服务迁移测试稳定之后, 团队陆续将一些其他服务迁移过来, 也释放了一些服务器资源, 将这些空闲的服务器也重新回收纳入到我们的Mesos集群中。
在此之后, 维护这些服务变得简单便捷, 泡杯咖啡, 点点鼠标就可以轻松搞定, 运维压力减小了很多。
未来的愿景(补轮子篇)
拥有了以上的这些基础架构服务之后, 一切都可以运转起来。但总有一些痛点需要我们自己造轮子去解决。
当你有大量的Spark批处理作业时, 一个很头疼的事情就是如何去调度这些作业。
以前我们通过来做执行管理, 但这个工具太过简陋, 对于cluster-mode下的spark作业, 如果你想定义依赖, 则需要使用它的异步回调来通知作业已完成, 这样一来无可避免需要侵入业务代码。(程序猿表示如果要妥协强行写这些跟业务半点关系都没有的代码, 我选择狗带)
我们需要一个零侵入的Spark通用作业流程解决方案。为此我们自己实现了一个小项目(Armyant), 旨在解决这个问题。
整体架构很简单, 通过做流程引擎, 做定时调度, 来做状态通知:
armyant架构图
(armyant架构图)
外加一套易用的UI, 第一个版本就能顺利跑起来。
(armyant图示1)
后续又实现了一个mesos framework, 这样也可以定义一些one-off形式的任意docker任务。接着再向上封装一下, 包装一层任意的Java服务也很方便。当然mesos生态圈其实也有很多专门为one-off形式的作业而生的工具, 如等等。
(armyant图示2)
虽然DC/OS社区版可以查看当前的运行状态, 但它没有监控报警相关的功能(天下没有免费的午餐)。目前我们在每个节点上部署了传统的nagios。
在接下来的阶段, 团队也会对此做进一步的探索。
DC/OS再配合mesos自带的日志其实已经很大程度上方便了查看日志的需求。甚至DC/OS本身也可以接入ELK。但我们期望有更高级的日志分类收集, 这需要定制一些收集处理模块。团队的大神亲自操刀正在实现这些高级的功能, 随着业务的扩张，能有一个可以灵活定制的日志处理系统是很有好处的。我的Leader也常说, 大厂和小厂的东西, 区别就在于大厂的监控报警运维系统做得非常完善易用。
文末最后, 作为一个初创小团队, 笔者觉得Mesos对我们的利好是不言而喻的。也希望让我们的集群更加稳定健壮, 来支撑我们日益增长的业务系统。
本文系力谱宿云LeapCloud旗下MaxLeap团队_数据分析组成员：蔡伟伟 【原创】
-力谱宿云首发-
蔡伟伟，本科毕业于同济大学，从事Java开发多年，后端码农一枚。先后从事ETL、AdHoc报表、垂直爬虫、App制作云服务、动态用户分群等产品的设计研发工作。在互联网领域混迹多年，各方面均有所涉猎。现任MaxLeap数据分析组开发人员，负责Hadoop、Spark相关的分析系统架构设计与开发。
专业分享iOS/Android移动端研发技术干货，前端/后端All in Here，伴随UI设计等，让你知道最新最酷炫的移动端应用研发知识~
985出身的作者团队，多年研发经验汇总，干货满满，值得驻足。
公司官网：/
真旺云平台：/