City of Rome Year 1 (CPT Demos) 36th Edition

From wiki.gis.com
Jump to: navigation, search
Capacity Planning Tool TABLE OF CONTENTS 36th Edition
1. System Design Process (CPT Demos) 36th Edition 2. GIS Software Technology (CPT Demos) 36th Edition 3. Software Performance (CPT Demos) 36th Edition
4. Server Software Performance (CPT Demos) 36th Edition 5. GIS Data Administration (CPT Demos) 36th Edition 6. Network Communications (CPT Demos 36th Edition)
7. GIS Product Architecture (CPT Demos) 36th Edition 8. Platform Performance (CPT Demos 36th Edition) 10. Performance Management (CPT Demos) 36th Edition
12. City of Rome Year 1 (CPT Demos) 36th Edition 12. City of Rome Year 2 (CPT Demos 36th Edition) CPT What’s New 36th Edition


City of Rome System Architecture Design (Year 1)

This section shares the CPT analysis supporting the City of Rome Year 1 system architecture design. The City of Rome case study brings together what has been discussed in the earlier chapters and demonstrates the value of the system design analysis in making informed design decisions.

Technical architecture strategy: Year 1

Figure 12.13 City of Rome Year 1 user location and bandwidth connectivity.

Figure 12.13 shows the user locations and network connectivity for the year 1 GIS implementation strategy.

A server-based architecture will be deployed from the central IT data center for the year 1 implementation.

  • Server platforms will include a Windows Terminal Server farm to support the remote ArcGIS for Desktop users.
  • ArcGIS for Server to support the public web services.
  • A central GIS data server to support the enterprise geodatabase.


CPT Business workflows]
Figure 12.8 Custom project workflows established for the City of Rome system design.

Figure 12.8 shows the results of our City of Rome workflow loads analysis.

The workflow performance targets (component software service times) generated by the CPT Calculator can be included in the City of Rome project workflows located on the CPT Workflow tab.

Each organization's solution will be different.

  • Several decisions must be made during the design process before a final representation is collected in the capacity planning tool.
  • The process and discussion leading up to the final design should be documented as a record of decisions made during the design process.
  • Design documentation should clearly define the basis for the final workflow representation.


CPT Workflow definitions
Figure 12.9 A workflow description includes the workflow recipe generated by the CPT Calculator during the initial workflow analysis. Workflow names are then changed to a more recognizable reference for use during the design.

Figure 12.9 shows the CPT Calculator recipe used to generate the City of Rome project workflows.

Assumptions made during the technology selection process must be carried through project implementation. This is a single point where many GIS implementation fail — assumptions are made during the initial system architecture design that is lost when developing and implementing the final software technology solution.

A change control process should be established to ensure that any modification to the initial design assumptions are properly reviewed and approved before change acceptance.

  • The approval process should include an assessment of potential performance and scalability risks.
  • The CPT Calculator and CPT Design tools will provide a valuable framework to document and manage technology change and make proper assessments during system design and deployment.


CPT hardware platform candidates
Figure 12.10 City of Rome hardware platform candidates are moved to the Project Platform Candidates area on the Hardware tab for easy access during the design process.

Figure 12.10 shows how to identify project hardware candidates on the CPT Hardware tab. Hardware candidates should be reviewed for performance and capacity metrics. Most vendors publish performance benchmarks for their platform configurations on the SPEC Web site.

Hardware procurement standards are normally established by the IT department.

  • Enterprise-level procurement agreements are often made with hardware vendors to streamline the procurement process.
  • It is important to review the available hardware selections and do research to identify performance and capacity needs.
  • You will also need to understand if virtual server environments will be used, and review how this will impact your software licensing requirements.

The CPT Hardware tab is used as a lookup list for capacity planning hardware performance metrics.

  • The CPT Calculator and Design tabs gather platform performance metrics from the Hardware tab.
  • All platform configurations used in your CPT Design must first be identified on the CPT Hardware tab.


Network suitability analysis: Year 1

Figure 12.15 The City of Rome workflows are configured in the CPT Design requirements module to represent the Year 1 business needs.

Figure 12.15 shows the CPT Design year 1 workflow configuration. The CPT requirements analysis includes all of the Year 1 workflows identified during the business needs analysis.

While you configure the user requirements and site locations in the CPT, and update the site traffic summation ranges to include all site workflow traffic going over the network connections (these CPT configuration procedures were discussed in lesson 6), Excel will complete the network suitability analysis.

