GIS Product Architecture 30th Edition (Fall 2011)

From wiki.gis.com
Jump to: navigation, search
System Design Strategies
System Design Strategies 30th Edition (Fall 2011)
1. System Design Process 2. GIS Software Technology 3. Software Performance 4. GIS Data Administration
6. Network Communications 7. GIS Product Architecture 9. Platform Performance 8. Information Security
5. Performance Fundamentals 10. Capacity Planning Tool 11. City of Rome 12. System Implementation



Fall 2011 GIS Product Architecture 30th Edition

This section 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 6-1.

Figure 6-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, Image servers, and map cache. Additional data sources are available from ArcGIS Online and other Internet data sources.

ArcGIS Desktop Clients: ArcGIS Desktop clients are licensed at three levels do address specific user application needs. ArcInfo provides the full suite of standard desktop technology used by GIS professionals, ArcEditor provides functionality focusing on data maintenance and administration, and ArcView provides view and query functionality. ArcGIS Engine is a programming environment for developing custom GIS applications.

Application Servers: GIS applications are supported within the distributed configuration by hardware platforms that execute GIS functions. In a centralized solution, Windows Terminal Server and Web application 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. Web application servers 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, and general public access to published GIS resources over the Web.

ArcGIS System Software Architecture

ArcGIS is an integrated collection of software components available for building a complete geographic information system. The ArcGIS family of software products is 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 initially developed leveraging Microsoft Component Object Model (COM) programming technology. Figure 6-2 provides an overview of the ArcGIS software component architecture.

Figure 6-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 Desktop can be deployed on client workstations or hosted by a Windows Terminal Server. Custom ArcGIS Engine applications include the same ArcObjects 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 Server is deployed in a scalable Web application server architecture. The Web server solutions include a software component architecture supporting application development and system performance and scalability. Recommended platform configuration strategies will be provided for both standard and high availability Web solutions.

GIS applications support an open systems architecture. The GIS 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 6-3 ArcSDE Components
The ArcGIS technology includes a spatial database engine (ArcSDE) for managing and sharing GIS data. Figure 6-3 provides an overview of the ArcSDE components. Every Esri 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 ArcObjects and the supported DBMS. The ArcSDE executable is included in the ArcGIS ArcObject 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).

CPT Calculator ArcSDE Architecture

Figure 6-4 shows how the ArcSDE Architecture connections are made in the CPT Calculator (DC-Direct Connect or ASC-Application Server Connect) using the platform architecture selection in cell A11. The top left result shows an ArcGIS Server 10 REST MSD Light Web mapping workflow in a two tier server configuration with ArcSDE GSRVR installed on the DBMS platform (ASC connect). The bottom right result shows the same Web mapping workflow with an ArcSDE Direct Connect configuration.

Figure 6-4 CPT Calculator ArcSDE Connection Performance Comparison

User performance is roughly the same for both configuration options (0.3 seconds for local users) and remote user traffic is the same. Web server load increases from 19.3 to 22.0 percent, and the DBMS server load decreases from 6.2 to 3.1 percent. The DBMS server peak capacity increases from 1078 to 2156 users.

ArcSDE Direct Connect is the recommended ArcSDE DBMS configuration for most GIS environments. The following connection will provide more information on performance of the available ArcSDE configuration alternatives.

ArcSDE DBMS Configuration Alternatives

Many Esri customers continue to configure ArcSDE on the DBMS server. Most customers are moving to a direct connect architecture to simplify administration and reduce licensing costs. Esri continues to fully support both ArcSDE geodatabase configuration strategies.

Capacity Planning Design Software Configuration Module

The Capacity Planning Design includes a software install module for configuring workflow software components on the appropriate server platform environments. The design tab supports an Enterprise data center configuration with up to 10 separate platform tier. Different server platforms can be identified for each platform tier, and each platform tier can expand to include an unlimited number of server nodes (server platforms). Figure 6-5 provides an overview of the CPT Design software configuration module.

Figure 6-5 Capacity Planning Design Software Configuration Module

Workflow application software components (Client, WTS Citrix, Web2, Web1, SOC, SDE, DBMS) are identified in columns I through P on row 4 of the CPT Design tab. Appropriate application software components are highlighted based on the selected workflow software technology pattern. Dropdown menus are available for each software component on each workflow row, providing a list of the available platform installation selections. A default platform selection for each software column is provided in row 5 (default platform selections on the workflow rows will be installed on the default platform selection in row 5 at the top of each column). The SDE software (column N) default setting in row 5 will implement an ArcSDE direct connect configuration (SDE processing load will be assigned to the application software component). The SDE processing load assignment for each workflow is indentified in column O. Data source selection for each workflow is made in column Q.


