Facebook处理PCIe故障，以保持我们的数据中心可靠地运行

外围组件互连Express（PCIe）硬件继续推动计算的边界，因为转移速度的进步，可在线数据传递的可用通道的数量以及主板上的相对小的占地面积。如今，基于PCIe连接的硬件可提供更快的数据传输，并且是将组件连接到服务器的事实上的方法之一。

我们的数据中心包含数百万基于PCIe的硬件组件 - 包括用于视频和推理的ASIC的加速器，GPU，NIC和SSDS - 直接连接到服务器主板上的PCI插槽或通过PCIe开关如运营商卡连接。

与任何硬件一样，基于PCIe的组件易于不同类型的硬件，固件或软件相关的失败和性能下降。各种组件和供应商，故障阵列以及规模的挑战使监控，收集数据和对基于PCIe的组件进行挑战的故障隔离。

我们开发了一种检测，诊断，修复和修复这些问题的解决方案。由于我们已经实施了它，这种方法有助于使我们的硬件船队更加可靠，有弹性和性能。我们认为更广泛的行业可以从相同的信息，策略，帮助构建围绕这种常见问题的行业标准中受益。

PCICrawler：一个开源，基于Python的命令行界面工具，可用于显示，过滤和导出有关PCI或PCIe总线和设备的信息，包括PCI拓扑和PCIe高级错误报告（AER）错误。此工具可在视觉上吸引人的幻影，以便于调试以及机器可解释的JSON输出，可以通过刻度进行部署的工具消耗。

Machinecher：一个内部工具，用于快速评估服务器的生产价值从硬件角度。 MachinechEcker有助于检测和诊断硬件问题。它可以作为命令行输入工具运行。它也生活为图书馆和服务。

用于采用目标主机的硬件配置的快照以及硬件建模的内部工具。

内部公用事业服务用于解析自定义DMESG和SEL，以检测数百万服务器上的PCIe错误。此工具以规则的间隔解析服务器上的日志，并记录相应服务器上文件上的可纠正错误的速率。该速率每10分钟记录每30分钟，每小时，每六小时和每天。根据平台和服务，此速率用于确定哪些服务器已超出配置的可容许PCIe校正的错误率阈值。

IPMI工具：用于管理和配置支持智能平台管理界面（IPMI）的设备的开源实用程序。 IPMI是用于监视，记录，恢复，清单和控制的开放标准，该硬件独立于主CPU，BIOS和OS实现。它主要用于手动提取系统事件日志（SEL）进行检查，调试和研究。

OpenBMC项目：具有基板管理控制器（BMC）的嵌入式设备的Linux发行版。

Facebook自动修复（FBAR）：一个系统和一组守护进程，用于响应单个服务器上的检测到的软件和硬件信号而自动执行代码。每天，如果没有人为干预，FBAR会使服务器出错，并向我们的数据中心团队发送物理硬件维修，使孤立的失败成为非发票的要求。

Scuba：在Facebook上建造的快速，可扩展，分布式的内存内存数据库。我们为大多数实时分析使用的数据管理系统。

PCIe硬件组件（ASIC，NIC，SSD等）的纯粹品种使得研究PCIe发出令人生畏的任务。这些组件可以具有不同的供应商，固件版本和在它们上运行的不同应用程序。在此之上，应用程序本身可能具有不同的计算和存储需求，使用简档和公差。

通过利用上面列出的工具，我们一直在进行研究以改善这些挑战，并确定PCIe硬件故障和性能下降的根本原因。

一些问题是显而易见的。例如，PCIe致命未经校正的错误肯定是糟糕的，即使特定服务器上只有一个实例。 Machinechecker可以检测到这一点并标记故障的硬件（最终导致它被替换）。

根据错误条件，无法纠正的错误进一步分为非速度错误和致命错误。非行动错误是导致特定事务不可靠的错误，但PCIe链接本身是完全正常的。另一方面，致命错误导致链接不可靠。根据我们的经验，我们发现，对于任何未校正的PCIe错误，交换硬件组件（有时主板）是最有效的动作。

其他问题起初似乎无害。例如，PCIe校正的错误是根据定义可纠正的，在实践中主要纠正。应该对界面的功能没有影响，因此应该对纠正错误构成。但是，纠正错误发生的速率。如果速率超出特定阈值，则它导致某些应用程序不可接受的性能下降。

我们进行了深入的研究，将性能下降和系统摊位与PCIe校正误差率相关联。确定阈值是另一个挑战，因为不同的平台和不同的应用具有不同的简档和需求。我们推出了PCIe错误日志记录服务，观察了潜水表中的故障，以及相关事件，系统摊位和PCIe故障以确定每个平台的阈值。我们发现，当PCIE校正的误差率跨越特定阈值时，交换硬件是最有效的解决方案。

