EAA Technology White Paper

    16-08-2018

H3C_彩色.emf



Overview

Embedded Automation Architecture (EAA) is a monitoring framework embedded in Comware software. It enables you to self-define monitored events and schedule the actions to take in response to the events.

Technical background

EAA is a component of H3C Comware V7 software. It is a technology to increase the network availability and reduce costs of managing increasingly complicated data centers that are deployed with new technologies (such as virtualization, cloud computing, and EVI).

EAA provides a group of functional components for users to subscribe interested software and hardware events such as link down event, and to apply policies. According to user-defined policies, EAA can send event information through e-mail to technical support or user email accounts.

Did you ever wish that your routers and switches could become smarter to monitor its own

transient error conditions and conduct automated diagnostics? Did you ever struggle with some

repetitive tasks that you hope you could have the devices do them automatically? Did you ever

dream that your router can automatically configure itself when a new device is plugged in

Extremely flexible and powerful

subsystem within Cisco IOS

Software

Adapt device behavior and insert

custom logic without IOS upgrade

24 Event Detectors (ED) integrated

with IOS modules for wide range of

system event detection

CLI and Tcl based policy provides

consistent programmability

interface

Powerful event engine supporting

multi-event correlation, advance

scheduling and more

Benefits

Real-time—Monitors the device in real time and takes user-defined actions.

Openness—Provides an open structure for users to easily add events and actions. You can use comsh command line scripts to configure a monitor policy for monitoring events that occur (such as interface, hotplug, and process events). You can also write a Tcl script that supports complete Tcl grammar and feature (the supported Tcl version is 8.5.8), upload the Tcl script file to the device, and register the file, so EAA can monitor the device.

Security—Provides a safe framework:

Only the administrator or an authorized user can register a policy script. Only a registered policy script takes effect.

Records user roles assigned to a registered policy and uses the RBAC feature to prevent the policy from accessing action-specific commands and resources. If EAA lacks access to an action-specific command or resource, EAA does not perform the action and all the subsequent actions.

EAA verifies a registered policy script. When script tampering occurs, the registered policy does not operate unless it is re-registered.

EAA implementation

EAA contains the following major components:

Real-time event manager (RTM)—The core of EAA. Performs event subscription and policy implementation.

Real-time notify (RTN)—Performs message assembly and email notification.

Real-time detector (RTD)—Detects software and hardware faults as early as possible and triggers RTM to perform policies such as information collection and automatic recovery.

Scheduler—Executes one-time and regular jobs, similar with Linux cron/atd.

RTM works together with RTD and RTN to achieve a sequenced EAA implementation of "monitor-action-report."

Comware V7 implements RTM and scheduler in the current software version, and will support RTN and RTD in later versions. This document mainly describes RTM.

RTM mechanism

RTM is an embedded model for policy trigger and it monitors the device in real time. RTM works with the server control management (SCM) module to monitor the process startup and shutdown, estimate system reliability, and apply policies that are not applicable to SCM.

RTM monitors, debugs, suspends, or stops policy scripts. To avoid longtime occupying resources, RTM limits the maximum amount of time that the monitor policy can run from the time it is triggered.

Figure 1 describes a basic RTM framework. Event sources are software and hardware components that trigger events. For example, executing the comsh command triggers a CLI event, and a syslog triggers a syslog event. RTM filters events that are triggered by event sources according to user subscriptions, and executes policies for qualified events by running scripts. Policy implementation executes policy scripts according to the requirements of RTM. Policy scripts include comsh command line scripts and TCL scripts.

Figure 1 RTM framework

Event sources

To the date of writing, EAA has supported the event sources in Table 1.

Table 1 Event sources

Sequence number

Event source

Description

1

CLI

comsh command help events (tab, ?).

comsh command execution events.

Command line regular expression matching.

Execution control of the matching commands.

2

Syslog

Syslog severity matching.

Syslog message body regular expression matching.

3

Interface

Interface statistics thresholds events.

4

Hotplug

Card hot-swapping events.

5

Process

Process startup, stop, anomaly, and restart events.

6

SNMP

SNMP OID threshold and setting events.

7

SNMP_Notification

Notification generation and value setting events.

Notification sending control.

Actions

You can configure a series of order-dependent actions to take in response to a user-subscribed event. RTM executes the actions when the event occurs in ascending order of action IDs. RTM supports the following actions in Table 2:

Table 2 RTM-supported actions

Sequence number

Action

Description

1

Reboot

Reboots a card or a device.

2

CLI

Executes a command.

3

Syslog

Sends a log.

4

Switchover

Enables an active/standby switchover.

EAA monitor policies

You can configure EAA monitor policies by using the CLI or Tcl scripts.

CLI-defined policy

You can configure a CLI-defined EAA monitor policy at the CLI. Figure 2 provides a simple example of a CLI-defined policy, which shows that a log is sent for the administrator to check an exception that an ospfd process crashed.

Figure 2 Example of a CLI-defined policy

Tcl-defined policy

EAA supports complete Tcl 8.5 grammar, and extends a bit based on the grammar. You can use Tcl grammar to write more flexible and intelligent policy scripts.

Figure 3 provides a simple example of Tcl-defined policy, which prevents the user from rebooting the card in slot 3.

Line 1 registers a CLI event source. This Tcl script is triggered when the reboot word is included in this line.

Line 4 determines whether the reboot slot 3 command is executed. If the reboot slot 3 string is included in the command, the card in slot 3 is not rebooted. _cmd is a system-defined variable referenced in the $variable_name format that indicates the command executed by the user.

Figure 3 Example of a Tcl-defined policy

新华三官网