Hi,
> -----Original Message-----
> From: Testbed Support for GridPP member institutes
> [mailto:[log in to unmask]] On Behalf Of Burke, S (Stephen)
> Sent: 05 July 2007 15:41
> To: [log in to unmask]
> Subject: Re: Torque/Info System Questions
>
> Testbed Support for GridPP member institutes
> > [mailto:[log in to unmask]] On Behalf Of Brew, CAJ (Chris)
> said:
> > 1) Do we still need per VO queues?
>
> I could argue that you never did need per VO queues :) However, the
> general point is that voviews are only understood by the glite WMS. In
> theory the RB is likely to be phased out Real Soon Now so
> that shouldn't
> be a problem ... also the effect is only that scheduling is
> non-optimal,
> e.g. a VO may see a large ERT for a multi-VO queue when its jobs would
> actually start quickly because it's currently under its fairshare
> target.
Hmmm, that's possibly non-optimal. The other option I'd come up with was
to use the same queues and hack whatever does the "qsub" to add --l
nodes=sl[34]-prod to get the right resource request. Is that feasable,
does anyone know what I'd have to hack?
> > 2) Is there any reason not to leave the second CE in place
> long term -
> > it would be useful for load balacing and upgrades to have two Ces
> > feeding jobs to the same queues but would it lead to double
> > counting of resources?
>
> It does lead to double-counting e.g. in gstat, but that possibly isn't
> too serious. Also there is no explicit load-balancing as such, brokers
> will just treat them as independent so the outcome will depend on
> exactly what gets published (e.g. are you running the info providers
> once or twice?) and what ranking algorithm is used - although brokers
> randomise if the ranks are equal which helps. One thing, make sure you
> have a shared pool account mapping!
Good Point! I'd not thought of that but just nfs mounting
/etc/grid-security/gridmapdir/ does that does it not?
Thanks,
Chris.
|