公告：Facebook 集群调度管理系统 · OSDI 2020Twine:AUnifiedClusterManagementSystemforSharedInfrastructure，该论文实现的Twin
Twine:AUnifiedClusterManagementSystemforSharedInfrastructure，该论文实现的Twine是Facebook过去十年生产环境中的集群管理系统。在该系统出现之前，Facebook的集群由为业务定制的独立资源池组成，因为这些资源池中的机器可能有独立的版本或者配置，所以无法与其他业务共享。
Twine的出现解决了不同资源池中机器配置不同的问题，提供了动态配置机器的功能，这样可以合并原本独立的资源池，提高资源整体的利用率，在业务申请资源时可以根据需要配置机器，例如：改变内核版本、启用HugePages以及CPUTurbo等特性。
Kubernetes是今天十分热门的集群管理方案，不过Facebook的方案Twine却做出了与Kubernetes相反的决策，实现了截然不同的解决方案。需要注意的是使用Kubernetes并不一定意味着要使用静态集群、私有节点池和大容量机器，我们仍然可以通过引入其他模块实现动态集群等特性，只是Kubernetes本身不支持这些设计。我们在这篇文章中仅会讨论上述三大决策的前两个以及Twine如何实现水平扩容、管理大规模的集群。
架构设计
作为可以管理上百万机器、支撑Facebook业务的核心调度管理系统，Twine的生态系统非常复杂，我们在这里简单介绍该系统中的一些核心组件：
分配器（Allocator）：对应Kubernetes中的调度器，负责为工作负载分配机器，它在内存中维护了所有机器的索引和属性并使用多线程处理资源的调度分配；
调度器（Scheduler）：对应Kubernetes中的控制器，它负责管理工作负载的生命周期，当集群出现硬件故障、日常维护等情况时会推动系统做出响应；
应用程序调度器（Application-LevelSchedulers）：对应Kubernetes中的Operator，如果我们想使用特殊的逻辑管理有状态服务，需要实现自定义的调度器；
分配器、调度器和应用程序调度器是Twine系统中的核心组件，然而除了这些组件之外，生态中还包含前端界面、优化集群工作负载的平衡器和指定特定业务容量的服务。在了解这些具体组件之后，这里我们围绕文章开头提出的动态集群和自定义配置展开讨论Twine的设计。
动态集群
Twine的动态集群建立在其抽象出的权利（Entitlement）上，每个权利集群都包含一组动态分配的机器、属于特定业务的伪集群。数据中心中的机器和任务之间建立其的这层抽象使机器的分配变得更加动态：
分配器不仅会将机器分配给权利集群，还会把同一个权利集群中的工作负载调度到特定的机器上。
需要注意的是，我们在这里简化了Twine中的模型，Facebook的数据中心会由几十个主配电板（MainSwitchboard、MSB）组成，它们具有独立的电力供应和网络隔离，配电板上的机器可以看做属于同一个集群。
自定义配置
私有的节点池很不利于机器的共享，但是确实有很多业务对机器的内核版本和配置有要求，例如：很多机器学习或者数据统计的任务都需要使用Linux的HugePages优化性能，但是HugePages可能会损害在线服务的性能。
Twine由此引入了主机配置的概念，为每个权利集群绑定独立的主机配置，当数据中心的机器被分配到某个伪集群时，会根据集群的配置更新机器，为工作负载提供最符合需求的运行环境，这在Facebook内将Web层的服务性能提高了11%，也是目前的Kuberentes无法满足的。
集群规模
Facebook的集群规模也是目前世界领先的，虽然目前的集群规模还没有突破百万级，但是随着业务的快速发展，Twine很快就需要支持百万级别的物理机管理，它会通过下面两个原则支撑这个数量级的节点：
通过按照权利集群分片的方式水平扩容；
通过分离关注点减少调度系统的工作量；
分片
分片是集群或者系统想要实现水平扩容的最常见方式，Twine为了支持水平扩容就以权利集群的维度分片；作为虚拟集群，Twine可以在分片之间迁移权利集群，不需要重启机器上的任务，然而跨权利集群的迁移就需要滚动更新的支持了。
通过分片，集群管理系统的水平扩容就变得非简单，而Twine最大的分片中管理了170,000台机器，这与Kubernetes能够支持5,000节点相比有将近两个数量级的差距。
除了分片之外，联邦也是解决集群管理规模的有效手段，Kubernetes社区的联邦可以让同一个任务在多个独立集群运行，可以支持多地区、混合云甚至多云的部署，但是因为需要跨集群同步信息，所以实现相对比较复杂；Twine的调度器可以在分片中的机器不足时动态迁移新的机器，所以可以使用单个调度器管理一个服务的所有副本。这里就不讨论两种方案的优劣了，各位读者可以自行思考，不过作者还是倾向于通过的联邦管理多个集群。
分离关注
Kubernetes是一种中心化的架构，所有的组件都会从集群中的API服务器读取或者写入信息，所有的数据都存储在独立的持久存储系统中，而中心化的架构和存储系统也成为了Kubernetes集群管理的瓶颈。
Twine在设计上尽量避免了中心化的存储系统并分离原本属于单个组件的职责，拆分到了调度器、分配器、资源代理、健康检查服务和主机配置服务中，每个服务也有独立的存储系统，这就能够避免单存储系统带来的扩容问题。
