[go: up one dir, main page]

CN103119590B - 在分布式数据库中管理完整性的方法和系统 - Google Patents

在分布式数据库中管理完整性的方法和系统 Download PDF

Info

Publication number
CN103119590B
CN103119590B CN201180044819.2A CN201180044819A CN103119590B CN 103119590 B CN103119590 B CN 103119590B CN 201180044819 A CN201180044819 A CN 201180044819A CN 103119590 B CN103119590 B CN 103119590B
Authority
CN
China
Prior art keywords
region
copy
region copy
backup
zone
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
CN201180044819.2A
Other languages
English (en)
Other versions
CN103119590A (zh
Inventor
阿兰·G·布赖恩特
凯文·S·格里马迪
特雷克·帕默尔
戴维·平克尼
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.)
Hitachi Vantara LLC
Original Assignee
Hitachi Data System Corp
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 Hitachi Data System Corp filed Critical Hitachi Data System Corp
Publication of CN103119590A publication Critical patent/CN103119590A/zh
Application granted granted Critical
Publication of CN103119590B publication Critical patent/CN103119590B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • 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/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
    • 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/0629—Configuration or reconfiguration of storage systems
    • G06F3/0635—Configuration or reconfiguration of storage systems by changing the path, e.g. traffic rerouting, path reconfiguration
    • 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/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0647—Migration mechanisms
    • 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]
    • 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/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0689—Disk arrays, e.g. RAID, JBOD

Landscapes

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

Abstract

通过本文描述的增量式刷新技术减少了群组恢复时间。本技术的目的在于挽救部分冗余分布式数据库的损失（例如，在故障期间），这是在损失期间通过仅对发生在该部分数据库的更新执行增量式刷新来实现。

Description

