From black box to enterprise: management, JMX 1.1 style

[It168 technical article]This article studies the history of network management software and how it develops from the initial stage of crude software to the current complex and mature enterprise management system. He also studied the root causes of many common problems that plague these systems. And how to use JMX to solve them.

Java Management extension (JMX) is a popular Addition on the Java platform, it promises to provide scalable, low-cost, and compatible solutions for old problems related to enterprise network management. The new software server (including popular open source servers such as Jakarta Tomcat and JBoss) can quickly use JMX as its management standard. We will start our research on JMX by studying the history of network management software and how it develops.

Development of Network Management

Early bridges, protocol converters, and Routers
Is a simple dedicated hardware device, usually configured by directly connecting to the device's own serial port. Configuration commands are usually used to enable or disable ports, or to change the features of protocols supported by devices. These "Black Boxes
"The number of parameters can be configured is limited. The serial Terminal interface is usually" mysterious "and can only be understood by a large number of trained network operators, as shown in 1:

Figure 1. dedicated serial connection

　　

Private Network Period

As the network grows and the number of these "black boxes" surges, it is clear that some methods are needed to address and control these large numbers of network devices. Some vendors choose a separate out-of-band interconnect or concentrator network that provides for managing these devices, as shown in Figure 2:

　Figure 2. Out-of-band Multiplexing Control

　　

Other vendors use the in band technology, which sends addressing and control information on the same network running these black boxes, as shown in 3:

Figure 3. In-band Device Control and Management

　　

　
The client software (called the management console, which is inherited from similar names such as the terminal console) slowly develops from a "mysterious" terminal-style interface to an enhanced GUI.
Configuration tool, which allows you to separately configure each addressable device on the network. Therefore, an early Network Management System (NMS) was created ). To a large extent, the dedicated network protocol is at the control site during this period.
Early NMS typically used dedicated protocols to address, control, and monitor vendor devices.

　　TCP/IP becomes the actual networking standard

Then we entered the TCP/IP network era. Through the early evolution of the Internet, the TCP/IP protocol family has become the standard for global interconnection networks. Large enterprises discover that they need to connect to their separately developed and dedicated heterogeneous internal network islands (many of which come from different vendors around the world ), however, it does not lose control over all the devices in the enterprise.

In addition, more and more network black boxes will be maintained by infrastructure builders in their operations. This usually spans multiple network operation centers located in different geographic regions. Therefore, you need to manage, control, and monitor all these devices from a centralized location. The urgent needs from these two major user groups gave birth to the concept of early enterprise NMS.

During this period, the console (client) uses the latest graphics workstation and
Processing technology, usually including interactive map of the location of the managed device, and network mesh topology. By using a map or Gui
Click on a node in the Network Diagram. The network operations center staff can monitor the status of any specific device and change its settings and configurations. As a standard for heterogeneous network management, SNMP (Simple Network Management Protocol)
-A protocol completely designed for network management on TCP/IP networks has become more popular. Although, for practical and economic reasons, SNMP
However, the private network hardware vendor eventually adopted SNMP as an alternative for managing its connected devices.

PC and LAN revolution: Expanding Enterprise Management

Almost in the same time as the TCP/IP revolution, the number of offices equipped with PCs and LAN has exploded. This requires some enterprise NMS to take on the new scope: Management and Control of PC workstations, printers, peripherals and other LAN devices, as shown in Figure 4:

Figure 4. Add a PC and LAN device to the management mix

　　

　
Many vendors use their new capabilities as marketing advantages to drive their enterprise management systems or EMS (note that the word "network" is not emphasized ). During this period, leading suppliers provide business
The scale and complexity of EMS increase, but many suppliers' products still maintain a large number of dedicated code libraries and support all vendor-specific legacy systems. Existing Gui-based
Management Console (client) software has been repeatedly "transplanted" to many different versions of the emerging desktop operating system, which relaxed the restrictions, but increased the complexity of the underlying code library. The SNMP protocol has been extended to its limits to support new and different devices that were never considered during its design. As the number of managed network endpoints surge and exceeds the manageable level, value-added intelligent management assistance has become a standard in almost every commercial EMS.

Internet and electronic trading revolution: Add manageable software services to EMS

