Chapter 5Going beyond the ArcGIS Enterprise base deployment

Objectives

• Review distributed computing principles and appropriate scaling options in ArcGIS Enterprise.
• Explore options to extend ArcGIS Server.
• Discuss ArcGIS Enterprise on Kubernetes.

Introduction

In the previous chapters, we discussed ArcGIS Enterprise in its most essential form—a base deployment. As business needs change, administrators need to be prepared to scale their deployments of ArcGIS Enterprise to meet growing demands. The type of scaling needed depends on the type of work to be completed or performance limitation to be solved. ArcGIS Enterprise supports scaling to distribute workflows and add functionality through ArcGIS Server roles and extensions.

In this chapter, we will focus on what options administrators have when considering how to scale or extend their ArcGIS Enterprise deployments. We will review the basics of workload separation and how to apply different methods to scale out environments that support various workflows. We will also explore the ArcGIS Server roles and extensions, defining their use cases as well as some best practices for deploying these roles.

The chapter will conclude with a review of ArcGIS Enterprise on Kubernetes. Using containerized architecture, ArcGIS Enterprise on Kubernetes seeks to improve system responsiveness and availability through automated scaling. Many of the concepts discussed in this book regarding architecture considerations do not apply as clearly to Kubernetes architecture, but it is important to understand which needs ArcGIS Enterprise on Kubernetes has been designed to address.

Distributed GIS and workload separation

As we mentioned in chapter 2, ArcGIS Enterprise is made up of four primary components: ArcGIS Enterprise portal, ArcGIS Server, ArcGIS Data Store, and ArcGIS Web Adaptor. The base deployment of ArcGIS Enterprise requires each of these components to be deployed and configured to form a functional deployment. However, this is the minimum viable product of ArcGIS Enterprise, so what if we needed to push it further?

Recall the core concepts of a distributed GIS: Client software is used to offload expensive workloads to servers to improve data efficiency and process flow. The client software does not always have to be ArcGIS Pro or other desktop offerings. Depending on the work being performed and the location of the service, the ArcGIS Enterprise portal may also be a client, a user’s browser, or ArcGIS Server itself. In these cases, understanding the origin of the work and the types of resources needed to complete a job becomes important from a scaling perspective.

You can consider scaling in ArcGIS Enterprise in two ways:

• Scaling up: Add resources to your existing machines (RAM, CPU, hard disk space). Scaling up can be beneficial if many services exist on a site.
• Scaling out: Add more machines to sites/stores. Scaling out may make sense if user demand grows or to enable high availability.

We will cover how these options apply to ArcGIS Server, Portal for ArcGIS, and ArcGIS Data Store later in this chapter.

Administrators need to make informed decisions on how to scale or grow ArcGIS Enterprise. Because of the resources needed to be successful, scaling any enterprise system introduces added levels of complexity, upkeep, and cost. Thoughtfully analyzing and balancing system requirements against investment in new infrastructure will promote sustainable growth of your organization’s capacity.

ArcGIS Server

An ArcGIS Server site is a single configuration of ArcGIS Server that fulfills a specific role or process. An ArcGIS Server site can be configured to run on either a single machine or a multimachine configuration across multiple virtual machines, and the distinction between a site and the machine or machines the site comprises is key to the overall understanding of ArcGIS Server scalability. One common example of a server site is the hosting site that is configured in an ArcGIS Enterprise base deployment. As your user base matures and more projects get introduced, it may be best to scale out by adding more machines to the hosting site. The primary benefit of scaling out is providing more resources to a site without needing to rely on adding resources to a single machine. This introduces some redundancy and safety to scaling the system out.

When scaling out an ArcGIS Server site, specific requirements must be met to ensure a successful implementation. One key area is the storage location of the configuration store; all too often, multimachine sites will have their configuration store located on one of the machines in the active site, and if that machine should go down for any reason, you stand to lose access to the site completely. Instead, ensure that the files in the configuration store are available to each machine in a site regardless of the hardware status of the individual machines in the site—this is critical to the long-term success of a multimachine site. There are also version-specific considerations, so make sure you consult the ArcGIS Server documentation for your version.

But what if a lot of services are running on ArcGIS Server? This is where scaling up an ArcGIS Server site makes the most sense. Let’s consider an ArcGIS Enterprise deployment that has a dedicated ArcGIS Image Server. Its capabilities include servicing referenced image services, enabling raster analysis in the ArcGIS Enterprise portal, and storing hosted image services. If you find that users are running more raster processing over time and the performance of those tools is degrading, it may be a good idea to scale up the ArcGIS Image Server site to include more resources.

