By clicking or navigating this website site, you agree to allow our collection of information on Scaleway to offer you an optimal user experience and to keep track of statistics through cookies. Learn more about our Cookie Policy.

Setting up a load balanced Wordpress

Load Balancer Overview

The capacity of a single server is limited. Once a website gains more and more attraction the instance serving the site comes to a point where it can not handle any more users. The website starts to slow down or even become unavailable as the server goes down from the traffic.

This is the point where a load balancer enters the game. It allows to spread the “load” that all those visitors and their requests create to be “balanced” over a series of different instances.

In case of increasing load on a setup, capacity can easily be increased by adding more instances to the load balancers backend. This allows to scale your infrastructure without any downtime or delays whilst waiting for DNS zones to be updated.

In this tutorial you learn how to setup a Scaleway managed Load Balancer with two Wordpress instances and one database instance running MariaDB. The final setup is visible in this schema:

Prework - Setting up the Backend Instances

51.51.51.51 for the Load Balancer front-end IP Load Balancer supports private IPs of Scaleway instances for backend servers, allowing you to deploy instances without public IPv4.

1 . Follow this tutorial to start an Ubuntu instances and to install WordPress with LEMP on both of them.

2 . Set up a third instance with a MariaDB database as explained in this tutorial.

Configuring a Load Balancer

1 . Click on Load Balancer in the menu on the left, to enter the Load Balancer section, then click on + Create a Load Balancer:

2 . Enter the Name of the load balancer, optionally you can enter a description and tags to simplify the management of them. Choose the Region for the load balancer (it should be the same region as the geographical region of your instances), a new IP address is allocated automatically.

3 . Create a frontend rule for the Load Balancer. This rule specifies on which external port the service will listen on the load balanced IP address. As Wordpress is a web based application, specify the Port 80 and a name for the rule:

4 . Configure a backend rule, this rule defines the backend infrastructure that will be load balanced.

The following parameters should be configured in the backend rule:

Parameter

Description

Backend Name

A name for the backend rule (e.g. wordpress-backend-rule)

Protocol

The protocol to use. Set this value to HTTP, to have access to HTTP specific features of the Load Balancer

Port

The port on which the backend application listens, with a standard configuration it is port 80 for a web application. It is also possible to use SSL to encrypt backend connections, in this case set the port to 443.

Proxy

This enables or disables PROXY protocol version 2 (must be supported by backend servers). It is not required for this tutorial, keep it off.

Health Check Type

The health check type to use. To check the health of a web application, set this to HTTP.

URI

The uniform resource identifier (URI) to check, to check if the Nginx web server is up, enter / in the form.

Code

The nginx web server sends a status code with with each response. The HTTP status code for successful requests is 200. Set this value in the form.

Sticky Session

Enables the load balancer to bind a user’s session to a specific instance. This ensures that all subsequent sessions from the user are sent to the same instance, while there is at least one active session. Keep this feature disabled for this setup.

Server IPs

Add the two Wordpress instances (10.45.2.3 and 10.45.2.3) to the list of backend servers

The final backend rule should look similar to the following example:

5 . Click on Create a Load Balancer to deploy the Load Balancer.

Checking If the Load Balancer Works

It is possible to check the status of the Load Balancer with an API call. It will provide you information to status of the load balancer and if the health check was successful.

LB_ID="<LOAD_BALANCER_ID>"TOKEN="<API_SECRET_KEY>"REGION="<REGION>"# (can be either fr-par or nl-ams, depending on the load balancers region)

2 . When the load balancer is configured and running, type the following command to request its status. Make sure that jsonpp is installed on the machine running the above command to get a easily readable JSON output:

As two instances are configured in the backend, the JSON list contains four entries. This is due to the high availability feature of the load balancer. Should the master instance experience a failure, it switches automatically to the backup one.

In the status of the running instance, the health check status (last_health_check_status) has passed. This means that the backend instance replied well on the request sent to it in the health check. Requests to Wordpress are load balanced between the two instances.

4 . Connect to the first Wordpress instance (10.45.2.3) and stop the web server application running on it:

systemctl nginx stop

5 . Re-run the command from Step 3.

6 . In the JSON list, the last_health_check_status changed to failed, as the web server does no longer replies on requests:

When you navigate to the load balanced IP (http://51.51.51.51) in your browser, your Wordpress displays. The Load Balancer has automatically detected that the Nginx server on the first instance (10.45.2.3) is not running any more and redirects all traffic to the second instance (10.45.2.3).

7 . Restart the web server application and re-run the command mentioned in step 3. The last_health_check_status will change again into passed and requests are load balanced again between the two instances.

Configuring Wordpress

Update the configuration of each instance now, so they will use the database on the dedicated MariaDB instance instead of using a local database.

1 . Connect to the instance via SSH as root

2 . Open the file /var/www/wp-config.php in a text editor and edit the database section as following: