City of Rome 36th Edition

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


Spring 2015 City of Rome 36th Edition

This chapter shares a process you can use to complete your own system architecture design. This process brings together what has been discussed in the earlier chapters and demonstrates the value of the system design analysis in making informed design decisions.

System architecture design provides a methodology for establishing hardware and network requirements that support the performance and communication needs of GIS application users. Hardware requirements should be established based on identified business needs. A fundamental understanding of user workflow requirements and the supporting GIS technology is required before one can identify the appropriate hardware and network requirements for supporting effective enterprise GIS operations.

City of Rome is the name of the case study provided to demonstrate the planning process presented in a book by Roger Tomlinson called Thinking about GIS: Geographic Information System Planning for Managers. Both his book’s chapter 9 and this chapter show standard templates that can be used for most enterprise design studies. In this chapter we will use the Capacity Planning Tool as a framework to model user requirements and the system architecture design for two planned years of expansion and growth for the City of Rome.

Contents

City of Rome case study

Figure 12.1 The City of Rome is a typical municipal community that is used to represent how you might use the system architecture design methodology to make your infrastructure upgrade decisions.

Figure 12.1 shows a collection of photos representing City of Rome. The fictional City of Rome represents a typical organization, just right as a case study to demonstrate how you can use the capacity planning tool in your system design process.

Pre-design efforts

Figure 12.2 Business needs establish the foundation for any enterprise GIS design. The enterprise vision, existing business architecture, and user requirements must be understood to select the best GIS solution.

Figure 12.2 shows the efforts completed in preparation for the system architecture design. Business needs must be understood before you are ready to complete the system architecture design.

Enterprise vision

GIS software deployment patterns are optimized to support your business needs:

  • Asset management
  • Planning and analysis
  • Field mobility
  • Operational awareness
  • Constituent engagement

Existing Business Architecture

Business architecture defines the current state of how you are meeting your business requirements.

  • Governance and political landscape
  • People and communication strategies
  • Platform and network environments
  • Operational constraints and priorities
  • Funding constraints

User requirements analysis

User requirements analysis reviews the business processes to identify where and what is required to support business needs.

  • user location and connectivity
  • user workflow analysis (user needs)

User location and connectivity

Figure 12.3 Where users are located and how they are connected to central applications and data sources can determine acceptable system design candidates.

Figure 12.3 shows the user location and connectivity. All user locations requiring access to GIS applications and data resources must be identified.

  • You want to include everyone who might need access to the system during peak work periods.
  • The term "user locations" encompasses local users, remote users on the Wide Area Network (WAN), and Internet users (internal and public).

The enterprise infrastructure must be able to accommodate peak workflow traffic loads.

  • Know where users are located.
  • Know what information products users will need to do their work.
  • Identify the location of the necessary data resources.
Best practice: A simple diagram can be helpful for identifying user location and network connectivity.

In the system design assessment, you must identify the network communication bandwidth between the different user locations and the data center.

  • Network bandwidth may include communication constraints that will influence the proper software technology solution.
  • The selected technology solution may require upgrades to the network communication infrastructure.
Best practice: It is important to identify additional infrastructure costs during the planning process—you do not want to find this out after system deployment.


User workflow patterns

Figure 12.4 User workflow patterns are normally a product of a user needs assessment and provide a reference for establishing workflow loads for the system architecture design.

Figure 12.4 identifies the software technology workflow patterns identified for the City of Rome. GIS business information products and associated data sources were used to classify the identified technology patterns.

  • Desktop Editors would be classified as medium complexity workflows.
  • Desktop viewers work primarily with much more focused map displays and can be classified as light complexity workflows.
  • Business Analyst desktop applications will be classified as a medium complexity workflow.
  • Remote desktop viewers will be supported from a centralized terminal server farm, and will be classified as light complexity vector based workflows.
  • Web mapping services will be divided into two categories, with a medium complexity workflow used for internal web services and a light complexity workflow used for the more focused public facing services.
  • The Police services will use a Mobile ADF client in the patrol cars with a relatively light synchronization service for updating business layers during emergency response operations.