As the endpoints managed by EMS surge, the Internet revolution has impacted most EMS systems and architects. Suddenly, large networks that were once completely different were connected over the Internet, the customer requested that the "network" could be managed using the same user-friendly management console that they knew and liked (see figure 5 ).

With the emergence of various SMART network devices, PCs and peripheral devices, more and more intelligence is required in daily management and monitoring of these endpoints. In addition, the increasing demand for services over the Internet requires EMS to support a new endpoint: intelligent software servers/services.

For the new EMS system, it can access every database server, web server, application server, and ultra-high-capacity disk (Disk farm) of the enterprise all over the world) (new, high-intelligence, broadband, and adaptive ultra-large-capacity disks are now called storage area networks or San) all have management access rights, which is not surprising.

Figure 5. New EMS

　　

Requirements for Distributed Intelligence in managed networks

　
In today's EMS
In this age, intelligent management assistance is no longer an option but a necessity. This requirement is also required for dynamic networks that process Composition and topology changes frequently. In addition, the ability to adapt to and support any new and future devices
Is a clear requirement. However, these new EMS
It is also necessary to continue to support the mixture of old equipment, protocols and software and to work in concert with them, as customers have made huge investments in them during the difficult development process. In fact, the customer
The EMS client of Gui has a strong demand because of investment in training these complex tools. At the same time, new EMS users also require the latest web-based
To support remote management and monitoring.

With these new EMS systems, you can still enable and disable ports on the old "dumb" black box, but you just need to easily issue a command like this:

Automatically switch to the backup application server cluster and database server if necessary, so that 95% of the normal running time can be maintained in the next 24 hours; when a catastrophic fault occurs, send an alarm to the network operator via pager 808-555-1212.

In other words, when a network fault occurs in a typical application service provider (ASP) environment, you can also manage it with intelligent management assistance.

　
In the Internet age, what changes have been made to the software architecture and network protocols so that such complex network management can continue to function? In fact, the EMS we have already described
To a large extent, the case is still "A job in development ". JMX is a key step towards implementing general management of dynamic networks. It has full backward compatibility and is applicable to existing and old EMS.
Infrastructure support.

Use Java platform for Network Management

The Java platform has many features that make it a natural candidate for implementing complex network management solutions. These features include platform and OS independence, networking and dynamic adaptability.

Platform and OS independence

Because the Java platform is unrelated to OS, NMs developers no longer need to maintain a code library version for each combination of OS and hardware platforms. Instead, you can focus on a single code library to improve product functionality.

Networking

　
Unlike most other programming languages, networking is the core part of the Java platform. It is not an afterthought or third-party library, so you can be sure and guarantee that it is connected
Other components of the OS/hardware platform can collaborate well. This is important because earlier network management products often rely on third-party online libraries to meet the requirements of platforms/OS
Combinations cannot provide requirements, or achieve stability as a target.

Dynamic Adaptability

Network management software can easily use the ability to dynamically and securely load classes across networks. For example, the Java-based EMS can only "LOAD" its support modules across networks to support them, and can dynamically upgrade the software modules that implement intelligent network management as needed.

JMX: network management specifications

　
JMX is the result of extensive cooperation in the industry to create a set of specifications. It will describe the Scalable Architecture, APIs, and a group of Java
Programming languages are distributed services used for network management. As previously described in detail, it utilizes the network management capabilities of the Java platform. At the time of writing this article, the latest specification is Java
Managing extension tools and proxies V1.1 (Java Management extension instrumentation and agent)
Specification, V1.1 ).

Deliverables of JMX include a set of specifications, API documentation, Reference implementations and compatibility testing kits that comply with JMX specifications. For more information, see references.

　
The goal of JMX is to define JMX
The system interfaces in the architecture, rather than specifying implementation and policies when unnecessary. This idea is necessary to win support from vendors that have patent rights in existing network and service management technologies. It will make the new
JMX-based applications enjoy the maximum degree of freedom and flexibility in design ―
This avoids situations where the specified implementation and policies may not be suitable for future needs. In this way, the reference implementation only provides an example about how to satisfy a specified set of interfaces, without the recommended or recommended method.

JMX architecture and Operation Model

The architecture and operational model of JMX are designed to meet the following objectives:

Scalability: the ability of enterprises to manage tens of thousands of Management endpoints from a few devices or services to the Internet era.

