Rackspace Cloud Servers and Cloud API Review

TL;DR: Rackspace Cloud is an acceptable option for existing Rackspace dedicated or managed colo customers, or those who need an alternative to AWS (or just lots of handholding and phone support), and can be very patient for future features.

Introduction

These are my observations based on meetings with Rackspace and daily operational experience.

I used Rackspace Cloud Servers (40 Ubuntu and CentOS linux servers of all sizes in ORD) and Cloud API v1.0 and v2.0 daily from mid-2012 to mid-February, 2013.

Multiple versions of Cloud Servers

Rackspace has seemingly had four Cloud Servers versions so far:

  1. early v1 (obsolete – forced migration to late v1)
  2. late v1 (v1 API frozen, incompatible with Cloud API v2, snapshots limited to 80 GB of “used” blocks)
  3. early v2/early OpenStack (incompatible with Cloud API v1)
  4. late v2/recent OpenStack (incompatible with Cloud API v1).

There are currently two Rackspace Cloud datacenters:

  1. ORD
  2. DFW.

The maximum RAM in each version is 32 GB.

Obviously you want to be using the latest version available to avoid multiple forced migrations down the road.

Server Migration Between Cloud Servers Versions

Migrating a server between different Cloud versions is quite a project.

Rackspace has a bash wrapper script for rsync named rsrsyncLive.sh that lets you copy files from one server to another. In practice it works well, especially for the same flavor of linux, though the result is not guaranteed and there’s no practical way to verify the end result of copying live files. (Please stop your email and database servers before trying this.)

A safer method is to put your server in rescue mode, then mount your filesystems readonly and use a modified version of the wrapper script to copy the now quiescent files to another server.

Each host server can only support one VM in rescue mode, but once you enter rescue mode it is available until the next VM requests it on the same host machine. (I’ve seen a VM in rescue mode last all weekend.)

Cloud Portal Admin UI

The Cloud Portal admin UI allows the end-user to control servers in one DC via the web, but tickets must be filed for the second DC.

Any user login or API key allows you to fully control all servers (no granular roles and permissions). The most common feature request Rackspace gets is to add granular roles and permissions.

Rackspace Cloud API Limitations

The API documentation is sadly typical in not being 100% accurate, both for the text and sample code. Users have contributed fixes in the comments which have mostly been incorporated. (If you see a Rackspace Cloud API response message about a “Java type violation”, then it means the pathinfo for the API request needs one level more or less.)

Neither the Cloud API v1 or v2 return bandwidth consumption data, regardless of what the documentation says.

The v1 Cloud API does not return the server creation date.
The v2 Cloud API does not return backup schedules information.

Rackspace Cloud Servers Features

Not as many total features as some other services, so compare your needs with Rackspace Cloud Servers capabilities first.

No Cloud Servers instance disappeared, although 1 did hang for no obvious reason and required a remote reboot.

It appears that there are only 2 recursive nameservers per DC.

Cloud API Performance and Reliability

The Cloud API worked reliably. API reboots were surprisingly fast, with servers coming up in a second or so.

VPN Between Your Office and Rackspace Cloud

Rackspace Connect is normally used to connect Rackspace leased servers to Rackspace Cloud servers with a Cisco ASA-based VPN. However you can request it from your office or datacenter major-brand router to Rackspace Cloud.

The disadvantages of Rackspace Connect are:

  1. it can take quite a while for Rackspace to configure and test Connect since multiple groups are involved
  2. servers created before Connect is installed must be migrated to new servers on the Connect internal netblock
  3. more routers introduce more point of failure for your Cloud to the Internet, even if using redundant routers
  4. it reduces your total Cloud bandwidth to whatever can fit through the VPN router (likely 100 Mbps to 300 Mbps)

If Rackspace Connect is not right for you, their recommended alternative is OpenVPN, which would be a lot harder to manage for more than 2 servers.

Terms of Service Limitations

It’s very important that potential clients read the Rackspace Cloud ToS and discuss their usage patterns with Rackspace before any commitment of time or money:

  1. in the past, port scans (ie. nmap) were not allowed, which is an issue with third-party PCI compliance auditing
  2. there may be outbound email limitations
  3. only 1 IP address is allowed per server in v2 (rules out hosting providers)
  4. Cloud API calls have daily limits and throttling
  5. only Rackspace-provided server images are supported
  6. ensure your content is ok with Rackspace.

Billing Issues

We had recurring billing formatting and amount problems that were quite time-consuming to track down:

  1. some servers were billed more than 200 hours per month
  2. v1 and v2 Cloud Servers are billed at different hourly rates
  3. one server can be fragmented into multiple billing lines across multiple invoice pages, making reconciliation difficult
  4. the bill is not viewable online in the Cloud Portal admin UI v2 yet.

Rackspace Cloud API v1
Rackspace Cloud API v2
API v1.0 and API v2 Differences
Migrating A Linux Server from the Command Line – Scripted

Interesting commentary from theregister.co.uk:

Price cuts, OpenStack transition make Rackspace miss in Q1
Rackspace shares crater in drab results aftermath

This entry was posted in API Programming, Business, Cloud, Linux, MySQL, Open Source, Psychology, Storage, Tech, Toys. Bookmark the permalink.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.