Several performance problems are identified in the existing design due to network traffic bottlenecks.

  • Red cells in columns F:G identify traffic bottlenecks.
  • Recommend network upgrades to about twice identified network traffic.

Recommended network upgrades should be roughly double the peak traffic flow:

  • WAN from 1.5 Mbps to 18 Mbps
  • Site 2 from 1.5 Mbps to 3 Mbps
  • Site 3 from 1.5 Mbps to 12 Mbps
  • Site 4 from 1.5 Mbps to 12 Mbps
  • Internet from 1.5 Mbps to 24 Mbps


Figure 12.16 User workflow performance looks good once network bandwidth upgrades are completed (no red boxes).

Figure 12.16 shows the CPT Design Year 1 network suitability upgrades. Recommended network upgrades are included in column H.

RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate batch process productivity for the new configuration.

CPT Design shows network bottlenecks are resolved.

  • Workflow performance summary shows relative user display performance.


CPT Platform architecture selection

Figure 12.20 Platform architecture selection for City of Rome physical hardware solutions.

Figure 12.20 shows the physical platform tier configuration for year 1. Data center servers will be configured in four separate platform tier. Citrix terminal server farm will host the remote desktop clients, separate tier will be provided for the internal and public Web mapping services, and a single DBMS will provide the data source for internal GIS data. The minimum server configuration is focused on the production system - existing hardware will be used for development, testing, and staging environments.

Platform tier configuration

  • WTS: Platform Tier 07 will host the Citrix Terminal Server farm.
  • WebIn: Platform Tier 08 will host the web internal ArcGIS for Server web and SOC software components.
  • WebPub: Platform Tier 09 will host the web public ArcGIS for Server web and SOC software components.
  • DBMS: Platform Tier 10 will host the SDE geodatabase server platform.

The minimum physical platform configuration will use the fastest available processor to minimize overall system costs. The same platform will be used for all server tiers.

Platform selection:

  • Client workstation: Intel Core i7-4770 4-core (1 chip) 3400 MHz
  • Data center server tier: Xeon E5-2637v2 4-core (2 chip) 3500 MHz platform
  • 80 percent rollover selected for all server platform tier


CPT Design Software configuration

Figure 12.21 Software configuration for City of Rome platform solutions.

Figure 12.21 shows the CPT software configuration module selections for year 1. For each workflow, the software is assigned to the appropriate platform tier and SDE_DBMS is selected as the data source. The internal Web mapping services are assigned to the WebIn platform tier and the public Web mapping services are assigned to the WebPub platform tier. All workflows will use an SDE direct connect architecture when accessing the Geodatabase.

Default Row 5 software assignment:

  • Client software set to client
  • Citrix software set to WTS platform tier
  • Web software set to WebIn platform tier (internal web services)
  • SOC software set to WebIn platform tier (internal web services)
  • SDE software set to Default (direct connect)
  • DBMS software set to DBMS platform tier

WebPublic workflow software assignment (row 22)

  • Web software set to WebPub platform tier (public web services)
  • SOC software set to WebPub platform tier (public web services)
  • DBMS software set to Default (Enterprise DBMS data source)

All remaining workflow software assignments set to default platform.

DBMS software set to Default (Enterprise DBMS data source)

Enterprise design solution: Year 1

CPT Design analysis for physical platform solution - Year 1

Minimum physical platform configuration
Figure 12.22 Enterprise design solution for minimum physical platform architecture.

Once the Platforms and Workflow software are configured, Excel completes the system architecture design analysis and provides the platform solution. Figure 12.22 shows the minimum physical platform solution for year 1.

RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate Batch process productivity for the new configuration.

Minimum physical platform solution - Year 1

  • One (1) Xeon E5-2637v2 4-core WTS server, 50 GB RAM.
  • One (1) Xeon E5-2637v2 4-core WebIn server, 12 GB RAM.
  • One (1) Xeon E5-2637v2 4-core WebPub server, 12 GB RAM.
  • One (1) Xeon E5-2637v2 4-core DBMS server, 50 GB RAM.


High-availability physical platform configuration
Figure 12.23 Enterprise design solution for high-availability physical platform architecture.

A copy of the CPT Design for the minimum physical platform configuration can be updated to provide results for the high-availability physical platform configuration. Once you update the CPT Design platform architecture selection and software configuration, Excel completes the system architecture design analysis and provides the platform solution. Figure 12.23 shows the high-availability physical platform solution for year 1.

The high-availability (High Avail) selection above each platform tier in column H will automatically generate the proper number of platform nodes for each tier.

  • WTS tier high-availability requirements include N+1 server nodes.
  • WebIn and WebPublic high-availability requirements include at least two server nodes.
  • DBMS high-availability requirements must include an additional failover data server node.
