City of Rome 32nd Edition

Spring 2013 City of Rome 32nd 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.  

GIS business planning
Figure 12-1 shows the process for GIS planning. GIS planning provides a foundation for building and maintaining successful GIS operations.

Planning begins by thinking about what you want out of the system.
 * What is the overall business strategy?
 * What are the critical business processes?
 * What information products drive business decisions?
 * What are the critical data resources?
 * How does GIS support current business operations?
 * What are the current business needs?
 * What are the GIS software technology needs?
 * What are the available software technology deployment patterns?
 * What is the process for migrating business operations to the new technology state?
 * What are the costs and benefits for making this business change?

These are some of the questions that are addressed during a typical business needs assessment.

System architecture design is a process for identifying the required network and platform infrastructure. Network and platform infrastructure must satisfy peak system capacity and performance needs to enable planned business operations.

"Best practice: System architecture design should be included as an integral part of every business planning process." 

System architecture design
Figure 12-2 shows the system architecture design process. System architecture design is an integral part of the GIS business needs assessment.

GIS enterprise operations are both compute processing and network traffic intensive, which means:
 * GIS operations can place heavy demands on server processing and network traffic loads.
 * Network capacity can be one of the determining factors driving proper software technology selection.
 * In some cases, hardware constraints can drive software technology selection.

"Best practice: Infrastructure requirements should always be understood and considered before making a final software technology selection." 

Maintain a current plan
Figure 12-3 emphasizes the importance of maintaining a current GIS plan.

Planning is critical for:
 * Providing a framework for enterprise GIS implementation.
 * Ensuring upper management support for required GIS investments.
 * Managing the evolution of enterprise GIS operations.

Technology is changing more rapidly every year.
 * During the 1990s, GIS planning was a detailed, rigorous process required to identify and justify major changes in business processes necessary to achieve the benefits provided by GIS technology. GIS implementation would take several years to reach the final planned state—and technology would be relatively stable throughout that period.
 * Today, technology is changing much faster, and it is difficult to plan for more than one year at a time. Technology keeps improving, and adjustments must be made each year to keep pace with the change. Planning methodology is becoming more agile, adapting to the rapid change in technology.

"Best practice: Enterprise GIS planning is an ongoing process, and should be updated on an annual basis to keep pace with technology."

Most GIS deployments evolve over many years of incremental technology improvements, and: 
 * Implementation plans normally address a two- or three-year schedule to ensure that the budget is in place for the anticipated deployment needs.
 * Project planning should be adjusted annually to take advantage of technology improvements and adjust for technology change.

Figure 12-4 shows the CPT Design, a snapshot of a GIS plan identifying user needs, site locations, peak system loads, and platform solution for a specific target architecture (point in time). Changes in user workflow requirements will adjust loads on the selected platform solution. Changes in the platform architecture will identify expected performance improvements and system capacity. The CPT can provide an adaptive design model representing your GIS enterprise environment.

"Best practice: The Capacity Planning Tool provides a very adaptive framework for representing your GIS user workflow requirements and the associated system infrastructure needs required to manage technology change." 

City of Rome case study
Figure 12-5 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-6 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.

Business requirements can be grouped into three areas:
 * Enterprise vision
 * Existing business architecture
 * User workflow requirements

"Best practice: Each of these areas should be explored in some detail before you begin your system architecture design." 

Enterprise vision
Figure 12-7 shows an overview of the ArcGIS technology patterns and how they are deployed to satisfy customer business needs. GIS enterprise vision looks at how GIS technology can best support your business needs. ArcGIS includes a range of technology options developed as a complete set of integrated workflows and systems to satisfy a broad range of business requirements.

GIS software deployment patterns are optimized to support your business needs:
 * Asset management
 * Planning and analysis
 * Field mobility
 * Operational awareness
 * Constituent engagement

Most successful enterprise GIS operations evolve to embrace the full range of available GIS technology patterns to address focused business needs throughout their organization.

"Best practice: Establishing a clear enterprise GIS vision early in planning can help identify an optimum roadmap for building effective GIS operations."

Existing Business Architecture
Business architecture defines the current state of how you are meeting your business requirements. This includes a review of your platform and network architecture, governance and political landscape, types of user communities, operational constraints and priorities, and existing funding constraints. This is information that can be leveraged to identify a GIS design solution that builds on your current business operations. 

Platform and network environments
Figure 12-8 shows the types of software, network, servers, and data sources maintained within most business environments. Whether on your own or in concert with a design consultant, you should review the vendor platforms and network environments currently maintained by your organization.

Hardware experience, maintenance relationships, and staff training represent a considerable amount of investment for any organization.

