Single-machine high-availability (active-active) deployment
In this topic
- GIS server, server directories, and configuration store
- Data
- Reverse proxy server
- Other considerations
- Advantages
- Disadvantages
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 GIS server, 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.
GIS server, server directories, and configuration store
Each GIS server 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.
Data
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 will be used to distribute 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 will depend on the services being hosted and their patterns of use. Load balancers also typically leverage different options for handling failures. For example, you may 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 will also fulfill 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 heath 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 GIS 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.
Other considerations
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 GIS servers 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.
- Virtualization: If you operate in a virtual environment, virtual machine templates can be created and used to launch new sites. Each template will have a copy of the data needed for GIS services (unless a database is used). The template will also have all services published and configured. If changes are necessary, such as adding or updating existing services, a new template can be created to later launch new virtual machines that would replace the existing pool of GIS server machines in use under the load balancer. Virtual machine templates can also be used to quickly recover stale GIS servers.
The recommended procedure to apply changes to your sites in this deployment pattern is as follows:
- Administrative changes will first be made against a site that is in standby mode. For example, you will add a new service and change the security of another in a site that is not actively handling requests. This ensures there will be absolutely 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 may write images to an output directory and reference these images through a URL in the request response. In order 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 will use output directories:
- Creating a feature service replica (feature service)
- Downloading a raster image (image service)
- Obtaining mobile service and mobile layer resources (mobile capability in a map service)
- Exporting a map image (map service)
- Exporting a schematic diagram (schematics capability in a map service)
- Exporting a web map (geoprocessing service)
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 request will be able to 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 will help 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.
Advantages
- Conceptually straightforward. Minimal interdependencies between GIS servers make it easy to replace stale or faulty machines, apply upgrades, or add and remove machines from the pool of GIS 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.
Disadvantages
- 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.