CN102301368B - 用于保持数据完整性的设备 - Google Patents

Abstract

本发明提供了一种在软件组件的多个实例各自包括能够访问共享资源的多个进程的环境中保持数据完整性的设备。软件组件的每个实例是“活动的”实例(被允许更新数据)或“待命的”实例(不被允许更新数据)。在任何时间点，环境不包括多于一个活动实例，然而，可以存在多于一个待命实例。优选地，在活动实例完全故障(即，与当前活动实例的每个进程相关联的故障)的事件中，单个待命实例能够变为新的活动实例。

Description

用于保持数据完整性的设备

技术领域

本发明涉及用于保持数据完整性的设备。

背景技术

在“高度可用的”商业计算环境中，硬件和软件技术的组合被典型地组合以提供关键程序从硬件和软件故障的快速恢复，所述环境被设计用于消除单点故障。

例如，典型的高度可用的环境通常包括多个共享诸如磁盘驱动器的资源的松散连接的计算机。关键程序能够在一组计算机中的任何一台上运行。而且，硬件资源(例如，磁盘驱动器)在计算机之间共享。导致关键程序的不可用性的硬件或软件故障能够通过将其移至另一台计算机由此恢复它的可用性而得到补救。

典型的高度可用的环境在历史上是由被称为高度可用性(HA)软件的软件所管理的。典型地，HA软件通过监视组件并承担响应于故障而移动资源的责任，提供对硬件和软件组件的管理。

这样的高度可用的环境的示例(100)在图1A中示出，并包括具有第一HA软件(117)和高度可用的软件组件(110)的第一实例的第一计算机(105)，其中软件组件(110)可操作用来访问共享资源，例如，包括数据的共享磁盘(120)。

高度可用的环境(100)还包括具有可操作用来与第一HA软件(117)通信的第二HA软件(119)的第二计算机(115)。

在示例中，第一计算机(105)的第一实例(110)访问共享磁盘(120)。第一HA软件(117)具有共享磁盘(120)的“所有权”。

在第一计算机(105)的故障的事件中，第二HA软件(119)可操作用来检测故障(例如，响应于第二HA软件(119)不再能够与第一HA软件(117)通信)。

参考图1B，作为响应，第二HA软件(119)可操作用来终止第一实例(110)，将共享磁盘(120)的所有权移至其本身，并接着在第二计算机(115)上开启(start)软件组件(125)的第二实例。第二计算机(115)接着可操作用来从第一计算机(105)“接管”责任，并且在第二计算机(115)上运行的第二实例(125)能够访问共享磁盘(120)。

图1A和1B的环境(100)提供了软件组件的有保证的单个激活——也即，软件组件的两个实例不可能在不同的计算机上同时开启。如果软件组件的两个实例要在不同的计算机上同时开启，则这可能引起诸如共享磁盘(120)上的数据的损坏的错误。

虽然上述环境(100)为关键程序的高度可用性和关键程序的有保证的单个激活作了准备，但是特殊硬件(例如，必须被具体地配置以使其能够被多个计算机访问的共享磁盘(120))和软件(例如，HA软件)是需要的。

凭借更多的现代技术，可以在不需要特殊的硬件和/或软件的情况下获得高度可用性和有保证的单个激活。

这样的环境的代表(200)在图2中示出，其中环境(200)包括相同软件组件的两个实例。更具体地，环境(200)包括具有高度可用的软件组件(210)的第三实例的第三计算机(205)，其中第三实例(210)可操作用来访问共享资源，例如，包括数据的共享磁盘(220)。环境(200)还包括具有高度可用的软件组件(225)的第四实例的第四计算机(215)，其中第四实例(225)也可操作用来访问共享磁盘(220)。

在图1A和1B的示例中，软件组件不需要负起有保证的单个激活的责任，因为环境(100)包括HA软件。因为图2的环境(200)不包括HA软件，所以软件组件需要能够确保共享磁盘上的数据不会通过来自两个计算机(205、215)的同时的未协调的访问而被损坏。

如果软件组件的每个实例分别由单个进程组成，并且如果共享磁盘上的数据仅包含在少量文件中，则使用对共享磁盘上的数据文件的文件锁定以确保数据的完整性被保持是充分的。

例如，排他的文件锁定能够用于确保一次只有软件组件的一个运行实例读取或写入数据文件。在更复杂的方法中，数据文件的区域的“范围锁定”可用于确保软件组件的多个实例不会通过未协调的访问而使数据文件损坏。

当软件组件的复杂度增加时，需要进一步的改进。

发明内容