在分布式数据库中管理完整性的方法和系统
相关申请的交叉引用
本申请与以下申请相关：
在2010年9月24日递交的、名称为“System and method for enhancing theavailability of a distributed object storage system during a partial databaseoutage”的序列号为No.12/889,762的申请。
技术领域
本发明总体上涉及分布式计算机网络中的高有效性、可靠性和永久性数据存储的技术。
背景技术
存在“固定内容”的存档存储设备以高有效性、可靠性和永久性的方式替换或补充传统的磁带和光学存储解决方案的需求。术语“固定内容”一般是指期望为不会因为参考或其他目的改变而保持的任意类型的数字信息。这样的固定内容的例子包括，例如电子邮件、文档、诊断图像、检查图像、录音、电影和视频等。传统的独立节点冗余阵列（RAIN）存储方法作为创建用于存储这些固定内容信息资产的大型在线存档的选择的架构呈现。根据需要允许节点加入或离开群集，RAIN架构将存储群组与一个或多个节点的故障隔离。通过复制多个节点上的数据，RAIN-型存档可以自动为节点故障或移除进行补偿。一般地，RAIN系统很大程度上表现为在封闭系统内由相同元件设计的硬件设施。
已知的现有技术中的存档存储系统一般存储每个文件的元数据及其内容。元数据是用于描述该数据的数据元素。一般，元数据描述存储在系统中的实际数据的内容、质量、条件和其他特征。在分布式存储设备情景中，文件的元数据包括，例如文件名称、文件块存储地点、文件创建日期、保留数据等。为实现文件的可靠性和有效性的存储系统，可靠性文件存储设备是必要的，并且元数据的完整也是系统的重要部分。然而，在现有技术中，在潜在的不可靠节点的分布式系统之间分布元数据是不可能的。本发明解决本领域中的这种需求。
在共有的专利号为No.7,155,466、No.7,657,581和No.7,657,586的美国专利中描述了一种改进的存档存储系统。该系统提供了一种跨分布式节点集的分布式对象存储。根据美国专利No.7,657,581，对称节点的存档存储群组包括组织和提供访问元数据的“元数据管理”系统，优选以元数据对象的形式。每个元数据对象具有唯一名称，并且元数据对象被组织成区域。在一个实施例中，通过哈希一个或多个对象的属性（例如，对象名称）并获取结果哈希值的给定数量的比特来选择区域。比特的数量可以由配置参数来控制。在该方案中，每个区域冗余存储，并且区域包括一组区域副本。特别的，存在区域的一个授权副本以及零个或多个备份副本。如所描述的，副本的数量可以由配置参数来控制，有时候副本的数量指的是元数据保护层（“MDPL”）的数量。从而，例如，在该方案的一个实施例中，区域包括授权区域副本及其MDPL-1个备份副本。区域副本在群组节点之间的分布可以平衡每个节点上的授权区域副本的数量和每个节点上的区域副本的总数量。
以上描述的元数据管理系统的另一方面是指识别为每个区域的每个副本负责的节点的区域“映射”。区域映射可以通过包括元数据管理系统的过程访问。区域映射中的区域表示一组哈希值，并且该组中的所有区域覆盖所有可能的哈希值。通过号码来识别区域，该号码来源于获取的哈希值的比特的数量。使用名称空间分区方案来明确区域映射中的区域并控制给定区域的所有权。该分区方案在数据库中实现。在该方案中，区域副本具有三个状态之一：“授权的”、“备份的”和“不完全的”。如果区域副本是授权的，则将对该区域的所有请求发送到该副本，并且每个区域存在一个授权副本。如果区域副本是备份（或者不完全的），则副本接收（来自授权区域管理过程的）更新请求。如果正在加载元数据却还未同步副本（一般地是与相应的授权区域副本同步），则区域副本是不完全的。在同步完成之前，不完全区域副本是无法升级至另一状态的，当同步完成时，副本变成备份副本。
以上描述的元数据管理方案的另一方面是备份区域副本与授权区域副本保持同步。当处理更新请求时，通过实现授权区域副本与其MDPL-1个备份副本之间的协议或“合同”来保证同步。例如，在本地提交更新之后，授权区域管理过程将更新请求发布至其MDPL-1个备份副本（一般位于其他节点）的每一个。在通常过程中，当接收到更新请求时，与给定备份副本相关的区域管理过程发布或试图发布应答。在发出更新已经成功的指示之前，授权区域管理过程等待来自所有MDPL-1个备份副本的应答。这里有几种方式，然而其中该更新处理会失败，例如，授权区域管理者（在等待应答时）可能遇到表示备份管理过程已经不运行或者备份管理过程即使它已经发布应答也无法在本地处理更新请求的例外，或者备份区域管理过程在发布应答时遇到表示授权区域管理处理已经不运行的例外等。如果备份区域管理者无法处理更新，则其将自己从服务移除。如果备份区域管理过程或授权管理过程不运行，则发布新的区域映射。通过以这种方式来确保同步，每个备份副本是授权副本的“热备份”。如果授权区域副本丢失或由于负载平衡需求指示降级当前授权区域副本（并且提升某个备份区域副本），则将这种备份副本升级至授权副本是适当的。
上述描述的方案的优点在于，即使在同时多个节点故障时也能确保元数据的高有效性。当有节点故障时，一个或多个区域会丢失，之后系统需要恢复。恢复过程涉及为丢失的区域创建区域副本。该修复会消耗硬件和数据库资源从而会消耗性能。在大型群组中，修复会消耗大量时间，并且在这段时间中群组可能会低于MDPL。
发明内容
通过本文描述的增量式刷新技术减少了群组恢复时间。本技术的目的在于挽救部分冗余分布式数据库的损失（例如，在故障期间），这是在损失期间通过仅对发生在该部分数据库的更新执行增量式刷新来实现。
在一个实施例中，增量式刷新在联网的独立节点的冗余阵列中实现，其中，元数据对象存储在跨所述阵列分布的区域的集合中。区域映射用于识别所述区域的集合的位置，所述区域映射包括处于多个状态之一的所述区域的副本，所述状态包括以下之一：授权的（A）、备份的（B）和不完全的（I），并且其中不完全的区域副本存储对所述区域的待执行更新。根据本技术，状态还包括部分状态，所述部分状态从待执行更新来构成，在用于修复返回到所述区域的集合的区域的恢复期间使用所述待执行更新。具体地，修复包括以下步骤。首先，当确定（A）或（B）过期时，优选地，通过将（A）或（B）区域副本降级为（或者转换为）（P）区域来创建区域的部分（P）副本。之后，通过对于适当的不完全（I）区域应用已经排队的待执行更新使部分（P）区域为最新的。之后将（P）区域转换为备份（B）区域副本。通过在（P）区域转换时使它进行更新将它作为备份区域。在特定环境中，从所述区域的授权（A）副本通过同步所述部分（P）副本中的一部分来使得所述部分（P）副本成为最新的，以取消最后一次更新。
在替换实施例中，在包括处理器和保存计算机程序指令的计算机存储器的装置中执行以上描述的方法，以及当由处理器执行计算机程序指令时，执行上述的方法。
在另一替换实施例中，通过在与版本化文件系统结合使用的计算机可读介质中的计算机程序产品执行以上描述的方法，其中，版本化文件系统位于备份存储器。计算机程序产品存储计算机程序指令，当由处理器执行计算机程序指令时，执行上述的方法。
前面概述了本发明的一些较重要的特征。这些特征仅是示例性的。如将要描述的，通过以不同方式应用公开的本发明或通过修改本发明可以获得很多其他有益效果。
附图说明
为了更完整的理解本发明及其优点，以下结合附图参考具体实施方式，其中：
图1是其中实现本文的主题的固定内容存储存档的简化框图；
图2是独立节点冗余阵列的简化示意图，其中每个独立节点是对称的并且支持存档群组应用；
图3是在给定节点上执行存档群组应用的各种元件的高级示意图；
图4是在群组的给定节点上的元数据管理系统的元件示意图；
图5是示意性的区域映射；
图6示出了当群组在尺寸上增长时如何应用名称空间分区方案以促使区域映射的改变；
图7是根据本文描述的技术如何在（B）区域丢失之后的恢复期间创建（P）区域副本（P区域）并之后升级至（B）区域的例子示意图；以及
图8是根据本文描述的技术如何在（A）区域丢失之后的恢复期间创建（P）区域副本并之后升级至（B）区域的例子示意图。
具体实施方式
以下描述的技术优选地在可扩展的基于磁盘的存档存储管理系统中实现，优选地，是基于独立节点冗余阵列的系统架构。节点可能包括不同的硬件从而认为是“异构性”。一般，节点访问一个或多个存储磁盘，存储磁盘可以是实际的物理性存储磁盘，也可以是如存储区域网络（SAN）中的虚拟存储磁盘。在每个节点上支持的存档群组应用（以及，可选地执行应用的底层操作系统）可以是相同的或者是本质上相同的。在一个示例性实施例中，在每个节点上的软件栈（可以包括操作系统）是对称的，而硬件可能是异构的。使用如图1所示的系统，企业可以为很多不同种类的固定内容信息创建永久性存储设备，其中固定内容信息如文档、电子邮件、卫星图像、诊断图像、检查图像、录音、录像以及其他等。当然，这些类型仅是示例性的。通过在独立服务器或者所谓的存储节点上复制数据来实现高度可靠性。优选地，每个节点与其同伴之间是对称的。因而，由于任意给定的节点优选地可以执行所有功能，所以任一节点的故障在存档的可用性上具有很小的影响力。
如在共有的美国专利No.7,155,466、No.7,657,581和No.7,657,586描述，在每个节点上执行的分布式软件应用获取、维护、管理并恢复数字资产。在图2的示例性实施例中，各个存档的物理边界称为群组。一般，群组并不是单个设备，而是设备的集合。设备可以是相同类型的，也可以是不同类型的。一种类型的设备是计算机或者运行如Linux之类的操作系统的机器。运行在通用硬件上的基于Linux系统的群组提供存档机制（archive），该存档机制可以从几个存储节点服务器扩展到存储成千上万字节的数据的很多节点。该架构确保了存储容量可以始终与组织增长的存档需求保持同步。优选地，数据跨过群组进行复制，从而存档可以始终不受设备故障影响。如果磁盘或者节点故障，则群组对于群组中的其他节点自动故障以维持相同数据的复制。
优选地，示例性群组包括以下通常种类的元件：节点202、一对网络交换机204、配电单元（PDU）206、以及不中断电源（UPS）208。节点202典型地包括一个或多个日常服务器并包含CPU（例如，Intel×86、适当的随机存取存储器（RAM）、一个或多个硬盘驱动器（例如，标准IDE/SATA、SCSI等）、以及两个或多个网络接口（NIC）卡。典型的节点是具有2.4GHz芯片、512MBRAM以及六（6）个200GB硬盘驱动器的2U机架式单元。然而，这并不是限制。网络交换机204典型地包括能够在节点之间点对点通信的内部交换机205和允许额外的群组访问每个节点的外部交换机207。每个交换机需要足够的端口来操作群组中所有潜在的节点。以太网或GigE交换机可以被用于这个目的。使用PDU206为所有节点和交换机供电，并且使用UPS208保护所有节点和交换机。尽管不意为限制，但是典型的群组可以被连接到网络，诸如公共互联网、企业内部互联网、或其他广域或局域网。在示例性实施例中，在企业环境内实现群组。例如，通过在站点的集体域名命名系统（DNS）命名服务器中导航可以实现。例如，群组域因此可以是现存域的新的子域。在代表性的实现中，在集体DNS服务器中将子域委托给在群组自身中的命名服务器。终端用户使用任何传统的接口或访问工具访问群组。例如，这样可以在任何基于IP的协议（HTTP、FTP、NFS、AFS、SMB、网页服务等）上经由API，或通过任何其他已知或以后将研发的访问方法、服务、程序或工具来实现对群组的访问。
客户应用通过诸如标准UNIX文件协议，或HTTP API的一个或多个类型的外部网关访问群组。优选地通过虚拟文件系统来公开存档，该虚拟文件系统能够随意符合任何标准的面向UNIX文件协议的设施。这些包括NFS、FTP、SMB/CIFS等。
在一个实施例中，联网在一起（例如，经由以太网）成为群组的独立节点的冗余阵列(H-RAIN)上运行存档群组应用。给定节点的硬件可以是异构的。然而，为了得到最大可靠性，每个节点优选地运行分布式应用的实例300（可以是相同实例，或基本上相同的实例），其包括多个运行时组件，如图3中所示。这样，在硬件可以是异构的同时，节点上的软件栈（至少当它涉及本发明时）是相同的。这些软件组件包括网关协议层302、访问层304、文件处理和管理层306以及核心组件层308。为了说明的目的而提出“层”的名称，如同普通技术人员将领会的，可以用其他有意义的方法来体现功能的特征。可以集成或不集成一个或多个层（或其中的组件）。一些组件可以在层之间共享。
网关协议层302中的网关协议提供现存应用的透明。具体来说，网关提供诸如NFS310和SMB/CIFS312的本地文件服务，以及网页服务API来建立客户应用。还提供了HTTP支持314。访问层304提供对存档的访问。具体来说，根据本发明，固定内容文件系统（FCFS）316模拟本地文件系统来提供对存档对象的完全访问。FCFS给予了应用对存档内容的直接访问，如同他们是普通文件一样。优选地，存档的内容表现为其原始格式，同时将元数据公开为文件。FCFS316提供了传统观点的目录和访问权限和流程的文件级（file-level）调用，使得管理者能够以他们所熟悉的方式来规定固定内容数据。文件访问调用优选地被用户空间后台程序中断，并被路由给适当的核心元件（在层308）中，其对调用应用动态地产生适当的视图。FCFS调用优选地被存档策略约束，以辅助自主的存档管理。因此，在一个实施例中，管理者或应用不能删除保存期限（给定策略）仍然有效的存档对象。
访问层304优选地还包括网页用户界面（UI）318和SNMP网关320。网页用户界面318优选地实现为管理者控制台，提供对文件处理和管理层306中的管理引擎322的交互访问。管理控制台318优选地是密码保护的，提供存档的动态视图的基于网页的GUI，包括存档对象和单独节点。SNMP网关320向存储管理应用提供了对管理引擎322的轻易访问，这使得他们安全地监视和控制群组动作。管理引擎监视群组动作，包括系统和策略事件。文件处理和管理层306还包括请求管理器处理324。请求管理器324协调来自外部世界（经过访问层304）的全部请求，以及来自核心组件层308中的策略管理器326的内部请求。
除策略管理器326以外，核心组件还包括元数据管理器328和一个或多个存储管理器330的实例。元数据管理器328优选地被安装在每个节点上。共同地，元数据管理器在群组中作为分布式数据库，管理所有存档对象。在给定的节点上，元数据管理器328管理存档对象的子集，其中优选地，每个对象在外部文件（“EF”，为了存储而进入存档的数据）和存档数据物理所在的内部文件（每个都是“IF”）组之间映射。相同的元数据管理器328还管理从其他节点上复制的存档对象组。这样，每个外部文件的当前状态对于数个节点上的多个元数据管理器一直都是可用的。如果发生节点故障，则其他节点上的元数据管理器继续提供对先前由故障节点管理的数据的访问。存储管理器330提供了文件系统层，对于分布式应用中的所有其他组件都可用。优选地，它将数据对象存储在节点本地文件系统中。在给定节点中的每个驱动器优选地具有其自己的存储管理器。这使得节点可以移除单个驱动器并且优化吞吐量。存储管理器330还提供系统信息、数据的完整性检查，以及能够直接遍历本地结构。
如图3中还显示了，通过通信中间件层332和DNS管理器334，群组管理内部和外部通信。设施332是高效和可靠的基于消息的中间件层，其使能存档组件间的通信。在所示实施例中，层支持多点传送和点对点通信。DNS管理器334运行将所有节点连接至企业服务器的分布式命名服务。优选地，DNS管理器（单独或者与DNS服务相结合）在所有节点上加载平衡请求，以确保最大的群组吞吐量和可用性。
在所示实施例中，ArC应用实例在基本操作系统336上运行，诸如Red HatLinux9.0、Fedora Core 6等。通信中间件是任何传统的分布式通信机制。其他组件可以包括FUSE（USErspace中的文件系统），其可以被用于固定内容文件系统（FCFS）316。NFS网关310可以由标准nfsd Linux Kernel NFS驱动来实现。每个节点中的数据库可以被实现，例如PostgreSQL(本文中也被称为Postgres)，其是对象关系型数据库管理系统（ORDBMS）。节点可以包括网页服务器，诸如Jetty，其是Java HTTP服务器和小服务程序容器。当然，以上机制仅仅是说明性的。
给定节点上的存储管理器330负责管理物理存储设备。优选地，每个存储管理器实例负责单个根目录，在单个根目录中所有文件根据其放置算法被放置。可以在节点上同时运行多个存储管理器实例，并且每个通常代表系统中不同的物理磁盘。存储管理器提取在其余系统中使用的驱动器和接口技术。当存储管理器实例被请求以写入文件时，它生成其负责的用以表达的完全路径和文件名。在代表性的实施例中，存储在存储管理器上的每个对象被接收为原始数据而被存储，存储管理器随后在存储数据时将其自己的元数据添加到文件，以寻迹不同类型信息。外部文件（EF）存储随后由查询引擎（Query Engine）进行查询中将需要的信息。例如，元数据包括而不限于：EF长度（外部文件长度字节）、IF段尺寸（该片内部文件的尺寸）、EF保护表达（EF保护模式）、IF保护作用（该内部文件的表达）、EF创建时间戳（外部文件时间戳）、签名（写入（PUT）时内部文件的签名，其包括签名类型）、以及EF文件名（外部文件文件名）。与内部文件数据一起存储该附加元数据提供了额外程度的保护。具体来说，清除（scavenging）能够通过内部文件存储的元数据在数据库中创建外部文件记录。其他策略可以验证内部文件哈希相对于内部文件以确认内部文件保持完好。
如上描述，优选地，内部文件可以是数据“组块（chunk）”，代表在存档对象中的原始“文件”的一部分，并且他们可以被放置在不同节点上以存档条带（stripe）并保护块（block）。典型地，在元数据管理器中，对于每个存档对象提供一个外部文件条目，同时对于每个外部文件条目可以存在许多内部文件条目。典型地，内部文件布局取决于系统。在给定实现中，磁盘上的该数据的真实物理格式被存储为一系列可变长度记录。
请求管理器324负责运行通过与系统中的其他组件交互而执行存档动作所需的操作组。请求管理器支持不同类型的许多同时动作，能够重新执行任何失败的处理，并支持可能花费长时间来运行的处理。请求管理器还确保在存档中的读/写操作被适当操作并且确保所有请求在所有时间上处于已知状态。其还提供处理控制，用以配合节点上的多个读/写操作以满足给定的客户请求。此外，请求管理器为最近使用过的文件高速缓存元数据管理器条目，并为会话和数据块提供缓冲。
群组的主要职责是在磁盘上可靠地存储无限数量的文件。可以将给定节点想作是“不可靠的”，感觉像它是因为任何原因而不可到达或者其他方式不可用的。收集这种潜在的不可用节点有助于创建可靠的和高度可用的存储。通常，存在两种类型的信息需要被存储：文件本身和关于文件的元数据。
元数据管理
如美国专利No.7,657,581描述的，其公开内容以引用的方式结合于此，元数据管理系统负责组织给定元数据（诸如系统元数据）和提供对它的访问。该系统元数据包括位于存档中的文件的信息以及配置信息、在管理UI上显示的信息、公制（metrics）、不可修复的策略违规信息等。尽管不详细说明，但是其他类型的元数据（例如，与存档文件相关的用户元数据）也可以使用现在描述的元数据管理系统管理。
在代表性实施例中，元数据管理系统为元数据对象组提供持续性，这可以包括一个或多个以下对象类型（仅仅是说明性的）：
ExternalFile（外部文件）：存档用户所意识到的文件；
InternalFile（内部文件）：存储管理器存储的文件；典型地，在外部文件和内部文件之间可以是一对多关系。
ConfigObject（配置对象）：用于配制群组的名称/值对；
AdminLogEntry（管理日志条目）：将在管理者UI上显示的消息；
MetricsObject（公制对象）：时间戳密钥/值对，代表在时间点上一些存档的量度（例如，文件数量）；以及
PolicyState（策略状态）：一些策略的违规。
每个元数据对象可以具有唯一名称，优选地从不改变。根据上述专利中描述的技术，元数据对象被组织为区域（region）。区域包括授权区域副本和元数据保护等级（MDPL）数量（零或多的组）的备份区域副本。具有零个副本，元数据管理系统是可变比的，但是可能不是高度可用的。通过哈希一个或多个对象属性（例如，对象名称，诸如完全合格的路径名，或其部分）和提取给定数量比特的哈希值来选择区域。这些比特包括区域数量。选择的比特可以是低位比特、高位比特、中间位比特，或单个比特的任何组合。在代表性实施例中，给定的比特是哈希值的低位比特。对象的一个或多个属性可以使用任何传统的哈希函数而被哈希。这些包括而不限于，基于Java的哈希函数，诸如java.lang.string.hashCode等。优选地，包括区域数量比特数由配置参数控制，本文中指代为regionMapLevel（区域映射层）。例如，如果该配置参数被设定为6，则这样的结果是26=64个区域。当然，区域数量大是允许的，并且可以使用命名空间分区方案自动地调整区域数量。
如美国专利No.7,657,581描述的，每个区域可以被冗余存储。如以上所说明的，存在区域的一个授权副本，和零个或多个备份副本。备份副本的数量由元数据数据保护等级（或“MDPL”）配置参数控制，如同已经描述过的。优选地，区域副本被分布在群组的所有节点上，以便平衡每个节点授权区域副本的数量，并平衡每个节点全部区域副本的数量。
元数据管理系统将元数据对象存储在每个节点上运行的数据库中。该数据库被用来支持区域映射。示例性数据库使用PostgreSQL实现，其可以作为开源使用。优选地，对于每个区域副本存在概要（schema），并且在每个概要中，存在对于每种类型的元数据对象的表格。概要仅仅是命名空间，可以拥有表格、索引、过程和其他数据库对象。每个区域优选地具有其自己的概要。每个概要具有完整的表格组，每个元数据对象一个表格。这些表格中的一个表格的行对应于单个元数据对象。同时，Postgres是优选的数据库，任何方便的关系型数据库（例如，Oracle、IBM DB/2等）都可以被使用。
如图4中所示的，每个节点400具有一组过程或组件：一个或多个区域管理器（RGM）402a-n、元数据管理器（MM）404、至少一个元数据管理客户（MMC）406、以及具有一个或多个概要410a-n的数据库408。RGM、MM和MMC组件与虚拟机412（诸如Java虚拟机）一起运行。对于每个区域副本存在一个RGM。这样，对授权的区域副本具有RGM、对每个备份区域副本具有RGM、并且对于每个不完全的区域副本具有RGM。对于每个RGM402还具有由其管理该概要的数据库概要410。数据库还存储区域映射405。根据如上所述的专利公开，每个节点优选地具有区域映射的相同全局查看，以及由同步方案实施的要求。区域管理器RGM402负责在区域副本上操作（作为可能的情况，可能是授权的、备份的或不完全的），并且用以运行由元数据管理器客户406和其他区域管理器402提交的请求。通过任何方便的手段将请求提供给RGM，这种手段是诸如图3中所示的通信中间件或其他消息层。区域管理器提供这些请求运行的环境，例如通过提供对数据库的连接，该环境被配置为在由该RGM管理的概要上操作。每个区域管理器将它的数据存储在数据库408中。元数据管理器404是顶级组件，负责节点上的元数据管理。其负责生成和销毁区域管理器（RGM）并组织RGM所需的资源，例如群组配置信息和数据库连接池。（给定节点中的）给定元数据管理器用做领导者（MML）并且负责决定哪些元数据管理器（在节点集或子集上）负责哪些区域副本。领导者选择算法，诸如欺负（bully）算法或其变形，可以被用来选择元数据管理器领导者。优选地，尽管可能每个节点运行多个MM，但是每个节点具有单个元数据管理器。一旦区域拥有关系被命名空间分区方案建立（如以下将描述的），每个元数据管理器负责相应地调整其一个或多个区域管理器集。系统组件（例如，管理引擎、策略管理器等）与元数据管理器MM通过元数据管理器客户交互。MMC负责（使用区域映射）定位RGM来执行给定请求，以此将请求发布给所选RGM，并且以此如果所选的RGM不可用（例如，因为节点已经故障）则重新尝试请求。在后种情况中，当在节点上接收了新的区域映射时，重新尝试请求将会成功。
如以上所提到的，区域映射用于识别负责每个区域的每个副本的节点。虚拟机412（和其中的每个RGM、MM和MMC组件）具有对区域映射405的访问通路；区域映射的副本420在已经被复制到JVM之后，也显示在图4中。区域映射因此对于给定节点中的JVM和数据库都可用。在这种示例的实施例中，每个元数据对象具有属性（例如名称），其被哈希为0x0和0x3fffffff之间所包括的整数字段，也就是30比特值。这些值能够充分地表示带符号的32比特整数，而不会出现溢出问题（例如，当向范围的高端添加1时）。30比特允许高达近10亿个区域，甚至对于大型群组都是充足的。区域表示哈希值集，并且所有区域的集覆盖所有可能的哈希值。对于每个区域，具有不同比特的位置，并且不同比特的位置优选地是固定顺序。这样，每个区域以数字来识别，其优选地通过提取哈希值的RegionLevelMap（区域层映射）比特而得到。其中，配置参数被设置为6，这允许64个区域，所得出的哈希值是数字0x0至0x3f。
如以上说明的，根据上述专利，区域副本具有三（3）种状态之一：“授权的”（A）“备份的”（B）和“不完全的”（I）。如果区域副本是授权的，则对区域的所有请求都去向该副本，并且对每个区域具有一个授权的副本。如果区域副本是备份的，则副本（从授权的区域管理器过程）接收备份请求。如果加载了元数据，但是副本还没有同步（典型地，关于其他备份副本），则区域副本是不完全的。直到同步完成，在副本变为备份副本的时刻，不完全的区域副本还不适合升级到其他状态。每个区域具有一个授权的副本和给定数量（如同由MDPL配置参数设定的）的备份的或不完全的副本。
如美国专利No.7,657,581中描述的，通过在授权区域副本和其MDPL备份副本之间实施协议（或“合同”），备份区域副本与授权区域副本被保持同步。现在介绍该协议。
如以上描述的，区域映射描述每个区域的每个副本的所有权。例如，图5示出了具有metadataMDPL=2的4个节点群组的区域映射。在该例子中，如示出的，对于区域0，节点1是授权的，并且节点2和3被指定为备份的，对于区域1，节点2是授权的，并且节点3和4被指定为备份的等。随着群组的扩展，可以使用名称空间分区方案来改变具体区域的控制（所有权）。允许动态扩展的一种方式是递增用于确定构成哈希值数量的比特数量的regionMapLevel配置参数。随着群组的扩展，区域映射的一个或多个分区执行“分裂（split）”操作。据此，分裂操作涉及使用更多的哈希值和重新分配元数据。例如，在6层上的映射，具有哈希值0x1000002a和0x1000006a的两个元数据对象。这些哈希值（十六进制0x2a、“2”的二进制为“0010”和“6”的二进制为“0110”）的最后6位是相同的；从而，两个对象落入区域0x2a中。如果之后映射层增加到7，则区域为0至0x7f，因此两个对象被迫进入不同区域，即，0x2a和0x6a。
当使用该方法时，要求在同一时间分裂每个区域。更好的技术是逐步分裂区域。为此，名称空间分区方案按照顺序分裂区域，从区域0开始到当前层的最后一个区域结束。通过使用一个更多的比特的哈希值来分裂区域。图6示出了该处理。在该例子中，假定映射层1有两个区域602（节点0）和604（节点1）。节点号码以二进制显示。当映射需要增长时，分区方案通过使用一个更多比特的哈希值来分裂区域0。这产生了三个区域606、608和610。新的比特为零的对象留在它们在区域606（节点00）中的位置，并且剩余的节点进入新的最后一个区域610（节点10）。由于分裂导致增加的比特用斜体字表示，即：00和10。需要注意的是，第一个和最后一个区域606和610使用两个比特，而中间（未分裂）区域仅使用一个；但是，编号方案仍然正确工作，即，当左到右看时为{0,1,2}。为了进一步扩展，分裂区域1以产生四个区域612（节点00）、614（节点01）、616（节点10）和618（节点11）。这完成了层2。当区域映射需要再次扩展时，方案分裂区域00至000（即，通过增加一个更多比特的哈希值）并在最后增加新的区域100（也通过增加一个更多比特的哈希值）。之后区域映射就具有示出的五个区域620、622、624、626和628。
区域号码与节点号码无需对应。一般地，区域号码与独立节点的阵列中的节点号码无关。
因此，根据一个实施例，通过将元数据对象分配给区域以及之后逐步分裂区域来实现对区域的控制。将区域副本（不管是授权的、备份的或不完全的）存储在每个节点上的数据库中。如所描述的，由授权GRM来执行元数据操作。然而，当节点故障时，一些区域副本会丢失。如所描述的，通过将区域的备份副本的一个升级为授权副本来恢复有效性，这通常可以在几秒内执行。在短暂的升级备份的间隔期间，对区域的由MMC提交的请求将会失败。该故障显示为由MMC导致的例外，在一段延迟之后，会进行重新尝试。等到重新尝试请求时，更新的映射应该已经形成，从而可以对MMC用户连续服务。如所描述的，该方法依赖保持同步的区域的（优选地，所有）副本。
以下提供元数据管理系统的附加的实现细节。
如以上提及的，当节点离开群组时、当节点加入群组时或当不完全区域副本分别完成加载时，MM领导者创建区域映射。在第一种情况中，当节点短暂地或永久地离开群组时，重新分配由该节点上的MM管理的区域。第二种情况涉及节点返回服务的时间或者节点第一次加入群组的时间；在这种情况下，将区域分配给它以减轻群组中其他MM的负担。创建在新节点上的所有区域都是不完全的。当这些区域完成加载数据时他们会被升级至备份。第三种情况在不完全区域完成加载其数据时发生。此时，区域变成备份。优选地，映射创建算法确保给定节点绝不包含任意区域的一个以上的副本，确保授权区域在群组中是平衡的，并且确保所有区域在群组中都是平衡的。因为由于所有RGM处理每个元数据的升级因此应该在群组间展开，所以后两种限制是必要的。由于授权RGM还处理检索请求，因此它们也应该均匀分布。
以下描述关于映射创建算法的其他细节。
当MM领导者需要创建新映射时，其做的第一件事是区域调查。这可以通过将请求发送至当前在群组中的每个节点上的MM的请求/响应消息模式来完成。优选地，请求/响应模式包括聚集步骤，在该步骤中结合所有响应以形成存档中的区域所存在的完整图片（picture）。优选地，对于每个区域副本，由区域调查提供的信息包括如下：拥有区域副本的节点、由（如果有的话）区域管理者处理的最后的升级、以及存储在区域数据库概要中的区域时间戳。区域时间戳用于识别在调查中删除的丢弃（obsolete）的区域。这保证了丢弃的区域不会出现在将要形成的映射中并且也保证了丢弃区域概要将会删除。在大多数情况下，丢弃区域的副本具有的映射版本号码低于当前区域副本的映射号码。但是，这也不是总是这种情况。例如，假定由于节点崩溃（crash）而创建的新映射。区域调查发现剩余的区域并形成新的映射。如果故障节点适时的重新启动以响应区域调查，则节点将如同一切正常地通告它的区域。然而，这些区域可能都会被废弃，这是由于在节点故障时错过升级。该问题的解决方案是检查区域调查包括的区域时间戳。每个区域副本通告代表处理最后升级的时间戳的它的区域时间戳。由于区域副本是保持同步的，因此有效的时间戳必须考虑映射版本的变化和初始映射。这用于识别丢弃的区域，以及故障区域是否具有当前或过期的映射版本号码。节点故障并迅速恢复服务，之后基于丢弃区域开始处理请求是不存在危险的。这样的原因是在重新启动时，节点是不存在区域映射的，并且直到接收到映射时RGM才存在。在创建RGM之前无法处理来自MMC的请求。因此，迅速重新启动的故障节点在获得新映射之前无法处理请求，并且新映射将会使节点丢弃它的旧区域。
在区域调查之后，如下生成初始区域映射。如果区域调查发现根本没有区域，则之后群组一定是第一次启动。此时，首先分配授权区域所有者。对于每次分配，算法选择最空闲的节点。该最空闲节点是具有最少区域副本的节点。基于拥有的授权副本的数量解决束缚。在分配授权区域所有者之后，分配备份区域所有者，努力保持授权和总的区域所有权的平衡。将新映射发送至所有的MM，之后MM创建由该映射描述的区域。
优选地，当群组启动时，通过顺序执行以下映射转变来实现映射变化：（1）如果区域不具有授权副本（由于节点故障），则升级备份；（2）如果区域具有大于MDPL的备份，则删除过量的备份；（3）如果区域具有小于MDPL的备份（由于节点故障或者由于升级到了授权），则创建新的不完全的区域副本；（4）重新平衡所有权；以及（5）重新平衡授权的所有权。步骤（4）涉及查找最忙的节点和将它的其中一个区域重新分配给所有权计数至少低两级的节点。（如果目标节点的所有权计数是低一级，则之后的重新分配不会对平衡工作量有利。）优选地，这可以通过创建新的不完全区域来实现。只要保持减少任意节点所拥有的区域的最大数量就可以持续该操作。步骤（5）涉及找到拥有最大数量的授权区域的节点并找到授权所有权计算至少低两级的备份。该步骤可以互换责任，例如，通过升级备份的和降级授权的来实现。只要保持减少任意节点所拥有的授权区域的最大数量就可以持续该操作。
当节点离开群组时，步骤（1）和（3）将填充由于节点离开而留下的区域映射中的任意间隙。之后如果必要的话，步骤（4）和（5）用于平衡工作量。
当节点加入群组时，步骤（1）-（3）不会改变任何事。相反地，步骤（4）会将一组不完全区域分配给新的节点。当不完全区域完成加载其数据时，它会通知MM领导者。映射将不完全区域升级为备份。之后步骤（5）负责将授权区域分配给新的节点。
当不完全区域完成其同步时，将该不完全区域转换成备份区域并通知给MM领导者。之后MM领导者发布包括多于至少一个区域的TPOF备份的新映射。步骤（2）删除超出的备份区域，这引起减少在最重负荷的MM上的负担。
当MM接收到新映射时，该MM需要将新映射与当前映射进行比较，并且对由MM管理的每个区域应用任意改变。可能的改变包括如下：删除区域、创建区域、将备份区域升级至授权的、将不完全区域升级至备份、以及将授权区域降级至备份。关于第一种类型的改变，负载平衡可以将区域副本的控制从一个节点移到另一个节点，这会导致副本的删除。此时，恢复网络和数据库资源，这包括用于存储区域数据中的概要的删除。第二种类型的改变是创建区域，一般发生在创建了授权和备份区域的新群组中。随后，仅创建不完全区域。区域创建涉及创建包括每个类型的元数据对象的表格的数据库概要。每个区域概要包括识别区域的角色（授权的、备份的或不完全的）的信息。第三种类型的改变是将备份升级至授权的，这需要区域角色的改变。其他改变类型，如他们的名称所暗示的，涉及区域角色从不完全的到备份或从授权的到备份的改变。
节点的每个元数据管理者控制整个群组的元数据的给定部分。因此，存储在给定节点的元数据包括（元数据）的分布式数据库的一部分，理论上数据库均匀地分布在群组中的所有节点（或者给定子集）之中。如所描述的，元数据管理者之间协作完成该功能。当新节点加入到群组中时，各个节点的责任是适应新的能力；这包括重新分配所有节点之间的元数据使得新成员承担相同的份额。相反地，当节点故障或者离开群组时，其他节点元数据管理者通过承担更大的份额来补偿减少的能力。优选地，为了防止数据丢失，元数据信息在多个节点之间复制，其中每个节点直接负责管理所有群组元数据的一定比例的元数据，并且将该数据复制到一定数量的其他节点上。
当生成新映射时，MM领导者开始将该映射分配到其他节点上并在所有节点都拥有它之前请求处理的暂停。当系统确认所有节点都拥有新映射时重新开始常规处理。
增量式刷新
在如上描述的系统中，将元数据分配到冗余地存储在系统的节点之间的区域中。元数据管理者具有包括这些区域的位置的区域映射，这能够使系统合适地路由请求。区域的数量确定粒度（granularity），在该粒度上在所有节点间划分元数据负荷。映射包括如下状态的区域副本：授权区域副本（A区域）、备份区域副本（B区域）以及处于从无或者从（A）或（B）区域（I区域）中恢复处理中的不完全区域副本。当（A）或（B）区域离开群组时，刷新映射。如果（B）区域已经离开群组，则创建（I）区域并通过复制来自（A）区域的所有元数据来构成（I）区域。当（A）区域离开群组时，升级相应的（B）区域到（A）并且之后创建（I）区域。当完成（I）区域副本时，将其升级至（B）区域。当所有区域都完成时，映射再次位于MDPL。如果在这处理期间丢失的区域恢复，则由于它的时间戳已经过期，一般会丢弃它。
根据上述公开，描述了基于将最后应用的改变存储到区域上的增强的恢复方案。其重要性是用于确定如何处理恢复的区域而不仅是当前的时间戳。
因而，当（A）或B区域立刻恢复（例如，由于平常的节点重启）时，在多数情况下，由于恰好地一个更新使得区域仅是不同的。优选地，根据本公开，为了检查该情况，最后的更新维持在每个区域中的区域时间戳表格中。在第一种情况中，存在恰好错失最后的更新的区域。这是在（B）区域接收到来自（A）区域的更新之前它离开的情况。在这种情况下，系统应用最后的更新使得最新的区域具有当前映射。在应用更新之后，其余的映射安装继续正常进行。第二种情况是存在不向系统的任何地方传送的应用于区域的更新。这是在A区域的更新适用于其（B）区域之前A区域离开的情况。在该情况中，认为该更新是无效的并且在区域恢复到映射之前从该区域将其移除。在这种情况下，系统创建以下描述的称为“在这区域同时进行更新的移除。
最后，存在恢复的区域副本根本不会与授权副本不同（例如，当恢复的节点是不可用时假定未对区域进行写操作）的情况。此时，通过比较上述提及的区域时间戳，元数据管理领导者可以确定恢复的区域是完全最新的并且从而可以立刻（作为备份（B）区域）恢复服务。区域时间戳比较是很灵活的从而可以解释一个或多个丢失的映射，这允许MM领导者错误地检查已经丢失一段时间的恢复的区域副本。
如本文所称的，应用于到特定的区域时间戳为止是最新的任意区域的部分或“P”状态不是具有当前映射的最新的，但是通过应用存储在另一个区域副本上的待执行的更新可以达到最新的。由于（如之前描述的）当系统检查到区域副本丢失时立即创建了（I）区域，并且由于这些（I）区域接收（A）区域接收到的每个更新（开始于丢失区域副本的映射的最后更新），因此（I）区域副本包括了使（P）区域副本达到最新的待执行的更新。将这些待执行的更新从（I）区域复制到（P）区域。
因此，根据本公开，（P）区域表示从已存在的（A）或（B）区域恢复的区域。每个（P）区域从存储在（I）区域（刚好包含使（P）区域副本达到最新的待执行的更新）中的待执行的改变中更新。如（B）或（I）区域一样，一创建（P）区域，（A）区域就视其为所有更新的备份区域。（P）区域（它一创建）就接收到备份请求并将它们存储在pending_update（待执行更新）表格中（或者其他任意合适的存储机制中）。当执行（P）区域更新时，将其转换为（B）区域。根据该转换，移除（I）区域。
在需要移除最后的更新时，如果应用的最后的更新未应用于其他区域副本上，则P区域首先取消应用的最后的更新。
图7示出了第一种示例情况。这里，（B）区域700已经丢失并且再不会接收到来自（A）区域702的更新（100,4）。此时，创建（I）区域704。通过复制来自（A）区域702的元数据来构成（I）区域（如所示）；（I）区域704也开始接收任意后续的对（A）区域702的更新。当（B）区域700恢复时，由于它（（B）区域）当前在包含它的上次的映射中，因此转换（B）区域为（P）区域706。（P）区域706从（I）区域704的待执行的更新表格中构成它错失的更新。如果该处理在（I）区域704为最新的之前执行，则将（P）区域706升级至（B）区域并丢弃（I）区域。
图8示出了第二种示例。这里，在（A）区域800应用更新（100,4）到（B）区域802之前故障。当区域（A）离开群组时，将（B）区域升级为新的（A）区域。创建新的（I）区域804以接收来自区域（A）的新的更新。当之前的（A）区域恢复时，转换其为（P）区域806。如上描述的，（P）区域806从区域（I）804的待执行更新表格中构成它错失的更新。（P）区域还取消无效的最后的更新。如果该处理在（I）区域为最新的之前执行，则将区域（P）806升级至（B）区域并丢弃（I）区域。
因此，图7示出了如何在（B）区域丢失之后的恢复期间创建（P）区域副本（P区域）并且之后升级至（B）区域的示例。图8示出了如何在（A）区域丢失之后的恢复期间创建（P）区域副本并且之后升级至（B）区域的示例。
当映射表示一个存在时创建（P）区域，并将已存在的区域转换为（P）区域。那时，区域也会在映射中显示其是否需要恢复到最后的更新以及从哪个（I）区域复制。
当群组需要移动区域或者根据已存的授权区域创建备份区域时，开始刷新任务（称为RefreshTask）。任务的重点是在源机器和目的机器之间的复制表格脚本的调用。脚本直接与基于SQL的数据库交互。RefreshTask实现（P）区域的功能。在任何其他操作之前，如果应用的最后的更新未在其他区域副本上应用，则（P）区域必须首先取消该应用的最后的更新。这是称为Undo Last Update（取消最后更新）的子任务。为此，RefreshTask从（A）区域中删除通过更新已经影响的数据库表格中任意行的本地副本及相等行的副本。在单个待执行的更新中可能存在多个更新，因此对于待执行更新中的所有的单独更新会重复该处理。对于每个更新，Task（任务）确定受影响的数据库表格和用于受影响的行的SQL（结构化查询语言）的where clause。之后该where clause首先用于删除用于该更新的受影响的表格中的任意本地行，并且之后（通过复制表格脚本）从（A）区域源复制所有的相似行。该语句将断言应用于元数据以选择需要通过Undo Last Update更改的元数据的子集。
之后，RefreshTask开始称为Copy Pending Updates（复制待执行的更新）的子任务。该任务从映射中指定的（I）区域中复制pending_update（待执行更新）的表格。该复制的目标是pending_update_copy（待执行更新复制）表格而不是pending_update（待执行更新）表格，以防止将发生的pending_update（待执行更新）和正常的备份请求之间的冲突。当完成复制时，RefreshTask将两个pending_update（待执行更新）表格合并。这对pending_update（待执行更新）进行了分类并且消除了任意复制。
之后，RefreshTask开始称为Apply Pending Updates（应用待执行的更新）的子任务。具体地，一旦pending_update（待执行更新）表格完全构成，则优选地，（P）区域以两种途径应用pending_update（待执行更新）。在该处理的最后，一般会更新区域的region_timestamp（区域时间戳）。
一旦应用待执行更新，RefreshTask就执行称为Convert to Backup Region（转换为备份区域）的子任务。这里，（P）区域将其自己转换为（B）区域。
由于（P）区域减少了刷新（I）区域的消耗，因此在(P)→(B)转换完成之前（I）区域会保持工作。为了完成这个，映射包括表示可使用的I区域的标记，当发生转换时，该标记将它们指定为丢弃。该转换由A区域来协调，因为A区域需要获知将备份更新停止发送至I区域。当发生(P)→(B)转换时，（A）区域具有新的监听器，通过对于通告的区域从本地映射移除任意可使用的（I）区域、释放时钟以及对这些区域的每一个发送移除它们自己的新消息，从而对该消息作出反应。
如果（P）或（I）区域RefreshTask（更新任务）的任意步骤失败，则无法再次使用该区域。
以上描述的增量式刷新提供了很多的优点。最主要的优点是防止（I）区域的时间长和消耗多的刷新。具体地，当区域调查（作为映射生成过程的一部分）识别具有少于MDPL个副本的区域时，创建（I）区域作为新的副本。该（I）区域开始RefreshTask（更新任务）以根据区域的（A）副本复制完整的概要。该RefreshTask（更新任务）具有几个开销大的步骤，包括复制数据和创建索引。通过使用本文中描述的技术，仅对在发生数据库的部分丢失时应用更新，因此该操作花费的时间和消耗的系统资源远远小于通过冗余来重建该部分所花费的时间和消耗的系统资源。减少修复的时间也减少了群组低于MDPL和最大性能的时间。
如本文描述的存档管理方案能够实现数字资产的获取、维护、管理和检索。该设计解决了很多需求：无限制量存储、高可靠性、自我管理、法规遵从、硬件独立性和易于与现有应用集成。
运行（例如）Linux商用硬件的群组提供了一种鲁棒的平台和虚拟的无限量的存档。该系统可以扩展，例如，从一些存储节点服务器扩展到存储成千上万个兆兆字节的数据的很多节点。该结构确保了存储性能可以始终与机构增长的存档需求保持一致。
该系统的设计是从不会丢失文件。通过跨群组复制数据可以使得存档总是免受设备故障的损害。如果磁盘或者节点故障，则群组自动将故障转移到群组中的其他节点上以维持相同数据的副本。
系统通过自动处理减少了存档存储的消耗。例如，当节点加入或离开群组存档时，通过跨成员节点重新分配文件使得系统自动调节群组负荷平衡并且优化性能。
系统方便了遵守客户定义的保留策略。
系统通过在开放平台上的配置消除了硬件的依赖性。随着商业平台和专属存储设备之间的价格差异的增长，IT购买者不再想要与高成本设施供应商的关系绑定。由于给定节点一般在商业硬件和优选地开源（例如，Linux）操作系统软件上运行，购买者优选地可以在很多硬件选择中购买最好的解决方案。
系统还提供工业标准接口，例如用于存储和检索文件的NFS、HTTP、FTP和CIFS。这确保了系统能够简单地获得到大多数标准内容管理系统、搜索系统、存储管理工具（如HSM和备份系统）和定制的存档应用的接口。
上述描述了由特定实施例执行的操作的具体顺序，需要理解的是，该指令是示范性的，替代实施例可以以不同顺序执行操作，组合特定操作、重叠特定操作等。说明书中对于特定实施例的参考表明了描述的实施例可以包括具体特征、结构或特性，然而每个实施例不必要都包括该具体特征、结构或特性。
在方法或处理的上下文中描述了公开的技术，本文的主题也涉及执行本文中的操作的装置。该装置可以为了需要具有特定结构，或者它可以包括通过存储在计算机中的计算机程序选择性的激活或重新配置的通用计算机。这种计算机程序可以存储在计算机可读存储介质中，例如但是不限于，包括光盘、CD-ROM和磁光盘、只读存储器（ROM）、随机存取存储器（RAM）、磁卡或光学卡的任意类型的磁盘、或者适用于存储电子指令的任意类型的介质，其中每个都与计算机系统总线耦合。
虽然分别描述了系统的给定元件，但是普通技术人员可以意识到一些功能可以与给定指令、程序序列、代码部分等组合或共享。
虽然在用于“固定内容”的存档的情景中描述了本发明，但是不限于此。本文描述的技术同样可以应用于允许对本文进行添加和替换类型的修改的存储系统。
已经描述了我们的发明，现在我们所要的权利要求如下。

