YarnonDocker集群方案

统一的资源分配

• 每个NodeManager和容器都可以限定CPU、内存资源

• Yarn资源划分精确到CPU核数和内存大小

弹性伸缩性服务

• 每个容器中运行一个NodeManager&＃xff0c;增减yarn资源只需增减容器个数

• 可以指定每个NodeManager拥有的计算资源多少&＃xff0c;按需申请资源

Docker集群管理系统&＃xff1a;Kubernetes or Swarm&＃xff1f;

关于容器集群管理系统的选型&＃xff0c;用Kubernetes还是Swarm&＃xff1f;我们结合自己的经验和业务需求&＃xff0c;对比如下&＃xff1a;

基于以上四点&＃xff0c;我们最终选择了Swarm&＃xff0c;它基本满足我们的需求&＃xff0c;掌握和开发时常较短。

解决方案的优势

选用Yarn on Docker的好处有以下两点&＃xff1a;

Swarm统一集群资源调度

• 统一资源
• 增加Docker虚拟化层&＃xff0c;降低运维成本

增加Hadoop集群资源利用率

• For datacenter&＃xff1a;避免了静态资源隔离
• For cluster&＃xff1a;加强集群内部资源隔离

系统架构

比如数据中心中运行的Hadoop集群&＃xff0c;我们将HDFS依然运行在物理机上&＃xff0c;即DataNode依然部署在实体机器上&＃xff0c;将Yarn计算层运行在Docker容器中&＃xff0c;整个系统使用二层资源调度&＃xff0c;Spark、Flinek、MapReduce等应用运行在Yarn上。

Swarm调度最底层的主机硬件资源&＃xff0c;CPU和内存封装为Docker容器&＃xff0c;容器中运行NodeManager&＃xff0c;提供给Yarn集群&＃xff0c;一个Swarm集群中可以运行多个Yarn集群&＃xff0c;形成圈地式的Yarn计算集群。

具体流程

1. swarm node向swarm master注册主机资源并加入到swarm cluster中
2. swarm master向cluster申请资源请求启动容器
3. swarm根据调度策略选择在某个node上启动docker container
4. swarm node的docker deamon根据容器启动参数启动相应资源大小的NodeManager
5. NodeManager自动向YARN的ResourceManager注册资源一个NodeManager资源添加完成。

Swarm为数据中心做容器即主机资源调度&＃xff0c;每个swarm node的节点结构如图&＃xff1a;

一个Swarm node就是一台物理机&＃xff0c;每台主机上可以起多个同类型的docker container&＃xff0c;每个container的资源都有限制包括CPU、内存NodeManager容器只需要考虑本身进程占用的资源和需要给主机预留资源。假如主机是24核64G&＃xff0c;我们可以分给一个容器5核12G&＃xff0c;NodeManager占用4核10G的资源提供给Yarn。

技术详解

(一)镜像制作与发布

镜像制作和发布流程如下图&＃xff1a;

用户从客户端提交代码到Gitlab中&＃xff0c;需要包含Dockerfile文件&＃xff0c;通过集成了docker插件的Jenkins的自动编译发布机制&＃xff0c;自动build镜像后push到docker镜像仓库中&＃xff0c;同一个项目每提交一次代码都会重新build一次镜像&＃xff0c;生成不同的tag来标识镜像&＃xff0c;Swarm集群使用该镜像仓库就可以直接拉取镜像。

Dockerfile的编写技巧

Dockerfile相当于docker镜像的编译打包流程说明&＃xff0c;其中也不乏一些技巧。

很多应用需要配置文件&＃xff0c;如果想为每次启动容器的时候使用不同的配置参数&＃xff0c;可以通过传递环境变量的方式来修改配置文件&＃xff0c;前提是需要写一个bash脚本&＃xff0c;脚本中来处理配置文件&＃xff0c;再将这个脚本作为entrypoint入口&＃xff0c;每当容器启动时就会执行这个脚本从而替换配置文件中的参数&＃xff0c;也可以通过CMD传递参数给该脚本。

启动容器的时候通过传递环境变量的方式修改配置文件&＃xff1a;

