A Grid OS?

By Roderick Flores

I have recently been working on a test plan for a framework designed to deliver applications to grid users. The framework is useful for the specific environment in which the customer operates. However it has led me to imagine something more generic that anybody who manages a Grid intended for use by a diverse community would find useful.

You need to have a solid software infrastructure consisting of compilers, libraries, middleware, languages, and services. Your customers want to be able to run the applications that suit their goals best with as little fuss as possible. These include off-the-shelf, commercial customizations, open-source, freeware, supported in-house, and individually built software packages.

While there may be few interoperability issues within a small group or company, you can bet that not all programs will play well with others. Some applications will require very specific libraries and middleware while others will prove to be quite flexible. Some applications require supporting software for 64-bit architectures while others need 32-bit. Other software has different feature-sets on different hardware (e.g. SPARC versus x86) as well as software (e.g. Linux versus IRIX) systems. Still other applications, particularly those that are on long development cycles, tend to use older feature sets whose behavior may have changed or been eliminated from subsequent package releases. Meanwhile your in-house developers might be working on the bleeding-edge and therefore use software that is too unstable for the general user community. Face it: very few software developers expect their products to co-exist with others.

This is a big challenge for anybody who is expected to create a shared-computing environment for a big user community. Typically system administrators will create an operating-system image based upon anticipated usage patterns, security, stability, feature-sets, and availability. They will have specific builds for their web-farm, mail-servers, storage-nodes, and (most importantly) for our Grid computation nodes. They would also like to be proactive and keep their systems up to the latest security and bug-fix patch
levels. In addition, they are going to try to provide the best product they can; therefore they would like to provide the most feature-rich infrastructure with which they feel-comfortable. However, and most importantly, they will use a package manager to maintain software releases on their machines. Why would any system manager want to reinvent the wheel when it comes to building software when the vendors will do it for them?

This last practice has a significant impact on the software you will find on the Grid. If the hardware vendor has a build for the software you use, chances are that is what you will get. These package managers tend to keep only one version of a particular software package on a system at a time. Consequently if a newer version of a package is desired, the older one is removed. Even if they tried to make multiple packages coexist, files would be overwritten. There are a few "compat" versions but these are exceptions.

Clearly, when your mandate is to provide a shared computing environment that has a significant number of processing nodes as well as users, you will have to provide a more substantive infrastructure. At this point you could either build specialized virtual machines for each operating environment or you can create a shared infrastructure that any image can use. Utility-computing players like Amazon have you create your own machine image (AMI) but I think it is unreasonable to expect application users to have the skills to create a proper operating environment.

The second option, creating a shared infrastructure that any image can use could be considered a grid operating system from scratch vis-à-vis Linux from scratch. This type of framework would force us to place our software into a categorized structure capable of differentiating operating systems, hardware architectures, and application versions. This infrastructure should not replace the standard installs for the operating system in order to avoid conflicts – providing application support for a grid is orthogonal to managing a compute node.

All of this needs to work without overtaxing your customers (i.e. application users). The typical user doesn’t care which operating environment they are provided as long as their software runs. Rather they would prefer to be able to call their application as if it were the only version using the only installed system libraries and middleware on the only supported compute node configuration. Basically if a user wishes to use an application, they simply want to call it by name: for example python and perhaps python-2.3.7 or python-2.4.5 should they require a particular version.

A big component of your effort in creating the proposed framework is providing the correct versions of libraries and middleware to your customers’ frontline applications; this is a task that demands specialized configuration scripts whose job is to set-up the operating environment to match the user request and the operating environment. There are a few tools out there that are quite capable of accomplishing something like this. However there is nothing that I am aware of whose goal it is to specifically deliver applications on a grid. Instead this class of tools provides far more flexibility than what is necessary, let alone wanted.

Ultimately I think that the best thing for the industry would be to establish a standard Grid directory structure for placing software in shared environments (e.g. /<root-directory>/bin/<operating-system>/<architecture>/<application name>-<application version>). A standard method for exposing applications should be decided upon as well. This could be anything from link-farms, to wrapper-scripts, or even environment set-up scripts. If this were to happen software developers and Grid administrators could create standardized packages including configuration scripts that would install into this framework. Setting up python would then be as easy as installing the standard packages for each desired operating environment and then calling "python".