Right-size Deployment Instances to Meet Enterprise Demand
description
Transcript of Right-size Deployment Instances to Meet Enterprise Demand
Deliver a mission-critical, production grade architecture and infrastructure
Right-Size Deployment Instances to Meet Enterprise Demand
© WSO2 2012. Not for redistribution. Commercial in Confidence.
Asanka Abeysinghe - Director, Solutions Architecture, WSO2
Mission-critical Deployment Webinar Series
We are going to look at
- Deployment Patterns
- Deployment Architecture
- Capacity Planning
- Best Practices
Picture Credit : http://www.ibtimes.com/
Why ?
Production System
Business stakeholders Consumers
Business Objectives
IT Capabilities
Architecture
Standards SDLC
Reviews
SLAs
Patterns Find a catalog
Deployment Patterns : Standalone with individual runtimes
Deployment Patterns : Standalone with shared runtime
Break : Icons
Deployment Patterns : Shared Registry – JDBC mode
Deployment Patterns : Shared Registry – WS-* mode
Deployment Patterns : Cluster for high-availability
A P
- Stateful Cluster - Enable Carbon Clustering - Multicasting - WKA
- Stateless Cluster - Rely on load-balancer
Deployment Patterns : Cluster for scalability
- Static - Use any load-balancer
- Elastic - Use WSO2 ELB A A
Deployment Patterns : Cluster for scalability Elastic
A A A
Deployment Patterns : Cluster with Deployment-Sync
A A A
Admin Node Worker Nodes
Deployment Synchronizer - SVN
Architecture Draw the blueprints
Things to consider before go to the whiteboard - Infrastructure
- Physical / Virtual / Cloud / Hybrid
- Infrastructure Policies
- Non Functional
- Performance
- Security
- High-availability
- Recovery
Things to consider before go to the whiteboard - Make it simple
- Manageable (TechOps)
- Change control and configuration management
- Governance
- Future proof
- Unexpected business demand
Build the architecture visually
Deployment Architecture – Reference architecture 1
Deployment Architecture – Reference architecture 2
Deployment Architecture – Reference architecture 3
Deployment Architecture – Reference architecture 4
Deployment Architecture – Reference architecture 5
Capacity Planning How to Scale
Gather Data : Sources
- From monitoring systems - From business marketing stats - Current data - Future / Projected data
Gather Data : Types
- Expected maximum throughput/TPS - Expected latency - Size of messages - Work done per transaction
Expected Maximum TPS / Peak load
- You have to know TPS or TPM (per minute). Transactions per day is useless unless we have some store and process model in the architecture. Often, most messages in a day come within minutes.
- When there is no numbers to refer try to get a rough idea, is it 10s, 100s 1000s or 10000s?
- Remember, this is Maximum value, not the average
Size of Messages
- Try to classify them to following - Small (<50k) - Moderate (<1M) - Large (<5M) - Extra large (> 5M)
- If messages greater than 1M, better to a trial run as results are very unreliable
Transaction : Identify the CPU cycles
Apply to each deployment architecture layer
Component Capacity Planning Guidelines
API Gateway Peak load of the API calls
Auth Server Peak load of the API calls
API Store Peak load of the subscriptions and browsing
API Publisher Peak load of the API publishing and LCM tasks
Analytics System load of the API calls
Example : API Manager Capacity Planning
Refer available performance numbers
Compute the instances Pattern With WSO2 Analytics With WSO2 LB
Minimum Internal Store
5 [ 2 GW + 2 Auth + 1 (Store + Publisher) ]
7 [ 2 GW + 2 Auth + 1 (Store + Publisher) + 2 BAM (DC + DS, DB + DS + DA ]
9 [ 2 LB + 2 GW + 2 Auth + 1 (Store + Publisher) + 2 BAM (DC + DS, DB + DS + DA ]
Minimum External Store
6 [ 2 GW + 2 Auth + 1 Store + 1 Publisher ]
8 [ 2 GW + 2 Auth + 1 Store + 1 Publisher + 2 BAM (DC + DS, DB + DS + DA ]
10 [ 2 LB + 2 GW + 2 Auth + 1 Store + 1 Publisher + 2 BAM (DC + DS, DB + DS + DA ]
Extend = n1 GW + n2 Auth + n3 Store + n4 Publisher
= n1 GW + n2 Auth + n3 Store + n4 Publisher + n5 Analytics
= n1 LB + n2 GW + n3 Auth + n4 Store + n5 Publisher + n6 Analytics
But … try it on your environment with the use-cases
- Performance test - Actual use-cases - Message sizes - Infrastructure - Tools (Jmeter/SOAP-UI/Grinder ….)
Work with a WSO2 Consultant
- Fill the capacity planning sizing parameter doc - Work with a WSO2 consultant
Things to consider
- Keep a buffer of 30% - Should not load servers beyond 25% of normal instantaneous peak load - Allocate 2GB memory per Carbon instance/ JVM - Keep minimum 2GB memory for the OS and system utilities - Use system load (TPD/TPY) for data / log growth - Keep performance test (2x) and long running test as part of the
acceptance test
Extend the deployment
- Secure vault - Headless worker nodes - Connect to the existing user-store (LDAP/AD/RDBMS) - Fine-tune , thread pools, throttling - Command-line tools - Connect to SDLC, change control
Summary
- Identify the deployment patterns - Consider the deployment needs and constraints - Draw the deployment architecture (logical)
- Identify the architecture layers
- Gather data - Current - Future
- Refer performance statistics for a given HW and use-case(s) - Compute the instance count per each layer - Identify the physical architecture
Future webinars on Mission-critical Deployment
API Management Webinar Series
More Info
§ Corporate website: http://wso2.com
§ Solution Architecture Blog: http://wso2.com/blogs/architecture/
§ Business development team: [email protected]
§ Asanka Abeysinghe
§ Blog : http://asanka.abeysinghe.org
§ Twitter : @asankama
41
lean . enterprise . middleware