基于容器的虚拟化资源调度系统架构设计 | 原力计划
Posted CSDN
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了基于容器的虚拟化资源调度系统架构设计 | 原力计划相关的知识，希望对你有一定的参考价值。
前言
大多数底层平台必须支撑上层的多种服务，如媒体流服务、深度学习计算框架等，如果采用传统的基于 MapReduce 分布式计算框架必将带来扩展性差、资源利用率低、无法支持多种框架的问题。上层的每个服务组件的实现均是一个分布式子系统，如果单独实现，必然造成各组件之间完全孤立维护与管理。
设计思路
为了解决这个问题，解决方案则是考虑将各个服务组件的资源管理与作业控制进行分离，并且加入基于 Docker 容器的资源管理方案。
将资源管理整合成一个资源管理与调度平台，而作业控制则放到应用程序框架中从而解决扩展性差的问题。各个服务组件中的各个模块则采用虚拟化容器 Docker 进行资源隔离，提高了资源利用率，同时也保证了安全性。在基于容器的分布式资源管理平台之上，可以构建类似于视频流服务、深度学习计算框架等服务，形成媒体智能处理层。
基于多种面向有向无环图（DAG）任务的调度方式，将业务平台与资源管理平台进行解耦，达到资源的高效利用。
架构设计方案
采用 Master/Slave 架构，分别对应 RC（Resource Control）、NC（Node Control）和 SAS。RC 负责整个集群的资源管理和调度，NC 负责单个节点的资源管理，SAS 负责保存框架实例的服务访问入口
具体架构示意图如下：
各个功能模块如下：
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：保存框架实例的服务访问入口。
本文为 CSDN 博客专家「.NY&XX」的原创文章。
原文链接：https://blog.csdn.net/songguangfan/article/details/104433894
以上是关于基于容器的虚拟化资源调度系统架构设计 | 原力计划的主要内容，如果未能解决你的问题，请参考以下文章