Claims (8)

1.一种在联网的独立节点的冗余阵列中运行的装置，其中，元数据对象存储在跨所述阵列分布的区域的集合中，所述装置包括：
提供模块，用于提供区域映射，所述区域映射用于识别所述区域的集合的位置，其中所述区域映射包括处于多个状态之一的所述区域的副本，所述状态包括以下之一：授权的、备份的和不完全的，并且其中不完全的区域副本存储当所述授权的区域副本或所述备份的区域副本丢失时对所述区域的待执行更新；以及
使用模块，用于在将丢失的区域副本修复到所述区域的集合的恢复期间，使用所述待执行更新，
其中，所述使用模块将所述丢失的区域副本转换为部分的区域副本，使用所述不完全的区域副本中的待执行更新以更新所述部分的区域副本，并且将所述部分的区域副本转换为恢复的备份的区域副本；以及
所述状态进一步包括部分状态，所述部分状态为将所述部分的区域副本转换为恢复的备份的区域副本之前的所述部分的区域副本的状态。
2.根据权利要求1所述的装置，其中，所述使用模块从所述不完全的区域副本中的所述待执行更新对所述部分的区域副本进行更新。
3.根据权利要求1所述的装置，其中，所述使用模块从所述授权的区域副本通过同步所述部分的区域副本中的一部分来更新所述部分的区域副本以取消最后一次更新。
4.根据权利要求1所述的装置，其中，当所述部分的区域副本完成更新时，所述使用模块将所述部分的区域副本转换为所述备份的区域副本。
5.根据权利要求2所述的装置，还包括：移除模块，用于当将所述部分的区域副本转换为所述备份的区域副本时，移除所述不完全的区域副本。
6.一种在联网的独立节点的冗余阵列中运行的方法，其中，元数据对象存储在跨所述阵列分布的区域的集合中，所述方法包括：
提供区域映射，所述区域映射用于识别所述区域的集合的位置，其中所述区域映射包括处于多个状态之一的所述区域的副本，所述状态包括以下之一：授权的、备份的和不完全的，并且其中不完全的区域副本存储当所述授权的区域副本或所述备份的区域副本丢失时对所述区域的待执行更新；以及
在将丢失的区域副本修复到所述区域的集合的恢复期间，使用所述待执行更新，
其中，所述使用所述待执行更新包括：将所述丢失的区域副本转换为部分的区域副本，使用所述不完全的区域副本中的待执行更新以更新所述部分的区域副本，并且将所述部分的区域副本转换为恢复的备份的区域副本；以及
所述状态进一步包括部分状态，所述部分状态为将所述部分的区域副本转换为恢复的备份的区域副本之前的所述部分的区域副本的状态。
7.根据权利要求6所述的方法，其中，当所述部分的区域副本完成更新时，将所述部分的区域副本转换为所述备份的区域副本。
8.根据权利要求6所述的方法，其中，当将所述部分的区域副本转换为所述备份的区域副本时，移除所述不完全的区域副本。
CN201180044819.2A 2010-09-24 2011-09-13 在分布式数据库中管理完整性的方法和系统 Active CN103119590B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/889,744 US8600944B2 (en) 2010-09-24 2010-09-24 System and method for managing integrity in a distributed database
US12/889,744 2010-09-24
PCT/US2011/051313 WO2012039988A2 (en) 2010-09-24 2011-09-13 System and method for managing integrity in a distributed database

