Deployment scenarios

This topic describes different ways you can architect your ArcGIS Server site to meet various capacity and availability requirements.

The following terms are used to help explain each deployment scenario:

• Site: A site consists of several components, such as a GIS server and ArcGIS Web Adaptor, that can optionally be distributed across multiple machines to increase computing power and redundancy. For a more detailed description, see Inside an ArcGIS Server site.
• GIS server: The main component of the site that does the work to satisfy requests issued to the GIS web services. A GIS server can draw maps, run tools, serve imagery, and perform many other operations offered by ArcGIS.
• ArcGIS Web Adaptor: An optional component that allows you to configure a web entry point into your site. It integrates with your web server and distributes incoming requests among GIS servers. For more information, see About the ArcGIS Web Adaptor.
• Server directories: A set of directories containing certain types of files that support your services. These files include caches, search indexes, and geoprocessing job results. For more information, see About server directories.
• Configuration store: A location that contains configuration information such as the list of GIS servers participating in the site. The configuration store must be available for your site to function. For more information, see About the configuration store.
• Data: Data supporting your web services, such as feature classes, tools, imagery, and locators. For more information, see Making your data accessible to ArcGIS Server.

The following scenarios are presented as guides for you to consider as you build your ArcGIS Server site. Although you could configure your site exactly as presented in one of the scenarios, these configurations are flexible and can be adjusted to fit specialized needs and hardware resources.

Developer sandbox site

When you're just developing or experimenting with ArcGIS Server, you can simply install the GIS server without installing a web server or the Web Adaptor.

Developer sandbox site containing one GIS server. Data, server directories, and the configuration store reside locally on the GIS server.

In this scenario, the site is configured with one GIS server. The data, server directories, and configuration store reside locally on the GIS server. A PostgreSQL database is a good option for setting up a small instance of a geodatabase on the GIS server.

Clients access the developer sandbox site by connecting directly to the GIS server through HTTP on port 6080. For example, the URL to the site would be http://myserver:6080. The GIS server hosts services only; there is no web server in this configuration for hosting web applications.

Use cases and advantages of the developer sandbox site

This configuration is ideal for prototyping services and isolated sandbox testing. It is relatively simple to install and maintain.

Disadvantages of the developer sandbox site

This configuration is not very secure, since ArcGIS Server Manager and the ArcGIS Server Administrator Directory are exposed through the same port that everyone else uses to access the services. Also, this configuration cannot host web applications, and there is no failover option if the GIS server goes offline.

Single machine site

The simplest appropriate configuration for a production site is to expose one GIS server through the Web Adaptor.

The Web Adaptor is recommended so that incoming requests can go through your established web server. This gives you more security options and the ability to host web applications. If you are short on resources or you don't have to accommodate many concurrent requests, you can install both the GIS server and Web Adaptor on a single machine. This machine must also have a web server installed.

For example, the site in the diagram below is configured with a Web Adaptor on port 80 and would be accessed using the URL http://myserver. The Web Adaptor forwards incoming client requests to the GIS server on port 6080. Server administrators should log in to Manager or the Administrator Directory through port 6080.

Single machine site with the Web Adaptor installed on the GIS server.

You can architect your site to use parts of your organization's existing IT infrastructure. In the diagram below, the Web Adaptor has been offloaded to a web server on a separate machine. Similarly, the data, server directories, and configuration store have been put on a dedicated data server. This shows that the phrase "single machine site" technically means "single GIS server site."

Site with one GIS server with the Web Adaptor and data offloaded to separate machines.

Putting the web server on its own machine may be desirable in organizations where the web server has a different set of administrators or access policies than the GIS server.

Putting the data on a separate machine allows you to add and remove GIS servers from your site without any disruption to your data path settings. Putting the server directories and configuration store on a redundant network storage device improves your abilities to back up and recover these resources.

Use cases and advantages of the single machine site

The single machine site as diagrammed above with a Web Adaptor is ideal for accommodating small numbers of concurrent users. It's also useful in development or prototyping scenarios where extra security or the ability to host web applications is desired. The single machine site is relatively simple to configure and can integrate into your existing web server and data storage architecture.