"Best practice: Proposed GIS design solutions should take advantage of corporate experience gained from working with the established platform and network environment." 

Governance and political landscape
Figure 12-9 shows how the organization governs and manages its business operations. Organizations often develop policies and standards that support their software and hardware investment decisions.

A review of management preferences and associated vendor relationships will provide insight into a design solution that can be supported best by the organization.

Meet with the GIS and IT managers to review any policies or preferences they may have for the design. Major system upgrades often provide a chance for reviewing new platform technology directions, and management may want to include specific alternative technology patterns they are considering in the design effort. 

Use the right language
Figure 12-10 shows the importance of using the right language to get your message across.

"Best practice: Take time to listen."

Successful design consulting requires some communication skills.
 * Often the language used by the technical staff is very different than what is used by the user community.
 * Performance and user productivity is often viewed differently by the IT staff and the user community.
 * Technology is changing rapidly, along with the words that are used to describe system loads, architecture patterns, system performance and capacity needs.
 * Words that are used to describe GIS technology patterns change and many design concepts are not well understood.

"Best practice: The words you use, how you listen, and how you speak establishes your credibility with both the user community and the technical IT staff. Credibility is very important in leading a mixed group of business users, technical architects, and system administrators toward a proper design decision." 

Operational constraints and priorities
Figure 12-11 shows some key constraints that impact the system architecture design. Understanding the type of operations supported by the GIS solution will identify requirements for fault tolerance, security, application performance, and the type of client/server architecture that would be appropriate to support these operations.

System availability requirements
Most enterprise operations include several additional platform requirements in addition to their production environment.
 * Development and test platforms
 * Staging platforms
 * Redundant maintenance and publishing database environments
 * Possible remote backup data center
 * Possible cloud collaboration and publishing services

"Warning: All business requirements and priorities are not the same, and it is important to listen and understand what is important in making the final design recommendations. "

Security requirements
Identify the level of security governing the current business operations
 * Basic - no sensitive data.
 * Standard - moderate consequences for data loss or integrity
 * Advanced - sensitive data

What security standards are currently in place
 * Published Web services standards
 * Data production and distribution access standards
 * Access protection for Web appication servers and data sources.

Performance requirements
Identify any performance concerns being addressed by the new design
 * User productivity
 * Remote access
 * Public web services
 * Geoprocessing timelines
 * Batch process timelines

"Best practice: High availability, redundancy, security, and special performance considerations drive requirements for increased hardware and software costs. Recommendations should be backed up with facts to support proper cost and benefit analysis." 

Funding constraints
Figure 12-12 shows the projected GIS operations budget.

"Warning: The final design must be affordable. "

An organization will not implement a solution that is beyond its financial resources.
 * With system design, cost is a function of performance and reliability.
 * If cost is an issue, the system design must facilitate a compromise between user application performance, system reliability, cost and schedule.
 * The design consultant must identify a hardware solution that provides optimum performance and reliability within identified budget constraints.

Current technology enables distribution of GIS solutions to clients throughout an enterprise environment, but there are limitations that apply to any distributed computer system design. 
 * It is important to clearly understand real GIS user needs and discuss alternative options for meeting those needs with system support staff to identify the most cost-effective solution.
 * It may be necessary to review several alternative software technology patterns along with a variety of system deployment options to identify and establish the best implementation strategy.

User location and connectivity
Figure 12-13 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
Software technology workflow patterns are normally identified during a user requirements analysis. The Figure 12-14 workflow patterns were identified for the City of Rome.

The user workflow analysis will review each of these technology patterns and identify appropriate software component processing loads for each of the identified use cases. These user workflow loads will determine computer processing and network capacity requirements.

The CPT Calculator tab provides the capability for generating custom user workflow models to represent a broad range of software technology patterns.
 * The CPT Calculator and Design tools incorporate all the platform sizing models Esri has used for system design consulting services over the past 20 years. GIS software workflow patterns were identified in Chapter 2.  Workflow performance recipes were introduced in Chapter 3.
 * New technology patterns are included with each software release.
 * The tool's ability to dynamically model available system design alternatives provides an adaptive, integrated, management view of a complete system architecture design solution.

There is a tradeoff between simplicity and complexity in representing user workflows in a system architecture design.
 * Simplicity is easier to understand, simpler to quantify, enables broader validation, helps quantify business risk, and provides valuable information on which to base business decisions.
 * Complexity may be more accurate, may provide a closer representation of the final implementation, and may lead to more detailed results; yet complex models can be much more difficult to understand, harder to quantify, more difficult to validate, and may include hidden risk.

During the initial planning phase, it is best to develop the most simple representation of your system architecture design solution that will lead to the right business decisions.