PCIe定义了两个错误报告范式：基线能力和AER功能。所有PCIe组件都需要基线功能，并提供最小定义的错误报告要求集。该AER能力用PCIe AER扩展能力结构实现，并提供更强大的错误报告。 PCIe AER驱动程序提供基础设施，以支持PCIe AER功能，并利用PCICrawler利用此功能。

我们建议每个供应商采用PCIe AER功能和PCICrawler，而不是依靠自定义供应商工具，这些工具缺乏一般性。自定义工具很难解析，甚至更难维护。此外，集成了新的供应商，新内核版本或新类型的硬件需要很多时间和精力。

糟糕（谈判）链接速度（通常以预期速度的1/2或1/4运行）和坏（谈判）链路宽度（以1/2，1/4甚至1/8运行）预期的链路宽度）是其他关于PCIe故障的其他。由于硬件正在运行，因此在没有某种自动化工具的情况下，这些故障可能很难检测到，因为硬件正在工作，就像它一样。

根据我们的研究，我们发现大多数这些故障都可以通过重新安装硬件组件来纠正。这就是为什么我们在将硬件标记为错误之前先尝试第一次。

由于重启可以修复这些故障的少数少数，我们还记录了历史修复行动。我们有特别的规则来识别重复罪犯。例如，如果同一服务器上的相同硬件组件以预定时间间隔在预定义的重置次数之后，我们将自动将其标记为错误并将其交换出来。在组件交换无法修复的情况下，我们必须诉诸主板交换。

我们还致力于修复趋势，以识别非正式失败率。例如，在一个情况下，通过使用来自自定义水肺表及其说明性图表和时间表的数据，我们根本导致从特定供应商的特定固件发布的下调问题。然后，我们与供应商合作，推出修复问题的新固件。

对限制补救措施并作为安全网进行修复也很重要，以防止大规模排水和取消安全性的代码中的错误，这可能导致服务中断如果没有正确处理。

使用此整体方法，我们已经能够添加硬件健康覆盖并修复数千台服务器和服务器组件。每周，我们都能够在数百个服务器上检测，诊断，修复和修复各种PCIe故障。

以下是我们识别和修复PCIe故障的过程的逐步崩溃：

Machinechecker定期运行，作为在我们的生产舰队中的数百万硬件服务器和交换机上的服务。部分检查包括PCIe链接速度，PCIe链路宽度，以及PCIe-Protected和PCIe校正的错误率检查。

对于特定的PCIe端点，我们发现其父级使用PCICrawler的PCIe拓扑信息称为上游。我们考虑PCIe链接的两端。

我们利用PCICrawler的输出，这又取决于通用寄存器LNKSTA，LNKSTA2，LNKCTL和LNKCTL2。

current_speed必须等于预期_peed。换句话说，我们应该具有任一端的当前速度等于最小的能力速度，上游能力，下游能力和上游目标速度。

如果预期的_width小于上游的当前宽度，则我们将此标记为一个不好的链接。

PCIe错误日志记录服务独立运行在我们的硬件服务器上，并以预定格式（JSON）独立记录校正和不可识别的错误及其速率的速率。

Machinecher检查未校正的错误。即使是单个未校正的错误事件也将服务器符合错误。

在定期运行期间，Machinechecker还查找服务器上的生成文件，并在ConfigoRator（我们的配置管理系统）中检查它们的预先记录的真相源，每个平台阈值。如果速率超过预设阈值，则硬件被标记为错误。每个平台很容易可调这些阈值。

我们还利用PCICrawler，该PCICraWler还预先安装了所有硬件服务器，检查PCIe Aer问题。

我们利用我们内部工具的硬件配置知识，将PCIe地址与给定的硬件部分相关联。

Machinechecker使用PCICraWler（用于链路宽度，链接速度和空气信息），PCIe错误解析服务（反过来使用SEL和DMESG）来识别硬件问题并创建警报或警报。 Machinechecker利用我们内部工具的信息来识别与PCIe地址相关联的硬件组件，并通过提供其他信息，例如组件的位置，模型信息和供应商，帮助数据中心运营商（可能需要交换硬件）名称。

应用程序生产工程师可以订阅这些警报或警报，并自定义工作流程以监控，警报，修复和自定义修复。

所有警报的子集可以接受特定的修复。我们还可以微调修复并添加特殊壳体，将修复限制为例如特定情况众所周知的固件升级。

如果修复程序不够失败，则会自动创建硬件维修机票，以便数据中心运算符可以使用测试的好的良好的硬件组件或服务器交换。

我们在几个地方的速率限制为安全网，以防止代码或大规模排水和取消外向的错误，这可能导致服务中断如果没有正确处理。

我们添加了硬件健康覆盖范围并使用此方法固定了几千台服务器和服务器组件。 我们每周继续使用各种PCIe故障检测，诊断，修复和修复数百个服务器。 这使我们的硬件船队更可靠，有弹性和表演。 我们要感谢Aaron Miller，AleksanderKsićek，Chris Chen，Deomid Ryabkov，Wren Turkal以及许多贡献在不同方面的工作的其他人。