Patent Grant
8788465
The present application is related to the following commonly owned copending patent applications, which are filed on even date herewith and are incorporated herein by reference:
1. Technical Field
The present invention relates in general to data processing, and in particular, to cluster data processing systems.
2. Description of the Related Art
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 centers, 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. When a node, component, or application fails, the software quickly establishes an alternative path to the desired resource. The brief interruption required to reestablish 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. In particular, 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.
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. In a small cluster, the 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 configuration database and performs adequately as long as the cluster size remains small. In a very large cluster, however, the overhead associated with full replication of the cluster configuration database can be prohibitively high.
Another central issue in cluster system management is the handling of cluster partitions. 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. When a cluster partition occurs, for example, at system startup 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. 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.
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. In a conventional cluster implementation, the identifiers are assigned by a central naming authority so that the identifiers can be guaranteed to be universally unique in the cluster. However, 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 preexisting identifier upon joining the cluster.
In at least one embodiment, 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. In response to receiving the message, the second node attempts to find the shared data storage device. In response to finding 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.
With reference now to
As shown, 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. In various embodiments, 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. In a preferred embodiment, at least one of operating systems 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. As described further below, the operating system infrastructure supports unique cluster-wide node and storage device naming across the cluster. In one preferred embodiment, this clustering capability is provided by cluster-aware AIX®, an open standards-based UNIX® operating system available from International Business Machines Corporation of Armonk, N.Y.
As further illustrated in
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.
Those of ordinary skill in the art will appreciate that the hardware and software employed in a cluster system, such as the exemplary data processing environment depicted in
To permit resource sharing between certain nodes 102 in data processing environment 100 while preventing unauthorized access to the shared resources by other nodes 102, clients or other devices, 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. In one preferred embodiment depicted in
Hard disk 202 includes a boot sector 204 containing the information required to boot the host node 102 under one of operating systems 122. In accordance with a preferred embodiment, 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. At a minimum, cluster configuration database 200 identifies which nodes 102 are authorized to join a cluster and thus access shared cluster resources.
With reference now to
The payload 304 of 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
As noted above, 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. 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.
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. As will be appreciated, 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. However, in a cluster environment, the migration of software and hardware resources between nodes 102 is hampered by use of inconsistent resource identifiers by different nodes 102 to identify the same resource. Accordingly, cluster configuration database 200 preferably includes support for the generation of unique names for shared data storage devices 114. In the depicted embodiment, this support includes a reserved prefix buffer 330 that holds a reserved prefix of the names of shared data storage devices 114. In addition, 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.
Thus, as shown in
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 UUID) 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.
With reference now to
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. Thus, at the time first node 102 initiates the cluster configuration operation, first node 102 may or may not already be a member of the cluster.
In addition, at block 504, 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. In one embodiment, 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
As shown at block 506, 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. Thereafter, the process depicted in
Referring now to
The process shown in
In response to receiving a stimulus to read cluster configuration database 200, second node 102 determines at block 604 whether or not it already has a self-assigned UUID. In making the determination depicted at block 604, 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
If 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
Returning to block 622, 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. As discussed further below with reference to
As previously noted, 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
The preceding discussion has described access to cluster configuration database 200 by a first node 102 and a second node 102. However, because cluster configuration database 200 is itself a shared resource of the cluster, 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. To ensure integrity of the data records 302 of cluster configuration database 200 in the presence of contemporaneous access by multiple nodes 200, access to cluster configuration database 200 is preferably coordinated between nodes utilizing an agreed protocol.
In many environments supporting concurrent access to shared data records, 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. However, in the case of cluster configuration database 200, the infrastructure on which such coordination relies (e.g., software or communication protocols) may not be available when a node 102 accesses cluster configuration database 102, for example, early in the boot process of that node 102.
Accordingly, access by multiple nodes 102 to cluster configuration database 200, and more broadly, access by multiple requesters to shared data records, can be effectively coordinated without recourse to higher level software and communication protocols as illustrated in
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. At block 704, 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
Returning to block 710, if the calculated checksum does not match the checksum read from cluster configuration database 200, then two possibilities exist: (1) the data record 302 is in the process of being updated or (2) data record 302 is corrupt. To differentiate these cases, 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.
If the calculated checksum now matches the value of checksum field 306 at block 710, then the update of data record 302 has completed, and the data record 302 is validated as previously described. If, however, the calculated checksum does not equal the value of checksum field 306, operating system 122 again determines at block 720 whether or not the calculated checksum is equal to the previous checksum recorded at block 730. If not, then the update to the data record 302 is ongoing, and the process iterates as previously described. If, however, operating system 122 determines at block 720 that the calculated checksum matches the previous checksum, then data record 302 is not the target of an ongoing update and is instead corrupted, as indicated at block 722. Consequently, the process illustrated in
As should be appreciated, the process for reading a shared data record depicted in
Referring now to
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. In response to acquisition of the inter-node lock on the target data record 302, 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
With reference now to
The process shown in
If, however, a matching UDID (or UUID) is found in the node configuration, 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
As has been described, in at least one embodiment, in response to a stimulus indicating configuration of a node into a cluster of a plurality of nodes including the node, 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. The node searches a cluster configuration database for a temporary identifier associated with the node. In response to the node locating the temporary identifier of the node in the cluster configuration database, the node writes its self-assigned UUID into the cluster configuration database and joins the cluster.
According to another aspect, 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. In response to finding a matching device identifier in the cluster configuration database, 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.
According to yet another aspect, in a method of access to a shared data record subject to contemporaneous read and write access by multiple requesters, 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.
According to yet another aspect, 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. In response to receiving the message, the second node attempts to find the shared data storage device. In response to finding 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.
In each of the flowcharts above, 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. In some implementations, 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. Thus, while 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.
It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
Thus, 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.
Any combination of one or more computer-readable medium(s) may be utilized. 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. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, 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. In the latter scenario, 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).
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.
As will be further appreciated, the processes in embodiments of the present invention may be implemented using any combination of software, firmware or hardware. As a preparatory step to practicing the invention in software, 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.
Thus, it is important that while an illustrative embodiment of the present invention is described in the context of a fully functional computer (e.g., server) system with installed (or executed) software, those skilled in the art will appreciate that the software aspects of an illustrative embodiment of the present invention are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the present invention applies equally regardless of the particular type of media used to actually carry out the distribution.
While the invention has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular system, device or component thereof to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiments disclosed for carrying out this invention, but that the invention will include all embodiments falling within the scope of the appended claims. Moreover, the use of the terms first, second, etc. do not denote any order or importance, but rather the terms first, second, etc. are used to distinguish one element from another.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5490270 | Devarakonda et al. | Feb 1996 | A |
| 5553239 | Heath et al. | Sep 1996 | A |
| 5612865 | Dasgupta | Mar 1997 | A |
| 5666486 | Alfieri et al. | Sep 1997 | A |
| 5870759 | Bauer et al. | Feb 1999 | A |
| 5870765 | Bauer et al. | Feb 1999 | A |
| 5881316 | Chaney et al. | Mar 1999 | A |
| 5884325 | Bauer et al. | Mar 1999 | A |
| 5898836 | Freivald et al. | Apr 1999 | A |
| 6014669 | Slaughter et al. | Jan 2000 | A |
| 6038625 | Ogino et al. | Mar 2000 | A |
| 6047332 | Viswanathan et al. | Apr 2000 | A |
| 6108699 | Moiin | Aug 2000 | A |
| 6119131 | Cabrera et al. | Sep 2000 | A |
| 6163806 | Viswanathan et al. | Dec 2000 | A |
| 6219818 | Freivald et al. | Apr 2001 | B1 |
| 6256740 | Muller et al. | Jul 2001 | B1 |
| 6269374 | Chen et al. | Jul 2001 | B1 |
| 6353898 | Wipfel et al. | Mar 2002 | B1 |
| 6453426 | Gamache et al. | Sep 2002 | B1 |
| 6467050 | Keung | Oct 2002 | B1 |
| 6662219 | Nishanov et al. | Dec 2003 | B1 |
| 6694459 | Nyman | Feb 2004 | B1 |
| 6748429 | Talluri et al. | Jun 2004 | B1 |
| 7010617 | Kampe et al. | Mar 2006 | B2 |
| 7103616 | Harmer et al. | Sep 2006 | B1 |
| 7107267 | Taylor | Sep 2006 | B2 |
| 7171476 | Maeda et al. | Jan 2007 | B2 |
| 7200626 | Hoang et al. | Apr 2007 | B1 |
| 7269706 | Agarwal et al. | Sep 2007 | B2 |
| 7289998 | Kalos | Oct 2007 | B2 |
| 7401093 | Hamilton et al. | Jul 2008 | B1 |
| 7441159 | Meng et al. | Oct 2008 | B2 |
| 7593968 | Beck | Sep 2009 | B2 |
| 7617257 | Sathyanarayan et al. | Nov 2009 | B2 |
| 7617289 | Srinivasan et al. | Nov 2009 | B2 |
| 8095753 | Pandey et al. | Jan 2012 | B1 |
| 20020002582 | Ewing et al. | Jan 2002 | A1 |
| 20020042693 | Kampe et al. | Apr 2002 | A1 |
| 20020059465 | Kim | May 2002 | A1 |
| 20040078455 | Eide et al. | Apr 2004 | A1 |
| 20040088294 | Lerhaupt | May 2004 | A1 |
| 20040199486 | Gopinath et al. | Oct 2004 | A1 |
| 20050015471 | Zhang et al. | Jan 2005 | A1 |
| 20050171927 | Chan et al. | Aug 2005 | A1 |
| 20060100981 | Jones et al. | May 2006 | A1 |
| 20060167921 | Grebus et al. | Jul 2006 | A1 |
| 20060173932 | Cortright et al. | Aug 2006 | A1 |
| 20070168793 | Seo | Jul 2007 | A1 |
| 20070276833 | Sen et al. | Nov 2007 | A1 |
| 20080052455 | Ahmadian et al. | Feb 2008 | A1 |
| 20090172195 | Risbud | Jul 2009 | A1 |
| 20100154054 | Beck | Jun 2010 | A1 |
| Number | Date | Country |
|---|---|---|
| 1094651 | Apr 2001 | EP |
| 1197862 | Apr 2002 | EP |
| Entry |
|---|
| Ghemawat et al., “The Google File System”; SOSP '03, Oct. 19-22, 2003, Bolton Landing, New York; 15 pp. |
| Gordon, Susan, “Database Integrity: Security, Reliability, and Performance Considerations”; Indiana University South Bend, South Bend, IN; 12 pp. |
| Herminghaus et al., “Storage Management in Data Centers—Chap. 11.3 Disk Outage in Detail”; http://books.google.com; 1 pg. |
| Nick et al., “S/390 cluster technology: Parallel Sysplex”; http://researchweb.watson.ibm.com/journals/sj/362/nick.pdf; 33 pp. |
| Vogels et al., “The Design and Architecture of the Microsoft Cluster Service”; Published in the Proceedings ofFTCS'98, Jun. 23-25, 1998, Munich, Germany; IEEE; 11 pp. |
| Kronenberg et al., “VAXclustersr: A Closely-Coupled Distributed System”; Dept. of Computer Science, University of Washington, Seattle, WA; 1986 ACM 0734-0261; 17 pp. |
| Singh, Kamal; CS article—Nov. 16, 2005; http://www.cs.sjsu.edu/faculty/stamp/CS249/projects/Chapter14.pdf; 54 pp. |
| U.S. Appl. No. 12/957,980 entitled “Propagation of Unique Device Names in a Cluster System” Non-final office action dated Nov. 19, 2012, 13 pg. |
| International Business Machines Corporation; Int'l Appln. No. PCT/EP2011/071367; International Search Report and Written Opinion dated May 15, 2012, 11 pg. |
| Ghemawat, et al. “The Google File System”; SOSP '03, Oct. 19-22, 2003, Bolton Landing, NY.; 15 pp. |
| Gordon, Susan. “Database Integrity: Security, Reliability, and Performance Consideration”; Indiana University South Bend, South Bend, IN; 12 pg. |
| Herminghaus, et al., “Storage Management in Data Centers—Chap. 11.3 Disk Outage in Detail”; http//books.google.com; 1 pg. |
| Nick, et al., “S/390 cluster technology: Parallel Sysplex”; http://researchweb.watson.ibm.com/journals/sj/362/nick.pdf; 33 pg. |
| Vogels, et al., “The Design and Architecture of the Microsoft Cluser Service”; Published in the Proceedings of FTCS'98, Jun. 23-25, 1998, Munich, Germany; IEEE; 11 pg. |
| Kronenberg et al., “VAXclusters: A Closely-Coupled Distributed System”; Dept. of Computer Science, University of Washington, Seattle, WA; 1986 ACM 0734-0261; 17 pg. |
| Singh, Kamal, CS article—Nov. 16, 2005; http://www/cs/sjsu.edu/faculty/stamp/CS249/projects/Chapter14.pdf; 54 pg. |
| International Business Machines Corporation; Int'l Appln. No. PCT/EP2011/071309; International Search Report and Written Opinion dated Mar. 14, 2012, 13 pg. |
| U.S. Appl. No. 12/957,980 entitled “Propagation of Unique Device Names in a Cluster System”; Non-final office action dated Aug. 1, 2013 (15 pg). |
| U.S. Appl. No. 12/957,894 entitled “Self-Assignment of Node Identifier in a Cluster System”; Non-final office action dated Aug. 15, 2013 (11 pg). |
| U.S. Appl. No. 12/957,894 entitled “Self-Assignment of Node Identifier in a Cluster System”; Non-final office action dated Feb. 6, 2013 (16 pg). |
| U.S. Appl. No. 13/456,388 entitled “Validation of Access to a Shared Data Record Subject to Read and Write Access by Multiple Requesters”; Final office action dated Jun. 13, 2013 (16 pg). |
| U.S. Appl. No. 13/456,388 entitled “Validation of Access to a Shared Data Record Subject to Read and Write Access by Multiple Requesters”; Non-final office action dated Feb. 6, 2013 (16 pg). |
| U.S. Appl. No. 12/957,937 entitled “Validation of Access to a Shared Data Record Subject to Read and Write Access by Multiple Requesters”; Non-final office action dated Feb. 6, 2013 (32 pg). |
| U.S. Appl. No. 12/957,937 entitled “Validation of Access to a Shared Data Record Subject to Read and Write Access by Multiple Requesters”; Final office action dated Jun. 13, 2013 (17 pg). |
| U.S. Appl. No. 12/957,980 entitled “Propagation of Unique Device Names in a Cluster System”; Final office action dated Jun. 17, 2013 (16 pg). |
| Number | Date | Country | |
|---|---|---|---|
| 20120143829 A1 | Jun 2012 | US |
