两个月前我们还在用文本编辑器逐个维护每台裸金属节点的grub.cfg菜单项和user-data文件。那时完成一个 50 节点的上架批次运维同事需要复制粘贴、修改 IP、检查 YAML 缩进三小时以上。今天这个过程被压缩到了30 秒。—上一次的痛点为什么手动方案走不远如果你读过上篇关于 PXE Ubuntu Autoinstall 的基础方案应该记得结尾我们预告了 UDS 并列出几个硬伤菜单爆炸每换一种 OS 版本或分区策略就得在grub.cfg里新增一组菜单项。User-Data 碎片化每台机器一个user-data文件名靠 MAC 地址区分改一个全局参数比如 DNS要批量 sed。网卡名称踩坑Ubuntu 20.04 识别为ens17f0升级到 22.04 HWE 内核变成ens17f0np0Netplan 配置直接失效。装机后二次配置IP 地址虽然在装机时通过 DHCP 获取但业务 Bond 网络还是得 SSH 进去手动改 Netplan 再重启。这些问题在节点量少的时候还能忍但当你的集群要从 50 台扩展到 200 台、横跨两个 IDC、涉及 A100 和 4090 两种异构机型时手动维护就是一颗定时炸弹。我们需要一个配置即代码的渲染引擎而不是一堆需要手工缝合的静态文件。UDS 是什么一个约定优于配置的 PXE 配置生成器UDSUnified Deployment System是我们针对异构 GPU 数据中心开发的自动化部署配置引擎。它不替代你的 DHCP、TFTP 或 Nginx而是坐在这些基础设施之上把节点清单翻译成可执行的 PXE 配置。核心设计哲学只有一条约定优于配置Convention over Configuration。你不需要记住某台机器的网卡叫ens111f0np0还是ens13f0np0。只要它的 hostname 是XJ-DC1-R4090-106UDS 就知道它是一期机房的一台 4090默认使用 G13 网卡模型存储布局是sdasdbNVLink 关闭。# conf/nodes.yaml —— 你只需维护这一份清单nodes:-mac:68:91:D0:70:17:97hostname:XJ-DC1-R4090-106os:version:ubuntu24043filesystem:ext4network:bond0:ip:10.2.23.11netmask:255.255.255.192gateway:10.2.23.62UDS 会基于这 10 行配置自动生成该节点的完整user-data含 Netplan、存储分区、late-commandsTFTP 目录下grub.cfg中对应的引导菜单项按 MAC 地址隔离的节点配置目录结构运行方式只有一行python bin/uds.py\--output-res-dir /usr/share/nginx/html/res\--output-tftp-dir /var/lib/tftpboot\--server-ip10.1.8.5运行后TFTP 目录下的grub.cfg会自动生成按节点区分的引导菜单PXE 启动时可直接选择目标节点关键技术决策我们是怎么做到的1. Hostname 作为唯一事实来源在多机型、多 IDC 环境中最容易出错的不是配置语法而是把 A 机型的网络模板套到了 B 机型上。UDS 的解决方案是把 hostname 当作唯一标识通过模式匹配推断所有硬件参数Hostname 模式推断结果影响包含DC1一期机房单 Bond 网络、直连存储策略包含DC2二期机房双 Bond 网络、需配置静态路由包含A100训练节点开启 NVLink、加载 Fabric Manager包含R4090推理节点关闭 NVLink、标准 CUDA 安装variant: g12旧款网卡网卡映射为ens111f0np0/ens121f0np0这意味着运维同学只需要按照命名规范填写 hostname系统就会自动拉取正确的网络 Profile 和存储布局不需要去查 wiki 里的某机型网卡对照表。2. 网络拓扑完全外置profiles.yaml把网络配置写死在代码里是 many IaC 工具的早期陷阱。UDS 把网络拓扑定义完全剥离到conf/profiles.yamlidc2-4090:ethernets:-ens17f0-ens20f0-ens17f1-ens20f1bonds:bond0:interfaces:[ens17f0,ens20f0]parameters:{mode:802.3ad,lacp-rate:fast}bond1:interfaces:[ens17f1,ens20f1]parameters:{mode:802.3ad,lacp-rate:fast}这样做有两个好处。一是新机型上架时不需要改 Python 代码加一段 YAML 即可。二是网络团队可以直接维护这份文件无需了解生成器的内部逻辑。3. 网卡名称兼容性Match Rename 机制这是我们踩过最多的坑。同一个硬件平台Ubuntu 20.04.6 的内核识别网卡为ens17f0而 24.04.3 的内核识别为ens17f0np0。如果 Netplan 里写死了名称装机后直接失联。UDS 的解决方式是在生成的 Netplan 配置中自动注入match/set-name规则ethernets:ens17f0:match:name:ens17f0*set-name:ens17f0无论底层实际名称是ens17f0还是ens17f0np0Netplan 都会将其统一重命名为ens17f0确保 Bond 配置始终生效。这个功能通过network_unified_naming参数控制默认关闭显式优于隐式仅在你确认需要跨内核版本兼容时开启。4. 无锚点 YAML 生成策略Cloud-init 对 YAML 的解析器比较挑剔YAML 锚点id001和别名*id001在某些版本下会导致解析失败。UDS 的 YAML 生成器强制继承yaml.SafeDumper并重写ignore_aliases方法确保输出的user-data100% 是无锚点的扁平结构。这是我们从早期测试中不断试错后加上的防御性设计。classNoAliasDumper(yaml.SafeDumper):defignore_aliases(self,data):returnTrue5. 动态 URL 路径计算支持多期项目共存在真实生产环境中一期项目和二期项目可能共用同一台 PXE 服务器但静态资源放在不同子目录下。UDS 根据--output-res-dir参数动态计算user-data的 HTTP URL输出到/usr/share/nginx/html/res→ URL 指向/res/nodes/mac/输出到/usr/share/nginx/html/res/cxn→ URL 指向/res/cxn/nodes/mac/这不需要你在代码里写 if-else生成器会自动根据路径的相对位置拼接出正确的 URL。Excel 导入从采购清单到 nodes.yaml对于批量上架场景手动编辑 YAML 仍然不够快。UDS 提供了excel_to_nodes.py工具允许你从采购部门提供的 Excel 表格直接生成配置。# 1. 生成标准模板python bin/excel_to_nodes.py--template# 2. 采购部填完 MAC、IP、Hostname 后发回# 3. 一键转换python bin/excel_to_nodes.py-iinventory.xlsx-oconf/nodes.yaml模板中包含智能默认值OS 版本默认ubuntu22044文件系统默认xfsNVIDIA 驱动默认575。你只需要填写关键列MAC、Hostname、IP其余留空即可。生成器内部架构UDS 的架构刻意保持极简没有数据库、没有守护进程、没有 Web UI只有三个核心组件uds.py主生成逻辑负责推断、渲染、输出。user-data.templateJinja2 模板定义了 Autoinstall 的完整结构。profiles.yaml网络拓扑定义纯数据无逻辑。我们尝试过但没走的路在决定自研 UDS 之前我们评估过 MAAS 和 Ironic维度UDSMAASIronic架构复杂度无状态脚本PostgreSQL Region/Rack 控制器依赖 OpenStack 组件群网络管控依赖外部 DHCP专注配置生成内置 DHCP/DNS/IPAM依赖 Neutron上手成本5 分钟数小时到数天数周MAAS 的功能确实更全但在我们的场景里网络基础设施交换机、DHCP Relay已经由网络团队维护好了我们只需要一个把操作系统和驱动装上去的工具。引入 MAAS 意味着多一套需要监控和排错的分布式系统收益不成正比。如果你的需求是从零构建一个完整的数据中心网络MAAS 是合理的选择。但如果你已经有网络只想快速批量装机UDS 这种轻量级配置引擎更划算。从手动到自动效率对比过去维护 50 个节点需要手动编辑 50 个user-data文件手动维护grub.cfg中的 50 个菜单项每次改全局参数都要批量 sed现在只需要维护一份nodes.yaml或一个 Excel 表格一条命令生成全部配置。改 DNS、换 ISO 镜像、调整 Bond 参数都只需要改一处。已知限制和后续规划UDS 目前不是万能药有几个明确的边界无状态管理UDS 只负责生成配置不追踪节点的装机进度或健康状态。装机后的监控仍需配合现有监控系统。无 Web UI所有操作通过命令行和 YAML 完成。如果需要图形界面目前得自己包一层。DHCP 外部依赖UDS 不替代 DHCP 服务你需要确保网络侧的 DHCP Relay 已经指向 PXE 服务器。后续我们计划在 UDS 的基础上增加GPU 交付验收报告装机完成后自动检查 GPU 拓扑、CUDA 版本、驱动状态输出 HTML 报告。批量巡检脚本跨节点的配置一致性校验。如何开始项目已开源核心代码只有约 700 行 Python。gitclone https://gitee.com/path_fly/unified-deployment-system.gitcdunified-deployment-system python-mvenv .venvsource.venv/bin/activate pipinstall-rrequirements.txt# 编辑 conf/nodes.yaml填入你的节点信息# 运行生成器python bin/uds.py\--output-res-dir /usr/share/nginx/html/res\--output-tftp-dir /var/lib/tftpboot\--server-ip YOUR_PXE_IP详见项目中的 QUICKSTART.md 获取完整操作指南包括 Excel 工具的使用方法和多机型场景的进阶配置。FAQQ: UDS 能管理装机后的节点状态吗A: 不能。UDS 只生成配置不监控装机进度。装机完成后建议配合现有监控系统使用。Q: 支持 Red Hat / CentOS 吗A: 目前只支持 Ubuntu Autoinstall。如果要支持 Kickstart需要新增一套模板和渲染逻辑。Q: 新机型上架需要改代码吗A: 不需要。只要新机型遵循 hostname 命名规范在conf/profiles.yaml中新增一段网络拓扑定义即可。Q: 为什么默认关闭network_unified_namingA: 显式优于隐式。如果你的 Profile 已经精确匹配了硬件网卡名称不需要额外的 match 规则。只有在跨内核版本出现命名不一致时才建议开启。相关阅读上篇PXE Ubuntu Autoinstall 基础方案详解DHCP / TFTP / Nginx 手动配置全流程