Publications (2)

Publication Number Publication Date
CN103119590A CN103119590A (zh) 2013-05-22
CN103119590B true CN103119590B (zh) 2016-08-17

Family

ID=45871660

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201180044819.2A Active CN103119590B (zh) 2010-09-24 2011-09-13 在分布式数据库中管理完整性的方法和系统

Country Status (5)

Country Link
US (1) US8600944B2 (zh)
EP (1) EP2619695B1 (zh)
JP (1) JP5918243B2 (zh)
CN (1) CN103119590B (zh)
WO (1) WO2012039988A2 (zh)

Families Citing this family (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2004286660B2 (en) * 2003-10-27 2011-06-16 Hitachi Vantara, LLC Policy-based management of a redundant array of independent nodes
US10198494B2 (en) 2006-05-18 2019-02-05 Allotz.Com Limited Control of distributed databases
US8849750B2 (en) 2010-10-13 2014-09-30 International Business Machines Corporation Synchronization for initialization of a remote mirror storage facility
US8484163B1 (en) * 2010-12-16 2013-07-09 Netapp, Inc. Cluster configuration backup and recovery
US10176184B2 (en) * 2012-01-17 2019-01-08 Oracle International Corporation System and method for supporting persistent store versioning and integrity in a distributed data grid
CA2911001C (en) * 2013-06-13 2019-11-19 Tsx Inc. Failover system and method
CN104754008B (zh) 2013-12-26 2019-03-08 伊姆西公司 网络存储节点、网络存储系统以及用于网络存储节点的装置和方法
US9213485B1 (en) 2014-06-04 2015-12-15 Pure Storage, Inc. Storage system architecture
US12137140B2 (en) 2014-06-04 2024-11-05 Pure Storage, Inc. Scale out storage platform having active failover
US10574754B1 (en) 2014-06-04 2020-02-25 Pure Storage, Inc. Multi-chassis array with multi-level load balancing
US11652884B2 (en) 2014-06-04 2023-05-16 Pure Storage, Inc. Customized hash algorithms
US8850108B1 (en) * 2014-06-04 2014-09-30 Pure Storage, Inc. Storage cluster
US9836234B2 (en) 2014-06-04 2017-12-05 Pure Storage, Inc. Storage cluster
US12182044B2 (en) 2014-07-03 2024-12-31 Pure Storage, Inc. Data storage in a zone drive
US10853311B1 (en) 2014-07-03 2020-12-01 Pure Storage, Inc. Administration through files in a storage system
US9483346B2 (en) 2014-08-07 2016-11-01 Pure Storage, Inc. Data rebuild on feedback from a queue in a non-volatile solid-state storage
US9141659B1 (en) * 2014-09-25 2015-09-22 State Farm Mutual Automobile Insurance Company Systems and methods for scrubbing confidential insurance account data
CN105518659B (zh) * 2014-10-28 2019-07-26 华为技术有限公司 分布式数据库的数据分区分配方法及装置
EP3015699B1 (de) 2014-10-31 2018-12-05 Winterthur Gas & Diesel AG Gaszuführsystem mit einem Kontrollsystem und Zylinder für eine Hubkolbenbrennkraftmaschine, Hubkolbenbrennkraftmaschine, sowie Verfahren zum Betreiben einer Hubkolbenbrennkraftmaschine
US10657004B1 (en) 2015-03-23 2020-05-19 Amazon Technologies, Inc. Single-tenant recovery with a multi-tenant archive
US9390154B1 (en) 2015-08-28 2016-07-12 Swirlds, Inc. Methods and apparatus for a distributed database within a network
US10747753B2 (en) 2015-08-28 2020-08-18 Swirlds, Inc. Methods and apparatus for a distributed database within a network
WO2017040313A1 (en) * 2015-08-28 2017-03-09 Swirlds, Inc. Methods and apparatus for a distributed database within a network
US9529923B1 (en) 2015-08-28 2016-12-27 Swirlds, Inc. Methods and apparatus for a distributed database within a network
US10762069B2 (en) 2015-09-30 2020-09-01 Pure Storage, Inc. Mechanism for a system where data and metadata are located closely together
US10261690B1 (en) 2016-05-03 2019-04-16 Pure Storage, Inc. Systems and methods for operating a storage system
US9646029B1 (en) 2016-06-02 2017-05-09 Swirlds, Inc. Methods and apparatus for a distributed database within a network
US11886334B2 (en) 2016-07-26 2024-01-30 Pure Storage, Inc. Optimizing spool and memory space management
CN106339278A (zh) * 2016-08-24 2017-01-18 浪潮电子信息产业股份有限公司 一种网络文件系统的数据备份及恢复方法
US11422719B2 (en) 2016-09-15 2022-08-23 Pure Storage, Inc. Distributed file deletion and truncation
US10613974B2 (en) 2016-10-04 2020-04-07 Pure Storage, Inc. Peer-to-peer non-volatile random-access memory
US9747039B1 (en) 2016-10-04 2017-08-29 Pure Storage, Inc. Reservations over multiple paths on NVMe over fabrics
SI3539026T1 (sl) 2016-11-10 2022-05-31 Swirlds, Inc. Postopki in naprave za porazdeljeno bazo podatkov, vključno z anonimnimi vnosi
US11550481B2 (en) 2016-12-19 2023-01-10 Pure Storage, Inc. Efficiently writing data in a zoned drive storage system
US11222006B2 (en) 2016-12-19 2022-01-11 Swirlds, Inc. Methods and apparatus for a distributed database that enables deletion of events
US11467913B1 (en) 2017-06-07 2022-10-11 Pure Storage, Inc. Snapshots with crash consistency in a storage system
KR102415097B1 (ko) 2017-07-11 2022-06-29 스월즈, 인크. 네트워크 내의 분산 데이터베이스를 효율적으로 구현하기 위한 방법들 및 장치
US10831935B2 (en) 2017-08-31 2020-11-10 Pure Storage, Inc. Encryption management with host-side data reduction
CN107562883B (zh) * 2017-09-04 2018-10-26 马上消费金融股份有限公司 一种数据同步的方法及系统
US10789211B1 (en) 2017-10-04 2020-09-29 Pure Storage, Inc. Feature-based deduplication
US10545687B1 (en) 2017-10-31 2020-01-28 Pure Storage, Inc. Data rebuild when changing erase block sizes during drive replacement
US12067274B2 (en) 2018-09-06 2024-08-20 Pure Storage, Inc. Writing segments and erase blocks based on ordering
SG11202002308RA (en) 2017-11-01 2020-04-29 Swirlds Inc Methods and apparatus for efficiently implementing a fast-copyable database
US10976948B1 (en) 2018-01-31 2021-04-13 Pure Storage, Inc. Cluster expansion mechanism
US11593496B2 (en) * 2018-04-23 2023-02-28 EMC IP Holding Company LLC Decentralized data protection system for multi-cloud computing environment
US11385792B2 (en) 2018-04-27 2022-07-12 Pure Storage, Inc. High availability controller pair transitioning
CN109088913B (zh) * 2018-06-29 2021-05-11 华为技术有限公司 请求数据的方法和负载均衡服务器
CN109063135B (zh) * 2018-08-03 2021-08-06 中国人民银行清算总中心 一种基于多活分布式架构的数据库复制方法及系统
US11500570B2 (en) 2018-09-06 2022-11-15 Pure Storage, Inc. Efficient relocation of data utilizing different programming modes
US11467920B2 (en) * 2018-10-25 2022-10-11 EMC IP Holding Company LLC Methods and systems to index file data of virtual machine (VM) image
AU2020279389A1 (en) 2019-05-22 2021-10-14 Hedera Hashgraph, Llc Methods and apparatus for implementing state proofs and ledger identifiers in a distributed database
US11487665B2 (en) 2019-06-05 2022-11-01 Pure Storage, Inc. Tiered caching of data in a storage system
US11416144B2 (en) 2019-12-12 2022-08-16 Pure Storage, Inc. Dynamic use of segment or zone power loss protection in a flash device
CN111581221B (zh) * 2020-03-18 2023-09-26 宁波送变电建设有限公司永耀科技分公司 一种分布式多站融合系统信息冗余存储与重构的方法
US11474986B2 (en) 2020-04-24 2022-10-18 Pure Storage, Inc. Utilizing machine learning to streamline telemetry processing of storage media
US12056365B2 (en) 2020-04-24 2024-08-06 Pure Storage, Inc. Resiliency for a storage system
CN112527767B (zh) * 2020-12-03 2024-05-10 许继集团有限公司 一种分布式数据库重启后多region表完整修复的方法及系统
US11487455B2 (en) 2020-12-17 2022-11-01 Pure Storage, Inc. Dynamic block allocation to optimize storage system performance
US12229437B2 (en) 2020-12-31 2025-02-18 Pure Storage, Inc. Dynamic buffer for storage system
US12093545B2 (en) 2020-12-31 2024-09-17 Pure Storage, Inc. Storage system with selectable write modes
US12067282B2 (en) 2020-12-31 2024-08-20 Pure Storage, Inc. Write path selection
US11507597B2 (en) 2021-03-31 2022-11-22 Pure Storage, Inc. Data replication to meet a recovery point objective
CN114504828B (zh) * 2022-02-08 2023-04-28 北京趣玩天橙科技有限公司 一种数据回滚实现内存一致性的方法及系统
US11880803B1 (en) * 2022-12-19 2024-01-23 Tbk Bank, Ssb System and method for data mapping and transformation

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101131675A (zh) * 2006-08-22 2008-02-27 国际商业机器公司 预防存储控制器的分区高速缓存中写饥饿的装置和方法
CN101183323A (zh) * 2007-12-10 2008-05-21 华中科技大学 一种基于指纹的数据备份系统
CN101546249A (zh) * 2008-03-26 2009-09-30 中兴通讯股份有限公司 磁盘阵列在线容量扩展方法
US8229893B2 (en) * 2010-02-01 2012-07-24 Hitachi Data Systems Corporation Metadata management for fixed content distributed data storage

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001290687A (ja) * 2000-04-04 2001-10-19 Nec Eng Ltd データ同期化制御方式
US7103796B1 (en) * 2002-09-03 2006-09-05 Veritas Operating Corporation Parallel data change tracking for maintaining mirrored data consistency
AU2004286660B2 (en) * 2003-10-27 2011-06-16 Hitachi Vantara, LLC Policy-based management of a redundant array of independent nodes
JP4313650B2 (ja) * 2003-11-07 2009-08-12 株式会社日立製作所 ファイルサーバ、冗長度回復方法、プログラム及び記録媒体
US7657581B2 (en) * 2004-07-29 2010-02-02 Archivas, Inc. Metadata management for fixed content distributed data storage
JP4575088B2 (ja) * 2004-08-31 2010-11-04 三菱電機株式会社 情報処理システム及び情報処理方法及び情報処理プログラム
US7549028B2 (en) * 2005-06-29 2009-06-16 Emc Corporation Backup and restore operations using a single snapshot driven by a server job request

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101131675A (zh) * 2006-08-22 2008-02-27 国际商业机器公司 预防存储控制器的分区高速缓存中写饥饿的装置和方法
CN101183323A (zh) * 2007-12-10 2008-05-21 华中科技大学 一种基于指纹的数据备份系统
CN101546249A (zh) * 2008-03-26 2009-09-30 中兴通讯股份有限公司 磁盘阵列在线容量扩展方法
US8229893B2 (en) * 2010-02-01 2012-07-24 Hitachi Data Systems Corporation Metadata management for fixed content distributed data storage

Also Published As

Publication number Publication date
US20120078847A1 (en) 2012-03-29
JP5918243B2 (ja) 2016-05-18
US8600944B2 (en) 2013-12-03
CN103119590A (zh) 2013-05-22
EP2619695A4 (en) 2017-07-19
EP2619695A2 (en) 2013-07-31
EP2619695B1 (en) 2018-07-18
JP2013544386A (ja) 2013-12-12
WO2012039988A2 (en) 2012-03-29
WO2012039988A3 (en) 2012-05-18

Similar Documents

Publication Publication Date Title
CN103119590B (zh) 在分布式数据库中管理完整性的方法和系统
US10489412B2 (en) Highly available search index with storage node addition and removal
US9898514B2 (en) System and method for aggregating query results in a fault-tolerant database management system
US9904605B2 (en) System and method for enhancing availability of a distributed object storage system during a partial database outage
CA2574735C (en) Metadata management for fixed content distributed data storage
US8935211B2 (en) Metadata management for fixed content distributed data storage
US9575975B2 (en) Cluster-wide unique ID for object access control lists
JP2013544386A5 (zh)
US8621270B2 (en) System and method for transparent recovery of damaged or unavailable objects in a replicated object storage system
US8812445B2 (en) System and method for managing scalability in a distributed database
AU2011265370B2 (en) Metadata management for fixed content distributed data storage

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
CP01 Change in the name or title of a patent holder

Address after: American California

Patentee after: Hitachi Data Management Co. Ltd.

Address before: American California

Patentee before: Hitachi Data Systems Corp.

CP01 Change in the name or title of a patent holder