1.7 Management Patterns

Ru-Brd

1.7 Management Patterns When developing a manageable resource, the developer is faced with many choices concerning how to interact with the management system and how to fit into a manager-agent architecture. The set of architectural patterns we present here[46] categorizes the common ways that managed resources interact with the management system. Each pattern is progressively more interactive from the management system to the managed resource. Patterns are differentiated by the flow of information and the placement of function. 1.7.1 Event Generator The Event Generator pattern is applicable to resources whose processing contains events and metrics and whose service does not require operations or dynamic configuration control while executing. The resource contains instrumentation and sends management data via events to the management system. The events would represent failures, lifecycle changes, state changes, metric data, or configuration data changes. The resource would not support being invoked for operations or reconfiguration by the management system. It does not have to implement any facilities to listen for and respond to management requests or implement the generic API. This is the simplest and most basic way for a managed resource to interact with a management system. 1.7.2 Noninterruptible In the Noninterruptible pattern, the managed resource contains instrumentation, and it sends events and publishes management information to a management system. Unlike the Event Generator pattern, in the Noninterruptible pattern the resource sends the management system a standard object, like an MBean, MIB object, or CIM object, that contains that resource's identity and metric information, as well as details of the current configuration. Notifications of changes to the managed object can be sent via events specified for that purpose or by the resending of the updated managed object to the management system. This pattern is preferable to the Event Generator pattern when the management requires the data to be represented as a managed object or there is a great amount of potentially complex management data that may be frequently updated. When the management is not in real time, sending the entire managed object on a periodic basis rather than every time a value is updated batches the service's changes to the management system. It also allows a set of changes to be sent so that they are consistent with each other. This is better than sending a set of events, some of which may not arrive in order or at all, which would leave the management system's version of the managed object in an invalid or inconsistent state. The Noninterruptible pattern should also be used when a particular management system requires the data in a particular format. The receiver of this information receives data already in the context of the managed object it understands. The resource does not support being invoked for operations or reconfiguration by the management system. It does not have to implement any facilities to listen for and respond to management requests, nor does it have to implement a particular API. 1.7.3 Queryable The Queryable pattern is related to the Event Generator pattern in that the resource does not require configuration or operational control, but in this case the service sends events and implements an API that can be called by the management system. This is essentially read-only management because the managed resource supports being invoked by the management system to get current metric and configuration data, but not being controlled or altered. The management data may be represented as complex data types and objects. Management systems typically retrieve the management data when they need it or poll for entire sets of related management data rather than one or two metrics. This approach works well for applications with a high rate of change of metric values or a number of complex metrics large enough that sending events to signal changes represents too much overhead. The managed resource implements facilities to listen for and respond to management requests and may implement the generic management API. 1.7.4 Operational As in the Queryable pattern, in the Operational pattern the management system can retrieve configuration and metric data and get events from managed resources. However, in this pattern the management system can set configuration data and invoke operations on the managed resource. The managed resource implements facilities to listen for and respond to management requests and may implement the generic management API. In addition, the managed resource must be designed to allow for configuration changes during execution. Figure 1.9 summarizes the essential characteristics of these four patterns. These patterns give increasing amounts of information and control over the resource to the management system. Any of the patterns may send events directly to the management application or through an event collector. Both the Event Generator and the Noninterruptible patterns only send communications and do not implement any way for the management application to initiate communications with the resource. The Noninterruptible pattern sends a specific managed object and is much more dependent on a management application understanding that object. The Queryable and Operational patterns usually use a managed object as well. These two patterns must support two-way communications. They both require the implementation of a way for the management application to initiate communications with the resource. Only the Operational pattern allows the management system the ability to control the resource. Figure 1.9. Management Patterns

Ru-Brd