Old system integration and compatibility: ability to collaborate with existing NMS or EMS solutions and old manageable endpoints that may not support JMX

Low-cost implementation: JMX compatibility can be easily designed into existing software products and devices without much design and coding work.

In the JMX architecture, a three-level distributed architecture is used to reduce the complexity of scalable network management. Figure 6 illustrates the three loosely coupled layers. They are:

　
Tool layer: In this layer, management endpoints (devices, software services, etc.) can be accessed through interfaces specified by JMX. This is a Java
Object implementation. These objects are called managedbean (mbean for short ). In the specification, endpoints that can be managed through these objects are called managed resources of JMX. By providing
The Java mbean package allows you to easily "adjust" old non-JMX devices and servers (such as SNMP-compatible devices or subnets) to manageable resources of JMX. JMX management resources on this layer can be designed completely independently of any other JMX architecture layer objects.

　
Proxy layer: This layer exposes the internal architecture of the JMX agent. A jmx agent is a software component that exposes a set of standardized proxy services to the remote management component and uses JMX
Mbean interfaces that can manage resources directly control these resources. In fact, mbeans can be managed by dynamically loading and unloading mbean servers in the JMX proxy. The interface for accessing the mbean server is specified by JMX. Value-added services (such as localized Intelligent Monitoring and automatic response) in large EMS systems can be implemented in the JMX architecture at this layer. Objects on other layers can be designed as proxies at this layer. The agent communicates with the management application through a connector or protocol adapter. However, the specifications used for these components are still in the development process.

　
Distributed service layer: In this layer, the target is the interface specified for the JMX Manager component. JMX manager can access the proxy or proxy group to manage
Resources that can be managed by JMX. Essentially, these are the interfaces that EMS application developers rely on for programming. The Manager component can be EMS.
An application or an intermediate intelligence layer that manages multiple proxies and related resources.

Figure 6. Layer 3 of the JMX Architecture

　　

　
Figure 6 illustrates the JMX objects on the three layers and the interfaces specified by JMX 1.1. Using object-oriented design and Java programming language, JMX
Each layer in the architecture is highly componentized and divided by well-defined interfaces. Write compliant code according to these well-defined interfaces to ensure that our tools and Agent logic are compatible with any
The JMX 1.1 Implementation is used together. Although the JMX 1.1 Specification specifies the tool and proxy layer, the distributed service layer is still within the scope of future specifications (see Figure 6
Is displayed as a horizontal gray dot line and a dot box on it ). Standard JMX interfaces of existing network management standards (including SNMP and CIM/WBEM) are being developed by other groups for synchronization.

Standard mbean vs. Dynamic mbean

The core of the tool layer is the mbean interface. The mbean interface specifies how to access attributes, how to call operations (similar to methods in Java programming language), and how to send events from mbean. Mbean has two main types, which are described in detail in table 1.

Table 1. Standard and dynamic mbean

Mbean type	Description
Standard mbean	All attributes, operations, and events associated with standard mbean are specified statically in their interfaces. They are fixed and do not change with time. Standard mbeans must comply with fixed encoding conventions (knownLexical Design ModeThe mbean specification specifies the management interface for encoding. For example, to use a standard mbean to use a class named Webserver, the management interface must be calledWebServerMBean. The JMX proxy usually uses "Introspection" to discover the management interfaces of standard mbeans.
Dynamic mbean	All dynamic mbeans are implementedjavax.management.DynamicMBeanInterface. UseDynamicMBean Interface, a group of attributes, operations, and events associated with mbean are determined at runtime. This satisfies manageable JMX with attributes, operations, and events that may change over time. Resource requirements (for example, the tool application server may have different release levels-Tomcat 4.1.4 and tomcat 4.1.5 ― Supports different attributes ). It is also naturally suitable for joint network technology tools such as Jini/Jiro.

Dynamic mbean specialization: Model and open mbean

There are two types of dynamic mbeans for special purposes, as shown in table 2:

Table 2. Model and open mbean

Mbean type	Description
Model mbean)	All JMX implementations must provide an mbean model instance-Implementationjavax.management.modelmbean.ModelMBeanInterface. It must be namedjavax.management.modelmbean.RequiredModelMBean . The model mbean provides "ready-made" mbean implementation, which you can use immediately to quickly use any JMX to manage resources. It is premade, universal, and dynamic Mbean class, which is provided as part of the reference implementation, already contains the implementation of all the necessary default behaviors-allows you to add or override the implementations that need to be customized during runtime. This makes Java and non-tool resources can provide compatible mbean virtual packages during runtime, so that they can be managed through the JMX architecture.
Open mbean)	Open mbean is a dynamic mbean. All mbean attributes belong to a group of specified Java data types (String,Integer,Float), And the bean uses a groupjavax.management.openmbean.*The interface provides self-describing data. Any proxy and any manager/EMS can easily manage the JMX resources provided by these beans. JMX 1.1 does not fully describe the details of open mbean, and their Reference implementations are not included.

　
Figure 7 shows how to use mbean to add tools to devices and software services. Note that the corresponding mbean is the internal representation of the device or service JMX. Any
Mbeans registered on the mbean server in the JMX proxy (discussed later) can send their management interfaces (attributes, operations, and events) to remote NMS or other JMX
Publish applications. However, when we add mbeans to take advantage of devices or software services, we do not have to consider which JMX proxy or NMS is used for management.

