Continuing our introductory blog series, this blog will demonstrate how to add load balancing capability to Apache Web Server and forward to our simple Payara Server cluster.
A load balancer can redirect requests to multiple instances, primarily for the purpose of distributing incoming requests between cluster members based on pre-determined rules. This could be a simple “round-robin” algorithm, where the workload is distributed to each instance in turn, or a weighted algorithm where requests are delivered based on a pre-determined weight for each cluster member.
A load balancer plays a key role in our cluster:
If you have been following this series, so far we have:
Created two “standalone” Payara Server instances, clustered using Hazelcast
This blog will demonstrate how you enable Apache Web Server to load balance requests across our cluster using the Apache Web Servermod_proxy_balancermodule.
Requirements
To follow along with this blog, the cluster we created in Part 3 and our Apache configuration from Part 2 will be required.
As it currently stands, this environment is:
Our cluster:
One Ubuntu 16.04 host with JDK8, Apache Web Server, and Payara Server installed, with a Domain Administration Server and another instance (“local-instance”).
One Ubuntu 16.04 host with JDK8, OpenSSH, and Payara Server installed, with a single Payara Server instance (“second-Ubuntu-host-instance”) controlled by the DAS on the first host.
Since this blog is demonstrating Apache’s load balancing capabilities, we will need the clusterjsp sample application, which we will deploy to our cluster.
Deploying the clusterjsp application
Clusterjsp is a simple web application which can show HTTP session information alongside details of the server instance which served the request. This should make it clear if Apache is load balancing our requests between our two server instances!
Deploy the application by going to the “Applications” page on the Admin Console and making sure to target the application to both our “Standalone” instances (in our case, “local-instance” and “second-Ubuntu-host-instance“), with everything set to the default values.
With our application deployed, click on “Launch” to display the links to the clusterjsp application:
Now we have the endpoints we need to add to our load balancer! We have the choice of HTTP or HTTPS, here, since Payara Server can be accessed directly if needed. Since we are going to use Apache, we can terminate SSL when requests reach the load balancer rather than continuing to pay the performance cost to HTTPS at this stage. It should be noted, however, that the performance cost of HTTPS will only be the case until both Apache Web Server and Payara Server (with Servlet 4) fully support HTTP/2, after which HTTPS will almost certainly be much more performant than HTTP.
Setting up Apache Web Server as a Load Balancer
With our environment set up, we can begin modifying the Apache Web Server configuration. If you have been following this series of blogs you should already have Apache Web Server installed with a basicmod_proxy_http, and your a site congfiguration called “payaraSite”at/etc/apache2/sites-available/payaraSite.conf, which should look like this:
While this worked when we were using the ProxyPass directives to forward to the Domain Admin Server (DAS), we now have two cluster members as separate instances athttp://192.168.93.133:28080/and http://192.168.93.134:28080/, and no longer want to send traffic to the DAS.
It is not possible to add multiple endpoints to the same ProxyPass directive, so we need to introduce mod_proxy_balancer,which will allow us to, effectively, point our ProxyPass directive to a list of endpoints.
Configuring Mod Proxy Balancer
The modified configuration is similar to what we had previously done by forwarding traffic to a specific URL, except the URL will now point to a block of possible endpoints within a <Proxy> tag, and a load balancer method to determine how the proxy is chosen.
To start, we must first enable the module proxy_balancer and a simple load balancing method using our Apache Web Server helper tools which were installed as part of the Ubuntu apache2 package:
sudo a2enmod proxy_balancer lbmethod_byrequests
Theby_requestsmethod of load balancing simply alternates between instances in a round-robin. With the module now active, reopen thepayaraSite.conffile with your chosen text editor. We need to first create a <Proxy> block which contains a list of endpoints where our app is located as shown:
Once we have a list of endpoints, we can change the ProxyPass directives to use one of the endpoints we just specified, by referencing the <Proxy> block. We could create multiple <Proxy> blocks with different names to refer to different lists of endpoints, depending on which applications we wanted to load balance and what endpoints they were deployed to.
In our case, the configuration file should now look something like this:
Save your configuration and restart Apache:
sudo service apache2 restart
So now, on the host where Apache is installed, whenever we load the page http://localhost/clusterjspwe will find that each request alternates between being served from the first or second Payara Server instances:
Summary
So with that done, we have implemented basic load balancing to spread requests across multiple Payara Server instances, all thanks to Apache Web Server and itsmod_proxy_httpandmod_proxy_balancermodules. This configuration is relatively naïve and won’t take into account session data, so in our next blog, we will enable sticky sessions to make sure that users’ sessions will be pinned to a single Payara Server instance, rather than bouncing between the two.
For now, if you have any questions, feel free to post a comment below.
Something not highlighted is the Session ID differs between the screenshots. If the application can be completely stateless then this is OK. Otherwise session replication is needed across the cluster. I’ll refer to my blog which is a how-to on creating a High Availability (HA), Session Replicated, Multi-VM Payara Cluster – http://mjremijan.blogspot.com/2017/04/high-availability-ha-session-replicated.html
Hello
First of all I want to congratulate this blog for the initiative, very good series of articles.
But I wonder if forecasting for the continuation of this would be with intrusion to session sharing only in a single insight.
Apache server is very popular among the people because it gives a flexibility to the user so they can use a lot of programming languages. Thanks for sharing the informative article.
Something not highlighted is the Session ID differs between the screenshots. If the application can be completely stateless then this is OK. Otherwise session replication is needed across the cluster. I’ll refer to my blog which is a how-to on creating a High Availability (HA), Session Replicated, Multi-VM Payara Cluster – http://mjremijan.blogspot.com/2017/04/high-availability-ha-session-replicated.html
Hello
First of all I want to congratulate this blog for the initiative, very good series of articles.
But I wonder if forecasting for the continuation of this would be with intrusion to session sharing only in a single insight.
Best Regards
Alan Rodrigues
Apache server is very popular among the people because it gives a flexibility to the user so they can use a lot of programming languages. Thanks for sharing the informative article.