Another suggestion.

Can you look at staggering the reload start times based on the load of the management node?


A problem that currently exist on the backend method is that the block allocation process inserts multiple reloads at a time, which can quickly overload a management node. For example if a 50 seat block allocation for an upcoming class or workshop is triggered the backend currently inserts 50 reloads at the same time to start preparing for the upcoming block.

So maybe somewhere around 5-10 concurrent reloads 2-5 minutes apart. Of course we hit a problem of missing the window needed to get the machines ready. Maybe the number of concurrent reloads and the reload start delta could be a result of some calculation of how many nodes are current loading on that particular management node and an average of the historical load time of the image. Hope that made sense.

Aaron


--On February 5, 2009 9:16:13 AM -0500 Aaron Peeler <aaron_pee...@ncsu.edu> wrote:

Would it make sense to break this into two functions?

Have this function XMLRPCblockAllocation with only two parameters
blockrequestid and blockTimeid.

The second function would be to create the Block Allocation -
XMLRPCcreateBlockAllocation.

Aaron

--On February 4, 2009 4:39:30 PM -0500 Josh Thompson
<josh_thomp...@ncsu.edu> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm going to start work on VCL-78 which is an addition to the frontend
XML RPC  API to allow the backend to call the frontend for allocating
computers for  block reservations.  Currently, the block reservations are
created in the  frontend, but computers are not allocated to fulfill them
because the  requested time(s) could be at any point in the future.  So,
around 6 hours  before a requested time, the backend picks up that block
reservation time  slot, allocates computers for it, and then inserts
reload reservations early  enough for the computers to be preloaded by
the start of the time slot.

This results in a fair amount of duplicated code, since the frontend
currently  handles computer allocation in all other cases.

This is how I am planning on implementing it.  Please reply with any
comments  on doing it differently or tweaking it somehow.  I'm open to
any suggestions.

The backend could just call the frontend with the blockTimes id to
process,  but I'll make it more generic to be more useful in other cases
and require  that the backend specify several items.

function name: XMLRPCblockAllocation

parameters:
  imageid - id of the image to be used
  start - unix timestamp for the start time (i.e. machines should be
prep'd  and ready by this time)
  end - unix timestamp for the end time
  machinecount - number of computers to allocate
  usergroupid - id of user group for checking user access to machines
  ignoreprivileges - 0 (false) or 1 (true) - set to 1 to select computers
from  any that are mapped to be able to run the image; set to 0 to only
select  computers from ones that are both mapped and that users in
usergroupid have  been granted access to through the privilege tree.  If
this is set to 1,  usergroupid is ignored (more on this below).
  blockTimeid - id from blockTimes table that this will fulfill or 0 if
there  is not an existing block reservation related to this call

returns: the number of machines that were successfully allocated, with 0
indicating a complete failure of not being able to allocate any computers

Description of how it will work:
The frontend will use the normal scheduling functions to allocate
computers  and insert them into the blockComputers table.  If blockTimeid
is 0, new  entries will be created in the blockRequest and blockTimes
tables.  It will  create reload reservations for the computers early
enough for them to be  loaded by the start time based on historical
loading times.

The ignoreprivileges flag exists to allow more machines to be available
for  fulfilling block reservations than just those that the user group
has access  to.  The current implementation with the backend doing the
processing  functions as if ignoreprivileges were set to 1.

That's pretty much it.

Josh
- --
- -------------------------------
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University

josh_thomp...@ncsu.edu
919-515-5323

my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJigsTV/LQcNdtPQMRAvSuAJkBLrJnfgC+VD/MFVcg6HIM3OIb9QCdGVkL
NK5Mjyap5+oeemdm40DEdaQ=
=e3CH
-----END PGP SIGNATURE-----

Reply via email to