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

wy168

/ ~' K: N5 j% y2 w9 a

作者 | .NY&XX，CSDN 博客专家

; d/ Z+ Y0 q) l: y, t

责编 | 唐小引

+ c ^, O# X' f( A% H, o

头图 | CSDN 下载自东方 IC

( M2 E g$ y* v

出品 | CSDN 博客

, v& {5 Y$ M% y3 ^- Q

前言

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

设计思路

. R5 I6 ]6 \* C6 d' E5 ^! V

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

_( N2 A d5 P" M, k# \

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

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

架构设计方案

" N( i) |; p! y) s: U; ~6 W. d* z+ q

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

0 Y) Q% W5 Y5 X+ r/ p) `

具体架构示意图如下：

各个功能模块如下：

Framework（FW）：应用程序框架，包含该应用程序的所有模块，如应用程序框架内的 master、slave 等。

/ r; y4 ?3 I- C. k- O

RC：资源控制节点，是一个全局的资源管理器，负责整个系统的资源管理与分配。

" G( p, D" s6 Q% \+ `: ^4 U0 B

NC：节点控制，NC 是每个节点上的资源和作业管理器。

& ]' P( ?8 I5 q0 f/ b6 b" p6 `+ y/ p. m

Docker Container：虚拟化的应用容器，用于资源隔离。在每台机器上，一个 Docker Container 对应一个 Framework 实例，因此 Framework 实例内部的资源可以共享，Framework 实例间的资源不能共享。

- f0 U; r8 x5 F; U$ k$ z( j0 J; e

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 的仓库。

0 l& S; i, u1 r7 L0 L& J2 @ g U$ \

LS：日志服务器，负责记录操作日志等。

( o2 s! H" I( q( w7 Z

SAS：保存框架实例的服务访问入口。

& A. R& m6 W$ @8 ]1 w; W2 V+ ~

本文为 CSDN 博客专家「.NY&XX」的原创文章。

2 m g3 J5 [9 `" S

原文链接：

https://blog.csdn.net/songguangfan/article/details/104433894 - ?+ i* K( h+ n) c; b# R* j4 g ) d, X( J- z& R+ Y1 P5 i" x