ArcGIS Desktop Client/Server Configurations

ArcGIS Desktop software is supported on Microsoft Windows desktop and terminal server platform environments. ArcGIS Engine is a software development kit providing ArcObjects components for custom desktop application development. Visual Studio is used as the primary programming language for ArcGIS Desktop applications and Python is the primary scripting language. Figure 6-6 provides an overview of the primary software components supporting the ArcGIS Desktop application workflow.

Figure 6-6 ArcGIS Desktop Software Architecture

ArcGIS Desktop is deployed in a client/server architecture. The client applications are tightly coupled with the GIS 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 data source. Communications between the ArcGIS Desktop application and the GIS data source should be supported over 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 GIS data source. ArcGIS Desktop maintenance includes user licensed Web access to worldwide high quality image cache basemaps (Microsoft Virtual Earth - Bing Imagery).

ArcGIS Desktop software supports connection to local file and Imagery data sources, DBMS sources through an ArcSDE interface, map cache, and published Web data services. Web data services can be integrated with local data in a standard GIS map display.

ArcGIS Desktop Workstation Architecture

Four distributed ArcGIS Desktop client configuration alternatives are identified in Figure 6-7. These configurations include access to a network file data source, direct connect access to an ArcSDE data source, and two ArcSDE connect options to an ArcSDE data source (one connecting through a middle tier ArcGIS Server and the other connecting to ArcSDE installed on the database server).

Figure 6-7 ArcGIS Desktop Workstation Architecture

The ArcGIS 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 CIFS or similar UNIX 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 Desktop application.

The CPT Design software configuration module includes a data source selection for each user workflow. For an ArcGIS Desktop workflow, Select file data source (SFG_Small File GDB, LFG_Large File GDB, SSF_Small Shape File, LSF_Large Shape File, or Img_Image) in column Q of the software configuration module for each user workflow. Workflows with a selected file data source do not show DBMS or SDE software service times (cells are black). Appropriate application query loads (Workstation/terminal server desktop application or server SOC) are adjusted based on the file data source selection.

