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: bizdev@wso2.com

§  Asanka Abeysinghe

§  Blog : http://asanka.abeysinghe.org

§  Twitter : @asankama

41

lean . enterprise . middleware