【Free Style】Mesos 容错调研分享
1 ZooKeeper容错(选主组件)
mesos框架中,如果master节点失效,执行器中的当前现有任务将继续执行,但是framework无法获取新的资源,从而导致新的任务因没有资源而得不到执行。为了解决这种情况,需要采用了多master模式,即选取其中一个master作为有效的leader,其它master作为follower来避免master的故障。master的选主是通过ZooKeeper来实现的,所以同样需要保证ZooKeeper的故障可恢复。
ZooKeeper的故障恢复也是通过在集群中创建多个ZK server来实现的(建议部署2N+1台机器来构成ZooKeeper集群,并且建议不同节点跨机房部署,以防止数据中心故障导致ZooKeeper无法使用。)
1.1 配置
1. 创建zoo.cfg配置文件
进入zookeeper-3.4.5软件包conf目录,配置ZooKeeper配置文件,配置参考如下:
用户需关心以下参数:
tickTime:
ZK中的一个时间单元,ZK中所有时间都是以这个时间单元为基础进行整数倍配置,例如session的最小超时时间是2*tickTime
dataDir:
存储快照文件snapshot的目录。默认情况下,事务日志也会存储在这里。
clientPort:
ZooKeeper客户端连接Server的端口,及对外服务端口,默认设置为2181。
server.x=[hostname]:dataPort:selectPort
这里配置Zookeeper集群的主机IP和通信端口。x是一个数字,表示服务器ID,与myid文件中的id是一致的,dataPort用于Leader与Follower之间的数据同步和其它通信,selectPort用于Leader选举过程中的投票通信。ZooKeeper集群中的每个server需要清楚ZK集群中有哪些其它server的存在,所以每个节点都需要配置以上参数。
2. 进入zookeeper-3.4.5,创建zkdata目录,用于存放数据
3. 进入conf目录,创建myid文件
myid的值必须在整个ZK集群中唯一,值必须为1~255
1.2 启动
以下以三个节点为例:
1. 分别进入每个节点的zookeeper-3.4.5/bin目录执行./zkServer.sh start启动Zookeeper server
2. 验证启动是否成功,有两种方法验证
1)./zkServer.sh status查看本节点的ZK角色
从上面可以看到产生一个leader,两个follower
2)./zkCli.sh –server IP:Port
其中IP可以为运行着的ZK集群中的任一节点,Port为Server的客户端监听端口
1.3 容错验证
1. Leader退出,新Leader的选举
从上面可以看到SZV1000035589这台主机节点是Leader,我们手动将其关闭,观察Leader的产生
从上面可以看到,leader已经切换到SZV1000035590这个节点,新leader的产生时间大概是200ms
2. 退出Leader的恢复
我们可以看到恢复之后,身份变成了follower
3. 关闭其中两个节点
由于ZooKeeper要求大多数(大于一般)节点存活才能使用,所以当两个关闭时,剩下的一个也无法使用了,只需再启动其中一个,就能达到大多数存活,使ZK集群继续可用。
1.4 总结
ZooKeeper容错主要是建立ZK集群来实现容错,目前无代码改动,只要涉及配置文件修改即可。
2 Mesos master容错
图1 Mesos master容错
Mesos master自身的容错需要部署多个master节点来完成。为了保证master的高可用,推荐使用3或5个master。
2.1 配置
进入panda/uTask/artifacts/sbin,打开launch_mesos_master.sh编辑以下选项
用户需关心以下参数:
MASTER_IP:
master节点监听IP地址,master集群每个节点要对应有当前机器的IP
MASTER_PORT:
master节点监听端口,默认5050
ZOOKEEPER_PORT:
对应ZooKeeper客户端连接Server的端口,默认2181
ZOOKEEPER_IP~ ZOOKEEPER_IPx:
对应ZooKeeper集群的IP
2.2 启动
以下以三个节点为例:
1. 分别进入每个节点的panda/uTask/artifacts/sbin目录执行sh launch_mesos_master.sh启动mesos master
2. 如何确认启动是否成功,有两种方法确认
1) master节点日志
启动后可以看到如下日志,说明启动成功
Leader节点
Standby节点:
2)slave节点日志
2.3 容错验证
1. Leader退出,新Leader的选举
1)主动将leader关闭
可以在standby master节点观察到以下打印
可以在slave节点上观察到以下打印
2)新的leader选举
新的leader选举时间大约为200ms
可以从新的leader master节点上观察到以下打印
可以从standby master节点上观察到一下打印
可以从slave节点上观察到一下打印
从slave节点上可以观察到,slave重新检测到master是在大约10s钟之后,这是由mesos的自身机制决定的。Mesos利用超时时间来检测各个组件是否可用,组件一旦和ZooKeeper断开时间超过了配置时间,Mesos组件就会超时。竞争者(master)和观察者(slave和framework scheduler)的会话分别会在MATSER_CONTENDER_ZK_SESSION_TIME_OUT(默认10秒,在src/master/contender.cpp中定义)和MASTER_DETECTOR_ZK_SESSION_TIMEOUT(默认10秒,在src/master/detector.cpp中定义)指定的时间后超时,不同组件的超时与ZooKeeper断开后需要做不同处理。
2. 退出Leader的恢复
退出的leader IP为10.186.68.240
可以看到,leader恢复后,可以检测到新的leader,但自身已经降为standby master
新的leader节点上的打印如下
3. 关闭其中两个节点
把10.186.68.240、10.186.68.247关闭,可以从10.186.69.228(standby master)观察到,晋升为leader
slave节点上观察到以下日志:
4. 全部关闭
1)slave
全部关闭后可以从slave上看到以下日志,将一直检测新的master
2)framework scheduler
全部关闭后可以从framework scheduler上观察到以下日志
等待检测到新的master
5. Leader断开超过10s,framework scheduler的处理
可以观察到检测到新的master之后,并不会马上注册,而是等到10s之后注册
2.4 总结
从上面的日志可以观察到,断开后,framework scheduler的disconnect()函数将被马上调用,而10s之后,重新注册成功,registered()函数将被调用,然而断开之后,相应的resourceOffers将不被调用,也不存在任务分发过程,所以framework scheduler的代码不用做任何处理。
Mesos master容错通过部署多个master节点来完成,目前无代码改动,只要涉及配置文件修改即可。
3 Mesos slave容错
图2 Mesos slave容错
3.1 配置
进入panda/uTask/artifacts/sbin,打开launch_mesos_master.sh编辑以下选项
用户需关心以下参数:
SLAVE_IP:
slave节点监听IP地址,slave集群每个节点要对应有当前机器的IP
SLAVE_PORT:
slave节点监听端口,默认5051
MASTER_IP:
master节点监听IP地址,当slave具体指定连接一台master时,此变量有效
MASTER_PORT:
master节点监听端口,默认5050
LIBPROCESS_IP:
mesos内部通信组件使用的是libprocess,需要使用此设置环境变量来识别libprocess通信地址
ZOOKEEPER_PORT:
对应ZooKeeper客户端连接Server的端口,默认2181
ZOOKEEPER_IP~ ZOOKEEPER_IPx:
对应ZooKeeper集群的IP
--master:
指定slave要连接的master路径,有4种形式
1)主机名:localhost:5050
2)主机IP地址:127.0.0.1:5050
3)ZooKeeper集群:ZK_IP1:ZK_PORT1, ZK_IP2:ZK_PORT, ZK_IP3:ZK_PORT3……/mesos
4)文件:可以将1.2.3存入文件,配置指向文件路径 –master=/etc/mesos/zk
3.2 启动
1. 分别进入每个节点的panda/uTask/artifacts/sbin目录执行sh launch_mesos_slave.sh启动mesos slave
2. 如何确认启动是否成功,有两种方法确认
1)master节点日志
2)slave节点日志
3.3 容错验证
1. slave出错(Ctrl+C 模拟)
从master可以观察到下面日志
2. slave恢复
从master可以观察到下面日志
3. 任务重发
1) 当slave出错的时候,任务状态将被标识为TASK_LOST
下面是scheduler上的日志信息
任务分发到228节点
228节点出错,scheduler收到TASK_LOST信息
任务重新分发到其它节点运行
4. slave节点恢复
节点恢复后,可以从scheduler的resourceOffers中继续收到此节点的资源上报,并做任务分发
4 Executor容错和Task容错
图5 Executor和Task容错
4.1 配置
无
4.2 启动
executor的启动由mesos框架自身实现,用户task相应的被放入executor执行,无需用户干预。
4.3 容错验证
1. executor容错
executor出错后,将会上报任务状态TASK_LOST,scheduler根据任务状态进行任务重发,任务信息从redis中获取
2. task容错
task出错后,会将任务状态返回给executor,executor相应的将任务状态上报给scheduler。当前任务状态不细分,scheduler处理任务出错状态,都是进行任务的重发。
- 点赞
- 收藏
- 关注作者
评论(0)