Welcome!

Java Authors: Pat Romanski, Elizabeth White, Adrian Bridgwater, Liz McMillan, Kevin Benedict

Related Topics: Virtualization, Java, Linux, Cloud Expo, Big Data Journal, SDN Journal

Virtualization: Blog Feed Post

Resource Pools versus Virtual Machine Pools

On the importance of recognizing that what we have today is not a pool of resources, but a pool of virtual machines

This post is following up on last week's post, "The Inevitability of Idle Resources", in which I mentioned the importance of ensuring not only that resources are available when you need to provision a new service to scale but that the resources available match the needs of the service.

So let's continue that by assuming you can find some idle (available) resources to use when you need them. Two questions need to be asked before you hit the easy button:

  1. Are there enough resources to support this service? After all, different services require different resource profiles. Some need more storage, others more RAM, others many CPUs.
  2. What's the possible impact of provisioning this service on this resource? In other words, what else is currently using these resources? How many other virtual instances are on the same hardware and what are their resource consumption profiles? What will happen if I provision two network-hungry services on the same hardware (especially in cloud environments that share a physical network interface)?

Marketing makes it sound so simple. Just grab some resources and provision away. But the reality that IT professionals know is that different services require different resources and contention for those resources is a primary cause of poor application performance and network congestion. Which is one of the arguments for specialized resources, but let's not muddy the waters with that discussion today.

What happens if you don't have the appropriate resources? Well, it's going to throw your math off and that will throw your capacity planning off.

Let's say you know you need X RAM and Y CPU and Z network in order to support 1000 CPS (connections per second) for your load balancing service. Your capacity planning exercises, then, are based on this assumption. If you set up your systems to auto-scale based on that assumption and then, for some reason, you scale your load balancing service by provisioning it with a resource profile capable of only supporting 600 or 700 CPS without significant degradation of performance, well.. you can imagine what happens. Users become frustrated, your phone starts ringing and there goes your quarterly bonus along with big chunks of your hair because the system won't kick off another instance of the service until you near that 1000 CPS threshold. (This is a good time to point out that a more adaptable load balancing algorithm might be helpful though not a panacea).

This is true for just about everything you want to run. Applications, network services, application services. It doesn't matter. Each one is going to have its unique resource requirement profile and if you start ignoring that your systems are going to begin to acting wonky.

Until we reach the real data center nirvana, where hardware resources really are a single pool from which the appropriate combination of memory, CPU and network capacity can be provisioned for a specific application or service, we have virtualization and pools of pre-determined resource sets. We don't  have a pool of resources, we have a pool of virtual machines. While advances have been made in terms of growing and shrinking virtual machine resource allocations, it's far from nirvana and it's far from perfect (and rarely on-demand).

That means when you're chopping up resources into virtual machines you're still going to have to indulge in sizing exercises and capacity planning. At least until we have true pools of resources and not pools of virtual machines.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.