✨ 要点🔬 技术摘要
想象一个超级计算机就像大型高速火车站的世界。几十年来,这些车站都是为一种特定类型的乘客——“批处理”旅客而设计的。这些旅客是庞大且紧密排列的数据组,它们同时到达,在整个旅程中都待在同一个专用的车厢里,只有当整列火车任务完成后才会离开。这种系统对于传统科学来说运作得非常完美,但世界正在发生变化。现在,我们有了另一种类型的旅客:“云原生”乘客。他们是灵活的、独立的容器化数据,想要能够即时上下列车,安全地与其他陌生人共用车厢,并运行像 AI 聊天机器人或安全医疗数据库这样复杂的交互式应用。
问题在于,旧的火车站(传统的超级计算机)并不是为此设计的。它们擅长运送大规模货物,但在管理一个繁忙的、多租户的车站时表现得很糟糕,因为在那里每个人都需要拥有自己安全的空间。于是,Kubernetes 登场了。把 Kubernetes 想象成终极的交通调度员,专门负责这些容器化乘客。它是确保每个人都有座位、确保正确的人无法窥视他人的行李、并确保即使在成千上模不同的应用同时运行时车站仍能平稳运行的软件。但是,将这种灵活的交通控制器安装到僵化的高速超级计算机上,就像是试图在一个蒸汽机车内部安装现代地铁票务系统;这需要极其高超的工程魔法,才能让它们协同工作而不导致整个系统崩溃。
这篇论文讲述了一支工程师团队如何将这位现代交通调度员成功安装到世界上最先进的超级计算机之一——Isambard-AI 上的故事。他们不仅让它运转了起来,还通过两个截然不同且非常重要的任务测试了它。首先,他们构建了一个“受信任研究环境”(Trusted Research Environment),这就像是一个超级安全的玻璃房,科学家可以在其中查看敏感的医疗数据,而永远无法窃取或泄露这些数据。其次,他们搭建了一个 AI 模型“沙盒”,允许多位研究人员同时运行和测试强大的 AI 大脑,而不会互相干扰。
团队发现,他们的新系统运作得非常出色。他们证明了你可以在不降低超级计算机速度的情况下,运行这些灵活的多租户服务。事实上,当他们测试连接计算机的网络速度时,发现添加这个安全层仅增加了微乎其微、几乎可以忽略不计的延迟——大约 0.89 微秒。为了让你理解,这甚至比计算机的一次眨眼还要快。他们还展示了他们的设置可以处理大规模的 AI 模型,使其在多台计算机上运行并保持安全。
然而,这段旅程并非没有坑洼。团队发现了一个关键的硬件瓶颈:底层的网络卡(Cassini NICs)对能发放的“服务 ID”数量有严格限制。由于目前的系统会为每一个容器分配一个唯一的 ID,如果同时有太多用户尝试连接,车站面临着 ID 用尽的风险,从而导致系统停滞。此外,他们还发现当前设置中存在一个主要的安全性缺陷:为了访问高速网络,目前的“玻璃房”必须使用“特权”密钥来构建。这意味着安保人员实际上是在把车站的万能钥匙交给乘客,这削弱了系统原本旨在实现的隔离性。
虽然他们承认该系统的搭建过程仍然有些复杂,并且需要未来的进一步完善以解决这些硬件限制和安全漏洞,但他们已经证明,将云端的灵活性带入超级计算机的力量之中是完全可能的。这为未来打开了大门:科学家和 AI 研究人员可以在同一台强大的机器上共同工作,既安全又高效,而无需为每一种新类型的任务都去建造全新的硬件。
技术摘要:用于 AI、安全计算、数据服务及更多领域的多租户 Kubernetes 用例
问题陈述 传统的高性能计算(HPC)系统旨在处理由 Slurm 等调度器管理的紧耦合、大规模批处理工作负载,但在灵活性、服务抽象和多租户隔离方面缺乏支持现代多样化工作负载的能力。这些新兴用例包括 AI 模型训练与推理、敏感数据的安全沙箱以及机密计算。虽然 Kubernetes (K8s) 是云环境中多租户编排的标准,但将其部署在裸金属 HPC 系统上(特别是使用 HPE Slingshot 等先进高速织网的系统)并非易事。核心挑战在于如何协调 Kubernetes 的动态、临时资源模型与 Slurm 对稳定、专用硬件的假设,同时确保 RDMA(远程直接内存访问)平面(该平面绕过了标准的 Linux 内核网络栈)在不同租户之间保持安全的隔离。现有的集成尝试(例如 Slinky、Slurm Operator)通常难以应对延迟开销、阻抗失配以及为基于 MPI 的工作负载和高速互连提供无缝互操作性的根本困难。
方法论 作者在 Isambard-AI (IS-AI) 上实现并评估了一种“Kubernetes 即服务”的部署。IS-AI 是一个基于 HPE Cray EX 框架、配备 NVIDIA Grace-Hopper 超级芯片和 Slingshot 互连的英国国家主权 AI 研究资源。该部署旨在作为现有 Slurm 批处理调度器的补充,而非替代。
该方法论侧重于三个关键领域:
基于 Slingshot 的裸金属 Kubernetes 与多租户性:
团队将 Friese 等人 [6] 提出的网络隔离方案适配到了 IS-AI ARM64 架构上。
架构: 他们扩展了 CXI 驱动、CXI 库和 libfabric,将 CXI 服务限定在 Linux 网络命名空间内。这使得容器可以被分配不同的 CXI 服务和虚拟网络标识符(VNI),类似于 VLAN,从而确保织网隔离。
适配: 由于需要针对 IS-AI 环境进行特定补丁处理。由于 SmarterDeviceManager 未能在容器内挂载高速网络(HSN)netdev 设备(导致 libfabric 初始化失败),作者对 libfabric 的 netdev_lookup() 方法进行了补丁处理,使其改为读取环境变量(CXIP_DEFAULT_LINK、CXIP_DEFAULT_SPEED)而非 sysfs 条目。
编排: 他们部署了 RKE2、用于存储的 Longhorn 以及 NVIDIA GPU Operator。通过使用 Metacontroller 和 SmarterDeviceManager 实现了一个 VNI 服务,用于根据 Kubernetes 清单注解管理 VNI 预留和 CXI 服务创建。
受信任研究环境 (TREs):
团队部署了 FRIDGE (由数据治理扩展支持的联邦研究基础设施),这是一个符合 SATRE 标准的基于 Kubernetes 的 TRE。
实现: 利用 Pulfer 进行基础设施即代码(IaC)管理,配置了命名空间、RBAC 和网络策略。他们使用 MetalLB 进行负载均衡(通过 Layer 2 ARP 通告,因为无法使用 BGP)并使用 Cilium 进行网络策略管理。
安全性: 访问 Slingshot 的工作负载被分配专用的 VNI 以确保隔离。Longhorn 为静态数据提供了加密卷。Argo Workflows 被用于作业编排,其 WorkflowTemplates 经过预配置,能够挂载必要的 CXI 设备和库,从而将底层配置从用户端抽象化。
安全且多节点的模型托管:
作者使用 KubeRay 、Ray 和 vLLM 部署了一个分布式、沙箱化的 AI 模型托管服务。
镜像构建: 为了避免运行时开销和依赖问题,他们构建了一个多阶段自定义容器镜像。该镜像包含一个“感知织网”的基础镜像(含 libfabric(感知 netns)、NCCL 和 OpenMPI),随后是包含 PyTorch 和 vLLM 的推理镜像。
自动化: 他们利用 变异准入策略 (MAP) 自动为 RayCluster 资源添加 vni: "true" 注解。这会触发 VNI 服务分配资源,确保 RayCluster 中的所有 Pod 共享同一个 VNI 进行节点间通信。
核心贡献
部署基准: 在 IS-AI 上展示了一种可复现的部署多租户裸金属 Kubernetes 平台的方法,为在现有 HPE Cray EX 及未来 GX 基础设施上运行运维环境的加固方案提供了坚实的基准 。
网络隔离: 验证了一种使用网络命名空间和 VNI 在 Kubernetes 租户之间隔离 RDMA 流量的方法,防止了 Slingshot 织网上跨租户的干扰。
用例实现:
在超级计算机上实现了一个 SATRE 合规的受信任研究环境 (FRIDGE) ,实现了对敏感医疗和健康数据的安全分析。
建立了一个持久、沙箱化的 AI 模型托管服务 ,能够以动态资源分配的方式提供分布式大语言模型 (LLM) 服务。
软件构件: 提供了针对 libfabric 的特定补丁,以支持在没有 HSN netdev 挂载的情况下进行容器化环境运行,并演示了通过准入控制器将 VNI 分配与 Argo Workflows 及 KubeRay 进行集成的过程。
结果与评估
性能开销:
延迟: OSU 微基准测试显示,具有 VNI 隔离的 Kubernetes 容器与裸金属或 Podman 容器相比,存在约 0.89µs 的固定延迟开销(在小消息传输时,从 ~2.22µs 趋向于 ~3.11µs)。该开销归因于网络命名空间遍历,且不随消息大小而变化。
带宽: 对于大消息,峰值带宽达到了 Slingshot 织网的理论最大值 (200 Gb/s ),表明对于固定大小的开销不存在显著的吞吐量损失。
TRE 功能: FRIDGE 部署成功允许研究人员通过 Argo Workflows 提交作业,而无需手动进行 CXI 配置。然而,团队指出 VNI 预留不会在工作流完成后自动释放,这可能导致资源枯竭,通过强制执行 ttlStrategy 缓解了此问题。
AI 模型托管:
在 Meta-Llama-3.1-405B-Instruct-FP8 模型上的基准测试显示,该 K8s/VNI 技术栈的表现优于标准的 BriCS 和 vLLM 教程配置。
vni: "true" 配置实现的平均每输出 Token 时间 (TPOT) 和 Token 间延迟 (ITL) 低于其他设置的一半 。
每秒输出 Token 数 (TPS) 比 BriCS 配置提高了约 3 倍 。
系统实现了 120ms 的首个 Token 时间 (TTFT) 和 22 tokens/second,与同类硬件配置下的其他报告数据相当甚至更优。
意义与声明 本文声称为在现有 HPE Cray EX 和未来 GX 基础设施上运行运维环境的 Kubernetes 解决方案提供了坚实的基准 。作者强调,其工作证明了基于以太网兼容互连(如 Slingshot)的超级计算平台和类云端供应栈(如 CSM)可以支持多租户服务,而无需完全定制的、垂直集成的解决方案。
其意义在于证明了 Kubernetes 可以有效地补充传统的 HPC 调度器,以应对 AI 和安全数据处理等新兴且细分的用例。然而,作者对当前方案的现状保持了审慎态度,承认:
目前的实现运维复杂度较高 ,依赖于松散耦合的组件(Metacontroller、SmarterDeviceManager、VNI 服务),这些组件需要定制修改和进一步加固才能达到生产就绪状态。
需要社区维护的组件 ,例如 CXI Kubernetes 动态资源分配 (DRA) 驱动程序,以减轻运维负担。
未来需要实现清单增强的自动化(例如 VNI 注解、库挂载),并使用更稳健的替代方案(如 Akri 或专门的 DRA 驱动程序)来取代已过时的工具(如 SmarterDeviceManager)。
该工作并不声称要取代大规模 MPI 作业中的 Slurm,而是旨在建立一个互补的服务层,为“国家 AI 研究资源”提供安全、可复现且灵活的计算能力,以应对敏感及 AI 驱动的工作负载。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题,再试一次?
无垃圾邮件,随时退订。