The VMware vFabricTM
HTTP Session Management Module provides fast, scalable, and reliable HTTP session replication for SpringSource tc Server and Apache Tomcat without requiring any application changes. Depending on your usage model, you can replicate session data across multiple peers, partition data across multiple servers, distribute session data across a WAN, or manage your session data in many other customizable ways.
Why Use GemFire?
- tc Server integration
The GemFire module offers clean integration into the tc Server environment with minimal configuration changes necessary.
Applications with a small number of frequently-accessed sessions can replicate session information on all nodes in the cluster. However, when the number of concurent sessions being managed is large, data can be partitioned across any number of servers (either embedded within your application server process or managed by GemFire cache servers), which allows for linear scaling. Additionally, capacity can be dynamically added or removed in a running system and GemFire re-executes a non-blocking, rebalancing logic to migrate data from existing nodes to the newly added nodes. When the session state memory requirements exceed available memory, each partition node can overflow to disk.
- Server-managed session state
Session state can be managed independent of the application server cluster. This allows applications or servers to come and go without impacting session lifetimes.
- Shared nothing cluster-wide persistence: Session state can be persisted (and recovered) - invaluable for scenarios where sessions manage critical application state or have long lifetimes. GemFire uses a shared nothing persistence model where each node can continuously append to rolling log files without ever needing to seek on disk, providing very high disk throughput. When data is partitioned, the total disk throughput can come close to the aggregate disk transfer rates across each of the nodes storing data on disk.
- Session deltas
When session attributes are updated, only the updated state that is sent over the wire (to cache servers and to replicas). This provides fast updates even for large sessions. Session state is always managed in a serialized state on the servers, avoiding the need for the cache servers to be aware of the application classes.
- Tiered caching
Applications can configure a local or near cache for in-process caching of the most frequently used session state. This local cache delegates to a farm of cache servers where the entire session state is partitioned across any number of peer cache servers. The local cache can be configured to consume a certain percentage of the total heap available before least-recently used (LRU) eviction. This is a simpler and more effective way to manage LRU caches as opposed to alternate strategies based on count or memory size, which increase the risk of getting an "OutOfMemoryException".
- Application server sizing
Another aspect of tiered-caching functionality is that session replication can be configured so that session objects are stored external to the application server process. This allows for the JVM heap settings on the application server to be much smaller than otherwise.
- Replication to remote clusters
The session state can be asynchronously replicated to/from multiple clusters across a WAN. This allows for disaster recovery (DR) architectures, among other benefits.
- High availability (HA), disk-based overflow, synchronization to backend data store, other GemFire features
All the popular GemFire features are available. For example: more than one synchronous copy of the session state can be maintained providing high availability (HA); the session cache can overflow to disk if the memory capacity in the cache server farm becomes insufficient; state information can be written to a backend database in a synchronous or asynchronous manner.
- Download and install tc Server version 2.1.x or greater. (For instructions using Tomcat instead of tc Server, refer to Complete Setup Instructions.)
- Download and unpack the HTTP Session Management for tc Server Module into the templates directory of tc Server.
- Go to the root directory of tc Server.
- Create a GemFire instance using one of the provided templates and run it. For example:
prompt$ ./tcruntime-instance.sh create my_instance_name --template gemfire-p2p
prompt$ ./tcruntime-ctl.sh my_instance_name start
This will create and run a GemFire instance using the peer-to-peer topology and default configuration values. Another GemFire instance on another system can be created and started in the same way. For complete instructions on setting up GemFire on either tc Server or Tomcat, refer to Complete Setup Instructions.
Newer versions of tc Server (for example 2.5.0) allow for the use of either Tomcat 6.x or 7.x with 7.x being the default. Version 1.1 of the HTTP Session Management module is not compatible with Tomcat 7.x. When creating an instance using tcruntime-instance.sh, you must use the --version option to explicitly select Tomcat 6.x for use with the HTTP Session Management module.
Common GemFire Topologies
Before configuring the GemFire module, you must consider which topology is suited for your usage. The configuration process is slightly different for each topology.
For information about GemFire purchase options as they relate to your desired configuration, refer to HTTP Session Management and GemFire Purchase Options.
In a peer-to-peer configuration, each GemFire instance within an application server contains its own cache. It communicates with other GemFire instances as peers (rather than clients and servers). Depending on the way the GemFire data region is defined, data is either replicated across all GemFire peers or it is partitioned so that each instance's cache contains a portion of the entire data set. By default, data is replicated. A peer-to-peer configuration is useful when multiple systems want fast access to all session data. This configuration is also the simplest one to set up and does not require any external processes.
In a client/server configuration, the Tomcat or tc Server instance operates as a GemFire client, which must communicate with one or more GemFire servers to acquire session data. The client maintains its own local cache and will communicate with the server to satisfy cache misses. A client/server configuration is useful when you want to separate the application server instance from the cached session data. In this configuration, you can reduce the memory consumption of the application server since session data is stored in separate GemFire server processes.
Multi-site (or WAN-based) Configuration
With this configuration, distributed systems at different sites are loosely coupled through gateway system members (i.e. gateway hubs). The distribution of session data between sites is seamless to the applications within each distributed system. If a system becomes unavailable, the rest of the cluster continues to operate. In a multi-site topology, each site has its own distinct distributed system. In each system, at least one member is chosen to act as a gateway that distributes data to and from the other sites. This configuration is useful when you are attempting to replicate session data across multiple sites, which can be valuable for handling complete site failovers. Load balancers such as SpringSource ERS can be configured with hot backups that access this remote HTTP session data.
Consult the "Introduction" chapter of the GemFire Developer's Guide for more information on GemFire topologies.
Complete Setup Instructions
If you are using tc Server 2.1 or greater, you can set up GemFire session replication using the provided tc Server 2.1 templates. Alternatively, you can set up session replication in Apache Tomcat or tc Server by directly making a few changes to Tomcat's server.xml and context.xml files.
For complete details on setting up and managing GemFire, refer to the GemFire System Administrator's Guide and the GemFire Developer's Guide.