Consolidation, integration, refactoring, and migration are some of today's popular data center catchwords. All of these words reflect some kind of renewal or replacement process--the old is either substantially modified or thrown in the garbage and replaced with the new. However, in many cases, we are often stuck with old equipment and software. We must continue to extract more services from aging infrastructure and still make reasonable claim to them being manageable.
Java Dynamic Management Kit (JDMK) is a framework for the creation of Java-based management software and legacy SNMP-based systems. It extends Java Management Extensions (JMX), which allows instrumented applications to remotely monitor resources throughout the network.
One of the files I'll use contains a list of managed objects, which can be referenced by JDMK code. The following listing is an excerpt from a generated Java file, called RFC1213_MIBOidTable.java (available in the sample code, in the Resources section below). This file is generated with reference to a specified standard MIB file.
The symbols in each
//Metadata definitions for managed objects of interest new SnmpOidRecord("ifInOctets", "18.104.22.168.22.214.171.124.1.10", "C"), new SnmpOidRecord("ifLastChange", "126.96.36.199.188.8.131.52.1.9", "T"), new SnmpOidRecord("ifOperStatus", "184.108.40.206.220.127.116.11.1.8", "I"),
SnmpOidRecordcan be directly accessed by network management software. This is our interface into the managed network devices.
Later, I'll look at ways in which JDMK can provide something of a management makeover for legacy devices. As we'll see, it's reasonably easy and inexpensive to produce entry-level management tools. Such tools may even help IT managers to gain a deeper understanding of the dynamics of their networks and the services that sit on top of them.
One other take-away for readers is the use of the adapter pattern as a means of accessing the JDMK API. This increases the level of abstraction in the way we use the standard APIs.
Imagine you've just been promoted to network manager with a staff of two. You're now responsible for all of the computing devices on a site with 200 people spread across four departments. Part of the task is also connection the corporate WAN, telephony system support, PC upgrades, application deployment, server support, etc. Basically, you've got to concentrate on everything!
Let's assume Figure 1 is the hypothetical network for which you've become responsible.
Figure 1. An enterprise network
In Figure 1, we see a schematic diagram of a single building with three floors. The devices on each floor are connected into a switch--in many cases, these individual links will each have bandwidth of 10Mbps and terminate in a wiring closet (not shown). The switches in turn are connected (via Links 1, 2, and 3) to a floor-level switch (F1 for floor 1, F2 for floor 2, and F3 for floor 3). In turn, each floor-level switch is connected by a high-speed link to a core switch. The latter might then be connected to a WAN link or a service provider network.
Looking at Figure 1, we can immediately discern some possible problem areas. The following items represent single points of failure:
Remember that a network is only ever as strong as its weakest link--this means that our network is vulnerable. It's the job of the network designer to try to balance service continuity against the cost of providing redundancy. In Figure 1, there are some weak points that might profit from a review! I'll focus on these by writing some JDMK code to help us see when problems have occurred and when problems might be just about to occur.
An important requirement in any IT manager's job is identifying the weak points in the network. This involves a careful combination of talking to your users and your predecessor (if possible) and instigating data collection. Every network has its very own folklore! Certain network links may periodically become overloaded; one or two routers or switches may be a little flaky; a server may be past its sell-by date, etc.
A considerate predecessor might well pass on such vital information to you as you embark on your new job. Let's assume your predecessor is a kindly soul who wants to help you make an orderly transition into your new role. Further, let's assume that she tells you to "Watch out for Link 1--it tends to become congested, and the folks on Floor 1 get a little angsty." This is important insider know-how, and we'll put it to use in the Java code later on.
In many cases, networks are held together by a fragile combination of scripts and insider know-how. What I hope to show in this article is that it is pretty straightforward to produce some JDMK tools that will assist you in holding your own against the network you manage. There is, of course, no real substitute for a well-designed and well-maintained network, but even in this rare case, our Java tools might provide some assistance.
HP OpenView Network Node Manager (NNM) provides a widely used application that is found in both enterprise and service provider networks. It provides some useful features, including automatic discovery and mapping of network devices, receipt of notification messages, and the ability to add your own proprietary software. In short, NNM provides a GUI that allows you to see your network. If NNM is available to you, then it may prove invaluable in discovering and monitoring your network. If not, then don't despair!
The key to effective IT management is selective use of automated tools. If you have access to high-end application software, then use it. As we move into an era of autonomic computing, it will increasingly be the case that systems and software will execute some or all of their own management. Get aboard this bandwagon early by maximizing your use of software solutions in your IT management tasks!
Using JDMK, we can create software that both listens for events and pro-actively reads device status. In this article, I'll be focusing on the latter, just to illustrate the principles.
To begin with, I'll write a simple program that looks at a specific network link and tries to determine if it's prone to congestion. We do this by sampling and averaging some SNMP counters on an interface at one end of this link. These are standard objects that are maintained by the SNMP entity running on the device. Sometimes, the SNMP entity is not running by default--in this case, I'll assume the network manager (i.e., your predecessor!) has chosen to run SNMP on all of those devices where it is available. Let's now describe the simple requirements for the code.
We want to create some software that fulfils the following simple requirements:
An interface usually has an administrative state and an operational state. The administrative state is the one desired by the network manager; i.e., "I want this interface to be up." The operational state is the actual state of the interface. Try to think about the operational state as the network's response to the requested state. If the administrative state is up and the operational state is down, then we know there's a problem.
The interface type I'll be using is Ethernet, specifically 10Mbps (or 10,000,000bps). I'll be retrieving a snapshot of the count of incoming bits received at an interface at one end of Link 1 in Figure 1. This will give us an instantaneous picture of the inward traffic level at that interface. Then, we'll wait a bit and retrieve the same counter value. The difference between these two values gives us the required utilization value. Let's have a look at some source code now.
The Java class I use is called
RequestData. It contains a
main() method and makes use of the following JDMK resources (among others):
import com.sun.management.snmp.SnmpDefinitions; import com.sun.management.snmp.SnmpOid; import com.sun.management.snmp.SnmpVarBindList; import com.sun.management.snmp.manager.SnmpPeer;
To begin with, I initialize the SNMP Manager API. This allows us to access the generated table mentioned in the introduction.
final SnmpOidTableSupport oidTable = new RFC1213_MIBOidTable(); SnmpOid.setSnmpOidTable(oidTable);
Next, I create an
SnmpPeer object. This represents the entity with which we will communicate. Note that this uses the port passed in as a command-line parameter.
final SnmpPeer agent = new SnmpPeer(host, Integer.parseInt(port));
We must now create a communications session with the remote entity. This requires us to specify SNMP community strings. These data elements are then associated with the agent.
final SnmpParameters params = new SnmpParameters("public", "private"); agent.setParams(params);
We're nearly there! We now have to build the session to manage the data request and then we're ready to create the data request list (or variable binding list).
final SnmpSession session = new SnmpSession("SyncManager session"); session.setDefaultPeer(agent); final SnmpVarBindList list = new SnmpVarBindList( "SyncManager varbind list");
The program is a single JDMK class that builds an SNMP request message. This message specifies four objects of interest, using the following code:
// A description of the host device list.addVarBind("sysDescr.0"); // The operational state of interface 1 list.addVarBind("ifOperStatus.1"); // The number of incoming octets on interface 1 list.addVarBind("ifInOctets.1"); // The speed of interface 1 list.addVarBind("ifSpeed.1");
Our four required objects are packed into an SNMP
getRequest message and sent to the receiving entity as follows:
SnmpRequest request = session.snmpGetRequest(null, list);
We now retrieve the same set of objects twice; the difference in time between the samples is found using this Java code:
// Calculate the time between messages long oldTime = date1.getTime(); long newTime = new Date().getTime(); long elapsed = (newTime - oldTime) / MS_DIVIDEND; println("Elapsed time in seconds " + elapsed);
In this section, we get the most recent time and subtract a time value recorded just before the first retrieval. This gives us a rough estimate of the elapsed time between the data samples.
When the returned data is displayed, we see the following major elements:
Value : 25625, Object ID : 18.104.22.168.22.214.171.124.1.5.1 (Syntax : Gauge32) Value : 10000000 >> Press Enter to resend the request. Elapsed time in seconds 16 Value : 26005, Object ID : 126.96.36.199.188.8.131.52.1.5.1 (Syntax : Gauge32) Value : 10000000
The three bold data items above represent the two values of the
ifInOctets object taken at an interval of 16 seconds. The selected interface (which supports a speed of 10,000,000bps) has received 25625 octets (or bytes) at the time
T1 and 26005 octets at the time
T2. To determine the incoming link utilization, we apply the following formula:
Incoming Link % Utilization = ((T2 octets - T1 octets) * 8 * 100) / (ifSpeed * Sample speed)
Plugging in the values above gives us a utilization of (26005 - 25625) * 8 * 100/(10,000,000 * 16), or 0.0019 percent.
Clearly, the interface is very lightly loaded on the incoming side! A similar measurement can be made for the outgoing direction (using the
ifOutOctets object instead). Then, both values can be summed to determine the overall loading. Obviously, care is required in drawing any conclusions from the figures (they are instantaneous snapshots of data that can change rapidly), but they do provide some minimal level of understanding of the loading on the interface.
Plying this program with diligence and observing loading trends over a period of a day might lead us to understand why the outgoing network manager made the comment concerning Link 1. In any case, it means that you are beginning to learn about the secrets that the network holds in store! Extending this approach to other regions of the network should help in acquiring a broader understanding again.
To run the example program, you'll need to install JDMK. Free evaluation copies can be downloaded from Sun Microsystems, though these copies expire after 90 days. So don't be too leisurely about running this code! Alternatively, if you win a couple of lotteries, you might be tempted to purchase JDMK.
In either case, just follow the instructions in the examples\current\Snmp\Manager\ReadMe file and the example should compile and run successfully. I used JDMK version 5.1. Also, there's detail and further Java examples in my book, Network Management, MIBs & MPLS: Principles, Design & Implementation--no lottery win required!
I strongly encourage using the adapter pattern to hide the complexity of the JDMK API. Really, JDMK isn't complex per se, but it is proprietary. For this reason, it's important to not litter your application code with calls into such an API. The adapter provides a useful model for achieving this noble design aim.
The adapter serves to insulate the application code from the details of the JDMK (or other) technology. Your code then calls into the adapter, rather than directly using the JDMK interface. So, if you later decide to change from JDMK and use another technology, any required changes to your code will have been minimized ahead of time.
Further details on the adapter pattern and its applications can be found in design pattern books, such as O'Reilly's Head First Design Patterns.
Supporting legacy systems and equipment is difficult and unforgiving, particularly as IT budgets and staffing levels are squeezed. However, nothing is too much of a challenge for a game Java developer! Using some simple concepts from network management and SNMP, it's possible to quickly create some quite powerful JDMK-based software tools. These tools can be used to keep an eye on troublesome corners of your network, while you get on with more interesting tasks. They might also help you troubleshoot in times of difficulty.
I've barely scratched the surface of what's possible with JDMK: you can employ notifications, create your own agents as well as managers, use browsers to access the management infrastructure, etc. However, perhaps more importantly, what we have seen on the one hand is the conceptual simplicity of network management, and on the other the potentially boundless complexity of running a network. Both endeavors must meet at a common boundary, and JDMK provides a fertile ground for this.
Stephen B. Morris is an independent writer/consultant based in Ireland.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.