Single-machine high-availability (active-passive) deployment
In this topic
- GIS server, server directories, and configuration store
- Data
- Reverse proxy server
- Other considerations
- Advantages
- Disadvantages
To eliminate a single point of failure in your GIS server tier, a single-machine ArcGIS Server site can be configured in a failover fashion with the inclusion of a third-party load balancer.
At a high level, the idea in this deployment pattern is to clone a single-machine site and place two or more independent instances of it behind a load balancer with an active-passive configuration. While all the sites behind the load balancer are running and ready to service requests, the load balancer will only hand over requests to one of the sites, designated as the primary site. If the load balancer detects that the primary site is unavailable, incoming requests are then redirected to a failover or standby site.
The failover process is handled completely outside of ArcGIS Server and can be typically configured to be triggered when the GIS server machine is completely unavailable (network or hardware failure), or in some cases, when a specific GIS service or operation is failing.
Note:
You can request license files from My Esri for your standby or failover sites at no additional cost.
While several machines are used to host GIS servers in this deployment pattern, this configuration cannot be technically described as a multiple-machine site, because each of the sites behind the load balancer are independent of each other. Each site is composed of a single GIS server and has its own local configuration store and server directories.
GIS server, server directories, and configuration store
Apply the same considerations here as described in the single-machine deployment. Each GIS server will have its own local server directories and configuration store. This ensures maximum performance and keeps interdependencies to a minimum.
Data
If using file-based data sources in your GIS services, it is recommended that these be stored locally on every GIS server instead of network shares to maximize the performance of your services. In some cases, such as when handling large amounts of imagery, sharing your files over the network may be the only practical choice. If using files in shared resources over the network, it is very important that you choose a storage device configured for high availability.
If using databases, you can dedicate a database to each of your sites: one database for your primary site and a separate one for your standby site. To keep the databases in sync, you can leverage database replication, or if needed, geodatabase replication techniques. Alternatively, you can leverage other high-availability techniques from your database provider.
Reverse proxy server
In this configuration, a third-party load balancer is required. At a minimum, this component will be used to handle the load across the sites and failover when necessary. Typically, the load balancer will also fulfill the role of the reverse proxy server as described in the Single-machine deployment with reverse proxy server. In some scenarios, you already may have a reverse proxy server configured 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 leverage web tier authentication. For simplicity, you can choose to configure it in the same machine as your GIS server. Alternatively, you can configure it on 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 that 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.
Asynchronous geoprocessing and long-running tasks
When the load balancer switches to the standby site, any active requests in the primary site are lost. For example, if a long-running request such as a geoprocessing task is running when the failover occurs, the task will need to be reinitiated in the standby site by the client application.
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 in the primary site will not be valid when used against a standby site. To learn how to duplicate the shared token keys across multiple sites, refer to About ArcGIS tokens and Editing token settings in Manager.
Advantages
- The active-passive failover configuration allows you to build a redundant GIS server tier without incurring additional licensing fees. Standby servers can be licensed at no additional cost.
Disadvantages
- Each site behind the load balancer is independent of the other. Each site must be managed separately; the sites have their own local configuration store and server directories. This can potentially add significant administration and management overhead if the site's services or data change frequently.
- When switching to the standby site, any active requests in the primary site are lost.