Components and responsibilities

In any architecture involving Gurobi, we have three key responsibilities:

• Constructing mathematical models (and processing solutions)
• Solving these models
• Licensing

With a Floating Compute Server license, these three responsibilities are all assigned to dedicated components:

• Your application uses the Gurobi API to construct a mathematical model
• Compute Server receives these models and solves them
• Token Server holds your commercial Gurobi license and manages concurrent usage of this license by one or more Compute Servers

Interaction between components

To understand how these components work together, it’s best to visualize them as follows and focus on the information flow between them. 

• When the Token Server starts up, it reads the Floating Compute Server license. It ensures the Token Server is being used on the right machine, as defined in the license file.
• When the Compute Server starts up, it connects to the Token Server. Connection information is found in the “Token Server client license file”, which is a simple gurobi.lic text file specifying the hostname and port of the Token Server. Note that there might be more than one Compute Server in the cluster; each of them would request its own token from the Token Server.
• When the Application starts working on a Gurobi model (specifically, creates a Gurobi environment  object), it automatically connects to the Compute Server. Connection information is stored in a similar client license file.
• During its lifetime, the Compute Server will remain connected to the Token Server to continuously check that valid license capacity is reserved. Note that this check is independent of the fact whether the Compute Server is solving any models.

Adding the Gurobi Cluster Manager

To benefit from all functionality that a Compute Server has to offer, we recommend using Gurobi Cluster Manager as well. This additional (free) component introduces many useful features and acts as a gateway between your application and your Compute Server(s).

The Cluster Manager itself does not need a license. In this architecture, each Compute Server is configured to know the hostname and port of the Cluster Manager. On startup each Compute Server registers itself, so the Cluster Manager has an overview of the cluster. Your application(s) connect to the Cluster Manager as well to submit models.

Setting up a Floating Compute Server environment

While the diagrams above are conceptual, in practice there are many ways to setup an environment like this. For example, most of the components can be deployed as containers using Docker or Kubernetes (with the exception of the Token Server). Your application might also be a Databricks notebook or pipeline. For this reason, we don’t provide a single installation guide that covers all scenarios.

• The official documentation for Compute Server and Cluster Manager is our “Remote Services manual”. This includes installation instructions.
• For setting up a Token Server, you can follow the article “How do I set up and use a floating token server license?” in our knowledge base.
• You may also want to look at our Gurobi Installation Navigator, which provides guidance for many common scenarios with Floating Compute Server. After specifying some details for your architecture, the tool will provide step-by-step instructions. If you need more detail for each step, please look at the resources listed above.

Adding redundancy

With the architecture topologies described above, there are several single points of failure. You may want to design your architecture to be highly available.

• For the Cluster Manager, you can run more than one instance. This is described in more detail in our "Remote services" documentation.
• For the Token Server, you can run more than one instance on separate machines. Each would need to have its own Gurobi license. Then, each Compute Server can be configured to know the location of both Token Server instances. Use a comma-separated list for the TOKENSERVER setting.