System and method for using a data replication service to manage a configuration repository

• US 7,617,289 B2
• Filed: 02/20/2003
• Issued: 11/10/2009
• Est. Priority Date: 02/22/2002
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: BEA Systems Incorporated (Oracle Corporation)
• Inventors: Srinivasan, Ananthan, Kramer, Reto, Jacobs, Dean B.
• Primary Examiner(s): Etienne; Ario
• Assistant Examiner(s): Burgess; Barbara N
• Application Number:
  US10/371,247
• Publication Number:
  US 20040025079A1
• Time in Patent Office: 2,455 Days
• Field of Search: 709/208, 709/209, 709/203, 709/211, 709/220, 709/223, 709/224, 709/248, 707/203, 707/200, 707/100, 714/15, 714/16
• US Class Current: 709/209
• CPC Class Codes: G06F 2201/82 Solving problems relating to consistency ensuring consistency in mirrored systems G06F11/2064
• CPC Class Codes: H04L 67/1095 Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
• CPC Class Codes: Y10S 707/99953 Recoverability
• CPC Class Codes: Y10S 707/99954 Version management

Abstract

A mechanism for making changes consistently across an application server domain or a cluster. Server configuration consistency is absolutely necessary for cluster deployments. The invention allows changes to the configuration repository and to the application deployment process to be managed via a Data Replication Service (DRS). The former requires that the configuration repository be version aware, while the latter breaks down the application deployment process into two phases—one for data distribution and processing as far as possible, and the second to expose the changes through the Java Naming and Directory Interface (JNDI).

Claims

1. A system for using a data replication service to consistently manage server configuration within a domain or cluster, comprising:

a plurality of servers within the domain or cluster, each server comprising a configuration repository that defines the configuration information of the server as a plurality of configuration elements, and wherein the configuration repository has an updated-to version number associated therewith which is updated each time a change is made to the configuration of the server by adding, removing, or changing attributes of, one or more of the plurality of configuration elements;

a master server within the plurality of servers that contains the configuration information including information about resources to be made available throughout the domain or cluster, said resources defined by the plurality of configuration elements;

a master data replication service layer that recognizes changes made at the master server to one or more of the plurality of configuration elements and that sends from said master server, data replication packets defining the changes in the master server'"'"'s configuration information, said data replication packets including the recognized changed one or more of the plurality of configuration elements, said data replication packets including both an initial-from version number, and an updated-to version number of the master server'"'"'s configuration repository, together with the configuration information that changed between the initial-from version number and the updated-to version number;

a slave data replication service layer that receives, at a slave server within the plurality of servers, the data replication packets from the master data replication service layer, and wherein the slave server determines whether the configuration information currently contained in the configuration repository at the slave server has been updated to correspond to the updated-to version number associated with a latest data replication packet received from the master server, and if the configuration information currently contained in the configuration repository at the slave server does not correspond to the updated-to version number, then the slave server requests a plurality of the data replication packets to be sent from said master server to said slave server, to match the undated-to version number at each server, including any intervening data replication packets, and wherein the slave server uses the data replication packets to update the configuration information at the slave server to match that of the master server, including adding, removing, or changing attributes of, the one or more plurality of configuration elements as necessary;

wherein the system uses a two-phase process that comprises

sending the data replication packet from the master server to a plurality of slave servers to prepare the slave servers,

waiting for each slave server to prepare to commit the changes, including receiving and preparing class files from the master server for use in providing resources, and then responding to the master server with an acknowledgment,

receiving the acknowledgment from each slave server, determining which of the slave servers have returned an acknowledgment, and then sending a commit from the master server to only those slave servers which have returned an acknowledgment, to commit the change to their configuration repository, and

updating a naming directory interface at each of those slave servers advertising the availability of the resources for use within the domain or cluster.

2. The system of claim 1 wherein said configuration information can be changed as necessary or desired, and automatically replicated from said master server to said slave server, to converge consistency of the services as defined by the configuration elements within the entirety of the domain or the cluster.

3. The system of claim 1 wherein updates to said configuration information are packaged as incremental deltas of configuration data between subsequent configuration versions.

4. The system of claim 1 wherein said slave server is a one-phase sewer which can commit to new configuration information data as soon as it is received.

5. The system of claim 1 wherein the master server keeps track of the evolution of its configuration repository over time by maintaining a list of change tuples up to and including the current version of the configuration repository, and extending backwards from the current version to the version last known to have been successfully applied to all servers in the domain or cluster, and wherein a temporarily unavailable slave server is eventually provided with the configuration information updates by being served a list of change tuples from the slave server persistent repository version to either the desired or the current version of the repository, and wherein the slave server receives the list and performs a series of updates to its configuration repository to enable it to be made up to dare.

6. The system of claim 1 wherein, for each of a new element the data replication packet is in the form of a DOM tree snippet, and wherein each data replication packet includes a scaping element specifying the place where the change applies to the DOM tree, and wherein for a particular update said waiting includes waiting to receive an ACK from all of the slave servers that are specified in the scope of the update.

7. The system of claim 1 wherein the data replication packet is in the form of a name value pair matching an attribute name with a new value for that attribute.

8. A method for using a data replication service to consistently manage server configuration within a domain or cluster, comprising the steps of:

providing a plurality of servers within the domain or cluster, each server comprising a configuration repository that defines the configuration information of the server as a plurality of configuration elements, and wherein the configuration repository has an undated-to version number associated therewith which is updated each time a change is made to the configuration of the server by adding, removing, or changing attributes of, one or more of the plurality of configuration elements;

maintaining, at a master server within the plurality of servers that contains the configuration information including information about resources to be made available throughout the domain or cluster, said resources defined by the plurality of configuration elements;

