Create a clustered eXtreme Scale session grid
Home


Creating a clustered eXtreme Scale session grid


Overview

We will create a cluster of two application servers to host our session grid. We are creating this cluster with only two members for simplicity and to demonstrate a clustered grid setup. However, the number of servers we will need to host the grid depends on the amount of session data the Portal application stores.


Set up the grid cluster

  1. In the administrative console, click...

    Servers | Clusters | WebSphere application server clusters | New

  2. Enter a cluster name, for example, XS Session Grid Cluster. Click Next.

  3. Add the first cluster member with the appropriate details.

    • Member name: XS_GridCluster_Member1.
    • Select the node you want the servers to run on.
    • Click Next.

  4. Create additional cluster members. For our sample environment, we will add only one additional member to make it a two member cluster.

    • Member name: XS_GridCluster_Member2.
    • Click Add Member.
    • Click Next.

  5. Review the Summary and click Finish.

  6. Save the changes.


Configure the WXS session grid

To set up the session grid, we will need to package the objectGridStandAlone.xml and objectGridDeploymentStandAlone.xml files into an EAR file and deploy it on WAS Server. These files define the grid and its deployment configuration. The "stand-alone" files are used for the configuration because they define a remote grid for HTTP sessions, which is the topology we are deploying.

  1. Locate the objectGridStandAlone.xml and objectGridDeploymentStandAlone.xml files in...

    WAS_HOME\optionalLibraries\ObjectGrid\session\samples

  2. Create a temporary folder with a META-INF folder inside it. Place these files in the META-INF folder.

  3. Modify the configuration files.

    objectGridStandAlone.xml contains the grid definition required by WXS to host session data. This file does not require any editing.

    <?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="session"> <bean id="ObjectGridEventListener" className="com.ibm.ws.xs.sessionmanager.SessionHandleManager"/> <backingMap name="objectgridSessionMetadata" pluginCollectionRef="objectgridSessionMetadata" readOnly="false" lockStrategy="PESSIMISTIC" ttlEvictorType="LAST_ACCESS_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES"/> <backingMap name="objectgridSessionAttribute.*" template="true" readOnly="false" lockStrategy="PESSIMISTIC" ttlEvictorType="NONE" copyMode="COPY_TO_BYTES"/> <backingMap name="objectgridSessionTTL.*" template="true" readOnly="false" lockStrategy="PESSIMISTIC" ttlEvictorType="LAST_ACCESS_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES"/> </objectGrid> </objectGrids> <backingMapPluginCollections> <backingMapPluginCollection id="objectgridSessionMetadata"> <bean id="MapEventListener" className="com.ibm.ws.xs.sessionmanager.MetadataMapListener"/> </backingMapPluginCollection> </backingMapPluginCollections> </objectGridConfig>

    objectGridDeploymentStandAlone.xml contains the deployment configuration that WXS will use to create the grids. Use this with default values. However, it is advised that you review the contents.

    <?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="session">
    
            <mapSet name="sessionMapSet" 
                numberOfPartitions="5" 
                minSyncReplicas="0" 
                maxSyncReplicas="0" 
                maxAsyncReplicas="1" 
                developmentMode="true" 
                numInitialContainers="2"
                placementStrategy="PER_CONTAINER">
    
               
    <map ref="objectgridSessionMetadata"/>
    <map ref="objectgridSessionAttribute.*"/>
    <map ref="objectgridSessionTTL.*"/>
    
           
    </mapSet>
       
    </objectgridDeployment>
    
    </deploymentPolicy>
    

    Revise the following parameters and change them as appropriate.

    • numInitialContainers

      This should be equal to the number of application servers in the topology. However, if the number of initial containers is lower than the number of application servers, it will lead to an imbalanced grid. The placement will not start till these many containers are started.

    • numberOfPartitions

      The default value is 5, which means that each container instance will start five new primaries, with its replicas spread across the other servers. The higher the value of numberOfPartitions, the more the work is spread out in event of a failover. The default works in most cases.

    • developmentMode

      This attribute influences where a shard is placed in relation to its peer shards. When set to false, (the default) a replica shard will not be placed on the same physical node as the primary. When set to true, shards from the same partition can be placed on the same physical machine. In either case, no two shards from the same partition are ever placed in the same container.

      For the purpose of this sample environment, because we have both grid containers on the same physical node, we have to set the developmentMode to true to be able to see replicas placed in our grid.

    • placementStrategy

      There are two placement strategies.

      The default strategy is FIXED_PARTITION, where the number of primary shards that are placed across available containers is equal to the number of partitions defined. In a single-container configuration this will be the total number of shards. In a multiple-container configuration, the total number of shards will be a multiple of this number, depending upon how many replicas are configured.

      The alternate strategy is PER_CONTAINER, where the number of primary shards that are placed on each container is equal to the number of partitions that are defined, with an equal number of replicas placed on other containers.

      We selected PER_CONTAINER for our sample session topology to support a multi-datacenter environment where clients in one data center prefer the primary partitions that are local to that data center. A standard FIXED_PARTITIONS strategy cannot guarantee the client will always talk to a primary in its own data center.

  4. Rename objectGridStandAlone.xml to objectGrid.xml and objectGridDeploymentStandAlone.xml to objectGridDeployment.xml.

    Because we are running the containers in WAS, we must rename the *StandAlone.xml files to objectGrid.xml and objectGridDeployment.xml. The XML files must be a specific name for the grid container embedded in WAS to start.

  5. Create a WAR with the objectGrid.xml and objectGridDeplyment.xml files.

    The WAR file can be created by running the jar command from the temporary directory containing the META-INF folder. The jar command can be found in...

    WAS_HOME/java/bin

    jar -cvf GridDeployment.war *
    added manifest
    ignoring entry META-INF/
    adding: META-INF/objectGrid.xml(in = 1263) (out= 464)(deflated 63%)
    adding: META-INF/objectGridDeployment.xml(in = 712) (out= 340)(deflated 52%)
    

  6. Deploy the WAR file on the application server using the following steps:

    • On the WebSphere administrative console, click...

      Applications | New Application | New Enterprise Application | Browse for the Local file system | GridDeployment.war | Next

    • On Preparing for the application installation, leave the default as Fast Path and click Next.

    • For the remainder of the installation, use all of the defaults except for...

      Step 2: Map modules to servers

      .. which prompts you to select the GridDeployment.war module. Instead, select XS Session Grid Cluster and click Apply.

    • On the Summary page, click Finish and save the changes.

