GIS Product Architecture 37th Edition

Fall 2015 GIS Product Architecture 37th Edition

This edition will focus on the ArcGIS 10.3 product architecture. The ArcGIS 10.1 release introduced some significant ArcGIS for Server software architecture improvements which were carried forward with the ArcGIS 10.3 release. The [System Design Strategies 30th Edition] provides an overview of the ArcGIS 10.0 product architecture.

GIS Product Architecture shares the software components and platform configuration options available for distributed GIS operations. Understanding application architecture alternatives and associated configuration strategies provides a foundation for selecting an appropriate distributed GIS design.

Enterprise-level GIS applications support a variety of users throughout an organization, all requiring access to shared spatial and attribute data sources. System hardware and software environments for distributed GIS applications are supported by a multi-tier client/server or Web services architecture. A simple overview of the various ArcGIS architecture components is provided in Figure 7.1.



Central Data Servers: Shared spatial and tabular database management systems provide central data repositories for shared geographic data. These database management systems can be located on separate data servers or on the same central server platform. Data servers include File Servers, File and ArcSDE Geodatabase Servers, Imagery servers, map and imagery tile cache, and database servers supporting other Enterprise business systems. Additional data resources are available from ArcGIS Online and other Internet data sources.

ArcGIS for Desktop Clients: ArcGIS for Desktop clients are licensed at three levels that address specific user application needs. Basic provides view and query functionality, Standard provides functionality focusing on data maintenance and administration, and Advanced provides the full suite of standard desktop technology used by GIS professionals. ArcGIS Engine and ArcGIS Runtime are programming environments for developing custom ArcGIS Desktop applications.

Application Servers: GIS applications are supported within a distributed configuration by server platforms that execute GIS functions. In a centralized solution, Windows Terminal Server and ArcGIS for server platforms can host applications and services for a large number of concurrent GIS clients. Windows Terminal Servers host GIS desktop applications on centrally managed server farms allowing remote terminal clients to display and control applications executed on the terminal server platforms. ArcGIS for Server platforms support a variety of Web applications and services accessed by standard browser clients, rich internet applications, or other desktop applications.

Mobile Clients: A rapidly expanding number of mobile clients are used by the GIS community. Mobile clients are used for data collection, focused mobile operations, a variety of mobile applications, and general public access to published GIS resources over the Web.

ArcGIS Software Architecture
ArcGIS is an integrated collection of software components available for building a complete geographic information system. The ArcGIS software products are used to deploy GIS functionality and business logic where needed—in desktops, servers, custom applications, Web services, and mobile devices. The ArcGIS applications are supported by a common set of software components. Figure 7.2 provides an overview of the ArcGIS software component architecture.



GIS is technology used for the creation, management, integration, analysis, display, and dissemination of spatial data. Spatial data includes any information that can be associated with a location on the earth's surface or data that can be associated with a person or place that has a location.

How the spatial data is maintained and published within the organization contributes to the performance and scalability of the system design. GIS Data must be organized and managed to support effective and efficient GIS operations. GIS data deployment patterns are discussed in more detail in the Chapter 5 GIS Data Administration chapter.

ArcGIS for Desktop can be deployed on client workstations or hosted by a Windows Terminal Server. Custom ArcGIS Engine and runtime applications include the same ArcGIS components supporting the ArcGIS Desktop commercial software and share common configuration strategies. Different configuration alternatives are available to support communications between the client application and the GIS data source. ArcGIS for Desktop deployment patterns are discussed in more detail in the SDSwiki Chapter 2 Desktop operations section.

ArcGIS for Server is deployed in a scalable Web application server architecture. The Web solutions include software development kits and runtime environments supporting application development, system performance, and scalability. Recommended platform configuration strategies will be provided for both standard and high availability architecture solutions. ArcGIS for Server deployment patterns are discussed in more detail in the SDSwiki Chapter 2 Web operations and Mobile operations sections.

GIS applications support an open systems architecture. The ArcGIS enterprise architecture combines a variety of closely integrated commercial products to establish a fully supported system solution. All commercial software products must be maintained to support evolving communication interface standards. The importance of selecting well established (popular) software architecture solutions based on standard design practices cannot be overemphasized, since all parts of the distributed configuration are critical and must work together to ensure communication interfaces are properly maintained and supported. 

Virtualization deployment options
Figure 7.3 provides an overview of the four principle virtualization solutions. Virtualization provides a variety of options available for ArcGIS deployments.

Virtual session
Virtual sessions are used for improved security and high performance access to shared centralized data souces. Multiple desktop applications are deployed on a centralized server platform sharing a common server operating system. Desktop applications run on the server with each session displayed and controlled by remote terminal clients.

Vendor offerings:
 * Windows: Remote Desktop Service (RDS) -> Remote Desktop Connector (RDC)
 * Citrix: XenApp -> (Citrix Receiver)
 * VMware: NA

"Note: CPT workflow: Citrix workflow with Physical or Virtual platform tier selection."

Esri certifies each ArcGIS for Desktop release with Citrix XenApp server (Citrix Receiver) environment. A more complete discussion on Centralized Windows Terminal Server/Remote Desktop Services (Citrix) Architecture is provided in Chapter 7.

"Best practice: Large number of Esri customers use Citrix XenApp application servers for remote user access to centrally managed remote desktop terminal services."

Virtual server
Virtual Server machines reduce administration overhead and share the host physical server compute resources. Virtual Server machines share a common hypervisor for access to host platform processing resources. Each Virtual Server machine has its own installed Server operating system. Server applications are installed in each separate Virtual Server machine.

Vendor offerings:
 * Windows: HyperV
 * Citrix: XenServer
 * VMware: VMware vSphere (ESX)

"Note: CPT workflow: Virtual platform tier selection."

"Best practice: Large number of Esri customers deploy ArcGIS for Server in the three available virtual server environments."

