This configuration is a variation of the single-machine high-availability (active-passive) deployment, where the load balancer is configured to spread the load across all sites at all times. In this configuration, there are no standby sites.
In this architecture, two or more sites are configured behind a third-party load balancer to increase the capacity of your ArcGIS Server deployment. You can use this technique to accommodate some of the high-availability limitations described in the single-machine deployment and single-machine deployment with reverse proxy server deployment scenarios, or to scale up by adding more machines.
While you can scale up and achieve high availability by using multiple-machine sites, there are advantages and limitations to active-active deployments, which are discussed below.
At a high level, the idea behind the single-machine active-active architecture is to clone a single-machine site and place independent instances of it behind a load balancer. Technically this configuration cannot be described as a multiple-machine site, because each of the sites is independent of each other, composed of a single ArcGIS Server machine, and has its own local configuration store and server directories.
Multiple-machine ArcGIS Server site deployments greatly simplify server administration. However, the active-active architecture can be used in scenarios where the number and settings of services are well defined, remain static, and can provide significant performance advantages over multiple-machine sites, especially for cached map services.
ArcGIS Server machines, server directories, and configuration store
Each ArcGIS Server machine must have its own local configuration store and cache, jobs, and system directories. This ensures maximum performance and keeps interdependencies to a minimum. Conversely, the output directory (or directories) must be shared between each site. For additional details, see Other considerations below.
Apply the same considerations here as described in the single-machine high-availability (active-passive) deployment.
Reverse proxy server
In this configuration, a third-party load balancer is required. At a minimum, this component distributes the load across all the sites. Load balancers have different configurations for distributing the load, such as round robin and least connections. Selecting the right load distribution depends on the web services you have running on the ArcGIS Server sites, and their patterns of use. Load balancers also typically leverage different options for handling failures. For example, you might apply rules in your load balancer preventing it from forwarding requests to a machine that is unavailable due to a hardware or network failure or a particular ArcGIS Server service that is not available. If using single-machine sites as proposed in this pattern, requests sent to a particular machine are guaranteed to be handled by that machine.
Typically, the load balancer itself also fulfills the role of the reverse proxy server as described in Single-machine deployment with reverse proxy server. In some scenarios, you may have already configured a reverse proxy server independently from the load balancer.
If your network load balancer supports a health check function, you can use ArcGIS Server's health check endpoint to determine if the site is available to receive requests. This is useful to quickly determine if there's a software or hardware failure in the site. For more information, see Health Check in the ArcGIS REST API.
The use of ArcGIS Web Adaptor is optional and typically only necessary for this scenario if you would like to take advantage of web tier authentication. You can choose to configure it in the same machine as your ArcGIS Server, or alternatively you can configure it in a dedicated machine. In either case, if using ArcGIS Web Adaptor, you must configure a separate ArcGIS Web Adaptor for every site.
Keeping the services in your sites in sync
Unlike a true multiple-machine site, this configuration requires that all of the sites behind the load balancer host exactly the same content and that they follow the same security model. You are responsible for ensuring that all the sites look exactly the same to the load balancer.
There are multiple techniques that can help you keep ArcGIS Server services in sync across the primary and failover sites:
- Scripting: ArcGIS Server includes a RESTful administrative API that you can use to script
administrative tasks, such as publishing services and changing their
security settings. You can create your own scripts to apply changes
to all the ArcGIS Server machines involved in your deployment consistently.
Scripting is especially useful when you need to make small
adjustments, such as changing the security of a service or
overwriting it. For more information, see Scripting ArcGIS Server administration.
Do not use a script to create the initial site. Manually create the first site on a virtual machine image, and script creation of additional sites from this base image. Creating all machines from the same virtual machine image ensures that all machines use the same encryption key.
- Virtualization: Create a virtual machine template and use it to launch new sites. As mentioned above, this ensures all machines use the same encryption key. In addition, each template will have a copy of the data needed for GIS services (unless a database is used) and all published and configured services. If changes are necessary, such as adding or updating existing services, create a new template to launch subsequent virtual machines that would replace the existing pool of ArcGIS Server machines in use under the load balancer. You can also use virtual machine templates to recover stale ArcGIS Server machines.
The recommended procedure to apply changes to your sites in this deployment pattern is as follows:
- Make administrative changes against a site that is in standby mode first. For example, add a new service and change the security of another in a site that is not actively handling requests. This ensures there is no impact to applications using your primary site.
- Manually configure your load balancer to hand over all requests to the standby site on which the changes have been made.
- Apply the same changes to the idle site.
- Revert the load balancer so requests are directed back to the original primary site and leave the standby site in standby mode.
Changes to your site in the procedure described above can be applied manually through ArcGIS Server Manager, scripts, or virtual images.
Output directory sharing
Some ArcGIS Server service operations reference resources in one or more output directories. For example, map services can write images to an output directory and reference these images through a URL in the request response. For clients to successfully obtain the image, all sites in your active-active configuration must reference the same output directory. This can be accomplished by placing the output directories on a network resource and sharing them with your sites.
The following is a list of service operations that use output directories:
Asynchronous execution of geoprocessing services
ArcGIS Server geoprocessing services support two execution modes: synchronous and asynchronous. Synchronous execution follows a stateless request-response pattern and is completely supported in an active-active configuration. Asynchronous execution follows a stateful request-response pattern and is the default. In order to use asynchronous execution in an active-active configuration, you'll need to consider the following:
- When submitting an asynchronous geoprocessing job, you're returned a job ID that refers to the submitted job and its outputs. Only the ArcGIS Server site that receives the original can recognize this ID. For this reason, the active-active configuration requires you to define affinity in your load balancer (also known as sticky sessions) if you would like to use asynchronous execution. This helps provide high availability for asynchronous geoprocessing and map service outputs. Refer to your load balancer vendor to understand the implications of enabling sticky sessions.
- If your geoprocessing service does not use map services to render outputs and no outputs of type 'File' have been defined, you can select synchronous execution for your geoprocessing services. No sticky sessions in your load balancer are required.
Using token-based security
If using token-based authentication, also referred to as GIS tier authentication, it is important that all sites in this configuration use exactly the same shared token key. Otherwise, tokens generated for one machine will not be valid when used against the other machine. To learn how to duplicate the shared token keys across multiple sites, refer to About ArcGIS tokens and Editing token settings in Manager.
- Conceptually straightforward. Minimal interdependencies between ArcGIS Server machines make it easy to replace stale or faulty machines, apply upgrades, or add and remove machines from the pool of ArcGIS Servers as needed without interrupting services or aborting requests.
- If map tiles are stored locally on every machine, this configuration provides significant performance advantages as compared to multiple-machine sites. In fact, this configuration is ideal if your objective is to increase the capacity of cached map services.
- It is your responsibility to keep all sites in sync. This adds an administrative overhead that can make this deployment pattern impractical for cases where you have many machines or services/caches that change frequently.
- Requires knowledge of third-party load balancers.