当前位置: 首页 > 科技观察

Facebook集群调度管理系统·OSDI2020

时间:2023-03-19 01:19:43 科技观察

《看论文》是分析计算机与软件工程领域论文的系列文章。在本系列的每篇文章中,我们都会阅读一篇来自OSDI和SOSP等顶级会议的论文。论文中的论文,这里不会详细介绍所有的细节,而是会筛选出论文的重点内容,如果你对相关论文非常感兴趣,可以直接点击链接阅读原文。本文介绍的是2020OSDIJournal上的论文——Twine:AUnifiedClusterManagementSystemforSharedInfrastructure[^1],它实现了Twine作为Facebook在过去十年的生产环境中的集群管理系统。在该系统出现之前,Facebook的集群由为业务定制的独立资源池组成,因为这些资源池中的机器可能有独立的版本或配置,因此无法与其他业务共享。Twine的出现解决了不同资源池中机器配置不同的问题,提供了动态配置机器的功能,可以合并原本独立的资源池,提高资源的整体利用率,在申请资源时按需配置机器。例如:更改内核版本,启用HugePages和CPUTurbo等功能。图1-Twine设计决策Kubernetes是当今非常流行的集群管理解决方案,但Facebook的解决方案Twine做出了与Kubernetes相反的决策,实现了完全不同的解决方案。需要注意的是,使用Kubernetes并不一定意味着使用静态集群、私有节点池、大容量机器。我们仍然可以通过引入其他模块来实现动态集群等特性,但Kubernetes本身并不支持这些设计。在本文中,我们将只讨论以上三个主要决策中的前两个,以及Twine如何实现水平扩展和管理大规模集群。架构设计Twine的生态系统非常复杂,作为可以管理百万台机器并支撑Facebook业务的核心调度管理系统。这里我们简单介绍一下系统中的一些核心组件:图2-TwineEcosystemAllocator:对应Kubernetes中的调度器,负责为工作负载分配机器。它在内存中维护所有机器的索引和属性,并使用多线程处理资源的调度和分配;调度器(Scheduler):对应Kubernetes中的控制器,负责管理工作负载的生命周期。当集群出现硬件故障、日常维护等情况时,会驱动系统做出响应;Application-LevelSchedulers:对应Kubernetes中的Operator。如果我们想使用一个特殊的有状态服务的逻辑管理需要自定义调度器的实现;分配器、调度器和应用程序调度器是Twine系统的核心组件。但是,除了这些组件之外,生态还包括前端接口和优化的集群工作负载。指定特定业务容量的平衡器和服务。在了解了这些具体的组件之后,这里我们围绕文章开头提出的动态集群和自定义配置来讨论Twine的设计。DynamicClustersTwine的动态集群建立在其抽象的Entitlement之上,每个entitlement集群包括一组动态分配的机器和属于特定服务的伪集群。数据中心机器和任务之间的这一抽象层使机器的分配更加动态:图3-任务、权利和数据中心分配器不仅会将机器分配给权利集群,还会对集群中的相同权利工作负载进行调度到特定的机器。需要注意的是,我们在这里简化了Twine中的模型。Facebook的数据中心将由数十个主配电板(MainSwitchboard,MSB)组成,它们具有独立的供电和网络隔离。机器可以被视为属于同一个集群。自定义配置私有节点池不利于机器共享,但确实有很多业务对机器的内核版本和配置有要求,例如:很多机器学习或数据统计任务需要使用LinuxHugePages来优化性能,但HugePages可能会损害在线服务的性能。图4-主机配置Twine由此引入了主机配置的概念,为每个正确的集群绑定独立的主机配置,当数据中心的一台机器被分配到一个伪集群时,它会根据集群的配置更新机器,为工作负载提供了最能满足需求的运行环境,使得Facebook内部Web层的服务性能提升了11%,这是目前的Kuberentes无法满足的。集群规模Facebook的集群规模目前全球领先。虽然目前集群规模还没有超过百万,但是随着业务的快速发展,Twine很快就需要支持百万级的物理机管理。它将通过以下两个原则支持这个数量级的节点:根据集群的权限通过分片进行水平扩展;通过关注点分离减少调度系统的工作量;sharding是集群或系统实现横向扩展最常见的方式,Twine为了支持横向扩展,sharding是基于权限集群的维度;作为一个虚拟集群,Twine可以在不重启机器任务的情况下在分片之间迁移权限集群。但是跨权限集群的迁移需要滚动更新的支持。图5-Schedulersharding通过分片,集群管理系统的横向扩展变得非常简单,Twine在最大的分片中管理着170,000台机器,这与Kubernetes支持5,000个节点的能力相差近两个数量级。除了分片,联邦也是解决集群管理规模的有效手段。Kubernetes社区的联邦可以让同一个任务运行在多个独立的集群中,可以支持多地域、混合云甚至多云部署。但是由于跨集群同步需要信息,所以实现起来比较复杂;Twine的调度器可以在分片中的机器不足时动态迁移新机器,因此可以使用单个调度器来管理一个服务的所有副本。两种方案的优缺点这里不再赘述。读者可以自行思考,但笔者还是更倾向于通过federation来管理多个集群。关注点分离Kubernetes是中心化架构,所有组件都会从集群中的APIserver读取或写入信息,所有数据都存储在一个独立的持久化存储系统中,而中心化架构和存储系统也成为了Kubernetes的瓶颈集群管理。Twine在设计上尽可能避免中心化的存储系统,将各个组件的职责分离,拆分为调度器、分配器、资源代理、健康检查服务和主机配置服务,每个服务也有独立的存储系统,可以避免单一存储系统带来的扩容问题。综上所述,在Kubernetes大行其道的今天,看到Facebook分享其内部集群管理系统的不同设计是非常有意义的,这让我们重新思考Kubernetes中设计所带来的潜在问题,例如:中心化的etcd存储,许多大公司使用Kubernetes会选择修改etcd的源代码或者更换存储系统,以便让它管理更多的节点。Kubernetes对于集群规模较小的公司还是有很大好处的,它确实可以解决集群管理中95%的问题。Kubernetes不是灵丹妙药,它不能解决场景中的所有问题。在应用Kubernetes时,中小企业可以完全接受Kubernetes的架构和设置,而大公司可以基于Kubernetes做一些定制,甚至参与标准的制定,以增加技术影响力,提高话语权,帮助支持。公司业务增长。[^1]:TangC、YuK、VeeraraghavanK等。Twine:共享基础设施的统一集群管理系统[C]//第14届{USENIX}操作系统设计与实现研讨会({OSDI}20)。2020:787-803。本文转载自微信公众号《没有逻辑》,作者EmbeddedSystems。转载本文请联系真诺逻辑公众号。