根据优选实施例的第一方面，提供了一种用于保持数据完整性的设备，用于在包括具有第一多个进程的第一软件实例、以及第二软件实例的环境中使用，其中所述第一软件实例和第二软件实例各自可操作用来访问共享数据，并且其中，与所述共享数据相关联的文件用于锁定，所述设备包括：第一锁组件，用于响应于第一多个进程的第一父进程不持有(hold)第一分层(hierarchical)文件锁，代表第二实例获得所述第一分层文件锁；部件，用于响应于代表所述第二实例获得第一分层文件锁，激活第二锁组件，其中，所述第二锁组件可操作用来响应于第一多个进程均不持有作为第一分层文件锁的子锁(child)的第二分层文件锁，代表所述第二实例获得第二分层文件锁；以及部件，用于响应于由第一锁组件获得所述第一分层文件锁，并响应于由第二锁组件获得所述第二分层文件锁，防止第一实例访问共享数据并允许所述第二实例访问共享数据。

根据优选实施例的第二方面，提供了一种保持数据完整性的方法，用于在包括具有第一多个进程的第一软件实例、以及第二软件实例的环境中使用，其中所述第一软件实例和第二软件实例各自可操作用来访问共享数据，并且其中，与所述共享数据相关联的文件用于锁定，所述方法包括：响应于第一多个进程的第一父进程不持有第一分层文件锁，代表第二实例获得所述第一分层文件锁；响应于代表所述第二实例获得第一分层文件锁、以及第一多个进程均不持有作为第一分层文件锁的子锁的第二分层文件锁，代表所述第二实例获得第二分层文件锁；以及响应于获得所述第一分层文件锁和所述第二分层文件锁，防止第一实例访问共享数据并允许所述第二实例访问共享数据。

根据优选实施例的第三方面，提供了一种计算机程序，包括程序代码组件，其被适配为当所述程序在计算机上运行时执行上述方法的所有步骤。

附图说明

现在将参考以下附图中图示的本发明的优选实施例，仅通过示例的方式来描述本发明：

图1A是现有技术的高度可用的第一环境的框图；

图1B是在高度可用的第一环境中的计算机故障的事件中、图1的现有技术的高度可用的第一环境的框图；

图2是现有技术的高度可用的第二环境的框图；

图3是根据优选实施例的高度可用的第二环境的框图；

图4是示出与图3的环境的父进程相关联的进程中涉及的操作步骤的流程图；

图5是示出与图3的环境的子进程相关联的进程中涉及的操作步骤的流程图；

图6A是与第一父进程相关联的组件的框图；

图6B是与第二父进程相关联的组件的框图；

图7A是与图6A的父进程的第一子进程相关联的组件的框图；以及

图7B是与图6A的父进程的第二子进程相关联的组件的框图。

具体实施方式

在软件组件的多个实例各自包括能够访问共享资源的数据的多个进程的环境中，需要改进的方法。

在这里的示例中，软件组件的多个实例能够在多台计算机上同时开启。每个实例可操作用来访问环境中的数据，并且每个实例包括一个或多个操作系统进程。

软件组件的每个实例是“活动的(active)”实例(被允许更新数据)或“待命的(standby)”实例(不被允许更新数据)。

在任何时间点，环境不包括多于一个活动实例——然而，可以存在多于一个待命实例——这确保关键程序的单个激活。

优选地，在活动实例的完全故障(即，与当前的活动实例的每个进程相关联的故障)的事件中，单个待命实例可变为新的活动实例。更优选地，活动实例的局部故障(即，与当前的活动实例的进程的子集相关联、而不是与当前的活动实例的每个进程相关联的故障)防止单个待命实例变为新的活动实例。

现在将参考附图描述优选实施例的实现。

图3描绘了高度可用的环境的代表(300)，其包括具有高度可用的软件组件(310)的第五实例的第五计算机(305)。

第五实例(310)包括多个进程(311、312和313)，每个进程都可操作用来访问共享资源，例如，包括数据的共享磁盘(320)。在示例中，共享磁盘(320)与网络文件系统相关联。

第一进程(311)是具有两个子进程(也就是，第二进程(312)和第三进程(313))的父进程，其中父进程启动子进程。

环境(300)还包括具有高度可用的软件组件(325)的第六实例的第六计算机(315)，其中第六实例(325)包括多个进程(326、327和328)，每个进程都可操作用来访问共享磁盘(320)。

第四进程(326)是具有两个子进程(也就是，第五进程(327)和第六进程(328))的父进程，其中父进程启动子进程。

