Tuesday, July 17, 2012

Amazon and Rackspace: A Comparison, Part 2

In my last post I discussed the steps I took to get our application working on AWS. This post will address steps used on Rackspace to get a test environment up and going. This isn't an apples-to-apples comparison. I'm sort've biased towards Rackspace for reasons I mentioned previously, so I'm going the full monty in deploying a test environment with them, doing my best to replicate how I envision the final product actually working.

Rackspace
Setting up servers was pretty flawless and easy. Honestly, you simply pick the kind of server you want, and deploy it. It did take a little longer for each instance to be up and ready than AWS, but the creation process was pretty much point and click. I had a web server, a Tomcat server, and 3 MySQL servers set up in no time (the 3 MySQL servers were because I was going to also try out using MySQL-MMM again).

An immediate difference between Amazon and Rackspace was server access. With Amazon you got a public IP that requires private-key SSH authentication to connect to. All other services are locked down until you edit/create a security group, so by default it's pretty secure. With Rackspace each server you set up also has a public/private IP pair, and you can SSH to the public IP with a username/password combo. The account you use is root, which by default on Ubuntu systems is locked so that you can't log in directly with it, but which for some reason the folks at Rackspace have seen fit to enable. That and the fact that again each server if directly accessible via SSH and a public IP made me a little nervous. If you don't use RackConnect, which is their offering for setting up a private environment including an ASA, you have to enable the firewall on each box and control access that way. From a security standpoint this introduces a lot of potential holes and requires some serious care and attention to detail. I had no sooner set my boxes up than I saw scans from the usual suspects (China, Spain) on my boxes. So right off the bat Rackspace servers require more manual intervention to secure your setup than AWS unless of course you're going to use their RackConnect feature which requires more money.

I got my servers set up in a timely manner and set about working on the load balancer.
This turned out to be a little trickier because the devil was in the details. On my first go around I selected the private IP version of the LB because traffic between private IPs isn't subject to the bandwidth charges. What wasn't clear was that it meant your LB only got a private IP, making it inaccessible from the public. I'm sure there are reasons why you'd want this, but it wasn't what I needed. You have to tear down your LB and create a new one to change this setting. Once I set it up as a public IP I still wasn't able to access it. This time the problem was that the LB was in a different data center than the cloud servers I'd created.

Setting up the LB was my first of many opportunities to chat with Rackspace customer service, which I remembered being awesome. It wasn't as consistently awesome this time around. It's still nice to have, and being able to instantly chat with someone about a problem is great, but the quality was about 50/50.

Once the LB was set up I started working on getting MySQL-MMM installed and going. That went fairly well until I ran into a major snag: MySQL-MMM depends on a virtual IP that can be passed back and forth between the two MySQL hosts. Rackspace doesn't allow you to reserve an IP in that way. If I remember correctly AWS does (I think it's their Elastic IP setup), but with Rackspace you can't do that unless again you go with RackConnect I believe. You essentially need to purchase/lease a dedicated network device that would be in charge of handing out private IPs.

Back to the drawing board. Amazon has their RDS service for databases; Rackspace has something similar that it's still in Early Adoption. You can only use their API to interact with it for now. This meant adding another learning curve to the process, so something that started off as fairly simple got to be much more complicated than I was looking for. I used the utility curl to send XML requests to get an API token, and then to setup a MySQL instance. Then I had to actually enable the root MySQL account to be able to add any databases. The instructions for setting up the initial instance created a single database and a single user with rights to that database. After all of that, I am left with a root account with a long, unwieldy password, and a database instance with a long, unwieldy domain name. Our application has many databases (at least one per client) so needing to change the connection details was inevitable regardless of where we moved to. However, it turns out that the text field for entering the hostname for connecting to a db server has a character limit that the Rackspace hostname exceeds! Lastly, it also turns out that you don't have access to the actual underlying system, so there's no ability to check MySQL logs and rather than editing my.cnf to make changes to the configuration you have to do it from within MySQL itself, if at all possible. For example, we need to set the parameter lower_case_table_names=1. This is not a system variable that you can set from within MySQL though; it has to be done in my.cnf.

In the end, although both Amazon and Rackspace were relatively easy to use in terms of setting up simple front-end portions of our SaaS infrastructure, the database side of things was simply not flexible enough for us. Amazon RDS has many perks, one of which is automated snapshots/backups, but this is only supported on InnoDB engines. If you use MyISAM as we do, you're back to your own devices doing manual snapshots anyway. AWS RDS also does not allow direct access to the host so you run into the same barriers as with Rackspace.

I suppose one could simply roll out a cloud instance and install MySQL on it manually and let 'er rip. I think however that there are performance risks to doing this as you don't have any guarantee of dedicated resources beyond your RAM, so if you happen to have your DBs on a host with another user with high performance needs, you could be out of luck.

I may go ahead and see what the performance is like deploying our own MySQL server, but I think ultimately we're looking at going fully into RackConnect if we want to do this.


No comments:

Post a Comment