Performance targets for the identified workflow patterns were reviewed with the department managers to validate workflow complexity estimates.

Best practice: Workflow performance targets will be revisited during system deployment to validate design compliance.


City of Rome CPT user workflow analysis

The user workflow analysis will include a user requirements analysis for year 1 and year 2 to identify the workflows required to satisfy the City of Rome business requirements.

User Requirements Year 1
Figure 12.5 User requirements for City of Rome Year 1 establish peak business throughput loads for the Year 1 system architecture design.

Figure 12.5 shows the user requirements for City of Rome year 1 deployment.

The template used to document the year 1 user application requirements for the City of Rome was designed to integrate the requirements analysis provided in Tomlinson's Thinking about GIS with what is needed to complete the system architecture design. The spreadsheet identifies user workflow requirements (peak workflow loads) at the department level for each user location.

Peak workflow loads establish processing and traffic requirements used by the CPT to generate hardware specifications.

  • Each department manager should be called upon during the design process to validate that these peak user loads are accurate estimates.
  • It is important that the design analysis be based on validated peak user requirements, and that the relationship between business needs and these peak throughput estimates have been reviewed and are understood before the final design acceptance processes.
  • Peak user requirements are used by the CPT to generate system loads (the processing and traffic requirements referred to above) and determine the final hardware and network solution.

The first year deployment will include:

  • Internal ArcGIS for Desktop (Desk Edit and Desk View) and internal web services (LocalMap) within central City Hall (Planning and Engineering departments).
  • Three user locations over the WAN (Operations, Freeberg, and Willsberg).
  • The IT department will host public web services over their Internet connection.
Best practice: Each department manager is responsible for validating estimated peak workflow requirements.


User Requirements Year 2
Figure 12.6 User requirements for City of Rome Year 2 establishes peak business throughput loads for the year 2 system architecture design.

Figure 12.6 shows the user requirements for City of Rome year 1 deployment.

Year 2 includes:

  • Business Development department deployment of a new Business Analyst information system.
  • Engineering department deployment of Joint Tracking (JTX) work order management applications.
  • City adds 911 services within the Operations department, along with a new dispatch operation and implementation of five additional field offices (Perth, Wawash, Jackson, Petersville, and Rogerton).
  • A Tracking Server implementation is also deployed to facilitate snowplow scheduling.

Year 2 also includes implementation of a separate secure network to support police operations.

  • The police network will be a separate design.
  • Geodatabase replication services will provide updates from the city database to the police database.
  • A new ArcGIS Mobile application will support the police patrols, using wireless communications connecting through a T-1 WAN connection synchronizing with the ArcGIS for Server mobile clients (patrol cars).
  • The police department adds a police dispatch and implements a Tracking Server solution with the 20 police patrols.


User Requirements Summary
Figure 12.7 A requirements analysis summary provides a more condensed overview of user workflow requirements you will use to complete the system architecture design.

Figure 12.7 shows a requirements analysis summary for years 1 and 2

A user requirements summary is a more condensed template that you can use as your resource in completing the system architecture design. This template includes the same user locations and workflows provided in the earlier templates.

Best practice: GIS workflow requirements analysis represents the business requirements used to complete a proper system architecture design.

Performing a proper requirements analysis is hard work.

  • Organization staff must work together to identify workflow processes and agree on business needs.
  • Estimating the peak number of users for each user workflow is a fundamental part of doing business and must be completed by the business organization.
    • Peak workflow usage will affect decisions on staffing and software licensing.
    • Peak workflow usage will determine the network and hardware specifications.
  • Understanding and getting the user requirements summary right will make a big contribution toward completing a proper system architecture design and deploying productive GIS operations.

Now that you have completed the user requirements analysis, you are ready to continue with the system architecture design.

CPT Business workflows

Critical information is provided with this link to the Capacity Planning Tool Appendix.

CPT Workflow definitions

Critical information is provided with this link to the Capacity Planning Tool Appendix.

CPT hardware platform candidates

Critical information is provided with this link to the Capacity Planning Tool Appendix.

CPT workflow and hardware platform favorites
Figure 12.11 The CPT Favorites tab provides a way to organize your workflow and platform project lookup information.

