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
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:
|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 or one of the following locations where XXX is the Gurobi Optimizer version you are using:
Or set the environment variable
|Provide an cost estimate for a pool.|
|Toggle the selection. Some actions such as manual launch or termination can apply to many pools, and you can toggle the selection.|
|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 (v8 only)||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 (for example in an interactive python shell) while not being active. If the value is 0, it will be disabled.|
|Job Limit||A maximum number of concurrent jobs for each compute server. This option can be set only for 'full compute server' license type.|
|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).|
Starting the the 8.0.0 engine, 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.
Static Addressing (deprecated)
Advanced users can also benefit from the static addressing feature of the pools. With this feature, a set of static IP addresses are reserved for the machines of a pool. Then, when the machines are launched, one of the static IP addresses will be assigned to each machine. If machines are terminated and restarted they will always get one of the static IP addresses of the pool. This is useful when a customer side firewall is in place and the static IP addresses can be declared so that traffic can go through to the Gurobi Cloud machines. As the set of IP addresses is static, the firewall does not need to be updated. However, if the pool size, the number of distributed workers or the region is changed, the set of IP addresses will be adjusted, and the firewall will have to be updated.
In order to use this feature, you first need to activate it globally in the preferences. Then, when you create or
edit a pool,
you need to set the addressing mode in the
Addresses tab. When you create or change the configuration,
you will notice that the state of the pool is indicated as in progress because the IP addresses are being
When the addresses have been fully provisioned, the pool state comes back to stable and you can access the addresses
to download the list of IP addresses.