Oliver Jobson

Load Balancing WordPress

Last modified on:

When we moved to WordPress, we ran into an issue with our load balanced servers – you can’t add a post to each server individually because of the unique post number added by wordpress when you publish – the post will have a different URL on each server which, because traffic could go to any server, will result in a 404-error lottery – with the chance of the correct page being displayed being 1 in x (x being the number of servers you are balancing the traffic across).

If you’re big enough to use clustering, then you will probably have ways to get around this, however if you aren’t, it could get problematic and clustering would take some expertise and know how to set up.

The way we solved this also helped improve the level of security with our web servers – an issue that any security aware organisation uses open source software will be well aware of.

The answer was to employ an internal staging server – we could test all content amendments and updates on this server before rolling them out to the live servers. Previously we would have to take a server out of the load balancing ‘array’, make changes, test and then copy the changes across to the live servers before releasing the server used for testing back into the array. This was a pain and it reduced the level of resilience as the number of servers used for load balancing was reduced.

So how do you copy the changes from a staging server to your live servers? Simply use a script that dumps the database and then copies the database across to the live servers along with any updated files (do this using using rsync over ssh). The script then runs a remote script sitting on each of the live servers that automatically imports the transferred database and bingo – new content is copied across and live on all your load balanced servers.

How does this improve security? Well now you can disable access to to wp-admin, wp-login.php and any other admin area of the site on the live servers by using .htaccess files or custom php rules. Simply omit these files from being included in the rsync process (see ignoring files during rsync) and you can help ensure that your WordPress server stays yours.

Additionally, and I really like this, if WordPress does get hacked (and it may not be immediately obvious that this has happened), then the security & integrity of your database and code is no longer known. All you need do is upload the files and database from the staging server (which isn’t publicly accessible) and you’re back in the game.

One last thing – using the auto update script also makes it really easy to upgrade WordPress. Do it on the staging server – test your content and plugins and then roll out the upgrade to your load balanced servers simultaneously.

Published on

in

by

Oliver Jobson

Tags:

Comments

5 responses to “Load Balancing WordPress”

  1. charffers avatar
    charffers

    Now this makes sense….have been thinking of all sorts of approaches to managing our websites better and have been exploring options to improve resiliency following hosting problems. At present we take an automated 4 hourly snap backup of files and DB from virt and bring back to internal server but your way makes much more sense and has security and dev/test improvements to boot. Impressive stuff

  2. Anthony avatar
    Anthony

    So on your dev box do you have the same domain name? So internal dns takes you to the dev box while internet dns takes you to the prod site.

    I have 2 prod boxes in ec2 and want to make a dev box but the wordpress redirect takes me to the prod name. Otherwise I have to hunt down dev. domain name and change it.

  3. oliver avatar
    oliver

    Yeah, the dev boxes use the same domain name – I use my hosts file to take me to the appropriate IP address of the dev box. I use a few VM’s on my iMac for testing so I can usually check the live boxes with a VM configured with a standard host file – this uses the same normal DNS that all other staff use internally to reach the live sites.

  4. Per Wiklander avatar
    Per Wiklander

    It sounds like you either have no comments on your system or you use an external comment service, like Disqus. Would you care to comment 🙂 on that?

    One more thing. I don’t know how dynamic yout pages are, but if you have no user accounts and no user created content, couldn’t you just generate HTML files from you staging box and rsync that to prod?

  5. oliver avatar
    oliver

    Missed this comment – yeah, the content is pretty static at the moment, so we don’t need to keep the servers in sync – html files would do the job: 6 + 2×3’s in my view – maybe if we were bigger this would give us a speed improvement too. At some point I would love to have the time to have the resources to move towards a system that makes use of MySQL replication or clustering – that will be the next step, possibly when we move to our new ExpressionEngine CMS. I can’t really seem much of advantage with this, I’d just like to use the experience to learn how to implement it.

Leave a Reply

Your email address will not be published. Required fields are marked *