Figure 7. JMX Operation Model

　　

Persistent mbean

　
Some mbeans may require persistent support to ensure proper operations. These mbeans should always be implemented
Javax. Management. persistentmbean interface. This interface only has the SAVE () and load () methods. Persistent mbean
The implementation calls the load () method during bean construction to initialize the mbean status based on the persistent value.Inside the JMX proxy

Figure 7 shows the internal structure of a typical JMX proxy. Note that the four main components inside the proxy are mbean server, a group of proxy services, connectors and Protocol adapters, and custom proxy logic.

Mbean Server

　
The mbean server is the core component inside the proxy. All mbeans must be registered with the mbean server before they can be accessed through remote applications. When mbean is used
The server uses a unique object name to address registered mbeans. Remote Manager applications (or distributed services) can only use mbean
Management Interface (published properties, operations, and events) to discover and access mbean.

　Proxy Service

The proxy also provides a set of proxy servers.
You can use the custom proxy logic to operate registered mbeans on the mbean server. To comply with JMX 1.1, these services are required
-All proxies must provide them. Interestingly, You can implement these services in the form of mbean itself. Mbean has the following advantages:

You can remotely access the service through the Manager component or EMS.

By accessing the application from the remote Manager, EMS can remotely manage the service itself.

You can download mbean to dynamically execute Service Logic updates at runtime.

Table 3 shows a group of proxy services defined in the JMX 1.1 specification.

Table 3. Proxy services required by JMX 1.1

M-Let or management applet Service	Supports loading dynamic classes from URLs across networks (seejavax.management.loading.MLetMBeanAnd associated classes/interfaces ).
Monitor Service	Converts costly remote polling operations to local operations. monitors specific changes to mbean attributes and sends events when the changes are observed.
Timer Service	After a specified amount of time, send events, or periodically send events at a specified interval (seejavax.management.monitor.MonitorMBeanAnd related classes/interfaces ).
Link Service	Supports relationship definitions between mbeans and enforces the integrity of relationships (seejavax.management.relation.RelationServiceMBeanAnd related classes/interfaces ).

Value-added proxy Logic

　
Value-added proxy logic is usually written code. It is a custom agent logic that provides localization intelligence to manage JMX registered to this agent.
Resources can be managed. For example, if we have two redundant Application Server Clusters, we can create custom proxies to monitor load levels and dynamically redirect inbound requests to different clusters ―
You can perform operations on mbeans of registered servers. Generally, NMs
Suppliers also provide custom logic. Once the specification of the distributed service is enriched, it can be predicted that a specific custom proxy logic can be used with the custom remote JMX
The Manager components work together to provide more advanced network management functions.

Connector and protocol adapter

