HP OpenView System Administration Handbook [Electronic resources] : Network Node Manager, Customer Views, Service Information Portal, HP OpenView Operations نسخه متنی

19.2 TERMINOLOGY

When there are multiple management servers, it is helpful to use new terms and concepts to understand the configuration.

19.2.1 OpenView Domain

This term refers to the managed devices that send messages and events to an OpenView management server. The management server has responsibility for the devices within the domain. The responsibilities of the management server were described in Chapter 14, "Agents, Policies, and Distribution."

19.2.2 Message Forwarding

Events are transformed into messages on the managed node using an SNMP trap interceptor, program monitor, message interceptor, console monitor, or message interceptor. After converting the intercepted event into an OVO message, the message is sent to a management server. This process is called message forwarding.

19.2.2 Responsible Manager

The responsible manager is the server to which the managed node is authorized to send messages. The responsible manager configuration is defined inside a configuration file that could reside on a managed node or a management server.

19.2.3 Primary Manager

A primary manager is the management server is authorized to configure the agent, deploy policies and execute actions. The information about which manager currently is primary resides on the managed node.

19.2.4 Original Manager

The original management server distributes the initial OpenView configuration to the managed node. The initial configuration includes the agent software, templates, and configuration components such as programs, files, or scripts.

19.2.5 Secondary and Action Allowed Managers

The secondary manager is authorized to become a primary management server in the event of a failure or takeover. The authorized manager configuration resides in a file on the managed node. It is important to define all relevant managers as secondary, including the primary manager. If this is not done it will not be possible for the primary manager to resume responsibility for the node.

An action-allowed manager is authorized to execute actions on the managed node. Typically all secondary managers are also declared as action-allowed.

19.2.6 Failover/Takeover/Failback/Takeback

A failover is triggered when a secondary manager becomes the primary manager. The process is generally performed manually but can be automated. The command that triggers the failover (sometimes called takeover) is issued from a secondary manager. The

opcragt command (with appropriate options) is sent across the network to the managed nodes and instructs them to begin forwarding the necessary (OPC_PRIMARY_MGR) messages to the new primary server. If the calling server is an authorized secondary manager, the node responds by sending messages to the new primary server. The secondary server is now the primary manager. In order for the original primary server to resume responsibility for the managed nodes, it must also issue the same command to instruct the nodes to report to a new primary manager. This process is sometimes called failback or takeback.

In some environments, the failover and takeback process is automated in the event that the primary node is not responding. If other management servers periodically check the primary server (via ping) and it is not responding, the secondary manager automatically triggers a failover.

19.2.7 Escalation

Some or all messages can be selected from the message browser and forwarded (escalated) to another server. One key difference in the escalation process is that it is initiated manually by the operator. The other message-forwarding concepts, once configured, happen automatically. The server to which the message is sent is called an escalation manager. The operator initiates an escalation through the GUI. The escalate button will display in the pop-up menu or message details for a selected message. If the message matches an escalation rule, the operator can initiate the escalation by selecting the escalate button for the selected message. The escalation configuration resides on the management server. After a message is escalated, it is flagged as 'escalated to' or 'from.' Message escalation is determined by configuration rules.

19.2.8 Switch Control Responsibility

Messages forwarded from one manager to another can allow the target manager to have full control of the message. This means that the standard message actions are available, such as acknowledge, own, escalate (if configured), operator initiated actions, and add annotations. When the message is acknowledged on the second server, it is automatically acknowledged on the original server. Alternatively, a message can be forwarded as read-only from one management server to another. Messages that arrive at the target management server without switch control have the attribute flag set to read-only and cannot be forwarded or escalated. Non-switch control messages allow local acknowledgement and annotations. The non-switch control messages are called notification messages. Several configurable parameters define the behavior of switch control messages. The switch control parameters are in the ovconfchg on the server, and have to be set up in dedicated forwarding configuration files, as explained in Section 19-5. Sample configuration files, templates and configuration parameters are presented in other sections of this chapter.

19.2.9 Sync Configurations

When multiple management servers have responsibilities and authority to become primary managers, the configurations of the servers must be kept synchronized. If, for example, a message from a node, arrives on a secondary manager for which it has no configuration, the message is discarded. It is recommended that the configuration be regularly synchronized. The process to synchronize the configuration requires a configuration download from one manager and a configuration upload on the other managers.