图6A是与第一进程(311)相关联的组件的框图，其中第一进程(311)包括第一监视器组件(600)和第一锁组件(605)，它们每个都可操作用来访问共享磁盘(320)。第一进程(311)还包括第一启动器组件(610)。

图6B是与第四进程(326)相关联的组件的框图，其中第四进程(326)包括第二监视器组件(615)和第二锁组件(620)，它们每个都可操作用来访问共享磁盘(320)。第四进程(326)还包括第二启动器组件(625)。

图7A是与第二进程(312)相关联的组件的框图，其中第二进程(312)包括第三监视器组件(700)和第三锁组件(705)，它们每个都可操作用来访问共享磁盘(320)。第二进程(312)还包括第一终止器(710)。

图7B是与第三进程(313)相关联的组件的框图，其中第三进程(313)包括第四监视器组件(715)和第四锁组件(720)，它们每个都可操作用来访问共享磁盘(320)。第三进程(313)还包括第二终止器(725)。

优选地，父进程和子进程中的每个都可操作用来访问一个或多个锁。

存储在共享磁盘(320)上的文件用于锁定。

在这里的示例中，提供了可以被锁定在排他模式中的主锁和可以被锁定在排他或共享模式中的活动锁。

本发明可以用建议的或强制的锁来实现。

优选地，锁包括与实例相关联的标识符，其中所述实例的父进程持有所述锁。在一个示例中，将标识符存储在共享磁盘(320)中的用于锁定的文件中。在另一个示例中，将标识符存储在与用于锁定的文件分离的文件中。

现在将参考图3至8描述示例。

在示例中，第一进程(311)开始执行，使得第五实例(310)开启。

参考图4，第一进程(311)的第一监视器组件(600)监视主锁，从而确定(步骤400)是否可以获得锁的排他模式。

第一监视器组件(600)确定可以获得主锁上的排他模式，并且，作为响应，第一锁组件(605)获得主锁上的排他模式。优选地，与第一进程(311)相关联的标识符与主锁相关联。

第一进程(311)的第一监视器组件(600)监视活动锁，从而确定是否可以获得锁的排他模式。

第一监视器组件(600)确定可以获得活动锁上的排他模式，并且，作为响应，第一锁组件(605)获得活动锁上的所述排他模式。优选地，与第一进程(311)相关联的标识符与活动锁相关联。

作为响应，第五实例(310)变为活动实例(注意，第五实例(310)变为唯一的活动实例)。

作为响应，第一锁组件(605)解锁活动锁上的排他模式，并接着将活动锁锁定在共享模式中。

第一启动器组件(610)启动一个或多个子进程。在这里的示例中，第一启动器组件(610)启动第二进程(312)和第三进程(313)。

可替代地，第二进程(312)和第三进程(313)中的至少一个可以被独立地启动(例如，通过与第一进程(311)分离的另一个进程)。

优选地，第二进程和第三进程不做任何工作，直到它们证实了活动锁的持有者是第一进程为止——第三监视器组件(700)和第四监视器组件(715)中的每一个都检查与活动锁相关联的标识符，从而分别确定标识符是否与第二进程和第三进程的父进程相关联。如果标识符不与父进程相关联，则第二进程和第三进程假定父进程已经失败并且它们也必须终止——下面将更详细地描述终止过程。

在该示例中，标识符与父进程(也就是，第一进程(311))相关联。作为响应，参考图5，一旦启动，第三监视器组件(700)和第四监视器组件(715)中的每一个就都监视活动锁，从而确定(步骤500)是否可以获得锁的共享模式。

第三监视器组件(700)确定可以获得活动锁上的共享模式，并且，作为响应，第三锁组件(705)获得(步骤505)活动锁上的所述共享模式。

第四监视器组件(715)确定是否可以获得活动锁上的共享模式，并且，作为响应，第四锁组件(720)获得(步骤505)活动锁上的所述共享模式。

因此，第一进程(311)以排他模式持有主锁，并且第一进程(311)、第二进程(312)和第三进程(313)中的每一个都以共享模式持有活动锁。

结果，另一单个实例不能变为新的活动实例，并且第一进程(311)、第二进程(312)和第三进程(313)中的每一个都能够安全地访问共享磁盘中的数据。应该理解，由于第一进程(311)、第二进程(312)和第三进程(313)与同一实例(也就是，第五实例(310))相关联，所以可以使用已知的机制来协调第一进程(311)、第二进程(312)和第三进程(313)对共享磁盘(320)的访问。

参考图4，在该示例中，第四进程(326)由第六实例(325)启动。