ArcGIS Desktop software provides two options for accessing the SDE geodatabase. The direct connect option 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 ArcSDE connect option supports network communication with a remote geodatabase server (ArcSDE can be supported as an ArcGIS Server geodatabase 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.

The CPT Design software configuration module includes a data source selection for each user workflow. Select SDE DBMS data source when configuring user workflow access to an SDE Geodatabase. When SDE DBMS is selected, workflow will include SDE and DBMS software that must be installed on a selected platform tier. The SDE platform selection determines the connection architecture.

Direct Connect. A default SDE selection is used to designate a Direct Connect architecture. In an ArcSDE Direct Connect configuration, the SDE processing is performed by the SDE Direct Connect API located on the platform hosting the GIS application (Workstation or Terminal Server for ArcGIS Desktop applications, and on the SOC host machines for Server workflows).

Figure 6-8 CPT Calculator Data Source Comparison

Remote Server Connect. Select the platform tier used for the remote server when configuring a three tier ArcSDE connection. SDE and the DBMS client processing loads will be assigned to the selected remote server.

ArcSDE Application Server Connect. Select the DBMS server when the SDE GSRVR will be installed on the DBMS. SDE processing loads will be assigned to the DBMS server.

Figure 6-8 shows the three CPT Calculator configuration options for and ArcGIS Desktop 10 Workstation workflow. Top left analysis shows CPT Calculator result when using a small File Geodatabase data source, middle analysis shows CPT Calculator result when using an ArcSDE connection (ASC) to a DBMS geodatabase, and the bottom right shows CPT Calculator result when using an ArcSDE Direct Connect architecture. The CPT Calculator does not support a three tier ArcSDE configuration (SDE remote server).

Figure 6-9 CPT Design Requirements Module ArcGIS Desktop Software Configuration Overview

Figure 6-9 shows the software configuration and the Arc10 Platform Service times sections included with the CPT Design requirements module. Four ArcGIS Desktop Workstation workflows, representing each of the data source selection options (Small File GDB, SDE Direct Connect, SDE Remote Server, SDE connect), are included in each result. The top view shows the install configurations, and the bottom view shows the resulting software processing loads.

Figure 6-10 CPT Design ArcGIS Desktop System Architecture Design Overview

Figure 6-10 provides a full view of the CPT Design solution for the same four ArcGIS Desktop Workstation workflows. The Workflow Performance Summary shows the software service time distribution and expected client display response time for each workflow, while the platform section shows the processing loads on the selected SDE remote server and the DBMS.

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.

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.

Figure 6-11 Centralized ArcGIS Desktop Client
Four distributed ArcGIS Desktop configuration alternatives are identified in Figure 6-11. All configurations are supported by remote terminal client access to ArcGIS Desktop applications hosted on a central Windows Terminal Server. ArcGIS Desktop 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 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 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.

Figure 6-12 CPT Calculator Windows Terminal Server (Citrix) Data Source Comparison
Figure 6-12 shows the three CPT Calculator configuration options for the ArcGIS Desktop 10 Windows Terminal Server workflow. Top left analysis shows CPT Calculator result when using a small File Geodatabase data source, middle analysis shows CPT Calculator result when using an ArcSDE connection (ASC) to a DBMS geodatabase, and the bottom right shows CPT Calculator result when using an ArcSDE Direct Connect architecture.


Figure 6-13 CPT Design Requirements Module ArcGIS Desktop Windows Terminal Server (Citrix) Software Configuration Overview
Figure 6-13 shows the software configuration and the Arc10 Platform Service times sections included with the CPT Design requirements module. Four ArcGIS Desktop Windows Terminal Server (Citrix) workflows, representing each of the data source selection options (Small File GDB, SDE Direct Connect, SDE Remote Server, SDE connect), are included in each result. The top view shows the install configurations, and the bottom view shows the resulting software processing loads.


Figure 6-14 CPT Design ArcGIS Desktop Windows Terminal Server (Citrix) System Architecture Design Overview
Figure 6-14 provides a full view of the CPT Design solution for the same four ArcGIS Desktop Windows Terminal Server workflows. The Workflow Performance Summary shows the software service time distribution and expected client display response time for each workflow, while the platform section shows the processing loads on the selected SDE remote server and the DBMS. The file data share in row 65 shows data traffic flow of 3.3 Mbps and network interface card (NIC) bandwidth (10 Gbps) for the common file share.


ArcGIS Server Web 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. Critical components associated with the Web services communication architecture are identified in Figure 6-15.

Figure 6-15 Web Services Software Architecture

Web 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 Server software. ArcGIS Server provides an ArcObjects software-based server development environment for deploying GIS server-based ArcGIS applications and services. ArcGIS Server can be deployed in a Web architecture or as a LAN/WAN network service for desktop clients. ArcGIS Server is also used to deploy "smart client" mobile GIS technology. Smart clients are loosely connected, lightweight, handheld or desktop computers that support persistent data cache and disconnected GIS client operations. Client application deployment and data synchronization are managed by ArcGIS Server parent services. ArcGIS Imagery services are fully integrated into ArcGIS Desktop and ArcGIS Server with the ArcGIS 10 release.

The software architecture components for ArcGIS Server include Web applications (WAS), service object manager (SOM), server object container (SOC), and data server (DS) component functions 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 can directly impact system capacity, service reliability, and overall output performance.

ArcGIS Server Component Architecture

ArcGIS Server is a set of objects, applications, and services that make it possible to run ArcObjects components on a server platform environment. Server objects are managed and run within the GIS server. Server applications make use of server objects and may also use other ArcObjects components that are installed on the GIS server.

The Web server hosts server applications and Web services developed using the ArcGIS Server application programming interface. These Web services and Web applications can be developed using the ArcGIS Server ADF map viewer and map editor, which is available for both .NET and Java developers and supported within the associated Web application server development environments. The ArcGIS Server ADF components will not be supported beyond the ArcGIS 10 release.

Figure 6-16 provides an overview of the ArcGIS Server component architecture and the associated software functional locations. The ArcGIS Server architecture includes four configuration groups of software identified as Web applications, service manager, spatial services, and data source.

Figure 6-16 ArcGIS Server Component Architecture

The ArcGIS Server configuration groups include the following:

Web Applications: The ArcGIS Server WAS components include a commercial Web HTTP server supporting communications with the Web clients and a Web application server development environment for .NET or Java Web applications or Web service catalogs. ArcGIS Server includes a Web tier that includes a .NET and Java Application Development Framework. ArcGIS Server also includes software components for simple object access protocol (SOAP) and representational state transfer (REST) Web service application program interfaces (APIs). ArcGIS Server includes translation of mapping services to a variety of Open Geospatial Consortium APIs, including WMS (Web Mapping Service for simple map images), WFS (Web Feature Service for streaming points, lines, and polygons), WCS (Web Coverage Service for raster and image steaming), CWS (Catalog Web Services for metadata searches), and KML (Keyhole Markup Language) for integration with Google Earth clients.

Server Object Manager: A server object manager (SOM) controls service object deployment and initial application assignment to deployed server object containers. SOM performs as a parent process, controlling service load balancing and managing deployment of published service configuration instances based on active inbound service request loads.

Server Object Container: The container machines (one or more depending on peak transaction requirements) host the server object containers (SOCs) that are managed by the SOM. Each service configuration is supported by dedicated SOCs. The server objects hosted within each SOC are supported by ArcObjects components installed on the container machine.

Data Source: The data server (GIS data source) is where the GIS data is stored. An ArcSDE data source supports the query processing functions. Standard GIS image or file data sources are also represented at this level.

Services available on ArcGIS Server can be published for use by intranet LAN or WAN applications. Application service assignment can be provided with direct access to the SOM without using the Web server interface.

Web Platform Configuration Strategies

A Web site can be supported with as few as one platform or as many as six or more platforms, depending on site capacity and availability requirements. ArcGIS Server platform configuration strategy can adapt to the required system reliability, availability, and security needs. This section will address the Web software component configuration strategies. Web security requirements will be addressed in more detail in the Information Security chapter. ArcGIS 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. 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).

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 primary ArcGIS Server software components. Following are recommended platform configuration strategies for supporting standard GIS Web services.

