一个性能不佳的 GPU 可能会降低整个分布式训练作业的速度。节点可以通过基本的运行状况检查并显示正常利用率,让操作员在工作负载运行后才发现问题。
这些问题可能会在集群生命周期的任何时候出现。GPU 集群在节点替换、驱动程序补丁和容量增加时,在移交更改时通过就绪性检查。未经重复验证,原始认证将不再反映集群的状况。
这种可见性缺口浪费了对故障节点的计算,并导致健康节点出于谨慎而闲置。利用率指标可以隐藏这些损失。有效输出 (Goodput) ,即成功完成的工作量,可提供更有用的集群效率衡量标准。保持集群就绪状态需要在集群的整个运行生命周期中进行验证,包括在配置更改之后、容量增长以及修复后的节点恢复服务之前。
NVIDIA DSX AI 工厂平台整合了用于设计、构建和运营高效、弹性 AI 工厂的技术。其开源软件层 NVIDIA DSX OS 包含用于配置、认证和维护加速 Kubernetes 基础架构运行状况的工具。
- 配置:NVIDIA AI 集群运行时 (AICR) 为 GPU 优化的 Kubernetes 基础设施建立可复制的基准。
- 为网络、存储和驱动程序等组件定义版本锁定配置方案。
- 将配方渲染为现有部署工具的捆绑包。
- 认证:NVIDIA 集群就绪引擎 (NVCRE) 验证集群是否已准备好运行生产工作负载。
- 使用 AI 工作负载和诊断测试 GPU、网络和存储。
- 记录认证结果并帮助识别有故障的节点。
- 操作:NVSentinel 监控集群运行状况,并支持故障修复和重新验证。
- 根据 GPU、节点和网络运行状况发布节点条件。
- 配置后,系统会封锁或污染不健康的节点,消除工作负载并修复故障。
- 可以在节点返回服务之前使用 NVCRE 触发重新验证。
以上三个项目均为开源项目,在 Apache 2.0 下获得许可,欢迎外部贡献。
开始之前,请按照 AICR、NVCRE 和 NVSentinel 的安装指南安装和配置它们。这些示例假设访问 Kubernetes GPU 集群,并配置了所需的 CLI、控制器、依赖项和 NVCRE 测试提供程序。
此演练遵循一个集群的整个生命周期:从配方配置、生产使用前的认证、运行期间的监控以及维修后的重新认证。每个命令都是该序列中的一个步骤。
配置:您可以重现的基准
AICR 在版本控制的文件中定义集群的软件基准,并将其渲染为现有部署工具所应用的构件。它会生成和验证数据;您的部署人员会应用这些数据并对其进行调节。声明性模板有助于检测手动更改造成的配置漂移,并在维修后保持节点配置的一致性。
您描述了目标环境。AICR 会根据经过验证的叠加库对其进行解析,并发出 recipe:
aicr recipe --service eks --accelerator h100 --os ubuntu \
--intent inference --platform dynamo -o recipe.yaml
生成的 recipe 中的每个组件条目都固定了一个版本,并声明在安装组件之前哪些依赖项必须正常:
apiVersion: aicr.run/v1alpha2
componentRefs:
- name: dynamo-platform
chart: dynamo-platform
namespace: dynamo-system
source: https://helm.ngc.nvidia.com/nvidia/ai-dynamo
type: Helm
version: 1.4.2
valuesFile: components/dynamo-platform/values.yaml
dependencyRefs:
- grove
- cert-manager
- kube-prometheus-stack
- gpu-operator
- kai-scheduler
该 recipe 包含三个关键属性:
- 固定版本:固定版本可帮助您重现软件配置并调查故障。相比之下,浮动标签可以随着时间的推移指向不同的软件版本,从而使故障更难以重现。
- 依赖关系图:
dependencyRefs声明必须首先安装且运行良好的内容。AICR 在渲染捆绑包时解析图形,因此排序已在您的部署程序应用的构件中进行了编码。您无需在 NVSentinel 之前指定 cert-manager,稍后添加组件也无需重新编号。 - 每个组件的运行状况主张:每个条目都携带一个
healthCheckAsserts块,该块在安装后运行,并检查组件是否符合其配置的运行状况标准。Kubernetes 可以将卡在CrashLoopBackOff中的 POD 报告为Running,因此仅基于 POD 阶段的检查可能会遗漏损坏的组件。已发送的声明会过滤容器的等待原因,而不是仅在 pod 阶段进行过滤。
渲染 recipe 是一个单独的步骤,可将 AICR 连接到您现有的工作流:
aicr bundle --recipe recipe.yaml --deployer argocd --output ./bundles
--deployer 接受 helm、argocd、argocd-helm、flux 或 helmfile,因此经过验证的相同 recipe 会变为 Argo CD Application manifests、Flux 资源、Helmfile 版本图或普通 Helm 命令。您可以保留现有的部署工具,并使用 AICR 生成其配置构件。
由于 recipe 是一个文件,因此您可以使用版本历史记录、代码审查和漂移检测来管理基准。
# Check a live cluster against the recipe's constraints
aicr validate --recipe recipe.yaml
# Compare a golden baseline against the live cluster, non-zero exit on drift
aicr diff --baseline ./golden.yaml --target cm://default/aicr-snapshot --fail-on-drift
--fail-on-drift 可将漂移检查转换为持续积分 (CI) 门,而非报告。
认证:证明集群将运行作业
集群现已按照已知基准构建。它仍然需要工作负载验证。标准运行状况检查确认基本服务正在运行。他们无法确认集群是否可以通过其互联技术运行要求严苛的多节点作业,而不会出现卡顿。NVCRE 通过运行训练任务和 NVIDIA 集合通信库 (NCCL) 测试来验证工作负载就绪情况。
NVSentinel 可管理验证请求、调度门、隔离和维修,而 NVCRE 则运行测试并记录结果。表 1 显示了这些责任如何融入节点验证生命周期。
| 步骤 | 负责组件 | 行动 | 结果 |
|---|---|---|---|
| 1. 请求和门 | NVSentinel 生命周期管理器;用于升级或更改结构的运算符 | 为新建或修复的节点创建 ValidationRequest。升级或更改结构后,操作员会封锁节点并创建请求。 |
在验证期间,封锁或污染会阻止节点上的调度。 |
| 2. 测试和属性 | 从 NVCRE 到 nvcre-provider |
运行工作负载和诊断测试。对故障组进行划分,以识别可疑节点。 | 测试结果可识别可疑节点。NVCRE 不会更改节点状态。 |
| 3. 记录并评估 | NVCRE 和 NVSentinel 生命周期管理器 | NVCRE 在 Certification 资源中记录通过/ 失败结果、失败节点 ID 和失败原因。生命周期管理器会评估结果。 |
验证结果决定是否可以删除调度门。 |
| 4. 解决门问题 | NVSentinel 生命周期管理器 | 根据验证结果和任何剩余测试,删除或保留调度门。 | 在没有其他测试支持节点时,通过: 会删除已配置的门。重试后失败: 保持节点处于封锁状态。 |
认证可识别要测试的节点、要运行的类别,以及确定测试是否通过的值:
apiVersion: nvcre.nvidia.com/v1alpha1
kind: Certification
metadata:
name: gpu-cluster-cert
spec:
target:
nodeSelector:
nvidia.com/gpu.present: "true"
categories:
- domain: communication
variant: nccl-all-reduce
- domain: training
variant: nemotron5-8b
options:
thresholds:
busBandwidthGBps: "value >= 300"
nvcrectl certification run --cert-file certification.yaml --wait
nvcrectl certification report gpu-cluster-cert -n <namespace>
该报告显示每个类别的状态、运行时、测量带宽以及任何故障节点的原因。
值使认证成为性能的门户。默认情况下不会配置任何数据。如果没有上面的 options.thresholds 块,则运行会报告其测量值,但在测试无法开始时失败。低于目标执行的节点可以通过。值有助于捕捉性能下降而不是崩溃。
该目录涵盖 NCCL 通信变体、NVIDIA Data Center GPU Manager (DCGM) L4 级诊断套件,以及使用 NVIDIA NeMo 框架 (包含 80 亿和 560 亿参数模型) 的预训练工作负载。WorkloadRun 资源可将您自己的容器化测试转变为认证检查。NVCRE 从目标节点中推断出其余部分,因此清单文件在任何受支持的平台上都保持简洁。
这些测试有助于识别遥测中不明显的性能问题。低于其性能目标运行的 GPU 可能不会产生 Xid 错误、违反监控值或导致节点指标异常。一个 GPU 可能会将同步训练作业的速度减慢到最慢的等级,操作员可能会在几小时后发现,或者在用户投诉后才发现。NCCL 带宽测试可以发现这种性能下降的情况。
找出原因同样重要。如果 64 个节点的 all-reduce 产生的带宽较差,则每个节点都很可疑,并且手动对分可能非常耗时。NVCRE 会拆分失败的组,并重新运行测试,直到达到最小组大小,然后报告可疑节点及其原因。
先运行 NVCRE,然后再将集群或新容量交给租户,然后在修复后的硬件重新加入池。
操作:负载下的检测和补救
认证集群目前正在运行工作负载,需要保持正常运行。AICR 和 NVCRE 提供时间点验证。NVSentinel 与工作负载一起持续运行。
NVSentinel Watch 会向集群发出以下信号:DCGM 运行状况检查、Xid 错误、网卡 (NIC) 状态和云提供商维护事件。它不消耗 GPU 时间,因此 GPU 可用于工作负载。
默认情况下,NVSentinel 安装在监控模式下:它会将故障报告为节点状况,不会封锁、驱逐或修复节点。您可以在实时集群上部署,同时评估其报告。一旦您信任报告的信号,就可以启用隔离、排水和补救。
检测会发布运行状况事件;故障隔离规则集决定节点的运行状况。规则集在值文件中使用通用表达式语言 (CEL) 表达式:
fault-quarantine:
ruleSets:
- enabled: true
version: "1"
name: "GPU fatal error ruleset"
priority: 100
match:
all:
- kind: "HealthEvent"
expression: "event.agent == 'gpu-health-monitor' && event.componentClass == 'GPU' && event.isFatal == true"
- kind: "Node"
expression: |
!('k8saas.nvidia.com/ManagedByNVSentinel' in node.metadata.labels &&
node.metadata.labels['k8saas.nvidia.com/ManagedByNVSentinel'] == "false")
cordon:
shouldCordon: true
taint:
key: "nvidia.com/gpu-error"
value: "fatal"
effect: "NoSchedule"
封锁或污点会发出信号,让您的调度程序、警报和生命周期工具无需直接与 NVSentinel 集成即可使用。
通过限制可在滑动窗口中隔离的 GPU 节点数量,电路开关可以限制这种影响。“故障隔离” 配置指南涵盖边界和规则集选项的其余部分。
并非每个断层都有相同的路径。已知的致命错误可直接用于补救。健康事件分析器通过检测节点故障历史记录中的模式来处理其他情况,因此,反复失败的节点有资格根据累积记录而不是任何单一事件进行调查。
具有推荐操作 CONTACT_SUPPORT 的健康事件需要人工调查或支持干预。
循环:准备就绪如何变得持续
节点发生故障并得到修复,需要重新加入池。在节点返回服务之前进行验证会关闭操作循环,但手动传递会中断进程。手动认证会产生时间点结果,导致常规操作过时。有人必须注意到集群发生了变化,重新运行验证,然后读取输出并采取行动。NVSentinel 和 NVCRE 可以帮助实现此过程的自动化。
配置后,两个生命周期事件会自动触发重新验证。NVSentinel 生命周期控制器会在节点加入集群时创建 ValidationRequest,并在节点修复后返回时再次创建。它使用封锁或污点将调度控制在节点上,然后使用 NVCRE 运行测试并记录结果。控制器会评估这些结果,并在测试通过后移除门,因此仍未能通过验证的节点无法以静默方式重新加入池。将 nvcre-provider 配置为其测试提供程序时,这些测试是 NCCL 或通过 NVCRE 运行的 NVIDIA Nemotron:
global:
lifecycleManager:
enabled: true
fault-quarantine:
validation:
enabled: true
lifecycle-manager:
config:
schedulingGate:
cordon:
remove: true
lifecycle-manager 图表启用新节点验证;fault-quarantine 标志单独选择进行修复后验证。schedulingGate.cordon 将 cordon 设置为验证的调度门,而 remove: true 会在节点测试通过后解除其封锁。
对于就地驱动升级、操作员升级或结构更改,该流程有所不同。这些更改不会自动触发验证。由于基准是一个文件,当实时集群偏离其 recipe 时,aicr diff --fail-on-drift 在工作流阶段失败,从而触发在进行更改的同一工作流中运行认证。
封锁受影响的节点,然后创建验证请求,为其命名并运行测试:
apiVersion: nvsentinel.nvidia.com/v1alpha1
kind: ValidationRequest
metadata:
name: post-driver-upgrade
spec:
nodes:
- name: node-a
- name: node-b
tests:
- nccl-all-reduce
- nemotron-5b
控制器也会对结果起作用。如果请求通过,它会在没有其他测试支持节点时删除调度门。如果测试在重试后失败,节点将保持处于封锁状态。
在验证过程中也会出现故障:GPU 可能会在训练测试期间开始散热。NVSentinel 隔离节点,控制器在修复后重试测试。节点一直受到监控,直到验证通过。
请求和节点都带有您可以查询的状态:
kubectl get validationrequests
kubectl get nodes -l nvsentinel.nvidia.com/validation-state=validation-failed
恢复不需要手动修改节点:稍后的请求通过相同的测试,即可清除故障并移除门。删除所有引用节点的失败验证请求,无需重新运行验证即可将其释放。
交接边界清晰明了。NVCRE 会停止追踪,记录哪些节点发生故障及其原因;NVSentinel 拥有隔离和维修权限。两个系统封锁同一节点可能会产生双重封锁和非同步清理。
这种分离还允许您使用自己的节点生命周期工具。平台团队可以使用相同的认证结果并接管 NVSentinel 的角色。扩展堆栈意味着编写规则集或策略,而不是派生项目。
这对运算符有何影响
AICR、NVCRE 和 NVSentinel 可帮助操作员实现可重复的配置、验证和恢复。启用修复和生命周期验证后,NVSentinel 可以在节点恢复服务之前协调修复和测试,从而减少人工交接。表 2 概述了这些工具处理的内容以及操作员仍在管理的内容。
| 操作任务 | 哪些变化 | 运营商仍需管理的内容 |
|---|---|---|
| 保持软件基准 | AICR 提供版本锁定的方法,并为现有部署工具生成配置构件。操作员可以查看与定义的基准的偏差。 | 批准基准更改、部署构件、运行漂移检查并调节差异。 |
| 验证新建或修复的容量 | NVCRE 运行选定的工作负载和诊断,并记录就绪情况结果。通过配置生命周期验证,NVSentinel 可以在节点恢复服务之前协调测试。 | 选择适合集群的测试和值,并调查失败结果。 |
| 恢复不正常的节点 | 启用 NVSentinel 后,NVSentinel 会协调隔离、清空、修复和重新验证,从而减少这些操作之间的手动切换。 | 定义隔离规则、补救限制和上报程序;处理自动修复无法解决的故障。 |
| 验证基础架构更改 | 运营商可以将基准检查和工作负载验证整合到升级工作流程中。 | 在就地更改驱动程序、操作员或结构后触发验证;这些更改不会自动触发重新验证。 |
开始使用
从项目资源库开始获取安装说明和示例:
您还可以:
- 参加与 NVIDIA DSX OS AI 推理和贡献者研讨会 一起举办的 KubeCon + CloudNativeCon North America,亲身体验这些工具。需要单独报名,席位有限。
- 欢迎造访 KubeCon 上的 NVIDIA 170 号展位,了解更多 Kubernetes 深度解析和现场演示。
- 加入DSX AI Factory Slack 社区,继续对话。
- 在 NVIDIA DSX AI Factory GitHub 中探索开源、模块化组件。