"Best practice: A simple model is best: it highlights the relationship between what the organization wants to do with GIS (what you want out of the system) and the technology you need to do it (software, hardware, and network infrastructure procurement decisions)."

Planning should establish performance targets that you can identify and validate throughout system deployment.
 * The CPT models used during planning are based on what is learned from performance benchmark testing and what other people are able to do with the technology. Software performance targets were introduced in Chapter 3.
 * You can use the CPT models to establish your own system performance targets, based on your specific infrastructure limitations and operational needs. You can also use the workflow performance models introduced in Chapter 3.

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-15 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. " <br style="clear: both" />

User Requirements Year 2
Figure 12-16 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. <br style="clear: both" />
 * 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-17 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. <br style="clear: both" />

CPT Business workflows
Figure 12-18 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. <br style="clear: both" />
 * 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-19 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. <br style="clear: both" />
 * 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-20 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. <br style="clear: both" />
 * 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.

CPT workflow and hardware platform favorites
Figure 12-21 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. <br style="clear: both" />
 * 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-22 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: <br style="clear: both" />
 * 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.

Technical architecture strategy: Year 1
Figure 12-23 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 <br style="clear: both" />
 * 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-24 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) <br style="clear: both" />
 * User requirements include five workflows. Additional batch process was included for system administration use.
 * DeskEdit: AGD101 wkstn MXD 50%Dyn Med 10x7 Feature +$$ (local workstation DeskEdit users)
 * DeskView: AGD101 wkstn MXD 50%Dyn Lite 10x7 Feature +$$ (local workstation DeskView users)
 * RemoteGISView: AGD101 Citrix MXD V 50%Dyn Med 10x7 ICA +$$ (remote DeskView clients)
 * WebInternal: AGS101 REST MSD V 50%Dyn Med 10x7 PNG24 +$$ (LocalMap services)
 * WebPublic: AGS101 REST MSD V 50%Dyn Lite 10x7 PNG24 +$$ (PublicMap services)
 * BatchAdmin: AGS101 REST MSD R 100%Dyn Med 10x7 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
Figure 12-25 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: <br style="clear: both" />
 * WAN from 1.5 Mbps to 24 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-26 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. <br style="clear: both" />
 * Workflow performance summary shows relative user display performance.

Network upgrade recommendations: Year 1
Based on a completed network suitability analysis, Figure 12-27 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. <br style="clear: both" />

Platform architecture selection: Year 1
Figure 12-28 shows the candidate architecture patterns that will be evaluated during the City of Rome Year 1 analysis.

Platform solution candidates <br style="clear: both" />
 * 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
City of Rome management requests that we complete a cost analysis for the various platform architecture patterns being proposed for this study. Figure 12-29 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 identifies the [2012 best buy platform recommendations] identified in the Platform Performance Chapter 8." <br style="clear: both" />

CPT Platform architecture selection
Figure 12-30 shows the physical plaform 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 focussed 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 tier.

Platform selection <br style="clear: both" />
 * Client workstation: Intel Core i3-2120 2-core (1 chip) 3100 MHz selected to represent the client workstation environments.
 * Data center server tier: Xeon E5-2637 4-core (2 chip) 3000 MHz platform selected for the physical server solutions based on highest performing best buy 4-core server configuration.
 * 80 percent rollover selected for all server platform tier.

CPT Design Software configuration
Figure 12-31 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. <br style="clear: both" />

CPT Design analysis for Minimum physical platform solution - Year 1
Once the Platforms and Workflow software are configured, Excel completes the system architecture design analysis and provides the platform solution. Figure 12-32 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: <br style="clear: both" />
 * WTS tier: One (1) Xeon E5-2637 4-core (2 chip) 3000 MHz server with 44 GB RAM
 * WebIn tier: One (1) Xeon E5-2637 4-core (2 chip) 3000 MHz server with 12 GB RAM
 * WebPublic tier: One (1) Xeon E5-2637 4-core (2 chip) 3000 MHz server with 12 GB RAM
 * DBMS tier: One (1) Xeon E5-2637 4-core (2 chip) 3000 MHz server with 44 GB RAM

Minimum physical platform solution summary: Year 1
Figure 12-33 shows the minimum physical platform solution summary 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 platform solution:
 * WTS: 1 x Xeon E5-2637 4-core 3000 MHz 48 GB RAM
 * WEB Internal : 1 x Xeon E5-2637 4-core 3000 MHz 12 GB RAM
 * WEB Public: 1 x Xeon E5-2637 4-core 3000 MHz 12 GB RAM
 * DBMS: 1 x Xeon E5-2637 4-core 3000 MHz 48 GB RAM

The hardware pricing list can be used to identify the cost for this solution. Minimum physical platform solution server platform cost = $55,740.

