© 2009 IBM Corporation Capacity Management, Demand Management, and Performance Engineering...

© 2009 IBM Corporation

Capacity Management, Demand Management, and Performance Engineering Integration

Ann Dowling

[email protected]

IT Optimization and Service Management

2

The Capacity Management Process is comprised of six key Activities.

Establish Capacity Management Framework: Based on the business and IT strategy and the architectural models, guidelines and a framework for capacity management will be developed.

Model and Size Capacity Requirements: – Modeling involves performance and capacity prediction through estimation, trend analysis,

analytical modeling, simulation modeling and benchmarking. Application sizing is a technique that predicts the capacity solution required to meet service level requirements for response times, throughput, and batch elapsed times.

Monitor, Analyze, and Report Capacity Usage: – Monitors should be established on all the components and for each of the services. The data

should be analyzed using, wherever possible, expert systems to compare usage levels against thresholds. The results of the analysis should be included in reports, and recommendations made as appropriate.

Supervise Tuning and Capacity Delivery: – Outputs from monitoring, analyzing, and reporting activities are examined and actions to tune

individual resources or to re-balance the available capacity are planned and initiated through Change and Release Management.

Produce and Maintain Capacity Plan: – The objective of this activity is to develop, maintain, test and revise alternative approaches in

satisfying various enterprise-shared resource requirements. It delivers the capacity plan that addresses the customer's resource requirements.

Evaluate Capacity Management Process Performance: Measurements include the definition, collection of measurements, analysis, review and reporting for Capacity Management.

Managing

the

Process

Managing

the

Process

Executing the

Process

Executing the

Process


3

There are three sub-processes that comprise the ITIL® Capacity Management process. Each uses the primary activities of the process decomposition in differing ways, to differing stakeholders, to differing end results.

Business Capacity Management (BCM) translates business needs and plans into requirements for service and

IT infrastructure, ensuring that the future business requirements for IT services are quantified, designed, planned and implemented in a timely fashion

Service Capacity Management (SCM) management, control and prediction of the end-to-end performance and

capacity of the live, operational IT services usage and workloads

Component Capacity Management (CCM) management, control and prediction of the performance, utilization and

capacity of individual IT technology components

"ITIL ® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office"


4

Elements of Demand Management are the main source of business demand that Capacity Management uses to develop capacity forecasts and solutions.

Excerpted from “Service economics” chapter of itSMF publication for ITIL® V3 core documents, 2008-12-15.

Conceptual View

Note: IBM provides additional process guidance supporting Demand Management and other ITIL processes.• IBM Tivoli Unified Process (ITUP)

Business processes are the primary source of demand for services.

Patterns of business activity (PBA) influence the demand patterns seen by the service providers (Figure5.23)

It is very important to study the customer’s business to identify, analyse and codify such patterns to provide sufficient basis for Capacity Management.

Visualize the customer’s business activity and plans in terms of the demand for supporting services


5

And…add ITIL V3 Service Strategy Demand Management for ‘sense and respond’ alignment with client Business Transformation

ITIL® Demand Management Key Activities:

Establish Demand Management framework

Value and classify business demands

Consolidate business demand patterns and forecasts

Forecast service demand

Identify and plan demand management initiatives

Assess and report demand management outcomes

Evaluate demand management performance

Capacity Management translates demand through to the component level.


6

Several tasks in the Demand Management process need to be driven by the Capacity Management team in order to initiate progress toward improved capacity requirements and forecasts.

Demand Mgmt. Key Activity

Demand Mgmt. Task

Relationship with Capacity Management

Note: This is a minimal subset to provide input to Capacity Management for Demand Management

Value and Classify Business Demands

Identify and Analyze Business Demand Streams and Demand

Work with business areas to gather business demand information, analyze types of demand in business terms and obtain trend of the demand - For customers of IT, internal and external

Forecast Service Demand

Create Business Demand Forecasts

