『看一下毕业论文』是一系列剖析电子计算机和软件开发行业毕业论文的文章内容，我们在这一系列产品的每一篇文章上都会阅读文章一篇来源于 OSDI、SOSP 等顶会中的毕业论文，这儿不容易事无大小地详细介绍全部的关键点，只是会挑选毕业论文中的重要內容，假如你对有关的毕业论文十分很感兴趣，能够立即点一下连接阅读。
文中要详细介绍的是 2020 年 OSDI 刊物中的毕业论文 —— Twine: A Unified Cluster Management System for Shared Infrastructure[^1]，该毕业论文完成的 Twine 是 Facebook 以往十年工作环境中的群集智能管理系统。在该系统软件发生以前，Facebook 的群集由为业务流程订制的单独资源池构成，由于这种资源池中的设备很有可能有单独的版本号或是配备，因此 没法与别的业务流程共享资源。
Twine 的发生解决了不一样资源池中产品配置不一样的难题，出示了动态性配备设备的作用，那样能够合拼本来单独的资源池，提升 資源总体的使用率，在业务申请資源时能够依据必须配备设备，比如：更改内核版本、开启 HugePages 及其 CPU Turbo 等特点。
图 1 - Twine 设计方案管理决策
Kubernetes 是今日十分受欢迎的群集管理制度，但是 Facebook 的计划方案 Twine 却作出了与 Kubernetes 反过来的管理决策，完成了迥然不同的解决方法。必须留意的是应用 Kubernetes 并不一定代表着要应用静态数据群集、独享连接点池和大空间设备，大家依然能够根据引进别的控制模块完成动态性群集等特点，仅仅 Kubernetes 自身不兼容这种设计方案。我们在本文中仅会探讨所述三大管理决策的前2个及其 Twine 怎样完成水准扩充、管理方法规模性的群集。
架构模式
做为能够管理方法几百万设备、支撑点 Facebook 业务流程的关键生产调度智能管理系统，Twine 的生态体系比较复杂，大家在这儿简易详细介绍该系统软件中的一些关键部件：
图 2 - Twine 生态体系
调节器(Allocator)：相匹配 Kubernetes 中的生产调度器，承担为工作中负荷分派设备，它在运行内存中维护保养了全部设备的数据库索引和特性并应用线程同步解决資源的生产调度分派;
生产调度器(Scheduler)：相匹配 Kubernetes 中的控制板，它承担管理方面负荷的生命期，当群集发生硬件配置常见故障、日常维护保养等状况的时候会促进系统软件作出回应;
应用软件生产调度器(Application-Level Schedulers)：相匹配 Kubernetes 中的 Operator，如果我们想应用独特的逻辑性管理方法有情况服务项目，必须完成自定的生产调度器;
调节器、生产调度器和应用软件生产调度器是 Twine 系统软件中的关键部件，殊不知除开这种部件以外，绿色生态中还包括前面页面、提升群集工作中负荷的平衡装置和特定特殊业务流程容积的服务项目。在掌握这种实际部件以后，这儿大家紧紧围绕文章开头明确提出的动态性群集和自定配备深入探讨 Twine 的设计方案。
动态性群集
Twine 的动态性群集创建在其抽象性出的支配权(Entitlement)上，每一个支配权群集都包括一组动态分配的设备、归属于特殊业务流程的伪群集。大数据中心中的设备和每日任务中间创建其的这层抽象性使设备的分派越来越更为动态性：
图 3 - 每日任务、支配权和大数据中心
调节器不但会将设备分派给支配权群集，还会继续把同一个支配权群集中的工作中负荷生产调度到特殊的设备上。
必须留意的是，大家在这儿简单化了 Twine 中的实体模型，Facebook 的大数据中心会由几十个主配电设备板(Main Switchboard、MSB)构成，他们具备单独的能源供应和互联网防护，配电设备板上的设备能够看作归属于同一个群集。
自定配备
独享的连接点池很不利设备的共享资源，可是的确有很多业务流程对设备的内核版本和配备有规定，比如：许多深度学习或是数据分析的每日任务都必须应用 Linux 的 HugePages 提升特性，可是 HugePages 很有可能会危害在线客服的特性。
图 4 - 电脑主机配置
Twine 从而引进了电脑主机配置的定义，为每一个支配权群集关联单独的电脑主机配置，当大数据中心的设备被分派到某一伪群集时，会依据群集的配备升级设备，为工作中负荷出示最合乎要求的软件环境，这在 Facebook 内将 Web 层的服务项目特性提升 了 11%，也是现阶段的 Kuberentes 不能满足的。
群集经营规模
Facebook 的群集经营规模也是现阶段技术领先的，尽管现阶段的群集经营规模都还没提升上百万级，可是伴随着业务流程的迅速发展趋势，Twine 迅速就必须适用上百万等级的物理机管理方法，它会根据下边2个标准支撑点这一量级的连接点：
根据依照支配权群集分块的方法水准扩充;
根据分离出来侧重点降低智能监控系统的劳动量;
分块
分块是群集或是系统软件要想完成水准扩充的最普遍方法，Twine 为了更好地适用水准扩充就以支配权群集的层面分块;做为虚似群集，Twine 能够在分块中间转移支配权群集，不用重新启动设备上的每日任务，殊不知跨支配权群集的转移就必须翻转升级的适用了。
图 5 - 生产调度器分块
根据分块，群集智能管理系统的水准扩充就越来越非简易，而 Twine 较大的分块中管理方法了 170,000 台设备，这与 Kubernetes 可以适用 5,000 连接点对比有接近2个量级的差别。
除开分块以外，联邦政府也是处理群集管理方法经营规模的合理方式，Kubernetes 小区的联邦政府能够让同一个每日任务在好几个单独群集运作，能够适用多地域、云计算平台乃至阴天的布署，可是由于必须跨群集同歩信息内容，因此 完成相对性非常复杂;Twine 的生产调度器能够在分块中的设备不够时动态性转移新的设备，因此 能够应用单独生产调度器管理方法一个服务项目的全部团本。这儿也不探讨二种计划方案的好坏了，诸位阅读者能够自主思索，但是创作者還是趋向于根据的联邦政府管理方法好几个群集。
分离出来关心
Kubernetes 是一种去中心化的构架，全部的部件都是会从群集中的 API 网络服务器载入或是载入信息内容，全部的数据信息都储存在单独的长久分布式存储中，而去中心化的构架和分布式存储也变成了 Kubernetes 群集管理方法的短板。
Twine 在设计方案上尽量减少了去中心化的分布式存储并分离出来本来归属于单独部件的岗位职责，分拆到生产调度器、调节器、資源代理商、健康体检服务项目和电脑主机配置服务项目中，每一个服务项目也是有单独的分布式存储，这就可以防止单分布式存储产生的扩充难题。
小结
在 Kubernetes 盛行的今日，可以见到 Facebook 共享其內部群集智能管理系统的不一样设计方案還是有非常大实际意义的，这使我们再次思索 Kubernetes 中设计方案产生的潜在性难题，比如：去中心化的 etcd 储存，许多应用 Kubernetes 的大企业为了更好地让其可以管理方法更多节点，都是会挑选改动 etcd 的源码或是更换分布式存储。
Kubernetes 针对群集经营规模小的企业還是有非常大益处的，而其自身的确可以处理群集管理方法中 95% 的难题，Kubernetes 也不是银弹，它无法保证处理情景内的所有难题。在运用 Kubernetes 时，中小规模纳税人的企业能够整盘接受 Kubernetes 的构架和设置，而大企业能够在 Kubernetes 的基本上做一些订制，乃至参加到规范的制订中提升技术性知名度、提升 主导权而且协助支撑点公司业务发展。
[^1]: Tang C, Yu K, Veeraraghavan K, et al. Twine: A Unified Cluster Management System for Shared Infrastructure[C]//14th {USENIX} Symposium on Operating Systems Design and Implementation ({OSDI} 20). 2020: 787-803.
文中转载微信公众平台「真没有什么逻辑性」，创作者嵌入式操作系统。转截文中请联络真没有什么逻辑性微信公众号。
