At some point in your career administering ArcGIS Enterprise, you will likely need to upgrade it to a newer version to take advantage of new functionality in the software.
If your deployment has a high service level agreement (SLA), such as ones involved in disaster relief or emergency response, it may be challenging to know how to upgrade without affecting availability or introducing downtime.
This blog is intended to describe the different options that are available, and what we’ve done at ArcGIS Enterprise 10.8 to better support upgrades for these critical systems moving forward.
Upgrading a highly available Enterprise – a double edged sword
When you’re ready to upgrade ArcGIS Enterprise, there are two approaches you can take:
- Upgrade your production environment (common approach)
- Upgrade a mirrored, standby environment (less common approach)
These approaches have their own challenges: you need to choose to bring down your deployment or identify a strategy to either prevent users from creating content or simply re-create the content when the environment is upgraded. Let’s go into each of them in a bit more detail.
Upgrade your production environment
Upgrading your production environment simply involves running an in-place upgrade, which is described in a blog and documentation. However, the challenge with this approach is that the deployment will be unavailable during the upgrade process. The time it takes to upgrade the environment can be significant if the deployment is highly available or has a number of additional federated servers or servers with additional capabilities, (GeoAnalytics, Image Analysis). For some organizations and deployments, the amount of downtime incurred during the upgrade may be acceptable. For other organizations or deployments, such as systems supporting emergency response, you may not be able to afford any downtime. An administrator within environments where ArcGIS Enterprise acts as a critical component within daily operations will need to figure out how to upgrade while maintaining some level of availability.
Upgrade a mirrored environment
There’s a good chance that an organization that is dedicated to making sure their GIS meets a certain SLA has already implemented disaster recovery using geographic redundancy. If you haven’t, then this is a good opportunity to think about whether that approach fits into your disaster recovery plan. You can read more about it here.
Essentially, it involves setting up a mirrored environment in a separate data center and ideally, in a different geographic region, and replicating content to it on a scheduled basis. In the event that your primary environment goes down, you can flip over to the secondary environment to continue normal operations:
In the context to upgrades, having a standby environment available gives you the opportunity to upgrade one of your environments without affecting the other. For example:
In this scenario, disaster recovery was being used to minimize data loss and downtime in the event that the primary data center went down. Backups are taken from the primary environment and restored to the standby environment. The intent is to upgrade the primary environment, so the first step would be to send traffic to the standby environment. This ensures that users can still access ArcGIS Enterprise and complete the important tasks they’re meant to perform, albeit to the standby environment.
Once traffic is directed to the standby environment, the primary environment can be upgraded. This step also gives an administrator the peace of mind that they don’t need to rush through an upgrade because end users are unable to access the GIS.
If something unexpected occurs (the upgrade fails or there’s an issue discovered after the upgrade), the administrator has the opportunity to investigate instead of rolling back to a previous pre-upgrade snapshot.
Once the administrator is ready, they can send traffic back to the primary environment, which is now upgraded and ready for users to take advantage of new functionality and features. The standby can then be upgraded while users interact with the deployment as they normally would.
A problem with this approach is that there is no governance at the software level to prohibit users from creating or modifying content. Throughout the time it takes to upgrade the primary environment, users can create applications and services, share items with groups, run analysis, and perform any other actions that create or modify content.
Once the upgrade is complete and traffic sent back to the primary site, those changes they made will be gone. Users will need to redo any changes that were made, which doesn’t lend itself to be a great experience.
Setting up a mirrored environment
If you don’t have a second data center to set up ArcGIS Enterprise in, we have written a blog on how to replicate content to a new site. The context to the blog is to help users migrate to new machines, such as when you’re upgrading the operating system or hardware of an existing deployment.
That blog can be followed to set up a new deployment in preparation of a minimal to no downtime upgrade.
Looking ahead
At version 10.8 of ArcGIS Enterprise, you can now set your deployment to read-only mode. This freezes the state of the content and setting within your deployment. Users (even administrators!) won’t be able to create new content, update or delete existing content, and limited administrative changes can be made. You can read more about read-only mode here.
Within the context of upgrades, read-only mode can eliminate the risk of managing data differences and the potential for data loss. By enforcing governance at the software level, you can upgrade your standby environment from 10.8 to a later version while your production environment remains accessible and read-only. This ensures that data won’t change within your production environment while the standby is upgraded.
Stay tuned for this blog to be updated when the next release of ArcGIS Enterprise after 10.8 is available where we’ll discuss this approach in more detail.
Wrap-up
As GIS continues to move into more business and mission critical applications, it’s increasingly important to make sure it’s available as much as possible.
On the other hand, each new release introduces new new functionality that an organization may want to take advantage of. In order to do that, deployments need to be upgraded, which can be challenging given SLA requirements. If you take the right steps, your organization can upgrade while maintaining availability for the users of your ArcGIS Enterprise deployment.
About the author
Article Discussion: