General Considerations
- Be aware of the academic license limitations for Gurobi Compute Servers:
- You can run at most two Compute Servers concurrently but an unlimited number of Compute Server Workers. A Worker is a reduced Compute Server that can only be used for distributed optimization and by the parameter tuning tool.
- On each Compute Server (worker), you can run at most one job concurrently.
- Queueing of jobs is not allowed, i.e., if there are currently no Compute Servers idle in your cluster, your job will be rejected.
- We recommend using a dedicated machine for each Compute Server, Compute Server Worker, and Cluster Manager to reproduce performance and get reliable running times.
Setup Steps
- Get an Academic WLS license for the Compute Servers. You can use the same WLS license for at most two Compute Servers. The Cluster Manager and the Compute Server Workers do not need a license.
- Follow the article "How do I set up a managed Compute Server Cluster?" to set up the Gurobi Cluster Manager with its database and the Gurobi Compute Servers. To set up Compute Server Workers, we refer to this documentation page.
- From the client machine where you want to start a job, create an API key for your user in the Cluster Manager by following the article "How do I create a new Cluster Manager API key?"
Usage Considerations
- Ensure that your license file with the API key created in Step 3 is available, see the article "Where do I place the Gurobi license file (gurobi.lic)?".
- Solving models on a single Compute Server node works the same as if you would solve the model on your local machine. The information in the license file tells the solver to use the Cluster Manager here. You can also define the connection parameters in your code.
- If you want to solve models with distributed optimization algorithms, you need to set parameters DistributedMIPJobs or ConcurrentJobs.
- If you want to use the automatic parameter tuning tool, you can define the number of permanently used Compute Servers (Workers) with the parameter TuneJobs and the number of dynamically used Compute Servers (Workers) that are shared with all other jobs currently running in the cluster with the parameter TuneDynamicJobs.