Cluster config recommendation needed

[Artur Korol，修改在7 年前。]

Our setup is Lifeferay 6.2 GA4+Tomcat + nginx. Liferay components is very limited.
Portal is complex JSF application (more than 300 portlet instances).
We use some Liferay components like CMS but this is marginal. 90% of service is JSF application.
We do not use document and image libraries.
Most users do not log in to the portal but some do.

Goal to configure cluster is to distribute workload. I want to divide portal into a few subportals, eg.

Root portal: http://our-portal.com
http://our-portal.com/music
http://our-portal.com/sport
etc

I performed first tests:
To create portals for http://our-portal.com/music and http://our-portal.com/sport I just cloned our first Liferay to other 2 machines. So all Liferay share the same db and config.
Made simple changes at nginx server to just proxy_pass to the proper Liferay depending on the incoming URL.

For anonymous users everything seems to work (I think every Liferay creates its own session) but problem is with logged in users. The question is how to do it:

1.) Do I need to configure session replication? I want to avoid it as is complicated and incurs extra overhead
2.) Do I need to configure Liferay to use a clustered cache.

I know, standard cluster solution is to use "sticky" load balancer (as descibed here http://www.liferay.com/community/wiki/-/wiki/Main/Clustering) and use "identical" Liferays. This solution has some disadvantages for me:
using subportals seems to be more logical as our application uses 300 portlets and I feel better is to let one Liferay to serve only part of the portal (say 100 portlets and another 100 another Liferay).
"sticky" load balancer requires commercial nginx plus

Any advise are welcome. Maybe I do not need cluster but proper single sign-on solution?
Thanks

[David H Nebinger，修改在7 年前。]

When Liferay is in a cluster, it works better when all nodes are mirrors. There are shared config and ongoing messaging between the nodes that, should a node be out of sync, can cause some problems.

If you want to approach your "subportal" concept, you should still keep all nodes in the cluster as mirrors of each other.

Now, about the subportal concept, if you look at the html for, say, the /music landing page you'll notice that not all of the URLs have /music as the prefix part; theme, javascript, css, etc tends to be a portal asset, not necessarily a site asset. Routing different requests to different subportals based upon URL is actually going to distribute the rendering of a single page across many of your subportal nodes instead of just to a single sticky node.

In the standard Liferay cluster setup, say you have 10 nodes all equally handling work. Using sticky sessions and load balancing, your incoming traffic should be distributed equally across the cluster and the cluster is able to adjust to higher loads with the only impact being a lengthening load time.

In your subportal concept, imagine something hot hits your /music subportal. Since load cannot be distributed to other subportals, it will be easy to take down /music when something hits. Now you might counter saying you can add nodes to support /music, but does that mean you're taking nodes away from the other subportals? Will the extra nodes stick with /music? Next week, when something hot hits /sport, are you actively going to reshuffle nodes to support additional load?

A vanilla cluster is a resilient entity that distributes all load across all nodes in the cluster. Whether things are hot on /music this week and /sport next week, the cluster distributes the load and is able to quickly adjust under heavy load situations without an ounce of active operator management.






Come meet me at the LSNA!

[Artur Korol，修改在7 年前。]

Thanks for the answer,

I am aware of what You said eg, themes, javascripts are taken from the root Liferay and if this goes down others Liferays do not work properly either. So the first one must always work. But this one I can configure to server light traffic only.

There are other reasons - eg. I want to dedicate one Liferay to serve one portlet only but heavily used

All Liferays must be mirrors but I think would be "easier" to each of them to serve only part of the portal. And more acceptable is when one part of the portal eg /music goes down than everything what might happen if something goes wrong in the cluster.

Anyway - if in the future portal would be big enough I can mixture both approaches.

Could You suggest how to solve single logon problem?

[David H Nebinger，修改在7 年前。]

Artur Korol:

All Liferays must be mirrors but I think would be "easier" to each of them to serve only part of the portal.

That is definitely not true. Liferay aggregates the page, it's not aggregated by nginx or in the browser.

When Liferay aggregates a page, all of the portlets on the page render their individual HTML fragments and the portal wraps those around the adjusted theme (to include portlet-specific javascript and css resources) to come up with the final HTML document. Note that all render requests come in via the regular Liferay URLs, i.e. /web/guest/page, the URLs do not come in individually as /portlet1/request and /portlet2/request sort of things.

The only paths that have /portlet1 or /portlet2 is to serve up static resources like JS or CSS; the actual render of the portlet HTML fragment comes in on the portal's main request and the portal aggregates the fragments of all portlets on the page via direct method calls, not internal web calls.

So there's no way to "offload" a single portlet render to a dedicated node, it just would never get any real traffic to offload the processing, it just would offload static resource service.

Even if it were possible, your concept just doesn't make any sense whatsoever. It would introduce single points of failure, it would cause a lot of monitoring and active management to rebalance traffic in response to load, it would lead to nodes with light or no load while others might be peaked, ...

If your complaint is not wanting to pay for nginx to get sticky sessions, then your problem is with nginx (or lack of adequate financial resources). So solve that problem by changing over to Apache HTTPd (which handles sticky sessions and doesn't cost you a thing) or other alternatives. You know what the real problem is, so fix the real problem and try to avoid creating problems to work around an issue that really isn't one.






Come meet me at the LSNA!

[Artur Korol，修改在7 年前。]

David,

Thanks for suggestions a lot