The expansive architecture of the network often leads to its being implicated in application problems. Stuart Mark explains why network managers need to accept some responsibility.

Managing Applications from the Network

Network managers have traditionally been tasked with providing a stable network infrastructure on which to run user applications. This responsibility hasn’t changed but as network applications become more and more complex, it is increasingly the job of the network manager to monitor specific applications and, in many cases, explain their inability to meet user expectations, be it through lack of stability or poor performance.

This is because the continuing predominance of multi-tiered applications, where a single user transaction may involve communication with multiple servers, gateways or data sources, increases the chance of problems being experienced. Also, the growth of outsourcing and the widespread application of Service Level Agreements (SLA), both externally and internally, has raised user expectations of application performance.

Today’s network managers must be prepared, not only to resolve generic network deficiencies, but to diagnose the applications that use their infrastructures. There are a lot of tools that can make this task easier but tools alone won’t do the job; a change in working practice is almost always required.

From WORD to WEB

If you support a large infrastructure where applications are becoming complex, you may have to rethink your approach to network management, even leading to fresh investment in a more suitable network management product.

Today, it is not unusual for a single application to involve a large number of users, a web server, an application and file server, firewalls, gateways, a midrange device such as an RS6000 or AS400, a caching server, a DNS server, a mainframe connection and a number of databases. Some telephony products even communicate with PBX’s. All this is held together by various types of media and switch/routing devices carrying various network protocols.

Such a level of complexity demands the empowerment of the network manager through the correct tool but, like any tool, it must be used in proper context to provide real benefit.

Tools

Most networks have some form of network management. For small implementations, it may be an analyst with a network analyser, such as Sniffer, but larger sites tend to have a management product which will use Simple Network Management Protocol (SNMP) and/or Remote MONitoring (RMON) features to provide network health information. There are a lot of companies with network management products on offer, like Hewlett Packard/Agilent, Compuware and Netscout, who will tell you that their product caters for all your network (and sometimes even application) management requirements.

Beware though. While a lot a of products promise extensive management, they will typically be very expensive to implement across an enterprise and should not be treated as a panacea. Network management software on its own can never resolve every network and application issue and some careful consideration may end up saving you a lot of money.

Management strategy is key. It is a matter of balance between a tool and how it is used. Strategies can generally take three directions, the more expensive providing the best solution. Note that these are not mutually exclusive;

1. Use SNMP and/or RMON software to monitor status of network devices such as bridges, switches , routers and servers. You can monitor whether a device is up or down, if a network interface is up or down, the utilisation of a device or a connected LAN or WAN, error rates and vendor specific device information. Mini RMON will also allow trending through the collection of historical utilisation and error data while full RMON will provide remote packet capture and will help in identifying traffic flows by showing network conversations and protocol distribution. Note that full RMON agents are rarely provided with network devices; mini RMON is more common.

2. Install RMON software which will collect information from dedicated RMON probes at key points on the network. This better shows application traffic flows as full RMON capabilities are provided but, due to the high CPU required to process packets, these probes are expensive. You will be able to tell who is talking to who and how much data is being passed but not how efficient an application is or how it is performing. It’s also worth noting that this form of management is only as good as the number and position of probes. If you have a large network, you could easily spend a very large amount of money trying to achieve total visibility.

3. Install a management product that will use dedicated network probes to identify traffic flows between stations and report on utilisation per application, data volumes and response times. This is a relatively recent product evolution and has come about as a result of the need for application visibility on the network. As in option 2, this solution is only as good as the number of probes used and their position on the network and will be expensive to implement.

Most products will provide combinations of the functions listed and it is up to the network manager to decide what he needs. Option 1 provides almost no network application management while option 3 will give the best available today. Therefore, when evaluating products, the types of applications used and SLA’s in place will have a bearing on the decision process.

Using People AND Tools

When an IT business customer experiences a problem with an application on which they rely to do their job, they usually have no concept of its component parts, they just know that it isn’t working correctly. What may appear to a customer as a number of online forms or web pages with nice buttons and some swish graphics can conceal a level of complexity that requires the knowledge of many different IT disciplines to fully address.

Network analysts are concerned with layer 4 and below while software developers only look down to layer 4, so complex application problems can often be passed between support areas. If a network manager becomes involved in such an issue and no obvious network problems exist, he should be prepared to take ownership of the problem, identify the personnel with most knowledge of the application components, be it internal support staff or external suppliers and provide a forum where these people can meet and discuss the problem in detail. Finger pointing must always be avoided.

All applications should be mapped and baselined. Don’t wait for a problem to do this. Where are the users, what servers are used, where are they, what is the data flow? A network management tool may help in baselining but only from a network perspective; it can never correlate user transactions to network conversation. Ask a user to describe and carry out key functions and time each one manually. Cross reference this to the network baseline so that when a user calls to say the ‘Process Z5’ function is slow, you can reference the baseline information and decide whether you have a perception issue or a real problem. Application familiarity is key to solving problems. A user’s view of an application is very different to a network analyst’s.

Try to think in terms of services rather than separate components; if a wide area connection goes down, what application are affected? Some management products can help with this.

When diagnosing a problem, work on a process of elimination. Use your probes or analyser to identify a fault area, Slow PC? Slow server? High Network Latency? Work with the customer and other support people in doing this and, if the fault exists in software or an end node, try to retain involvement as long as is feasibly possible to lengthen the sense of teamwork.

Finally, network management is a science in itself and can easily become as complex as the applications and infrastructures it is intended to manage. Consider this when designing your network. Ask yourself what level of management you want to achieve and then place network resources accordingly. A single, powerful probe can monitor all traffic to and from a server farm but many more are required if the same servers are spread across an infrastructure. An application may have the Application Response Monitor API (ARM-API) embedded which could improve its performance visibility. Plan your management in as much detail as your network.

http://www.aprisma.com/

http://www.compuware.com/

http://www.openview.hp.com/

http://www.netscout.com/

http://www.tertio.com/

Summary

• Network management software is evolving to address application complexity.

• Most application management solutions rely on dedicated network probes to collect data.

• Use your management tool wisely and act on the information it provides.

• Understand your application architectures.

• Effective application management requires a collaborative environment.