Single-Tier Platform Configuration

Figure 6-17 provides an overview of single-tier platform configurations. Single-tier configurations provide one or two platforms capable of supporting all Web service components. Most initial customer deployments with a small database can be supported by a single-tier architecture.

Figure 6-17 Single-Tier Platform Configurations

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 workgroup server license bundled with a Microsoft SQL Server database is available for customer sites that can be supported by a single platform 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 servers during normal operations and only to the active server if one of the servers fails, (2) service manager load balancing to distribute spatial services processing load between the two platforms to avoid having requests back up on one server when extra processing resources are available on the other server (separate SOC containers are required on each platform to support this configuration), and (3) duplicated data servers that require a complete copy of the data.

ArcGIS Server Image Extension single tier platform configuration

Figure 6-18 provides an overview of single-tier ArcGIS Server Image service extension platform configurations. ArcGIS Server Image extension is fully integrated with ArcGIS Server with the ArcGIS 10 release. Image extension configuration is unique due to the potential high volume of the image data source.

Figure 6-18 Single-Tier ArcGIS Server Image Extension Platform Configurations

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. Imagery would be installed on the server internal disk storage for a single tier architecture.

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 servers during normal operations and only to the active server if one of the servers fails, (2) service manager load balancing to distribute spatial services processing load between the two platforms to avoid having requests back up on one server when extra processing resources are available on the other server (separate SOC containers are required on each platform to support this configuration), and (3) duplicated data sources each requiring a complete copy of the data.

Figure 6-19 CPT Design Requirements Module ArcGIS Server Single-tier Software Configuration Overview
Figure 6-19 shows the ArcGIS Server single-tier software configuration and the Arc10 Platform Service times sections included with the CPT Design requirements module. Four ArcGIS Server workflows, representing each of the data source selection options (Small File GDB, SDE Direct Connect, SDE Remote Server, SDE connect), are included in each result. The top view shows the install configurations, and the bottom view shows the resulting software processing loads.


Figure 6-20 CPT Design ArcGIS Server Single-tier System Architecture Design Overview
Figure 6-20 provides a full view of the CPT Design solution for the same four ArcGIS Server workflows. The Workflow Performance Summary shows the software service time distribution and expected client display response time for each workflow, while the platform section shows the processing loads on the configured server platforms.


Two-Tier Platform Configuration

A two-tier architecture provides an optimum solution for sites supported with a separate database server. The two-tier high-availability option may become the most popular and practical configuration supporting most ArcGIS Server deployments.

The two-tier architecture in Figure 6-21 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.

Figure 6-21 Two-Tier Platform Configurations (Separate Data Servers)

