| Solstice Enterprise Manager 4.1 Managing Your Network | |
Automating Nerve Center Requests
Automating a Solstice Enterprise ManagerTM (Solstice EM) network involves precise interworking of pre-programmed Nerve Center request templates, autoManagement objects, and an autoManagement daemon, em_autod. Nerve Center requests are inquiries programmed into Nerve Center request templates and issued to agents for data about the status of the network components that the agents support.
Through automation of Nerve Center requests, you can manage any network component configured with an agent, regardless of protocol, without having to manually check conditions. For example, you can launch a Nerve Center request that probes to determine whether a host is up and running or down. See Section 7.6 Reference for sample requests or refer to any of the following tasks.
This chapter comprises the following topics:
- Section 7.2 Getting Started
- Section 7.3 Creating autoManagement Objects
- Section 7.4 Manually Starting and Stopping Requests
7.1 Overview
By setting up predefined and customizable Nerve Center request templates, autoManagement objects, and the autoManagement daemon, em_autod, you can automate the management of components that exist in the topology of your network.
7.1.1 About Requests for Network Conditions
The Nerve Center is a module of the MIS that detects the current conditions of a type of object and responds by taking appropriate actions. Solstice EM provides scripts that, when run, send requests to the Nerve Center. The Nerve Center responds, and the ensuing chain of events results in the automation of network management tasks.
7.1.2 About Nerve Center Request Templates
The scripts that enable the automation of Solstice EM network management tasks are referred to as Nerve Center request templates, or request templates for short. You can customize the templates using Advanced Requests, accessible from the Tools menu of Network Views, or from the command line. For information about customizing default request templates, see the Customizing Guide.
Request templates comprise a finite number of states and transitions between states. States represent the anticipated conditions of a network component, as indicated by information available to the request. Specifying transitions in request templates involves providing conditions that define when a transition is likely to occur.
For example, if you want to determine whether a device is up and running or down, the states up and down are included in the request template as possible states. Request templates also indicate how a transition from one state to another should occur following an evaluation of the conditions of the network component. In this example, the request template could contain a transition to indicate the transition from the up state to the down state, or from the down state to the up state, or both.
7.1.3 About autoManagement Objects
Solstice EM provides autoManagement objects, which use preset criteria to determine the status of specific network components and to indicate the Nerve Center request templates to be launched against each instance of a type of network component. AutoManagement objects are represented online in the Request Controllers tool by the template name and type of object that they specify. Like request templates, the autoManagement object also is associated with a script, called an entry file, which defines its characteristics. Solstice EM provides a set of default autoManagement objects that you can customize using the Request Controllers tool.
7.1.3.1 Default autoManagement Objects
During installation, you have the opportunity to start the two default autoManagement objects, described in the following table.
Note – The autoManagement objects listed in the preceding table are specified by their entry file name, which uses the .autoentry extension. This extension is optional. No extension is required for an entry file. For information about creating new entry files, see Section 7.3.1 Creating Multiple autoManagement Objects.
If the two autoManagement objects described above are selected during installation, they are started automatically by the installation procedure after Solstice EM is started. If Solstice EM is stopped, you can restart the autoManagement objects if they were previously running when you bring up the MIS again using the command, em_services, without the -i or -r options. If you do not start the two default autoManagement objects during installation, you can manually start them later using the Request Controllers tool. For additional information about how to manually start requests, see Section 7.4 Manually Starting and Stopping Requests. For information about the em_services command, see Chapter 2, "Starting and Shutting Down the MIS", of the Management Information Server (MIS) Guide.
Solstice EM also provides another default autoManagement object, link_up.autoentry, which enables you to monitor the status of links, the connections between network topology objects, such as hosts and routers, networks and subnetworks. The link_up.autoentry object is not available during installation, but can be started manually once Solstice EM is running.
7.1.3.2 Custom autoManagement Objects
You can customize your own autoManagement objects as well as the Nerve Center request templates they use. For more information about customizing request templates, see the Customizing Guide.
7.1.3.3 When to Create an autoManagement Object
Create an autoManagement object when you want to automatically launch a Nerve Center request against objects of a given type. However, autoManagement objects are not mandatory if you want to run a Nerve Center request manually, on an ad-hoc basis.
The autoManagement object identifies a particular object type and correlates the object type with a specific Nerve Center request template. This correlation ensures that when a new object of the specified type is created in the topology, the autoManagement daemon automatically launches the associated Nerve Center request template against the new object. The same request template is also launched separately against every object of the specified type.
For example, if an autoManagement object specifies an autoEntryTopoType as "host," then, as long as the autoManagement object is started (its administrativeState value displays as unlocked in Request Controllers), the autoManagement daemon causes a Nerve Center request to be launched against each new or pre-existing host object.
An exception to this rule exists in the case of the device_reachable_ping.autoentry autoManagement object, which issues only one request, against root, rather than against every host object in the topology. The autoManagement daemon then issues an snmEventRequest against every host in the topology to determine whether or not a network component can be reached by the ping command. The collected responses from each host are received by the single Nerve Center request. Because only one request is issued, the load is reduced on the MIS components that handle Nerve Center requests, contributing to improved MIS performance. For detailed information about the device_reachable_ping.autoentry object, see Section 7.6.3.3 Entry Launching Ping-Reachable Template.
7.1.3.4 Criteria Used by autoManagement Objects
You can set up autoManagement objects from the Request Controllers tool or from the command line. By setting up specific criteria, you set an autoManagement object to recognize specific network components from which to request status data. The following table lists and describes some criteria used in typical autoManagement objects.
TABLE 7-2 Criteria for Automatic Management Identity of the autoManagement object Distinguished name or unique identifier of the autoManagement object you create. A unique identifier is required. Template to use Specifies the name of the template to be launched against the topology object. This template must exist in the system. Default templates are provided in the Advanced Requests tool, available in Network Views by clicking Tools -> Advanced Requests. Type of object Specifies the topology type of network components against which you want to launch requests for status. The type of object specified must be a valid Solstice EM definition, such as Device or Container. In Solstice EM, you can find out an object's type in Network Views by clicking Object -> Properties. The type is displayed in the Object Properties dialog. Scope of the network request Specifies whether or not requests are launched against all topology nodes. Possible values of this attribute are local and all. Local specifies that the request is launched only against topology nodes of the local MIS. All specifies that the request is launched against topology nodes in all available MISs. Specific keywords Specifies a value that must match a keyword contained in the ObjectInstance of the topoNodeMOSet. If the keyword matches, a request is launched. A keyword specification of none, the default value, causes requests to be launched without checking the topoNodeMOSet, resulting in simple autoManagement entries.
The following two criteria are backward-compatible SunNet Manager (SNM) characteristics used in creating an autoManagement object that launches requests against SNM proxy agents.Schema Specifies a concatenation of the SNM agent name and the group in the schema that the agent supports. Event Request information Specifies SNM-specific event request information, the snmEventRequest attribute, entered in the same format used for the RCL function snmEventRequest when building a Nerve Center request template. For more information, see the chapter in the Customizing Guide covering RCL functions.
7.1.4 About the autoManagement Daemon
The autoManagement daemon, em_autod, is responsible for the following tasks:
- Monitoring the creation and deletion of objects in the MIS topology
- Starting Nerve Center requests by launching request templates when new managed objects are created in the topology
- Stopping Nerve Center requests when objects are deleted from the topology
To automatically start requests for managing network components, the autoManagement daemon must be running. For a more detailed description of what the autoManagement daemon is and how it works, see Section 7.6.2 AutoManagement Daemon.
7.1.5 Process of Automatic Management
From a high-level perspective, the overall process of automatically managing a network component by automating Nerve Center requests can be delineated as follows:
Before automatic management begins, you complete the following tasks.
1. In the Design Advanced Requests tool, you use or customize default Nerve Center templates or write new Nerve Center templates as needed.2. In the Request Controllers tool, you create an autoManagement object that specifies a Nerve Center request template and the type of network component to which to send a request. If you prefer, you can create an autoManagement object from the command line in an entry file rather than use Request Controllers.
- Example--You create an autoManagement object called SysUpOrDown that specifies the default Nerve Center request template IsSnmpSystemUp and the object type host. The IsSnmpSystemUp request template causes the Nerve Center to inquire of an agent whether the host it supports is up or down. In response to the request, the agent sends back a response about the condition of the host. If the agent itself is not running or if the device is down then the IsSnmpSystemUp request will send a nerve center alarm indicating that the device is down.
The Steps of Automatic Management
After you have set up your Nerve Center template and autoManagement object, automatic management begins. The following steps occur:
1. The autoManagement daemon, em_autod, extracts the criteria required for gathering status data from the autoManagement object. This criteria includes the specified Nerve Center request template and the object type.2. The autoManagement daemon then listens for notification of the creation or deletion of the specified type of object from the topology.3. When the autoManagement daemon discovers an object of the specified type in the topology, it starts the Nerve Center request template designated by the autoManagement object.4. The Nerve Center request starts. Following specifications in the request template, the Nerve Center sends a request for attributes to, or subscribes to events from, the agent of the specified network component.5. The agent receives the request and sends back the appropriate response to the Nerve Center.6. The Nerve Center listens for the agent's response or waits for an event to come from the agent.Example--In the previous example, the autoManagement daemon extracts the Nerve Center request template IsSnmpSystemUp and the object type host from the SysUpOrDown autoManagement object.
The autoManagement daemon discovers a host computer named wasabi and starts up the IsSnmpSystemUp template.
The SNMP agent configured for wasabi receives the request from the Nerve Center. The request, essentially, asks "Is wasabi up or down?"
The SNMP agent configured for wasabi sends back notification that wasabi is down. The IsSnmpSystemUp request template sends a request to check if a device is up or down. If wasabi is down or the agent on wasabi is not running, the agent sends an error response that triggers the template to then send an alarm indicating that the device is down.
7.1.6 Related Tasks
- Complete a Discover of your network. see Chapter 3 for more information on finding out what components are located on your network."
- Determine which Nerve Center request templates you want to automate. Also anticipate potential states of managed objects and transitions.
- Obtain the appropriate Nerve Center request templates in the Advanced Request tool.
7.1.7 Related Files
- /opt/SUNWconn/em/bin/em_automgr
- /opt/SUNWconn/em/bin/em_autod
- /opt/SUNWconn/em/bin/em_services
7.2 Getting Started
This section explains how to start and exit the Request Controllers tool.
1. Start Request Controllers in one of the following ways.
- From Network Tools, click the Administration icon, then click the Request Controllers icon. The Request Controllers window displays.
- From an operating system prompt, execute: em_automgr options
- where options include: -help -host hostname
For more information about the em_automgr command-line options, see Section 7.6.1 Command-Line Options.
2. Perform any task discussed in this chapter.3. Click File -> Exit when you are finished.See also Creating autoManagement Objects-page 7-8.
7.3 Creating autoManagement Objects
This section describes how to create a basic or an advanced autoManagement object using the Request Controllers tool. Basic autoManagement objects require a specification of the following:
- Nerve Center request template to launch against the specified type of object
- Type of object that exists in the network topology against which you want the autoManagement object to launch the Nerve Center request
Advanced autoManagement objects require this information as well as additional criteria, described in Section 7.1.3.4 Criteria Used by autoManagement Objects.
The following types of object creation are included:
- Basic
- Advanced
- Multiple
To Create a Basic autoManagement Object
1. In the Request Controllers window, click Object -> Create.
- The Request Controllers - Create dialog displays.
2. To create a basic autoManagement object:
3. Click OK.
- A message displays briefly to confirm that the autoManagement object was created.
To Create an Advanced autoManagement Object
1. In the Request Controllers - Create dialog, after you have specified the Nerve Center request template and the object type, click Advanced.2. In the expanded Request Controllers - Create dialog, type the appropriate information in the following fields:
- For descriptive information about any of these details, see Section 7.1.3.4 Criteria Used by autoManagement Objects. For sample entry files that use this information, see Section 7.6.3 Sample autoManagement Objects.
3. Click OK.
A message displays briefly to confirm that the autoManagement object was created.
Whether you create a basic or an advanced autoManagement object, the autoManagement daemon will run the specified Nerve Center request against all objects of the specified type. Requests continue to run until the network component being monitored is deleted, or until you manually stop the request. For information about manually stopping requests, see Section 7.4 Manually Starting and Stopping Requests.
7.3.1 Creating Multiple autoManagement Objects
The Request Controllers tool provides a convenient and simple way to create autoManagement objects one at a time. However, when you want to create many autoManagement objects at once, it is easier to develop entry files.
Entry files are scripts that contain the specifications of autoManagement objects, including the object type and the Nerve Center request template to use--the same information that you specify in Request Controllers--but for more than one object simultaneously. You can also put additional information in entry files to develop more complex functions for autoManagement objects.
To Create Multiple autoManagement Objects
1. Execute the following command at an operating system prompt:
2. Add entries to the file to describe each of the autoManagement objects you create.
- Multiple CREATE entries can be present in the entry file to load multiple autoManagement objects.
To view how the CREATE entry operates in the context of an entry file, see Section 7.6.3 Sample autoManagement Objects. For more information about using em_objop to create customized scripts, see Chapter 5 in the Developing C++ Applications.
7.4 Manually Starting and Stopping Requests
- When autoManagement objects are first created in the MIS, they are given an administrativeState value of unlocked, which means that the ability to automate Nerve Center requests is turned on. If you change the administrativeState value to locked, the autoManagement object is disabled and all requests launched by the autoManagement daemon for that autoManagement object are deleted. If you want to re-enable the autoManagement object, you need to change the administrativeState attribute value to unlocked. You can change the administrativeState value from the Request Controllers tool.
To Start Request Controllers
- After opening Request Controllers, click Object -> Start in the Request Controllers window.
- When a request is running, the autoManagement object is displayed as unlocked in the Request Controllers window. The administrative state value, unlocked, refers to the condition of the autoManagement object as being available, and permitted, to run automatically and continuously until the managed object that it affects is deleted.
To Stop Request Controllers
- To manually stop requests, click Object -> Stop.
- After you manually stop a request, the name of the autoManagement object is displayed as locked in the Request Controllers window. The administrative state value, locked, refers to the condition of the autoManagement object as being available, but not permitted, to run.
7.5 Changing autoManagement Object Characteristics
You can change, or edit, an autoManagement object to specify a Nerve Center request template different from the one that you originally specified, or to launch requests against another type of object. When you change an autoManagement object, the pre-existing object is deleted and replaced with a new autoManagement object containing your changes. You can also delete or change advanced criteria, for example, if the scope of the request changes.
To change an autoManagement object, you use the Request Controllers - Edit dialog, which contains the same fields as the Request Controllers - Create dialog.
To Change a Basic autoManagement Object
1. In the Request Controllers window, click Object -> Edit.
- The Request Controllers - Edit dialog displays, in the default manner for changing basic attributes of an autoManagement object.
2. To change the autoManagement object:
- In the Template field, select a different Nerve Center request template.
- In the Device field, enter the type of network component, such as a host, container, bridge, or router, against which you want the Nerve Center to start a request.
- Click OK.
- A message displays to confirm the deletion of the previous autoManagement object and the creation of the new autoManagement object which contains your changes.
To Change an Advanced autoManagement Object
1. In the Request Controllers - Edit dialog, click Advanced to expand the dialog.2. Change the information in any of the following fields:
- Scope (this can be local or all)
- Key
- Schema
- Event Request
- For descriptive information about any of these details, see Section 7.1.3.4 Criteria Used by autoManagement Objects. For sample entry files that use this information, see Section 7.6.3 Sample autoManagement Objects.
3. Click OK.
- A message displays to confirm the deletion of the previous autoManagement object and the creation of the new autoManagement object which contains your changes.
Using the new criteria in the modified autoManagement object, your requests run as specified until the network component being monitored is deleted, or until you manually stop the request. For information about manually stopping requests, see Section 7.4 Manually Starting and Stopping Requests.
To Delete an autoManagement Object
- In the Request Controllers window, select the autoManagement object that you want to delete, then click Object -> Delete.
- A message displays to confirm that the autoManagement object was deleted.
7.6 Reference
The following sections include information about command-line options for Request Controllers.
For detailed information about dialogs, menus, and other user interface elements, refer to the Solstice EM Online Help. To access Online Help, click the Help button on any dialog box or select options from the Help menu located in the upper right corner of each Solstice EM tool window.
7.6.1 Command-Line Options
The optional parameters of the em_automgr command are shown in the following table.
TABLE 7-3 Request Controller Options -help Prints list of options (with descriptions) for the em_automgr command. -host hostname Specifies the hostname of a remote MIS.
For information about the criteria required for both Basic and Advanced autoManagement objects and for descriptions of the fields in the Request Controllers - Create dialog, see Section 7.1.3.4 Criteria Used by autoManagement Objects.
7.6.2 AutoManagement Daemon
The autoManagement daemon (em_autod) starts and stops requests launched against managed objects when the automatic management function is active. The autoManagement daemon starts automatically when the MIS is started using the command em_services. The daemon can also be restarted any time after start-up of the MIS using the command: em_autod [-debug]. The optional -debug parameter causes debugging information to be displayed.
The main tasks of the autoManagement daemon are to await the creation or deletion of object types specified by the autoManagement object and to launch or delete the Nerve Center requests against those created or deleted objects. To ensure that this task is completed, the object types must be created in or deleted from the same environment in which the autoManagement object exists.
As long as both conditions are met--the autoManagement daemon is running and objects of a type specified by the autoManagement object are created in the appropriate system--the autoManagement daemon registers with the MIS to receive event notifications of the creation or deletion of objects. For each autoManagement object, the autoManagement daemon retrieves from the MIS the managed objects that match the selection criteria set up in the autoManagement object. The autoManagement daemon then launches the request template specified by the autoManagement object against all objects specified in the entry file.
The autoManagement daemon is also notified by the MIS if the administrativeState value is changed for any autoManagement object, or if any managed objects are deleted. If the value of administrativeState for an autoManagement object is changed from unlocked to locked, the daemon deletes the requests that were launched against the objects selected by that entry file.
If a request launched against an object is deleted manually, you can restart automatic management for that object by first changing the administrativeState to locked, then changing it to unlocked.
Note – There can be at most one em_autod daemon running at one time. The MIS does not check for duplicate autoManagement daemons.
7.6.3 Sample autoManagement Objects
7.6.3.1 Entry Launching IsSnmpSystemUp Template
The format of CREATE entries is illustrated in the following example. The example entry file creates a single entry that launches the IsSnmpSystemUp template against all "Host" topology objects configured to manage SNMP. See TABLE 7-4 for field descriptions.
CODE EXAMPLE 7-1 Entry Code that Launches the IsSnmpSystemUp Template
TABLE 7-4 Automatic Management Entry File Fields OC The name of the object class. OI The identity or distinguished name of this entry. Each entry should have a unique name. autoEntryTemplate The name of the template you want to launch against the topology object. This template must exist in the system. To view the request templates, use Advanced Requests. For more information, consult the Customizing Guide. autoEntryScope Specifies whether or not the requests are launched against all topology nodes. The possible values for this attribute are local and all.
If the autoEntryScope is set to local, and there are multiple MISs connected, then the specified autoEntryTemplate is launched against only those topology nodes in the local MIS. If autoEntryObject is set to all, then the request is launched against all topology nodes in all available MISs.autoEntryTopoType Specifies the topology type of the objects against which you want to launch the request(s). This must be a valid topology type. All topology types in Solstice EM begin with a capital letter (for example, "Host", not "host"). autoEntryKey The value specified in this field must match a keyword contained in the ObjectInstance in the topoNodeMOSet before a request is launched. If you specify `none', then em_autod launches requests without checking the topoNodeMOSet. In short, requests are started on topology node creation based on topology type. This allows for very simple autoManagement Entries. The default value is `none.'
Note – Automatic Nerve Center requests work only for objects that exist in the topology.
7.6.3.2 Entry Launching LinkUp Template
The following CREATE entry creates a single autoManagement object that launches the LinkUp template against all topology objects on the local MIS of type "Link" with `cmipsnmp' as part of its topoNodeMOSEt.
CODE EXAMPLE 7-2 Entry Code that Launches the LinkUp Template
You can also create an autoManagement object that minimizes the network traffic generally involved in polling. Management stations initiate polling by issuing SNM requests to proxy agents. By editing the autoManagement object to use the LinkUp Nerve Center request template, you can ensure that polling is completed outside the MIS by the proxy agent, thus minimizing the network traffic and polling work required of the MIS. For example, you could send a request to a proxy agent to check devices for reachability. If a device is not reachable, then that proxy agent sends out an event notification. For more information see chapter 6 on device management using RPC agents in the Customizing Guide.
To take advantage of this feature, add the following attributes to the CREATE entry:
- autoEntrySchema -- A concatenation of the SNM agent name and the group in the schema that the agent supports.
- autoEntryEventRequest -- The snmEventRequest information, entered in the same format used for the RCL function snmEventRequest when building a Nerve Center request template. For more information, see chapter 20 in the Customizing Guide.
7.6.3.3 Entry Launching Ping-Reachable Template
The following entry file creates the device_reachable_ping autoManagement object. This autoManagement object issues only one request, against root. The entry file specifies the Nerve Center request template, snmEventRequest, is launched against all managed objects of the type, host, to determine whether each host in the topology can be reached by the ping command. Proxy agents handle the polling and send back error information only if the threshold specified in the request to the proxy agent is crossed, thereby reducing polling load on the MIS and improving MIS performance overall. Responses to the request are sent to the single AutoManageDecayReachablePing template, which ascertains which devices can be reached and posts alarms accordingly.
Note – The keyword HOSTNAME in the autoEntryEventRequest attribute is replaced by the name of the host against which the request is launched.
CODE EXAMPLE 7-3 Entry Code That Launches the Ping-Reachable Template
The advantage of this type of autoManagement is that you only need one template for any number of hosts. All the threshold checking is done by the SNM RPC proxy agent.
7.6.3.4 Entry Returning the Transport Address of an Agent
The following file causes the transport address attribute of a CMIP or SNMP proxy agent to be returned in hexadecimal form. The line, OPTION ='HEX' can be changed to OPTION = `OCTAL' to have the transport address returned in octal form.
CODE EXAMPLE 7-4 Entry Code That Returns the Transport Address in Hexidecimal Form
|
Sun Microsystems, Inc. Copyright information. All rights reserved. |
Doc Set | Contents | Previous | Next | Index |