Documentation

Deployment Architecture

The goal of Gurobi Cloud for AWS is to let you install and use your own servers running on AWS EC2 to perform optimization tasks. The client can run on-premise (laptop or workstation) or on the Cloud as well (another EC2 instance for example), and it will connect to the servers. Once you have configured the Gurobi Remote Services on the servers, it is not necessary to log in to the EC2 instance directly.

We assume you are familiar with setting up the Gurobi Remote Services cluster as explained with full details in the Remote Services Reference Manual. In the next sections, we will focus on the specific items related to deploying the Remote Services on EC2 instances.

Capabilities

You will need to review the capabilities of the Gurobi Remote Services that you will use as this will impact the architecture and licensing requirements.

• Compute Server. The Gurobi Compute Server is a system for client-server Gurobi applications. The client program uses the standard Gurobi interface, and the optimization computation takes place on a remote compute server. With the Gurobi Compute Server on EC2, your EC2 instance does the optimization computation. You can run multiple instances of Gurobi Compute Server to form a cluster for better robustness or to efficiently solve many models at a time.
• Distributed Worker. With Gurobi distributed optimization algorithms, multiple computers can work together to solve a difficult model. An EC2 instance can be configured as a distributed worker. In this case, there is no Gurobi license charge for the EC2 instance, but that instance is unable to solve models on its own (You are still responsible for the EC2 machine charges). To use distributed algorithms, you should configure one EC2 instance as a Compute Server, and configure one or more additional EC2 instances as Distributed Workers. When using Distributed Workers, you will get the best performance when all the workers are the same EC2 instance type, and all are in the same AWS Availability Zone.

Cluster and Clients

If you need to start multiple instances of compute servers, distributed workers or a combination, you will need to form a cluster. In a cluster, each EC2 instance is called a node and it is running the Remote Services Agent (grb_rs). All the nodes in the cluster communicate between each-other to detect failed nodes, report status and balance the jobs among the compute server nodes. Thus, it is important to make sure that each EC2 instance can access any of the nodes in your cluster.

A client program will communicate with the cluster and must also be able to reach any nodes in the cluster (unless you have setup a Remote Services Router). The cluster can be administrated using the command line tool grbcluster so that you can list the nodes, list the running and recently processed jobs etc. This tool must also be able to access any node in the cluster. If you want to run the client program or grbcluster outside of EC2, you will need to make sure that each EC2 instance of the cluster has a public DNS name accessible from the clients.

Protocols and Data Encryption

Communication between the nodes and with the client follow the principle of a REST API, and can be configured in 3 modes:

• HTTP for unencrypted communication.
• HTTPS for TLS encrypted communication. To enable this mode, you will need to install a private key and certificate on each node.
• HTTPS insecure is a mode where data will be encrypted but the certificate validation is disabled. This mode works well with self-signed certificates that can be generated automatically.

By default, the HTTP mode will use the standard port 80, while the HTTPS and HTTPS insecure modes will use the standard port 443. However, you can specify another port as necessary during the cluster configuration that we will review later on.

All the EC2 instances running the nodes of the cluster should be protected by a EC2 Security Group that will leave open the selected protocol and port.

Passwords

The access to the cluster is protected by different levels of passwords that can be specified during the configuration that we will review later on:

• PASSWORD: client password used to submit jobs
• ADMINSPASSWORD: client password to access restricted actions such as aborting a job
• CLUSTER_ADMINSPASSWORD: password to administrate the cluster
• CLUSTER_TOKEN: password letting the nodes communicate among themselves

Note that these properties must have the same values for all the nodes in a cluster.