1.6 Managed Resource Responsibilities

Ru-Brd

1.6 Managed Resource Responsibilities In order for management systems to manage software resources, they must have information (i.e., management data) about the resources they're managing, along with the ability to control or update those resources via management operations. This information and operations are provided by management instrumentation from inside and outside the resource itself. This section will explain management data, management operations, and management instrumentation. 1.6.1 Management Data Management data is the information about a software resource that a management system uses. The management system must be able to determine the identity of the resource, how it has been defined to run, and what statistics are available to monitor it. The management data that management systems need access to generally falls into four categories: Identification data. Identification data uniquely identifies the resource to be managed. This data must include the name of the resource and an identifier that allows a specific instance of the resource to be distinguished from other instances of the same type. Other data that is usually included is resource type, vendor, version, serial number, location, contact, installation date, last updated date, and address. This data is used by management systems with discovery, inventory, topology, and configuration components. If the management system cannot find this data for the resource, the resource must be manually defined to the discovery, inventory, topology, and configuration management systems. Configuration data. Configuration data may include the complete configuration of the resource or a subset thereof. Read access alone is valuable for problem determination and dynamic management policy. It gives the management system real-time management guidance about data for which thresholds should be established, logs and components that should be managed, and so on. If the configuration data can be set by the management system, an update to this data may cause the resource to dynamically update and behave in accordance with the new configuration values. Statistical data. Statistical data is numerical data that generally represents the current state of the resource. Most management systems use resource statistics as the data to be monitored to determine resource health. Depending on the quality and quantity of statistical data available from the resource, management systems may also be able to use this data for load and resource balancing, tuning, trend analysis, capacity forecasting, billing, and understanding application usage. Service-level agreements and the systems that report and enforce them use statistical data to define the expectations, thresholds, and responses for the service-level agreements for an application. Status data. Status data is information about the resource that indicates its health and current operational state. Typically status data is reported by enumerated values, like Active, Degraded, Stopped, DependencyDown, Down, or Failed. A resource may have status substates indicating the health and state of its components. Some of this information (e.g., configuration data) can be obtained from logs and files. Some of this information must be obtained directly from the managed resource. 1.6.2 Management Operations Management operations are used to control, locally or remotely, all components of a managed resource. Operations can be categorized as lifecycle control (start, stop, restart, refresh, and so on), query, configure, and custom. Some of these operations (e.g., start and stop) are provided by the platform that is hosting the managed resource. Some must be provided directly by the managed resource as commands or APIs. The management system will invoke these APIs and commands from scripts, programs, remote connections, command prompts, and agents in response to events, schedules, and user requests. It is interesting to note that although user-driven interfaces like administration applications can be used to drive management operations, it is difficult for management systems to use them. Software resources should supply a user interface and command or APIs for the management operations. 1.6.3 Management Instrumentation Management instrumentation is the way a resource provides its management data and operations to the management system. Resources provide two types of management instrumentation: external and internal. Management disciplines need different kinds of instrumentation, depending on whether they need to interact directly with the executing resource. For example, the distribute discipline typically needs only external instrumentation, and operations are difficult to support without internal instrumentation. Most disciplines use a combination of both types of instrumentation, as illustrated by Figure 1.8. Figure 1.8. Internal and External Instrumentation JMX provides the infrastructure for Java resource developers to expose this management information. It also provides the APIs for management systems to gain access to the information and invoke the operations. 1.6.3.1 External Instrumentation External instrumentation is management enablement that is defined and executed outside the resource itself. The external instrumentation consists of definitions describing the resource. The instrumentation is used to customize the management system so that it can effectively manage the resource. These definitions specify the directories, files, libraries, executables, installation processes, configurations, events, APIs, and policies that are required knowledge to manage the resource. The external instrumentation of the resource includes special files, programs, or utilities that may be necessary for the management system to access the data for or control the resource. The management disciplines of distribute, install, configure, monitor, and operate can be supported by this type of instrumentation. Tivoli uses its Application Management Specification (AMS)[44] files as its external instrumentation. AMS files are generically defined as a software resource's management "definition file." Some management system vendors provide tools to facilitate the creation of a resource's management definition files. For SNMP, the MIB file represents this type of instrumentation. For CIM/WBEM, the instrumentation is defined as a schema in a MOF (Managed Object Format) file.[45] 1.6.3.2 Internal Instrumentation Internal instrumentation is management enablement that is developed and executed directly as part of the resource by the vendor or developer. It consists of code specifically engineered to meet a management system's requirements. Basic instrumentation includes the provision of a command tool or a management agent that can invoke or perform the operations and that can obtain the application status and statistics. The monitor and control management disciplines may require this type of instrumentation. Extensive internal instrumentation may be required for communication with a single management system. Monitoring and operating an executing application requires that the application support instrumentation for several different types of management data and functions. For example, an SNMP subagent must be developed for each application that supports a defined SNMP MIB. Likewise, with WBEM, a CIM provider may need to be developed to support the management schema for an application. There is currently no standard instrumentation data or API approach for applications to adhere to or take advantage of. This may not be true in the future, however, because a management model defining the data for managing executing applications is currently being developed in the DMTF. In reality, a combination of external and internal instrumentation methodologies, as illustrated in Figure 1.8, is optimal. There are at least three good arguments for this: External instrumentation is rarely sufficient in and of itself. Generally the resource will need to expose some specific metrics, operations, and events. You then have internal instrumentation. Internal instrumentation is rarely sufficient in and of itself. There are frequently management tasks to perform within a system to keep it healthy for the application to continue to function. Data space management by the rotation or clipping of logs, the compression of backup data, and the deletion of obsolete logs and data is an example of the second case for external instrumentation. You will need to advertise the internal instrumentation's capabilities in external instrumentation used by the management system. Defining an SNMP MIB is an example. You are advertising your management data to an SNMP manager. A single common application management API simplifies and minimizes the internal instrumentation required. This is the essence of the requirement for a common management system application-level API, as defined by the JMX API set and as described in this book. JMX is designed to satisfy the requirements of managing the executing application from the resource developer's point of view, as well as the management vendor's point of view. JMX is an internal instrumentation API. It is used to expose and and provide access to the execution-time management information that is necessary for an application to be manageable by an arbitrary management system. Tools can be used to generate the external instrumentation for a specific management system from the information available through the JMX APIs.

Ru-Brd