在 90 年代早期,David Culler 领导下的伯克利 NOW(工作站网络)项目提出,可以使用性能较低的机器组(运行 SunOS)来解决科学和其他计算问题,而成本仅为大型计算机的一小部分。1994 年,Donald Becker 和 Thomas Sterling 通过采用当时新兴的 Linux 操作系统在 NASA 戈达德太空飞行中心构建贝奥武夫集群,进一步降低了成本。通过将桌面机器与 PVM(并行虚拟机)、MPI(消息传递接口)和 PBS(可移植批处理系统)等开源工具连接在一起,早期的集群——通常是将 PC 塔堆放在金属架子上,并用一堆电线相互连接——从根本上改变了科学计算的平衡。在这些早期集群出现之前,分布式/并行计算仅在少数计算中心、国家实验室和极少数大学部门中流行。自从集群引入以来,分布式计算现在实际上无处不在。
然而,集群也存在着丑陋的现实。工具的缺乏意味着构建 16 或 32 台机器紧密协同工作是一项英雄般的系统工程。开源软件的文档记录通常很差(而且往往仍然如此),并且缺乏更成熟的商业产品在“大型机器”上提供的关键功能。通常需要几个月才能启动并运行一个集群,并且需要训练有素的专家才能使其达到这种状态。应用程序在这些廉价机器上合理运行(如果能运行的话)需要更长的时间。
尽管如此,构建可扩展且廉价计算的潜力太大了,不容忽视,整个社区也变得更加成熟,直到集群成为高性能计算领域的主导架构。中型集群现在大约有 100 台机器,大型集群由 1,000 台机器组成,而最大的超级计算机是更大的集群机器。对于 HPC(高性能计算)而言,集群已经到来。其中大多数是基于 Linux 的或商业 Unix 衍生产品,前 500 名机器中的大多数运行的是 Linux 衍生产品。现在出现了一种更好的硬件集成趋势,即刀片服务器。这有助于消除大量的布线混乱。
过去 12 年的集群经验磨练了社区的技能——许多人可以制造出“MPI 盒子”(支持消息传递并行应用程序的同构硬件),并且有几种软件工具可以理解集群,并允许非专业人员在几个小时内从裸机(例如,您最喜欢的计算硬件公司的集群 SKU)到由数百个独立节点(计算机)组成的功能集群。在国家超级计算应用中心,Tungsten2 集群(512 个节点)从下订单到全面投入生产不到一个月,并且在 2005 年 6 月成为世界上 50 个最快的超级计算机之一。
集群的问题似乎已经解决,但它们的巨大成功意味着每个人都想用它们做更多的事情。虽然保留了 HPC 的根基,但 Web 服务器集群、平铺显示墙、数据库服务器和文件服务器正变得司空见惯。现代机房中的几乎每个实体本质上都是集群架构。构建一个专门的 MPI 盒子(经典的贝奥武夫集群)只是支持计算研究人员需求所需内容的一个小子集。
早期的集群对于专家来说是易于管理的,因为所有硬件都是相同的(以这种方式购买是为了简化事情),并且集群中的每个节点只运行一个软件堆栈。为了构建这些机器,专家通过细致的手工系统管理,仔细地创建了一个“模型”节点。然后,他或她获取此模型的映像,并将位克隆到所有其他节点上。当需要更改时,将构建一个新的模型,并重新克隆节点。社区了解到,为了使集群应用程序正常运行,软件必须在所有节点上保持一致。已经使用了各种机制和底层假设来实现不同程度的成功。一致性本身并不是难以解决的问题,但随着基础设施复杂性的增加,实现一致性变得更加重要。
现代机房复杂性的原因不仅仅在于所有节点都是特定逻辑集群的一部分,还在于每个集群都需要不同的软件配置。在我们开发的用于快速配置和管理集群的 Rocks 软件中,我们将这些配置称为 appliance(设备)。如果每个设备都有自己的“手工制作”模型,则集群的成本将急剧上升,跨集群的安全策略的统一性与集群专家将更改统一应用于所有模型节点的能力相关联,并且每个(子)集群必须使用相对相同的硬件。这种以管理员为主导的模型会导致企业中的不一致性,并且过于依赖人类的“湿件”,而真正需要的是一种程序化的方法。
为了使此讨论更具体,我们描述了一种名为 CAMERA(用于高级海洋微生物生态学研究和分析的社区网络基础设施)的新资源,我们正在与 J. Craig Venter 研究所合作构建。CAMERA(http://www.camera.calit2.net)的目标是为新兴的元基因组学领域的计算生物学家构建一个社区资源,该资源最初侧重于微生物群落的研究。CAMERA 提供物理资源,以实现跨各种基因序列数据的搜索和比较。
CAMERA 最初填充了 Venter 研究所 Sorcerer II 探险收集的全球海洋调查数据1(其中使用鸟枪法测序对来自 200 个海洋站点的微生物群落进行测序,这被证明是人类基因组测序的关键推动因素)和其他关键基因组数据集,CAMERA 提供了一个“科学目的地”,科学家可以在其中通过计算方式搜索多个数据集,下载原始样本,并为社区注释基因序列。在底层,必须部署真实的硬件、应用程序、数据服务器等,以提供平滑的计算引擎。当用户在 CAMERA 门户提交一个简单的 BLAST2 查询时,一组后端服务器必须协同工作以执行分析。对于用户而言,这种复杂性必须是隐藏的,这样该站点才能成为有用的工具。
图 1 说明了定义 CAMERA 的逻辑集(设备)和物理机器集,包括 Web 应用程序服务器、数据库服务器、平面文件服务器、计算集群(经典的贝奥武夫)、单点登录网格证书服务。在图中所示的 CAMERA 集群机房中,计算节点构成了一个经典的贝奥武夫集群。应用程序、数据库、可视化、存储、身份验证和数据库设备完善了系统。
CAMERA 从 BIRN(生物医学信息学研究网络;http://www.nbirn.net)3 借用了许多安全性和 Web 容器基础设施,并且随着时间的推移,将整合其他项目共有的软件的很大一部分。CAMERA 特有的结构包括应用程序数据库、Web 应用程序以及特定的计算生物学工具和数据库,例如 BLAST、HMMER4 和 PFAM5。与 BIRN 一样,CAMERA 必须支持基础设施的持续演进,并定义用于开发和生产的池。虽然定义所有这些不同的设备需要大量的跨领域专业知识,但 CAMERA 的定义方式使得单个系统工程师可以快速部署整个系统。
今天的 CAMERA 在其集群机房中定义了 10 种不同且独特的设备,其初始部署由近 200 台不同的物理机器组成,每台机器都必须定义为承担特定的角色。这正是这个门户网站和许多其他计算门户网站固有的复杂性所在——不同的应用程序对底层系统软件有大量的要求,并且必须正确配置每台机器或设备,整个门户网站才能正常工作。用最简单的术语来说,这归结为为特定设备选择合适的软件进行安装,然后正确配置所有软件组件。
在您查看典型的 Unix(或 Windows)服务器并看到需要 700 多个软件包(数万个文件)和数百个配置更改才能正确定义任何一台机器之前,这听起来并不太困难。对于 CAMERA,简单的乘法运算表明,在 10 个设备的复杂系统中,需要 7,000 个软件包和 2,000 个配置更改才能正确定义。对于 200 台物理机器,这些数字膨胀到 140,000 个软件包和 40,000 个配置更改。集群机房中的关键问题是在处理所有必需的逻辑设备的大量配置更改的同时,还要处理持续不断的软件更新流。
此外,为了使许多大型集群应用程序可靠地工作,特定计算中使用的所有节点都需要一个核心软件(例如,库、服务、内核和其他项目),使其具有相同的修订级别和配置。跨独立的最终用户工作站的企业进行延迟更新效果很好,但通常会为用于并行计算的大量机器集合引入太多的不确定性。
解决此问题的经典方法是由系统管理员团队手工制作每个设备的配置,然后使用磁盘克隆或磁盘映像方法来构建类似的设备集群。对于经典的贝奥武夫集群(又名 HPC 集群),如果您恰好拥有现场系统管理专业知识来构建头节点和计算节点配置,这实际上是可行的。对于集群机房,这是不可行的——一个精明的管理员需要花费数天或数周的时间来制作任何特定计算设备的配置。如果您在 CAMERA 上安排一个由 10 名管理员组成的团队,您可能可以在一周内制作出 10 个设备,但随后您必须注意设备之间的一致性,因为所有机器必须协同工作才能形成一个工作和分布式系统。实际集群系统的复杂性已经远远超过了通常的系统定义和管理方法。
Rocks(http://www.rocksclusters.org)是一个开源集群构建工具包,在过去六年内开发完成。它已被用于构建数千个集群,并拥有一个庞大而活跃的电子邮件讨论列表(超过 1,500 名订阅者)。CAMERA(和其他团队)使用 Rocks 作为应对集群机房挑战的基本工具。Rocks 与大多数系统配置和管理工具的区别在于,它管理的是系统描述,而不是已安装软件的位映像6。当 Rocks 在五年多前开始时,最先进的管理方式是依赖集群管理员将系统的操作系统和配置作为“黄金”磁盘映像进行管理。此映像是根据站点和单个机器本地化要求手动配置的。
另一方面,Rocks 将所有软件作为本机操作系统软件包进行管理,并将这些软件包的选择和配置用于特定节点,作为两个不同的实体:完整的操作系统发行版和 Rocks 配置图7。操作系统发行版是可以安装在任何特定机器上的所有软件的并集。配置图选择哪些软件包将安装在特定机器上,以及如何精确配置该软件。配置图对于打破集群机房中规模的暴政至关重要。本质上,该图允许不同的设备共享其各自配置的重要部分。虽然单个设备需要数百个软件更改才能正常运行,但其中许多更改在特定站点的设备之间是通用的。一个新的设备可能只需要添加或更改十几个左右的配置参数。
图 2 显示了 Rocks 配置图的两种表示形式。此图中的颜色表示提供配置的 roll(Rocks 的基本构建块)。不同的颜色表示不同的 roll:黄色和绿色 roll 包括核心 Rocks 功能,蓝色和紫色表示生物信息学和 SGE(Sun 网格引擎)roll。
roll 本身是一组二进制软件包和一个子图,该子图连接到主图(在图 2 的右侧表示)。完整的图由管理员在构建时选择的所有 roll 定义和组成。roll 中的二进制软件包提供基本构建块;roll 提供的节点描述软件包以及如何配置它们;roll 提供的图边指示应包含哪些节点以用于特定的设备类型。所有 roll 的这种组合是自动且透明的,对最终用户而言。在 Rocks 中,即使操作系统(在我们的示例中,是一个 Red Hat 兼容的 Linux 基础)也被定义为一个仅包含软件包的 roll。完整集群的这种基本分解以及将这些构建块重新组合为程序的能力,提供了核心系统的程序化可扩展性,而无需每个集群都配备专家系统管理员。
在图 2 中,左侧的图简化了 Rocks 如何定义服务器和计算设备,通过扩展每个连接节点中包含的指令来定义。您可以看到,Rocks 服务器设备(集群中的主机器)包括前端、生物服务器、SGE 服务器、基本、生物基本和 SGE 基本配置的所有功能,而 Rocks 计算设备包括客户端、生物客户端、SGE 客户端、基本、生物基本和 SGE 基本配置的所有功能。还要注意,使用了四个独立的 roll 来构建此复合图。在完整的图中,设备之间的通用性非常高,通常只需要少量的节点进行区分。右侧的图显示了 CAMERA 项目的完整配置图(单个图中大约有 200 个节点)。该图包括以下设备的规范:前端服务器、计算节点、数据库服务器、Web 应用程序、安全凭证处理服务器、NFS 服务器和平铺显示节点。构建特定 Web 应用程序服务器的具体细节是以编程方式捕获的,因此是可重现的,而不是每个节点都配备超级管理员。
Rocks 从头开始控制所有设备的配置,这意味着通过遍历配置图,在所有机器上执行完整的操作系统安装(数据分区不会被破坏)。捕获如此多样的设备类型的完整配置一直是 Rocks 的一项主要工作,并且将随着人们发明更复杂的系统架构而继续进行。以这种方式构建操作系统使我们始终能够从相同的初始系统状态(空集)开始,并以可预测的最终状态结束。此观察结果对于理解这允许集群机房中设备之间的可重现性和兼容性至关重要。该图实际上是整套设备的源代码;安装相当于编译源代码。
要构建任何 Rocks 设备的描述,程序从一个特定的已知点进入图(该图是一个多根树,树的根是图的入口点),并开始扩展图的每个节点中的指令。这些指令包括要加载的软件包,以及这些软件包的配置。一旦图被遍历,就完成了特定设备的完整描述。然后,此描述被传递给本机安装程序(例如,用于基于 Red Hat 的机器的 Anaconda),该安装程序执行这些指令。安装完成后,特定的设备即可投入工作。虽然配置图的绑定与 Linux(尤其是 Red Hat)松散地联系在一起,但正在努力抽象化这种绑定,并使 Rocks 操作系统中立。Solaris 是正在定位的第一个操作系统。
毋庸置疑,需要大量的基础设施才能使这项工作正确进行。此基础设施本身被捕获为一个不同的设备:前端(或头)节点。有多种方法可以引导 Rocks 配置的集群机房,我们支持从一组 CD 构建,以及通过网络安装。引导过程构建一个内存图,并使用相同的程序化结构。
Rocks 的核心是可扩展性。Roll 允许我们使用新功能扩展任何 Rocks 集群。添加功能(例如经典贝奥武夫的队列系统)就像在引导时插入所需的队列系统 roll 一样简单。从那里开始,配置是自动且程序化的。所有这些过程都有助于将集群机房分解为可管理的位,然后可以将这些位重新组合成新系统。
Rocks 挑战了将已安装的计算机视为特殊事物的传统观念——事实上,我们提倡对任何特定节点进行完全重新安装,而不是补丁管理,以管理任何系统。任何桌面用户都熟悉消息“Windows 刚刚下载了重要更新并已重新启动您的计算机”,以及如果笔记本电脑需要更换时的同样恐惧感,因为可能需要数周才能“使其恰到好处”。我们认为,在这种非常常见的情况下,基本问题在于数据(您真正关心的内容)和操作该数据的程序(完整的操作系统和应用程序)被可怕地交织在一起。定期重新安装操作系统具有有益的效果,即实际上将应用程序数据与应用程序二进制文件分开。
集群机房在扩展配置方面提出了重大挑战。在构建 CAMERA 等复杂端点时,系统的相互依赖性意味着本地应用神奇管理员的“一切照旧”的方式根本行不通。Rocks 是我们实现捕获配置复杂系统的专业知识并允许任何人重现我们构建的任何系统的方案。
有趣的是,单个程序(甚至编程环境)的架构师都具有源代码控制以及构建和测试方案,以便他们可以在多种环境中重现其二进制最终产品。许多商业和开源项目都具有自动化的夜间“检出、构建、测试”方案,这些方案不需要编程团队仔细手工制作每个编译。令人好奇的是,在现代系统中,这种严谨性通常不适用于定义任何计算机系统(包括您的桌面)的程序总和。问
PHILIP PAPADOPOULOS 是加州大学圣地亚哥分校圣地亚哥超级计算机中心的网格和集群计算项目主管,并参与了包括 BIRN(生物医学信息学研究网络)、OptIPuter、GEON(地球科学网络)和 PRAGMA(环太平洋地区应用和网格中间件大会)在内的关键研究项目。他获得了加州大学圣巴巴拉分校的电气工程博士学位。他曾在橡树岭国家实验室工作五年,是 PVM(并行虚拟机)开发团队的成员。他还因开发开源 Rocks 集群工具包而闻名。
GREG BRUNO 是 Rocks 的核心开发人员,Rocks 在加州大学圣地亚哥分校圣地亚哥超级计算机中心开发。在 Rocks 项目之前,他在 Teradata Systems 工作了 10 年,为支持全球最大数据库的系统开发集群管理软件。他是 UCSD 的博士候选人,在那里他正在研究异构磁盘如何影响并行文件系统。
MASON KATZ 是加州大学圣地亚哥分校圣地亚哥超级计算机中心的集群开发组组长,他的主要重点是 Rocks 集群发行版。他活跃于 PRAGMA(环太平洋地区应用和网格中间件大会)。他还曾在亚利桑那大学从事网络安全协议 (IPSec) 和操作系统 (x-kernel, Scout) 的研究,并在商业领域担任实时嵌入式软件工程师。
最初发表于 Queue 第 5 卷,第 3 期—
在 数字图书馆 中评论这篇文章
Marc Brooker, Ankush Desai - AWS 的系统正确性实践
构建可靠且安全的软件需要一系列方法来推理系统正确性。除了行业标准测试方法(例如单元测试和集成测试)之外,AWS 还采用了模型检查、模糊测试、基于属性的测试、故障注入测试、确定性模拟、基于事件的模拟以及执行跟踪的运行时验证。形式化方法一直是开发过程的重要组成部分——也许最重要的是,作为测试预言机的形式化规范,为 AWS 的许多测试实践提供了正确的答案。正确性测试和形式化方法仍然是 AWS 的关键投资领域,这些领域已经看到的投资回报加速了这一趋势。
Achilles Benetopoulos - 数据中心计算机的中间表示
我们已经到了分布式计算无处不在的地步。内存应用程序数据大小正在超过单台机器的容量,因此需要将其在集群上进行分区;在线服务具有高可用性要求,只有通过将系统部署为多个冗余组件的集合才能满足这些要求;高持久性要求只能通过数据复制来满足,有时甚至跨越广阔的地理距离。
David R. Morrison - 模拟:分布式系统中未充分利用的工具
模拟在 AI 系统的出现中发挥着巨大的作用:我们需要一种高效、快速且经济高效的方式来训练 AI 代理在我们的基础设施中运行,而模拟绝对提供了这种能力。
Matt Fata, Philippe-Joseph Arida, Patrick Hahn, Betsy Beyer - 公司到云端:Google 的虚拟桌面
超过四分之一的 Googler 使用内部、数据中心托管的虚拟桌面。这种本地产品位于公司网络中,允许用户在世界任何地方远程开发代码、访问内部资源和使用 GUI 工具。在其最显着的特点中,虚拟桌面实例可以根据手头的任务调整大小,具有持久的用户存储,并且可以在公司数据中心之间移动以跟随出差的 Googler。直到最近,我们的虚拟桌面都托管在使用名为 Ganeti 的自研开源虚拟集群管理系统的 Google 公司网络上的商用硬件上。今天,这项重要的且对 Google 至关重要的工作负载在 GCP(Google Compute Platform)上运行。