Figure 12.11 shows a summary of the City of Rome Favorites (Workflows and Platforms) provided by the CPT Favorites tab.

The CPT Favorites tab can be used for organizing project workflows and hardware platform technology choices.

  • The Favorites tab can be used as an alternative CPT Design workflow lookup list or CPT hardware selection list.
  • The Favorites tab allows you to organize your specific project workflows and platform selection options on a shorter selection list.
  • The Favorites tab also includes the selected workflow description and the selected platform specifications as a summary view of your project resources.


System design process

Figure 12.12 System architecture design process provides a logical step-by-step methodology for using the CPT to complete your system architecture design.

Figure 12.12 shows the process used to complete the system architecture design. A fairly standard system architecture design process will be used to complete the City of Rome analysis.

System architecture design process:

  • Technical architecture strategy. High-level network drawing showing user site locations, network bandwidth connections, and central data center locations. Drawing should match the user location information provided on the user requirements templates.
  • Workflow loads analysis: The CPT Requirements analysis section is configured to represent the site locations, user workflows, peak loads, and network bandwidth for the enterprise design solution.
  • Network suitability analysis: CPT Design completes the network suitability analysis and identifies any communication bottlenecks. Network bandwidth upgrades are identified to complete the network suitability analysis.
  • Platform architecture selection: The CPT Design Platform tier is configured to represent the design solution. Identify platform tier nicknames, select platforms, and identify platform rollover settings.
  • Software configuration: The CPT Design Software Configuration module is used to assign workflow software to supporting platform tier (software install) and make workflow data source selection.
  • Enterprise design solution: Once configured, the CPT Design tab completes the system architecture design analysis and provides the platform solution.


City of Rome System Architecture Design: Year 1

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.

City Hall data center remote network connections

  • Data center—100 Mbps LAN connection
  • Data center—1.5 Mbps WAN connection
    • Site 2 Operations facility—1.5 Mbps WAN connection
    • Site 3 Freeberg—1.5 Mbps WAN connection
    • Site 4 Willsberg—1.5 Mbps WAN connection
  • Data center—1.5 Mbps Internet connection
    • Public web services will connect through the data center Internet connection.


Workflow loads analysis: Year 1

Figure 12.14 City of Rome Year 1 user needs summary

Figure 12.14 shows the City of Rome year 1 user needs summary. Once the custom workflows are defined (Workflow loads analysis), you are ready to complete the Phase 1 workflow requirements analysis. The City of Rome Year 1 user needs summary will be used as a reference to configure the CPT Design requirements analysis module.

The CPT workflow requirements analysis includes all of the Year 1 workflows identified during the business needs analysis.

  • Common workflows can be consolidated at each site location to simplify the display.
  • The CPT workflows must track back to represent the user requirements analysis.

User needs summary (workflow recipe introduced in Chapter 3)

  • User requirements include five workflows. Additional batch process was included for system administration use.
    • DeskEdit: AGD102 wkstn MXD 50%Dyn Med 19x10 Feature +$$ (local workstation DeskEdit users)
    • DeskView: AGD102 wkstn MXD 50%Dyn Lite 19x10 Feature +$$ (local workstation DeskView users)
    • RemoteGISView: AGD102 Citrix MXD V 50%Dyn Med 19x10 ICA +$$ (remote DeskView clients)
    • WebInternal: AGS102 REST MSD V 50%Dyn Med 13x7 PNG24 +$$ (LocalMap services)
    • WebPublic: AGS102 REST MSD V 50%Dyn Lite 13x7 PNG24 +$$ (PublicMap services)
    • BatchAdmin: AGS102 REST MSD R 100%Dyn Med 13x7 JPEG (reserved for batch administration processing)
  • Users are located at different network locations (local users, Operations site 2, Freeberg site 3, Willsberg site 4, and public Web services)
  • Peak workflow usage is identified for each network location
    • Local Area Network (peak users for DeskEdit and DeskView; peak throughput for LocalMap)
    • Operations site 2 (peak users for DeskEdit; peak throughput for LocalMap)
    • Freeberg site 3 (peak users for DeskEdit; peak throughput for LocalMap)
    • Public Internet connection (peak throughput for WebPublic services)


