Getting Comfortable With Oversubscription

It's a key concept in getting any sort of shared resource efficiency.  We see it everywhere we look in our daily lives.

But as we talk about IT strategies, private cloud and fully virtualized environments, one of the biggest stumbling blocks I'm encountering is the idea of intentionally pushing oversubscription of IT infrastructure resources -- servers and storage.

And that's going to have to change, I think.

Oversubscription Everywhere

We're all familiar with various forms of shared infrastructure where -- by design -- it's assumed that all possible users won't demand full usage at the same time.

Sometimes it works out well, sometimes it doesn't. 

This week, I flew on an overbooked flight to San Francisco, to land in a state with crowded highways, perennial water shortages and a history of rolling electrical brownouts.

No wonder IT professionals are leery of infrastructure oversubscription -- there are plenty of real world example where it hasn't worked out so well :-)

Back to our overbooked airline flight example, one could theoretically fix the problem by providing a private jet and pilot, pre-reserved for each passenger, on demand and waiting.  But it's pretty clear that pre-reserving resources for the occasional worst-case can be outrageously expensive.

Although, given my travel schedule, I wouldn't mind that approach :-)

How We Used To Deal With Things In IT

There were certain parts of the infrastructure that had to be shared (e.g. networks), and certain parts that didn't need to be shared (e.g. servers).

Servers, in particular, usually were dedicated to a single application, and provisioned with the "worst case" in mind -- which led to the inevitable poor average server utilization which virtualization and VMware have been addressing for a while.

Networks, on the other hand, are shared resources.  Potential oversubscription is an inherent property of most networks.  Very few point-to-point networks with dedicated bandwidth are built these days.

So these cost-effective shared networks are monitored, traffic is prioritized, seamless infrastructure upgrades are made as traffic grows, and so on.  We've all grown very comfortable with this approach over time.

Storage, well, ended up somewhere in the middle.  In some cases, capacity and bandwidth are shared, in other cases, they're not -- witness the NAS vs. FC alternatives in the marketplace today.

Managing Server (And Storage) Resources More Like Networks

Virtualization of resources at scale creates pools that can be dynamically allocated, much like a network.

Certainly this is true for servers that are virtualized.  But if we think of storage less in terms of capacity, and more in terms of performance (response time and bandwidth), the same can be said for storage as well.

So, this brings up the question -- why on one hand are people so comfortable with using a shared, potentially oversubscribed network to access their applications -- but on the other hand exhibit strong reactions to the idea of shared server resources (e.g. virtualization) and shared storage bandwidth?

I, for one, think the answer breaks into three parts: economics, process and psychology.

First, let's consider the relative economic costs.  If someone came to you and said "I need a dedicated global network for my application that is fully redundant and can never be oversubscribed", the associated incremental costs for that requirement would be mind-boggling, wouldn't they?

But, by comparison, if someone were to say "I need a dedicated server farm and associated storage for my application that is fully redundant and can never be oversubscribed", well -- it would be expensive, but not outrageously so.

Unless, of course, you've got hundreds or thousands of applications, and then the aggregate costs of this approach would be, well, outrageous.

Which seems to be exactly the place so many IT infrastructure people are in today.

Second, let's look at the process part.  Frankly, the network people have done an excellent job in managing their shared resource -- the network.  They usually have the tools and the processes in place to manage oversubscription cost-effectively.

Yes, they do have their bad days, but they're infrequent and well managed when they do happen -- unlike, say, most airlines.

Mainframe people got very comfortable with the same shared-resource management model.  When we moved to UNIX and Windows, it was far easier to just plop in another server rather than invest in learning to manage multiple, potentially competing applications on the same server.

Hence our current situation.

And, finally, there's psychology.  We've all met business users who want to see "their server".  Perfectly understandable.

One clever guy I met created an internal web page connected to a web cam in the data center where business users could see "their" server.

I don't think many people realized they were all looking at the exact same server sitting in the data center :-)

Where Does That Leave Us?

The economics are clear -- we're going to have to get comfortable with server and storage bandwidth oversubscription, much like we are with networks.

We learned to do it well on the mainframe, we'll have to do the same thing on the new "software mainframe" -- the fully virtualized private cloud, built on VMware.

The tools are there -- if you care to use them.

And, if internal IT environments don't get comfortable with delivering the improved economics -- and generally acceptable service levels -- that oversubscription provides, they'll be inevitably competing with external outsourcers, telcos and other service providers who *are* comfortable in these environments.

Everything must change ...

Comments

[yveke321]

Hi Chuck,

Oversubscription already exists for quite some time within Networked Storage, in the SAN, but also at the Storage array level. Sometimes referred to as Fan-in/Fan-out. Seldom do we use single server/dedicated front end controller ports on the arrays, but instead servers share the front end array ports in for example a 10:1 ratio. This is however oversubscription from a bandwidth/cpu or even cache(with or without QoS) perspective. Where there is still (valid) resistance is in the oversubscription of capacity, as used with Thin(or virtual) provisioning. Due to the implications(crash) of not having capacity available for a server or application, we tend to do a 1:1 capacity allocation. Mechanisms such as Quality of Capacity would help a lot to overcome some of the "discomforts".