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.
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.