scalable and robust http session management with websphere extreme scale

Scalable and robust HTTP session managementwith WebSphere eXtreme ScaleSkill Level: Introductory

Nitin Gaur ([email protected])WebSphere IT SpecialistIBM

27 May 2009

This article shows you how to use WebSphere® Extreme Scale as a separatein-memory data grid to store HTTP sessions. After describing existing software, thearticle shows how Extreme Scale addresses scalability challenges in a cost effectivemanner and simplifies the implementation of an Extreme Scale grid.

Introduction

HTTP session management is a function offered by Java Enterprise Edition (JEE)application servers. It allows JEE applications to store state information about agiven user across many HTTP requests. The JEE specification provides an API tostore and retrieve information specific to the given user. WebSphere ApplicationServers and other competing products provide session-replication functionality,normally either by writing to a database or through memory-to-memory replicationtechnology.

These approaches, while extensively used today, have operational challenges andimportant cost implications. HTTP session replication enables seamless sessionrecovery in the event of an application failure, but currently, no reliable, predictable,and cost-effective solution exists to handle session recovery in the event of adata-center failure. Until now, session replication across cells and data centers hasbeen discouraged, primarily due to cost and performance impacts. With theintroduction of WebSphere eXtreme Scale’s zone technology, you can now recoversessions in the event of a data-center failure.

This paper discusses a common usage scenario and demonstrates the

Scalable and robust HTTP session management with WebSphere eXtreme Scale© Copyright IBM Corporation 2009. All rights reserved. of 15

mailto:[email protected]

http://www.ibm.com/legal/copytrade.shtml

implementation of WebSphere eXtreme Scale (hereafter referred to as eXtremeScale) as a separate in-memory data grid to store HTTP sessions. It also delineatespast and existing technology in this context, and introduces eXtreme Scale as atechnology that differentiates itself, namely by addressing scalability challenges in acost-effective manner. Also addressed is the simplification of the Finally, we showhow eXtreme Scale simplifies the technical implementation of a grid, making it acompelling yet simple solution to store HTTP sessions.

But first, we need to define some session-related concepts:

• Session management: The process of keeping track of a user's activityacross sessions of interaction.

• Session replication: The process of replicating or copying the sessiondata or object, either to another process (in memory, see Figure 1) or to adatabase (Figure2).

• Session storage: Persistence of (session) data to an external store (orin-process memory) to provide an efficient way to share session-stateinformation across multiple machines running the same application.

Figure 1: Memory-to-memory session replication

developerWorks® ibm.com/developerWorks

Scalable and robust HTTP session management with WebSphere eXtreme Scale of 15 © Copyright IBM Corporation 2009. All rights reserved.


Figure 2: Database session replication

ibm.com/developerWorks developerWorks®



Challenges of storing HTTP sessions

Many enterprise applications today require HTTP session persistence. Thisrequirement stems primarily from end-user expectations, regulatory constraints,service level agreement (SLA) commitments, or a combination thereof. Sessionpersistence provides the application with features such as handling session-stateinformation, high availability of end-user sessions and application performanceenhancements. The WebSphere Application Server application infrastructureensures efficient session persistence management and configuration. For instance,WebSphere Application Server provides two distinct mechanisms to persistsessions: memory-to-memory replication; and storing session objects in a shared




database. While these two mechanisms provide a persistence mechanism, thevalidity of session state across clustered application servers must be ensured.

Best practices to ensure validity of session state include:

• Session affinity: A mechanism to pin a user session to a particularserver.

• Session invalidation: A mechanism that must be performed across allsession-persistent storage entities (JVMs or databases).

While these options exist to store HTTP session and state beyond the life of anapplication server or JVM (which facilitates high availability) these approaches havechallenges of their own. The growth and changing dynamic of Web applicationshave forced application infrastructure to rethink session-persistence strategies.Some of these growing challenges include:

• Use of runtime real-estate; that is, an application server JVM heap tostore session provides an inefficient use of resources.

• Higher administrative and maintenance costs due to increase in userbase, and subsequent linear growth in application hosting infrastructure.

• Performance considerations for storing, replicating, and managing thestate of session objects.

• Performance considerations due to large session objects in some specificuse cases.

The challenges for session storage revolve around performance costs due toserialization of the session object to a database, or to other application servers orJVMs across the network. This performance cost, coupled with the management ofsession state such as replication, updates and invalidation, add significantperformance bottlenecks to the application-hosting platforms.

Why use eXtreme Scale?

WebSphere eXtreme Scale addresses these performance considerations byintroducing a new technological platform for improvised management andreplication, thus addressing the challenges imposed by conventional HTTP sessionpersistent mechanisms. Note that while eXtreme Scale also employsmemory-to-memory replication of HTTP sessions, it significantly differs from themechanism employed by WebSphere Network Deployment alone. eXtreme Scaleprovides features such as quality of service, replication reliability and linearscalability. Furthermore, eXtreme Scale distinguishes itself from traditionalapproaches in these ways:




