[{"content":"\r关于闫工\r#\r十年运营商机房 IT 运维，CCIE。工作围绕数据中心网络架构、GPU 服务器硬件维护，以及裸金属服务器初始化交付。\n这个站点记录两件事：\n运维实战：故障排查、压测验收、批量运维脚本，都来自真实机房场景。 自研小工具：解决工作痛点的脚本和工具，能复用就整理出来。 内容同步自公众号《闫工的算力工具箱》。\n联系方式\r#\r公众号：闫工的算力工具箱 ","date":"August 31, 2026","externalUrl":null,"permalink":"/about/","section":"闫工的工具箱 · 博客","summary":"关于闫工\r#\r十年运营商机房 IT 运维，CCIE。工作围绕数据中心网络架构、GPU 服务器硬件维护，以及裸金属服务器初始化交付。\n","title":"关于","type":"page"},{"content":"欢迎来到闫工的技术博客。这里同步更新微信公众号《闫工的算力工具箱》的硬核实战经验。\n主要话题：\n数据中心网络架构与排障（CCIE 视角） GPU / AI 算力集群的散热、压测、交付实战 自研运维小工具（脚本、自动化、经验沉淀） 如果你也对 GPU 集群运维感兴趣，或者正在为夜间告警头疼，欢迎常来看看。\n","date":"August 31, 2026","externalUrl":null,"permalink":"/","section":"闫工的工具箱 · 博客","summary":"欢迎来到闫工的技术博客。这里同步更新微信公众号《闫工的算力工具箱》的硬核实战经验。\n","title":"闫工的工具箱 · 博客","type":"page"},{"content":"","date":"August 30, 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"August 30, 2026","externalUrl":null,"permalink":"/tags/esxi/","section":"Tags","summary":"","title":"ESXi","type":"tags"},{"content":"📌 转载说明：本文首发于微信公众号《闫工的算力工具箱》 原文链接：https://mp.weixin.qq.com/s/7ujntwxN91j0cPrs1z4Gcw\n【闫工的工具箱 · 第 14 弹｜实战】\r#\r我是闫工，数据中心搬砖的 CCIE。\n今天讲个\u0026quot;心跳骤停\u0026quot;的场景：系统盘被格式化重装，重启后原数据盘上的虚拟机全部消失。\n先翻译下标题里的词：ESXi 是服务器上跑的虚拟机管理系统，VMFS 是它存虚拟机文件（.vmx 配置、.vmdk 磁盘）的格式。不懂这些没关系，记住一个前提就够——\n先说结论压压惊：只要一个前提成立——数据盘在重装过程中没被触碰——那里面存的虚拟机文件都还完好。三步就能把全部虚拟机救回来。\n— — —\n1. 为什么数据盘\u0026quot;看起来\u0026quot;丢了？\r#\rVMFS（Virtual Machine File System）是 ESXi 的集群文件系统，元数据写在磁盘分区头部。系统盘重装不会碰独立的数据盘，但有两个原因让 ESXi 重启后\u0026quot;认不出\u0026quot;原卷：\n签名不一致：重装后 ESXi 把原 VMFS 卷当成\u0026quot;另一台机器留下的副本\u0026quot;，标记为 snapshot 卷（快照卷），不会自动挂载； 挂载状态变化：卷的签名和当前已知签名对不上，ESXi 干脆不挂。 数据没丢，只是没挂上来。\n第一铁律：严禁对 NVMe 数据盘执行\u0026quot;新建 datastore / 格式化 / 写入数据\u0026quot;。VMFS 元数据一旦被覆盖，数据就真没了。只要 .vmdk 还在，就还有救。\n2. 三步恢复：挂载 → 注册 → 开机\r#\r第一步：重装 ESXi（版本不能低于原版）\r#\r用与原版本相同或更高的 ESXi 安装介质，重装到系统盘（只选系统盘！）。装完进入 Host Client。\n版本过低可能无法识别原 VMFS 格式，这条踩过坑。\n第二步：确认 NVMe 盘状态\r#\r# 列出存储设备，确认能看到原 NVMe 设备 esxcli storage core device list # 查看文件系统，看是否自动识别出 VMFS 数据存储 esxcli storage filesystem list\r情况 1（自动识别）：/vmfs/volumes/datastore1 已经在列表里，直接进第三步。\n情况 2（设备在，但卷没挂）：查快照卷：\nesxcli storage vmfs snapshot list\r如下：\nVolume Name: datastore1 VMFS UUID: 5f8b4b22-1234abcd-... Can mount: true Reason for un-mount: Detected previously mounted VMFS volume\rCan mount: true，可以挂。执行：\n# 按卷名挂载（持久化，重启后保留） esxcli storage vmfs snapshot mount -l datastore1 # 或按 VMFS UUID 挂载 esxcli storage vmfs snapshot mount -u 5f8b4b22-1234abcd... # 确认挂载路径存在 esxcli storage filesystem list\r或者用 Host Client 走图形界面挂载（适合不熟命令行的同学）：\n图：当看到原本那块 447 GB 的 SSD 再次出现在设备列表里时，心里那块石头才算落了地——这说明数据盘完好，VMFS 分区结构还在。\n第三步：重新注册虚拟机\r#\rvSphere Host Client → 存储 → 进入 datastore1； 找到虚拟机目录 vmname/； 右键 .vmx 文件 → 注册虚拟机（Register VM）； 虚拟机会重新出现在清单里，开机验证。 若 .vmx 文件缺失：新建虚拟机，选\u0026quot;使用现有磁盘\u0026quot;，指向原 .vmdk 也能恢复。注册完选存储时就能看到原 datastore1 挂回来了：\n图：新建虚拟机选存储时，datastore1 稳稳显示 318.5 GB 可用（VMFS6）——那一刻才真正确认：盘里的虚拟机文件一个没少，全都能用。\n3. 进阶修复：卷挂不上怎么办？\r#\r⚠️ 高级操作警告：以下几步涉及命令行直接操作 VMFS 分区表与强制挂载，有一定风险，仅建议有一定命令行经验的运维同学尝试。如果你不确定，或者数据极其重要，优先使用第三方只读恢复工具（UFS Explorer / R-Studio Technician）在另一台主机上分析，或联系原厂 / 专业数据恢复支持——宁可慢一步，别把元数据写坏。\n如果 snapshot mount 失败，一步步排查：\n# ① 重新扫描所有存储适配器 esxcli storage core adapter rescan --all # ② 查看分区表，确认 VMFS 分区还在（GPT 类型标识 AA31E02A...） partedUtil getptbl /vmfs/devices/disks/naa.55cd2e404c123456 # ③ 强制挂载指定 VMFS 分区到自定义名称（:1 通常是分区号） vmkfstools -M /vmfs/devices/disks/naa.55cd2e404c123456:1 /vmfs/volumes/MyVMFS # ④ 重新扫描 VMFS vmkfstools -V\r如果分区表也坏了，数据极其重要时，用第三方 VMFS 恢复工具（UFS Explorer / R-Studio Technician）在另一台 Linux/Windows 主机上只读分析 NVMe 盘并导出 .vmdk。\n决策建议：snapshot mount 失败时怎么选？\r#\r你的状态 建议动作 理由 能看到 snapshot 卷，且 Can mount: true 直接 snapshot mount，别犹豫 最安全，元数据零写入风险 卷挂不上，但 partedUtil getptbl 能看到 VMFS 分区 谨慎执行 vmkfstools -M 强制挂载，只此一次 分区表还在就有救，强制挂载比 resignature 侵入更小 分区表损坏 / getptbl 报错 / 强制挂载仍失败 立刻停手 ，转第三方只读工具或原厂支持 再写入只会覆盖元数据，数据真没了 数据极其重要、心里没底 先做只读镜像，再决定下一步 镜像在手，怎么试都不慌 一句话总结：能挂就挂，挂不上先看分区表，分区表坏了就别硬来——交给工具和原厂。\n4. 恢复避坑清单\r#\r现象 可能原因 处理 filesystem list 无输出 VMFS 分区丢失/损坏 partedUtil getptbl 确认；vmkfstools -V 扫描；必要时只读镜像 + 第三方工具 snapshot list 为空 设备未识别 esxcli storage core adapter rescan \u0026ndash;all；检查 NVMe 盘是否在线 挂载报 \u0026ldquo;already mounted\u0026rdquo; 卷已被挂载 直接用 esxcli storage filesystem list 看现有挂载路径 注册后虚拟机无法开机 .vmdk 指向路径变化 编辑虚拟机设置，重新指向正确的现有磁盘文件 5. 安全红线（每条都是血泪教训）\r#\r只读优先：操作前尽量对 NVMe 盘做只读镜像/备份，任何写入都可能破坏元数据； 禁止格式化数据盘：绝不在此盘上\u0026quot;新建 datastore\u0026quot;或写入测试数据； 版本一致性：重装 ESXi 版本不低于原版本，避免 VMFS 格式不兼容； 最小侵入：优先 snapshot mount 而非 resignature，保留原 UUID 便于回退； 记录在案：记下设备 naa ID、VMFS UUID、datastore 名称，便于追溯。 📖 推荐阅读\n灯亮、端口Up、Ping通，但RDMA就是起不来：理线师傅的4根线全插错了\n交换机 M-LAG 状态全绿，PXE 装机却全部超时？真相：广播能通，单播回不来\n100 台 BMC 改密码，从半天缩到 20 分钟：一个脚本搞定批量改密 + 建监控账号\n","date":"August 30, 2026","externalUrl":null,"permalink":"/posts/esxi-vm-recover-after-reinstall/","section":"Posts","summary":"ESXi 系统盘重装后，原本的虚拟机全不见了？别急着格式化数据盘！只要数据盘没被碰过，里面虚拟机文件都还在。挂载快照卷 + 重新注册虚拟机，三步救回全部业务。","title":"ESXi系统盘重装后虚拟机消失？别慌，三步救回数据盘里的虚拟机","type":"posts"},{"content":"","date":"August 30, 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"August 30, 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"August 30, 2026","externalUrl":null,"permalink":"/tags/%E6%95%B0%E6%8D%AE%E6%81%A2%E5%A4%8D/","section":"Tags","summary":"","title":"数据恢复","type":"tags"},{"content":"","date":"August 30, 2026","externalUrl":null,"permalink":"/tags/%E8%99%9A%E6%8B%9F%E5%8C%96/","section":"Tags","summary":"","title":"虚拟化","type":"tags"},{"content":"","date":"August 30, 2026","externalUrl":null,"permalink":"/categories/%E8%BF%90%E7%BB%B4%E5%AE%9E%E6%88%98/","section":"Categories","summary":"","title":"运维实战","type":"categories"},{"content":"📌 转载说明：本文首发于微信公众号《闫工的算力工具箱》 原文链接：https://mp.weixin.qq.com/s/IILoH2DA-vPhB5jBhVDWfw\n【闫工的工具箱 · 第 13 弹｜GPU硬件维修】\r#\r凌晨 1 点，训练任务挂了。\n业务方在群里@我：\u0026ldquo;卡坏了，赶紧换一张。\u0026rdquo;\n先算笔账再动手：一张 A800 十万起步，换卡要走报修、等备件、重新压测，几天起不来；而如果是散热问题，清灰换硅脂几百块、半天搞定。差别这么大，所以别急着换。\n我登录节点，nvidia-smi 一看，8 卡只剩 7 卡，消失的是 GPU 3。再查温度：93°C，Perf Reason 那一栏赫然写着 Throttling（芯片在\u0026quot;自我降速保命\u0026quot;，就是标题里说的那个状态）。\n每年七八月，这是 GPU 集群最常被误判的故障。今天把完整的排查和修复流程写清楚：从确认告警、风道检查、清灰换硅脂到 vBIOS 更新，走完这一套，满载温度能压回 80°C 以内。\n— — —\n1. GPU 为什么会热到掉卡？\r#\rGPU 常年高负载（训练、推理、HPC），散热系统会慢慢劣化：\n灰尘累积：散热鳍片堵了，风进不去； 硅脂老化：干了、裂了，热量导不出来； 风道受阻：线缆挡住、导风罩装错； 风扇老化：转速掉了，甚至直接停转。 散热能力一下降，核心/显存温度逼近阈值，芯片就开始降频保命，表现就是算力骤降、掉卡、甚至宕机。\n记住一个认知：Throttling 不是坏了，是太热了。先查温度，别急着换卡。\n2. 多热算\u0026quot;过高\u0026quot;？\r#\r不同型号上限不同。我把公开资料和运维经验交叉核对后的参考值列出来（以厂商 datasheet 为准）：\n型号 最高工作温度（参考） 警戒线（建议） 行动线（建议） A100 SXM ~83°C \u0026gt;78°C \u0026gt;83°C 持续 5 分钟 H100 SXM5 ~90°C \u0026gt;85°C \u0026gt;85°C 持续 5 分钟 L40 / L40S 8589°C \u0026gt;82°C \u0026gt;85°C 持续 5 分钟 RTX A6000 8993°C \u0026gt;85°C \u0026gt;85°C 持续 5 分钟 ⚠️ 说明：L40/L40S 不同来源给的是 85°C 或 89°C，RTX A6000 是 89°C 或 93°C，官方 datasheet 因 OEM 定制 vBIOS 有差异。最准的办法是看 nvidia-smi 自己报的阈值：\nnvidia-smi -q -d TEMPERATURE | grep -i max\r内部运维目标：满载 ≤80°C、稳定 ≤80°C，留足余量，别贴着上限跑。\n3. 第一步：确认是不是真的\u0026quot;热\u0026quot;\r#\r登录节点，看温度域详情：\nnvidia-smi -q -d TEMPERATURE\r重点看四样：\nGPU Current Temp（核心温度） GPU Memory Temp（显存温度） Fan Speed（风扇转速） 有没有 Throttling 标记 温度逼近上限还带 Throttling，基本可以锁定掉卡元凶就是它。\n4. 第二步：查风道和环境（先别拆机）\r#\r先别急着拆机，八成问题出在环境：\n① 风道方向：必须\u0026quot;前进后出\u0026quot;（Front → Rear），检查有无线缆/面板挡风。\n② 相邻 GPU 间距：≥10mm，太挤会互相加热。\n③ 导风罩：确认 airflow shroud 装对了。\n④ 风扇转速：如果转速为 0 或明显偏低，风扇模组可能挂了：\n# 看风扇传感器 ipmitool sensor | grep -i fan\r⑤ 机房温度：冷通道建议低于 27°C，不然 GPU 散热再努力也白搭。\n5. 第三步：清灰 + 换硅脂（停机操作）\r#\r环境没问题，那就是\u0026quot;积劳成疾\u0026quot;，清灰换硅脂。\n⚠️ 这是停机操作，流程要严谨。普通卡（A100 PCIe / RTX 系列）和高端卡（H100 SXM / 液冷）完全是两套玩法，下面分开讲。\n普通卡（A100 PCIe / 风冷散热）\r#\r图：PCIe 卡正面 PCB 实物——拆下散热器后，中央 die 区还残留着导热硅脂的痕迹，周围是显存与供电电感。PCIe 卡的密度比 SXM 低，拆装风险也小很多，是绝大多数机房能自己上手的卡\n停止业务、断电、拔电源线 拆下 GPU，防静电手环戴好 无尘布 + 异丙醇清洁旧硅脂 压缩空气反吹散热器灰尘 按原装规格换导热硅脂/导热垫（厚度必须一致！） 按编号原位回装螺丝 上电复测 图：PCIe 散热鳍片特写——这就是 GPU 上方的风冷散热器内部，鳍片阵负责把热量带走。灰尘就藏在这片密集的铝片之间，压缩空气反吹是性价比最高的清理方式\n高端卡（H100 SXM / 液冷冷板）\r#\r图：H100 GPU模组内部——8 卡 SXM5 GPU 整齐排在 NVSwitch 周围，中央是金色散热鳍片。高密度集群就是这种\u0026quot;挤法\u0026quot;，温度稍有异常就会被放大成全集群故障\n⚠️ 风险极高。H100 TDP 约 700W，热界面材料是相变材料（PCM）+ 导热垫（putty pad），不是普通硅脂。拆机几乎必然作废保修，且存在损坏 die、HBM、PCB 或水冷系统的风险。\n如果你是厂商授权人员，以下是一份浓缩要点：\n准备工作：\n完全断电，防静电手环、接地工作台 Torx T10/T15 扭矩螺丝刀（典型扭矩约 0.4±0.05 N·m） 酒精清洁垫、新 PCM 套件、putty pad 套件 务必查阅对应机型服务手册（Lenovo SR780a V3、Dell PowerEdge XE9680 等） 拆卸冷板：\n严格按冷板标签上的顺序，先每颗拧松约 720 度，再用扭矩螺丝刀完全松开 用运输支架固定水管，小心抬起冷板模块 用平头工具从角落轻轻撬开，切勿用力过猛或接触 GPU die 周围元件 清洁与更换 TIM：\n用酒精清洁垫轻轻清除旧 PCM 和 putty pad 新 PCM：撕掉一侧保护膜，对准冷板标记贴上，按压排出气泡，停留 1-2 分钟再撕另一侧 Putty pad（通常 5 个左右，覆盖 VRM）：对准标记粘贴，轻压贴合 PCM 更换后有热限制磨合期，需执行官方 PCM TIM 熔融程序 重新组装：\n严格遵循对角线/指定顺序和扭矩值 通电后运行 nvidia-smi、DCGM、nvsm health 诊断和压力测试 三个致命坑，每个都踩出过教训\r#\r下面这张是真实的反面教材——die 中央堆了一大坨、四周又没涂满：\n图：GPU die 上残留的导热硅脂——中央堆得厚、四周没涂到。这种涂法会让局部接触不良，温度压不下来。正确做法是薄薄一层、用刮刀抹平，或用五点法让冷板压下时自然摊开。是不是和你在某些渠道上看到的\u0026quot;涂一大坨更稳\u0026quot;完全反着来？\n坑 后果 正确做法 导热垫厚度不对 厚了压不实，薄了压不住，白干 必须与原装厚度一致（H100 的 putty pad 厚度因位置而异，务必记录原厂规格） 压缩空气直吹风扇叶片 会把风扇吹坏 从散热器反方向吹，或固定扇叶后再吹 裸芯片（H100）螺丝单边锁紧 压裂 die，整块卡报废 必须对角线均匀锁，逐颗递增扭矩，不能一次性拧死 6. 第四步：复测压测\r#\r清完灰换完硅脂，上电压测：\nnvidia-smi # 确认 8 卡全识别 ./gpu_burn 300 # 满载烤 5 分钟 nvidia-smi -l 5 # 每 5 秒刷一次温度\r合格标准：\n满载 70~80°C 风扇转速随温度动态变化 无 Throttling、无掉卡 温度压稳后，建议再跑一遍 NVIDIA 官方的 DCGM 诊断（[Data Center GPU Manager]，包含 nvsm health、dcgmi diag -r 4 等子命令）或者 fieldiag。这是 NV 自家的\u0026quot;过一遍验机\u0026quot;，比手写脚本更全：会从 inventory、connectivity、PCIe、NVLink、显存、性能几条线一起跑过一遍，绿色才算出厂状态。\n下面是修前fieldiag (Field Diagnostics)工具跑出来的真实输出——inventory FAILED、connectivity FAILED，最后 Final Result: FAIL，红线拉到底：\n图：fieldiag 诊断输出（修前那次）—— inventory 失败说明 GPU 没被正确识别，connectivity 失败说明 PCIe / NVLink 链路有问题，gpustress 看似过了但整体 FAIL 依然不能交付。诊断跑完别只看 gpustress 那行，整体 Final Result 才是验收线\n7. 进阶：vBIOS 也要查（仅授权人员）\r#\r如果清灰换硅脂后还热，可能是 vBIOS 版本太老、风扇曲线不合理：\n# 查当前 vBIOS 版本 nvidia-smi -q | grep -i \u0026#34;VBIOS Version\u0026#34; # 备份现有固件（必须！） sudo nvflash64 --save backup.rom # 解除写保护 + 刷写新固件 sudo nvflash64 --protectoff sudo nvflash64 -6 new_vbios.rom\r⚠️ vBIOS 更新是高危操作，必须先用 backup.rom 备份，OEM 机型（Dell/Inspur/Supermicro）用厂商专用工具，别硬刷公版。个人运维请跳过此步骤，直接联系原厂支持。刷错就变砖，没有后悔药。\n8. GPU 高温排查决策树\r#\r为了让你不用把每一步都试一遍，我整理了这个决策树：\n第一步：看温度（nvidia-smi -q -d TEMPERATURE）\n满载 \u0026gt;85°C → 进入第二步 满载 \u0026lt;80°C → 问题不在温度，查 NCCL/驱动/PCIe 第二步：看风扇转速和 Throttling 标记\n风扇满速 + 温度高 → 散热系统失效 → 进入第三步 风扇转速低 + 温度高 → 风扇模组故障 → 换风扇模组 有 Throttling 标记 → 温度越限，进入第三步 第三步：区分核心高温和显存高温\n核心高（GPU Current Temp）→ 硅脂/冷板接触问题 → 清灰换硅脂 显存高（Memory Temp）→ 导热垫老化或风道问题 → 换导热垫 + 检查风道 9. 常见问题对照表\r#\r现象 可能原因 动作 温度高但风扇转速低 风扇模组故障 / 风道受阻 换风扇模组；清风道导风罩 清灰换硅脂后仍高温 导热垫厚度不符 / 热管泄漏 换整套散热模组 掉卡 / Throttling 温度越限触发降频 复核风道、功耗、环境温度 刷固件后异常 刷错/非定制 vBIOS 用 backup.rom 回刷，联系原厂 相邻 GPU 温差大 间距不足 / 缺导风罩 保证 ≥10mm 间距，加装导流罩 清灰换硅脂后温度不降反升 H100 冷板未跑 PCM 磨合期 / 扭矩不对 执行官方 PCM 熔融程序；重装冷板确认扭矩 10. 长期防复发\r#\r每 12 个月换一次导热材料； 每季度清一次风道； 上 Prometheus + nvidia_gpu_exporter 做温度趋势监控，别等告警才处理； GPU 并排安装时加装风道隔板/导流罩。 — — —\n📖 推荐阅读\n服务器红灯告警说硬盘坏了，我没换——结果真救活了\n凌晨3点的GPU服务器：一次BMC故障排查全记录\nGPU全在、驱动正常，训练就是卡死——NVLink悄悄坏了一半\n满血的 200G 网卡被降成「残血」：我围着 NCCL 调了一宿，真凶藏在主板背后一根线\n","date":"August 26, 2026","externalUrl":null,"permalink":"/posts/gpu-throttling-93c/","section":"Posts","summary":"凌晨训练任务挂了，8 卡只剩 7 卡，温度 93°C 还带 Throttling——卡没坏，是太热了。从确认告警、风道检查、清灰换硅脂到 vBIOS 更新，完整排查流程，满载压回 80°C。","title":"8卡变7卡、93°C还在Throttling：卡没坏，是热到'自我降速'了","type":"posts"},{"content":"","date":"August 26, 2026","externalUrl":null,"permalink":"/tags/gpu/","section":"Tags","summary":"","title":"GPU","type":"tags"},{"content":"","date":"August 26, 2026","externalUrl":null,"permalink":"/tags/%E6%95%85%E9%9A%9C%E6%8E%92%E6%9F%A5/","section":"Tags","summary":"","title":"故障排查","type":"tags"},{"content":"","date":"August 26, 2026","externalUrl":null,"permalink":"/categories/%E7%AE%97%E5%8A%9B%E5%9F%BA%E5%BB%BA/","section":"Categories","summary":"","title":"算力基建","type":"categories"},{"content":"","date":"August 26, 2026","externalUrl":null,"permalink":"/tags/%E8%BF%90%E7%BB%B4%E5%AE%9E%E6%88%98/","section":"Tags","summary":"","title":"运维实战","type":"tags"},{"content":"📌 转载说明：本文首发于微信公众号《闫工的算力工具箱》 原文链接：https://mp.weixin.qq.com/s/jYKUvo2zwJCZ8OBNpBP-zg\n【闫工的工具箱 · 第 12 弹｜实战】\r#\r我是闫工，数据中心搬砖的 CCIE。\n先直接说损失账：这台 8 卡 GPU服务器交付当天就趴窝，训练集群少算力一小时，客户那边就是一笔真金白银。更让人挠头的是，显卡全在、驱动正常，卡死的却是训练任务。\n先解释下标题里的黑话：NVLink 是 GPU 之间的高速通道，Fabric Manager（FM）是管这条通道的服务。这台机器的问题，就是 NVLink 悄悄坏了一半，而 FM 这个\u0026quot;交警\u0026quot;直接罢工了。一开始按驱动问题处理，重装驱动、换 CUDA 版本，折腾了半天。后来才搞明白，FM 只需改一行配置，就能让这台机器\u0026quot;带伤上岗\u0026quot;。\n— — —\n1. 诡异现场：训练卡死，FM 反复起不来\r#\r新上架的 8 卡 A800-SXM4-80GB，跑分布式训练时 NCCL 疯狂报错。先看服务状态：\nsystemctl status nvidia-fabricmanager ● nvidia-fabricmanager.service - NVIDIA fabric manager service Active: activating (start) since Fri 2026-07-24 16:24:59 CST; 1s ago\ractivating → failed → activating → failed，无限循环。再看日志：\njournalctl -u nvidia-fabricmanager -n 50 nv-fabricmanager[31506]: NVLink initialization failed for NodeId:0 nvswitch0 NVLink:24 nv-fabricmanager[31506]: NVLink initialization failed for NodeId:0 GPU PCI bus id:00000000:55:00.0 enumIndex:5 NVLinkIndex 3 nv-fabricmanager[31506]: global fabric manager initialization failed More than one NVSwitches have trunk NVLink failed, set to abort Fabric manager\r上面几行是细节，最后一句 More than one NVSwitches have trunk NVLink failed 才是破案核心——它直接告诉我们，故障发生在 NVSwitch 的 Trunk 链路上。不止一个 NVSwitch 的 trunk 链路坏了，FM 的安全机制直接中止启动，宁可停机也不带伤运行。这个设计平时是保护，排查时就成了迷惑源：明明 GPU 都在，服务却起不来，很容易让人误判成驱动问题。\n2. 破案：nvidia-smi 一行看出 NVLink 伤情\r#\rFM 起不来，但 GPU 本身是活的。用 nvidia-smi nvlink \u0026ndash;status 看每条 NVLink 链路：\n结果是这样的：\nGPU 故障链路 正常链路 故障率 GPU 0 1 条 7 条 12.5% GPU 1 2 条 6 条 25% GPU 2 1 条 7 条 12.5% GPU 3 5 条 3 条 62.5% GPU 4-7 0 条 8 条 0%（正常） GPU 3 最惨，8 条 NVLink 废了 5 条，基本等于半残。还有个细节：GPU 0-3 在一台 NVSwitch 域里，GPU 4-7 在另一台，后者完全正常。\nnvidia-smi topo -m 确认拓扑：\nGPU 0↔GPU 3 只有 3 条 NVLink（NV3，正常应 8 条），GPU 4↔GPU 7 是完整的 NV8。问题集中在 GPU 0-3 这个 NVSwitch 域。\ndmesg 也给出佐证：\ndmesg | grep \u0026#34;NVRM.*fabric address\u0026#34; NVRM: knvlinkCheckNvswitchP2pConfig_IMPL: GPU 0 doesn\u0026#39;t have a fabric address NVRM: knvlinkCheckNvswitchP2pConfig_IMPL: GPU 3 doesn\u0026#39;t have a fabric address\rGPU 0 和 GPU 3 拿不到有效的 fabric 地址，NVSwitch 的 trunk 链路没建立起来，GPU 连不上 NVSwitch。\n3. Access Link 还是 Trunk Link？故障面完全不同\r#\rNVLink 链路分两种，故障影响差得远：\nAccess Link（GPU → NVSwitch）：只影响单个 GPU 的通信； Trunk Link（NVSwitch ↔ NVSwitch）：影响整个 NVLink 域。 咱们这次是 Trunk Link 故障，NVSwitch 之间断了，整个 GPU 0-3 域通信瘫痪。这也是 FM 直接 abort 的原因：它检测到\u0026quot;多个 NVSwitch trunk 失败\u0026quot;，认为整个 fabric 不可信，干脆停机保平安。\n4. 为什么换块 GPU 没用？根子在 NVSwitch\r#\r有人会问：换块 GPU 试试？没用。根子不在 GPU 卡上，而在 NVSwitch 芯片或 GPU 与 NVSwitch 之间的物理连接（背板/线缆）。可能的硬件原因：\nGPU 3 的 NVLink 引脚 / 背板接触不良； NVSwitch 芯片部分 trunk 链路损坏； 电源波动导致 NVLink 链路不稳定； NVSwitch 过热自动降级。 5. 解决方案：修改 FM 配置，容忍 NVLink 故障\r#\r硬件换不了，业务不能停。那就改 Fabric Manager 配置，让它容忍部分 NVLink 故障，坏哪块禁哪块，剩下的 GPU 继续干活。\n1. 停服务 systemctl stop nvidia-fabricmanager 2. 追加配置（NVLink 故障容忍） cat \u0026gt;\u0026gt; /usr/share/nvidia/nvswitch/fabricmanager.cfg \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; # NVLink故障容忍配置 TRUNK_LINK_FAILURE_MODE=1 # 禁用故障NVSwitch，不影响整体 ACCESS_LINK_FAILURE_MODE=0 # 移除故障GPU的P2P能力 NVSWITCH_FAILURE_MODE=1 # 禁用故障NVSwitch FM_STAY_RESIDENT_ON_FAILURES=1 # 即使有故障也保持运行 EOF 3. 启动服务 systemctl start nvidia-fabricmanager\r⚠️ 配置文件路径因发行版/厂商而异：不同发行版或服务器厂商（如 Dell、HPE）的配置文件路径可能不同，我这里是 /usr/share/nvidia/nvswitch/fabricmanager.cfg，你的机器可能是 /etc/nvidia/fabricmanager.cfg。如果上述路径不存在，用这条命令确认实际位置，别照抄： find / -name \u0026ldquo;*fabricmanager*.cfg\u0026rdquo; 2\u0026gt;/dev/null\nFM 启动成功，故障 NVSwitch 被禁用，其余 GPU 继续工作，训练恢复。虽然 GPU 0-3 之间通信降级，但整体业务能跑，这已经是最好的结果了。\n6. 备选方案（按风险从低到高）\r#\r方案 操作 效果 风险 ① 改 FM 配置（推荐） 追加故障容忍配置 禁坏 NVSwitch，其余继续 低 ② GPU 软重置 nvidia-smi \u0026ndash;gpu-reset + 重载驱动 可能恢复部分 NVLink 中 ③ 完全断电重启 关机、拔电源 30 秒、上电 最彻底，可能解决锁死 中高 ④ 禁用全部 NVLink 内核参数 NVreg_NvLinkDisable=1 GPU 走 PCIe 通信，性能暴跌约 95% 高 ⚠️ 方案③的风险：A800 SXM 是整机系统（DGX/HGX），完全断电会导致所有 GPU 同时掉电，可能影响 NVLink fabric 的初始化顺序，甚至让本来正常的链路也暂时起不来。部分节点重启后需要重新配置 FM。建议作为最后手段，先试 ①②。\n方案④的性能账：NVLink 域内带宽约 600 GB/s，禁用后 GPU 之间走 PCIe 4.0 x16（约 32 GB/s），暴跌约 95%，等于把 8 卡机变成 8 台独立机器。\n7. 给交付团队的建议\r#\r几条血的教训，写进你的检查清单：\n验收必查 NVLink：nvidia-smi nvlink \u0026ndash;status + nvidia-smi topo -m，别只看 nvidia-smi 8 卡在不在； FM 状态要看：systemctl status nvidia-fabricmanager 必须 active，activating 就是有坑； 区分 Access/Trunk：trunk 故障影响整域，故障面比单卡大得多； NVLink 故障不致命但影响性能：把坏域 GPU 放同一节点、不同通信组，能有效规避影响。 ","date":"August 23, 2026","externalUrl":null,"permalink":"/posts/nvlink-half-broken-training-stuck/","section":"Posts","summary":"8 卡 A800 训练卡死，显卡全在、驱动正常，可训练就是跑不动。查下来是 GPU 之间的 NVLink 高速通道废了 5 条。改一行配置让服务\"带伤上岗\"，集群满血复活。","title":"GPU全在、驱动正常，训练就是卡死——NVLink悄悄坏了一半","type":"posts"},{"content":"","date":"August 23, 2026","externalUrl":null,"permalink":"/tags/nvlink/","section":"Tags","summary":"","title":"NVLink","type":"tags"},{"content":"📌 转载说明：本文首发于微信公众号《闫工的算力工具箱》 原文链接：https://mp.weixin.qq.com/s/DwApGCxSZ8TCOIEV7lYSsg\n【闫工的工具箱 · 第 11 弹｜工具】\r#\r大家好！这次给大家分享一个机房运维中的小脚本工具。\n先交代个背景：新机房一次性上架了 100 多台服务器，BMC 全顶着出厂默认密码。安全整改的单子已经下了，要求统一改强口令、加监控账号。\n100 多台，逐台登 Web 界面：改密码、建账号、配权限。一台顺的话 5 分钟，不顺手 10 分钟。我算了算，半天没了，还得祈祷自己别手滑输错。\n后来我把这活写成了脚本。100 台，20 分钟跑完，还带失败清单。今天就把这套东西给你，拿去改改 IP 就能用。\n— — —\n1. BMC 是什么？为什么非得管它？\r#\rBMC（Baseboard Management Controller），服务器的\u0026quot;带外管家\u0026quot;。机器死机、断电、系统起不来的时候，你还能通过它远程开机、看传感器、装系统。\n它的权限，等于服务器的物理权限——能开机、能进固件、能读硬件传感器。出厂默认密码摆在那，等于把机房大门钥匙挂在门口。\n安全整改第一件事，就是把这把钥匙换了，再给监控系统留一把低权限的备用钥匙。\n2. 为什么不能一台台登 Web？\r#\r三个理由，每个都是泪：\n100 台 × 登录 + 改密 + 建账号，半天起步； 手滑一次，密码没改成功但你以为改了，等于白干； 改完还要复核。日志呢？审计呢？回头查哪个改了哪个没改，脑壳疼。 点鼠标最累的不是手，是心——你永远不确定\u0026quot;这一台到底改没改成\u0026quot;。\n3. 破局：IPMI 协议，一行命令远控 BMC\r#\rIPMI（Intelligent Platform Management Interface）是服务器带外管理的开放标准协议，BMC 就是它的落地实现。IPMI 2.0 支持 lanplus 加密通道，走 UDP 623 端口远程执行命令。\nLinux 下最常用的工具是 ipmitool：\n# 装工具（RHEL/CentOS/Rocky） yum install -y ipmitool # 或（Debian/Ubuntu） apt install -y ipmitool # 远程查某台 BMC 的电源状态 ipmitool -I lanplus -H 10.X.X.10 -U Admin -P Admin chassis power status\r一行命令能读状态，那改密码、建账号，自然也能远程批量干。\n⚠️ 安全提醒（生产环境必看）：示例里密码是明文写在命令行里的（-P Admin），仅用于演示。明文密码会留在 shell 历史、进程列表里——管理机上其他同事一个 ps aux 就能看到你的密码。生产环境请用 -f 参数从文件读密码，或通过环境变量注入：\n# 方式一：从文件读密码（推荐） echo -n \u0026#39;Admin\u0026#39; \u0026gt; /root/.bmc_pass \u0026amp;\u0026amp; chmod 600 /root/.bmc_pass ipmitool -I lanplus -H 10.X.X.10 -U Admin -f /root/.bmc_pass chassis power status # 方式二：环境变量注入（ipmitool 支持 IPMI_PASSWORD） export IPMI_PASSWORD=\u0026#39;Admin\u0026#39; ipmitool -I lanplus -H 10.X.X.10 -U Admin chassis power status\r批量脚本里同样建议：密码从配置文件读，不写死在命令行。\n— — —\n4. 批量脚本核心设计\r#\r脚本原理不复杂，但有四个设计点，缺一个都会翻车：\n4.1 清单化：IP 列表文件，可注释可排除\r#\r# ips.txt —— 每行一个 BMC IP，支持 # 注释 10.X.X.10 10.X.X.11 \\# 10.X.X.12 # 这台先排除，别改 10.X.X.13\r4.2 动态探测 UserID（第一个坑就在这）\r#\r不同厂商的 BMC，默认管理员的 UserID 不一样。有的厂商是 2，有的不是。写死\u0026quot;管理员就是 UserID 2\u0026quot;的脚本，换一批机器就翻车。\n所以第一件事是动态探测：\n# 动态探测 UserID（不同厂商默认管理员 UserID 不一样，不能写死） get_userid() { ipmitool -I lanplus -H \u0026#34;$1\u0026#34; -U \u0026#34;$OLD_USER\u0026#34; -P \u0026#34;$OLD_PASS\u0026#34; user list \\ | grep -i \u0026#34;$2\u0026#34; | awk \u0026#39;{print $1}\u0026#39; } # 改密：先定位管理员 UserID，再 set password change_password() { uid=$(get_userid \u0026#34;$1\u0026#34; \u0026#34;$OLD_USER\u0026#34;) ipmitool -I lanplus -H \u0026#34;$1\u0026#34; -U \u0026#34;$OLD_USER\u0026#34; -P \u0026#34;$OLD_PASS\u0026#34; \\ user set password \u0026#34;$uid\u0026#34; \u0026#34;$NEW_PASS\u0026#34; } # 建用户：从 UserID 3 开始找空闲槽位，避免覆盖已有账号 create_user() { for uid in $(seq 3 16); do name=$(ipmitool -I lanplus -H \u0026#34;$1\u0026#34; -U \u0026#34;$2\u0026#34; -P \u0026#34;$3\u0026#34; user list | awk -v id=$uid \u0026#39;$1==id{print $4}\u0026#39;) [ -z \u0026#34;$name\u0026#34; ] \u0026amp;\u0026amp; break # 找到空闲槽位 done ipmitool ... user set name \u0026#34;$uid\u0026#34; \u0026#34;$username\u0026#34; ipmitool ... user set password \u0026#34;$uid\u0026#34; \u0026#34;$upass\u0026#34; ipmitool ... channel setaccess 1 \u0026#34;$uid\u0026#34; callin=true ipmi=true link=true privilege=\u0026#34;$priv\u0026#34; ipmitool ... user enable \u0026#34;$uid\u0026#34; }\r4.3 并发控制：20 台同时跑，带重试和超时\r#\rMAX_JOBS=20 # 并发数，别一上来全开 RETRY=2 # 单操作失败重试次数 CMD_TIMEOUT=15 # 单条命令超时（秒） job_count=0 while read -r ip; do [[ -z \u0026#34;$ip\u0026#34; || \u0026#34;$ip\u0026#34; =~ ^# ]] \u0026amp;\u0026amp; continue process_ip \u0026#34;$ip\u0026#34; \u0026amp; ((job_count++)) (( job_count \u0026gt;= MAX_JOBS )) \u0026amp;\u0026amp; { wait; job_count=0; } done \u0026lt; ips.txt wait\r4.4 完整日志：每台独立日志 + 失败清单\r#\r跑完自动生成三样东西：\nlogs/bmc_*.log\n——每台每一步的结果；\nbmc_success.txt\n——成功的 IP 清单；\nbmc_fail_*.txt\n——失败的 IP 清单。\n失败的清单是重点。下一轮只重试这批，不用重新全量跑。批量脚本和一把梭的区别，就在这——出了事有据可依，不是黑箱操作。\n另外，前面说\u0026quot;改完还要复核、审计\u0026quot;，这套日志就是审计留底：每台每一步都有记录，安全审计要凭证的时候，翻 logs/ 就行，不用像登 Web 那样手动截图。\n— — —\n5. 执行 \u0026amp; 验证\r#\rchmod +x bmc_manage.sh ./bmc_manage.sh\r跑完别急着收工，验证三步走：\n# ① 改密前：旧密码还能用？（用旧密码随便查个状态） ipmitool -I lanplus -H 10.X.X.10 -U Admin -P Admin chassis power status # ② 改密后：旧密码应失效，新密码能登录 ipmitool -I lanplus -H 10.X.X.10 -U Admin -P NewStrongPassw0rd!2025 chassis power status # ③ 账号列表里能看到新加的 monitor/operator/readonly ipmitool -I lanplus -H 10.X.X.10 -U Admin -P NewStrongPassw0rd!2025 user list\r— — —\n6. 踩过的坑（抄作业前先看）\r#\r现象 真凶 解法 Unable to establish IPMI v2 / RMCP+ session 网络不通 / UDP 623 被挡 / 用户名大小写错 先单台测连通；确认管理 VLAN 放行 623 建了用户，user list 却看不到 槽位被占用 / 权限没生效 用空闲槽位探测；确认 channel setaccess 里 ipmi=true 改密成功，后续命令用新密码却失败 厂商默认管理员 UserID 不是 2（写死导致） 改用动态 get_userid，别假设管理员 ID 某品牌 BMC 改密返回成功，新密码却登录失败 BMC 固件版本太老，不支持 user set password 的某些参数格式 升级 BMC 固件；或改用 user enable + user disable 组合操作 并发跑着跑着超时 管理机网络/会话数顶不住 降 MAX_JOBS、加 CMD_TIMEOUT、加 RETRY 💡 兼容性提醒：不同厂商 BMC 对 ipmitool 的支持程度不一样，老款型号尤其容易有坑。批量跑之前，先拿一台测试机验证一条命令： ipmitool -H test_ip -U admin -P admin user list 能正常返回再批量跑，确认不了的厂商型号先排除。\n安全铁律，三条：\nBMC 必须进独立管理 VLAN，禁止对公网暴露 UDP 623； 监控账号用低权限（Operator/User），禁止共用管理员账号； 先小批量（≤5 台）灰度，确认无误再全量。批量改密失败会导致部分 BMC 失联——到时候哭都来不及。 — — —\nEND\r#\r批量改完 BMC，机器能远程管了。但新交付的 8 卡 GPU 服务器刚上架，训练一跑就卡死——nvidia-smi 显示 8 张卡都在，nvidia-fabricmanager 却反复起不来。NVLink 悄悄坏了一半，表面根本看不出来。\n下期，聊聊一台 8 卡 GPU 服务器的 NVLink 故障排查：Fabric Manager 起不来，NVLink 悄悄坏了一半。\n关注公众号\n硬核实战经验，带你轻松避坑！\n","date":"August 21, 2026","externalUrl":null,"permalink":"/posts/bmc-batch-password/","section":"Posts","summary":"新机房上架 100 多台服务器，BMC 还是出厂默认密码？逐台登 Web 改要一整天。用 IPMI 写个批量脚本：改密、建监控账号、并发重试、失败清单，100 台 20 分钟跑完。","title":"100 台 BMC 改密码，从半天缩到 20 分钟：一个脚本搞定批量改密 + 建监控账号","type":"posts"},{"content":"","date":"August 21, 2026","externalUrl":null,"permalink":"/tags/bmc/","section":"Tags","summary":"","title":"BMC","type":"tags"},{"content":"","date":"August 21, 2026","externalUrl":null,"permalink":"/tags/%E8%87%AA%E5%8A%A8%E5%8C%96/","section":"Tags","summary":"","title":"自动化","type":"tags"},{"content":"","date":"July 31, 2026","externalUrl":null,"permalink":"/tags/raid/","section":"Tags","summary":"","title":"RAID","type":"tags"},{"content":"📌 转载说明：本文首发于微信公众号《闫工的算力工具箱》 原文链接：https://mp.weixin.qq.com/s/ZtKF6rjKzzWZvzGgt0sZnw\n【闫工的工具箱 · 第 5 弹】\r#\r我是闫工，数据中心搬砖的 CCIE。\n这是「闫工的工具箱」第 5 篇。前 4 弹分别是：SN 剪贴速记（录 SN 提速）、硬盘擦除工具（下架清数据）、BMC 故障排查（GPU 起不来）、再到上一篇的批量装系统 MAAS 镜像打包（自己造 Rocky 种子）。\n上一篇讲了 MAAS 镜像打包，从零造了个 Rocky 的\u0026quot;种子\u0026quot;。这篇回到排障线——硬盘状态标了 UBad（RAID 卡误报的「疑似坏盘」标记，盘往往根本没坏），监控群里喊换盘，但我没换。\n— — —\n下午 4 点 17 分，群里炸了\r#\r下午 4 点 17 分，监控告警群里弹出一条告警：「存储节点 /dev/sdb 状态异常，UBad」。\n紧接着群里跟了一句：「UBad 了，换盘吧。」\n图：硬件监控面板——告警触发时的磁盘状态\n换一块企业级硬盘，钱不是大头——业务重建、数据同步、阵列降级期间的服务影响，这些才是。而且机器还在跑业务，动一块盘牵一发而动全身。\n我没急着拔。因为我见过太多次 UBad 被当成了\u0026quot;盘坏了\u0026quot;，换下来的盘插到另一台机器上一测，SMART 干干净净，啥事没有。\nUBad 这仨字母，第一次见的人容易慌，但干过几年存储的都知道：UBad 不等于物理损坏。\n这次我没换盘，先开了个终端。\n— — —\nUBad 到底是个啥\r#\rUBad = Unconfigured Bad，直译\u0026quot;未配置的不良盘\u0026quot;。它和 Onln（在线）、UGood（未配置但健康）不是一回事。简单记：\n盘在线干活 → Onln 盘没进阵列但本身没问题 → UGood 盘被 RAID 卡判成\u0026quot;状态存疑\u0026quot; → UBad 图：RAID 卡视角——同一端口两块盘：一块 Unconfigured Bad，一块 Online\n为啥会出现 UBad？三种最常见的原因：\n逻辑 / 元数据对不上：异常断电、误插拔，导致硬盘上的 RAID 配置信息和控制器的记录不匹配——盘没坏，是\u0026quot;账对不上\u0026quot;。最常见。 物理介质故障：盘真有坏道、SMART 已经报警了。这种才是真坏。 临时通信故障：背板接触不良、线缆松了、供电不稳，盘短暂失联，RAID 卡一慌就给它标了 UBad。 核心原则就一句：UBad ≠ 坏了。先诊断，别急着换盘。\n换一块好盘容易，但要是盘根本没坏、只是被误判，你换掉的可是还能再战三年的盘，还白搭一次重建的风险。\n— — —\n先看全局，别动\r#\r盘挂着 UBad，第一反应不是 set good、不是拔盘，而是先把真实状态看清楚。RAID 卡记的东西比你看一眼 LED 灯准得多。\n登录机器，按这个顺序过五步，盘到底坏没坏、坏在哪，基本就清楚了。\n准备工作：确认 StorCLI 已安装\n如果系统里还没有 storcli64 命令，需要先安装。安装包到 Broadcom 官网搜索 \u0026ldquo;StorCLI\u0026rdquo; 下载，Ubuntu 系统用 .deb 包安装：\nsudo dpkg -i storcli_*.deb sudo ln -s /opt/MegaRAID/storcli/storcli64 /usr/local/sbin/storcli64\r安装完成后，storcli64（64 位版本）位于 /opt/MegaRAID/storcli/ 目录下。Ubuntu 22.04 是 64 位系统，全文统一使用 storcli64。\n图：storcli64 show —— 控制器已识别\n第一步：确认控制器认到了\nstorcli64 show\r预期看到 Number of Controllers = 1 且列出控制器型号（比如 AVAGO MegaRAID SAS 9460-8i）。这一步先确认工具装对了、卡认到了。\n第二步：看每一块盘的真实状态\nstorcli64 /c0 /eall /sall show\r图：storcli64 /c0 /eall /sall show —— 两块盘并列：一块 UBad，一块 Onln\n这是最常用的一条。输出里每块盘一行，状态字段含义如下：\n状态值 说明 Onln Online，硬盘在线且正常工作 UGood Unconfigured Good，未配置的好盘（可加入阵列） UBad Unconfigured Bad，未配置的不良盘（需处理） Offln Offline，硬盘离线 Rbld Rebuild，正在重建数据 F Foreign，存在外部配置信息 DHS Dedicated Hot Spare，专用热备盘 GHS Global Hotspare，全局热备盘 输出里，两块盘并列：一块 UBad，一块 Onln。\n第三步：查 SMART，看盘有没有物理损伤\nstorcli64 /c0 /e252 /s0 show smart\r/e252 /s0 是\u0026quot;第 252 号 Enclosure 的第 0 号 Slot\u0026quot;，按你实际槽位替换。重分配扇区计数是 0，pending 错误也是 0——物理层面干干净净。SMART 里如果有大量重分配扇区、pending 错误，那大概率是物理坏道；如果 SMART 干干净净，基本可以排除物理故障。\n第四步：查 RAID 卡事件日志\n先把日志导出到文件再过滤，别直接管道 grep——日志量大的时候容易卡住：\nstorcli64 /c0 show events \u0026gt; /tmp/raid_events.txt grep -i \u0026#34;bad\\|fail\\|error\u0026#34; /tmp/raid_events.txt | tail -30\r⚠️ 注意：如果日志量很大，直接 show events | grep 可能会卡住。建议先导出到文件再过滤，更稳妥。\n日志里有一行：PD 0x1a 状态变更：Onln → UBad，原因：写入超时。写入超时 ≠ 盘坏了。可能是背板信号抖了一下，也可能是那次写入刚好碰到了盘内部的重试。RAID 卡的事件日志会记下盘掉线、通信超时的来龙去脉。是\u0026quot;瞬间失联又回来\u0026quot;，还是\u0026quot;持续报错\u0026quot;，一看便知。\n第五步：查有没有外部配置残留\nstorcli64 /c0 /fall show\r结果显示有 Foreign 配置。这块盘上残留着之前在别的阵列里的 RAID 元数据，RAID 卡识别到了但不知道怎么处理，索性标了个 UBad。\n信息收束：盘没坏，是账对不上了。\n场景判断：先定性，再动手\r#\r诊断结果 处理方案 硬盘显示 UBad，但 SMART 正常 按逻辑 / 通信问题处理（多半能救回） 硬盘显示 UBad，且 SMART 有严重报错 按物理故障处理，直接换盘 所有硬盘显示 Onln，VD 状态 Optimal 无需操作，阵列健康 阵列已离线或控制器都识别不到 立即关机，找专业数据恢复，别自己折腾 — — —\n两行命令救回来\r#\r⚠️ 执行前注意：RAID 1 阵列已处于降级状态（只剩单盘在工作），操作前务必确认数据有最近可用的备份，或至少确认另一块盘的健康状态。重建期间不要重启或断电。\n方案 A：逻辑 / 通信问题（硬盘本身 OK）—— 大部分情况都是它（如果业务允许也可以重启设备进到服务器BIOS里设置，我这里就不具体讲了，逻辑是一样的。）****\n第一步，把盘从 UBad 改回 UGood：\nstorcli64 /c0 /e252 /s1 set good\r图：set good —— 盘状态从 UBad 改回 UGood，\u0026ldquo;Set Drive Good Succeeded\u0026rdquo;\n第二步，导入外部配置（如果上一步发现有过 Foreign）：\nstorcli64 /c0 /fall import\r图：storcli64 /c0 /fall show —— 发现 Foreign（外部残留）配置\n导入成功后，RAID 卡自动触发了重建（状态变成 Rbld）。几十分钟后（SSD 重建本来就快），状态回到 Onln。群里没人再提换盘了。\n图：fall import —— 外部配置导入成功，盘状态从 UBad → Rbld（重建中）\n图：修复后——监控面板：HDD0 / HDD1 双盘全部正常 ✓\n补充：如果 fall show 显示没有 Foreign 配置，说明盘上的 RAID 元数据已被清除，此时无法通过 import 恢复。这种情况可以尝试手动将盘加入磁盘组，或直接按方案 B 用新盘替换。具体操作需根据阵列配置判断，本文不展开。\n方案 B：物理故障（真坏道）—— 该换就换\n确认故障盘的 EID 和 Slot，服务器开机状态下直接拔出坏盘，插一块容量、规格完全相同的新盘。RAID 卡通常会自动开始重建；要是没自动起，手动推一把：\nstorcli64 /c0 /e252 /s1 start rebuild\r— — —\n这次踩的几个坑\r#\r坑一：storcli64: command not found\n装完 DEB 包，命令默认在 /opt/MegaRAID/storcli/storcli64，不在 PATH 里。建个软链就哪儿都能用了：\nsudo ln -s /opt/MegaRAID/storcli/storcli64 /usr/local/sbin/storcli64\r坑二：set good 执行失败\n如果 set good 直接报错、盘死活不肯回到 UGood，多半是盘真有物理坏道。这时候别硬刚，按方案 B 换盘最稳。\n坑三：storcli64 show 看不到控制器\n先确认 RAID 卡驱动正常：lspci -vv | grep -i raid，看不到卡就得先排查驱动 / 卡槽，别在工具层面死磕。\n坑四：没备份就动手\n这条不是命令坑，是心法坑。set good + import 看着无伤大雅，但任何对阵列的写操作都有风险。动手前确认有最近可用的备份——它是你最后一道防线，没有之一。\n— — —\n结尾\r#\r那块盘救回来之后，又安安静静跑了很长时间，再没出过问题。\n复盘几点：\nUBad ≠ 坏了——它是 RAID 卡的保护机制，先\u0026quot;冻\u0026quot;住等你确认，不是判死刑 先诊断后操作——SMART 正常就按逻辑问题处理，SMART 有报错才换盘 操作前确认备份——最后一道防线，没有之一 定期巡检 SMART 和阵列状态——别等告警响了才看 存储这条线先收在这儿。上上集讲\u0026quot;盘擦干净地走\u0026quot;（回复「擦除」拿工具），上集讲\u0026quot;盘怎么造镜像进 MAAS\u0026quot;，这集讲\u0026quot;盘被误判别误杀\u0026quot;。\n下期是个大块头——一台裸金属从 0 到交付，10 个坑我帮你踩完了。关注本号，下期见。\n","date":"July 31, 2026","externalUrl":null,"permalink":"/posts/raid-false-alarm-hdd/","section":"Posts","summary":"服务器报警说硬盘坏了，监控群里喊换盘。我没换——因为那多半是 RAID 卡误报的「疑似坏盘」标记，盘根本没坏。用 StorCLI 5 分钟平反：先看全局、再查 SMART 和健康日志，逻辑问题一键重建，真有物理坏道才换。别让一块好盘白白被换掉。","title":"服务器红灯告警说硬盘坏了，我没换——结果真救活了","type":"posts"},{"content":"","date":"July 31, 2026","externalUrl":null,"permalink":"/tags/%E7%A1%AC%E7%9B%98/","section":"Tags","summary":"","title":"硬盘","type":"tags"},{"content":"📌 转载说明：本文首发于微信公众号《闫工的算力工具箱》 原文链接：https://mp.weixin.qq.com/s/5CVjC9R8qVRwQVAwphXzBA\n我是闫工，数据中心搬砖的CCIE。\n前两弹聊的都是工具（SN剪贴速记、硬盘擦除）。这弹换个口味——不卖工具，卖教训。\n第一篇实战，讲个我印象最深的故障：凌晨3点，一台8卡GPU服务器，没了。\n现场：它死透了，但没死绝\r#\r凌晨3点，手机震醒。\n监控大屏上一片红：集群里一台8卡GPU节点失联，训练任务中断。SSH连不上，ping不通——硬掉线。\n那一瞬间脑子里闪过的念头很真实：炸了？这么贵的GPU设备，大半夜的……\n但我没往机房跑。因为这台机器虽然\u0026quot;死\u0026quot;了，主板上还住着一个独立供电、独立网络的小东西——BMC。它还在线。\n登录BMC网页，第一眼就翻它的系统事件日志（SEL，相当于服务器的\u0026quot;黑匣子\u0026quot;）。里面反复出现这么几行：\nSEL #123 | Power Unit | Power off/down | Asserted SEL #124 | Power Unit | Power off/down | Deasserted SEL #125 | Power Unit | Power off/down | Asserted SEL #126 | Power Unit | Power off/down | Deasserted\rAsserted = 掉电，Deasserted = 恢复。交替出现，反复横跳。\n翻译成人话：机器的供电在\u0026quot;抖\u0026quot;——掉一下、回来、再掉一下、又回来。不是软件崩了，是电没供稳，主机被物理拽停。\n图：电源页面拉出来一看——PSU3 紧急、PSU4 轻微，另外两块正常\nOK，有方向了。接下来一步步查。\n查证：一步步锁定真凶\r#\r第一步：确认是哪块电源模块出了问题\nGPU服务器通常配4到6个电源模块（GPU功耗大，冗余必须拉满）。用 ipmitool 扫一遍PSU状态：\nipmitool -I lanplus -H 192.168.x.x -U admin -P \u0026#39;******\u0026#39; sdr list | grep -i psu\r输出：\nPSU1 Status | ok PSU2 Status | ok PSU3 Status | failure PSU4 Status | ok\rPSU3 状态是 failure，其他三块正常。这台机器是4电源冗余配置（N+N或N+1），坏一块按理说还能撑住。但SEL里显示的是反复掉电恢复，说明不止是\u0026quot;坏了一块\u0026quot;那么简单——剩下的PSU在负载波动时也扛不住了，或者坏的那块在反复尝试上线又失败，把整路电都拖得不稳。\n第二步：排除软件层面\n掉电第一反应是\u0026quot;是不是系统里有人触发了关机\u0026quot;？查操作系统日志：\njournalctl --since \u0026#34;2:00:00\u0026#34; | grep -i \u0026#34;shutdown\\|poweroff\\|thermal\u0026#34;\r干干净净，啥也没有。dmesg 里也没有温度过高的告警。说明关机不是操作系统主动触发的，是硬件层直接被拽断了。\n第三步：排查机房供电环境\n电源冗余的机器，如果PDU有一路在闪断，SEL里也会出现类似的\u0026quot;掉电/恢复\u0026quot;交替记录。让机房值班同事帮忙看了一眼那台机器所在的PDU端口指示灯——正常亮着，没有闪烁。电源线也重新插拔了一遍，确认没有虚接。\n线索收束：PSU3硬件故障 + 负载波动时供电不稳 → 机器被反复拽停。\n图：BMC 告警面板拉满——PSU3 紧急（电源输入丢失）、HDD0 严重（驱动器故障），电源和存储同时报警\n顺带挖出第二颗雷\r#\r那晚顺手打开了BMC的远程KVM（就是隔空看屏幕），想确认机器死的时候屏幕上有没有留下什么。\n结果看到了一个 kernel panic 界面：\nRIP: 0010:ceph_set_page_dirty+0x1ba/0x1c0 [ceph] ---[ end trace f6f982abafac13ee ]--- CR2: 0000000000000070\r旁边 nvidia_uvm、nvidia_drm 这些NVIDIA驱动模块还挂在 Tainted（内核污染）列表里。\n意思很明确：这台机器除了电源隐患，还埋着另一颗雷——NVIDIA驱动和内核/Ceph存储I/O有兼容性问题。高负载下自旋锁死锁（日志里能看到 native_queued_spin_lock_slowpath），驱动崩了连带kernel一起panic。电源抖是\u0026quot;导火索\u0026quot;，驱动不稳是\u0026quot;体质问题\u0026quot;。\n真要长治久安，驱动版本和内核得对齐，Ceph客户端的I/O压力也得调。\n真凶找到了，怎么救？\r#\r短期止血：\n远程冷重启（Power Cycle）——先把业务拉起来，训练任务恢复 锁定PSU3，不让它再上线（有故障的电源模块反复尝试接入反而会拖累整路电） 排期更换掉PSU3硬件 图：锁定 PSU3、更换掉之后——四路电源全部恢复正常，电压/功耗/温度/转速一目了然\n长期根治：\nGPU服务器电源冗余配置要留足余量，别让PSU额定功率贴着峰值功耗跑 PSU状态必须上监控告警，不能等关机了才翻SEL——坏一块就应该报警 机房供电波动也要纳入告警范围（部分数据中心支持PDU级别的电压/电流监控） 驱动版本和内核版本对齐NVIDIA官方兼容矩阵，别用\u0026quot;能跑就行\u0026quot;的版本凑合 那一晚踩的四个坑\r#\r坑一：操作系统日志干干净净，差点误判\n系统日志里啥异常都没有——因为掉电是硬件层的事，OS层面的日志根本来不及写。真相只在BMC SEL里。\n教训：服务器\u0026quot;无故关机\u0026quot;，第一反应别查/var/log，先查带外。\n坑二：以为SSH能看现场，结果机器硬掉线\n人在被窝，唯一能戳到机器的就是BMC的KVM/SOL/远程Power Cycle。没配带外管理的机器，大半夜只能跑机房。\n坑三：SOL连上黑屏啥也没有\nSOL（Serial over LAN）能把服务器的串口重定向到你这端，BIOS、启动信息都能远程看。但连上黑屏，根因在被控端没配全：\n没开串口服务：sudo systemctl enable --now serial-getty@ttyS0.service（状态得是active (running)） GRUB没把启动输出导向ttyS0 控制端命令少了-I lanplus——SOL必须走lanplus通道，用默认lan连上就是黑屏 防火墙没放行UDP 623端口 四缺一就黑屏，查了一遍才发现是第三项。\n坑四：电源\u0026quot;冗余\u0026quot;被当成免死金牌\n一只PSU悄悄failure，系统靠其他几只硬撑，平时根本发现不了——直到负载一高剩下的也扛不住，才彻底宕机。\n冗余保的是\u0026quot;不瞬间死\u0026quot;，不保\u0026quot;你不用管\u0026quot;。PSU状态得上监控告警，别等关机了才翻SEL。\n结尾\r#\r这台8卡GPU节点的那一夜，是我对\u0026quot;带外管理\u0026quot;最刻骨铭心的一课：主机会死，但BMC记下了它怎么死的。 半夜把你叫醒的从来不是机器，是没配好的监控。\n下篇不聊故障了，换个话题——一台裸金属服务器，MAAS 死活不认 Rocky Linux。我不改 MAAS，从头 Packer 打包了一个镜像，硬塞进去。\n关注我，下期见。\n","date":"July 26, 2026","externalUrl":null,"permalink":"/posts/gpu-bmc-troubleshooting-3am/","section":"Posts","summary":"凌晨3点，集群一台8卡GPU节点硬掉线。SSH连不上、ping不通，但BMC还活着。翻SEL发现供电在抖，锁定了坏掉的PSU3，顺带挖出NVIDIA驱动和内核的兼容性雷。不卖工具，卖教训。","title":"凌晨3点的GPU服务器：一次BMC故障排查全记录","type":"posts"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]