Esri/VMware joint benchmark testing reports.
 * October 2011 Esri ArcGIS Server 10 for VMware Infrastructure Deployment and Technical Considerations Guide includes performance testing of ArcGIS Server 10 with VMware ESXi 3.5u4.
 * July 2013 Esri ArcGIS 10.1+ for Server on VMware vSphere Deployment and Technical Considerations Guide includes performance testing of ArcGIS 10.1 for Server with VMware vSphere 5.1.

Test results show significant virtual server performance improvements with the more recent VMware vSphere technology. The October 2011 testing showed slightly more than 10 percent virtual server processing overhead per core, while the July 2013 testing showed limited performance degradation between physical and virtual server deployment configurations.

Virtual desktop infrastructure (VDI)
Virtual desktop infrastructured deployments reduce administration overhead and share the host physical server compute resources for centralized virtual desktop deployment. Virtual Desktops share a common hypervisor for access to host platform processing resources. Each Virtual Desktop has its own installed Desktop operating system. Desktop applications are installed in each separate Virtual Desktop machine. Virtual Desktops run on the server with display and control provided by a variety of remote terminal client devices.

Vendor offerings:
 * Windows: Microsoft Virtual Desktop Infrastructure
 * Citrix: XenDesktop
 * VMware: VMware View

"Note: CPT workflow: Citrix workflow with VDI platform tier selection."

Esri customers have deploy Virtual Desktop Infrastructure (VDI) and though they are known to work, Esri has not yet certified these solutions.

"Best practice: Virtual desktops environments are used by Esri for development and hosted ReadyTech training environments."

Virtual desktop environments traditionally do not have access to hardware video cards which has contributed to some functional performance degradation noticed by users. Vendor solutions are available to include shared NVIDIA GRID video cards within the VDI host server architecture to improve display performance for future virtual desktop deployment patterns.

Virtual client
Virtual clients are virtual desktop environments deployed on a local physical desktop. Virtual Desktops interface through a hypervisor for access to physical desktop processing resources. Each Virtual Desktop has its own installed Desktop operating system. Desktop applications are installed in each separate Virtual Desktop machine. Virtual Desktops run on the client physical workstation..

Vendor offerings:
 * Windows: Virtual PC
 * Citrix: XenDesktop
 * VMware: VMware VDI

"Note: CPT workflow: Increase client load to handle visualization."

"Best practice: Virtual desktops are used by Esri for development and classroom training environments."

"Warning: Some virtual desktop environments to not have access to hardware video cards which contributes to some performance degradation noticed by users. "

ArcGIS for Desktop architecture patterns
ArcGIS for Desktop software is supported on Microsoft Windows desktop and terminal server platform environments. ArcGIS Engine and Desktop Runtime are software development kits providing ArcGIS components for custom desktop application development. Python is a fully supported scripting language used for process automation. Figure 7.4 provides an overview of the software components supporting the ArcGIS for Desktop application.

ArcGIS for Desktop is deployed in a client/server component architecture. The client applications are tightly coupled when accessing a DBMS data source, exchanging hundreds of sequential data requests to complete each user map display transaction. A typical map display is refreshed in less than a second, requiring a very chatty protocol exchange with the connected database.

" Best Practice: Communications between the ArcGIS for Desktop application and an SDE Geodatabase should be limited to stable high-bandwidth local network environments with minimum network latency. "

ArcGIS direct access to remote DBMS data sources can result in reduced display performance and unstable editing operations. The most common architecture for supporting remote client editing uses terminal access to a central Windows Terminal Server located in the SDE Geodatabase data center, which we will discuss later in this chapter.

Network latency is the primary cause for reduced display performance when accessing a remote database. Display performance can be improved by reducing the number of sequential application round trip requests per display. You can reduce the required round trips to the server by establishing a local feature cache or by accessing remote DBMS data sources through an ArcGIS for Server feature service. You could also establish ArcGIS for Desktop local basemap layers to further improve display performance for a defined work area. These are some workaround options for improving display performance, and may not be practical for all workflow scenarios.

ArcGIS for Desktop software connects to local file and Imagery data sources, DBMS sources, map and imagery cache, and Web data services. Web data services can be overlaid with local data in a standard GIS map display. ArcGIS for Desktop software includes Web access to a variety of worldwide high quality ArcGIS Online basemaps and is fully integrated with publishing and collaborating through ArcGIS Online organization membership.

The CPT data source selections for an ArcGIS for Desktop workflow include a variety of data source formats (SDE_DBMS, SFG_Small File GDB, LFG_Large File GDB, SSF_Small Shape File, LSF_Large Shape File, or Cache_Cached Tiles). Appropriate application query load adjustments (Workstation/terminal server desktop application or server SOC) are made based on the data source selection. 

ArcGIS for Desktop workstation architecture
Four distributed ArcGIS for Desktop workstation configuration patterns are identified in Figure 7.5. These configuration patterns include access to a networked file data source, direct connect access to an ArcSDE Geodatabase (SDE DBMS), direct access to a supported DBMS (non-SDE), and DBMS access through an ArcGIS for Server feature service.

The ArcGIS for Desktop software will provide native file access to GIS data located on local disk. GIS applications can access a remote file data source by using Microsoft's Common Internet File Services (CIFS) or similar UNIX Network File Services (NFS). When mounting the remote disk, the remote file would appear as a local file share to the desktop application. Query processing for a file data source is supported by the ArcGIS for Desktop application.

ArcGIS for Desktop software provides a direct connection to all supported database servers. The direct connect option (SDE_DBMS DC) includes the direct connect API executables and will communicate with a database client installed on the same machine. The database client will support network communications to the database server.

" Best Practice: Direct Connect is the recommended method for connecting to all supported database servers. "

ArcGIS for Desktop software provides direct connections to supported database servers providing view, query and analysis of the DBMS data content. Some of the databases you access can contain geodatabase tables, functions, and procedures, but they don't have to; you can connect to any supported database and view the data from ArcGIS for Desktop.

ArcSDE geodatabases, also known as multiuser geodatabases, are stored in a relational database using Oracle, Microsoft SQL Server, IBM DB2, IBM Informix, or PostgreSQL. These geodatabases require the use of ArcSDE and can be unlimited in size and numbers of users.