recognizing changes made at the master server to one or more of the plurality of configuration elements;

sending data replication packets from said master server to a slave server, said data replication packets defining changes in the master server'"'"'s configuration information, said data replication packets including the recognized changed one or more of the plurality of configuration elements, said data replication packets further including both an initial-from version number, and an updated-to version number of the master server'"'"'s configuration repository, together with the configuration information that changed between the initial-from version number and the updated-to version number;

receiving data replication packets at said slave server; and

determining whether the configuration information currently contained in the configuration repository at the slave server has been updated to correspond to the undated-to version number associated with a latest data replication packet received, and if the configuration information currently contained in the configuration repository at the slave server does not correspond to the undated-to version number then requesting a plurality of the data replication packets to be sent from said master server to said slave server, to match the undated-to version numbers at each server, including any intervening data replication packets, and wherein the slave server uses the data replication packets to update the configuration information at the slave server to match that of the master server, including adding, removing, or changing attributes of, the one or more plurality of configuration elements as necessary;

wherein the method uses a two-phase process that comprises

sending the data replication packet from the master server to a plurality of slave servers to prepare the slave servers,

waiting for each slave server to prepare to commit the changes, including receiving and preparing class files from the master server for use in providing resources, and then responding to the master server with an acknowledgment,

receiving the acknowledgment from each slave server, determining which of the slave servers have returned an acknowledgment, and then sending a commit from the master server to only those slave servers which have returned an acknowledgment, to commit the change to their configuration repository, and

updating a naming directory interface at each of those slave servers advertising the availability of the resources for use within the domain or cluster.

9. The method of claim 8 wherein said configuration information can be changed as necessary or desired, and automatically replicated from said master server to said slave server, to converge consistency of the services as defined by the configuration elements within the entirety of the domain or the cluster.

10. The method of claim 8 wherein updates to said configuration information are packaged as incremental deltas of configuration data between subsequent configuration versions.

11. The method of claim 8 wherein said slave server is a one-phase server which can commit to new configuration information data as soon as it is received.

12. The method of claim 8 wherein the master server keeps track of the evolution of its configuration repository over time by maintaining a list of change tuples up to and including the current version of the configuration repository, and extending backwards from the current version to the version last known to have been successfully applied to all servers in the domain or cluster, and wherein a temporarily unavailable slave server is eventually provided with the configuration information updates by being served a list of change tuples from the slave server persistent repository version to either the desired or the current version of the repository, and wherein the slave server receives the list and performs a series of updates to its configuration repository to enable it to be made up to date.

13. The computer readable medium of claim 8 wherein the master server keeps track of the evolution of its configuration repository over time by maintaining a list of change tuples up to and including the current version of the configuration repository, and extending backwards from the current version to the version last known to have been successfully applied to all servers in the domain or cluster, and wherein a temporarily unavailable slave server is eventually provided with the configuration information updates by being served a list of change tuples from the slave server persistent repository version to either the desired or the current version of the repository, and wherein the slave server receives the list and performs a series of updates to its configuration repository to enable it to be made up to date.

14. A computer readable medium, including instructions stored thereon which when executed cause the computer to perform the steps of:

providing a plurality of servers within the domain or cluster, each server comprising a configuration repository that defines the configuration information of the server as a plurality of configuration elements, and wherein the configuration repository has an undated-to version number associated therewith which is updated each time a change is made to the configuration of the server by adding, removing, or changing attributes of, one or more of the plurality of configuration elements;

maintaining, at a master server within the plurality of servers that contains the configuration information including information about resources to be made available throughout the domain or cluster, said resources defined by the plurality of configuration elements;

recognizing changes made at the master server to one or more of the plurality of configuration elements;

sending data replication packets from said master server to a slave server, said data replication packets defining the changes in the master server'"'"'s configuration information, said data replication packets including the recognized changed one or more of the plurality of configuration elements, said data replication packets further including both an initial-from version number, and an updated-to version number of the master server'"'"'s configuration repository, together with the configuration information that changed between the initial-from version number and the updated-to version number;

receiving data replication packets at said slave server; and

determining whether the configuration information currently contained in the configuration repository at the slave server has been updated to correspond to the undated-to version number associated with a latest data replication packet received, and if the configuration information currently contained in the configuration repository at the slave server does not correspond to the undated-to version number then requesting a plurality of the data replication packets to be sent from said master server to said slave server, to match the updated-to version numbers at each server, including any intervening data replication packets, and wherein the slave server uses the data replication packets to update the configuration information at the slave server to match that of the master server, including adding, removing, or changing attributes of, the one or more plurality of configuration elements as necessary;

wherein the computer readable medium further comprises instructions to perform the steps of

sending the data replication packet from the master server to a plurality of slave servers to prepare the slave servers,

waiting for each slave server to prepare to commit the changes, including receiving and preparing class files from the master server for use in providing resources, and then responding to the master server with an acknowledgment,

receiving the acknowledgment from each slave server, determining which of the slave servers have returned an acknowledgment, and then sending a commit from the master server to only those slave servers which have returned an acknowledgment, to commit the change to their configuration repository, and

updating a naming directory interface at each of those slave servers advertising the availability of the resources for use within the domain or cluster.

15. The computer readable medium of claim 14 wherein said configuration information can be changed as necessary or desired, end automatically replicated from said master server to said slave server, to converge consistency of the services as defined by the configuration elements within the entirety of the domain or the cluster.

16. The computer readable medium of claim 14 wherein updates to said configuration information are packaged as incremental deltas of configuration data between subsequent configuration versions.

17. The computer readable medium of claim 14 wherein said slave server is a one-phase server which can commit to new configuration information data as soon as it is received.