You can replicate your web GIS to a disconnected standby deployment. If your primary deployment fails or becomes inaccessible, you can fail over to the standby deployment.
Standby deployments typically run on a different network or subnetwork, or even in a geographically separate location from your primary deployment. Wherever you place the standby deployment, be sure your web GIS clients can access it when it is needed.
Geographic redundancy
You can implement geographic redundancy if your primary data center and standby data center are in geographically separate locations. If one data center experiences a catastrophic event, such as a hurricane or other natural disaster, you can make the standby data center active and operations can resume.
Geographic redundancy has specific requirements to be successful.
- The primary and standby environments must be duplicated. Each data center must have the same number of machines in the web GIS, and the machine host names must be the same.
- Geographic redundancy typically follows an active-passive approach; therefore, data and content must be replicated to the standby web GIS consistently.
- Geographic redundancy relies on third-party components to be successful. For example, a global site selector or global domain name system (DNS) server is important so that when a switch has to occur from the primary data center to the standby, there is no disruption to any web GIS users.
To ensure the least amount of downtime in event of a failure or catastrophe, you could deploy a highly available, geographically redundant web GIS. This is the most complex deployment to achieve, as it requires the most machines and the most maintenance. Configure two separate data centers, each with their own highly available web GIS deployment. In each data center, all the machine names are configured identically and there are no single points of failure, which include the data, whether it resides in a highly available file server or highly available database, all web servers and load balancers, as well as the web GIS components. Backups of the primary web GIS are consistently created, and restoration to the standby web GIS in the separate data center can occur immediately or when a failure in the primary web GIS occurs.
Planning for a replicated deployment
First, determine how many machines you require. Next, plan for the following disaster recovery requirements for a replicated web GIS:
- Duplication—Ensure both data centers and web GIS deployments contain the same architecture.
- Replication—Back up content and data from the primary data center and restore to the standby.
- Monitoring—Review logs to determine when a failure occurs and determine whether the severity of the failure requires you to fail over to the standby data center.
- Fail over—Decide whether to fail over to a different component within the web GIS or fail over the entire web GIS to a different data center.
Determine machine requirements
The number of machines you need depends on how you configure your web GIS. At a minimum, you need two machines. If your web GIS does not store a lot of data and services and not that many people access it, you can configure a primary deployment comprised of a single-machine ArcGIS Server site, and install Portal for ArcGIS and ArcGIS Data Store on the same machine. You need a second machine to store the replicated standby deployment.
If your web GIS is more heavily used—for example, if a large number of people access it, your organization stores a large number of items, or your deployment is heavily edited—you may need a single or multimachine ArcGIS Server site, and you should install Portal for ArcGIS and ArcGIS Data Store on machines separate from each other and ArcGIS Server. If you publish multiple hosted scene layers, you may want to configure ArcGIS Data Store to store the scene cache databases on another machine. In this case, calculate the number of machines required using the following formula:
(<number of ArcGIS Server machines> + 1 Portal for ArcGIS machine + <number of machines in the data store>) X 2Note that additional ArcGIS licenses are not required for the standby deployment because it is not actively accessed; you only make it the active deployment if the primary fails.
Duplicate deployments
Within a web GIS, there are various dependencies you must account for that typically revolve around accessibility. Map services rely on data in a shared folder or accessed through a database connection. Machines within the web GIS communicate with each other through specific URLs, for example, such as how ArcGIS Server and Portal for ArcGIS communicate in a federated environment. For these reasons, a web GIS in one site must be duplicated in another so every component (for example, host name, folder location, database name, and URL) within the web GIS in each data center is the same. Network-attached storage (NAS) devices that store file geodatabases or Portal for ArcGIS and ArcGIS Server configuration files need to be named the same so the standby web GIS can successfully connect to the resources. All the web GIS components must be installed in the same directories within each web GIS. Finally, the number of machines should be identical between the data centers, as performance issues can arise if less machines are available to respond to user load. Note that you can use DNS entries or modify hosts files on the machines to achieve host name consistency.
Replicate your web GIS
Portal for ArcGIS includes a tool—webgisdr—that allows you to export portal content, federated GIS servers, and ArcGIS Data Store content (relational and tile cache) to a file that you can move to the standby machine to restore. The tool maintains Portal for ArcGIS, ArcGIS Server, and ArcGIS Data Store configured settings, and copies all content created in the portal as well as data that's copied to the GIS server and data store while publishing. Note that the tool does not copy data from databases or folders registered with the GIS server, for example, data in a database or file geodatabase data. It is up to the organization to replicate that data to the standby web GIS.
You can run the webgisdr tool as a scheduled task within Windows Task Scheduler or as a cron job within a Linux environment. Additionally, the tool can be moved to and run from a different machine than the portal installation as long as communication is open between the machine where it's running and the web GIS components.
It's up to you when to restore the web GIS backups to the standby deployment. If you restore backups as soon as they're exported from the primary web GIS, the standby deployment, minimal data loss or downtime will occur in the event that the primary deployment fails. If you do not immediately restore backups, there may be additional overhead in importing the backup and failing over to the standby web GIS. Also consider, though, that if something is incorrect in a web GIS when the backup is created and there are automated processes to import the backup to the standby, those incorrect settings will be imported to the standby web GIS.
See Configure disaster recovery for instructions on replicating a web GIS deployment.
Monitor your web GIS
Monitoring is important in both a replicated and highly available environment. In a highly available environment, certain parts of the deployment fails over without human intervention. For example, if the primary portal in a web GIS fails, the software immediately fails over to the standby without any human intervention. Similarly, GIS server and ArcGIS Data Store components can fail, and the system can function as normal as there are no single points of failure. Considering there may be no visible disruptions in the web GIS, you should put mechanisms in place to notify administrators of failures on any particular component within the web GIS. For example, Python scripts can be configured to query the Portal for ArcGIS and ArcGIS Server logs periodically to check for messages that indicate a failure of a particular component. If a failure occurs, the script can be written to send emails or notify administrators that attention is needed. Querying the logs through the Portal for ArcGIS Administration API and ArcGIS for Server Administration API can be effective ways to check for issues.
In a replicated environment, failover requires human intervention; therefore, you must monitor your deployment to determine when failures occur so you can decide if a failover is necessary.
Failover
Within a web GIS, Portal for ArcGIS, ArcGIS for Server, and ArcGIS Data Store have their own internal mechanisms to fail over. In a highly available configuration, each component can fail over without significant disruption to the overall web GIS.
Failover of a replicated deployment from the primary to the standby data center typically involves the organization's IT department and can be achieved through a global site selector (GSS) or global DNS. Members of an organization typically reach their web GIS through a few URLs, for example, https://my.organization.com/arcgis for the public portal URL and https://my.organization.com/server for the public services URL. The GSS or global GNS can assign an IP address to the my.organization.com hostname. If you need to fail over to a different data center, the GSS or global DNS will reassign the my.organization.com hostname to the IP address associated with the standby data center. Clients and users will not be affected, but all requests are sent to the standby data center. Once the primary data center is back online, the IP address for my.organization.com can be reassigned to an IP address within the original data center. You would then need to reconcile data from the standby to the primary to ensure the primary data center contains all of the new content and data that was created while the standby was active.
If data in any of the GIS server's registered databases (enterprise geodatabase or database) was edited, use database replication tools to ensure the original primary web GIS contains that updated data. If data in file-based data sources, such as file geodatabases, registered with any of the GIS servers in the web GIS has changed, copy edited files to the original directory it was stored in. Finally, use the webgisdr utility to export a web GIS backup from the standby and import it to the primary. The tool will replicate the content in the portal, including associated hosted feature layer data and new nonhosted services registered with the portal, to the original primary web GIS.