We will discuss ArcGIS Server roles later in the chapter; however, the key takeaway of this section is to understand when to scale a site out versus when to scale a site up. Scaling ArcGIS Server in either direction will generally increase the efficiency of services or the total user access capacity to the site. However, it is important to realize that you need to partner with your database administrators and IT specialists to scale other dependencies appropriately, such as databases and network connections.

Portal for ArcGIS

The scale-up concepts for the Portal for ArcGIS remain consistent with ArcGIS Server. If you find that more users are accessing ArcGIS Enterprise to manage their content or to create apps, adding more resources, including RAM, CPU, and hard drive space, is a good way to handle this load.

The key difference comes when we talk about scaling out Portal for ArcGIS. Unlike ArcGIS Server, you cannot add more than two machines to a single deployment of Portal for ArcGIS. Additionally, adding a second machine to the ArcGIS Enterprise portal does not achieve the same performance or scalability objectives as with ArcGIS Server. In the context of Portal for ArcGIS, scaling out to a second machine is the beginning of setting up a highly available, or HA, deployment.

Deploying and maintaining a successful HA deployment of ArcGIS Enterprise requires a lot of thought and intention when designing the system. To learn more about what you must consider when deploying these types of systems, access the high availability section of the ArcGIS Architecture Center at .

Unlike a multimachine ArcGIS Server site, where traffic and requests are actively serviced by all machines within a site, the ArcGIS Enterprise portal works differently. Both machines in the site will actively handle traffic simultaneously to maintain a consistency of high availability. However, only one of the portal machines will contain the active underlying database used by the Portal for ArcGIS to manage user activity. When configured correctly, the HA system will be able to switch to the secondary system.

Deploying a true HA ArcGIS Enterprise organization requires a significant amount of architectural planning and system redundancy to achieve. Redundancy can be achieved at every component of ArcGIS Enterprise by configuring separate load balancers between Portal for ArcGIS, ArcGIS Server, and ArcGIS Data Store. Each of these components may be configured to have standby deployments (as seen in the figure) referencing the same configuration stores. Although the sample provided is one solution, there are many ways to attain HA, depending on your chosen ArcGIS Server extensions and multisite deployments.

ArcGIS Data Store

Before considering scaling any type of ArcGIS Data Store, it is best to start with a fully separated instance of ArcGIS Data Store hosted on independent resources. Although it is possible to run multiple components on a single machine, operating at scale may resolve itself in resource competition between ArcGIS Enterprise components, which may negate any resources added to the machine. ArcGIS Data Store can consume a large number of resources quickly, and some ArcGIS Data Store types are configured to use a constant number of resources upon start-up for internal efficiency. The scaling rules for ArcGIS Data Store depend on the type of data store being used. At the 11.4 release of ArcGIS Enterprise, four data store types exist within the system:

• Relational data store: The relational data store is used to configure the base deployment of ArcGIS Enterprise. It follows the same scaling logic that Portal for ArcGIS follows. Scaling out the relational data store can be done only to configure an HA environment. This means that a second machine may be configured for a relational data store site, and this machine may be used only as a passive backup, not for additional resources. Scaling up the relational datastore machine by adding more resources, such as RAM, CPU, and hard drive space, is supported.
• Spatiotemporal big data store: The spatiotemporal big data store supports scaling out its resources by adding additional nodes (machines) to the instance. Because of the baseline architecture of the site, administrators must always have an odd number of nodes available. This means that if you need to scale a spatiotemporal big data store instance that has eight CPU cores and 32 GB or RAM, you will need to add at least two more machines of the exact resource allocation to the site at the same time for proper operation. This would total three nodes.
• Graph store: The graph store follows the same scaling rules as the relational data store. It supports scaling out only in the context of a passive/active HA configuration. You would add resources directly to the machine running the graph store when required.
• Object store: The object store supports scaling through clustering in a similar way to the spatiotemporal big data store . If an odd number of clusters are available, and resources match each one, the object store will be able to use these resources. Scaling up through adding resources to each node is also supported.

So far, we’ve covered different options to scale up ArcGIS Enterprise by adding CPU, RAM, and disk space to machines within the organization. We’ve also covered how to scale out ArcGIS Enterprise by adding machines and nodes to specific components that support these additions. But what if you wanted to add to the features that are available to your users? This is where different ArcGIS Server roles come into play.

ArcGIS Server roles and extensions

Certain features in ArcGIS Enterprise require additional federated ArcGIS Server sites licensed and configured to fulfill a specific role. At minimum, an ArcGIS Server role requires a dedicated site that has been licensed for that role. Some ArcGIS Server roles require additional underlying software of configured ArcGIS Data Store types to function.

.

