大规模故障缓慢：大型生产系统中硬件性能故障的研究和建议

ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月大规模故障缓慢：大型生产系统中硬件性能故障的证据哈雅迪GUNAWI和RIZA O.SUMINTO，芝加哥大学RUSSELLSEARS和CASEY GOLLIHER，Pure StorageSWAMINATHANSUNDARARAMAN，并行机XING LIN和TIM EMAMI，Weiguang Sheng和NEMATOLLAH BIDOKHTI，华为CAITIE MCCAFFREY，TwitterDEEPTHI SRINIVASAN和BISWARANJAN PANDA，Nutanix安德鲁·巴蒂斯特，IBM加里·格里德和帕克斯·M。美国洛斯阿拉莫斯国家实验室KEVINHARMS和ROBERT B. 罗斯，阿贡国家实验室安德烈·雅各布森，新墨西哥州财团罗伯特·里奇和柯克·韦伯，犹他大学彼得·阿尔瓦罗，加州大学圣克鲁斯H. BIRALI RUNESHA，芝加哥大学研究计算中心Mingzhe Hao和Huaicheng Li，芝加哥大学故障缓慢硬件是一种研究不足的故障模式。我们提出了一项研究，114个故障慢硬件事件的报告，收集大规模集群部署在14个机构。我们表明，所有硬件类型，如磁盘，SSD，CPU，内存和网络组件，可以表现出性能故障。我们做了几个重要的观察，如故障从一种形式转换为另一种形式，级联的根本原因和影响可能很长，故障慢故障可能有不同的症状。从这项研究中，我们提出了建议，供应商，运营商和系统设计师。CCS概念：·计算机系统组织→独立和容错系统和网络;实时系统;附加关键词和短语：硬件故障、性能、故障缓慢、故障断续、limpware、抖动该材料得到了NSF的资助（资助号：CCF-1336580、CNS-1350499、CNS-1526304和CNS-1563956）和DOE科学办公室用户设施（合同编号DE-AC 02 - 06 CH 11357）。作者S. 古纳维河O. 苏明托河西尔斯角Golliher，S.Sundararaman，X.Lin，T.Emami，W.Sheng，N.比多赫蒂角McCaffrey，D.斯里尼瓦桑湾Panda，A.Baptist，G.Grider，P.M. 菲尔兹，K。哈姆斯河B. Ross，A.雅各布森，R. Ricci，K.作者声明：H. B. Runesha，M. Hao和H.李;电子邮件：{haryadi，riza}@cs.uchicago.edu，{sears，casey. golliher}@ pupage.com，swaminathan. parallelmachines.com，{xing.lin，Tim.Emami}@ netapp.com，{weiguangsheng ， Mr.bidokhti}@huawei.comcaitiem20@gmail.com ， {deepthi.srinivasan ， biswara.panda}@nutanix.com ， abaptist@us.ibm.com ， {ggrider ， parks}@lanl.gov ， harms@alcf.anl.gov ， rross@mcs.anl.gov ，newmexicoconsortium.org，{ricci，kwebb}@cs.utah.edu，palvaro@ucsc.edu，{runesha，hmz20000}@uchicago.edu，huaicheng@cs.uchicago.edu.允许制作本作品的全部或部分数字或硬拷贝供个人或课堂使用，无需付费，前提是复制品不以营利或商业利益为目的制作或分发，并且复制品在第一页上带有此通知和完整的引用版权的组成部分，这项工作所拥有的其他人比ACM必须尊重。允许用信用进行提取复制，或重新发布，张贴在服务器上或重新分发到列表，需要事先特定的许可和/或费用。 请求权限请发邮件至permissions@acm.org。© 2018 ACM 1553-3077/2018/10-ART23 $15.00https://doi.org/10.1145/324208623ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月二十三：2H. S. Gunawi等人ACM参考格式：哈里亚迪湾Gunawi，Riza O. Suminto，Russell Sears，Casey Golliher，Swaminathan Sundararaman，Xing Lin ， Tim Emami ， Weiguang Sheng ， Nematollah Bidokhti ， Caitie McCaffrey ， DeepthiSrinivasan，Biswaranjan Panda，Andrew Baptist，Gary Grider，Parks M.放大图片作者：Robert B.放大图片创作者：Peter Alvaro，B.鲁尼莎，郝明哲，李怀成。2018.大规模故障缓慢：大型生产系统中硬件性能故障的 ACM Trans. 储存14，3，第23条（2018年10月），26页。https://doi.org/10.1145/32420861介绍了解故障模型是建立鲁棒系统的一个重要标准几十年的研究已经开发出成熟的故障模型，如故障停止[4，23，31，33，36]，故障部分[7，34，35]，故障-瞬变[27]，故障以及腐败[8，19，21，37]和拜占庭故障[15]。本文重点介绍了一种未深入研究的“新”故障类型：fail-slo w a r dwa r e，它仍在运行且功能正常，我们发现，所有主要的硬件组件都可能出现故障缓慢故障。例如，磁盘通过-由于振动，固态硬盘的速度可能会下降三个数量级，降至100 KB/s，由于固件错误，内存卡可以降低到正常速度的25%，由于松散的NVDIMM连接，CPU可以意外地以50%的速度运行，由于缺乏电力，最后网卡性能可以崩溃到Kbps的水平，由于缓冲区损坏和重新传输。虽然可以说，故障缓慢的硬件在过去并不经常出现，但今天，随着系统的大规模部署，以及大规模操作条件的许多复杂性，故障缓慢硬件事件可能发生的可能性增加。此外，随着硬件技术继续扩展（更小和更复杂），今天只会让问题恶化不幸的是，故障缓慢的硬件研究不足。之前的一些论文已经暗示在这个问题的紧迫性;许多不同的术语已被使用，如“失败口吃”[ 5 ]，“灰色failu re“[ 26 ]，和“lim p mode“[ 18，22，28 ]。但是，讨论的焦点并不完全集中在硬件上，还掺杂了软件性能故障。在之前的论文中，我们粗略地计算了一篇论文中提到的故障慢硬件的8个故事，这可能不足以说服系统社区这个紧迫的问题。为了填补该领域硬件性能故障的有力证据的空白，我们，一群来自14个机构的大型数据中心系统的研究人员，工程师和操作员，决定撰写这篇“数据中心文章”。更具体地说，我们收集了114个故障缓慢硬件行为的详细报告，包括硬件类型、根本原因、症状和对高级软件的影响。据我们所知，这是公开报道的生产系统中故障缓慢硬件的最完整的描述由于篇幅限制，我们在表1中总结了我们独特而重要的发现，在此不再重复该表还描述了文章的组织具体来说，我们首先提供我们的高层次观察（第3节），然后详细说明故障缓慢事件的内部根本原因（第4节）以及外部因素（第5节），最后向供应商，运营商和系统设计师提供建议（第6节）。我们希望我们的文章能促进更多的研究和解决这个问题。2方法从14个机构的大规模集群部署中收集了114份故障缓慢硬件报告（表2）。在这样的规模下，更有可能见证故障慢硬件事件。的大规模故障缓慢：大型生产系统中硬件性能故障的证据23：3ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月表1.我们的调查结果和建议摘要重要发现和观察结果第3.1节不同的根本原因：慢故障硬件可能由内部原因（如固件错误或设备错误/磨损）以及外部因素（如配置、环境、温度和电源问题）引起第3.2节故障从一种形式转换为另一种形式：故障停止、局部和瞬时故障可以转换为故障缓慢故障（例如，损坏数据的频繁错误屏蔽的开销可能导致性能下降）。第3.3节不同的症状：故障-缓慢行为可以表现为永久性减速、暂时性减速（性能上升和下降）、部分减速（性能下降）、子组件），和瞬时停止（例如，偶尔重启）。第3.4节一长串根本原因：故障缓慢硬件可能由一长串原因引起一个风扇停止工作，使其他风扇以最大速度运行，造成严重振动，降低磁盘性能）。第3.4节级联影响：故障缓慢的硬件可能会崩溃整个集群性能;例如，降级的NIC使许多作业锁定健康机器中的任务插槽/容器，因此新作业无法找到足够的空闲插槽。第3.5节罕见但致命（检测时间长）：由于多种原因（例如，没有全栈可见性、环境条件、级联根本原因和影响）。建议第6.1节致供应商：当错误屏蔽变得更加频繁时（例如，由于内部故障增加），应该抛出更明确的信号，而不是以高开销运行。应收集和报告设备级性能统计数据（例如，通过S.M.A.R.T），以促进进一步的研究。第6.2节致操作员：32%的根本原因是外部因素，因此故障慢硬件的故障排除必须在线完成。由于级联的根本原因和影响，需要全栈监控。故障缓慢的根本原因和影响表现出一定的相关性，因此统计相关技术可能是有用的（全栈监控）。第6.3节致系统设计者：虽然软件系统在处理故障-停止（二进制）模型方面是有效的，但需要更多的研究来容忍故障-缓慢（非二进制）行为。系统架构师、设计人员和开发人员可以使用本文中报告的所有根本原因对系统进行故障注入，以评估系统的健壮性上述调查结果和建议标有将讨论的章节编号报告都是没有格式的文本，由工程师和操作员撰写，由于影响的严重性，他们仍然生动地回忆起事故这些事件是在2000年至2018年期间报告的，2010年之前只有30起报告每个机构都报告了一组独特的根本原因。例如，尽管某个机构可能多次发现损坏的缓冲区是导致网络硬件变慢（数据包丢失和重传）的根本原因，但它仅被收集为一个报告。因此，单个报告可以表示事件的多个实例如果多个不同的机构报告了相同的根本原因，则会多次计数然而，大多数根本原因（56%）是唯一的，只有32%是重复的。更具体地说，平均有2.6个机构报告了重复事件;例如，5个机构报告了固件错误，4个机构报告了驱动程序错误，2个机构报告了其余问题12%的报告未指出原因（标注为“UNK“表示“未知”）。在大多数情况下，运营商完全可以肯定硬件的性能二十三：4H. S. Gunawi等人ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月表2.经营规模机构#节点机构节点数公司1公司2公司3公司4公司5公司6公司7>10，000150100>1，000>10，000>10，000>10，000A 大 学B 大 学CUniv. D300>100>1，000500Nat’l LabsNat’l LabsNat’l>1，000>10，000>10，000上表显示了故障缓慢报告所源自的客户的运营规模正如文章标题所示，操作规模越大，观察到故障缓慢硬件的概率越高降解的（例如，在一些办公室内、离线测试之后）。在硬件保修尚未到期的情况下，执行更换比调试成本更容易和更便宜原始（部分）数据集可以在我们的网站上下载[3]。数据集是部分的，因为并非所有机构都被允许发布原始数据。我们注意到，没有可分析的硬件级性能日志（更多信息请参见第6.1节），这妨碍了大规模的日志研究。我们坚信，还有更多的案件被遗漏和忽视。一些故事也没有随着操作员的工作变动而传播。我们不包括已知的减速（例如， 随机IO导致磁盘变慢，或GC活动偶尔使SSD变慢）。我们只包括意外退化的报告例如，会报告意外的硬件故障，这些故障会使GC活动更加难以工作。3观察结果（要点）从这项研究中，我们得出了五个重要的高水平发现，如表1所示。3.1不同的根本原因确定故障缓慢硬件的根本原因是一项艰巨的任务，因为它可以由各种根本原因引起，如表3所示。硬件性能故障可能由器械内部的根本原因引起，例如固件问题（FW）或器械错误/磨损（ERR），将在第4节中讨论。然而，一个完美工作的设备也可能会因许多外部根本原因而降级，例如配置（CONF）、环境（ENV）、温度（TEMP）和电源（PWR）相关问题，这些问题将在第5节中介绍。请注意，一份报告可能有多个根本原因（环境和电源/温度问题），因此表3中的总数（125）大于114份报告。3.2故障转换为故障慢不同类型的故障，如故障停止，局部和瞬态可以转换为故障慢故障。故障停止到故障慢：由于许多硬件连接在一起，故障停止组件可以使其他组件表现出故障慢行为。例如，由于备用电源无法提供足够的电力，一个断电的电源将CPU的速度降低了50%;一个坏磁盘会破坏整个RAID的性能这些例子表明，故障-缓慢发生可以与其他故障-停止故障相关，大规模故障缓慢：大型生产系统中硬件性能故障的证据23：5ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月表3.不同硬件类型硬件类型根SSD磁盘Mem净CPU总ERRFW117103110109324521TEMPPWRENVCONF113130510120205566531282010UNK041229总2426153327125该表显示了不同硬件类型的根本原因的发生率。例如，在第一行和第一列中，有11个由于内部设备错误或Wwearouts（ERR）而导致的故障慢SSD。该表参见第3.1节。 硬件类型是SSD、磁盘、存储器（“Mem”）、网络（“Net”）和处理器（“CPU”）。 内部根本原因是设备错误（ ERR ） 和 固件 问题 （FW ） ，外 部根 本原 因是 温度（ TEMP ） 、 电 源 （ PWR ） 、 环 境 （ ENV ） 和 配 置（CONF）。标记为未知（UNK）的问题意味着操作人员无法查明根本原因，而只是更换了硬件。请注意，一份报告可能有多个根本原因（环境和电源/温度问题），因此总数（125）大于114份报告。系统此外，一个强大的故障停止容错系统应确保故障停止故障不会转换为故障慢。故障-瞬时到故障-慢：除了故障-停止，许多种类的硬件可以表现出故障-瞬时错误;例如，磁盘偶尔返回IO错误，处理器有时产生错误的结果，并且不时地存储器位被损坏。 由于其瞬态和“随机“性质，固件/软件通常对用户屏蔽这些错误。一种简单的机制是重试操作或修复错误（例如，ECC或奇偶校验）。然而，当瞬时故障更频繁地发生时，错误请求可能成为“双端工作”。 也就是说，由于错误掩蔽不是自由操作（例如，重试延迟、修复成本），当错误并不罕见时，掩码开销成为影响常见情况性能的最大开销。我们观察到许多情况下，故障瞬态到故障慢转换。例如，磁盘固件触发了严重风险中的“写后重新加载”检查;由于许多DRAM位翻转的ECC校正量很大，机器被认为无法工作;我们收到了许多DRAM的现场报告，显示出高错误率，因此ECC修复延迟成为常见情况;松散的PCIe连接使驱动程序多次重试IO;以及许多丢失/损坏网络数据包的情况（在我们的报告中，比率在1%到50%之间）触发了大量重试，导致网络吞吐量下降了几个从上面的故事中，很明显，必须区分罕见和频繁的故障-瞬时故障。虽然屏蔽前者是可以接受的，但后者应该暴露于而不是隐藏于高级软件堆栈和监控工具。部分故障到慢故障：某些硬件也可能出现部分故障，其中只有设备的某个部分不可用（即，部分故障停止）。这种故障通常由固件/软件层（例如，重新映射）。然而，当部分失效的规模增大时，二十三：6H. S. Gunawi等人ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月图1. 慢故障症状该图显示了四种类型的故障-缓慢症状，如第3.3节所述。X轴表示时间，y轴表示设备的性能表4. 跨硬件类型的症状HW类型Perm.译部分Tr. 停止SSD8733磁盘10455Mem8105净25052CPU10713该表描述了不同硬件类型的故障缓慢症状的发生情况。例如，在第一行和第一列中，有八个SSD案例的减速症状是特殊的（设备性能直到修复后才恢复到正常）。该表在第3.3节中引用。四个症状“烫发。”“特兰斯，”“部分”和“Tr. 最常见的四种故障屏蔽对性能带来负面影响例如，在一个部署中，可用内存大小随时间减少，增加了缓存未命中率，但没有导致系统崩溃; SSD中的坏芯片减少了过度配置空间的大小，触发了更频繁的垃圾收集;以及一个更知名的问题，大量坏扇区的重新映射可能导致更多的磁盘寻道。与上面的故障瞬态情况类似，必须区分小规模和大规模的局部故障。3.3不同的故障-缓慢症状我们观察到故障-停机症状的“多面性”：异常、瞬时、部分故障-停机和瞬时故障-停机，如图1所示。表4显示了这些故障的细分大规模故障缓慢：大型生产系统中硬件性能故障的证据23：7ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月表5.各种根本原因中的故障-缓慢症状症状根Perm.译部分Tr. 停止ERRFW2212838174TEMPPWRENVCONF63129324111302210UNK6112该表描述了各种根本原因中各种故障缓慢症状的计数。例如，在第一行和第一列中，有22种情况下，器械减速是由内部错误/磨损引起的，这些错误/磨损导致每次减速。该表参见第3.3节。根本原因缩写见表3的标题。四个症状“烫发。”“翻译。”“部分”和“T r. 最常见的是图1中的四种症状。跨不同硬件类型的模式表5显示了不同根本原因下这些失效模式的细分永久性减速：第一个症状（图1（a））是永久性减速，其中设备最初正常工作，但随后其性能下降，并且不会恢复到正常状态（直到手动修复问题此模式是四种模式中最简单的，因为操作员可以始终看到问题。如表4所示，这种症状（幸运的是）是最常见的症状。瞬时减速：第二种（图1（b））是瞬时减速，其中设备性能在正常条件和显著退化之间波动，这更难以排除故障。例如，当环境太冷/太热时，磁盘和网络性能可能会下降，但当温度恢复正常时会恢复;当许多磁盘同时繁忙时，偶尔的振动可能会使磁盘速度降低几个数量级;而创建大量负载的应用程序可能会导致机架电源控制向其他机器提供的电力不足（降低其性能），但只能在耗电的应用程序完成之前。部分减速：第三种模型（图1（c））是部分减速，其中只有设备的某些部分会显示减速。换句话说，这是部分故障停止转换为部分减速的情况（第3.2节）。例如，内存的某些部分有故障，需要执行更多的ECC检查;网络路由器的缓冲区的某些部分部分故障-慢模式也会使调试复杂化，因为某些操作会遇到减速，但其他操作（在同一设备上）不受影响。瞬时停止：最后一种（图1（d））是瞬时停止的情况，其中设备偶尔会重新启动，因此有时性能会下降到零。例如，有缺陷的固件有时会使SSDs从RAID磁盘驱动器“消失”，然后重新出现;SAS/SCSI命令中偶尔的位翻转导致主机总线适配器重复重新启动;并且节点在热节流时自动重新启动（例如，当风扇固件没有快速反应时）。二十三：8H. S. Gunawi等人ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月在一个（滑稽的）事件中，在数据中心，有一个方便的桌子，一个操作员把一把办公椅放在存储集群旁边操作员喜欢在椅子上摇晃，反复将热插拔驱动器从机箱中弹出（这是一个很难诊断的相关性虽然本文的重点是硬件，但我们记录了一个事件，其中ext4文件系统处理特定类别的磁盘错误的方式导致对它的请求被挂起，而不是成功或失败。在文件系统重新挂载或节点重新启动后，系统将正常运行，但在收到相同的磁盘错误时会重复出现相同的问题，从而产生短暂的故障停止行为。我们还注意到，高度的位错误将使ECC在修复错误时无效。在某些情况下，ECC支持的内存返回损坏的数据，导致计算机重新启动，并且问题重复出现。根本原因仍然是个谜（例如，也可能是L2/L3缓存中的错误引起的。总的来说，瞬态停止极难诊断，因为通常在硬件和软件堆栈的所有级别上都没有完整的“cor d um p“。当设备或计算机重新启动时，不会记录根本原因，只有在相同的特定情况下，设备才会再次重新启动。3.4连锁反应的原因和影响故障慢硬件的另一个复杂性是级联事件链：首先，在实际的故障原因和硬件的故障慢症状之间，是级联的故障原因链。第二，故障缓慢的症状，然后创建级联的影响，以高层次的软件栈，并可能对整个集群。下面是一些导致故障缓慢硬件的长级联根本原因的示例计算节点中的一个风扇停止工作，使其他风扇以最大速度运行来补偿死风扇，这导致了大量的噪音和振动，随后降低了磁盘性能。主板中的一个故障传感器向操作系统报告了一个错误的值，使CPU在节能模式下运行得更慢。电源损坏导致的电力不足可能会导致许多类型的硬件、磁盘、处理器和网络组件以次优方式运行。电源故障本身也可能是由长期级联原因引起的，例如，供应商省略了与故障电容器一起运送的120V保险丝，这些电容器在电源循环时很可能短路，然后导致轻微的电气火灾，级联成机架级电源故障。接下来，当硬件变成故障缓慢时，它不仅会影响主机，而且还会在整个集群中造成级联影响例如，一台机器中的NIC从1Gbps降级到1 Kbps，导致连锁反应，减慢了整个100台机器的集群（因为受影响的连接任务长时间占用容器/插槽，并且由于插槽短缺，新作业无法运行）。在HDFS HA（高可用性）部署中，当其中一个磁盘速度极慢时，仲裁的名称节点会在HBase部署中，25%正常速度的存储卡会导致积压、内存不足错误和崩溃。在另一个类似的故事中，错误的ECC内存处理速度非常慢，导致分布式索引节点锁定，并由于其他客户端的重试而造成对象争用最后，降级的磁盘创建了一直到客户端虚拟机的积压，向用户弹出了“蓝色死亡名单”。上面的这些案例强调了监控每种硬件的性能的重要性虽然研究界在分布式系统尾部容限领域取得了重大进展，但延迟“尾部”背后的概念由于IO突发而导致的慢速磁盘）。然而，如果尾部模型不包含故障慢硬件，则可能会忽略我们早期的工作[18，40]表明，许多流行系统（如Hadoop和Spark）中的尾部延迟管理存在缺陷，例如一个降级的NIC最终可能会崩溃整个集群。这是因为任务进度的概念只包括任务速度，而不包括大规模故障缓慢：大型生产系统中硬件性能故障的证据23：9ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月→→→→ →→→→图2. 时间检测。该图显示了故障缓慢硬件事件中的检测时间CDF（以小时为单位），并报告了检测时间值X轴（小时）为对数标度。个别传输带宽可能揭示NIC降级问题。例如，让我们假设两个reduce节点R1和R2都从MapReduce洗牌过程中的两个map节点M1和M2读取这里，存在四个数据传输M1R1、M1 R2、M2 R1和M2R2。如果一个节点M2的NIC降级，则路由器R1和R2将关闭。 也就是说，两个归约器将向作业管理器报告类似的任务进度分数，并且因此不触发推测性执行，并且作业无法从SlowM2的NIC中进行扩展。同样，这里的问题是，在MapReduce设计中，每个reduce任务（例如， R1）不报告个人转移过程（例如，例如， M1R1和M2R1）。 如果有一个，则将检测到slowM2的NIC（例如，M2 R1被标记为比M1 R1慢），并且创建新的推测任务M2'以避免M2。虽然上面的示例只说明了来自一个作业的任务，但是这个慢作业的任务锁定了健康机器中的任务槽。例如，归约任务R1和R2是慢的，因为它们的吞吐量被M2的NIC吞吐量指示。R1和R2的机器是健康的，但是reduce任务会长时间锁定插槽。逐渐地，随着健康节点中的更多作业与具有慢速NIC的节点通信，健康节点耗尽空闲任务槽，并且新作业无法运行。在我们对Hadoop Facebook工作负载的一次实验中，我们能够在4小时内将整个30节点集群从170个作业/小时压缩到1感兴趣的读者可以在我们以前的论文中看到详细信息[18，40]。3.5罕见但致命：长TTD我们报告中的故障缓慢硬件事件需要数小时甚至数月才能检测到（精确定位）。 更具体地说，1%的病例是在几分钟内检测到的，10%是在几小时内检测到的，11%是在几天内检测到的，18%是在几周内检测到的，23%是在几个月内检测到的（37%是在未知时间内检测到的）。图2显示了更多的分布（CDF）详细信息，在具有报告的检测时间（TTD）值的事件中，x轴以对数标度小时为单位。 有些工程师称它为“昂贵的窃听器尾巴”。在一个年代，一个由工程师组成的团队TTD很长的原因有几个。首先，故障慢硬件的发生率不像故障停止情况那样频繁的事实意味着今天破坏）这样的场景。因此，虽然可以快速解决更频繁的故障，但频率较低但更复杂的故障（系统无法缓解）可能会大大花费工程师的时间。二十三：H. S. Gunawi等人ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月–其次，如前所述，根本原因可能不是源于故障缓慢硬件（例如，第3.3节中的耗电应用程序引起的瞬时减速的情况花了几个月的时间才弄清楚，因为问题的根源并不在于缓慢的机器或电源。第三，超出操作者控制的外部环境条件可延长诊断（例如，几个月来，一家供应商未能在其海平面测试设施中重现故障-缓慢症状，因为硬件只有在高山海拔处才会减速最后，运营商并不总是具有整个硬件栈的完全可见性（例如，因为操作员无法看到电源的健康状况，所以事件需要几天才能解决4根本原因我们现在讨论内部根本原因，主要是固件错误和设备错误/磨损。我们根据硬件类型（SSD、磁盘、内存、网络和处理器）组织讨论4.1SSD慢故障固态硬盘可能由固件错误和NAND闪存管理复杂性触发。固件/驱动程序错误：我们收到了三个SSD固件错误的报告，供应商承认。首先，许多本应只需数十微秒的单个IO被25 0μs的e x 10倍节流，高达2- 3 ms。 然而，在另一个地区，一批糟糕的SSD停止响应数秒，然后恢复。 如前所述，一个操作员发现一些SSD“disap pea re d”从存储器和later reap pea re d. 在客户端上，SSD正在执行一些内部元数据写入，触发硬件断言失败并重新启动设备。在所有这些情况下，没有解释固件如此运行的原因（专有原因）。然而，下面的其他事件可能会更清楚地说明根本问题。我们记录了一个问题，其中操作系统使用旧的设备驱动程序，该驱动程序与SSD控制器固件的交互效果不佳，因此，许多I/O观察到秒级的高使用不同电压的读取重试为了读取闪存页面，SSD控制器必须设置特定的电压阈值。随着闪存芯片的磨损，氧化物栅极中的电荷减弱，使得使用默认电压阈值的读取操作失败，迫使控制器继续使用不同的电压阈值重试读取[11，12]。由于设备磨损或环境（下文更多内容）与预期不同，因此很难准确建模正确的因此，使用默认电压阈值，如果失败，SSD将使用不同的电压进行重试我们在现场观察到多达四次重试RAIN/基于奇偶校验的读取重建：此外，如果数据不能被读取（即，完全损坏并且ECC检查失败），SSD必须使用RAIN（NAND级RAID）重建页面[1，42]。有三个因素可能会使这种情况变得更糟。首先，如果RAIN条带宽度为N，则必须生成N1个附加读取以重建损坏的页。第二，如上所述，N1个读取也可能经历读取重试。第三，较新的基于TLC的SSD使用LDPC码[41]，这需要更长的时间来重建错误页面。我们观察到，这种重构问题经常发生在接近寿命结束的设备中。此外，SSD工程师发现，位翻转的次数是自上次写入以来的时间、自上次写入以来的读取次数、闪存温度和闪存磨损量部分故障SSD中的重度GCNAND闪存页面的垃圾收集（GC）是用户违反SLA的罪魁祸首[24，29，42]。然而，在现代数据中心SSD中，更高级的固件成功地减少了GC对用户的影响。在现实中，有SSD船舶与“坏”芯片。我们目睹了更多芯片的死亡，大规模故障缓慢：大型生产系统中硬件性能故障的证据23：11ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月××面积减小，这会更频繁地触发GC，其影响无法隐藏。例如，让我们考虑具有1.5TB原始空间的1TB SSD在这里，操作系统级文件系统认为SSD具有1TB的区域，并且SSD保持0.5TB的过度配置空间。随着越来越多的芯片死亡，SSD无法减少暴露给操作系统的1 TB空间因此，0.5 TB的过度配置空间将随着时间的推移而减少，因此，可用空间将更快地填满，GC将更频繁地运行次优磨损均衡破坏并行性：理想情况下，大型IO映射到并行通道/芯片，增加IO并行性。但是，损耗均衡（将热/冷页迁移到热/冷块）会导致LPN到PPN的映射始终发生变化已经观察到，一些罕见的工作负载行为可以使损耗均衡算法次优，使得顺序的LPN映射在相同的通道/芯片之后（较少的并行性）。此外，上述坏页/芯片的问题还迫使损耗均衡算法做出次优的、较少并行的页/块映射。高温导致磨损、重复擦除和空间减少：高温可归因于外部原因（第5.1节），但可能导致SSD内部的连锁反应[32]。我们还观察到，随着温度的升高，SSD页面磨损得更快，并且当SSD在更高的温度下工作时，存在电压阈值建模无效的因此，在块擦除后，位没有正确复位（并非所有位都变为“1”）。因此，有些区块必须多次擦除。注意擦除时间已经很长（例如，高达6ms），因此重复擦除导致可观察到的慢故障行为。更糟糕的是，由于一些块在几次尝试后无法正确重置，固件将这些块标记为不可用，从而导致减少的过度供应空间，以及随后更频繁的GC，如上所述。磨损到更高的垃圾收集和写入放大：更快的磨损和更频繁的GC可以引起更高的写入放大。值得报告的是，我们观察到了广泛不同的扩增水平（例如，对于模块“A”为5，对于模块“B”为600，对于由于过早磨损而导致的某些工作负载为“无限”）。在一种情况下，由于大量的垃圾收集，磨损的SSD上的服务时间观察到12到300毫秒的延迟。并非所有芯片都是平等的：总之，上述大多数问题都源于并非所有芯片都是平等的。坏的芯片仍然通过供应商因此，给定SSD，存在不相等的质量[11，37]。一些工作负载可能会导致低质量芯片上更明显的磨损，从而导致上述所有问题4.2磁盘与SSD类似，故障慢磁盘也可能由固件错误和设备错误/磨损引起固件错误：我们收集了三个与磁盘固件错误相关的报告，这些错误导致速度减慢。有一个案例，磁盘控制器延迟了几十秒的I/O请求。在另一个问题中，磁盘每隔几秒就“抖动”一次，这会产生一个难以调试的问题。在一个大型测试平台中，主节点上的RAID控制器停止，但重新启动后，控制器工作，但偶尔超时和重试。最后，有一个事件，其中一个坏磁盘ex-hausted RAID卡资源造成许多IO超时（坏磁盘屏蔽失败的情况）。设备错误：由大量磁盘损坏触发，RAID控制器在运行时启动频繁的RAID重建;修复程序重新格式化文件系统，以便收集坏扇区，并且不在存储堆栈中使用。磁盘错误可以是当前的;在一个例子中，二十三：H. S. Gunawi等人ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月状态自动从存储池中删除，但当其状态更改为“良好”时又重新添加，但良好的连续转换导致影响用户V女士的问题。一些操作员还观察到介质故障，该故障迫使磁盘在返回操作系统之前多次重试每个读取操作。weakheads：这个问题的disk我们的一份研究报告指出，从致动器组件中溢出的粘性物质并且在磁盘头和盘片之间的累积会导致磁盘头的缓慢移动。由于磁盘变得“纤薄”，因此捕获磁盘粘性的可能性增加。 这个问题可以通过执行随机IO来修复，以使磁盘磁头能够读取fl。”其他原因：慢故障磁盘也可能由环境条件（例如，来自以最大速度运行的风扇的噪声和振动）或温度（例如，磁盘在较冷的环境中进入写后读模式[20]），这将在后面讨论（第5节）。4.3存储器内存系统被认为是相当健壮的，但我们设法收集了一些证据，表明内存硬件也可以表现出故障缓慢的故障。ECC开销：内存减速最常见的根本原因是ECC开销。通常，内存中只有少数地址被损坏，因此ECC需要修复数据。然而，我们已经收集了大量的故障，使ECC修复成为常见的情况下，许多事件。这里，可以想象，引用存储器硬件中的大多数地址将触发ECC修复。减少空间的设备错误在部分内存错误的情况下，有报告称自定义芯片掩盖了错误，没有暴露坏地址。在这里，随着时间的推移，更多的错误增加，可用内存大小减少，导致更高的缓存未命中。与磁盘/SSD使用情况不同，当空间耗尽时会抛出空间不足错误，内存使用情况则不同;只要满足最低内存空间要求，应用程序仍然可以运行，尽管由于减少的缓存大小导致更频繁的页面交换而导致性能降低外部原因：有两种情况下，由于环境条件（特别是高海拔部署，引入了更多的宇宙事件，导致频繁的多位干扰）和人为错误（操作员匆忙插入新的NVDIMM卡，松散的连接使卡仍然可以工作，但性能较慢），存储卡变慢原因不明还有其他原因不明的故障缓慢内存事件在HBase部署中，存储卡的运行速度仅为正常速度的25%在另一个非确定性的情况下，在某个基准测试下观察到低内存带宽，但在不同的基准测试下没有观察到。SRAM错误：人们对DRAM错误给予了很大的关注[38]，可以说DRAM的可靠性在很大程度上是一个已经解决的问题-大多数错误可以被ECC（通过牺牲可预测的延迟）掩盖，或者导致受影响程序的故障停止行为除了DRAM之外，SRAM的使用在设备控制器（例如，FPGA、网卡和存储适配器）。与DRAM不同，SRAM的工作原理是将每个存储单元的电压保持在所需的水平;它不包含可能导致读/写停滞的刷新周期它是最常用的电路，不能af-福特招致失速或缓冲区之间的RAM和组合逻辑消耗的数据。数据路径上的SRAM错误通常会被透明地屏蔽;它们最终会导致CRC验证错误，并且网络数据包或磁盘I/O会被简单地重试。然而，SRAM也被并入控制路径中。我们观察到SRAM错误导致偶尔重新启动设备大规模故障缓慢：大型生产系统中硬件性能故障的证据23：13ACM Transactions on Storage，Vol.号143、第二十三条。出版日期：2018年10月中断的控制路径（在许多其他问题中），导致短暂停止症状（如3.3节所述）。不幸的是，SRAM的每比特错误率并没有得到改善[9]。因此，在实践中，SRAM错误在大规模基础设施中经常发生，是服务中断的主要罪魁祸首4.4网络网络性能变化是一个众所周知的问题，通常由负载波动引起这篇文章强调了慢故障网络硬件可能是网络性能下降的主要原因固件缺陷：我们收集了三份交换机固件中路由算法“不好”的报告。在一种情况下，网络性能下降到最大性能的一半，这是由于在存储驱动器/固件上的动态路由算法没有“按规定”工作。 由于对固件中发生的事情缺乏可见性，操作员必须破解内核才能在交换机之间执行ping，这消耗了很长时间。在另一个故事中，MAC学习没有响应，特殊类型的流量（如组播）无法正常工作，造成流量泛滥。第三个故事与第一个相似NIC驱动程序错误：报告了四个NIC驱动程序错误实例，丢失了许多数据包并导致TCP性能崩溃。 在一个年代，5%的包丢失导致许多虚拟机进入“蓝色死亡名单”。另一个NIC驱动程序错误导致了“错误”，操作员在另一个案例中，开发人员在Linux中发现最后，一个错误导致NIC和TOR交换机之间的意外自动协商，限制了它们之间的带宽，从而未充分利用可用带宽。设备错误：在一个有趣的故事中，网卡的物理实现与设计规范不匹配-芯片的一个遥远的角落正在挨饿，没有全速运行;供应商重新制造了所有的网