Scale-Up光链路可靠性设计：从物理层到协议层的工程实践

聊Scale-Up网络的时候，大家很容易被“端口速率多高、时延多低”这种指标带走。但我见过太多开局就翻车的情况：集群刚跑起分布式训练或高性能计算，某个端口的FEC计数呼呼上涨，接着就是链路反复重训练，最后整个作业超时。排查到最后，往往不是算法也不是代码的问题，而是Scale-Up协议域里一根光纤端面污染、一个光模块的DSP收敛异常，把整组计算单元拖下了水。

Scale-Up协议不像普通数据中心那样有大量冗余路径可以绕行，它的每一条光链路都承载着确定的带宽和确定的时延预算。光链路的可靠性设计，本质上是把“偶然错误”从协议层能容忍的范围内彻底压出去，让上层协议看不到意外。这篇文章我想从物理光层、编码纠错、协议协同、可观测性和运维落地几个层面，把我在Scale-Up光链路可靠性设计上攒下来的经验拆开来讲，适合正在做高性能计算、AI集群或分布式存储网络的工程师参考。

1. 先把“Scale-Up光链路”这个对象定义清楚

1.1 Scale-Up协议到底在解决什么问题

Scale-Up，直译是“纵向扩展”。在很多高性能场景里，Scale-Up互连是把若干台高性能节点连成一个逻辑上的“大节点”，多个大节点再通过Scale-Out网络组成更大的资源池。

Scale-Up协议的典型特征是：端口速率极高，时延预算极紧，端到端链路数量相对有数，但每一条的位置都不可替代。举例来说，在一个中等规模的训练集群中，单个设备的互连带宽可能已经达到400G甚至800G，而协议设计目标是端到端时延稳定在某个固定级别。这种场景下，链路的可靠性不是“能通就行”，而是要保证极端压力下不出现感知层面的抖动。

1.2 光链路进入Scale-Up域后带来的新变量

过去很长一段时间，Scale-Up域内使用铜质线缆甚至背板走线，因为距离近、设计好控制。但问题也很明显：线缆数量多、重量大、屏蔽要求高、跨机柜布线困难，速率提升后信号的完整性压力成倍增长。

光进铜退是大趋势。光链路的好处是把信号从电域搬到光域，损耗更低、线缆更轻、可以实现跨机柜的灵活布局。但代价也很直接：电光转换模块把信号完整性问题的复杂度从PCB延伸到了光纤、连接器和光学器件。以前链路不稳定的原因可能在背板走线，现在变成了光模块端的激光器、调制器、探测器，甚至是几根光纤跳线之间几个dB的损耗变化。

1.3 可靠性的“评估标尺”变了

Scale-Up场景下，最关键的指标是时延，而不是单纯看吞吐率。吞吐率可以靠并发补偿，时延抖动则会直接暴露在分布式协议的关键路径上。

当一条光链路上出现偶然误码时，如果协议选择重传，那么每一次重传都会引入几微秒级别的额外时延。单看几次重传似乎无害，但在大规模集合通信中，所有节点都在等最慢的那一跳。某个端口的误码率稍微偏高，就可能让整个集群的每次同步都慢一大截，宏观表现是“整体性能下降”，肉眼很难定位到某一根光链路。

所以在Scale-Up域里，可靠性设计的目标不是简单满足某个误码率指标，而是让每条链路在运行周期内都保持“可预测的干净”。这需要从物理层到协议层做整体的协同设计。

2. 物理与光层：可靠性设计的第一道防线

2.1 链路预算：不要只看发射功率和接收灵敏度

光链路的可靠性，首先取决于链路预算有没有留够余量。很多人拿到光模块规格书，只看两个数据：发射光功率和接收灵敏度，觉得只要发射大于接收就行，这是不对的。

真正有效的计算要加上链路当中所有损耗项。一个常见的估算方式是这样的：

链路余量 ≈ 模块最低发射光功率 - 接收灵敏度 - 连接器损耗 - 光纤损耗 - 链路功率代价

举个例子，某个模块发射光功率最低值为-2dBm，接收灵敏度为-8dBm，中间经过两根跳线和一对适配器，连接器损耗合计约1dB，光纤本身损耗约0.5dB，再考虑一些功率代价约0.5dB，那么链路余量大约是4dB。

