GIS Product Architecture 31st Edition

From wiki.gis.com
Jump to: navigation, search
System Design Strategies
System Design Strategies 31st Edition (Fall 2012)
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 A2. ESD Planning tools A3. Acronyms and Glossary



Fall 2012 GIS Product Architecture 31st Edition

This edition will focus on the ArcGIS 10.1 product architecture. The ArcGIS 10.1 release includes some significant ArcGIS for Server software architecture improvements. The [System Design Strategies 30th Edition] provides a similar overview of the ArcGIS 10.0 product architecture.

GIS Product Architecture provides a foundation for understanding 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 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, and map cache. Additional data sources 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.

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

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 translates 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).

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 SOC host machines for ArcGIS for Server workflows).

Remote Server Connect. SDE and the DBMS client can be installed on a middle tier server. In this configuration, the SDE API is used by the ArcGIS application to access the remote SDE server, SDE communicates directly with the DBMS client, and the DBMS client API is used to communicate with the DBMS server. SDE processing loads would be applied to the installed remote server.

ArcSDE Application Server Connect. In the ArcSDE Application Server Connect (ASC) configuration, the SDE API is used by the ArcGIS client application to access the SDE process located on the DBMS server.

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. The .NET framework is used as the primary programming environment for ArcGIS Desktop applications and Python is the primary scripting language. 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 an SDE Geodatabase 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. 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. Remote clients should be supported using terminal access to a central Windows Terminal Server located with the SDE Geodatabase.

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.

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 data source, and two ArcSDE connect options to an SDE geodatabase data source.

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 two options for accessing the SDE geodatabase. The direct connect option (SDE_DBMS DC) includes the ArcSDE executables as part of the direct connect API and will communicate with a database client installed on the same machine. The database client will support network communications to the database server. The SDE DBMS connect (SDE_DBMS ASC) option supports network communication with a remote geodatabase server (ArcSDE can be supported as an ArcGIS for Server geodata service or installed on the DBMS server). Query requests are sent to the data server and processed by the supported DBMS software. All data is stored and maintained in the DBMS repository.

CPT Calculator ArcGIS for Desktop workstation workflows

Software selections include ArcGIS 9.3.0, 9.3.1, 10, and 10.1 workflows. The CPT Calculator supports three of the ArcGIS for Desktop workstation configuration patterns.

  • SDE Direct Connect (DC) architecture
  • SDE Application Server Connect (ASC) architecture
  • File data source architecture
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

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) to support communication between the terminal server and the Windows client.

The Citrix Xen Application Server (XenApp) enables a more efficient independent computing architecture (ICA) communication 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. Xen Application Server includes 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-13 Centralized ArcGIS Desktop Client

Esri has certified ArcGIS 10 SP2 as a hosted application with Citrix XenApp 6 and Windows 2008 R2 using the Citrix ICA Onnline Pulg-in for Windows 12.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-13. 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, and two ArcSDE connect options to a geodatabase (one connecting through a middle tier ArcGIS Server and the other connecting to ArcSDE installed on the database server).

The Windows terminal client communicates with the Windows Terminal Server through a compressed message-oriented communication protocol. Terminal clients have a persistent connection with the Windows Terminal Server ArcGIS for Desktop session; lost connections are reinstated without losing the session. 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 may 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
  • SDE Application Server Connect (ASC) architecture
  • File data source architecture

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.

  • SDE Direct Connect (DC) architecture
  • SDE server connect (remote server)
  • SDE Application Server Connect (ASC) architecture
  • File data source architecture

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-21 ArcGIS 10.1 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 is a major release for Server. ArcGIS 10.1 for Server includes all the primary functionality of ArcGIS 10 delivered in a new 64-bit JAVA based software component architecture. Primary software components associated with the ArcGIS for Server 10.1 software architecture are identified in Figure 7-21.

ArcGIS 10.1 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. A new optional Web Adaptor component is included with the ArcGIS for Server install package for improved security and network load balancing. Application Development Framework (ADF) software components are no longer supported with the ArcGIS 10.1 release.


ArcGIS 10.1 for Server Enhancements

ArcGIS 10.1 for Server is designed for rapid deployment and friendly administration. Server enhancements improve installation, performance, reliability, administration, cloud deployment options, and more Linux friendly software compatibility.

  • Installation is much quicker and simpler, no windows registry components, fewer Windows/Linus user accounts, and no post-install requirements.
  • Runs as a 64-bit native application with improved software performance.
  • More robust architecture with fewer single points of failure, automated configuration management, and better recovery from process failures.
  • Administration is scriptable through an administrative REST admin API.
  • Designed for elastic cloud deployments, with adaptive site aware configuration management.
  • Much more Linux friendly with a new Java software component architecture.

