spark master ha彻底解密
2017-01-19 11:17
274 查看
一:Master HA解析
1, 生产环境下一般采用ZooKeeper做HA,且建议为3台Master,ZooKeeper会自动化管理Masters的切换;
2, 采用ZooKeeper做HA的时候,ZooKeeper会负责保存整个Spark集群运行时候的元数据:Workers、Drivers、Applications、Executors;
3, ZooKeeper遇到当前Active级别的Master出现故障的时候会从Standby
Masters中选取出一台作为Active Master,但是要注意,被选举后到成为真正的Active Master之间需要从ZooKeeper中获取集群当前运行状态的元数据信息并进行恢复;
4, 在Master切换的过程中,所有的已经在运行的程序皆正常运行!因为Spark Application在运行前就已经通过Cluster
Manager获得了计算资源,所以在运行时Job本身的调度和处理和Master是没有任何关系的!
5, 在Master的切换过程中唯一的影响是不能提交新的Job:一方面不能够提交新的应用程序给集群,因为只有Active
Master才能接受新的程序的提交请求;另外一方面,已经运行的程序中也不能够因为Action操作触发新的Job的提交请求;
二:Master HA的四大方式
1, Master HA的四大方式风别是:ZOOKEEPER、FILESYSTEM、CUSTOM、NONE;
2, 需要说明的是:
a) ZOOKEEPER是自动管理Master;
b) FILESYSTEM的方式在Master出现故障后需要手动重新启动机器,机器启动后会立即成为Active级别的Master来对外提供服务(接受应用程序提交的请求、接受新的Job运行的请求)
c) CUSTOM的方式允许用户自定义Master HA的实现,这对于高级用户特别有用;
d) NONE,这是默认情况,当我们下载安装了Spark集群中就是采用这种方式,该方式不会持久化集群的数据,Master启动后立即管理集群;
3, val
serializer = new
JavaSerializer(conf)
val (persistenceEngine_,
leaderElectionAgent_) = RECOVERY_MODE
match {
case
"ZOOKEEPER" =>
logInfo("Persisting recovery state to ZooKeeper")
val
zkFactory =
new
ZooKeeperRecoveryModeFactory(conf,
serializer)
(zkFactory.createPersistenceEngine(),
zkFactory.createLeaderElectionAgent(this))
case
"FILESYSTEM" =>
val
fsFactory =
new
FileSystemRecoveryModeFactory(conf,
serializer)
(fsFactory.createPersistenceEngine(),
fsFactory.createLeaderElectionAgent(this))
case
"CUSTOM" =>
val
clazz = Utils.classForName(conf.get("spark.deploy.recoveryMode.factory"))
val
factory = clazz.getConstructor(classOf[SparkConf],
classOf[Serializer])
.newInstance(conf,
serializer)
.asInstanceOf[StandaloneRecoveryModeFactory]
(factory.createPersistenceEngine(),
factory.createLeaderElectionAgent(this))
case
_ =>
(new
BlackHolePersistenceEngine(),
new MonarchyLeaderAgent(this))
}
4,PersistenceEngine中有一个至关重要的方法persist来实现数据持久化,readPersistedData来恢复集群中的元数据;
/**
* Defines how the object is serialized and persisted. Implementation will
* depend on the store used.
*/
def persist(name:
String,
obj: Object)
/**
* Returns the persisted data sorted by their respective ids (which implies that they're
* sorted by time of creation).
*/
final def readPersistedData(
rpcEnv: RpcEnv): (Seq[ApplicationInfo],
Seq[DriverInfo],
Seq[WorkerInfo]) = {
rpcEnv.deserialize { () =>
(read[ApplicationInfo]("app_"),
read[DriverInfo]("driver_"),
read[WorkerInfo]("worker_"))
}
}
5,FILESYSTEM和NONE的方式均是采用MonarchyElectionAgent的方式来完成Leader选举,其实际实现是直接将传入的Master设置为Leader;
1, 生产环境下一般采用ZooKeeper做HA,且建议为3台Master,ZooKeeper会自动化管理Masters的切换;
2, 采用ZooKeeper做HA的时候,ZooKeeper会负责保存整个Spark集群运行时候的元数据:Workers、Drivers、Applications、Executors;
3, ZooKeeper遇到当前Active级别的Master出现故障的时候会从Standby
Masters中选取出一台作为Active Master,但是要注意,被选举后到成为真正的Active Master之间需要从ZooKeeper中获取集群当前运行状态的元数据信息并进行恢复;
4, 在Master切换的过程中,所有的已经在运行的程序皆正常运行!因为Spark Application在运行前就已经通过Cluster
Manager获得了计算资源,所以在运行时Job本身的调度和处理和Master是没有任何关系的!
5, 在Master的切换过程中唯一的影响是不能提交新的Job:一方面不能够提交新的应用程序给集群,因为只有Active
Master才能接受新的程序的提交请求;另外一方面,已经运行的程序中也不能够因为Action操作触发新的Job的提交请求;
二:Master HA的四大方式
1, Master HA的四大方式风别是:ZOOKEEPER、FILESYSTEM、CUSTOM、NONE;
2, 需要说明的是:
a) ZOOKEEPER是自动管理Master;
b) FILESYSTEM的方式在Master出现故障后需要手动重新启动机器,机器启动后会立即成为Active级别的Master来对外提供服务(接受应用程序提交的请求、接受新的Job运行的请求)
c) CUSTOM的方式允许用户自定义Master HA的实现,这对于高级用户特别有用;
d) NONE,这是默认情况,当我们下载安装了Spark集群中就是采用这种方式,该方式不会持久化集群的数据,Master启动后立即管理集群;
3, val
serializer = new
JavaSerializer(conf)
val (persistenceEngine_,
leaderElectionAgent_) = RECOVERY_MODE
match {
case
"ZOOKEEPER" =>
logInfo("Persisting recovery state to ZooKeeper")
val
zkFactory =
new
ZooKeeperRecoveryModeFactory(conf,
serializer)
(zkFactory.createPersistenceEngine(),
zkFactory.createLeaderElectionAgent(this))
case
"FILESYSTEM" =>
val
fsFactory =
new
FileSystemRecoveryModeFactory(conf,
serializer)
(fsFactory.createPersistenceEngine(),
fsFactory.createLeaderElectionAgent(this))
case
"CUSTOM" =>
val
clazz = Utils.classForName(conf.get("spark.deploy.recoveryMode.factory"))
val
factory = clazz.getConstructor(classOf[SparkConf],
classOf[Serializer])
.newInstance(conf,
serializer)
.asInstanceOf[StandaloneRecoveryModeFactory]
(factory.createPersistenceEngine(),
factory.createLeaderElectionAgent(this))
case
_ =>
(new
BlackHolePersistenceEngine(),
new MonarchyLeaderAgent(this))
}
4,PersistenceEngine中有一个至关重要的方法persist来实现数据持久化,readPersistedData来恢复集群中的元数据;
/**
* Defines how the object is serialized and persisted. Implementation will
* depend on the store used.
*/
def persist(name:
String,
obj: Object)
/**
* Returns the persisted data sorted by their respective ids (which implies that they're
* sorted by time of creation).
*/
final def readPersistedData(
rpcEnv: RpcEnv): (Seq[ApplicationInfo],
Seq[DriverInfo],
Seq[WorkerInfo]) = {
rpcEnv.deserialize { () =>
(read[ApplicationInfo]("app_"),
read[DriverInfo]("driver_"),
read[WorkerInfo]("worker_"))
}
}
5,FILESYSTEM和NONE的方式均是采用MonarchyElectionAgent的方式来完成Leader选举,其实际实现是直接将传入的Master设置为Leader;
相关文章推荐
- [Spark内核] 第29课:Master HA彻底解密
- Master HA彻底解密
- Master HA彻底解密
- 第30课:集群运行模式下的Spark Streaming日志和Web监控台实战演示彻底解密
- Spark RDD概念学习系列之rdd的依赖关系彻底解密(十九)
- 第28课:彻底解密Spark Sort-Based Shuffle排序具体实现内幕和源码详解
- Spark Sort-Based Shuffle内幕彻底解密
- Spark技术内幕:Master基于ZooKeeper的High Availability(HA)源码实现
- [Spark内核] 第33课:Spark Executor内幕彻底解密:Executor工作原理图、ExecutorBackend注册源码解密、Executor实例化内幕、Executor具体工作内幕
- 《Spark商业案例与性能调优实战100课》第28课:彻底解密Spark Sort-Based Shuffle排序具体实现内幕和源码详解
- 第39课:spark streaming中direct kafka 内幕实现彻底解密
- [Spark内核] 第40课:CacheManager彻底解密:CacheManager运行原理流程图和源码详解
- 《Spark商业案例与性能调优实战100课》第31课:彻底解密Spark 2.1.X中Shuffle中内存管理源码解密:StaticMemory和UnifiedMemory
- 《Spark商业案例与性能调优实战100课》第32课:彻底解密Spark 2.1.X中Shuffle 下Task视角内存分配管理
- 第16课:Spark Streaming源码解读之数据清理内幕彻底解密
- Spark集群master节点实现HA配置
- 第24课:彻底解密Shuffle是如何成为Spark性能杀手的及调优点思考
- Spark定制班第30课:集群运行模式下的Spark Streaming日志和Web监控台实战演示彻底解密
- Spark EXecutor彻底解密
- 42:Spark Streaming中checkpoint内幕实现彻底解密