这个余量看着还可以。但要注意，模块的发射功率和灵敏度参数会随温度漂移，激光器老化后功率也会下降。如果设计时把余量卡在1到2dB，到了夏天或者设备运行几个月后，误码率就会悄悄恶化。我的习惯是在设计阶段至少留出3dB以上的余量，并把这个数值写入验收用例。

2.2 端面污染是最浪费时间、最隐蔽的坑

在Scale-Up光链路排障中，我遇到最多的问题不是光模块坏了，而是光纤端面污染。

端面污染为什么隐蔽？因为一根光纤连接器的端面只有几十微米到一百多微米的核心区，污染可能是一层油膜，也可能是细小的灰尘颗粒。用肉眼观察完全正常，插上模块后链路也能通，但光功率已经悄悄掉了几个dB，误码率处在“颜色正确但有时候漂移”的状态。

处理端面污染，没有偷懒的余地。任何一根光纤在插拔之前，必须使用光纤端面检测仪进行检查。我见过太多所谓“脏了就擦一下”的现场操作，棉签擦过的端面往往带来更严重的划伤和残留。检测和清洁应该按照规范流程做，而不是凭手感。这个流程看起来繁琐，但它能解释掉现场一半以上的光链路“玄学问题”。

2.3 多模与单模、波长与色散的组合选择

Scale-Up域内短距离链路有时会考虑多模光纤，用VCSEL激光器，成本低、功耗小。但是PAM4信号对模式色散非常敏感，多模光纤在高速率下的模式色散会产生严重的价差损伤。如果链路长度稍微拉长，或者弯曲半径控制不好，误码率就会直接抬头。

单模链路相对更稳，硅光调制器配合外置激光器，波长稳定性和色散容忍度更好。跨机柜、综合布线、未来速率升级，单模往往是更安全的选择。

但单模也不是万能。PAM4下，色散和偏振模色散带来的损伤依然存在，只是可从电域DSP补偿的空间更大。选型时要把光纤类型和使用长度并列考虑。如果一条链路既有多模部分又有多模转换，整个系统的可靠性预算会变得很难算，设计和运维的复杂度上升得很快。

2.4 DSP与均衡：可插拔模块内部的“隐性作用”

现在的高速光模块内部普遍集成了DSP芯片，承担补偿、均衡、判决、CDR等工作。DSP的作用非常关键：它能把物理层的光信号损伤尽量在模块内消化掉，让协议层感知到的误码率尽量低。

但这不代表可以完全放任物理层。DSP的均衡能力是有限的，它依赖训练序列来收敛抽头系数。如果光纤损耗偏大、反射偏高、光功率不足，DSP的收敛结果会非常敏感。一旦工作条件发生波动，比如温度升高或连接器微动，DSP就会触发重新训练，链路出现短暂的中断。

所以在讨论可靠性时，不要把DSP当成万能药。DSP的调试参数确实能掩饰一些光层问题，但正确做法是让光层的工作环境本身足够干净，DSP只做细调，而不是替物理层背锅。

3. 编码与均衡：FEC和链路训练机制怎么兜底

3.1 FEC的关键参数：纠错能力和开销

光链路可靠性的第二道防线是前向纠错编码。当前高速链路广泛使用KP4模式的RS(544,514)编码，它以10比特为一个符号，每544个符号中包含514个有效载荷符号，可对最多15个符号的错误进行纠正。

纠错能力直接决定链路的“容忍度”。在没有FEC的情况下，光链路要达到极低的误码率，对光器件的余量要求会非常苛刻；开了FEC之后，物理层不必做到完美无缺，有一部分随机误码可以在链路层被纠正。

但FEC的运行有一个重要特征：它存在“悬崖效应”。当输入误码率超过纠错上限时，输出端会出现大量不可纠错误。这时链路不会马上断，但协议层会感知到大量错误帧，性能断崖式下跌。因此，监控FEC的纠错前误码率和纠错后误码率同样重要，只看最终结果往往会错过早期预警。

3.2 为什么Scale-Up域里不能总靠重传兜底