From a usage perspective, you will find few differences in this technology compared with the look and feel of ArcGIS Enterprise. Content, group, and user management are consistent with Windows and Linux offerings. ArcGIS Enterprise on Kubernetes comes with familiar web apps, including ArcGIS Experience Builder and ArcGIS Instant Apps. Not all ArcGIS Server roles are included in ArcGIS Enterprise on Kubernetes; however, more roles are being included in every release. The Capabilities section of the version of ArcGIS Enterprise you are deploying will have more information from a function perspective.

A successful deployment of ArcGIS Enterprise on Kubernetes is built on a foundational grasp of Kubernetes at the architectural and networking level. If you become curious about these capabilities or require certain scaling features that Kubernetes offers, talking to your IT department about its experience with deploying Kubernetes clusters and understanding their capabilities is a vital first step toward success.

Tutorial 5: Investigate distributed computing in ArcGIS Enterprise

Your deployment of ArcGIS Enterprise may already make use of distributed computing to separate workloads or provide redundancy. In this tutorial, you will investigate how, and whether, you are already taking advantage of distributed computing.

Investigate the ArcGIS Enterprise portal

1. Sign in to your ArcGIS Enterprise portal organization as an administrator.
2. Change the organization site URL to point to the Portal Administrator Directory.
3. On the Site Root page, in Resources, click Machines.
   • How many machines are listed?

   An HA ArcGIS Enterprise portal will list two registered machines. A single machine represents a single point of failure: If that machine goes down, the capabilities of your ArcGIS Enterprise portal will not be available.

4. What are the fully qualified domain names of each machine?
5. Click the status link for one of the machines.
   • What is the machine’s status?
6. At the top of the page, click the Home link to return to the Site Root.

Investigate federated ArcGIS Server sites

1. Within Resources, click Federation and then click Servers.
   • How many federated servers are listed?
2. Click the link for the hosting server.
   • What is the URL for the hosting server?
3. Copy the URL for the hosting server and paste it on a new browser tab. Add /manager to the end of the URL and then navigate to that page to access Server Manager.
4. At the top of the page, click the Site tab.
5. On the left, go to the Machines section.
   • How many machines are listed for this server site?

   Multiple listed machines indicate an HA server site with an active-active configuration. Each machine is capable of handling requests for any service published to the server site, increasing both the capacity and resilience of the site.

   • What are the fully qualified domain names for each machine?
   • Are the fully qualified domain names the same as any machine used for the ArcGIS Enterprise portal?

   If multiple components are running on the same machine, they will contend for system resources. Problems in one component are more likely to negatively affect other components if they are running on the same machine.

6. Repeat the previous steps for any other federated servers listed in the Portal Administrator Directory.

Investigate ArcGIS-managed Data Store items

1. Change the URL to point to the ArcGIS Server Administrator Directory.
2. Sign in to the ArcGIS Server Administrator Directory using the credentials for the Primary Site Administrator or by following the directions to acquire a portal token.
3. From Resources, click data. Then click items and go to the /enterpriseDatabases link.
4. Click the link for the Child Item that has AGSDataStore in its name.

   This is the relational data store that holds data for hosted feature layers.

5. Below Data Item Properties, click machines.
   • How many machines are listed?

   Multiple machines indicate that there is redundancy at the relational data store level. If the primary machine fails, the standby will be promoted to primary.

   • What are the fully qualified domain names of each machine?
   • Are any of the machine names the same as those used for your ArcGIS Enterprise portal or any ArcGIS Server site?
6. Click the name of one of the machines.
   • What role does this machine have?
7. At the top of the page, click the items link to return to the list of Root Data Items.
8. Click the /nosqlDatabases link.

   The child items on this page have information about the other ArcGIS-managed data stores registered with the hosting server, such as the object store or spatiotemporal big data store.

9. Repeat the previous steps for each of the child items listed.
10. Return to the Site Root of the Portal Administrator Directory on your previous browser tab.

Investigate the Portal for ArcGIS Web Adaptor components

1. From the Site Root of the Portal Administrator Directory, within Resources, click System and then click Web Adaptors.
   • How many web adaptor components are listed?

   Multiple web adaptors indicate resiliency at the web adaptor tier. If one of the Web Adaptor components fails, requests can still be routed to ArcGIS Enterprise.

2. Click the name of one of the Web Adaptor components.
   • What is the IP address of the Web Adaptor component?

Summary

In this chapter, we covered the basic concepts on how to extend your deployment of ArcGIS Enterprise to meet new requirements. Extending ArcGIS Enterprise can include scaling resources by adding hardware to an existing deployment to meet new volume requirements. Adding new server roles to an ArcGIS Enterprise organization will add functionality to an existing site. Lastly, we touched on ArcGIS Enterprise on Kubernetes and how it can scale to match volatile demand for services.

Отправить