ArcGIS 10.1 for Server supports the same access to data and services as ArcGIS 10 while expanding Web application client interfaces. Migration of rich internet applications from ArcGIS 10 to ArcGIS 10.1 is painless and simple.


ArcGIS 10.1 for Server key site aware component functions

Figure 7-22 ArcGIS 10.1 for Server architecture terminology
Figure 7-22 provides an introduction of terminology used to describe the ArcGIS 10.1 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 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 that 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 defines 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.

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.


Web platform configuration strategies

Figure 7-23 ArcGIS 10.1 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.

The Web system architecture design alternatives are grouped as single-tier, two-tier, and three-tier configurations as shown in Figure 7-23. 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.1 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. ArcGIS for Server Recommended platform configuration strategies will be provided for the three configuration alternatives identified above. Five ArcGIS for Server workflows will be used to represent the user requirements in the CPT Design examples.

  • Rest mapping workflow (AGS101 REST MSD R 100%Dyn Med 10x7 JPEG)
  • REST mapping workflow with cached basemap (AGS101 REST MSD R 40%Dyn Med 10x7 JPEG +$$)
  • REST feature editing workflow with cashed basemap (AGS101 REST MSD V 20%Dyn Med 10x7 Feature +$$)
  • Fully cached map service (AGS Full MapCache Service)
  • Imagery service with Mosaic dataset (AGS101 Imagery MosaicDS R 100%Dyn Med 10x7 JPEG)


Single-Tier Platform Configuration

Figure 7-24 Single-Tier Platform Configurations
ArcGIS 10.1 for Server is much easier to install and manage than the [ArcGIS 10.0 single platform architecture]. The initial ArcGIS 10.1 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-24 provides an overview of single-tier platform configurations. Single-tier configurations provide one or two platforms capable of supporting all Web service components.

Standard 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

The CPT Design includes several integrated modules used for completing the system architecture design. ArcGIS for Server workflow selection is made in the user Requirements Analysis module. Platform tier nicknames (followed by a colon) and selected hardware platform can be modified to represent your deployment environment. Software platform configuration is identified by selecting a platform nickname from the highlighted software component drop-down list on each workflow row. Data source selection is made for each workflow row.

The single tier software configuration would host the Web, GIS Server, and and DBMS data source all on a single platform tier.

Once the CPT Design is properly configured to represent your business requirements and selected hardware, the Workflow Performance Summary shows the software service time distribution and expected client display response time for each workflow and the platform section shows the number of required platform nodes and processing loads on the selected platform tier.

Two-Tier Platform Configuration

Figure 7-29 Two-Tier Platform Configurations (Separate Data Servers)
ArcGIS 10.1 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-29 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.

Standard Configuration: The standard 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

The CPT Design includes several integrated modules used for completing the system architecture design. ArcGIS for Server workflow selection is made in the user Requirements Analysis module. Platform tier nicknames (followed by a colon) and selected hardware platform can be modified to represent your deployment environment. Software platform configuration is identified by selecting a platform nickname from the highlighted software component drop-down list on each workflow row. Data source selection is made for each workflow row.

The two tier software configuration would normally host the Web and GIS Server on one platform tier, and the DBMS server on a separate platform tier.

Once the CPT Design is properly configured to represent your business requirements and selected hardware, the Workflow Performance Summary shows the software service time distribution and expected client display response time for each workflow and the platform section shows the number of required platform nodes and processing loads on the selected platform tier.

Three-Tier Platform Configuration

Figure 7-34 ArcGIS for Server Three-Tier Platform Configurations
ArcGIS 10.1 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-34 shows an ArcGIS 10.1 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.

Standard Configuration: The standard 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.

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

The CPT Design includes several integrated modules used for completing the system architecture design. ArcGIS for Server workflow selection is made in the user Requirements Analysis module. Platform tier nicknames (followed by a colon) and selected hardware platform can be modified to represent your deployment environment. Software platform configuration is identified by selecting a platform nickname from the highlighted software component drop-down list on each workflow row. Data source selection is made for each workflow row.

The three tier software configuration would normally host the Web server on one platform tier, the GIS Server on a second platform tier, and the DBMS server on the third platform tier.

Once the CPT Design is properly configured to represent your business requirements and selected hardware, the Workflow Performance Summary shows the software service time distribution and expected client display response time for each workflow and the platform section shows the number of required platform nodes and processing loads on the selected platform tier.

CPT Calculator ArcGIS for Server platform configurations

The CPT Calculator can be configured 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

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 Video: GIS Product Architecture

Previous Editions

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
System Design Strategies 31st Edition (Fall 2012)
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 A2. ESD Planning tools A3. Acronyms and Glossary


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