docker run -d
--net&＃61;mynet
-e NAMESERVICE&＃61;nameservice
-e ACTIVE_NAMENODE_ID&＃61;namenode29 \
-e STANDBY_NAMENODE_ID&＃61;namenode63 \
-e HA_ZOOKEEPER_QUORUM&＃61;zk1:2181,zk2:2181,zk3:2181 \
-e YARN_ZK_DIR&＃61;rmstore \
-e YARN_CLUSTER_ID&＃61;yarnRM \
-e YARN_RM1_IP&＃61;rm1 \
-e YARN_RM2_IP&＃61;rm2 \
-e CPU_CORE_NUM&＃61;5
-e NODEMANAGER_MEMORY_MB&＃61;12288 \
-e YARN_JOBHISTORY_IP&＃61;jobhistory \
-e ACTIVE_NAMENODE_IP&＃61;active-namenode \
-e STANDBY_NAMENODE_IP&＃61;standby-namenode \
-e HA&＃61;yes \
docker-registry/library/hadoop-yarn:v0.1 resourcemanager

最后传递resourcemanager或者nodemanager参数指定启动相应的服务。

(二)集群管理

我们自行开发程序调用docker的API来管理集群&＃xff0c;也可以通过其他开源可视化页面来管理集群&＃xff0c;比如shipyard。

&＃xff08;三&＃xff09;自定义网络

Docker容器跨主机互访一直是一个问题&＃xff0c;Docker官方为了避免网络上带来的诸多麻烦&＃xff0c;故将跨主机网络开了比较大的口子&＃xff0c;而由用户自己去实现。我们开发并开源了Shrike这个docker网络插件&＃xff0c;大家可以在这里下载到&＃xff1a;https://github.com/talkingdata/shrike

目前Docker跨主机的网络实现方案也有很多种, 主要包括端口映射&＃xff0c;ovs, fannel等。但是这些方案都无法满足我们的需求&＃xff0c;端口映射服务内的内网IP会映射成外网的IP&＃xff0c;这样会给开发带来困惑&＃xff0c;因为他们往往在跨网络交互时是不需要内网IP的&＃xff0c;而ovs与fannel则是在基础网络协议上又包装了一层自定义协议&＃xff0c;这样当网络流量大时&＃xff0c;却又无端的增加了网络负载&＃xff0c;最后我们采取了自主研发扁平化网络插件&＃xff0c;也就是说让所有的容器统统在大二层上互通。架构如下&＃xff1a;

我们首先需要创建一个br0自定义网桥&＃xff0c;这个网桥并不是通过系统命令手动建立的原始Linux网桥&＃xff0c;而是通过Docker的cerate network命令来建立的自定义网桥&＃xff0c;这样避免了一个很重要的问题就是我们可以通过设置DefaultGatewayIPv4参数来设置容器的默认路由&＃xff0c;这个解决了原始Linux自建网桥不能解决的问题. 用Docker创建网络时我们可以通过设置subnet参数来设置子网IP范围&＃xff0c;默认我们可以把整个网段给这个子网&＃xff0c;后面可以用ipam driver&＃xff08;地址管理插件&＃xff09;来进行控制。还有一个参数gateway是用来设置br0自定义网桥地址的&＃xff0c;其实也就是你这台宿主机的地址。

docker network create
--opt&＃61;com.docker.network.bridge.enable_icc&＃61;true
--opt&＃61;com.docker.network.bridge.enable_ip_masquerade&＃61;false
--opt&＃61;com.docker.network.bridge.host_binding_ipv4&＃61;0.0.0.0
--opt&＃61;com.docker.network.bridge.name&＃61;br0
--opt&＃61;com.docker.network.driver.mtu&＃61;1500
--ipam-driver&＃61;talkingdata
--subnet&＃61;容器IP的子网范围
--gateway&＃61;br0网桥使用的IP,也就是宿主机的地址
--aux-address&＃61;DefaultGatewayIPv4&＃61;容器使用的网关地址
mynet

IPAM驱动是专门管理Docker 容器IP的, Docker 每次启停与删除容器都会调用这个驱动提供的IP管理接口&＃xff0c;然后IP接口会对存储IP地址的Etcd有一个增删改查的操作。此插件运行时会起一个Unix Socket, 然后会在docker/run/plugins 目录下生成一个.sock文件&＃xff0c;Docker daemon之后会和这个sock 文件进行沟通去调用我们之前实现好的几个接口进行IP管理&＃xff0c;以此来达到IP管理的目的&＃xff0c;防止IP冲突。

