Try our new documentation site (beta).
Architecture Topologies
Let us now review a few common deployment configurations.
Cluster Manager with a single node
In this deployment, we only need to deploy one instance of a Cluster Manager with the Database and a single Compute Server node. This is appropriate for small environments so that you can offload simple optimization tasks to one Compute Server.
Cluster Manager with multiple nodes
If you need to handle more jobs concurrently, you will need to add more Compute Server nodes. Also, if you want to run distributed algorithms, several Distributed Worker nodes will be needed. To this end, you can deploy one instance of the Cluster Manager (with a Database), and connect those nodes to the Cluster Manager.
Scalable Cluster Manager
If you have even more concurrent users, or if you need a scalable and
high available architecture, several instances of the Cluster Manager
can be started. In this case, you may need to install and set up a
regular HTTP load balancer (such as Nginx) in front of the
Cluster Manager instances. Cluster Manager server instances are
stateless and can be scaled up or down.
The database itself can be deployed in a cluster. In a MongoDB or DocumentDB cluster, one of the nodes is chosen dynamically as the primary, while the others are deemed secondary. Secondary nodes replicate the data from the primary node. In the event of a failure of the primary node, the Cluster Manager will automatically reconnect to a new primary node and continue to operate.
In this deployment, several Compute Server nodes are also recommended. In the event of a node failure, any jobs currently running on the failed node will fail, but new jobs will continue to be processed on the remaining nodes.
![\scalebox{1.0}{\includegraphics[width=\textwidth]{graphics/csgraphics/csmanager_scalable}}](https://gurobi-dev.flywheelsites.com/wp-content/plugins/hd_documentations/documentation/10.0/remoteservices/img8.svg)
Finally, Compute Server nodes and Distributed Worker nodes can be deployed by themselves, without a Cluster Manager or a Database. This was actually the only option in Gurobi version 8 and earlier. In this configuration, you will not benefit from the latest features: secured access using user accounts and API keys, persistent job history, batch management, and the Web User Interface.
![\scalebox{1.0}{\includegraphics[height=.5\textwidth]{graphics/csgraphics/cscluster}}](https://gurobi-dev.flywheelsites.com/wp-content/plugins/hd_documentations/documentation/10.0/remoteservices/img9.svg)
