An important step of any architectural design process is the recommendation of a physical design for a system. Physical design generally refers to the hardware and configuration specifics of the actual components that are deployed based on a logical architecture design – the virtual machines, storage, databases and networking components that must be created to move the design into implementation. In addition, physical design addresses issues like performance, scalability and system deployment. The technical or capacity aspect of the physical design concept often defines specifications like CPU type, hard disk size and type, memory types and amounts, or networking interfaces and capacity.
For many years, the careful design of the capacity definition of a system was crucially important as most new systems included a significant capital expenditure to purchase new servers or other types of hardware. Purchasing and deploying physical machines to data centers was an expensive part of the deployment process and usually involved the expectation of a multi-year usage period, so getting the size right on the first attempt was valuable and important for cost controls. Physical hardware on a controlled computing environment is infrequently changed or upgraded after deployment, and carries significant support and management requirements, so the cost of adding capacity to a system was traditionally a significant burden.
Today, the use of virtualization technology throughout public and private cloud patterns is widespread, and the importance of up-front capacity planning has changed – it became easier to change the size of a specific virtual machine in terms of the compute and memory allocated to that virtual server, while adding disk space for storage or virtual network interfaces has become a software configuration instead of a hardware acquisition. The physical hosts and network that the virtual servers are built on are still important considerations during design, but virtualization generally reduced the focus on building a server of a specific specification at the outset, in favor of a starting size with the option to increase or decrease resources in a future review. This shift in approach also suggests a shift in approach to the capacity planning process, while still retaining the importance and value of this step.
For information about various system and deployment patterns in ArcGIS, see Anatomy of a system pattern.
These physical design considerations are most relevant to ArcGIS Enterprise-based systems, where the architecture and physical resources are subjective and must be designed as part of the architecture process. In contrast, physical design considerations do apply to fully managed systems, where infrastructure is handled for you, such as ArcGIS Online (SaaS) and ArcGIS Location Platform (PaaS) offerings. See ArcGIS-specific considerations and cloud options in the ArcGIS Trust Center for additional guidance.
The physical design stage of an overall system design should always occur after the overall solution has been planned and understood. At this stage, some decisions you may expect to make in designing your system include (but are not limited to):
These details will help to guide how the physical design is developed, and any questions in these areas will need to be answered as part of the design process.
The best practice approach to designing the physical architecture of a modern ArcGIS Enterprise system is as follows:
This focus on informed hardware decisions relies on clear testing approaches and active monitoring of software and hardware components. This approach is a best practice because it balances initial costs (not over-investing in a system before there is evidence of a need) with flexibility, allowing for the impact that growing and changing use of a system will have on hardware resources.
Common considerations for physical design include those relating to operating system virtualization, CPUs and GPUs, network design, and storage. Additional details for these considerations are provided.
While it is supported to install ArcGIS software directly onto the operating system of physical hardware, the majority of modern designs rely on operating system virtualization where ArcGIS software is installed on a virtual machine.
This approach allows for better use of hardware resources, as it provides key features like VM snapshots, disk expansion, resource re-allocation or network virtualization. Virtualization software also generally provides excellent hardware monitoring and profiling tools to aid in further physical design adjustments based on user activity and system utilization.
ArcGIS software is supported on any virtualization system, provided it offers a supported operating system for that particular component and release. As such, it is recommended for organizations to use existing virtualization experiences and resources wherever possible.
In any deployment, whether on physical hardware or virtual machines, the type and capacity of CPU resources assigned to the system plays a critical role in the system’s performance, scalability, and successful handling of the expected user load.
CPU resources are used to process all user requests, whether for static files, REST requests, or complex resources and asynchronous workflows. In contrast, GPU resources are more specialized, and are more applicable to ArcGIS Pro workloads, machine and deep learning workflows such as those for raster analytics services, and for geoprocessing tools that make use of GPU resources when published to an ArcGIS Server site.
GPUs are generally provided as virtual infrastructure (software emulation of a GPU) or physical resources that are attached and dedicated to a virtual machine. While emulation may suffice for some basic workflows such as simple data management or publishing a service, any serious use of ArcGIS Pro or deep learning packages will likely benefit from a hardware GPU resource. For more information about CPU and GPU considerations in ArcGIS Pro, see General-purpose computing on a GPU.
Network architecture is another important consideration to the physical design process. While network structure, connectivity, and resources are usually defined at an organizational level, and inherited by a specific business system like ArcGIS, some physical design considerations can be introduced or reinforced to network design during the design process. Recommendations in the context of network design are provided.
Locate clients close to systems and data – In this context, the word close means within the same low-latency network or sub-network, where clients can communicate quickly with ArcGIS system components and any relevant data sources or storage. Many ArcGIS applications send multiple or parallel requests to storage, databases, and other components, so latency can have a significant impact on system performance.
Maintain network boundaries and guard external access – Networks must be designed with a security mindset and least-privileges approach. The ArcGIS Enterprise documentation provides a comprehensive set of ports and communication patterns that must be allowed between ArcGIS Enterprise components for successful functionality, along with a corresponding diagram of connectivity requirements.
Use WAFs, firewalls and network filtering carefully – Many systems use web application firewalls or other network protection and filtering software to guard against malicious requests or activity. These components can provide excellent functionality but should be designed and implemented carefully to ensure that the protective actions do not negatively affect ArcGIS functionality.
There are several different types of storage that are relevant to physical architecture design. Disk storage generally refers to the attached disks (virtual or physical) that are exposed to the OS of a virtual or physical machine in a traditional Windows or Linux deployment. These disks generally come in several different types, and include quoted data storage capacity and disk speed information, sometimes using a metric such as Gigabytes per second (for access speeds to storage) or revolutions per minute (RPM, such as 7.2K or 10K).
Other types of storage include network-attached storage, storage area networks (SAN), virtual file systems from various software and hardware providers, different RAID configurations for durability and reliability, or cloud storage systems like AWS FsX or Azure Files. Each of these systems should be carefully reviewed and considered as part of a physical design recommendation, as they have different features, strengths and weaknesses. NAS storage configurations are especially important to ArcGIS Server sites, and the software documentation provides specific guidance on selecting a NAS device.
Storage is especially relevant for components where a lot of reading and writing activity occurs, such as the ArcGIS Server configuration store, or a disk that is used to host a relational database. In these cases, the speed and throughput of storage can have a significant material impact on the performance of the system. Ensure that the storage you use can be monitored for utilization, and when performance testing takes place, check that storage speed is not creating bottlenecks before compute throughput is maximized.
In addition to the common design considerations outlined above, other ArcGIS or product-specific considerations also apply to physical design, and details for these are provided.
For organizations using ArcGIS Online, there are fewer active physical design choices to be made as part of a system design, as a SaaS system, the design of backend compute, storage, or memory is largely managed by Esri, and is not configurable or adjustable per-organization.
ArcGIS Online offers various options for feature data storage, including Standard and various Premium sizes. The type of storage chosen can affect the throughput and overall performance of hosted feature services in an organization. The Premium Feature Data store provides dedicated storage capacity and compute capacity to an organization, which can assist with more complex workflows or higher throughput processes. For additional information, see options for the Premium Feature Data Store.
Consider the impact of client hardware configuration of that client’s use of ArcGIS Online. For example, a complex web app that includes 3D and WebGL content may display poorly on a device with lower hardware specifications, and while the client is accessing data from ArcGIS Online, the root cause of a slow perceived performance is the client hardware configuration, not a flaw in the hosting or service configuration in ArcGIS Online.
Most ArcGIS Enterprise architectures include an enterprise geodatabase, which is configured as part of an existing relational database management system (RDBMS). The physical resources dedicated to this database component can have a significant impact on the performance and usability of this component, and should be carefully considered during the design process. Most RDBMS software packages include mature performance monitoring tools, and database management professionals can also consult on the appropriate sizing of these resources.
In the past, Esri has published and maintained a set of tools or resources for physical design, including the Capacity Planning Toolkit. These resources were focused on a traditional method of physical design where the CPU cores and system configuration were more fixed (and not virtualized) and the workflows mostly involved desktop clients connecting to databases and web services. These resources are no longer updated with new processor specifications, and do not accurately capture the more common web-based workflows of a modern ArcGIS system.