For about a year or so now I’ve been hosting my Email, Website and other related services off Slicehost. As I don’t host people’s websites en masse any more, this makes sense financially - which frees up money for other projects.
When I evaluated where to put my slice originally, I looked at a few VPS providers:
- Slicehost
- RedWood Virtual
- Linode
- GANDI
Based on price and feature sets, I ended up trialling Redwood, GANDI and Slicehost to see what their service was like. From a technology point of view, I was looking for a Xen or VMWare based provider, no KVM or Virtualbox providers for me, kthx.
GANDI, being relatively new at the game - managed to irrecoverably lose my slice image in the first week. Bad luck on their part, but ruled it out for me.
Redwood’s management tools weren’t great, and dealing with support was a bit average, but otherwise things were okay. Not so okay was having storage not showing up as a block device. I’m not actually sure these guys were running Xen, but I’d been curious to go with them after hearing good things.
Slicehost, as well as boasting a recommendation from one of my colleagues - had some good management tools and just worked(tm). Also appreciated is that their kernel management seems to play nicely with Debian/Ubuntu package management (ie: they didn’t piss over each other).
So in the last year I’ve had a pretty good experience, and only a few hiccups - most notably a bug in the management tool which caused my host to run a newer kernel without installing any of the loadable modules outside of the initrd. That and some really big process queues from IO wait lately.
Now I’m in the situation where I’d like to upgrade to Ubuntu/Lucid, the latest Long-Term-Support edition - so I can continue to receive security updates into the future.
Let’s start by saying I’m not normal. I don’t like to dist-upgrade boxes between major releases. There’s something not quite right about doing an in-place upgrade on your init, really. As such, my boxes are built to be blown away and reinstalled easily.
Unfortunately, with the Slicehost management tools there just doesn’t seem any easy way to create a new slice, mount the old image and copy files across whilst keeping the same IP. The only solutions are to create a new slice, and use the private interface IPs to copy between them, and set up for a new IP.
Which sucks, so I don’t know what to do. I’ve just shot a support ticket to Slicehost to find out, but it would be nice to be able to just mount the old image on a new box.
As it turns out, this is not only possible on Linode - but downright easy. Whilst fixing someones Linode (funnily enough, from a broken dist-upgrade to Ubuntu/Lucid), I got a good chance to play with their management tools: they’re awesome.
Want to create your own customised partition layout (instead of using an all-in-one layout)? No problems. Want to create multiple block devices? No worries. Want to boot into a new image with the old one available? No problems.
Oh, and it turns out that Linode have updated their plans to be more competitive for RAM and Storage. Going from a 512 slice to a 1024 slice will cost the same - and you’ll get the benefits of better management tools.
Theres a lot more info on their management tools available on their site than there used to be also, so worth checking out.
So I’ve had a quick look at the bandwidth and latency from the various Linode datacentres, overall not bad at all.
11:10:07 (740.23 KB/s) - `100MB-london.bin' saved [104857600/104857600]
11:12:56 (696.35 KB/s) - `100MB-newark.bin' saved [104857600/104857600]
12:18:09 (844.26 KB/s) - `100MB-atlanta.bin' saved [104857600/104857600]
12:23:42 (987.36 KB/s) - `100MB-dallas.bin' saved [104857600/104857600]
12:27:51 (840.12 KB/s) - `100MB-fremont.bin' saved [104857600/104857600]
The Fremont DC was flapping between 750KB/s 1.2MB/s, whilst most others stayed reasonably constant.
And the round trip times are also quite good:
london: rtt min/avg/max/mdev = 348.397/349.640/363.074/1.498 ms
newark: rtt min/avg/max/mdev = 284.731/285.829/303.533/1.992 ms
atlanta: rtt min/avg/max/mdev = 268.222/269.473/296.800/2.947 ms
dallas: rtt min/avg/max/mdev = 249.007/250.088/261.556/1.603 ms
fremont: rtt min/avg/max/mdev = 211.310/212.034/213.691/0.578 ms
Packet loss was 0 or negligible on all tests, so I’ll leave it out for the purposes of simplicity. Also, for a baseline, here’s a test from the same network to my existing slice:
13:29:59 (808.72 KB/s) - `100MB-autodeist.bin' saved [104857600/104857600]
rtt min/avg/max/mdev = 255.246/255.970/257.267/0.723 ms
Transfer speeds from my slice also flap fairly heavily between 450KB/s and 1.3MB/s.
Whilst these tests are only useful for an indication only, the RTT times gave me pause on what DC I would choose. Originally it was a toss up between Atlanta/Dallas - but with the fairly consistent low response times from Fremont, that might just be the contender. Obviously this benefit is from being geographically closer to the cable landings in the US.
So what happens now? I’m pretty tempted about the move, so I might sign up an account on Linode to test with, and if it runs smoothly and as expected - I could be moving host soon, hopefully for the last time in a while.
I’ll update soon :)