Server Consolidation - Back to the Future

Fashions change with the times. Today's rage is passe tomorrow; that which is out of favor today is tomorrow's rage.

Computing is as subject to fashions and fads as any other human activity. Trendy ideas are fashions of the moment, and soon fall out of favor. Good ideas may temporarily fall from favor and seem unfashionable; yet in the end are timeless. So it is far from surprising that today's computing milieu has come full circle, and multi-role servers are once again the rage; with major manufacturers and research firms promoting the Total Cost of Ownership (TCO) benefits of server consolidation. Yet these very same manufacturers and research firms often had, just a short time previously, declared multi-role central (or organizational) systems dead; declaring instead that the wave of the future was the unconstrained proliferation of small systems liberated from the burden of central control. At that time, it was argued that freedom from central control was beneficial.

What is often left unsaid is that the reductions in TCO and increases in scalability achieved by server consolidation (and for that matter, so-called utility computing) all but require the systems and operations disciplines that were much disparaged in the rush to de-centralize computing. What was not realized, and was often lost, is the understanding that coexistence on a single system and operating environment requires a degree of discipline and care that one can occasionally ignore on small systems. The limited environment of a single function system can obscure the importance of boundaries. In reality, the discipline and care required to enforce well-defined boundaries are the keys to realizing the holy grail of cost- effectiveness: agility.

OpenVMS from its beginnings has excelled at providing a reliable, secure platform for highly diverse environments, easily supporting a multitude of otherwise independent functions on a single integrated system.

Today's OpenVMS systems range from very small VAX-based systems, to very high-end Alphas and the coming Itanium-based systems. There are many applications today that have transcended several generations of hardware with minimal change; the VAX to Alpha transition via image translation and will similarly make the Itanium transition by re- translating the resulting Alpha executable to Itanium. This is not to say that these applications would not benefit from re-compilation, merely the translation technology is so robust that efforts are better spent on other matters.

A discussion of where image translation fits into the spectrum of possible strategies is deserving of its own column, which I will reserve to a future occasion. What is more important, and more critical to the average system manager and user, is the techniques that applications use to be good citizens on OpenVMS. Good citizenship is the unsung reason behind the large savings in TCO and increases in scalability.

Successful applications leverage OpenVMS' user environment and security features to generate flexibility and maintain security. The most crucial feature to scalability and robust operation is brickwall protection, the absolute separation of different end-user processes.

Specifically, brickwall protection ensures the integrity of the protection schemes used to control access to files and system hardware. A wide range of separately controllable privileges determines access to the global system state. Thus, a properly managed system allows users an environment secure from interference by others sharing the system.

The user environment is parametric, namely, it is customized for each user based upon information contained in the UAF (User Authorization File). This parameterization allows different users to securely experience dramatically different environments, each dependant upon settings in their individual UAF entry (or for that matter, based upon membership in a particular UIC group, or any other datum stored in the UAF).

One of the first rules is that the there is little need for elevated privileges in the overwhelming majority of OpenVMS applications. Elevated privileges are rarely needed; file access permissions to particular files are more than adequate in most cases. In truth, in over 25 years, this author has seen a very small number of situations where elevated privileges (those privileges beyond NETMBX and TMPMBX) are actually needed for an application. The increase in system availability and a decrease in necessary reboots are directly related to limiting privileged access to system facilities. With a relatively small investment in planning and security, it is quite possible to manage large OpenVMS systems. These systems support constituencies numbered in the hundreds or thousands of users, spread across a multitude of functions, each with its own startup and shutdown functions, all within security domains on a single system. This can all be accomplished without an extensive systems programming staff. Unlike other systems, OpenVMS has the full suite of building blocks necessary to construct such an environment safely and securely.

Previous columns have covered the use of the logical name facilities, and future columns will discuss how the basic (groups/users), and the extended security capabilities (Rightslist identifiers and ACLs) are used to leverage the environment.

The ubiquitous use of SYS$SYSTEM, SYS$STARTUP, SYS$LOGIN, and SYS$SCRATCH (and other logical names) similarly provide extensive leverage. In reality, OpenVMS is an example of how simplicity and cleanliness is indeed the key to reductions in TCO.

In summary, the traditional best practices for building and managing OpenVMS systems are the same best practices that are the basis of the TCO benefits achieved by server consolidation.

URLs for referencing this entry

Long:	http://www.rlgsc.com/blog/openvms-consultant/server-consolidation.html
Short:	http://rlgsc.com/r/20030806.html