"Warning: The hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing. " <br style="clear: both" />

CPT Design analysis for high-available physical platform configuration: Year 1
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-34 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: <br style="clear: both" />
 * WTS tier: Two (2) Xeon E5-2637 4-core (2 chip) 3000 MHz servers with 44 GB RAM
 * WebIn tier: Two (2) Xeon E5-2637 4-core (2 chip) 3000 MHz servers with 12 GB RAM
 * WebPublic tier: Two (2) Xeon E5-2637 4-core (2 chip) 3000 MHz servers with 12 GB RAM
 * DBMS tier: One (1) Xeon E5-2637 4-core (2 chip) 3000 MHz servers with 44 GB RAM with additional failover server of the same configuration.

High-availability physical platform solution summary: Year 1
Figure 12-35 shows the high-availability physical platform solution summary for year 1. The solution summary was generated by the CPT Design tab. Each of the platform tier is supported by two servers; if any server were to fail, the remaining server would continue providing required user services.

Year 1 high-availability physical platform solution:
 * WTS: 2 x Xeon E5-2637 4-core 3000 MHz 48 GB RAM
 * WEB Internal : 2 x Xeon E5-2637 4-core 3000 MHz 12 GB RAM
 * WEB Public: 2 x Xeon E5-2637 4-core 3000 MHz 12 GB RAM
 * DBMS: 1 x Xeon E5-2637 4-core 3000 MHz 48 GB RAM with failover server

High-availability physical platform solution server platform cost = $111,480 based on provided hardware price list. This is twice the cost of the minimum physical server platform solution.

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

"Note: Server utilization for each platform tier is less than 25 percent, suggesting there could be significant savings through server consolidation by implementing a virtual server solution." <br style="clear: both" />

CPT Design analysis for high-availability virtual platform configuration: Year 1
Copy of the CPT Design for the high-availability physical platform configuration can be updated to provide results for the high-availability virtual 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-36 shows the high-availability virtual platform solution for year 1.

The Xeon E5-2667 12-core (2 chip) 2900 MHz server was selected as the virtual server host platform. This platform provides roughtly the same per core performance as the Xeon E5-2637 4-core 3000 MHz server with much more capacity (total of 12 core). The Xeon E5-2690 16 core (2 chip) 2900 MHz platform was also considered, and was rejected due to the higher virtual server cost ($4,500 per VM for 8 core chips).

Select a new host platform configuration for each server tier.
 * Xeon E5-2667 12-core (2 chip) 2900 MHz platform

"Best practice: E5-2667 12-core platforms were selected because they provide optimum virtual server consolidation capacity with minimum loss in per-core performance."

Select the virtual server configuration.
 * Select virtual server (VMware) selection for each tier in column I.
 * Select 2 core/node to set virtual core for each node.

"Best practice: Two core server configurations provide the best performance and throughput for virtual server platforms. CPT model applies 10 percent performance overhead per core to account for virtual server processing overhead."

Once virtual server selection is made, Excel completes the system architecture design analysis.

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

High-availability virtual platform solution:
 * WTS tier: WTS: 3x VM (2-core 20 GB RAM) deployed on Xeon E5-2667 2900 MHz host servers
 * WebIn tier: WebIn: 2x VM (2-core 6 GB RAM) deployed on Xeon E5-2667 2900 MHz host servers
 * WebPub: 2x VM (2-core 6 GB RAM) deployed on Xeon E5-2667 2900 MHz servers
 * DBMS: 1x VM (2-core 20 GB RAM) deployed on Xeon E5-2667 2900 MHz servers with a failover VM with the same configuration

"Best practice: Deployment of the virtual machines on the host platforms should be reviewed for an optimum high-availability configuration." <br style="clear: both" />

High-availability virtual platform solution summary: Year 1
Figure 12-37 shows the high-availability physical platform solution summary for year 1. The solution summary was generated by the CPT Design tab. Each of the platform tier is supported by two servers; if any server were to fail, the remaining server would continue providing required user services.

Year 1 high-availability virtual platform solution:
 * Hardware: Xeon E5-2690 12-core 2900 MHz host platforms
 * WTS: 3 x 2-core virtual servers each with 20 GB RAM
 * WEB Internal: 2 x 2-core virtual servers each with 6 GB RAM
 * WEB Public: 2 x 2-core virtual servers each with 6 GB RAM
 * DBMS: 1 x 2-core virtual server with failover server each with 20 GB RAM

High-availability virtual server platform configuration: Year 1
Virtual servers are deployed on physical server host platforms.
 * Xeon E5-2667 12-core (2 chip) 2900 MHz physical servers

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

