借助 NVIDIA DGX Spark Enterprise 可管理性，大规模控制 AI 基础设施的生命周期

随着 AI 基础设施的扩展，企业对运营成熟度的期望与日俱增。组织期望这些系统具备可配置、可观察、安全且可大规模管理的特点，所有关键基础设施都采用相同的标准。当 AI 系统从开发阶段进入企业部署阶段时，这一运营基础至关重要。

NVIDIA DGX Spark 和 NVIDIA GB10 系统通过新的企业可管理性奠定了这一基础。如本文所述，企业可管理性为企业 IT 团队提供了从首次调配到生命周期结束结束的完整运营框架，包括对完全空隙和不连接部署的支持。

DGX Spark Enterprise 可管理性如何集成到现有 IT 工作流中？

DGX Spark 可管理性框架提供模块化堆栈，旨在集成到企业 IT 团队已经使用的工具中，而不是取而代之。目前从企业可管理性角度支持 DGX Spark 的 NVIDIA 合作伙伴包括 Progress Chef、Perforce Puppet 和 Canonical Landscape。

操作模型有意简单：无代理 SSH 执行，有边界的标准 JSON 输出。无需常驻管理代理即可在 DGX Spark 端点上运行。相反，IT 团队通过 SSH 调用工具，每个工具都会返回一个标准化的 JSON 包络，该包络可直接集成到 CMDB、SIEM 和监控流程中。无论在哪个编排平台上运行，模式都是相同的。

该框架附带生产工具和参考脚本，按以下六个运营生命周期阶段进行组织：

1. 采购和接收：为 CMDB 捕获稳定的设备标识符、序列号和接收到的硬件快照
2. 初始调配：基准硬件、固件、驱动程序和软件清单；SSH 可达性；注册元数据
3. 持续监控：持续运行状况检查、根据记录的基准进行漂移检测、重置原因分析
4. 维护窗口：在更改窗口内进行受控更新和重启编排，并提供分阶段推出和回滚安全性
5. 事件响应：定向 L1 分诊或完整的 L2 诊断捆绑包集合，用于上报
6. 生命周期结束/ 级联和重新调配: 使用产销监管链证据、报废文件进行出厂重置

该框架有意将收集器 (只读、无权限、可安全频繁运行) 与控制器 (状态更改、使用最低权限 sudo 进行门控，需获得变更管理审批) 分开。该设计直接映射到企业 IT 如何管理访问。

DGX Spark 自定义安装如何实现已知的良好配置？

在企业 AI 部署中，很大一部分操作复杂性来自于从一开始就让系统处于已知的良好状态，而不是来自于运行环境。在限制或禁止直接访问互联网的环境中尤其如此。

DGX Spark 自定义安装直接解决了这一难题。在宏观层面，它使企业 IT 团队能够：

• 预配置设备，无需运行开箱即用体验
• 首次从 USB 驱动器或本地服务器启动之前，请先自定义软件
• 支持联网设备和空隙设备

在幕后，这些模式依赖于云初始化、安装 USB 驱动器上的 OEM 数据分区和置备 Hook 脚本。此外，还可以使用可选的本地镜像，用于完全通风的车队。

这使得使用标准企业工具维护完全气隙的 DGX Spark 机群变得切实可行。除了内部服务器或 USB 驱动器之外，不需要自定义基础架构。如需了解全套安装模式以及何时使用每种模式，请参阅企业可管理性文档。

DGX Spark Enterprise 可管理性如何帮助诊断？

DGX Spark 可管理性框架提供专为可观察性、诊断和事件响应而设计的诊断工具。远程诊断 AI 基础设施故障通常成本高昂。固件回归、PCIe 问题和意外重置等事件都需要在确定根本原因之前收集证据，而在不中断正在运行的系统的情况下大规模收集这些证据并非易事。

可管理性框架提供了两种旨在应对这些挑战的诊断工具：spark_diagctl.py 和 reset_reason_reporter.py。

spark_diagctl.py 是框架中的主要诊断工具。它是通过 SSH 远程运行的单个脚本，可让 IT 团队监控任何 DGX Spark 系统的运行状况和状态，而无需物理访问或常驻代理。它以两种模式运行：

• L1 (运行状况)： 返回包含磁盘、网络和驱动程序状态的边界 JSON 运行状况摘要。它快速、安全地频繁运行，并直接集成到自动监控中，而不会产生大量伪影。
• L2 (深度证据包)： 为事件升级生成完整的诊断包。其中包括 GPU 遥测、内核日志、硬件事件、PCIe 状态、固件信息和崩溃诊断。该捆绑包在设备上作为构件生成；该工具通过标准输出返回指针，以便在需要时按需拉取构件。