通过Docker命令去创建一个自定义的网络起名为“mynet”&＃xff0c;同时会产生一个网桥br0&＃xff0c;之后通过更改网络配置文件&＃xff08;在/etc/sysconfig/network-scripts/下ifcfg-br0、ifcfg-默认网络接口名&＃xff09;将默认网络接口桥接到br0上&＃xff0c;重启网络后&＃xff0c;桥接网络就会生效。Docker默认在每次启动容器时都会将容器内的默认网卡桥接到br0上&＃xff0c;而且宿主机的物理网卡也同样桥接到了br0上了。其实桥接的原理就好像是一台交换机&＃xff0c;Docker 容器和宿主机物理网络接口都是服务器&＃xff0c;通过veth pair这个网络设备像一根网线插到交换机上。至此&＃xff0c;所有的容器网络已经在同一个网络上可以通信了&＃xff0c;每一个Docker容器就好比是一台独立的虚拟机&＃xff0c;拥有和宿主机同一网段的IP&＃xff0c;可以实现跨主机访问了。

&＃xff08;四&＃xff09;集群监控

如果使用shipyard管理集群会有一个单独的监控页面&＃xff0c;可以看到一定时间段内的CPU、内存、IO、网络使用状况。

我们自己开发了基于大数据的监控系统Owl也即将支持docker容器的监控。https://github.com/TalkingData/OWL-v3

性能瓶颈与优化

大家可能会担心自定义网络的性能问题&＃xff0c;为此我们用iperf进行了网络性能测试。我们对比了不同主机容器间的网速&＃xff0c;同一主机上的不同容器和不同主机间的网速&＃xff0c;结果如下表&＃xff1a;

从表中我们可以看到&＃xff0c;在这一组测试中&＃xff0c;容器间的网速与容器是在想通主机还是在不同主机上的差别不大&＃xff0c;说明我们的网络插件性能还是很优异的。

Hadoop配置优化

因为使用docker将原来一台机器一个nodemanager给细化为了多个&＃xff0c;会造成nodemanager个数的成倍增加&＃xff0c;因此hadoop的一些配置需要相应优化。

• yarn.nodemanager.localizer.fetch.thread-count 随着容器数量增加&＃xff0c;需要相应调整该参数
• yarn.resourcemanager.amliveliness-monitor.interval-ms默认1秒&＃xff0c;改为10秒&＃xff0c;否则时间太短可能导致有些节点无法注册
• yarn.resourcemanager.resource-tracker.client.thread-count默认50&＃xff0c;改为100&＃xff0c;随着容器数量增加&＃xff0c;需要相应调整该参数
• yarn.nodemanager.pmem-check-enabled默认true&＃xff0c;改为false&＃xff0c;不检查任务正在使用的物理内存量
• 容器中hadoop ulimit值修改&＃xff0c;默认4096&＃xff0c;改成655350

关于未来

我们未来规划做的是DC&＃xff0f;OS&＃xff0c;基于Docker的应用自动打包编译分发系统&＃xff0c;让开发人员可以很便捷的申请资源&＃xff0c;上下线服务&＃xff0c;管理应用。要达到这个目标还有很多事情要做&＃xff1a;

• Service Control Panel&＃xff1a;统一的根据服务来管理的web页面
• Load balance&＃xff1a;容器根据机器负载情况自动迁移
• Scheduler&＃xff1a;swarm调度策略优化
• 服务配置文件&＃xff1a;提供镜像启动参数的配置文件&＃xff0c;所有启动参数可通过文件配置
• 监控&＃xff1a;服务级别的监控

(点击放大图像)

作者简介

宋净超&＃xff0c;TalkingData 大数据及云计算工程师。拥有多年的 Hadoop 大数据集群部署、管理、优化和实战经验&＃xff0c;对 Hadoop 和 Docker 的结合落地进行了丰富的探索&＃xff0c;主导了 TalkingData 的 Yarn on Docker的改造和微服务落地&＃xff0c;关注大数据开源软件及微服务的前沿发展。