Configure the WXS dynamic cache grid

Home | Previous | Next

Configure the WXS dynamic cache grid

Overview

The next step is to configure the dynamic cache grid.

Create a new WAS cluster of two application servers. In a production environment, use at minimum three cluster members to ensure an even spread of data in the grid. Sizing considerations will dictate how many application servers you need for the grid.

Create the application server cluster

From the WAS console...

Servers | Clusters | WAS clusters | New | cluster_name | Next

Add in the first application server cluster member with appropriate details:

Member name: WXS_DC_ClusterMember1.
Enter Node that the application server is going to run on.
Click Next.

Add additional application server cluster members.
In this scenario, we created one additional application server, to have a total of two cluster members.

Enter the member name: WXS_DC_ClusterMember2.
Click Add Member.
Click Next.

Review the summary and click Finish.

Save the changes.

Set JVM heap size at 1500 Mb as a starting point and tune as needed.

To leave more memory for WXS, switch on the WAS v7 feature...

Start components as needed

Deploy the dynamic cache grid

We need to package the WXS configuration files into a WAR file.
WXS provides default configuration files for the dynamic cache grid in...

WAS_HOME/optionalLibraries/ObjectGrid/dynacache/etc

Two files cover the definition of the grid and the nature of its deployment:

dynacache-remote-objectgrid.xml Definition of the grid required by WXS to host the dynamic cache data. This file should not need editing.
objectGridDeployment.xml Deployment information for the grid. Review and edit this file.

To deploy the dynamic cache grid...
Create a temporary folder location with a META-INF folder

Copy objectgrid.xml and deployment.xml into META-INF.

Rename the files...

mv objectgrid.xml objectGrid.xml
mv deployment.xml objectGridDeployment.xml

Optional: Review the contents of objectGrid.xml.
This file should not need editing.
It is possible to configure WXS to run more than one dynamic cache grid. This can be used for hosting grids for more than one Commerce or other application server environment.
To do this:

Create a separate set of objectGrid.xml and objectGridDeployment.xml files and rename objectGrid definition in the objectGrid.xml (for example, to DYNACACHE_REMOTE_2).

Edit objectGridDeployment.xml to have the same objectgridName and mapSet name.

Add an additional JVM property

com.ibm.websphere.xs.dynacache.grid_name

Deploy the grid settings alongside other grids and register them with the same catalog server(s).
Review the contents of objectGridDeployment.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="DYNACACHE_REMOTE">
    
        <mapSet name="DYNACACHE_REMOTE"
                numberOfPartitions="47"
                minSyncReplicas="0"
                maxSyncReplicas="0"
                maxAsyncReplicas="1"
                numInitialContainers="1"
                developmentMode="false"
                replicaReadEnabled="false">
        
            <map ref="IBM_DC_PARTITIONED_.*" />
        
        </mapSet>

    </objectgridDeployment>

</deploymentPolicy>
The key parameters to review and change where appropriate are:

numInitialContainers=2 Set to equal the number of application servers in the WXS grid cluster. In our example set to two.
This prevents the grid starting until all application servers in the grid have started so it can balance the partitions evenly. Without this, there will be imbalance towards the initial application server started because WXS will not move or balance partitions unless strictly necessary.
numberOfPartitions=47 The default number of partitions is a good starting place. This number can be changed in line with sizing and capacity planning considerations
maxAsyncReplicas=1 WXS provides two modes of replication:

synchronous
asynchronous

With the quality of service required by the dynamic cache service, asynchronous replication will be sufficient, and it naturally performs better than synchronous replication.
Set maxAsyncReplicas to the maximum number of asynchronous replicas you want. The default of 1 is probably sufficient and will mean that each partition will have one copy.
Zero is a viable option if you do not want to replicate the cache partitions. In this case, any cached data held on a stopped or failed JVM is lost and must be recreated. That might meet the cache availability requirement and saves memory by having no data duplication.
developmentMode=false This setting shouldn't need changing but is commented on here for convenience. If testing the grid on a single server, then by default WXS will not start replicas because it tries to put them on separate nodes from the primary for availability. For testing purposes, this can be set to true to test the impact of replication in a single node environment.
Create a WAR to deploy the WXS configuration.

