GIS Product Architecture 42nd Edition
Spring 2018 GIS Product Architecture 42nd Edition
GIS Product Architecture shares the software components and platform configuration options available for distributed GIS operations. Understanding application architecture alternatives and associated configuration strategies provides a foundation for selecting an appropriate distributed GIS design.
ArcGIS 10.5 is a major architecture release. An excellent overview of ArcGIS Enterprise is provided in Philip Heede's presentation on Architecting your Deployment.
- 1 ArcGIS technical architecture evolution
- 2 Virtualization deployment options
- 3 ArcGIS Desktop architecture patterns
- 3.1 ArcGIS Desktop workstation architecture
- 3.2 Centralized Windows Terminal Server/Remote Desktop Services (Citrix) Architecture
- 4 ArcGIS Enterprise services architecture
- 5 ArcGIS Platform deployment strategies
- 5.1 Portal for ArcGIS platform configuration
- 5.2 ArcGIS Enterprise platform configuration structure
- 5.2.1 Migrating standalone ArcGIS Server to ArcGIS Enterprise
- 5.2.2 ArcGIS Server site single-tier platform configuration
- 5.2.3 ArcGIS Server site two-tier platform configuration
- 5.2.4 ArcGIS Server site three-tier platform configuration
- 5.3 Data center platform tier architecture
- 6 ArcGIS Enterprise server roles
- 7 ArcGIS Server site deployment (single-site alternative patterns)
- 8 ArcGIS Server site deployment (multiple site patterns)
- 8.1 ArcGIS Server multiple site integration
- 8.1.1 Enterprise development, staging, and production operations
- 8.1.2 Active-Passive ArcGIS Server Failover configurations
- 8.1.3 Data Center COOP/DR Failover configurations
- 8.1.4 Additional multiple site deployment considerations
- 8.1.5 Optional high capacity single-machine GIS Server Site active-active configuration tier
- 8.1 ArcGIS Server multiple site integration
- 9 Concluding Remarks
- 10 CPT Capacity Planning videos
ArcGIS technical architecture evolution
Figure 9.1 shows how GIS architecture is evolving to enable a more adaptive and functional exchange of geographic information.
File-based systems: Desktop applications building file-based datasets that were unique to the individual user. Building and sharing information was limited to individual relationships, and data integration was limited.
Database-centric: Enterprise desktop clients would access a centrally shared geodatabase data source. Data was maintained and shared in an integrated database environment, improving information continuity and quality of the available data resources. Published data could be managed and controlled to promote a common view of available validated data resources. Access to data resources was limited to desktop users on the local area network.
Server-centric: Database resources were published as Web services, making information products available to a broad Internet community of Web clients. Rich Internet clients could access services from multiple server locations, expanding access and integration of information resources to a much broader community of users. Applications were developed and deployed to leverage available Web services
Best practice: Database- and Server-centric architecture patterns support optimum governance for system of record content.
Web-centric: Introduction of a portal architecture expanded development of Web content to the business community, no longer requiring software developer project efforts to deploy new Web information products. Generic commercial applications able to leverage Web maps created and shared by business users provide timely access to information products at any location on any supported device. Users could create and administer their own groups for sharing content, use configurable apps to create new Web applications, and leverage solution templates to rapidly create and deploy content to a broad community of users.
Best practice: Web-centric portal architecture provides optimum solution for system of engagement.
ArcGIS system technical architecture
Enterprise-level GIS applications support a variety of users throughout an organization, all requiring access to shared spatial and attribute data sources. System hardware and software environments for distributed GIS applications are supported by a multi-tier client/server or Web services architecture. A simple overview of the various ArcGIS architecture components is provided in Figure 9.2.
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 Enterprise Geodatabase Servers, Imagery servers, map and imagery tile cache, and database servers supporting other Enterprise business systems. Additional data resources are available from ArcGIS Online and other Internet data sources.
ArcGIS Desktop Clients: ArcGIS 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.
Hosted GIS services: GIS applications are supported within a distributed configuration by server platforms that execute GIS functions. In a centralized solution, Windows Terminal Server and ArcGIS 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 Server platforms support a variety of Web applications and services accessed by standard browser clients, rich internet applications, or other desktop applications.
Web GIS in the cloud: ArcGIS Online Organizations provide GIS capabilities through Esri-hosted software as a service environment.
Web GIS on-premise: Base ArcGIS Enterprise deployment (Portal for ArcGIS, hosting ArcGIS Server site, ArcGIS Data Store (Relational) supporting on-premise system of engagement.
ArcGIS Enterprise server roles: ArcGIS Image Server (Raster Analytics and Image Services), ArcGIS GeoEvent Server (realtime events), ArcGIS GeoAnalytics Server, and ArcGIS Business Analyst Server—along with their associated ArcGIS Data Stores—provide expanded capabilities for on-premise system of engagement.
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 9.3 provides an overview of the ArcGIS software component architecture.
GIS is technology used for the creation, management, integration, analysis, display, and dissemination of spatial data. Spatial data includes any information that can be associated with a location on the earth's surface or data that can be associated with a person or place that has a location.
How the spatial data is maintained and published within the organization contributes to the performance and scalability of the system design. GIS Data must be organized and managed to support effective and efficient GIS operations. GIS data deployment patterns are discussed in more detail in the Chapter 5 GIS Data Administration chapter.
ArcGIS Desktop can be deployed on client workstations or hosted by a Windows Terminal Server. Custom 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 Desktop deployment patterns are discussed in more detail in the SDSwiki Chapter 2 Desktop operations section.
ArcGIS Server is deployed in a scalable Web application server architecture. The Web solutions include software development kits and runtime environments supporting application development, system performance, and scalability. Recommended platform configuration strategies will be provided for both standard and high availability architecture solutions. ArcGIS Server deployment patterns are discussed in more detail in the [ SDSwiki Chapter 2 Web operations].
GIS applications support an open systems architecture. The ArcGIS enterprise architecture combines a variety of closely integrated commercial products to establish a fully supported system solution. All commercial software products must be maintained to support evolving communication interface standards. The importance of selecting well established (popular) software architecture solutions based on standard design practices cannot be overemphasized, since all parts of the distributed configuration are critical and must work together to ensure communication interfaces are properly maintained and supported.
Virtualization deployment options
Figure 9.4 provides an overview of the four principle virtualization solutions. Virtualization provides a variety of options available for ArcGIS deployments.
Virtual sessions are used for improved security and high performance access to shared centralized data souces. Multiple desktop applications are deployed on a centralized server platform sharing a common server operating system. Desktop applications run on the server with each session displayed and controlled by remote terminal clients.
- Windows: Remote Desktop Service (RDS) -> Remote Desktop Connector (RDC)
- Citrix: XenApp -> (Citrix Receiver)
- VMware: VMware Horizon RDSH (Remote Desktop Services Host)
Note: CPT workflow: Citrix workflow with Physical or Virtual platform tier selection.
Esri certifies each ArcGIS Desktop release with Citrix XenApp server (Citrix Receiver) environment. A more complete discussion on Centralized Windows Terminal Server/Remote Desktop Services (Citrix) Architecture is provided is provided later in this chapter.
Warning: ArcGIS Pro is not supported in a virtual session environment.
Best practice: Large number of Esri customers use Citrix XenApp application servers for remote user access to centrally managed remote desktop (ArcMap) terminal services.
Virtual Server machines reduce administration overhead and share the host physical server compute resources. Virtual Server machines share a common hypervisor for access to host platform processing resources. Each Virtual Server machine has its own installed Server operating system. Server applications are installed in each separate Virtual Server machine.
- Windows: HyperV
- Citrix: XenServer
- VMware: VMware vSphere (ESX)
Note: CPT workflow: Virtual platform tier selection.
Best practice: Large number of Esri customers deploy ArcGIS Server in the three available virtual server environments.
Virtual desktop infrastructure (VDI)
Virtual desktop infrastructured deployments reduce administration overhead and share the host physical server compute resources for centralized virtual desktop deployment. Virtual Desktops share a common hypervisor for access to host platform processing resources. Each Virtual Desktop has its own installed Desktop operating system. Desktop applications are installed in each separate Virtual Desktop machine. Virtual Desktops run on the server with display and control provided by a variety of remote terminal client devices.
- Windows: Microsoft Virtual Desktop Infrastructure
- Citrix: XenDesktop
- VMware: VMware View
Note: CPT workflow: Citrix workflow with VDI platform tier selection.
Esri customers have deploy Virtual Desktop Infrastructure (VDI) and though they are known to work, Esri has not yet certified these solutions.
Best practice: Virtual desktops environments are used by Esri for development and hosted ReadyTech training environments.
Virtual desktop environments traditionally do not have access to hardware video cards which has contributed to some functional performance degradation noticed by users. Vendor solutions are available to include shared NVIDIA GRID video cards within the VDI host server architecture to improve display performance for future virtual desktop deployment patterns.
Best practice: Virtual desktops environments with host platform NVIDIA GRID video cards are used for hosted ArcGIS Pro deployments.
Virtual clients are virtual desktop environments deployed on a local physical desktop. Virtual Desktops interface through a hypervisor for access to physical desktop processing resources. Each Virtual Desktop has its own installed Desktop operating system. Desktop applications are installed in each separate Virtual Desktop machine. Virtual Desktops run on the client physical workstation..
- Windows: Virtual PC
- Citrix: XenDesktop
- VMware: VMware VDI
Note: CPT workflow: Increase client load to handle visualization.
Best practice: Virtual desktops are used by Esri for development and classroom training environments.
Warning: Some virtual desktop environments to not have access to hardware video cards which contributes to some performance degradation noticed by users.
ArcGIS Desktop architecture patterns
ArcGIS Desktop software is supported on Microsoft Windows desktop and terminal server platform environments. QT Desktop Runtime provides ArcGIS components for custom desktop application development. Python is a fully supported scripting language used for process automation. Figure 9.5 provides an overview of the software components supporting the ArcGIS Desktop application.
ArcGIS Desktop is deployed in a client/server component architecture. The client applications are tightly coupled when accessing a DBMS data source, exchanging hundreds of sequential data requests to complete each user map display transaction. A typical map display is refreshed in less than a second, requiring a very chatty protocol exchange with the connected database.
Best Practice: Communications between the ArcGIS Desktop application and an Enterprise Geodatabase should be limited to stable high-bandwidth local network environments with minimum network latency.
ArcGIS direct access to remote DBMS data sources can result in reduced display performance and unstable editing operations. The most common architecture for supporting remote client editing uses terminal access to a central Windows Terminal Server located in the Enterprise Geodatabase data center, which we will discuss later in this chapter.
Network latency is the primary cause for reduced display performance when accessing a remote database. Display performance can be improved by reducing the number of sequential application round trip requests per display. You can reduce the required round trips to the server by establishing a local feature cache or by accessing remote DBMS data sources through an ArcGIS Server feature service. You could also establish ArcGIS Desktop local basemap layers to further improve display performance for a defined work area. These are some workaround options for improving display performance, and may not be practical for all workflow scenarios.
ArcGIS 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 Desktop software includes Web access to a variety of worldwide high quality ArcGIS Online basemaps and is fully integrated with publishing and collaborating through ArcGIS Online organization membership.
The CPT data source selections for an ArcGIS Desktop workflow include a variety of data source formats (DB_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 Desktop workstation architecture
Four distributed ArcGIS Desktop workstation configuration patterns are identified in Figure 9.6. These configuration patterns include access to a networked file data source, direct connect access to an Enterprise Geodatabase, direct access to a supported DBMS (non-SDE), and DBMS access through an ArcGIS Server feature service.
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 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 Desktop application.
ArcGIS Desktop software provides a direct connection to all supported database servers. The direct connect option (Direct Connect) includes the direct connect API executables and will communicate with a database client installed on the same machine. The database client will support network communications to the database server.
ArcGIS Desktop software provides direct connections to supported database servers providing view, query and analysis of the DBMS data content. Some of the databases you access can contain geodatabase tables, functions, and procedures, but they don't have to; you can connect to any supported database and view the data from ArcGIS Desktop.
Enterprise geodatabases, also known as multi-user geodatabases, are stored in a relational database using Oracle, Microsoft SQL Server, IBM DB2, IBM Informix, or PostgreSQL. These geodatabases require the install of ArcSDE schema and can be unlimited in size and numbers of users.
ArcMap allows you to edit a supported database by creating a local copy of data from a published ArcGIS Server feature service. You can then make edits to the local copy in ArcMap and synchronize the edits back to the service. Edits can be made to the local copy without having to be connected to the server. Access to the server is only required when creating the local copy or applying changes from the local copy to the server. This workflow can be useful when your organization has disconnected employees and provides a common method for editing the same data using multiple clients, such as through the web or using desktop applications. The functionality is built into ArcMap and does not require any customization. Edits to a published feature service are captured in a single version of the database.
Four ArcGIS Desktop workstation configuration alternatives are identified in Figure 9.6. All configurations are supported by ArcGIS Desktop applications installed on a local workstation. ArcGIS Desktop workstation configuration options include access to a network file data source, direct connect access to an Enterprise geodatabase, direct access to a non-SDE DBMS, and DBMS access through an ArcGIS Server feature service.
New ArcGIS Pro remote desktop deployment patterns
For over 20 years, recommended ArcGIS Desktop architecture patterns would host both the ArcMap application and the database on the same local network (ArcMap direct connection to an Enterprise Geodatabase over a remote network connection did not perform well). ArcGIS Pro, deployed with ArcGIS Enterprise, provides a powerful new Web GIS services architecture that introduces an alternative remote desktop solution for distributed GIS operations.
- Web GIS provides an alternative ArcGIS Desktop services architecture pattern that performs well over remote network connections.
- The base ArcGIS Enterprise deployment provides a framework for publishing and sharing dynamic content with remote ArcGIS Desktop clients over wide-area network connections.
- ArcGIS Pro supports edits to a remote supported database through dynamic feature service connections.
- > ArcGIS Pro can maintain a local cache for features from a published ArcGIS Enterprise feature service,
- > Edits can be performed with the local client cache.
- > Edits are synchronized back to the service data source.
- ArcGIS Enterprise also allows Portal named users to create filtered Web map layers that support focused dynamic remote client edit operations.
- > Create a web layer from a published feature service.
- > Turn off all layers that are not required for edit operations.
- > Share map with feature service editing enabled.
- > Perform connected dynamic remote edit operations with minimum bandwidth traffic and optimum display performance.
- ArcGIS Pro's powerful multi-threaded capabilities enable clients to perform local geoprocessing on their workstation while working with remote data sources over a wide area network.
- > Clients can leverage dedicated local workstation processors and video card for multiple background jobs while supporting desktop operations.
Best Practice: ArcGIS Pro ArcGIS Enterprise connections provide an alternative cost-effective remote desktop solution.
Note: The high cost of centralized ArcGIS Pro remote desktop host platforms, along with the risk of resource contention when deploying several powerful ArcGIS Pro workflow sessions in a shared host environment, will potentially favor a Web GIS architecture for supporting ArcGIS Desktop remote client operations.
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) for communication between the terminal server and the Windows client. Windows terminal server platform memory recommendations are generated based on peak concurrent ArcGIS Desktop user sessions supported by the selected platform configuration.
The Citrix Xen Application Server (XenApp) enables a more efficient independent computing architecture (ICA) protocol to communicate between the terminal server and client Windows platform. The ICA protocol requires less than 28 Kbps bandwidth (rendering vector data information products) for full Windows display and control of GIS applications supported on a Windows Terminal Server. Traffic can increase to 100 Kbps bandwidth when accessing a raster data source. XenApp supports client software for Windows, UNIX, Macintosh, and embedded Web client applications.
XenApp provides many additional benefits over just RDS alone, including “seamless” windows, universal print drivers, and HDX technologies such as HDX 3D Progressive Display for imagery acceleration, just to name a few. Most Esri customers that deploy centralized thin-client solutions have realized the benefits of Citrix XenApp and have deployed it in addition to standard RDS. There is currently a very large Esri customer user base that utilizes Citrix XenApp for ArcGIS Desktop ArcMap operations. The following knowledge base article provides Esri best practices for running ArcGIS Desktop ArcMap in a Citrix XenApp environment.
Esri initially certified ArcGIS 10 SP2 as a hosted application with Citrix XenApp 6 and Windows 2008 R2 using the Citrix ICA Online Plug-in for Windows 12.1. Esri has since certified ArcGIS 10.3 as a hosted application with Citrix XenApp 6 and XenApp 6.5 with Windows 2008 R2 using the Citrix ICA Online Plug-in for Windows 13.1.
Though XenApp is a popular solution and meets most desktop application publishing needs, there are a few limitations with its use in GIS. The limits are primarily centered on supporting graphic intensive displays such as those from ArcGlobe and other 3D applications. These limits can result in the need to maintain some presence of thick-client desktops for targeted power users that require high-performance and 3D graphics environments. Design and testing efforts are in work with our vendor partners to improve 3D performance in remote desktop deployment patterns. ArcGIS Resources blog shares Esri test feedback on ArcGIS Pro with NVIDIA K1 in XenDesktop. Citrix shares results for their commitment with Esri in supporting ArcGIS Pro for Citrix XenApp and XenDesktop.
Further, centralizing applications and data naturally creates a distributed printing environment. This can be particularly problematic for large plot printing used in GIS. Solutions are available to help with remote printing management and these solutions are being used by Esri Citrix customers. The following reference document addresses printing with ArcGIS in Citrix environments and mentions some of the available solutions. Two of the most popular have been ThinPrint and UniPrint.
Four distributed ArcGIS Desktop Citrix configuration alternatives are identified in Figure 9.7. All configurations are supported by remote terminal client access to ArcGIS Desktop applications hosted on a central Windows Terminal Server. ArcGIS Desktop Citrix configuration options include access to a network file data source, direct connect access to an Enterprise geodatabase, direct access to a non-SDE DBMS, and DBMS access through an ArcGIS Server feature service.
Terminal clients have a persistent connection with the Windows Terminal Server ArcGIS Desktop session; lost connections are reinstated without losing the session (referred to as Session Reliability in XenApp). The application display is provided over the network to the terminal client, requiring much less data transfer than the spatial data query chatter between the application and the data source. The terminal client display traffic requirements are very small; supporting good application performance over 28 Kbps modem dial-up connections (displays with an image backdrop require more bandwidth).
Each ArcGIS Desktop user session deployed 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.
ArcGIS Pro reference sites (recommendations for ArcGIS Pro VDI host platform configurations)
- Virtualizing ArcGIS Pro: Nvidia Grid vGPU Profiles May 2015 Deployment configuration: 10-12 ArcGIS Pro Virtual Desktops on high performance 24-core server with two NVIDIA GRID video cards.
- Virtualizing ArcGIS Pro: Nvidia GRID Tesla M60 July 2017
- ArcGIS Desktop Virtualization Appliance March 2017 Deployment configuration: Up to 25 ArcGIS Pro Virtual Desktops on high performance 28-core server with NVIDIA Tesla GPU accelerator cards.
Best Practice: Provide dedicated host platform environment for ArcGIS Pro virtual desktop deployment.
ArcGIS Enterprise services architecture
Figure 9.8 shows the ArcGIS Enterprise software licensing components. ArcGIS Enterprise licensing includes software for a basic deployment along with options for additional separate ArcGIS Server roles.
ArcGIS Enterprise software components include Portal for ArcGIS, ArcGIS Server, ArcGIS Web Adaptor, and five additional server roles.
- ArcGIS Enterprise software licensing
- ArcGIS Server is delivered as a single software install that includes web service endpoints and SOC functions within a single software bundle.
- An optional web adaptor component is included for enhanced security and network load balancing.
- Portal for ArcGIS software provides overall content management for information security, collaboration, and sharing.
- ArcGIS Server roles expand capabilities to include ArcGIS Image Server, ArcGIS GeoEvent Server, ArcGIS GeoAnalytics Server, and ArcGIS Business Analyst Server.
ArcGIS Server roles are designed for rapid deployment, user collaboration sharing, and friendly administration.
ArcGIS Enterprise deployment strategies
Figure 9.9 shows the ArcGIS Enterprise deployment strategies. ArcGIS Enterprise provides what you need to enable enterprise GIS content development and sharing based on your business needs.
ArcGIS Enterprise provides a component-based architecture that can be deployed and scaled as required to satisfy GIS operational needs.
ArcGIS Enterprise base deployment
- Relational data store supports feature data tables.
- Portal for ArcGIS provides content management and security.
- Hosting ArcGIS Server manages Portal published services.
- ArcGIS Data Stores manage Portal published data resources.
- ArcGIS Server supports registered GIS services.
- ArcGIS Image Server supports image services and raster analytics.
- ArcGIS GeoEvent Server supports real-time events.
- ArcGIS GeoAnalytics Server supports spatial and temporal analysis.
Base ArcGIS Enterprise deployment is required to support ArcGIS Server role capabilities.
ArcGIS Server software architecture
Web mapping services provide an efficient and effective approach to serving map products and services over the Internet. The ArcGIS Desktop architecture presented earlier in this section requires tightly coupled client/server processes that demand stable high-bandwidth communications supported over relatively short distances. Web client communications are supported using a transaction-based HTTP, which supports optimum communications over long distances and less stable communication environments.
ArcGIS Server services are published through a Web server. Web server clients are presented with a catalog of published services when accessing the Web site. Web applications consume map services and render a client presentation layer to support the published application workflow. Client and Web servers are loosely coupled (stateless) connection in which each client communication represents a complete transaction. Transactions are processed by the appropriate Web-based GIS server and returned to the client.
Esri Web GIS services are hosted by ArcGIS Server software. ArcGIS Server provides an ArcGIS software-based environment for deploying GIS server-based ArcGIS applications and services. ArcGIS Server can be deployed as a Web service for Internet/Intranet clients or as a network service for local desktop clients. Rich internet applications (RIA) Web clients are loosely connected, lightweight, handheld or desktop computers that can support a variety of Web based applications and include persistent data cache and potentially support disconnected GIS client operations. Client application deployment and data exchange are managed by ArcGIS 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 browsers, Portal for ArcGIS, RIA clients, GIS Server, and geodatabase software components that can be deployed on different platform combinations to support scalable capacity and system availability requirements. Location of the various software components and the selected software configuration contributes to system capacity, service reliability, security, and overall output performance.
ArcGIS 10.1 was a major release for Server. ArcGIS 10.1 for Server introduced all the primary functionality of ArcGIS 10 delivered in a new 64-bit JAVA based software component architecture. ArcGIS 10.1 for Server was designed for rapid deployment and friendly administration. Server enhancements improved installation, performance, reliability, administration, cloud deployment options, and more Linux friendly software compatibility. Primary software components associated with the ArcGIS Server software architecture are identified in Figure 9.10. GIS Server support access to file data sources, ArcSDE Geodatabase and non-geodatabase database sources, imagery and cached tile data sources.
ArcGIS Server is delivered as a single software install that includes the web service endpoints within a new fully integrated GIS Server software bundle. An optional Web Adaptor component is included with the ArcGIS Server install package for improved security and network load balancing.
ArcGIS Server key site aware component functions
Figure 9.11 provides an overview of the terminology used to describe the ArcGIS Server architecture. An ArcGIS Server high availability configuration will be used to introduce these terms. These terms will be discussed in more detail as we describe the ArcGIS Server architecture patterns later in this chapter.
The initial ArcGIS Server install defines the primary components that make up a named Site. These primary components include the GIS Server and the Site Configuration Store (ConfigStore). The Site ConfigStore contains all service definitions and configuration parameters for GIS Server machines within the named Site. Data source path names are included as part of each service definition. Each GIS Server includes HTTP end points (SOAP, REST, Open Standards) available for publishing and serving Web services. HTTP access to GIS Server services is through HTTP port 6080. HTTPs secure communications with GIS Server is provided through port 6443.
When you join a new GIS Server machine to a named Site, it will automatically deploy service configurations as defined in the Site ConfigStore (service configurations are defined per GIS Server machine). The ConfigStore contains a single repository that defines all GIS Server machine configurations within a named GIS Server Site. All GIS Server machines within a site will share a single ConfigStore (a replicated copy of the ConfigStore would create a new Site). ConfigStore must be located on a file share which can be accessed by all GIS Servers within the named Site.
Warning: If you lose the ConfigStore or data source, you lose the site. ConfigStore backup and recovery was introduced with the 10.2 release..
ArcGIS Server includes optional Web Adaptor software that can be used to manage GIS Server inbound service requests. The Web Adaptor must be installed on a machine with a third party Web Server. The Web Adaptor is Site aware, which means that it will distribute inbound service requests across the active GIS Server machines within the named Site. The Web Adaptor can also act as a reverse proxy, accepting service requests on a configurable inbound port (i.e. Port 80) and communicating with the Site GIS Server machines on Port 6080. If any of the Site GIS Server machines fail, the Web Adaptor will route service requests only to the remaining active GIS Server machines (high availability failover functionality). A single Web Adaptor can service only one named Site. Multiple Web Adaptors can be assigned to a single named Site. Multiple Web Adaptors can be deployed on a single Web server (enables support for multiple ArcGIS Server named Sites from a single Web server).
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.
ArcGIS 10.3 introduced the option for single-cluster configuration, with service handler load balancing disabled. Single-cluster deployment provides more scalable architecture and is the baseline for the ArcGIS 10.4 and 10.5 deployments.
Inbound service requests will be assigned to one of the GIS Servers located within the named Site. Inbound requests will be distributed across the site machines. In a single-cluster site, the machine that receives the inbound requires will complete the service transaction.
In a multi-cluster site configuration, a 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).
High availability implies there is no single software or server component failure that will results in a Site failure. A high availability configuration must include network load balancing with failover capability to ensure inbound traffic will be routed to an active Web gateway machine, at least two GIS Server machines, and high availability File Share for the ConfigStore, Server Directories, and any shared File data sources. Any DBMS data source would also need to be supported in a failover configuration. If you lose the ConfigStore or any of the required data sources, you lose the Site.
ArcGIS Server uses certain default ports to communicate with machines over the network. The Ports used by ArcGIS 10.2 for Server are identified in the Esri ArcGIS Help.
ArcGIS Platform deployment strategies
ArcGIS platform deployment strategies can include a mix of self-managed and vendor-managed configuration options.
Key ArcGIS components for Web GIS
- Web Apps
- GIS portal
- GIS service framework
- Ready-to-use content
ArcGIS platform configuration strategies
- Software as a Service (SaaS)
- > ArcGIS Online Organization; Hosted services online; Online basemaps and services
- Software/data installed on-premises or in a private cloud
- > Portal for ArcGIS; ArcGIS Server; Data Appliance for ArcGIS
Best Practice: Deployment strategies can include a mix of self-managed and vendor-managed hardware option.
There are a few self-managed deployment options:
- Non-cloud on-premise ArcGIS Server deployment
- Infrastructure as a Service (IaaS)-based community private cloud deployment
- Hybrid deployment, including IaaS and on-premises services
There are also vendor-managed deployment options:
- IaaS-based community private cloud deployment
- Hybrid of IaaS public and private cloud services
- Vendor-managed IaaS-based public cloud deployment
- Public SaaS-based deployment
How you deploy your ArcGIS Platform depends on your business requirements, as shared in this video on [https://www.esri.com/videos/watch?videoid=2497&isLegacy=true ArcGIS Deployment Patterns}.
Portal for ArcGIS platform configuration
Figure 9.13 shows an overview of the Portal for ArcGIS configuration. Portal for ArcGIS can be installed on a stand-alone web server or as a content management component of a federated ArcGIS Server configuration.
Portal for ArcGIS enables secure and private content sharing within the organization and leverages mobile, server, and desktop clients.
Portal for ArcGIS is installed on a Web server with a dedicated ArcGIS Server Web adaptor. The server includes an identity store which contains Portal member user names, passwords, and roles. Portal for ArcGIS security authentication and authorization options are discussed in more detail in the Information Security chapter. Named users of the Portal organization can create Web maps, add services to their content, and share content with groups and other members throughout their organization.
Portal for ArcGIS releases starting with 10.3 include documentation for installing a high availability Portal configuration.
Registered Web services
Web services referenced in Web maps or added to the Portal are considered registered services. Web maps can be created from Public or internal published Web services.
Federated ArcGIS Server sites
Internal ArcGIS Server sites can be federated with Portal for ArcGIS. Federated ArcGIS Server site web services are published and shared by the Portal content management interface. Federated ArcGIS Server sites are managed as part of the Portal configuration. Access authorization for all federated ArcGIS Server sites are managed by the Portal for ArcGIS identify configuration.
ArcGIS 10.4 introduced capabilities for fine grained access control of federated ArcGIS Server sites. You can update a federated server site to restrict publishing and administrative access. Once updated, all portal publisher and administrator access will be controlled by group privileges unique to the restricted federated server.
Note: Only ArcGIS Server sites using version 10.2 or later can be federated with a portal.
Hosting server site
A federated ArcGIS Server site can be fully integrated with your portal if you designate it as a hosting server. A hosting server allows portal users to:
- Publish tiled map and feature services to the portal from ArcGIS Desktop.
- Share layers and maps from Esri Maps for Office.
- Create maps by adding CSV files and shapefiles from local machines to the portal map viewer.
- Publish CSV and shapefiles as feature services from the portal website.
ArcGIS Data Stores
ArcGIS Data Stores require a hosting ArcGIS Server. The ArcGIS Data Stores manage data for services published through Portal for ArcGIS. Portal publishing capabilities and deployed GIS Server roles drive ArcGIS Data Store selection.
Portal for ArcGIS can be deployed in a variety of configurations adapting to your hosting requirements. Portal for ArcGIS is supported by a dedicated Web Adaptor.
Best Practice: Use the Portal for ArcGIS Data Store (relational, introduced with ArcGIS 10.3) for scalable feature service deployment.
The Capacity planning tool includes features for sizing a Portal for ArcGIS configuration.
ArcGIS Enterprise platform configuration structure
Figure 9.14 shows the ArcGIS Enterprise base deployment and options for deploying the ArcGIS Server roles. ArcGIS Enterprise architecture includes single-tier, two-tier, and three-tier platform configuration options for adaptable data center management.
ArcGIS Enterprise is designed to support multiple single-, two-, and three-tier platform architecture solutions. All of the optional ArcGIS Server site deployment options are available for the ArcGIS Enterprise base deployment and for each of the ArcGIS Server roles. The optimum architecture solution is established based on operations security, systems management (environment isolation), and system capacity requirements.
Platform tier structure
- Base deployment: Includes Portal for ArcGIS, ArcGIS Server (hosted), and required ArcGIS Data Stores.
- Single-tier structure: All software components are deployed on a single platform tier.
- Two-tier structure: Software components are deployed on two separate platform tiers.
- Three-tier structure: Software components are deployed on three separate platform tiers.
High-availability scalable architecture patterns
- Both web tiers can scale out to satisfy availability requirements.
- The ArcGIS Server tier can scale out to satisfy availability and capacity requirements.
- The DBMS tier can include a failover platform to satisfy high availability requirements.
ArcGIS Server is designed to support a scalable Web architecture. Optimum platform environments are configured using standard physical or virtual server platform technology. ArcGIS Server is licensed based on the number of platform processor core (virtual or physical) supporting the GIS Server software tier.
Best Practice: Each platform tier can support multiple servers to satisfy capacity requirements.
Migrating standalone ArcGIS Server to ArcGIS Enterprise
Strategies for migrating your existing ArcGIS Server on-premise environment to ArcGIS Enterprise are shared in this Migrating standalone ArcGIS Server to ArcGIS Enterprise whitepaper.
ArcGIS Server site single-tier platform configuration
The ArcGIS Server installation takes less than 5 minutes, and a single machine is ready for publishing services from ArcGIS Desktop without any additional installation or configuration requirements.
Figure 9.15 provides an overview of single-tier platform configurations. Single-tier configurations provide one or two platforms capable of supporting all Web service components.
Minimum Configuration: A complete Web site can be supported on a single hardware platform. This configuration is appropriate for Web service development and testing, Sites with a limited number of service requests, and initial prototype deployments. A special single chip (2-core) workgroup server license bundled with a Microsoft SQL Server database is available for customer sites that can be supported by a single platform configuration.
If more than one GIS Server machine is joined to a minimum configuration with inbound service requests all sent to the initial GIS Server machine, the initial GIS Server service manager will assign inbound service requests to any available GIS Server machine instances within the named Site. The ConfigStore and SvrDirectories must be shared with all GIS Server machines within the named Site and the GIS Data source must be distributed to each machine to avoid performance contention.
This is not a high-availability configuration, since if you lose the initial GIS Server machine you will lose the ConfigStore and service request distribution to the remaining GIS Server machines within the Site.
High-Availability GIS Server Site Configuration: Most GIS server production operations require redundant server solutions, configured so the site remains operational in the event of a single platform failure. A high-availability configuration must continue to support production operations during single platform maintenance and upgrade and while configuring and publishing new services. This configuration includes (1) network load balancing to route the traffic to each of the ArcGIS Server machines during normal operations and only to the active server if one of the servers fails, (2) GIS Server Site aware service manager load balancing to distribute spatial services processing load between the GIS Server machines throughout the Site to avoid having requests back up on one server when extra processing resources are available on the other server (load balancing is automatically handled within the GIS Server Site), (3) common high availability (fault tolerant) file share for the ConfigStore and SvrDirectory files, and (4) replicated file and DBMS data sources with local copy distributed on each GIS Server machine (in some cases, performance can be adequate with file data located on the HA file share).
The GIS Servers can publish services through their native Port 6080, or a third party Web server with the Web Adaptor can be installed on the ArcGIS Server tier for enhanced security.
For Imagery and File Geodatabase data sources, data should be deployed on each GIS Server machine or configuration should ensure high bandwidth dedicated storage network connection and high performance storage architecture to avoid potential heavy traffic and I/O contention (network or storage contention can contribute to poor Site performance).
In a mixed services environment, it is good practice to deploy image services and Cached tile services on a separate GIS Server machine from dynamic mapping services.
CPT Calculator tab can be used to configure and complete a single-tier System Architecture Design capacity planning analysis.
ArcGIS Server site two-tier platform configuration
ArcGIS Server site architecture is designed for easy install and administration. The two-tier architecture in Figure 9.16 includes separate GIS server and data server platform tier. The Web server and GIS server components are located on the GIS server platform tier, and the data server is located on a separate data server platform. This is a popular configuration for sites with large volumes of data resources or existing data servers. A single copy of the data can support multiple GIS Server machines in conjunction with other enterprise GIS data clients.
For Imagery and File Geodatabase data sources, data should be deployed on each GIS Server machine or configuration should ensure high bandwidth dedicated storage network connection and high performance storage architecture to avoid potential heavy traffic and I/O contention (network or storage contention can contribute to poor Site performance).
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 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 Server tier for enhanced security.
In a mixed services environment, it is good practice to deploy image services and cached tile services on a separate GIS Server machine from dynamic mapping services.
CPT Calculator tab can be used to configure and complete a two-tier System Architecture Design capacity planning analysis.
ArcGIS Server site three-tier platform configuration
Three-tier configurations include Web server, GIS Server, and data server tiers.
Figure 9.17 shows an ArcGIS Server 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.
Most GIS server production operations require redundant server solutions, configured so the site remains operational in the event of a single platform failure. This configuration will continue to support production operations during single platform maintenance and upgrade and while configuring and publishing new services. This configuration includes (1) network load balancing to route the traffic to each of the Web Servers during normal operations and only to the active service if one of the server machines fail, (2) network load balancing to distribute the traffic to each of the GIS Server machines during normal operations and only to the active servers if one of the servers fail, (2) GIS Server Site aware service manager load balancing to distribute spatial services processing load between the GIS Server machines throughout the Site to avoid having requests back up on one server when extra processing resources are available on the other server (load balancing is automatically handled within the GIS Server Site), (3) common high availability (fault tolerant) file share for the ConfigStore and SvrDirectory files, and (4) two DBMS servers that are clustered and connected to a common storage array data source. The primary data server supports query services during normal operations, and the secondary data server takes over query services when the primary server fails. Data server clustering is not required if availability requirements are satisfied with a single data server.
The GIS Servers can publish services through their native Port 6080, or a third party Web server with the Web Adaptor can be installed on the Web Server tier for enhanced security (reverse proxy server) and site aware load balancing.
Warning: For Imagery and File Geodatabase data sources, data should be deployed on each GIS Server machine or configuration should ensure high bandwidth dedicated storage network connection and high performance storage architecture to avoid potential heavy traffic and I/O contention (network or storage contention can contribute to poor Site performance).
Best Practice: In a mixed services environment, it is good practice to deploy image services on a separate GIS Server machine from dynamic mapping services.
CPT Calculator tab can be used to configure and complete a three-tier System Architecture Design capacity planning analysis.
Data center platform tier architecture
ArcGIS Enterprise includes an expanding number of servers. Figure 9.18 shows the variety of platforms supporting the Web GIS product architecture.
Enterprise solutions support four generic platform tiers.
- RDSH tier: Centralized ArcGIS Desktop deployment
- DBMS tier: Variety of database management solutions
- GIS tier: Variety of GIS application servers
- Web tier: ArcGIS Web Adaptors and Portal servers.
Separate platform environments (Web, Portal, Servers, Data source)may be required for internal and external services to satisfy security requirements.
Best Practice: High availability requires platform redundancy.
Warning: All components of the system must be configured with sufficient capacity to support peak business needs.
Best Practice: Capacity planning is essential to ensure deployment success.
CPT Design ArcGIS Enterprise system architecture design with ArcGIS Desktop (ArcMap and ArcGIS Pro) deployments.
ArcGIS Enterprise server roles
Figure 9.26 shows an overview of the ArcGIS 10.5 server roles. ArcGIS Enterprise server roles expand support for Portal collaboration with geoprocessing and real-time services. The ArcGIS Enterprise server role architecture promotes optimized workflow separation configurations.
ArcGIS Server software supports the following installed server configurations
ArcGIS Server core processing capabilities
- Configured in as many multi-machine sites that make sense for your particular deployment following workflow separation recommendations.
- For example, provide separate sites for different sets of map services, separate sites for heavy-weight geoprocessing, separate sites for CPU intensive routing services, ...
ArcGIS Image Server
- Configured multi-machine site for dynamic image services.
- Configure multi-machine site for raster analytics.
ArcGIS GeoAnalytics Server
- Configure multi-machine site for GeoAnalytics Server.
ArcGIS GeoEvent Server
- Configure single-machine sites for your particular deployment.
- At 10.5 and prior: strong recommendation to use single-machine sites for optimum scalability.
ArcGIS Server site deployment (single-site alternative patterns)
Figure 9.19 shows two alternative ArcGIS Server site configuration options. ArcGIS Server alternative site configurations are available since the ArcGIS 10.4 release.
ArcGIS Server read-only operations
- Cached copy of ConfigStore and SvrDirectories is maintained on each machine within the ArcGIS Server site.
- Site is restricted to read-only operations.
Best Practice: Read-only configuration provides sustained operations with loss of network connection with shared site configuration store.
ArcGIS Server multiple-cluster site operations
- Load balancing provided by Web Adaptor or third-party load balancer
- Additional service manager load balancing within site.
Warning: Multiple-cluster site scalability limited for light services with high transaction rates.
ArcGIS Server site deployment (multiple site patterns)
Figure 9.20 shows the ArcGIS Server multiple-site deployment patterns. ArcGIS Server can be deployed as individual machines in a multi-site deployment architecture, with each machine having its own dedicated ConfigStore and SvrDirectories. This architecture pattern, although more complex to administer, can provide advantages for some specific business workflows.
Some multiple-site examples include the following:
- Separate development, staging, and production server environments. Recommended practice for managing production architecture change.
- Failover ArcGIS Server role active-passive configurations. Licensing required only for active ArcGIS Server.
- Separate replicated data center configurations. Support continuity of operations planning (COOP) and disaster recovery (DR) configurations.
- Replicated scale-out site configurations. Optimized high capacity virtual GIS server deployments.
Single-tier, two-tier, and three-tier architecture deployment strategies discussed discussed earlier in this section can be considered for each of the multiple-site configuration patterns.
ArcGIS Server multiple site integration
ArcGIS Server can be deployed as multiple independent GIS Server site machines as shown in Figure 9.21. Independent GIS Server site configurations remove the deployment simplicity built into the adaptive GIS Server site architecture.
Business requirements drive how these sites would share service requests and common data resources. Multiple GIS Server site configurations are not aware of each other, and proper business processes must be established for keeping data, security, and services in sync. Third party load balancer, often an integral part of many large data center Web operations, must be used to distribute inbound traffic to the independent GIS Server sites.
Custom business processes must be established to maintain and distribute traffic across the GIS Server multiple site configuration.
- Multiple site install and configuration. Each independent server machine site must be installed and configured. Any required load balancing and failover requirements must be satisfied by a third-party solution (Web Adaptor does not support multiple site load balancing operations). In a virtual server environment, machine clones and site management tools can be used to deploy single tier GIS Server machine sites.
- Multiple site service deployments. Custom business processes must be established for publishing and updating services across the multiple server machine farm. Published service definitions (SDs) can be used to distribute services across multiple GIS Server site machines. Properly registered data folders and database sources can simplify service deployment configuration requirements. Custom ArcPy scripts may be used to automate service deployments.
- Multiple site data source updates. Data sources for all server machines must be in sync. Shared data sources can be used for two and three tier Web architecture patterns when server machines are located in a common location. For multiple data center and/or single tier configurations, data must be replicated or replaced on each GIS Server data source location.
- Updating applications between sites. Custom business processes can be established to copy application files and update Web URLs across each GIS Server site.
Enterprise development, staging, and production operations
- Development – This is a sandbox ArcGIS Server site for testing new applications and services. Once changes are validated on the development site, they are applied to the staging site.
- Staging – This ArcGIS Server site is a clone of the production site. This site is used for final performance and functional testing before moving to the production site.
- Production – This site supports live business workflows. Only changes that have passed testing on the staging site are moved to the production site.
Guidelines and best practices for building and managing ArcGIS Server in development, staging, and production environments are available in the reference ArcGIS Help documentation.
Active-Passive ArcGIS Server Failover configurations
ArcGIS Server sites can be configured in an active-passive failover configuration to support high-availability business needs. The primary active GIS Server site supports production operations, while the secondary failover site operates in standby mode configured to take over the production service operations in the event of primary server site failure.
The active-passive configuration requires two separate identical GIS Server site installs, each site with its own ConfigStore and SvrDirectories. A third-party load balancer solution can be configured to monitor the primary site and failover to the secondary site in the event of a primary site failure. Custom business processes must be established to maintain the multiple site configuration. Guidelines provided for development, staging, and production operations can be used to publish services and maintain data in sync at both site locations.
ArcGIS Server active-passive failover configurations within a single data center location can be supported with a single primary server license – failover secondary server does not require a separate ArcGIS Server license as long as it operates in a standby mode when the primary server is operational.
Data Center COOP/DR Failover configurations
ArcGIS Server sites can be configured in an active-passive failover configuration to support continuity of operation plans (COOP) and disaster recovery (DR) business needs. The primary active GIS Server site supports production operations, while the secondary failover site operates in standby mode configure to take over the production service operations in the event of primary server site failure. Primary site operations can be distributed (shared) between the primary and secondary data center, depending on your business needs.
Each active-passive configuration requires two separate identical GIS Server site installs, each site with its own ConfigStore and SvrDirectories. A third-party load balancer solution can be configured to monitor the primary site and failover to the secondary site in the event of a primary site failure. Custom business procedures must be established for building and maintaining the multiple site configurations. Guidelines provided for single-machine high-availability (active-passive) deployment can be used to publish services and maintain data at both multiple site locations.
Additional multiple site deployment considerations
Multiple ArcGIS Server site configurations are not the optimum solution for most organizations. There are potential benefits – multiple site deployment configurations may adapt well with other Web Service business processes, particularly in large virtualized data center operations or cloud deployments. Multiple site configurations extend support for operations across multiple data center locations. For small organizations, an active-passive failover solution may reduce licensing costs.
There is no single best solution for all organizations. ArcGIS provides an open platform that supports the simplicity requirements of most customers, along with the flexibility to expand and adapt to meet the needs of the most advanced organizations. System architecture design planning can help identify what solution pattern works best for your organization. Understanding your business requirements and the technology available to satisfy your business needs is critical in building a GIS that works best in your environment.
Optional high capacity single-machine GIS Server Site active-active configuration tier
Single machine ArcGIS Server sites can be configured in an active-active high capacity configuration. Each GIS Server machine includes its own ConfigStore and SvrDirectories. GIS Server machines in this configuration are not cluster aware. Limiting use of built in cluster aware GIS Server site automation will result in a more scalable architecture. ArcGIS 10.3.1 release provides an alternative ArcGIS Server site high scalability configuration option with cluster aware load balancing turned off.
The active-active configuration requires multiple GIS Server platform installs. A third-party load balancer must be used to assign traffic to the appropriate GIS Server sites and balance processing loads. Custom business processes must be established to maintain the GIS Server multiple site configuration. Guidelines provided for single-machine high-availability (active-active) deployment can be used to publish services and maintain data across the multiple GIS Server machine farm.
Virtual server clones can be used to build and automate platform deployment. Service definition files can be used to deploy and update services to the production platforms. Data sources can be replicated to each GIS Server platform or maintained in a common database or file share. A common service output file share can be used to support distributed service requires across the multiple platform sites.
Single-cluster configurations provide optimum ArcGIS Server site scalability
ArcGIS Server single cluster sites is the default configuration since the ArcGIS 10.4 release.
The ArcGIS 10.3.1 release provides an option to remove the cluster aware load balancing between GIS server machines. A single ArcGIS Server site cluster deployment option is preferred over deploying multiple active-active server sites. There are several administrative advantages in deploying server machines in a single site cluster, taking advantage of a common config store and sharing common service configurations.
Removing GIS Server cluster aware load balancing between GIS Server machines reduces the communication overhead of a standard ArcGIS Server cluster deployment, providing scalability comparable with a multi-site server deployment with the advantages of a shared configuration store and common data source.
To remove ArcGIS Server cluster aware load balancing, the following criteria must be met:
- All GIS servers in the site must participate in a single cluster. Multiple clusters cannot exist.
- An external load balancer or ArcGIS Web Adaptor must be configured to forward requests to the GIS servers in the site. If no external gateway exists, requests will only be handled by the GIS server designated in the request.
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.
GIS Product Architecture 41st Edition
GIS Product Architecture 40th Edition
GIS Product Architecture 39th Edition
GIS Product Architecture 38th Edition
GIS Product Architecture 37th Edition
GIS Product Architecture 36th Edition
GIS Product Architecture 35th Edition
GIS Product Architecture 34th Edition
GIS Product Architecture 33rd Edition
GIS Product Architecture 32nd Edition
GIS Product Architecture 31st Edition
GIS Product Architecture 30th Edition
GIS Product Architecture 29th Edition
GIS Product Architecture 28th Edition
GIS Product Architecture 27th Edition