Java DMK and Legacy IT Management
- An Unenviable Inheritance
- Getting Started
- Standard Applications May Help
- Creating Software to Ease the Management Task
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 code is either substantially modified or thrown in the garbage and replaced with the new code. 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 (Java DMK) 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 Java DMK code. The following listing is an excerpt from a generated Java file, called RFC1213_MIBOidTable.java. This file is generated with reference to a specified standard management information base (MIB) file.
//Metadata definitions for managed objects of interest
new SnmpOidRecord("ifInOctets", "1.3.6.1.2.1.2.2.1.10", "C"),
new SnmpOidRecord("ifLastChange", "1.3.6.1.2.1.2.2.1.9", "T"),
new SnmpOidRecord("ifOperStatus", "1.3.6.1.2.1.2.2.1.8", "I"),
The symbols in each SnmpOidRecord can be directly accessed by network management software. This is our interface into the managed network devices.
Later in the article, I’ll look at ways in which Java DMK can provide something of a management makeover for legacy devices. As you'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 is the use of the adapter pattern as a means of accessing the Java DMK API. This increases the level of abstraction in the way we use the standard APIs.
An Unenviable Inheritance
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, and so on. Basically, you need 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:
- Links 1, 2 or 3
- The links between the core switch and the floor-level switch
- The individual switches
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, some weak points might profit from a review! I’ll focus on these by writing some Java DMK code to help us see when problems have occurred and when problems might be just about to occur.