Now, start the grid and verify the grid configuration.

  1. To start the WXS Grid using the administrative console, click...

    Servers | Clusters | WAS Clusters | XS Session Grid Cluster | Start

  2. When the cluster starts, all of the cluster members start. Verify the grid configuration by looking at the SystemOut.log files. You will come across grid related log entries in the following order:

    • WXS version information...

      [11/2/10 23:39:36:152 EDT] 00000000 RuntimeInfo I CWOBJ0903I: The internal version of WebSphere eXtreme Scale is v4.0 (7.1.0.0) WXS7.1.0.XS [a1025.57350].

      The version information displayed in this message will reflect the fixpacks installed on the setup.

    • Web module and grid startup...

      [11/2/10 23:39:49:402 EDT] 0000001b PeerManagerSe I CWOBJ7700I: Peer Manager service started successfully in server (com.ibm.ws.objectgrid.leader.PeerManager@1c3d1c3d) with core group (DefaultCoreGroup).

      [11/2/10 23:39:50:059 EDT] 00000018 PeerManager I CWOBJ8601I: PeerManager found peers of size 2

      [11/2/10 23:39:50:496 EDT] 0000001b ServerImpl I CWOBJ8000I: Registration is successful with zone (DefaultZone) and coregroup of (saw006-sys2Cell01DefaultCoreGroup).

      [11/2/10 23:39:50:512 EDT] 0000001b ServerImpl I CWOBJ1001I: ObjectGrid Server saw006-sys2Cell01\saw006-sys2Node01\XS_GridCluster_Member1 is ready to process requests.

      [11/2/10 23:39:50:715 EDT] 0000001b XmlObjectGrid I CWOBJ4701I: Template map info_server.* is configured in ObjectGrid IBM_SYSTEM_xsastats.server.

      [11/2/10 23:39:50:887 EDT] 0000001b XmlObjectGrid I CWOBJ4701I: Template map objectgridSessionAttribute.* is configured in ObjectGrid session.

      [11/2/10 23:39:50:887 EDT] 0000001b XmlObjectGrid I CWOBJ4701I: Template map objectgridSessionTTL.* is configured in ObjectGrid session.

      [11/2/10 23:39:51:559 EDT] 0000001b webapp I com.ibm.ws.webcontainer.webapp.WebGroupImpl WebGroup SRVE0169I: Loading Web Module: GridDeployment.war.

    • WXS partitions and replicas activating.

      [11/2/10 23:39:52:356 EDT] 00000026 ReplicatedPar I CWOBJ1511I: IBM_SYSTEM_xsastats.server:IBM_SYSTEM_ENTITYMANAGER_MAPSET:0 (primary) is open for business.
      [11/2/10 23:39:52:387 EDT] 00000027 ReplicatedPar I CWOBJ1511I: IBM_SYSTEM_xsastats.server:stats:0 (primary) is open for business.
      [11/2/10 23:39:52:387 EDT] 00000028 ReplicatedPar I CWOBJ1511I: session:IBM_SYSTEM_ENTITYMANAGER_MAPSET:0 (primary) is open for business.
      [11/2/10 23:39:54:559 EDT] 00000029 ReplicatedPar I CWOBJ1511I: session:sessionMapSet:0 (primary) is open for business.
      [11/2/10 23:39:54:762 EDT] 0000002a ReplicatedPar I CWOBJ1511I: session:sessionMapSet:1 (primary) is open for business.
      [11/2/10 23:39:54:809 EDT] 0000002b ReplicatedPar I CWOBJ1511I: session:sessionMapSet:2 (primary) is open for business.
      [11/2/10 23:39:55:293 EDT] 0000002c ReplicatedPar I CWOBJ1511I: session:sessionMapSet:3 (primary) is open for business.
      [11/2/10 23:39:55:699 EDT] 0000002d ReplicatedPar I CWOBJ1511I: session:sessionMapSet:4 (primary) is open for business.


+

Search Tips   |   Advanced Search