无声却致命：没有什么比数据损坏更具破坏性了，这些数据损坏无法被硬件甚至软件中的各种错误捕获工具捕获，并且在感染整个应用程序之前很难发现。
这对 Facebook 规模来说尤其具有破坏性，但这家社交巨头的工程团队已经找到了防止本地问题蔓延到全球的策略。对于 Facebook 而言，单个硬件根源的错误在超大规模上倍增时可能会演变成一个巨大的问题，要避免这种情况需要结合硬件弹性、生产检测机制和更广泛的容错软件架构。
Facebook 的基础设施团队于 2018 年开始努力了解静默数据损坏的根源和修复方法，以了解整个舰队范围内的修复可能会是什么样子，以及这些检测策略可能会花费多少开销。
工程师发现，许多级联错误是生产中的 CPU 造成的，但并不总是由于辐射或合成故障注入的“软错误”造成的。相反，他们发现这些可以以可重复的方式在 CPU 上随机发生。尽管 ECC 很有用，但这主要针对 SRAM 中的问题，但其他元素也很容易受到影响。报告这些问题的 Facebook 工程团队发现，由于其他块中缺乏纠错，CPU 静默数据损坏实际上比软错误高出几个数量级。
CPU 复杂性的增加为更多错误打开了大门，当在超大规模数据中心级别与更密集的节点混合时，这些大规模问题只会变得更加成问题和更广泛。在硬件层面，问题可能包括一般的设备错误（布局和布线问题可能导致信号到达时间不同，例如导致位翻转），也可能会发生更多以制造为中心的问题，例如蚀刻错误。此外，设备的早期故障和现有 CPU 的退化也会产生难以察觉的影响。
例如，当您执行 2×3 时，在某些微架构条件下，CPU 可能会默默给出结果 5，而不是 6，而系统事件或错误日志中没有任何错误计算的指示。因此，使用 CPU 的服务可能不知道计算精度，并不断消耗应用程序中的错误值。
Facebook 基础设施团队成员解释道： “静默数据损坏是大规模运行的数据中心应用程序中真实存在的现象。了解这些损坏有助于我们深入了解硅片设备的特性；通过复杂的指令流及其与编译器和软件架构的交互。存在多种检测和缓解策略，每种策略都会给大规模数据中心基础设施带来额外的成本和复杂性。”
Facebook 使用了一些参考应用程序示例来强调大规模静默数据损坏的影响，其中包括一个 Spark 工作流程示例，该工作流程每天运行数百万次字数计算以及 FB 的压缩应用程序，该应用程序每天运行数百万次压缩/解压缩计算。在压缩示例中，Facebook 观察到算法为单个文件返回“0”大小值（应该是非零数字），因此该文件没有写入解压缩的输出数据库中。 “结果，数据库丢失了文件。丢失的文件随后传播到应用程序。保存压缩文件的键值存储映射列表的应用程序会立即观察到压缩的文件不再可恢复。依赖链导致应用程序失败。”很快，查询基础设施就会报告关键数据丢失。从这个例子中问题就很明显了，想象一下它是否比压缩或字数统计更大——Facebook 可以。
数据损坏在整个堆栈中传播并表现为应用程序级别问题。这些类型的错误可能会导致数据丢失，并且可能需要数月的调试工程时间……随着硅密度和技术规模的增加，我们认为学术研究人员和行业应该投资于解决这些问题的方法。
调试是一项艰巨的工作，但它仍然是 Facebook 处理这些无声数据损坏的核心，尽管直到它们的声音大到足以被听到为止。 “为了调试无声错误，如果不了解执行了哪些机器级指令，我们就无法继续进行。我们要么需要一个针对 Java 和 Scala 的提前编译器，要么需要一个探测器，它在执行 JIT 代码时提供所执行指令的列表。” 5.2 中详细介绍了静默错误调试的最佳实践。
一整套容错机制也是 Facebook 战略的关键。其中包括软件级别的冗余，但当然，这会带来成本。 “裁员成本对资源有直接影响；架构越冗余，重复的资源池需求就越大”，尽管这是实现概率容错的最确定路径。处理容错的开销较少的方法还包括依赖容错库（特别引用了 PyTorch），尽管这也不是“免费”的，但对应用程序性能的影响是显而易见的。
“这项工作需要硬件无声错误研究社区和软件库社区之间的密切配合。”
就这次握手而言，Facebook 公开呼吁数据中心设备制造商了解他们最大的客户期望更多，特别是考虑到硬件衍生错误所带来的级联广网影响。
“静默数据损坏并不局限于大型基础设施中百万分之一的罕见情况。这些错误是系统性的，不像机器检查异常等其他故障模式那样容易理解。”基础设施团队补充说，有几项研究评估了降低处理器内软错误率的技术，这些经验可以应用到类似、可重复的 SDC 中，这些 SDC 可能会以更高的频率发生。
Facebook 表示，设备制造商应承担很大一部分责任。这些方法是在制造商方面，可以包括使用自定义 ECC 增强设备上的块以实现更好的数据路径保护、提供更好的随机测试、了解增加的密度意味着更高的错误传播，最重要的是，通过“理解”大规模行为”与大规模使用设备的客户密切合作，以了解无声错误的影响。”这包括发生率、生产中的故障时间、频率依赖性以及影响这些错误的环境问题。
“Facebook 基础设施在过去 18 个月内实施了上述硬件检测和软件容错技术的多种变体。对上述每种方法的收益和成本进行量化有助于确保基础设施对于 Facebook 系列应用程序来说是可靠的。”基础设施团队计划发布后续版本，详细介绍当前方法的各种权衡和成本。
本站全部资讯来源于实验室原创、合作机构投稿及网友汇集投稿，仅代表个人观点，不作为任何依据，转载联系作者并注明出处：https://www.lvsky.net/75.html
评论