CN111587428B - 分布式存储***中的元数据日志 - Google Patents

分布式存储***中的元数据日志 Download PDF

Info

Publication number
CN111587428B
CN111587428B CN201880086394.3A CN201880086394A CN111587428B CN 111587428 B CN111587428 B CN 111587428B CN 201880086394 A CN201880086394 A CN 201880086394A CN 111587428 B CN111587428 B CN 111587428B
Authority
CN
China
Prior art keywords
metadata
log
data
vfs
logs
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201880086394.3A
Other languages
English (en)
Other versions
CN111587428A (zh
Inventor
马奥尔·本-达扬
卡纳尔·阿迪蒂
奥姆里·帕尔蒙
利兰·兹维贝
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Weka Io Ltd
Original Assignee
Weka Io Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Weka Io Ltd filed Critical Weka Io Ltd
Priority to CN202311813920.0A priority Critical patent/CN117785636A/zh
Publication of CN111587428A publication Critical patent/CN111587428A/zh
Application granted granted Critical
Publication of CN111587428B publication Critical patent/CN111587428B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/188—Virtual file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

多个计算设备经由网络彼此可通信地耦接，并且多个计算设备中的每一个可操作地耦接至多个存储设备中的一个或多个。每个计算设备可操作以压缩一个或多个数据块且在数据之前附加日志。日志和数据同时写入闪存。每个计算设备还可操作以将记录变化的元数据注册表保持在闪存中。在电源故障的情况下，日志和以前的日志可用于验证元数据注册表的状态。

Description

分布式存储***中的元数据日志
优先权要求
本申请要求2017年11月13日提交的题为“分布式存储***中的元数据日志”的美国临时专利申请62/585,063以及2018年9月4日提交的题为“分布式存储***中的元数据日志”的美国专利申请号16/121,496的优先权。
背景技术
通过将这样的方法与参照附图在本公开的其余部分中阐述的本方法和***的一些方面进行比较，数据存储的常规方法的局限性和缺点对于本领域技术人员将变得显而易见。
相关申请的交叉引用
题为“分布式擦除编码虚拟文件***”的美国专利申请号15/243,519的全文通过将其整体引入而结合于本文中。
发明内容
提供了用于分布式存储***中的元数据日志的方法和***，该方法和***基本上由至少一个附图示出和/或结合至少一个附图进行了描述，并在权利要求中更完整地阐述。
附图说明
图1示出根据本公开的方面的虚拟文件***的各种示例配置。
图2示出根据本公开的方面的虚拟文件***节点的示例配置。
图3示出根据本公开的示例实现方式的虚拟文件***的另一种表示。
图4A和图4B示出根据本公开的示例实现方式的日志链表和注册表的示例。
图5示出根据本公开的示例实现方式的分布式存储***中的日志链表的另一示例。
图6示出根据本公开的示例实现方式的利用压缩来减少分布式存储***中的写入放大的元数据日志。
图7是说明根据本公开的示例实现方式的在分布式存储***中使用元数据日志的方法的流程图。
图8示出其中两个分布式故障弹性地址空间驻留在多个固态存储盘上的示例实现方式。
图9示出了根据本公开的示例实现方式的前向纠错方案，其可以用于保护存储到虚拟文件***的非易失性存储器的数据。
具体实施方式
本公开中的***适用于小型集群，并且还可以扩展到许多成千上万个节点。讨论了关于非易失性存储器(NVM)(例如，以固态驱动器(SSD)形式出现的闪存)的示例实施例。NVM可以分为4kB“块”(block)和128MB“组块”(chunk)。“扩展区”(extent)也可以存储在易失性存储器中，例如用于快速访问的RAM，也可以由NVM存储备份。扩展区可以存储块的指针，例如，指向存储在块中的1MB数据的256个指针。在其他实施例中，也可以使用更大或更小的存储器划分。本公开中的元数据功能可以有效地分布在许多服务器上。例如，在大的负荷指向文件***名称空间的特定部分的“热点”的情况下，则此负荷可以分布在多个节点上。
图1示出根据本公开的方面的虚拟文件***(VFS)的各种示例配置。图1中所示的是局域网(LAN)102，其包括一个或多个VFS节点120(由1至J的整数索引，j≥1)，并且可选地包括(虚线所示)：一个或多个专用存储节点106(由1至M的整数索引，M≥1)；一个或多个计算节点104(由1至N的整数索引，N≥1)；和/或将LAN 102连接到远程网络118的边缘路由器。远程网络118可选地包括一个或多个存储服务114(由1至K的整数索引，K≥1)；和/或一个或多个专用存储节点115(由1至L的整数索引，对于L≥1)。
每个VFS节点120j(j为整数，其中1≤j≤J)是网络计算设备(例如，服务器，个人计算机等)，其包括用于运行VFS进程以及可选的客户端进程的电路(或者直接在设备104n的操作***上和/或在设备104n中运行的一个或多个虚拟机中)。
计算节点104是可以在没有VFS后端的情况下运行VFS前端的联网设备。计算节点104可以通过将SR-IOV放入NIC并使用完整的处理器内核来运行VFS前端。备选地，计算节点104可以通过经由Linux内核联网堆栈路由联网并且使用内核进程调度来运行VFS前端，因此不具有完整内核的要求。如果用户不想为VFS分配完整的核心，或者联网硬件与VFS要求不兼容，这将很有用。
图2示出根据本公开的方面的VFS节点的示例配置。VFS节点包括VFS前端202和驱动器208、VFS存储器控制器204、VFS后端206和VFS SSD代理214。如本公开中所使用的，“VFS进程”是实现以下中的一个或多个的进程：VFS前端202、VFS存储器控制器204、VFS后端206和VFS SSD代理214。因此，在示例实现方式中，可以在客户端进程和VFS进程之间共享VFS节点的资源(例如，处理和存储器资源)。VFS的进程可以配置为要求相对少量的资源，以最大程度地减少对客户端应用程序的性能的影响。VFS前端202、VFS存储器控制器204和/或VFS后端206和/或VFS SSD代理214可以在主机201的处理器上或在网络适配器218的处理器上运行。对于多核处理器，不同的VFS进程可以在不同的内核上运行，并且可以运行服务的不同子集。从客户端进程212的角度来看，与虚拟文件***的接口独立于运行VFS进程的特定物理机器。客户端进程只需要驱动器208和前端202存在就能为它们提供服务。
VFS节点可以被实现为直接在操作***上运行的单个租户服务器(例如，裸机)，或者被实现为裸机服务器中的虚拟机(VM)和/或容器(例如Linux容器(LXC))。VFS可以在LXC容器中作为VM环境运行。因此，在VM内部，仅包含VFS的LXC容器可以运行。在经典的裸机环境中，存在用户空间应用程序，并且VFS在LXC容器中运行。如果服务器正在运行其他容器化的应用程序，则VFS可能在容器部署环境(例如Docker)的管理范围之外的LXC容器内运行。
VFS节点可以由操作***和/或虚拟机监视器(VMM)(例如，管理程序)服务。VMM可以用于在主机201上创建并运行VFS节点。多个内核可以驻留在运行VFS的单个LXC容器内，并且VFS可以使用单个Linux内核在单个主机201上运行。因此，单个主机201可以包括多个VFS前端202、多个VFS存储器控制器204、多个VFS后端206和/或一个或多个VFS驱动器208。VFS驱动器208可以在LXC容器的范围之外的内核空间中运行。
单个根输入/输出虚拟化(SR-IOV)PCIe虚拟功能可用于在用户空间222中运行网络堆栈210。SR-IOV允许隔离PCI Express，从而可以在虚拟环境上共享单个物理PCIExpress，并且可以向单个物理服务器计算机上的不同虚拟组件提供不同的虚拟功能。I/O堆栈210使VFS节点能够绕过标准TCP/IP堆栈220并直接与网络适配器218通信。可以通过无锁队列将用于uniX(POSIX)VFS功能的便携式操作***接口提供给VFS驱动器208。SR-IOV或完整的PCIe物理功能地址也可以用于在用户空间222中运行非易失性存储器Express(NVMe)驱动器214，从而完全绕开Linux IO堆栈。NVMe可以用于访问通过PCI Express(PCIe)总线连接的非易失性存储介质216。非易失性存储介质216例如可以是固态驱动器(SSD)形式的闪存或固态硬盘(SSD)或内存模块(DIMM)形式的存储类存储器(SCM)。其他示例可能包括存储类存储器技术，例如3D-XPoint。
通过将物理SSD 216与SSD代理214和联网210耦接，可以将SSD实现为联网设备。可替代地，可以通过使用诸如NVMe-oF(基于结构的NVMe)的网络协议将SSD实现为附接网络的NVMe SSD 242或244。NVMe-oF可以允许使用冗余网络链路访问NVMe设备，从而提供更高级别或弹性。网络适配器226、228、230和232可以包含用于连接到NVMe SSD 242和244的硬件加速，以将它们转换为联网的NVMe-oF设备而无需使用服务器。NVMe SSD242和244可以各自包括两个物理端口，并且可以通过这些端口中的任何一个来访问所有数据。
每个客户端进程/应用程序212可以直接在操作***上运行，或者可以在由操作***和/或管理程序服务的虚拟机和/或容器中运行。客户端进程212可以在执行其主要功能的过程中从存储器读取数据和/或将数据写入存储器中。然而，客户端进程212的主要功能与存储无关(即，该过程仅关注其数据被可靠地存储并且在需要时可被检索，而不关注数据的存储位置、时间或方式)。引起这种过程的示例应用程序包括：电子邮件服务器、Web服务器、办公效率应用程序、客户关系管理(CRM)、动画视频渲染、基因组计算、芯片设计、软件构建和企业资源计划(ERP)。
客户端应用程序212可以对与VFS驱动器208通信的内核224进行***调用。VFS驱动器208将相应的请求放在VFS前端202的队列上。如果存在几个VFS前端，则驱动器可能会负荷均衡地对不同的前端进行访问，以确保始终通过同一前端访问单个文件/目录。这可以通过基于文件或目录的ID对前端进行“碎片化”(sharding)来完成。VFS前端202提供接口以用于基于负责该操作的存储桶将文件***请求路由到适当的VFS后端。适当的VFS后端可以在同一主机上，也可以在另一主机上。
VFS后端206托管多个存储桶，其中每个存储桶服务于它接收的文件***请求，并执行任务来另外地管理虚拟文件***(例如，负荷平衡、日志记录、维护元数据、缓存、在层之间移动数据、删除过时数据、更正损坏的数据等)。
VFS SSD代理214处理与相应的存储设备216的交互。这可以包括例如转换地址，以及生成发布给存储设备的命令(例如，在SATA、SAS、PCIe或其他合适的总线上)。因此，VFSSSD代理214用作虚拟文件***的VFS后端206和存储设备216之间的中介。SSD代理214也可以与支持标准协议的标准网络存储设备通信，标准协议例如NVMe-oF(基于结构的NVMe)。
图3示出根据本公开的示例实现方式的虚拟文件***的另一种表示。在图3中，元件302表示虚拟文件***驻留在的各个节点(计算，存储和/或VFS)的存储器资源(例如DRAM和/或其他短期内存)和处理(例如，x86处理器、ARM处理器、NIC、ASIC)资源，例如，如上关于图2所描述的。元件308表示提供虚拟文件***的长期存储的一个或多个物理存储设备216。
如图3所示，物理存储被组织为多个分布式故障弹性地址空间(DFRAS)518。每个分布式故障弹性地址空间包括多个组块310，组块310又包括多个块312。将块312组织成组块310仅是在一些实现中的便利，并且可能并非在所有实现中都进行。每个块312存储提交的数据316(其可以采取下面讨论的各种状态)和/或描述或引用提交的(committed)数据316的元数据314。
将存储设备308组织成多个DFRAS使得能够从虚拟文件***的许多(可能是全部)节点进行高性能并行提交(例如，图1的所有节点1041–104N，1061–106M和1201–120J可以并行执行并发提交)。在一个示例实现方式中，虚拟文件***的每个节点可以拥有多个DFRAS中的相应一个或多个，并对其拥有的DFRAS具有独占读取/提交访问权限。
每个存储桶拥有DFRAS，并因此在对其进行写入时不需要与任何其他节点进行协调。每个存储桶可能会在许多不同的SSD上的许多不同组块上建立条带，因此每个存储桶及其DFRAS可以基于许多参数选择当前要写入的“组块条带”，并且一旦将组块分配给该存储桶，就无需进行协调就可以进行写入。所有存储桶都可以有效地写入所有SSD，而无需协调。
每个DFRAS仅由在特定节点上运行的其所有者存储桶所拥有和访问，从而允许VFS的每个节点控制存储设备308的一部分，而不必与任何其他节点进行协调(在初始化期间或在节点故障之后[重新]分配持有DFRAS的存储桶期间除外，例如，这可以与存储设备308的实际读取/提交操作异步执行)。因此，在这样的实现方式中，每个节点可以独立于其他节点正在做什么而读取/提交到其存储桶的DFRAS，而在读取并提交到存储设备308时不需要达成任何共识。此外，在特定节点发生故障的情况下，该特定节点拥有多个存储桶的事实允许更智能且更有效地将其工作负荷重新分配给其他节点(而不是将整个工作负荷分配给单个节点，可能会创建“热点”)。就这一点而言，在一些实现方式中，存储桶的数量相对于***中的节点的数量可能较大，使得任何一个存储桶可能是放置在另一节点上的相对较小的负荷。这允许根据其他节点的能力和容量对发生故障的节点的负荷进行细粒度的重新分配(例如，具有更多功能和容量的节点可能会获得故障节点存储桶的较高百分比)。
为了允许这种操作，可以保持元数据，该元数据将每个存储桶映射到其当前拥有的节点，使得可以将对存储设备308的读取和提交重定向到适当的节点。
负荷分配是可能的，因为整个文件***元数据空间(例如，目录、文件属性、文件中的内容范围等)可以分解(例如，切碎或碎片化)成均匀的小片(例如，“碎片””)。例如，具有30k服务器的大型***可以将元数据空间分成128k或256k的碎片。
每个这样的元数据碎片可以被保存在“存储桶”中。每个VFS节点可能负责几个存储桶。当存储桶在给定的后端上正在服务元数据碎片时，该存储桶被视为该存储桶的“活动”或“领导者”(leader)。通常，存储桶比VFS节点多。例如，有6个节点的小型***可以有120个存储桶，而有1,000个节点的大型***可以有8k个存储桶。
每个存储桶可以在一小群节点上活动，通常5个节点组成该存储桶的五元组。集群配置使所有参与节点都保持关于每个存储桶的五元组分配的最新信息。
每个五元组监视自己。例如，如果集群中有1万台服务器，并且每个服务器有6个存储桶，则每个服务器将只需要与30台不同的服务器进行通信即可维护其存储桶的状态(6个存储桶将具有6个五元组，因此6*5＝30)。这比集中式实体必须监视所有节点并保持集群范围的状态要少得多。使用五元组可以使性能随着更大的集群而扩展，因为当集群大小增加时，节点不会执行更多的工作。这可能会带来一个缺点，即在“哑”模式下，一个小型集群实际上可以产生比物理节点更多的通信，但是可以通过它们共享所有存储桶而在两台服务器之间仅发送单个心跳来克服此缺点(随着集群的增长，这将更改为仅一个存储桶，但是如果您有一个5个服务器的小型集群，则它将仅在所有消息中包括所有存储桶，而每个服务器将仅与其他4个服务器通信)。五元组可以使用类似于Raft共识算法的算法进行决策(即达成共识)。
每个存储桶可能都有可以运行它的一组计算节点。例如，五个VFS节点可以运行一个存储桶。但是，在任何给定时刻，组中只有一个节点是控制器/领导者。此外，对于足够大的集群，没有两个存储桶共享同一组。如果集群中只有5个或6个节点，则大多数存储桶可以共享后端。在一个相当大的集群中，可能有许多不同的节点组。例如，在26个节点的情况下，有超过64,000个可能的五节点组(即五元组)。
组中的所有节点都知道并同意(即达成共识)哪个节点是该存储桶的实际活动控制器(即领导者)。访问存储桶的节点可能会记住(“缓存”)组中(例如五个)成员中该存储桶的领导者的最后一个节点。如果它访问存储桶领导者，则存储桶领导者执行所请求的操作。如果它访问的节点不是当前领导者，则该节点指示领导者“重定向”访问。如果访问缓存的领导者节点超时，则联系节点可以尝试使用同一五元组的另一个节点。集群中的所有节点共享集群的公用“配置”，这使节点可以知道哪个服务器可以运行每个存储桶。
每个存储桶可都有负荷/使用率值，该值指示文件***上运行的应用程序对存储桶的使用程度。例如，即使使用的存储桶数量不平衡，具有11个使用率较低的存储桶的服务器节点也可以接收另一个元数据存储桶，以在具有9个使用率较高的存储桶的服务器之前运行。可以根据平均响应等待时间、并发运行的操作数、内存消耗或其他指标来确定负荷值。
即使VFS节点没有故障，也可能会发生重新分发。如果***根据跟踪的负荷指标识别出一个节点比其他节点更忙，则***可以将其一个存储桶移动(即“故障转移”)到另一台不太繁忙的服务器。但是，在实际将存储桶重新定位到不同主机之前，可以通过转移写入和读取来实现负荷平衡。由于每次写入可能在由DFRAS决定的不同的节点组上结束，因此具有较高负荷的节点可能不会被选择在要写入数据的条带中。***还可能选择不提供来自高负荷节点的读取。例如，可以执行“降级模式读取”，其中，从同一条带的其他块重构高负荷节点中的块。降级模式读取是通过同一条带中的其余节点执行的读取，并且通过故障保护来重建数据。当读取延迟过高时，可能会执行降级模式读取，因为读取的发起者可能会认为该节点已关闭。如果负荷足够高以创建更高的读取延迟，则集群可以恢复为从其他节点读取该数据，并使用降级模式读取来重建所需的数据。
每个存储桶管理其自己的分布式擦除编码实例(即，DFRAS 518)，并且不需要与其他存储桶协作来执行读取或写入操作。可能有成千上万个并发的分布式擦除编码实例同时工作，每个实例用于不同的存储桶。这是扩展性能不可或缺的一部分，因为它可以有效地将任何大型文件***划分为不需要协调的独立部分，从而无论扩展规模如何都可以提供高性能。
每个存储桶处理属于其碎片的所有文件***操作。例如，目录结构，文件属性和文件数据范围将属于特定存储桶的管辖范围。
从任何前端完成的操作开始于找出哪个存储桶拥有该操作。然后确定该存储桶的后端领导者和节点。可以通过尝试最近知道的领导者来执行该确定。如果最近知道的领导者不是当前领导者，则该节点可能知道哪个节点是当前领导者。如果最近知道的领导者不再是存储桶的五元组的一部分，则该后端将让前端知道应该回到配置中以找到存储桶的五元组的成员。操作的分布允许复杂的操作由多个服务器而不是标准***中的单个计算机处理。
图4A和图4B示出根据本公开的示例实现方式的日志链表和注册表的示例。每个存储桶都有其自己的日志链表，并且由于每个集群包含大量同时工作的存储桶，因此许多组日志可以在整个集群中进行协作。注册表和日志组合在一起以提供一致的操作，这些操作可以很好地对故障转移和重新平衡起作用。为了对注册表进行写入操作，可以每隔几百(或几千)次操作将注册表写入磁盘，并且在发生故障时可以使用日志。
在图4A和图4B中，存储桶401负责DFRAS 403，并控制关联的元数据注册表405。DFRAS 403包含元数据日志的链表，这些元数据日志跟踪更高级别的操作并在发生故障时确保其持久性。DFRAS 403中的每个日志(即，图4A中的每个日志A-H和图4B中的每个日志G-H)都与DFRAS操作相关联。
每个日志块在其之前具有指向多个先前日志块的指针(即“返回指针”)。这些返回指针可以形成具有弹性的链表。例如，如果最后一个日志块是已知的，并且它指向三个先前的日志块，则最后一个日志块的下一个与最后一个日志块共享两个指针，以此类推。为说明起见，最多两个返回指针与每个日志关联。但是，在其他实施例中，与每个日志关联的返回指针可以多于或少于两个。例如，返回指针可以是4个字节长。
元数据注册表405可以在运行该存储桶的同一台服务器的RAM内，并且元数据注册表405可以以下文所述的方式被检查指向DFRAS403，以为在VFS上执行的所有状态更改操作(例如，数据写入，元数据更改等)提供可恢复的持久性。
存储桶401保持并管理其自己的注册表405。注册表405可以用于从指针/键到块数据。存储在注册表405中的部分数据是指向4k数据块的对象的ID(即“返回指针”)。返回指针可用于区分对象。不同种类的对象可能具有相同的ID，但是它们不能由相同的对象ID指向。因此，了解对象ID可以对可能具有相同对象ID的所有块执行并发读取，并且仅返回具有正确返回指针的块。由于这些并发读取可以并行执行，因此总延迟保持得非常低。
注册表还指示将数据提交到DFRAS时的最新日志。如注册表405中的“最后日志”指针所示，图4A中的日志A-F已降级并提交给NVM。RAM中所有将来的“脏”信息都在等待降级。根据图4A中所示的DFRAS状态，只有日志H和G可以包含尚未提交给NVM的信息。日志A-F可能像日志C和E一样被垃圾收集。
图4B示出了在日志A-F被垃圾收集之后的DFRAS 403。此外，由于图4B中的“最后一个日志”指针已移至日志H，因此不再需要日志H和G。
一旦注册表降级到DFRAS，就不再需要创建的日志，并且可以将这些日志条目标记为潜在的释放/垃圾收集和删除。一旦删除了这些已经记帐的日志条目，指针可能仍指向它们，但是由于那里的块将不包含具有正确ID的有效日志条目，因此重播机制将知道这是我们应考虑重播的日志条目的开始(最早)块。例如，在图4A中，与日志A-F相关联的元数据已保存到闪存中。因此，日志A-F不会重播。
元数据注册表会记住日志链表的当前“头”(即“最新日志”)，并且一旦完成将其状态保存到磁盘后，注册表就可以返回日志并将其从该头释放直到尾。这样，注册中表可以“垃圾收集”日志。
如果元数据注册表没有保存到闪存中，则日志被“重播”。例如，在图4A中，与日志G和H相关联的元数据注册表尚未保存到闪存中。因此，将重播日志G和H。如图4B所示，在将日志G和H保存到闪存后，可以将它们释放，并且日志列表的“头”现在是日志H。
当服务器发生故障或从电源故障中恢复过来时，服务器将恢复该服务器作为其领导者的每个存储桶。元数据注册表405可以包括指示自最后一次提交闪存以来的变化的块副本(shadow)。在恢复过程中，注册表块和注册表副本块(如果适用)将在RAM中加载并重建。然后，找到每个存储桶的最新日志。日志列表从尾到头重播(例如，从日志G到日志H)。由于日志数据已经存储在其最终位置，因此将注册表与自最近元数据注册表存储到闪存以来发生的元数据更改进行协调。
在示例实现方式中，每个日志以幂等方式保存数据，即，当重播日志时，日志的状态不变。因此，在重播日志条目时，不会创建其他日志条目。顺序重播日志可能会很耗时，因为一次可能执行数千个日志从而会花费很长时间。但是，日志之间存在时间关系，从而允许每个日志定义要序列化的资源。重播过程可以从确定每个日志条目用于序列化的资源开始。然后，通过对日志进行拓扑排序，***确定以尽可能多的并行度重复播放所有日志的最佳方式。例如，如果块的分组C和D彼此独立(没有一致性问题)，则日志C和D可以并行重播。
一旦数据在数据结构中是完整的，就不再需要日志。但是，如果在重播日志时发现数据块和/或日志有错误，则可以从元数据注册表405上的副本数据重构数据。替代地或与注册表405中的块副本组合，可以从与错误数据块相同的条带中的其他数据块和/或保护块中重建错误数据块。
在存储桶中的所有日志都已成功重播之前，存储桶未设置为就绪。如果存储桶尚未准备就绪，则它将无法接受新的IO或元数据操作。在此期间到达的IO将获得返回码，表明存储桶尚未准备就绪。当BE正在初始化时，这会将责任推回到所有FE。因此，BE不必在初始化期间记住IO或元数据操作。一旦重播所有日志条目后，新的注册表状态将保存到DFRAS，并且可以标记达到该点的日志以进行垃圾收集。一旦保存注册表后，即存储桶就准备就绪来处理IO。
在负荷平衡期间，存储桶可以从一个服务器移动到可以在另一台计算机上的另一台服务器。当存储桶被发送到另一个后端服务器时，***可以等待“接收”VFS后端完全启动并运行，然后该后端负责该存储桶。对于存储桶管理的元数据片段，这可以节省几秒钟的性能下降。
当新的存储桶到来时，旧的存储桶仍然处理IO。当IO与新的存储桶进行通信时，旧存储桶会记住一旦新存储桶开始工作后存在的最后一个日志头。该日志之后的所有操作均从旧存储桶发送到新存储桶，同时也保存到旧存储桶中。一旦新的后端准备好为该存储桶提供服务，它就会通知旧的后端，并且该存储桶的旧实例停止接受IO，并开始将它们引导到运行存储桶的新后端。如果由于某种原因旧后端发生故障，则新存储桶可以作为标准过程重新开始。
图5示出根据本公开的示例实现方式的分布式存储***中的日志链表的另一示例。DFRAS 503在多个闪存设备之间分配数据，并确保在组件发生故障时可恢复数据。每个元数据日志(例如，图5中的日志A-E)可以与数据(例如，图5中的块1-4)同时保存，以避免传统日志操作的先执行后执行(before-perform-after)阶段。这为支持有限数量的写入操作的存储设备(例如NAND闪存设备)提供了更好的利用率，并且还具有使用与数据相同的保护开销来保护日志的优点。
每个元数据日志(A-E)与操作相关联，并且包括操作类型(例如，写入、创建文件、上行链路文件和截断文件)和附加参数。用于写入操作的附加参数(例如，日志A和E)可以包括索引节点ID和偏移量。用于创建文件操作的附加参数(例如，日志D)可以包括父目录和文件名。用于上行链路文件操作的附加参数(例如，日志C)可以包括父目录和索引节点名称。用于截断文件操作的附加参数(例如，日志B)可以包含索引节点ID和站点。
如上面关于图4A和图4B所述，与写入操作相关联的日志(例如，日志A和E)还包括指向数据块的指针(即，块指针)和返回指针。块指针可以包括例如长为4个字节的块ID。
图5中块的每一行示出了为该操作而写的逻辑条带，并且包括两个保护块。图5中的日志A-E示出了一个链表。日志A与最早的操作相关联，日志E与最新的操作相关联。
每个存储桶的DFRAS控制着其正在写入的活动条带组块。当前未处于活动状态的每个条带组块都会记住最近处于活动状态时日志尾存储在何处，从而使***可以查找日志链表的实际末尾/尾。每次DFRAS写入包含日志的条带时，DFRAS都会在活动条带中更新包含日志的最近的数据条带。每个存储桶的DFRAS都知道当前活动的条带组块，因此可以找到要写入日志条目的最近的实际条带。当***在故障后启动时，对于每个DFRAS，仅需要读取活动组块(这是实际***空间的一小部分)，即可找到其故障前执行的所有操作的日志链表。
每个操作在发生时都记录在日志中，并且新信息也以更新标准VFS数据结构的形式“推送”到注册表。在正常情况下，文件操作仅通过注册表工作。日志仅在发生故障转移，重新平衡(例如，将存储桶发送到其他后端服务器)以及电源故障后恢复时使用。
图6示出根据本公开的示例实现方式的利用压缩来减少分布式存储***中的写入放大的元数据日志。当存储日志(例如，图6中的日志A-C)和数据(例如，图6中的块1-4)时，DFRAS已经知道数据将被写入何处。因此，可以以单个原子方式将数据与每个日志一起写入，并且日志将指向实际数据的最终位置。一旦确认IO后，必要时可以重播日志。由于数据未原位写入，并且所有写入均写入新位置，因此可以进行回复。元数据可能会在写入时重定向更新。原位写入的传统存储解决方案需要更复杂的日志操作。例如，传统的存储解决方案可能会将日志和数据写到侧缓冲区，并且在确认后，旧数据将被覆盖以释放侧缓冲区。本公开的“写时重定向”架构允许将数据写入和日志写入操作打包为单个操作。同样，由于扩展区元数据未原位更新，因此新的扩展区数据可能会写入只有在降级窗口关闭后才被降级的注册表。
数据块1-4可以被写入非易失性存储器(例如，多个联网的闪存驱动器)上的DFRAS603。在第一写入操作中，写入数据块1。在第二写入操作中，写入数据块2。并且在第三写入操作中，写入数据块3和4。日志A-C分别在写入操作1-3的开始处添加。
为了减少写入放大，VFS尝试将日志数据与保存的用户数据一起存储。日志所需的空间可以通过透明压缩添加。日志数据本身可能不会很大。日志指向更改的块。例如，块指针和返回指针可能每个都需要4个字节，且整个日志可能不大于例如40个字节，这是4k块的0.1％。给定所需的少量内存，如果用户数据完全可压缩，则提供的一个或多个数据块应能够为日志提供足够的空间。如果组可以被压缩，则将关联的日志写入一个或多个数据块的组的第一个块的一部分。
数据压缩允许减小小的4k IO的写入放大。对于带有加2编码(每个条带上有两个保护块)的DFRAS，4k写入操作的开销已经是100％(因此原始数据块需要两个保护块)。由于还必须记录操作的日志，因此需要一个数据块、一个日志块和用于保护的两个保护块，从而导致150％的开销。通过将日志合并到用户数据中，开销从150％降低到100％。日志的元数据还将获得与数据相同的DFRAS保护。
第一和第三写入操作利用数据压缩来减少写入放大。由于数据块1是可压缩的，因此将日志A添加到包含数据块1的4k页中。因此，日志A与具有“加2”擦除编码保护的4k可压缩写入相关联，并且总共写入了三个4k页。由于数据块3也可压缩，因此将日志C添加到包含数据块3的4k页中。因此，日志C与具有“加2”擦除编码保护的8k可压缩写入相关联，并且总共写入了4个4k页。日志B与数据块2相关联。但是，数据块2是不可压缩的。因此，写入具有“加2”擦除编码保护的不可压缩数据块2总共需要四个4k页。
如果块被压缩，则其被标记为这样。读取时，DFRAS处理压缩块。如果DFRAS读取带有日志的压缩块，则它知道透明地剥离日志，解压缩数据，然后将解压缩的数据返回到VFS存储桶或前端。
在电源故障的情况下，***需要有效地恢复整个可用日志并将日志与磁盘上实际保存的数据结构进行比较。注册表中的每个元数据都记住负责它的日志。即使整个注册表的当前状态是未知的，最近的日志也是已知的，因为存储在磁盘上的注册表也指向“创建它”的最近的日志条目。因为日志是链接的，所以不需要每个日志的位置。为了提高写入平衡(leveling)，注册表不会频繁写入DFRAS。例如，如果注册表是在每次操作之后写入，则从平衡中不会获得任何好处，因为一次操作将导致整个块的更改。如果在DFRAS上更新注册表的状态之前对其进行汇总(或“平均化”)许多操作，则该注册表在写入平衡上变得有效。因此，注册表状态存储在RAM中，并且日志允许在故障的情况下重新创建注册表的内容。
图7是示出根据本公开的示例实现方式的在分布式存储***中使用元数据日志的方法的流程图。在701处，经由诸如分布式存储***中的虚拟文件***(VFS)节点的计算设备来压缩一个或多个数据块。在703，将元数据日志添加到压缩的一个或多个数据块的开头。在705，将元数据日志和压缩的一个或多个数据块同时写入闪存设备(例如，固态驱动器)。元数据日志包括与一个或多个数据块对闪存所做的更改相关联的数据(例如，块指针)。元数据日志还包括指向存储在存储设备上的一个或多个先前的元数据日志的一个或多个返回指针。
在707，与元数据日志有关的元数据注册表被存储在VFS节点中的VFS后端上的易失性存储器(例如，RAM)中。元数据注册表存储一个或多个数据块对存储设备所做的更改。在电源故障的情况下，在709，将元数据日志和一个或多个先前的元数据日志与闪存数据进行比较。在711，VFS后端确定闪存数据是否完整。如果闪存数据是完整的，则在713处，丢弃元数据日志和/或一个或多个先前的元数据日志。如果闪存数据不是完整的，则在715，重播元数据日志和一个或多个先前的元数据日志以确定新的元数据注册表状态。
图8示出其中两个分布式故障弹性地址空间驻留在多个固态存储盘上的示例实现方式。组块5101,1至510D,C可以被组织为多个组块条带5201-520S(S是整数)。在示例实现方式中，使用前向纠错(例如，擦除编码)来分别保护每个组块条带520s(s是整数，其中1≤s≤S)。因此，可以基于期望的数据保护级别来确定任何特定组块条带520s中的组块510d,c的数量。
为了说明的目的，假设每个组块条带520s包括N＝M+K(其中，N，M和K中的每个是整数)个组块510d,c，则N个组块510d,c中的M个可以存储数据码(对于当前存储设备通常是二进制数字或“位”)且N个组块510d,c中的K个可以存储保护码(再次通常是位)。然后，虚拟文件***可以向每个条带520s分配来自N个不同故障域的N个组块510d,c。
如本文所用，“故障域”是指一组组件，其中任何一个组件中的故障(组件掉电，变得无响应等)可能导致所有组件的故障。例如，如果机架具有单个机架顶部交换机，则该交换机的故障将使与该机架上的所有组件(例如，计算、存储和/或VFS节点)的连接断开。因此，对于***的其余部分，这等效于该机架上的所有组件如同一起出现故障。根据本公开的虚拟文件***可以包括比组块510更少的故障域。
在对于每个这样的节点，虚拟文件***的节点以完全冗余的方式仅与单个存储设备506连接和供电的示例实现方式中，故障域可以仅仅是该单个存储设备506。因此，在示例实现方式中，每个组块条带520s包括位于存储设备5061-506D的N个中的每个上的多个组块510d,c(因此，D大于或等于N)。这样的实现方式的示例在图7中显示。
在图8中，D＝7，N＝5，M＝4，K＝1，并且存储设备被组织为两个DFRAS。这些数字仅用于说明，而无意作为限制。第一DFRAS的三个组块条带520被任意地调出以用于说明。第一组块条带5201由组块5101,1、5102,2、5103,3、5104,5和5105,6组成；第二组块条带5202由组块5103,2、5104,3、5105,3、5106,2和5107,3组成；第三组块条带5203由组块5101,4、5102,4、5103,5、5105,7和5107,5组成。
尽管在实际实现方式中在图8的简单示例中D＝7和N＝5，但是D可能比N大得多(例如，大于1的整数倍，并且可能高至多个数量级)，并且可以选择两个值，以使单个DFRAS的任何两个组块条带520驻留在同一组N个存储设备506(或更一般地说，在同一组N个故障域)上的概率低于所需阈值。以此方式，任何单个存储设备506d(或更普遍地，任何单个故障域)的故障将导致(期望统计可能基于以下各项确定：D和N的选定值，N个存储设备506的大小以及故障域的布置)任何特定条带520s的至多一个组块510b,c的丢失。更进一步，双重故障将导致绝大多数条带最多丢失单个块510b,c，并且只有少量的条带(基于D和N的值确定)将从任何特定的条带520s中丢失两个组块(例如，两次故障的条带数量可能会比一次故障的条带数量成指数地减少)。
例如，如果每个存储设备506d是1TB，并且每个组块是128MB，则存储设备506d的故障将导致(期望统计可能基于以下各项确定：D和N的选定值，N个存储设备506的大小以及故障域的布置)7812(＝1TB/128MB)个组块条带520丢失一个组块510。对于每个这样的受影响的组块条带520s，可以使用适当的前向纠错算法和组块条带520s的其他N-1个组块来快速地重建丢失的组块510d,c。此外，由于受影响的7812个组块条带均匀分布在所有存储设备5061-506D中，因此重建丢失的7812个组块510d,c将涉及(希望的统计可能基于以下项确定：D和N的选定值，N个存储设备506的大小以及故障域的布置)从每个存储设备5061-506D读取相同数量的数据(即，重建丢失的数据的负担均匀地分布在所有存储设备5061-506D中，以便从故障中非常快速地恢复)。
接下来，转向两个存储设备5061–506D并发故障的情况(或更一般地说，两个故障域的并发故障)，由于每个DFRAS的组块条带5201-520S在所有存储设备5061-506D上的均匀分布，只有极少数的组块条带5201-520S会丢失N个组块中的两个。虚拟文件***可操作为基于元数据快速识别这种两次丢失的组块条带，该元数据指示组块条带5201-520S与存储设备5061-506D之间的映射。一旦识别出这样的两次丢失组块条带，虚拟文件***就可以在开始重建一次丢失组块条带化之前优先考虑重建那些两次丢失组块条带。其余的组块条带将仅具有单个丢失的组块，并且对于它们(受影响的组块条带中的绝大多数)，两个存储设备506d的并发故障与仅一个存储设备506d的故障相同。类似的原理适用于三个并发故障(在两个并发故障场景中，具有三个故障块的组块条带的数量将远远少于具有两个故障块的数量)，依此类推。在示例实现方式中，可以基于组块条带520s中的丢失数量来控制执行组块条带520s的重构的速率。这可以通过例如控制执行用于重建的读取和提交的速率，执行用于重建的FEC计算的速率，传送用于重建的网络消息的速率等来实现。
图9示出根据本公开的示例实现方式的前向纠错方案，其可以用于保护存储到虚拟文件***的非易失性存储器的数据。所示为DFRAS的块条带5301–5304的存储块9021,1–9027,7。在图8的保护方案中，每个条带的五个块用于存储数据码，且每个条带的两个块用于保护码(即，M＝5和K＝2)的数据存储。在图9中，使用以下公式(1)-(9)计算保护码：
因此，图9中的四个条带5301-5304是多个条带(在这种情况下为四个条带)FEC保护域的一部分，并且任何块条带5301-5304中的任何两个或更少块的丢失通过使用以上等式(1)-(9)的各种组合来恢复。为了进行比较，单条带保护域的示例是：如果仅通过P1保护D11，D22，D33，D44，D54，并且将D11，D22，D33，D44，D54和P1全部写入条带5301(5301是单个条带FEC保护域)。
根据本公开的示例实现方式，多个计算设备经由网络彼此通信地耦接，并且多个计算设备中的每一个包括多个存储设备中的一个或多个。多个故障弹性地址空间分布在多个存储设备上，使得多个故障弹性地址空间中的每一个跨越多个存储设备。多个故障弹性地址空间中的每一个被组织成多个条带(例如，如图8和图9所示的多个530)。多个条带中的每个或多个条带是多个前向纠错(FEC)保护域(例如，诸如图9中的多条带FEC域)中的相应一个域的一部分。多个条带中的每一个可以包括多个存储块(例如，多个512)。多个条带中的特定条带的每个块可以位于多个存储设备中的不同存储设备上。多个存储块的第一部分(例如，由图9的条带5301的9021,2–9021,6组成的5个数量)可用于存储数据码，而多个存储块的第二部分(例如，图9的条带5301的两个9021,1和9021,7的数量)可以用于存储至少部分地基于数据码计算出的保护码。多个计算设备可以可操作以对多个条带进行排序。该排序可以用于选择多个条带中的哪个条带用于对多个故障弹性地址空间之一的下一提交操作。排序可以基于在多个条带中的每个条带中有多少个受保护和/或不受保护的存储块。对于多个条带中的任何一个，该排序可以基于存储在具有多个条带中的特定一个的多个存储设备上的位图。该排序可以基于多个条带中的每个条带中当前存储数据的块的数量。该排序可以基于用于向多个条带中的每个条带进行提交的读取和写入开销。每个故障弹性地址空间可以在任何给定时间仅由多个计算设备之一拥有，并且多个故障弹性地址空间中的每个只能由其所有者读取和写入。每个计算设备可以拥有多个故障弹性地址空间。多个存储设备可以被组织成多个故障域。多个条带中的每个条带可以跨越多个故障域。每个故障弹性地址空间可以跨越所有多个故障域，使得当多个故障域中的任何特定故障域发生故障时，在多个故障域中的每个其他故障域之间分配用于重建丢失数据的工作量。多个条带可以分布在多个故障域上，使得在多个故障域中的两个故障域同时发生故障的情况下，多个故障域中的两个故障域上的多个条带中的任何一个特定条带的两个块出现的机率小于多个故障域中的两个故障域上的多个条带中的任何特定条带中只有一个块存在的几率。多个计算设备可用于首先重建具有两个故障块的多个条带中的任何一个，然后重建仅具有一个故障块的多个条带中的任何一个。多个计算设备可用于以比仅具有一个故障块的多个条带的重建速率更高的速率(例如，在专用于重建的CPU时钟周期中，百分比较大，专用于重建的网络传输机会占较大百分比，等等)来执行具有两个故障块的多个条带的重建。多个计算设备可用于在一个或多个故障域发生故障的情况下，基于丢失了多个条带中的同一条带的多少其他块来确定重建任何特定丢失块的速率。其中，多个故障域中的一个或多个包括多个存储设备。多个FEC保护域中的每一个可以跨越多个条带中的多个条带。多个条带可以被组织为多个组(例如，图8中的组块条带5201-520S)，其中，多个组中的每一个包括多个条带中的一个或多个，以及多个计算设备可操作用于对每个组，对组的多个条带中的一个或多个进行排序。多个计算设备可操作为：对多个组中的选定的一组执行连续的提交操作，直到组的多个条带中的一个或多个条带不再满足确定的标准为止，并且在多个组中选择的一个不再满足确定的标准时，选择多个组中的另一个。该标准可以基于有多少块可用于新数据写入。
尽管已经参考某些实现描述了本方法和/或***，但是本领域技术人员将理解，在不脱离本方法和/或***的范围的情况下，可以进行各种改变并且可以替换等同物。另外，在不脱离本发明范围的情况下，可以做出许多修改以使特定情况或材料适应本发明的教导。因此，意图是本方法和/或***不限于所公开的特定实现，而是本方法和/或***将包括落入所附权利要求的范围内的所有实现。
如本文所使用的，术语“电路”和“电路***”是指物理电子组件(即硬件)以及任何软件和/或固件(“代码”)，其可以配置硬件，由硬件执行和/或与硬件相关联。如本文所使用的，例如，特定的处理器和存储器在执行第一行或多行代码时可以包括第一“电路”，并且在执行第二行或多行代码时可以包括第二“电路”。如本文所用，“和/或”是指列表中由“和/或”连接的任何一个或多个项目。作为示例，“x和/或y”表示三元素集{(x)，(y)，(x，y)}中的任何元素。换句话说，“x和/或y”是指“x和y之一或两者”。作为另一个示例，“x，y和/或z”表示七元素集{(x)，(y)，(z)，(x，y)，(x，z)，(y，z)，(x，y，z)}。换句话说，“x，y和/或z”是指“x，y和z中的一个或多个”。如本文所使用的，术语“示例性”是指用作非限制性示例，实例或说明。如本文所使用的，术语“例如”和“例如”引出一个或多个非限制性示例，实例或插图的列表。如本文所利用的，只要电路包含执行该功能所需的必要硬件和代码(如有必要)，该电路就“可操作”以执行功能，而不管该功能的性能是否被禁用(例如，通过用户可配置的设置，出厂调整等)。

Claims (20)

1.一种用于分布式存储***中的元数据日志的***，包括：
存储设备；以及
多个计算设备，经由网络彼此通信地耦接并通信地耦接到所述存储设备，其中，所述多个计算设备的每一个用于压缩一个或多个数据块，将元数据日志添加到压缩的一个或多个数据块中的每一个的开头并将所述元数据日志和压缩的一个或多个数据块同时写入所述存储设备，并且其中，所述元数据日志包括与所述一个或多个数据块对所述存储设备所做的更改相关联的数据，其中，所述元数据日志被链接以创建跟踪更高级别的操作并在发生故障时确保所述更高级别的操作的持久性的元数据日志的链表。
2.根据权利要求1所述的***，其中，所述多个计算设备中的每一个包括虚拟文件***(VFS)节点。
3.根据权利要求2所述的***，其中，元数据注册表保存在所述VFS节点中的VFS后端上。
4.根据权利要求3所述的***，其中，所述VFS后端管理所述元数据注册表，以存储由所述一个或多个数据块对所述存储设备进行的所述更改。
5.根据权利要求4所述的***，其中，所述元数据注册表包括所述VFS后端上的易失性存储器。
6.根据权利要求1所述的***，其中，多个所述存储设备包括闪存。
7.根据权利要求1所述的***，其中，所述元数据日志与压缩的所述一个或多个数据块同时被写入所述存储设备，并且其中，所述元数据日志包括指向所述存储设备中的一个或多个先前的元数据日志的一个或多个返回指针。
8.根据权利要求7所述的***，其中，在电源故障的情况下，将所述元数据日志和所述一个或多个先前的元数据日志与保存在所述存储设备中的数据进行比较，以确定保存的数据是否完整。
9.根据权利要求8所述的***，其中，如果所述保存的数据是完整的，则丢弃所述一个或多个先前的元数据日志。
10.根据权利要求8所述的***，其中，如果所述保存的数据不是完整的，则重播所述元数据日志和所述一个或多个先前的元数据日志以确定新的元数据注册表状态。
11.一种用于分布式存储***中的元数据日志的方法，包括：
通过计算设备压缩一个或多个数据块；
将元数据日志附加到压缩的所述一个或多个数据块中的每个的开头；以及
同时将所述元数据日志和压缩的所述一个或多个数据块写入存储设备，其中，所述元数据日志包括与由所述一个或多个数据块对所述存储设备所做的更改相关联的数据，
其中，所述元数据日志被链接以创建跟踪更高级别的操作并在发生故障时确保所述更高级别的操作的持久性的元数据日志的链表。
12.根据权利要求11所述的方法，其中，多个所述计算设备中的每一个包括虚拟文件***(VFS)节点。
13.根据权利要求12所述的方法，其中，所述方法包括：在所述VFS节点中的VFS后端上保存与所述元数据日志有关的元数据注册表。
14.根据权利要求13所述的方法，其中，所述方法包括经由所述VFS后端管理所述元数据注册表以存储由所述一个或多个数据块对所述存储设备进行的更改。
15.根据权利要求14所述的方法，其中，所述元数据注册表包括所述VFS后端上的易失性存储器。
16.根据权利要求11所述的方法，其中，多个所述存储设备包括闪存。
17.根据权利要求11所述的方法，其中，所述元数据日志包括指向所述存储设备中的一个或多个先前的元数据日志的一个或多个返回指针。
18.根据权利要求17所述的方法，其中，所述方法包括：在电源故障的情况下，将所述元数据日志和所述一个或多个先前的元数据日志与保存在所述存储设备上的数据进行比较，以确定保存的数据是否完整。
19.根据权利要求18所述的方法，其中，所述方法包括：如果所述保存的数据是完整的，则丢弃所述一个或多个先前的元数据日志。
20.根据权利要求18所述的方法，其中，所述方法包括：如果所述保存的数据不是完整的，则重播所述元数据日志和所述一个或多个先前的元数据日志，以确定新的元数据注册表状态。
CN201880086394.3A 2017-11-13 2018-10-05 分布式存储***中的元数据日志 Active CN111587428B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311813920.0A CN117785636A (zh) 2017-11-13 2018-10-05 分布式存储***中的元数据日志

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201762585063P 2017-11-13 2017-11-13
US62/585,063 2017-11-13
US16/121,496 US11301433B2 (en) 2017-11-13 2018-09-04 Metadata journal in a distributed storage system
US16/121,496 2018-09-04
PCT/IB2018/001283 WO2019092500A1 (en) 2017-11-13 2018-10-05 Metadata journal in a distributed storage system

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202311813920.0A Division CN117785636A (zh) 2017-11-13 2018-10-05 分布式存储***中的元数据日志

Publications (2)

Publication Number Publication Date
CN111587428A CN111587428A (zh) 2020-08-25
CN111587428B true CN111587428B (zh) 2023-12-19

Family

ID=66433278

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201880086394.3A Active CN111587428B (zh) 2017-11-13 2018-10-05 分布式存储***中的元数据日志
CN202311813920.0A Pending CN117785636A (zh) 2017-11-13 2018-10-05 分布式存储***中的元数据日志

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN202311813920.0A Pending CN117785636A (zh) 2017-11-13 2018-10-05 分布式存储***中的元数据日志

Country Status (4)

Country Link
US (2) US11301433B2 (zh)
EP (1) EP3710952A4 (zh)
CN (2) CN111587428B (zh)
WO (1) WO2019092500A1 (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9971397B2 (en) 2014-10-08 2018-05-15 Apple Inc. Methods and apparatus for managing power with an inter-processor communication link between independently operable processors
US10489085B2 (en) * 2018-02-28 2019-11-26 Micron Technology, Inc. Latency-based scheduling of command processing in data storage devices
US11792307B2 (en) 2018-03-28 2023-10-17 Apple Inc. Methods and apparatus for single entity buffer pool management
US11042661B2 (en) * 2018-06-08 2021-06-22 Weka.IO Ltd. Encryption for a distributed filesystem
US11829303B2 (en) 2019-09-26 2023-11-28 Apple Inc. Methods and apparatus for device driver operation in non-kernel space
US11558348B2 (en) 2019-09-26 2023-01-17 Apple Inc. Methods and apparatus for emerging use case support in user space networking
US11606302B2 (en) 2020-06-12 2023-03-14 Apple Inc. Methods and apparatus for flow-based batching and processing
US11775359B2 (en) 2020-09-11 2023-10-03 Apple Inc. Methods and apparatuses for cross-layer processing
US11954540B2 (en) 2020-09-14 2024-04-09 Apple Inc. Methods and apparatus for thread-level execution in non-kernel space
US11799986B2 (en) 2020-09-22 2023-10-24 Apple Inc. Methods and apparatus for thread level execution in non-kernel space
US20220391359A1 (en) * 2021-06-07 2022-12-08 Netapp, Inc. Distributed File System that Provides Scalability and Resiliency
US11882051B2 (en) 2021-07-26 2024-01-23 Apple Inc. Systems and methods for managing transmission control protocol (TCP) acknowledgements
US11876719B2 (en) 2021-07-26 2024-01-16 Apple Inc. Systems and methods for managing transmission control protocol (TCP) acknowledgements
EP4246330A1 (en) * 2022-03-15 2023-09-20 Samsung Electronics Co., Ltd. Storage device and operating method thereof

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1425986A (zh) * 2003-01-17 2003-06-25 清华大学 自动压缩/解压缩文件***及其压缩算法
US7519628B1 (en) * 2004-06-01 2009-04-14 Network Appliance, Inc. Technique for accelerating log replay with partial cache flush
CN101681312A (zh) * 2008-02-29 2010-03-24 株式会社东芝 存储器***
US7739677B1 (en) * 2005-05-27 2010-06-15 Symantec Operating Corporation System and method to prevent data corruption due to split brain in shared data clusters
CN103744961A (zh) * 2014-01-06 2014-04-23 清华大学 用可重构的文件***目录树提高非易失性存储寿命的方法
US9020987B1 (en) * 2011-06-29 2015-04-28 Emc Corporation Managing updating of metadata of file systems
US9047189B1 (en) * 2013-05-28 2015-06-02 Amazon Technologies, Inc. Self-describing data blocks of a minimum atomic write size for a data store
US9223843B1 (en) * 2013-12-02 2015-12-29 Amazon Technologies, Inc. Optimized log storage for asynchronous log updates
CN105335098A (zh) * 2015-09-25 2016-02-17 华中科技大学 一种基于存储级内存的日志文件***性能提高方法
CN106354434A (zh) * 2016-08-31 2017-01-25 中国人民大学 日志数据的存储方法及***

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6487636B1 (en) 2000-04-24 2002-11-26 Hewlett-Packard Co. Method and apparatus for mapping data in a heterogeneous disk array storage system
US7024427B2 (en) 2001-12-19 2006-04-04 Emc Corporation Virtual file system
AU2003265335A1 (en) 2002-07-30 2004-02-16 Deepfile Corporation Method and apparatus for managing file systems and file-based data storage
US7877511B1 (en) 2003-01-13 2011-01-25 F5 Networks, Inc. Method and apparatus for adaptive services networking
US7698401B2 (en) * 2004-06-01 2010-04-13 Inmage Systems, Inc Secondary data storage and recovery system
US8949395B2 (en) * 2004-06-01 2015-02-03 Inmage Systems, Inc. Systems and methods of event driven recovery management
US20050289152A1 (en) 2004-06-10 2005-12-29 Earl William J Method and apparatus for implementing a file system
US7681072B1 (en) 2004-08-13 2010-03-16 Panasas, Inc. Systems and methods for facilitating file reconstruction and restoration in data storage systems where a RAID-X format is implemented at a file level within a plurality of storage devices
WO2006134691A1 (ja) 2005-06-17 2006-12-21 Nec Corporation 情報処理装置、復旧装置、プログラム及び復旧方法
US7447839B2 (en) 2005-09-13 2008-11-04 Yahoo! Inc. System for a distributed column chunk data store
US8347010B1 (en) 2005-12-02 2013-01-01 Branislav Radovanovic Scalable data storage architecture and methods of eliminating I/O traffic bottlenecks
US7921132B2 (en) 2005-12-19 2011-04-05 Yahoo! Inc. System for query processing of column chunks in a distributed column chunk data store
US7860865B2 (en) 2005-12-19 2010-12-28 Yahoo! Inc. System of a hierarchy of servers for query processing of column chunks in a distributed column chunk data store
EP2024809A2 (en) 2006-05-03 2009-02-18 Data Robotics Incorporated Filesystem-aware block storage system, apparatus, and method
US7793146B1 (en) 2007-08-07 2010-09-07 Panasas, Inc. Methods for storing data in a data storage system where a RAID-X format or formats are implemented at a file level
US8645749B2 (en) 2009-02-04 2014-02-04 Micron Technology, Inc. Systems and methods for storing and recovering controller data in non-volatile memory devices
US8458287B2 (en) 2009-07-31 2013-06-04 Microsoft Corporation Erasure coded storage aggregation in data centers
US8370672B2 (en) 2010-02-26 2013-02-05 Microsoft Corporation Reducing power consumption of distributed storage systems
US9251087B2 (en) 2011-02-11 2016-02-02 SanDisk Technologies, Inc. Apparatus, system, and method for virtual memory management
US9348883B2 (en) * 2011-06-01 2016-05-24 Clustrix, Inc. Systems and methods for replication replay in a relational database
US8898376B2 (en) 2012-06-04 2014-11-25 Fusion-Io, Inc. Apparatus, system, and method for grouping data stored on an array of solid-state storage elements
US20140244897A1 (en) 2013-02-26 2014-08-28 Seagate Technology Llc Metadata Update Management In a Multi-Tiered Memory
US9489148B2 (en) 2013-03-13 2016-11-08 Seagate Technology Llc Selecting between non-volatile memory units having different minimum addressable data unit sizes
US9483431B2 (en) 2013-04-17 2016-11-01 Apeiron Data Systems Method and apparatus for accessing multiple storage devices from multiple hosts without use of remote direct memory access (RDMA)
US10402374B2 (en) * 2013-08-26 2019-09-03 Vmware, Inc. Log-structured storage device format
US9552242B1 (en) * 2013-09-25 2017-01-24 Amazon Technologies, Inc. Log-structured distributed storage using a single log sequence number space
JP2017512350A (ja) 2014-03-08 2017-05-18 ディアマンティ インコーポレイテッド 集中型ネットワーキング及びストレージのための方法及びシステム
IN2014DE00743A (zh) * 2014-03-13 2015-09-18 Netapp Inc
US9087012B1 (en) 2014-06-04 2015-07-21 Pure Storage, Inc. Disaster recovery at high reliability in a storage cluster
US9887878B2 (en) * 2014-06-06 2018-02-06 Microsoft Technology Licensing, Llc Dynamic scheduling of network updates
US9582363B2 (en) 2014-06-09 2017-02-28 International Business Machines Corporation Failure domain based storage system data stripe layout
US9384142B2 (en) * 2014-09-16 2016-07-05 International Business Machines Corporation Efficient and consistent para-virtual I/O system
US9921910B2 (en) 2015-02-19 2018-03-20 Netapp, Inc. Virtual chunk service based data recovery in a distributed data storage system
US9448887B1 (en) 2015-08-22 2016-09-20 Weka.IO Ltd. Distributed erasure coded virtual file system
US9934110B2 (en) * 2016-05-03 2018-04-03 Netapp, Inc. Methods for detecting out-of-order sequencing during journal recovery and devices thereof
US9940261B2 (en) * 2016-05-05 2018-04-10 Western Digital Technology, Inc. Zoning of logical to physical data address translation tables with parallelized log list replay
US10296250B2 (en) * 2016-06-08 2019-05-21 Intel Corporation Method and apparatus for improving performance of sequential logging in a storage device

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1425986A (zh) * 2003-01-17 2003-06-25 清华大学 自动压缩/解压缩文件***及其压缩算法
US7519628B1 (en) * 2004-06-01 2009-04-14 Network Appliance, Inc. Technique for accelerating log replay with partial cache flush
US7739677B1 (en) * 2005-05-27 2010-06-15 Symantec Operating Corporation System and method to prevent data corruption due to split brain in shared data clusters
CN101681312A (zh) * 2008-02-29 2010-03-24 株式会社东芝 存储器***
US9020987B1 (en) * 2011-06-29 2015-04-28 Emc Corporation Managing updating of metadata of file systems
US9047189B1 (en) * 2013-05-28 2015-06-02 Amazon Technologies, Inc. Self-describing data blocks of a minimum atomic write size for a data store
US9223843B1 (en) * 2013-12-02 2015-12-29 Amazon Technologies, Inc. Optimized log storage for asynchronous log updates
CN103744961A (zh) * 2014-01-06 2014-04-23 清华大学 用可重构的文件***目录树提高非易失性存储寿命的方法
CN105335098A (zh) * 2015-09-25 2016-02-17 华中科技大学 一种基于存储级内存的日志文件***性能提高方法
CN106354434A (zh) * 2016-08-31 2017-01-25 中国人民大学 日志数据的存储方法及***

Also Published As

Publication number Publication date
CN117785636A (zh) 2024-03-29
EP3710952A4 (en) 2021-08-11
US20190147069A1 (en) 2019-05-16
CN111587428A (zh) 2020-08-25
US20220188276A1 (en) 2022-06-16
WO2019092500A1 (en) 2019-05-16
US11301433B2 (en) 2022-04-12
EP3710952A1 (en) 2020-09-23

Similar Documents

Publication Publication Date Title
CN111587428B (zh) 分布式存储***中的元数据日志
CN111587418B (zh) 分布式存储***的目录结构
CN111587423B (zh) 分布式存储***的分层数据策略
CN111587425B (zh) 分布式存储***中的文件操作
CN111587421B (zh) 分布式存储***电源故障阻抗的方法和***
CN112262407A (zh) 分布式文件***中基于gpu的服务器
CN111587420A (zh) 分布式存储***快速故障恢复的方法和***
WO2020016649A2 (en) Pushing a point in time to a backend object storage for a distributed storage system
JP2023099186A (ja) 複数の故障ドメインに及ぶストレージシステム
CN111066009B (zh) 具有写入均衡的闪存寄存器
CN113039514A (zh) 分布式文件***中的数据迁移
CN112292661A (zh) 扩展分布式存储***
CN112005225A (zh) 具有盘上哈希的闪存注册表
CN112513828B (zh) 以分布式方式实现文件的一致性和页面高速缓存支持
CN112513828A (zh) 以分布式方式实现文件的一致性和页面高速缓存支持

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant