怎样选择集群管理系统?

1. 隐藏资源和失败处理的细节，使用户专注于应用开发
2. 高可靠、高可用
3. 在上万台机器上高效运行

1. 用户向borg提交job
2. job由多个相同的task组成
3. 每个job在一个borg cell(borg中的一组机器)上运行

1. 常驻任务，持续运行不退出
2. 批处理任务，运行结束后退出，对性能波动不敏感
3. borg cell中两种任务会有各种混合组合

1. MapReduce、FlumeJava、MillWhell、Pregel，实现了自己的controller，用于向borg提交任务，类似于yarn。
2. GFS、CFS、BigTable、Megastore都运行在borg上

1. 每个cell中的机器以fabric的方式互联，归属一个cluster
2. 一个cluster位于一个数据中心
3. 一个站点分布在多个数据中心中
4. 一个cluster通过有一个大的cell，和多个规模较小的test cell，以及有专门用途的cell
5. 一个中等的cell大约是1万台机器
6. 每台机器从多个维度评估： CPU、RAM、Disk、Network，External IP、Flash Storage

1. Name、Owner、task's number
2. 硬约束和软约束，可以约束:  CPU类型、OS version、External IP等
3. Job是有优先级的，优先级低的延迟启动
4. 每个job在一个cell中运行
5. 每个task在容器中运行
6. Borg中不使用VM，因为不想支付虚拟化的开销，以及当时已经在不支持虚拟化的硬件上做了相当多投入
7. Job的描述语言BCL是GCL(生成protobuf files)的变种，支持lambda函数，可以根据环境修改配置
8. 相当多的BCL文件超过了1000行，总计有数亿行
9. job的配置与Aurora类似

1. 资源要求，CPU、RAM、Disk Space、Disk Access Rate、TCP port
2. 在Job中的编号
3. 程序都是静态连接的，以减少对运行环境对依赖
4. 软件包的安装由Borg负责

1. 可以修改运行中的job的配置
2. 更新是以滚动的方式进行的，每次可以中断的task数量是有限制的
3. Task被SIGKILL信号终止前，会被发送SIGTERM信号，可以有时间清理、保存状态

1. 一台机器机器上的资源是以alloc(allocation)为单位分配
2. 一个alloc中的资源即使没有被使用，也被认为是已经分配的
3. 在同一个alloc中运行的task共享alloc的资源
4. alloc set是分布在多个机器上的alloc，可以向其提交一个或多个job

1. 每个job有优先级，高优先级的job可以抢占低优先级job的资源
2. 将优先级划分为几个范围（按由高到低排序）： monitoring、production、batch、best effort(testing)
3. 高优先级的task被调度另一台机器上，可能抢占资源，导致低优先级的机器又被调度，引发抢占风暴
4. 为了防止抢占风暴，不允许production范围内的task抢占其它task的资源
5. 用quota来描述一个job在一段时间内需要的资源上限，admission control检查job的quota是否充足。
6. 高优先级的quota只有当cell中的资源确实满足的时候，对应的job才会被接受
7. 低优先级的quota即使cell中的资源不足，也会被接受，进行超卖
8. 管理员可以删除修改job，可以允许指定用户使用受限制的内核特性，以及关闭指定用户的job中的资源估计功能

1. 在BNS(Borg name service)中记录每个task，包括cell name、job name、task number
2. task的hostname和port被记录在chubby中，以task的BNS name为key
3. task的BNS name被用于task的dns name
4. job size和task的健康状态也被写入到chubby中，lb得以更新路由信息
5. 基本上每个task都会内置一个用于健康检查和提供性能指标的http server
6. Borg监控每个task的状态，自动重启异常的task

1. 用Sigma系统提供一个监控页面
2. Borg记录所有的job提交和task事件，以及每个task的资源使用情况，可用于计费、调试、资源规划等。

1. 一个逻辑上的中心控制器Borgmaster，每个机器上的agent: Borglet。
2. 全部用C++实现
3. Borgmaster由两个进程组成: main process、scheduler
4. main process处理client RPC、管理系统中所有资源的状态、与Borglet通信、像Sigma提供接口
5. Borgmater逻辑是上单进程的，实际是由5个副本组成，通过paxos协议选出leader
6. master的重新选举需要10秒，但在大集群中可能需要1分钟的时间重建内存中的记录
7. 重新上线的副本通过paxos协议更新数据
8. Borgmaster的状态会定期做checkpoint，即定期做snapshot，记录更改日志，记录在paxos记录中
9. 开发了一个Fauxmaster，它可以加载checkpoint，模拟borgmaster

1. job被提交后，borgmaster将其记录在paxos store中，并将job的task添加到pending队列中
2. scheduler异步地扫描pending队列，将任务分配到machine
3. scheduler按优先级调度任务，以round-robin的方式调度不同用户的同优先级任务
4. 调度过程分两步，选出可以承担任务的机器(feasibility checking)，为选出机器打分(scoring)
5. 选机器的时候，会将优先级低的任务占用的资源认为是可以使用的。
6. 打分时会考虑用户指定的偏好，但主要还是依据内置的标准，例如，被抢占的任务数量最少，机器上
   是否已经有任务的package文件，将任务跨供电区域、故障区域分配，在一个高优先级的任务和多个
   低优先级的任务分配到同一个机器上（使高优先级任务可以从容扩容）