Standard Configuration: The standard configuration includes one GIS Web server platform with a separate single data server platform. The Web server is installed on the GIS Web server platform.

High-Availability Configuration: High-availability operations require redundant server solutions, configured so the site remains operational in the event of any single platform failure. This configuration includes (1) network load balancing to route the traffic to each of the GIS Web servers during normal operations and only to the active GIS Web server if one of the servers fails, (2) SOM load balancing to distribute SOC processing load between the two GIS Web server platforms to avoid having requests back up on one server when extra processing resources are available on the other server (two SOC container groups are required on each GIS Web server platform to support this configuration), and (3) two data 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.

ArcGIS Server Image Extension two tier platform configuration

Figure 6-22 ArcGIS Server Image Extension Platform Configurations
Figure 6-22 provides an overview of the ArcGIS Server Image Extension two tier platform configurations. The Image Extension software can be configured as a standalone server with image files hosted on direct attached storage or on a storage area network. Network attached storage can provide a common data source for multiple image service provider platforms which may be required for high availability or high capacity configurations.


Figure 6-23 CPT Design Requirements Module ArcGIS Server Two-tier Software Configuration Overview

Figure 6-23 shows the ArcGIS Server two-tier software configuration and the Arc10 Platform Service times sections included with the CPT Design requirements module. Four ArcGIS Server workflows, representing each of the data source selection options (Small File GDB, SDE Direct Connect, SDE Remote Server, SDE connect) are included in each result. The top view shows the install configurations and the bottom view shows the resulting software processing loads.

Figure 6-24 CPT Design ArcGIS Server Two-tier System Architecture Design Overview

Figure 6-24 provides a full view of the CPT Design solution for the same four ArcGIS Server workflows. The Workflow Performance Summary shows the software service time distribution and expected client display response time for each workflow, while the platform section shows the processing loads on the configured server platforms.

Three-Tier Platform Configuration

Three-tier configurations include Web server, map server/container machine, and data server tiers. Two configuration options are provided, based on the location of the ArcGIS Server SOM.

Figure 6-25 shows a three-tier configuration with the service manager located on the Web server tier. This configuration provides the simplest three-tier architecture (network load balancing handles Web tier failover), 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.

Figure 6-25 Three-Tier Platform Configuration—SOM on Web Tier

Standard Configuration: The standard configuration includes a single Web server with a separate container machine layer and a separate data server. The container machine layer can be a single platform or can be expanded to support several platforms, depending on the required site capacity. SOM load balancing is provided by the GIS Web server service manager.

High-Availability Configuration: High-availability operations require redundant server solutions, configured so the site remains operational in the event of any single platform failure. This configuration includes (1) network load balancing to route the traffic to each of the GIS Web servers during normal operations and only to the active GIS Web server if one of the servers fails, (2) SOM load balancing to distribute SOC processing load between the two map server/container machine platforms to avoid having requests back up on one server when extra processing resources are available on the other server (separate SOC containers are required on each map server/container machine platform to support this configuration), and (3) data server configuration supporting enterprise requirements.

Figure 6-26 shows a three-tier configuration with the SOM located on the container machine tier. The Web server and SOM connectors are located on the Web server platform, and the SOM and SOC components are located on the container machine platforms. This could be a preferred configuration when supporting Java applications on Linux-based Web servers. In this configuration, all the COM-based software is located on the container machine tier. The failover scenarios are more complicated. If the SOM1 software fails, WAS1 will send maps to SOM2. SOM2 will return results to the parent WAS2 output file. Client will return to WAS1 to get results and will need a virtual disk mount to receive the result from the SOM2 output directory. It will still be necessary to configure SOM load balancing for optimum capacity during peak loads.

Figure 6-26 Three-Tier Platform Configuration—SOM on SOC Tier

Standard Configuration: The standard configuration includes a single Web server with a separate container machine layer. The container machine layer can be a single platform or can be expanded to support several platforms, depending on the required site capacity. Web application traffic balancing is supported by the GIS Web server SOM connectors. The ArcGIS Server implementation can be configured in a failover mode (SOM2 would be activated only if SOM1 fails). SOM load balancing is provided by the server manager components (preferably no more than two SOM components on the container machine tier). All of the container machines can host SOM1 and SOM1 instances, so both SOM1 and SOM2 will deploy dedicated SOC instances on each host platform. Separate data server is provided as a common data source. Administration of this architecture can become increasingly complex as additional container machines are deployed - most of this complexity is managed by the SOM dispatch software.

