Use the deployment policy descriptor XML file and the objectgrid descriptor XML file to manage your topology.
For information on starting container servers, see Starting eXtreme Scale containers automatically in WebSphere Application Server applications or Starting container processes.
Endpoint information is not pre-configured in the dynamic environment. There are no server names or physical topology information found in the deployment policy. All shards in a grid are automatically placed into containers by the catalog service. The catalog service uses the constraints that are defined by the deployment policy to automatically manage shard placement. This automatic shard placement leads to easy configuration for large grids. You can also add servers to your environment as needed.
A deployment policy XML file is passed to an eXtreme Scale container during startup. A deployment policy must be used along with an ObjectGrid XML file. The deployment policy is not required to start a container, but is recommended. The deployment policy must be compatible with the ObjectGrid XML that is used with it. For each objectgridDeployment element in the deployment policy, you must have a corresponding objectGrid in your ObjectGrid XML. The maps in the objectgridDeployment must be consistent with the backingMaps found in the ObjectGrid XML. Every backingMap must be referenced within one and only one mapSet.
companyGridDpReplication.xml <?xml version="1.0" encoding="UTF-8"?> <deploymentPolicy xmlns:xsi="http://www.w3.org./2001/XMLSchema-instance" xsi:schemaLocation="http://ibm.com/ws/objectgrid/deploymentPolicy ../deploymentPolicy.xsd" xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy"> <objectgridDeployment objectgridName="CompanyGrid"> <mapSet name="mapSet1" numberOfPartitions="11" minSyncReplicas="1" maxSyncReplicas="1" maxAsyncReplicas="0" numInitialContainers="4"> <map ref="Customer" /> <map ref="Item" /> <map ref="OrderLine" /> <map ref="Order" /> </mapSet> </objectgridDeployment> </deploymentPolicy>
companyGrid.xml <?xml version="1.0" encoding="UTF-8"?> <objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd" xmlns="http://ibm.com/ws/objectgrid/config"> <objectGrids> <objectGrid name="CompanyGrid"> <backingMap name="Customer" /> <backingMap name="Item" /> <backingMap name="OrderLine" /> <backingMap name="Order" /> </objectGrid> </objectGrids> </objectGridConfig>
The companyGridDpReplication.xml file has one mapSet that is divided into 11 partitions. Each partition must have exactly one synchronous replica. The number of synchronous replicas is dictated by the minSyncReplicas and maxSyncReplicas attributes. Because the minSyncReplicas attribute is set to 1, each partition in the mapSet must have at least one synchronous replica available to process write transactions. Since maxSyncReplicas is set to 1, each partition must not exceed one synchronous replica. The partitions in this mapSet have no asynchronous replicas.
The numInitialContainers attribute instructs the catalog service to defer placement until four containers are available to support this ObjectGrid. The numInitialContainers attribute is ignored after the specified number of containers has been reached.
The companyGridDpReplication.xml file demonstrates a common way to configure a deployment policy, but a deployment policy can offer even more control over how and when your ObjectGrid is deployed into your environment. For a complete description of the deployment policy descriptor file, see Deployment policy descriptor XML file.
WebSphere eXtreme Scale automatically balances servers. You can include additional servers without restarting WebSphere eXtreme Scale. Adding additional servers without having to restart eXtreme Scale allows you to have simple deployments and also large, terabyte-sized deployments in which thousands of servers are needed. This deployment topology is flexible. With the catalog service, you can add and remove servers to better use resources without removing the entire cache. To add or remove a server, you use the startOgServer command to start a container server, which communicates with the catalog service with the -catalogServiceEndPoints option. All distributed topology clients communicate to the catalog service through the Internet Interoperability Object Protocol (IIOP). All clients use the ObjectGrid interface to communicate with servers.
The dynamic configuration capability of WebSphere eXtreme Scale makes it easy to add resources to the system. Containers host the data and the catalog service functions as the touch point for the grid. The containers are responsible for maintaining data. The catalog service is responsible for forwarding requests to the right place on first touch, allocating space in host containers, and managing health and availability of the overall system. Clients connect to a catalog service, retrieve a description of the container-server topology, and then communicate directly to each server as needed. When the server topology changes due to the addition of new servers, or due to the failure of others, the client is automatically routed to the appropriate server hosting the data.
A catalog service typically exists in its own grid of Java™ virtual machines. A single catalog service can be used to manage multiple servers. A container can be started in a JVM by itself or can be loaded into an arbitrary JVM with other containers for different servers. A client can exist in any JVM and communicate with one or more servers. A client can also exist in the same JVM as a container.
You can also create a deployment policy programmatically when embedding a container in an existing Java process or application. For more information, see the eXtreme Scale DeploymentPolicy API.