Gurobi Remote Services Release Notes v9.5.2
You have successfully installed version 9.5.2 of the Gurobi Remote Services.
Gurobi Remote Services is a set of Gurobi features that allows a cluster of one or more machines to perform Gurobi computations on behalf of other machines. The key components of Remote Services are:
- Compute Server, which allows you to offload all Gurobi computations from a client machine onto a remote cluster.
- Distributed Workers, which can be used to perform parallel computation on multiple machines.
- The Cluster Manager, an application server that provides secured access to your Remote Services cluster, as well as providing a Web User Interface and a command-line tool that make it easier to manage and monitor your cluster. The Cluster Manager uses a database to store user accounts, API keys, jobs, batches, and settings. You can use Compute Servers without a Cluster Manager – we refer to that as a self-managed cluster. However, we recommended you use a Cluster Manager to get the rich set of features that it provides.
Obtaining Your License
To obtain a Gurobi 9 license, you will need to visit the Gurobi License Center. If you are a commercial user under maintenance, you should see your Gurobi 9 license under Current Gurobi Licenses. If you would like to request a free academic license, you can do so from the Free Academic License page. Once you have a license on the Gurobi web site, you will need to follow the instructions for installing a license in the Quick Start Guide.
Supported Platforms for Remote Services
Platform | Operating System | Notes |
---|---|---|
Windows 64-bit (win64) | Windows 10, 11, Windows Server 2012 R2, 2016, 2019, 2022 | |
Linux® x86-64 64-bit (linux64) | Red Hat® Enterprise Linux 7 (and the corresponding CentOS distribution), 8 | |
SUSE® Enterprise Linux 12, 15 | ||
Ubuntu® 18.04, 20.04 | ||
Amazon Linux 2 | ||
Mac OS 64-bit (macos_universal2) | 10.15 (Catalina), 11 (Big Sur), 12 (Monterey) |
Supported Browsers by the Cluster Manager Web UI
Browser | Minimum Version | Notes |
---|---|---|
Chrome | 79 | |
Firefox | 72 | |
Edge | 44 | |
Safari | 14 |
New or Improved Features
Global Updates
- Gurobi Compute Server now supports Gurobi Optimizer 9.5, in addition to past releases: 8.0.0, 8.0.1, 8.1.0, 8.1.1, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.1.0, 9.1.1, and 9.1.2.
- This release provides a macOS Universal 2 package (named macos_universal2). The macOS Universal 2 binary format provides binaries that are compatible with both x86-64 and ARM64-based processors. This applies to all command-line tools and server components, except for past engine workers (from 8.0.0 to 9.1.2) that will continue to work but only contain x86-64 binaries.
- The server components (grb_rs, grb_rsm, and grb_rsr) now support configurable TLS v1.2 cipher suites and policies. The
ciphers
command lists the supported cipher suites and policies which can then be specified in theTLS_CIPHERS
configuration property or the--tls-ciphers
command-line flag. Use the commandgrb_rs ciphers --help
to learn more. TLS v1.3 will be used if the client supports it, and in that case, standard cipher suites for this protocol version will automatically be selected. When using the Gurobi library, TLS v1.3 will be used only when the client is running on a Linux platform.
Cluster Manager – Security
- The Cluster Manager supports two types of authentication: interactive login and API keys. With an interactive login, a user must provide a username and password. With an API key, a user or an application must provide an access ID and a secret key. For each account, the system administrator can enable or disable interactive login or API authentication. This can be done at creation time, or it can be done later by editing the account properties. An account that only allows interactive login will not be able to create, use, or manage API keys. An account that only allows API key authentication can only be used for programmatic access through the REST API (system account).
- The system administrator can now disable and later reenable a user account. When an account has been disabled, interactive login and/or API key authentication will fail and access to the Cluster Manager will not be granted. Disabled accounts will appear with a grayed icon in the user account table. The tooltip will indicate the reason.
- The Cluster Manager now supports password policies to ensure that passwords for local accounts match configurable security standards. Through a password policy, the system administrator can specify the minimum length of a password and can require that a password contain a mix of upper and lower case characters, digits, or symbols. Any changes to a policy will apply only when new passwords are created; previously created password will remain valid. In addition, the system administrator can define a maximum number of failed login attempts before the account is locked. When a user account has been locked, a message will appear on the login page, and the user will be asked to contact a system administrator. The system administrator can then change the password to unlock the user account.
- The Cluster Manager can now be integrated with an LDAP repository. This integration can be configured in the Cluster Manager settings section. The system administrator can specify connection parameters (including the use of LDAPS for encrypted communication), account filtering, and account mapping. Once activated, users will be given access based on the user accounts defined in the LDAP server. Accounts with a system administrator role can log in using their local passwords, which enables them to administer the cluster even if there is a problem with the LDAP configuration. System administrators will need to log in using the special login page by following the “System Administrator Log in” link at the top of the main login page. System accounts (i.e., accounts with no interactive login) can always gain access using API keys only. The Cluster Manager continually synchronizes user accounts with the LDAP server in the background. If a given user account is no longer mapped to the LDAP filter in place, it will be disabled. In particular, if an account was created before the integration with the LDAP server and if it is not mapped to the defined LDAP filter in place, it will be disabled. The same policy will apply during migration from local accounts to LDAP. Two important exceptions are system administrator accounts and system accounts, which will not be disabled for this reason.
- The Cluster Manager now supports a new user role for read-only access. Read-only users can only monitor optimization tasks. They can list jobs and batches, access history, display the log of a job, etc. They are not allowed to submit jobs or batches to the cluster, nor can they abort jobs.
- The management of API keys with the Cluster Manager has been improved. When creating an API key, you can specify an optional application name and a description to help keep track of how the key is being used. Once a key is created, you can download an associated client license file, which contains the API access ID, the secret key, and the Cluster Manager URL. This file can be used by client applications and command-line tools to connect to the Cluster Manager. The Cluster Manager keeps track of the timestamp and IP address of the last API key usage. The owner of the API key or the system administrator can disable or enable an API key. These features simplify the task of monitoring API keys, detecting unwanted usage, and safely rotating keys by disabling previous keys before permanently deleting them.
Cluster Manager – Usability
- The Cluster Manager now provides an integrated user manual that is accessible in the help section. It also provides contextual help, and you can click on question mark icons placed throughout the Web UI. This will open a new page with the relevant documentation.
- The Cluster Manager now provides a settings section to manage some configuration parameters. The settings are stored in the database and shared between the instances of the Cluster Manager. In some cases, changes may take some time to propagate (see the cache expiration parameter for details). Before version 9.5, some of these parameters were static values defined in the grb_rsm.cnf file. In this release, initial values will be taken from the grb_rs.cnf file, but changes can be made in the settings section after that.
- The detailed view of a job will now also display graphical charts of metrics over time. All jobs will have a chart showing the evolution of the objective, and the MIP jobs will also show the %Gap over time. These charts will be automatically updated for as long as the job is still running. This new view allows the user to inspect job properties, logs, and charts to simplify the task of monitoring and controlling jobs.
- The Cluster Manager now creates permalinks for all tables that can be filtered or searched. Any change to the filter or search will be immediately reflected in the URL so that it can be copied and pasted for further reference. This way, users can share and reuse links more easily. For example, the following URL will systematically display the jobs that are running,
http://localhost:61080/jobs/main?status=RUNNING
, assuming the Cluster Manager is running onlocalhost:61080
. - When a system administrator uses the Cluster Manager, he will see the jobs and batches of all users by default, instead of only the ones he created. This behavior better matches the role of a system administrator.
Cluster Manager – Database
- The Cluster Manager now supports AWS DocumentDB 4.0 (https://aws.amazon.com/pm/documentdb) as a back-end database. This expands your options when deploying the Cluster Manager on an AWS environment.
- When installing the 9.5 Cluster Manager on an existing deployment, the database will be automatically migrated to schema version 1.1.0. During that process, new fields will be added and indexes will be dropped and recreated. No data will be deleted, and the migration is a safe process. Having said that, we do recommend that you perform a backup before starting the migration.
Tools
- The
grbgetkey
command-line tool is used to retrieve and assign some types of licenses from the Gurobi server. The associated communication is now done exclusively over HTTPS for better security. The option to use insecure HTTP has been removed. - The
grbprobe
command-line tool is used to inspect some properties of a machine or container for licensing purposes. When it is executed inside a container, the container ID will be displayed. If the container ID is not displayed, it means that the specific type of container environment is not supported. In this case, please run the commandgrbprobe cgroup
and send the output to the Gurobi support for further analysis.
License Agreement
Note that this software is covered by the Gurobi End User License Agreement. By completing the Gurobi installation process and using the software, you are accepting the terms of this agreement.
Thank you for using Gurobi products!