Re: [Condor-devel] Condor as a vm scheduler

[Matt Hope <Matt.Hope@xxxxxxxxxxxxxxx>]

-----Original Message-----
From: sateesh.potturu@xxxxxxxxx [mailto:sateesh.potturu@xxxxxxxxx] 
>
> Will this serve your purpose?
>  1. NEGOTIATOR_POST_JOB_RANK = "((TotalSlots + 1) * Cpus) + Memory/1024". Until Cpus of a machine that matched first becomes zero or close to zero, all jobs get matched with it
>  2. To address initial placement, you could use Random number suggestion that Matt gave
>
> We use NEGOTIATOR_POST_JOB_RANK to force breadth first scheduling of VM's (opposite of the OpenNebula behavior you mentioned). We over provision VM's a lot in our private cloud and wanted to observe the impact of over provisioning conservatively to tune the over provisioning factor.

> Currently, our NEGOTIATOR_POST_JOB_RANK is "((100 - TotalSlots) + Cpus + CCP_FreeMemoryGB)". Value of TotalSlots indicates number of VM's and it increases as more VM's start on a physical machine. Value of Cpus decreases as more VM's with multiple virtual CPUs start on a physical machine. Physical machines running fewer number of VM's and with more number of CPU cores will get filled first. Because we have equal capacity machines, we see breadth first distribution always; otherwise higher capacity machines would get filled first until available capacity on them matches that of lower capacity machines. So, initially when no VM's are provisioned, physical machines with more capacity get filled first.
>

Is this using dynamic slots?

My understanding was that a partionable slot would only be assigned one dynamic slot per negotiation cycle (which is what can slow down throughput) but that, this throttle tends to allow the collector to get a solid view on what changed on the assigned machine as a result of the job being assigned to it.

If you don't use dynamic slots then the negotiator can assign multiple jobs to an SMP machine in one go and as a result any attempt to distribute by the memory usage, load, etc are doomed to be in correct.

What is needed is to know what values are updated as the negotiation cycle goes along so that statements about requirements/rank for a job can refer to the other slots on the machine and be close to 100% up to date (albeit for a restricted subset of the possible advertised values)

Incidentally how can NEGOTIATOR_POST_JOB_RANK enforce breadth first unless the jobs rank statement is always flat? did you mean NEGOTIATOR_PRE_JOB_RANK?

The last time we tried using NEGOTIATOR_PRE_JOB_RANK it had no effect (I have no idea if this is a bug or some facet of our use of machine RANK for prioritization)

Matt

----
Gloucester Research Limited believes the information provided herein is reliable. While every care has been taken to ensure accuracy, the information is furnished to the recipients with no warranty as to the completeness and accuracy of its contents and on condition that any errors or omissions shall not be made the basis for any claim, demand or cause for action.
The information in this email is intended only for the named recipient.  If you are not the intended recipient please notify us immediately and do not copy, distribute or take action based on this e-mail.
All messages sent to and from this email address will be logged by Gloucester Research Ltd and are subject to archival storage, monitoring, review and disclosure.
Gloucester Research Limited, 5th Floor, Whittington House, 19-30 Alfred Place, London WC1E 7EA.
Gloucester Research Limited is a company registered in England and Wales with company number 04267560.
----