Web interface illustrates the current state of load balancers and their nodes.

The following info is shown for the balancer nodes:

• Worker URL;
• Route: name of balancer member;
• RouteRedir: name of the node to redirect requests to in case of inaccessibility;
• Factor: mamber relative weight;
• Status: state of member;
• Elected: how many times the node was chosen to process request, i.e. practically the number of processed requests;
• Transmitted: number of bytes sent to the node;
• Received: number of bytes received from the node;
• EMA ResponseTime: exponential moving average of response time
• Status TTL: period of time for which the node is excluded from the balancing process due to inaccessibility.

Here’s how you can set this handler to enjoy all this stuff:

<Location /balancer-manager/>
  SetHandler balancer-manager
  Order allow,deny
  Allow from 127.0.0.7 ::1 localhost
</Location>

Please pay attention that the URL to which the handler is mapped must be secured from unauthorized access. For instance, the access must be granted for local machine only (see example above) or basic/digest authorization must be enabled.

Feel free to try our web interface for the load balancer to facilitate control and get comprehensible statistics for any node and any balancer.

Best wishes,
Ruslan – Helicon Tech Team

Goal

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 [session_data]![backend_id].

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.

Configuration

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.

BalancerMember http://static1.site.com/media/

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 http://www.site.com/static/[path].

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.

ProxyPassReverse and 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:

• byrequests to perform weighted request counting;
• bytraffic to perform weighted traffic byte count balancing;
• random to perform weighted random balancing;
• byresponsetime to perform weighted response time balancing.

Nodes accessibility

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.

Best wishes,
Helicon Tech Team

Proxy-server is a network service empowering clients to perform indirect requests to other network services. Proxy-server may be considered an intermediary. The brief description of proxy-server operation is as follows:

• client connects to proxy-server (front-end server)
• asks proxy-server for some resource located on another server
• proxy-server connects to the specified server (back-end server)
• gets requested resource
• gives out resource to the client

And the client may be ignorant that the requested resource was delivered from another server.

What is HTTP-proxy

HTTP-proxy is an implementation of proxy service for HTTP protocol. HTTP-proxy may be either reverse or forward.

Reverse HTTP-proxy usually lives between external network and internal network, it resolves external namespace into internal one, it is a barrier between external clients and live web-servers on the Intranet. The example is given below. Reverse HTTP-proxy is used to disguise internal network infrastructure, balance load among back-end servers, caching and HTTP responses compression. As a rule external clients have no idea that they are getting response from reverse proxy server.

Forward HTTP-proxy (aka Web-proxy) is used to reside between internal network and external network (Internet) and restrict access to specific HTTP resources, HTTP responses caching and web surfing. To make use of forward proxy the client shall explicitly specify its address (e.g. in browser settings). HTTP requests to forward proxy look like:

GET http://example.com/ HTTP/1.1
Host: example.com
Accept: */*
User-Agent: Mozilla

Note! The peculiarity of forward proxy request in comparison with direct request is that the path after GET (and any other HTTP method) is a fully qualified URL (including protocol and host part) and not just the local path to destination (starting with /).

Helicon Ape mod_proxy

Helicon Ape owns a mod_proxy module that implements both reverse and forward proxy functionality. All basic aspects of this module along with examples may be found in the docs.

Forward proxy in Helicon Ape is enabled by ProxyRequests On directive. Before enabling you need to secure your server so that only authorized users could access the proxy.

Reverse proxy is enables by ProxyPass directive. For example:

ProxyPass /app/ http://backend.domain.com/

or (the first parameter may be omitted when the directive is used inside <Location> section or .htaccess):

<Location /app/>
  ProxyPass http://backend.domain.com/
</Location>

The above config will proxy all requests starting with /app/ to backend.domain.com previously removing /app part from the path:
/app/item/33/ -> http://backend.domain.com/item/33/.

To make HTTP response headers change when reverse proxying (e.g. Location header upon redirect) ProxyPassReverse directive may be used, and to change domain names and paths in cookies the following directives are used: ProxyPassReverseCookieDomain and ProxyPassReverseCookiePath.

Now we’ll illustrate you an example of non-trivial proxy application.

Example: load balancing

Given: front-end server example.com visible from external network.

Goal: Realize load balancing among three back-end application servers accounting for their performance and two back-end servers storing static files (images, CSS, etc.). Say, the second and the third back-end application servers are twice as productive as the first one, and the second back-end for static is thrice as powerful as the first one.

Solution. The reverse proxy configuration in httpd.conf will be:

<VirtualHost *:80>

ProxyPass /static/ balancer://cluster-static/ lbmethod=bytraffic

<Proxy balancer://cluster-static>
  BalancerMember http://static1.example.com/ loadfactor=1
  BalancerMember http://static2.example.com/ loadfactor=3
</Proxy>

ProxyPass / balancer://cluster-app/ lbmethod=byrequests

<Proxy balancer://cluster-app>
  BalancerMember http://app1.example.com/ loadfactor=1
  BalancerMember http://app2.example.com/ loadfactor=2
  BalancerMember http://app3.example.com/ loadfactor=2
</Proxy>

</VirtualHost>

The search of ProxyPass directive to match current request is performed subsequently, so directives with shorter matching patterns should be put lower in the config. balancer: protocol in ProxyPass directive tells that requests will be forwarded to the URLs specified in subsequent BalancerMember directives. lbmethod=byrequests parameter indicates that balancing will be based on the number of requests to back-end server; bytraffic value means that load balancing will depend on the quantity of bytes transmitted from back-end.

Compression and caching

To accelerate your proxy-server responses from the back-end may be compressed and cached. To do that we add the following line into the VirtualHost section of our htpd.conf:

# enable compression
SetEnv gzip 

# enable caching
CacheEnable mem http://app1.example.com/
CacheEnable mem http://app2.example.com/
CacheEnable mem http://app3.example.com/

Please notice that caching will only work if the response from back-end contains expiration headers; e.g., Cache-Control: max-age=60.

Conclusion

As you could see Helicon Ape mod_proxy module possesses full-fledged proxy functionality to satisfy the most exacting needs.

Best wishes,
HeliconTech Team