普通以太网络中出现少量丢包，可以由上层协议重传，TCP的拥塞控制甚至能应对一定的随机丢包。但Scale-Up协议完全不同，它的时延预算不允许频繁重传。

协议设计上通常要求端到端的帧交付出错率极低，希望在极端情况之外，链路看起来几乎是“零错误”的。这意味着光链路的可靠性目标不是“能纠错就好”，而是让FEC纠错成为常态机制，真正不可纠正的码字极少出现。

如果把重传当成兜底手段，一次重传带来的时延代价在Scale-Up场景里会被放大。所以真正可靠的设计，是把所有能扛误码的机制前置到物理层和链路层，协议层只做罕见情况的最后处理。

3.3 链路训练和重训练：可靠性的“折点”

PAM4链路的启动过程需要训练，双方通过一连串的训练序列协调发送端的预加重和接收端的均衡参数。正常情况下一旦收敛，链路进入业务状态。

麻烦的是“重训练”。当信号质量恶化到一定程度，DSP会重新开始训练，这一过程可能导致链路在几百毫秒甚至更长的时间里无法承载业务。对大规模同步训练类负载来说，一次重训练可能直接造成整个作业的暂停。

更麻烦的是，如果链路处于“勉强能通但不稳定”的状态，训练会反复触发，表现为链路状态一直正常，但业务间歇性卡死。这种问题很难在常规联通性测试里被捕捉到，只能依赖重训练计数这样的底层统计指标。

从可靠性设计角度，最好的策略不是等重训练触发，而是让链路始终工作在信号余量充足的区域，并通过监控提前发现劣化趋势，在重训练发生之前完成维护动作。

4. 协议层的故障感知与恢复：别只看“通不通”

4.1 错误检测与错误处理的边界

Scale-Up协议通常会对数据做校验，以确认端到端传输没有损坏。在光链路偶尔出现无法通过FEC纠正的码字时，协议层必须有能力识别坏包并采取动作，可能是丢弃重传，也可能直接触发链路重训。

设计时要想清楚一个问题：协议层把多少错误视为“正常现象”？如果在核心路径上设计了对随机错误的严格惩罚机制，那任何光层的微小抖动都会被放大。比较稳妥的做法是区分瞬时错误和持续性错误，瞬时错误尽可能在链路层消化，持续性错误则需要快速切换或告警。

4.2 快速故障切换与优雅降级

Scale-Up域中虽然链路冗余度不如Scale-Out网络，但也不是完全没有弹性设计。比如一对并行链路的场景，某一条中断后，另一条还能承载部分流量，但带宽会下降。

好的可靠性设计会把这种降级纳入规划，而不是让上层协议在链路中断后完全不知所措。带宽减半确实会影响性能，但总比整条通信路径完全不可用要好。设计上应当保证从故障发生到路径切换完成的时延足够短，让上层感知到的是“带宽下降”，而不是“链路消失”。

4.3 避免死锁和暂停风暴

具备无损语义的Scale-Up协议会使用流控机制。当接收端无法及时处理数据时，会发送暂停或反压信号。光链路如果发生间歇性误码，可能瞬间触发协议重传，进而造成缓冲区堆积，最终引发全局反压。

这就像城市交通的一个路口突然堵住，很快会蔓延到整条主干道。所以在光链路可靠性设计中，必须让误码率低到几乎不可能触发协议暂停的程度。任何“偶尔可以容忍”的设计思路在Scale-Up域内都会变成隐患。

5. 可观测性：让光链路问题“提前现身”

5.1 DOM/DDM能告诉我们什么

光模块内部普遍具备数字诊断监控能力，可以读取模块温度、电压、发射光功率、接收光功率等信息。这些参数的实时变化极具价值。

比如接收光功率的缓慢下降，可能预示着光纤连接器污染加重，或者发射端激光器老化。温度异常升高，会导致DSP的错误率抬高，甚至引发频繁重训练。电压波动也需要关注，很多模块间歇性故障都和供电品质有关。

我建议把DOM数据纳入监控采集系统，而不是只在故障时登录设备看一眼。没有历史数据，所有诊断都只能是猜测；有了长期曲线，很多故障可以在发生之前被预判。

5.2 FEC计数是比误码率更直观的指标