"Best practice: For configuration planning purposes, virtual server cores do not exceed available physical host platform cores."

"Warning: Over-allocation of available host processor cores (more virtual cores than physical cores) can result in reduced throughput and performance during peak virtual server loads. " <br style="clear: both" />

Figure 12-38 shows the virtual server host platform configuration strategy. Deployment strategy should be planned to provide an optimum high-availability virtual server configuration.

Two and three host configurations were discussed. Two Xeon E5-2667 12-core (2 chip) 2900 MHz host platforms are required to support this configuration. This was a trade-off configuration between overall cost and required availability requirements.

Primary host platform:
 * 3x WTS 2-core virtual servers
 * 1x WebIn 2-core virtual server
 * 1x WebPub 2-core virtual server
 * 1x DBMS 2-core virtual server
 * 1x Staging 2-core virtual server

Backup (failover) host platform:
 * 1x WTS 2-core virtual server (active)
 * 1x WebIn 2-core virtual server (active)
 * 1x WebPub 2-core virtual server (active)
 * 1x DBMS 2-core virtual server (failover)
 * 1x Development 2-core virtual server
 * 1x Test 2-core virtual server

In the event of a primary host platform failure:
 * DBMS will failover to backup server instance.
 * Dev and Test servers will be replaced with WTS servers.

"Warning:How virtual servers are deployed on available host platforms can impact system availability, performance, and the number of host platforms required to satisfy peak operations. "

High-availability physical platform solution server platform cost = $42,370 based on provided hardware price list. This represents $69,110 hardware savings over the high-availability physical server platform solution.

"Warning: Hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing. " <br style="clear: both" />

Technical architecture strategy: Year 2
Figure 12-39 shows the City of Rome year 2 implementation strategy.

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 - 24 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 remote network connections: <br style="clear: both" />
 * Police — 1.5 Mbps WAN connection to data center
 * Police vehicles — 56 Kbps WAN connection to each vehicle

Workflow loads analysis: Year 2
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-40 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. <br style="clear: both" />
 * 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
Figure 12-41 shows the Year 2 CPT Design workflow configuration. To simplify configuration effort, start with a copy of the Year 1 CPT Design tab (virtual server platform configuration) and add the Year 2 workflows to complete 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 Chapter 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: <br style="clear: both" />
 * Data center LAN from 100 Mbps to 1 Gbps
 * Data center WAN from 24 Mbps to 45 Mbps
 * Site 2 from 3 Mbps to 24 Mbps
 * Data center Internet from 24 Mbps to 90 Mbps
 * Site 6 from 1.5 Mbps to 12 Mbps
 * Site 7 from 1.5 Mbps to 6 Mbps
 * Site 8 from 1.5 Mbps to 18 Mbps
 * Site 9 from 1.5 Mbps to 18 Mbps

Figure 12-42 shows the Year 2 network suitability upgrades. Results of the network suitability analysis should be shared with the Network Administrator, and together identify upgrades for the year 2 network infrastructure to support the year 2 design. Recommended network upgrades are included in column H.

The 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. <br style="clear: both" />
 * Workflow performance summary shows relative user display performance for each workflow at each site location.

Network upgrade recommendations: Year 2
Based on your network suitability analysis, Figure 12-43 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. <br style="clear: both" />

Platform architecture selection: Year 2
Figure 12-44 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 highbrid cloud architecture deploying their public Web services in the Amazon cloud.

Platform solution candidates: <br style="clear: both" />
 * 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).

CPT Design analysis for high availablility virtual platform configuration: Year 2
Confirm the virtual platform configuration: The Workflow Configuration sheet was copied from the Year 1 virtual server configuration and should have the proper hardware platform configuration set. Once you confirm the proper hardware configuration, Excel completes the system architecture design analysis. Figure 12-45 shows the year 2 high availability virtual platform solution.

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

High-availability virtual platform solution: <br style="clear: both" />
 * WTS tier: WTS: 10x VM (2-core 20 GB RAM) deployed on Xeon E5-2667 2900 MHz host servers
 * WebIn tier: WebIn: 2x VM (2-core 6 GB RAM) deployed on Xeon E5-2667 2900 MHz host servers
 * WebPub: 2x VM (2-core 6 GB RAM) deployed on Xeon E5-2667 2900 MHz servers
 * DBMS: 1x VM (4-core 40 GB RAM) deployed on Xeon E5-2667 2900 MHz servers plus an additional failover VM with the same configuration

High availability virtual platform solution summary: Year 2
Figure 12-46 shows the high-availability virtual platform solution summary for year 2. The solution summary was generated by the CPT Design tab. Each of the platform tier is supported by two servers; if any server were to fail, the remaining server would continue providing required user services.

