Posts tagged ‘xen’

37signals (and DHH) love Xen 4 Jan 08

37signals, the team behind popular productivity apps such as Basecamp, Backpack and Campfire, recently posted some stats which make fascinating reading. Of greater interest to us, though, is their use of Xen virtualisation for parts of the server infrastructure and the plans to upgrade more servers to Xen over the next couple of months, reducing their physical server count from 30 to 16 whilst remaining at around 100 cores.

DHH, Mr Rails himself, in another comment says of Xen:

Wonderful system. Strongly recommended for anyone building out a cluster.

What better recommendation to you need that Xen is a perfect solution for Rails hosting and scaling?!

Posted 4 January 2008 by Jeremy Jarvis ::: add comment

Secure virtual disk deletion - is your data safe? 4 Dec 07

Everyone knows the dangers of old hard disks being discarded with sensitive data still on them, but what about virtual disks? With so many virtual machine hosting services cropping up of late (hi!), have you ever wondered what happens to your data when you delete your virtual machine?

Usually your machine’s ‘partition’ is just a small part of a larger disk array; the partition is deleted and the space returned for the pool to be used by another virtual machine. This means, the next time someone buys a virtual machine with the same host, some of the blocks that made up your filesystem could end up making up their filesystem. The metadata will be wiped clean when the filesystem is formatted of course, so they won’t just see your files listed, but the blocks can still contain your data. It depends on how they’re managing their disks.

Homework: go buy a virtual machine somewhere and pipe the contents of your new disk through the strings command and look out for anything that isn’t yours (ssh root@newmachine "dd if=/dev/sda1 bs=1M | strings"). Extra credit if you don’t get thrown off your new host on the first day for maxing out the disk IO :)

So, you’re probably careful and securely wipe your sensitive data before you leave, phew. But disk space is virtualised too. The blocks that make up your disk might not all be in order or even all be on the same disk. With snapshots, your data may exist in duplicate too that you can’t even access. And what about if you bought extra disk space, then removed it?

At Brightbox we use Linux’s LVM implementation to manage disk space and these are problems we have to deal with and we take it seriously. All virtual machine disks are wiped at the block level when the machine is deleted or when a new machine is created. The only corner case we’re likely to run into is if a disk image is extended into space that had previously been used as a snapshot or as a disk that was shrunk. Luckily we don’t currently offer snapshots or disk shrinking but it’ll be something we’ll probably offer at some point, so we’ll have to address it then.

Posted 4 December 2007 by John Leach ::: 1 comment

Why we chose Ubuntu Dapper Drake 3 Aug 07

We’ve had a few beta testers ask about why we chose Ubuntu 6.06 (Dapper Drake) as our primary Xen guest installation, as opposed to one of the more recent releases such as Edgy or Feisty. We chose it primarily because of its support contract.

Ubuntu’s release schedule sees a new version released roughly every 6 months. These releases contain the very latest versions of the software packaged with it and are supported for only 18 months. Once in a while a version is selected as Long Term Support release (LTS) which gets 5 years of server support (3 years for desktop). By support, I mean the Ubuntu team are committed to releasing security upgrades in a timely manner. Dapper was the first LTS version and is support through to June 2011.

If we’d chosen Edgy, security upgrades wouldn’t be available to us after April 2008, forcing all of our Brightboxers to upgrade to Feisty, and so on every 18 months. With the speed that the Rails community jump deployment strategy ships some might say this isn’t a problem, but most installations do need long term stability and Dapper provides that.

There are some issues though, mainly that Dapper’s version of Apache is too old to support the nice proxy balancing stuff that’s used for Mongrel deployments1. To solve this, we chose to use a backported Apache package2. This does mean that we have to commit to backporting all security fixes, but this is trivial compared to all our guest machines needing a full upgrade every 18 months. We still get the Ubuntu team working for us on the other 99.9% of packages.

For our users who like to ride the bleeding edge, they can still upgrade to Feisty themselves if they know what they are doing but for most, this isn’t what Brightbox is all about.

1 A beta tester pointed us in the direction of this bug report requesting an official Apache backport for Dapper. The more people testing these packages and voicing their support, the more likely this might happen.

2 We’re using the backported Apache package provided by kodefoo.com at the moment (http://www.kodefoo.com/2007/2/18/deploying-rails-on-ubuntu-dapper/) but are ready to roll our own if necessary.

Posted 3 August 2007 by John Leach ::: add comment