Clusters have traditionally belonged to a small community of users. When groups begin to pool their resources to form grids, the size of the user community for each individual cluster grows. Each user community in turn brings with it new applications and requirements. In many cases, these new applications may have requirements that conflict, one typical example being applications that require different versions of the same package.
In this example, application A requires version 1.7 of the foo package, but appplication B requires version 1.1. On a traditional fabric, these demands cannot both be satisfied at the same time.
However, a machine will only usually be running either application A or application B at any given moment, not both at once. This means that although each machine should be able to run both applications it doesn't need to provide all their dependencies all the time. In an ideal situation, the node might be able to decide which packages it should have installed at any one time, depending on the application the user wishes to run.
In a system like this, the version of the foo package that is currently needed might be installed on-the-fly just before the application runs. But how can a node know what application is about to run? One easy way is to have the user tell it just before the application is executed. It can then perform any necessary changes before the run commences.
In our implementation, the nodeswitcher allows the user to inform the node of the requirements of the job that is about run. By including a call to nodeswitcher in their job script, the user can pick a predefined configuration that is suitable for their job to run in. The system is able to ensure that the user's job runs in the correct environment.
|See nodeswitcher in action.|
|A user session showing job submission and its output||AVI||1.7 Mb||Download|
|A monitor window showing a node's RPMs change when its job runs.||AVI||1.4 Mb||Download|
|The monitor window in its final state, showing the changed RPMs.||JPEG||129 Kb||Download|
|The monitor window in its final state, showing the changed PATH.||JPEG||139 Kb||Download|
|An administrator session observing a node's configuration log as a job causes reconfiguration||AVI||122 Kb||Download|
|The configuration log in its final state||JPEG||115 Kb||Download|
These techniques enable administrators to support more applications on a cluster much more easily, but there is still a major source of overhead: for each different collection of packages we need, we must pre-arrange a name for them that the nodes can recognise. This might require a great deal of human input.
To avoid this problem, we developed a system whereby users can arrange for new groups of packages to be identified, without the involvement of the system administrators. Of course, adding new packages to the system remains within the domain of the system administrator, but for packages which are already available to the cluster, users may select new combinations to make use of.
We provide a simple GUI interface to allow users to list the packages they desire. From here, the packages are sent to a server which makes all nodes in the cluster aware of the new configuration. The GUI displays a reference which can be passed to nodeswitcher to notify a node that this list of packages is required. The references used in the previous section were obtained this way.
|Watch negotiation in action.|
|The GUI main display||JPEG||116 Kb||Download|
|The package entry screen||JPEG||62 Kb||Download|
|A user session with the GUI setting up an environment for their application||MPEG||430 Kb||Download|
|The main display showing a successfully deployed configuration.||JPEG||128 Kb||Download|