City of Rome Year 1 (CPT Demos) 37th Edition
- City of Rome System Architecture Design (Year 1)
This section shares the CPT analysis supporting the City of Rome Year 1 system architecture design. The City of Rome case study brings together what has been discussed in the earlier chapters and demonstrates the value of the system design analysis in making informed design decisions.
A considerable amount of planning and evaluation must occur before an organization is ready to complete a system architecture design. Every organization is unique, and the optimum business solution will depend on the purpose and mission of the organization.
Contents
Pre-design planning efforts
Before developing a system architecture design, a review of business operations must be conducted to identify requirements for geographic information product solutions.
Enterprise vision. ArcGIS user workflow requirements are typically driven by decision points within existing business workflows, where user access to geographic information resources enhance the decision making process helping users work faster, smarter, or more efficiently in completing business tasks. Establishing an Enterprise vision is the effort to identify where ArcGIS solutions can be used to enhance business operations.
Existing business architecture. Initial planning should also take a close look at how the organization does business. Understanding the existing business architecture guides what type of system architecture design solutions will work best in supporting the business needs.
Workflow loads analysis. The Workflow loads analysis initially identifies the system design requirements in business terms (user needs summary). Requirements show the types of user workflows (ArcGIS technology patterns) needed to support the identified business operations, the peak number of concurrent users that will be working with this technology, where these users are located, and how they are connected to the central data center. It is also helpful to identify these users by department to aid in the review and requirements authorization process.
Figure A1-11.3 shows the product of the City of Rome user needs summary. The spreadsheet identifies the City of Rome departments that will participate in the ArcGIS deployment. General ArcGIS technology patterns are identified for each deployment phase. Design requirements are established by identifying the number of concurrent users that will be using each identified ArcGIS technology pattern during the peak loads on the system. The spreadsheet shows where the users will be located and how they will be connected (over the network) to the central data center.
CPT Workflow Loads Analysis
Once City of Rome completes and approves their user needs requirements summary, the CPT Calculator can be used to translate each of the ArcGIS technology patterns into user workflows that represent the identified business needs. Meetings with users of each ArcGIS workflow pattern can be used to inform the system design architect on the complexity and application requirements for each of the user workflows. The CPT Calculator software technology performance factors section can be used to generate appropriate performance targets for each of the ArcGIS technology workflow patterns.
Figure A1-11.4 shows the CPT Calculator being used to generate performance targets for the City of Rome local map user workflows. A medium complexity ArcGIS 10.3 REST service was used as a performance target for Web services published to support internal Web operations. City of Rome decided to use the Esri Community Maps program to host their base map reference layers, which would be consumed from ArcGIS Online reducing processing load on their internal ArcGIS Server by 50% (%DataCache). The cached tiles would be included in the workflow recipe (+mapcache) representing the cached tile traffic with each client display.
CPT Business workflows
Figure A1-11.5 shows the results of our City of Rome CPT workflow loads analysis.
The workflow performance targets (component software service times) generated by the CPT Calculator can be included in the City of Rome project workflows located on the CPT Workflow tab.
Each organization's solution will be different.
- Several decisions must be made during the design process before a final representation is collected in the capacity planning tool.
- The process and discussion leading up to the final design should be documented as a record of decisions made during the design process.
- Design documentation should clearly define the basis for the final workflow representation.
CPT Workflow definitions
Figure A1-11.6 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 deploying the final software technology solution.
A change control process should be established to ensure that any modification to the initial design assumptions are properly reviewed and approved before change acceptance.
- The approval process should include an assessment of potential performance and scalability risks.
- The CPT Calculator and CPT Design tools will provide a valuable framework to document and manage technology change and make proper assessments during system design and deployment.
City of Rome System Architecture Design: Year 1
Figure A1-11.7 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 for each identified design solution.
System architecture design process:
- Technical architecture strategy. High-level network drawing showing user site locations, network bandwidth connections, and central data center locations.
- 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 A1-11.8 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.
User requirements analysis: Year 1
Figure A1-11.9 shows an overview of the peak business requirements for City of Rome Year 1.
- Three project workflows on the LAN network (DeskEdit, DeskView, and LocalMap).
- Three remote sites on the WAN network (Operations, Freeberg, Willsberg).
- Operations has two project workflows (DeskView, LocalMap).
- Freeberg and Willsberg each have two project workflows (DeskView, LocalMap).
- One Web Services project workflow on the Internet network (PublicMap).
The user requirements analysis is completed by configuring the CPT Design tab to represent the business requirements identified in the user needs summary. Figure A1-11.10 shows the CPT Design tab requirements analysis module configured to represent City of Rome Year 1 requirements.
- BatchAdmin project workflow was included on the LAN configuration to reserve capacity for executing one administrative batch process during peak operations.
- Project workflows were updated in column B to represent the user needs.
- Peak users for each workflow were identified in column C.
- Peak throughput (TPH) were included for Web services in column D.
- Network bandwidth was included in column H for each network gateway.
Network suitability analysis: Year 1
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 the identified network traffic. These upgrades are normally coordinated with the network administrator based on the identified network traffic. Network administrator may identify any existing or planned traffic that was not identified in the GIS user requirements workflow loads analysis. Additional traffic can be added to the CPT Design by including the background traffic template in row 25 within the site configuration.
Recommended network upgrades should be roughly double the peak traffic flow:
- WAN from 1.5 Mbps to 90 Mbps
- Site 2 from 1.5 Mbps to 12 Mbps
- Site 3 from 1.5 Mbps to 45 Mbps
- Site 4 from 1.5 Mbps to 24 Mbps
- Internet from 1.5 Mbps to 24 Mbps
Figure A1-11.11 shows the CPT Design Year 1 network suitability upgrades. Recommended network upgrades are included in column H.
RESET/ADJUST function in Column T must be reset and returned to SAVE to recalculate batch process productivity for the new configuration.
CPT Design shows network bottlenecks are resolved.
- Workflow performance summary shows average user display performance.
CPT hardware platform candidates
Hardware procurement standards are normally established by the IT department.
- Enterprise-level procurement agreements are often made with hardware vendors to streamline the procurement process.
- It is important to review the available hardware selections and do research to identify performance and capacity needs.
- You will also need to understand if virtual server environments will be used, and review how this will impact your software licensing requirements.
The CPT Hardware tab is used as a lookup list for capacity planning hardware performance metrics.
- The CPT Calculator and Design tabs gather platform performance metrics from the Hardware tab.
- All platform configurations used in your CPT Design must first be identified on the CPT Hardware tab.
CPT Hardware Pricing
Figure A1-11.13 shows hardware pricing for the platform candidates identified for the City of Rome design. Hardware pricing will be used during the system architecture design analysis to identify the most cost effective design solution. All of the platform candidates used in the CPT Design must be included on the HWPricing tab to support the cost analysis.
- Hardware platform processor configurations are identified in column B.
- Available memory configurations are identified in column C for each platform.
- City of Rome procurement price is identified for each configuration in column F.
CPT Platform architecture selection
Figure A1-11.14 shows the physical platform tier configuration for year 1. Data center servers will be configured in four separate platform tier. Citrix terminal server farm will host the remote desktop clients, separate tier will be provided for the internal and public Web mapping services, and a single DBMS will provide the data source for internal GIS data. The minimum server configuration is focused on the production system - existing hardware will be used for development, testing, and staging environments.
Platform tier configuration
- WTS: Platform Tier 07 will host the Citrix Terminal Server farm.
- WebIn: Platform Tier 08 will host the web internal ArcGIS for Server web and SOC software components.
- WebPub: Platform Tier 09 will host the web public ArcGIS for Server web and SOC software components.
- DBMS: Platform Tier 10 will host the SDE geodatabase server platform.
The minimum physical platform configuration will use the fastest available processor to minimize overall system costs. The same platform will be used for all server tiers.
Platform selection:
- Client workstation: Intel Core i7-4770 4-core (1 chip) 3400 MHz
- Data center server tier: Xeon E5-2637v3 4-core (2 chip) 3500 MHz platform
- 80 percent rollover selected for all server platform tier
CPT Design Software configuration
Figure A1-11.15 shows the CPT software configuration module selections for year 1. For each workflow, the software is assigned to the appropriate platform tier and DB_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 and Portal software set to WebIn platform tier (internal web services)
- SOC software set to WebIn platform tier (internal web services)
- SDE software set to Direct Connect
- DBMS software set to DBMS platform tier
WebPublic workflow software assignment (row 22)
- Web software set to WebPub platform tier (public web services)
- SOC software set to WebPub platform tier (public web services)
- DBMS software set to Default (Enterprise DBMS data source)
All remaining workflow software assignments set to default platform.
DBMS software set to Default (Enterprise DBMS data source)
Enterprise design solution: Year 1
CPT Design analysis for 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 A1-11.16 shows the minimum physical platform solution for year 1.
RESET/ADJUST function in Column T must be reset and returned to SAVE to recalculate BatchAdmin process productivity for the new configuration.
Minimum physical platform solution - Year 1
- One (1) Xeon E5-2637v3 4-core WTS server, 56 GB RAM.
- One (1) Xeon E5-2637v2 4-core WebIn server, 12 GB RAM.
- One (1) Xeon E5-2637v2 4-core WebPub server, 12 GB RAM.
- One (1) Xeon E5-2637v2 4-core DBMS server, 56 GB RAM.
CPT Design analysis for high-availability physical platform solution - 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 A1-11.17 shows the high-availability physical platform solution for year 1.
The high-availability (High Avail) selection below 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.
Note: If two DBMS platforms are required to support peak throughput loads, a higher capacity platform (scale up) or active-active DBMS architecture (special configuration) will be required to support the peak loads. Multiple DBMS platforms can be configured by specifying the number of platform nodes for the DBMS tier in column H.
RESET/ADJUST function in Column T must be reset and returned to SAVE to recalculate batch process productivity for the new configuration.
High-availability physical platform solution:
- Two (2) Xeon E5-2637v3 4-core WTS server, 56 GB RAM.
- Two (2) Xeon E5-2637v3 4-core WebIn server, 12 GB RAM.
- Two (2) Xeon E5-2637v3 4-core WebPub server, 12 GB RAM.
- One (1) Xeon E5-2637v3 4-core DBMS server with additional failover platform with the same configuration, 56 GB RAM.
CPT Design analysis for high-availability virtual platform solution: Year 1
A copy of the CPT Design for the Year 1 HA physical platform configuration can be updated to build the Year 1 high-availability virtual platform configuration.
Select virtual server configuration in column I.
- Select Vserver for each virtual tier.
- Select 2 core/node for each virtual tier.
- Select Host platform assignment for each virtual tier.
Select Xeon E5-2635v3 8 core server as the host platform. This platform provides roughly the same per core performance as the Xeon E5-2637v3 4 core server 3500 MHz server with twice the capacity (total of 8 core). The Xeon E5-2643v3 12 core 3400 MHz platform was also considered, and was deferred for Year 2 consideration (the E5-2637v3 had plenty of capacity to handle peak Year 1 capacity requirements and provided the lowest cost hardware solution).
Once the Platform Tier are configured, Excel completes the system architecture design analysis and provides the platform solution. Figure A1-11.18 shows the high-availability virtual server platform solution for year 1.
Warning: Virtual Server tier platform much match the assigned Host Platform selection.
HA Virtual Server and host platform configuration:
- Two (2) E5-2637v3 8 core (2 chip) 3500 MHz, 167 GB RAM host platforms.
- Three (2) 2-core WTS Virtual Servers, 27 GB RAM.
- Two (2) 2-core WebIn Virtual Servers, 6 GB RAM.
- Two (2) 2-core WebPub Virtual Servers, 6 GB RAM.
- One (1) 2-core DBMS Virtual Server plus failover, 27 GB RAM.
Best practice: Host platform configuration must have N+1 servers for high availability.
City of Rome business case summary: Year 1
Figure A1-11.19 shows the Rome City Hall Year 1 server deployment alternatives. The business case summary shows over $17,400 savings with the high-availability virtual server configuration.
• 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.
Page Footer
Specific license terms for this content
System Design Strategies 26th edition - An Esri ® Technical Reference Document • 2009 (final PDF release)
