IBM WebSphere eXtreme Scale V7.0
IBM WebSphere eXtreme Scale V7.0 HTTP session management
This presentation will cover WebSphere® eXtreme Scale V7.0 HTTP session management.
HTTP session persistence
HTTP session persistence eXtreme Scale servlet filter to manage HTTP sessions Upgrade existing session persistence mechanism Can be inserted into any Web application Enhanced session persistence Advanced session replication HTTP sessions can be replicated across servers Independent of the WebSphere cell infrastructure Older versions of WebSphere products Other servers Geronimo, JBoss, Other J2EE 1.4 or higher
WebSphere eXtreme Scale can be used to manage your HTTP session data. You can override the default session manager in the base application server to provide HTTP session management capabilities for an associated application. The eXtreme Scale session manager will fully manage the life cycle of HTTP sessions that belong to the application. The eXtreme Scale session manager is compatible with any J2EE 1.4 or higher servlet container, so it can support older versions of WebSphere Application Server and other vendors’ server environments.
eXtreme Scale HTTP session configuration
Internet eXtreme Scale HTTP session configuration Web application eXtreme Scale filter Servlet application Application logic eXtreme Scale HTTPServletRequest eXtreme Scale HTTPServletResponse eXtreme Scale HTTPSession HTTP response HTTP request eXtreme Scale grid container eXtreme Scale replica container Replicate
This diagram summarizes the operation of the eXtreme Scale session filter. This filter intercepts every request to the Web application. Before passing control to the application servlet or JSP, it wraps the HTTPServletRequest and HTTPServletResponse objects that the application uses to access the request’s session state in an eXtreme Scale HTTPSession object. The eXtreme Scale HTTPSession object overrides the default session manager’s implementation, so there is no data duplication between the two session managers. The eXtreme Scale session filter normally stores session state in a grid container in the local process. This provides low latency read and write operations when running with asynchronous replication. The filter will ensure that the session data is persisted to the grid and the grid will ensure the data remains highly available.
HTTP session replication
HTTP session replication Session located in the JVM that creates it Persisted to eXtreme Scale container Session changes replicated to backup partition A shard in a separate process Automatic failover Session data does not exist locally State is automatically retrieved from remote servers This can happen when servers fail Replication zones Hints to ensure replicas are
HTTP session objects in the eXtreme Scale grid can be replicated for high availability of session data. The primary data location is the Java™ Virtual Machine that originally created the session object. As the application makes changes to the session data, the grid replicates the changes to one or more shards located in separate server processes. The failure of one server in a cluster will not affect the session. If a session object is not found locally, perhaps due to a loss of affinity, the grid will automatically retrieve the session state from a designated backup server. This prevents the loss of session data, and provides for high-speed recovery in the event of a server failure
Configuration
Configuration splicer.properties file Input to splicer utility Provides ObjectGrid configuration details “Splice” HTTP servlet filter into a Web application Run script “addObjectGridFilter.[bat|sh] ” Modifies WEB-INF/web.xml Part of application Adds initialization parameters to tune HTTP session management Deploy application
To activate the HTTP servlet filter provided by WebSphere eXtreme Scale you must “splice” the filter into your application. eXtreme Scale includes a script, addObjectGridFilter, to add the filter to your application. The script takes two parameters: the absolute path to the application to be spliced, and the location of a file that contains various configuration properties. The splicer utility modifies the application’s deployment descriptor, web.xml, with additional parameters which control how the filter interacts with the WebSphere eXtreme Scale grid. Follow the normal procedure to deploy the new application to your application server. The servlet filter will be started as part of the application initialization.
HTTP session topology
HTTP session topology Router A,B H’,E’ C,D G’,F’ G,H B’,D’ E,F C’,A’ Router sends new requests to any server Server persists session to a local grid instance Session cookie for router affinity Session changes are replicated Plug-in replicates to local primary partition Grid replicates to remote backups Failover to any server Will retrieve session from replica partition One additional remote procedure call using normal routers
A router, such as the IBM HTTP Server or On Demand Router, will route new requests to an available server. A “new” request is one that is not already associated with a session. The eXtreme Scale servlet filter will create a session object in a local grid instance, and associate that session instance with the session ID. The router will use the session ID to ensure subsequent requests for the session are sent to the same server instance. When session affinity is used, then the ObjectGrid session can be accessed directly in memory with no network cost. This allows very large sessions to be used efficiently.
Multi-cell HTTP session topology
Multi-cell HTTP session topology Router Cell A A,B C’,D’ C,E’ B’,A’ Cell B E, … D’,A’ D,B’ C’,E’ Router Multiple cells share a single catalog server Shared catalog can be: Its own cell Running in both deployment managers Running in stand-alone JVMs Deploy the application to each cell Zone rules can be used to influence placement IP Sprayer Shared Catalog
eXtreme Scale can also act as a mechanism to persist HTTP session objects across multiple WebSphere cells. You use a shared catalog to distribute primary and replica shards, and an IP sprayer to route requests between cells. Additionally, zone rules can be used to influence placement for the required availability. This diagram shows how zones can be used to place at least one backup for a session in a different cell from the primary. If Cell ‘A’ becomes unavailable, all of it’s sessions can fail-over to Cell ‘B’.
Summary
Summary WebSphere eXtreme Scale can act as a mechanism to persist HTTP session objects Implemented as a simple servlet filter Allows for session persistence across an eXtreme Scale grid Session objects held in cheap JVM memory Session changes are replicated to ensure fault tolerance and high availability When session affinity is used, session data can be accessed directly in memory
WebSphere eXtreme Scale contains a servlet session filter that can be used to persist and host your HTTP session data in the grid. Session changes are replicated to other application servers in the grid to ensure fault tolerance and high availability. When session affinity is used, the session data can be accessed directly in memory with no network cost.
Trademarks