In this final guide on how to set up a high availability network using VPS servers, we’re going to set up HAProxy on an Ubuntu 20.04 LTS NVMe VPS Instance. We are then going to use this to load balance the connection on a test network we have already configured. We are going to set up HAProxy server that is already running on a cloud for high availability. Your HAProxy server must be on a high availability service.
On our test network, we already have a database server, a backup server, two instances with our web site’s files and this instance for HAProxy. Eventually, we will combine these together to create a high availability service, hosted without any need for special network configurations. Let’s look at this as an image.
We’ve been load balancing with Cloudflare to test our existing setup so now, we are going to substitute Cloudflare with HAproxy. Data from our FR-Blog server is being replicated to the UK-Blog server using lsyncd.(Install LsyncD) (on a cloud you would have network storage here)(not actually our blog). Each server is connected to an internal database server. That is also located on a high availability NVMe VPS so we don’t have a single point of failure. With this design, we could duplicate the UK-Blog server in a different location and easily add a new instance to the network. We will do this in another article.
So, let’s set up HAProxy server, first add the Personal Package Archive (PPA) to the apt sources list then we can update the instance and install the files.
add-apt-repository ppa:vbernat/haproxy-2.5 apt update apt install haproxy
Now that HAProxy is installed let’s configure it.
Set Up HAProxy Server
For the purpose of this article, we want to set up HAProxy as a load balancer. In its default form, HAProxy is not bound to a port. Copy the configuration file and edit the original.
cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg_backup nano /etc/haproxy/haproxy.cfg
So in this file, we want to tell HAProxy what port to listen on and what servers to connect to. At the bottom of the file, we specify this with the code below. Change the values to represent the servers you want HAProxy to route connections to. We will deal with SSL support later on in the article. We are wanting to load balance and provide high availability on our blog. So, specify your domain name in the frontend section. Next, in the backend section specify the instances with the content of your website on. This was completed in the previous article.
In the final section, specify a port for HAProxy to listen on and a username + password. This will be used to monitor the connections.
frontend http-in bind *:80 acl host_d1 hdr(host) -i blog.f2h.cloud use_backend be_d1 if host_d1 backend be_d1 server FRM1 10.50.50.1:80 check server UKM2 10.10.20.42:80 check listen stats bind :32700 stats enable stats uri / stats hide-version stats auth user:password
Once you have completed this save the file and restart HAProxy
systemctl restart haproxy systemctl status haproxy
So let’s just recap here. When we start routing connections to our HAProxy server. Those connections will be routed to two backend servers. HAProxy distributes traffic evenly and if one backend server goes offline the other will pick up the slack. Our HAProxy server is already running on a high availability service.
Activating High Availiability
Because we are using Cloudflare we don’t have any requirement to install our network with an SSL. Cloudflare will automatically convert all connections to SSL as they enter the network. So, now we need to update the A record for the blog to point to our HAProxy server. This will then activate our blog on the high availability network we have created.
Updating the A record shows both backend servers are online and receiving requests. Now, if one of those backend servers falls offline the other one will pick up the slack. Because we are using a database on the network, any changes made in our database is synced over both backend servers.
Have you noticed the flaw with this setup yet? Because there is no network-attached storage there is a link missing in the chain. We synced data from the FR server to the UK server. But what happens if a change is made on the UK server? That won’t be replicated back to the FR server. Without network-attached storage, it’s difficult to overcome this but there are solutions.
- You could configure LSyncD on the UK host to sync back to the FR host. It’s not ideal but it does work.
- If your backend servers are located in the same region, you could use a Cloud VPS to host an NFS server on. You would copy your websites files from the /var/www/ folder to the NFS server and mount that in your backend servers. A simple change to the location of the website’s documents in the Apache configuration is made to point to the network-attached storage.
You might also like
More from Linux VPS Servers
If you have installed your Discovery instance using a distribution ISO. Then it's likely your drive will be using a …
Cloud-init is a popular way to automate deployments of instances in a cloud or none cloud environment. To save having …