Network suitability analysis: Year 1

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Network upgrade recommendations: Year 1

Figure 12.17 Network bandwidth upgrades are provided from the City of Rome Year 1 network suitability analysis.

Based on a completed network suitability analysis, Figure 12.17 shows a list of the Year 1 network upgrade recommendations.

Best practice: Network bandwidth upgrade recommendations must be coordinated with the City of Rome network administrator and included in the network infrastructure upgrade budget.
Warning: Serious performance issues will impact user productivity during peak loads if required network bandwidth is not available in production.

Once potential network contention is identified and resolved, we are ready to move on to the platform architecture selection.

Platform architecture selection: Year 1

Figure 12.18 Three platform architecture solutions will be evaluated for the City of Rome Year 1 analysis.

Figure 12.18 shows the candidate architecture patterns that will be evaluated during the City of Rome Year 1 analysis.

Platform solution candidates

  • Minimum physical configuration: Identify the minimum number of physical platform architecture required to support peak production load requirements.
  • High-availability physical configuration: Identify the minimum high-availability physical platform architecture required to support peak production load requirements.
  • High-availability virtual configuration: Identify the minimum high-availability virtual server configuration architecture required to support peak production load requirements.


Hardware price list

Figure 12.19 City of Rome hardware price list that will be used to complete this business case analysis.

City of Rome management requests that we complete a cost analysis for the various platform architecture patterns being proposed for this study. Figure 12.19 shows the City of Rome hardware price list for platforms under consideration for this design.

Customer price lists can vary based on vendor arrangements and contract agreements. It is important to validate pricing if you wish to include this in your analysis.

Best practice: The Platform Performance lesson includes an assessment of current hardware platform capabilities, and should be reviewed with the IT procurement team for use in generating the best possible list of hardware candidates.
Note: Platform selection list above shows the [2013 best buy platform recommendations] identified in the Platform Performance Chapter 8.


CPT Platform architecture selection

Critical information is provided with this link to the Capacity Planning Tool Appendix.

CPT Design Software configuration

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Enterprise design solution: Year 1

CPT Design analysis for physical platform solution - Year 1

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Physical platform solution summary: Year 1
Figure 12.24 City of Rome Year 1 physical platform solution summary.

Figure 12.23 shows the minimum physical platform solution summaries for year 1. The solution summary was generated by the CPT Design tab. Each of the platform tier is supported by a single server; if any server were to fail, the services would no longer be available for those users.

Year 1 minimum physical server platform selections.

  • Two (2) Xeon E5-2637v2 4-core platforms, 96 GB RAM.
  • Two (2) Xeon E5-2637v2 4-core platforms, 23 GB RAM.

Minimum physical server platform solution = $43,000.

Year 1 HA physical server platform selections.

  • Four (4) Xeon E5-2637 4-core platforms, 96 GB RAM.
  • Four (4) Xeon E5-2637 4-core platforms, 23 GB RAM.

Year 1 HA physical server platform solution = $86,000.

The hardware pricing list was used to identify the cost for these solutions.

Warning: The hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing.


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

Critical information is provided with this link to the Capacity Planning Tool Appendix.

High-availability virtual platform solution summary: Year 1
Figure 12.28 City of Rome Year 1 high-availability virtual platform solution summary.

Figure 12.28 shows the high-availability virtual platform solution summaries for year 1. The solution summaries were generated by the CPT Design tab.

Year 1 HA virtual solution (Virtual Citrix Tier):

  • Two (2) Xeon E5-2637v2 8-core platforms, 192 GB RAM.
  • Four (4) host platform processors (chips).

HA virtual server platform solution = $50,780

Year 1 HA virtual solution (Physical Citrix WTS Tier):

  • Two (2) Xeon E5-2637 4-core WTS platforms, 96 GB RAM.
  • Two (2) Xeon E5-2637 4-core Host platforms, 96 GB RAM.
  • Two (4) host platform processors (chips).

HA WTS physical with virtual server platform solution = $55,590