Work with business areas to create forecasts of business demand for major business areas

Assess & Report Demand Mgt.

Identify Service Demand Baselines

Determine existing baselines for service demand. for given business areas


Translate Service Demand to Service Consumption Units

Convert service demand into service consumption units for the business areas


Translate Business Demands to Service Demands

Take business demand data and results and identify demand for specific IT services


Create Service Demand Forecasts

Take the Service Demands and create forecast for the required IT services (input to “Model and Size Capacity Requirements” and “Produce and Maintain Capacity Plan”


7

IBM leverages its Performance Engineering and Management Method (PEMM) for its engagements.

PEMM was first outlined in 1998 in an IBM internal white paper, as a comprehensive approach to addressing performance throughout the lifecycle of a custom application development (CAD) project.

It was developed into a comprehensive method with full elaboration of the eight major Themes, supporting Work Products, exploration of the Role of the Performance Architect and the mult-disciplinary Performance Engineering Team

In addition to the traditional disciplines of performance testing and performance/capacity planning and management, PEMM stresses the need for proactive performance engineering tasks which should be taking place during earlier project phases (i.e. requirements, architecture, design & development) and managing the scalability, capacity and performance in the production environment.

PEMM is the basis of an internal IBM course on “Architecting for Performance” that is included in the education roadmap for the IBM Architect Profession.

PEMM has been customized by IBM on multiple engagements across several industries, including several large Insurance industry clients.

The three dimensions of Performance Engineering:• The project Phases and deliverables dimension defined in your project development

standards• The People dimension in which you build and maintain your relationships with other key

members of the project and within the Performance Engineering team itself.• The Themes dimension in which you maintain and drive forward the longer conceptual

threads of activity needed to help you achieve your objectives.

THEMES

PHASES

PE

OP

LE


8

The PEMM themes apply across the life cycle and produce a set of outputs also shared and refined throughout the life cycle. PEMM directly maps to YOUR life cycle and beyond into Introduction and Deployment.

Software Development Life Cycle

Startup DeploymentSolution

CloseSolution OutlineMacro Design

Micro Design

BuildSolution Requirements

Volumetrics

Performance Estimation and Modeling

Performance Testing and Validation

Live Monitoring and Capacity Management

Technology Research

Ou

tpu

ts

Requirements and Early Design

Design, Development, and Tracking

Risk and Performance Management

performance engineering activities completed in the earliest part of the project to ensure performance and capacity requirements are well-defined and assessed at the outset

analyzing the quantitative (volumes) factors, both business and technical, that will effect system performance

activities associated with predicting future performance behavior or capacity requirements of a system

PE Strategy Non-Functional

Requirements Business Volumetrics PE Risk Assessment

and Containment Plan

investigation required to make estimation and modeling more accurate and fact-based

PE activities conducted during the development life cycle include supporting design and code reviews and establishing performance time or resource utilization budgets

test and assess the performance of the live solution, usually by an independent performance test team

manage performance and capacity of the deployed solution in production, using monitoring tools and processes and service level agreements

ensure risks related to performance and capacity are properly identified, assessed and addressed

PE Plan Performance Critical

Use Cases Technical Volumetrics Performance Budgets Performance Model

Application Profiles Capacity Sizing Monitoring Plan Performance Test

Cases

►Performance Engineering and Management Method

Measurement Specifications

Performance Analysis Results

Tuning Recommendations

Performance Service Levels Monitoring Thresholds/Alerts Implemented Tuning Capacity Plan Capacity Plan vs. Actual reports


9

Business

Service

Component

Integration points foster mutual awareness and collaboration between the Capacity Management process and Performance Engineering themes which mutually strengthens the overall effectiveness.

Capacity Management view as embodied in ITIL and IBM’s ITUP

(Service Management perspective)

Performance Engineering view as embodied in PEMM

(Solution Design and Delivery perspective)

Capacity Planning for a future system deployment

Capacity Management for a deployed system

Performance Engineering of a solution being developed and/or assembled

Performance Management of a solution being deployed

Model and size capacity

requirements

Monitor, Analyze and Report

Capacity Usage

Supervise Tuning and Capacity

Delivery Produce and maintain capacity

plan


Volumetrics

Estimation and

ModelingTechnolog

y Research

Design, Developmen

t and Tracking

Test Planning

and Execution

Live Production


10

The convergence of Capacity Management, Demand Management, and Performance Engineering (PEMM) provides a powerful and truly full life cycle methodology.

Demand Management

Patterns of Business Activity and Demand

Policies

Performance Engineering Risk Assessment Non-Functional Requirements

Performance Model

Capacity Management Information System &

Capacity Plan

Performance Engineering & Management Method(PEMM based)

Capacity Management Process(ITIL® based)

Feasibility Design Development Test Deploy Production Optimize

• IBM’s Performance Engineering & Management Method (PEMM)

• IT Infrastructure Library (ITIL®)


11

Model and Size Capacity Requirements


requirements


Capacity Usage


DeliveryProduce and

maintain capacity plan


Volumetrics

Estimation and

Modeling

Technology Research

Design, Development and Tracking

Test Planning and

Execution

Live Production


12

Model and Size Capacity Requirements

Modeling involves performance and capacity prediction through estimation, trend analysis, analytical modeling, simulation modeling and benchmarking. Modeling can be performed for all or any layer of the IT solution including the business, application and technology infrastructure.

Application sizing is a technique that predicts the service level requirements for response times, throughput, and batch elapsed times.

It also:• predicts resource consumption and cost implications for new or

changed applications

• predicts the effect on other interfacing applications.


13

Modeling involves one or more techniques must be selected when modeling workload behavior and associated resource requirements.

Modeling Objectives:

– Predict the behavior of IT Services under a given volume and variety of work using:• Pilot studies• Prototypes• Full scale benchmarks• Trend analysis• Analytical modeling• Simulation modeling• Baseline models

Like modeling and forecasting during a solution development project:

– No single technique can apply to all situations

– One or more techniques must be selected when modeling workload behavior and associated resource requirements


14

Application Sizing Objectives– Estimate resource requirements for new or changed application– To ensure it meets required service levels– Has to be an integral part of the applications lifecycle

Application sizing has a finite life-span– Initiated at Project Initiation stage for a new application– Major Change to an existing Application– It is performed at the beginning of the solution lifecycle and continues

through the development, testing and implementation phases. Service Levels defined

– During initial systems analysis and design– Enables use of pertinent technologies & products– Easier and less expensive to consider early in application lifecycle

Modelling can be used within Application Sizing Applies to Application Packages (COTS):

– Research similar customers & do benchmarks

Application Sizing has a strong correlation with Performance Engineering.


15

Forecast Accuracy

Co

st &

Tim

e

FullProduction

Test

AnalyticModel

SimulationModel

Testing +Simulation

ModelTesting +AnalyticModel

ScalabilityTesting

LinearExtrapolation

The Testing / Modeling Continuum is a guide to determining which forecasting technique should be used in a particular situation.

+/- 10~15% +/- 5~10%

Benchmark


16

Capacity modeling can be utilized to project the infrastructure requirements for any production or test based application.

Basic Capacity Planning (Scalability) Methodology Identify key workloads / transactions and develop a performance metric

collection strategy Collect performance and configuration data required to construct the models Create and calibrate the model to base system metrics Utilize the calibrated baseline model to project future business scenarios Analyze modeling results and identify application and infrastructure

requirements Create and deliver final report and softcopy performance models

Model Projections

0

20

40

60

80

100

100 150 200 250 300 350 400 450

Total Users

CPU

Util

izat

ion

(%)

0

5

10

15

20

Res

pons

e Ti

me

(sec

) Server1

Server2

Server3

Tran1

Tran2

Time in Seconds Application NetworkApp Transaction RespT ProcT NetT App Turns AppMsgs AppData NetPkts NetData

CTC 1a (Total) 0.27 0.08 0.19 11 13 18,835 44 25,598CTC 4b (Total) 2.49 2.47 0.01 91 92 274,854 522 348,122CTC 7a (Total) 3.04 3.02 0.03 23 25 284,361 493 333,321CTC 8a (Total) 4.70 4.67 0.02 23 25 284,945 495 336,933CTC 11b (Total) 1.41 1.36 0.01 132 136 183,193 440 245,781Dealer KPI 15a (Total) 0.06 0.06 0.00 11 16 11,825 26 13,259Dealer KPI 21a (Total) 3.16 3.14 0.02 775 863 242,527 1,034 298,943Dealer KPI 22a (Total) 0.19 0.17 0.02 75 198 264,036 447 288,924Dealer KPI 29a (Total) 1.87 1.84 0.03 3,905 3,924 184,708 3,933 397,158SAS Enterprise Guide 34b (Total) 38.97 38.53 0.44 1,312 2,621 878,389 4,010 1,104,002SAS Enterprise Guide 39a (Total) 276.00 275.16 0.84 2,032 4,019 827,170 5,605 1,145,303SAS Enterprise Guide 45a (Total) 1.61 1.45 0.16 438 878 250,614 1,297 324,043SAS Enterprise Guide 51a (Total) 238.07 237.72 0.34 530 1,045 272,794 1,526 360,396VPIPE 54a (Total) 0.19 0.19 0.00 29 31 6,220 36 8,208VPIPE 57a (Total) 4.06 4.06 0.00 5 8 4,909 13 5,641VPIPE 59a (Total) 30.32 30.32 0.01 109 121 58,588 161 67,522VPIPE 61a (Total) 106.41 105.73 0.67 16,928 16,959 7,528,632 20,739 8,671,263DRBA 67a (Total) 0.14 0.14 0.00 3 4 3,875 7 4,265DRBA 71a (Total) 139.43 139.23 0.19 3 4 3,579 9 4,089DRBA 75a (Total) 7.49 7.49 0.00 3 4 544 7 940DRBA 79a (Total) 0.95 0.95 0.00 3 6 4,909 13 5,641

Time in Seconds Application NetworkApp Transaction RespT ProcT NetT App Turns AppMsgs AppData NetPkts NetData

CTC 1a (Total) 0.27 0.08 0.19 11 13 18,835 44 25,598CTC 4b (Total) 2.49 2.47 0.01 91 92 274,854 522 348,122CTC 7a (Total) 3.04 3.02 0.03 23 25 284,361 493 333,321CTC 8a (Total) 4.70 4.67 0.02 23 25 284,945 495 336,933CTC 11b (Total) 1.41 1.36 0.01 132 136 183,193 440 245,781Dealer KPI 15a (Total) 0.06 0.06 0.00 11 16 11,825 26 13,259Dealer KPI 21a (Total) 3.16 3.14 0.02 775 863 242,527 1,034 298,943Dealer KPI 22a (Total) 0.19 0.17 0.02 75 198 264,036 447 288,924Dealer KPI 29a (Total) 1.87 1.84 0.03 3,905 3,924 184,708 3,933 397,158SAS Enterprise Guide 34b (Total) 38.97 38.53 0.44 1,312 2,621 878,389 4,010 1,104,002SAS Enterprise Guide 39a (Total) 276.00 275.16 0.84 2,032 4,019 827,170 5,605 1,145,303SAS Enterprise Guide 45a (Total) 1.61 1.45 0.16 438 878 250,614 1,297 324,043SAS Enterprise Guide 51a (Total) 238.07 237.72 0.34 530 1,045 272,794 1,526 360,396VPIPE 54a (Total) 0.19 0.19 0.00 29 31 6,220 36 8,208VPIPE 57a (Total) 4.06 4.06 0.00 5 8 4,909 13 5,641VPIPE 59a (Total) 30.32 30.32 0.01 109 121 58,588 161 67,522VPIPE 61a (Total) 106.41 105.73 0.67 16,928 16,959 7,528,632 20,739 8,671,263DRBA 67a (Total) 0.14 0.14 0.00 3 4 3,875 7 4,265DRBA 71a (Total) 139.43 139.23 0.19 3 4 3,579 9 4,089DRBA 75a (Total) 7.49 7.49 0.00 3 4 544 7 940DRBA 79a (Total) 0.95 0.95 0.00 3 6 4,909 13 5,641


17

Monitor, Analyze, and Report Capacity Usage


requirements


Capacity Usage


DeliveryProduce and



Volumetrics

Estimation and

Modeling

Technology Research


Test Planning and

Execution

Live Production


18

Monitor, Analyze, and Report Capacity Usage

Monitors should be established on all the components and for each of the services.

The data should be analyzed using, wherever possible, expert systems to compare usage levels against thresholds.

The results of the analysis should be included in reports, and recommendations made as appropriate.

There is a fundamental level of data collection and reporting necessary in any environment before capacity and performance services can be established.

Monitors and Data Collection and Reporting suites might be required at many levels, including but not limited to, the operating system, the database, the transaction processor, middleware, network, Web Services, and end-to-end (user) experience.


19

Objectives of Monitoring and Analysis

Monitoring objectives:Measure the utilization of each resource and service on an on-going basis to ensure:

– the optimum use of the hardware and software resources– that all agreed service levels can be achieved– that business volumes are as expected

Analysis objectives:Identify trends from which the normal utilization and service level, or baseline, can be establishes

Identify exception conditions in the utilization of individual components or service thresholds by regular monitoring and comparison with the baseline thresholds

Identify and report breaches or near misses in the SLAs Predict future resource usage, or monitor predicted growth against actual business growth (plan vs. actual)


20

Several categories of monitoring are within the scope of the Capacity Management process.

Utilization MonitoringProcessor utilizationMemory utilizationPer cent processor per transaction

type IO rates (physical and buffer) and

device utilizationQueue lengthsDisk utilizationTransaction ratesResponse timesBatch durationDatabase usage Index usageHit ratesConcurrent user numbersNetwork traffic rates.

Response Monitoring Incorporating specific code within client and server

applications software (application instrumentation)Using ‘robotic scripted systems’ with terminal

emulation softwareUsing distributed agent monitoring softUsing specific passive monitoring systems

Durations for MonitoringReal-time (events)Historical

– Problem determination and root cause analysis

– Trend analysis

– Planning


21

Insesu

re Zon

e

Secu

re Zon

e

DM

Z

Ga

teway

We

bS

ervers

Voice

Service

sW

ebS

ervers

PartnerServices

VP

N

Customers

Émployees

Portal

Process Server

Service Registry

Application Servers

Integrated Service Management

InfrastructureServices

SecurityServices

Adapters

Connectors Adapters

Connectors

Existing Applications

Intranet

Rel. DB

Internet

Enterprise Service Bus

Agent

Composite ApplicationMonitoring & Management

Agent

Agent

Agent

Composite application monitoring and management offers end-to-end visibility within applications and infrastructure components.

Agent


22

Source: ITIL Service Design

© Crown Copyright 2007

According to ITIL, a CDB or CMIS is a cornerstone of a successful Capacity Management process.

The ITIL Capacity Management sub-processes are carried out across several key activities.


23

Data Collection begins with establishing a methodology for ensuring that data and measurement requirements are well understood and can be achieved.

Data collected must account for resource usage, accommodate forecasts, and provide for monitoring and tuning the system.

–Which tool(s) to use for data collection and reporting• Metric data – data repository• Non-metric data – document repository

–Frequency of collection and summarization• Detail, hourly, daily, weekly, monthly, quarterly• Peak vs. average

–View of data / information• Business, Application, or Project view• Service view• IT Component view • Location view

–Levels of detail• Shared vs. dedicated resources• Workload level (i.e., process id) vs. transaction level

The CMIS (Capacity Management Information System) repository will be the primary source of the system data needed for

forecasting.

Carefully designed categorization of data allows for flexibility in reporting and analysis from various views.


24

A diverse set of data and information can be compiled into a set of application profiles valuable as both inputs and outputs throughout the Capacity Management process.

Business data– Business transactions– Schedule of business events– Business drivers

Service data– Response Time service objectives / levels– Elapsed time, End time, Turnaround Time, Throughput– Maintenance windows

Technical data– CPU type, model, serial– available capacity (MIPS), memory (Central and

Expanded), channels, number of cps, speed of cps, weight

– Operating System, Subsystems

Financial data– Financial plans – IT budgets, including specific budgets for hw and sw

expenditure – external suppliers, for cost of new hw and sw upgrades

Utilization data– IT resource measurements by workload groupings

• CPU resource usage (utilization)• Storage usage (utilization)

Workload 123

Application abcNon-

metric and

metric data

Application or Workload Profiles provide the workload characterization:

Application behavior over time patterns, peaks

Aggregation or groupings Growth requirements, growth scenarios

A composite of all this information can be organized into a set of application or workload profiles.

Application xyz

Various analysis and reporting are also derived from use of the CDB or CMIS.


25

A common, standard set of resource usage data can be shared by performance, capacity, and usage-based show-back to forecast and manage IT demand.

Event Monitoring and Management • Alerts, Alarms• Thresholds

Short Term: performance bottleneck analysis(IT resource, application, process, or thread level)

• Problem determination• Root cause analysis

Long Term: Capacity Planning• Trending, plan vs. actual analysis • Forecasting• Sizing• Modeling, statistical regression

IT Accounting: usage-based chargeback • Pricing• Billing• Forecasting • Variance analysis

It is very important to determine which metrics to collect on an ongoing basis, with varying levels of detail applicable

to specific situations.

Raw Data from Agents

Time Range

It is crucial to map resource usage metrics to the

corresponding applications and business units

consuming the resource.

Metrics collected from various platforms, databases, sub-components and

applications address the entire range of scope – from immediate alerts and problem

determination to long term capacity planning and usage-based billing.

Consistent, standardized data collection is crucial to ensure that the metrics needed for performance monitoring, capacity planning (forecasting), and chargeback are readily available.


26

Supervise Tuning and Capacity Delivery


requirements


Capacity Usage


DeliveryProduce and



Volumetrics

Estimation and

Modeling

Technology Research


Test Planning and

Execution

Live Production


27


Outputs from monitoring, analyzing, and reporting activities are examined and actions to tune individual resources or to re-balance the available capacity are planned and initiated through Change and Release Management or through the Service Desk in the case of simple requests to other support groups or self-help for users.

Some recommendations might involve changes in the way that the users use the IT systems: – moving discretionary workloads to off-peak periods

– performing a business function using a more efficient IT service path

– balancing services

– changing concurrency levels

– adding or removing resources

The cycle then begins again, monitoring any changes made to ensure they have had a beneficial effect and collecting the data for the next day, week, or month.


28


Service and component tuning:– enables effective utilization of IT resources by identifying inefficient

performance, excess or insufficient capacity, and making recommendations for optimization. It can

– balances the need to maintain service while reducing capacity capability to reduce the cost of service.

Understanding the combined performance impact of various components within a complex infrastructure is needed to accurately differentiate symptoms from actual problems. This level of understanding provides the most accurate baseline for future planning.


29

Various techniques can be used for tuning.

Tuning objectives: Identify areas of the configuration that could be tuned to better utilize the

system resource or improve the performance of the particular service

Implementation objectives: Introduce to the live operation services any changes that have been identified

by the monitoring, analysis and tuning activities

Tuning techniques that are of assistance include: Balancing workloads and traffic – transactions may arrive at the host or server at a

particular gateway, depending on where the transaction was initiated; balancing the ratio of initiation points to gateways can provide tuning benefits

Balancing disk traffic – storing data on disk efficiently and strategically, e.g. striping data across many spindles may reduce data contention

Database locking strategy - definition of an accepted locking strategy that specifies when locks are necessary and the appropriate level, e.g. database, page, file, record and row – delaying the lock until an update is necessary may provide benefits

Efficient use of memory – may include looking to utilize more or less memory, depending on the circumstances


30

Produce and Maintain Capacity Plan


requirements


Capacity Usage


DeliveryProduce and



Volumetrics

Estimation and

Modeling

Technology Research


Test Planning and

Execution

Live Production


31

Produce and Maintain Capacity PlanThe objective of this activity is to develop, maintain, test/model and revise alternative approaches in satisfying various enterprise-shared resource requirements.

• Inputs:–forecast assumptions–forecast projections–subject matter expert recommendations

•Controls:–financial constraints–hardware constraints–performance policies–resource standards and definitions–strategy and direction.

•Deliverables:–agreed capacity plan–alternative solutions–optimized resource solution


32

Forecasted resource requirements (demand) can provide quantified IT resource ‘volumetric’ input (load) to testing or modeling studies that analyze the impact of the projected IT resource load and exercise various solution alternatives to satisfy the demand.

Establish Baseline:Define Content and Scope Select representative time Period Determine Metrics to characterize Determine time Durations

Develop forecast requirements (demand):

Define objectives of forecastDetermine forecasting horizonSelect appropriate set of forecasting techniques Define growth scenarios• Conservative, Most-likely, Aggressive Quantify forecasted requirements (demand) into IT

resource requirements (load) over time

Conduct Testing / Modeling Studies:

Calibrate the baselineApply forecasted requirements (demand) against

baseline Analyze impact of forecasted IT resource

volumetrics (load) over time Exercise various solution alternativesDocument assumptions and risksRecommend conservation actions

Capacity Plan:Consolidate growth plans for all workloads• existing workloads • new applications, enhancements to applications • changes to the IT environment / infrastructure Recommend solutionsDocument associated approaches, assumptions, risks Track through plan vs. actual analysis


33

Capacity planning is needed to help evaluate existing and new applications, as well as changes in your business environment.

Capacity planning missionThe goal of the capacity planning process is to help ensure that sufficient cost-

effective capacity is available to meet existing service level commitments, as well as business and application growth requirements.

Each of the three major sources of growth must consider the impact of business growth expectations and planned business events.

ENVIRONMENTAL CHANGES

NEW APPLICATIONS

GROWTH IN EXISTING APPLICATIONS

BASELINE USAGE

Time

IT r

eso

urc

e u

sag

e

t t0 1


34

Composite views of IT resource estimates are developed based on the aggregation of the individual resource requirements.

All of the requirements are summarized, or subtotaled, to develop an aggregate or composite view of the overall, enterprise-wide resource requirements or demand

IT resource composite views can include:– Servers

– Storage

– Data Network

– Voice Network

– Middleware

– Database A composite view of IT resource requirements can be

analyzed at various levels of breakout and detail: – Locations

– Key applications/workloads

– Business functions

– Physical processors


35

Individual requirements are developed at a more detailed level that is typically based on a reasonable set of key applications/workloads.

Workload grouping assists in determining what level of detail provides an effective aggregation for a composite view that is reasonable and appropriate for the Capacity Plan.

Workload grouping: Defining key applications/workloads

– Top resource load Group or Aggregate like application/workloads

– Similar resource usage characteristics• By IT resource component: an application / workload could surface as ‘key’ in some

component areas and not in others– Similar growth characteristics: one or more of these factors can justify

aggregation:• Similar seasonal trends• Similar growth rates (monthly, annually)• Similar historical trends• Similar business drivers (estimation or correlation)• Similar impact from business events


36

Validation of forecasts must be done on a regular basis. One common approach is plan vs. actual analysis. If the actuals deviate significantly or consistently from the plan then investigation into the cause and possible adjustment to the forecast is necessary.

EXAMPLE ONLY2084-305 CECA Average Monthly MIPS Used and Forecasted by LPAR

Shift xxx: startday - endday (starttime - endtime timezone)

0

200

400

600

800

1000

1200

1400

1600

1800

2000

Month

MIP

S

MVSP MVSW DOFPDOFD WSS1 HRAPMVSZ MVSB PHYSICALMVSI DOFZ 80% - planning threshold (1586.4 MIPS)Total installed (1983 MIPS) ACTUALS


37

Once the source of the deviation from plan has been determined then the cause of the deviation must be investigated.

What forecasting technique was used ?– If business-driven, has the business driver

forecast changed ?

– If historical trend, has some change been introduced that was not known ?

– Is there an unplanned business event or project that has occurred and is potential impacting the workload ?

Is it possible to drill down further within the workload to further isolate the source of the deviation ?

– perhaps at the application level Are there any related problems that have been

reported, such as response time degradation, etc. ?

What measurements were used to quantify the baseline and the forecasts ?

What were the assumptions ?

What is the degree of risk/impact from this deviation ?

– Is a forecast adjustment necessary ? How do I adjust the forecast ?

– One time event only ?

– Seasonal adjustment ?

– Long term adjustment ? Why do I adjust the forecast ?

– What assumptions need to be modified ?

– Is a different forecasting technique more appropriate ?

What measurements do I have to quantify the necessary adjustments ?

Was the baseline valid or does it have some inherent problems or exceptions that need to be resolved ?

Without sufficient levels of data grouping, it can be very difficult to drill down to the probable source of the deviation and therefore difficult to determine the cause of the

deviation of actual to plan.


38

The convergence of Capacity Management, Demand Management, and Performance Engineering (PEMM) provides a powerful and truly full life cycle methodology.

Demand Management

Patterns of Business Activity and Demand

Policies

Performance Engineering Risk Assessment Non-Functional Requirements

Performance Model

Capacity Management Information System &

Capacity Plan

Performance Engineering & Management Method(PEMM based)

Capacity Management Process(ITIL® based)

Feasibility Design Development Test Deploy Production Optimize

• IBM’s Performance Engineering & Management Method (PEMM)

• IT Infrastructure Library (ITIL®)


39

Method / Process(Themes / Activities)

Long term elements of system design, development, and delivery that interact

with Performance Engineering

Organization People in the project that you need to work with to achieve your objectives

Phases & Work Products

(Data and Tools)

What the team needs to do or to produce in each phase

of the project.

Integrating work products into the existing phases or gates of the SDLC, project management, and other key business and service management processes helps to operationalize or institutionalize PE.

THEMES & ACTIVITIES

PHASES

PE

OP

LE


40

The role of the Performance Engineer or Performance Architect requires multi-faceted skills and responsibilities.

A person who carries out performance engineering duties and leads a Performance Engineering project or team is referred to as a Performance Engineer or Performance Architect.

Performance Engineering is most successful when it is carried out by a multi-disciplinary team representing the major business and technical stakeholders in a project or solution:– Requirements Analysts – Architects– Developers – Infrastructure and Application Engineers– Testers– Capacity Planners– Performance Analysts


41

© 2009 IBM Corporation Capacity Management, Demand Management, and Performance Engineering...

Documents

Transcript of © 2009 IBM Corporation Capacity Management, Demand Management, and Performance Engineering...