DQS or the "Distributed Queueing System" is a highly portable (though somewhat primitive) system for clustering on Unix. It works by accepting the submission of jobs (or batches) which are queued for execution on whatever nodes are currently prepared to accept new jobs. It is arguable that DQS is more properly called a "collective" than a "cluster" as it is only a job-processing system.
Unlike openMosix or Beowulf, DQS is not tied to any specific Unix architecture, allowing you to have disparate computing architectures and even operating systems (as long as they are all Unix) in your cluster. However, it is distinctly less powerful than either of the given examples and paradoxically requires more management and setup. As it works by the submission of jobs, any software needed to process any job must be present on all nodes upon which you want the job to run. As all jobs run fully on remote nodes, and DQS does not itself provide any communication between nodes other than for tracking status and the submission of jobs, all data must be accessible to all nodes, and in the same way.
Even given these limitations, DQS is a remarkably useful software package, particularly in this modern age of free and open software. For example, it is entirely possible to build a cross-compiler for each architecture in your cluster to compile to each other architecture, meaning that disparate nodes can compile software for one another. Perhaps more importantly, it is also possible to compile a great deal of software on different flavors of Unix so that jobs you are submitting from the lowly workstation on your desk will be fanned out across other similar machines and massive servers at the same time.
DQS also allows the creation of arbitrarily-named queues. Thus you are free to characterize the machines in your cluster in any fashion you choose; by software present, hardware characteristics, or in any other fashion you like. Queues can be selected by wildcard, so if you take care with how you name your queues you can get a lot of mileage out of this feature. For example, a script which would run properly on any system in your cluster which was running Linux could be submitted only to those systems, or perhaps you need the POV-Ray raytracer to be present. DQS will easily allow you to make such specifications. You can specify times to run, users to receive email notifications when jobs experience status changes, and so on. There is even a small X client called qidle which detects when a user is or is not using their computer (through the X Window System anyway) and will suspend jobs while they are busy. You can require that a computer has a certain amount of RAM, or in fact any combinations of these items, even at the same time. For example, you could request a number of Sun machines running SunOS 5.5 or greater, each with at least 128 MB RAM, and two x86-Linux systems.
According to the DQS home page, a commercial version of DQS known as "Codine" was available from GENIAS Software GmbH which closed its doors on December 31st, 2000. Codine was handed off to Gridware, which company appears to no longer exist but once had a web site at "http://www.gridware.com/".
References:
- DQS-Distributed Queueing System home page(http://www.scri.fsu.edu/~pasko/dqs.html)
- Dennis W. Duke, Thomas P. Green, and Pasko, Joseph L. Research Toward a Heterogeneous Networked Computing Cluster: The Distributed Queuing System Version 3.0. Supercomputer Computations Research Institute,
Florida State University, January 1996. (http://www.scri.fsu.edu/~pasko/dqs/dqs.html)