WO2012072644A1 - Validation of access to a shared data record subject to read and write access by multiple requesters - Google Patents
Validation of access to a shared data record subject to read and write access by multiple requesters Download PDFInfo
- Publication number
- WO2012072644A1 WO2012072644A1 PCT/EP2011/071309 EP2011071309W WO2012072644A1 WO 2012072644 A1 WO2012072644 A1 WO 2012072644A1 EP 2011071309 W EP2011071309 W EP 2011071309W WO 2012072644 A1 WO2012072644 A1 WO 2012072644A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data record
- shared data
- node
- cluster
- payload
- Prior art date
Links
- 238000010200 validation analysis Methods 0.000 title description 3
- 238000000034 method Methods 0.000 claims abstract description 85
- 238000012545 processing Methods 0.000 claims description 58
- 238000013500 data storage Methods 0.000 claims description 38
- 238000004590 computer program Methods 0.000 claims description 11
- 230000008569 process Effects 0.000 abstract description 60
- 238000003860 storage Methods 0.000 description 26
- 230000004044 response Effects 0.000 description 13
- 230000006870 function Effects 0.000 description 8
- 238000007726 management method Methods 0.000 description 8
- 230000015654 memory Effects 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 7
- 230000003287 optical effect Effects 0.000 description 5
- 238000005192 partition Methods 0.000 description 5
- 238000005304 joining Methods 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 239000013307 optical fiber Substances 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 230000010076 replication Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 101100521334 Mus musculus Prom1 gene Proteins 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
- G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
- G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
- G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/142—Reconfiguring to eliminate the error
- G06F11/1425—Reconfiguring to eliminate the error by reconfiguration of node membership
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1479—Generic software techniques for error detection or fault masking
- G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/825—Indexing scheme relating to error detection, to error correction, and to monitoring the problem or solution involving locking
Definitions
- the present invention relates in general to data processing, and in particular, to cluster data processing systems.
- a cluster system also referred to as a cluster multiprocessor system (CMP) or simply as a “cluster,” is a set of networked data processing systems (or “nodes”) with hardware and software shared among those data processing systems, typically (but not necessarily) configured to provide highly available and highly scalable application services.
- Cluster systems are frequently implemented to achieve high availability as an alternative to fault tolerance for mission-critical applications such as data centres, aircraft control, and the like.
- Fault tolerant data processing systems rely on specialized hardware to detect hardware faults and to switch to a redundant hardware component, regardless of whether the component is a processor, memory board, hard disk drive, adapter, power supply, etc. While providing seamless cutover and uninterrupted performance, fault tolerant systems are expensive due to the requirement of redundant hardware, and fail to address software errors, a more common source of data processing system failure.
- High availability can be achieved in a cluster implemented with standard hardware through the use of software that permits resources to be shared system wide.
- the software quickly establishes an alternative path to the desired resource.
- the brief interruption required to re-establish availability of the desired resource is acceptable in many situations.
- the hardware costs are significantly less than fault tolerant systems, and backup facilities may be utilized during normal operation.
- Cluster system management is a special class of the general system management, with additional resource dependency and management policy constraints.
- the maintenance of cluster configuration information required for cluster system management poses a special problem.
- the cluster configuration information required for system management is typically stored in a database, which is either centralized or replicated to more than one data processing system for high availability. If centralized, the data processing system which manages a centralized cluster configuration database becomes a potential bottleneck and a single point of failure.
- the cluster To avoid the problems of a centralized cluster configuration database, the cluster
- configuration database may be replicated and maintained on a number of data processing systems within the cluster.
- system configuration and status information may be readily replicated to all data processing systems in the cluster for use by each data processing system in performing system management functions such as failure recovery and load balancing.
- Full replication provides a highly available cluster
- Cluster partitions occur if nodes that can nominally be configured to operate in a cluster are partitioned into two or more sets of nodes that are not currently configured to share system resources.
- a cluster partition occurs, for example, at system start up or in response to return of one or more downed nodes, errors can result if multiple copies of the same application, especially a database application such as the cluster configuration database, are run from these (temporarily) independent nodes of the cluster.
- a conventional way of managing cluster partitions is to require that a cluster remain offline until it reaches quorum.
- quorum While the definition of quorum varies between implementations, in many implementations a majority quorum is employed, and a cluster is said to have reached quorum when the number of active nodes is at least N/2+1.
- the nodes As nodes from a cluster partition become members of a cluster, the nodes must be assigned an identifier so that the nodes' software and hardware resources can be made available for access to the cluster.
- the identifiers are assigned by a central naming authority so that the identifiers can be guaranteed to be universally unique in the cluster.
- the use of a central naming authority can undesirably lead to a single point of failure, as well as the need for a node to modify its pre-existing identifier upon joining the cluster.
- a requester in a method of access to a shared data record subject to contemporaneous read and write access by multiple requesters, reads a shared data record including a payload and a first checksum. The requester calculates a second checksum of the payload of the data record. If the first and second checksums are not equal, the requester again reads the shared data record, including a third checksum, and calculates a fourth checksum of the payload of the shared data record. If the third and fourth checksums are equal, the requester processes the shared data record as valid, and if the second and fourth checksums are equal, the requester handles the shared data record as corrupt.
- the present invention provides a method of access to a shared data record subject to contemporaneous read and write access by multiple requesters, the method comprising: a requester reading a shared data record including a payload and a first checksum; the requester calculating a second checksum of the payload of the data record; if the first and second checksums are not equal, the requester again reading the shared data record, said shared data record including a third checksum, and calculating a fourth checksum of the payload of the shared data record; if the third and fourth checksums are equal, the requester processing the shared data record as valid; and if the second and fourth checksums are equal, the requester handling the shared data record as corrupt.
- the present invention provides a method further comprising: if the first and second checksums are equal, the requester processing the shared data record as valid.
- the present invention provides a method further comprising: the requester waiting for an update to the shared data record to complete prior to again reading the shared data record.
- the present invention provides a method wherein the reading comprises reading the data record in one shot.
- the present invention provides a method further comprising: the requester acquiring a lock on the shared data record and performing an update to the payload of the data record; the requester calculating and writing into the shared data record a fourth checksum of the updated payload; and the requester thereafter releasing the lock.
- the present invention provides a method wherein performing the update to the payload comprises performing an update to the payload in one shot.
- the present invention provides a program product for accessing a shared data record subject to contemporaneous read and write access by multiple requesters, the program product comprising: a computer readable storage medium; and program code stored within the computer readable storage medium that, when processed by a computer, causes the computer to perform: reading a shared data record including a payload and a first checksum; calculating a second checksum of the payload of the data record; if the first and second checksums are not equal, again reading the shared data record, said shared data record including a third checksum, and calculating a fourth checksum of the payload of the shared data record; if the third and fourth checksums are equal, processing the shared data record as valid; and if the second and fourth checksums are equal, handling the shared data record as corrupt.
- the present invention provides a program product wherein the program code further causes the computer to perform: if the first and second checksums are equal, processing the shared data record as valid.
- the present invention provides a program product wherein the program code further causes the computer to perform: waiting for an update to the shared data record to complete prior to again reading the shared data record.
- the present invention provides a program product wherein the reading comprises reading the data record in one shot.
- the present invention provides a program product wherein the program code further causes the computer to perform: acquiring a lock on the shared data record and performing an update to the payload of the data record; calculating and writing into the shared data record a fourth checksum of the updated payload; and thereafter releasing the lock.
- the present invention provides a program product wherein performing the update to the payload comprises performing an update to the payload in one shot.
- the present invention provides a data processing system comprising: a processor; data storage; and program code stored within the data storage that, when processed by the data processing system, causes the data processing system to perform: reading a shared data record including a payload and a first checksum; calculating a second checksum of the payload of the data record; if the first and second checksums are not equal, again reading the shared data record, said shared data record including a third checksum, and calculating a fourth checksum of the payload of the shared data record; if the third and fourth checksums are equal, processing the shared data record as valid; and if the second and fourth checksums are equal, handling the shared data record as corrupt.
- the present invention provides a data processing system wherein the program code further causes the data processing system to perform: if the first and second checksums are equal, processing the shared data record as valid.
- the present invention provides a data processing system wherein the program code further causes the data processing system to perform: waiting for an update to the shared data record to complete prior to again reading the shared data record.
- the present invention provides a data processing system wherein the reading comprises reading the data record in one shot.
- the present invention provides a data processing system wherein the program code further causes the data processing system to perform: acquiring a lock on the shared data record and performing an update to the payload of the data record; calculating and writing into the shared data record a fourth checksum of the updated payload; and thereafter releasing the lock.
- the present invention provides a data processing system wherein performing the update to the payload comprises performing an update to the payload in one shot.
- the present invention provides a computer program comprising computer program code to, when loaded into a computer system and executed, perform all the steps of the invention as described above.
- Figure 1 is a high level block diagram of an exemplary data processing environment that may be configured as a cluster system in accordance with a preferred embodiment of the present invention
- Figure 2 depicts a trusted data storage device that stores a cluster configuration database in accordance with a preferred embodiment of the present invention
- Figure 3 illustrates an exemplary cluster configuration database in accordance with a preferred embodiment of the present invention
- Figure 4 is a high level logical flowchart of an exemplary process for generating unique names for cluster storage devices in accordance with a preferred embodiment of the present invention
- Figure 5 is a high level logical flowchart of an exemplary process by which a first node initiates a cluster configuration change in a cluster including at least a second node in accordance with a preferred embodiment of the invention
- Figure 6 is a high level logical flowchart of an exemplary process by which a second node promulgates its self-assigned UUID (Universally Unique Identifier) to a cluster in accordance with a preferred embodiment of the present invention
- FIG. 7 is a high level logical flowchart of an exemplary process for reading a shared data record, such as a record of a cluster configuration database, in accordance with a preferred embodiment of the present invention
- FIG. 8 is a high level logical flowchart of an exemplary process for writing a shared data record, such as a record of a cluster configuration database, in accordance with a preferred embodiment of the present invention.
- Figure 9 is a high level logical flowchart of an exemplary process for configuring nodes of a cluster with common device names for shared data storage devices in accordance with in accordance with a preferred embodiment of the present invention.
- data processing environment 100 includes a distributed collection of homogeneous or heterogeneous networked data processing systems, referred to herein as nodes 102.
- nodes 102 can be implemented with a server computer system, such as one of the POWER servers available from International Business Machines Corporation of Armonk, New York.
- each node 102 includes both hardware resources 110 and software resources 120.
- Hardware resources 110 of nodes 102 include processors 112 for processing data and program instructions, as well as data storage devices 114 such as memory and optical and/or magnetic disks for storing software and data.
- Hardware resources 110 also include additional hardware 116, such as network, input/output (I/O) and peripheral adapters, power systems, ports, administrative consoles, attached devices, etc.
- hardware resources 110 may include at least some redundant or backup resources that may be selectively placed into service, for example, in response to high workload or hardware failure.
- the software resources 120 of a node 102 can include, for example, one or more possibly heterogeneous concurrent instances of operating system(s) 122, middleware 124 such as web and/or application servers, and applications 126.
- operating system(s) 122 includes built-in clustering capability supporting commands and programming APIs to enable creation, maintenance and management of a cluster from a group of operating system instances on multiple nodes 102.
- the operating system infrastructure supports unique cluster-wide node and storage device naming across the cluster.
- this clustering capability is provided by cluster-aware AIX®, an open standards-based UNIX® operating system available from International Business Machines Corporation of Armonk, New York.
- nodes 102 are coupled by one or more wired or wireless, public or private networks 104 to permit sharing of at least some of hardware resources 110 and software resources 120 among different nodes 102 configured to operate as a cluster.
- Network(s) 104 can include local area networks or wide area networks, such as the Internet, as well as private point-to-point connections between individual nodes 102.
- One important function of the cluster support provide by operating system(s) 122 is to make shared cluster hardware and software resources highly available. As an example, if an individual node 102 within cluster system 100 fails, one or more applications 126 on the failed node 102 will be automatically migrated by operating system 122 to one or more other nodes 102 in the cluster system 100. Consequently, services provided by the failed node 102 will, after a brief interruption, be continuously available. For an application 126 or other resource to be highly available, multiple nodes 102 within the cluster are usually configured to run that application 126 or resource, although usually at most only one node 102 manages the shared application 126 at any single instant in time.
- cluster system such as the exemplary data processing environment depicted in Figure 1
- a cluster system can additional or fewer nodes, one or more client systems, and/or other connections not explicitly shown.
- the generalized cluster architecture shown in Figure 1 is not intended to imply an architectural limitations on the claimed invention.
- a cluster configuration database preferably defines what nodes 102 are authorized to form and/or join a cluster and thus access the shared resources of the cluster.
- the cluster configuration database 200 resides on a trusted shared data storage device 114 of a host node 102, represented in Figure 2 by a hard disk 202.
- Cluster system 100 is constructed and configured such that trusted shared data storage device 114 is only accessible to nodes 102 that are authorized to be members of a cluster (whether or not the nodes 102 actually are members of the cluster at the time of access).
- Hard disk 202 includes a boot sector 204 containing the information required to boot the host node 102 under one of operating systems 122.
- boot sector 204 includes a cluster field 206 containing a pointer to cluster configuration database 200, which as shown, preferably resides on the same trusted shared data storage device 114.
- cluster configuration database 200 identifies which nodes 102 are authorized to join a cluster and thus access shared cluster resources.
- cluster configuration database 200 includes a plurality of data records 302 each comprising a payload 304 and a checksum field 306 storing a checksum of the data record's payload 304.
- each data record 302 includes a node UUID (Universally Unique Identifier) field 310 for storing the UUID of a respective one of nodes 102.
- the UUID preferably is self-assigned by the node 102 in accordance with the process depicted in
- Data record 302 additionally includes a node temporary ID field 312 that records a temporary identifier of the node 102, such as the hostname or Internet Protocol (IP) address assigned to the node 102.
- Data record 314 may optionally include one or more additional node metadata fields, shown generally at reference numeral 314, that hold additional metadata regarding the node 102.
- nodes 102 within a cluster defined by cluster configuration database 200 share software resources 120 and hardware resources 110, including at least some of data storage devices 114.
- the data storage device(s) 114 of a node 102 to be shared by other nodes 102 of a cluster are identified by Universal Disk Identifiers (UDIDs) (or UUIDs) recorded in UDID field 316 of data record 302.
- UDIDs Universal Disk Identifiers
- the UDID field 316 of a data record 302 is populated upon the addition of a host node 102 on which the shared data storage devices 114 reside to the cluster configuration.
- UDID field 316 Associated with UDID field 316 is a disk name field 318 that stores a corresponding device name for each of the shared data storage devices 114 referenced in UDID field 316.
- software such as operating systems 114, traditionally reference data storage devices by a variety of names, such as the combination of major and minor numbers utilized by UNIX® to refer to disks.
- cluster configuration database 200 preferably includes support for the generation of unique names for shared data storage devices 114.
- this support includes a reserved prefix buffer 330 that holds a reserved prefix of the names of shared data storage devices 114.
- cluster configuration database 200 includes a naming counter 340 that monotonically advances (i.e., increments or decrements) to ensure a device name is never repeated during the lifetime of cluster configuration database 200.
- the software that initiates the cluster configuration operation e.g., an operating system 122 preferably performs or invokes a process to generate unique device names for the shared data storage devices 114.
- the process begins at block 400 and then proceeds to block 402, which illustrates a determination of whether any additional shared data storage devices (represented by their UDIDs) remain to be processed. If not, the process ends at block 410.
- the software If, on the other hand, one or more new shared data storage devices 114 remain to processed, the software generates a device name for the new shared data storage device 114 at block 404 by concatenating the reserved prefix from reserved prefix buffer 330 with the value of naming counter 340, which is then advanced (i.e., incremented or decremented) as shown at block 406.
- the software then records the device name of the new shared data storage device 114 in device name field 318 in association with the UDID (or UUTD) recorded in UDID field 316 (block 408). Following block 408, the process returns to block 402 to generate a device name for the next new shared data storage devices 114 to be processed, if any.
- FIG. 5 there is illustrated a high level logical flowchart of an exemplary process by which a first node 102 initiates a cluster configuration change in a cluster including at least a second node in accordance with one embodiment.
- the exemplary process can be implemented, for example, by appropriate programming of a cluster-aware operating system 122 of the first node 102.
- the process begins at block 500 and then proceeds to block 502, which depicts a first node 102 of data processing environment 100 initiating a cluster configuration operation, for example, to establish a cluster including at least itself and a second node 102 or to perform some other cluster update to the configuration of a running cluster.
- a cluster configuration operation for example, to establish a cluster including at least itself and a second node 102 or to perform some other cluster update to the configuration of a running cluster.
- first node 102 may or may not already be a member of the cluster.
- first node 102 transmits on network 104 a cluster configuration communication identifying the second node 102 utilizing a temporary identifier, such as a hostname or IP address of the second node 102.
- the first node 102 may determine one or more recipient nodes 102 of the cluster configuration communication, for example, from the cluster configuration defined by cluster configuration database 200.
- the cluster configuration communication which may be a unicast or multicast message, simply identifies second node 102 by the temporary identifier and provides information regarding the location of cluster configuration database 200, for example, a unique identifier (e.g., UDID) of the trusted shared data storage device 114 (e.g., hard disk 202 of Figure 2). In this manner, second node 102 is notified to access cluster configuration database 200 without explicit transmission of cluster configuration data, and the inherent security provided by trusted shared data storage device 114 prevents unauthorized devices from accessing or receiving sensitive cluster configuration data.
- a unique identifier e.g., UDID
- first node 102 may thereafter optionally receive notification of the success or failure of the cluster configuration operation, for example, from second node 102.
- First node 102 can receive the notification, for example, in a message received via network(s) 104 or in a message communicated via trusted shared storage device 114.
- FIG. 6 there is depicted a high level logical flowchart of an exemplary process by which a second node promulgates its self-assigned UUID to a cluster in accordance with one embodiment.
- the exemplary process can be implemented, for example, by appropriate programming of a cluster-aware operating system 122 of the second node 102.
- the process shown in Figure 6 begins at block 600 and then proceeds to block 602, which depicts the second node 102 receiving a stimulus to read cluster configuration database 200.
- the stimulus is a message from the first node 102 received via network(s) 104.
- second node 102 may alternatively or additionally be configured (e.g., via appropriate programming of an operating system 122) to read cluster configuration database 200 at intervals or in response to predetermined events, such as system start-up.
- second node 102 determines at block 604 whether or not it already has a self-assigned UUID.
- second node 102 may, for example, access a storage location in one of its local data storage devices 114 predetermined by software and/or firmware. If second node 114 determines at block 604 that the second node 102 already has a self-assigned UUID, the process passes to block 410, which is described below. If, on the other hand, second node 102 determines at block 604 that is does not already have a self- assigned UUID, second node 102 generates and stores its UUID. Second node 102 can use any known or future developed technique to generate, store and retrieve its UUID, provided that the self-assigned UUID is persistent across reboots of second node 102. As is well known in the art, a UUID can be generated, for example, by random number generation or utilizing a SHA-1 or MD6 hash. Following block 606, the process passes to block 610.
- Block 610 depicts second node 102 accessing and searching cluster configuration database 200 in trusted shared data storage device 114 for its self-assigned UUID.
- Second node 102 can locate cluster configuration database 200, for example, utilizing the unique identifier received in the cluster configuration communication described at block 504 of Figure 5 and by then locating boot sector 204 of trusted shared data storage device 114 and following the pointer provided in cluster field 206. If second node 102 finds its self-assigned UUID in cluster configuration database 200 (e.g., in node UUID field 310 of a data record 302), second node 102 knows that it has previously been a member of the cluster. Accordingly, the process proceeds from block 612 to block 630, which is described below.
- the process passes block 612 to block 620, which illustrates second node 102 searching cluster configuration database 200 (e.g., in node temporary ID field 312) for a temporary identifier associated with second node 102, such as a hostname or IP address of second node 102.
- the temporary identifier may further be associated in cluster configuration database 200 with a constant or well-known UUID to indicate that the self-assigned UUID of second node 102 is not yet known to the cluster.
- second node 102 determines at block 622 that a temporary identifier of second node 102 is not present in cluster configuration database 200, second node 200 determines that it is not a member of the cluster and terminates the cluster configuration process shown in Figure 6 at block 640.
- the termination may be "silent" and provide no notification to first node 102; alternatively, second node 102 may provide a failure notification to first node 102 via trusted shared data storage device 114 or via a message transmitted over network(s) 104.
- second node 102 in response to second node 102 determining that a temporary identifier of second node 102 is present in cluster configuration database 200, second node 102 knows that this is its first time to join the cluster. Accordingly, second node 102 writes its self-assigned UUID into cluster configuration database 102 (e.g., in node UUID field 310 of its data record 302), as shown at block 424. In addition, second node 102 may supply or update additional metadata describing second node 102 (e.g., in node temporary ID field 312 or node metadata field 314 of its data record 302), as depicted at block 630.
- Second node 102 then proceeds to join the cluster and/or assimilate any configuration changes to the cluster since it last read cluster configuration database 200, as depicted at block 632.
- the activities performed by second node 102 in joining the cluster may include updating its internal configuration with the device names assigned to its shared storage devices 114 by cluster configuration database 200 and/or starting cluster services.
- the self-assigned UUID of second node 102 present in cluster configuration database 200 the various nodes 102 belonging to the cluster can then access hardware resources 110 and software resources 120 of second node 102 and perform cluster configuration operations referencing second node 102 utilizing its self-assigned UUID.
- second node 102 may optionally provide notification of joining the cluster to first node 102, for example, via trusted shared data storage device 114 or by transmitting a notification message via network(s) 114. Thereafter, the process depicted in Figure 6 ends at block 640.
- cluster configuration database 200 has described access to cluster configuration database 200 by a first node 102 and a second node 102.
- cluster configuration database 200 may potentially be contemporaneously accessed not only by first node 102 and second node 102, but also by numerous additional nodes 102 of data processing environment 100.
- access to cluster configuration database 200 is preferably coordinated between nodes utilizing an agreed protocol.
- coordination between requesters accessing the shared data records is implemented by middleware, such as database software, or the network protocols by which the requesters access the shared data records.
- middleware such as database software
- the infrastructure on which such coordination relies e.g., software or communication protocols
- FIG. 7 there is depicted a high level logical flowchart of an exemplary process for reading a shared data record, such as a record of a cluster configuration database, in accordance with one embodiment.
- a shared data record such as a record of a cluster configuration database
- the illustrated process is described as being implemented by an operating system 122 of a node 102 reading cluster configuration database 200, but it should be understood that the illustrated process is not limited to such embodiments and may generally be performed by any software or hardware that coordinates read access to shared data records between multiple requesters.
- the illustrated process begins at block 700 and then proceeds to block 702, which depicts operating system 122 initializing a temporary variable referred to as "previous checksum" to an initial value, such as zero, that is not a valid checksum value.
- the operating system 122 reads a data record 302 of cluster configuration database 200 into memory in one shot (but not necessarily atomically). This read, which includes both the payload 304 and checksum field 306 of the data record 302, may be performed, for example, during the steps illustrated at blocks 610 and 620 of Figure 6.
- Operating system 122 then calculates the checksum of payload 304 of data record 302 (block 706) and compares the calculated checksum with the contents of checksum field 306 read from cluster configuration database 200 (block 710).
- operating system 122 determines at block 720 whether or not the calculated checksum is equal to the previous checksum variable. If not, the process passes to block 730, which depicts operating system 122 updating the previous checksum variable with the checksum calculated at block 706. Operating system 122 then waits at block 732 for an appropriate amount of time to permit any ongoing update to the data record 302 to complete. The process then returns to block 704-710, which represent operating system 122 again reading the target data record 302 and calculating a checksum for its payload 304.
- the process for reading a shared data record depicted in Figure 7 permits validation of the a shared data record accessed by a requester without the mutual exclusion (mutex) locking or other similar infrastructure commonly used to synchronize access to shared data records.
- mutex mutual exclusion
- FIG 8 there is depicted a high level logical flowchart of an exemplary process for writing a shared data record, such as a record of cluster configuration database 200, in accordance with one embodiment.
- the following description again describes the illustrated process as being implemented by an operating system 122 of a node 102 writing a data record 302 in cluster configuration database 200, for example, at block 624 of Figure 6. It should be understood, however, that the illustrated process is not limited to such embodiments and may generally be performed by any software or hardware that coordinates write access to shared data records between multiple requesters.
- the illustrated process begins at block 800 and then proceeds to block 802, which depicts operating system 122 of a node 102 seeking to write a data record 302 of cluster
- configuration database 200 acquiring an inter-node lock on the target data record 302 to be written.
- the inter-node lock may be obtained, for example, utilizing an inter-node advisory locking methodology, such as the Ricart-Agrawala algorithm or the like.
- operating system 122 performs a one-shot (but not necessarily atomic) update to payload 304 of the target data record 302 (block 804).
- Operating system 122 additionally computes the checksum of payload 304 and writes the computed checksum into checksum field 306 of the target data record 302 (block 806).
- Operating system 122 thereafter releases the inter-node lock on the target data record 302, as depicted at block 808.
- the process shown in Figure 8 then terminates at block 810.
- FIG. 9 there is illustrated a high level logical flowchart of an exemplary process for configuring nodes of a cluster with common device names for shared data storage devices in accordance with one embodiment.
- the depicted process is performed by an operating system 122 of a node 102 at block 632 of Figure 6 as a part of the boot process.
- the process shown in Figure 9 begins at block 900, for example, during the boot process of a node 102, and then proceeds to block 902.
- Block 902 depicts an operating system 122 of the node 102 reading cluster configuration database 200 to determine a next UDID (or UUID) to be processed (and preferably validating the associated data record 302 utilizing the process illustrated in Figure 7).
- Operating system 122 determines if a UDID (or UUID) matching that read from cluster configuration database 200 is found in the node configuration maintained internally in the booting node 102. If not, the process passes to block 908, which is described below.
- operating system 122 renames the shared data storage device 114 in the node configuration maintained at the booting node 102 to the device name associated with the UDID in device name field 318 (block 906).
- Operating system 122 determines at block 908 if cluster configuration database 200 contains additional UDIDs to be processed. If not, the process depicted in Figure 9 ends at block 910. If, however, operating system 122 determines at block 908 that one or UDIDs remain to be processed, the process shown in Figure 9 returns to block 902, which has been described.
- nodes 102 belonging to a cluster rename shared storage devices such that the shared storage devices have common names across all nodes 102 of the cluster.
- the node determines whether or not the node has a universally unique identifier (UUID), and if not, the node provides its own persistent self-assigned UUID.
- UUID universally unique identifier
- the node searches a cluster configuration database for a temporary identifier associated with the node.
- the node writes its self-assigned UUID into the cluster configuration database and joins the cluster.
- a unique device name is assigned to each of a plurality of shared storage devices in a cluster configuration database defining membership of nodes in a cluster.
- a particular node among the nodes defined by the cluster configuration database as a member of the cluster searches the cluster configuration database for a device identifier matching a device identifier of a shared storage device hosted by the particular node.
- the particular node renames, in a local configuration maintained at the particular node, a storage device associated with the matching device identifier with the unique name assigned to that storage device in the cluster configuration database.
- a requester reads a shared data record including a payload and a first checksum.
- the requester calculates a second checksum of the payload of the data record. If the first and second checksums are not equal, the requester again reads the shared data record, including a third checksum, and calculates a fourth checksum of the payload of the shared data record. If the third and fourth checksums are equal, the requester processes the shared data record as valid, and if the second and fourth checksums are equal, the requester handles the shared data record as corrupt.
- a second node receives a message from a first node in a cluster environment.
- the message includes a unique identifier of a shared data storage device including a cluster configuration database that defines membership of nodes in a cluster.
- the second node attempts to find the shared data storage device.
- the second node locates and reads the cluster configuration database on the shared data storage device. The second node then assimilates a cluster configuration update indicated by the cluster configuration database.
- one or more of the methods may be embodied in a computer-readable medium containing computer-readable code such that a series of steps are performed when the computer-readable code is executed on a computing device.
- certain steps of the methods are combined, performed simultaneously or in a different order, or perhaps omitted, without deviating from the spirit and scope of the invention.
- the method steps are described and illustrated in a particular sequence, use of a specific sequence of steps is not meant to imply any limitations on the invention. Changes may be made with regards to the sequence of steps without departing from the spirit or scope of the present invention. Use of a particular sequence of steps is therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.
- aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer readable program code embodied thereon.
- the computer-readable medium may be a computer readable signal medium or a computer- readable storage medium.
- a computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
- a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
- a computer-readable signal medium may include a propagated data signal with computer- readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof.
- a computer- readable signal medium may be any computer-readable medium that is not a computer- readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
- Program code embodied on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
- Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the C programming language or similar programming languages.
- the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
- the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
- LAN local area network
- WAN wide area network
- Internet Service Provider an Internet Service Provider
- the computer program instructions may also be stored in a computer-readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
- the computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer- implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- the processes in embodiments of the present invention may be implemented using any combination of software, firmware or hardware.
- the program code (whether software or firmware) will typically be stored in one or more machine-readable storage mediums, such as fixed (hard) drives, diskettes, optical disks, magnetic tape, semiconductor memories such as ROMs, PROMs, etc., thereby making an article of manufacture in accordance with the invention.
- the article of manufacture containing the programming code is used by either executing the code directly from the storage device, by copying the code from the storage device into another storage device such as a hard disk, RAM, etc., or by transmitting the code for remote execution using transmission type media such as digital and analog communication links.
- the methods of the invention may be practiced by combining one or more machine-readable storage devices containing the code according to the present invention with appropriate processing hardware to execute the code contained therein.
- An apparatus for practicing the invention could be one or more processing devices and storage systems containing or having network access to program(s) coded in accordance with the invention.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE112011104020T DE112011104020T5 (en) | 2010-12-01 | 2011-11-29 | Validate access to a shared record for read and write access by multiple requestors |
CN201180057946.6A CN103238142B (en) | 2010-12-01 | 2011-11-29 | Checking on the access of the shared data record that reading and the write-access by multiple requestors affects |
GB1311637.1A GB2500348B (en) | 2010-12-01 | 2011-11-29 | Validation of access to a shared data record subject to read and write access by multiple requesters |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/957,937 | 2010-12-01 | ||
US12/957,937 US20120143836A1 (en) | 2010-12-01 | 2010-12-01 | Validation of access to a shared data record subject to read and write access by multiple requesters |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2012072644A1 true WO2012072644A1 (en) | 2012-06-07 |
Family
ID=45063140
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2011/071309 WO2012072644A1 (en) | 2010-12-01 | 2011-11-29 | Validation of access to a shared data record subject to read and write access by multiple requesters |
Country Status (5)
Country | Link |
---|---|
US (2) | US20120143836A1 (en) |
CN (1) | CN103238142B (en) |
DE (1) | DE112011104020T5 (en) |
GB (1) | GB2500348B (en) |
WO (1) | WO2012072644A1 (en) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8955097B2 (en) * | 2011-12-13 | 2015-02-10 | Mcafee, Inc. | Timing management in a large firewall cluster |
US9183148B2 (en) | 2013-12-12 | 2015-11-10 | International Business Machines Corporation | Efficient distributed cache consistency |
CN106569907B (en) * | 2016-10-31 | 2020-09-29 | Tcl移动通信科技(宁波)有限公司 | System startup file checking and compiling method |
US10972449B1 (en) * | 2018-06-28 | 2021-04-06 | Amazon Technologies, Inc. | Communication with components of secure environment |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030145210A1 (en) * | 2002-01-31 | 2003-07-31 | Sun Microsystems, Inc. | Method, system, program, and data structure for implementing a locking mechanism for a shared resource |
US20070168793A1 (en) * | 2006-01-09 | 2007-07-19 | Samsung Electronics Co., Ltd. | Device and method capable of verifying program operation of non-volatile memory and method card including the same |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6269374B1 (en) * | 1998-05-26 | 2001-07-31 | International Business Machines Corporation | Method and apparatus for updating checksums of data structures |
US6922782B1 (en) * | 2000-06-15 | 2005-07-26 | International Business Machines Corporation | Apparatus and method for ensuring data integrity of unauthenticated code |
CN1293739C (en) * | 2002-06-15 | 2007-01-03 | 华为技术有限公司 | High speed link control protocol transmission processing/module and data processing/method |
US7020798B2 (en) * | 2002-06-27 | 2006-03-28 | Microsoft Corporation | Detecting low-level data corruption |
US7289998B2 (en) * | 2004-06-24 | 2007-10-30 | International Business Machines Corporation | Method to update a data structure disposed in an embedded device |
US7269706B2 (en) * | 2004-12-09 | 2007-09-11 | International Business Machines Corporation | Adaptive incremental checkpointing |
US7660809B2 (en) * | 2005-01-31 | 2010-02-09 | Microsoft Corporation | Using a file server as a central shared database |
CN101655824A (en) * | 2009-08-25 | 2010-02-24 | 北京广利核系统工程有限公司 | Implementation method of double-port RAM mutual exclusion access |
-
2010
- 2010-12-01 US US12/957,937 patent/US20120143836A1/en not_active Abandoned
-
2011
- 2011-11-29 DE DE112011104020T patent/DE112011104020T5/en active Pending
- 2011-11-29 GB GB1311637.1A patent/GB2500348B/en active Active
- 2011-11-29 CN CN201180057946.6A patent/CN103238142B/en not_active Expired - Fee Related
- 2011-11-29 WO PCT/EP2011/071309 patent/WO2012072644A1/en active Application Filing
-
2012
- 2012-04-26 US US13/456,388 patent/US20120209821A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030145210A1 (en) * | 2002-01-31 | 2003-07-31 | Sun Microsystems, Inc. | Method, system, program, and data structure for implementing a locking mechanism for a shared resource |
US20070168793A1 (en) * | 2006-01-09 | 2007-07-19 | Samsung Electronics Co., Ltd. | Device and method capable of verifying program operation of non-volatile memory and method card including the same |
Also Published As
Publication number | Publication date |
---|---|
DE112011104020T5 (en) | 2013-08-29 |
CN103238142A (en) | 2013-08-07 |
CN103238142B (en) | 2016-06-29 |
GB2500348A (en) | 2013-09-18 |
US20120143836A1 (en) | 2012-06-07 |
GB201311637D0 (en) | 2013-08-14 |
US20120209821A1 (en) | 2012-08-16 |
GB2500348B (en) | 2019-08-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8943082B2 (en) | Self-assignment of node identifier in a cluster system | |
US9069571B2 (en) | Propagation of unique device names in a cluster system | |
US8788465B2 (en) | Notification of configuration updates in a cluster system | |
US10178184B2 (en) | System and method for session handling in a multitenant application server environment | |
US9727273B1 (en) | Scalable clusterwide de-duplication | |
US10922303B1 (en) | Early detection of corrupt data partition exports | |
US8301600B1 (en) | Failover recovery in a distributed data store | |
US9262324B2 (en) | Efficient distributed cache consistency | |
US9460183B2 (en) | Split brain resistant failover in high availability clusters | |
US7778970B1 (en) | Method and system for managing independent object evolution | |
US11709743B2 (en) | Methods and systems for a non-disruptive automatic unplanned failover from a primary copy of data at a primary storage system to a mirror copy of the data at a cross-site secondary storage system | |
US11010265B2 (en) | Decentralized data protection system using local metadata | |
TWI511046B (en) | Dynamic cli mapping for clustered software entities | |
EP3745269B1 (en) | Hierarchical fault tolerance in system storage | |
US7743167B2 (en) | Method and system for servicing requests in a dynamic cluster | |
US10455019B2 (en) | Highly performant reliable message storage using in-memory replication technology | |
US12001290B2 (en) | Performing a database backup based on automatically discovered properties | |
US20180322301A1 (en) | Commit and rollback of data streams provided by partially trusted entities | |
GB2500348B (en) | Validation of access to a shared data record subject to read and write access by multiple requesters | |
US11341009B1 (en) | Directing placement of data in cloud storage nodes | |
US11108730B2 (en) | Group heartbeat information in a domain name system server text record | |
EP3534588A1 (en) | Network policy exchanging method and system | |
Eberhardt et al. | Smac: State management for geo-distributed containers | |
CN112925662B (en) | Identification generation method and device | |
US20200311037A1 (en) | State information file locations based on version number |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11788839 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 112011104020 Country of ref document: DE Ref document number: 1120111040202 Country of ref document: DE |
|
ENP | Entry into the national phase |
Ref document number: 1311637 Country of ref document: GB Kind code of ref document: A Free format text: PCT FILING DATE = 20111129 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1311637.1 Country of ref document: GB |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 11788839 Country of ref document: EP Kind code of ref document: A1 |