Series Introduction

This is part one of a five-part series focused on network capacity planning using IBM’s SevOne network observability solution. 

Over the coming weeks we will cover the following topics:

• Planning for capacity with TopN views (today's topic)
• Using projection trending (May 16)
• The value of histograms when planning for capacity (May 30)
• How are percentiles calculated, and what value do they provide? (June 13)
• Generating capacity reports using RIA Workflows (June 27)

The Importance of Network Capacity Planning

“Network bandwidth is like oxygen for the applications” – CIO Fortune 500 Financial Company

Adequate capacity is required to accommodate all of the traffic users generate over the course of the day.  As companies grow and expand and applications come and go, capacity requirements will change along with them.  It’s important for the network team to keep on top of these changing requirements so that they are not surprised by lack of available bandwidth.  Rather than guessing how much capacity is needed, capacity planners utilize past performance data in order to project their future needs. 

IBM’s SevOne network performance observability solution does an excellent job in collecting network metrics, keeping as-polled data for a year or more, providing network capacity planners with the granularity they need to identify resources that are good targets for capacity planning activities. 

The first SevOne capability we will review is “TopN Views”.  That is covered next.

Planning for Capacity with TopN Views

TopN Views provide useful summarized information highlighting which network interfaces are consuming the most (or least) network bandwidth, allowing the network capacity planner the ability to periodically review and then quickly spot targets for a more in-depth capacity analysis.  The industry standard indicators that are used are taken from the MIB-II interfaces tree which defines the metrics that are available across all network devices conforming to the RFC-1213 standard. 

In our example we will be interested in evaluating bi-directional interface bandwidth consumption using the following indicators:

• ifInOctets, ifHCInOctets for incoming traffic on an interface;
• ifOutOctets, ifHCOutOctets for outgoing traffic on an interface;
• ifSpeed to determine *speed of interface, useful for % utilization calculations

(* the interface speed max value may be overridden on a per interface/per metric basis to reflect contracted speed vs. physical max interface speed as needed)

Building Capacity-Focused TopN Views

While SevOne comes with an OOTB “Most Utilized Interfaces In & Out” view which is perfectly fine to provide average utilization values, there are a few things that I like to add to my TopN views to focus them more towards the capacity planning use case. 

1. I like to view TopN Interface bandwidth metrics using two TopN views – one for inbound traffic and another for outbound traffic.  The network is full-duplex, so I like to view all of my interface bandwidth data accordingly, separating in from out.
2. I like to create my capacity views adding percentiles measurements to them.  I’ll be covering percentiles more in a future series blog.  But essentially, percentiles allow me to see how much of the network bandwidth is being consumed 90 percent of the time, 95 percent of the time, and 99 percent of the time.  This is needed to “plan for the peaks” vs. looking at average utilization.
3. I include Max value, so I can see how high an interface’s bandwidth utilization actually got over the period.  This is useful to compare with the other percentile values to see how close they are to the Max value seen.

Generating TopN Reports

When generating TopN reports, I always do the following:

1. I want to generate my reports using “like” interfaces that are specified for a purpose, such as edge router WAN interfaces, data center head-end router interfaces, internet interfaces, etc.  You can create purpose-built interface groups within SevOne using RegEx expressions based on interface name, description, or metadata values associated with the interfaces.
2. I want to apply “Device Work Hours” filtering on the TopN views so that it filters out traffic from hours that I do not want to include in my capacity planning exercise, such as off-hours quiet times which would water down my utilization values.

3. I like to generate 90-day projections within my TopN views to I can see where my average utilization is likely to be.  This gives me runway time to get network upgrades approved and scheduled with my local engineering team and network carrier.

To demonstrate the impact of “Device Work Hours” on results, let’s take a look at an interface’s projected trend bandwidth utilization data using all data points, and then compare it with the same data, but filtering results using “Device Work Hours”:

• The chart below uses all data points in its projection.  Using all data points includes weekend data and off-hours “non-business hours” data which waters down the projection data, providing a poor result for capacity planners.

• The next chart uses “Device Work Hours” data points in its projection.  Using “Device Work Hours” data removes the non-Device Work Hours data points from our projection data, providing superior results for capacity planners!

Here’s the TopN View with “Device Work Hours” enabled.  Sorting by percentiles allows us to determine which interfaces we may want to perform additional analysis on. 

Looking at the data you might want to upgrade interface bandwidth when the 95^th percentile reaches 90% capacity, leaving 10% available for peak hours.  You might also take into consideration how close to saturated you reach using the 99^th percentile and Max value columns.

You can use multiple timespans to display past trends and current projected values.

Here are my TopN View widget settings:

Summary

I hope this blog is helpful in exposing some of the capacity planning insights that the TopN Views widget brings to light -- Displaying 90th, 95th, 99th percentiles along with peak values provides insight into how much bandwidth is currently being consumed during the business day, when having available bandwidth is most critical.  We also saw that using "Device Work Hours" is needed so that we don't water down our average and percentile values.  We discussed using multiple timespans so we can display past performance along with projecting into the future.

In the next blog, we will go into more details on using projection trending.

#TechnicalBlog