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.
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.
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.
