基于容器的虚拟化资源调度系统的架构设计

前言

大多数底层平台必须支撑上层的多种服务,如媒体流服务、深度学习计算框架等,如果采用传统的基于MapReduce分布式计算框架必将带来扩展性差、资源利用率低、无法支持多种框架的问题。上层的每个服务组件的实现均是一个分布式子系统,如果单独实现,必然造成各组件之间完全孤立维护与管理。

设计思路

为了解决这个问题,解决方案则是考虑将各个服务组件的资源管理与作业控制进行分离,并且加入基于Docker容器的资源管理方案。

将资源管理整合成一个资源管理与调度平台,而作业控制则放到应用程序框架中从而解决扩展性差的问题。各个服务组件中的各个模块则采用虚拟化容器Docker进行资源隔离,提高了资源利用率,同时也保证了安全性。在基于容器的分布式资源管理平台之上,可以构建类似于视频流服务、深度学习计算框架等服务,形成媒体智能处理层。

基于多种面向有向无环图(DAG)任务的调度方式,将业务平台与资源管理平台进行解耦,达到资源的高效利用。

架构设计方案

采用Master/Slave架构,分别对应RC(Resource Control)、NC(Node Control)和SAS。RC负责整个集群的资源管理和调度,NC负责单个节点的资源管理,SAS负责保存框架实例的服务访问入口

具体架构示意图如下:

6F1A4759-8C76-4292-A15B-BD07CB363B6C.jpeg

各个功能模块如下:

  • Framework(FW):应用程序框架,包含该应用程序的所有模块,如应用程序框架内的master、slave等。
  • RC:资源控制节点,是一个全局的资源管理器,负责整个系统的资源管理与分配。
  • NC:节点控制,NC是每个节点上的资源和作业管理器。
  • Docker Container:虚拟化的应用容器,用于资源隔离。在每台机器上,一个Docker
    Container对应一个Framework实例,因此Framework实例内部的资源可以共享,Framework实例间的资源不能共享。
  • FW Master:框架实例内部的Master模块。
  • FW Slave:框架实例内部的Slave模块。 注:FW Master和FW
    Slave这里是相对的,如A启动B,B启动C。对于A来说,B是FW Slave,但对于C来说,B是FW Master。
  • Portal/Client:Portal和Client提供给用户不同的操作接口,拥有相同的协议。用户可以提交制作好的框架的Image(镜像),启动关闭框架,以及查询平台的资源情况和框架的资源使用情况,同时提供框架业务数据查询的重定向功能。
  • Docker仓库:存放所有Framework Image的仓库。
  • LS:日志服务器,负责记录操作日志等。
  • SAS:保存框架实例的服务访问入口。

添加新评论