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

Re: [Condor-users] Implications of using GCB on Windows submit nodes

Antonio García wrote:

Hello all,

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.