Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Optimising performance in a provisioning pool through configurable optimal distribution

IP.com Disclosure Number: IPCOM000216316D
Publication Date: 2012-Mar-29
Document File: 4 page(s) / 64K

Publishing Venue

The IP.com Prior Art Database


Suggested in this article is a method of improving the agility of a Provisioning system by allowing pool administrators to specify a "common distribution" of OS/Architecture combinations in their pool, as well as a schedule for automated actions to take place on their pool. These "automated actions" amount to installing Operating Systems on non-provisioned resources in the pool that bring the current OS/Architecture distribution in the pool as close as possible to the "common distribution" that was configured by the administrator.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 01 of 4

Optimising performance in a provisioning pool through configurable optimal distribution

In a Provisioning system, systems are provisioned "on demand": essentially, there is a pool of available resources, and when a user wants to request a system, they enter their requirements; if there is suitable free resource available in the pool, this resource is provisioned for them. When they are done with the provision, it is "given back" to the pool.

How the overall resources of an IT organisation are divided up into pools is a matter of choice, but one common example is to have one pool per development team.

    A major factor that introduces delays and decreases the agility of a provisioning system (an important characteristic) is the time taken from a provision request through to the machine being made available to the user. This is because the OS needs to be installed, and then the relevant setup scripts executed to prepare the machine for licensing and compliance etc.


    The main known solution has already been covered (i.e. a traditional provisioning system whereby machines are installed as requests come in).

A second piece of prior art is the idea of templating. This works particularly well

with Virtual Machines (VMs). Say a new version of the RedHat distribution comes out: the admin would create a new RedHat VM from scratch, patch it up to date, and then leave it defined in the cluster. If a request comes in for the same OS as this template VM, it can be cloned (licensing and compliance, plus any required software stacks may still need to be dealt with afterwards via scripting).

The benefit of this solution is that it is a lot faster than a new install. The down-side is that cloning creates a new VM: additional mechanisms are therefore needed to clear out old VMs and stop pools from growing too big. Another downside is the need to use up resource to create a template for every popular OS and architecture, and to provide every pool with access to these template VMs.

    Although the templating solution is a good one, it is clear that there is room in this space for other solutions that will better address the problem in some environments.

    We will describe a solution whereby owners of a pool can specify a common distribution of operating systems and architectures in that pool, to cover their users' needs (some use cases are given as examples in the next section). Thi s i s combined with picking a time and frequency for pool re-shuffling to take place. Typically this might be in the middle of the night, every night, or at any other time

when users are not often putting in provisioning requests.

When the re-shuffle time comes around, the provisioning system will look at the current distribution of systems in the pool: it will then automatically install operating systems on the un-provisioned (free) systems in the pool to bring this distribution as close as possible to the prescribed "common distribution".

    Once the OS is installed...