How to evaluate Gurobi Compute Server?

Gurobi Compute Server offloads optimization tasks to dedicated hardware – it provides seamless client-server optimization within your own deployment. Client-server optimization helps to achieve consistent runtimes, task independent scaling and efficient usage of shared hardware.

Compared to building and solving Gurobi models locally, setting up a Compute Server for client-server optimization involves a few more deployment steps, which often require the support from IT / infrastructure teams. This article is meant to give a concise overview of the components and considerations that are relevant for an evaluation of Compute Server.

Deployment Architecture

A full Compute Server deployment consists of at least one Compute Server node – dedicated hardware doing nothing else but solving optimization models with Gurobi – at least one machine or container to run the model building code + Cluster Manager and a Database. The Cluster Manager and Database are optional, free and highly recommended. Only with Cluster Manager and a Database you benefit from usage tracking, advanced user management, a convenient web UI, a more feature-rich REST API and more robust communication, especially in containerized environments. [Client-Server Optimization]

Your network configuration must allow Compute Server nodes and the optimization clients to connect with the Cluster Manager, and the Cluster Manager must connect to the Database. In a deployment without Cluster Manager and Database, the clients must be able to reach the Compute Server nodes directly. For detailed (interactive) installation instructions for Compute Server and Cluster Manager please refer to the license delivery email of your evaluation/subscription license.

Hardware Choice

The Compute Server (grb_rs) does the hard work and should run on dedicated hardware with high CPU clock rates and sufficient and fast memory. The number of physical cores of the CPU should match your needs (more below). Any Compute Server license supports up to 8 physical cores by default. [What hardware should I select when running Gurobi?]

Often, but not always, 8 physical cores translate to up to 16 vCPUs when selecting virtual machines from cloud providers. If the 2:1 ratio of vCPUs to physical cores holds depends on the underlying hardware and whether it supports hyperthreading or not. [How does Gurobi count cores?]

How many cores you need for your optimization load depends on the types of models you are solving, how many of them you would like to run in parallel, which algorithms are needed, and what your runtime requirements are. Please use the following articles as a guide to design experiments that help you make a decision, and feel free to ask for help – if you share some of your model files, we can run computational experiments for you. [1. How many cores does my model need? 2. How do I size my Gurobi architecture?]

Gurobi runs on common 64-bit platforms; please follow the link below to check your platform for compatibility. [Supported Platforms]

While we do not recommend specific hardware or operating systems, you may use the available machine types in our Instant Cloud service as a reference. [Instant Cloud Machine Types]

Compute Server and Cluster Manager Configuration and Usage

Compute Server and Cluster Manager help to make sharing your resources convenient with features like queueing, job priorities, and different capacity management strategies. Still, users and applications may compete for resources. Therefore, each user should know about the functioning of job limits, node thread limits, thread limits, and threads used per model. System administrators and Gurobi users should agree on how user accounts and API keys are managed, and users should be aware of how their usage affects the capacity left to others. Please consider the following article while configuring Compute Server and Cluster Manager to make sure you get the most out of your Compute Server capacity. [Capacity management with Gurobi Compute Server]

More advanced features like Compute Server grouping and job priorities are valuable to make your job queueing more granular, especially once you deploy a cluster with at least two Compute Server nodes. [Compute Server Grouping]

Licensing

In any Compute Server deployment, only the machines/containers running the Compute Server process/service (grb_rs) require a license; they are doing the actual optimization work. Scaling your optimization capacity with Compute Server is possible by adding more machines/containers, each running Compute Server (grb_rs), which requires additional licenses, or by increasing the core count of a machine (after adding cores to the licenses if the physical cores of the machine exceed 8 cores).