High-Availability Operations: High-availability operations require redundant server solutions, configured so the site remains operational in the event of any single platform failure. This configuration includes (1) network load balancing to route the traffic to each of the GIS Web servers during normal operations and only to the active GIS Web server if one of the servers fails, (2) Web application traffic load balancing to distributed inbound load between the two SOM located on the container machine tier. (3) SOM load balancing to distribute SOC processing load between the container machine platforms to avoid having requests back up on one server when extra processing resources are available on the other server (dedicated SOC containers are required on each container machine platform to support this configuration, with each SOC assigned to a parent SOM), and (4) data server configuration supporting enterprise requirements. Administration of this architecture becomes increasingly complex as additional map servers/container machines are deployed - most of this complexity is managed by the SOM dispatch software.

Three-Tier Service-Oriented Platform Configuration

Figure 6-27 Three-Tier Platform Configuration—Web Services Architecture
ArcGIS Server Web Applications can be developed and deployed supported entirely by remote Web data services. It is also possible to provide these HTTP SOAP based services from a separate local ArcGIS Server Web site. Figure 6-27 provides an example of a ArcGIS Server Web configuration that supports an enterprise services architecture configured across a firewall.

The internal GIS Web Servers are configured as identified in the earlier configurations. Web data services can be published by the internal GIS Web Servers supporting enterprise applications deployed on a separate Web application tier. Web services can be passed through the firewall using standard HTTP service protocols.

Many of the more powerful ArcGIS Server applications benefit from a more tightly coupled DCOM communications. Each application is directly coupled to an assigned SOC to support each transaction. Results from these applications can be provided as services to more loosely coupled enterprise applications supported in a separate security zone by using standard HTTP protocols.

ArcGIS Server provides a broad range of functionality that can be used to support standard Web mapping or for more complex geospatial workflows that previously were not available through open standard Web protocols. Use of the ArcGIS 9.3.1+ optimized map document (MSD) or preprocessed cached data layers available with ArcGIS Server can improve user performance beyond what we saw with ArcIMS technology and reduce network traffic requirements. Careful attention to user requirements and proper deployment of the technology can make a difference.

Figure 6-28 CPT Design Requirements Module ArcGIS Server Three-tier Software Configuration Overview

Figure 6-28 shows the ArcGIS Server three-tier software configuration and the Arc09 Platform Service times sections included with the CPT Design requirements module. Four ArcGIS Server workflows, representing each of the data source selection options (Small File GDB, SDE Direct Connect, SDE Remote Server, SDE connect), are included in each result. The top view shows the install configurations, and the bottom view shows the resulting software processing loads.

Figure 6-29 CPT Design ArcGIS Server Three-tier System Architecture Design Overview

Figure 6-29 provides a full view of the CPT Design solution for the same four ArcGIS Server workflows. The Workflow Performance Summary shows the software service time distribution and expected client display response time for each workflow, while the platform section shows the processing loads on the configured server platforms.

Figure 6-30 CPT Calculator ArcGIS Server Configuration Strategies

Figure 6-30 shows three CPT Calculator configuration options for the ArcGIS Server workflow. ArcSDE Direct Connect DBMS data source is used for all configurations. Top left analysis shows CPT Calculator configured in a single-tier architecture, middle analysis shows CPT Calculator configured in a two-tier architecture, and the bottom right shows CPT Calculator configured in a single-tier architecture.

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.

Figure 6-31 CPT Design Platform Module

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.

The CPT Design tab provides a framework for modeling enterprise operations. Figure 6-31 provides an overview of the adaptive CPT Design platform module.

• Up to 10 unique platform tier available for software assignment
• Each platform tier can scale to any required number of nodes (platforms)
• A different platform technology can be selected for each tier.
• Platform rollover setting automates platform sizing (fixed node option also available)
• Selected hardware can be native (physical server) or virtual server platform tier
• Platform names can be assigned to personalize the IT environment
• Software components can be installed on any platform tier

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


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 30th Edition (Fall 2011)
1. System Design Process 2. GIS Software Technology 3. Software Performance 4. GIS Data Administration
6. Network Communications 7. GIS Product Architecture 9. Platform Performance 8. Information Security
5. Performance Fundamentals 10. Capacity Planning Tool 11. City of Rome 12. System Implementation

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