在大规模基础设施系统中,静默数据错误(Silent Data Corruptions, SDCs)是一个普遍存在的问题。这些被更大系统未能检测到的数据错误可能导致数据丢失,并在系统栈中传播,最终表现为应用程序级别的故障。
硬件中的SDC会影响大规模应用的计算完整性,其来源包括数据路径依赖性、温度变化和老化等因素。这类错误不会在系统日志中留下任何记录或痕迹,因此在工作负载内部保持未检测状态,并可能跨越多个服务层传播。本文探讨了在大型基础设施内检测和缓解SDC的测试策略。鉴于问题的复杂性,我们实验了不同的检测与缓解方法,并对比了两种主要途径:1) Fleetscanner(生产外测试),2) ripple(生产内测试)。通过3年以上的生产经验,我们评估了硅片测试流程相关的基础设施权衡。
在典型制造周期中,服务器或CPU会在供应商处接受几小时的测试,然后在集成商处进行几天的最佳情况下的测试,并采用抽样方式。然而,一旦组件投入生产环境,实现规模化测试就变得非常困难。因此,我们需要创新的检测方法来确保应用健康性和集群恢复能力,即通过检测并规模化地解决SDCs问题。
每次测试迭代都会占用生产负载的时间。生产外测试在从测试切换至生产负载时存在启动和关闭的过程。而生产内测试可能会遗留对负载性能产生不利影响的配置残留。当扩大到整个集群规模时,这种变异性以及所需的测试时间都变得至关重要。对于生产内测试而言,挑战在于如何以最小影响智能共置;而对于生产外测试,则是有效利用生产停机时间,同时不影响其他维护任务。
在Meta,我们实施了多种方法来检测SDCs,其中最有效的两种方法是机会主义和周期性测试,以及生产内/ripple测试。机会主义测试已在集群中运行约3年。在评估两种方法之间的权衡后,我们认为两者在检测SDCs方面同样重要,并推荐在大规模集群中同时使用和部署这两种方法。我们发现生产内测试可以在15天内检测出大约70%的集群数据损坏,而同样的损坏机会主义测试可能需要6个月才能发现。但是,最后30%的故障只能通过机会主义测试检测到,因此两种方法在故障检测方面同等重要。
我们的研究表明,静默错误可能在数据中心CPU执行的任何一组功能中发生,机器在生命周期的不同阶段都可能遇到SDCs。由于这些错误可能给基础设施带来潜在问题,我们在集群中运行一系列专有和供应商特定的测试来检测不良硬件。
我们采取两种关键的基础设施测试方法:
- 生产外测试(机会主义测试)
- 生产内测试(ripple测试)
机会主义测试:
在大规模基础设施环境中,机器通常会经历多次计划内或计划外的维护事件。我们依赖这些维护事件,在此基础上搭载并运行SDC测试。系统重启、内核升级、固件升级、设备重新映像、主机配置以及命名空间重新配置和修复等都是启用机会主义测试的维护示例。我们通过内部工具Fleetscanner实现这一机制,用于机会主义地测试SDCs。
机会主义测试允许测试具有更长的运行时间(数分钟级别),从而实现更为深入的检测。然而,机会主义测试的内在架构意味着在可疑机器或CPU的两次测试间隔之间可能发生损坏。我们测量了测试频率以评估该测试模式的有效性。目前观察到,通过上述所有机制,一台机器平均每180天经历一次机会主义测试。这个数字取决于集群规模和升级节奏,且根据机器类型有所不同。我们提供了细粒度控制,以便在敏感层级和服务上启用更频繁的机会主义测试节奏。
通过这种方式,我们在集群中成功进行了超过6800万次测试,总测试时间约为40亿秒。
Ripple测试:
尽管机会主义测试能够提供频繁的集群覆盖范围,但它不足以防止在测试窗口之间出现的生产故障,或者那些依赖于不同数据模式的故障,以及因不同操作模式间切换导致的故障。
Ripple测试通过与工作负载同步执行静默错误检测解决了上述所有问题。通过密切关注工作负载特性——基于服务预定节奏,伴随着工作负载进行影子测试并在集群中不时注入预期结果的位模式——我们可以以显著加快的速度实现全集群覆盖。我们提供了精细控制,以确定与工作负载共置执行测试的测试间隔、测试持续时间和设备配置。
由于这里的测试“涟漪”般穿过我们的基础设施,所以测试时间比机会主义测试运行时间低1000倍。Ripple测试通常在集群内为数百毫秒量级。它们基于工作负载行为进行调度,并可以按工作负载开启或关闭。鉴于缺陷的本质以及基于规模的ripple测试方法,通过独特的种子生成更多转换事件,我们能够检测到仅在数千次测试迭代后才会显现的远程故障。为了支持这种测试,我们在集群中管理了一种资源开销,但相较于更频繁的管理工作,这种开销可忽略不计。我们已将早期研究成果分享给CPU供应商,他们从我们的集群中学到了经验教训,并在其工具中实现了类似机制以取得相似效果。
通过此机制,我们每个月在集群中运行大约25亿个独特测试/测试种子。这一框架在过去几年内在集群中实时运行,并在与工作负载共置的情况下取得了近1亿秒的总测试时间。
结合机会主义和ripple测试的优点:
虽然在大规模基础设施中检测SDCs是一项挑战,但多年的测试表明,机会主义和ripple测试可以提供一种新颖解决方案,尽可能快速地规模化检测SDCs。
指标 | 机会主义测试 | Ripple测试 |
测试用例数 | ~6800万(累计总数) | ~25亿(每月数量) |
测试时间 | ~40亿集群秒(累计) | ~1亿集群秒(每月) |
性能感知 | 否 | 是 |
独特SDC覆盖率 | 23% | 7% |
达到相同SDC覆盖率所需时间 | ~6个月(70%) | ~15天(70%) |
上表展示了上述两部分所列数字的比较。对于本文归类的缺陷类型,约70%的常见覆盖率检测可在15天内完成。机会主义测试能够在6个月内追上剩余23%的独特故障CPU,而剩余7%则通过集群内的重复ripple实例检测出来。两种测试模型各有优势。我们还不断回顾和评估这些覆盖率指标,以指导和更新我们在集群范围内围绕测试向量、测试节奏和测试运行时间的测试策略。预计随着不同类型的缺陷,覆盖率分配可能会有所不同。
历史上,每个CPU在基础设施烧录测试中仅经历几个小时的测试。进一步的测试通常通过抽样方式进行。我们观察到,为了保障应用健康性和集群弹性,需要采用新的检测方法。我们展示了在大规模环境下进行测试的能力,每月都能持续完成数十亿秒的测试。这些创新技术使我们能够检测并规模化地缓解静默数据损坏问题。
检测静默数据损坏对大规模基础设施来说是一项艰巨的任务。应用程序对这类问题表现出高度敏感性,如果没有加速检测机制,可能会在数月内暴露在这些损坏之下。这不仅会导致数据丢失,还可能需要耗费数月时间来调试和解决由静默损坏导致的软件层面残余问题。这项研究展示了源于多年观察静默损坏现象及其发生模式的研究成果,以及更快的检测时间。静默数据损坏的影响可能会对应用程序产生连锁效应,我们必须将其视为一个关键问题加以解决。因此,我们需要尽快在大规模基础上检测这些问题。