The following considerations are organized around the architecture pillars of the ArcGIS Well-Architected Framework. The appropriate application of best practices and architectural approaches in each of these technical areas contributes significantly to the successful design and implementation of well-architected systems.
You can also refer to these physical design considerations for additional recommendations.
We chose to design for workload separation to help achieve an optimal distribution of compute resources across the system. In the test study, editing requests generally took longer to process than standard map requests, so we isolated editing workloads with dedicated compute resources in the form of a separate ArcGIS GIS Server site.
Additionally, isolating the system components themselves onto different machines helps to ensure they don’t compete for system resources and allows for the opportunity to tailor machine types and sizes to the system requirements of each component.
Selecting the proper GPU (Graphics Processing Unit) is essential for ensuring the performance of ArcGIS Pro in a virtualized environment. Tests revealed that adding a dedicated GPU to ArcGIS Pro virtual machines significantly improved end-user productivity and produced a net reduction in cost when operational expenses, such as labor costs, are considered.
It’s important to understand the ratio of virtual CPU (vCPU) to physical CPU when making design decisions so system components may be assigned appropriate resources. There is a 2:1 ratio of vCPU : CPU for most of the instances in the diagram, apart from our Desktop instances, which have a 1:1 ratio.
Consider that different virtualization options may have different ratios. In addition to potential performance impacts, this may also have Esri licensing implications. For examples of public cloud ratios, see the following resources.
Proper configuration of GIS services is critical to system performance and user experience satisfaction, and the misconfiguration of GIS service instances can introduce problems or reliability challenges in a system. For example, if the number of instances for a map or feature service are set too low, it can result in long client wait times and timeout errors. However, configuring too many instances consumes excessive machine resources, limiting the number of services that can be deployed on a fixed hardware configuration.
When the maximum instance setting is higher than the minimum, the system can automatically add new instances in response to demand. However, this can also cause perceived performance problems, since incoming requests must wait for the instance to start. For any system, it is important to understand service usage so that instance numbers and server resources can be adjusted to provide optimum performance.
For our testing purposes, the ratio of service instances to vCPU (virtual CPUs) was set to 1:1 for each service, with the minimum and maximum instances set equally. Therefore, since our GIS and hosting server sites each had two instances with 8 vCPU, we had 16 instances per server site. The instance usage was monitored to determine how the system was handling the load. If at any point all instances on a GIS server become busy, we would expect high wait times for that service.
This was the optimal service instance configuration for our test system, but your organization’s configuration may differ. Monitoring and telemetry capture are necessary to make informed choices for configuring your own service instance settings. See The art and science of ArcSOC optimization for guidance.
In this test study, the parcel fabric editing services were configured as follows:
The hosting servers (view-only workflows) were configured as follows:
The specified service timeouts were configured as follows:
Our timeout configuration was adjusted iteratively to address timeouts encountered during the testing process. Since these settings may vary based on specific requirements, it is recommended to conduct your own testing to identify the most optimal configuration.
Backups are critical for Parcel Management Systems, like most data editing and management focused systems. While the tested design was not a production system, we did capture machine snapshots and database backups for each test run and before making any changes to the system. Virtual machine snapshots were taken before and after any change in the environment, such as resizing a machine, installing a patch, or updating Windows. Snapshots were then cataloged to enable either:
Note that snapshots may not be enough to enable you to recover your environment. See Backups and disaster recovery for an overview of the backup process in ArcGIS Enterprise.
Refer to the Land information management system reference architecture for more information.
The choice to design this system with a high availability configuration of ArcGIS Enterprise components was made based on business and technical system requirement, along with other organizational goals such as achieving uninterrupted operations and minimizing downtime. This configuration is illustrated in the design with redundant system components and a cloud-native, highly available file store for file storage. This test study did not configure a highly available database for testing purposes, though relational database vendors have a variety of methods to approach high availability including cloud-native services.
Keep in mind that high availability configurations can significantly increase infrastructure and operational costs of the system and requires specialized skills to be successful. Learn more about design choices and considerations with regard to high availability for a Parcel Management System.
To perform successful system validation and deliver meaningful results, system monitoring and telemetry capture were key aspects to the test study.
ArcGIS Monitor and enterprise IT monitoring tools like Windows Performance Monitor were used to monitor the system’s performance and capture telemetry on its behavior under certain conditions. Logs were collected across different system components, including:
Machine-level metrics such as CPU usage, RAM consumption, disk activity, and network activity were captured across all machines in the environment. Review the test results for more information.
Additionally, screen recordings were captured of conducted workflows to observe and assess end-user experience and productivity.
Because the scope of the test study was primarily focused on load testing, most types of automation that would be recommended for a production system, such as scripting administrative tasks, were not employed. However, in your environment, administrative scripts can have significant value to workflows and operations. Any automation scripting should be tested in a lower environment before deploying to production.
In this test study, the primary application of automation was for the purpose of simulating requests during load tests. Multiple workflows were run with virtual users at scale with the ability to apply to different load sizes, as illustrated in the test results.
We used Python scripts to perform analysis on and identify patterns in service wait times, services instance utilization, response times, and failed requests to inform needed system changes. Python, PowerShell and SQL scripts were also used to restore the database to an original state after completing a load test.
Security is an essential consideration for any enterprise IT system, including authentication and authorization, filtering, encryption, auditing, and hardening. ArcGIS software is architected to work effectively within secure networks, including those that are fully disconnected from the internet. It is critical to consider security requirements early in the design process for any production system.
While security was not a focus for this test study, we did include the use of an identity provider to provide proper user authentication and authorization, as seen in the physical architecture diagram. Subnet segmentation is another foundational security practice applied in this test study, rooted in the principles of least privilege and network isolation.
Related resources:
While integration was not within the scope of the test study, a Parcel Management System often requires integration with other enterprise systems like Computer Aided Mass Appraisal (CAMA) systems. Learn more about integration considerations with ArcGIS.