Apache Load Balancer [UPDATED]

When a server gets more traffic than it can handle, delays happen. If it's a web server, then the websites it hosts are slow to respond to user interactions. Services provided are inconsistent, and users could lose data or experience inconvenient interruptions. To prevent this, you can run a load balancer, which distributes traffic loads across several servers running duplicate services to prevent bottlenecks.

apache load balancer

By default, HAProxy uses port number 80. Incoming traffic communicates first with HAProxy, which serves as a reverse proxy and forwards requests to an available endpoint, as defined by the load balancing algorithm you've chosen.

In this example, the frontend sample_httpd listens on port number 80, directing traffic to the default backend sample_httpd with mode tcp. In the backend section, the load balancing algorithm is set to roundrobin. There are several algorithms to choose from, including roundrobin, static-rr, leastconn, first, random, and many more. HAProxy documentation covers these algorithms, so for real-world uses, check to see what works best for your setup.

Managing traffic on your servers is an important skill, and HAProxy is the ideal tool for the job. Load balancing increases reliability and performance while lowering user frustration. HAProxy is a simple, scalable, and effective way of load balancing among busy web servers.

Layer 4 NAT Traditional NAT mode gives easy to implement fast and transparent load balancing but usually requires a two-arm configuration (two subnets).HTTPS443All load balancing methods can be easily configured for SSL Pass-through. This has the advantage of being fast, secure and easy to maintain. Identical SSL certificates will need to exist on each of your backend servers for pass-through security.

SSL Termination or off-loading must be used when advanced Layer 7 functionality such as cookies or URL switching is required. You can also implement SNI if you have multiple domain certificates one public IP address. Optional re-encryption is also available between the load balancer and Apache.HTTP/2N/ALayer 7, support is imminent, this is due/expected in the 8.3.4 timeframe.Proxy ProtocolN/AApache support from v.2.4.31Load Balancing Apache Web Servers with OWASP Top 10 WAF in AzureRead blogguidesApache Web Servers with OWASP Top 10 WAF in Azure Deployment Guide

I did a load balanced with apache and the mod_proxy. Everything work well and I can load balance between two servers.Now I would like to do more.First I would like to do failover (if a server down, all the charge go to the other one)> Does it work only with this: nofailover=On ?Then I would like to have a second load balancer as a backup if the first one down. I search on internet but I didn't find.Do you know if it's possible to do it?To finish, Does it possible to change the configuration (like the ip of the server) in the load balancer without restart it because it's running?

One common method to set up a second load balancer would be to just set up a second system with identical configuration, and use DNS round robin to let users hit whichever one they happen to hit. Of course, this can incur delays for clients if one of the load balancers goes down; not a good thing.

Another option is to use VRRPd. I won't go into the implementation specifics here, but it would have your two load balancers sharing a single virtual IP address, which would move to the other device if one of them becomes unreachable.

At a certain amount of traffic, or a certain need on availability, you might consider using multiple public instances. Most likely those instances are on different servers as well. This guide will illustrate how to setup a load-balanced system using three different servers, where one acts as the load-balancer (using Apache for splitting the requests) and the two remaining servers host the LogicalDOC public instances.

This server will handle all HTTP requests from site visitors. As you might see, this means even though you run a load balanced system, using only a single load balancer means you still have a SPOF (single point of failure). It is also possible to configure an environment where yet another server will act as the fail-over load-balancer if the first one fails, but this is outside the scope of this guide.

Let's look at the relevant configuration here to set up the load-balancer. Most likely you will also have an Apache web-server installed on this machines, as for accessing the author instance if located on one of this servers with a nice URL. Here we suggest to use a single Tomcat application server for hosting one public instance. Make sure the AJP Port is set correctly to what you have defined in the virtual host configuration of the load-balancer (8009 as the default value used here).

Now in the same file as we configure the AJP Port server.xml we need to configure the jvmRoute for sticky sessions working correctly. Use the name defined in the virtual host configuration on load-balancer, the route value here separately for the two servers.

