First, set the following:


Languages:
C
C++
Java
.NET
Python
MATLAB
R

Then, choose below:


Quick Start Guides

Example Tour

Reference Manual

AMPL-Gurobi Guide

Remote Services

Cloud Guide

Managing Runtimes


Managing Runtimes

A runtime is an executable built to run jobs using a given version of the Gurobi Optimizer. Each node in the cluster can handle multiple runtimes, so different Gurobi versions can be supported on the same node at the same time. The Gurobi Remote Services agent will automatically select the appropriate runtime, depending on the version of the Gurobi Optimizer library used by the client program.

Runtime executables, named grb_rsw, are installed in the data directory of a node, under the following directory structure (the version numbers used in this example are just for demonstration purpose):

grb_rs
data/
  runtimes/
     v8.0.1/
        grb_rsw
     v8.1.1/
        grb_rsw

The Remote Services agent will select the latest technical release that matches the major and minor version of the client. With the example above, if the client uses version 8.0.0, runtime version 8.0.1 will be selected. If later a version 8.0.2 is installed, the same client will use it without any modification.

Note that the Remote Services agent should be no older than the runtimes you deploy for it. Thus, for example, you can deploy runtime version 8.1.1 in an agent version 8.6.0, but not vice-versa. Note also that the ability to support different versions in a single Compute Server only started with version 8.0, so older versions such as 7.0 or 7.5 are not supported.

Deploying Runtimes

The Remote Services installation package will contain the latest supported runtime, which will be ready to use. You don't need to take any action to install a runtime when you first install Remote Services.

When new versions are released, you have the choice of reinstalling Remote Services with the latest runtimes or deploying only the runtimes that you need.

To deploy a specific runtime to a running node, you first need to stop the processing on that node:

grbcluster --server=server1 --password=cluster stop

Once all running jobs have finished processing and the node processing state has changed to STOPPED, you can deploy the new runtime using the grbcluster deploy command:

>grbcluster --server=server1 --password=cluster deploy gurobi_server812/linux64/bin/data/runtimes/v8.1.2/grb_rsw

You can examine the list of available runtimes using the grbcluster nodes command. Available versions are listed in the RUNTIMES column:

> grbcluster --server=server1 --password=pass nodes --long

ADDRESS STATUS TYPE    LICENSE PROCESSING #Q #R JL IDLE  %MEM %CPU STARTED             RUNTIMES            VERSION
server1 ALIVE  COMPUTE VALID   ACCEPTING  0  0  2  2h28m 1.37 2.03 2019-04-07 11:41:25 [8.0.1 8.1.1 8.1.2] 8.1.1-v8.1.1rc0
server2 ALIVE  COMPUTE VALID   ACCEPTING  0  0  2  2h28m 2.67 0.83 2019-04-07 11:41:33 [8.0.1 8.1.1]       8.1.1-v8.1.1rc0

You can remove an old runtime using grbcluster undeploy:

> grbcluster --server=server1 --password=cluster undeploy 8.1.1

> grbcluster --server=server1 --password=pass nodes --long
ADDRESS STATUS TYPE    LICENSE PROCESSING #Q #R JL IDLE  %MEM %CPU STARTED             RUNTIMES      VERSION
server1 ALIVE  COMPUTE VALID   ACCEPTING  0  0  2  2h28m 1.37 2.03 2019-04-07 11:41:25 [8.0.1 8.1.2] 8.1.1-v8.1.1rc0
server2 ALIVE  COMPUTE VALID   ACCEPTING  0  0  2  2h28m 2.67 0.83 2019-04-07 11:41:33 [8.0.1 8.1.1] 8.1.1-v8.1.1rc0

After deploying or undeploying, you can resume the job processing on the node, at which point new jobs will use the latest runtimes:

> grbcluster --server=server1 --password=cluster start

You can use the flag --all-stopped with the deploy or undeploy commands to deploy or undeploy to multiple nodes at a time. Note that this flag will only apply to nodes that are already STOPPED, so you should issue the stop command fist (typically with the --all flag) to stop the nodes.

In conclusion, you can incrementally deploy new runtimes on cluster nodes as they become available without having to reinstall Remote Services. This works only for technical releases, and if you do not need to deploy a fix in the Remote Services stack.