[Deploying Sakai] SSL load balancing and fault tolerance for Sakai

[Grossman,John E]

We are deploying Sakai 2.6 on Windows/Tomcat.
We would like to have load balancing and in-session fault tolerance/failover.
We tried to deploy to support the following scenario (everything over SSL):

-       User authenticates via a web app using LDAP
-       The authentication app connects through a Cisco CSS load balancer configured for SSL sticky sessions to the Sakai login web service to create a Sakai session on one of our Sakai servers
-       The authentication app passes the Sakai session to the user's browser with the load balancer virtual IP in the address
-       User hits the load balancer
-       User is directed to one of the Sakai servers by the load balancer
-       If the server fails while a session is active the user is directed to another server and continues the session.

Problems
-       The load balancer doesn't necessarily send the user to the same Sakai server that created the Sakai session. The SSL sticky capability on the load balancer is based on the SSL session ID. The SSL session ID associated with the Sakai session is assigned to the authentication app - not to the user's browser. The user's browser doesn't get an SSL session ID until it connects to Sakai for the first time.
-       Even if the load balancing worked, we still wouldn't have in-session fault tolerance because one Sakai host isn't aware of sessions created on another host.

I've read the Jira documents about Terracotta, but I can't see a great deal of value in enabling Teracotta at this time since many tools don't appear to support Terracotta without some customization. We're trying to avoid customization as much as possible.

Has anyone else solved this problem using only standard Sakai and load balancer configurations? Our fallback is to implement simple round-robin load balancing in the authentication app. In this scenario we would not have in-session fault tolerance - anyone connected to a server at the time of server failure would have to log in again to the surviving server. Ugh!


John Grossman
The University of Texas M. D. Anderson Cancer Center



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20090812/6adb0f44/attachment.html