Example – load balancing a web server

As a means of demonstrating some of the options available with HAProxy, we will show HAProxy in action by revisiting an example from Chapter 8Redundancy and High Availability, in which we load balanced three Apache web servers.

Once we install HAProxy, we navigate to Services | HAProxy to begin configuration and click on the Settings tab. We will not check the Enable HAProxy checkbox right away; rather, we will do that last after all other configuration has been completed. There is a Maximum connections edit box which allows us to set the maximum number of per-process concurrent connections, along with some guidelines on how much memory connections will use. Unless your pfSense firewall has an unusually high amount of memory, it behooves you to limit the number of concurrent connections; in this case, we enter 5000

The next option is Number of processes to start, which defaults to 1 if left blank. The instructions recommend keeping this setting at the default value, which is what we will do. The Reload behavior checkbox, if checked, will force the old HAProxy process to stop when HAProxy is restarted, even if it is still serving old connections. In other words, old connections will be dropped when HAProxy is restarted, which is not what we want, so we will leave this option unchecked. We will also assume that in this case, we are not running a CARP failover group, so we will leave the Carp monitor drop-down box set to Disabled.

Scrolling down to  Stats tab, 'internal' stats port, we set Internal stats port - this can be any unused port. Under Logging, we want to log HAProxy activity to the local pfSense systemlog, so we enter /var/run/log in the Remote syslog host edit box. We scroll past the Global DNS resolvers for haproxy section, but we want to add email notifications, so under Global email notifications we add a mail server. Under Name, we enter an appropriate name (example, Local mail server); under Mailserver, we enter the IP address of the local email server (assume that the email server, like the web servers, are part of the DMZ network, and that the IP address is 192.168.2.20); for Mailserverport, we enter 25 - the default SMTP port. We also check the checkbox to the left of these edit boxes. Mail level allows us to define the maximum log level for which emails will be sent. Since we only want to receive emails if the situation is critical or worse, we set Mail level to Critical. Mail myhostname allows us to define the hostname to be used as the sender of the emails and Mail from allows us to define the email address which will be seen as the sender. For these two parameters, the actual value used is not important to the functioning of email notifications, but we should follow any conventions we have been using in configuring our network.

Finally, there is one last setting in this section whose value is important: Mail to, which allows us to set the email address to which notifications will be sent. In the Tuning section, we set Max SSL Diffie-Hellman size to 2048. When we are done, we scroll to the bottom of the page and click on the Save button and then the Apply Changes button at the top of the page. There is also  a Show button at the bottom of the page which, if clicked on, will show the current /var/etc/haproxy/haproxy.cfg configuration file, reflecting any changes that have been made. 

We click on the Backend tab (it's easier to configure the frontend after the backend has already been configured) and click on the Add button to begin backend configuration. we enter an appropriate Name (example, WEBSERVERS), and click on the down arrow under Server list to begin adding the backend web servers. You might recall that the IP addresses for the servers were 192.168.2.11, 192.168.2.12, and 192.168.2.13. We give the server a Name (example, WEB1); under Address we enter 192.168.2.11, and under Port we enter 443. We check the SSL checkbox, and for now we leave Weight unchanged.

Underneath the basic server configuration are a number of options related to SSL certificate verification. Essentially, if our servers use SSL, we have the option of verifying the client's SSL certificate against certificates that have been added with the Cert. Manager. In this case, we will assume that the web servers are configured to do SSL verification and not take advantage of this feature. 

We repeat the server configuration process for each of the other servers, three in total, in each case setting the port to 443, enabling SSL on each of them and leaving Weight unchanged. We scroll down to Loadbalancing options, click on the plus icon in the right portion of the column to expand this section, and choose Least Connections as the load balancing Option. Scrolling down, there are two sections that are worth noting. There is the Health checking section, which allows us to set a number of parameters controlling how HAProxy checks to see if a server is still up. A number of protocols are supported; HTTP is the default but LDAP, MySQL, SMTP and SSL are supported, to name a few. The Stick table persistence section allows you make sure separate requests from a single client go to the same backend. There are different criteria we can use to determine if a client is the same client. One is the SSL ID, the IP address (IPv4 or IPv6), or a cookie (standard cookie or RDP cookie). We will leave the defaults in these sections unchanged and click on the Save button and then the Apply Changes button.

We next click on the Frontend tab and click on the Add button to begin frontend configuration. We enter an appropriate Name (which can be the same name as the backend), an appropriate Description (example, Apache web server load balancing group) and leave the Status set to Active. For the Listen address, we want to use our WAN address, so we leave that at its default setting. Our web server is using HTTPS, so we change the Port to 80, and also check the SSL Offloading checkbox. We also check the checkbox in the leftmost column of this row.  Then we scroll down to the Default backend, access control lists and actions section and set Default Backend to the backend we configured in the previous step (WEBSERVERS). We then click on the Save button and click on the Apply Changes button.

HAProxy setup is complete, but we still need to create a rule to allow port 443 traffic on the WAN interface. We navigate to Firewall | Rules, and on the WAN tab we click on one of the Add buttons. Most of the settings can be kept at their defaults (Action, Interface, and Protocol are all by default at their correct settings), but we want to set Destination Port Range to 443 to allow HTTPS traffic on this port to pass through (port 443 is one of the presets in the drop-down box, although you can type it into the edit box as well). We enter a brief description (example, Allow web server traffic) and click on the Save button and then click on the Apply Changes button. After making sure the rule order is correct, we navigate back to Services | HAProxy, click on the Settings tab, and then check the Enable HAProxy checkbox. Then we scroll down, click on Save, and click on Apply Changes. To confirm that the load balancing pool is up and running, navigate to Status | HAProxy Stats and check.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset