When a VCL reservation is over, VCL must make a decision on what to do with the node. Typically, it loads the node with an image so that the node will be mostly ready for another user to use it rather than the user having to wait for a full deploy time. VCL calls this Predictive Preloading. The idea here is that since a VCL system has many nodes, rather than leaving them in a state that is not particularly useful, load them with an image that has the potential to be useful to a future user. Once reloaded with an image, the node is considered to be in a hot standby state. At this point, only things like adding a user account need to be done to make the node ready for a user to log in. This decreases the deploy time and makes for a better user experience.

Through the 2.4.2 release, this was controlled as a management node setting that was then applied to all computers controlled by that management node. In later releases, this is controlled by setting the Predictive Loading Module field for each computer.

There are 3 modules available from which to select:

  • Reload with last image - This method simply reloads the node with whatever image was just used on it. This method is really good at handling spikes in requests for a particular image. As more users make and end reservations for a particular image, more nodes end up getting preloaded with it.
  • Reload image based on recent user demand - This method incorporates data from the log table to rank images based on popularity. It uses several different time frames regarding how far back to look in the log data based on what percentage of the nodes in the system are free. The more free nodes, the further back it will look in the log. The algorithm then selects the most popular image that does not already have 2 nodes preloaded with it. This method is good at having a good selection of popular images available. It is not as good when there are spikes in demand for a particular image.
  • Unload/power off after reservation - This method is rather different and, as can be determined from the name, just unloads the node if it is a VM or powers it off if it is a bare metal node. This is useful to save power, but causes there to always be a full deploy time for each reservation.

There is 1 other case in how nodes are handled at the end of a reservation. If a new reservation for the node is coming up within a somewhat short amount of time, the node will be preloaded with the image for that reservation.

  • No labels