Year 2 high-availability virtual platform solution:
 * Hardware: Xeon E5-2690 12-core 2900 MHz host platforms
 * WTS: 10x 2-core virtual servers each with 20 GB RAM
 * WEB Internal: 2x 2-core virtual servers each with 6 GB RAM
 * WEB Public: 2x 2-core virtual servers each with 6 GB RAM
 * DBMS: 1 x 4-core virtual server with failover server each with 40 GB RAM

High-availability virtual platform configuration: Year 2
Virtual servers are deployed on physical server host platforms.
 * Xeon E5-2667 12-core (2 chip) 2900 MHz physical servers

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

"Best practice: For configuration planning purposes, virtual server core did not exceed available physical host platform core."

' Over-allocation of available host processor cores (more virtual cores than physical cores) can result in reduced throughput and performance during peak virtual server loads. ''' <br style="clear: both" />

Figure 12-47 shows the selected virtual server platform configuration. Deployment strategy should be planned to provide an optimum high-availability virtual server configuration.

Four Xeon E5-2667 12-core (2 chip) 2900 MHz host platforms are required to support this configuration.

Primary 1 host platform:
 * 6x WTS 2-core virtual servers (active - each 20 GB RAM)

Primary 2 host platform:
 * 2x WTS 2-core virtual server (active—each 20 GB RAM)
 * 1x WebIn 2-core virtual server (active—each 12 GB RAM)
 * 1x WebPub 2-core virtual server (active—each 12 GB RAM)
 * 1x DBMS 4-core virtual server (active—40 GB RAM)

Primary 3 host platform:
 * 2x WTS 2-core virtual server (active—each 20 GB RAM)
 * 1x WebIn 2-core virtual server (active—each 12 GB RAM)
 * 1x WebPub 2-core virtual server (active—each 12 GB RAM)
 * 1x DBMS 4-core virtual server (failover—40 GB RAM)

Backup (failover) host platform:
 * 1x Dev 2-core virtual server
 * 1x Test 2-core virtual server
 * 1x Staging 2-core virtual server

In the event of a primary 1 or 2 host platform failure:
 * DBMS will failover to backup server instance.
 * Backup (failover) host platform will drop Dev, Test, and Staging servers and recover failed server configuration.

"Warning: How virtual servers are deployed on available host platforms can impact system availability, performance, and the number of host platforms required to satisfy peak operations. "

High-availability physical platform solution server platform cost = $84,740 based on provided hardware price list.

"Warning: The hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing. " <br style="clear: both" />

CPT Design analysis for data center without hosting public Web services
Copy previous high availability virtual platform configuration — Year 2 solution on separate tab and delete WebPublic peak throughput from column D. Once you remove the WebPublic peak throughput, Excel completes the system architecture design analysis. Figure 12-48 shows the City of Rome Year 2 data center solution without hosting the public web services.

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

High-availability virtual platform solution:
 * WTS tier: WTS: 10x VM (2-core 20 GB RAM) deployed on Xeon E5-2667 2900 MHz host servers
 * WebIn tier: WebIn: 2x VM (2-core 6 GB RAM) deployed on Xeon E5-2667 2900 MHz host servers
 * DBMS: 1x VM (4-core 40 GB RAM) deployed on Xeon E5-2667 2900 MHz servers plus an additional failover VM with the same configuration

"Best practice: Publishing public services on the Amazon Cloud removes requirements to host these services in your data center environment. " <br style="clear: both" />

High-availability virtual platform solution summary without web public services: Year 2
Figure 12-49 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 of the 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 high-availability virtual platform solution without the web public services:
 * Hardware: Xeon E5-2690 12-core 2900 MHz host platforms
 * WTS: 10x 2-core virtual servers each with 20 GB RAM
 * WEB Internal: 2x 2-core virtual servers each with 6 GB RAM
 * WEB Public: 2x 2-core virtual servers each with 6 GB RAM
 * DBMS: 1 x 4-core virtual server with failover server, each with 40 GB RAM

<br style="clear: both" />

High-availability virtual platform configuration without web public: Year 2
Virtual servers are deployed on physical server host platforms.
 * Xeon E5-2667 12-core (2 chip) 2900 MHz physical servers

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

"Best practice: For configuration planning purposes, virtual server cores did not exceed available physical host platform cores."

"Warning: Over-allocation of available host processor cores (more virtual cores than physical cores) can result in reduced throughput and performance during peak virtual server loads. "

Figure 12-50 shows the selected virtual server platform configuration. Deployment strategy should be planned to provide an optimum high-availability virtual server configuration.

Three Xeon E5-2667 12-core (2 chip) 2900 MHz host platforms were selected to support this configuration.

