About this task Introducing WebSphere eXtreme Scale into a WebSphere Portal

About this task introducing websphere extreme scale

This preview shows page 317 - 319 out of 568 pages.

About this task Introducing WebSphere eXtreme Scale into a WebSphere Portal environment can be beneficial in the following scenarios: Chapter 6. Configuring 305
Image of page 317
Important: Although the following scenarios introduce benefits, increased processor usage in the WebSphere Portal tier can result from introducing WebSphere eXtreme Scale into the environment. v When session persistence is required. For example, if the session data from your custom portlets must stay available during a WebSphere Portal Server failure, you can persist the HTTP sessions to the WebSphere eXtreme Scale data grid. Data replicates among many servers, increasing data availability. v In a multiple data center topology. If your topology spans multiple data centers across different physical locations, you can persist the WebSphere Portal HTTP sessions to the WebSphere eXtreme Scale data grid. The sessions replicate across data grids in the data centers. If a data center fails, the sessions are rolled over to another data center that has a copy of the data grid data. v To lower memory requirements on the WebSphere Portal Server tier. By offloading session data to a remote tier of container servers, a subset of sessions are on the WebSphere Portal servers. This offload of data reduces the memory requirements on the WebSphere Portal Server tier. Procedure 1. Splice the wps WebSphere Portal application and any custom portlets to enable the sessions to be stored in the data grid. You can splice the application by configuring HTTP session management when you deploy the application, or you can use custom properties to automatically splice your applications. See “Configuring the HTTP session manager with WebSphere Application Server” on page 295 for more information about splicing the application. 2. If you are using the remote scenario, where your container servers are outside of the WebSphere Application Server, explicitly start remote eXtreme Scale containers for remote HTTP session persistence scenarios. Start the containers with the XS/ObjectGrid/session/samples/objectGridStandAlone.xml and objectGridDeploymentStandAlone.xml configuration files. For example, you might use the following command: startOgServer.sh xsContainer1 -catalogServiceEndPoints < host >:< port > -objectgridFile XS/ObjectGrid/session/samples/objectGridStandAlone.xml -deploymentPolicyFile XS/ObjectGrid/session/samples/objectGridDeploymentStandAlone.xml For more information about starting container servers, see “Starting container servers” on page 386. If you are using an embedded scenario, see “Configuring container servers in WebSphere Application Server” on page 267 for more information about configuring and starting container servers. 3. Restart the WebSphere Portal servers. See WebSphere Portal Version 7: Starting and stopping servers, deployment managers, and node agents for more information.
Image of page 318
Image of page 319

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture