RHEL7上A100 HGX服务器NVIDIA驱动与Fabric Manager配置踩坑指南-北京尧图网络

上个月在机房给一台HGX A100服务器重装系统客户指定要用RHEL7。我第一反应是A100从2020年就出来了RHEL7虽然老但也在NVIDIA支持矩阵里装个驱动应该不难。结果真正动起手来才发现RHEL7这个内核3.10的老骨头配上A100的NVSwitch新架构坑是一个接一个编译失败、显存枚举不全、NVIDIA-SMI反复失联、Fabric Manager服务起不来……从下午折腾到凌晨中间至少踩了七八个坑最后才把整套环境填平。这篇文章就把我这次完整的踩坑、填平过程记录下来。重点不是复述一遍官方文档而是把那些文档不会写、但实操中几乎必踩的细节讲清楚。尤其是Fabric Manager的配置部分网上资料本来就少讲RHEL7上的更少这次一次性说明白。文章适合正在给老系统上A100、A800这类新卡的运维同学参考也适合刚接触NVIDIA数据中心卡的开发人员提前避雷。1. 为什么RHEL7会成为地狱难度开局三个底层原因1.1 内核3.10与A100驱动之间存在代差RHEL7默认内核是3.10这是2013年的内核。A100要正常运行驱动版本至少要450.80.02以上而这类新驱动在内核API的使用上已经更新了不只一个版本。从NVIDIA驱动源码的角度看450系列为了兼容RHEL7做了不少#if分支但如果你用的RHEL7是最早期的小版本比如7.0到7.4内核头文件停留在3.10.0-327到3.10.0-862这个区间编译时大概率会碰到莫名其妙的报错。我实测下来的经验是RHEL7.5以下的旧小版本编译535.104.05版本的驱动经常会报unable to determine the version of the kernel source。这个报错本身非常有迷惑性因为它并没有直说你的内核太老了而是看起来像路径配置错误。实际上就是内核源码里的某些宏和驱动构建脚本的预期对不上。如果你还在7.5之前的版本强烈建议先升小版本不要想着在旧内核上硬杠。我最后是把系统通过CR渠道升到了RHEL7.9内核到了3.10.0-1160编译才稳定通过。还有一层容易忽略的点RHEL7的系统自带gcc是4.8.5而官方内核正是用这个版本的gcc编译的。很多人为了编译其他软件装了devtoolset把默认gcc切换到了8.x甚至9.x。这时候再去编译NVIDIA驱动构建系统会识别到gcc版本和编译内核时的gcc版本不一致轻则模块加载时报version magic mismatch重则直接编译失败。在这个环节上原配的gcc 4.8.5反而是最安全的。1.2 nouveau你以为禁了其实还在RHEL7默认内核里带有nouveau驱动模块而且安装系统时生成的initramfs镜像中已经把这个模块打包进去了。问题就在这里很多人知道要写blacklist文件写完也重启了但系统重启后还是提示nouveau占用了设备于是怎么排查都找不到原因。原理说透其实很简单。initramfs是一个启动时先加载到内存的小型根文件系统内核启动早期会先把initramfs里的模块load一遍。如果你的nouveau blacklist配置只写在/etc/modprobe.d/下它影响的是后续的modprobe行为但initramfs里已经打包好的.ko文件还是会被直接加载。所以写完blacklist之后必须重建initramfs把这个驱动从启动镜像里彻底拿掉。这一步不做后面的驱动装得再干净也没用因为nouveau始终在抢设备。这个问题在RHEL7上尤其常见因为RHEL7的dracut机制和RHEL8/9不一样很多人沿用RHEL8的习惯操作容易漏掉重建这一步。1.3 UEFI安全启动和旧固件的双重阻碍HGX服务器出厂默认会开UEFI Secure Boot这在RHEL7上是个很容易被忽略的坎。Secure Boot开启时内核只允许加载经过签名验证或已在MOKMachine Owner Key中登记过的内核模块。NVIDIA官方runfile安装驱动时生成的nvidia.ko并没有被UEFI固件信任重启后模块会被拒绝加载表现为module verification failed。最简单的处理办法是在BIOS里关闭Secure Boot如果出于安全合规不能关就需要用DKMS配合mokutil把NVIDIA公钥导入MOK列表。后者流程稍繁琐但一次配好后面升级内核也能用。另一个藏在固件层面的坑是老版本HGX平台的NVSwitch固件可能太旧。表现是驱动装好了、fabricmanager服务能起来但NVSwitch链路就是不健康。这个属于BMC/IDRAC层面的固件更新不是驱动能解决的需要到服务器厂商官网下载对应的NVSwitch固件包刷一遍。2. 动手前先做三件事系统升级、依赖安装、斩断nouveau2.1 先把RHEL7小版本升到7.9这一步建议放在最前面因为后面所有和内核相关的操作都依赖于一个尽量新的3.10内核。RHEL7的CRContinuous Release仓库里有小版本更新操作很简单。yum install -y yum-utils yum-config-manager --enable rhel-7-server-rpms yum-config-manager --enable rhel-7-server-extras-rpms yum update -y reboot如果你用的是RHEL官方订阅更新后确认一下版本cat /etc/redhat-release uname -r正常情况下应该是7.9和3.10.0-1160.el7.x86_64。这里多说一句不要为了追求内核新而去用ELRepo或其他第三方源把内核换成4.x/5.x那会让NVIDIA驱动根本无法编译纯属给自己挖坑。RHEL7.9官方内核已经包含了新GPU所需要的一些PCIe AER、MMIO修复够用了。2.2 安装编译依赖kernel-devel版本必须对齐装驱动不是光有gcc就行的还需要kernel-devel和kernel-headers而且版本必须和当前运行的内核完全一致。很多人第一次装驱动报kernel headers not found就是kernel-devel版本没对齐。yum install -y gcc make kernel-devel kernel-headers rpm -q kernel-devel-$(uname -r)如果最后一条命令提示package kernel-devel-xxx is not installed说明yum安装的是另一个内核版本的kernel-devel。这种情况常见于刚升级完内核还没重启或者yum源里默认的kernel-devel和正在跑的uname -r不一致。解决方案是让两部分回到同一个版本要么重启到新内核再装要么用yum install kernel-devel-$(uname -r)指定安装当前内核对应的包。gcc这里再啰嗦一遍确认当前默认gcc是系统自带的4.8.5。如果你装过scl的devtoolset检查一下gcc --version的输出。如果默认gcc不是4.8.5临时把PATH里的devtoolset路径去掉或者用scl disable devtoolset-8切回来。这个细节能帮你省下至少一个小时的排错时间。2.3 禁用nouveau三步走不能只写blacklistKill nouveau这一步我单独拿出来强调因为太多人栽在这里。完整操作如下cat /etc/modprobe.d/blacklist-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak dracut -f reboot重启后做两个验证lsmod | grep nouveau如果没有输出说明nouveau没有被加载。再看PCIe设备当前的驱动绑定情况lspci -k | grep -i nvidia正常情况下A100所在的PCIe设备行会显示Kernel driver in use: pcieport或者没有驱动占用但绝对不能是nouveau。如果你看到Kernel driver in use: nouveau说明blacklist没有生效需要回到上面重新检查尤其是initramfs是否真的重建成功了。3. 驱动安装全记录runfile安装、编译报错与NVIDIA-SMI失联排查3.1 用runfile安装注意交互选项和运行级别HGX服务器一般没有桌面环境但如果系统里装了Xorg建议先切换到多用户命令行模式再装避免显示服务占用GPU。systemctl set-default multi-user.target reboot去NVIDIA官网下载对应驱动。A100建议选535系列或525系列这两个系列对Ampere架构的支持已经很成熟。下载后执行chmod x NVIDIA-Linux-x86_64-535.104.05.run ./NVIDIA-Linux-x86_64-535.104.05.run安装过程中的交互选项有几个值得注意提示是否安装32位兼容库如果没有32位CUDA程序依赖选No。提示是否注册DKMS一定要选Yes。虽然RHEL7自带的内核更新频率不高但一旦有安全补丁升级内核没有DKMS就得手动重装驱动很麻烦。如果提示缺少某个依赖包比如libvdpau或libGL一般不影响核心驱动安装可以继续。整个编译过程在HGX 8卡平台上可能需要10到15分钟千万不要中途CtrlC。等它出现Installation of the NVIDIA Driver completed再动。3.2 编译报错的经典场景kernel-devel缺失与gcc版本错位我这台机器第一次编译就报错了报错信息是这样的Error: The kernel header file /lib/modules/3.10.0-1160.el7.x86_64/build/include/linux/version.h does not exist. The most likely reason for this is that the kernel source files are not installed at this location.看到这个先别急着重新跑安装脚本按顺序排查ls -l /usr/src/kernels/$(uname -r) ls /lib/modules/$(uname -r)/build如果/lib/modules/$(uname -r)/build是个软链接指向的目录不存在就是kernel-devel没有正确安装。重新执行yum install -y kernel-devel-$(uname -r)注意是当前uname -r的版本。第二个容易出现的编译报错是Unable to load the kernel module nvidia.ko. This happens most frequently when this kernel module was built against the wrong or improperly configured kernel sources, with a version of gcc that differs from the one used to build the target kernel.这个英文报错已经把原因说得很直白了gcc版本和编译内核的版本不一致。这时候把gcc --version和cat /proc/version对比一下如果/proc/version里显示内核是gcc version 4.8.5编译的而当前gcc是8.5.0那就是gcc错位了。我以前图省事装了devtoolset-8这次就吃了这个亏。切回gcc 4.8.5后重新编译一次通过。3.3 NVIDIA-SMI has failed的完整排查链路驱动装完输入nvidia-smi结果弹出这句经典报错NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.这个报错我在不少机器上见过原因五花八门。我这次排查按下面的顺序走了一遍每一步都有明确的目的第一步确认nouveau到底死透了没有lsmod | grep nouveau lspci -k | grep -i nvidia如果这次看到nouveau还在那就是initramfs的问题需要回到第2.3节把/boot/initramfs-$(uname -r).img再重建一次。我这次最终就是栽在这因为第一次重建的时候用的是dracut -f但忘记先备份实际没把旧镜像覆盖掉重启后nouveau还是被加载了。第二步手动加载nvidia模块看具体报错modprobe nvidia如果modprobe静默返回再执行nvidia-smi看是否恢复。如果报错用dmesg拿详细信息dmesg | tail -100 dmesg | grep -i nvidia | tail -100第三步判断dmesg里错误类型。常见几类dmesg错误特征根因指向解决方案module verification failedSecure Boot签名校验不通过关闭Secure Boot或配置MOKno such device驱动被其他模块占用或PCIe枚举异常检查是否还有nvidiafb/rivafb等冲突模块unknown symbol内核头文件版本不对重新安装匹配的kernel-devel并重编version magic mismatchgcc版本与编译内核的工具链不一致切回系统默认gcc后重编第四步检查设备节点ls -l /dev/nvidia*正常情况下应该有/dev/nvidia0、/dev/nvidiactl、/dev/nvidia-uvm等设备文件还需要确认cat /proc/driver/nvidia/version能输出NVRM version: NVIDIA UNIX x86_64 Kernel Module 535.104.05这类信息说明内核模块已经加载成功。顺便再检查一下/etc/ld.so.conf.d/下有没有NVIDIA的库路径配置没有的话在/etc/ld.so.conf.d/nvidia.conf写入/usr/lib64/nvidia并执行ldconfig否则后面跑CUDA程序会报找不到libcuda.so。3.4 装完驱动后的第一波验证驱动正常后nvidia-smi输出应该像这样----------------------------------------------------------------------------- | NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: 12.2 | |--------------------------------------------------------------------------- | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | || | 0 Tesla A100-SXM4-40GB On | 00000000:07:00.0 Off | 0 | | N/A 31C P0 58W / 300W | 0MiB / 40960MiB | 0% Default | ---------------------------------------------------------------------------看到这个只能说驱动层OK了还不能算完。紧接着验证一下所有GPU都被正确枚举nvidia-smi -L8卡平台应该列出一共8张卡的UUID。如果这里只列出4张或者数量不对大概率是Fabric Manager没起来直接跳到第4节处理。另外用lspci -k | grep -i nvidia确认每张卡的Kernel driver in use都已经是nvidia这样才算设备绑定成功。4. Fabric ManagerA100 NVSwitch架构的核心配置4.1 Fabric Manager到底在干什么Fabric Manager在网上资料少但A100这类带NVSwitch的平台上它是不可或缺的。用一个比较直白的类比NVSwitch相当于一个大型立交桥多张GPU之间的NVLink数据要通过这座桥互相交换。桥建好了放在那里但如果没有交警指挥车辆不知道走哪条道、桥面上的信号灯也不会自动亮起来。Fabric Manager就是这个交警它负责NVSwitch的初始化、fabric拓扑发现、路径计算和链路健康管理。没有Fabric Manager的典型症状是nvidia-smi里能看到部分GPU但NVLink状态全是N/A多卡之间的P2P通信跑不起来甚至某些SXM4 GPU直接报ERR!。很多人在HGX平台上驱动装完发现GPU数量不对第一反应是重刷BIOS、换PCIe槽其实根子就是fabricmanager没装或者没启动。这里也说明一下适用范围如果你是单卡A100 PCIe版本不涉及NVSwitch可以不装fabricmanager。但如果你上的是HGX A100 8卡平台或者未来考虑多机NVLink互联fabricmanager就是必需品。文章标题里既然带了这个配置我按完整多卡场景来讲。4.2 版本匹配是铁律fabricmanager必须与驱动版本完全一致Fabric Manager和GPU驱动的关系是严格绑定的。驱动是535.104.05fabricmanager也必须是535.104.05差一个小版本号都不行。服务启动时会做版本校验不一致直接退出日志里就是一句不痛不痒的Version mismatch。下载rpm包时注意看版本号wget https://download.nvidia.com/XFree86/Linux-x86_64/535.104.05/nvidia-fabricmanager-535.104.05-1.x86_64.rpm或者使用NVIDIA的CUDA网络仓库yum install -y nvidia-fabricmanager-535.104.05安装命令很简单rpm -ivh nvidia-fabricmanager-535.104.05-1.x86_64.rpm安装完成后启动并设置开机自启systemctl daemon-reload systemctl enable nvidia-fabricmanager.service systemctl start nvidia-fabricmanager.service systemctl status nvidia-fabricmanager.service正常情况下状态应该是active (running)。再用进程确认一下pgrep -af nv-fabricmanager能搜到类似/usr/bin/nv-fabricmanager -c /etc/fabricmanager.conf -p 53982的进程说明fabricmanager已经起来了。4.3 RHEL7上fabricmanager起不来的几种根因第一次启动fabricmanager时我就踩了坑服务状态是failed。用journalctl -u nvidia-fabricmanager -n 100 --no-pager看日志发现系统里同时装过不同版本的驱动包导致fabricmanager获取的NVML版本信息对不上。清理掉旧的fabricmanager包重装和驱动完全一致的版本后恢复正常。还有一个非常隐蔽的问题出在RHEL7的systemd版本上。RHEL7自带systemd是219版本比较旧。我从NVIDIA官网下载的rpm包里的service文件如果用了新版systemd才支持的指令systemctl start会直接失败。遇到这种情况可以手动检查service文件cat /usr/lib/systemd/system/nvidia-fabricmanager.service如果里面有ExecStartPre、ExecStartPost之类的指令RHEL7的systemd 219也能识别但如果出现KillModemixed在部分老版本里可能有兼容性问题。最稳妥的办法是删掉service文件里的高级指令只保留最基础的[Unit] DescriptionNVIDIA Fabric Manager Aftermulti-user.target [Service] Typeforking ExecStart/usr/bin/nv-fabricmanager -c /etc/fabricmanager.conf ExecStop/usr/bin/nv-fabricmanager -c /etc/fabricmanager.conf -r [Install] WantedBymulti-user.target改成这样之后systemctl daemon-reload再启动就能跑起来。另一个高频问题是NVSwitch固件过旧。症状是fabricmanager进程起来了但日志里反复提示NVSwitch firmware upgrade needed。这种情况光靠驱动和fabricmanager解决不了必须到服务器厂商的支持页面下载NVSwitch固件离线升级包在BMC里刷固件。刷完再重启NVSwitch的fabric才能正常bring-up。4.4 确认Fabric健康状态的三个命令配置完fabricmanager后不要只看进程在不在要看fabric的实际健康状况。我习惯按顺序执行三个命令第一个看Fabric状态nvidia-smi -q | grep -A5 -i fabric输出中Fabric State应该是Healthy。如果这里显示Unhealthy或Failed说明NVSwitch本身或fabricmanager和GPU之间的通信有问题。第二个看NVLink链路nvidia-smi nvlink -s正常状态下所有链路状态都应该是Active。如果有链路显示Inactive或Shared说明这部分链路没有完成初始化。第三个看NVSwitch本身状态nvidia-smi -q -d SWITCH这里会列出NVSwitch的固件版本、温度、电源利用率。没有报错信息就说明switch本身是健康的。如果以上三个命令中看到的状态不理想可以尝试重启fabric服务systemctl stop nvidia-fabricmanager rmmod nvidia_peer_memory modprobe nvidia_peer_memory systemctl start nvidia-fabricmanager这个顺序我实测过能解决一部分fabric onboarding不成功的情况原因是对NVSwitch的重新初始化需要让peer memory模块一起重新加载。这一套操作要小心最好在业务低峰期执行。5. 重启与内核升级后的保命手段DKMS、persistenced、日常巡检5.1 DKMS让驱动自动跟随内核更新RHEL7虽然是老系统但安全补丁还是会不定期更新内核。如果不做任何处理内核一升级驱动模块就失效nvidia-smi立刻报错。避免这个问题的首选方案就是DKMS。如果安装驱动时没有选DKMS可以通过EPEL源补装yum install -y epel-release yum install -y dkms然后重新运行driver安装脚本选择DKMS注册./NVIDIA-Linux-x86_64-535.104.05.run --dkms -sDKMS的作用是当内核升级时系统会自动重新编译nvidia.ko等模块让它们适配新内核。验证是否生效dkms status正常会显示类似nvidia/535.104.05, 3.10.0-1160.el7.x86_64, x86_64: installed如果看到DKMS is already installed之后模块状态不是installed可以先移除再重新添加dkms remove -m nvidia -v 535.104.05 --all dkms add -m nvidia -v 535.104.05 dkms build -m nvidia -v 535.104.05 dkms install -m nvidia -v 535.104.055.2 nvidia-persistenced与GPU掉卡问题HGX平台上GPU在空闲或系统电源状态切换时偶尔会出现总线错误表现为GPU从PCIe总线上消失nvidia-smi里数量减少。RHEL7老内核的PCIe电源管理对A100这种大功耗卡来说不够友好这个问题不算罕见。软件层面的对策是运行nvidia-persistenced。这个守护进程会持续保持GPU的访问通道处于活跃状态避免驱动在GPU进入低功耗模式后和设备失联。启动方法nvidia-persistenced --user root如果想开机自启可以写一个简单的systemd服务或者用NVIDIA驱动自带的脚本。建议在BIOS里把PCIe ASPMActive State Power Management设置为Disabled这个从硬件层面减少掉卡概率的效果比纯软件手段更明显。5.3 运维建议重启后三件套和ECC监控我在这台HGX服务器上跑了一段时间后形成了固定的巡检习惯。每次重启后先执行三件事lsmod | grep nouveau nvidia-smi systemctl status nvidia-fabricmanager第一命令确认nouveau没有死灰复燃第二个看GPU是否全部枚举第三个看NVSwitch管理服务状态。三个命令几秒钟就能确认整套环境是否健康比翻日志高效得多。另外建议每周看一次ECC错误计数nvidia-smi -q -d ECC重点关注Single Bit ECC和Double Bit ECC两栏。Single Bit错误计数持续增长说明显存颗粒有老化趋势Double Bit出现任何非零值都需要尽快准备更换或维修。A100这类计算卡对数据正确性要求极高ECC异常不是小事。最后分享一个我保留至今的小习惯在HGX服务器上完成驱动和fabricmanager配置后我会把每张GPU的UUID记录到一个txt文件和驱动版本、fabricmanager版本、NVSwitch固件版本一起归档。后面排查CUDA任务P2P通信异常时没有这份对照信息你会在八张卡之间反复试错有了一眼就能定位是哪张卡的问题。这个细节不算什么高深技术但真到排查问题的时候能帮你省下大把时间。

RHEL7上A100 HGX服务器NVIDIA驱动与Fabric Manager配置踩坑指南

相关推荐

本地部署AI桌面助手实战指南：从模型推理到内网知识库搭建

工艺会评估实战指南：从新手到产线守门人的五维动态思维

GTweak 社区支持渠道完整指南：GitHub Issue、Telegram 与作者联系方式

更多资讯

CC Switch 不走官方通道，改 TaoToken 行不行

RayCluster 快速入门：在 Kubernetes 上用 KubeRay 部署并运行 Ray 应用

Roc 语言 `if` 表达式缺失 `else` 分支的编译诊断深度解析：基于 `expr_if_missing_else` 快照测试

Boss直聘岗位数据抓取实战：requests+代理IP池搭建与反爬应对

伺服电机通信协议选型指南：Modbus、CANopen与EtherCAT对比

视频会议系统操作手册：从结构设计到doc格式落地全攻略

今日更新

OneUptime 自定义探针（Custom Probe）部署实战：私网监控、代理配置与断连排障全指南

大众TL52625前端框架材料要求详解：从性能测试到落地执行

TiXL 浮点运算算子库 Lib.numbers.float 完全指南：44 个算子的参数详解、源码原理与实战串联

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？