[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] Condor on multiple network interfaces



I am still running into this problem, where the submit and execute nodes are matched but the job does not start (when the execute node is on the private network).  I have configured GCB exactly as described in the networking section of the manual, and seems to be working correctly.

Now, the manual mentions that the private nodes should advertise themselves as all having the IP address of the broker, but on unique ports.  Looking at the IP addresses of the pool (condor_status -l | grep StartdIp), the private nodes still are showing "StartIpAddr" as the address on the private network, instead of the broker's address.  Could this be the problem?  If so how can I correct this?

Also, the Condor pool is almost exclusively Win. XP, should GCB have a problem with this?

-Nicholas


On 7/19/07, Dan Bradley < dan@xxxxxxxxxxxx> wrote:

Condor requires bidirectional connectivity between the submit node and
the execute node.  In other words, Condor must be able to open up
network connections to the execute machine from the submit machine and
also to the submit machine from the execute machine.

If connections can only be made in one direction in your network ( e.g.
from private to public), then you can configure condor to use GCB to
broker connections in the reverse direction.  There's a section in the
manual about that:

http://www.cs.wisc.edu/condor/manual/v6.8/3_7Networking.html#SECTION00473000000000000000

--Dan

Nicholas Lavigne wrote:

> Thanks for the reply.  I now have all of the machines appearing in the
> pool (as reported by condor_status) but I have a new problem.  I
> *think* I understand the problem, but as of yet the solution is
> evading me....
>
> Our network is mostly Windows and so the vanilla universe is my
> primary concern.  Now, submitting a job from the public network, the
> central manager is able to match the job to a machine on the private
> network, but the job does not run, presumably because Condor's file
> transfer mechanism does not know how to transfer the file from the
> public network to the private network.
>
> I know that other pools are using a similar type of setup and so there
> must be a solution to this problem.  I am not currently using a
> network file system, could this be the answer?
>
> -Nicholas
>
>
> On 7/18/07, *Tomas Grigera* <tgrigera@xxxxxxxxxxxxxxxxxx
> <mailto: tgrigera@xxxxxxxxxxxxxxxxxx>> wrote:
>
>     Hi,
>
>     I use a similar setup. I have
>
>     BIND_ALL_INTERFACES = TRUE
>
>
>     But you must make sure the server name resolves to the public IP also
>     for the internal machines.
>
>     Tomas
>
>     On 7/17/07, Nicholas Lavigne < condor.list@xxxxxxxxxxxxxx
>     <mailto:condor.list@xxxxxxxxxxxxxx>> wrote:
>     > Due to a shortage of allocated IP addresses on our university's
>     network, we
>     > have decided to use the central manager machine (running Debian)
>     as a
>     > gateway with two network interfaces and place some compute nodes
>     on a
>     > sub-network behind it.  The router is doing its job correctly,
>     but the
>     > machines on the subnet do not seem to appear in the Condor pool.
>     >
>     > Are there any general rules for having Condor listen on two network
>     > interfaces?  Maybe some modification to the HOSTALLOW_READ and
>     > HOSTALLOW_WRITE variables on the central manager?  Currently,
>     >
>     > HOSTALLOW_READ = *
>     > HOSTALLOW_WRITE = 134.95.*
>     >
>     > But I would like Condor to listen on the 192.168.10.* subnet as
>     well.
>     >
>     > Any suggestions?
>     >
>     >
>     > Thanks,
>     > Nicholas Lavigne
>     > University of Cologne
>     > Graduiertenkolleg Risikomanagement
>     >
>     >
>     > _______________________________________________
>     > Condor-users mailing list
>     > To unsubscribe, send a message to
>     > condor-users-request@xxxxxxxxxxx
>     <mailto: condor-users-request@xxxxxxxxxxx> with a
>     > subject: Unsubscribe
>     > You can also unsubscribe by visiting
>     > https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>     >
>     > The archives can be found at:
>     > https://lists.cs.wisc.edu/archive/condor-users/
>     >
>     >
>     _______________________________________________
>     Condor-users mailing list
>     To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx
>     <mailto:condor-users-request@xxxxxxxxxxx> with a
>     subject: Unsubscribe
>     You can also unsubscribe by visiting
>     https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>
>     The archives can be found at:
>     https://lists.cs.wisc.edu/archive/condor-users/
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Condor-users mailing list
>To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
>subject: Unsubscribe
>You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>
>The archives can be found at:
>https://lists.cs.wisc.edu/archive/condor-users/
>
>
_______________________________________________
Condor-users mailing list
To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/condor-users

The archives can be found at:
https://lists.cs.wisc.edu/archive/condor-users/