You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@vcl.apache.org by Josh Thompson <jo...@ncsu.edu> on 2013/02/18 16:31:04 UTC
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-----
Re: thoughts on reversing computer selection relative to RAM
Posted by Mark Gardner <mk...@vt.edu>.
+1
Generally people have in mind the efficient use of resources when they
think of virtualization. Thus I would be in favor of sorting in
ascending order as that will approximate best fit and hence give
better resource utilization.
Mark
On Mon, Feb 18, 2013 at 10:55 AM, Aaron Coburn <ac...@amherst.edu> wrote:
> +1
>
> I also like this idea. Making this a configurable option makes sense -- it would be nice to have the default set to ascending order as you describe.
>
> Aaron C
>
>
> On Feb 18, 2013, at 10:42 AM, Aaron Peeler <fa...@ncsu.edu>
> wrote:
>
>> I would like this ability, it would definitely simplify the mappings.
>>
>> I think it should be applied to both # or procs. and memory.
>>
>> I'm fine with either approach to just reserve it so it matches the min
>> valus or to have an option to choose which method.
>>
>> Aaron
>>
>> On Mon, Feb 18, 2013 at 10:31 AM, Josh Thompson <jo...@ncsu.edu> wrote:
>>> -----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-----
>>>
>>
>>
>>
>> --
>> Aaron Peeler
>> Program Manager
>> Virtual Computing Lab
>> NC State University
>>
>> 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.
>
--
Mark Gardner
--
Re: thoughts on reversing computer selection relative to RAM
Posted by Mark Gardner <mk...@vt.edu>.
+1
Generally people have in mind the efficient use of resources when they
think of virtualization. Thus I would be in favor of sorting in
ascending order as that will approximate best fit and hence give
better resource utilization.
Mark
On Mon, Feb 18, 2013 at 10:55 AM, Aaron Coburn <ac...@amherst.edu> wrote:
> +1
>
> I also like this idea. Making this a configurable option makes sense -- it would be nice to have the default set to ascending order as you describe.
>
> Aaron C
>
>
> On Feb 18, 2013, at 10:42 AM, Aaron Peeler <fa...@ncsu.edu>
> wrote:
>
>> I would like this ability, it would definitely simplify the mappings.
>>
>> I think it should be applied to both # or procs. and memory.
>>
>> I'm fine with either approach to just reserve it so it matches the min
>> valus or to have an option to choose which method.
>>
>> Aaron
>>
>> On Mon, Feb 18, 2013 at 10:31 AM, Josh Thompson <jo...@ncsu.edu> wrote:
>>> -----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-----
>>>
>>
>>
>>
>> --
>> Aaron Peeler
>> Program Manager
>> Virtual Computing Lab
>> NC State University
>>
>> 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.
>
--
Mark Gardner
--
Re: thoughts on reversing computer selection relative to RAM
Posted by Aaron Coburn <ac...@amherst.edu>.
+1
I also like this idea. Making this a configurable option makes sense -- it would be nice to have the default set to ascending order as you describe.
Aaron C
On Feb 18, 2013, at 10:42 AM, Aaron Peeler <fa...@ncsu.edu>
wrote:
> I would like this ability, it would definitely simplify the mappings.
>
> I think it should be applied to both # or procs. and memory.
>
> I'm fine with either approach to just reserve it so it matches the min
> valus or to have an option to choose which method.
>
> Aaron
>
> On Mon, Feb 18, 2013 at 10:31 AM, Josh Thompson <jo...@ncsu.edu> wrote:
>> -----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-----
>>
>
>
>
> --
> Aaron Peeler
> Program Manager
> Virtual Computing Lab
> NC State University
>
> 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.
Re: thoughts on reversing computer selection relative to RAM
Posted by Aaron Coburn <ac...@amherst.edu>.
+1
I also like this idea. Making this a configurable option makes sense -- it would be nice to have the default set to ascending order as you describe.
Aaron C
On Feb 18, 2013, at 10:42 AM, Aaron Peeler <fa...@ncsu.edu>
wrote:
> I would like this ability, it would definitely simplify the mappings.
>
> I think it should be applied to both # or procs. and memory.
>
> I'm fine with either approach to just reserve it so it matches the min
> valus or to have an option to choose which method.
>
> Aaron
>
> On Mon, Feb 18, 2013 at 10:31 AM, Josh Thompson <jo...@ncsu.edu> wrote:
>> -----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-----
>>
>
>
>
> --
> Aaron Peeler
> Program Manager
> Virtual Computing Lab
> NC State University
>
> 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.
Re: thoughts on reversing computer selection relative to RAM
Posted by Aaron Peeler <fa...@ncsu.edu>.
I would like this ability, it would definitely simplify the mappings.
I think it should be applied to both # or procs. and memory.
I'm fine with either approach to just reserve it so it matches the min
valus or to have an option to choose which method.
Aaron
On Mon, Feb 18, 2013 at 10:31 AM, Josh Thompson <jo...@ncsu.edu> wrote:
> -----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-----
>
--
Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University
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.
RE: thoughts on reversing computer selection relative to RAM
Posted by Yannick Charbonneau <yc...@uottawa.ca>.
I was wondering why our "small" images were ending up on "big" vms.
+1 for changing the order
Yanik
-----Original Message-----
From: Aaron Peeler [mailto:aaron_peeler@ncsu.edu]
Sent: Tuesday, February 19, 2013 10:42 AM
To: user@vcl.apache.org
Cc: dev@vcl.apache.org
Subject: Re: thoughts on reversing computer selection relative to RAM
Also like to add that it should be more efficient use of the computers that have higher memory and cpu settings, in that they won't get assigned first light weight images.
Aaron
On Tue, Feb 19, 2013 at 9:24 AM, Josh Thompson <jo...@ncsu.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dmitri,
>
> Actually, it will affect both. The VMs would still only be created
> with the specs listed for the image. However, if you have some VMs
> configured to be "beefier" than others, you end up with a similar
> situation where you don't want lighter weight images to end up running
> on those VMs. So, I think it would still be helpful for virtual-only
> environments, and I don't think it would have a negative impact on them.
>
> Josh
>
> On Monday, February 18, 2013 9:16:47 PM Dmitri Chebotarov wrote:
>> 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 <jo...@ncsu.edu>
>> 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-----
> - --
> - -------------------------------
> 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)
>
> iEYEARECAAYFAlEjiwwACgkQV/LQcNdtPQOfDQCfS4yLCYcwTrUAEL8whb0/fwJI
> pq4An3gGoBH05e6v9kSy2gFnX9IBhv2A
> =UAki
> -----END PGP SIGNATURE-----
>
--
Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University
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.
Re: thoughts on reversing computer selection relative to RAM
Posted by Aaron Peeler <aa...@ncsu.edu>.
Also like to add that it should be more efficient use of the computers
that have higher memory and cpu settings, in that they won't get
assigned first light weight images.
Aaron
On Tue, Feb 19, 2013 at 9:24 AM, Josh Thompson <jo...@ncsu.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dmitri,
>
> Actually, it will affect both. The VMs would still only be created with the
> specs listed for the image. However, if you have some VMs configured to be
> "beefier" than others, you end up with a similar situation where you don't
> want lighter weight images to end up running on those VMs. So, I think it
> would still be helpful for virtual-only environments, and I don't think it
> would have a negative impact on them.
>
> Josh
>
> On Monday, February 18, 2013 9:16:47 PM Dmitri Chebotarov wrote:
>> 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 <jo...@ncsu.edu>
>> 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-----
> - --
> - -------------------------------
> 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)
>
> iEYEARECAAYFAlEjiwwACgkQV/LQcNdtPQOfDQCfS4yLCYcwTrUAEL8whb0/fwJI
> pq4An3gGoBH05e6v9kSy2gFnX9IBhv2A
> =UAki
> -----END PGP SIGNATURE-----
>
--
Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University
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.
Re: thoughts on reversing computer selection relative to RAM
Posted by Aaron Peeler <aa...@ncsu.edu>.
Also like to add that it should be more efficient use of the computers
that have higher memory and cpu settings, in that they won't get
assigned first light weight images.
Aaron
On Tue, Feb 19, 2013 at 9:24 AM, Josh Thompson <jo...@ncsu.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dmitri,
>
> Actually, it will affect both. The VMs would still only be created with the
> specs listed for the image. However, if you have some VMs configured to be
> "beefier" than others, you end up with a similar situation where you don't
> want lighter weight images to end up running on those VMs. So, I think it
> would still be helpful for virtual-only environments, and I don't think it
> would have a negative impact on them.
>
> Josh
>
> On Monday, February 18, 2013 9:16:47 PM Dmitri Chebotarov wrote:
>> 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 <jo...@ncsu.edu>
>> 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-----
> - --
> - -------------------------------
> 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)
>
> iEYEARECAAYFAlEjiwwACgkQV/LQcNdtPQOfDQCfS4yLCYcwTrUAEL8whb0/fwJI
> pq4An3gGoBH05e6v9kSy2gFnX9IBhv2A
> =UAki
> -----END PGP SIGNATURE-----
>
--
Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University
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.
Re: thoughts on reversing computer selection relative to RAM
Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dmitri,
Actually, it will affect both. The VMs would still only be created with the
specs listed for the image. However, if you have some VMs configured to be
"beefier" than others, you end up with a similar situation where you don't
want lighter weight images to end up running on those VMs. So, I think it
would still be helpful for virtual-only environments, and I don't think it
would have a negative impact on them.
Josh
On Monday, February 18, 2013 9:16:47 PM Dmitri Chebotarov wrote:
> 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 <jo...@ncsu.edu>
> 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-----
- --
- -------------------------------
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)
iEYEARECAAYFAlEjiwwACgkQV/LQcNdtPQOfDQCfS4yLCYcwTrUAEL8whb0/fwJI
pq4An3gGoBH05e6v9kSy2gFnX9IBhv2A
=UAki
-----END PGP SIGNATURE-----
Re: thoughts on reversing computer selection relative to RAM
Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dmitri,
Actually, it will affect both. The VMs would still only be created with the
specs listed for the image. However, if you have some VMs configured to be
"beefier" than others, you end up with a similar situation where you don't
want lighter weight images to end up running on those VMs. So, I think it
would still be helpful for virtual-only environments, and I don't think it
would have a negative impact on them.
Josh
On Monday, February 18, 2013 9:16:47 PM Dmitri Chebotarov wrote:
> 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 <jo...@ncsu.edu>
> 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-----
- --
- -------------------------------
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)
iEYEARECAAYFAlEjiwwACgkQV/LQcNdtPQOfDQCfS4yLCYcwTrUAEL8whb0/fwJI
pq4An3gGoBH05e6v9kSy2gFnX9IBhv2A
=UAki
-----END PGP SIGNATURE-----
Re: thoughts on reversing computer selection relative to RAM
Posted by Dmitri Chebotarov <dc...@gmu.edu>.
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 <jo...@ncsu.edu>
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-----
>
>
Re: thoughts on reversing computer selection relative to RAM
Posted by Aaron Peeler <fa...@ncsu.edu>.
I would like this ability, it would definitely simplify the mappings.
I think it should be applied to both # or procs. and memory.
I'm fine with either approach to just reserve it so it matches the min
valus or to have an option to choose which method.
Aaron
On Mon, Feb 18, 2013 at 10:31 AM, Josh Thompson <jo...@ncsu.edu> wrote:
> -----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-----
>
--
Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University
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.
Re: thoughts on reversing computer selection relative to RAM
Posted by Dmitri Chebotarov <dc...@gmu.edu>.
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 <jo...@ncsu.edu>
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-----
>
>