• Enabling a grid of JVMs with the sole purpose of storing HTTP session (orany Java) objects.

• Isolating the application runtime from the grid runtime, thereby freeing upthe JVM heap for application use.

• Allowing linear scalability to accommodate growth, in sessions or the sizeof session objects.

• Providing implicit replication and management of session objects in thegrid.

• Using zone-support to enable the storage of session objects acrossgeographically disperse data centers (and cells), overcoming thetraditional limitation of single-cell replication.

• Improving quality of service and replication reliability when compared withWebSphere ND, which does not guarantee conistent replication.Conversely, eXtreme Scale offers a reliable replication mechanism.

Figure 3 illustrates the application cluster separated or isolated from the HTTPsession grid. Notice the session filter acts as an intercept prior to forwarding therequest to the JSP or servlet. The Filter check for the session is in the session grid.

Figure 3. Example eXtreme Scale-enabled grid for session persistence (gridJVMs isolated from application JVMs)




WebSphere eXtreme Scale provides non-invasive integration for HTTP sessionmanagement, so that you need not change the application logic. The twoprogressive approaches include:

• Configuring a servlet filter to an existing Web application with anin-memory data grid as the back end.

• Optionally, co-locating the application with the in-memory data grid in aclient-server context.

The next sections discuss these approaches in further detail.




HTTP servlet filter, a standard part of the servlet specification

As Figure 4 shows, the HTTP servlet filter intercepts every request prior toforwarding it to a servlet or JSP. The servlet filter wraps the HTTPServletRequestand HTTPServletResponse objects that the application developer uses to accessthe request’s session state. The eXtreme Scale HTTPSession object overrides theobject normally provided by the default session manager. Therefore there is no dataduplication between the two session managers, and the eXtreme Scale sessionmanager overrides the WebSphere session manager.

Figure 4. Topology of eXtreme Scale co-located HTTP session persistence(grid and application are in the same JVM)

The filter ensures that the session data is synchronized with the grid. On eachrequest, if HTTP session attributes have changed, they will be written back into thegrid. The eXtreme Scale HTTP filter presents a choice of storing the sessions in thesame JVMs as the servlet containers (co-located) or in a separate grid tier of remoteJVMs. Each of these options has its own advantages and limitations, and should beselected with infrastructure design considerations in mind.

The synchronous interaction of the filter and the grid is also an important designconsideration, because it ensures that any change to the HTTP session isimmediately replicated to the grid. While this might be a desirable option in some




cases, it does have a performance impact; eXtreme Scale allows a configuration (inthe splicer.properties file) for this interaction to be asynchronous, where thechanges are buffered and flushed to the grid at defined intervals. Note that thissynchronous and asynchronous replication between the filter and the grid, whilesimilar in concept, is entirely different from the replication mechanism configuredbetween the grid servers.

Follow these steps to use an HTTP servlet filter with eXtreme Scale:

1. Create the following files and package them in a WAR module in theMETA-INF directory.

• objectGrid.xml: contains the definition of the grid itself, including themaps, locking behavior, plug-ins, and other specifications.

• objectGridDeployment.xml: contains a description of the grid’sdeployment, such as how many partitions and zones, replicationstrategy, and other options.

• splicer.properties: provides the values used byaddObjectGridFilter, and is one of the required inputparameters for the script that splices the Web module with filterdeclarations. This file contains servlet context initialization parameterssuch as catalog server host and port, affinity, persistence mechanism,replication type and interval, and other context-related settings. Thisfile is not a required artifact in the WAR module, but is for informationonly.

2. Run the addObjectGridFilter script on the WAR to add the filter tothe web.xml file. The addObjectGridFilter script is usually locatedat: <eXtremeScale_HOME>/session/bin/addObjectGridFilter.bat | .shSyntax:

addSessionObjectGridFilter <location of WAR/EAR file> <location of properties file>

Example 1. Running the filter script

addSessionObjectGridFilter MyWebModule.war splicer.properties

3. When using eXtreme Scale in a WebSphere Network Deployment (ND)managed environment, you would need to augment the managed nodeswith eXtreme Scale. Then you would perform Steps 1 and 2 above,deploying the WAR to an eXtreme Scale augmented cluster.




(Optional): Co-locating the application with the in-memory datagrid in a client-server context

