The HP Virtual Server Environment at a Glance : The Target Problem—Rampant System Over-Provisioning

9/24/2012 7:03:34 PM
The key problem the Virtual Server Environment is designed to address is rampant over- provisioning of systems for the workloads they are running. Even today most customers admit to average system utilization numbers in the 25–30% range, and that is on higher-end 64-bit HP servers. It is not uncommon for utilization in the 32-bit Windows and Linux environment to be in the single digits. Figure 1 shows an example of the average utilization of a large number of servers in a datacenter.
Figure 1. Average utilization of servers across a large datacenter

In this figure you can see that a large number of servers are seriously over-provisioned. At the same time there are a handful of servers (typically older servers) that are no longer able to handle the load that is being placed on them. The real opportunity for consolidation is to put some of the workloads running on the servers on the right-hand side with the workloads running on the servers on the left-hand side onto larger servers together so that the unused capacity on the left can be allocated to the applications on the right. This provides a number of compelling advantages, including:

  • Higher utilization— the combined workloads could run at a higher level of utilization on the new shared server.

  • Lower total cost of ownership— because you have fewer systems to purchase and manage.

  • Better performance— the applications on the right will achieve better performance because they will have more resources available to them when they are busy.

The fact of the matter is that even consolidating the applications on the left-hand side will provide benefits. The biggest issue is still the systems that are over-provisioned. This brings escalating management costs for the large number of systems that are woefully underutilized. Let's explore a little about why utilization is so low in most datacenters and what can be done about it.

Why Over-Provisioning Is So Common

Over-provisioning is still the norm for a number of reasons. These include:

  • The perceived need for separate servers for each workload. There were, and still are, a number of reasons why some applications might need to run on their own server. The environment can be tuned specifically to the application and you can ensure that there are no other applications that might be competing for resources.

  • Business units (BUs) “own” the servers. Many companies have an IT model where the business units identify a requirement for a server, they work with IT to scope the size of the server, and then the BU pays for the cost of the server. IT then purchases the server and provisions it for the application. In this case there is no incentive for the business unit to share those resources with workloads from other business units, even if the vast majority of the resources are going to waste—the server has already been paid for.

  • Capacity planning is often little more than educated guesswork. If the application being deployed on the new server is new, there is very little information about the expected load, resource profile, or performance requirements of the workload. In these cases, most business units set the expectation that their usage will be higher than what it actually is.

  • The penalty for under-provisioning is severe. One of the reasons the estimates are typically high is that the cost of underestimating is another upgrade. You will need to get another larger server and initiate yet another migration off the new server you just bought onto the larger one. Not only is this costly in that you need to get a new server, but you also need to spend an exceptional amount of time to migrate and test the application once again. This can also lead to a loss of credibility, which will result in second-guessing of future capacity-planning reports.

The bottom line is that the combination of these issues has led to the proliferation of systems that are dedicated to a single workload. The fact is, if you have a single workload running on a system, you can't possibly get utilization over 50% without risking performance problems when the application is under stress. Figure 2 shows a sample resource consumption profile for a typical application.

Figure 2. Demand Profile for an Actual Production Workload

This graph shows that there are many short-term peaks and only a few large ones. And the large ones are short in duration. If you were to size a system for this workload, you would need to allow resources for the highest peak plus some amount of growth over the life of the system. The end result of this would mean that for all but an hour or so each day the system would be very lightly used and the average utilization would be less than one third of the size of the system.

Consolidation Makes Increasing Utilization Possible

Because workloads have these spikes, you need to make sure there are sufficient resources to meet the peak needs of each workload. Utilization is low because utilization peaks are usually high and short in duration. One way of increasing utilization is to provide a way for the resources to be used by other workloads when they aren't needed by this one.

Several studies show that running workloads in a consolidated environment reduces the need for CPU resources by roughly 40% with no performance degradation of any of the workloads. This is because the peaks of the different applications are usually short in duration and they do not occur at exactly the same time.

One concern with traditional consolidation (running multiple applications in a single copy of the operating system) is that there are a number of technical and political barriers to success. Technical barriers can include:

  • File system namespace collisions— different applications attempting to read or write the same files

  • Network port collisions— different applications attempting to attach to the same network ports

  • Interprocess Communications (IPC) collisions— different applications or instances of the same applications attempting to access the same shared memory segments, message queues, named pipes, etc.

  • Inconsistent kernel tunables or patch levels— each application may have specific kernel tunables or patches that are incompatible with those needed by the other applications.

