Apache server has been most popular web server to host sites and has loads of modules that can be used for the special cases.

We once came across a scenario where the IP for the live application was to be changed but that would need the app to be updated on Apple store also which is a takes at least a week before approval.
The challenge here was to keep the new app and the old app both running from the new server.

This is where mod_proxy came to rescue.

mod_proxy is one of the main modules provided by Apache and can be used to make your server work as a proxy.

We needed all the requests from old server to be forwarded to the new one and to do so, we added the configuration for the mod proxy.

To better understand mod proxy let us go through the basic settings first and then use our scenario to get this working.

ProxyRequests On|Off
This directive tells apache server whether to allow the Proxy Requests or not.

<Proxy *>
        Order deny,allow
        Allow from all
    </Proxy> 

This blocks tells which requests are to be handled by proxy block and which IP's are allowed to make this proxy requests, in the above example we have it enabled for all but you can restrict this to an IP or an IP block as listed in below examples.

eg. 1) Allow from 192.168.1.29
eg. 2) Allow from 129.186.29.1

then we specify the URL pattern that needs to be redirected thru the proxy, in our case we wanted all the requests to go thru the proxy as in example below.

ProxyPass / http://192.186.81.230:80/
ProxyPassReverse / http://192.186.81.230:80

So the changes below in your server config file would redirect all the requests to your server would forward it to the server with IP 192.186.81.230.

Example of a balancer configuration

The below example will show how you might use mod_proxy_balancer to provide load balancing between two back-end servers:

<Proxy balancer://mycluster>
    BalancerMember http://192.186.81.230:80
    BalancerMember http://192.186.81.231:80
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster

The first two lines of block enables us to refer to web servers by name. The ProxySet directive declares which algorithm to use for load balancing. The above instructs to use the byrequest algorithm to balance (You can find a brief intro to load balancing algorithm at the end of this article).

All this needs to be wrapped in tags to let apache know it needs to be sent to mod_proxy. The balancer://mycluster can be any valid identifier provided it contains balancer:// as prefix.

Stickyness

It is a common for servers to manage some session or cookie. A common problem arise while balancing is what if a request from one client is routed to one server and another request from same client gets routed to another server (By default, a load balancer routes each request independently to the application instance with the smallest load.).
However, you can use the sticky session feature. To bind a user's session to a specific application instance, load balancer is enabled by this sticky session. This makes sure that all requests from a particular user during the session are sent to the same application instance.

Another example of how to provide load balancing with stickyness utilizing mod_headers, even if the back-end server does not set a felicitous session cookie:

    Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
    <Proxy balancer://mycluster>
        BalancerMember http://192.186.81.230:80 route=1
        BalancerMember http://192.186.81.231:80 route=2

        ProxySet stickysession=ROUTEID
    </Proxy>
    ProxyPass /test balancer://mycluster

You final configuration entries should look something like this :

<VirtualHost *:80>
        ProxyRequests off

        ServerName domain.com

        <Proxy balancer://mycluster>
                BalancerMember http://192.186.71.230:80

                BalancerMember http://192.186.71.234:80

                Order Deny,Allow
                Deny from none
                Allow from all
ProxySet lbmethod=byrequests

        </Proxy>

        ProxyPass / balancer://mycluster/
</VirtualHost>

Restart Apache and you should be good to go.

Load balancer scheduler algorithm

Currently there are 3 load balancer scheduler algorithms available for use and all these are controlled via the lbmethod value of the Balancer definition:
1. Request Counting
2.Weighted Traffic Counting
3. Pending Request

Request Counting Algorithm

Enabled via lbmethod=byrequests, the conception abaft this scheduler is that we distribute the requests among the sundry workers to ascertain that each gets their configured quota of the number of requests. It works as follows:

lbfactor is how much we expect this worker to work, or the workers's work quota. This is a normalized value representing their "share" of the amount of work to be done.

Ibstatus is how exigent this worker has to work to consummate its quota of work.

The worker is a member of the load balancer, customarily a remote host serving one of the fortified protocols.

We distribute each worker's work quota to the worker, and then look which of them needs to work most exigently (most immense lbstatus). This worker is then culled for work, and its lbstatus reduced by the total work quota we distributed to all workers. Thus the sum of all lbstatus does not transmute and we distribute the requests as desired.

Weighted Traffic Counting Algorithm

Enabled via lbmethod=bytraffic, the conception abaft this scheduler is very kindred to the Request Counting method, with the following changes:

lbfactor is how much traffic, in bytes, we optate this worker to handle. This is withal a normalized value representing their "share" of the amount of work to be done, but in lieu of simply counting the number of requests, we take into account the amount of traffic this worker has optically discerned.

Pending Request Counting Algorithm

Enabled via lbmethod=bybusyness, this scheduler keeps track of how many requests each worker is assigned at present. An incipient request is automatically assigned to the worker with the lowest number of active requests. This is utilizable in the case of workers that queue incoming requests independently of Apache, to ascertain that queue length stays even and a request is always given to the worker most liable to service it most expeditious.

In the case of multiple least-diligent workers, the statistics (and weightings) utilized by the Request Counting method are habituated to break the tie. Over time, the distribution of work will come to resemble that characteristic of byrequests.

This algorithm is available in Apache HTTP Server 2.2.10 and later.