$ cd TEMP
$ WAS_HOME/java/bin/jar -cvf WXSDynacacheGrid.war *
added manifest
ignoring entry META-INF/
adding: META-INF/objectGridDeployment.xml(in = 668) (out= 354)(deflated 47%)
adding: META-INF/objectGrid.xml(in = 2132) (out= 722)(deflated 66%)

Deploy the WAR file to the WXS Dynamic Cache Cluster we created earlier.

From the administrative console, select...

Applications | New Application | New Enterprise Application

Click Browse for the Local file system option and select the WXSDynacacheGrid.war file that you just created. Click Next.

On Preparing for the application installation, select the default of Fast Path and click Next.

In the next five steps of the deployment, leave the defaults except for...

Step 2: Map modules to servers

...where we will need to select WXSDynacachGrid.war module, select the WXS Dynamic Cache Cluster, then click Apply...

On the summary page, click Finish and save the changes.

To start the WXS grid, in the administrative console, click...

Servers | Clusters | WebSphere application server clusters | WebSphere eXtreme Scale Dynamic Cache Cluster | Start

When the cluster has started, check the cluster members' SystemOut.log files for messages that WXS has started successfully.
When the application server itself is starting, we will see a message similar to that below...

[10/22/10 13:19:41:468 CDT] 00000000 RuntimeInfo I CWOBJ0903I: The internal version of WXS is v4.0 (7.1.0.0) WXS7.1.0.XS [a1025.57350].

This shows that the product is correctly installed and being used by the cluster, and provides the exact product version.
Secondly, towards the end of the application server start-up, you can see where the web module starts to load. The WXS configuration has been detected in the web module and the ObjectGrid Server is started. It will also reference the template map configuration from objectGrid.xml.
A template is the prefix name for the dynamic cache grid(s) that will be created.

[10/22/10 13:20:04:515 CDT] 00000019 ApplicationMg A WSVR0200I: Starting application: WXSDynacacheGrid_war
[10/22/10 13:20:07:781 CDT] 00000019 ServerImpl I CWOBJ1001I: ObjectGrid Server thinkCell01\thinkNode02\WXS_DC_ClusterMember1 is ready to process requests.
[10/22/10 13:20:08:140 CDT] 00000019 XmlObjectGrid I CWOBJ4701I: Template map info_server.* is configured in ObjectGrid IBM_SYSTEM_xsastats.server.
[10/22/10 13:20:08:250 CDT] 00000019 XmlObjectGrid I CWOBJ4701I: Template map IBM_DC_PARTITIONED_.* is configured in ObjectGrid DYNACACHE_REMOTE.

Finally, WXS will wait until both application servers are fully started before actually starting the grid itself.
This is the importance of the numInitialContainers value in the objectGridDeployment.xml file. This value was set to 2 so that WXS will wait for both servers to start.
You will see a message when each of the partitions and their replicas that are started. A primary partition must always be on a separate cluster member than its replica.

...
[10/29/10 4:24:19:896 CDT] 00000021 AsynchronousR I CWOBJ1511I: DYNACACHE_REMOTE:DYNACACHE_REMOTE:10 (asynchronous replica) is open for business.
[10/29/10 4:24:19:896 CDT] 00000021 AsynchronousR I CWOBJ1543I: The asynchronous replica DYNACACHE_REMOTE:DYNACACHE_REMOTE:10 started or continued replicating from the primary. Replicating for maps: [xsastats_DYNACACHE_REMOTE_grid, xsastats_DYNACACHE_REMOTE_map]
[10/29/10 4:24:22:802 CDT] 00000038 ReplicatedPar I CWOBJ1511I: DYNACACHE_REMOTE:DYNACACHE_REMOTE:15 (primary) is open for business.
...
Verify the grid deployment and grid access.
Use xsadmin to query the WXS runtime configuration.
At the time of writing, there is an issue connecting to the catalog server using xsadmin from an installation of WXS v7.1 installed with WAS v7.0. The work around is to use xsadmin from a separate, stand-alone installation of WXS or upgrade to WXS V7.1.0.1. and WXS V6.1.0.5. The resolution is also available as a patch.
From the deployment manager profile bin directory, run the xsadmin commands with a -dmgr flag, telling xsadmin that it is connecting to a catalog server in a deployment manager and to use the default deployment manager ports to connect. If the deployment manager is running on a non-default bootstrap port, then specify that with the -p option.
List running grids
$ cd WAS_HOME/profiles/Dmgr01/bin/
$./xsadmin.sh -dmgr -l 

