Achieving active active deployments of stateful applications (Websphere example)

I am exploring how we could solution active/active deployments across two data centers for stateful applications. The key limiting factor to date has been a viable persistent routing solution using our F5 LTM and GTM network load balancers. As a result, our configurations are mostly active/standby meaning assets in the standby center typically sit idle unless there is a DR scenario.

 

Typically here is how a routing approach would work for a J2EE Websphere application:

 

1. Client looks up an application's IP using a GTM Alias DNS name.
2. GTM returns the LTM VIP for the application. (for active standby deployment, the LTM VIP for the active center is returned)
3. Client sends request to the LTM VIP (virtual IP).
4. LTM routes the request to an IBM HTTP Server (IHS) sitting in front of WebSphere.
5. IHS Websphere plugin routes request to a Websphere JVM.
6. Websphere generates a JSESSION cookie and returns it to the client on the response. Encoded in the JSESSION cookie is the Websphere server name which satisfied the request and a session identifier.
7. On subsequent requests the following steps occur: i) If the DNS lookup TTL has expired, the same LTM VIP is always returned because only one LTM VIP is active at a time; the other LTM VIP is only returned if the original LTM VIP is unhealthy (in this case session state cannot be recovered - reasonable limitation) ii) the JSESSION cookie is passed by the client (on Step 3), iii) IHS decodes the JSESSION cookie (on Step 5) and iv) IHS routes the request to the same WebSphere server as the original request v) The Websphere server looks up the state information for the user based on the session identifier in the JSESSION cookie

The above configuration works for active/standby configuration across 2 data centers. However, I'm trying to understand an approach that could work for an active/active configuration across 2 data centers. ie: I would want the routing to work like this:

 

1. Client looks up an application's IP using a non data center specific alias.
2. Lookup returns the center specific LTM VIP for the application. (for active active deployment, the LTM VIP from either center could be returned)
3. Client sends request to the LTM VIP.
4. LTM routes the request to an IBM HTTP Server (IHS) sitting in front of WebSphere.
5. IHS Webshere plugin routes request to a Websphere JVM.
6. Websphere generates a JSESSION cookie and returns it to the client on the response. Encoded in the JSESSION cookie is the Websphere server name which satisfied the request.
7. On subsequent requests substep i) is the key differentiator: i) the client sends the request back to the LTM VIP originally returned in Step 2, since routing to the other center would result in loss of session (eg: if a round robin global traffic routing approach was used) ii) the JSESSION cookie is passed by the client (on Step 3), iii) IHS decodes the JSESSION cookie (on Step 5) and iv) IHS routes the request to the same WebSphere server as the original request v) The Websphere server looks up the state information for the user based on the session identifier in the JSESSION cookie

Here are solutions we've considered

 

1) Long TTL of the DNS lookup in Step 1, not viable because i) TTL would need to be very long and if the LTM VIP goes down, then the client would not be able to perform another DNS lookup until the TTL has expired, or the local DNS cache is flushed (no viable mechanism to achieve this) ii) DNS lookup may be performed by a gateway device (eg: such as a reverse proxy), which would result in all traffic from that device being distributed to a single center for the TTL period

 

2) Use geo-affinity for routing... this has not been explored in detail, but there are concerns about how complex this may be to setup and it may not provide a reliable solution given that we want equal distribution of traffic, and the amount of activity from different regions could vary throughout the day (as business hours shift from east coast to west coast)

 

3) Replicate session across both data centers for the application in question - this would kill performance for applications of our scale. We do not even do this within a data center.

 

4) Have IHS route the traffic to Websphere in either data center. This requires a Websphere deployment topology that is not recommended by IBM (ie: a single cell spanning two data centers).

 

Sorry for a long post, but I hope it describes the problem and I'd be interested in any potential solutions.

 

Thanks Steve