CiRBA Blog

In Praise of Mainframes

I've had a number of discussions recently regarding the sizing of servers for use in virtualization initiatives.  On one hand, keeping the cpu count low has the advantage of keeping software costs down, and allows an infrastructure to be constructed of low-cost, commoditized servers.  On the other hand, using larger servers has an advantage in that it provides better economies of scale when combining workloads, and also provides higher headroom for peak demands.  This has understandably been a hot topic of late.

When I try to put this in perspective I can't help but turn my thoughts to the mainframe world, where virtualization and proper capacity planning have been mainstays for decades.  This is the epitome of the scale up model, and few if any mainframe environments are suffering from the sprawl and underutilization that we are seeing in the opens systems world.

And there is, in my opinion, a significant underlying reason for this. It is what I call reverence for the platform, and, put simply, it is the fact that people respect big, expensive systems more than small, cheap ones. Why do we rarely see VM sprawl on mainframes? Because people don't mess with them.

This respect is important.  How important? Just watch any movie.

Nobody goes on a quest to seek advice from "blade rack"

Nobody tries to defeat the enemy by knocking out their "midrange"

Nobody crawls through air ducts to gain access to "file and print"

They go to Mainframe

They go to the biggest, most vertically scaled thing they can find.

In fact, the only prominent example of a horizontally scaled technology in a movie that I can think of is the Borg. But it was evil – more like a grid with attitude. And that may have been a TV show.

So next time you are sizing servers for virtualization be sure to pay some attention to the ultimate non-technical consideration: reverence for the platform.  And who knows - if a bunch of actors come walking through the server room they may just try wreck your stuff instead…

Virtualization: Technical Challenge or Business Challenge?

Many view virtualization as a technical challenge, and focus on determining how many applications can be combined together on as little hardware as possible.  I would challenge this notion, and say that it is instead a business challenge, which largely revolves around determining which applications should be placed together from a business perspective.

The difference is important, and any confusion between the two can be explained quite simply.  Many virtualization projects start out in the lab, which is relatively free of business constraints.  This tends to cause early virtualization investigations to focus on the technical aspects of virtualization, and the criteria used to combine applications is almost universally driven by workload considerations.

Once you go beyond the lab, however, the "real world" production environments are riddled with constraints, including change restrictions, availability commitments, business owner relationships, compliance rules, etc..  To charge into such environments using workload as the primary consideration for virtualization is to run the risk of constructing a completely dysfunctional infrastructure.  Consider a simple case: by combining applications that have non-overlapping maintenance windows onto a single physical server you may never be able to do hardware maintenance again.

This is but one example, and to list all the business constraints that govern production environments would be daunting.  But for a start I always recommend incuding the following basic constraints when analyzing production environments:

• physical location
• operational environment
• application tier
• availabilty target

There are many others, but these are a good start.  It is rare that one would seek to combine a production server and its DR counterpart on the same server, and combining servers from different application tiers on the same system can create correlated workloads that slow transaction response times.  Location is also usually a big constraint, although this is often lifted if the virtualization is part of a larger data center consolidation.  Keeping availability levels consistent between VMs is always wise, and allows you to size and spec hardware appropriately, particularly wrt redundancy levels and UPS requirements.

These are specific examples, but are part of a general trend.  As virtualization moves out of the lab and into production, the challenge becomes less and less about the the specific virtualization technology and how to stack workloads on it, and more about the target environment and the proper consideration of all the constraints within it.

Branching Late

We met with a number of technology analysts in the last week to discuss version 4.0 of our product and one conversation stands out as particularly interesting in my mind. The discussion centered on how to arrive at the best strategies for consolidation and/or virtualization for a particular set of servers that are part of a larger environment.

The analysts were describing cases they've seen where a strategy was decided upon early, and that this strategy dictated the end result and prevented the exploration of other options. They referred to this as "branching early", where a path is committed to early in the process, even if it not optimal. An example would be to say "we're going to take those servers at that location and virtualize them all" without proper consideration of what is on the servers or whether location is a true constraint on the virtualization process.

I contrasted this with the preferred approach of "branching late" and holding off on committing to a path for a set of servers until you having performed various types of what-if analysis. For example, the servers in question can first be analyzed for database and app server consolidation potential, which helps avoid putting I/O intensive apps on virtualized platforms (and also saves on expensive VM licenses). They can also be kept in a larger pool and a location constraint can be applied or lifted, allowing exploration of other options by effectively allowing an analyst to say "now let's see how much consolidation we can do if we allow ourselves to go across locations."

By keeping target servers grouped together and using constraint models to analyze the possibilities, rather than breaking them up along specific lines and committing to a strategy prematurely, this "late branching" technique is a much more effective way to determine the "optimal transfer function" for a set of servers.

We met with a number of technology analysts in the last week to discuss version 4.0 of our product and one conversation stands out as particularly interesting in my mind. The discussion centered on how to arrive at the best strategies for consolidation and/or virtualization for a particular set of servers that are part of a larger environment.

The analysts were describing cases they've seen where a strategy was decided upon early, and that this strategy dictated the end result and prevented the exploration of other options. They referred to this as "branching early", where a path is committed to early in the process, even if it not optimal. An example would be to say "we're going to take those servers at that location and virtualize them all" without proper consideration of what is on the servers or whether location is a true constraint on the virtualization process.

I contrasted this with the preferred approach of "branching late" and holding off on committing to a path for a set of servers until you having performed various types of what-if analysis. For example, the servers in question can first be analyzed for database and app server consolidation potential, which helps avoid putting I/O intensive apps on virtualized platforms (and also saves on expensive VM licenses). They can also be kept in a larger pool and a location constraint can be applied or lifted, allowing exploration of other options by effectively allowing an analyst to say "now let's see how much consolidation we can do if we allow ourselves to go across locations."

By keeping target servers grouped together and using constraint models to analyze the possibilities, rather than breaking them up along specific lines and committing to a strategy prematurely, this "late branching" technique is a much more effective way to determine the "optimal transfer function" for a set of servers.

Inaugural Post

Welcome to my new blog. 

It is going live as part of an update to our website, and I plan to use it to post observations and commentary on data center management and optimization, with a particular focus on server consolidation and virtualization.  People are always saying to me "you should write that down....it's an interesting perspective..."  Well now I can.

January 16th marks an important date for our company as we ship version 4.0 of our Data Center Intelligence product.  We think this highly unique and powerful software will change the way server consolidation and virtualization analysis will be done in many data centers. To coincide with the release I decided to join the Blogging ranks.

Be sure to visit again...