reset_reason_reporter.py 解决了 AI 基础设施中更为持久的诊断挑战之一：解释系统重启的原因。该工具会关联多个证据来源 (系统事件日志、BMC 记录、内核循环、固件事件) ，并生成结构化的根本原因评估。它刻意使用保守的分类，标记模糊性而不是猜测，使输出对于事件分类和稳定性趋势更可靠。

这两种工具都会发出相同的 JSON 包络格式。这意味着，运行状况检查的同一 Ansible 剧本、Tanium 包或横向脚本也可以触发事件响应收集，而不会更改集成层。

如何跨 DGX Spark 集群协调多层更新管理

保持 AI 系统的最新状态可能具有挑战性。DGX Spark 汇集了紧密合的层：内核、GPU 驱动程序、固件、容器运行时、AI 框架和安全补丁。任何一层的更新失败都会破坏环境的稳定。还需要在变更管理窗口中进行更新，并提供适当的回滚选项。

spark_updatectl.py 是更新控制平面。它以 JSON 报告的形式显示系统当前的更新状态。其中包括需要更新的软件包、适用的固件更新以及重启是否待处理等项目。然后，它提供受控更新操作，与维护窗口调度进行协调。它支持跨设备环的分阶段部署、预检查和后检查证据捕获，以及固件回滚可见性。

该工具旨在由团队已经使用的任何编排平台驱动。Ansible 剧本可以查询整个车队的更新状态，识别滞后的系统，并使用适当的审批门分阶段更新，所有这些操作都使用与框架其余部分相同的无代理 SSH 执行模型。

DGX Spark 的企业级安全保护范围是什么？

企业 AI 系统越来越多地拥有专有模型、敏感数据集和内部知识产权。安全状况必须可审计，合规性证据必须按需提供。该框架自始至终将安全性视为首要要求。

具体功能包括：

• 经过验证的启动完整性：检查安全启动和经过验证的启动信号，生成存储在设备上的每次运行证据以进行审核检索
• 加密静态状态报告：报告磁盘加密状态，并提供符合安全审计保留要求的证据 (建议超过 180 – 365 天)
• APT 签名验证：根据合规性上下文验证软件包签名完整性，每次运行都会生成清晰的通过/ 失败/ 未知结果以及详细证据
• 通过监管链进行出厂重置：生成适用于受监管处置或调配工作流程的结构化停用证明 (包括方法、时间和成功/ 失败状态)
• UEFI 支持的资产元数据标签：一项可选功能，可将持久性资产元数据直接写入 UEFI 存储，即使在重新安装操作系统的过程中也能实现可靠的车队库存

RBAC 的设计自始至终都体现了最低权限模型。收集器工具 (仅读取状态的工具) 在不提升权限的情况下运行。控制器工具 (用于修改状态的工具) 需要显式的 sudo 授予特定操作的范围。这清晰地映射到企业环境中的角色分离，在这些环境中，变更管理和只读访问是分开管理的。

Canonical Landscape 集成为将现有 Ubuntu 车队管理操作扩展到 DGX Spark 提供了切实可行的途径。这些参考脚本涵盖了完整的安全和生命周期层面：签名验证、验证启动、备份级别、出厂重置、运行状况看门狗、支持包收集、日志检索和静态加密报告。已经为其他 Ubuntu 基础架构运行 Landscape 的组织可以将 DGX Spark 引入相同的操作视图，而无需构建单独的管理层。

开始使用 NVIDIA DGX Spark Enterprise 可管理性

企业 AI 基础设施承载了企业的期望。在 AI 系统投入生产后，调配、可观察性、安全状态验证、合规性证据和生命周期管理并非可有可无。

DGX Spark Enterprise 可管理框架旨在满足您所在 IT 团队的需求：使用他们已经使用的编排工具，在他们已经实施的安全和变更管理策略范围内运行，以及管理系统可能与公共互联网完全断开连接。请持续关注，以更深入地了解特定的企业可管理性功能。

准备好开始了吗？下载以下指南：

• DGX Spark 可管理性指南：车队载入、调配、监控、维护、事件响应和停用。包含适用于 Canonical Landscape 的集成模式和参考脚本，以及适用于所有 11 种生产工具的完整参考代码图。
• 使用 Cloud-Init 自定义安装 DGX Spark: 基于 USB 的安装、本地 APT 存储库设置、LVFS 固件镜像、OEMDATA 分区布局、云初始化配置和完整的参考脚本。

这两个指南都是作为运营参考而构建的，其中包含具体示例、集成模式和生产就绪型示例脚本，旨在适应每个团队已经制定的工具和策略。有关其他文档，请访问 DGX Spark Enterprise 可管理性。