第四进程(326)的第四监视器组件(615)监视主锁，从而确定(400)是否可以获得锁的排他模式。

第四监视器组件(615)确定不能获得主锁上的排他模式——这是因为主锁的排他模式已经被第一进程(311)获得。

有利地，第四监视器组件(615)可使用与是否可以获得主锁的排他模式相关联的确定，从而还确定另一个实例是否是活动的。如果第四监视器组件(615)不能获得主锁的排他模式，则第四监视器组件(615)确定另一个实例已经持有主锁的排他模式。

在步骤430，第六实例(325)确定它是否将重试变为新的活动实例。响应于第六实例(325)不重试(步骤435)变为新的活动实例，图4的进程结束。

响应于第六实例(325)重试变为新的活动实例，第六实例(325)被标记为待命实例(步骤435)。

在该示例中，第六实例(325)重试(步骤435)变为新的活动实例，并且接着，第四监视器组件(615)监视主锁，从而确定(步骤400)是否可以获得锁的排他模式。

第四监视器组件(615)确定可以获得主锁上的排他模式——这是因为在该示例中，主锁的排他模式已经被第一进程(311)的锁组件(605)释放(例如，被显式地释放，因为第一进程(311)已经完成工作；被隐式地释放，因为第一进程(311)已经失败)。

接着，第四锁组件(720)获得(步骤405)主锁上的排他模式。

现在，第六实例(325)尝试变为新的活动实例。

作为响应，第四监视器组件(615)接着监视活动锁，从而确定(步骤410)是否可以获得锁的排他模式。

第一监视器组件(600)确定不能获得主锁上的排他模式——在这里的示例中，这是因为第二进程(312)或第三进程(313)中的至少一个仍然以共享模式持有活动锁。

接着，第四锁组件(720)释放主锁上的排他模式，并且第六实例(325)仍然是(步骤430)待命实例。

应该理解，优选实施例提供了“分层的”锁，也就是，主锁和活动锁，其中，首先获得主锁，并且接着可以获得活动锁。通过使用分层锁，本发明通过对在其期间当前活动实例的父进程可能已经终止、但相关联的子进程尚未终止的定时窗口(timing window)负责而提供了可靠性——这导致了主锁上的排他模式被父进程释放且活动锁上的共享模式被子进程释放。因此，即使第四进程(326)能够获得主锁上的排他模式(即，因为第四进程(326)由于第二进程(312)或第三进程(313)中的至少一个仍然以共享模式持有活动锁而不能获得主锁上的排他模式)，第六实例(325)也仍然是待命实例。

响应于第六实例(325)不重试(步骤435)变为新的活动实例，进程结束。

在该示例中，响应于第六实例(325)重试(步骤435)变为新的活动实例，第四监视器组件(615)监视主锁，从而确定(步骤400)是否可以获得锁的排他模式。

第四监视器组件(615)确定可以获得主锁上的排他模式——在该示例中，这是因为主锁的排他模式已经被第一进程(311)的第一锁组件(605)释放。

接着，第四锁组件(720)获得主锁上的排他模式。

第四监视器组件(615)接着监视活动锁，从而确定(步骤410)是否可以获得锁的排他模式。

第一监视器组件(600)确定可以获得活动锁上的排他模式——在这里的示例中，这是因为第二进程(312)和第三进程(313)都不再以共享模式持有活动锁。

第二进程(312)和第三进程(313)都不再以共享模式持有活动锁的事件可由以下情况引起：例如，第二进程和第三进程中的每一个都被显式地或隐式地终止；或者第一进程(311)(显式地或者由于故障而隐式地)终止，并且接着，第三监视器组件(700)和第四监视器组件(715)中的每一个都确定第一进程(311)已经通过使用轮询功能(步骤510)而终止——接着，第二进程和第三进程的第一终止器(710)和第二终止器(725)中的每一个分别终止(步骤520)并释放共享模式中的活动锁。应该理解，如果第一进程(311)未终止，则子进程可以继续工作(步骤515)。

响应于第一监视器组件(600)确定可以获得活动锁上的排他模式，第四锁组件(720)获得活动锁上的所述排他模式。

作为响应，第六实例(325)变为新的活动实例。

应该理解，在上面的示例中，由于没有第五实例(310)(也就是，之前的活动实例)的子进程正在运行，所以第四锁组件(720)可操作用来获得活动锁上的排他模式。而且，由于与第五实例(310)相关联的进程(311、312和313)中的每一个都不在运行，所以第四锁组件(720)可操作用来获得主锁和活动锁中的每一个上的排他模式。