ArcMap allows you to edit a supported database by creating a local copy of data from a published ArcGIS for Server feature service. You can then make edits to the local copy in ArcMap and synchronize the edits back to the service. Edits can be made to the local copy without having to be connected to the server. Access to the server is only required when creating the local copy or applying changes from the local copy to the server. This workflow can be useful when your organization has disconnected employees and provides a common method for editing the same data using multiple clients, such as through the web or using desktop applications. The functionality is built into ArcMap and does not require any customizations. Edits to a published feature service are captured in a single version of the database.

Alternative Remote Server Connect and ArcSDE Application Server Connect architecture communication options are supported with the ArcGIS 10.3 release but are no longer relevant for most implementations. 


 * CPT Calculator ArcGIS for Desktop workstation workflows

Software selections include ArcGIS 9.3.0, 9.3.1, 10, 10.1, 10.2, and 10.3 workflows. The CPT Calculator supports three of the ArcGIS for Desktop workstation configuration patterns.
 * SDE Direct Connect (DC) architecture. This architecture should be used for SDE Direct Connect and direct non-geodatabase DBMS connect workflows.
 * SDE Application Server Connect (ASC) architecture. This architecture is no longer supported with the ArcGIS 10.3 release.
 * File data source architecture. Provides access to selected file data source.


 * CPT Design ArcGIS for Desktop workstation workflows

The CPT Design includes several integrated modules used for completing the system architecture design. ArcGIS for Desktop workflow selection is made in the user Requirements Analysis module. Platform tier configuration is established in the Platform Configuration module. Final software platform assignment is made in the Software Configuration module.

Centralized Windows Terminal Server/Remote Desktop Services (Citrix) Architecture
ArcGIS Desktop Virtualization

The Microsoft Windows Terminal Server (name changed to Remote Desktop Server  with Windows Server 2008 R2 release) operating system establishes a multiuser environment on a Windows server host. A Windows terminal client (name changed to Remote Desktop Connection with Windows Server 2008 R2 release) provides display and control of applications executed on the Windows Terminal Server. Microsoft uses a standard Remote Desktop Protocol (RDP) for communication between the terminal server and the Windows client. Windows terminal server platform memory recommendations are generated based on peak concurrent ArcGIS for Desktop user sessions supported by the selected platform configuration.

The Citrix Xen Application Server (XenApp) enables a more efficient independent computing architecture (ICA) protocol to communicate between the terminal server and client Windows platform. The ICA protocol requires less than 28 Kbps bandwidth (rendering vector data information products) for full Windows display and control of GIS applications supported on a Windows Terminal Server. Traffic can increase to 100 Kbps bandwidth when accessing a raster data source. XenApp supports client software for Windows, UNIX, Macintosh, and embedded Web client applications.

XenApp provides many additional benefits over just RDS alone, including “seamless” windows, universal print drivers, and HDX technologies such as HDX 3D Progressive Display for imagery acceleration, just to name a few. Most Esri customers that deploy centralized thin-client solutions have realized the benefits of Citrix XenApp and have deployed it in addition to standard RDS. There is currently a very large Esri customer user base that utilizes Citrix XenApp for ArcGIS Desktop operations. The following knowledge base article provides Esri best practices for running ArcGIS in a Citrix XenApp environment.

Esri initially certified ArcGIS 10 SP2 as a hosted application with Citrix XenApp 6 and Windows 2008 R2 using the Citrix ICA Online Plug-in for Windows 12.1. Esri has since certified ArcGIS 10.3 as a hosted application with Citrix XenApp 6 and XenApp 6.5 with Windows 2008 R2 using the Citrix ICA Online Plug-in for Windows 13.1.

Though XenApp is a popular solution and meets most desktop application publishing needs, there are a few limitations with its use in GIS. The limits are primarily centered on supporting graphic intensive displays such as those from ArcGlobe and other 3D applications. These limits can result in the need to maintain some presence of thick-client desktops for targeted power users that require high-performance and 3D graphics environments. Design and testing efforts are in work with our vendor partners to improve 3D performance in remote desktop deployment patterns. ArcGIS Resources blog shares Esri test feedback on ArcGIS Pro with NVIDIA K1 in XenDesktop. Citrix shares results for their commitment with Esri in supporting ArcGIS Pro for Citrix XenApp and XenDesktop.

Further, centralizing applications and data naturally creates a distributed printing environment. This can be particularly problematic for large plot printing used in GIS. Solutions are available to help with remote printing management and these solutions are being used by Esri Citrix customers. The following reference document addresses printing with ArcGIS in Citrix environments and mentions some of the available solutions. Two of the most popular have been ThinPrint and UniPrint.

Four distributed ArcGIS Desktop Citrix configuration alternatives are identified in Figure 7.6. All configurations are supported by remote terminal client access to ArcGIS for Desktop applications hosted on a central Windows Terminal Server. ArcGIS for Desktop Citrix configuration options include access to a network file data source, direct connect access to a geodatabase, direct access to a non-SDE DBMS, and DBMS access through an ArcGIS for Server feature service.

Terminal clients have a persistent connection with the Windows Terminal Server ArcGIS for Desktop session; lost connections are reinstated without losing the session (referred to as Session Reliability in XenApp). The application display is provided over the network to the terminal client, requiring much less data transfer than the spatial data query chatter between the application and the data source. The terminal client display traffic requirements are very small; supporting good application performance over 28 Kbps modem dial-up connections (displays with an image backdrop require more bandwidth).

Each ArcGIS for Desktop user session hosted on the Windows Terminal Server connects to each data source the same way as a distributed client workstation session. Most current Esri customers using Windows Terminal Server also use the Citrix XenApp Server software. The Windows Terminal Server farm is supported by commodity Windows server platforms (Intel or AMD). Client session load balancing across the terminal server farm is managed by the Citrix software. Client profiles and security options are provided to support an optimum GIS user display experience. 


 * CPT Calculator ArcGIS for Desktop terminal server clients

