Helicon Ape mod_proxy module provides simple way to configure load balancer. This article is giving explicit instructions of how to configure and test such load balancer.
Create simple cluster in which one front-end server (www.site.com), accessible via Internet, proxies some application operation in an intranet (not accessible via Internet).
To improve stability (resistance to failures) and speed the application will run on internal servers (app1.site.com & app2.site.com) which will distribute requests between themselves. In case one server is down (scheduled maintenance, upgrade, breakdown), all requests will be directed to another server.
Requests between the servers are distributed based on the response time value. I.e. the quicker back-end returns responses (better copes with the load), the more requests it will get.
The application uses sessions, so if the request contains the cookie with session id, this request must be assigned to the back-end which initiated this session. The cookie is of the following format
Static content is also shared between two internal servers (static1.site.com & static2.site.com) so they need to distribute it among themselves as well.
Here’s the sample configuration of the balancer described above:
<VirtualHost www.site.com> # route all requests starts with /static/ to static balancer ProxyPass /static/ balancer://static-balancer/ <Proxy balancer://static-balancer/> # describe static balancer members BalancerMember http://static1.site.com/media/ BalancerMember http://static2.site.com/media/ </Proxy> # enable reversing of response redirects ProxyPassReverse /static/ http://static1.site.com/media/ ProxyPassReverse /static/ http://static2.site.com/media/ # route all other requests to application balancer ProxyPass / balancer://app-balancer/ stickysession=sessionid routeregex=!(.*)$ <Proxy balancer://app-balancer/> # describe application balancer members BalancerMember http://app1.site.com/ route=app1 BalancerMember http://app2.site.com/ route=app2 </Proxy> # enable reversing of response redirects ProxyPassReverse / http://app1.site.com/ ProxyPassReverse / http://app1.site.com/ # enable reversing of domain in Set-Cookie headers ProxyPassReverseCookieDomain app1.site.com www.site.com ProxyPassReverseCookieDomain app2.site.com www.site.com </VirtualHost>
What was that?
And here’s the explanation of the code above.
<VirtualHost www.site.com> ... </VirtualHost>
section conditions that all directives inside it are applied only to the requests to www.site.com. This is especially important when the server manges several sites.
ProxyPass /static/ balancer://static-balancer/
directive tells mod_proxy that all requests beginning with
/static/ must be proxied via static-balancer balancer.
<Proxy balancer://static-balancer/> ... </Proxy>
section stores directives for static-balancer, members of this balancer in particular.
directives define balancer members: their working URL and load factor.
ProxyPassReverse /static/ http://static1.site.com/media/
directives are needed to reverse proxy the redirects coming from the back-ends. All redirects with URLs like
http://static1.site.com/media/[path] will be substituted with
These were the rules for static content balancer. Now let’s look at the balancer for the application itself.
ProxyPass / balancer://app-balancer/ stickysession=sessionid routeregex=^(.*)$
directive tells mod_proxy that all other requests must be proxied through app-balancer balancer. As the rule for /static/ folder is above, it will be applied earlier.
The balancing must be relative to back-end response time (default
lbmethod=byresponsetime), i.e. the back-end with faster response time will get more requests with probability reverse-proportional to the response time. Response time for each back-end is averaged according to exponential moving average algorythm.
stickysession=sessionid parameter defines the name of the cookie storing the session id, and
routeregex=!(.*)$ defines the regular expression to match the request route in the cookie value. In our case it’s everything after the exclamation mark (‘!’).
BalancerMember http://app1.site.com/ route=app1
directives define app-balancer members.
route=app1 assignes the name to this node (route) which will be used to direct requests with corresponding sticky session.
ProxyPassReverseCookieDomain directives serve to reverse proxy redirects (Location header) and domains in cookies (Set-Cookie header).
Other types of load balancers
The method of load balancing is defined by
lbmethod parameter of
ProxyPass directive and may be one of the following:
byrequeststo perform weighted request counting;
bytrafficto perform weighted traffic byte count balancing;
randomto perform weighted random balancing;
byresponsetimeto perform weighted response time balancing.
The node is considered inaccessible if the balancer cannot connect to it. In such case the balancer marks it as
IN_ERROR and excludes from the balancing process. In our situation it means that if app1.site.com is not accessible (e.g. due to upgrade), then the balancer will route all requests to app2.site.com.
statusttl parameter of
BalancerMember directive defines the period of time in seconds after which it’ll retry to establish connection to this node. The default is 300 secs.
You can learn more about mod_proxy directives and features from mod_proxy manual.
Helicon Tech Team