Slashdot Mirror
Amazon's Cloud May Provision 50,000 VMs a Day
Dan Jones writes "It has been estimated that Amazon Web Services is provisioning some 50,000 EC2 server instances per day, or more than 18 million per year. But that may not be entirely accurate. A single Amazon Machine Image (the virtual machine) may be launched multiple times as an EC2 instance, thereby indicating that the true number of individual Amazon servers may be lower, perhaps much lower, than 50,000 per day. So, even if it's out by a factor of 10 that's still 1.8 million VMs per year. Is that sustainable? By way of comparison, In February of this year, Amazon announced S3 contained 40 billion objects. By August, the number was 64 billion objects. This indicates a growth of 4 billion S3 objects per month, giving a daily growth total of about 133 million new S3 objects per day. How big can the cloud get before it starts to rain?"
I agree, the rain does muddy the waters somewhat. Not to mention the flood of comments deriding it as such.
Ok, you don't work in IT right? At least not on the admin side.
VM are mainly about server consolidation. That means that given the fact that servers are usually under utilized you can put quite a number of VM per core. Usually for server workloads the number is around 2: 2VM * 4 cores * 2 cpu (typical blade) yields 16 VM. You see, in the end the power company gets paid only for a physical server every 16 OS instances. Not bad.
Server consolidation is not the only reason you use virtualization. Other issues you can solve are: high availability and fault tolerance, quick deployment of new servers, hardware abstraction and many others
Its more than that.
/.) then you still have the beefy hardware to cope with it. You will also find heating bills go down. You'll usually even get the costs of the hardware down as well.
Most machines run at around 10% of all possible utilisation. Often web servers will run at less than this. In a datacenter you have two options a) run hundreds of very slow cheap machines each running one instance of your webserver. b) consolidate lots of machines onto one powerful box and running it at 70-80% utilisation.
Option b) has the advantage that should a website get hit heavily (maybe because its been linked too on
If your still not convinced then look at the work by most VM software manufacturers who are making it so the VM can move around on physical hardware. Now if your hardware fails - the VM and OS does not. It just moves off somewhere else and continues to operate with little/no drop in performance or uptime.
I've never really understood the fuss around VMs. Sure , they're useful if you want to test run an OS install or run a different OS on top of another. But otherwise whats the point? Instead of having app + OS you end up with app + VM + OS so how exactly is that benefiting anyone other than the power company for the extra electricity used?
Because for the most part, most servers don't run anywhere near full capacity (and if they do, then they are probably not good candidates for virtualization, except possibly for high availability purposes which I will go over in the second paragraph). I forget the study but I read once that on average a typical server sits at 5-15% utilization. So the idea behind products like VMware ESX is that if you need 5 unique servers, instead of buying 5 servers at $5,000 a piece, you buy 1 server for $5,000 + 1 $5,000 VMware license, and run the 5 virtual servers on that. So you spend $10,000 instead of $25,000, and your footprint is 1/5th of what it was before, meaning less racks, less cooling, less power, etc. And the numbers I gave are very conservative. A lot of people do 10-20 VMs per server easily.
So cost, power, and cooling issues aside, there are other issues. In a typical server environment, if a physical server suffers from a catastrophic hardware failure, that server is down until someone can walk over and swap the hardware. With VMware, if a VM is running on a server and that server fails, the VM is cold booted on another ESX server automatically, and is typically up in 30-60 seconds. With the newest release of ESX server, called vSphere, they take it a step further. You can optionally choose to have A VM mirror itself on to another physical ESX server. So in the event of a hardware failure, the VM keeps running on the mirrored host. And then, it becomes the primary VM and sets itself up to mirror automatically on another ESX server. So you have ZERO downtime and the app re-mirrors itself. These are just some of the many useful features in VMware.
And no, I do not work for VMware. I am a contractor for the Air Force and over the past 2 years I have converted almost 200 physical servers to VMs. We are a relatively small program, but our projections show that we will save $2,000,000 over 10 years just on the cost of servers (and yes, i have added in the cost of VMware licenses and support into that equation), and that doesn't even account for power and cooling savings. We've gone from almost 200 physical servers distributed over 7 full racks racks down to 28 servers in 2 racks (2 racks only because they are two separate facilities. Each rack only contains a single HP c-class chassis)
I think the real question is, how can you NOT understand the fuss around VMs?
Managers love this kind of terminology, because from their point of view Internet just 'happens' somehow, they do not have a real clue how, but the cloud fits perfectly into this kind of thinking. That is why cloud hosting is so popular, they just order 4GB/100Mbit/s cloud and the hosting company creates one for them. They do not have to worry about setting up DNS, SQLs, multiple servers, domains, SMTPs and get schooled by some lowlife nerdy IT guys, they understand the dumbed down cloud interface well enough themselves, they just interact with the web interface and are happy it is all working for them.. somehow, somewhere, in the cloud.
Managers love this kind of terminology, because from their point of view Internet just 'happens' somehow.
And cloud computing makes them right. You pay some money, and the entity you're paying the money to, makes it happen.
Just like when I buy a tin of soup from a supermarket, I don't need to understand anything about the supply chain that got it there.