The CPT Calculator supports three of the ArcGIS for Desktop Citrix (WTS) configuration patterns.
 * SDE Direct Connect (DC) architecture. This architecture should be used for SDE Direct Connect and direct non-geodatabase DBMS connect workflows.
 * SDE Application Server Connect (ASC) architecture. This architecture is no longer supported with the ArcGIS 10.3 release.
 * File data source architecture. Provides access to selected file data source.

CPT Calculator analysis is limited to completing a single-user workflow analysis. The analysis is also limited to show SDE connections to the DBMS server (does not support a remote SDE server configuration).


 * CPT Design ArcGIS for Desktop Citrix workflows

The CPT Design supports all four of the ArcGIS for Desktop Citrix configuration patterns.

The CPT Design includes several integrated modules used for completing the system architecture design. ArcGIS for Desktop workflow selection is made in the user Requirements Analysis module. Platform tier configuration is established in the Platform Configuration module. Final software platform assignment is made in the Software Configuration module.

ArcGIS for Server services architecture
Web mapping services provide an efficient and effective approach to serving map products and services over the Internet. The ArcGIS Desktop architecture presented earlier in this section requires tightly coupled client/server processes that demand stable high-bandwidth communications supported over relatively short distances. Web client communications are supported using a transaction-based HTTP, which supports optimum communications over long distances and less stable communication environments.



ArcGIS for Server services are published through a Web server. Web server clients are presented with a catalog of published services when accessing the Web site. Web applications consume map services and render a client presentation layer to support the published application workflow. Client and Web servers are loosely coupled (stateless) connection in which each client communication represents a complete transaction. Transactions are processed by the appropriate Web-based GIS server and returned to the client.

Esri Web GIS services are hosted by ArcGIS for Server software. ArcGIS for Server provides an ArcGIS software-based environment for deploying GIS server-based ArcGIS applications and services. ArcGIS for Server can be deployed as a Web service for Internet/Intranet clients or as a network service for local desktop clients. Rich internet applications (RIA) Web clients are loosely connected, lightweight, handheld or desktop computers that can support a variety of Web based applications and include persistent data cache and potentially support disconnected GIS client operations. Client application deployment and data exchange are managed by ArcGIS for Server parent services. ArcGIS Imagery services are fully integrated into ArcGIS for Desktop and ArcGIS for Server with the ArcGIS 10 release.

The software architecture components for ArcGIS for Server include Web browsers, RIA clients, GIS Server, and geodatabase software components that can be deployed on different platform combinations to support scalable capacity and system availability requirements. Location of the various software components and the selected software configuration contributes to system capacity, service reliability, security, and overall output performance.

ArcGIS 10.1 was a major release for Server. ArcGIS 10.1 for Server introduced all the primary functionality of ArcGIS 10 delivered in a new 64-bit JAVA based software component architecture. ArcGIS 10.1 for Server was designed for rapid deployment and friendly administration. Server enhancements improved installation, performance, reliability, administration, cloud deployment options, and more Linux friendly software compatibility. The ArcGIS 10.3 release is an upgrade of the same ArcGIS 10.1 for Server architecture. Primary software components associated with the ArcGIS for Server 10.3 software architecture are identified in Figure 7.7. GIS Server support access to file data sources, ArcSDE Geodatabase and non-geodatabase database sources, imagery and cached tile data sources.

ArcGIS 10.3 for Server is delivered as a single software install that includes the web service endpoints, Server Object Manager (SOM), and Server Object Container (SOC) functions of the previous release within a new fully integrated GIS Server software bundle. An optional Web Adaptor component is included with the ArcGIS for Server install package for improved security and network load balancing. 

ArcGIS 10.3 for Server key site aware component functions
Figure 7.8 provides an overview of the terminology used to describe the ArcGIS 10.3 for Server architecture. An ArcGIS for Server high availability configuration will be used to introduce these terms. These terms will be discussed in more detail as we describe the ArcGIS for Server architecture patterns later in this chapter.

The initial ArcGIS for Server install defines the primary components that make up a named Site. These primary components include the GIS Server and the Site Configuration Store (ConfigStore). The Site ConfigStore contains all service definitions and configuration parameters for GIS Server machines within the named Site. Data source path names are included as part of each service definition. Each GIS Server includes HTTP end points (SOAP, REST, Open Standards) available for publishing and serving Web services. HTTP access to GIS Server services is through HTTP port 6080. HTTPs secure communications with GIS Server is provided through port 6443.

When you join a new GIS Server machine to a named Site, it will automatically deploy service configurations as defined in the Site ConfigStore (service configurations are defined per GIS Server machine). The ConfigStore contains a single repository that defines all GIS Server machine configurations within a named GIS Server Site. All GIS Server machines within a site will share a single ConfigStore (a replicated copy of the ConfigStore would create a new Site). ConfigStore must be located on a file share which can be accessed by all GIS Servers within the named Site.

A GIS Server named Site can include one or more GIS Server Clusters. All GIS Server machines within a defined Site Cluster will deploy the same service configurations. Each GIS Server machine can participate in only one Site Cluster. The Site ConfigStore will contain service configurations for all Clusters defined within the named Site. The Site ConfigStore file share will also include a Server Directories file for collecting and sharing common administrative Site directories.

Inbound service requests will be assigned to one of the GIS Servers located within the named Site. The GIS Server service handler will assign the service request to the first available service instance within the named Site. If a service instance is not available on the assigned GIS Server machine, the service handler will send the request to an available service instance on another one of the GIS Server machines within the named Site for processing. All GIS Server service handlers are Site aware, which means they are able to assign an inbound service to any available service instance on any GIS Server machine within the named Site (service handler load balancing).

