V-Base Development Blog

Because of the way our funding works we had to buy the hardware for the back end of this project relatively early. So at this stage of the project we have two beefy servers. Both have two dual core processors with loads of memory and underlying this we have half a Terabyte of storage for the database (that is a lot of volunteering opportunities ;-P ). To make optimal use of this hardware we decided to use Xen virtualization. With this technology you chop up a single server into multiple ‘virtual’ servers. Meaning: you can run multiple OS’s on a single piece of kit.

In back end application building it’s commonly thought good practice to dedicate a specific task to a single server. So if a single server crashes it doesn’t tear down the whole application. Also, running software in separate servers prevents them from interfering with each other and makes it easier to upgrade and maintain them. We have, for example, one big Oracle database server and several Java application servers all with different tasks.

Another big advantage is that the file system of a virtual server is stored in a large, single file, in our case stored on the storage device, which is a redundant raid5 setup. This has two advantages: If the hardware of one of the servers breaks (cpu meltdown or something similar) we can just login on the other server and start the same(!) server from there (this can also be automated). And the other big advantage: if we want an extra server with the same functionality (e.g for clustering), the only thing I have to do is make a copy if that big file and fire it up next to the original one; no lengthy installation processes anymore once done

In the final setup one server will function as the main server with the other one as backup in case the main one gets struck by disaster. Normally this would mean that the fail over server would gather dust and do next to nothing. Not with us! We use this fail over server for all our development, experimentation and test server needs. All set up as virtual servers of course. And in a case where the main server breaks, we stop all the development / test servers and simply start all the (virtual) production servers on the fail over server, stop development, focus all our attention on repairing the main server and when successful, switch back again To put it in money, this saves us easily a couple of thousands pounds because we don’t have to buy expensive development kit.

I have to say this wasn’t an easy task to set up but I finally got it working and it does gives me a little bit of geek pride because it puts us in line with two other major users of this technology: Google & Amazon