Primary 1 host platform:
 * 6x WTS 2-core virtual servers (active—each 20 GB RAM)

Primary 2 host platform:
 * 3x WTS 2-core virtual server (active—each 20 GB RAM)
 * 1x WebIn 2-core virtual server (active—each 12 GB RAM)
 * 1x DBMS 4-core virtual server (active—40 GB RAM)

Primary 3 host platform:
 * 1x WTS 2-core virtual server (active—each 20 GB RAM)
 * 1x WebIn 2-core virtual server (active—each 12 GB RAM)
 * 1x DBMS 4-core virtual server (failover—40 GB RAM)
 * 1x Dev 1-core virtual server
 * 1x Test 1-core virtual server
 * 1x Staging 2-core virtual server

In the event of a primary 2 host platform failure:
 * DBMS will failover to backup server instance.
 * Test, Staging, and Development servers will be dropped and failover server will reinstate failed server 2 configuration.

In the event of a primary 1 host platform failure:
 * DBMS, Test, Staging, and Development servers will be dropped and failover server will reinstate failed server 1 configuration.

"Warning: How virtual servers are deployed on available host platforms can impact system availability, performance, and the number of host platforms required to satisfy peak operations. "

High-availability physical platform solution server platform cost = $63,555 based on provided hardware price list. This is a reduction of $21,185 over the solution that included support for the public Web mapping services.

"Warning: Hardware pricing used for this analysis is for demonstration purposes only and does not represent actual vendor pricing. " <br style="clear: both" />

Amazon pricing assumptions
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-51 shows the Amazon Reserved Instances (3 year term) pricing. Three-year term instances were used for this study.

Additional pricing considerations include:
 * Internet data transfer IN = $0.00 per GB
 * Data transfer OUT = $0.12 per GB/month (First GB/month free)
 * Regional data transfer = $0.01 per GB
 * Public and elastic IP and elastic load balancing data transfer = $0.01 per GB in/out
 * Elastic load balancing = $0.025 per hour

"Warning: Amazon pricing is subject to change and may not represent the values used in this case study. " <br style="clear: both" />

CPT Calculator analysis for Amazon Cloud public services configuration
Figure 12-52 shows the CPT Calculator used to compute web public server platform solution. CPT Calculator can be used for completing a single workflow system architecture design sizing analysis.

Enter the Web public peak throughput and data source selections.
 * Peak throughput = 100,000 TPH
 * Select Small FGDB data source (you will use geodatabase replication services to publish data updates to the Amazon machine).

Amazon AMI Platform Selection:
 * Select AMI HM Extra Large Instance 2-core (6.5 CU) 17.1 GB as the platform selection.

"Warning: The Amazon server instances performance specifications are included in the CPT Hardware tab based on [EC2 instance type compute resources information] provided on the Amazon Web site. "

"Best practice: The AMI HM Extra Large Instance 2-core (6.5 CU) 17.1 GB virtual server machine is Amazon's highest performing 2-core server configuration based on the information Amazon shares for the AMI instance performance."


 * Identify a two-tier high-availability configuration.

"Best practice: With ArcGIS 10.1 server, a high-availability configuration would require two separate site deployments (Amazon does not provide a file share to host the ConfigStore and ServerDirectories with access from multiple platforms). It is possible to configure failover file servers to establish a file share, but this would increase cost to unreasonable levels for smaller configurations.  The simplest solution is to deploy two separate ArcGIS for Server sites and manage updates accordingly."

Amazon Cloud platform solution:
 * GIS server: 2x HM Extra Large Instance 2-core (6.5 CU) 17.1 GB Amazon Machine Instance
 * Data source: File geodatabase

Amazon AMI pricing (based on pricing model): <br style="clear: both" />
 * Fixed cost for three-year term = $1,283
 * Variable cost of $0.18 per hour for 26,280 hours = $4730.40
 * Total cost per server = $6,013.40
 * Cost for two servers = $12,027

Amazon hosted pubic web servers pricing summary
Figure 12-53 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 an 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)
 * $396 S3 storage (100 GB x 0.11/month x 36 months)

Data out estimates (100,000 peak TPH, average 300,000 transactions per day):
 * 1.2 Mbpd traffic per transaction (36 GB per day, 1,080 GB per month)
 * $130 per month (1,080 GB @ $0.12)
 * $4,666 over three years ($130 x 36 months)

Elastic load balancing (ELB) costs:
 * $ 648 total hour cost (24 hrs/day for three years @ $.025/hr)
 * $ 388 traffic cost (1,350 GB/month @ $.008/GB for three years)

Overall cost estimate is less than $19,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. " <br style="clear: both" />