ArcGIS for Server includes optional Web Adaptor software that can be used to manage GIS Server inbound service requests. The Web Adaptor must be installed on a machine with a third party Web Server. The Web Adaptor is Site aware, which means that it will distribute inbound service requests across the active GIS Server machines within the named Site. The Web Adaptor can also act as a reverse proxy, accepting service requests on a configurable inbound port (i.e. Port 80) and communicating with the Site GIS Server machines on Port 6080. If any of the Site GIS Server machines fail, the Web Adaptor will route service requests only to the remaining active GIS Server machines (high availability failover functionality). A single Web Adaptor can service only one named Site. Multiple Web Adaptors can be assigned to a single named Site. Multiple Web Adaptors can be deployed on a single Web server (enables support for multiple ArcGIS for Server named Sites from a single Web server).

High availability implies there is no single software or server component failure that will results in a Site failure. A high availability configuration must include network load balancing with failover capability to ensure inbound traffic will be routed to an active Web gateway machine, at least two GIS Server machines, and high availability File Share for the ConfigStore, Server Directories, and any shared File data sources. Any DBMS data source would also need to be supported in a failover configuration. If you lose the ConfigStore or any of the required data sources, you lose the Site.

ArcGIS for Server uses certain default ports to communicate with machines over the network. The Ports used by ArcGIS 10.2 for Server are identified in the Esri ArcGIS Help.



Web platform configuration strategies
A Web site can be supported with as few as one platform or as many as six or more platforms, depending on site capacity and availability requirements. ArcGIS Server platform configuration strategy can adapt to the required system reliability, availability, and security needs. This section will address the Web software component configuration strategies. Web security requirements will be addressed in more detail in the Information Security chapter. ArcGIS for Server performance metrics are discussed in the Software Performance chapter. ArcGIS for Server platform memory recommendations are based on recommended peak active concurrent service instance (SOC) configurations supported by the selected platform configuration.

The Web system architecture design alternatives are grouped as single-tier, two-tier, and three-tier configurations as shown in Figure 7.9. Simple configurations are easier to maintain and support. More complex configurations satisfy higher-capacity and system availability requirements. Production operations are normally supported with high availability configurations (configurations that will continue providing services following any single platform failure). A high level overview of ArcGIS for Server deployment scenarios are provided in the ArcGIS Help 10.2 documentation.


 * Single-tier: All Web software components are deployed on a single platform tier.
 * Simple deployment pattern for initial ArcGIS for Server prototype testing.
 * Simple deployment pattern for the Cloud.
 * Optimum deployment pattern for hosting cached tile services.
 * Two-tier: Web Software components are deployed on two separate platform tier.
 * Web and GIS application software components are deployed on one platform tier.
 * Database application software components are deployed on a separate platform tier.
 * This is the most common deployment pattern when security is not a primary concern. It provides a common shared database for access by multiple machines on the GIS server application tier.
 * Three-tier: Software components are deployed on three separate platform tier.
 * Web application software components are deployed on one platform tier.
 * GIS application software components are deployed on a second platform tier.
 * DBMS application software components are deployed on a third platform tier.
 * Optimum configuration when deploying enterprise web applications or have a need for enhanced security. The web server is hosted on a separate platform tier.
 * High availability considerations
 * GIS server tier can add additional platforms to add capacity and satisfy availability requirements.
 * Web tier can add additional platforms to increase capacity and satisfy availability requirements.
 * DBMS tier can include a failover platform to satisfy availability requirements.

ArcGIS Server is designed to support a scalable Web architecture. Optimum platform environments are configured using standard commodity server platform technology. ArcGIS Server is licensed based on the number of platform processor core supporting the GIS Server software tier. 

ArcGIS for Server site single-tier platform configuration
ArcGIS 10.3 for Server is much easier to install and manage than the [ArcGIS 10.0 single-tier platform architecture]. The initial ArcGIS 10.3 installation takes less than 5 minutes, and a single machine is ready for publishing services from ArcGIS for Desktop without any additional installation or configuration requirements.

Figure 7.10 provides an overview of single-tier platform configurations. Single-tier configurations provide one or two platforms capable of supporting all Web service components.

Minimum Configuration: A complete Web site can be supported on a single hardware platform. This configuration is appropriate for Web service development and testing, Sites with a limited number of service requests, and initial prototype deployments. A special single chip ( 2-core) workgroup server license bundled with a Microsoft SQL Server database is available for customer sites that can be supported by a single platform configuration.

If more than one GIS Server machine is joined to a minimum configuration with inbound service requests all sent to the initial GIS Server machine, the initial GIS Server service manager will assign inbound service requests to any available GIS Server machine instances within the named Site. The ConfigStore and SvrDirectories must be shared with all GIS Server machines within the named Site and the GIS Data source must be distributed to each machine to avoid performance contention.

This is not a high-availability configuration, since if you lose the initial GIS Server machine you will lose the ConfigStore and service request distribution to the remaining GIS Server machines within the Site.

High-Availability GIS Server Site Configuration: Most GIS server production operations require redundant server solutions, configured so the site remains operational in the event of a single platform failure. A high-availability configuration must continue to support production operations during single platform maintenance and upgrade and while configuring and publishing new services. This configuration includes (1) network load balancing to route the traffic to each of the ArcGIS for Server machines during normal operations and only to the active server if one of the servers fails, (2) GIS Server Site aware service manager load balancing to distribute spatial services processing load between the GIS Server machines throughout the Site to avoid having requests back up on one server when extra processing resources are available on the other server (load balancing is automatically handled within the GIS Server Site), (3) common high availability (fault tolerant) file share for the ConfigStore and SvrDirectory files, and (4) replicated file and DBMS data sources with local copy distributed on each GIS Server machine (in some cases, performance can be adequate with file data located on the HA file share).

The GIS Servers can publish services through their native Port 6080, or a third party Web server with the Web Adaptor can be installed on the ArcGIS for Server tier for enhanced security.

For Imagery and File Geodatabase data sources, data should be deployed on each GIS Server machine or configuration should ensure high bandwidth dedicated storage network connection and high performance storage architecture to avoid potential heavy traffic and I/O contention (network or storage contention can contribute to poor Site performance).

In a mixed services environment, it is good practice to deploy image services and Cached tile services on a separate GIS Server machine from dynamic mapping services.


 * CPT Design for Web single-tier platform configuration

