30% of Servers Are Sitting “Comatose”
anthesisgroup.com
anthesisgroup.com
It is interesting to look at server utilization, Google had a very publicized plan for power driven computing (basically you switched on more machines as you needed them, turned them off when they were idle). Which kind of works and kind of doesn't when you consider the complete picture of computational dynamics. Of the many resources requires (memory, compute, storage, and networking) only compute is easily "turned off" and "turned on" again. Next best is memory with many non-server memory systems allowing for a low power standby mode, disks and networks are both pretty much a massive latency hit when powered down.
And oddly latency is the fidelity of internet interaction. We think of things with low latency and rapid response as "good" and things which have high latency and slow response as "bad". Just as an amplifier with poor frequency response is 'muddy' and one that has high frequency response 'crisp'. At scale your idle machine are essentially latency capacitors waiting for that sudden burst of packets that happens during the commercial breaks.
It is an area that is ripe for improvement but it needs some pretty deep thinking to go along with that.
Is that still true with SSD's? I can't imagine they take anything like as long to come on as spinning rust but I've no idea so now I'm curious :).
Most SSDs, like Intel's series, are instantly available. They cost little power to keep running all the time, so there's no need to power them down, and they'll be operational by the time your system POSTs.
There probably is wastage, though it would nice to see a proper, modern, scientific study on this though.
Originally I submitted Computerworld story [1], which is a summary of a few studies (including NRDC's), but that submission's url got changed to pdf, and today I got mod-email that it's "a good story to repost", so I posted announcement this time.
[1] http://www.computerworld.com/article/2937408/data-center/1-i...
In short we were building new servers every time a new order came in and when a customer cancelled or stopped paying their server would continue to sit idle. An audit was eventually run and something like 25% of our tens of thousands of servers were simply sitting there waiting for a new client.
I think at this point our billing developer was fired but this was so long ago the details have become fuzzy.
Today this lives on of course: you'll notice on AWS' EC2 pricing you can get memory and CPU time commits, but Amazon doesn't give you any sort of bandwidth guarantee for your instance (I don't mean transfer in the aggregate sense, but I mean how many MB/s your instance can sustain).
And a lot of time that's fine; quite a few people buying shared hosting are often more concerned about not paying through the nose if their small-time site gets slashdotted than about pumping every ounce of bandwidth they can 24/7.
Sometimes, better your site go down then you have a huge bill for something you're not monetizing.
Are these servers unsold resources? Are they hot spares? How many bytes of traffic and how many CPU cycles count as computing services? How much do they cost versus the cost of the whole datacenter including employees? Looking at other industries, is a 70% yield really that low?
30% idle is easily achievable if you're doing proper disaster recovery (recovery when the entire office is gone due to earthquake, flood, fire, etc).
In normal operation, the 3 bare metal servers do all of the work. But when one goes down, the role moves to the VM, where it might run in degraded mode until the physical server is restored.
P.S.: I bet there are some biological analogies are apropos. How long would you live if everything was redlined?
You could probably implement your idea just for yourself with a script though.