18 May 2023

borg 论文于2015年发布,展示了borg从2005年开始的一系列工作和成果.后才有参考google参考borg开源出Kubernetes. borg和Kubernetes相同点是,都是大规模集群管理系统,区别是borg在google管理了所有的机器,包括在线和离线。而目前Kubernetes大多数管理的还是在线场景,离线场景还是hadoop系的天下。 学习 borg 可以更深入了解google的大规模集群管理经验。

特性

  • 透明化资源管理和故障处理,使业务能够更专心(注:这一点就类似当今的docker,以及未来的serverless)
  • 自身的高可用,运行在上面的应用也能达成高可用(注:和第一个特性其实很类似,都是通过平台蹭提供更多能力,让业务低成本实现高可用)
  • 可以将负载轻松得分散到成千上万的节点中(注:开源的k8s想要扩展到这么多节点还是挺麻烦的,要考虑主从同步下,主节点的负载问题。同样的问题会出现在所有的主从模式集群下)

job 分类

  • prod : prodcution job . 生产性任务,短时且延迟敏感的请求(从几微秒到几百毫秒不等).(注:k8s中的pod 概念,似乎就来源于此)。高优先级。比如gmail web 就是prod。 属于prod的任务:google search ,gmail web ,youtube ,google docs.
  • non-prod : non-prodcution job . 非生产性任务,运行时间从分钟到天,堆短期的波动不敏感. 低优先级。比如某些批处理任务就是non-prod,资源紧张时,会被kill 让出资源给prod job。

优先级

优先级分为(从高到低): 监控(monitoring),生产(production),批处理(batch),尽力而为(best effort)(测试或免费程序)

上面的分类中,prod对应的就是监控和生产。

配额

  • 在低优先级任务上启用超卖,以提升资源利用率
  • 尽管鼓励用户”按需”购买配额,但是用户依然会忍不住超量购买(注:所有资源都是这样,公司内的资源,以及每个人的手机,如果不加硬性的限制,那么就一定会被消耗光)
  • 没有提到类似k8s 使用的cfs 调度器

调度

调度就是一堆机器中,选出来一个”合适”的机器,部署相应的job

  • 异步调度,job被加入调度器的队列中
  • 通过调度器异步扫描队列,如果有足够的资源并且满足job的约束(比如非亲和性),就将job的task部署到相应的机器上。
  • 两种调度算法
    • 最优匹配 : 尽可能填满机器,分配时从小到大分配。。(分配过程类似jvm cms 的free-list)
    • 最差匹配 : 最小化部署任务的成本,避免负载突刺。可能会造成资源碎片。(注,比如机器上剩下了0.5core cpu,50m 内存,类似jvm mark-sweep中的内存碎片)
  • 实际是混合算法(根据实践,调度中会有非常多的约束,导致调度时间比想象上久。比如常见的约束:追求高可用的服务:一个服务在同一个宿主机上最多部署n个节点、追求高性能的服务:服务上下游部署在一个苏主机上;带来的问题:弹性伸缩过程中,必须考虑调度的时间消耗)

从节点状态同步

每个从节点上部署一个borglet 服务(kubelet的亲爹啊),master 定时几秒轮询borglet 获取状态(注:pull 模式,对客户端和服务端都非常友好)。

master可以自发控制频率,避免borglet在master压力高时,继续push数据到master从而压垮master(注:背压的常见解决方案)。

扩展性

主从结构总是会出现瓶颈,borg做了以下方面的扩展以避免出现性能问题

  • 拆分调度器和master,增加并行度
  • 缓存
  • 副本
  • 增加线程以改善响应性能
  • 分片
  • 评分缓存
  • 等效评分:按照约束条件做group,而不是针对每一个task单独做评分
  • 宽松随机化 : 严格模式下,需要抓取所有机器的状态来做评分,毕竟抓取间隔需要尽量短,这会导致状态同步和计算成本高。改进为随机抓取节点(注:这是一种类似p2c负载均衡的方式,能大小减少负载的同时,有尽量高的准确率)

可用性

  • 如果borglet异常退出,对应机器上的task会继续执行,因为borglet已经挂了,所以task不会被kill,而不会被转移。反而能保证task的可用性
  • cell 独立隔离部署,减小爆炸半径,降低误操作的和故障传播几率
  • 多副本防止单点故障

资源利用率

borg 的终极目标就是提升google全球机房的资源率,borg给google节约了30%的机器,每年几百万美元(注:2005年的几百万美元)

评估方法

  • 方法简单粗暴:不断移除cell中的机器,直到出现问题。
  • 使用线上数据来进行仿真

cell 共享

  • non-prod 和 prod 共同运行在一个cell中
  • 必须共享才能实现资源利用率提升,如果隔离开,需要多30%-50%的机器。prod通常会预留资源,但大多数机器不需要那么多机器。这些空闲的资源可以被non-prod有效利用

大型 cell

  • 专门为大型任务和减少资源碎片提供的cell。(注:这就是G1GC和ZGC中的 humongous region,条条大路通罗马)

隔离

  • 使用cgroup 来隔离资源。内存带宽或者cpu l3 cache污染都会导致rt出现问题。通过设置优先级,延迟敏感型任务可以挂起其他任务。
  • 资源分为可压缩资源(cpu,iops;基于速率)和不可压缩资源(mem,network,disk)。