[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] Implications of using GCB on Windows submit nodes
- Date: Thu, 16 Aug 2007 11:03:45 -0500
- From: Dan Bradley <dan@xxxxxxxxxxxx>
- Subject: Re: [Condor-users] Implications of using GCB on Windows submit nodes
Antonio García wrote:
I've read the manual and it says that all Linux releases are linked
with GCB. I suppose that is not the case for Windows, then? Assuming
that it is the case, then, as the "How GCB works" webpage says,
Windows Condor nodes would only be able to connect to private Condor
nodes behind a GCB broker if they were in a public network, right?
That would be the legacy-private scenario, I assume.
Yes, the submit and execute nodes require bidirectional connectivity,
and there is no GCB client for Condor in Windows, so your Windows nodes
would need to be directly accessible to the private nodes, whereas the
private (Linux) nodes could be accessible through a GCB broker.
Do you think Condor-C would be more suited to the single Windows
submit client and Condor pool in separate private networks scenario? I
have read a tutorial where they propose installing Condor-C on the
edge of the private network, for example.
Yes, Condor-C may be more suitable, but keep in mind that it has some
basic functional differences from flocking. In flocking, matchmaking
happens between your jobs and the machines in one or more pools. In
Condor-C, you either directly configure which pool each job will go to,
or you use matchmaking to pick a pool. Either way, matchmaking between
your job and the machines doesn't happen until after the job has been
sent to the destination schedd in the pool that was selected. In other
words, if a sub-optimal decision is made about which pool to send the
job to, it is possible for the job to sit idle in the remote queue at
pool B while there are available machines waiting in pool C. This makes
life more complicated than in the simple flocking case.