1.8 Management Applications

Management systems can be considered as a set of management applications. These management applications usually address one or more management disciplines. This section gives an overview some of the more common management applications.

1.8.1 Distribution Applications

Software distribution applications (Figure 1.10) address the transfer of the files that compose an application from a central software repository to target systems, both servers and clients , where they will be installed and used. Once these files have been transferred, the distribution application prompts the user for configuration information or distributes the initial configuration files as well. Then it checks that all the prerequisite software is already installed on each of the target systems. If there are missing prerequisites, a more advanced software distribution application will automatically distribute and install the prerequisites available to it. The software distribution application will then start the installation programs and scripts on the target systems.

Figure 1.10. Software Distribution System

Usually the distribution and installation are scheduled to run during "off-peak" (night) hours. Therefore, these systems should be able to run unattended from configuration files rather than requiring user interaction. Because the tasks for installing maintenance are similar to the tasks for initial installation of the software, most software distribution systems also provide support for distributing and installing maintenance for those applications. So you can see that software distribution applications support the distribution, installation, and maintenance phases of the management lifecycle.

Maintaining software on large numbers of systems in this manner allows professional systems administrators to take care of more systems than they could otherwise . Having administrators take care of systems relieves the laypeople or end users from having to understand and administer the system themselves along with their regular responsibilities. Professional administrators and help desks can count on a known set of product versions and configurations in their customers' systems. This consistency makes problem determination more predictable.

When existing products are upgraded or maintained , the entire product or set of files is usually replaced . This wholesale replacement maintains a consistent set of software across the enterprise. Central management of software upgrades reduces the chance that different systems will end up with different and incompatible versions of software.

The drawback of using software distribution management systems is that some of them remove control from the educated end user and do not accommodate the user with special needs. Some simpler distribution systems do not allow the end user to install additional products. A software distribution system may update all the software on the systems from time to time, and some or all of the files not maintained by the management system could be lost. In addition, some or all of the system configuration done during product installation may be lost. Finally, system problems may occur if there are resource conflicts between the distributed and user-installed products. These types of problems can be very difficult to resolve. Any customization or personalization of system or products done by the user may be lost during each update.

Some software distribution systems distribute only initial installations of products. These systems are easier to use in enterprises where the target systems may have different inventories of software on them. Such systems will move the files onto the target system and perhaps even run installation programs. However, customization and maintenance of the software are the responsibilities of the end user.

Software distribution products are available from a variety of vendors , including Tivoli, Marimba, ^[47] and Computer Associates.

1.8.2 Inventory Applications

Inventory management applications inspect and track the hardware and software resources available on all of the managed systems. For each resource, an inventory management application tries to keep a similar base of information: type, vendor, model, version, serial number, part number, owner, contact, and location. The more advanced inventory systems also discover and track changes in the inventories automatically. This process is easier if the inventory management application is well integrated with the software distribution or maintenance application. In this case whenever the software on the target systems is updated, the inventory management application is updated.

Inventory systems can also be coupled with resource discovery systems that find new resources on their own. Discovery systems poll the managed systems and network to verify and update the inventory data. For example, SNMP MIB-II provides a significant amount of information about the system, such as interfaces, TCP connections, UDP connections, ICMP connections, ^[48] and so on. The "Host Resources MIB" RFC ^[49] gives details about the installed software. The CIM models provide similar information.

