分布式存储系统中文件系统故障的问题与容错设计相关

ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月冗余并不意味着容错：分布式存储对文件系统故障Aishwarya Ganesan，Ramnatthan Alagappan，安德里亚角ARPACI-DUSSEAU和REMZI H. 阿帕西-杜索，威斯康星大学麦迪逊分校我们分析了现代分布式存储系统在存在文件系统故障（如数据损坏和读写错误）的情况下的行为我们描述了八种流行的分布式存储系统，并发现了许多与文件系统容错相关的问题我们发现，现代分布式系统不符合-simulator使用冗余从文件系统故障中恢复：单个文件系统故障可能导致灾难性20数据丢失、损坏和不可用等后果我们还发现，上述结果的出现是由于文件系统故障处理中的基本问题，这些问题在许多系统中很常见我们的研究结果具有影响下一代容错分布式和云存储系统的设计CCS概念：·通用和参考→可靠性;·信息系统→分布式存储;• 计算机系统组织→Reddit; ·软件及其工程→文件系统管理;其他关键词和短语：文件系统故障、数据损坏、容错ACM参考格式：放大图片作者：Aishwarya Ganesan，Ramnatthan Alagappan，Andrea C. Arpaci-Dusseau和Remzi H.阿尔帕西-迪索2017. 冗余并不意味着容错：分布式存储对文件系统故障的反应分析 ACM Trans. 存储13，3，第20条（2017年9月），33页。https://doi.org/10.1145/31254971介绍基于云的应用程序，如互联网搜索，照片和视频服务[19，65，67]，社交网络[91，94]，运输服务[92，93]和电子商务[53]，依赖于现代分布式存储系统来管理其数据。这类重要的系统包括键值存储（例如，Redis）、配置存储（例如，ZooKeeper、LogCabin）、文档存储（例如，本材料得到了NSF资助CNS-1419199、CNS-1421033、CNS-1319405和CNS-1218405、DOE资助DE-SC 0014935的资助，以及EMC、Facebook、Google、Huawei、Microsoft、IBM、Samsung、Sea- gate、Veritas和VMware的捐赠本材料中表达的任何意见，发现，结论或建议均为作者的意见，可能不反映NSF，DOE或其他机构的观点。本文是Ganesan等人的FAST[29]. 这里的额外材料包括一些系统（Redis，Cassandra和Kafka）在存在位损坏的情况下的行为分析，Cassandra在不同配置中的研究，更多描述各种系统的关键磁盘数据结构的图形，更全面地描述跨系统的观察结果，以帮助理解，结果总结，说明我们的故障注入方法的图形，以及许多其他小的编辑和更新。作者地址：A.加内桑河Alagappan，A. C. Arpaci-Dusseau和R. H.阿尔帕西-迪索，1210 W。代顿街，麦迪逊，威斯康星州53706;电子邮件：{ag，ra，dusseau，remzi}@ cs.wisc.edu。允许制作本作品的全部或部分数字或硬拷贝供个人或课堂使用，无需付费，前提是复制品不以营利或商业利益为目的制作或分发，并且复制品在第一页上带有此通知和完整的引用。版权的组成部分，这项工作所拥有的其他人比ACM必须尊重。允许用信用进行提取。复制，或重新发布，张贴在服务器上或重新分发到列表，需要事先特定的许可和/或费用。从permissions@acm.org请求权限。© 2017 ACM 1553-3077/2017/09-ART20 $15.00https://doi.org/10.1145/3125497ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月二十：2A. Ganesan等人MongoDB）、列存储（例如，Cassandra）、消息队列（例如，Kafka）和数据库（例如，RethinkDB，CockroachDB）.现代分布式存储系统以复制的方式存储数据以提高可靠性。每个副本在商用硬件上的商用本地文件系统上工作，以存储和管理关键用户数据。在大多数情况下，复制可以掩盖故障，如系统崩溃，电源故障，磁盘或网络故障[22，24，31，32，41，81]。不幸的是，磁盘和闪存驱动器等存储设备表现出更复杂的故障模型，其中某些数据块可能无法访问（读写错误）[7，9，49，55，80，82]，或者更糟的是，数据可能会被悄悄损坏[8，60，86]。这些复杂的故障被称为部分存储故障[63]。以前的研究[10，63，99]已经展示了部分存储错误是如何由文件系统（如ext3，fixed和fixed）处理的。在某些情况下，文件系统只是将错误按原样传播给应用程序;例如，如果底层设备块损坏，ext4将损坏的数据按原样返回给应用程序。在其他情况下，文件系统对错误做出反应，并在传递给应用程序之前将其转换为不同的错误;例如，btrfs将底层块损坏转换为读取错误。在这两种情况下，我们将文件系统向其应用程序抛出的错误称为文件系统错误。现代分布式存储系统对文件系统故障的响应行为至关重要，cal并强烈影响基于云的服务。尽管如此重要，但人们对现代分布式存储系统如何对文件系统故障做出反应知之甚少。一种常见且广泛的期望是较高层中的冗余（即，跨副本）支持从本地文件系统故障中恢复[12，22，36，42，82]。例如，分布式存储系统的一个节点中的不可访问的数据块理想地不会导致用户可见的数据丢失，因为相同的数据冗余地存储在许多节点上。鉴于这种期望，在本文中，我们回答以下问题：现代分布式存储系统在本地文件系统故障时如何表现？他们是否使用冗余从单个文件系统故障中恢复为了研究现代分布式存储系统如何对本地文件系统故障做出反应，我们构建了一个名为CORDS的故障注入框架，该框架包括以下关键部分：errfs，一个系统地注入文件系统故障的用户级FUSE文件系统，以及errbench，一套驱动系统与其本地存储交互的系统特定工作负载。对于每个注入的故障，CORDS自动观察结果系统行为。我们研究了八个广泛使用CORDS的系统：Redis [66]，ZooKeeper [6]，Cassandra [4]，Kafka [5]，RethinkDB [70]，MongoDB [52]，LogCabin [46]和CockroachDB [14]。从我们的研究中得到的最重要的教训是：在大多数现代分布式存储系统中，单个文件系统故障可能会导致灾难性的后果。尽管分布式存储中普遍存在校验和、冗余和其他弹性方法，但单个文件系统故障可能导致数据丢失、损坏、不可用，并且在某些情况下，损坏会蔓延到其他完整的副本。我们系统研究的好处是双重的。首先，我们的研究帮助我们描述了八个系统的文件系统故障处理行为，并发现了这些广泛使用的系统中的许多错误。我们发现，这些系统可以默默地将损坏的数据返回给用户，丢失数据，将损坏的数据传播到完整的副本，变得不可用，或者在查询时返回意外错误。例如，日志初始化期间的单个写入错误可能会导致ZooKeeper中的写入不可用。类似地，Redis和Cassandra中的一个节点中的损坏数据可以传播到其他完整的副本。在Kafka和RethinkDB中，一个节点的损坏可能会导致用户可见的数据丢失。由于分布式存储系统固有地存储数据的冗余副本，并且我们一次只注入一个错误，因此这些行为是令人惊讶和不受欢迎的。冗余并不意味着容错二十：3ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月第二，我们的研究使我们能够在所有系统中对文件系统故障处理进行一些观察。我们发现，上述不良后果的出现是由于以下文件系统容错的根本原因，这是许多分布式存储系统中常见的系统采用不同的数据完整性策略。 我们发现，系统采用不同的策略，以防止文件系统故障，而一些系统仔细使用校验和，其他人完全信任堆栈中的较低层检测和处理腐败。故障通常无法在本地检测到。 我们发现，故障往往是局部未检测到的。有时，这种局部未检测到的故障会立即导致有害的全局影响。崩溃是最常见的反应。即使系统可靠地检测到故障，在大多数情况下，它们也只是崩溃，而不是使用冗余来从故障中恢复。Redundant未被充分利用。尽管分布式存储系统跨许多节点复制数据和功能，但单个节点上的单个文件系统故障可能导致有害的群集范围影响;令人惊讶的是，许多分布式存储系统并不一致地使用冗余作为恢复源。撞车和腐败处理纠缠在 系统经常将从崩溃中恢复与从损坏中恢复混为一谈，意外地调用错误的恢复子系统来处理故障，并最终导致数据丢失等不良结果。本地故障处理和全局协议以不安全的方式交互。本地故障处理行为和全局分布式协议（如读取修复、领导者选举和重新同步）有时会以不安全的方式进行交互，从而导致损坏的传播完整副本或数据丢失。这项工作有三大贡献。首先，我们构建了一个故障注入框架（CORDS）来仔细地将文件系统故障注入到应用程序中（第3节）。其次，我们提出了一个行为研究的八个广泛使用的现代分布式存储系统，他们如何对文件系统故障的反应，也发现了许多错误，在这些存储系统（第4.1节）。我们已经联系了七个系统的开发人员，其中五个已经承认了我们发现的问题。虽然一些问题可以通过实现级别的修复来容忍，但容忍许多其他问题需要根本的设计更改。第三，我们得出了一组跨所有系统的基本观察结果，显示了一些常见的数据完整性和文件系统故障处理问题（第4.2节）。我们的测试框架和我们报告的错误是公开的[1]。我们希望我们的研究结果将导致讨论和未来的研究，以提高下一代云存储系统的弹性。文章的其余部分组织如下。首先，我们提供了文件系统故障的背景知识，并激发了为什么文件系统故障在现代分布式存储系统中很重要（第2节）。然后，我们描述我们的故障模型以及我们的框架如何注入故障和观察行为（第3节）。接下来，我们将介绍我们的行为分析和跨系统的观察（第4节）。最后，我们讨论了相关的工作（第5节）和结论（第6节）。2背景和动机我们首先提供背景知识，说明为什么在文件系统上运行的应用程序会在读和写等操作期间遇到故障。接下来，我们激励为什么这样的文件系统故障是重要的分布式存储系统的上下文中，这些系统的端到端的数据完整性和错误处理的必要性。二十：4A. Ganesan等人ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月2.1文件系统故障文件系统下面的存储堆栈层由许多复杂的硬件和软件组件组成[2]。堆栈的底部是介质（磁盘或闪存设备）。介质上方的固件的命令由设备驱动程序提交。文件系统可能会遇到各种潜在原因的故障，包括介质错误，磁盘中的机械和电气问题，固件中的错误以及总线控制器中的问题[8，9，49，55，63，80，82]。有时，损坏可能是由于操作系统其他部分的软件错误[13]，设备驱动程序[89]，有时甚至是由于文件系统本身的错误[26]。由于这些原因，文件系统会出现两个问题：块错误，其中某些块不可访问（也称为潜在扇区错误），以及块损坏，其中某些块不包含预期的数据。当磁盘在检测到正在访问的块的某些问题时返回显式错误时，文件系统可以观察到块错误（例如磁盘内ECC抱怨块有位腐烂）[9，80]。之前对超过100万个磁盘驱动器进行的一项为期32个月的研究[9]表明，8.5%的近线磁盘和约1.9%的企业级磁盘出现了一个或多个潜在扇区错误。最近的结果显示，基于闪存的SSD中也会出现类似的错误[49，55，82]。同样，最近一项关于闪存可靠性的研究[82]显示，在数百万个闪存设备中，分别有高达63%和2.5%的闪存设备至少经历过一次读取和写入错误由于错误导致的错误定向或丢失写入，文件系统可能会收到损坏的数据在驱动器固件[8，60]中，或者如果磁盘内ECC未检测到位丢失。块损坏是阴险的，因为块以磁盘本身无法检测到的方式损坏。在许多情况下，文件系统会永久性地访问这些损坏的块，并将其默默地返回给应用程序。Bairavasundaram等人，在一项对153万个磁盘驱动器进行的41个月的研究中，发现超过400，000个块存在校验和不匹配[8]。轶事证据表明，存储错误和腐败的流行[18，38，76]。鉴于存储损坏的频率，错误，文件系统遇到此类故障的概率不可忽略在许多情况下，当文件系统遇到来自其底层的错误时，它只是将其原样传递到应用程序[63]。例如，默认的Linux文件系统ext4在底层块不可访问或损坏时分别向应用程序返回错误或损坏的数据。在其他一些情况下，文件系统可能会将潜在的错误转换为不同的错误。例如，btrfs和btrfs将底层损坏转换为错误-当访问底层损坏的磁盘块时，应用程序将收到错误而不是损坏的数据[99]。在这两种情况下，我们都将文件系统向其应用程序抛出的这些错误称为文件系统错误。2.2为什么选择分布式存储系统？考虑到本地文件系统可能返回损坏的数据或错误，数据完整性和正确错误处理的责任落在应用程序身上，因为它们关心安全地存储和管理关键用户数据。大多数单机应用程序（如独立数据库和非复制键值存储系统）仅依赖于本地文件系统来可靠地存储用户数据;它们很少有从本地文件系统故障中恢复的方法。例如，在读取时，如果本地文件系统返回错误或损坏的数据，则应用程序无法恢复该数据。他们的最佳行动方案是可靠地检测此类故障并向用户提供适当的错误消息。现代分布式存储系统与单机应用程序非常相似，也依赖于本地文件系统来安全地管理关键用户数据。然而，与单机应用程序不同，冗余并不意味着容错二十：5ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月分布式存储系统固有地以复制的方式存储数据。精心设计的分布式存储系统可以使用冗余从错误和损坏中恢复，而无需考虑其本地文件系统提供的支持理想情况下，即使一个副本损坏，整个分布式存储系统也不应受到影响，因为其他副本上存在相同数据的其他完整副本。类似地，一个节点中的错误不应该影响系统的全局可用性，因为功能（应用程序代码）也在许多节点上复制。端到端数据完整性和错误处理的案例可以在经典的端到端 系统设计中的结束参数[79]。Ghemawat等人还描述了在Google文件系统中需要这种基于端到端校验和的检测和恢复，因为底层廉价的IDE磁盘通常会损坏块服务器中的数据[30]。类似地，Google [22]在构建大规模互联网服务方面的经验教训强调了高层软件应该如何提供可靠性。考虑到分布式系统的端到端数据完整性和错误处理的可能性，我们研究现代分布式存储系统是否以及如何采用端到端技术来从本地文件系统故障中恢复。3测试系统正如我们在上一节中所讨论的，文件系统可能抛出错误或返回损坏的数据到运行在其上的应用程序;健壮的应用程序需要能够处理此类文件系统故障。在本节中，我们首先讨论我们的文件系统故障模型。然后，我们描述了我们的方法，我们的模型定义的故障注入和观察注入故障的影响。3.1故障模型我们的故障模型定义了应用程序可能遇到的文件系统故障条件我们的模型的目标是注入故障，代表当前和未来的文件系统的故障条件，并驱动分布式系统的错误情况下，很少测试。我们的故障模型有两个重要特征。首先，我们的模型考虑一次向单个节点中的单个文件系统块注入一个错误。虽然相关的文件系统故障[8，9]很有趣，但我们关注的是在sin中注入单个故障的最基本情况，GLE节点，因为我们的故障模型旨在为应用程序提供最大的恢复余地。另一方面，相关的故障可能会排除这种回旋余地。例如，如果包含重要应用程序级数据结构的两个或多个文件系统块被损坏（在相关故障模型中可能），则应用程序挽救其状态的机会可能会减少。其次，我们的模型只将错误注入到应用程序级的磁盘结构中，而不是文件系统元数据中。文件系统可能能够保护自己的（Meta）数据[27];但是，如果用户数据损坏或不可访问，应用程序将收到损坏的块或可能收到错误（如果文件系统有用户数据的校验和因此，应用程序必须处理此类情况。表1显示了我们的模型在读写操作过程中可能出现的错误，以及在最常用的文件系统中可能导致特定错误的根本原因的一些示例。对于所有进一步的讨论，我们使用术语块来表示文件系统块。如果以前对某个块的写入丢失，或者某些不相关的写入被错误地定向到该块，则应用程序可能会读取已损坏（包含零或垃圾）的块。例如，在ext系列文件系统和XFS中，用户数据没有校验和，因此应用程序可以读取这些损坏的数据而不会出现任何错误。我们的模型通过在读取时用零或垃圾破坏块来捕获这种情况。即使在诸如btrfs和dsp之类的文件系统上，用户数据是校验和的，也可能检测到损坏，但无法恢复（除非使用特殊选项装载，例如copies=2二十：6A. Ganesan等人ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月表1.可能的故障和示例原因类型的故障Op示例导致块腐败零读在ext和XFS垃圾读在ext和XFS块错误I/O错误（EIO）读所有文件系统中的潜在扇区错误，磁盘损坏在2004年，写文件系统装载的只读磁盘损坏btrfs空间错误（ENOSPC，EDQUOT）写磁盘已满，所有文件系统比特腐败读在ext和XFS该表显示了我们的模型捕获的文件系统故障以及导致读写操作期间特定故障的示例根本原因in 1999）.虽然btrfs和btrfs使用的用户数据校验和可以防止应用程序访问损坏的数据，但当应用程序访问损坏的块时，它们会返回错误。我们的模型通过在读取时返回类似的错误来捕获此类情况。此外，当存在与正在读取的数据相关联的潜在扇区错误时，应用程序可以在读取时接收EIO。这种情况在所有常用的文件系统上都是可能的，包括ext4、XFS、NTFS和btrfs。如果底层磁盘扇区不可写且磁盘不重新映射扇区，如果文件系统以只读模式挂载，或者如果正在写入的文件在btrfs中已损坏，则应用程序可以在从文件系统写入时接收EIO。对于需要额外空间的写入（例如，向文件追加新块），如果底层磁盘已满或用户我们的故障模型还包括位损坏，其中应用程序读取类似的块，只有几位翻转。当磁盘内ECC没有检测到位损坏并且文件系统也没有检测到这样的条件（例如，XFS和ext）或者当发生存储器损坏（例如，在校验和计算之后和校验和验证之前引入的损坏[99]）。我们的故障模型注入故障，我们认为这是一个现实的方式。例如，如果写入标记为损坏的块，则该块的后续读取将看到最后写入的数据而不是损坏的数据。类似地，当块被标记为读或写错误时，如果文件被删除并重新创建（可能分配新的数据块），我们不会为该块的后续读取或写入返回错误。类似地，当返回空间错误时，所有需要额外空间的后续操作都将遇到相同的空间错误。请注意，我们的模型并不试图模拟任何特定的文件系统。相反，它提出了一组抽象的错误，这些错误可能发生在应用程序可能遇到的常用文件系统上。3.2方法我们现在描述我们的方法来研究分布式系统如何对本地文件系统故障作出反应。我们构建了CORDS，这是一个故障注入框架，由errfs、FUSE [28]文件系统和errbench组成，errbench是一组工作负载和每个系统的行为推断脚本。3.2.1系统工作负载。 为了研究分布式存储系统如何对本地文件系统故障做出反应，我们需要练习导致与本地文件系统交互的代码路径。我们冗余并不意味着容错二十：7ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月图1. C.方法论。（a）概述我们研究分布式系统如何对本地文件系统故障作出反应的方法。（b）errfs如何将故障（损坏和错误）注入到块中，以及我们如何观察注入故障的局部行为和全局影响。为此，我们精心制作了一个工作负载套件errbench;我们的套件由每个系统的两个工作负载组成：读取现有数据项和插入或更新数据项。3.2.2故障注入。图1（a）说明了我们分析分布式系统行为的方法。我们通过插入一些数据项并确保它们被安全地复制和持久化在磁盘上，将所研究的系统初始化为已知状态。我们的工作负载读取或更新作为初始化的一部分插入的项。接下来，我们通过将应用程序的挂载点指定为应用程序的数据目录，将应用程序配置为在errfs上运行。因此，应用程序执行的所有读取和写入都流经errfs，然后errfs可以注入错误。我们运行应用程序工作负载多次，每次通过errfs为单个文件系统块注入单个故障。如果应用程序级数据结构跨越多个文件系统块，那么我们每次只在构成该数据结构的单个文件系统块中注入故障。对于位损坏，我们一次在一个块内的单个字段中翻转一个位。errfs可以注入两种类型的块损坏：用零或垃圾损坏。对于块corruption，errfs在返回到应用程序之前执行读取并更改标记为损坏的块的内容，如图1（b）所示。errfs可以注入三种类型的块错误：读时的EIO（读错误），写时的EIO（写错误），或者需要额外空间的写时的ENOSPC和EDQUOT（空间错误）。为了模拟错误，errfs不执行操作，而只是返回一个适当的错误代码。对于位损坏，errfs需要应用程序特定的信息，包括块内的各种字段及其偏移量和长度。为了注入一个位损坏，errfs在返回数据之前在标记为损坏的字段中翻转一个位。3.2.3行为推理。对于注入单个故障的工作负载的每次运行，我们观察系统的行为。我们的系统特定的行为推理脚本收集系统二十：8A. Ganesan等人ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月从系统的日志文件和客户端可见的输出，如服务器状态，返回代码，错误（stderr），和输出消息（stdout）的行为一旦注入故障的系统行为已知，我们将观察到的行为与预期行为进行比较。以下是我们测试的预期行为：• 提交的数据不应丢失• 防毒墙不应静默返回损坏的数据• 群集应可用于读取和写入• 重试后，重试不应失败。我们相信我们的期望是合理的，因为分布式系统的单个节点中的单个故障理想情况下不应该导致任何不良行为。如果我们发现观察到的行为与预期不符，那么我们将该特定运行（工作负载和注入的错误的组合）标记为错误，分析相关的应用程序代码，联系开发人员并提交错误。局部行为和全局效应。 在分布式系统中，多个节点使用其本地文件系统来存储用户数据。当在节点中注入故障时，我们需要观察两件事：注入故障的节点的局部行为和故障的全局影响，如图1（b）所示。在大多数情况下，节点局部地对注入的故障作出反应。如图1（b）所示，由于注入的故障，节点可能会崩溃或部分崩溃（只有少数进程线程被杀死）。在某些情况下，节点可以通过重试任何失败的操作或使用内部冗余数据（在复制副本内的文件之间相同数据是冗余的或者，节点可以检测并忽略损坏的数据或仅记录错误消息。最后，节点甚至可能无法检测到故障或采取任何措施。断层的全局影响是外部可见的结果。全局影响取决于分布式协议（如领导者选举，共识，恢复，修复）如何响应故障节点的本地行为。例如，即使节点可以在本地忽略损坏的数据并丢失它，全局恢复协议也可以潜在地修复该问题，从而导致正确的外部可观察行为。有时，由于分布式协议的反应方式，可能会出现全局损坏、数据丢失、读不可用、写不可用、不可用或查询失败当一个节点只是作为本地反应崩溃时，系统以减少的冗余运行，直到手动干预。对于给定的工作负载和故障，这些局部行为和全局影响可能会因取决于注入故障的节点所扮演的角色（领导者或跟随者）。为了简单起见，我们统一使用术语领导者和追随者，而不是主人和奴隶。我们在这里注意到，我们的工作负载套件和模型并不完整。首先我们的套房简单的读写工作负载可能会带来更多的洞察力，而更复杂的工作负载可能会带来更多的洞察力。其次，我们的模型不会注入所有可能的文件系统故障;相反，它只注入一个子集的故障，如损坏，读，写和空间错误。然而，即使是我们简单的工作负载和故障模型也会将系统推向极端情况，从而导致有趣的行为。我们的框架可以扩展到包含更复杂的故障，我们的工作负载套件可以增加更复杂的工作负载;我们将此作为未来工作的途径。4结果和观察结果我们研究了八个广泛使用的分布式存储系统：Redis（v3.0.4），ZooKeeper（v3.4.8），Cas- sandra（ v3.7 ） ， Kafka （v0.9 ） ，RethinkDB （v2.3.4 ） ， MongoDB （ v3.2.0） ，LogCabin（v1.0）和Cock- roachDB（beta-20160714）。我们对所有系统进行了配置，以提供最高的安全保证冗余并不意味着容错二十：9ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月我们启用了校验和、同步复制和同步磁盘写入。我们将所有系统配置为形成三个节点的集群，并将复制因子设置为3。我们提出了我们的结果在四个部分。首先，我们对每个系统进行详细的行为分析（第4.1节）。其次，我们推导并提出了一组与所有八个系统的数据完整性和错误处理相关的观察结果（第4.2节），并总结了我们的结果（第4.3节）。接下来，我们将讨论当前文件系统的特性，这些特性可能会影响我们发现的问题（第4.4节）。最后，我们讨论了为什么现代分布式存储系统不能容忍单个文件系统故障，并描述了我们与开发人员互动的经验（第4.5节）。4.1系统行为分析我们现在介绍我们对所有系统的详细行为分析。对于每个系统，我们描述了块损坏和块错误被注入到不同的磁盘结构时的行为。对于每个系统，我们还显示了磁盘文件的格式和系统中的逻辑数据结构。磁盘上的结构名称采用file_name.logical_entity的形式。我们从对文件在磁盘上的格式的理解中获得逻辑实体名。对于一些系统（Redis，Cassandra和Kafka），我们还介绍了注入位损坏时的行为。4.1.1Redis Redis是一种流行的数据结构存储，用作数据库，缓存和消息代理。Redis使用异步主备份复制;因此，存在数据丢失的窗口。然而，Redis可以配置为仅当至少N个滞后小于M秒的follower当前连接到leader时才接受写入。当当前leader失败时，Redis不会自动选择leader。磁盘结构。 图2（a）显示了Redis的磁盘结构。Redis使用一个简单的appen- donly日志文件（aof）来存储修改数据库状态的命令或操作序列appendonly文件不进行校验和。在记录一系列操作之前，会记录一个数据库标识符;这个标识符指定了在以后重放appendonly文件时要应用操作的数据库。从aof中定期获取快照以创建redis数据库文件（rdb）。在启动过程中，followers从leader重新同步rdb文件。整个rdb文件由单个校验和保护。行为分析 图2（b）显示了当块损坏和块错误被引入不同的磁盘结构时Redis的行为。当appendonly文件中的元数据结构损坏或访问该文件时出错时，节点会崩溃（图2（b）中两个工作负载的本地行为框的第一行）。如果领导者崩溃，则集群变得不可用，并且如果跟随者崩溃，则集群以减少的冗余运行（两个工作负载的全局效应的第一行Redis不对appendonly文件中的用户数据使用校验和;因此，它不会检测损坏（两个工作负载的本地行为的第二行如果leader被破坏，则它会导致全局用户可见的破坏，如果followers被破坏，则没有有害的全局影响（读取工作负载的全局影响的第二行）。图3（a）示出了重新同步协议如何在aof中将损坏的用户数据从领导者传播到跟随者，从而导致全局用户可见的损坏。相比之下，appendonly文件用户数据中的错误导致崩溃（两个工作负载的本地行为的第二行）;领导者和跟随者的崩溃分别导致集群不可用和冗余减少（两个工作负载的全局影响的第二行redis_database的第一个块中的问题通过重试并从appendonly文件中的数据再次创建redis_ database文件来修复（图2（b）中的第三行）。当follower上的re- dis_database文件损坏时，它会崩溃，导致冗余减少。由于leader在重新同步期间发送rdb文件，因此相同文件中的损坏会导致二十：A. Ganesan等人ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月图 2. Redis （ a ） Redis 的 文 件 和 逻 辑 数 据 结 构 的 磁 盘 格 式 逻 辑 结 构 采 用 以 下 形 式 ：file_name.logical_entity。如果一个文件可以包含在一个文件系统块中，那么我们不显示逻辑实体名。（b）当损坏（被垃圾或零损坏）、读错误、写错误和空间错误注入Redis中的各种磁盘逻辑结构时的系统行为。在每个系统工作负载（读取和更新）中，有两个框-第一个是注入故障的节点的本地行为，第二个是注入故障的群集范围的全局影响。最右边的注释显示了注入故障的磁盘逻辑结构底部的注释显示了注入特定故障的位置（L，leader/master; F，follower/slave）。故障和逻辑结构组合的灰框表示该故障不适用于该逻辑结构。例如，写错误不适用于读工作负载中的任何数据结构（因为它们没有被写入），因此显示为灰色框。（c）注入位损坏时的行为 对于位损坏，我们翻转磁盘结构内字段中的单个位。例如，appendonlyfile.db_num是appendonlyfile.metadata的一部分底部的图例是（b）和（c）共同的冗余并不意味着容错二十：ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月图3. 示例错误。图中描述了我们在Redis、ZooKeeper、Cassandra、Kafka和RethinkDB中发现的一些bug时间如左图所示向下流动黑色部分表示腐败。追随者崩溃。这些崩溃最终使集群无法进行写操作（图2（b）中的第四行和第五行）。位腐败。图2（c）显示了当注入位损坏时Redis的行为。在大多数appendonly文件元数据结构中，一个翻转的位会导致失败的重新配置，最终导致崩溃。如果领导者崩溃，那么集群变得不可用，如果跟随者崩溃，那么集群以减少的冗余运行在leader上，键字段中的位翻转Redis为每个数据库维护一个数据库标识符（db_num）。当插入或更新某些数据时，首先将适当的数据库（具体地说，数据库标识符）记录在appendonly文件中，然后进行实际的更新。如果记录的数据库标识符（P）中的一个位翻转并因此改变为新值（Q），则仅附加文件中的所有后续操作都被重定向到数据库Q而不是P。数据库标识符中的这一位翻转会导致当查询数据库P时数据丢失，而当查询数据库Q时提供虚假数据在我们的位损坏实验中，我们降低了故障的粒度：我们在磁盘结构中的字段中翻转一个位。我们的比特腐败实验有助于发现通过我们的块腐败实验没有发现的有趣行为。例如，考虑作为appendonlyfile.metadata的一部分的字段appendonlyfile.db_num。当我们在leader上的appendonlyfile.metadata中注入一个粗略的块损坏时（图2（b）中的第一行），leader崩溃，二十：A. Ganesan等人ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月图第四章ZooKeeper （a）文件的磁盘格式和ZooKeeper的逻辑数据结构（b）在ZooKeeper中的各种结构中注入故障时的系统行为。使群集不可用。相反，当我们在leader上的appendonly- file.db_num中注入细粒度的位翻转时（图2（c）中的第二行），它会导致数据丢失，如上所述。4.1.2ZooKeeper ZooKeeper是一个流行的服务，用于存储配置信息、命名和分布式同步。ZooKeeper提供了一个分层的命名空间（一个数据树），并支持在数据树中创建和删除节点等操作。ZooKeeper实现了状态机复制，并使用原子广播协议（ZAB）来维护系统中所有节点的身份状态。只要大多数节点正常工作，系统就保持可用。它通过在日志中持久化操作和持久化数据树的定期快照来提供持久性。磁盘结构：图4（a）显示了ZooKeeper的磁盘结构ZooKeeper使用日志文件来附加用户数据。日志包含日志头（magic、version等）接着是一系列交易。事务由事务头组成，并受校验和保护。 事务头包含epoch、session id等。ZooKeeper维护两个重要的元数据结构：epoch （ 接 受 和 当 前 epoch ） 和 myid （ 节 点 标 识 符 ） 。 epoch 的 更 新 方 法 是 先 写 入epoch_tmp，然后将其重命名为epoch。冗余并不意味着容错二十：ACM Transactions on Storage，Vol.号133、第二十条。出版日期：2017年9月行为分析图4（b）显示了在ZooKeeper中引入块损坏和块错误时的行为。ZooKeeper可以使用校验和来检测日志的transaction_head和transaction_body中的损坏，但是通过简单的崩溃来做出反应（图4（b）中两个工作负载的本地行为的第四行和第五行当epoch和myid损坏或无法读取时，节点会崩溃（两个工作负载的第一行和第三行同样，它在大多数错误情况下崩溃，导致冗余减少在所有崩溃场景中，ZooKeeper都可以可靠地选出新的领导者，从而确保可用性。ZooKeeper在事务的尾部损坏时会在本地忽略该事务（两个工作负载的本地行为的第六行）;leader选举协议会阻止该节点成为leader。最终，损坏的节点通过联系领导者来修复其日志，从而导致正确的行为（两个工作负载的全局效果的第六行不幸的是，ZooKeeper不能从事务头和日志尾的写错误中恢复（图4（b）中的第四行和第八行图3（b）描述了这种情况。在日志初始化期间发生写入错误因此，其他节点认为领导者是健康的，并且不选举新的领导者。然而，由于leader部分崩溃，它不能提出任何事务，导致无限期的写不可用。请注意，这种情况不会对读取工作负载造成有害的全局影响，因为读取可以由任何ZooKeeper节点本地服务，而不需要领导者提出新的事务。4.1.3卡桑德拉 Cassandra是一个类似Dynamo的NoSQL存储。与我们研究的其他系统不同，Cassandra是一个分散的系统;它没有领导者和追随者。系统将所有数据均匀地分布在一个节点集群周围，这些节点形成一个环。Cassandra将数据复制到由复制因子指定的多个节点。它还支持不同的读写一致性级别。在Cassandra中，行被组织到表中，并且行基于主键的散列在集群中的节点之间划分。Cassandra还提供了类似SQL的查询语言（CQL）。磁盘结构：在Cassandra中，本地存储引擎是日志结构合并（LSM）树的变体[59]，将数据存储在sstable中。为每个键空间维护一个单独的sstable;我们将用户创建的键空间的sstable称为 tablest 。 图 5 （ a ） 显 示 了 sstable 中 的 磁 盘 文 件 。 每 个 sstable 由 一 个 Bloom 过 滤 器（tablesst_filter）组成;过滤器提供了一种快速的方法来确定给定的键是否存在。如果在过滤 器 中 找 到 键 ， 则 访 问 表 摘 要 （ tablesst_summary ） 和 表 索 引 （ tablesst_index ） 。tablesst_index包含数据文件（tablesst_data）中数据项的偏移量。tablesst_data包含表中的所有行。行为分析 Cassandra对用户数据启用校验和验证仅作为启用压缩的副作用。因此，我们在Cassandra中进行了两个实验，一个是对用户表禁