Liferay 7.3 AWS deployment Architecture and tuningLiferay 7.3 AWS deployment Architecture and tuninghttps://liferay.dev/en/c/message_boards/find_thread?p_l_id=119785333&threadId=1207726902024-03-28T16:22:29Z2024-03-28T16:22:29ZRE: RE: Liferay 7.3 AWS deployment Architecture and tuningPHILIP JACOBhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1208297312021-06-17T16:54:50Z2021-06-17T16:37:22Z<p>Thanks for the reply</p>PHILIP JACOB2021-06-17T16:37:22ZRE: Liferay 7.3 AWS deployment Architecture and tuningOlaf Kockhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1207751992021-06-17T16:37:07Z2021-05-07T07:54:14Z<p>Welcome to the world of Liferay.</p>
<p>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):</p>
<ul>
<li>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</li>
<li>Set up a geographically distributed cluster and measure what it
can handle<ul>
<li>Note: You'll need to cluster Elasticsearch, your database, and
your file storage (unless you store Document Library's files in
your database).</li>
<li>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.</li></ul></li>
<li>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.</li></ul>
<p>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)</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>Olaf Kock2021-05-07T07:54:14ZLiferay 7.3 AWS deployment Architecture and tuningPHILIP JACOBhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=1207726892021-05-06T16:45:13Z2021-05-06T16:26:07Z<p>
<span style="font-size: 12.0pt;">
<span style="font-family: "Times New Roman" , serif;">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 .</span></span></p>
<p>
<span style="font-size: 12.0pt;">
<span
style="font-family: "Times New Roman" , serif;">Liferay
has provided an AWS deployment architecture (<a
href="https://www.liferay.com/resources/whitepapers/Deploying+Liferay+DXP+in+Amazon+Web+Services"
style="color: blue;text-decoration: underline;">Deploying
Liferay DXP in Amazon Web Services</a>) . For deployment , We
are planning to have two instances of Liferay which is spread
across <b>2 Availability Zones (AZ) </b>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? </span></span></p>
<p>
<span style="font-size: 12.0pt;">
<span style="font-family: "Times New Roman" , serif;">In
this case how should the load balancer be configured (Active -
Active) ? Should it be with Sticky session?</span></span></p>
<p>
<span style="font-size: 12.0pt;">
<span style="font-family: "Times New Roman" , serif;">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 ?</span></span></p>
<p>
<span style="font-size: 12.0pt;">
<span style="font-family: "Times New Roman" , serif;">Also
Liferay has an EH cache built in. How should we tune that. Has
anyone done that?</span></span></p>
<p>
<span style="font-size: 12.0pt;">
<span style="font-family: "Times New Roman" , serif;"> 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 . </span></span></p>
<p>
<span style="font-size: 12.0pt;">
<span style="font-family: "Times New Roman" , s