Communication Options#

The Cluster Manager and the nodes running Gurobi Remote Services communicate through a REST API using HTTP by default. If you are using a Cluster Manager, you have a few options for a more secure deployment with HTTPS:

Use a load balancer listening on HTTPS in front of the Cluster Manager. The load balancer can remove TLS encryption, and forward the communication to the Cluster Manager as HTTP.
Enable HTTPS on the Cluster Manager and then let it forward the communication to the nodes using HTTP. The nodes themselves will continue to communicate over HTTP only.
End-to-end HTTPS by enabling HTTPS on the Cluster Manager and the nodes.

If you are not using a Cluster Manager, you still have a few options:

Enable HTTPS for all of the nodes.
Set up a Gurobi Router and enable HTTPS for the router only.
End-to-end HTTPS by enabling HTTPS on the Router and the nodes.

Enabling HTTPS on the different components follows the same principles. Remote Services also support self-signed certificates for testing your deployment. Finally, firewalls may have to be configured to let clients connect to the Cluster Manager or the Cluster nodes. In some cases, a Remote Services router can be used instead of a Cluster Manager.

Enabling HTTPS#

Enabling HTTPS on the Cluster Manager or the nodes follows the same principles. Several properties can be used to configure the communication options. In order to enable HTTPS with TLS data encryption over the wire, you need to set the TLS property.

TLS=true

You will also need to provide the paths to the private key and the certificate files:

TLS_CERT=cert.pem
TLS_KEY=key.pem

When HTTPS is enabled on the cluster nodes, the standard HTTPS port 443 is then used as the default instead of port 80. As with the port 80, you will need to start grb_rs with elevated privileges. Otherwise, you will get a permission error. On Linux, you’d see an error message like the following:

fatal : Gurobi Remote Services terminated, listen tcp :443: bind: permission denied

As explained in the installation section, you can change the port using the PORT property. Note that you cannot mix nodes using HTTP and nodes using HTTPS in the same cluster. If you wish to use HTTPS, all of the nodes must be configured in the same way. HTTPS will be used for communication between the nodes.

If you enable HTTPS, you will need to use the prefix https:// to access the nodes of your cluster:

> grbcluster nodes
ADDRESS               STATUS TYPE    LICENSE PROCESSING #Q #R JL IDLE   %MEM  %CPU
https://server1:61000 ALIVE  COMPUTE VALID   ACCEPTING  0  0  2  46h59m 9.79  0.50
https://server2:61000 ALIVE  COMPUTE VALID   ACCEPTING  0  0  2  46h46m 8.75  0.00

Using HTTPS with Self-Signed Certificates#

Using self-signed certificates is not recommended for production deployment as it is less secure, but it can be useful when testing a deployment. When using this mode, the data will be encrypted over the wire, but the certificate will not be validated.

If you do not specify a key and a certificate in the TLS_KEY and TLS_CERT properties, grb_rs and grb_rsm will generate them for you at startup. You can also specify your own self-signed certificate using TLS_KEY and TLS_CERT properties.

To use a self-signed certificate, you will need to activate insecure mode by setting the following property for grb_rs:

TLS_INSECURE=true
MANAGER_INSECURE=true

At the same time, similar properties must be set for grb_rsm:

TLS_INSECURE=true

When using grbcluster, you will also need to activate this mode by using the —-tls-insecure flag with the login command.

> grbcluster login --manager=https://mymanager:61080 --username=sysadmin --tls-insecure
info  : Using client license file '/Users/jones/gurobi.lic'
Password for sysadmin:
info  : User gurobi connected to https://mymanager:61080, session will expire on...

When using other clients such as gurobi_cl, grbtune, you can set the GRB_TLS_INSECURE environment variable. In the programming language APIs, there is also a CSTLSINSECURE parameter.

Firewalls#

