1 超节点与整机柜要理解什么
把服务器放进机柜，不等于建成了超节点。普通机柜可以只是摆放设备的架子，里面的服务器各有电源、风扇、网卡和操作系统，借助交换机通信。超节点通常强调把若干计算单元通过专用高速互连组织成较紧密的计算整体；整机柜则强调供电、冷却、布线、管理和交付以机柜为单位集成。两者可能同时出现，也可能分别存在。不同产品对超节点的边界定义不同，判断时要看实际连接和资源关系。
例如，1 台双路服务器装有 2 颗 CPU、16 条 DDR5 内存、4 块 NVMe 固态盘和 2 张 200 Gb/s 网卡。CPU 通过内存控制器访问本地内存，通过 PCIe 连接网卡、存储控制器或加速卡。把 8 台这样的服务器放进同柜，仍可能只是 8 台独立主机；若若干加速器通过专用互连组成紧密通信的计算域，又共享机柜级电源和液冷设施，就需要同时理解计算边界与设施边界。
本课采用贯穿示例：1 个 42U 机柜容纳 8 个计算托盘，每个托盘包含 2 颗 CPU、16 条内存、4 块 NVMe 盘和 4 个加速器，另有管理设备、供电部件和机柜内互连设备。具体高度和功率来自教学假设，不代表通用产品配置。CPU 负责主机侧控制和通用计算，内存保存运行中的数据，NVMe 盘保存本地文件，网卡负责连接柜外网络；加速器之间还可能存在独立的数据通路。
理解它首先要回答：哪些部件共同完成任务，哪些部件可以单独更换，哪些部件失效会同时影响多个计算托盘。1 个计算托盘可以对应 1 个操作系统实例，也可能采用其他组织方式，不能根据外壳数量推断系统数量。同样，专用互连能让设备更快交换数据，却不自动把全部 CPU 内存和加速器内存变成任意软件都能透明使用的共享空间。资源能否共同使用，还取决于硬件能力、驱动和程序设计。
机柜的价值，是把原本分散的供电、冷却和连接提前组织好，减少现场逐台装配的工作，并满足更高的功率密度。代价是各部分的依赖更紧：托盘的计算部件健康，也可能因公共冷却条件不足而降频或停机。学习超节点与整机柜，就是把观察尺度从“这台服务器有没有坏”，扩展到“哪些设备共同依赖了哪个部件”。
2 液冷、总线与故障域
先沿着热量走 1 遍。芯片工作时产生热量，冷板把热量传给液体，液体沿支路进入歧管，再经机柜与冷却设施之间的接口输送出去。冷却液分配单元常写作 CDU，它可以承担换热、循环、压力和温度控制等功能，具体职责取决于设计。部分 CDU 服务单柜，部分服务多柜，因此不能看到“每柜有液冷管”就认定冷却故障只影响单柜。
冷板液冷也不意味着取消所有风扇。内存、固态盘、网卡和供电器件仍可能需要空气带走热量。检查冷却条件时，要同时查看供液温度、回液温度、流量、压差、漏液告警和空气侧进风条件。仅有“水温正常”不能证明冷却正常：泵停止后，传感器附近的液体可能暂时温度不高，但芯片冷板内的有效流量已经不足。测量位置与采样时间必须随读数一起记录。
总线和互连则负责搬运数据。PCIe 连接主机与外设，专用加速器互连连接特定设备，Ethernet 等网络连接服务器或机柜。它们服务的范围与软件用法不同，不能只把带宽数字排成大小表。例如 PCIe 5.0 x16 的理论单向带宽约为 63 GB/s，实际有效吞吐还要扣除协议开销；200 Gb/s 网口对应的原始速率为 25 GB/s，也不能直接当成应用吞吐。链路是否共享、走几跳以及程序如何传输，同样影响结果。
故障域是可能被同一故障共同影响的设备范围。1 块 NVMe 盘失效，直接影响可能局限在本托盘；1 个公共配电部件失效，可能让多个托盘断电；1 条共享冷却回路失效，可能让整柜保护停机。这里要区分故障源与影响面：公共回路是故障源，8 个托盘同时停止是影响面，而不是证明 8 个托盘同时发生独立硬件损坏。
用功率还能初步检查冷却关系。假设整柜需要液体带走 80 kW 热量，冷却液暂按清水比热估算，供回液温差为 10 ℃，则所需质量流量约为 80000 ÷（4180 × 10），即 1.9 kg/s，约合 115 L/min。这只是理解热量守恒的估算；实际液体成分、压力损失、余量和设备规定都会改变设计。不能据此直接选泵，也不能把某次低负载流量当成满载保证。
3 整机交付与备件
整机交付的对象包括计算设备，也包括让设备按约定工作的连接、设施接口和配置资料。机柜抵达机房前，需要确认运输通道、门高、电梯载荷、地板承重、机柜定位和维护空间。静态总重量与搬运时局部轮载不是同一个条件，不能只看机房平均承重。机柜就位后，还要确认电源接口、供回液接口、网络光纤以及管理网络都有可追溯的标识。
到货验收应把“数量齐全”与“系统可工作”分别留下证据。先对照清单核对托盘、内存、固态盘、网卡、线缆和可更换部件，再核对序列号、槽位和固件版本。随后按交付程序完成供电检查、液路检查、管理连通检查和负载测试。机柜空闲时所有指示灯正常，并不能说明满载时没有供电限流、局部流量不足或互连误码问题。
本例的 8 个计算托盘应建立位置表，例如托盘 T01 对应哪些 CPU、内存槽位、NVMe 盘、网卡端口与液冷支路。这样 T03 上报内存错误时，维护人员才能准确找到部件；互连端口错误增多时，也能沿线缆编号定位连接两端。位置表还要标注共享部件服务范围，否则“更换右侧模块”这样的描述很容易造成误操作。
备件要围绕现场可更换单元安排。某些内存条、网卡或固态盘可以单独更换，某些冷板组件与计算板绑定，需要按较大的组件处理。用户能够拆到哪一级，应以维护手册、工具条件和人员资格为准。支持热插拔也只说明满足规定条件时可以带电操作，不意味着拔出部件不会影响业务；数据冗余、路径冗余和剩余容量仍需满足要求。
例如现场备有 1 个同型号计算托盘，可以缩短整托盘替换时间，却不能解决公共泵或控制部件故障。备有泵也不等于马上恢复，还需要隔离、排液或补液、排气和复验的时间。制定备件表时，应同时写上兼容型号、固件要求、存放条件、替换前置条件和恢复验证步骤。部件采购周期与维修耗时共同决定需要在现场保留哪些备件。
交付完成的标志应是一套可以重复执行的验收记录：在约定负载下，功率、温度、流量和互连状态达到要求；停用某条可冗余路径后，剩余路径能承受约定负载；告警能够到达值班人员。涉及供电和液路的切换测试需要按现场程序执行，不能在生产机柜上临时拔线验证猜想。设备清单、测试条件与操作记录需要共同移交。
4 动手：对照一次机柜级故障影响面
本节在纸面或电子表格中完成，不对运行设备实施断电、拔管或停泵。准备 8 行记录，分别代表 T01 至 T08，再添加共享供电组 P、冷却回路 L、互连设备 S 和管理设备 M。为了让依赖清楚，本例假设 8 个托盘都依赖 L，各托盘有独立操作系统，本地 NVMe 盘只直接服务所属托盘。互连设备 S 负责本例的跨托盘加速器通信。
先填写故障前基线：8 个托盘都在线，每个托盘记录最近 5 min 的功率、最高芯片温度、支路流量以及作业状态。时间窗口只是练习用值，真实监控间隔和保护阈值应遵循设备要求。还需记录数据来源：管理控制器提供硬件读数，操作系统提供设备状态，作业系统提供任务进展。不同来源的时间戳若没有对齐，就容易把后发生的告警误认为起因。
第 1 组事件是 T03 的 1 块 NVMe 盘失效。标记直接影响为 T03 的该存储设备，再检查它承载的内容。若只是可重新生成的临时数据，影响可能是本地任务失败并重算；若承载唯一的检查点，后果可能更大。其他托盘虽未失去硬件，也可能因为同一并行作业等待 T03 而空闲。因此表格中要分开记录“硬件不可用范围”和“作业受影响范围”。
第 2 组事件是 L 的循环流量持续下降。此时将全部托盘标成潜在受影响对象，再按时间补上观测：共享流量先异常，多托盘温度随后上升，功率因限频或保护开始下降，最终可能有托盘停机。这条顺序比“有 8 台机器掉线”更接近故障机制。若只有 T03 支路流量异常而其他支路正常，调查范围则应先落在该支路，不能直接宣布整柜回路损坏。
第 3 组事件是 S 的关键端口失去连接。托盘的 CPU、内存和本地盘可能仍然正常，但跨托盘任务无法继续。检查时同时记录链路状态、端口错误计数和作业等待情况，不要把“操作系统还能登录”当成整柜业务正常。链路重训练或错误恢复也可能造成间歇性停顿，静态截图未必能呈现，需要保留事件前后的时间序列。
完成练习后，为每组事件写出故障源、直接依赖、业务传播和恢复条件。若某项信息未知，就在表中写“待确认”，并指出需要查哪份拓扑或哪条读数。合格的影响面分析允许保留不确定性，但不能把未确认的备用能力写成已经生效的隔离能力。由此形成的依赖表，是现场排查和方案评审都能使用的共同语言。
5 集成度与替换粒度取舍
集成度提高，可以减少重复的机箱、电源和布线，把有限空间用于更多计算部件。较短且固定的连接，也便于在出厂时完成整体验证。但集成越紧，并不意味着每项指标都同时改善：维护空间可能变小，部件选择可能受限，某个连接器或冷板组件的更换可能需要取出整个托盘。评估时应把性能、密度、停机范围和维修条件同时摆出来。
替换粒度指现场维修时一次换掉多大的单元。若 1 张小板故障可以单独替换，备件成本可能较低，但拆装连接和复验耗时可能较长。若直接替换整托盘，现场操作可能更快，却需要更贵的备件，并让该托盘上的健康 CPU、内存和存储一起暂时退出服务。究竟哪种更好，取决于故障频率、恢复目标、库存和维护流程，不能只比较部件价格。
假设同样有 8 个计算托盘，方案 A 的每条可隔离冷却支路服务 1 个托盘，方案 B 的每条支路服务 4 个托盘。若支路能够独立隔离且其余支路仍满足运行条件，单支路故障的直接影响上限分别为 1 个和 4 个托盘。可是它们若仍共享同一套没有有效备用能力的循环泵，公共泵故障就可能影响全部 8 个托盘。增加支路数量本身没有消除公共依赖。
交互中只改变每条支路服务的托盘数，观察支路数量与单支路故障影响比例如何变化。它帮助理解隔离粒度，不提供真实可靠性预测。实际系统中，阀门能否隔离、隔离操作会不会扰动其他支路、剩余流量是否充足，都需要工程验证。将图上的分组直接当成实际故障域，会漏掉管路、控制器和供电的共同故障。
还要区分冗余数量与冗余能力。2 个电源模块可能只是共同承担满载需求，损失 1 个后必须降载；2 个泵也可能采用其他运行策略。只有明确正常负载、故障后的可用能力和切换条件，才能说明是否支持所需的持续运行目标。维修时若必须停掉整个公共设施，日常运行中的备用能力也未必能缩小维护窗口。
部署决策可以从可承受的损失倒推。若业务最多允许同时损失 1 个托盘，就不能仅凭单托盘可更换满足要求，还要检查冷却、供电和互连有没有更大的共同影响面。若系统允许整柜退出，则可以在其他机柜准备恢复容量与数据副本。集成度是设备组织方式，业务连续性则需要把设备边界与调度、存储和恢复策略连接起来。
6 常见坑：按单服务器习惯运维机柜
常见错误是看到某托盘温度高，就反复重启该托盘。若真正原因是公共流量不足，重启既不能恢复冷却，还可能使任务反复加载、延长故障时间。正确入口是先看是否有共同异常：同一时段有多少托盘升温，是否共享回路，供回液读数和泵状态如何。单设备告警需要与机柜层面的观测合并解释。
另一个错误是把双路接入直接记为无单点。例如 2 条电源线最终接到同一个上游配电点，或 2 个管理端口经过同一台交换设备，都仍可能被共同部件中断。检查应沿路径追到能够形成独立保障的层级，并确认故障后剩余容量。只数接口数量，无法判断冗余是否有效；只看设备内部，也无法发现机房设施中的共同依赖。
替换操作也容易沿用普通服务器的经验。液冷托盘退出前，可能需要完成业务迁移、停止相关设备、隔离支路、确认连接器状态等步骤，具体顺序必须遵循维护规程。带有快速接头不等于可以任意带载拆卸，接头状态、压力条件与残液处理都有要求。操作员还应核对托盘编号和支路标签，避免处理相邻的健康设备。
固件维护同样有机柜边界。CPU 主板、网卡、加速器、互连设备与管理控制器可能存在经过验证的版本组合，单独升级其中 1 类设备后，系统可能出现设备不可见、链路异常或管理读数变化。应按兼容矩阵和维护计划选择升级批次，保留升级前状态与恢复路径。升级是否支持在线执行，需要单独确认，不能从“固件更新成功”推导业务完全无影响。
还要避免把本地盘当成天然持久的数据位置。整托盘被更换时，本地 NVMe 盘可能随旧托盘退出；若恢复流程没有保存必要数据，即使新托盘很快上线，任务也无法接续。反过来，存储副本跨了托盘却没有跨机柜，也可能同时受公共冷却故障影响。数据布局应按实际故障域检查，不能只看副本数量。
最后是只监控主机在线率。整柜需要同时观察环境、设施、链路和业务：管理控制器在线但计算任务停滞，或者网口正常但专用互连中断，都可能被简单在线率掩盖。告警应保留原始读数、位置和时间，并支持把同源事件关联起来。关联的目标是帮助定位共同原因，不能把全部告警合并后丢失各托盘的细节。
7 案例：冷却回路故障影响整柜
设教学机柜在稳定负载下运行，8 个托盘共用回路 L。某次事件中，L 的实际循环流量下降，起因可能是泵、阀门、堵塞或控制问题，初始阶段尚未确认。值班人员先收到公共流量告警，随后多个托盘出现温度告警，部分设备降频，接着作业吞吐下降。这些现象说明需要优先检查共同冷却条件，但还不能单凭告警顺序认定具体损坏部件。
运维人员保留事件前后记录，核对传感器时间戳与读数可信度，查看回路和各支路的变化。若公共流量下降与多个支路变化相符，就比孤立的单传感器异常更有支持力。与此同时，按预定程序限制新增任务，并由系统或值班人员执行约定的降载、停机措施。若已经出现漏液告警，应进入相应处置程序，不能把继续运行当成获取更多证据的手段。
这里可能出现容易误判的现象：芯片功率降低后，温度暂时稳定，值班人员便认为回路恢复。实际上，温度稳定可能是设备主动减少发热的结果。判断恢复必须结合流量、压差、供回液温度和负载，不能只看温度曲线回落。保护停机是降低损坏风险的动作，也不意味着设备在长时间失冷时一定不会受损，后续仍要按规定检查。
在设施维护人员完成故障定位和处置后，恢复过程仍有明确门槛：确认液路状态满足要求，相关告警解除，连接处检查通过，再按规定顺序让设备回到服务。先让少量设备处于受控负载，观察流量分配、温度和功率是否稳定，再逐步增加负载。不能因为空载时温度低就一次恢复全部任务，也不能为了追赶进度跳过互连和设备枚举检查。
业务恢复还要处理被中断的作业。核对检查点是否完整、数据是否位于可用存储、任务是否支持重启，然后由作业系统重新分配资源。某些托盘恢复较晚，可能继续限制需要全部托盘参与的任务。因此记录中应分别标明设施恢复、硬件恢复和业务恢复时间；这能解释为什么“冷却已经正常”之后，实际产出仍未立刻回到原水平。
复盘时，把损失拆成故障发现、保护处置、维修、复验和作业恢复几个阶段。若大部分时间花在寻找支路标签，就改进标识和位置表；若维修已完成却缺少可用检查点，就改进数据与作业策略；若备用泵未能承担负载，就重新核对容量和切换条件。整柜故障的改进措施应对应证据，不能笼统归结为“加强巡检”。
8 把超节点约束写进机房方案
机房方案首先要把需求写成有边界的条件：计划放置多少柜，每柜的配置、典型运行功率与设计最大功率分别是多少，业务允许同时退出多少计算资源。设备标称功率、实际负载功率和设施规划值用途不同，应说明取值来源与余量原则。不能用当前测试任务的平均功率代替未来满配置运行所需的设施能力。
供电部分要说明机柜输入形式、上游配电路径、保护与计量位置，以及故障后的可用容量。冷却部分要说明液体类型、接口、允许的供液温度范围、流量与压差要求、空气侧剩余散热需求和设施责任边界。参数应来自设备与设施的匹配资料，由相关专业人员完成校核。这里的重点是提出完整问题，具体电气和水力设计不在本课展开。
空间部分除了机柜占地，还要包含前后维护距离、托盘抽出空间、搬运工具路线以及液路检修空间。网络部分要分别描述管理连接、业务网络和机柜内专用互连，注明设备位置、端口与线缆标识。即便采用整柜预布线，柜外供电、液路与网络仍需要现场对接，交付边界必须写清，避免双方都以为某个接口由对方负责。
运行方案需要列出公共部件及其影响面，例如某 CDU 服务哪些柜，某配电点覆盖哪些负载，某互连设备失效会阻断哪些任务。再为这些场景安排告警、降载、维修窗口和跨柜恢复能力。维护人员、设施人员与作业管理员需要看到同一份依赖关系，否则可能出现设施准备检修而作业仍向该柜分配资源的情况。
验收条件应当可测量、可重复。约定负载、测试持续时间、采样位置、允许范围和异常处理方法；对冗余切换与故障隔离，只按经批准的现场测试程序验证。交付证据应包含测量记录、版本与配置、位置表、维护规程和备件清单。若某项能力只能在特定负载下成立，就把这个条件写进验收结论，避免日后被当成无条件承诺。
9 从超节点与整机柜走向AI 集群网络（H47）
机柜内部集成完成后，任务还可能跨越多个机柜。此时，单柜算力再高，也需要柜间网络及时搬运参数、数据和结果。1 个任务若分布在多个托盘，较慢或不可达的参与者可能让其他设备等待；增加计算部件，不一定按比例缩短任务时间。观察性能时，需要把计算时间、数据传输和同步等待联系起来。
可以先建立 3 个尺度：芯片或板卡之间的连接、机柜内部的连接、机柜之间的连接。它们可能采用不同技术，也可能在某些系统中共享同类技术，边界应以实际拓扑为准。专用互连很快，不意味着柜外网络同样充足；网卡端口速率很高，也不意味着多柜同时通信时没有共享瓶颈。
下一课讨论 AI 集群网络时，将继续追问端口连接到哪里、哪些流量共享上行链路、某条链路或某台交换设备失效后还有没有可用路径。本课只需带走检查方法：沿数据路径看通信能力，沿供电与冷却路径看共同依赖，再把这些范围映射到任务。这样网络拓扑就能与真实托盘、机柜和故障恢复建立联系。
跨柜规划还要延续故障域意识。把作业检查点或备用资源放在另一个柜，只有在它们没有继续依赖同一个失效设施时，才可能实现预期隔离。网络路径增加后，监控和位置表也要跟着扩展。H47 会在这些明确的硬件边界上讨论网络组织与通信需求，而更深入的互连协议、拥塞控制和加速器内部实现留待后续学习。
放进方案里
某机房准备部署 2 个整机柜，每柜包含 8 个计算托盘，用于需要多托盘协作的计算任务。方案先列明每个托盘的 CPU、内存、NVMe 盘、网卡和加速器配置，再按设备资料填写整柜功率、重量、液路接口及空气侧散热要求。示例中的 80 kW 只能用于教学估算，正式设施容量采用经校核的设计值，并注明满载与故障降载条件。
供电图标出机柜输入到上游配电的完整路径，液路图标出 CDU、公共回路与可隔离支路，位置表把 T01 至 T08 对应到管理地址、端口和部件编号。方案特别检查 2 个机柜是否共享同一 CDU 或配电部件；若共享，就记录公共部件故障可能同时影响 2 柜，不能把跨柜部署直接算作完整隔离。
运维约定区分单托盘与公共设施事件：单块本地盘失效时，确认数据和作业影响后处理对应托盘；公共流量下降并伴随多托盘升温时，按规程限制任务、降载或停机，并由设施人员处置液路。替换托盘前，核对业务退出、液路隔离和部件兼容条件。现场备件覆盖已约定的可更换单元，同时列出公共部件的保障方式与到场时间。
验收在约定负载下记录功率、温度、流量、链路错误和作业完成情况，并按批准程序验证备用路径能力。任务恢复依赖可用检查点，检查点存放位置需避开拟防范的共同故障域。交付包包含拓扑、位置表、配置版本、维护步骤和测试记录，由设备、设施与作业负责人共同确认接口责任。最终方案要能回答：哪个部件失效会影响哪些任务，谁执行处置，以及满足什么条件才能恢复服务。
10 小结：下一步AI 集群网络（H47）
超节点强调计算单元之间的紧密连接，整机柜强调设备与设施的整体集成。认识真实系统时，要同时画出数据、供电和冷却路径，找出共同依赖，并区分硬件失效、保护动作与业务中断。维修粒度、备件和恢复流程，也必须与实际故障域对应。
学习后应能解释：为什么 8 个托盘掉线未必是 8 次独立故障；为什么 2 条供电线未必提供有效冗余；为什么温度下降未必代表冷却恢复。带着这些判断进入 H47，再看多个机柜怎样通过网络协作，以及连接方式如何影响计算任务的效率与恢复能力。