Disadvantages of the single machine site

The single machine site has no failover abilities if the GIS server goes offline. Also, the capacity of the GIS server is limited to the physical hardware characteristics of the single machine.

Multiple machine site

A site can include multiple GIS servers to handle increased traffic or provide a backup in case one of the GIS servers goes offline. The following diagram shows the simplest way to configure a site with multiple GIS servers. The Web Adaptor detects the GIS servers that participate in the site and forwards requests to each in a round-robin fashion. The GIS servers also perform some degree of request distribution among themselves.

Site with multiple GIS servers where the data resides on a highly available data server.

There are two strategies for storing the data when using multiple GIS servers. The approach shown above keeps the data in one centralized location visible to each GIS server. The data only has to be maintained in one place, and this configuration is recommended if you have a good intranet connection.

The other approach for data storage, shown below, is to put a local copy of the data on each GIS server machine at an identical path. This strategy cuts down on network calls and can increase performance if your intranet connection speed is slow. However, it's difficult to maintain large, frequently changing datasets with this architecture.

Site with multiple GIS servers where data is stored locally on each GIS server.

If demand increases in either of the above scenarios, additional GIS server machines can be added to the site either manually or automatically (through scripts). This architecture is well suited to cloud computing, in which any GIS server can be added or removed from the site at any time.

Taking advantage of clusters

Large sites with two or more GIS servers can take advantage of clusters. A cluster is a group of GIS servers that has been configured to run a dedicated subset of services. In the diagram below, Cluster A could potentially be configured to run map services, while Cluster B (with higher processing power) could be configured to run geoprocessing services.

Multiple machine site with clusters. Each cluster runs its own subset of services.

Some server operations, such as batch geocoding, are very CPU intensive. Using clustered servers for this type of operation may help free up other machines in your site so that your remaining services can remain online unencumbered.

Clustering is also useful when you have disparate hardware resources. For example, an older or slower server could be placed in its own cluster to perform lower-priority jobs.

For more information, see About GIS server clusters.

Using more than one web server

To help ensure high availability of your site, you can also establish redundancy at the web server tier. In the diagram below, two web servers installed with the Web Adaptor act as identical entry points into your site on port 80. This helps keep your site running in the event of an unplanned outage on one of the web servers. It can also help reduce the load on the first web server machine.

Site with redundancy at the web server tier. The clusters are optional.

Following are several other scenarios that might require two Web Adaptors, although these are less common:

• You need internal users to connect to Manager through the Web Adaptor, but you want to block external users from accessing the Manager login screen. This could occur if ArcGIS Server is in a perimeter network (DMZ) and your firewalls block it from receiving connections from your internal network through port 6080. In this case you set up a second Web Adaptor for internal users only that communicates through whichever port is allowed by your firewall.
• You want to block external users from accessing the Manager login screen, but you are also performing web tier authentication. In this case, you set up a second Web Adaptor for internal users only that allows publishing and administrative access.

Use cases and advantages of the multiple machine site

The multiple machine site is ideal for enterprise deployments that need to accommodate more users than a single machine can handle. This architecture can be scaled out to include as many machines as needed, thereby multiplying the processing power of the site. GIS servers can even be added in response to user demand. This is useful in cloud environments like Amazon EC2 that offer automatic scaling based on usage statistics.

The multiple machine site is also appropriate for sites that cannot afford to have any downtime. If a GIS server goes offline, the other GIS servers can keep the site running.

Disadvantages of the multiple machine site

The multiple machine site requires an extra degree of setup and obviously more hardware resources. Because the site is able to gracefully continue running if a GIS server goes offline, the server administrator must set up his or her own monitoring or alert schedule to understand whether a machine has become unavailable.

Summary

ArcGIS Server is designed to accommodate both large and small deployments. When you first begin building your site, you might want to start small and install all the components on a single machine. As you get ready to deploy your production site, or if you need to handle more users, you can add more GIS servers. You can also integrate your site into your existing IT infrastructure by using your own enterprise web server (via the Web Adaptor) or data server. Finally, many of the components in the ArcGIS Server architecture can be duplicated or run in parallel to avoid a single point of failure.