When a Cluster Manager is used, clients communicate with the Cluster Manager only. The Cluster Manager then communicates with the cluster nodes. If there is a firewall between the clients and the Cluster Manager, the port used by the Cluster Manager will have to be open. The default port is 61080 but you can choose an arbitrary port through the PORT configuration property.

In a self-managed cluster, clients communicate directly with the nodes. They use port 80 for HTTP or 443 for HTTPS by default, but you can choose an arbitrary port through the PORT configuration property. If there is a firewall between the clients and the nodes of the cluster, the chosen port will have to be open. In this case, another option is to set up a Gurobi Router.

The command-line tools and the libraries are also compatible with standard proxy settings using environment variables HTTP_PROXY and HTTPS_PROXY. HTTPS_PROXY takes precedence over HTTP_PROXY for https requests. The values may be either a complete URL or a host[:port], in which case the http scheme is assumed.

If you face connectivity issues with firewalls or proxy servers, we suggest you share this section with your network administrator.

Using a Router without a Cluster Manager#

If you are installing a self-managed cluster, the clients need to have direct access to each node in the cluster, including the node DNS name and IP address. A Remote Services Router provides a point of contact for all clients and will route the communication to the appropriate node in the cluster, thus allowing you to isolate your cluster from its clients. A Remote Services Router acts as a reverse proxy. Behind a router, the cluster nodes can use private DNS names or IP addresses as long as all of the nodes and the router can communicate together. Only the router must be accessible from the clients.

The router can use either HTTP or HTTPS to communicate with clients, and similarly it can choose either protocol to route traffic to cluster nodes. It is a common to enable HTTPS between the clients and the router, while having the router and the nodes communicate over unencrypted HTTP in a private network. Using this setup only requires you to manage certificates on the router.

You can get more information about the router (grb_rsr) by reading the command-line help:

grb_rsr --help

The router uses a configuration file grb_rsr.cnf that must be placed in the same directory as the grb_rsr executable. A predefined configuration file with additional comments is provided. The following command lists the available configuration properties:

grb_rsr properties

Similarly to grb_rs, the router can be started as a service and log messages will be stored in the grbrsr-service.log rotating file by default. Log messages will also be sent to the syslog on macOS and Linux, and to the service event log on Windows.

grb_rsr start

Here are some examples of how you might refer to a router using a URL (using HTTP or HTTPS, with the standard port or a custom port):

http://router.mycompany.com
http://router.mycompany.com:61001
https://router.mycompany.com
https://router.mycompany.com:61001

When using the command-line tools grbcluster or gurobi_cl, you can first log in with a router. The router address will be saved in your license file in the ROUTER property so that you can run other commands without needing to specify it again:

> grbcluster login --server=http://server1:61000 --router=http://router.mycompany.com
info  : Using client license file '/home/jones/gurobi.lic'
Enter password (return to use default):
info  : Connected to node http://server1:61000 via router http://router.mycompany.com

> grbcluster nodes
ID       ADDRESS               STATUS TYPE    LICENSE PROCESSING #Q #R JL IDLE %MEM  %CPU
b7d037db https://server1:61000 ALIVE  COMPUTE VALID   ACCEPTING  0  0  10 <1s  66.58 7.97
eb07fe16 https://server2:61000 ALIVE  COMPUTE VALID   ACCEPTING  0  0  1  <1s  66.58 9.62

For the clients using the Gurobi Optimizer API, you will need to either set the ROUTER property in the license file or construct an empty environment and set the CSRouter parameter before starting the environment.

For clients using the cluster REST API for monitoring purpose, you will need to use the router URL instead of a node address, and you can pass the selected node address in the header X-GUROBI-SERVER. In this way, the client communicates with the router and the router will use the header value to forward the request to the selected node. In case the node address is incorrect or does not exist, the router will return the HTTP error code 502.

Press `/` or click to search this documentation	Gurobi website	Gurobi community forum
Go to other Gurobi documentation	Gurobi download	Contact support