Skip to content

taotaowill/galaxy

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Galaxy

Build Status
Copyright 2015, Baidu, Inc.
Galaxy是一个数据中心操作系统,目标是最大化资源的利用率与降低应用部署运维代价。

#Galaxy 3.0设计

背景

Galaxy3.0是对Galaxy2.0的重构,主要解决以下问题:

  1. 容器管理和服务管理紧耦合:服务的升级和启停都伴随容器的销毁和调度;
  2. 没有磁盘管理,只能管理home盘;
  3. 不支持用户quota和记账;
  4. 机器管理功能缺失;
  5. Naming功能可用性低;
  6. Trace功能不完善;

系统架构

    Galaxy3.0架构上分为2层: 资源管理层和服务管理层,每层都是主从式架构  
    1. 资源管理层由ResMan(Resource Manager)和Agent构成  
    2. 服务管理层由AppMaster和AppWorker构成;


   +-------------------+-----------------------------+
   |                   |               |             |
   |                   |   MapReduce   |   Spark     |
   |                   |               |             |
   |                   +-----------------------------+
   |                                                 |
   |               Service Management                |  ---> {AppMaster + AppWorkers}
   |                                                 |
   +-------------------------------------------------+
   |                                                 |
   |               Resource Management               |  ---> {ResMan + Agents}
   |                                                 |
   +-------------------------------------------------+

1. 资源管理层(Resource Management)

组件: ResMan + Agents
一个Galaxy集群只有一个处于工作状态的ResMan,负责容器的调度,为每个容器找到满足部署资源要求的机器;
ResMan通过和部署在各个机器上的Agent通信,来创建和销毁容器;
容器: 一个基于linux cgroup和namspace技术的资源隔离环境;
容器里默认会启动AppWorker进程,是容器内的第一个进程,也就是根进程;
ResMan不暴露给普通用户接口, 仅供内部组件以及集群管理员使用;

2. 服务管理层 (Service Management)

组件: AppMaster + AppWorkers
AppMaster是外界用户操作Galaxy的唯一入口;
一个Galaxy集群通常只有一个AppMaster,负责服务的部署、更新、启停和状态管理,把服务实例分发到各个机器上的容器内启动并跟踪状态;
AppMaster通过调用ResMan的RPC接口创建容器,容器内自动拉起AppWorker进程;
容器内的AppWorker进程通过和AppMaster进程通信,获得需要在容器内执行的命令,包括部署、启停、更新等等;
AppWorker会汇报服务的状态给AppMaster,例如托管的服务是否在正常运行,进程退出码等;

调度逻辑

用户提交的Job内容主要是两部分:资源需求 + 程序描述
资源需求: CPU核数、内存大小、磁盘容量、机器Lable、端口范围、mount路径
程序描述: 部署命令、启动命令、停止命令、更新命令、版本号

1. ResMan的调度逻辑

ResMan通过定时查询Agent,获得每个Agent上面可分配的资源
ResMan不断检查当前是否有处于Pending状态的容器, 寻找有资源的Agent创建容器;
创建失败的容器,又进入Pending状态,等待重新调度;
不符合预期的容器, ResMan命令Agent销毁, 重新进入Pending状态;
ResMan确保容器的个数始终符合用户的需求;

2. AppMaster的调度逻辑

AppMaster等待AppWorkers的定时汇报;
如果AppWorker汇报的服务状态不符合AppMaster的预期,则AppMaster返回一些命令让AppWorker执行;

a) 部署: AppWorker汇报目前没有运行任何服务, AppMaster返回部署命令给AppWorker;
b) 启动: AppWorker汇报部署成功了, AppMaster返回启动命令给AppWorker;
c) 更新: AppWorker汇报当前服务的版本号, AppMaster发现不匹配, 返回更新命令给AppWorker;
d) 失败处理: AppWorker汇报(部署失败 or 启动失败 or 更新失败), AppMaster记录此次异常,并根据策略决定是否让AppWorker继续重试;

容错

  1. ResMan,AppMaster都有备份,通过Nexus抢锁来Standby;
  2. Agent跟踪每个容器的状态汇报给ResMan,当容器个数不够或者不符合ResMan的要求时,就需要调度:创建或删除容器;
  3. AppWorker负责跟踪用户程序的状态,当用户程序coredump、异常退出或者被cgroup kill后,反馈状态给AppMaster,AppMaster根据指定策略命令AppWorker是否再次拉起用户的服务;
  4. 由于机器缺陷或者网络分割,可能导致ResMan认为容器个数足够,但是AppMaster发现服务实例数不够的情况:

例如: 磁盘坏了、端口被占用等, 导致用户服务始终无法拉起;
这种情况下, AppMaster可以调用ResMan的接口,增大容器个数(有上限);

服务发现

  1. SDK通过Nexus发现AppMaster地址;
  2. SDK请求AppMaster,发现每个Job实例的地址和当前的服务状态;
  3. AppMaster会定时同步服务地址和状态到第三方Naming系统(如BNS,Nexus,ZK等);

服务更新

  1. SDK通过Nexus发现指定的Job的AppMaster地址;
  2. SDK请求AppMaster, AppMaster将服务更新命令传播给AppWorker, AppWorker将更新状态反馈给AppMaster;
  3. AppWorker和AppMaster的通信方式是Pull的方式,因此AppMaster可以根据当前的情况来决定部署的暂停和步长控制;
  4. 服务的更新都在容器内进行,不涉及到容器的销毁和创建

权限管理和quota管理模型

  1. 集群(Cluster):共用同一ResMan的host/agent及服务
  2. 机器池(Pool): 一个host/agent只能属于一个机器池,一个机器池通常有很多host/agent。一个集群中可能有多个机器池。机器池用于资源及环境的硬隔离, 也是权限分配的单位。
  3. 用户(User):galaxy用户
  4. 权限(Authority):某用户在某机器池上具有的某种操作权限,如对Job的增、删、改、查权限等。用户可以同时对多个机器池具有多项权限。
  5. 配额(Quota):配额是对用户在集群中拥有资源量的描述, 包含cpu配额,内存配额, 磁盘空间配额,可提交任务数量配额等。用户的配额和具体的机器池没有关系。
  6. 标签(label): 标签一般用来表征一批拥有某种特征的机器,标签和机器是多对多的关系。有权限的用户可以对机器池中的机器打标签,提交任务时可指定标签。

系统依赖

  1. Nexus作为寻址和元信息保存
  2. MDT作为用户日志的Trace系统
  3. Sofa-PbRPC作为通信基础库

About

Borg-like cluster operation system

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • C++ 94.8%
  • Protocol Buffer 2.8%
  • Python 1.3%
  • Shell 1.1%