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.

A not so short guide to TDD SaltStack formulas

One of the hardest parts about Infrastructure As Code and Configuration Management is establishing a discipline on developing, testing and deploying changes.
Developers follow established practices and tools have been built and perfected over the last decade and a half. On the other hand sysadmins and ops people do not have the same tooling and culture because estensive automation has only become a trend recently.

So if Infrastructure As Code allows you to version the infrastructure your code runs on, what good is it if then there are no tools or established practices to follow?

Luckily the situation is changing and in this post I'm outlining a methodology for test driven development of SaltStack Formulas.

The idea is that with a single command you can run your formula against a matrix of platforms (operating systems) and suites (or configurations). Each cell of the matrix will be tested and the result is a build failure or success much alike to what every half-decent developer of…