ACM Transactions on Storage，Vol.号182、第十四条。出版日期：2022年4月高性能并行文件系统RUNZHOU HAN，OM RAMESHWAR GATLA和MAI ZHENG，爱荷华州立大学JINRUI CAO，纽约州立大学普拉茨堡分校张迪和董戴，北卡罗来纳大学夏洛特分校陈勇，德克萨斯理工大学乔纳森库克，新墨西哥州立大学大规模并行文件系统（PFS）在高性能计算（HPC）中起着至关重要的作用然而，尽管它们很重要，但与本地存储系统或云存储系统相比，它们的可靠性研究或理解要少得多。最近在实际HPC中心发生的故障事件暴露了PFS集群中的潜在缺陷，以及对系统分析的迫切需要为了应对这一挑战，本文对PFS的故障恢复和日志机制进行了研究。首先，为了触发目标PFS的故障恢复和日志记录操作，我们引入了一个名为PF AU l T的黑盒故障注入工具，该工具对PFS是透明的，并且易于在实践中部署。PFAU lT基于一组预定义的故障模型来仿真PFS中的各个存储节点的故障状态，并且使得能够系统地检查故障下的PFS行为接下来，我们应用PFAU lT来研究两个广泛使用的PFS：Lustre和BeeGFS。我们的分析揭示了独特的故障恢复和记录模式的目标PFS，并确定多个情况下，PFS是不完善的故障处理。例如，Lustre包含一个名为LFSCK的恢复组件，用于检测和修复PFS级别的不一致性，但我们发现LFSCK本身可能会在扫描损坏的Lustre时挂起或触发内核恐慌即使在LFSCK的恢复尝试之后，应用于Lustre的后续工作负载仍可能表现异常（例如，挂起或报告I/O错误）。在BeeGFS及其恢复组件BeeGFS-FSCK中也观察到类似的问题我们深入分析了观察到的异常症状的根本原因，这导致了一个新的补丁集被合并到即将发布的Lustre此外，我们详细描述了实验中产生的大量日志，并确定了PFS在故障日志方面的独特模式和局限性。我们希望这项研究以及由此产生的工具和数据集可以促进社区的后续研究，并帮助改进PFS以实现可靠的高性能计算。CCS概念：·计算机系统组织→可靠性;二级存储组织;这项工作得到了美国国家科学基金会（NSF）的部分支持，资助项目为CCF-1717630/1853714、CCF-1910747和CNS-1943204。本材料中表达的任何观点、发现和结论均为作者的观点，不一定反映申办者的观点。作者Han，O.R. Gatla和M.Zheng，爱荷华州立大学，613 Morrill Rd，Ames，Iowa，50011;电子邮件：{hanrz，ogatla，mai}@iastate.edu; J.Cao，State University of New York at Plattsburgh，101 Broad St，Plattsburgh，New York，12901; email：will_cao@nmsu.edu; D.Zhang和D.戴，北卡罗来纳大学夏洛特分校，9201大学城大道，夏洛特，北卡罗来纳州，28223;电子邮件：{dzhang 16，dong.dai}@ uncc.edu; Y。陈，得克萨斯理工大学，2500百老汇，拉伯克，得克萨斯州，79409;电子邮件：yong. ttu.edu; J。库克，新墨西哥州立大学，1780 E大学大道，拉斯克鲁塞斯，新墨西哥州，88003;电子邮件：jcook@cs.nmsu.edu。允许制作本作品的全部或部分数字或硬拷贝供个人或课堂使用，无需付费，前提是复制品不以营利或商业利益为目的制作或分发，并且复制品在第一页上带有此通知和完整的引用版权的组成部分，这项工作所拥有的其他人比ACM必须尊重。允许用信用进行提取 复制，或重新发布，张贴在服务器上或重新分发到列表，需要事先特定的许可和/或费用。从permissions@acm.org请求权限。© 2022计算机协会1553-3077/2022/04-ART14 $15.00https://doi.org/10.1145/348344714ACM Transactions on Storage，Vol.号182、第十四条。出版日期：2022年4月十四：2R. Han等人附加关键词和短语：并行文件系统，文件系统检查器，可靠性，故障处理，日志记录，高性能计算，存储系统ACM参考格式：Runzhou Han，Om Rameshwar Gatla，Mai Zheng，Jinrui Cao，Di Zhang，Dong Dai，Yong Chen，and Jonathan Cook.2022年高性能并行文件系统故障恢复与日志记录的研究 ACM Trans.Storage 18，2，Article 14（April 2022），44 pages.https://doi.org/10.1145/34834471介绍大规模并行文件系统（PFS）在当今起着至关重要的作用各种PFS（例如，Lustre[1]、BeeGFS [2]、OrangeFS [3]）已部署在世界各地的高性能计算（HPC）中心，以支持大规模I/O密集型计算。因此，PFS的可靠性至关重要。然而，尽管最重要的是，PFS的可靠性是少得多的研究或理解相比，其他存储系统。例如，研究人员[4- 12 ]已经研究并发现了本地存储系统的不同层中的RAID [5]、本地文件系统[6，7]）以及许多分布式云系统（例如，HDFS [13]，Cassandra [14]，ZooKeeper [15]）。然而，据我们所知，很少有类似的研究PFSs。这引起了对构建在本地存储系统之上的PFSs的关注，PFS负责以与云系统相当的规模管理大型数据集。事实上，在德克萨斯州的HPC中心最近发生的一次故障事件中，由Lustre并行文件系统管理的多个存储集群[1]在停电后遭受了严重的数据丢失[17]。尽管经过数月的人工努力，许多文件已经恢复，但仍有关键数据永久丢失，对科学发现的潜在损害是不可估量的。其他HPC中心也报告了类似事件[18- 20 ]。这些故障事件表明生产PFS的故障处理存在潜在缺陷，迫切需要进行系统研究。本文从实际问题出发，对PFS的故障处理机制进行了研究。我们关注两个方面：（1）PFS的恢复，这对于确保故障事件下PFS中的数据完整性很重要，以及（2）PFS的日志记录，这对于诊断恢复后PFS异常的根本原因很重要（例如，I/O错误或数据丢失）。第一个挑战是如何以系统的方式触发PFS的故障恢复和日志记录操作。虽然已经提出了许多方法和工具来研究分布式云系统[8主要的PFS被设计为符合POSIX，以支持丰富的HPC工作负载和中间件（例如，MPI-IO [24]）具有高性能。 为此，它们通常包括操作系统（OS）内核模块，并与OS的虚拟文件系统（VFS）层挂钩。例如，Lustre [1]需要在所有存储节点上安装定制的Linux内核模块才能正常工作，并且必须为Lustre的ldiskfs后端修补本地文件系统Ext4[ 25 ]。这种紧密交织和对OS内核的强烈依赖使得现有的设计用于用户级分布式系统的方法（例如，HDFS）在实践中难以用于研究PFS例如，CORDS [21]通过定制的FUSE文件系统向云系统注入故障，这与主要的PFS不兼容此外，与许多云系统不同[14，26，27]，PFS不维护PFS水平的数据，也没有使用充分理解的基于共识的方案[23]进行恢复。因此，依赖于众所周知的容错规范的现有方法高性能并行文件系统的故障恢复与日志研究十四：3ACM Transactions on Storage，Vol.号182、第十四条。出版日期：2022年4月协议（例如，gossip协议[14]）不适用于PFS。进一步讨论见第2、6和7为了应对这一挑战，我们引入了一种名为PF AU l T的故障注入工具，它遵循黑盒原理[28]，以实现在实践中研究PFS的高可用性。PF allT基于两个关键观察结果：（1）外部故障事件可能不同，但只有驱动器上的持久状态可能影响重启后的PFS恢复;因此，我们可以将各种外部故障事件的生成归结为每个存储节点上的设备状态的仿真（2）尽管PFS的复杂性，我们总是可以将整个系统分成跨多个节点的全局层和每个单独节点上的本地系统层;此外，目标PFS（包括其内核组件）可以通过远程存储协议（例如，iSCSI [29]，NVMe/Fabric [30]），它们已用于大规模存储集群中，以便于管理存储设备。换句话说，通过远程存储协议模拟单个存储节点的故障状态，我们可以最大限度地减少入侵或移植工作，以研究PFS。基于上述思想，本文构建了一个基于iSCSI的PF自动化原型系统，该原型系统包括三个部分：代表性故障模型（即，整个设备故障、全局不一致性和网络分区（将在第3.2.2节中介绍），以支持系统地研究PFS的故障恢复和日志记录此外，为了解决将iSCSI添加到PFS软件堆栈的潜在问题，我们开发了PF AU l T的非ISCSI版本，该版本可用于验证iSCSI对所研究的目标PFS的行为的潜在影响。接下来，我们应用PFAU lT来研究两个主要的生产PFS：Lustre [1]和BeeGFS [2]。我们将这三种故障模型应用于PFS集群中不同类型和子集的节点，以创建不同的故障场景，然后仔细检查目标PFS的相应恢复和日志记录操作。我们的研究揭示了多个情况下，PFS是不完善的。例如，Lustre包含一个名为LFSCK的恢复组件[31]，用于检测和修复PFS级别的不一致性，但我们发现LFSCK本身可能会在扫描故障后的Lustre时挂起或触发内核恐慌此外，在运行LFSCK之后，应用于Lustre的后续工作负载仍然可能表现异常（例如，挂起或报告I/O错误）。类似地，BeeGFS的恢复组件（即，BeeGFS-FSCK）在尝试恢复故障后的BeeGFS时也可能突然失败在日志记录方面，我们发现Lustre和BeeGFS在故障处理期间都可能生成大量日志。然而，与现代云系统不同的是，现代云系统通常使用公共库（例如， Log4J [32]）生成格式良好的测井曲线，PFS的测井方法和模式多样且不规则。例如，Lustre可以报告七种类型的标准Linux错误消息（例如，EIO、EBUSY、EROFS），而BeeGFS在相同故障下只能在有限的节点上记录两种类型的标准消息。另一方面，BeeGFS可能会生成更多自定义的错误消息，其中一些相当于标准的Linux错误。通过基于日志源、内容、故障类型和位置详细描述PFS日志，我们可以识别日志消息不准确或误导性，这意味着新的机会，日志增强和日志为基础的分析。更重要的是，基于大量PFS日志、PFS源代码和PFS开发人员的反馈，我们能够识别实验中观察到的异常症状子集的根本原因（例如，I/O错误，重新启动）。深入的根本原因分析已经澄清了在我们的初步实验中观察到的资源泄漏问题[33]，并导致一个新的补丁集被合并到主线Lustre版本[34]。据我们所知，这项工作是第一次全面的研究，故障恢复和记录机制的生产PFS广泛使用的HPC中心。通过开发一个实用的工具，并应用它来系统地分析多个版本的代表性PFS的深入，我们确定了共同的局限性，以及进一步改进的机会我们十四：4R. Han等人ACM Transactions on Storage，Vol.号182、第十四条。出版日期：2022年4月我希望这项研究，包括开源PF测试工具和PFS故障日志的广泛收集，1可以提高对PFS潜在缺陷的认识，促进社区的后续研究，并帮助改进Lustre，BeeGFS和HPC存储系统，以实现可靠的高性能计算。文章的其余部分组织如下。第二节论述了这一研究的背景和动机。在第3节中，我们将介绍PF自动测试工具。在第4节中，我们描述了基于PF的研究方法。在第5节中，我们介绍了Lustre和BeeGFS的研究结果在第6节中，我们详细阐述了经验教训和进一步改进的机会第七节讨论了相关的工作，第八节对本文进行了总结.此外，对于感兴趣的读者，我们在附录A中描述了我们实验中收集的大量故障日志。2背景和动机2.1并行文件系统PFS是高性能计算的关键构建块它们是针对HPC环境设计和优化的，这导致了与其他分布式存储系统不同的体系结构（例如，GoogleFS [26]，HDFS [13]）。例如，PFS针对对同一文件的高度并发访问进行了优化，并且它们严重依赖于硬件级冗余（例如，RAID [35]）而不是分布式文件系统级复制[26]或擦除编码[27]。 我们使用Lustre [25]和BeeGFS [2]，这两个具有不同设计权衡的代表性PFS作为示例，在本节中介绍PFS的典型架构。2.1.1光泽和LFSCK。 Lustre占据了HPC中心的市场份额[36]，前100台超级计算机中有一半以上使用Lustre [37]。 Lustre文件系统通常包括以下组件：管理服务器（MGS）和管理目标（MGT）管理和存储Lustre的配置信息。一个集群中的多个Lustre文件系统可以共享MGS和MGT。元数据服务器（MDS）和元数据目标（MDT）管理和存储Lustre的元数据。MDS为本地MDT提供请求处理从Lustrev2.4开始可以有多个MDS/MDT。此外，MGS/MGT可以与MDS/MDT共处一地对象存储服务器（OSS）和对象存储目标（OST）管理和存储实际的用户数据。OSS为一个或多个本地OST提供文件I/O服务和网络请求处理 用户数据存储为一个或多个对象，每个对象存储在单独的OST上。客户端将Lustre挂载到其本地目录并启动应用程序以访问Lustre中的数据;应用程序通常在登录节点或计算节点上执行，这些节点与Lustre的存储节点分离。与大多数云存储系统不同（例如，HDFS [13]，HBase [38]，Cassandra [14]），Lustre服务器组件的主要功能与Linux内核紧密集成，以实现高性能。此外，Lustre 与操作系统内核的这种紧密交织使得分析Lustre具有挑战性。传统上，高性能是PFS最期望的度量然而，随着HPC应用程序生成越来越多的关键数据，系统规模和复杂性不断增加。1PFAU lT的最新原型和实验日志可在https://git.ece.iastate.edu/data-storage-上公开获得。lab/prototypes/pfault.····高性能并行文件系统的故障恢复与日志研究十四：5ACM Transactions on Storage，Vol.号182、第十四条。出版日期：2022年4月因此，确保PFS的一致性和维护故障下的数据完整性变得越来越重要和具有挑战性。为了应对这一挑战，Lustre引入了一个名为LFSCK的特殊恢复组件[31]，用于在故障后检查和修复Lustre，该组件自v2.6以来已得到显著改进。与Lustre的常规操作类似，LFSCK也涉及在操作系统内核级别实现的大量功能。通常，Lustre集群可以包括一个MGS节点，一个或两个专用MDS节点，以及两个或更多OSS节点，如图1（a）中的目标PFS示例所示（第3.1节）。并且LFSCK可以在故障发生后按需调用以检查和修复Lustre本研究就是在这样的背景下请注意，LFSCK也可以在某些条件下由Lustre自动调用例如，当在对象索引（OI）查找操作期间发现错误时，可以触发LFSCK的oi_scrub过程以扫描设备上的所有对象;此外，如果在OST上访问LAST_ID文件时出现错误，LFSCK将尝试基于OST上的现有对象修复它[25]。在本研究中，我们显式地调用LFSCK，延迟可调，以确保执行所有LFSCK过程。2.1.2BeeGFS和BeeGFS-FSCK。 BeeGFS是领先的PFS之一，在HPC社区中不断发展并获得显著的普及[39]。从概念上讲，BeeGFS集群类似于Lustre，它主要由一个管理服务器（MGS），至少一个元数据服务器（MDS），多个存储服务器（OSS）和几个客户端节点组成BeeGFS还包括内核模块，以实现客户端的高性能和POSIX兼容性。此外，BeeGFS集群可以可选地包括其他实用程序节点（例如，用于利用图形界面进行监视的Admon服务器为了简单起见，我们使用相同的缩写名称（即，MGS、MDS、OSS）来描述Lustre和BeeGFS中的等效存储节点。BeeGFS面临着与Lustre相同的挑战，即保证PFS级的一致性和数据完整性，BeeGFS也有一个名为BeeGFS-FSCK的恢复组件。与Lustre的LFSCK不同SQLite [40]），并发出SQL查询来检查BeeGFS中的潜在错误，这与SQCK [41]的原理类似与调用LFSCK类似，我们在本研究中显式调用BeeGFS-FSCK以确保它完全执行。 为了简单起见，我们在本文的其余部分使用FSCK来指代LFSCK和BeeGFS-FSCK。2.2现有努力的局限性PFS测试套件。与其他实际软件系统类似，PFS通常具有内置的测试套件。例如，Lustre有一个名为“auster”的测试框架，可以驱动2,000多个活动测试用例[ 1 ]。类似地，BeeGFS包括一组丰富的默认测试以及第三方测试[39]。然而，大多数测试套件都是单元测试或微基准测试，用于在正常执行期间验证PFS的功能或性能。存在设计用于执行错误处理代码路径的有限情况，但是它们通常需要修改PFS源代码（例如，启用调试宏、插入函数钩子），这是侵入性的。此外，它们旨在生成一个特定的函数返回错误，以模拟源代码中的单个错误函数实现，而不是模拟整个PFS集群可能必须处理的外部故障事件（例如，断电或硬件故障）。因此，现有的PFS测试套件不足以研究PFS的故障恢复和日志记录机制。其他分布式系统的研究。已经做出了很大的努力来理解其他分布式系统（例如，[9，10，21[13]，Cassandra [14]，Yarn [49]，ZooKeeper [15]）。与PFS不同，大多数深入研究的分布式系统[13- 15，49 ]都是从头开始设计的，以便在云环境中优雅地处理故障事件，其中组件故障是正常的为此，十四：6R. Han等人ACM Transactions on Storage，Vol.号182、第十四条。出版日期：2022年4月云系统通常不在OS内核中嵌入定制的模块或补丁相反，它们由松散耦合的用户级模块组成，这些模块具有用于容错的明确指定的协议ZooKeeper中的leader election [15]，Cassandra中的gossip protocol [14]）。 这种干净的设计功能使许多灰盒/白盒工具[28]能够利用充分理解的内部协议或规范来有效地分析目标系统[9，10，22，23，48]。不幸的是，虽然现有的方法是优秀的，他们的原始目标，我们发现，他们都不能直接应用于PFS在实践中。我们认为一个重要的原因是，PFS传统上是为HPC环境设计和优化的，在HPC环境中，性能至关重要，组件故障预计将最小化。这样的基本假设导致了几十年来完全不同的设计权衡，这使得现有的面向云的努力次优或不适用于PFS。 更具体地说，有以下几个原因。首先，如第1节所述，主要PFS通常与操作系统内核集成，以实现高性能和POSIX兼容性。在没有大量工程努力的情况下（如果可能的话），为用户级分布式系统设计的现有方法无法处理对本地存储堆栈的强烈交织和依赖。第二，PFS倾向于将可靠性功能与常规功能逐步集成，而不使用众所周知的容错协议。例如，PFS层没有可插入的擦除编码模块（如HDFS 3.X [50]）或显式的基于共识的协议[23]相反，PFS严重依赖于本地存储系统（例如，修补的本地文件系统和检查器[51]），以保护PFS元数据免受单个节点上的损坏，并利用FSCK组件在PFS级别检查和修复损坏此外，FSCK的大多数功能可以在定制的内核模块中与常规功能一起实现[52]。这种整体和不透明的性质使得依赖于良好理解的分布式协议或需要目标系统内部规范的详细知识的现有工具难以用于在实践中研究PFS [9，10，22]。第三，许多云系统是基于Java的，并且它们利用公共库进行日志记录（例如，Log4J [32]）。Java的强类型特性和统一的日志格式使得对源代码和/或系统日志进行复杂的静态分析以研究云系统[10]。然而，PFSs通常在C/C++中实现，在OS内核中具有大量的低级代码，这对于静态分析是具有挑战性的。此外，正如我们将在后面的章节（第5节和第A节）中详细介绍的那样，PFS倾向于使用具有不规则日志格式的多种日志方法，这使得依赖于干净日志的技术在很大程度上不适用。总之，我们发现，由于一个或多个约束，现有方法对于研究PFS的故障处理是次优的：它们可能（1）仅处理用户级程序（例如，Java程序）而不是包含OS内核模块和补丁的PFS;（2）需要修改本地存储堆栈（例如，使用FUSE [53]），其与主要PFS不兼容;（3）依赖于不适用于主要PFS的语言特定功能/工具;（4）依赖于公共日志库（例如，Log4J [32]）和格式良好的日志消息，这些消息在主要PFS上不可用;以及（5）依赖目标系统内部协议的详细说明据我们所知，这些说明不适用于PFS进一步讨论见第6节和第7节2.3远程存储协议远程存储协议（例如， NFS [54]、iSCSI [29]、光纤通道[55]、NVMe/Fabric [30]）支持在文件级或块级将远程存储设备作为本地设备进行访问。具体来说，iSCSI [29]是一种基于IP的协议，允许一台机器（即，iSCSI启动器）访问另一机器上的远程块存储（即，iSCSI目标）。到启动器上数据块设备驱动程序层（未通过PFS修补）之上的所有内容高性能并行文件系统的故障恢复与日志研究十四：7ACM Transactions on Storage，Vol.号182、第十四条。出版日期：2022年4月图 1. 我们将继续努力。阴影框是PFAUT的主要组成部分。（a）iSCS版本能够有效地操纵PFS映像;（b）非iSCSI版本能够验证iSCSI对目标PFS的潜在影响。iSCSI完全透明。换句话说，包括PFS的文件系统可以在iSCSI设备上构建，而无需任何修改。 我们利用这个属性，使PF所有的实用和有效的研究现实世界的PFS。3如何触发PFS故障处理和日志记录操作在本节中，我们描述了PF自动测试工具的设计和实现，使我们能够执行系统的研究。如第1节和第2节所述，我们在启动研究时遇到的第一个挑战是，现有工具（包括官方PFS测试套件和广泛的研究原型（第2.2节））都无法在不进行实质性修改的情况下（如果不是不可能的话）应用于分析Lustre等生产PFS的失效行为为了应对这一挑战，我们设计并实施了PF AU l T，其中有以下三个关键目标，我们认为这对于研究PFS在实践中的失效行为至关重要：可用性。由于PFS集群的复杂性，应用工具来研究PFSs可能需要大量的工作; PF旨在尽可能地减少负担。为此，PFAU lT做出关键权衡，将目标PFS视为黑盒[28]。它不需要对PFS代码进行任何修改或插入，也不需要对PFS的恢复方案进行任何规范（通常没有很好地记录一般性。 通过利用对大多数OS内核模块透明的iSCSI驱动程序，PF AU l T可以应用于研究不同的PFS，而几乎不需要移植工作，无论PFS的分布式层和本地内核组件之间的交错有多强。忠诚。PF AU L T可以仿真各种外部故障事件（例如，元数据损坏，网络分区）而不改变PFS本身（即，非侵入式）。3.1概述图1显示了PFAU lT的概述及其与研究中的目标PFS的关系 为了使讨论更具体，我们使用Lustre作为 目标PFS的 示 例 ， 它 包 括 三 种类 型 的 存 储 节 点 （ 即 ， MGS/MGT 、 MDS/MDT 、OSS/OST），如第2.1节所述。PFAU lT有两个版本：基于iSCSI的版本（图1（a））和非iSCSI版本（图1（b））。 iSCSI版本通过iSCSI控制PFS节点的持久状态，并能够有效地研究PFS的故障恢复和日志记录机制，而非iSCSI版本可用于验证iSCSI对目标PFS的潜在影响。如图1（a）中所示，基于iSCSI的PFAU lT包括四个主要组件。（1）故障状态仿真器负责向目标PFS注入故障 它通过iSCSI将一组虚拟设备装载到存储节点，并通过iSCSI协议将所有磁盘I/O命令转发到备份文件。每个备份文件都是在PF所有服务器上维护的一个常规图像文件···十四：8R. Han等人ACM Transactions on Storage，Vol.号182、第十四条。出版日期：2022年4月并配置为iSCSI目标的后端设备（第2.3节），表示相应虚拟设备的持久状态。此外，故障状态仿真器操纵备份文件，并基于工作负载和一组预定义的故障模型来仿真每个虚拟设备的故障状态。（2）PFS工作者启动工作负载以执行PFS并生成I/O操作。（3）PFS服务器调用恢复组件（即，FSCK）以及一组可验证的工作负载，以检查PFS的可恢复性。（4）日志管理器协调整个工作流程并自动收集相应的日志。我们将分别在3.2、3.3、3.4和3.5节详细讨论这四个组成部分图1（b）显示了PFAU lT的非iSCSI版本，它与iSCSI版本的不同之处在于故障状态仿真器和配置器组件。我们在第3.6节中讨论了主要差异，并在第3.7节中总结了整体工作流程。3.2故障状态仿真器为了研究PFS的故障恢复和日志记录，有必要以系统的方式生成故障。由于在理解现实世界存储系统故障方面所做的巨大努力[4，5，56-62 ]，我们可以相对容易地在不同粒度上对一组代表性场景进行然而，真正的挑战是如何构建一个实用的工具，以高可用性、通用性和保真度（即，第三节中所描述的三个重要目标）。 虽然在社区中已经提出了各种故障注入器[4，10，21，23，42-46]，但我们发现，由于许多实际约束（例如， 不能处理PFS的内核模块，需要详细的规范，如第2.2节所述）。基于我们对PFS独特架构的关键观察，我们确定了一个低级软件层（即，iSCSI），它使我们能够在不同粒度的不同PFS上实现自动故障注入（例如，文件级元数据损坏、设备和节点级崩溃以及群集级网络分区）。 更具体地说，PF AU l T通过FailureStateEmulator将各种故障事件还原为存储设备的状态，主要包括两个子组件：虚拟设备管理器和故障模型（图1（a）），如下所示：3.2.1虚拟设备管理器（VDM）。 此子组件管理iSCSI虚拟设备的状态，以实现高效的故障模拟。目标PFS的持久状态取决于向设备发出的I/O操作。为了捕获PFS中的所有I/O操作，VDM创建并维护一组备份文件，每个备份文件对应于存储节点中使用的一个存储设备。备份文件通过iSCSI协议作为虚拟设备安装到存储节点[29]。由于有了iSCSI，从PFS的角度来看，虚拟设备似乎是普通的本地块换句话说，PF AU l T对于所研究的PFS（包括其内核组件）是透明的。PFS中的所有I/O操作最终都将转换为低级磁盘I/O命令，这些命令将通过iSCSI传输到VDMVDM根据收到的命令更新备份文件的内容，并相应地满足I/O请求。请注意，虚拟设备可以通过iSCSI装载到物理机或虚拟机（VM）在VM情况下，整个框架和目标PFS可以托管在一个单个物理机器上，这使得研究具有PF的PFS很方便。这种设计理念类似于ScaleCheck [48]，它利用虚拟机在单个机器上实现分布式系统的可伸缩性测试。3.2.2故障模型。 这个子组件定义了PF所有要模拟的故障事件。对于具有虚拟设备的每个存储节点，PFAU lT基于预定义的故障模型操纵对应的备份文件和网络守护程序 PF AU l T的当前原型包括如下三个代表性故障模型：高性能并行文件系统的故障恢复与日志研究十四：9ACM Transactions on Storage，Vol.号182、第十四条。出版日期：2022年4月(a) 整个设备故障（a-DevFail）。当存储设备完全无法访问PFS时，就会出现这种情况，这可能是由多种原因造成的，包括RAID控制器故障、固件错误和扇区错误累积[4，5，56]。由于PFAU lT旨在通过iSCSI将PFS与虚拟设备解耦，因此我们可以简单地注销虚拟设备以模拟此故障模型。更具体地说，PFAU lT使用iSCSI协议中的loдout命令（第2.3节）断开备份文件到相应存储节点的连接，这使得PFS立即无法访问该此外，不同类型的设备（即，MGT、MDT、OST）可以单独或同时断开，以模拟不同规模的设备故障 通过利用远程存储协议，PF AU l T可以自动模拟不同的场景，而无需任何手动操作。(b) 全局不一致性（b-不一致）。 在这种情况下，PFS仍然可以访问所有存储设备;即，可以正常满足来自PFS的I/O请求此外，本地文件系统后端（例如，基于Ext4的Lustreldiskfs）是一致的。但是，从PFS的角度来看，PFS的全局状态（由所有本地状态组成）是不一致的。因为PFS是建立在（修补）本地文件系统之上的，PFS通常依赖于本地文件系统来维护本地一致性。例如，本地文件系统检查器（例如，e2fsck[63]（对于ldiskfs）需要在调用PFS FSCK之前在每个存储节点上执行换句话说，期望PFS FSCK能够在本地文件系统损坏时正确恢复PFS可能是不合理的因此，在此模型中，我们有意强制PFS集群中的每个本地文件系统必须在本地保持一致请注意，这与现有的模拟异常本地文件系统的工作不同（例如，返回本地文件系统操作的错误[21，23]）。全局不一致场景可能由各种原因引起例如，在数据中心范围的停电[17]中，各个存储节点上的本地文件系统可能会损坏到不同程度，具体取决于故障时的PFS I/O操作类似地，除了断电之外，本地文件系统也可能由于文件系统错误、潜在扇区错误等而损坏[4，56，64]。 本地文件系统的损坏需要由相应的本地文件系统检查器进行检查和修复。然而，本地检查器仅具有本地元数据一致性规则的知识（例如，ldiskfs遵循Ext4虽然运行本地检查器可以将所有本地文件系统带回到本地一致状态，但是由于其本地修复操作，它可能（无意地）破坏PFS的全局一致性规则（例如，跳过不完整的日志事务、回收损坏的本地inode、将本地文件移动到结果，PFS节点之间的全局一致性可能受到损害。为了有效且高效地仿真故障模型，PFAU lT使用如下两种互补方法：(1) PFAU lT调用本地文件系统的调试工具（例如，debugfs[65] for Ext4）来在选定节点上管理本地状态调试工具允许我们利用这样的功能随机损坏磁盘上文件的inode字段的给定百分比 在引入本地损坏之后，我们调用本地文件系统的检查和修复实用程序（例如，e2fsck[51]）来修复本地不一致性，从而使本地文件系统恢复到（本地）健康状态。(2) PFAU lT调用Linux命令行实用程序（例如， rm）随机删除选定节点上给定百分比的磁盘文件。这是为了模拟本地文件系统的修复效果，其中本地检查器可以将损坏的本地文件移动到“lost+found“目录，使其从PFS的角度来看是“丢失”的。由于删除操作是本地文件系统支持的常规操作，因此本地文件系统保持一致。通过删除不同的本地文件（例如，各种对象文件，链接）在不同类型的节点上（即，MGS，MDS，OSS），我们可以很容易地引入大范围的全局不一致性，同时保持局部一致性。十四：R. Han等人ACM Transactions on Storage，Vol.号182、第十四条。出版日期：2022年4月这两种方法各有优缺点。由于调试工具可以暴露本地文件系统的元数据的准确类型信息，因此第一种方法允许PFAU lT直接且全面地操纵本地元数据结构然而，直接向本地元数据引入破坏可能导致超出本地文件系统实用程序的修复能力的严重损害（例如，e2fsck）。因此，局部图像可能“太破碎”而不能用于进一步分析PFS的全局一致性，并且整个分析工作流程必须停止。这种中断是我们的初步原型[33]中的一个主要限制，这使得工作流程效率低下。相比之下，第二种方法始终保持一个可用的和一致的本地文件系统状态，只关注所有可能的情况下，这使得研究PFS的全局不一致性问题的一个子集有效。我们在这项工作中混合使用这两种方法(c) 网络分区（c-Network）。这是大规模网络系统中的典型故障场景[66]，这可能是由功能失调的网络设备（例如，[67]或挂起服务器进程[62]。 当故障发生时，集群会分裂成多个“分区”，这些分区之间无法相互通信。为了模拟网络分区效果，PFAU lT通过网络守护程序禁用PFS在所选节点上使用的网卡，这有效地将所选节点与系统的其余部分总结与展望。上面定义的三种故障模型代表了广泛的现实世界故障场景[4，5，56- 62 ]。通过自动模拟这些故障模型，PFAU lT能够有效地研究目标PFS的故障恢复和日志记录请注意，在所有三种情况下，PF所有都从目标PFS外部引入故障（例如，目标PFS的本地模块下的iSCSI驱动程序而且，由于存在多种类型的存储节点（例如，MGS、MDS、OSS），故障可能会以不同的方式影响PFS，具体取决于受影响的节点类型因此，PFAU lT允许通过配置文件指定哪些类型的节点应用故障模型在这项研究中，我们涵盖了PFS的行为时，故障发生在每一种类型的PFS节点（第5节）。由于PFS传统上是针对高性能进行优化的，因此有人可能会认为，如果目标PFS在经历这些故障后无法正常工作，则可能是但是，我们期望目标PFS的检查和修复组件（例如，Lustre的LFSCK [31]和BeeGFS的BeeGFS-FSCK[2]）能够检测PFS中的潜在损坏并正确响应（例如，在检查期间不要挂起或崩溃此外，我们希望相应的故障日志组件能够生成有意义的消息。 我们相信，了解这种故障处理机制的有效性是解决HPC中心实际发生的灾难的基本步骤[17]。3.3PFS工人与新的文件系统相比，老化的文件系统更能代表真实世界的文件系统使用情况[68，69]。此外，由于内部状态更加复杂，老化的文件系统更有可能在故障情况下遇到恢复问题因此，PFSWorker调用数据密集型工作负载（例如，未修改的HPC应用程序）以老化目标PFS并在注入故障之前生成在内部，PFS将I/O操作分发到存储节点，这些操作将进一步传输到虚拟设备管理器，如第3.2.1节所述。除了未经修改的数据密集型工作负载外，另一种有用的工作负载是专门为检查PFS的可恢复性而设计的自定义应用程序例如，工作负载可以在写入PFS的数据中嵌入校验和最终用户可以使用校验和直接识别PFS中存储的文件的潜在损坏通过这种方式，可以在不依赖于目标PFS的报告的情况下验证用户数据的完整性（其可以是高性能并行文件系统的故障恢复与日志研究十四：ACM Transactions on Storage，Vol.号182、第十四条。出版日期：2022年4月不正确）。 PF AU l T的当前原型包括两种类型的工作负载的示例，这将在第4.3节中详细描述。3.4PFS系统与本地文件系统类似，维护内部一致性和数据完整性对于包括PFS在内的大规模存储系统至关重要因此，PFS通常包括FSCK组件（例如，LFSCK、BeeGFS-FSCK、PVFS 2-FSCK）作为故障后恢复PFS的最后一道防线（第2.1节）。PFAU lT的PFS调度器调用目标PFS的默认FSCK组件以在注入具有可调延迟的故障之后恢复PFS（即，FSCK延迟）。 注意，如果FSCK组件没有被适当地设计或实现（这并不罕见，如将在第5节中讨论的），则FSCK本身可能挂起，并且因此干扰PF自动化的自动工作流程。因此，PF所有的PFS延迟包括可调时间阈值，以在FSCK过程变得无响应的情况下终止FSCK过程。此外，为了验证默认的FSCK是否可以正确地恢复PFS，PFS服务器还调用一组自定义的和可验证的检查工作负载来访问FSCK后的PFS。这使得可以根据工作负载的响应从最终用户的角度检查PFS的可恢复性， 此类工作负载的示例包括具有已知数据校验和或已知I/O操作返回值的I/O密集型程序。
我的内容管理
展开