An inventory management application usually maintains a database of this information that can be used by other management applications (like software distribution's prerequisite checking function) or by topology applications. Inventory management applications support the install, maintain, and monitor lifecycle phases.

The advantage of using an inventory management application is that it maintains a more accurate database of IT, systems, software, and maintenance resources than manually updated databases do. Besides being used to feed other management applications, this information can be used by business accounting systems for asset reporting, control, and depreciation. When warnings from vendors regarding flaws and fixes for their product are received, it is relatively simple to notify users within the company and schedule the appropriate corrective action. Knowing the age of the IT resources and scheduling the replacement of obsolete sources before they fail and are replaced in a panic can help us make predictions about expenses and capital.

The drawback of using these management applications is that all resources must be deployed by an application that automatically feeds the inventory application, or the resource information must be entered manually. Obsolete resources must be removed from the inventory manually. Manually entered information can quickly become inaccurate. Even in automatically updated installations, advanced users in an organization will circumvent controlled resource deployment and install their own hardware and software, causing more inaccuracy in the inventory.

1.8.3 Topology Applications

Topology management applications are the heart of most functionally complete management applications. Topology management applications, as illustrated in Figure 1.11, display the current status and relationships, both physical and logical, between managed systems and/or software components . Topology applications discover the current set of resources to be monitored and displayed. They can discover these resources from a configuration file, from an inventory management application, from queries to resources with knowledge about neighbors (gateways, routers, name servers, and so on), or from queries to the systems themselves.

Figure 1.11. Topology Console

Topology management applications allow administrators to define policy to or manually include or exclude resources for the displays. The display of the resources shows their name, type, relationship to other resources, and status. These applications should be able to provide different views of the resources by type, status, or relationships. Custom views and views defined by policies can be defined by the administrator.

Some topology management applications also support monitoring, operations, and configuration management. Most topology management applications contain or use monitoring management applications to get and maintain the status of the resources. Monitoring may be controlled by configuration files or policy. Ties to event management applications provide an additional asynchronous source of status information. The topology display is a convenient launch point to display and invoke available operations. It is also convenient to launch configuration displays from this screen.

Topology management applications support the monitor lifecycle phase as well. Monitoring applications can reflect any detected status changes in the topology management application. Using topology management applications that reflect status can help operations staff identify failing resources with a glance at the topology console. The effect of resource failures on the health of the infrastructure and the root causes of those failures can usually be determined faster. If operations are available, recovering those resources directly from the topology application can be the most efficient means to return the resource to a fully operational state.

The disadvantages of using topology management applications are similar to those of using an inventory management application. The topology is only as accurate as the resources it knows about and the status it can access. In addition, in a very large enterprise environment, the number of resources becomes unwieldy to represent on a single topology screen, and the screen is no longer meaningful, as shown in Figure 1.12.

Figure 1.12. A Less-Than-Useful Topology Console. There Are So Many Resources That Each Resource Is Just a Shaded Line

Large enterprises may have to spend more time developing custom and policy-driven screens.

1.8.4 Configuration Applications

Configuration management applications support displaying the configuration of a resource. If the resource supports runtime reconfiguration or staged reconfiguration (loading a batch of configuration changes or a new configuration file and restarting the resource), then configuration management applications can also support changing the configuration of a resource. Configurations may be changed automatically by policy or manually by an administrator. When configuration changes are applied, they should be validated against the state of the target system. This goes for dependent product configurations too. Side effects of the changes should be predicted and identified if possible. Configuration changes can be applied to a single resource or a group of resources. The group of target resources can be defined by the operator or by a policy.

Configuration management applications are often part of a topology management or an installation management application. Configuration management applications support the execute, configure, and operate phases of the management lifecycle.

Using configuration management applications can dramatically increase the number of systems that a single administrator can manage. This is the case not only because the configuration can be applied to large groups of resources at the same time, but also because it checks that the configuration change is valid before applying it, avoiding configuration problems. Using configuration management applications across the enterprise also helps ensure a consistent configuration of resources, making problem determination and tuning much easier. Configuration managers assign version numbers to the configurations they replace and install so that they can be used in problem determination on problems in deployment and upgrades. Having one centralized control over configuration of many distributed resources can simplify the administrator's job by eliminating the need for him to start and access multiple configuration utilities for each resource type or resource instance.

As with distribution management applications, the disadvantages of using configuration management applications is the freedom that they take from the users. If users customize their configuration at all, that customization may be lost or in conflict with centrally controlled configuration changes.

1.8.5 Operations Applications

Operations management systems provide a list of tasks or operations associated with each resource. Administrators can invoke these operations and see the responses. Operations may be simple or complex. Simple operations can usually be completed with one interaction with the resource. Complex operations invoke a series or set of operations, like a work flow or a script, on a resource or set of resources.

Different scopes of operations are available. Singleton operations are invoked for one resource. Group operations invoke the same operation on a set of similar resource types. Cascaded operations invoke the operation on a resource and all of its subresources or dependent resources.

A typical simple operation is "shutdown" or "stop." It is often invoked as a group and cascaded operation. A complex operation may be "failover," in which case in order to start executing a resource on a backup system after the primary system has failed, a series of operations must be executed successfully.

Operations management applications are often used in conjunction with distribution, installation, and automation management applications. Operations management applications support the start, execute, operate, and stop phases of the management lifecycle.

Like configuration management, operations management applications dramatically increase the number of resources an operator can be responsible for by supporting execution of an operation for an entire set of resources at the same time, as shown in Figure 1.13. Giving operators centralized control of resources saves them trying to find and keep track of an operations console for each resource type or instance. For operators responsible for many disparate resource types, operations management applications will simplify their lives by mapping their operations to some common operations.

Figure 1.13. Sending a Start Operation to Large Numbers of Systems to Start a Web Server Farm

1.8.6 Event and Automation Applications

Event management applications and automation management applications are nearly always delivered together.

Event management applications receive, filter, categorize, and display events from resources to an administrator in near real time. The events may be forwarded to other management applications, such as an inventory management applications, topology management applications, or monitoring and performance management applications. Advanced event management applications correlate the events to filter duplicate events and determine the root cause of a failure. Event filters can be based on event types, severity, resource types, resource groups, or policy rules.

The events are also recorded in a log or database. These records are mined later by performance analysis, problem determination, and capacity planning applications.

Automation management applications detect conditions and perform response actions on the basis of predefined policies without administrator intervention, as illustrated in Figure 1.14. The conditions that are detected are called triggers. The most common trigger is an event. Other common triggers are resource status changes, configuration changes, log updates, and monitored value changes (i.e., threshold exceptions).

Figure 1.14. Event Automation: Expanding a Database When a Database Is Full

Response actions can be to display or log the event, generate a new event, send the event to a new target, invoke an operation, or update the configuration. There can be multiple response actions.

Policies defined in the automation management application are generally based on rules. Simple rules may consist of simple comparisons and Boolean logic. Complex rules have multiple parts, may be order and time dependent, and may require program execution to provide values for parts of the rules.

Event and automation management applications are used by inventory, monitoring, and performance management applications. Event and automation management applications are used to support the execute, monitor, and maintain phases of the management lifecycle.

Using event and automation management applications can reduce the amount of problem determination and recovery that an operator has to do. Just having the events collected and displayed drastically reduces the amount of proactive monitoring of resource status that operators must do.

The only downside to using these management applications is that an operator needs to be tending to them or carrying a pager that the applications use to signal the operator so that critical events are seen and reacted to. Event and automation management applications need to be well customized and tuned . In a large enterprise without filtering, these applications can consume a fair amount of enterprise resource bandwidth.

1.8.7 Monitoring and Performance Applications

Monitoring and performance management applications monitor resources on a regular basis for the purpose of making sure the application is functional, catching problems before they become fatal, and gathering statistics for analysis. Monitoring can be used to provide availability tracking, health status, and events. Monitoring is usually done in a polling format, but passive, asynchronous event monitoring is also used.

Monitoring and performance applications may collect and use several types of management data. The collected data is usually logged or saved in a database for analysis later. Data processed after execution or a failure can be used to drive root cause analysis, capacity planning and management, trend identification, and usage reporting applications. The real-time management data can be used by management applications, such as topology, monitoring, and event managers, to determine availability, health, and events.

Availability management applications report when a resource is not available or responding. Resource availability in the eyes of the management application may be different from that experienced by users because the network status may be different between them and the resource. Availability may also be determined by support of test operations.

Performance and health status management applications report when resources are not performing within defined limits. They determine this by monitoring availability, as in Figure 1.15, and application statistics, or by running and measuring a resource test command that will exercise the critical resource functions that must perform well. Management applications can also test thresholds, analyze the quality of service guarantees , graph data, and identify trends of historical statistical data. The results of these activities indicate application health.

Figure 1.15. Performance Monitoring System for a Web Server Farm

The monitoring and performance management application asynchronously receives or pulls events from the event management application or resource. An automation management application can be used to run recovery or tuning operations, to notify operators, to log, or to filter. Events indicating that the resource is healthy , rather than failing, are called heartbeats. Monitoring management applications should receive and accommodate heartbeats. Heartbeats should also drive status updates in related topology management applications. More sophisticated management systems may monitor application statistics to establish trend lines to guide tuning for optimal operational results over time.

Monitoring and performance management applications implement the monitor discipline and are used to support the execute and monitor phases of the management lifecycle.

Using monitoring and performance management applications can improve operator efficiency by removing the need to constantly survey resources. Performance management applications can warn operators early and allow them an opportunity to proactively tune resources, avoiding resource failure and outages.

Monitoring and performance management applications, like event and automation management applications, must be customized and tuned for large enterprises, or they may consume too much of the IT resources.