Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Liferay 7.3 AWS deployment Architecture and tuning
We have a website developed with components such as Theme, Web content, Fragment Layout ,Page template by wiring fragment layout with web content ,React search widget and liferay language hooks . We are using Liferay 7.3 GA6 .
Liferay has provided an AWS deployment architecture (Deploying Liferay DXP in Amazon Web Services) . For deployment , We are planning to have two instances of Liferay which is spread across 2 Availability Zones (AZ) to ensure high availability. The instance of Liferay is to be clustered. What will be typical communication delay when deployed in two AZ.? Is this way of clustering correct?
In this case how should the load balancer be configured (Active - Active) ? Should it be with Sticky session?
The reference Architecture tells about having a web server in front Or even we can use CDN . Can anyone tell us that CDN is fine ?
Also Liferay has an EH cache built in. How should we tune that. Has anyone done that?
If anyone has done a deployment in AWS can you please provide the best architecture to deploy 2 instances each of Liferay, elastic search and postgres database and the best tuning parameters .
We are planning to conduct a load test soon .Please help as we are new to Liferay .
Welcome to the world of Liferay.
My recommendation, as geo-clustered instances of Software still is quite an elaborate setup (as there were no recent advances in the speed-of-light research, and as you say you're new to Liferay):
- Start easy, by setting up a cluster in one location. Make sure it's rock-solid. Test that (or if) it can handle the load you're planning for. Measure the load that it can actually handle
- Set up a geographically distributed cluster and measure what it
can handle
- Note: You'll need to cluster Elasticsearch, your database, and your file storage (unless you store Document Library's files in your database).
- You can start setting up the geographical distribution by just setting up a distributed Database & Elasticsearch cluster and Document Library replication. This way, on failure of one location, you can just fire up a separate instance in the second location, and you've simplified the problem instead of setting up everything at once.
- Note: What's hard in a clustered setup is rarely to keep the operation running on failure of one side. It's rather to merge the two instances after one failed, or after a "split brain", when the connection between both fails and both stay operative.
As of your load balancer configuration: It depends. If a single server can safely stand the load you're throwing at it, you can almost save yourself the cluster configuration and make it active-passive. This is also cost efficient if you only fire up the other location on demand (as I laid out)
CDN is fine - did you mean "CDN in general" or "CDN instead of a Webserver"? I'd always opt for a webserver. Apache's rewrite rules have been the simplest and quickest way to solve some problems for me.
Tuning: You'll need to start by measuring, which you'll do by conducting a load test. In that process you'll find what breaks first. E.g. find the narrowest bottleneck. Fix it. Then repeat: Your previously invisible second-narrowest bottleneck will have been promoted to the new #1. Repeat until you reach the actual end of your hardware's abilities, or until you're happy with the load that can be handled. Remember to load-test a realistic scenario. It's easy to break any server with unrealistic traffic.
And if I'm allowed a sales pitch: If you truly require that level of high availability, consider getting support services from the company that knows the code the best, and check out DXP. It's not only the cloud datacenters that can fail. In fact, those are the rarest problems I'd expect.
DXP will also give you access to Liferay's Global Services Team, that has conducted quite a lot of "Go-Live" projects, load testing etc.
Thanks for the reply
Powered by Liferay™