Hi 

Sounds like this change will affect environments which offer bare-metal 
reservations. 

For virtual-only environments it will be the same since reservation is created 
based on resources listed in the image properties.  

Does it sound right?

Thanks.



----- Original Message -----
From: Josh Thompson <[email protected]>
Date: Monday, February 18, 2013 10:31 am
Subject: thoughts on reversing computer selection relative to RAM

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> I'd like to get people's thoughts about reversing how computers 
> are assigned 
> for reservations relative to the specified amount of RAM for an 
> image.  
> Currently, the scheduler builds a list of computers that can 
> fulfill a given 
> reservation and orders them by specs of the machine by this priority:
> 
> first by procspeed * proc number
> next by amount of RAM,
> finally by network speed
> 
> Each of those is ordered in a descending order (i.e. best specs at 
> the top).  
> Then, the highest rated machine is given to the user.
> 
> That algorithm came from our initial design back in 2004 when our 
> nodes didn't 
> have lots of RAM, didn't have a high variability of contained RAM, 
> didn't have 
> more RAM that some of the OSes could handle, and we weren't doing 
> any 
> virtualization.  The idea was that the user would get the best 
> available 
> machine for the reservation.
> 
> Now, with nodes having very high amounts of RAM, a high 
> variability of 
> contained RAM, and having WinXP images that can't even use more 
> than 4 GB of 
> RAM, I'm wondering if ordering for RAM (and maybe all specs) 
> should be 
> reversed.  This would make it so that priority is given to assign 
> a node that 
> just meets the specs for the image rather than assigning the best 
> one 
> available.  We're running in to cases where we have some bare 
> metal nodes with 
> 24 GB or more of RAM, but still have WinXP images available to 
> users.  We have 
> to map things so that the WinXP images cannot get deployed to the 
> higher RAM 
> nodes to keep from wasting the RAM when other users would like to 
> have it.  
> Things would be simplified if we could just have a more general 
> pool and have 
> the scheduler take care of keeping resources from being wasted.
> 
> What do others think?  I could also make it an option in conf.php 
> as to which 
> method is used.  However, unless people feel it useful to keep the 
> current 
> method, it would be simpler to just reverse the ordering.  Also, 
> if you think 
> it is a good idea to reverse it, should all specs be reversed, or 
> just RAM?
> 
> Thanks,
> Josh
> - -- 
> - -------------------------------
> Josh Thompson
> VCL Developer
> North Carolina State University
> 
> my GPG/PGP key can be found at pgp.mit.edu
> 
> All electronic mail messages in connection with State business which
> are sent to or received by this account are subject to the NC Public
> Records Law and may be disclosed to third parties.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> 
> iEYEARECAAYFAlEiSTwACgkQV/LQcNdtPQN3qQCeLaxbUg9Rh6F4mpQrcn1mh5jz
> VSEAn2C35CQCIqLnRUJFansQ5zKIhlNa
> =KVAL
> -----END PGP SIGNATURE-----
> 
> 

Reply via email to