资源调度器的一些基本问题

1 调度算法

Capacity based， DRF(dominant recourse fairness)，label based等

多态化，插件化，可以多种策略一起工作，对应于不同Job （优先级，job特性，service or batch job)

2 容错，HA

调度器一般处在一个中心位置，存在SPF问题。可以采用类似HDFS，JobTracker的HA方案

1）active - standby 结构，（standby 一般是一个，也可多个）

2）无状态（状态外化），使用可靠的外部shared storage保存状态（NFS，Bookeeper，Zookeeper）

3）状态的形式一般是 snapshot + read ahead log ( image + edits)

4)  Fault Detect，具体方案有很多：

a) active 向 standby 心跳，超时standby take over

b) active向 数据库心跳，standby 定时检查 active的 last heart beat time。

c) 基于 全局锁，能获得锁的就是active

d) 基于的membership list通知 

5）切换。standby 从shared storage恢复状态，VIP切换（或者不基于VIP，client liberary自己retry判断)

3 调度器的架构以及相应的scalability

调度器面对的是整个cluster的资源以及使用情况，这是一个全局的复合状态。最安全的架构就是串行化，job一个一个schedule。一般的架构就是单线程的。

1）Monolithic scheduler

就一个scheduer，面向整个资源

2）静态分区的scheduler

静态的把资源partition，每个scheduler负责一个partition的资源的调度，这样每个scheduler并行工作，彼此也无冲突。

3）双层调度架构

一个中心recourse allocator动态的给每个scheduler分配资源，方案二的动态化。通过资源锁实现，一个scheduler拥有一个资源就是拥有这个资源的锁。

缺点：

a） 死锁的问题。

b）每个调度器只能看到部分资源，影响调度算法的效果

c ）较低的并发度

注：Yarn虽然形式上像双层架构，但本质上是单体的，因为第二层的ApplicationMaster的调度本质上是job管理，而非资源管理。

4）share state 调度器

每个scheduler都面向整个资源，基于乐观的并发机制（后验的并发）。适用于冲突较少的情况。