high availability Configuring WHMCS to run in a High Availability environment

[WHMCS JoshQ]

For many of our clients, it is absolutely crucial that their WHMCS installation is always accessible, especially when outages start to occur. You may, therefore, want to run WHMCS in a High Availability environment.

This post doesn't serve as a guide on how to set this up, but rather as a collection of thoughts and best practices that may point you in the right direction.

What is High Availability?

Rather than explaining the ins-and-outs of High Availability (HA) to you in my own words, I'd like to point you towards the brilliant blog post written by @Matt a few years ago which explains it beautifully:

Quote

Availability is used to describe the period of time for which a service is online and operational. With high availability, we're trying to create a system that operates continuously, even when some of its components fail. We do this by eliminating single points of failure and thereby keeping things online more of the time.

At its simplest, High Availability is the idea of having redundancy at every level of the web stack.

Choosing a cluster design (Active-Active vs Active-Passive)

The first decision that you need to make is whether you want to run your HA cluster in an Active-Active configuration or an Active-Passive configuration.

• In an Active-Active configuration, traffic will be directed to all servers in the cluster via a load balancer, which is essentially responsible for making sure that no singular node is getting more traffic than any other node. Not only does this provide fault tolerance with no downtime if a node goes offline, but more importantly allows you to deliver your WHMCS installation to an unlimited number of clients, no matter the size of your organisation, as you can easily scale-up the number of nodes running according to demand.
• In an Active-Passive configuration (often referred to as Failover), all traffic will be routed to a single server; should that server go offline, another server 'wakes up' and takes over. Where you don't have extremely high traffic but your installation is mission-critical for your business, this is often the best choice as it is simpler to configure and less prone to configuration errors.

There are many deviations to these designs and different ways of configuring each (e.g. Active-Active in a round-robin configuration), but these are the simplest and most common strategies used in production.

Regardless of which design you choose, you are going to need a minimum of three servers (and an S3 bucket for the most optimal setup).

Designing your cluster

In this example, we will be configuring a cluster with the following servers:

• Web001 - Primary web and database server
• Web002 - Secondary web and database server
• LB1 - Load balancer / reverse proxy

In addition to these servers, we will also be making use of an Amazon S3 bucket.

Cluster configuration

1. Your first consideration should be creating a redundant web server environment. This doesn't need to be anything complicated for WHMCS, as most live changes are made to either your database or your S3 bucket.
   My recommendation: install WHMCS normally on your primary web server and copy all of your files over to your secondary server(s). Following this, you will want to have some mechanism to keep your files in sync; you could use a distributed filesystem like GlusterFS if you wanted, but it might be easier to use a tool like Rsync and run it on a schedule using cron. That's it!
2. Next, you'll want to set your storage locations to use your Amazon S3 bucket. Check out our guide here.
3. The third step is to setup MySQL database replication (specifically as a Master-Master cluster, as we'll want to be able to write from any server). There are lots of guides available that show you how to do this - here's an example.
4. Now that you have redundant web servers and database replication configured, you should configure WHMCS to store user sessions in the database. See our guide here. This makes it so that your users will stay logged-in to their account regardless of which server they are connected to, thus creating a seamless experience.
5. Lastly, it's time to setup a load balancer / reverse proxy that can direct traffic to the appropriate server. This is where your chosen network design comes in; in an Active-Active cluster, the load balancer will route traffic to all servers in the cluster (depending on configuration), whereas in an Active-Passive cluster traffic will be routed to the primary server (in this case, Web001) unless it becomes unavailable, in which case it will be routed to one of your secondary servers. There are many options to choose from for reverse proxies, but Nginx is one of the most popular; there's also the option of using Nginx Proxy Manager for those that like using a GUI.

It is possible to do a failover-of-sorts by using DNS round-robin and/or by changing the IP address that DNS is pointing to. I would like to discourage you from doing this, as you are reliant on another system operating correctly, and there is also the small matter of DNS caching to battle with. Only use DNS-based-failover when absolutely necessary - this should rarely be the case.

If you have managed to follow all of the above steps, you should now have a redundant, fault-tolerant WHMCS installation. Congratulations!

A little note about licensing

All of this is possible whilst using only a single WHMCS license. That's because WHMCS will only receive your reverse proxy's IP address. The only thing that you need to make sure is that you are using the same directory on each web server to serve your installation.

 

If you've got any questions about any of this, please feel free to leave them below or contact our team!