Common Pitfalls When Clustering Liferay

Trying to cluster Liferay? Think it's as simple as just putting a bunch of Liferay servers behind a load balancer? Think again. Here are some of the top pitfalls when setting up a clustered Liferay environment:

 

1. Merely copying Liferay and putting it behind a load balancer. 

Do not do this and think you are done. You must account for the local caching, indexing, and document repository storage. Did you know that, via the default configuration, each Liferay server has a local instance of all of the above? Use ClusterLink to synchronize the cache (Ehcache), and index (Lucene), and decide on a central way to mount or store documents (e.g. - SAN, NAS, Amazon S3, etc.). Failure to do this will not only cause users to see inconsistent content and behavior from node to node, but also cause data corruption for your documents because each node will only have a portion of the entire document repository, even though the document metadata is already centralized in the database. The actual documents files are stored on the local server's file system by default. Not only that, other nodes may not be aware of new or updated documents due to a stale cache and index. This is probably the most common mistake I have seen by those new to Liferay who have not taken the Administering Liferay Systems course or thoroughly read the documentaton

 

 

2. Assuming multicast works in your hosting vendor's environment

This is often not the case for the cloud. For example, did you know that Amazon Web Services does not support multicast or broadcast? See: http://aws.amazon.com/vpc/faqs/ . You must configure use a unicast configuration for your cache and index replication.

 

 

3. Not eliminating other single points of failure

Although taking care of (1) and (2) above will typically ensure data integrity and a consistent user experience, in some high-volume environments, there are elements of Liferay High Availability that need to be addressed to ensure consistent and reasonably quick response time. Configuring a database cluster (e.g. - MySQL Cluster, Oracle RAC, etc.) will eliminate outages cause by a database server going down. Installing the Solr plugin and clustering your Solr servers is one way to not only speed up heavy indexing, but clustering Solr itself also eliminates another single point of failure. Adding redundancy at the load balancer level is not necessarily a Liferay configuration, however it will eliminate another single point of failure. For the document repository, even though you may have configured a centralized document repository as recommended above, adding redundancy via SAN replication or another method will also prevent headaches if the document storage method goes down. 

 

 

For more documention on Liferay Clustering options, see the online documentation at:

https://www.liferay.com/documentation/liferay-portal/6.2/user-guide/-/ai/liferay-clustering-liferay-portal-6-2-user-guide-20-en

 

 

Blogs
If you're looking for a thorough overview of putting a Liferay cluster in place, check out this great post: http://www.liferay.com/web/fimez/blog/-/blogs/configuring-a-liferay-cluster-and-make-it-use-unicast-

It's got some extra coverage on unicast environments, too.