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

[Condor-users] Efficiently using a inhomogeneous cluster

I'm planning to enhance part of the Condor pool by adding memory modules
to about 1/4 of the nodes, in particular since there are applications which
need more memory per process.
The same - in the short run - could of course be achieved by reducing the
number of VMs (these are dual-core machines), but the problem basically
is the same:
How do I keep other users away from the "better" nodes?

Say I've got 100 (virtual or not, doesn't matter) machines, 20 of them 
with larger memory resources.
Users A and B don't care because their app's memory footprint is quite
beyond the amount available. They care about CPU power though.
User C depends on big memory. CPU power isn't too important, but memory
is crucial.

Is it possible to prefer low-memory machines in negotiation in a global
way (so I don't have to depend on the cooperation of users A and B to
include some Requirement or Rank in their submit files - they will rank
by Mips or Kflops though), unless overwritten by specific Requirements 
(of user C who will have a memory Requirement in his submit file)?
In prose, "hand out the weakest (concerning the attribute the user didn't
specify) machine first even if there are others with close specs on the
attributes the user *did* specify".
Which is a bit tricky since Kflops and Mips are always slightly different,
and by accident the big-memory box might be a bit faster than a low-mem
one... sounds a bit like fuzzy logic...
(If it's possible to bias the user's specification by a globally defined
additional term, making the visible Mips/Kflops value less attractive,
that would be very helpful.)

Any ideas, suggestions?


Steffen Grunewald * MPI Grav.Phys.(AEI) * Am Mühlenberg 1, D-14476 Potsdam
Cluster Admin * http://pandora.aei.mpg.de/merlin/ * http://www.aei.mpg.de/
* e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7233,fax:7298}
No Word/PPT mails - http://www.gnu.org/philosophy/no-word-attachments.html