Although these technical barriers can make consolidation of some combinations of applications within a single OS image impossible, they are actually pretty rare. However, political barriers are very common. These can include:

  • Coordinating reboots is difficult. If the applications are owned by different user groups, it can be very difficult to coordinate among the groups sharing a server when a reboot is necessary to resolve a problem with only one of the applications.

  • Multiple applications are impacted whenever a failure occurs.

  • Support may be harder to get for some software products. Even if the applications will work just fine when sharing an OS, if the independent software vendor (ISV) won't support running their application with some other application, you can't put the combination into a production environment.

  • User wariness. Some users just won't be comfortable about the fact that you have their application in an environment where there are one or more other applications that they don't own or understand. This wariness is usually unfounded, but it only takes one time for another application to impact their application before they ask you to put their application in an isolated environment.

What is needed is the ability to run the applications on the same system so that they can share resources AND isolate them from each other. What you need is virtualization.

Virtualization Makes Consolidation Easier

A key component of HP's Adaptive Enterprise messaging is the virtualization of the environments that applications run in. This gives the ability to reallocate unused resources in one virtual environment to workloads that need them in another. With virtualization, this can be done in a way that is transparent to the users of the application and even to the application itself.

How the Virtual Server Environment Can Help

There are actually two ways to increase utilization in this environment. The first is to consolidate multiple workloads on a server to allow resources not being used by one workload to be used by others. The other is to provide headroom in the system that is utility priced and idle until it is needed. The Virtual Server Environment (VSE) provides both of these.

Consolidation is very different today than it was even five years ago. There are now a number of partitioning alternatives that make it possible to isolate workloads from each other while allowing the resources of the system to be shared by the different workloads. However, partitioning alone is not sufficient. What we really want is dynamism. It doesn't do you any good to partition a box into four CPU partitions to run your workloads if those four partitions can't flex to allow the resources to be shared. The VSE has four different partitioning solutions that allow you to run multiple workloads on each server so that idle resources can be brought to bear on workloads that can use them. These partitioning solutions provide various levels of hardware and software isolation so the applications can't impact each other even though they are running on the same system.

There are also several Utility Pricing solutions that allow you to pay for resources as you use them. This makes it possible to provision a system with sufficient resources to meet the peak expected demands of the workloads running on the system but to have some of those resources be inactive inside the box. This makes it possible to run the system at much higher levels of utilization while still ensuring that there are sufficient resources on hand when a spike in load occurs.

Finally, the VSE has a number of management tools that provide simple configuration interfaces, automated resource allocation, and high availability. These management tools make it easier to take advantage of some of the more advanced features of the VSE.

  •  Oracle Coherence 3.5 : Clustered cache topologies (part 3) - Near cache
  •  Oracle Coherence 3.5 : Clustered cache topologies (part 2) - Partitioned Cache service
  •  Oracle Coherence 3.5 : Clustered cache topologies (part 1) - Replicated Cache service
  •  Oracle Coherence 3.5 : Planning Your Caches - Anatomy of a clustered cache
  •  Memory Management : Clean Up Managed Resources Using the Dispose Pattern
  •  Memory Management : Get the OS View of Your Application's Memory, Clean Up Unmanaged Resources Using Finalization
  •  Active Directory Domain Services 2008 : Create a WMI Filter, Import a WMI Filter, Export a WMI Filter
  •  Active Directory Domain Services 2008 : Filter Group Policy Object Scope by Using Security Groups, Disable User Settings in a Group Policy Object, Disable Computer Settings in a Group Policy Object
  •  Active Directory Domain Services 2008 : Block & Remove Block Inheritance of Group Policy Objects, Change the Order of Group Policy Object Links
  •  The Future Of Apple: Chip Off The Block (Part 10)
    Top 10
    Review : Sigma 24mm f/1.4 DG HSM Art
    Review : Canon EF11-24mm f/4L USM
    Review : Creative Sound Blaster Roar 2
    Review : Philips Fidelio M2L
    Review : Alienware 17 - Dell's Alienware laptops
    Review Smartwatch : Wellograph
    Review : Xiaomi Redmi 2
    Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
    Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
    3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
    Popular Tags
    Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8