Climbing the Spiral: A Better Rightsizing Paradigm

The first question discussed when planning a new system is often: “How large a system should be purchased.” Many times, system sizing is done long before anyone has any sound estimates of system utilization or load. Decisions on sizing are often made long before the relevant code is even designed, much less written and debugged.

This creates a conundrum. One can select a small system, taking the risk that it will be underpowered. Alternatively, one can be very protective, and purchase far more capacity than is likely to be needed, with the hope of preventing any possibility of a capacity shortage. This is a multi-dimensional dilemma. It is a decision with substantial financial impact; excess computing capacity beyond a small safety margin has been one of the worst performing investments in the history of computing. Effective employment of capital requires purchasing enough computing capacity to satisfy needs with a reasonable safety margin to provide for surges in demand. This has always been a dilemma. Today's challenging financial landscape only exacerbates the problem.

OpenVMS clusters can be used to ameliorate this dilemma, introducing a flexibility that reduces risk and reduces the temptation to over-provision resources.

“Rightsizing” has often been used as a euphemism for “downsizing.” While many use the term to refer to server consolidation or elimination, the concept has far more potential than merely “bean counter” euphemism.

Since the dawn of computing, the cost of a unit of computing has steadily decreased over time. It does not generally matter if the capacity is leased, rented, or purchased; installing or arranging for more capacity than is actually needed is almost always a poor choice.

This is true for all classes of computing; be it the oldest mainframe configuration or the latest cloud implementation. From the perspective of the actual equipment owner, equipment installed above and beyond expected usage is an extravagance.

Safety margins to handle surges are part and parcel of this calculation. Average usage is not the relevant factor. The relevant factor is expected usage, plus a capacity reserve to accommodate unexpected surges in demand.

Systems rarely have uniform activity. Sometimes, it is a question of generally low usage during a development cycle with surges of testing activity. Later, the tempo increases as a system is brought into production. Once in production a system is subject to the ebbs and flows of business activity – be it the predictable load of a holiday shopping season or a planetary encounter or the unpredictable load caused by crowd hysteria. The computation is the same: expected usage based upon known factors with a supplemental allowance for unpredictable contingencies and failures.

Even when purchasing hosting capacity from others, this calculation cannot be ignored. A provider who under provisions risks the cyber equivalent of a “bank run” on bandwidth or computing capacity, which can lead to missed commitments (I wrote about this issue in general in Why Settle on a Hosting Provider? Bandwidth liquidity and other issues, the May 12, 2010 installment in Ruminations - An IT Blog). OpenVMS is as vulnerable to under provisioning as is any other system.

The difference with OpenVMS is the flexibility of OpenVMS clusters to expand computing and storage capacity to accommodate the increased load while maintaining overall user availability. The ability of OpenVMS systems to share system residence volumes, together with the ease of creating new nodes and including them into an OpenVMS cluster makes “continuous rightsizing” possible. Nodes can be added to or subtracted from an OpenVMS cluster as needed to maintain the desired processing margins.

Base OpenVMS provides the ability to easily switch configurations. When logical names are properly used, applications are independent of the precise hardware configuration of the host system. OpenVMS clusters enhance this posture by providing further opportunities for increased flexibility. The first step in this direction is changing your default configuration choice from a standalone OpenVMS system to a soloist OpenVMS cluster (see Soloist OpenVMS Clusters: A New Perspective to Improve Functionality, Flexibility, and Usability ). However, a Soloist OpenVMS cluster is only the first step. The second step is hosting the single node of the soloist OpenVMS cluster on a fractionally provisioned virtual machine, either an Alpha or an Integrity VM. This means that projects can be prototyped and developed at nominal cost; without the need to purchase additional hardware capacity.

Similar strategies can be followed by using Shadowing for OpenVMS, generally known as Host-based Volume Shadowing (HBVS) and Dynamic Volume Expansion to render upgrades in storage capacity and changes in storage technologies invisible to users and overall system operation, an approach descibed in Migrating OpenVMS Storage Environments without Interruption or Disruption presented at the 2007 HP Enterprise Technology Symposium).

Starting with this basic foundation, system expansion is straightforward. The time lag between needing capacity and bringing capacity on-stream can be significantly reduced by pre-configuring bootstrap roots for additional, as yet non-realized members of the OpenVMS cluster. Bringing capacity on-stream thus becomes merely a matter of obtaining physical (or virtual) resources needed to run an already configured (but not presently active) OpenVMS cluster member node.

These operational and business concepts were at the heart of my recent OpenVMS Bootcamp presentation Using OpenVMS Technologies to Build an Agile Computing Base. As a courtesy to the community, we have made the slides and audio track from those sessions publicly available.

This is my perspective on how OpenVMS fulfills the aspirations of HP's Adaptive Infrastructure concept.

URLs for referencing this entry

Long:	http://www.rlgsc.com/blog/openvms-consultant/climbing-the-spiral.html
Short:	http://rlgsc.com/r/20101118.html