Try our new documentation site (beta).
Pools
A pool defines the configuration of one or more machines. When the Gurobi client library connects to the Instant Cloud to get an environment of Cloud machines, the pool is used to reference the group of machines to use. If the machines are already started, they will be used right away. If some of the machines are not running, Instant Cloud will then launch them automatically so that the client will be able to start the optimization as soon as they become available. The pools fully automate the process of starting machines and waiting for them to be ready.
A pool can be shared by multiple applications and users. The first application accessing the pool will trigger the launch of the required machines, and the subsequent solves by any other applications will be able to execute without waiting for the machines.
A pool can be created to distinguish configurations used in different contexts: large or small optimization problems, development vs production deployments, different regions (data centers) to minimize latency...
A pool has a name (alphanumeric characters only), and its size indicates how many compute servers are part of the pool. If the license type is 'full compute server', the pool configuration can also specify the number of distributed workers to associate with each compute servers. The compute servers and the distributed workers (if any) have the same configuration: machine type, region, idle shutdown, idle job timeout, job limit, and Gurobi version.
A default pool is automatically created for each license. A default pool cannot be deleted, but its configuration
can be changed. When the license file does not specify a pool, the default pool is used. The name of a default pool
is
default.
The status of the pool is displayed with a colored icon:
 |
The pool is not ready, some machines have not been launched yet. |
 |
The pool is not ready, some machines have been launched but are not available yet. |
 |
The pool is ready, all the machines specified in the pool are available. |
 |
The pool has an error, you can move the mouse over and a tooltip will display the exact reason. |
In addition to the status, you can perform the following actions. Some actions are specific to one pool and some others can be applied to multiple pools, in this case you can toggle the selection using the checkboxes.
 |
Add a pool. When adding a pool, you are able to specify its name, its license, and all the configuration parameters. |
 |
Scale up or down the pool. |
 |
Edit a pool. The pool configuration can be changed so that it can be adjusted depending on the needs without changing the clients or the deployed applications. Note that the name of the pool and its license cannot be changed. Also note that changing the pool configuration will take effect only when new machines are launched. To avoid possible inconsistent configurations among the machines of the same pool, terminate the machines first. |
 |
From the list of pools you can also download the pool license file. The license file contains the default access ID and secret key for the selected pool. You just have to place this file in your home directory which takes precedence, or in one of the following shared locations:
In case you previously had a license file installed, please make sure to replace it,
or set the environment variable |
 |
Delete selected pools. When a pool is deleted, all the machines are also terminated if they were running. |
 |
Terminate pools. The machines launched for a pool will typically auto-terminate based on the idle shutdown parameter. However, it may be useful in some cases to terminate the machines manually. |
 |
Launch pools. A pool will typically be launched automatically by a client when an optimization problem is ready to be processed. However, it may be useful to launch the pool manually. When a pool is launched, the missing machines part of the pool are launched. |
Create or Edit Pools
When creating or editing a pool, you will have access to the following properties:
| Name | A pool has a name that is unique for a given license. The name must be composed of alphanumeric characters only and the name 'default' is reserved. The name of a pool cannot be changed. |
| Description | An optional description of the pool. |
| Size | The number of compute servers that must be launched for this pool. |
| License | The license used for this pool. The license of a pool cannot be changed. |
| Workers | The number of distributed workers to launch for each compute server. This option can be set only for 'full compute server' license type. |
| Gurobi version | Version of the Gurobi Optimizer runtime. |
| Idle Shutdown | Idle shutdown specifies a duration limit in minutes after which the machine will auto-terminate. |
| Idle Job Timeout | This timeout specifies a duration limit in minutes after which the job will auto-terminate when there is no command sent to the server. This is useful to avoid using resources when some clients may leave their connection open while not being active (for example in an interactive python shell). This timeout can also be specified client side by using the property CSIdleTimeout. The default value client-side is 30 minutes. The actual value will be the maximum between the value specified by the client and the value specified by the pool. |
| Job Limit | A maximum number of concurrent jobs for each compute server. This option can be set only for 'full compute server' license type. |
| Provider | The cloud provider, Amazon Web Services (AWS) or Microsoft Azure. |
| Region | The region references the location of the data center where the machines are provisioned. Select a region that is closer to your operations to minimize latency. |
| Machine type | Different machine types can be provisioned depending on the requirements (mainly memory and CPU). Depending on the machine types and license, the cost of a machine and distributed workers can differ. Instant Cloud can give you more details and an estimate of the costs. |
Pool Scaling
It is possible to scale up or down your pools using the Instant Cloud Manager or the REST API. A pool defines a number of compute servers that is actually the minimum number of servers. So when a client starts a pool, the pool will be ready when this number of servers is ready. Then, you can scale up by requesting additional servers to be added to the pool. When servers are added, they automatically join the cluster of compute servers of the pool and start processing new jobs or jobs already queued in existing servers.
The pool will scale down automatically by using the existing idle shutdown parameter. This means that any server being idle for this time limit will be terminated, up to completely terminate the pool. The pool can also be explicitly scaled down by reducing the number of servers. In this case, if a machine must be stopped but it is already running a job, it will be moved into a draining mode where new jobs will not be processed while running ones will be processed normally. When these jobs have completed, the machine will be automatically terminated.
For better monitoring, the pool view displays the number of machines that are starting, stopping and the ones that are ready.