7. 最早使用E-PVM的变种进行计分，在安排新的任务时，将影响降到最低，实际结果是任务被分配到
   所有机器上，预留了扩容空间，但是增加了资源碎片。(worst fit)
8. 另一种打分方案是，尽可能将已有任务的机器填满，这种方式可以是部分机器处于空置状态，可以
   减少了资源碎片，但是不利于资源需求评估不当的job，不利于负载突增的任务，也不利于等待资源
   空置时进行执行的批处理任务（机器上任务安排过于紧凑，得不到空置资源）。(best fit)
9. Borg采用的打分方案混合了worst fit和best fit。
10. 当被选中的机器上资源不足时，从优先级最低的任务开始抢占，直到资源满足。
11. 任务的启动延迟中位数是25s，80%的时间是加载任务的文件包，主要是因此磁盘写入速度的限制。
    因此,scheduler优先考虑已经缓存了任务文件包的机器。

1. Borgmaster轮询Borglet来获取机器状态，以及发送请求，由borgmaster控制通信，去掉对流量控制
   （flow conrol)的需要，并可以防止系统恢复时产生请求风暴。
2. 多个非Leader的Borgmaster副本都是无状态的，各自自动分管一批Broglet。
3. borglet回报的是全量状态，负责的borglet收到后，将计算出的增量提交给Borgmater Leader。
4. borglet与Borgmaster失联时，master将对应机器标记为宕机，并将任务迁移。borglet恢复后，
   在Borgmaster的指示下删除对应的task。
5. 所有的Borgmaster宕机，不影响已经在运行的task

1. 单个Borgmaster可以管理几千台机器，每分钟处理上万个任务
2. 一个忙碌的Borgmaster，使用10-14个CPU，50G内存。
3. 早期的Borgmaster是同步串行运行的，后来将调度拆分到一个单独的进程中。
4. 调度进程自己缓存了一份cell的状态数据
5. 调度器采用乐观并发，即积极向master提交任务，master允许或者拒绝
6. 借鉴了Oemega，正在增加不同的调度器来处理不同的任务类型.
7. borglet通信、以及处理只读rpc的处理，在单独的线程中运行. 99%的UI查询响应在1s之内
   95%的borglet轮询响应在10秒之内
8. 机器的打分过程是很消耗资源的，Borg缓存了机器的评分，直到属性发生变卦时，才更新评分
   资源使用量的微小变动会被忽略，防止缓存频繁失效
9. job中的多个task都是等价的，因此调度时只需要做一次选机器和评分操作。
10. 选机器时，是随机的挑选一批机器进行核实，直到选出足够的机器
11. 实验结果，将一个cell中的所有任务调度一次需要的是几百秒。单个实时调度在半秒内完成。

1. 自动重新调度被驱逐的任务
2. 将一个job的task跨宕机区域调度，例如跨机器、跨机架、跨供电域
3. 限制task的中断频率，限制一个job中可以关闭的task数量
4. 用户提交的最终期望的状态，发送的请求是幂等的
5. 限制重新调度task的速率，避免大规模宕机或者网络割裂导致大量调度
6. 避免将任务分配到曾经多次导致任务失败的机器上
7. 跟踪记录每个任务的日志，即使任务被重新分配到另一个机器上
8. Borgmaster的可用性是99.99％

1. 用cell的压实度评估，即在指定的任务量下，一个cell最少需要的机器数量。
2. 不同优先级的任务（生产、测试）运行在同一个cell中，否则需要增加20～30%的机器。
3. 生产环境中任务通常都会多声明资源，这些多出的资源大部分时间是闲置的。
4. 所有用户共享cell，否则cell的数量需要增加2～16倍，机器需要增加20～150%。
5. 在一台机器上添加一个task，会使机器上其它task的每条CPU指令的执行周期(CPI)增加0.3%
6. CPU使用率增加10%，CPI增加不到2%
7. 多种类型的任务混合的cell的CPI比任务类型单一的cell的CPI要高出3%
8. 在专用的cell中，borglet的执行速度是共享cell的1.19倍

1. 建立大规模的cell，可以支持大规模的计算，并且减少碎片
2. 如果使用多个小规模的cell，要比一个大规模的cell耗费更多的机器

1. CPU单位百万分之1核(milli-cores)，这里的核是hyperthread
2. 内存和磁盘是字节
3. 设置固定的资源模版会增加30～50%的资源需求

1. Borgmaster会评估一个task真实需要的资源数量，并将其多申请的资源分配给对资源要求较低任务，例如批处理。
2. task的保留资源开始时等同于它所申请的资源，维持300秒，然后逐渐降低到它实际使用的资源数量。
3. 如果实际使用的资源开始上升，那么task保留资源数量也会快速上升。
4. 生产中的任务调度时计算的已有任务的申请资源，非生产环境中任务调度时，计算的是已有任务的保留资源。
   一个任务的保留资源<=任务申请的资源，差额为被回收的资源
