DX Operational Intelligence

An App-Centric Capacity Planning Approach

By Jeremy Rossbach posted 05-19-2015 08:32 AM

  

From the server rack to the storage array, the Internet of Things will stretch data center resources to the limit.  Find out how to maximize and manage capacity more effectively.

 

http://cainc.to/Jfl8yp

 

53577869-e1432028319454.jpeg

7 comments
0 views

Comments

06-04-2015 07:40 AM

Thank you to all who replied.  I appreciate the information and insight.

06-03-2015 01:57 PM

Keep in mind...You cannot model that which you cannot measure.

In production, APM solutions tell us workload throughput and response times, but does not necessarily give resource consumption per workload.

This is where correlation reporting is our friend!

As Rob states “a workload should be defined that correlates against a measured set of resource utilization“, but identifying that key workload that correlates to utilization can be a challenge. APM can gives us A LOT of workload data, but getting actionable information from the data in reports can be a challenge. By bringing APM data into the Capacity Management solution, we can start getting some actionable information. For example, Ade’s correlation workload reports where you can select different workloads and servers that are in the same groupings and see which workloads have the strongest correlation to the individual system, or the group. This analysis proves which workloads are driving the utilization, armed with this info we can use this workload as a natural forecasting unit for the groups' resource consumption.

 

I can see how that could be done and presented in a report. For example, the user could get a report of which workload in the group has the strongest correlation with the group’s servers usage. Then this workload can be set as the KPI for the group and a model would use that workload’s throughput as the input. Group level and system level reports can then include that KPI along with how it correlates to resource usage. Armed with this we can model to increases in the KPI to see impact workload change on resources. An assumption is that ratio of workloads associated with the KPI will remain constant.

>KIP

 

ommunityadmin@communities-mail.ca.com]

Sent: Wednesday, June 03, 2015 09:57

To: Lamb, Kip M

Subject: Re:  - An App-Centric Capacity Planning Approach

 

CA Communities <https://communities.ca.com/?et=blogs.comment.created>

 

 

An App-Centric Capacity Planning Approach

 

new comment by Robert Limbrey<https://communities.ca.com/people/limro02?et=blogs.comment.created> - View all comments on this blog post<https://communities.ca.com/community/ca-capacity-management/blog/2015/05/19/an-app-centric-capacity-planning-approach?et=blogs.comment.created#comment-233912440>

06-03-2015 12:55 PM

Good advice from Richard.  I would add to this..

 

  Be careful of how you define “workload”.  For capacity management purposes, a workload should be defined that correlates against a measured set of resource utilizations.  If you define your workloads too tightly, you may struggle to allocate the observed utilizations against your defined workloads.  On the other hand, if you define your workloads too loosely, then you may miss important time-related relationships.

  In general terms, I would suggest a ‘top-down’ approach to workload definition.  Ask yourself whether you can start with a single workload, measured by a single throughput metric (such as number of users).  If this doesn’t make sense – for example, you might have a ‘batch’ workload and an ‘online’ workload which are easily separated by time, then you can extend your model accordingly.  Another example of where you can extend to multiple workloads is if you have sufficiently granular data, which may be forthcoming from an APM tool perhaps.

06-03-2015 11:53 AM

There are two different ways to approach this problem:

  1. By component - this would include your tier-based approach (14 different tiers)
  2. By workload - where you state there are 12 major workloads

 

These two approach are consistent with ITIL's description of the Capacity Management sub-processes

  1. Component Capacity Management (this is your tier-based approach)
  2. Service capacity management (matches your workload approach)
  3. Business capacity management (you must have Component & Service before you get to this level)

 

2-STEP RECOMMENDATION:


Step 1 - Start with a tier-by-tier approach.

  • Pick a tier and determine three things:
    • Server inventory - what servers comprise the tier
    • Current resource footprint (e.g., CPU, memory, storage)
    • How much of the resource footprint is being used
  • Repeat for all tiers
  • This will be the start of a "profile" for your application.

 

The result of this step is a quantitative description and evaluation of each tier in your infrastructure.  This corresponds to ITIL's "Component Capacity Management".  In addition, this step is required before you start looking into the more detailed applications (workload).

 

Step 2 - Extend to a workload-level analysis

  • The initial tier-level analysis will give you a good understanding of the parts of your application.
  • This step drills down by looking at the applications (workloads) that utilize those tiers.
  • Pick one application (or workload)
    • Determine which tiers and servers support the application
    • If the tiers are shared, determine the proportion of resource usage used by your selected application.
  • Repeat for all workloads

 

The result of Step 2 is the start of an application profile. Note that we are extending the initial component-level analysis from Step 1.  You are effectively layering applications on top of your infrastructure components.  This is exactly where you want to be to start application-level capacity planning.

 

Make sense?

 

Richard

06-02-2015 11:25 AM


Based on the 80/20 rule there are twelve workloads.

06-02-2015 10:59 AM

How many workloads?

06-02-2015 06:44 AM

My application environment consists of fourteen (14) different tiers on eighty (80) different servers.  Would you recommend a tier-by-tier app-centric capacity planning approach?