Best practice: The DBMS tier High Avail selection must be set as minimum to show a single server. SDE Geodatabase multi-platform active-active server configurations required more expensive software and added administration complexity - it is much easier and effective to increase the number of platform core and maintain a single server primary environment than to implement an active-active clustered geodatabase server solution. A standby server would be configured in a failover cluster configuration for high availability.

RESET/ADJUST function in Column AF must be reset and returned to SAVE to recalculate batch process productivity for the new configuration.

High-availability physical platform solution:

  • Two (2) Xeon E5-2637v2 4-core WTS server, 50 GB RAM.
  • Two (2) Xeon E5-2637v2 4-core WebIn server, 12 GB RAM.
  • Two (2) Xeon E5-2637v2 4-core WebPub server, 12 GB RAM.
  • One (1) Xeon E5-2637v2 4-core DBMS server with additional failover platform with the same configuration, 50 GB RAM.


CPT Design analysis for high-availability virtual platform solution: Year 1

High-availability virtual server platform solution
Figure 12.26 Enterprise design solution for high-availability virtual server and host platform architecture, year 1.

A copy of the CPT Design for the Year 1 HA physical platform configuration can be updated to build the Year 1 high-availability virtual platform configuration.

Select virtual server configuration in column I.

  • Select Vserver for each virtual tier.
  • Select 2 core/node for each virtual tier.
  • Select Host platform assignment for each virtual tier.

Select Xeon E5-2635v2 8 core server as the host platform. This platform provides roughly the same per core performance as the Xeon E5-2637v2 4 core server 3500 MHz server with twice the capacity (total of 8 core). The Xeon E5-2690 12 core 2900 MHz platform was also considered, and was deferred for Year 2 consideration (the E5-2637v2 had plenty of capacity to handle peak Year 1 capacity requirements).

Once the Platforms tier is configured, Excel completes the system architecture design analysis and provides the platform solution. Figure 12.26 shows the high-availability virtual server platform solution for year 1.

Warning: Virtual Server tier platform much match the assigned Host Platform selection.

HA virtual server and host platform configuration:

  • Two (2) E5-2637v2 8 core (2 chip) 3500 MHz, 157 GB RAM host platforms.
  • Two (2) 2-core WTS Virtual Servers, 25 GB RAM.
  • Two (2) 2-core WebIn Virtual Servers, 6 GB RAM.
  • Two (2) 2-core WebPub Virtual Servers, 6 GB RAM.
  • One (1) 2-core DBMS Virtual Server plus failover, 25 GB RAM.
Best practice: Host platform configuration must have N+1 servers for high availability.


High-availability WTS physical servers with Web services and DBMS virtual server platform solution
Figure 12.27 Enterprise design solution for high-availability physical WTS tier with Web and DBMS virtual server and host platform architecture, year 1.
City expressed some concerns about deploying their Citrix XenApp applications in a virtual server configuration. Figure 12.27 provides a physical Citrix tier hybrid solution with the Web Services and DBMS platform tier deployed in a virtual server environment.

High-availability physical WTS tier with Web services and DBMS virtual server platform solution: • Two (2) E5-2637v2 4-core (1 chip) 3500 MHz WTS platforms, 50 GB RAM. • Two (2) E5-2637v2 4-core (1 chip) 3500 MHz Host platforms, 78 GB RAM. • Two (2) 2-core WebIn Virtual Servers, 6 GB RAM. • Two (2) 2-core WebPub Virtual Servers, 6 GB RAM. • One (1) 2-core DBMS Virtual Server plus failover, 25 GB RAM.

Best practice: WTS Citrix XenApp Physical server configuration provides lower risk deployment strategy.


Capacity Planning Tool TABLE OF CONTENTS 36th Edition
1. System Design Process (CPT Demos) 36th Edition 2. GIS Software Technology (CPT Demos) 36th Edition 3. Software Performance (CPT Demos) 36th Edition
4. Server Software Performance (CPT Demos) 36th Edition 5. GIS Data Administration (CPT Demos) 36th Edition 6. Network Communications (CPT Demos 36th Edition)
7. GIS Product Architecture (CPT Demos) 36th Edition 8. Platform Performance (CPT Demos 36th Edition) 10. Performance Management (CPT Demos) 36th Edition
12. City of Rome Year 1 (CPT Demos) 36th Edition 12. City of Rome Year 2 (CPT Demos 36th Edition) CPT What’s New 36th Edition


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