That's basically it. Now you can set your DNS entry of www.yourcompany.com to your Load-Balancer's IP address and enjoy the comfort and security of a redundant LogicalDOC installation. If one of the public LogicalDOC servers is failing, mod_proxy on your load-balancer will automatically detect this and stop serving requests to that server.

This example requires mod_proxy_balancer and mod_status. The mod_proxy_balancer module provides you with a graphic web interface to dynamically manage the various members of the set. You can some screenshots of the interface from Apache documentation Reverse Proxy Guide

Workers managed by the same load balancer worker are load balanced(based on their configured balancing factors and current request or session load)and also secured against failure by providing failover to other members of the sameload balancer. So a single Tomcat process death will not "kill" the entire site.

The load balancer supports complex topologies and failover configurations.Using the member attribute distance you can group members.The load balancer will always send a request to a member of lowest distance.Only when all of those are broken, it will balance to the members of thenext higher configured distance. This allows to define priorities betweenTomcat instances in different data center locations.

When working with shared sessions, either by using session replicationor a persisting session manager (e.g. via a database), one often splitsup the Tomcat farm into replication groups. In case of failure of a member,the load balancer needs to know, which other members share the session.This is configured using the domain attribute. All workerswith the same domain are assumed to share the sessions.

For maintenance purposes you can tell the load balancer to notallow any new sessions on some members, or even not use them at all.This is controlled by the member attribute activation.The value Active allows normal use of a member, disabledwill not create new sessions on it, but still allow sticky requests,and stopped will no longer send any requests to the member.Switching the activation from "active" to "disabled" some time beforemaintenance will drain the sessions on the worker and minimize disruption.Depending on the usage pattern of the application, draining will take fromminutes to hours. Switching the worker to stopped immediately beforemaintenance will reduce logging of false errors by mod_jk.

The redirect flag on worker1 tells the load balancerto redirect the requests to worker2 in case that worker1 has a problem.In all other cases worker2 will not receive any requests, thus actinglike a hot standby.

A final note about setting activation to disabled:The session id coming with a request is send eitheras part of the request URL (;jsessionid=...) or via a cookie.When using bookmarks or browsers that are running since a long time,it is possible to send a request carrying an old and invalid session idpointing at a disabled member.Since the load balancer does not have a list of valid sessions, it willforward the request to the disabled member. Thus draining takes longer thanexpected. To handle such cases, you can add a Servlet filter to your webapplication, which checks the request attribute JK_LB_ACTIVATION.This attribute contains one of the strings "ACT", "DIS" or "STP". If youdetect "DIS" and the session for the request is no longer active, delete thesession cookie and redirect using a self-referential URL. The redirectedrequest will then no longer carry session information and thus the loadbalancer will not send it to the disabled worker. The request attributeJK_LB_ACTIVATION has been added in version 1.2.32.

Comments:I'm using mod_proxy in apache 2.4.7 My configuration for a sample site is like below, My problem is when one of the back-end servers goes unresponsive, My load balancer still sends requests to the dead back-end server and clients are complaining. What is wrong with the below config:

After your comments: It depends on how the balancerMember stops responding. If a connection can still be made, but no error code and no response is forthcoming you might benefit from setting the timeout and failontimeout options.

But how to do it on the load-balancing server? For instance, I have a website on which I can click a button (app1.0, app1.1, app1.2 etc.) and an URL pops up like: www.lb.com/app1.0/.../... How to direct to the app based on application version in URL? Use RewriteCond and regex and pass it to ProxyPass? I don't really how to script it, anyone could help? :)

One way to distribute transaction load across multiple physical servers is to give each server a separate task. For your www.example.com site, use animages.example.com server to serve static image content, a secure.example.comserver to handle SSL transactions, etc. This approach allows you to tune each server for its specialized task. The downside is that this approach does not scale by itself: once, for instance, your secure server runs out of processing headroom, you will have to add more machines using one of the techniques described below. 041b061a72