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.