Administration guide > Configure the deployment environment > Configuring catalog and container servers
Configure multi-master replication topologies
With the multi-master asynchronous replication feature, you use links to interconnect a set of domains, then eXtreme Scale synchronizes the domains, using replication over the links. Because you define the links among domains, you can construct almost any topology. Define links in the properties files of the catalog servers for each domain, or define links at runtime using Java Management Extensions (JMX) programs or the xsadmin command line utility. However you create links, the set of current links for a domain is stored in the catalog service, enabling you to add and remove links without restarting the domain (data grid).
Before you begin
Multi-master data grid replication topologies (AP) introduces you to the characteristics of various multi-master replication topologies. The following procedure describes the mechanics of configuring various links among domains to form the topology you choose. The section after the procedure provides some examples to illustrate how to set up specific topologies, such as a hub and spoke formation.
Also, map sets must have the following characteristics to replicate changes across catalog service domain links.
- The ObjectGrid name and map set name within a catalog service domain must match the ObjectGrid name and map set name of other catalog service domains. For example, ObjectGrid "og1" and map set "ms1" must be configured in domain A and domain B to replicate the data in the map set between the catalog service domains.
- Is a FIXED_PARTITION data grid. PER_CONTAINER data grids cannot be replicated.
- Has the same number of partitions in each catalog service domain, but is unrestricted with respect to the number or type of replicas.
- Has the same data types replicated in each catalog service domain.
- Contains the same maps and dynamic map templates in each catalog service domain.
Any map sets with the preceding characteristics will be replicated after the catalog service domains in the topology have been started.
Procedure
- Define links in the properties file for the catalog server of each domain in the topology, for bootstrap purposes.
The property file is detected automatically if you name it objectGridServer.properties (case sensitive on some systems) and place it on the classpath used when starting a catalog service instance. You also can specify its location on the command line to the startOgServer script, using the -serverProps parameter.
Because the property names are case sensitive, take care on capitalization when updating the property file.
- Local Domain name
- Name of "this" domain, such as domain A:
For example:
domainName=A
- An optional list of foreign domain names
Names of "other" domains in the multi-master replication topology, such as domain B:
foreignDomains=B
- An optional list of endpoints for the foreign domain names
- Connection information for the catalog servers of the foreign domains, such as domain B:
For example:
B.endPoints=hostB1:2809, hostB2:2809If a foreign domain has multiple catalog servers, specify all of them.
- Use the xsadmin command utility or JMX programming to add or remove links at runtime.
The links for a domain are kept in the catalog service in replicated memory. This set of links can be changed at any time by the administrator without requiring a restart of this domain or any other domain. The xsadmin command line utility includes several options for working with links.
The xsadmin utility connects to a catalog service and thus a single domain. Therefore, xsadmin can be used to create and destroy links between the domain it attaches to and any other domain.
Use the command line to create a new link, for example:
xsadmin –ch host –p 1099 –establishLink dname fdHostA:2809,fdHostB:2809
The command establishes a new link between the ‘local' domain and the foreign domain named “dname” whose catalog service is running at fdHostA:2809 and fdHostB:2809. The local domain has a catalog service JVM with a JMX address of host:1099. Specify all catalog endpoints from the foreign domain so that fault tolerance connectivity to the domain is possible. It is not recommended to use a single host:port pair for the catalog service of the foreign domain.
It does not matter which local catalog service JVM the xsadmin specifies using –ch and –p. Any catalog JVM will work. If the catalog is hosted in a WAS deployment manager, then the port is usually 9809.
The ports specified for the foreign domain are NOT JMX ports. They are the usual ports you would use for eXtreme Scale clients.
After the command to add a new link is issued, the catalog service instructs all containers under its management to begin replicating to the foreign domain. A link is not needed on both sides. It is only necessary to create a link on one side.
Use the command line to remove a link, for example:
xsadmin –ch host –p 1099 –dismissLink dnameThe command connects to the catalog service for a domain and instructs it to stop replicating to a specific domain. A link only needs to be dismissed from one side.
Example
Suppose that to configure a two-domain setup involving Domains A and B.
Figure 1. Link between domains
Here is the property file for the catalog server in domain A:
domainName=A foreignDomains=B B.endPoints=hostB1:2809, hostB2:2809
Here is the property file for the catalog server in domain B. Notice the similarity between the two property files.
domainName=B foreignDomains=A A.endPoints=hostA1:2809,hostA2:2809
After the two domains are started, then any data grids with the following characteristics will be replicated between the domains.
- Has a private catalog service with a unique domain name
- Has the same data grid name as other grids in the domain
- Has the same number of partitions as other data grids in the domain
- Is a FIXED_PARTITION data grid (PER_CONTAINER data grids cannot be replicated)
- Has the same number of partitions (it might or might not have the same number and types of replicas)
- Has the same data types being replicated as other data grids in the domain
- Has the same mapset name, map names, and dynamic map templates as other data grids in the domain
Note that the replication policy of a domain will be ignored.
The preceding example shows how to configure each domain to have a link to the other domain, but it is necessary only to define a link in one direction. This fact is especially useful in hub and spoke topologies, allowing a much simpler configuration. The hub property file does not require updates as spokes are added, and each spoke file needs only to include hub information. Similarly, a ring topology requires each domain to have only a link to the previous and next domain in the ring.
Figure 2. Hub and spoke topology
The hub and four spokes (domains A, B, C, and D) would have catalog server property files like the following examples.
domainName=Hub
The first spoke would have the following properties:
domainName=A foreignDomains=Hub Hub.endPoints=hostH1:2809, hostH2:2809
The second spoke would have the following properties:
domainName=B foreignDomains=Hub Hub.endPoints=hostH1:2809, hostH2:2809
The third spoke would have the following properties:
domainName=C foreignDomains=Hub Hub.endPoints=hostH1:2809, hostH2:2809
The fourth spoke would have the following properties:
domainName=D foreignDomains=Hub Hub.endPoints=hostH1:2809, hostH2:2809
Parent topic:
Configure catalog and container servers
Related concepts
Best practice: Clustering the catalog service
Topology planning for multi-master grid replication
Related tasks
Configure WebSphere eXtreme Scale with WAS
Develop custom arbiters for multi-master replication
Related reference