简介：这份PDF文档为ODCC发布的《OTII-E模块化服务器技术规范V1.0》（编号ODCC-2023-01002），由中国移动、中国电信、英特尔等单位牵头编制，面向服务器设计、生产与运维工程师，尤其是关注5G与边缘计算场景的技术与管理人员。规范围绕深度定制、开放标准与技术统一的目标，系统给出机框规格与前后板布局、模块类型与尺寸、CPU/内存/存储/PCIe插卡/加速硬件等部件要求，以及电源风扇、环境适应性和硬件管理接口（HWI）等设计细则，并附有大量图表辅助理解布局与逻辑框图。资源包共1个PDF文件，约1.4MB，便于随查随用。目前已有304人学习。读者可借此掌握模块化服务器的标准化设计思路与接口约定，为边缘侧灵活配置、系统性能与可靠性提升及维护成本控制提供参考依据。
1. 模块化服务器：为什么"插槽"比"堆料"更难做
边缘计算这件事，最反直觉的一点是：算力从来不是瓶颈，部署形态才是。一个典型的边缘机房可能只有 600mm 深的机柜、没有空调、维护窗口只有几分钟，你塞一台标准 2U 服务器进去，深度超了、温度扛不住、硬盘还得绕到后面去拔。OTII-E 模块化服务器技术规范要解决的，就是这种"机房条件倒逼硬件形态"的问题——它把服务器拆成机框、模块、部件三层，用插槽式模块组合替代整机定制，让同一套机框能装下计算、存储、网络三类节点。
这份规范值得搞懂的地方不在于它定义了哪些尺寸，而在于它回答了一个工程难题：当硬件被切成可插拔的模块之后，管理、供电、散热、时钟这些原本"整机内部"的事情，怎么在模块之间重新分配职责。这背后涉及主从节点管理、RMC 方案、带外管理功能集、前维护布局等一系列设计取舍。下面从总体约束开始，一层层拆到管理接口的实现细节。
2. 总体约束：600mm 深度和 5℃~40℃ 是怎么倒逼架构的
2.1 物理约束先于电气约束
规范里最先定死的不是 CPU 型号，而是机框尺寸：宽度兼容 19 英寸和 21 英寸机架，高度 1U 或 2U，PSU 出线口与前面板距离 d≤450mm，整机深度 D≤470mm。这几个数字不是随便写的。标准机柜深度通常 600mm，前面要留 D1≥90mm 给前门框，后面要留 D2≥60mm 给 PSU 出线，中间留给服务器的净空间就被压到 470mm 以内。一旦深度被锁死，主板布局、PCIe 插卡方向、电源位置全部要重新排。
更关键的是"前维护"这条：开关、指示灯、硬盘、网线全部走前面板。传统服务器硬盘在 front、PCIe 在 rear，维护要两头跑；边缘机房往往只有单面操作空间，所以 OTII-E 把可维护部件全部前置。这直接导致后面板只剩风扇区和电源区两个区域，风扇支持故障备份、电源支持故障备份，布局被极度简化。
温度约束同样在倒逼设计：长期 5℃~40℃、短期 -5℃~45℃。这个范围比标准数据中心（通常 10℃~35℃）宽，意味着风扇调速策略、电源转换效率、器件选型都要按工业级余量来。规范里 CPU TDP 上限标注"基于风冷条件，液冷可支持更高 TDP"，就是在给散热方案留口子。
2.2 模块类型划分的逻辑
机框定完之后，模块类型表就是架构的核心。规范定义了三大类模块：
| 模块类型 | 模块名称 | 功能定位 |
|---|---|---|
| 1U 半宽 | CPU 模块 / SOC 模块 | 单路计算节点 |
| 2U 半宽 | CPU 模块 / SOC 模块 | 单路计算节点，更高 TDP |
| 1U 全宽 | 容量存储节点 / 网络资源模块 / 单路 CPU / 双路 CPU | 存储、交换、计算 |
半宽和全宽的划分不是尺寸游戏，而是前面板 Flex 区域的分配策略。1U 半宽模块推荐尺寸 180x370x41mm，两个半宽模块并排刚好填满一个全宽位；1U 全宽 360x370x41mm，独占整个前面板。这样厂家可以根据场景选：边缘 AI 推理要 GPU，就上 2U 半宽 CPU 模块（支持 2 张全高全长单宽卡或 1 张双宽卡）；纯转发场景要网口密度，就上网络资源模块（支持 switch 芯片）。
模块逻辑框图里能看出一个共同点：每个模块都是独立计算单元，有自己的 CPU、内存、存储、网络、BMC。模块之间不共享内存总线，只通过机框背板做供电和管理信号互联。这种"计算下沉到模块、机框只做物理承载"的思路，是模块化服务器和刀片服务器最大的区别——刀片通常共享电源和风扇但计算仍集中，OTII-E 把管理也下沉了。
2.3 部件规格里的取舍
以 1U 半宽 CPU 模块为例，规范给的规格很具体：支持 Intel 最新 Xeon-SP 处理器，最高 TDP 165W；8 通道内存，1DPC 配置下频率不低于 4800MHz，2DPC 时不低于 4400MHz；支持 2x2.5 SATA/SAS/NVMe；至少 6 个 10GbE 或 25GbE 网口加 1 个独立 1GbE 管理网口；1 张 PCIe 半高半长卡加 1 块 OCP 3.0 卡。
这里有个容易被忽略的细节：内存频率随 DPC 下降。1DPC（每通道 1 个 DIMM）能跑 4800MHz，2DPC 掉到 4400MHz，这是 DDR5 电气特性决定的——通道负载增加，信号完整性变差，必须降频保稳。规范把这个写进最低要求，意味着厂家不能拿 2DPC 跑 4800 当卖点，因为物理上做不到稳定。
2U 半宽 CPU 模块把 TDP 上限提到 205W，PCIe 插卡能力也增强到 2 张全高全长单宽或 1 张双宽。这个差异来自高度：2U 有 83mm 高度，能容纳全高卡；1U 只有 41mm，只能上半高卡。所以选型时如果业务需要 GPU 或 FPGA 加速卡，2U 半宽是唯一选择，1U 半宽只能做纯 CPU 计算或轻量加速。
SOC 模块则是另一条路线：Xeon-D 处理器，TDP 上限 130W，3 通道内存 2DPC，板载 4x25G 或 8x10G 网络。SOC 的特点是网络和计算集成度高，适合 NFV 场景——网络功能虚拟化需要大量小包转发，板载网口比 PCIe 插卡延迟更低、功耗更优。规范里 SOC 模块可选支持时钟和同步方案，涉及 1PPS、GNSS、PTP、TOD，这是给 5G RAN 场景准备的：基站需要精确时间同步，普通服务器没有这些接口。
3. 管理架构：主从节点和 RMC 方案怎么选
3.1 两种管理交互方案的动机
模块化服务器最麻烦的问题不是硬件，是管理。一台整机只有一个 BMC，管理简单；但 OTII-E 机框里可能插了 4 个半宽模块，每个模块都有自己的 BMC，谁来统一管理？
规范给了两个方案：主从节点方案和 RMC 方案。
主从节点方案的逻辑是：机框里指定一个模块作为主节点，其他模块作为从节点。主节点的 BMC 负责整个机框的管理，包括风扇、电源、资产管理；从节点的 BMC 只管理自己模块内部。主从之间通过机框背板的管理总线通信，主节点对外提供统一管理接口。
RMC 方案则是引入一个独立的管理控制器（Rack Management Controller），不占用计算模块。RMC 直接管理机框级部件（风扇、电源、传感器），同时通过管理总线代理各模块的 BMC。这样计算模块可以完全专注业务，管理功能不占用模块资源。
两种方案的取舍很清晰：主从方案成本低，不需要额外硬件，但主节点故障时整个机框管理可能受影响；RMC 方案可靠性高，管理功能独立，但增加了一个部件和成本。规范把两种都列出来，是给不同场景留选择空间——成本敏感的边缘节点用主从，可靠性要求高的核心边缘用 RMC。
3.2 带外管理功能集
带外管理是模块化服务器的"黑匣子"，规范列了 8 类功能：
资产管理：记录机框、模块、部件的序列号、厂商、型号、位置信息。模块插拔时自动更新资产列表，这是模块化服务器比整机复杂的地方——整机资产固定，模块化资产是动态的。
远程诊断（可选）：支持远程重启、远程 KVM、远程挂载 ISO。边缘机房通常无人值守，远程诊断是刚需，但规范标了"可选"，因为实现成本高。
部件信息管理：CPU、内存、硬盘、PCIe 卡、电源、风扇的详细信息，包括温度、功耗、健康状态。这里的关键是部件和模块的归属关系——一个风扇属于机框，一个硬盘属于某个模块，管理界面要能正确映射。
传感器监控：温度、电压、电流、风扇转速。模块化服务器的传感器分布在不同模块上，主节点或 RMC 要聚合所有传感器数据。
电源和风扇管理：电源冗余、热插拔、风扇调速。规范要求电源支持故障备份、风扇支持故障备份，管理功能要能检测故障并告警。
故障告警：健康状态指示灯（绿灯正常、黄灯一般告警、红灯严重告警）、日志、SNMP Trap。前面板指示灯规范里定义得很细：电源指示灯绿灯常亮表示已上电，黄灯常亮表示待上电，黄灯闪烁表示管理系统启动中。
日志管理：系统日志、操作日志、故障日志。模块化服务器的日志要区分机框级和模块级，排查问题时能定位到具体模块。
其他功能：固件升级、配置备份恢复、时间同步。
3.3 带内管理功能
带内管理走操作系统，通过 NC-SI 接口或板载管理网口。规范里提到支持 NC-SI 管理接口，这是 Network Controller Sideband Interface 的缩写，作用是让 BMC 通过网卡的边带通道收发管理流量，不需要额外管理网线。对于边缘机房，少一根线就是少一个故障点。
带内管理主要做 OS 层面的监控：CPU 利用率、内存占用、磁盘 IO、网络流量。这些数据通过 OS 内的 agent 采集，和带外管理数据互补。带外看硬件健康，带内看业务负载，两者结合才能完整判断节点状态。
4. 避坑：模块化服务器部署的 5 个常见问题
4.1 模块插拔后资产信息不更新
现象：更换了一个半宽模块，管理界面里还是旧模块的序列号，新模块的资产信息没出现。
原因：模块插拔检测依赖背板上的 presence 信号和 BMC 轮询。如果主节点 BMC 的轮询周期设置过长，或者背板信号线接触不良，就会漏检。另外，部分厂家的 BMC 固件在模块热插拔时不会主动触发资产刷新，需要手动刷新或重启管理服务。
解决：先确认背板 presence 信号是否正常（看 BMC 日志里有没有模块上下线事件）；如果信号正常但资产不更新，检查 BMC 固件的资产管理模块版本，必要时升级；临时方案是通过管理命令手动触发资产扫描。
4.2 风扇调速策略和模块温度不匹配
现象：某个模块 CPU 温度已经很高，但机框风扇转速没提上去，模块开始降频。
原因：机框风扇调速通常基于机框级温度传感器，而不是模块内部 CPU 温度。如果模块的散热设计依赖机框风扇，但机框风扇看不到模块内部温度，就会出现"模块热但风扇不转"的情况。规范里风扇调速要求没有强制规定传感器位置，不同厂家实现差异大。
解决：检查机框风扇调速曲线是否包含模块进风口温度；如果只基于机框温度，需要在模块 BMC 里设置温度告警阈值，通过管理总线通知机框 BMC 提转速；选型时优先选支持模块温度联动的机框。
4.3 主从节点切换导致管理中断
现象：主节点模块故障重启，整个机框的管理界面失联，从节点模块的业务虽然没断但无法管理。
原因：主从方案里主节点 BMC 是唯一管理出口，主节点故障时管理功能没有备份。规范没有强制要求主节点冗余，所以很多实现是单点。
解决：如果业务对管理连续性要求高，选 RMC 方案；如果已经用了主从方案，配置管理口冗余（比如主节点管理网口和从节点管理网口都接入管理交换机），主节点故障时手动切换管理 IP；长期方案是推动厂家支持主节点自动选举。
4.4 电源冗余配置和实际功耗不匹配
现象：配置了 1+1 冗余电源，但一个电源故障后系统直接下电。
原因：电源冗余的前提是单个电源能承载整机满载功耗。如果两个电源各 800W，整机满载 1000W，1+1 冗余下单个电源带不动，故障时就掉电。规范里电源要求写了冗余和热插拔，但没有强制规定电源功率和整机功耗的比例。
解决：计算整机满载功耗（CPU TDP + 内存 + 硬盘 + PCIe 卡 + 风扇），确保单个电源额定功率大于满载功耗的 1.2 倍；如果空间允许，选更高功率电源；管理界面里监控电源负载率，超过 60% 就要警惕。
4.5 时钟同步方案在 SOC 模块上不生效
现象：SOC 模块配置了 PTP 时钟同步，但时间精度达不到要求，或者 GNSS 信号丢失后没有 holdover。
原因：规范里时钟和同步是"可选，只涉及 SOC 模块"，意味着不是所有 SOC 模块都支持。如果模块硬件没有 1PPS 接口或 GNSS 模块，软件配置再对也没用。另外 PTP 对网络交换机的透明时钟支持有要求，普通交换机不保证精度。
解决：选型时确认 SOC 模块硬件支持 1PPS、TOD、GNSS；检查交换机是否支持 PTP 透明时钟；GNSS 天线要放在能收到信号的位置，边缘机房通常在地下室或封闭空间，GNSS 信号可能很差，需要外部天线引到室外。
5. 设计取舍：模块化到底牺牲了什么
模块化服务器的代价，规范里没有明说，但从技术约束能反推出来。
第一是密度。1U 半宽模块 180mm 宽，两个并排 360mm，加上机框结构件和背板，实际可用宽度比标准 1U 服务器少。标准 1U 服务器能放 10 个 2.5 寸硬盘，1U 半宽模块只能放 2 个。存储密度下降是模块化的必然代价，换来的是灵活性。
第二是散热效率。整机服务器风道是统一设计的，模块化服务器每个模块有自己的进风口和出风口，机框风扇要同时照顾多个模块，风道复杂度高。规范里 CPU TDP 上限标注"基于风冷条件"，暗示风冷下模块化服务器的散热能力比整机弱，液冷才能释放全部性能。
第三是管理复杂度。整机一个 BMC 搞定，模块化要处理主从或 RMC，管理软件复杂度上升。带外管理功能集里资产管理、部件信息管理、传感器监控都要处理"模块归属"问题，开发工作量比整机大。
第四是成本。模块化意味着每个模块都要有独立的 BMC、电源转换、时钟电路，物料成本比整机高。但边缘场景下，灵活配置带来的运维成本下降能抵消硬件成本上升——一个机框备几种模块，现场按需组合，比备几种整机库存压力小。
验证这套设计是否合理，最直接的方法是看故障域。整机服务器故障域是整个机箱，模块化服务器故障域是单个模块。一个模块挂了，其他模块继续跑，管理界面还能看到故障模块的状态。对于边缘计算场景，这种故障隔离能力比密度更重要——边缘机房无人值守，一次故障导致整机宕机，恢复时间可能是几小时；模块化下只损失部分算力，业务可以迁移到其他模块。
从那以后我每次评估模块化服务器方案，都会强制走一遍"故障域推演"：假设任意一个模块、任意一个电源、任意一个风扇故障，系统还剩多少可用算力，管理界面是否还能访问，业务能否自动迁移。这个推演比看规格表更能判断方案是否真的适合边缘场景。希望帮到你。
本文还有配套的精品资源，点击获取