普通用户看光链路质量，习惯看误码率。但误码率的采样在高速链路上往往只是一段很短窗口的统计，观察时间不够长就会漏掉间歇性问题。

FEC计数则完全不同。它反映的是链路上持续出现的纠错情况。可以重点关注三类计数：纠正的FEC码字数量、不可纠正的码字数量、链路重训练次数。纠正数量持续增长说明链路存在稳定损伤源；不可纠正数量从零跳变，说明链路已经逼近能力边界；重训练次数出现非零值，则意味着物理层劣化已经比较严重。

下表是我在实际运维中比较关注的联动指标：

5.3 主动维护的节奏

有了监控数据，可靠性设计就进入了“主动维护”阶段。比如规定每季度对所有Scale-Up光链路的端面做一次检查和清洁，对FEC计数偏离基线的链路进行替换。

在实际项目里，我习惯给每条链路建立“健康基线”。新部署完成并稳定运行一定时间后，记录光功率、纠错计数、温度等数据。后续一旦某条链路的这些数据偏离基线明显，就把它列为观察对象。这种做法能把大多数故障掐灭在业务影响发生之前。

6. 从设计到落地：部署验收和运维中的几条关键经验

6.1 试运行验收不能只看连通性

新部署的Scale-Up光链路，最忌讳只做连通性测试就上线。我常用的验收有三步：

第一，跑满负载压测，让每个端口承受接近极限的持续流量。第二，检查FEC统计。如果纠错计数在压测过程中持续上涨，说明链路余量不足。第三，观察重训练计数。任何一次重训练都需要查明原因，绝不能把“过一会儿自己会好”当作没事。

这样的验收流程能在上线早期暴露大部分潜在故障，远比让故障出现在正式业务中划算。

6.2 常见排障顺序：一测端面、二查功率、三看FEC

光链路故障排查如果能按固定顺序走，会节省大量时间。

这个顺序其实是从“成本最低、最容易排除”到“成本较高、较难排除”排列的。

第一步看端面，很多时候是连接器脏了或者适配器没有对齐。第二步看DOM参数中的收发功率和温度，判断是否存在明显的物理层异常。第三步看FEC计数，区分是误码率升高还是不可纠正码字增加。第四步才考虑直接更换模块或者线缆。通过换件法定位问题，速度很快，但要在更换前保留好原始数据，否则排障现场很容易“换完看不出旧件问题在哪里”。

有一点要提醒：千万不要在链路还能正常通信时，因为某个计数器增长就反复插拔光模块。频繁插拔会加速连接器和模块的磨损，还可能引入新的污染。

6.3 运维现场不能省的成本

可靠性设计有时不是技术问题，而是管理问题。光模块、跳线这些看起来“小而便宜”的部件，现场往往备件不足，结果一坏就要等很长的周期。在Scale-Up域里，推荐对关键型号的模块和线缆做少量备件储备，并对备件本身也做同样的检测和验证，避免“拿备件换上去还是有故障”的尴尬。

线缆布局也值得多花时间。光纤的弯曲半径是硬指标，安装时捆扎过紧、折角过小，会让损耗和反射悄悄恶化。给光纤留出自然的走线空间，并且做好清晰的标签，能在后续维护里节省大量时间。从热设计角度看，光模块对温度很敏感，尽量让风流方向顺畅，不要将模块封闭在某个高温死角里，这比指望DSP去补偿更可靠。

6.4 我的最后一点个人体会

做了这么久Scale-Up网络的可靠性和运维，我最大的体会是：光链路可靠性不是某一个模块或某一段代码能解决的，它是一套从设计预算、编码选型、协议协同到日常巡检的体系。

你可以在协议层配置很多保险机制，但如果光模块本身的链路预算剩余不足，所有上层手段都是事倍功半。反过来，如果光层做得够干净，上层协议会非常省心——因为协议层最怕的恰恰就是那种“时好时坏、若隐若现”的物理层模糊故障。

所以，建议所有负责Scale-Up集群的工程师，从第一天就把每条光链路的基础记录建立起来，把端口、模块、线缆、端面检测结果、初始FEC计数全部归档。这个动作很简单，但是等某天集群性能突然下降时，它会让你在几分钟内锁定病因，而不是在无数条链路里大海捞针。