The Idle Cycle Conundrum

One of the advantages of a private cloud architecture is the flexible pooling of resources that allows rapid change to match business demands. These resource pools adapt to the changing demands of existing services and allow for new services to be deployed rapidly. For these pools to maintain adequate performance, they must be designed to handle peak periods and this will also result in periods with idle cycles.

In a traditional IT environment there are two excellent examples: backup and email. Email will typically peak at the start of the day and remain constant for the remainder of the day, with smaller peaks possible at lunch and quit times. Many traditional backup systems do the heavy lifting at night to avoid performance hits on production applications. With a private cloud environment, these different applications would most likely be sharing the same physical resources, which would increase hardware utilization and decrease idle cycles. Even with these advantages, idle cycles will still occur, and, in many cases, will occur regularly, based on time of day, month or year. The question becomes what to do with these cycles.

One school of thought revolves around power management. The idea being that if the resource isn’t being utilized, you don’t want to pay to power it. Depending on hardware and software, this can be automated at a very granular level. Processors can reduce power, server components can cap and more. Additionally, with virtualization software it’s possible to consolidate workloads across physical resources during off periods and shut down unused physical resources, bringing them back online as needs increase. This saves on power, but there is another issue.

Powered on or not, your IT hardware depreciates. The dollar value of purchase is written off over time on corporate books, and, more importantly, the hardware itself ages. IT hardware is quickly surpassed and is jokingly outdated by the time you stand it up. Additionally, as hardware ages, the MTBF increases. Powering it down during off peak periods saves money, but that hardware is still wasting away without providing value.

With this in mind, the other school of thought is finding alternative uses for that hardware during idle periods. Rather than shutting systems down and saving power, utilize the resources for other tasks that don’t otherwise get done or could use additional resources. Depending on the hardware and software platform, this could be done at either the physical or virtual level, with virtual typically being the easiest.

One example of a repurpose use would be Hadoop. Hadoop is designed to process large data sets, or big data, in parallel for increased speeds and reduced costs. To accomplish this, Hadoop spreads the processing and data across multiple nodes, from a few to upward of 6.000. Data files are fed into the Hadoop cluster, and processing functions are then run on those data sets.

Utilizing a small number of permanently dedicated resources--primarily Name and Job Tracker nodes, with a few slave nodes--idle resources could be added to the cluster when available. This would allow scalable processing of things like customer or Web traffic data, and so on.

This particular use case would be most relevant in environments with more seasonal peaks, weekly or monthly, due to redistribution of data across the cluster as nodes are added/removed. Additionally, fine tuning would be required to optimize for the architecture, but with the right data sets and resources this would allow data to be processed that might otherwise be neglected due to other priorities.

Hadoop is just one hypothetical example of services or applications that can be run using idle CPU cycles on an enterprise private cloud; many more exist. Remember, a private cloud should provide your IT staff with more time to work on strategic initiatives rather than tactical tasks, an allow them to use that time to optimize efficiencies and support IT’s customer, the business.