[GE users] clusters on a subnet

Craig Tierney ctierney at hypermall.net
Wed Apr 12 17:42:02 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:
> Hi everyone,
> 
>     I've been using 5.3p6 for over a year now with great results. I seem 
> to learn something new everyday though :)
> 
>     In house we recently got 2 new Linux clusters and they were put on a 
> subnet so that the qmaster can not directly rsh to each of the 64 nodes. 
> You must first log into a mgmt node for that cluster and then you can 
> rsh to all the nodes. All of the compute nodes have non-routable ip 
> addresses (because we were all out of ip addresses...).
> 
>     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.
> 
>     Has anyone run across this before? Are we better off finally making 
> the leap to 6.0 (maybe this is a non-issue for 6.0, I read that port 536 
> is not used for commd in 6.0? how does it communicate then?)
> 
>     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.
> 

Are your compute nodes on private subnets or public subnets relative to
the rest of the department or organization?  I think you are best off
renumbering the nodes.   If you want one qmaster for all of the 
clusters, transfer queues seem to be a bit overkill.

You could add additional ethernet interfaces to the qmaster and connect
them directly to the new subnets.  However, I don't know if this is
how you want to run the system.  Without more information about the
network architecture as well as how users access the systems and is
there a single /home filesystem for all clusters, it is hard to see
another solution.

Craig



> Thanks for any tips or advice,
> 
> Mark
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
> For additional commands, e-mail: users-help at gridengine.sunsource.net
> 

---------------------------------------------------------------------
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 mailing list