You are here

Load Balancing New LP5 Install

Submitted by leggn on Thu, 02/09/2012 - 15:17


I'm looking at setting up a new LP5 installation with two portal nodes using a software load balancing solution. I have some experience using Apache HTTPD with mod_proxy, mod_proxy_ajp, and mod_proxy_balancer to frontend my institution's existing uPortal service and our (external to Luminis) CAS service. Is a similar setup possible with Luminis? Does anyone currently employ such a setup in production?

Can anyone share any experiences regarding software load balancing LP5 in general?


Luminis Version:

I assume it's possible using software based load balancing. Liferay mentions it:

Your software solution would need to be able to forward ports to specific servers, maintain sticky https sessions to servers, and optionally be able to terminate SSL at the load balancer.

The LP50003in.pdf (install guide) has some application specific steps in it. Settings and config and so forth.

As far as I know, there isn't any session replication between tomcats, so it is just a basic load balancing setup. The load balancer creates sticky sessions to https to the portal tier servers round robin.

I'm going to be doing that in the next year or so. I'll probably put cas, admin, ldap, the db, everything behind the load balancer in anticipation of the clustering solutions that have been talked about. Ideally 2 ldaps, 2 cas, 2 admin, etc..

That wouldn't work. The crux of the idea is: "Each web tier would have 2 installs of Tomcat running on them. They would share the same doc base for the applications, and they would also be setup clustered, hence sharing session data" (emphasis added).

This idea is no different that establishing the Tomcat cluster across servers with session replication enabled. The idea is to setup two Tomcat instances on the same server and do session replication locally. As I've shown, Luminis's session cannot be replicated.

If you read through the comments on the post I linked earlier, you'll see that LP5 was going to offer a form of session replication early on. That's not entirely true; it was going to offer memory replication which would effectively negate the need for a serializable session. But that was scrapped. Likely because of licensing issues.