Using eXtreme Scale client-server topology for embedded applications is adeployment variation of the above techniques, in which the application is the client tothe eXtreme Scale grid. The natural progression after adding an eXtreme ScaleHTTP session filter is to decide upon the client-server topology for the Webapplication that is now embedded within the eXtreme Scale HTTP session filter.There are, in effect, two choices: either co-locate the application with the grid, orkeep them isolated from each other. The choice of topology depends upon theapplication design objectives. Although this section explores the deploymenttopology within the context of the eXtreme Scale HTTP session filter, this discussionapplies to any Web applications that employ session-management capabilities.

Co-locating the application with the grid (in the same JVM runtime)

This option means that the eXtreme Scale servers are co-located in the sameprocesses where the servlets run. The eXtreme Scale session manager cancommunicate directly with the local ObjectGrid instance, since it is co-locatedwithin the same server process.

When using WebSphere Application Server as a runtime and grid container, simplyplace the supplied objectGrid.xml and objectGridDeployment.xml files intoyour WAR files’ META-INF directories. At that point, when the application starts,eXtreme Scale will automatically detect the presence of these files and launch thecontainers in the same process as the session manager. You can modify theobjectGridDeployment.xml to configure which type of replication (synchronousor asynchronous) and how many replicas you want. This step assumes that youhave augmented the application server profile or instance with eXtreme Scale.

Isolating the application from the grid (application and grid in separate JVMs)

This technique is beneficial for applications with either voluminous HTTP sessiontraffic or relatively larger HTTP session objects. In this case the eXtreme Scalesession manager, which resides on the application server process, communicates toremote eXtreme Scale server processes. In effect, the eXtreme Scale sessionmanager becomes the client to the eXtreme Scale servers, which are the hosts togrid containers.

To use a remote ObjectGrid, you need to configure the eXtreme Scale sessionmanager to communicate with the catalog servers and grid servers. The sessionmanager then uses a client connection to communicate with the catalog server andthe container servers, wherever they may reside. If you want to start theObjectGrid servers in independent, stand-alone J2SE processes, then you shouldlaunch the ObjectGrid containers using the objectGridStandAlone.xml and




objectGridDeploymentStandAlone.xml files supplied in the session managersamples directory. This differentiation indicates that the HTTP session store isstandalone and isolated. However, the core functionality of the file remains thesame, such as how objectGrid.xml and objectGridStandalone.xml definethe grid for sessions, and how objectGridDeploymentStandalone.xml definesthe mechanics of grid deployment.

Zone support

The eXtreme Scale zone-based replication allows for rules-based data placement,enabling high availability of the grid due to redundant placement of data acrossphysical locations. This implementation is particularly appealing to enterpriseenvironments that need data replication and availability across geographicallydispersed data centers. WebSphere eXtreme Scale introduced zone-based supportin V6.1.0.3. Zone support provides much needed control of shard placement in thegrid, and allows for rules-based shard placement.

In the past, these enterprise computing environments were limited, due to theperformance constraints imposed by networks and real-time data replicationrequirements. With the inclusion of zone support, WebSphere eXtreme Scale offersbetter scalability by decoupling the grid environment. With zone support, only themetadata shared by the catalog servers is synchronously replicated, while the dataobjects are copied asynchronously across networks. This technique not only enablesbetter location awareness and access of objects, but also imposes fewer burdens onenterprise networks, by eliminating the requirement of real-time replication.

Striped in this context means segmentation of logically sequentialdata, which can then be written concurrently.

As long as catalog servers see zones being registered (as the zoned grid-serverscome alive), the primary and replica shards are striped across these zones.Additionally, the zone rules described in the objectGridDeployment.xml filedictate the placement of sync or async replica shards in respective zones. Figure 5shows Two geographically dispersed zones to store HTTP sessions across two datacenters. Note that the catalog servers are hosted in separate JVMs from the gridcontainers.

Figure 5. Geographically dispersed zones to store HTTP sessions across datacenters




As a general practice, we recommend that you place only sync replicas in the samezone, and async replicas in a different zone for optimal replication performance. Thisplacement would also be optimal for scaling across geographies or data centers.

Since core groups do not span zones, place the catalog servers one or two per datacenter or zone, so that the catalog servers synchronize their object and shardrouting information. A catalog service (one or more catalog servers) must beclustered for high availability in every zone. The catalog service retains topologyinformation for all of the containers in the ObjectGrid and controls balancing androuting for all clients. Since the individual catalog servers maintain the catalogservice and client routing, you need to understand the concept of a catalog servicequorum. A catalog service quorum is the minimum number of active catalog servermembers required for the grid system to operate correctly (to accept membershipregistrations and changes to membership to ensure proper routing and shardplacement).

Example 2. Zone meta-data from ObjectGridDeployment.xml file

<zoneMetadata><shardMapping shard="P" zoneRuleRef="stripeZone"/><shardMapping shard="S" zoneRuleRef="stripeZone"/><zoneRule name ="stripeZone" exclusivePlacement="true" >

