menu
When branch offices go awry: Detecting and fixing application and network performance issues made easy « US English

When branch offices go awry: Detecting and fixing application and network performance issues made easy

SHARE ON:

Branch OfficeWhat if you could predict when something goes wrong with your apps or the network and then fix it before it happens? It's probably not possible but how about getting close?

The best way to accomplish this is to have complete visibility of what's going on with your users, apps, and the network. But how and what can you really fix that might be broken?

One of the exciting things about Riverbed's Application Performance Platform is that you have choices depending on your needs and the complexity of your environment. 

Let's take a quick look at one example that we'll call "Branch Offices Gone Awry."

Branch Offices Gone Awry

When IT staff get swamped with an app or network issue reported by remote staff at branch offices across the enterprise, they typically scramble to fix these issues as they become more and more crucial because downtime and slow time have a direct impact on the business bottom line. Not only are users impacted in the branch but the helpdesk gets overwhelmed. Here are three steps to mitigate any Branch Offices Gone Awry scenarios.

Step 1—Get the Visibility You Need

In this scenario, your IT department has invested in SteelHead™ WAN optimization and has asked that the staff responsible for the deployment make sure they're getting the most out of them. As we're focusing on branch offices in this scenario, consider that they could be retail stores, delivery terminals, financial institutions, ticketing agents, coffee shops, you name it.

Regardless of the case, you'll want to know the number of branch office users, what apps they are running, and the throughput of each app with its effect on the total bandwidth consumption of your WAN link.

In general, you'll have the ability to capture the flow data from the branch with NetFlow and other sources but in this case, SteelFlow from your SteelHead deployment provides deep packet inspection (DPI) data of ports, protocols, AND the apps running across the network from the WAN. 

Here's an example of how this looks in a SteelCentral™ NetProfiler dashboard:

Deep Packet Inspection

At any time, you can also download the packets from continuous packet capture on your SteelHeads to do even further investigation.

Step 2—Set Policies for Events to Address

Here's what makes this scenario easier over time by setting policies for events to address. Use a solution that can learn when a critical performance measurements—such as link congestion—can affect the end-user experience in a branch office. This can make all the difference and you can be an IT hero. 

For example, using SteelCentral NetProfiler, you can set the tolerances as shown and be alerted when a measurement goes outside what is considered normal. In fact, you can get an email message so that you can know right away. This event provides that potential prediction indicating that degraded app and network performance in the branch is in your near future. See, we're coming close to what we said in the beginning.

Event Policy

When an issue is detected, it's now time to fix it. In this case, we'll consider a SteelHead QoS policy that makes sure that when throughput spikes, the mission critical apps in your branch office are getting the bandwidth they need.

Step 3—Fix the Issue with SteelHead QoS Policies

Here we see a breakdown of our business-critical apps running over Citrix as well as our critical web servers and our finance app. If we'd look at the other categories that are not business like in the Normal or Low Priority classes we'd see some of the recreational traffic shown in the first figure above—YouTube, Facebook, Amazon, and so on.

SteelHead QoS

Conclusion

With just a little investment in time and setting the policies for events in NetProfiler, we can affect the performance of our applications in our branch offices by fine tuning the detection and then addressing the issue. In other words, we have tamed the wild not only in the branch but also potentially at the Helpdesk by using the information to develop a QoS traffic shaping policy on our SteelHeads in the branches. We've come close to being able to head off poor performance as if we actually had accurate predictions, when in reality we just have good strategies for network and application visibility and the ability to act on what we see to keep our users happy.

Tweet: Detect and fix issues before end users notice .@Not2LateCapHill http://bit.ly/1EG0X7F

Further reading:

View Patrick T Campbell's profile on LinkedIn

 

 

top.name