The question “what problems will I have when migrating to the cloud” gets asked often enough. If by cloud you mean Amazon EC2, then from a technical perspective there isn’t much that changes. The biggest thing that changes is just how you pay your bill.
Having said that, there’s still a few potential gotchas:
- There are no Virtual IP addresses. Most High Availability tools (like MMM or DRBD+Heartbeat)
work on the principal of having a floating IP address which is used for the application to connect to the current master. With EC2, you can’t do this. - There’s no customization of the memory. The maximum amount of memory you can have is 15GB, so some users with larger working sets may find this a limitation. If you look at the Dell online store, it costs $2094 to upgrade an R900 from 4G memory to 64G (or $4378 to upgrade to 128G) which justifies that some problems are best solved by just throwing memory at them. With EC2, you can’t do this.
- Even the largest instance types have slow disks. Related to the point above – you can’t change the disks either. Both software RAID striping the internal disks on an extra large EC2 instance or using striped EBS volumes is still going to be slower than a good RAID 10 controller with a battery backed write cache.
If you can live with these three things, then hopefully your migration should work smoothly. If you can’t free yourself from these limitations, then perhaps you should either look at a cloud hosting provider that can host non-virtualized servers for you in the same data center, or hold tight for the moment.
Morgan,
It is good to think about solutions. For example for lack of Virtual IPs I trust you can do some stuff with DNS or by installing local proxy on the web server which is responsible for routing. Though it is not as simple and as reliable.
Lack of customization is generally concern. You mention disks but this is basically everything – you get only specific types of instances available which you have to deal with. Though I think this is really the point beyond the cloud. If you can have any configuration you want it is far from Utility computing. The applications best designed for the cloud should be scalable by using number of such “units”.
The thing here is – many people do not have applications which are designed for the cloud. They run them on the cloud because this is easy to use no commitment hosting.
There are two more important things I’d mention
1) Virtualization Overhead. It may be relatively low or can be ver large depending on the workload. Need to keep it into account.
2) Shared Infrastructure. A lot of issues I’ve seen come from the fact the network and storage are shared so the performance is not as consistent as with dedicated setup. For example if I have 2 servers connected 1Gb via switch I know I can push some 100MB/sec between them in single direction. It is always the same which makes it easy to do the sizing etc. In case of cloud computing it is much more complicated.
I think Rackspace offer cloud offering and managed hosting.
G’day,
Mosso or Rackspacecould or whatever its called now (It was mosso when I worked for the Rack in UK) is same in terms of limitations to private ips.
So I guess the cloud is only useful for databases when you’re problem is CPU bound, that can be solved by adding additional replicas when necessary?
The company that I’m not working for did a feasibility test on using EC2 as a DR solution; if only EC2 had an SLA on actually being able to power on instances….
Trent
@Trent: Do you know if Mosso/Rackspacecloud can sit in the same data center as dedicated servers? It would be interesting to run non-virtualized database servers alongside a set of virtualized servers.
@Morgan Tocker
I’m not sure; when I left the Rack they were looking to acquire slicehort. Their main US DC is ‘DFW’ dallas fort worth which is where mailtrust is at and where all new managed configurations in the US are being popped.
That said, I know by default all managed hosting customers only get 100Mb/s swithces unless you pay the gE premium though again this is something that may have changed since I left.
– Trent
Hi
I was reviewing the discussion and wanted to share a slightly different solution to cloud computing. Most cloud offerings out there with all the benefits of cloud are shared. While that may not mean much it gets into the topics of compliance, security and performance. The alternative is ‘private cloud’ and what exactly is the difference. My company specializes in private cloud solutions. We approach hosting a bit differently. We don’t have package solutions but rather we like to get into your shoes find out how things work, what your doing and develop a HA solution from scratch.
Take a look at a article regarding our ‘private cloud’ from eWEEK
http://www.eweek.com/c/a/Cloud-Computing/Logicworks-Offers-Private-Cloud-Service-586768/
In addition since i want to stay on topic for MySQL
http://www.logicworks.net/news/2008/logicworks-becomes-first-authorized-mysql-platinum-hosting-partner-us
I’m interested in making connections, finding out what people are doing out there with their technology solutions. Add me to LinkedIn, i work out of New York City.
I’m a techie however I build introductions for companies and consultants who are looking for enterprise HA solutions.
—
Nicholas O’Neil, [email protected], (212) 625-5359
Enterprise Solutions Manager MCSA/MCSE/MCTS:SQL,+Messaging
Visit us @ http://www.logicworks.net
155 Avenue of the Americas, New York, NY, 10013
LinkedIn @ http://www.linkedin.com/in/noneil
MySQL on EC2 is not to be taken lightly… with EC2’s incredible features comes a barrel of quirks. We benchmarked how well MySQL performs on Amazon EC2 and are sharing our findings in a series of blog posts. I thought it might be of interest to the community here. Our first post shares an incredible finding on how Amazon’s hardware variations can make a significant difference in the results you get!
The blog post is here: http://www.infibase.com/blog/2009/07/mysql-on-amazon-ec2-part-1/
Cloud hosting literally means your website is served on a web server cluster with many, many web servers handling all of your visitors. Our hosting platform grows and expands automatically as needed… instantly.
That may be possible with webservers, but it’s never going to happen with MySQL servers.
Why do you say that, Morgan? Given a master/slave configuration, it should be possible to spin up new slave instances fairly easily. Take a snapshot of an existing slave volume, fire up a new MySQL instance with a volume created from that snapshot, point it at the master, and it should be ready for action in very short order. Stick a smart proxy in front of your MySQL cluster, and it can point queries at whatever slave instance is least busy (or just round-robin it). When demand drops below a certain threshold, just terminate one of the slave instances.
Am I missing something?
Earl
Earl – it may be possible, but the effort for MySQL to get to that point is *massive*. Take for example master/slave replication:
1) It doesn’t scale writes (at all).
2) It relies on you having complete duplication of contents on all nodes – so a replication slave with a large working set won’t work. Since I wrote this article the maximum memory/node has moved up to 68.4 GB, but it will cost you $2.40/hour ($1700/month). I can buy a Dell R900 in only a few months at that rate 😉