Assuming Assuming and part II worked for you, and you have tested that keepalived does indeed failover and route traffic, you need to deal with the services on those hosts. In the case of a LAMP environment, you are looking primarily at MySQL and Apache – and you have to address config files and data replication for each.

MySQL is fairly straightforward, and multi-master replication is covered well elsewhere. Personally, I used this guide to cover the setup. Glossing over most of the details, the process is this:

1. set the unique ID’s for each database instance
2. set the update increment for each instance (so multi-master won’t step on itself
3. set each to replicate from the other
4. stop external connections to the databases
5. make sure the same data is loaded into each
6. enable replication
7. test

Setting up Apache is slightly more complex, assuming you don’t have a expensive shared clustered storage, as your config files (and website content) need to reflect one another. This is best handled in some kind of Source Code Management engine, like SVN or Git. Git is a better choice for this, it’s fully distributed – each copy of the repository is a full copy, and can stand alone in case of total failure of everything else in the world other than the server it is on. Sadly, I can’t share the scripts we use at work (nasty IP lawyers), so until I develop one in my free time to post here, this post is going to be short on content. In essence, what you do is make each server a git repo that serves can serve content over HTTPS or SSH. Script up the connection between the two (to push/pull data between your web server nodes), and then check that copy out to your preferred development platform.

If you want to get really fancy (which you should), setup a second VIP in keepalive so you have a place to test development changes before pushing the button and going live. As most LAMP stacks draw their content from the database backend anyway, this changes won’t happen too often, but it’s always good to be able to test on a real server before blowing up production. (To be extra super fancy, you’ll run two sets of apache daemons – with separate sets of config files – so when you add the new version of PHP, you don’t destroy the production environment.)

In the next and final installment of this series, we’ll look at the final part of this, which is harvesting the apache logs, looking for attackers, and adding them to the block lists automatically.