With Linux on the mainframe, you are likely to have a heterogeneous environment with multiple operating systems, including traditional mainframe operating systems such as z/VM, z/OS, and VSE/ESA. Systems management frameworks address the question of how to accomplish an integrated management of such heterogeneous environments. This section first provides a general introduction to frameworks and then gives examples for frameworks that are suitable for a Linux-on-the-mainframe environment and encompass Linux and the traditional mainframe operating systems.
During the late 1980s and early 1990s, major vendors of systems management tools began to develop substructures for integrating tools and handling the diversity of heterogeneous environments. Initially, the goal was to make the vendor's own disparate tools work together in a single, integrated, monolithic solution and to provide a single point of control from where an administrator could monitor and control all systems.
Monolithic solutions soon proved too rigid to meet the demands of highly dynamic and diverse customer environments. As a response, the major providers separated the substructure from their tools. With its interfaces published, the substructure became a framework that allowed other vendors and customers to plug in their own tools.
An open framework provides the basis for suitable plug-ins to be assembled into a set of tools that spans all systems management disciplines and all systems in a heterogeneous environment. The framework/plug-in model not only allows tool integration but also the selection of only those tools that are needed in a particular environment.
To a framework provider, the framework is a selling point for the systems management tools that come with it. The suite of tools that the framework provider offers is more attractive to customers if the framework allows other tools to be integrated. Framework providers, therefore, tend to publish their interfaces to enable other vendors and home-grown tools to plug in.
12.6.1 What is in a framework?
A systems management framework is an architecture that allows a user interface, managers, and agents to work together. Managers and agents are plug-ins that communicate with the framework through APIs (Application Programming Interfaces). Managers provide platform-independent management functions and use the agents to run system-specific code on the systems to be managed. For example, a manager that runs a system health monitor could send a request to the agents on each system to find out about free space in the file system. As a response, the agents could use a method that is specific to a particular operating system to get the data. For example:
In all cases, the agent then sends the results back to the manager. On each image, multiple agents can plug into the framework.
A framework usually includes:
that are available on all platforms, such as task management, memory management, or an interface to a security manager.
Extending a framework to support Linux merely means writing the code to map the common services to the ones provided by Linux. And then, in most cases, all one needs to do is retarget the compile to the respective hardware platform.
among the plug-ins. The communication is typically based on TCP/IP. It can include encryption and usually provides secure communication across systems.
A data repository
for information that is shared across the framework. For example, this could be an LDAP-based directory with an underlying SQL database. The database contains common definitions and information about the state of managed objects (for example, processors or applications).
A user interface
that provides the user with a view of the data in the management data repository and through which the user interacts with other plug-ins. The interface usually runs on a PC or laptop away from the machine room (for example, in a control room or in the system administrator's office). The user interface also connects to the framework through an API, so alternatives are possible. User interfaces are often graphical interfaces but can also be command interfaces.
for getting to common services and communication with other user interfaces, managers, agents, and the data repository.
Figure 12-5 illustrates how a framework spans the StoreCompany infrastructure.
Figure 12-5. Framework for StoreCompany
The framework is installed on all managed systems and the systems where the managers run. It offers interfaces to agents and managers and connectivity with other systems that run the framework. The managers can run on any system for which the system requirements for the framework and the manager are fulfilled. Potentially, a manager could run on one of the systems being managed, but it could just as well be on a different continent.
12.6.2 Frameworks and standards
Systems management vendors with frameworks usually provide a suite of managing functions that plug into the framework. You can usually get plug-ins by vendors other than the framework provider, and there is room for you to plug in your own management tools if you have functions to complement what is provided.
To allow other vendors to use a framework and to enable you to plug in your own functions, framework owners publish the APIs that define their architecture. The architecture describes the behavior of the framework.
There is an interaction between architectures and standards. An architecture can be raised to a standard by approval through a standards body. Framework architects, on the other hand, look to existing standards to make their frameworks compatible with tools that adhere to the same standards.
It is no surprise that different vendors often use competing standards. Some vendor APIs are proprietary, others are open standards like SNMP (Simple Network Management Protocol) or the Distributed Management Task Force (DMTF) CIM (Common Information Model). See http://www.dmtf.org for details.
The DMTF is the industry organization that is leading the development, adoption, and unification of management standards and initiatives for desktop, enterprise, and Internet environments. CIM is a common data model of an implementation-neutral schema for describing overall management information in a network/enterprise environment. It includes specifications that define details for integration with other management models, while the schema provides the actual model descriptions.
SNMP is a standard for a systems management protocol that is not only supported by many management tools but also by many "dumb" devices like printers, where the framework cannot be installed. If a tool or framework supports SNMP, it can manage these devices. The Web site for the SNMP standards body is at http://www.ietf.org.
12.6.3 Existing frameworks
Examples of frameworks that cover Linux today are:
IBM Tivoli Management Framework
The Tivoli Management Framework implementation is object-oriented. Earlier implementations were based on the Object Management Group / Common Object Request Broker Architecture (OMG/CORBA) specification (http://www.omg.org/). Its APIs were adopted by DMTF and the Open Group.
More recent development shows a shift to Java, Java Beans, and the CIM data model.
The Tivoli Management Framework has a 3-tier architecture with a TMR (Tivoli Management Region) server at the top. The TMR server can support up to about 200 gateways, each of which can connect to thousands of endpoints. This design provides scalability to a large number of systems and keeps the framework code to be installed on the managed endpoints very small.
Tivoli Management Framework comes with a base set of management functions. There are additional functions that you can optionally plug in, including a plug-in for SAP R3 support. In addition, Tivoli provides a toolkit that helps you to write your own plug-ins.
An administrator with sufficient rights can add a new endpoint to a Tivoli controlled environment by instructing a Tivoli manager or gateway to install the framework code on the new machine. The new machine then communicates with its assigned gateway or registers with a suitable gateway by means of a broadcast.
The Tivoli Management Framework includes a security concept that is based on user roles. These user roles are mapped to regions that are managed by policies.
For the Tivoli Management Framework, Linux has been given increasing attention as a platform for running mainframe managers. For example, IBM Tivoli Storage Manager runs on Linux.
For more information on Tivoli Management Framework visit: http://www.ibm.com/software/tivoli/products/mgt-framework/.
CA Unicenter TNG Framework
The Unicenter TNG Framework provides a base set of management tools, plus optional management tools that you can buy. Optional tools are offered by several vendors, including Computer Associates International, Inc. The Unicenter TNG Framework also provides the Unicenter TNG Software Developer Kit for integrating home-grown tools. Several major system vendors ship systems with the Unicenter.
TNG provides "auto discovery" when an image with a TNG agent registers with the corresponding managers. Unicenter plug-ins can use policies and correlation techniques to attain a degree of autonomous behavior and to reduce network traffic.
The Unicenter GUI and the manager functions run on Linux, so you can control your entire enterprise from a Linux image.
For more information on Unicenter TNG Framework visit: http://www3.ca.com/press/PressRelease.asp?CID=37246.
Other organizations that are worth following in this context are:
PATROL does not claim to be a framework but fits our definition of 12.6.1, "What is in a framework?." It takes a more decentralized approach than the other frameworks we have discussed.
It combines what we have called managers and agents into "knowledge modules." These plug into what we would call the framework, but BMC calls an agent. The agent/framework provides, for example, for cross-system communication.
The knowledge modules are platform- and function-specific. Because they act fairly autonomously, once they are set up on a machine, PATROL creates less data traffic than some other frameworks. Knowledge modules take a set of parameters that can be specified in a plain text configuration file.
PATROL comes with a basic set of knowledge modules. There is also a toolkit that allows customers and vendors to write their own knowledge modules. PATROL knowledge modules identify themselves by listening at a specific port.
PATROL does not have knowledge modules for the mainframe operating systems. Instead, there is a separate product, MainView, that provides administrative functions for these systems.
Because the knowledge modules can act independently, PATROL does not provide a GUI. However, PATROL provides knowledge modules that can send messages to the MainView interface, the TNG console, or the Tivoli GUI. Thus, either of these can be a control point, if needed.
For more information on BMC PATROL visit: http://www.bmc.com/homepage_elements/ii/idc/ema_bmc_patrol_brief.pdf.
OpenNMS is an Open Source group that started from the network view of the world and based much of its work on SNMP.
Its code is based on today's state-of-the art open standard technologies XML (Extensible Markup Language), SML (Simple Markup Language), Java, Perl, and a PostgreSQL object-based relational database.
For more information on OpenNMS visit: http://opennms.org.
We refrain from a detailed comparison of the merits of the various systems management frameworks that can work in a Linux-on-the-mainframe environment because they are subject to rapid change. Which framework is best suited to your environment depends on how well it addresses your current business and operational needs, and on the ease with which you can integrate plug-ins to cover future needs.