Connect to Catalog service at localhost:9809
*** Show all 'objectGrid:mapset' names 
Grid Name                  MapSet Name      
DYNACACHE_REMOTE           DYNACACHE_REMOTE 
IBM_SYSTEM_xsastats.server stats 
List all containers (JVMs) and their partitions. This lists all 47 partitions and their replicas shared evenly between the two cluster members.
$ cd WAS_HOME/profiles/Dmgr01/bin/
$ ./xsadmin -dmgr -containers 
Connect to Catalog service at localhost:9809
Warning: Detected there is more than one Placement Service MBean
*** Show all online containers for grid - DYNACACHE_REMOTE & mapset - 
DYNACACHE_REMOTE
Host: think.was7.ibm.com
Container: thinkCell01\thinkNode02\WXS_DC_ClusterMember1_C-1, 
Server:thinkCell01\thinkNode02\WXS_DC_ClusterMember1, Zone:DefaultZone
    Partition Shard Type          
    0         AsynchronousReplica 
    1         AsynchronousReplica 
    2         AsynchronousReplica 
    8         AsynchronousReplica 
    ... 
    40        Primary             
    42        Primary             
    43        Primary             
  Container: thinkCell01\thinkNode02\WXS_DC_ClusterMember2_C-1, 
Server:thinkCell01\thinkNode02\WXS_DC_ClusterMember2, Zone:DefaultZone
    Partition Shard Type          
    3         AsynchronousReplica 
    4         AsynchronousReplica 
    5         AsynchronousReplica 
    ... 
    44        Primary             
    45        Primary             
    46        Primary 
  Num containers matching = 2 
  Total known containers  = 2 
  Total known hosts       = 1 
List running partitions with number of entries and used heap in KB
xsadmin -dmgr -mapsizes 
We have now created an application server cluster that is hosting an WXS grid that we can use to store dynamic cache data from WebSphere Commerce. We have verified that the grid has been deployed and started successfully.
All of these steps involve hosting the WXS grid within WAS. It is possible to run the WXS grid outside WebSphere on stand-alone JVMs. This will function in exactly the same way and the WXS grid configuration is the same. The difference is that the stand-alone deployment will not have any management tooling for grid deployment and operational control. In the case of a stand-alone grid, the XML descriptors do not need packaging but can be referred to directly from the command line.

+
Search Tips | Advanced Search

dynacache-remote-objectgrid.xml	Definition of the grid required by WXS to host the dynamic cache data. This file should not need editing.
objectGridDeployment.xml	Deployment information for the grid. Review and edit this file.

numInitialContainers=2	Set to equal the number of application servers in the WXS grid cluster. In our example set to two. This prevents the grid starting until all application servers in the grid have started so it can balance the partitions evenly. Without this, there will be imbalance towards the initial application server started because WXS will not move or balance partitions unless strictly necessary.
numberOfPartitions=47	The default number of partitions is a good starting place. This number can be changed in line with sizing and capacity planning considerations
maxAsyncReplicas=1	WXS provides two modes of replication: synchronous asynchronous With the quality of service required by the dynamic cache service, asynchronous replication will be sufficient, and it naturally performs better than synchronous replication. Set maxAsyncReplicas to the maximum number of asynchronous replicas you want. The default of 1 is probably sufficient and will mean that each partition will have one copy. Zero is a viable option if you do not want to replicate the cache partitions. In this case, any cached data held on a stopped or failed JVM is lost and must be recreated. That might meet the cache availability requirement and saves memory by having no data duplication.
developmentMode=false	This setting shouldn't need changing but is commented on here for convenience. If testing the grid on a single server, then by default WXS will not start replicas because it tries to put them on separate nodes from the primary for availability. For testing purposes, this can be set to true to test the impact of replication in a single node environment.