ClusterFoundry Blog Highly-Available and Load-Balanced WordPress Cluster

Jun 14, 2013

by Jayson Cena

Introduction

This article explains on how to setup a load-balanced WordPress cluster in a master-slave configuration. The load balancer(HAProxy) sits in front of 2 or more web server nodes (1 Master and 1 Slave) which has the same contents. HAProxy does not only distribute requests, but also checks the health of the services running on the node. If one of the nodes are down, all requests will be redirected to the remaining nodes.

The cluster will be running in a master-slave configuration. The master will be hosting the Administration Panel(/wp-admin/) while the slave nodes will be receiving other requests other than /wp-admin/.

This article does not guarantee that this will work for you. This will also break compatibility with some of your plugins that writes on the filesystem like WP Super Cache. I will discuss it as we go further why this cluster breaks the compatibility in some of the plugins and what other alternatives are available on caching plugins.

4 types of node in the cluster:

Load-Balancer – HAProxy to load-balance requests for MySQL and HTTP
Web Server Master Node – NginX and PHP5-FPM, will host WordPress Admin Page
Web Server Slave Node – NginX and PHP5-FPM, will be hosting other pages
Database Node – Percona XtraDB Cluster (MySQL drop-in replacement with Galera plug-in) See http://www.percona.com/software/percona-xtradb-cluster
(Optional)Memcached Node – This will be used as a PHP session storage. By default, WordPress core doesn’t use PHP session storage. Instead, it uses cookies to manage sessions. But there are few WordPress plugins that uses PHP session_* functions so we’re going to use a central session storage just in case. We can also use this as a cache storage by using the plugin Batcache which can be used as an alternative to WP Super Cache plugin.

Master-Slave Architecture

Filesystem Replication

In this cluster, we are going to use asynchronous file replication. For the software, we’re going to use lsyncd and rsync. lsyncd works by adding inotify watches to directories. When there are changes done on any of the files under the directory, it will trigger inotify and will send a notification to lsyncd. Then lsyncd will then put the replication commands on the queue for later processing. All replication commands are always done in batches and uses rsync to replicate changes.

Why I decided to use lsyncd over other storage replication systems? What are the Pro’s and Con’s that we’ve considered?

Each web server node has its own copy of every file
Low latency access because of direct access to local disk
There’s no need to obtain read-lock or verify file contents to a remote copy (with other web server nodes)

Slave Lag: It takes a (number of seconds or 1000 events) + transfer time before the changed/new files are synced
Failure on rsync/file transfer will make the slave’s file copy different from the master’s copy. Consistencies will only be synced when the file has changed, initial sync during lsync’s startup or manually trigger rsync. File transfer failure detection is left on the monitoring software. See https://github.com/axkibe/lsyncd/issues/57

Our goal why I designed this cluster is to scale WordPress. I chose to have a faster response time in exchange for consistency.

Web Servers

Web server nodes are running in 2 states. The “Master” node which only has 1 active node per cluster at a time and also serves /wp-admin/ site. The other one is a “Slave” node which serves other requests. I decided to use the Master-Slave architecture so that replication will only be coming from the master node. Only changes on the master node will be considered for replication. That’s also the reason why the /wp-admin/ page is only hosted on the master node. Changes or updates on themes, plugins, uploads will and should only happen on the master.

Database Servers

Different from Storage and Web Servers, Database Servers will be running in a multi-master synchronous mode. We are going to use Percona XtraDB Cluster which is a MySQL fork with the Galera module from Codership.