| openMosix , Past Present and Future | ||
|---|---|---|
| <<< Previous | Next >>> | |
First we will look at "running parallel applications" and then we will tell you how running sequential applications will take advantage on an openMosix cluster.
A parallel application , consists of more than one process , starts processes on every cluster-nodes and uses its uses own communication mechanism
To give the program-developers a helping hand there are lots of different parallel libraries that care e.g. about initializing the cluster, starting processes, inter-process communication etc. Two widely used libraries are used for this PVM and MPI. Let's look how openMosix optimizes applications created with those libraries
PVM, in full words : parallel virtual machine Is a software which connects a number of networked systems as a parallel virtual machine. Typically those clusters and their PVM-applications are master-slave based. The "main" program is started on the master which starts a bunch of worker-tasks on the remote nodes by the rsh or ssh protocol as configured.
PVM has a master/slave concept of applications it has a static load/process assignment by PVM
By having dynamic load-balancing done by openMosix we minimize the configuration needs for PVM
Generally a PVM application running "natively" in the above described way on and openMosix cluster takes additional advantages of the dynamic load-balancing PVM tasks are distributed to the worker-nodes by the PVM-cluster init + spawn function (spawn is a kind of remote-fork) openMosix balances this statically assigned task during runtime to optimize the performance.
openMosix can also minimize the PVM-cluster configuration requirements to exactly one node the master node. To archive this goal the PVM cluster and application is just installed and configured on one node in the openMosix cluster. The result is a single node PVM cluster within a multi-node openMosix cluster. PVM spawns its tasks just on the PVM-master node and openMosix takes care of the full load + computing distribution and load-balancing. In this scenario PVM is just used to parallelize the application. By using the PVM library-functions the "problem to solve" is splitted into multiple sub-tasks which are then balanced by the openMosix single system cluster.
All yet used PVM applications are taking advantages by running on openMosix. PVM and openMosix are "good friends" and PVM is quite easy to learn. If PVM is used as a single-node PVM cluster within and openMosix cluster there is no additional configuration requirements at all, most of the times PVM is even pre-installed + configured by default.
To give some examples of programs using PVM :
octave, a high-level language, primarily intended for numerical computations
pvm gmake, a distributed gnu make
pvm-povray, a parallel povray renderer
parallel lil-gp, a parallel version of the genetic programming kernel "Lil-gp"
MPI is a standard for parallel computing and stands for "message passing interface". There are two main-stream implementations of MPI which are LAM, (Local Area Multicomputer) and MPICH, a freely available, portable implementation of MPI, the Standard for message-passing libraries.
Both MPI implementations are using the same MPI so that MPI programs are usually compileable + runnable on LAM and MPICH.
There are also other MPI implementations available with additional or enhanced functionality which are not further explained here.
The concept of the master-slave programming model is similar to that of PVM. MPI provides a lot specialized functions for passing messages from task to tasks, or better from processes to processes like for example broadcast, reduce, gather,
A common execution model of MPI is MPSD, multiple program single data. It means that the same program is running on multiple processors which are MPI cluster-nodes. The program task running on each node synchronizing variables and exchanging data by e.g. broadcasting + gathering. Each program task computes a part of the data and the sub-results are being combined afterwards.
Basically MPI and openMosix are friends and MPI applications are benefiting from the dynamic load-balancing on openMosix. MPI is just very aggressive in using the network-connections between the MPI-tasks to exchange data. Often MPI applications requiring synchronization of all running tasks which can soon become a bottleneck in the cluster -> this is a well know limitations of master-slave-based clustering-concepts. In this scenario having the MPI task migrated by openMosix on remote nodes other than their MPI-home-node will cause an additional network-utilization which won't be a benefit for the MPI application.
Please notice that this is NOT an openMosix limitation but a that of some "fancy programmed" MPI-application. In most cases those bottle-necks can be solved by increasing the network speed, bandwidth and latency. Also having enough memory on all nodes (including swap) is a serious issue since the MPI-program footstamp in the nodes memory can be quite big dependent on the application and data to compute.
the openMosix patch for MPICH For the MPICH implementation there is a small patch available which exchanges the use of "rsh/ssh" by "mosrun". This has the great advantage to reduce the overhead of the remote execution calls. The MPICH processes won't be spreaded to the remote nodes by rsh/ssh but starting as "local" but directly migrated to a remote node by the mosrun util.
Even pure sequential/regular applications take advantages by running them on the openMosix platform. Those regular application task are performing computation on a data-section. To archive parallelization one has to think of how the "problem to solve by the application" can be divided into sub-tasks, or better sub-problem-solvers. In most cases this can be done by simply splitting the data to compute into several parts and run multiple instances of the program on each data-part.
This is known as MPMD, multiple program multiple data.
To ease up starting of those sub-tasks to gain parallelization the openMosix API provides functions and examples e.g. for dynamically process creation according the number of nodes We can now have a small wrapper script to start the sequential application which e.g. finds out how many nodes are available, then splits the data according the number of nodes and forks a sub-task on each part automatically.
some sequential application examples are : seti -> seti@home openMosix group , povray, number-cruncher applications, password cracker, mp3 converter, shell scripts, compiling, mostly anything ;)
Also users can benefit from openMosix if their workstation is part of the cluster. Every user can simply start his computation tasks and openMosix will balance all tasks on the whole cluster. Using the loadlimit feature each user or the administrator can decide how many resources each single workstation should "spend" to the cluster.
| <<< Previous | Home | Next >>> |
| Checkpointing with openMosix + chpox | openMosixView |