The agent does not communicate directly with distributed services, NMs, or other management applications. Instead, the connector and protocol adapter are used. This architecture is consistent with the J2EE Connector Architecture (J2EE Connector Architecture) (see references ). A protocol adapter is a software component that provides access to resources managed by agents through standardized protocols (such as HTTP and SNMP.

A connector is a specialized software component, it provides remote interfaces to the proxy and/or the managed resources on the proxy (usually completed using remote process calling technologies such as CORBA or RMI-for security
Usually through SSL ). When there are multiple active connectors and protocols, you can use multiple heterogeneous applications or NMs
Access managed resources synchronously. Protocol adapters can be used to provide backward compatibility with existing NMS. For example, we can create
Common Information Model/Web-Based Enterprise Management (CIM/webm) Adapter, or you can create a Telecommunications Management Network (TMN) protocol adapter to enable
Operations, management, and maintenance (OAM) on Telecom resources managed by agents ). Precise specifications of JMX connectors and Protocol adapters fall into the scope of standards under development at the same time.

Increasing application support in JMX 1.1

Only the tools and proxy layers are fully defined, but it has won wide support among Java-based enterprise technical developers.

J2EE 1.4 and JMX

　
The final draft version of J2EE v1.4 proposed in August 18, 2002 details how JMX-based tools will become J2EE Web
Standard Section of the container (JSP/servlet engine), EJB container, and application client container. This is a natural development because it is based on J2EE
The extensive deployment of servers is making manageability a clear requirement. (As you can imagine, manual or specialized configuration, management, and monitoring are almost impossible in a large site where hundreds of servers are deployed .)

To date, commercial server products have supported manageability through specialized methods or special additives (compatible with existing NMS products. JMX standardization, as the management basis in J2EE v1.4 specifications, is helpful to ensure that server products from different vendors are generally compatible with NMS (and can be managed by NmS.

　　Implementation Case Study: Apache Jakarta Tomcat 4.1.x

　
The latest beta version of Tomcat 4.1.x server is consistent with the J2EE v1.4 specification. It has integrated JMX tools .. Majority
Tomcat tools are concentrated on configuration components, which correspond to runtime objects in Tomcat's Catalina engine. You can only use
Configuration components modified in the server. XML and Web. XML files, such as <engine>, And <realm>). Now, you can use JMX mbean.

If you look at the org. Apache. Catalina. mbeans package (in the source code distribution or API javadoc), you will find all JMX tool mbean classes that publish tomcat configuration components. Some examples include using <context> Configuration
Set org. Apache. Catalina. mbeans. standardcontextmbean of the component
Org. Apache. Catalina. mbeans. memoryuserdatabasembean
Use the <memoryuserdatabase> component. If you study the actual source code, you will find that the Tomcat 4 tool widely uses the model mbean template provided by the JMX implementation.

Currently, Tomcat 4.1.x is implemented using mx4j JMX (an open source code-licensed JMX implementation), rather than Sun's reference to JMX implementation. However, both implementations are fully compatible with JMX 1.1.

　
One of the advantages of a wide range of Tomcat tools is that it is easy to create a web-based GUI management application. Tomcat 4.1.x
Provides an application called admin. The application itself is created using the struts application framework and JSP technology. It uses the local JMX proxy
The mbean server accesses all configuration components (the same as those defined in the server. xml file ). In the Tomcat environment, the JMX proxy is composed
Org. Apache. Catalina. mbeans. serverlifecyclelistener class is created. This class is
The lifecyclelistener that will be called at startup and shutdown.

To try this JMX-Based Admin Utility, you must first edit the tomcat-users.xml file under the conf directory of the Tomcat distribution. Make sure that you have added the admin role to the Tomcat User:

1 <User Username = "Tomcat" Password = "Tomcat" roles = "tomcat, admin"/>
2

 

The component will use this file to Verify access at runtime. To run this utility, the user must have the admin role. Start Tomcat 4.1.x.

Open the browser and enter the URL:

1 http: // localhost: 8080/admin/
2

On the logon page, enter:

1 Username: Tomcat
2 password: Tomcat
3

Now, study the Admin Utility and observe how JMX mbean supports displaying and modifying the component values of Catalina in real time. For example, Figure 8 shows the configuration page of the properties of the Configuration component:

　　Figure 8. Tomcat 4 GUI Admin Utility Based on JMX 1.1

　　

Of course, in addition to the Web-Based Admin application, Tomcat tools support other proxies and EMS to manage it.

Conclusion

　
By using the Java platform and careful design, JMX has achieved its design goals: scalability, low implementation cost, and compatibility with existing technologies. In the next article, we will use the reference
JMX 1.1 code implements our own standard mbean and dynamic mbean, uses the desired model mbean as a fast tool, and uses the JMX proxy for experiments.