The deployment model illustrated below can be implemented to ensure both High Availability and Disaster Recovery. Here, both Orchestrator nodes are active and the Load Balancer directs traffic to them using a specific algorithm, such as Round Robin or one of its variants.
This configuration requires good network connectivity between the datacenters, which are located in different geographical areas. The model can be implemented on premises or cloud-based. For cloud deployment, you need to pick different regions for the primary and secondary locations.
Note:
This deployment model requires the following:
- SQL Server 2012, or later, and High Availability add-on for Orchestrator. Earlier versions of SQL Server do not support AG, and an Active-Active configuration is not supported by open-source Redis.
- Two High Availability add-on licenses.
In order to provide High Availability for the Network Load Balancer (if the NLB is located in the Primary Datacenter), a secondary NLB should be provided in the Disaster Recovery Datacenter. The two NLBs need to be placed in a Primary-Secondary (or Master-Slave) configuration.
In the same datacenter, one NLB can be used, with different Virtual Servers (VIPs) for Ochestrator and Elasticsearch. This same NLB can be used to optimally distribute loads to Orchestrator and Elasticsearch nodes.
The Always On availability group feature can be composed of minimum 2 machines:
- Primary DB in the first data center;
- Secondary DB in the second datacenter.
Note:
Minimum three nodes are required for both HAA and Elasticsearch in each datacenter, configured in different clusters and synchronized.
See here the prerequisites, restrictions, and recommendations for Always On availability group.
Updated 9 months ago
See Also
About Physical Deployment |
Web Server on a Single Machine |
High Availability |
Deployment in the Cloud |
Disaster Recovery - Active/Passive |