Try our new documentation site (beta).
Architecture
Let us now consider the roles of the different Remote Services components. Consider a Remote Services deployment:
![\scalebox{1.0}{\includegraphics[height=.5\textwidth]{graphics/csgraphics/csmanager_multiple}}](https://gurobi-dev.flywheelsites.com/wp-content/plugins/hd_documentations/documentation/10.0/remoteservices/img7.svg)
The Cluster Manager is the central component of the architecture. It provides the following functions:
- Security. The Cluster Manager is in charge of
authenticating and authorizing all access to the cluster. It does
this by managing user accounts and API keys, and by controlling
access to all Remote Services nodes (Compute Servers or Distributed
Workers).
- Cluster Monitoring. The Cluster Manager gives
visibility to all operations on the cluster: available nodes,
licenses, and jobs. It also records and retains job history,
including detailed metadata and engine logs.
- Batch Management. The Cluster Manager controls the
batch creation process and the storage of input models and output
solutions. It also keeps a history of batches. Internally, it
communicates with the nodes to submit and monitor batch jobs.
- REST API. All of the functions provided by the Cluster
Manager are exposed in a REST API. This REST API is used by all
built-in clients: gurobi_cl, grbtune,
grbcluster, and the Web User Interface. The REST API
can also be used by user programs.
- Web User Interface. The Cluster Manager includes a Web Application Server that provides a complete and secured Web User Interface to your Compute Server cluster.
The Cluster Manager is optional. You can build a self-managed Remote Services cluster, but it will be missing many features.
Cluster Manager installation is covered in this section.
The database supports the Cluster Manager. It stores a variety of information, including data with long lifespans, like user accounts, API keys, history information for jobs and batches, and data with shorter lifespans, like input models and their solutions for batch optimization.
How much space does this database require? This will depend primarily on the expected sizes of input and output data for batches. The Cluster Manager will capture and store the complete model at the time a batch is created, and it will store the solution once the model has been solved. These will be retained until they are discarded by the user, or until they expire (the retention policy can be configured by the Cluster Manager system administrator, in the settings section). The data is compressed, but it can still be quite large. To limit the total size of the database, we suggest that you discard batches when you are done with them. Note that discarding a batch doesn't discard the associated (small) metadata; that is kept in the cluster history.
The Cluster Manager can be connected to two types of database servers:
- MongoDB version 4.0 or later, deployed on-premise, on the Cloud, or hosted by a SaaS provider.
- Amazon Web Services (AWS) DocumentDB 4.0 or later, when deployed to AWS.
Cluster Manager users must install and configure their own database as part of the Compute Server installation process. It can be deployed as a single node or as a cluster for high availability.
A Compute Server node is where optimization jobs are executed. Each such node has a job limit that indicates how many jobs can be executed on that node simultaneously. The limit should reflect the capacity of the machine and typical job characteristics. Compute Server nodes support advanced capabilities such as job queueing and load-balancing. Deploying a Compute Server requires a Gurobi license.
Compute Server node installation is covered in this section.
A Distributed Worker node can only be used as a worker in a distributed algorithm. Only one job can run on such a node at a time and it does not support queueing or load balancing. This type of node does not require a Gurobi License.
Distributed Worker installation is covered in this section.
Subsections
