Application Awareness Part 1 CPU

In my previous post concerning Application Awareness, I talked about resource utilization and the need for a workload manager type management layer which provides the ability to manage applications from the resource perspective. I would like to break that down to the different resources (core four of CPU, Memory, I/O and Network) for discussion.

From the CPU perspective, the good news is the number of cores is increasing. We started out with a single core, then added hyper threading, to dual cores, four cores and now six cores per processor. This trend aids in the move to virualization and 64 bit OS/Applications as the 32 bit OS's cannot utilize more than 4 cores and most only two cores. What this means is for the virtual world, there are a number of cores available for an ever increasing number of virtual machines per host. That's the good news. The bad news is there are only so many cores to share.

A brief note on how I equate cores for business people. A core is a resource where only one instruction can occur at a time. So sorting a report or fetching a record from disk is an instruction.

There's more good news in that the core speed is increasing as well which means the applications can run faster but more importantly, the core can process the instruction and be free for another instruction/vm to use that resource. So, let's break this down a bit further in how application awareness comes into play here. As applications grow and scale, they are utilizing the increased size (speed) and number (cores) more and more. What this means to the application awareness discussion is the need to separate out which applications need more CPU (CPU intensive processing) and Cores (multi-threaded applications to process in parallel).

In the physical world, this is not a problem. An application is assigned to a physical node and the application gets all of the resources. In the virtual world, this is a four step process.

1. The creation of the VM requires the number of processors (cores) to be defined.
2. The VM needs to be placed on a host which has enough processors (cores) to start the VM.
3. The application needs to perform within limits for Service Level Agreements (SLA's) to be defined and meet.

While VMware's Distributed Resource Scheduler (DRS) provides the ability to set priorities (once the VM is running) at the VM layer to balance resources and ensure VM's have the resources they need, this is a manual process at best. In the cloud where the operations staff is far removed from the business/application owner, taking the step towards application awareness will become vital for the performance and availability of applications in the cloud.

The cloud providers will need to factor into their portals the creation, placement and performance of the VM's to maintain customer satisfaction. Moving towards Application Awareness is the first step.

Application Awareness in the Cloud? Is it possible?

As we move closer to the cloud (private or public) the vendors are starting to circle the wagons around capacity planning, charge back and availability. In order to do this, the vendors (hardware and software) need to enable their components to be application aware. What exactly does this mean and what have we learned from our past?

A bit of history. Back in the main frame days, there was one computer being shared with batch jobs, online applications (think web today) and databases. There were more but lets start with this list. With only one computer to run all these applications on, there was a need to prioritize the different applications based on available resources and the priorities of the application (i.e. business unit). IBM and others created some thing called Workload Manager. The goal was to provide metrics at the resource (CPU, memory, I/O and network) and application (which application was using the resources and which one had priorities over other applications) level.

Moving back into today's world, in the physical (not virtual world), this is easy. Each application was installed onto one server. The application could use all the resources it wanted as it was the only application on that particular server. With the average CPU utilization rates of around 10%, this model is a huge waste of resources and power. Virtualization has in many ways, taken us back to the mainframe days (without the single computer).

So how do we enable the cloud to be application aware? A good start is to look to our past and what Workload manager did for us in the mainframe days. VMware has done a good job of prioritizing VM's with their resource management functions. This helps with ensuring resources are available on a given ESX host at start time and also for memory and CPU resources during run time. This assumes the VM is a single application, which in most cases it is. With the cloud, many applications from potentially many different customers will be running in the same environment. How do we prioritize these workloads based on service level agreements, price points (think phone companies charging more for day time calls, vice night time calls) and resource availability.

I propose the need for deeper awareness of the applications and resources by utilizing another piece of mainframe history. That being the concept of Systems Management Facility (SMF) and Resource Management Facility (RMF) type records. These records provide the ability to collect resource usage for performance and tuning, application usage for charge back and workload management for prioritization of applications across the cloud.

VMware has started the charge by opening up their API and some third party vendors have started bringing products to market for reporting and alerting on storage, CPU/Memory and network usage. Next steps are to tag the resources allowing application aware reporting and prioritization in the cloud.