Warning: Host platform per-core performance and overall throughput capacity determines the number of required virtual servers. Host platform with faster processor cores provide the best return on investment.
Note: Host platform utilization is 23.3 percent during peak loads, which leaves adequate capacity for additional virtual servers (i.e. test, development, and staging machines) .
Warning: Hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing.


City of Rome System Architecture Design: Year 2

Technical architecture strategy: Year 2

Figure 12.29 City of Rome Year 2 user location and bandwidth connectivity.

Figure 12.29 shows the City of Rome year 2 implementation strategies.

A server-based architecture in the central IT data center will be expanded to support the year 2 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.

City Hall data center remote network connections:

  • Data center — 100 Mbps LAN connection
  • Data center - 18 Mbps WAN connection (year 1 upgrade)
    • Site 2 Operations facility—3 Mbps WAN connection (year 1 upgrade)
    • Site 3 Freeberg—12 Mbps WAN connection (year 1 upgrade)
    • Site 4 Willsberg—12 Mbps WAN connection (year 1 upgrade)
  • Data center — 24 Mbps Internet connection (year 1 upgrade)
    • Public web services will connect through the data center Internet connection.
    • Site 5 Perth—1.5 Mbps Internet connection
    • Site 6 Wawash—1.5 Mbps Internet connection
    • Site 7 Jackson—1.5 Mbps Internet connection
    • Site 8 Petersville—1.5 Mbps Internet connection
    • Site 9 Rogerton—1.5 Mbps Internet connection

Additional data center Internet clients:

    • Emergency vehicles—56 Kbps Internet connection to each vehicle
    • Snow plows—56 Kbps Internet connection to each vehicle

A separate police department network will be deployed with their own GIS server.

  • Police Data Center – 100 Mbps LAN connection
  • Police Data Center — 1.5 Mbps WAN connection
  • Police vehicles — 56 Kbps WAN connection to each vehicle


Workflow loads analysis: Year 2

Figure 12.30 City of Rome Year 2 user needs summary

Once you complete the year 1 design, you are ready to complete the system architecture design for the City of Rome year 2 full deployment plans. Figure 12.30 shows the user needs summary for year 2.

The City of Rome Year 2 user needs summary will be used as a reference to configure the CPT Design requirements analysis module.

The CPT workflow requirements analysis includes all of the Year 2 workflows identified during the business needs analysis.

  • Common workflows can be consolidated at each site location to simplify the display.
  • The CPT workflows must track back to represent the user requirements analysis.


Network suitability analysis: Year 2

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Network upgrade recommendations: Year 2

Figure 12.33 Network bandwidth upgrades are provided from the City of Rome Year 2 network suitability analysis.

Based on your network suitability analysis, Figure 12.33 shows a list of the Year 2 network upgrade recommendations.

Network bandwidth upgrade recommendations must be coordinated with the City of Rome network administrator and included in the network infrastructure upgrade budget.

Warning: Serious performance issues will impact use productivity during peak loads if required network bandwidth is not available in production.

Once network contention is resolved, you are ready to move on to the platform architecture selection.

Platform architecture selection: Year 2

Figure 12.34 Two platform architecture solutions will be evaluated for the City of Rome Year 2 analysis.

Figure 12.34 shows the architecture selection objectives of the City of Rome Year 2 analysis. The high-availability virtual server solution was clearly the best choice for Year 1, so that will be the first candidate solution. The City would also like to evaluate a highbred cloud architecture deploying their public Web services in the Amazon cloud.

Platform solution candidates:

  • High-availability virtual configuration: Identify the minimum high-availability virtual server configuration architecture required to support peak production load requirements.
  • Amazon Web Public Services: Evaluate the benefits for deploying public web services on ArcGIS for Server Amazon Machine Instances (AMIs).


Enterprise design solution: Year 2

CPT Design analysis for high availability virtual platform configuration: Year 2

Critical information is provided with this link to the Capacity Planning Tool Appendix.

High availability virtual platform solution summary: Year 2
Figure 12.38 City of Rome Year 2 high available virtual platform solution summary.

