解析Google集群资源管理系统Omega(2)

　　(3) 共享状态调度器(Shared State Scheduler)

　　为了克服双层调度器的以上两个缺点，Google开发了下一代资源管理系统Omega，Omega是一种基于共享状态的调度器，该调度器将双层调度器中的集中式资源调度模块简化成了一些持久化的共享数据(状态)和针对这些数据的验证代码，而这里的“共享数据”实际上就是整个集群的实时资源使用信息。一旦引入共享数据后，共享数据的并发访问方式就成为该系统设计的核心，而Omega则采用了传统数据库中基于多版本的并发访问控制方式(也称为“乐观锁”, MVCC, Multi-Version Concurrency Control)，这大大提升了Omega的并发性。

　　由于Omega不再有集中式的调度模块，因此，不能像Mesos或者YARN那样，在一个统一模块中完成以下功能：对整个集群中的所有资源分组，限制每类应用程序的资源使用量，限制每个用户的资源使用量等，这些全部由各个应用程序调度器自我管理和控制，根据论文所述，Omega只是将优先级这一限制放到了共享数据的验证代码中，即当同时由多个应用程序申请同一份资源时，优先级最高的那个应用程序将获得该资源，其他资源限制全部下放到各个子调度器。

　　引入多版本并发控制后，限制该机制性能的一个因素是资源访问冲突的次数，冲突次数越多，系统性能下降的越快，而google通过实际负载测试证明，这种方式的冲突次数是完全可以接受的。

　　Omega论文中谈到，Omega是从Google现有系统上演化而来的。既然这篇论文只介绍了Omega的调度器架构，我们可推测它的整体架构类似于Mesos，这样，如果你了解Mesos，那么可知道，我们可以通过仅修改Mesos的Master将之改造成一个Omega。

　　4. 总结

　　除了以上讨论的几点外，Omega论文还谈到了集群管理系统的其他方面，比如不同的资源分配方式的优缺点，当前有两种资源分配方式，分别是：“all-or-nothing”和“incremental placement”，在此举例说明：一个任务需要2GB内存，而一个节点剩余1GB，若将这1GB内存分配给该任务，则需等待将节点释放另外1GB内存才可运行该任务，这种方式称为“incremental placement”，Hadoop YARN采用了这种增量资源分配的方式，而如果只为该任务选择剩余节点超过2GB内存的节点，其他不考虑，则称为“all-or-nothing”，Mesos和Omega均采用了这种方式。两种方式各有优缺点，“all-or-nothing”可能会造成作业饿死(大资源需求的任务永远得到不需要的资源)，而“incremental placement”会造成资源长时间闲置，同时可也能导致作业饿死，比如一个服务需要10GB内存，当前一个节点上剩余8GB，调度器将这些资源分配给它并等待其他任务释放2GB，然而，由于其他任务运行时间非常长，可能短时间内不会释放，这样，该服务将长时间得不到运行。

　　从Omega论文发表时间和使用的数据时间可看出，Omega在google内部是一个比较新的系统，而开源界(Mesos，YARN)的类似系统已经在开发中，虽然当前不稳定，但稳定版不久将推出，由于Omega与Mesos/YARN架构的不同主要体现在资源分配模块，因此，我们很容易通过改造Mesos或者YARN的“Resource Master”模块将其改造成一个类似于Omega的系统。我说这句话的意思是，开源软件已走得很快，普通公司，如果人力不足的话，就跟着开源走吧。

　　5. 推荐阅读

　　(1)http://www.wired.com/wiredenterprise/2013/04/google-john-wilkes-new-hackers/

　　(2)Multi-agent Cluster Scheduling for Scalability and Flexibility

　　(3)Omega: flexible, scalable schedulers for large compute clusters

　　(4)Return of the Borg: How Twitter Rebuilt Google’s Secret Weapon

　　(5)Google Omega PPT： http://vdisk.weibo.com/s/yLOtZ

原文转自：http://blogread.cn/it/article/6387?f=wb