Share this page:
Apache can be configured as a proxy to redirect HTTP traffic to other servers. When Apache is configured as a reverse proxy, it receives HTTP requests from the internet, and forwards them to another server to process the request. This server, often referred to as a backend server or a worker node, sends a response through the proxy back to the client.
Proxies often have more than one network interface. One network interface receives HTTP requests from clients, and the other network interface forwards HTTP requests to servers on a different subnet. Proxies act a bit like TCP/IP routers, but they don't forward all traffic, just HTTP requests and responses. The interface that receives incoming HTTP requests can be considered the public interface, while the interface on the same subnet as the servers is a private interface. This means the backend servers that handle web traffic can be kept on a seperate subnet from the rest of the network.
A reverse proxy is often used as a gateway to a collection of servers. They can direct traffic for different sites to different servers. This is useful if there are several servers, and each one hosts a different web site. It means that several sites to be hosted from a single IP address. In this case, the domain names for several different sites would point to the proxies public interface, and the proxy forwards traffic to different servers based on the host name in HTTP requests. Alternatively, a reverse proxy can spread the load across a collection of identical servers.
This is useful in situations where more than one server is required to handle the traffic for one site. In this example I'm going to set up a reverse proxy to a cluster of servers that all host the same site.
The proxy needs to have at least two network interfaces, and they should both be on different subnets. You can access the network settings by clicking on the networking icon in the top left corner of the screen, and selecting 'Edit Connections...' from the drop down menu.
In the network connections dialogue, select 'Wired connection 1' and click on the edit button:
This will bring up a dialogue for the public network interface. Click on the IPv4 settings tab, and in the method tab, select manual. Enter an IP address, netmask and gateway:
Save the settings, and then edit the settings for the second network interface:
Note that the public interface has an IP address on subnet 192.168.0, and the private interface has an address on subnet 192.168.1. Apache will listen for requests on the public interface, and forward them to backend servers through the private interface.
Make sure Ubuntu is up to date, and then install Apache:
Install some Apache modules:
Check which version of Apache was installed:
This step isn't necessary with Apache 2.2, but with Apache 2.4, fewer modules are enabled by default, so you will also need to enable these modules:
The virtual host file that's used to configure Apache must contain directives that tell Apache how many servers there are in the cluster of worker nodes, and what traffic to forward to those nodes. I'm going to use the default virtual host file, 000-default.conf, to store these directives. (Note that if you're working with Apache 2.2, the default virtual host file is called default.conf.) Use this command to open the file in gedit:
Suppose the reverse proxy needs to forward traffic for a site named example.com to a cluster of servers. The ServerName directive is used to make this virtual host handle traffic for any request with example.com in the host name. The ServerAlias directive is set up to ensure that this virtual host also handles traffic for subdomains of example.com.
It's best to turn off proxy requests for security reasons. Otherwise people could use your server as a proxy to hide behind while they engage in illegal activity. It's also a good idea to make sure the host name is preserved when the reverse proxy forwards HTTP requests. You can acheive these things by adding the following two lines to the virtual host:
In this example I'm going to assume that there are two servers in the cluster with identical web sites on each of them, and with IP addresses 192.168.1.13 and 192.168.1.14. The virtual host file must contain a definition of the cluster that will handle traffic for this site:
This defines a cluster called my_cluster with two worker nodes. The ProxySet directive is used to tell the load balancer to distribute requests in a round-robin manner. Requests can also be ditrbuted based on the amount of traffic that each backend server has sent:
or by the number of pending requests on each backend server:
The ProxyPass directive is used to send traffic matching a particular URL to the cluster. In this case all traffic needs to be forwarded to my_cluster:
The complete virtual host file should look something like this:
Save the file and restart Apache:
On a PC on the local network, open a browser and visit the IP address of the load balancer's public interface. The request will be passed through the reverse proxy to one of the backend servers which will handle the request and send a response back through the proxy. The web site on the backend server should be visible in your browser. Try modifiying a page on one of the servers. If you view the modified page and hit Shift-F5 to force the browser to refresh, the modified page will be displayed about 50% of the time.
If you have problems getting this to work, check Apache's logs on the load balancer (access.log and error.log in /var/log/apache2/), and also check the web server logs on the backend servers.
Following on from the previous post about configuring Apache as a reverse proxy, in this post I'm going to look at setting up the balancer manager web UI.
The balancer manager UI can be used to change settings on the load balancer without having to restart Apache. It also provides feedback on problems with the nodes in the cluster.
The UI is enabled by editing the virtual host file that contains the balancer settings. In the last post, I set up the load balancer by editing the default virtual host file, so I'm going to open that file again:
The following code needs to be added beneath the Proxy definition:
This tells Apache that requests to the /balancer-manager URL should be handled by the balancer manager module, and it should only be accessible from addresses on subnet 192.168.0. The ProxyPass directive is used to tell Apache that requests to /balancer-manager should not be proxied - they should be handled locally by the balancer manager module.
Save the file and restart Apache:
Now visit your load balancer's public IP address in a web browser with /balancer-manager added to the URL (for example, http://192.168.0.2/balancer-manager). You should see something like this:
If you click on the link for the balancer status, you'll be able to edit settings for the load balancer's timeout period, the load balancing algorithm, and failover options.
By clicking on URLs of the worker nodes, you can bring up options that control individual servers:
The load factor determines what proportion of requests are sent to a given server. For example, if the load factor is set to 2 for one of the worker nodes, that node will be sent twice as many requests as servers that have a load factor of 1. Worker nodes can also be disabled using this interface, which is useful if you need to do maintenance on a server. Disabling the node stops the load balancer from sending sending traffic to it, so you can work on the server without interrupting user's access to the site.
Note that any settings entered into the UI will be lost when Apache is restarted.