CPT Design tab can be used to configure and complete a single-tier System Architecture Design capacity planning analysis. 

ArcGIS for Server site two-tier platform configuration
ArcGIS 10.3 for Server is much easier to install and manage than the [ArcGIS 10.0 two-tier platform architecture].

The two-tier architecture in Figure 7.11 includes separate GIS server and data server platform tier. The Web server and GIS server components are located on the GIS server platform tier, and the data server is located on a separate data server platform. This is a popular configuration for sites with large volumes of data resources or existing data servers. A single copy of the data can support multiple GIS Server machines in conjunction with other enterprise GIS data clients.

For Imagery and File Geodatabase data sources, data should be deployed on each GIS Server machine or configuration should ensure high bandwidth dedicated storage network connection and high performance storage architecture to avoid potential heavy traffic and I/O contention (network or storage contention can contribute to poor Site performance).

Minimum Configuration: The minimum configuration includes one or more GIS Server machines with a separate tier supporting the DBMS data source. The GIS Server can publish services through its native Port 6080, or a third party Web server with the Web Adaptor can be installed on the ArcGIS for Server tier.

If more than one GIS Server machine is joined to a minimum configuration with inbound service requests all sent to the initial GIS Server machine, the initial GIS Server service manager will assign inbound service requests to any available GIS Server machine instances within the named Site. The ConfigStore and SvrDirectories must be shared to all GIS Server machines within the named Site and all GIS Server machines must have access to the DBMS data tier.

This is not a high availability configuration, since if you lose the initial GIS Server machine you will lose distribution to the remaining GIS Server machines within the Site, and the DBMS platform and ConfigStore/Svr Directory file share is not in a high availability configuration.

High-Availability Configuration: Most GIS server production operations require redundant server solutions, configured so the site remains operational in the event of a single platform failure. This configuration will continue to support production operations during single platform maintenance and upgrade and while configuring and publishing new services. This configuration includes (1) network load balancing to route the traffic to each of the ArcGIS for Server machines during normal operations and only to the active server if one of the servers fails, (2) GIS Server Site aware service manager load balancing to distribute spatial services processing load between the GIS Server machines throughout the Site to avoid having requests back up on one server when extra processing resources are available on the other server (load balancing is automatically handled within the GIS Server Site), (3) common high availability (fault tolerant) file share for the ConfigStore and SvrDirectory files, and (4) two DBMS servers that are clustered and connected to a common storage array data source. The primary data server supports query services during normal operations, and the secondary data server takes over query services when the primary server fails. Data server clustering is not required if availability requirements are satisfied with a single data server.

The GIS Servers can publish services through their native Port 6080, or a third party Web server with the Web Adaptor can be installed on the ArcGIS for Server tier for enhanced security.

In a mixed services environment, it is good practice to deploy image services and cached tile services on a separate GIS Server machine from dynamic mapping services.


 * CPT Design for Web two-tier platform configuration

CPT Design tab can be used to configure and complete a two-tier System Architecture Design capacity planning analysis. 

ArcGIS for Server site three-tier platform configuration
ArcGIS 10.3 for Server is much easier to install and manage than the [ArcGIS 10.0 three-tier platform architecture].

Three-tier configurations include Web server, GIS Server, and data server tiers.

Figure 7.12 shows an ArcGIS 10.3 three-tier configuration. This configuration includes the Web Adaptor which provides reverse proxy and network load balancing on the Web Server tier, and would likely be the most popular solution. The three-tier configuration provides a scalable architecture, where the middle tier can support two or more platforms as required to support capacity requirements.

Minimum Configuration: The minimum configuration includes a single Web Adaptor server with a separate GIS Server and separate data server. The GIS Server tier can be a single platform or can be expanded to support several platforms, depending on the required Site capacity. The Web Adaptor will distribute the inbound service load across the GIS Server machines, and the GIS Server service manager will ensure a balanced load across the GIS Server machines within the site.

High-Availability Configuration:

Most GIS server production operations require redundant server solutions, configured so the site remains operational in the event of a single platform failure. This configuration will continue to support production operations during single platform maintenance and upgrade and while configuring and publishing new services. This configuration includes (1) network load balancing to route the traffic to each of the Web Servers during normal operations and only to the active service if one of the server machines fail, (2) network load balancing to distribute the traffic to each of the GIS Server machines during normal operations and only to the active servers if one of the servers fail, (2) GIS Server Site aware service manager load balancing to distribute spatial services processing load between the GIS Server machines throughout the Site to avoid having requests back up on one server when extra processing resources are available on the other server (load balancing is automatically handled within the GIS Server Site), (3) common high availability (fault tolerant) file share for the ConfigStore and SvrDirectory files, and (4) two DBMS servers that are clustered and connected to a common storage array data source. The primary data server supports query services during normal operations, and the secondary data server takes over query services when the primary server fails. Data server clustering is not required if availability requirements are satisfied with a single data server.

The GIS Servers can publish services through their native Port 6080, or a third party Web server with the Web Adaptor can be installed on the Web Server tier for enhanced security (reverse proxy server) and site aware load balancing.

" Warning: For Imagery and File Geodatabase data sources, data should be deployed on each GIS Server machine or configuration should ensure high bandwidth dedicated storage network connection and high performance storage architecture to avoid potential heavy traffic and I/O contention (network or storage contention can contribute to poor Site performance)."

" Best Practice: In a mixed services environment, it is good practice to deploy image services on a separate GIS Server machine from dynamic mapping services."


 * CPT Design for Web three-tier platform configuration

CPT Design tab can be used to configure and complete a three-tier System Architecture Design capacity planning analysis.


 * CPT Calculator ArcGIS for Server platform configurations

The CPT Calculator can be used to configure a single user workflow for each of the three ArcGIS for Server architecture patterns.


 * CPT Calculator single-tier configuration
 * CPT Calculator two-tier configuration
 * CPT Calculator three-tier configuration

