GIS Product Architecture 34th Edition

From wiki.gis.com
Jump to: navigation, search
System Design Strategies (select here for table of contents)
System Design Strategies 34th Edition (Spring 2014)
1. System Design Process 2. GIS Software Technology 3. Software Performance 4. Server Software Performance
5. GIS Data Administration 6. Network Communications 7. GIS Product Architecture 8. Platform Performance
9. Information Security 10. Performance Management 11. System Implementation 12. City of Rome
A1. Capacity Planning Tool B1. Windows Memory Management A3. Acronyms and Glossary Preface (Executive Summary)



Spring 2014 GIS Product Architecture 34th Edition

This edition will focus on the ArcGIS 10.2 product architecture. The ArcGIS 10.1 release introduced some significant ArcGIS for Server software architecture improvements which were carried forward with the ArcGIS 10.2 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.

Figure 7.1 Esri ArcGIS System Environment

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.

Figure 7.2 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. Vector data types are used to represent geographic points, lines, and areas (polygons). Other spatial data types include scanned drawings, global positioning system (GPS) coordinates, satellite imagery, survey measurements, photogrammetry, and aerial photography, all of which can be georeferenced to establish proper placement within a geographic map display. GIS technology is currently being used in business, government, public safety, defense and intelligence, health and human services, utilities and transportation, education, and natural resources to manage and understand spatial relationships.

How the spatial data is maintained and published within the organization contributes to the performance and scalability of the system design. The volume of spatial data used to support a GIS has grown exponentially over the last 10 years. Many operational GIS environments maintain and support several terabytes of active GIS data resources with megabytes of data reviewed and processed within a typical user display session. This data must be organized and managed to support effective and efficient GIS operations. GIS data deployment patterns are discussed in more detail in the SDSwiki 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 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.

ArcSDE Geodatabase

Figure 7.3 ArcSDE Components

The ArcGIS technology includes a spatial database engine (ArcSDE) for managing and sharing GIS data. Figure 7.3 provides an overview of the ArcSDE components. Every ArcGIS software product includes an ArcSDE communications client. The ArcSDE schema includes relationships and dependencies used to manage geodatabase versioning and replication functionality. The ArcSDE schema also includes the geodatabase license code stored in host DBMS tables. ArcSDE also includes an executable that enables communications between ArcGIS software components and the supported DBMS. The ArcSDE executable is included in the ArcGIS DBMS direct connect application program interface (api), and is also available for install on the DBMS server or middle server tier as a separate application executable (GSRVR). ArcSDE Geodatabase memory guidelines are generated based on peak concurrent ArcSDE Geodatabase connections supported by the selected platform configuration.

Direct Connect. In an ArcSDE Direct Connect (DC) configuration, The SDE Direct Connect API communicates directly with a local DBMS client, and the DBMS client API is used to communicate with the DBMS server. SDE processing is performed on the platform hosting the GIS application (Workstation or Terminal Server for ArcGIS for Desktop applications, and on the GIS Server host machines for ArcGIS for Server workflows).

Best Practice: ArcSDE Direct Connect is the recommended method for connecting to supported SDE Geodatabase servers.

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

SDE License Key. SDE license key must be installed in the DBMS with the ArcSDE schema to enable an ArcSDE Geodatabase. The DBMS server processor core count toward license pricing only in the ASC configuration, when the SDE GSRVER process is running on the DBMS server. SDE license key can be installed on any number of SDE Geodatabase servers within the licensed site.

ArcGIS for Desktop architecture patterns

Figure 7.4 ArcGIS for Desktop Software Architecture
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 communication 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

Figure 7.5 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.2 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, and 10.2 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 supported with the ArcGIS 10.2 release but no longer relevant for most implementations.
  • 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 <RDS> 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.

Figure 7.6 Centralized Remote Desktop Client architecture

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.2 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.

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 supported with the ArcGIS 10.2 release but no longer relevant for most implementations.
  • 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.

Figure 7.7 ArcGIS 10.2 for Server Software Architecture

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 connected 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 or Internet clients or as a network service for local desktop clients. 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 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.2 release is an upgrade of the same ArcGIS 10.1 for Server architecture. Primary software components associated with the ArcGIS for Server 10.2 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.2 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 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.2 for Server key site aware component functions

Figure 7.8 ArcGIS 10.2 for Server architecture terminology
Figure 7.8 provides an overview of the terminology used to describe the ArcGIS 10.2 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 on the Internet and intranet. The Ports used by ArcGIS 10.2 for Server are identified in the Esri ArcGIS Help.


Web platform configuration strategies

Figure 7.9 ArcGIS 10.2 for Server platform tier architecture
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.
  • 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 and 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.

Single-Tier Platform Configuration

Figure 7.10 Single-Tier Platform Configurations
ArcGIS 10.2 for Server is much easier to install and manage than the [ArcGIS 10.0 single platform architecture]. The initial ArcGIS 10.2 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 standard 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 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 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 (3) 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 heavy traffic contention.

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 single-tier platform configuration

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

Two-Tier Platform Configuration

Figure 7.11 Two-Tier Platform Configurations (Separate Data Servers)
ArcGIS 10.2 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 GIS server and data server platforms. The Web server and GIS server components are located on the GIS server platform, 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 server components in conjunction with other enterprise GIS data clients.

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 standard 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.

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 heavy traffic contention.

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 two-tier platform configuration

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

Three-Tier Platform Configuration

Figure 7.12 ArcGIS for Server Three-Tier Platform Configurations
ArcGIS 10.2 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.2 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 heavy traffic contention.
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


Portal for ArcGIS platform configuration

Figure 7.12.1 Portal for ArcGIS Platform Configurations can include registered Web services, federated ArcGIS for Server sites, and a hosting ArcGIS for Server site.
Figure 7.12.1 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.

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. Separate Web Adaptors can be deployed for each federated ArcGIS for Server site included in the Portal configuration.

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.

CPT Capacity Planning videos

Previous Editions

Fall 2013 GIS Product Architecture 33rd Edition
Spring 2013 GIS Product Architecture 32nd Edition
Fall 2012 GIS Product Architecture 31st Edition
Fall 2011 GIS Product Architecture 30th Edition
Spring 2011 GIS Product Architecture 29th Edition
Fall 2010 GIS Product Architecture 28th Edition
Spring 2010 GIS Product Architecture 27th Edition

System Design Strategies (select here for table of contents)
System Design Strategies 34th Edition (Spring 2014)
1. System Design Process 2. GIS Software Technology 3. Software Performance 4. Server Software Performance
5. GIS Data Administration 6. Network Communications 7. GIS Product Architecture 8. Platform Performance
9. Information Security 10. Performance Management 11. System Implementation 12. City of Rome
A1. Capacity Planning Tool B1. Windows Memory Management A3. Acronyms and Glossary Preface (Executive Summary)

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