5. 当时机器上的资源需求过载时，杀死后限制非生产任务
6. 在一个中等规模的cell中，20%的任务使用的是被回收的资源
7. 实际使用的任务超出了limit的任务，在资源不足时，首先被抢占，无论它的优先级有多高。

1. 50%的机器运行了超过9个任务
2. 运行了25一个任务的机器中，90%的机器上有45000个线程
3. 使用linux 的chroot进行任务隔离，通过borgssh登陆任务的运行环境
4. 在GAE和GCE中还使用了vm和沙盒技术，vm使用的是kvm。
5. 所有的任务运行在基于cgroup的container中，但还是有一些低层次资源的竞争，譬如内存带宽、L3缓存。
6. 任务的划分维度：低延迟的和其它、可压缩的资源(内存、磁盘带宽、CPU)和不可压缩的资源(内存和磁盘空间)
7. 如果任务使用不可压缩资源超过限制，立即被按照优先级由低到高的顺序终止。
8 .如果任务使用的可压缩资源超过限制，borglet压缩资源
9. borglet的通过预测为生产任务分配内存，依据内存使用情况，为非生产的任务分配内存，内存超过时OOM
10. 低延迟任务可以独占一个物理CPU
11. 动态调整低延迟任务的资源，防止其它任务得不到处理
12. 改进了Linux Kernel的CPU调度器

1. Cluster中的Central Manager负责调度
2. Cluster中的Execute Server承担任务

1. Central Manager->Master Daemon: 管理进程
2. Central Manager->Scheduler: 裁断任务的调度策略
3. Central Manager->Collector: 收集Execute Server的机器和任务状态
4. Central Manager->Http Server: 提供浏览器查询

1. Execute Server->Master Daemon: 管理进程
2. Execute Server->Start Deamon: 
	1. 接收Central Manager下发的任务
	2. 创建执行任务的进程(注意: 任务进程是其子进程)
	3. 根据Central Manager指令管理任务进程
	4. 将任务进程状态上报Central Manager
	5. 定期上报物理机状态
3. Execute Server->Http Server: 提供浏览器查询

1. Central Master使用主备机制
2. Execute Server被监控
3. ZooKeeper提供强一致性

1. 用户通过Submitter(Torca客户端)从Central Manager获取任务状态、提交任务、管理任务等。
2. 任务的属性和资源需求通过任务描述文件说明。
3. 任务的依赖文件(程序体)存放在共享文件系统(XFS)中, Execute Server主动拉取。
4. 通过名字服务(Torca naming service)获得任务的服务地址(IP:Port)

1. 共享文件服务(XFS)中断导致任务的依赖文件无法获取, 正在转向Execute Server间的p2p减少XFS的依赖.
   (评: 使用p2p没有必要, 存储的问题就应当有存储来解决) 
2. Torca通过retry/migrate保证任务的执行。
3. Torca将任务的异常状态实时通知到指定人员(email、短信等)。

1. 任务的隔离:  在Execute Server上使用LXC技术进行隔离
2. 资源的分配算法: [Unkown: 详情未知]
3. 资源碎片:       [Unkown: 详情未知]
4. 任务资源的出让和回收: [Unkown: 详情未知]
   (任务空闲时出让计算资源, 负载上升时回收计算资源)
5. 任务峰值时所需资源的满足:  树状container  [Unkown: 详情未知]
6. Torca的冷升级: 任务自动迁移
7. Torca的热升级: 记录进程的checkpoint, 升级后从checkpoint恢复

各种分布式框架部署在独立的集群中, 集群的计算资源不能有效利用。

将所有的分布式框架部署在同一个集群中, 动态调整各个框架对集群资源的占用, 实现集群的复用。

分布式框架种类多, 原理与类型存在差异, 而且未来还会有新的框架不断出现。

双层调度设计(two-level Scheduler)
Mesos负责将可用的计算资源交付给Framework, 由Framework自行调度它所接收的资源。
Framework使用完毕后将资源归还给Mesos, Mesos将其分配给其它的Framework, 从而提高资源的利用率。

1 Master负责计算资源在Framework间的分配
2 Slave承担实际的计算任务

在Slave上使用容器技术进行隔离。

1. Master使用主备方式容灾
2. zookeeper

Job的容灾由Framework解决

1. 注册Framework: 将实现了调度策略的Scheduler和承担task的Executer提交到Mesos.
2. 提交Job:  将Job提交到注册在Mesos中的Framework

Mesos: Master向Framework发送Resource Offer
Omega: scheduler可以看到全局状态, 直接抢占资源。

kube::etcd::start --> etcd -name test --data-dir ?? -addr ??
apiserver -v=? --address=? --port=? --etcd_servers=? --portal_net=? --cors_allowed_origins
controller-manager -v=? --machines=? --master=?
kubelet -v=? --etcd_servers=? --hostname_override=? --address=? --port=?
proxy -v=? --master=?
scheduler -v=? --master=?