[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-devel] Condor as a vm scheduler
Matt Hope,
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.
Regards,
Sateesh
-----Original Message-----
From: condor-devel-bounces@xxxxxxxxxxx [mailto:condor-devel-bounces@xxxxxxxxxxx] On Behalf Of Matt Hope
Sent: Tuesday, January 12, 2010 11:37 PM
To: 'Matthew Farrellee'
Cc: condor-devel@xxxxxxxxxxx
Subject: Re: [Condor-devel] Condor as a vm scheduler
Unfortunately that will not work well from an initially empty state on SMP machines.
This is increasingly a problem with how the scheduler works (and the solutions can have a significant throughput impact as the dynamic partitioning on hefty boxes like Mag Gam's show)
Personally I think this is something that needs some serious thought and attention in the design of the scheduler.
How this works in a general sense is hard I know certain attributes can be updated on the fly, others (like LoadAvg) cannot but perhaps that means that those values which will prevent high throughput negotiation with consistent state should be marked as such and avoided (or if it's easier mark the ones that can be maintained).
If we moved to a dynamic model I may well decide to just use job hooks if they are stable enough and entirely bypass the scheduler since I can then control the performance characteristics and make use of internally calculated state rather than relying on state in the collector to 'catch up' with state that should be available (since it was decided just a moment ago in the same process).
Matt
-----Original Message-----
From: condor-devel-bounces@xxxxxxxxxxx [mailto:condor-devel-bounces@xxxxxxxxxxx] On Behalf Of Matthew Farrellee
Sent: 12 January 2010 17:58
To: Stanislav Ievlev
Cc: condor-devel@xxxxxxxxxxx
Subject: Re: [Condor-devel] Condor as a vm scheduler
On 01/12/2010 02:15 AM, Stanislav Ievlev wrote:
> Greetings!
>
> With vm universe I can use Condor as a scheduler for virtual machines.
>
> Does the condor use a one generic scheduling algorithm for all types
> of universe?
>
> For example, OpenNebula's scheduler try to pack the VMs in the cluster
> nodes to reduce VM fragmentation
> http://www.opennebula.org/doku.php?id=documentation:rel1.4:schg).
>
> Can I have a same functionality with a Condor?
>
> --
> With best regards
> Stanislav Ievlev.
Condor's scheduling algorithm is flexible enough to enable things like packing, without having to swap out the algorithm itself.
For instance, packing is just a preference to match against machines that already have running VMs. In Condor, you can do this with the RANK expressions.
http://condor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToSteerJobs
Best,
matt
_______________________________________________
Condor-devel mailing list
Condor-devel@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
----
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.
----
_______________________________________________
Condor-devel mailing list
Condor-devel@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
