sually do not talk to each other, and getting a complete status of all devices can be a chore. But it's a start.
Naturally, there is a financial aspect to this. Desktop computers are everywhere, and so is the realization that expenses don't stop at delivery. Cost of ownership is a new worry for already overburdened IT managers. Early results are shocking. In almost every study, the cost of maintaining systems exceeds their purc
hase price manyfold over their useful life span.
In addition, distributed computing, by its very nature, places users and equipment far from those most capable of monitoring, diagnosing, and troubleshooting problems. However, remote monitoring systems have tended to be crude, proprietary, and somewhat oblique in terms of the information they provide.
With recently introduced technologies and emerging standards, future desktop and server systems will report their own status remotely, take proactive steps to mitigate their self-predicted failures, and submit to automated management tools.
Hold Still for the Doctor, Dear
In some cases, the intelligence needed to monitor a particular device's current state, and its prospects for continued health, requires nearly omniscient hardware. However, more often this can happen with more modest systems. Commonly available microprocessors -- such as the 8051 family (developed by Intel but now a commodity), Motorola's 68HC11 line, and the PIC16 an
d PIC17 lines from Microchip Technology -- can provide the smarts. These are not dumb chips but true computers-on-a-chip, often including RAM, ROM, UART, analog/digital translators, and application-specific sensors. Management applications collaborate with application-specific firmware running on these chips on top of a highly portable real-time operating system. (See the sidebar "Embedded Diagnostic Hardware".)
These RTOSes have been central to other embedded applications, ranging from antilock brakes to network hubs, routers, and switches to the dinosaurs in the Jurassic Park ride at Universal Studios. RTOS vendors include Chorus Systems, Diba, Integrated Systems, Microtec, Phar Lap Software, QNX Software Systems, and Wind River Systems. Companies like emWare write tiny code (less than 1 KB) that expands the chips' laconic communications to more accessible network and human interaction.
Marrying easily portable embedded-systems hardware and RTOS-based software with enterprise network management
was a natural. It's like space exploration processes applied to the needs of network managers doing long-distance troubleshooting. Without embedded diagnostics, it's as difficult to get reliable diagnostic information from a crashed server in Podunk as it is from a Mars rover.
"Essentially, in the past, the diagnostic user interface was some blinking LEDs," says Wind River's product manager for embedded Internet, Joerg Bertholdt. "Now the network becomes the user interface to embedded devices." Sensors that can communicate over the network make up for a lack of physical access to widely distributed devices. However, this is only one of the challenging aspects of managing and administering distributed systems, and not the most formidable.
The Tower of Management Babel
There has been no lack of options for monitoring components, at least on networks. In fact, there may have been too many, which has contributed to the difficulties. First, many monitoring and diagnostic protocols are propriet
ary. Then, there are protocols that may not be proprietary but don't talk to each other well or at all. Some protocols are extremely vertical, looking at only a certain component or type of component: not ideal with a vast array of different components to monitor. Some protocols must query the device directly for data. And many protocols do not have World Wide Web capability: a pain if Web access would simplify management, but worse if you're trying to manage a corporate intranet.
Two long-time standards are SNMP's Remote Monitoring (RMON) and OSI's Common Management Information Protocol (CMIP). All by itself SNMP can query network devices, which is fine if the device is in any condition to respond. RMON is an extension to SNMP that keeps closer tabs on a variety of conditions and errors. SNMP 2 gets data from devices on a continuous basis without explicit individual queries.
CMIP is another venerable standard for exchanging network management data. Management consoles can get information from app
lications or other management consoles. CMIP versions run on a variety of networks, almost regardless of network protocol or access method.
What everyone would like is a single diagnostic, monitoring, and maintenance standard. This standard should allow other existing (possibly proprietary) standards to work within its framework, and exchange information, too. The standard should allow monitoring of multiple components, even if those components use other standards. Devices could send ongoing status information, or respond to queries. This standard should be Web-friendly, since so many want to use the Web to monitor remote components. Finally, the standard should be extendible, to incorporate new technologies that arise. Simple, fast, and free would be nice, too, but let's not push it.
The good news: Such a thing is at hand. The bad news: Instead of one "standard," there are two (or more) to consider.
The DMTF Effort
In one move toward a rational standard, the Internet Engineering Ta
sk Force (IETF) has chartered the Desktop Management Task Force (DMTF) subgroup. DMTF represents the spectrum of stakeholders in remote system management, including leading hardware and software vendors -- such as Compaq, Dell, Digital, Hewlett-Packard, IBM, Intel, Microsoft, NEC, Novell, Santa Cruz Operation, SunSoft, and Symantec -- as well as users. DMTF is currently working on standards for an open and interoperable architecture for objects dispersed across a network to converse and collaborate with remote management tools.
The DMTF's steering committee handles direction and strategies, and a technical committee develops the standards and offers technical support. Working committees come in and out of existence to deal with specific issues, including cost of ownership, support management, and application management.
DMTF's first standard was the
Desktop Management Interface
(DMI), in 1994. DMI 1.0 described and gathered information from stand-alone PCs. DMI 2.0 followed i
n 1996, allowing remote data access and troubleshooting of network components.The DMI information format includes the type of processor, date of installation, printers and other peripherals, and maintenance history.
The DMTF working committees have created standard sets of manageable attributes, in a file format called the Management Information Format (MIF), for products including PCs, servers, printers, software applications, and mobile devices. Vendors can DMI-enable products by providing the appropriate information in MIF files. More than 200 products from major vendors are already DMI-enabled.
While DMTF started with networks in mind, it became clear that management over the Internet is necessary. The result is the Common Information Model (CIM), a systems management model. Essentially, CIM is metadata: information that defines the attributes of, and relationships between, the real, raw data.
DMI also defines
service providers
, pieces of code that run in the background. Service p
roviders "expose" a management interface (by which consumers of DMI data -- like management programs -- can more easily access device data) and a component interface (by which device status is made public). DMI also defines a pair of APIs: one between DMI service providers and system management tools, and another between service providers and the component objects under scrutiny themselves. In addition, DMI defines a set of remote communication services. With DMI in place, devices and software can report their health and status and participate in highly refined, automated remote inventory monitoring.
Items that provide DMI management information are collectively known as managed products. Management applications use this information. The DMI service layer running locally in the background receives information from managed products (like printers, PCs, or applications) and stores it in the management information database (in MIF). The standard includes three groups of information that a managed object ma
y report: the component ID group, the event group, and the DMI service provider group. The various groups of reported DMI data in MIF records reside in a database accessible by DMI-compliant information providers and consumers.
A managed object must provide information for the component ID group. This specifies basic identifying attributes, including the manufacturer's name and description, product name, serial number, version, and the date and time of the object's installation.
An
event
is a change of state or a notification of a condition of particular interest to a DMI-compliant object. For example, a printer might raise a DMI event in the case of a paper jam. An event can occur without anyone being told about it.
By contrast, an
indication
provides notification of an event to a DMI consumer. With the printer example, an indication reporting a paper jam might go to remote management tools across a network connection. An administrator would then be able to view this indicatio
n and take appropriate corrective steps.
In the printer example, a "listening" management tool is an
event subscriber
, and it announces that it wants to receive indications through "subscription." Indications themselves are not rich in data; they simply document a change to the MIF database. To receive the actual content of the event that triggered the indication, a consumer must also designate which event data to forward. Indication types include predefined common types (such as add/delete component, add/delete language mapping, add/delete group), but this system allows for the extension of standard types and addition of proprietary types.
DMI is a network management protocol that adds to what existing protocols such as SNMP or CMIP provide, but it does nothing to reduce the complexity of the overall management snarl. Enter Web- Based Enterprise Management.
WBEM on the Air
Besides DMI, DMTF has a parallel standards effort in progress, the Web-Based Enterprise Management (WBE
M) Initiative. ("Web" doesn't imply any reliance on browsers, HTTP, or other Web-specific methods.) The WBEM draft standard is an effort to define a generalized management
information model
that will allow it to work with DMI and many non-DMI proprietary management systems.
"We learned a lesson from the Web, which is that you can have a provider of information and a consumer of information that don't know anything about each other but that still communicate very effectively," says Microsoft's product manager for systems management marketing, Michael Emanuel. "This model has great advantages." Different management systems should talk to each other. Microsoft is betting on WBEM.
WBEM is a superset of other standards, encompassing several new protocols and some current Internet standards. It relies heavily on the same Common Information Model (CIM) metadata structure that the DMI 2.0 specification introduced.
CIM allows any existing protocol, either standard or proprietary
, to provide data for WBEM use. The data resides locally, on a hub or router, for example. Because it assumes nothing about the object model or protocol used, it is absolutely independent of vendor or platform. Devices are not "wired into" specific management tools, and management tools of many types can access device data from any connection. WBEM management will be able to synthesize data reported by components using any other protocol and deliver it at a single point, in contrast to current practice, where administrators use a different management tool for each object being managed.
WBEM already has the support of over 70 major vendors. Any method that can incorporate existing systems, permit new extensions, and deliver component information is a winner.
Microsoft expects to leverage WBEM in its own Windows Driver Model strategy, in a -- surprise! -- proprietary format: the Windows Management Interface (WMI). "WMI was not designed to be portable, it was designed to be optimal for Windows," says
Microsoft's Emanuel. Compliance with the overall WBEM initiative should guarantee that all drivers shipped with Memphis and NT 5.0 will include very consistent and comprehensive instrumentation.
Outlooks and Choices
The real questions are about when we'll see products. Major vendors already offer DMI-compliant components. WBEM is still a spec in the making. Nevertheless, we can reasonably expect WBEM-compliant products next year, especially with Microsoft tossing its admittedly proprietary version into the ring.
For administrators, combining many monitoring systems into one must seem like a dream come true. For managers, for once, they cannot make a wrong decision. If they choose DMI and the world turns WBEM, it doesn't matter: DMI will work under WBEM. If they choose WBEM and the world turns DMI, it doesn't matter: WBEM can talk to DMI. Even if they stick with SNMP or CMIP or a proprietary system, WBEM will simplify their lives. Eventually they will manage things from one console, and l
isten only to devices, rather than users, complain. Heaven at last!
Where to Find
Chorus Systems
Campbell, CA
Phone: 800-972-4678
Phone: 408-879-4100
Internet:
http://www.chorus.com
I'm Failing and I Can't Boot Up!
