Deployment scenarios

The scalable architecture of ArcGIS Server lends itself to numerous deployment options. Large deployments may require multiple Web servers, server object managers (SOMs), and server object containers (SOCs), while smaller organizations might want to consolidate these resources onto one or two machines. The way you deploy ArcGIS Server depends on what you want to do with it. If you are using the product for development or testing purposes, you don't need an extensive deployment, but if you are publishing GIS services to a large community of users, you need to give extra consideration and resources to factors such as processing loads, single points of failure, and security.

The following deployment scenarios are presented as guides for you to think about as you prepare to build your ArcGIS Server system. Although you could deploy your system exactly as presented in one of the scenarios, you will probably want to use the scenarios just to get ideas of what's possible with ArcGIS Server, then adjust your own deployment to fit your specialized needs and hardware resources.

Single-machine deployment scenario

If you're using ArcGIS Server exclusively for development, testing, or small deployments, you don't have to accommodate large numbers of requests for services; a simple configuration is sufficient. This scenario shows how you can install all the ArcGIS Server components on one machine. The Web server also resides on the machine. The machine must also have access to an ArcGIS Server administrative interface, such as Manager.

In the graphic below, the data needed by ArcGIS Server resides on the same machine as all the other components. If ArcSDE is used to access the data, then the data is most likely stored in a Microsoft SQL Server Express database. ArcGIS Server Workgroup uses this configuration.

Multiple-machine deployment scenario

The multiple-machine deployment scenario is ideal for many internal deployments or for Web deployments. In this scenario, the SOM and Web server reside on the same machine. Since the SOM uses relatively little memory, it can usually coexist with the Web server without conflict. The Web ADF is also installed on this machine.

The multiple-machine deployment scenario is sufficient for many ArcGIS Server deployments.

The multiple-machine scenario includes one or more SOC machines for performing GIS tasks and can be scaled out depending on the number of users your system needs to accommodate. The number of SOC machines you should add depends on how many users will be making requests to the system at one time and the intensity of the operations they will be requesting. A CPU in a SOC machine under average conditions can support about four concurrently active service instances. The diagram above shows two SOC machines. If each is a dual-CPU system, this configuration can accommodate about 16 users simultaneously performing operations on services. Using the above formula, you can adjust the number of SOC machines to accommodate the number of concurrent users you anticipate.

Keep in mind that some operations, such as creating map caches, are very CPU intensive and will require adjustments to the above formula (see Allocation of server resources to creating a map cache if you're concerned about this). Other operations, such as serving tiles from a cache, require little or no interaction with the GIS server and will allow you to support many more users than four per SOC machine.

The data tier of the multiple-machine configuration consists of a separate data server machine running enterprise ArcSDE and a DBMS. The SOC machines have permissions to access the data on this machine and generally do so through the name and password that you save when you make the ArcSDE connection in ArcCatalog.

Ensuring constant availability of the GIS server

To eliminate single points of failure in a multiple-machine deployment, you can configure network load balancing between several Web servers and use a failover or round-robin approach for distributing requests for services among two or more SOM machines. This type of configuration, shown in the diagram below, is appropriate for applications that require constant availability of server resources.

A request made to this system first encounters a network load balancer, which assigns the request to an available Web server. The network load balancer ensures that requests are distributed evenly among all available Web servers. If a Web server becomes unavailable due to maintenance or hardware failure, the network load balancer ensures that requests are sent to the remaining Web servers.

The Web server contains the Web application related to the request and the Web ADF Runtime. The Web application contains instructions on which SOM machines can be used to handle the request. In this diagram, the SOM machines are configured in a round-robin fashion. This means that incoming requests are distributed evenly among available SOM machines. If a SOM machine goes offline, requests are sent to the remaining SOM machines. You can use the Web ADF's Connection Library to configure this type of round-robin behavior for your Web applications.