[GE users] clusters on a subnet
John.Marshall at ec.gc.ca
Wed Apr 12 18:21:18 BST 2006
[ The following text is in the "ISO-8859-1" character set. ]
[ Your display is set for the "ISO-8859-10" character set. ]
[ Some special characters may be displayed incorrectly. ]
Mark Casella wrote:
> I read about transfer queues, but this doesn't seem to be exactly
> what I need, I would like ideally to just have the qmaster communicate
> to the execd's through the mgmt node. Also I would prefer to just have
> one qmaster to centralize all the accounting and usage info.
> If the simplest option is to just obtain more ip addresses for all
> the compute nodes, that's fine, I just wanted to check here first.
I gather you would prefer to have one big "cell"
containing your current SGE machines and the two
clusters. But, there are benefits to having
One thing that my organization has done is to
actually support separate cells in order to
allow management of each cell independently:
- system/down time on one cell does _not_
impact the others. This is very important
in an operational environment which makes
reconfiguration of a vital cell undesirable.
- allow different cell configurations including
different managers/operators. This may be an
issue when the equipment is owned by different
groups each with different priorities and
- support frontend-backend type network
arrangement for security and operational
purposes. On large clusters, it is sometimes
imperative to restrict network I/O to the
To allow access to the available cells we route
the jobs as required using SGE special router
queues. We also support non-SGE queuing systems
(e.g., LoadLeveler) using routing.
You may not need any of these things, though. And,
you may not want to use multiple cells if you want
scheduling to consider all your machines and be
handled by one qmaster.
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net
More information about the gridengine-users