Try our new documentation site (beta).
Deployment Architecture
The goal of Gurobi Cloud for Azure is to let you install and use your own servers running on Azure to perform optimization tasks. The client can run on-premise (laptop or workstation) or on the Cloud as well (another Azure 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 Azure 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 Azure 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 Azure, your Azure 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 Azure instance can be configured as a distributed worker. In this case, there is no Gurobi license charge for the Azure instance, but that instance is unable to solve models on its own (You are still responsible for the Azure machine charges). To use distributed algorithms, you should configure one Azure instance as a Compute Server, and configure one or more additional Azure instances as Distributed Workers. When using Distributed Workers, you will get the best performance when all the workers are the same Azure instance type, and all are in the same Azure 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 Azure 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 Azure 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 Azure, you will need to make sure that each Azure
instance of the cluster has a public DNS name or IP 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.
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.