<zone name="ZoneA" /><zone name="ZoneB" /><zone name="ZoneC" />

</zoneRule></zoneMetadata>

You can achieve this approach of ensuring the registration and consistency of gridservers only when a quorum is established between catalog servers. Writes to the




catalog service state are committed only when the majority of the catalog serversparticipate in the transaction. Containers that are changing states cannot receiveany commands, unless the catalog service transaction commits first. If the catalogservice is hosted in a minority partition, meaning that no quorum has beenestablished, it then accepts “liveness” messages. The catalog servers cannot,however, accept server registrations or membership changes, because the state isessentially frozen, until the catalog-service quorum is re-established.

Conclusion

One of the main design concerns of an application and application infrastructure isthe session persistence and handling of session state beyond the life of applicationservers or JVMs. Traditional persistence mechanisms impose performance andscalability concerns with growth in business and subsequent requirements. Growthin business usually results in increased traffic, user session and proportional storagerequirements. Historically, IT organizations have attempted to battle this problemwith innovative and complex solutions, such as employing various caching layers atthe edge for static content and a separate cache for dynamic content, or byselectively preserving some HTTP session data and recreating the others.

Such strategies, while effective in some application environments, have reached thematurity level of their growth spectrum. Increasingly complex and defragmentedapplication frameworks have compelled the “in-memory data-grid” paradigm toprovide a scalable solution to address the growth of session storage, in terms ofboth size and volume. The introduction of an in-memory grid relieves the constantbattle with scalability and provides an isolated layer whose sole purpose is to storeHTTP session (or any Java) objects.

The eXtreme Scale technology enables this model, which is essentially a grid ofinterconnected JVMs acting as a single cohesive unit, much like a database, withoutthe management and performance overheads. Using eXtreme Scale for HTTPsession persistence is a non-invasive change to application architecture, as seen inFigure 3, where you introduce a servlet filter in the application. This filter interceptsrequests and is connected to the grid without any significant change to theapplication architecture.

The eXtreme Scale-enabled grid is policy driven and self-managed, and can easilyabsorb growth by including additional JVMs to the existing grid. Thus, eXtremeScale makes a compelling solution for HTTP session persistence in environmentswhere performance and scalability challenges arise, due to growth in businessapplication traffic.

With that in mind, eXtreme Scale not only addresses fundamental session-storageconcerns, but also adds to the capability of session storage across geographicallydispersed data centers, independent of the WebSphere infrastructure’s cell-based



fig3


management boundaries. This capability alone empowers organizations with theability to persist and handle session state across data centers. Such a capability wasneither recommended nor technically feasible with existing technologies andsolutions, but eXtreme Scale’s zone support is sets it apart from competing cachingtechnologies.

Acknowledgements

I want to thank Joshua T. Dettinger and Billy Newport for their help in technicalcontent and editing of this paper.




Resources

Learn

• Redbook: User's Guide to WebSphere eXtreme Scale

• Brown et al - Improving HTTP session performance with smart serialization

• WebSphere eXtreme Scale Wiki

• Billy Newport’s Blog on WebSphere eXtreme Scale

• Session Management on Wikipedia

• WebSphere eXtreme Scale product information

• developerworks WebSphere Extended Deployment zone .

• developerworks WebSphere Application Server zone

Get products and technologies

• WebSphere eXtreme Scale Trial

Discuss

• WebSphere Extended Deployment forum

About the author

Nitin GaurNitin Gaur has been with IBM for 9 years and is currently a Senior WebSphere ITConsulting Specialist with IBM Technical Sales organization. Nitin was previously onthe WebSphere OEM and AIX support teams. He is an IBM Certified Consulting ITSpecialist and Advanced WebSphere Administrator as well as an AIX CertifiedAdvanced Technical Expert. Nitin is actively engaged in various virtualizationtechnologies and IBM's cloud computing initiatives. Nitin is an active member of theAustin Technical Vitality Council, an IBM Academy affiliate, and has presentedpapers on a wide range of subjects, including software architecture and improvingmanagement processes, at various conferences.



http://www.redbooks.ibm.com/redpieces/abstracts/sg247683.html?Open

http://www.ibm.com/developerworks/websphere/library/bestpractices/httpsession_performance_serialization.html

http://www.ibm.com/developerworks/wikis/display/objectgrid/Getting+started

http://www.devwebsphere.com/

http://en.wikipedia.org/wiki/Session_management

http://www.ibm.com/software/webservers/appserv/extremescale/

http://www.ibm.com/developerworks/websphere/zones/xd/

http://www.ibm.com/developerworks/websphere/zones/was/

http://www.ibm.com/developerworks/downloads/ws/wsdg/learn.html

https://www.ibm.com/developerworks/forums/forum.jspa?forumID=778&start=0


scalable and robust http session management with websphere extreme scale

Documents