Skip to main content

Rackspace Cloud Servers: what happens when the host fails

When developing applications for the cloud everybody knows (or should know) that a host, network or disk (in short any resource) failure is not an exceptional event but a rather common one. A resource failure becomes a 'normal', common event in the application lifecycle like the occasional bug.

The Amazon approach is that some services (like databases) come with a certain degree of resiliency built-in while others (i.e. EC2 instances) are expected to fail relatively frequently and it is left to the developer to install backup, redundancy and availability countermeasures.

My understanding is that other providers, like Rackspace, have instead a more traditional approach and will automatically restart failed virtual servers in case of host failure. If the failed cloud server image cannot be recovered then it will be bootstrapped from the most recent backup. This means that, depending on the requirements, one could move a traditional application to the cloud without having to worry too much about backups and high availability as they are, to a certain degree, built into the offering.

Yesterday I had proof that Rackspace does, in fact, do exactly what it says on the tin:

I keep a small cloud server instance running on Rackspace for testing purposes. I have setup daily backups because they come (almost) free with the package and they're dead-easy to setup: just a couple of clicks on the web control panel.
Yesterday Rackspace sent me an email saying that the host hosting my instance 'became unresponsive' (that was the exact wording) and was rebooted. After half an hour I received another email stating that the host suffered an hardware failure and my cloud server had been shut down and was in process of being moved to a new host.
Three and a half hours later another email informed me that my server was up and running again, which I could confirm by logging in. The cloud server kept its ip, luckily did not lose any data and was just moved to a new host.
Note that I was on the road coming back from holidays while all this happened and I did not have to lift one finger, well, except for logging into the server at the end.


Webmaster said…
Very nice information. I really thank you fro sharing this. I have you bookmarked to check out new stuff you post.
Cloud Server

Blogger said…
Bluehost is ultimately the best web-hosting company for any hosting plans you might need.

Popular posts from this blog

Indexing Apache access logs with ELK (Elasticsearch+Logstash+Kibana)

Who said that grepping Apache logs has to be boring?

The truth is that, as Enteprise applications move to the browser too, Apache access logs are a gold mine, it does not matter what your role is: developer, support or sysadmin. If you are not mining them you are most likely missing out a ton of information and, probably, making the wrong decisions.
ELK (Elasticsearch, Logstash, Kibana) is a terrific, Open Source stack for visually analyzing Apache (or nginx) logs (but also any other timestamped data).

From 0 to ZFS replication in 5m with syncoid

The ZFS filesystem has many features that once you try them you can never go back. One of the lesser known is probably the support for replicating a zfs filesystem by sending the changes over the network with zfs send/receive.
Technically the filesystem changes don't even need to be sent over a network: you could as well dump them on a removable disk, then receive  from the same removable disk.

RUNDECK job maintenance

Learn more about Rundeck.

Now that I have a fair number of jobs scheduled by Rundeck, how do I periodically prune the job execution history and keep only the last, say, 30 executions for each job?