The first step in deploying ArcGIS Enterprise is to design and plan your system architecture. This includes hardware and software components and the connections between them. It also includes human components: the people who will work on your system, the access they will receive, and the accepted practices they will follow.
Ultimately, you’re deploying ArcGIS Enterprise to deliver geospatial content to users in a way that meets their expectations and enables their workflows. Your deployment should be designed to deliver that content and ensure its integrity.
Operating a Web GIS system often involves serving multiple groups of stakeholders and their various requirements, working with hardware and resource limitations, and safeguarding content and identity security from threats. Because of this complexity, it’s important that all aspects be considered in the planning stage.
The best practices below can help you design an effective strategy for operational performance, reliability, and security in your ArcGIS Enterprise deployment.
Environment isolation
When designing your ArcGIS Enterprise system architecture, consider how your organization will develop and test new elements before making them available to end users.
The content that your users rely on for their workflows should be in a separate environment from where development and testing occur. This practice is known as environment isolation; it reduces the risk of unintended changes or deletions to GIS content.
Development, staging, and production
A common model for environment isolation contains three tiers: development, staging, and production. Implementing these three tiers is a minimum best practice; depending on your development and testing practices, you may have additional tiers or levels of quality assurance.
In a development workspace, GIS analysts and developers can work on content and explore new items without impacting a large audience. This dedicated server environment is typically used for unit testing, constructing business workflows, or creating new capabilities. The size and complexity of the environment depends on the level of risk generated by changes, the number of content creators, and the potential impact of system outages and downtime.
A staging environment, of which there can be multiple, is isolated from the end production environment but mirrors that environment as closely as possible. This assures that any problems end users may encounter can be detected during testing. For example, if you use a vector tile layer in custom basemaps for your customer apps and frequently update the vector tile layer, the staging environment should replicate those apps. You can then certify each update to the vector tile layer in each app to ensure there will be no disruption to your customers. All changes to your content should be tested in a staging environment before being deployed to production.
End users, such as field workers, business customers, or automated monitoring systems, should have access to a live production environment. In production environments, you may have service-level agreements (SLAs) that define the acceptable level of downtime. Availability and access should be constantly monitored, and appropriate methods of downtime prevention, such as backups and standby machines, should be available. See High availability in ArcGIS Enterprise for more information.
Do not make changes to software, apps, configurations, or networks in a production system without testing them in at least one staging environment first.
Load balancing
Load balancers take an intermediate position between clients and servers. They identify and accept communications and pass them to the correct recipient, distributing the client’s workload across the available computing resources. In doing so, they improve server security, balance system use, and simplify service delivery.
ArcGIS Enterprise has its own load balancer component: ArcGIS Web Adaptor that can handle traffic to ArcGIS Server sites and the ArcGIS Enterprise portal. ArcGIS Web Adaptor integrates the server site or portal with the web server where it’s installed, handles incoming traffic if there is no additional load balancer, and can enforce web-tier authentication.
Web Adaptor instances distribute incoming requests to multiple-machine ArcGIS Server sites using a round-robin pattern. Including Web Adaptor instances in your deployment is recommended for simple configurations.
More advanced configurations can benefit from using a third-party load balancer. These components can go beyond ArcGIS Web Adaptor functionality to use custom logic (distributing requests in a pattern other than round robin), manage asymmetric loads, and provide added security measures such as reverse proxies. Using a third-party load balancer can help your organization address advanced business and technical requirements.
You should always use at least one load balancer in your ArcGIS Enterprise deployment, whether it is ArcGIS Web Adaptor or a third-party component. Using load balancers helps to limit the number of points of entry to the system, hiding the internal topology of the network and simplifying operations.
Content delivery
While ArcGIS Enterprise can be used as a complete GIS platform on its own, it is designed to work seamlessly with all ArcGIS products. GIS professionals use ArcGIS Pro to create content and share it with ArcGIS Enterprise. Apps such as Collector for ArcGIS and Operations Dashboard provide workflows to enhance or add to the geospatial content in your ArcGIS Enterprise portal. ArcGIS Online can be used to share your organization’s work with the public without using your own digital infrastructure.
Consider how your organization uses or could use each element of ArcGIS. If your field workers use a mobile app to update the data in your maps, for example, you should understand the security implications, the uptime requirements, and so on.
If your organization serves both internal users for operations and transactions (such as GIS analysts, data scientists, and decision makers) and external or public users seeking information, consider setting up separate environments—using either multiple ArcGIS Enterprise deployments or ArcGIS Online.
By separating operational and transactional users from public information users, you can prevent improper access to internal content by external users and reduce the traffic impact on your infrastructure.
Workload separation
Your organization may have multiple groups performing different types of work in your ArcGIS Enterprise deployment. The resource requirements for each function, and the expectations or contracts that govern their work, are often different. For example, one GIS analysis team may need occasional access to powerful geoprocessing resources, while a decision support team may need constant access to less-intensive maps and apps.
During the planning phase of your ArcGIS Enterprise deployment, study the needs and usage patterns of each operational group that will use your system. Then, you can allocate your workload traffic to appropriate server resources and isolate the different geospatial functions based on their resource use.
When you separate the workloads of your organization’s various geospatial functions, the work done by one group won’t affect the resources available to another group. This is important when SLAs govern some or all of your organization’s GIS operations. If you’re under an obligation to provide users with a certain level of availability, isolating their machine resources reduces the risk that other groups’ work will interfere with their available resources.
Techniques to separate your workloads
Workload separation is most commonly practiced by deploying multiple ArcGIS Server sites. A site is a collection of ArcGIS Server machines working on equal terms; requests passed to a site can be assigned to any of its machines.
When multiple sites are deployed, requests can be routed to a site by a load balancer based on the type of request or who sent the request. This protects tasks from resource contention. For example, one ArcGIS Server site can receive all your geoprocessing task requests, while another can receive all map service requests. Your organization’s map services won’t be affected if a large geoprocessing task is being executed and vice versa.
Using load balancers to handle all requests gives you control and flexibility and promotes system stability, as well as improves security by preventing direct user access to your server machines.
Implementing multiple ArcGIS Server sites for separate workloads allows you to assign groups of more or less powerful machines to different sites. This is helpful when tasks being performed on one site are more compute-intensive than those on another site. You can make the best use of your computing resources to achieve the highest level of performance.