ArcGIS for Server multiple single-machine site deployment patterns
ArcGIS for Server can be deployed as individual machines in a multi-site deployment architecture, with each machine having its own dedicated ConfigStore and SvrDirectories. This architecture pattern, although more complex to administer, can provide advantages for some specific business workflows.

Some examples include the following:
 * Best practices for maintaining critical Enterprise operations often include separate development, staging, and production environments.
 * Failover GIS Server active-passive configurations may satisfy high availability requirements for organizations that wish to support peak capacity loads with a single ArcGIS for Server machine license.
 * Many organizations wish to maintain a separate data center failover location to satisfy continuity of operations planning (COOP) and disaster recovery (DR).
 * Large Web sites that wish to deploy custom high capacity GIS Server deployments for optimum throughput operations.

Single-tier, two-tier, and three-tier architecture deployment strategies discussed discussed earlier in this section can be considered for each of the multiple site configuration patterns. 


 * ArcGIS for Server multiple site integration

ArcGIS for Server can be deployed as multiple independent GIS Server site machines as shown in Figure 7.14 Independent GIS Server site configurations remove the deployment simplicity built into the adaptive GIS Server site architecture.



Business requirements drive how these sites would share service requests and common data resources. Multiple GIS Server site configurations are not aware of each other, and proper business processes must be established for keeping data, security, and services in sync. Third party load balancer, often an integral part of many large data center Web operations, must be used to distribute inbound traffic to the independent GIS Server sites.

Custom business processes must be established to maintain and distribute traffic across the GIS Server multiple site configuration.


 * Multiple site install and configuration. Each independent server machine site must be installed and configured. Any required load balancing and failover requirements must be satisfied by a third-party solution (Web Adaptor does not support multiple site load balancing operations).  In a virtual server environment, machine clones and site management tools can be used to deploy single tier GIS Server machine sites.


 * Multiple site service deployments. Custom business processes must be established for publishing and updating services across the multiple server machine farm. Published service definitions (SDs) can be used to distribute services across multiple GIS Server site machines. Properly registered data folders and database sources can simplify service deployment configuration requirements. Custom ArcPy scripts may be used to automate service deployments.


 * Multiple site data source updates. Data sources for all server machines must be in sync. Shared data sources can be used for two and three tier Web architecture patterns when server machines are located in a common location. For multiple data center and/or single tier configurations, data must be replicated or replaced on each GIS Server data source location.


 * Updating applications between sites. Custom business processes can be established to copy application files and update Web URLs across each GIS Server site.

Enterprise development, staging, and production operations
Most organizations use multiple environments to update and maintain their production operations. Separate environments are maintained for development, staging, and production.
 * Development – This is a sandbox ArcGIS Server site for testing new applications and services. Once changes are validated on the development site, they are applied to the staging site.
 * Staging – This ArcGIS Server site is a clone of the production site. This site is used for final performance and functional testing before moving to the production site.
 * Production – This site supports live business workflows. Only changes that have passed testing on the staging site are moved to the production site.

Guidelines and best practices for building and managing ArcGIS Server in development, staging, and production environments are available in the reference ArcGIS Help documentation. 

Active-Passive ArcGIS for Server Failover configurations
ArcGIS for Server sites can be configured in an active-passive failover configuration to support high-availability business needs. The primary active GIS Server site supports production operations, while the secondary failover site operates in standby mode configured to take over the production service operations in the event of primary server site failure.

The active-passive configuration requires two separate identical GIS Server site installs, each site with its own ConfigStore and SvrDirectories. A third-party load balancer solution can be configured to monitor the primary site and failover to the secondary site in the event of a primary site failure. Custom business processes must be established to maintain the multiple site configuration. Guidelines provided for development, staging, and production operations can be used to publish services and maintain data in sync at both site locations.

ArcGIS for Server active-passive failover configurations within a single data center location can be supported with a single primary server license – failover secondary server does not require a separate ArcGIS for Server license as long as it operates in a standby mode when the primary server is operational. 

Data Center COOP/DR Failover configurations
ArcGIS for Server sites can be configured in an active-passive failover configuration to support continuity of operation plans (COOP) and disaster recovery (DR) business needs. The primary active GIS Server site supports production operations, while the secondary failover site operates in standby mode configure to take over the production service operations in the event of primary server site failure. Primary site operations can be distributed (shared) between the primary and secondary data center, depending on your business needs.

Each active-passive configuration requires two separate identical GIS Server site installs, each site with its own ConfigStore and SvrDirectories. A third-party load balancer solution can be configured to monitor the primary site and failover to the secondary site in the event of a primary site failure. Custom business procedures must be established for building and maintaining the multiple site configurations. Guidelines provided for single-machine high-availability (active-passive) deployment can be used to publish services and maintain data at both multiple site locations. 

Optional high capacity single-machine GIS Server Site active-active configuration tier
Single machine ArcGIS for Server sites can be configured in an active-active high capacity configuration. Each GIS Server machine includes its own ConfigStore and SvrDirectories. GIS Server machines in this configuration are not cluster aware. Limiting use of built in cluster aware GIS Server site automation will result in a more scalable architecture. ArcGIS 10.3.1 release provides an alternative ArcGIS for Server site high scalability configuration option with cluster aware load balancing turned off.

The active-active configuration requires multiple GIS Server platform installs. A third-party load balancer must be used to assign traffic to the appropriate GIS Server sites and balance processing loads. Custom business processes must be established to maintain the GIS Server multiple site configuration. Guidelines provided for single-machine high-availability (active-active) deployment can be used to publish services and maintain data across the multiple GIS Server machine farm.

Virtual server clones can be used to build and automate platform deployment. Service definition files can be used to deploy and update services to the production platforms. Data sources can be replicated to each GIS Server platform or maintained in a common database or file share. A common service output file share can be used to support distributed service requires across the multiple platform sites.

Removing GIS Server cluster aware load balancing for optimum ArcGIS for Server site scalability
The ArcGIS 10.3.1 release provides an option to remove the cluster aware load balancing between GIS server machines. A single ArcGIS for Server site cluster deployment option is preferred over deploying multiple active-active server sites. There are several administrative advantages in deploying server machines in a single site cluster, taking advantage of a common config store and sharing common service configurations.