Rome City Hall business case summary.
The pricing summary can be used to make final deployment decisions.

Figure 12-54 shows the Rome City Hall Year 1 server deployment alternatives.

Over $69,000 savings with the high-availability virtual server configuration.
 * Able 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. <br style="clear: both" />

Figure 12-55 shows the Rome City Hall Year 2 server deployment alternatives.

Over $2,900 savings by publishing web public services on Amazon Cloud. <br style="clear: both" />
 * Extends data center enabling rapid response to changing service requirements.
 * Introduces cloud compute model for future deployment savings.

Workflow loads analysis
Figure 12-56 shows the City of Rome Police Department user needs and CPT Design workflow configuration. The CPT Design analysis is completed on a separate CPT Design tab. The CPT requirements analysis includes all of the police workflows identified during the business needs analysis. An additional batch process was included in the design to reserve core to accommodate one system administration batch process during peak system loads.

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

The CPT Design shows no network bottleneck issues. <br style="clear: both" />

Network suitability analysis
Figure 12-57 shows the Police hardware configuration. Separate single core VMs were established for the system administration batch process (Batch) and the mobile synchronization service (WebMap). The SDE geodatabase would be deployed on a single database server (DBMS).

Platform tier configuration:
 * Batch: Platform Tier 08 will host the batch process.
 * WebMap: Platform Tier 09 will host the web Mobile Synchronization service.
 * DBMS: Platform Tier 10 will host the SDE geodatabase server platform.

Xeon E5-2637 4 core (2 chip) 3000 MHz servers were selected as the host platform. The E5-2673 processor had a SPECrate_int2006 benchmark of 46.3 per core, one of the faster machines available in the 2012 procurement period.

Platform selection: <br style="clear: both" />
 * Client workstation: Intel Core i3-2120 2-core (1 chip) 3100 MHz selected to represent the client workstation environments.
 * Data center server tier: Xeon E5-2637 4-core (2 chip) 3000 MHz platform selected for the physical server solutions based on highest performing best buy 4-core server configuration.
 * 80 percent rollover selected for all server platform tier.

CPT Design software configuration
Figure 12-58 shows the software and virtual machine configurations. For each workflow, assign software to the appropriate platform tier and select appropriate data source.

Default Row 5 software assignment:
 * Client software set to client
 * Web software set to WebMap
 * SOC software set to WebMap (Mobile synchronization services)
 * SDE software set to Default (Direct connect)
 * DBMS software set to DBMS

Batch workflow software assignment (row 6):
 * Web software set to Batch (batch virtual machine)
 * SOC software set to Batch (batch virtual machine)
 * DBMS software set to Default (Police DBMS geodatabase)

All remaining workflow software assignments set to default platform.

Data source assignment SDE_DBMS for all workflows. <br style="clear: both" />

CPT Design analysis for high availability virtual platform configuration
Once the platforms and workflow software are configured, Excel completes the system architecture design analysis and provides the platform solution. Figure 12-59 shows the CPT Design Police virtual platform solution.

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

High-availability virtual platform solution: <br style="clear: both" />
 * Host platforms: Xeon E5-2637 4-core (2 chip) 3000 MHz servers
 * Batch tier: 2x VM (1-core 3 GB RAM)
 * WebMap tier: 2x VM (1-core 3 GB RAM)
 * DBMS: 1x VM (2-core 22 GB RAM) plus an additional failover VM with the same configuration

High availability virtual platform solution summary
Figure 12-60 shows the City of Rome Police Department high-availability virtual platform solution summary. The solution summary was generated by the CPT Design tab. Each of the 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 high-availability virtual platform solution:
 * Hardware: Xeon E5-2637 4-core (2 chip) 3000 MHz
 * Batch: 2x 1-core virtual servers each with 3 GB RAM
 * WebMap: 2x 1-core virtual servers each with 3 GB RAM
 * DBMS: 1 x 2-core virtual server with failover server each with 22 GB RAM

"Best practice: Batch and synchronization services are both sequential batch processes and will perform well on a single core server." <br style="clear: both" />

High availability virtual platform configuration
Figure 12-61 shows the Police virtual server platform configuration.

Virtual server host deployment
 * Active batch single core servers on each machine.
 * Active batch mobile single core servers on each machine.
 * Primary active DBMS 2-core server with failover machine.

"Best practice: Each host platform contains sufficient actives servers to accommodate the projected peak system loads."

Police server platform costs were $36,770.

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.

Previous Editions
City of Rome 31st Edition (Fall 2012) City of Rome 30th Edition (Fall 2011) City of Rome 29th Edition (Spring 2011) City of Rome 28th Edition (Fall 2010) City of Rome 27th Edition (Spring 2010)

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