Figure 12.38 shows the high-availability virtual platform solution summary for year 2. Once you complete the CPT Design platform architecture selection and software configuration, Excel completes the system architecture design analysis and provides the platform solution

Year 2 HA virtual solution (Virtual Citrix Tier):

  • Three (3) Xeon E5-2667v2 16-core Host platforms, 256 GB RAM.
  • Six (6) host platform processors (chips).

HA virtual server platform solution = $83,370

Year 2 HA virtual solution (Physical Citrix Tier):

  • Three (3) Xeon E5-2637 8-core WTS platforms, 128 GB RAM.
  • Two (2) Xeon E5-2637 8-core Host platforms, 192 GB RAM.
  • Four (4) host platform processors (chips).
Warning: Host platform per-core performance and overall throughput capacity determines the number of required virtual servers. Host platform with faster processor cores providing the best return on investment.

HA WTS physical with virtual server platform solution = $94,280.

Note: Host platform utilization is 29.9 percent during peak loads, which leaves adequate capacity for additional virtual servers (i.e. test, development, and staging machines) .
Warning: The hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing.


CPT Design analysis for data center without hosting public Web services

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Data center solution without web public services: Year 2
Figure 12.42 City of Rome Year 2 high-availability virtual platform solution without hosting web public services.

Figure 12.42 shows the high-availability virtual platform solution summary without web public services for year 2. The solution summary was generated by the CPT Design tab. Each platform tier is supported by at least two servers; if any server were to fail, the remaining server would continue providing required user services.

Year 2 HA platform solution without the web public services:

  • Three (3) Xeon E5-2637 8-core WTS servers, 128 GB RAM.
  • Two (2) Xeon E5-2637 8-core Host platforms, 128 GB RAM.
  • Four (4) host platform processors (chips).


Warning: Host platform per-core performance and overall throughput capacity determines the number of required virtual servers. Host platform with faster processor cores provide the best return on investment.

HA virtual server platform solution = $92,480

Warning: Hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing.


Public web services deployed on the Amazon cloud

Amazon pricing assumptions
Figure 12.43 Typical Amazon server instance pricing.

Accurate pricing of cloud hosting services can be challenging.

  • Host platform performance information may not be available.
  • A variety of fixed and variable pricing models may be used for computing your monthly bill.
  • Pricing over time is subject to change.
Best practice: Work with the cloud vendor to understand their pricing models and associated hosting platform performance.
Pricing for the City of Rome analysis is based on the following

Amazon virtual machine instances. Figure 12.43 shows the Amazon Reserved Instances (3 year term) pricing. Three-year term instances were used for this study.

Additional pricing factors include:

  • Initial data load = $85 (device + load time)
  • S3 storage = $0.030 per GB/month
  • Internet data transfer IN = $0.00 per GB
  • Data transfer OUT = $0.12 per GB/month (First GB/month free)
  • Elastic load-balancing = $0.025 per instance hour
  • Load Balance traffic charge = 0.008 per GB in/out
Warning: Amazon pricing is subject to change and may not represent the values used in this case study.


CPT Calculator analysis for Amazon Cloud public services configuration

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Amazon hosted pubic web servers pricing summary
Figure 12.45 Summary of total Amazon hosting costs for two servers over three years.

Figure 12.45 shows an overview of the Amazon pricing analysis for hosting the City of Rome public Web mapping services based on Year 2 throughput estimates. The pricing analysis assumed the estimated year 2 throughput would be consistent over the next three years, and pricing was based on a three year term. The three year term was selected for comparison based on life cycle cost for similar purchased hardware (3 year life cycle).

Data in estimates:

  • Assume 100 GB initial data source, with 10 GB updates per month
  • $85 for initial data load (AWS Import/Export service for 100 GB data)
  • $216 for S3 storage (200 GB x 0.030/month x 36 months)

Data out estimates (100,000 peak TPH, average 300,000 transactions per day):

  • 1.2 Mbpd traffic per transaction (45 GB per day, 1,350 GB per month)
  • $162 per month (1,350 GB @ $0.12 after first GB)
  • $5,832 over three years ($162 x 36 months)

