1.背景数据库
Google的论文Omega:flexible,scalable schedulers for large compute clusters中把调度分为3代:第一代是独立的集群;第二代是两层调度(Mesos,YARN);第三代是共享状态调度,如图9.3所示。架构
图9.3并发
2.架构ide
为了克服双层调度器的局限性,Google开发了下一代资源管理系统Omega。Omega是一种基于共享状态的调度器,该调度器将双层调度器中的集中式资源调度模块简化为一些持久化的共享数据(状态)和针对这些数据的验证代码,而这里的“共享数据”实际上就是整个集群的实时资源使用信息。一旦引入共享数据,共享数据的并发访问方式就成为该系统设计的核心。而Omega则采用传统数据库中基于多版本的并发访问控制方式(也称为“乐观锁”,Multi-Version Concurrency Control,MVCC),大大提高了Omega的并发性。因为Omega再也不有集中式的调度模块,所以,不能像Mesos或者YARN那样,在一个统一模块中完成如下功能:对整个集群中的全部资源分组;限制每类应用程序的资源使用量;限制每一个用户的资源使用量等。这些功能所有由各个应用程序调度器自我管理和控制。根据论文所述,Omega只是将优先级这一限制放到了共享数据的验证代码中,即当多个应用程序同时申请同一份资源时,优先级最高的那个应用程序将得到该资源,其余资源限制所有下放到各个子调度器。引入多版本并发控制后,限制该机制性能的一个因素是资源访问冲突的次数,冲突次数越多,系统性能降低得越快。而Google经过实际负载测试证实,这种方式的冲突次数是彻底能够接受的。该论文中还谈道,Omega是从Google现有系统中演化而来的。虽然这篇论文只介绍了Omega的调度器架构,但咱们能够推测它的总体架构相似于Mesos。所以,若是你了解Mesos,则经过修改Mesos的Master就能够将它改形成一个Omega。性能
3.优缺点测试
(1)优势:共享资源状态,支持更大的集群和更高的并发。flex
(2)缺点:只有论文,无具体实现,在小集群下没有优点。scala
更详细的信息,你们去看论文吧:)设计