Linux redundancy: intro and requirements

TransIP offers you the possibility to spread your services geographically over our availability zones. This makes it possible to set up a redundant VPS environment in which, when a hypervisor goes offline, for example, your customers will not notice it.

In this tutorial series, we show you how to set up a redundant environment for hosting websites, including database(s), and ensure that your data remains synchronized between VPSs. There are no one-size-fits-all solutions for all conceivable scenarios, so we recommend reading these tutorials before you follow the steps described.

Setting up a redundant VPS environment is covered in the following sections:

1. Introduction, requirements, use cases
2. Updating and synchronizing your websites (GlusterFS or Rsync)
3. Synchronizing your database (master-slave)
4. Failover of your database (MaxScale and MariaDB-Monitor)
5. Linking your database to your application with Keepalived (PHP, WordPress)
6. Additional tips

Concepts such as RSync, master-slave, etc. are explained in more detail in the relevant sections.

Use case

The purpose of this tutorial series is to show you how to set up redundant file, web and SQL servers in a broad sense. The techniques covered in these tutorials can however be used for a wider range of use cases.

We show you a way to set up a continuous synchronization for files hosted on your VPS as well as databases. This synchronizes website updates to your web servers and keeps files synchronized. 

The main goal is to introduce you to various tools which you can use to set up redundant file, web and SQL servers. The final result of the configuration discussed in this tutorial series is: 

• Websites: The websites refer to HA-IP Pro in their DNS settings. This achieves load balancing and failover:
   
  • Load balancing: Visitors are automatically distributed over the two linked VPSs.
  • Failover: If one of the web servers is unreachable, the other will take all the traffic. 
• SQL: We use a master-slave setup for the SQL database:
   
  • For a master-slave setup, the SQL master executes all write (create, drop, etc.) SQL queries to itself and to all linked slave VPSs. Suppose a visitor registers on your website, then that data is usually recorded in a write query.
  • The read queries are executed on the private LAN IP address of the SQL servers.
  • MaxScale ensures that when the master becomes unreachable, one of the linked slaves automatically becomes the new master.
  • We use a virtual IP address to ensure that write queries are always sent to the current master. 

VPS monitoring 

If a VPS goes offline in your redundant setup, you want to be on top of that of course. Always set up monitoring for your VPSs. You will then automatically receive an email if one of your VPSs becomes unreachable. 

What do I need to set up a redundant VPS environment? 

To set up a redundant VPS environment as in this tutorial series, you need at least two VPSs in each availability zone. In each availability zone, you have one VPS that serves as a web server and one VPS that serves as a database (SQL) server. You need at least the following products for such a redundant setup:

• Four VPSs: Two in one availability zone (Amsterdam), and two in another (Delft). Set up two VPSs as identical web servers and two as identical SQL servers with MariaDB 10.2 or later. In theory you can have the web server and SQL server on the same VPS (as the control panels do), but to reduce the number of possible attack points, we chose to split these in this tutorial series and to have the SQL servers only accessible from the private network.
  
  In order to achieve this setup, you could completely set up a web server and SQL server in our availability zone in Amsterdam and then clone both to two new VPSs in Delft. Alternatively, you can choose an availability zone when ordering the VPSs and set them up completely from scratch. 
   
• HA-IP Pro: HA-IP Pro is an out-of-the-box load balancer with automatic failover. We use HA-IP Pro in this tutorial series to distribute incoming traffic evenly over your web servers.
   
• Private network: For optimal operation of your redundant setup, you want to synchronize all files between your VPSs. With a private network you contribute to your setups security as the SQL servers will be publicly inaccessible (more about this in a later part of the tutorial). 
   

Optional:

• Big Storage: If you store large amounts of data, we recommend using Big Storage (one in one availability zone, and one in the other). With Big Storage, you can add up to 400TB of storage to a VPS.

HA-IP Pro configuration 

If you want to follow this tutorial series one-to-one, you need the following settings in HA-IP Pro. 

Linking VPSs 

Only link your web servers to HA-IP Pro (not your SQL servers). 

Load balancing 

The choice of a load balancing method is a personal one and you are completely free to do so. We use Round Robin for a even distribution over the VPSs. 

TCP port settings 

There are two types of traffic that you have to forward in HA-IP Pro: HTTP and HTTPS, traffic. Set up HA-IP Pro as in the screenshot below. For more information about HA-IP pro, see our article on HA-IP Pro. 

See our 'What is HA-IP Pro' article for more information about setting up the Health Check.

DNS settings 

In the DNS settings of the domain you use for these tutorials, refer the A record and AAAA record to your IPv4 and IPv6 address of HA-IP Pro respectively.

We have reached the end of the introductory part of setting up a redundant VPS environment. Before continuing, make sure you have the following configuration ready:

• Two identical web servers with an Apache or Nginx server, with an SFTP / FTPS server.
• The web servers are linked to HA-IP Pro.
• Two identical VPSs with MariaDB 10.2+
• All four VPSs are linked to your private network.
• At least one domain linked to HA-IP Pro in the DNS. 

Then, click here to continue with part two: synchronize your files.