在另一个实现中，提供了多个活动锁。优选地，如果主锁上的排他模式已经被释放了，则活动实例的所有进程必须释放所有的所述多个活动锁，从而使另一实例能够试图变为新的活动实例。

接着，第四锁组件(720)解锁活动锁上的排他模式，并接着将活动锁锁定在共享模式中。

第二启动器组件(625)可以启动一个或多个子进程，例如，第五进程(327)和第六进程(328)。

有利地，在每个实例可以包括多个进程的环境中，本发明考虑到实例的高度可用性(例如，实例可变为新的活动实例)和有保证的单个激活，以便一次只有软件组件的一个实例可以访问共享数据(例如，通过使用“分层”锁定——例如，排他的主锁和排他的/共享的活动锁)。

有利地，实例不需要配备另一个实例的位置，并且实例之间的网络心跳(network heartbeating)不需要确保单个激活。这是因为可以使用文件锁定来保证单个激活。有利地，待命实例可以在不需要知道与故障的实例相关联的数据(例如，与故障的实例在哪里运行相关联的位置)的情况下取代故障的实例。

有利地，不需要HA软件。这增加了可用性并允许更简单地引入待命实例。

而且，持有锁的进程的标识符与锁的关联是有利的，例如，如果已经存在网络中断。在中断之后，父进程可以重新获得该锁并查询标识符，以确定标识符是否是它自己的。如果标识符是它自己的，则进程知道它在中断之前持有该锁、以及在中断期间没有其它实例获得该锁。如果标识符不是它自己的，则进程知道在中断期间另一实例必定已经获得了该锁—-在这种情况下，父进程和与该实例相关联的其它进程必须终止，以保证完整性(并且如果需要，则父进程可以重新执行并试图获得该锁)。

应该理解，如果存在多个待命实例，则优选地，当当前活动实例不再是活动实例时，实施选择进程以选择单个待命实例变为新的活动实例，例如，其中，所述多个待命实例“竞争(race)”以变为新的活动实例；其中，所述多个待命实例判定它们中的哪一个变为新的活动实例。可替代地，可以使用另外的锁文件以协调和监视待命实例。

Claims (6)

1.一种用于保持数据完整性的设备，用于在包括第二软件实例、以及具有第一多个进程的第一软件实例的环境中使用，其中所述第一软件实例和所述第二软件实例各自可操作用来访问共享数据，并且其中，与所述共享数据相关联的文件被用于锁定，所述设备包括：

第一锁组件，用于响应于所述第一多个进程的第一父进程不持有第一分层文件锁，代表第二实例获得所述第一分层文件锁；

部件，用于响应于代表所述第二实例获得所述第一分层文件锁，激活第二锁组件，其中，所述第二锁组件可操作用来响应于所述第一多个进程均不持有作为所述第一分层文件锁的子锁的第二分层文件锁，代表所述第二实例获得所述第二分层文件锁；以及

部件，用于响应于由所述第一锁组件获得所述第一分层文件锁，并响应于由所述第二锁组件获得所述第二分层文件锁，防止第一实例访问所述共享数据并允许所述第二实例访问所述共享数据。

2.如权利要求1所述的设备，其中所述第二锁组件可操作用来响应于第二监视器组件确定已经由所述第一多个进程中的至少一个获得了所述第二分层文件锁，防止代表所述第二实例获得所述第二分层文件锁。

3.如权利要求1所述的设备，其中所述第二软件实例包括第二多个进程，并且其中所述第二锁组件可操作用来代表所述第二多个进程中的至少一个获得所述第二分层文件锁。

4.如权利要求1所述的设备，还包括第一监视器组件，用于确定所述第一分层文件锁是否能够被获得。

5.如权利要求1所述的设备，还包括第二监视器组件，用于确定所述第二分层文件锁是否能够被获得。

6.一种用于保持数据完整性的方法，用于在包括第二软件实例、以及具有第一多个进程的第一软件实例的环境中使用，其中所述第一软件实例和所述第二软件实例各自可操作用来访问共享数据，并且其中，与所述共享数据相关联的文件被用于锁定，所述方法包括：

响应于所述第一多个进程的第一父进程不持有第一分层文件锁，代表第二实例获得所述第一分层文件锁；

响应于代表所述第二实例获得所述第一分层文件锁、以及所述第一多个进程均不持有作为所述第一分层文件锁的子锁的第二分层文件锁，代表所述第二实例获得所述第二分层文件锁；以及

响应于获得所述第一分层文件锁以及所述第二分层文件锁，防止第一实例访问所述共享数据并允许所述第二实例访问所述共享数据。

Images