Re: What's the difference between openmosix and PBS system?

Deadpan110 <[email protected]> Wed, 19 Jul 2006 11:10:21 +0100
Newsgroups gmane.linux.cluster.openmosix.general
Message-ID <[email protected]>
Hiya,

To add to Andreas Schäfer's comments:

By using the openMosix kernel along side other clustering apps, a more
generalised beowulf style cluster can be built to cater for all types of
use.

I have used PBS and found it tricky to set up jobs to run quickly across
nodes but that would NOT mean that you cannot use PBS along side openMosix.

If a job you schedule for a particular node is openMosix firiendly, then
openMosix could cause that particular job to migrate on to a faster free
node and if your particular job spawns sub processes that are openMosix
friendly, then each one of those processes could infact migrate in order to
get 100% CPU usage from all the openMosix nodes in your network.

ie
PBS spawns 10 openMosix friendly processes for 1 node on the network,
openMosix would migrate each of those processes to a different node.
If one node is then used for something else, then openMosix could migrate
the process again to find the maximum CPU use for that process.
Without openMosix, PBS would only allow you to set the same 10 processes to
run across 10 nodes and stay where they run.

Quote from Andreas Schäfer:
So, oM is, despite some limitations, way more elegant. Give it a try.

*Yes, and use it along side PBS and other clustering apps.*

I also use DSH from within cron...
My cron scheduler runs on a designated master node, jobs are set using
crontab -e from any node and DSH is used to run them.

eg:

0 * * * * dsh -c -m 192.168.1.20 -m 192.168.1.21 /home/mydir/myscript.sh
Would cause the script 'myscript.sh' to run hourly on nodes 192.168.1.20 and
21 concurrently.
(please note that /home and /var/spool/cron/ are available from NFS )
If myscript.sh contains oM friendly processes, then those too will migrate
across the network to other nodes.


Martin



On 19/07/06, Andreas Schäfer <[email protected]> wrote:
>
> On 09:27 Wed 19 Jul     , ???? wrote:
> >     Openmosix makes a cluster into a logical SMP machine so that
> >     users can submit job easily and the job control, resource
> >     scheduling will be handled by openmosix but, this is exactly the
> >     same thing PBS system covers. I mean, if I install an openpbs on
> >     my cluster, I can also submit my serial/parallel job
> >     smoothly. So why should I use openmosix?
>
> While having similar aims, the way batch systems like the grid engine
> achieve them is quite different from the openMosix approach. Roughly
> speaking, batch systems start jobs on free nodes by "ssh-ing" to the
> given node (or do something a bit more clever but still somehow
> equivalent). This is also the reason why they have bring their own job
> management tools (e.g. qstat, qsub etc.) -- jobs just have to be
> processes on your local node. This does also limit the kind of jobs
> you can use with batch systems, as they're usually unable to execute
> interactive or X applications.
>
> Contrary to that, openMosix engages in a much lower level. It is a
> kernel patch that allows processes running locally on a node to be
> transmitted to another node transparently during runtime. The last
> part is quite important, as it has some interesting consequences:
>
> * If there is a load inequality among the cluster nodes, it can be
>    equalized much smoother by simply migrating some jobs to the idling
>    machines within seconds. Batch systems can only equalize load by
>    starting new jobs which isn't as elegant and, more important, will
>    fail if the queue is empty.
>
> * You don't have to use special job management tools, as openMosix
>    can migrated nearly every process on your node (ok, there are some
>    limitations: no multithreading, no shared memory, but for oM's use
>    case this is a weak limitation).
>
> * oM does also work with interactive and X applications. For instance
>    if you have a graphical fractal generator which is creating high
>    load on your login machine, oM could easily migrate it to an idling
>    machine without you noticing it.
>
> So, oM is, despite some limitations, way more elegant. Give it a try.
>
> Cheers!
> -Andreas
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> openMosix-general mailing list
> openMosix-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/openmosix-general
>
>
>
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
openMosix-general mailing list
openMosix-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/openmosix-general