Removing GIS Server cluster aware load balancing between GIS Server machines reduces the communication overhead of a standard ArcGIS for Server cluster deployment, providing scalability comparable with a multi-site server deployment with the advantages of a shared configuration store and common data source.

To remove ArcGIS for Server cluster aware load balancing, the following criteria must be met:
 * All GIS servers in the site must participate in a single cluster. Multiple clusters cannot exist.
 * An external load balancer or ArcGIS Web Adaptor must be configured to forward requests to the GIS servers in the site. If no external gateway exists, requests will only be handled by the GIS server designated in the request.

Additional multiple site deployment considerations
Multiple ArcGIS for Server site configurations are not the optimum solution for most organizations. There are potential benefits – multiple site deployment configurations may adapt well with other Web Service business processes, particularly in large virtualized data center operations or cloud deployments. Multiple site configurations extend support for operations across multiple data center locations. For small organizations, an active-passive failover solution may reduce licensing costs.

There is no single best solution for all organizations. ArcGIS provides an open platform that supports the simplicity requirements of most customers, along with the flexibility to expand and adapt to meet the needs of the most advanced organizations. System architecture design planning can help identify what solution pattern works best for your organization. Understanding your business requirements and the technology available to satisfy your business needs is critical in building a GIS that works best in your environment.

ArcGIS Platform deployment strategies
ArcGIS platform deployment strategies can include a mix of self-managed and vendor-managed configuration options.

Key ArcGIS components for Web GIS
 * Web Apps
 * GIS portal
 * GIS service framework
 * Ready-to-use content

ArcGIS platform configuration strategies
 * Software as a Service (SaaS)
 * > ArcGIS Online Organization; Hosted services online; Online basemaps and services


 * Software/data installed on-premises or in a private cloud
 * > Portal for ArcGIS; ArcGIS for Server; Data Appliance for ArcGIS

" Best Practice: Deployment strategies can include a mix of self-managed and vendor-managed hardware option."

There are a few self-managed deployment options:
 * Non-cloud on-premise ArcGIS for Server deployment
 * Infrastructure as a Service (IaaS)-based community private cloud deployment
 * Hybrid deployment, including IaaS and on-premises services

There are also vendor-managed deployment options:
 * IaaS-based community private cloud deployment
 * Hybrid of IaaS public and private cloud services
 * Vendor-managed IaaS-based public cloud deployment
 * Public SaaS-based deployment

How you deploy your ArcGIS Platform depends on your business requirements, as described by this video on ArcGIS Deployment Patterns.

Portal for ArcGIS platform configuration
Figure 7.20 shows an overview of the Portal for ArcGIS configuration. Portal for ArcGIS can be installed on a standalone Web server or as part of a federated ArcGIS for Server configuration.

Portal for ArcGIS is installed on a Web server with a dedicated ArcGIS for Server Web adaptor. The server includes an identity store which contains Portal member user names, passwords, and roles. Members of the Portal organization can create Web maps, add services to their content, and share content with groups and other members throughout their organization.

Portal for ArcGIS 10.3 includes documentation for installing a high availability Portal configuration.

Registered Web services
Web services referenced in Web maps or added to the Portal are considered registered services. Web maps can be created from Public or internal published Web services.

Federated ArcGIS for Server sites
Internal ArcGIS for Server sites can be federated with Portal for ArcGIS. Federated ArcGIS for Server site web services are published and shared by the Portal content management interface. Federated ArcGIS for Server sites are managed as part of the Portal configuration. Access authorization for all federated ArcGIS for Server sites are managed by the Portal for ArcGIS identify store.

"Note: Only ArcGIS Server sites using version 10.2 or later can be federated with a portal."

Hosting server site
A federated ArcGIS for Server site can be fully integrated with your portal if you designate it as a hosting server. A hosting server allows portal users to:
 * Publish tiled map and feature services to the portal from ArcGIS for Desktop.
 * Share layers and maps from Esri Maps for Office.
 * Create maps by adding CSV files and shapefiles from local machines to the portal map viewer.
 * Publish CSV and shapefiles as feature services from the portal website.

Portal for ArcGIS can be deployed in a variety of configurations adapting to your hosting requirements. A dedicated Web Adaptor must be deployed with Portal for ArcGIS. A registered database is required to support published feature services; recommend use of the data store introduced with the ArcGIS 10.3 release for optimum performance and scalability.

The Capacity planning tool includes features for sizing a Portal for ArcGIS configuration.

Concluding Remarks
There are several factors that should be considered when establishing your enterprise data center architecture. Many of these factors are determined based on business needs and standard IT operating procedures.

The primary focus for Esri system architecture design services is to identify hardware and infrastructure resources that satisfy user productivity needs during peak GIS system loads. This effort focuses on the primary production hardware and available network infrastructure bandwidth required to support GIS operations.

Other factors contribute to the final system configuration. These factors include provisions for system maintenance, updates, configuration control, software licensing, and security. System requirements often include hardware provisions for application development, system test, production staging, background processing (i.e. map cache maintenance and replication services), system backup, and security. System migration will normally include continued support for legacy operations while introducing new technology, often on separate hardware environments.

An Enterprise GIS design includes business, application, data, and technical architecture requirements. The Capacity Planning Tool provides a framework that models enterprise GIS performance and scalability, integrating the full range of Enterprise system design requirements into a solution that represents your GIS production needs.

Previous Editions
GIS Product Architecture 36th Edition GIS Product Architecture 35th Edition GIS Product Architecture 34th Edition GIS Product Architecture 33rd Edition GIS Product Architecture 32nd Edition GIS Product Architecture 31st Edition GIS Product Architecture 30th Edition GIS Product Architecture 29th Edition GIS Product Architecture 28th Edition GIS Product Architecture 27th Edition

Page Footer Specific license terms for this content System Design Strategies 26th edition - An Esri ® Technical Reference  Document • 2009 (final PDF release)