Set up

Install Package Dependencies on the Master Server

Log into the master server with the ssh command.

ssh root@your.master.public.ip.address

In order to install lsyncd the master server needs some additional packages installed. Run the command below to install these packages.

apt-get install lua5.1 liblua5.1-dev pkg-config rsync asciidoc make -y

Install lsync

To install the version of lsyncd required for this guide we will need to compile the code from source. If you are unfamiliar with this process simply copy and paste the commands below.

cd /var/tmp
wget  //lsyncd.googlecode.com/files/lsyncd-2.1.4.t...
tar xzvf lsyncd-2.1.4.tar.gz
cd lsyncd-2.1.4
./configure && make && make install

With the completion of the make install command the lsyncd service will be installed on the master server. The compressed lsyncd package does not come with start up scripts so you will need to roll your own.

Setup the Startup Scripts

Start by creating a file at /etc/init/lsyncd.conf with the following shell script.

cat << EOF > /etc/init/lsyncd.conf
description "lsyncd file syncronizer"
start on (starting network-interface
 or starting network-manager
 or starting networking)
stop on runlevel [!2345]
expect fork
respawn
respawn limit 10 5
exec /usr/local/bin/lsyncd /etc/lsyncd.lua
EOF

Next create a symbolic link so the service will respond if called via the init script counterpart.

ln -s /lib/init/upstart-job /etc/init.d/lsyncd

Configure Logging

Logging will assist in tracking down issues if they arise, this section will details logging configuration. Make a folder to hold the lsyncd logs with the mkdir command.

mkdir /var/log/lsyncd

Now that lsyncd has a place to log to, it will create a log event if an error occurs with replication. As experienced sysadmins known, log files can become large and unruly when not properly monitored, causing a harddisk to fill up. To ensure this does not happen add lsyncd to logrotate. Create a file at /etc/logrotate.d/lsyncd with the following shell script.

cat << EOF > /etc/logrotate.d/lsyncd
/var/log/lsyncd/*log {
    missingok
    notifempty
    sharedscripts
    postrotate
    if [ -f /var/lock/lsyncd ]; then
      /sbin/service lsyncd restart > /dev/null 2>/dev/null || true
    fi
    endscript
}
EOF

Now the logs will rotate saving the harddisk from possible issue.

Create the config file

Finally, the logic portion of your lsyncd configuration. Create a file at /etc/lsyncd.lua and insert the following data with a text editor.
Note: Replace the target parameter with the private IP address of the clone server. This is found in the Rackspace control panel.

cat << EOF > /etc/lsyncd.lua
settings {
    logfile = "/var/log/lsyncd/lsyncd.log",
    statusFile = "/var/log/lsyncd/lsyncd-status.log",
    statusInterval = 20
}
sync {
    default.rsync,
    source="/var/www/",
    target="your.clone.private.ip.address:/var/www/",
    rsync = {
        compress = true,
        acls = true,
        verbose = true,
        rsh = "/usr/bin/ssh -p 22 -o StrictHostKeyChecking=no"
    }
}
EOF

Take special note of the block of code beginning with sync. If you require more web servers, this block of code will need to be replicated with the IP address of each additional clone server. This is discussed further in the continued scaling section.
With configuration complete start the lsyncd service.

start lsyncd

Test the Configuraton

Before continuing, test the configuration. Create a file in the /var/www/ directory on the master server. This can be done with the touch command.

touch /var/www/dummy_file

If everything is working correctly the file will be replicated to the /var/www/ directory on the clone server. You can test by SSHing into the clone server and using the ls command.

ls /var/www

Next Steps

With lsync set up and configured to watch the web directory of the master server this scalable configuration is almost complete. When a modification occurs on the web directory, lsync will track this change, and replicate it to the clone server. To ensure all changes occur on the master server we will set up the varnish web accelerator. Varnish will ensure all login requests to the WordPress admin panel are routed to the master server. This is the last piece of the puzzle in your WordPress configuration.