Facebook 集群调度管理系统

一系列分析计算机和软件工程领域论文的文章，我们在这个系列的每一篇文章中都会阅读一篇来自 OSDI、SOSP 等顶会中的论文，这里不会事无巨细地介绍所有的细节，而是会筛选论文中的关键内容，如果你对相关的论文非常感兴趣，可以直接点击链接阅读原文。

本文要介绍的是 2020 年 OSDI 期刊中的论文 —— Twine: A Unified Cluster Management System for Shared Infrastructure[^1]，该论文实现的 Twine 是 Facebook 过去十年生产环境中的集群管理系统。在该系统出现之前，Facebook 的集群由为业务定制的独立资源池组成，因为这些资源池中的机器可能有独立的版本或者配置，所以无法与其他业务共享。

Twine 的出现解决了不同资源池中机器配置不同的问题，提供了动态配置机器的功能，这样可以合并原本独立的资源池，提高资源整体的利用率，在业务申请资源时可以根据需要配置机器，例如：改变内核版本、启用 HugePages 以及 CPU Turbo 等特性。

ubernetes 是今天十分热门的集群管理方案，不过 Facebook 的方案 Twine 却做出了与 Kubernetes 相反的决策，实现了截然不同的解决方案。需要注意的是使用 Kubernetes 并不一定意味着要使用静态集群、私有节点池和大容量机器，我们仍然可以通过引入其他模块实现动态集群等特性，只是 Kubernetes 本身不支持这些设计。我们在这篇文章中仅会讨论上述三大决策的前两个以及 Twine 如何实现水平扩容、管理大规模的集群。

架构设计

作为可以管理上百万机器、支撑 Facebook 业务的核心调度管理系统，Twine 的生态系统非常复杂，我们在这里简单介绍该系统中的一些核心组件：

器(Scheduler)：对应 Kubernetes 中的控制器，它负责管理工作负载的生命周期，当集群出现硬件故障、日常维护等情况时会推动系统做出响应;

应用程序调度器(Application-Level Schedulers)：对应 Kubernetes 中的 Operator，如果我们想使用特殊的逻辑管理有状态服务，需要实现自定义的调度器;

分配器、调度器和应用程序调度器是 Twine 系统中的核心组件，然而除了这些组件之外，生态中还包含前端界面、优化集群工作负载的平衡器和指定特定业务容量的服务。在了解这些具体组件之后，这里我们围绕文章开头提出的动态集群和自定义配置展开讨论 Twine 的设计。

动态集群

Twine 的动态集群建立在其抽象出的权利(Entitlement)上，每个权利集群都包含一组动态分配的机器、属于特定业务的伪集群。数据中心中的机器和任务

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!