2017 Esr iPETROLEUM
GIS CONFERENCE
Architecture Best PracticesAndrew Sakowicz, [email protected]
Agenda
• ArcGIS platform• Conceptual architecture• Physical architecture considerations
Our World Is Evolving
Open
Configurable AgileEasier
Ready to Use
Implementation3D
Visualization
Apps
Collaborative
Analytics
Applications
TechnologyFaster Computing
Big Data
Distributed Processing
Cloud
Virtualization
IoT
ConsumerizationSmart Devices
Content
UAVs
Real-Time
Crowdsourcing
GIS is EvolvingOpening, Integrating and Simplifying Everything
Integrating Existing Systems . . .
Apps
DesktopServer
IdentityReal-Time
System of Engagement
Connected
Services
. . . Creating a System of Systems
Conceptual Architecture
Use GIS Across Your Organization
FieldMobility
Get authoritative information into
and out of the field
LocationEnablement
Discover, use, make, and share maps at work --
anywhere, anytime
Location DataManagement
Collect and organize location data about your
assets and resources
Analytics
Describe, predict, and improve
business performance
DecisionSupport
Inform execs and management with maps and location
intelligence
ConstituentEngagement
Facilitate and manage
communication with stakeholders
Leverage Identity
• Integrate with your existing IDM system• Configure in the portal
- Users- Roles- Privileges
• Incorporate in your apps
Identity matters!
Workforce Development
Workforce Developmentis a valuableinvestment
in your people!
Project Prioritization
Approach to Solutions
• Configure first• Customize second
- Extend where possible
Deviations from “core” increase risk!
Rapid & Agile
• Keep iterations brief (~30 days)• Involve stakeholders• Stop | restart at any time• Iterations terminate with the business need
Each iteration results in deliverable you can use…
Environment Isolation
• Production: operational, real-time compute environment
• Staging: a separate, mirrored, pre-production environment
• Development: a limited scale and scope environment sufficient for the development of primary code and data modeling.
High Availability
What is acceptable downtime for your operational business workflows?
Availability (%) Downtime per year
Downtime per week
95.0 18.25 days 8.4 hours
99.0 3.65 days 1.68 hours
99.9 8.76 hours 10.1 minutes
99.99 52.56 minutes 1.01 minutes
99.999 5.26 minutes 6.05 seconds
AGOL, EMCS, most Public Cloud Vendors
Workload Separation
• Separate technology deployments by solution pattern• Benefits include:
- Reduced risk- Improved service delivery- Reduced system resource contention- Optimized resource utilization
Typically SLAs determine which server deployments need to be separated
Analysis Constituent Engagement
Conceptual ArchitectureBest Practices
https://www.esri.com/~/media/Files/Pdfs/products/arcgis-platform/architecting-the-arcgis-platform
Physical Architecture
Requirements and considerations
Characteristics Preference(s)IT Maturity Low, Moderate, Advanced
Cloud Policy / Preference Cloud First, Ok w/ Cloud, Cloud Averse
Infrastructure Elasticity Easy, Moderately Easy, or Hard to Provision Infrastructure
Data Sensitivity (security) Very Sensitive (e.g. HIPPA), Business Sensitive, Somewhat, Not Sensitive
GIS Workflows (next 2-3 years) Web Mapping, Cartographic Mapping, 3D, Analysis, Real-time, Big Data
Public / Constituent Engagement Heavy, Some, None
Level of Collaboration / Sharing External and Internal, Internal Only, Limited, None
Use of 3rd Party Services Prefer, Ok, None
Comfort Outsourcing to Esri Very, Some, Limited, Note
Service Level Agreement None, 95%, 99% +
Disaster Recovery Strategy None, Future, Imminent
Requirements and considerations
Area FocusSecurity Authentication & User Store Preferences (e.g. AD domains/forests, web adaptor)
Authorization Requirements (e.g. granularity, enterprise groups)
ArcGIS Server Federation?
Infrastructure Virtual or Physical (including desktop)
Operating System Preferences
Load Balancers, Reverse Proxies, and Forward Proxies
Availability & Resiliency High Availability Requirements
Disaster Recovery and/or Backup and Restore Requirements
Distribution Distributed GIS Design
Network Topology (bandwidth & latency)
Geodata Replication/Synchronization Requirements
ConsiderationsFocus Areas
1. Deployment Architecture2. GIS Server & Services Architecture3. High Availability & Disaster Recovery4. Security5. Real-time GIS & Big Data6. Geodata Management7. Imagery Data Management8. Publication Strategies9. Mobile GIS Deployment10. Desktop GIS Deployment11. Organizational Structure & IT Governance12. Operations
Cloud deployment options
On-premises Public Cloud Hybrid
On-Premises, Online or hybrid
Intranet
Online
Intranet
Online
Intranet
Online
Cloud GIS Server(e.g. Amazon)
Esri ManagedCloud Services
Internet Users Internet Users Internet Users
ArcGIS Online ArcGIS Online w/ Cloud GIS Server(s)
ArcGIS Online w/ Esri Managed Cloud Svcs
Cloud options
Portal deployment options
portal
portal
portalportal
One Portal Many Portals?
One or multiple portals
portal portal portal
Shared Services
Department A Users Department B Users Department C Users
Portal deployment options
Department A Users
portal
Department B Users
portal
Department C Users
portal
Shared Services
portalEnterprise or Public Users
Portal deployment options
ArcGIS Server deployment options
Cluster A Cluster B
Silo Siterecommended
ClusterTo be deprecated
Configuration Stores Configuration Store(shared)
Configuration Store(shared)
LB LB LB
Site
Site
Silos, Sites & Clusters
Use silos or small sites
Data management options
Data management strategyCentralized
Single data center = lower cost
Performance depends on network: good bandwidth and low latency
Data management strategyDistributed
Good performance-local application and data
Might require complex replication and Might require complex replication and synchronization process
Multiple datacenters = higher costs
Data management strategy
• Geodatabase export / import• RDBMS export / import• RDBMS replication• ETL Tools (e.g. FME, Informatica)• Geodatabase replication
Publication options
Services
App
Services
App
Web Maps & Layers
Server Pattern Web GIS Pattern
portal
WellsWells
Active Wells
Proposed Wells
Wells by Status
Portal GeoServices Geodata
Publication StrategiesThe Role of Portal & Web Layers
Hosting server
• Scalable solution - can publish thousands of services
Scaling and workload separation
Visualization Analysis &Data Management
Imagery
LBLBLB
ArcGIS Server ArcGIS Server ArcGIS Server
Visualization &Imagery
LB
ArcGIS Server
Initial Deployment Complete GIS
Workload Separation
Server Roles
• Follow best practices on workload separation and assign only one server role per ArcGIS Server site
• If small site and consider combining multiple server roles in a single site:- Be careful combining GIS Server role with other server roles- Be careful combining Image Server role with other server roles- Avoid combining GeoEvent Server role with other server roles- Never combine GeoAnalytics Server role with any other server role
Scaling the base ArcGIS Enterprise deployment
• Conduct capacity planning and testing • Add machine to hosting server as needed, especially when using:• Spatial analysis tools
- http://server.arcgis.com/en/portal/latest/administer/windows/configure-the-portal-to-perform-analysis.htm
• Insights for ArcGIS- http://server.arcgis.com/en/insights/latest/administer/windows/configure-the-portal-to-
support-insights-for-arcgis.htm
ArcGIS Enterprise High Availability
Strategies for minimizing downtime and data loss
Backup and Restore High Availability Geographic Redundancy Geographic Redundancy with High Availability
Increasing complexity and required resources
Highly available ArcGIS Enterprisehttp://server.arcgis.com/en/portal/latest/administer/windows/ha-scenarios-web-gis.htm
• ArcGIS Web Adaptor
• Portal for ArcGIS
• ArcGIS Server
• ArcGIS Data Store
Infrastructure Capacity Planning
Provide sufficient hardware resources
GIS Systems are bound by:1. CPU - typically2. Memory – when large number of services3. Disk – Image Service, Synchronization4. Network – low bandwidth deployment5. Poorly configured virtualization can result in 30% or higher performance degradation
Most systems are CPU bound
Most well-configured and tuned GIS systems are CPU bound.
CPU capacity
1. User load: Concurrent users or throughput2. Operation CPU service time (model)—performance3. CPU SpecRate
subscript t = targetsubscript b = benchmarkST = CPU service timeTH = throughput%CPU = percent CPU
• Required bandwidth- Response size- Number of transactions
• Network transport time• Response size
• Effective bandwidth
Network capacityNetwork transport time
All Built into System Designer
3600/ reqMbitsTHMbps
usedMbpsMbpsreqMbitsTransport
/(sec)
System DesignerSolution Architecture design methodology
• Gathering requirements
• Designing
• Capacity: CPU, Network, Memory
• Reporting
Quick Capacity Report
• High-level summary for Rough Order of Magnitude
Thank You to Our Sponsors
EM
ER
AL
D
SA
PP
HIR
E
Select the session you attended
Scroll down to find the survey
Complete Answersand Select “Submit”
Download the Esri Events app and find your event
Please Take Our Survey on the Esri Events App!
BIG WordSmaller Word