Elastic load balancing (ELB) costs:

  • $ 389 total hour cost (2 instances x 24 hrs/day for three years @ $.025/hr)
  • $ 389 traffic cost (1,350 GB/month @ $.008/GB for three years)

Overall cost estimate is less than $15,000 over three years.

The Amazon variable rates apply only when you are using the AMIs. Additional savings may be possible using elastic load balancing with on-demand instances. For this study, two machines were capable to satisfy peak throughput needs and both were needed to meet high availability requirements. The three year term rates provided the best buy for this study.

Best practice: One of the primary advantage of deploying public Web services in the Cloud is server elasticity. In the event the peak throughput loads were to rapidly increase, additional servers could be deployed in time to accommodate the increased throughput loads.
Warning: Amazon pricing is subject to change and may not represent the values used in this case study.


Rome City Hall business case summary

The pricing summary can be used to make final deployment decisions.

Figure 12.46 Estimated pricing summary for Rome City Hall year 1 server configurations.

Figure 12.46 shows the Rome City Hall Year 1 server deployment alternatives.

Over $30,400 savings with the high-availability virtual server configuration (Citrix physical server tier).

  • Opportunity to consolidate servers and reduce hardware costs.
  • More adaptive and manageable server environment.
  • Better server provisioning and recovery capabilities.

Virtual server deployment strategies save money.

Figure 12.47 Estimated pricing summary for Rome City Hall year 2 server configurations.

Figure 12.47 shows the Rome City Hall Year 2 server deployment alternatives.

Over $13,000 additional cost over 3 years by hosting web public services on Amazon Cloud.

  • Extends data center enabling rapid response to changing service requirements.
  • Introduces cloud compute model for future deployment savings.
Best practice: Deployment decision may consider more than cost benefits alone.


City of Rome Police Department System Architecture Design

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Workflow loads analysis

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Network suitability analysis

Critical information is provided with this link to the Capacity Planning Tool Appendix.

CPT Design software configuration

Critical information is provided with this link to the Capacity Planning Tool Appendix.

Enterprise design solution

CPT Design analysis for high availability virtual platform configuration

Critical information is provided with this link to the Capacity Planning Tool Appendix.

High availability virtual platform solution summary
Figure 12.52 Police high-availability virtual platform solution summary.

Figure 12.52 shows the City of Rome Police Department high-availability virtual platform solution summary. The solution summary was generated by the CPT Design tab. Each platform tier is supported by at least two servers; if any server were to fail, the remaining server would continue providing required user services.

Police HA virtual platform solution:

  • Two (2) Xeon E5-2637v2 4-core (2 chip) Host servers, 96 GB RAM for failover configuration
  • Two (2) host platform processors (chips).
Best practice: Batch and synchronization services are both sequential batch processes and will perform well on a single core server.

Police server platform costs = $32,790

Choosing a system configuration

The best solution for a given organization depends on the distribution of the user community and the type of operational data in use. User requirements determine the number of machines necessary (to support the operational environment), the amount of memory required (to support the applications), and the amount of disk space needed (to support the system solution). The system design models provide target performance metrics to aid in capacity planning. The capacity planning tool incorporates standard templates representing the sizing models and provides a manageable interface to help in enterprise-level capacity planning efforts. The CPT can be a big help in applying the results of the user needs assessment.

User needs change as organizations change, so this assessment not only identifies platform and infrastructure specifications and sets performance targets for the initial implementation, it is also part of the process going forward. System upgrades, new technology solutions, tuning and optimizing performance--every implementation or change is like a new launch, insofar as you need to plan for it. Planning provides an opportunity to establish performance milestones that can be used to manage a successful GIS implementation. Performance targets used in capacity planning can provide target milestones to validate performance and scalability throughput deployment of the system.

CPT Capacity Planning videos

Previous Editions

City of Rome 35th Edition
City of Rome 34th Edition
City of Rome 33rd Edition
City of Rome 32nd Edition
City of Rome 31st Edition
City of Rome 30th Edition
City of Rome 29th Edition
City of Rome 28th Edition
City of Rome 27th Edition

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

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