RHEL7服务器部署A100驱动与Fabric Manager避坑指南

接手这台 RHEL7 服务器的时候我原以为给 Tesla A100 装驱动就是个“下载、运行、重启”三步走的活儿。真正动手才知道RHEL7 配 A100 属于典型的“每个环节单看都简单串起来全是坑”老内核、新显卡、外加多卡场景必须配的 Fabric Manager任何一个环节版本对不上后面就是无休止的排查。这篇文章把我从零到能跑通完整流程的记录整理出来包括每一步怎么选版本、为什么这么选以及我踩过之后填平的坑希望能让后来的人少走点弯路。整套流程适合谁看两类人最需要一是要在 RHEL7/CentOS 7 这类老系统上部署 Ampere 架构显卡的运维二是第一次接触多卡互联、搞不清 Fabric Manager 到底干嘛用的同学。下面我按实际操作顺序来写从环境准备到驱动安装再到 Fabric Manager 配置最后附上我遇到的典型问题和排查思路。1. 先把账算清楚RHEL7、A100、驱动、Fabric Manager 四方关系1.1 A100 对驱动版本的要求不是拍脑袋定的Tesla A100 用的是 Ampere 架构和上一代 Volta、Turing 不一样的是它在驱动层面引入了不少新东西——比如对 NVSwitch 和 NVLink 3.0 的支持、新的计算能力特性sm_80。这意味着老驱动根本不认识这张卡。NVIDIA 官方支持 Ampere 的驱动是从 450 系列开始的具体来说 CUDA 11.0 配套的 450.36.06 是第一批正式支持 A100 的驱动版本。我见过很多人直接装 440 或者更老的驱动结果 nvidia-smi 里什么都看不到。这不是驱动坏了是驱动里根本没有 A100 的设备 ID。所以在下载驱动之前先确认两点驱动版本必须 ≥ 450.80.02后面为了稳定我用的 470 系列CUDA 版本建议直接用 11.x因为 A100 的很多特性比如 TF32、稀疏计算在 CUDA 11 里才完整支持。1.2 RHEL7 的老内核是第一个隐形门槛RHEL7 默认内核是 3.10 系列这个版本对现代 GPU 来说相当“陈旧”。问题不在内核本身能不能驱动 A100而在于三个连带效应第一3.10 内核里的 GCC 工具链默认是 4.8.5NVIDIA 驱动在编译内核模块时对 GCC 版本有要求太老的编译器有时会出警告甚至直接报错。第二老内核没有新硬件所需的一些内核 APINVIDIA 驱动的 .run 安装包会检测内核版本如果内核过老安装脚本会给出 unsupported 之类的提示。第三RHEL7 默认启用的是 nouveau 驱动不把它关掉NVIDIA 驱动装到一半就会撞车。所以我的建议是如果服务器能升级内核就尽量升级用 RHEL7 官方支持的 kernel-lt 或者 kmod 方案把内核升到 3.10 里更新的小版本比如 3.10.0-1160 以上。不能升的情况下至少要把 kernel-devel 匹配到当前跑的 uname -r 版本这是驱动编译成功的前提。1.3 Fabric Manager多卡服务器里最容易漏掉的部分很多人以为装完驱动、插上一张 A100 就完事了直到某天发现多卡之间数据交互慢得离谱才意识到 NVSwitch 没起来。A100 的 HGX 基板是 4 卡或 8 卡配置卡与卡之间通过 NVSwitch 芯片互联而 NVSwitch 的固件初始化、拓扑发现和运行时管理不是内核驱动干的活而是由 NVIDIA Fabric Manager 这个用户态服务负责的。也就是说单卡 A100 可以不装 Fabric Manager但多卡尤其是 8 卡 HGX 那种必须装而且要保证 Fabric Manager 版本和 GPU 驱动版本严格一致差一个小版本都会导致服务起不来或者 NVSwitch 链路异常。这是整篇记录里最需要引起重视的一点也是我后来填的最大的一个坑。2. 环境准备动手前必须搞定的几件事2.1 先把内核和编译环境对齐我第一次安装失败就是栽在 kernel-devel 版本和当前内核不匹配上。RHEL7 的 yum 源里 kernel-devel 默认包版本可能和已安装的内核不是同一个小版本导致编译驱动的头文件路径对不上。检查命令很简单uname -r rpm -qa | grep kernel-devel如果 kernel-devel 没装或者版本和 uname -r 不一致用 yum 装指定版本yum install -y kernel-devel-$(uname -r) yum install -y gcc make这里有个小坑如果你之前手动升级过内核yum 安装 kernel-devel-$(uname -r) 可能会提示找不到包因为默认源里没有那个小版本。解决办法是先把内核 yum update 到源里可用的最新版本然后重启进入新内核再装对应的 kernel-devel。反正记住一句话kernel-devel 的版本必须和当前运行的内核完全一致差一个小版本NVIDIA 的安装脚本就会在编译 nvidia.ko 时报一堆头文件找不到的错误。2.2 禁用 nouveau90% 安装失败的前置原因RHEL7 默认载入的 nouveau 驱动会和 NVIDIA 官方驱动抢占同一个设备.run 安装脚本检测到 nouveau 时会直接退出报 “The Nouveau kernel driver is currently in use by your system”。即使侥幸安装成功重启后也可能因为 nouveau 被优先加载而黑屏或者直接进不了图形界面。禁用方法我整理成了三步# 1. 在 /etc/modprobe.d/blacklist.conf 里加入 blacklist nouveau options nouveau modeset0 # 2. 备份并重建 initramfs mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak dracut /boot/initramfs-$(uname -r).img $(uname -r) # 3. 把启动参数里的 nouveau 也去掉 # 修改 /etc/default/grub 的 GRUB_CMDLINE_LINUX追加 rd.driver.blacklistnouveau grub2-mkconfig -o /boot/grub2/grub.cfg然后重启。重启后用lsmod | grep nouveau确认没有任何输出才算真正禁用干净了。这一步我建议放在装驱动之前的头一天做因为有的人机器上 nouveau 模块被多个服务引用重启后才发现还没清干净又得再折腾一轮。2.3 依赖包清单少一个都白搭NVIDIA 驱动编译的时候需要一堆基础依赖缺了哪个都会在中途报错。我第一次没装 elfutils-libelf-devel结果编译到一半报找不到 libelf 头文件。完整的依赖清单如下yum install -y gcc gcc-c make kernel-devel-$(uname -r) \ elfutils-libelf-devel libglvnd-devel \ pciutils wget vim如果是跑 CUDA 训练环境还需要装epel-release因为后面 Fabric Manager 的包认证、以及一些工具链要从 EPEL 源里补。这里多说一句不要为了省事跳过 libglvnd-devel新版 NVIDIA 驱动默认开启 GLVND 支持缺了这个头文件不一定导致安装失败但会有一些 GL 相关的警告后续跑图形程序容易出莫名其妙的问题。另外如果你要跑容器建议把 container-tools 或者 docker 也提前装好这不是必须项但 A100 的典型用法就是配合 NVIDIA Container Toolkit 跑 CUDA 容器提前准备可以省得到时候再折腾一套环境。3. 驱动安装实操一条命令背后的所有细节3.1 拿到版本匹配的 .run 安装包驱动我建议直接去 NVIDIA 官网的驱动下载页面选 Tesla 系列操作系统选 Linux 64-bit RHEL7然后拿到的 .run 文件。注意不要用系统源里的老旧 nvidia 驱动包RHEL7 官方源里的版本通常很老不支持 A100。我在实际操作中选择了 470 系列的驱动470.82.01 或更新因为这一系列经历过多轮补丁对 RHEL7 内核的兼容性最稳。下载之后用chmod x赋予执行权限。最好把安装包放在/opt或/root下不要放/tmp因为安装脚本可能需要大量临时空间而且某些环境 /tmp 会被服务自动清理。3.2 安装命令与参数选择安装之前务必将系统切换到纯命令行模式否则 X Server 占着显卡会装不进去。我用的命令telinit 3 ./NVIDIA-Linux-x86_64-470.82.01.run --no-opengl-files --dkms重点解释几个参数--no-opengl-files跳过 OpenGL 文件的安装。在无桌面服务器上这个参数强烈建议加它能避免破坏系统自带的 OpenGL 库。尤其是一些跑虚拟化的机器装完 OpenGL 文件后可能影响其它虚拟化组件。--dkms让驱动通过 DKMS 注册内核模块内核更新后模块会自动重新编译。不加这个参数的话每次内核升级后驱动就没了又得手动重装一遍非常麻烦。DKMS 需要系统里有 dkms 包RHEL7 默认没有先装一下yum install -y dkms如果 EPEL 源没配好导致 dkms 装不上也可以不加 --dkms靠后面手动重装兜底但我的建议是宁可在 yum 源上多花十分钟也别省这个。安装过程中脚本会问你是否注册内核模块、是否运行 nvidia-xconfig 等一般默认选项即可。如果之前残留过旧驱动脚本会提示 uninstall 旧版本选择 yes 让它清理干净再继续。3.3 安装后的验证与模块加载安装结束提示 “Installation completed” 后我的习惯是先不要急着重启直接手动加载模块测试modprobe nvidia nvidia-smi如果 modprobe 没有报错并且 nvidia-smi 能输出 A100 的型号、显存、驱动版本信息基本就成功了一大半。这里我再补一个更细致的验证命令cat /proc/driver/nvidia/version nvidia-smi -q | grep -E Product Name|Driver Version|CUDA Version这两个命令能确认内核模块和用户态驱动是匹配的。如果 nvidia-smi 报 “couldn’t communicate with the NVIDIA driver”多半是模块没加载成功先用dmesg | grep nvidia看内核日志定位原因再去排modprobe的问题。重启之后同样要再跑一遍 nvidia-smi确认驱动随系统自启正常。如果重启后失败大概率是 nouveau 没有彻底禁用或者内核启动参数里残留了冲突项。4. Fabric Manager 配置从装好到真正能多卡互联4.1 Fabric Manager 和 NVSwitch 到底是什么关系A100 的多卡服务器上GPU 之间不是靠传统的 PCIe Switch 桥接的而是通过高带宽的 NVLink 连接到一个叫 NVSwitch 的片上交换机。你可以把 NVSwitch 理解成 GPU 之间的“专用交换中心”它提供高达 600GB/s 的双向带宽比 PCIe 4.0 的 64GB/s 大了近十倍。问题在于NVSwitch 是一个有独立固件和状态机的硬件设备。GPU 驱动只能管理 GPU 本身NVSwitch 的初始化、拓扑发现、链路错误处理、健康检查这些工作需要 NVIDIA Fabric Manager 这个运行在用户态的守护进程来完成。这就是为什么多卡场景必须配它。如果没有 Fabric Manager系统可能看起来一切正常每张卡都能被识别、驱动也加载了但 NVSwitch 处于“未配置”或者“链路未激活”状态多卡之间的通信退化成走 PCIe 或者直接失败训练任务要么卡死要么性能断崖式下跌。4.2 安装 Fabric Manager 并保持版本一致Fabric Manager 的安装方式有两种一种是用 NVIDIA 的 yum 源直接装另一种是下载 .rpm 包手动安装。我推荐用 yum 源便于以后升级和自动解决依赖。先配置 NVIDIA 的 CUDA 仓库RHEL7 x86_64yum install -y https://developer.download.nvidia.com/compute/cuda/repos/rhel7/x86_64/cuda-repo-rhel7-11-4-local-11.4.0-470.82.01-1.x86_64.rpm rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-NVIDIA或者更简单的方式是直接从 NVIDIA 官方下载 nvidia-fabricmanager 的 RPMwget https://developer.download.nvidia.com/compute/cuda/repos/rhel7/x86_64/nvidia-fabricmanager-470.82.01-1.x86_64.rpm yum install -y nvidia-fabricmanager-470.82.01-1.x86_64.rpm注意版本号一定要和驱动版本一模一样——470.82.01 的驱动就配 470.82.01 的 fabricmanager我见到过有人驱动是 470.82.01结果 fabricmanager 装了 470.57.02然后服务起不来日志里全是版本不匹配的报错。这个要求属于硬性的没有任何回旋余地。4.3 配置服务、查看日志与验证多卡状态安装完成后Fabric Manager 会注册一个 systemd 服务名字叫 nvidia-fabricmanager。启动和设置开机自启systemctl enable nvidia-fabricmanager systemctl start nvidia-fabricmanager systemctl status nvidia-fabricmanager如果服务状态不是 active (running)立刻去查日志tail -n 100 /var/log/fabricmanager.log日志里最常见的两类信息一类是正常的拓扑发现和初始化比如 “Topology” 相关的内容另一类是错误比如版本不匹配、NVSwitch 固件状态异常、拓扑中某个 GPU 离线等。服务起来之后用 nvidia-smi 验证多卡和 NVSwitch 状态。查看 NVSwitch 我很常用的命令是nvidia-smi -q | grep -i NvSwitch\|NVLink -A 5正常状态下你能看到多张 A100 卡片并且能检测到 NVSwitch 的拓扑信息。如果 Fabric Manager 没配好输出里往往只有 GPU 列表NVSwitch 部分要么缺失要么显示异常。还可以用nvidia-smi nvlink -s查看 NVLink 链路状态这个命令能直接告诉我们每对 GPU 之间的链路是否 active。多卡互联的全链路验证最好跑一次 NCCL 的 allreduce 测试比如nvidia-smi topo -m这个命令输出 NVIDIA 官方的卡间拓扑矩阵如果显示 NVSWITCH 连接就说明 Fabric Manager 已经把 NVSwitch 配置起来了多卡互联的硬件链路算是彻底打通。5. 常见问题排查我遇到的坑和填平方法5.1 编译失败gcc 和 kernel-devel 版本不匹配这是最常见的问题报错信息五花八门但大部分都能追溯到同样的根源。我见过最典型的报错是Error: unable to determine the version of the kernel source或者编译时出现一堆/lib/modules/x.x.x/build找不到头文件的错误。前者通常是 kernel-devel 没装或者装错版本后者是 gcc 版本和内核编译时用的 gcc 版本不一致。排查顺序固定为uname -r和rpm -qa kernel-devel对比版本然后gcc --version看看编译器版本。RHEL7 默认 gcc 4.8.5 在大多数情况下能编译成功但我遇到过需要 devtoolset 的情况比如某些驱动版本要求 gcc 4.9 以上这时候用yum install -y devtoolset-9 scl enable devtoolset-9 bash启用新版本的 gcc 后再重新跑安装脚本。5.2 nvidia-smi 报错驱动模块没加载或权限问题nvidia-smi 报 “couldn’t communicate with the NVIDIA driver” 是最折磨人的错误因为它可能是内核模块没编译成功、模块加载失败、也可能是设备节点权限问题。先看模块是否加载lsmod | grep nvidia如果列表为空手动 modprobe nvidia 并看输出。如果 modprobe 报错立刻查内核日志dmesg | tail -n 50常见的情况是模块编译好了但加载时因为 Secure Boot 或者签名问题被拒绝。RHEL7 如果开启了 Secure Boot第三方内核模块必须签名否则加载不了。临时方案是进 BIOS 关掉 Secure Boot长期方案是生成自己的 MOK 签名并 enroll。对于内部测试服务器我一般直接关掉运维省心不少。另一个容易被忽略的是 /dev/nvidia* 设备节点权限。如果模式加载成功后 nvidia-smi 依然失败检查一下ls -l /dev/nvidia*如果没有设备节点可能是 systemd-tmpfiles 配置缺失可以试着运行nvidia-smi之前先执行mknod相关脚本或者重启一次让系统重新创建设备节点。5.3 重启后驱动“消失”DKMS 没生效或 nouveau 复活重启之后 nvidia-smi 找不到驱动基本就是两个原因DKMS 没生效或者 nouveau 没禁干净。如果是 DKMS 的问题重启后在/lib/modules/$(uname -r)/extra/nvidia里找找有没有 nvidia.ko没有就说明 DKMS 没有把它编进去。我建议重新执行一次dkms status dkms install -m nvidia -v 470.82.01如果是 nouveau 复活lsmod | grep nouveau能看到模块被加载。这种情况很隐蔽因为我明明写过 blacklist但某些 RHEL7 版本里 nouveau 的内核模块被编进了 initramfs导致即使 blacklist 也没用。解决方法是直接删除 initramfs 里的 nouveau 模块并重建mv /lib/modules/$(uname -r)/weak-updates/nouveau /lib/modules/$(uname -r)/weak-updates/nouveau.bak dracut -f然后把启动参数也一并堵死# /etc/sysconfig/grub 里在 GRUB_CMDLINE_LINUX 增加 rd.driver.blacklistnouveau modprobe.blacklistnouveau grub2-mkconfig -o /boot/grub2/grub.cfg双重保险之后重启基本不会再看到 nouveau 复活了。5.4 NVSwitch 不工作Fabric Manager 的隐性版本坑多卡机器上最隐蔽的问题就是 NVSwitch 没起来但系统“看着正常”。有个典型场景我装完驱动后 nvidia-smi 显示 8 张卡都在跑单卡任务完全正常但一跑多卡分布式训练就直接卡死或者报 NCCL 超时错误。查了一圈最后定位到 Fabric Manager 版本和驱动差了半个版本。虽然服务进程在跑日志里也没有明显错误但 NVSwitch 的拓扑没有被正确初始化NCCL 通信链路自然就挂了。排查方法就是回到 4.3 节用nvidia-smi topo -m看拓扑矩阵。如果显示的不是 NVSWITCH 而是 PCIE那就是 Fabric Manager 没生效。这时候别犹豫直接把 fabricmanager 卸了重装到和驱动完全一致的版本重启服务再验证。版本号一字不差这是我在这个坑里用血泪换来的结论。6. 实操心得与最后几条经验整套流程走下来我最大的体会是给 RHEL7 装 A100 驱动真正的难点不是“怎么敲命令”而是“怎么控制变量”。安装过程中系统版本、内核版本、gcc 版本、驱动版本、DKMS 状态、nouveau 是否残留、Fabric Manager 是否匹配任何一个变量变了症状可能完全不同。所以我的建议是每做一步就验证一步不要等全部装完再统一排查否则出了问题真的无从下手。具体来说有三个小的经验分享给大家第一建议把每一步的命令和输出都存到日志文件里。比如./NVIDIA-Linux-x86_64-*.run -s --no-opengl-files --dkms 21 | tee /root/nvidia-install.log。乱码或者滚动输出很容易漏看关键信息有日志回溯起来效率高得多。第二多卡服务器的网络和系统时间最好提前校准。Fabric Manager 在使用证书或者做健康检查时会对时间敏感时间偏移过大的话可能出现一些莫名其妙的握手失败。这属于我踩过的偏门问题列出来给大家避坑。第三如果条件允许第一次安装建议先在单卡机器或者测试卡上验证整套流程。A100 的机器通常很贵用得越稳越好。在测试机上把驱动版本、Fabric Manager 版本、验证命令全部跑熟再去生产环境操作心态和效率都会好很多。这套环境目前在我这边跑了几个月重装过两次驱动、升级过一次内核DKMS 帮了大忙Fabric Manager 也一直稳定运行。如果你也是要在 RHEL7 上部署 A100希望这篇记录能帮你把最耗时的版本匹配和 Fabric Manager 配置这两个坑提前填平。按照上面的顺序走一遍你应该能比我第一次少折腾好几个晚上。