Control Loop Design

Goal: Create and distribute closed-loop models for automating:
  • recovery of faults reported by traps or alarms

  • capacity management as performance thresholds are crossed

Tool: SDC/DCAE-DS/CLAMP

SDC user role: Designer

Closed loops use feedback to control and optimize their behavior. A closed loop can proactively respond to network and service conditions without human intervention.

There are different phases to the Closed Loop (CL) design:

  1. Design a closed loop template and associate it to a Service, the template represents the theoretical flow of the CL. (DCAE-DS/SDC)

    1. generate a deployment artifact that can be ingested by the DCAE, today it is a “cloudify” blueprint.

  2. Distribute the control loop to CLAMP and DCAE, the csar is distributed to CLAMP, the blueprint is distributed to both CLAMP and DCAE. (SDC)

  3. Submit the closed loop, meaning provision Policy/DCAE with closed loop data. (CLAMP)

  4. Deploy the closed loop, it initiates the deployment of the micro service on DCAE side (CLAMP)

Release 1 (Amsterdam) includes control loop template designer in Clamp UI.

Release 2 (Bejing) does not include the control loop template designer in Clamp UI, this is implemented in DCAE-DS.

Steps

Design a Model

Note

When required, contact the DCAE Group (see Mailing Lists) to confirm that a blueprint for the Service has been generated and is available on DCAE.

Prerequisites: Create and test a VF

#TODO ADD A LINK TO VF Creation and Testing user-guides-service-design?

  1. Create and name a new model

  2. Associate a Service with the model

  3. Based on the service, provide values for its attributes

  4. Select the Resource-VF and Resource-VFC to associate with the model

  5. Select one or more locations in the cloud where the closed loop will be deployed

  6. Here is a view of a hypothetical visual design tool showing loop modeling components:

    image0

  7. Use the tool to select and connect components, thus defining the structure of the model

  8. Configure each of the components of the model

    1. Configure Collector

    2. Configure Alarm Detector

    3. Configure Data Analytics Function

    4. Configure Policy

Configure Collector

Prerequisites: Design a Model.

Using the modeling tool, assign a message topic to which this component will subscribe.

Configure Alarm Detector

Prerequisites: Design a Model.

Using the modeling tool, configure the fields described in this table:

Field

Values

Description

Topic Publishes

  • DCAE-CL-EVENT

  • OPEN-DCAE-HIGHLANDPARK- EVENT-OUTPUT

DMAAP message topic to which the component subscribes.

Alarm Condition

(Multiple values)

Populated from vendor-provided list of alarm names. Stored in SDC and retrieved by the modeling tool. Alarms differ per VNF.

Event Source Type

(Multiple values)

Categories of alarms for a VNF .Differs per VNF.

Event Severity

  • NORMAL

  • not-NORMAL

  • WARNING

  • MINOR

  • MAYOR

  • CRITICAL

Severity level of the alarm that caused the rule to match. All conditions are exact matches, except for not-Normal , which matches anything except NORMAL.

Configure Data Analytics Function

Prerequisites: Design a Model.

  1. In the model, click the StringMatch.

  2. Click the Properties icon.

  3. Configure fields as required (see table).

  4. Click Close.

Field

Values

Description

Topic Publishes

  • DCAE-CL-EVENT

DMAAP message topic to which the component subscribes

AAI Fields Matching

(Multiple values)

Additional VM-related fields that downstream elements such as Policy and APPC can use to take action on the signature.

AAI Field Send (Select Multiple)

Resource- Group

Integer

Group of string matching rules that are to be treated together. For example, a resource group could contain two different traps that must be received to produce a signature, as well as the abatement match.

Alarm Condition

(Multiple values)

Populated from vendor-provided list of alarm names. Stored in SDC and retrieved by the modeling tool. Alarms differ per VNF.

Event Severity

  • NORMAL

  • not-NORMAL

  • WARNING

  • MINOR

  • MAYOR

  • CRITICAL

Severity level of the alarm that caused the rule to match. All conditions are exact matches, except for not-Normal , which matches anything except NORMAL.

Event Source Type

(Multiple values)

Categories of alarms for a VNF. Differs per VNF.

Time Window

Integer

Interval during which multiple traps must be received in order to produce a single signature. This value has no meaning if only one onset rule exists. A value of 0 means an unlimited time window.

Age Limit

Integer

Traps older than this limit are deemed too stale to be meaningful and are not processed.

Create CL Event ID

  • Initial

  • Close

Initial: start a closed loop with a new request ID

Close: end an existing closed loop (Close)

Create CL Event ID Output Event Name

  • OnSet

  • Abatement

OnSet: start a closed loop when a condition starts. Triggered with a new request_id and signature flag of Initial

Abatement: end a closed loop when a condition is corrected. Triggered with signature flag of Close.

Configure Policy

Use this task to configure the operational policy of the closed loop.

Prerequisites: Design a Model.

Model configuration involves setting the values in this table, for each of the Rebuild and Migrate recipies in the model.

Field

Values

Description

Overall Time Limit

Integer

Maximum overall time that can be spent on attempting all actions.

Receipe

  • Restart

  • Rebuild

  • Migrate

The automated action to be triggered on the VM by the closed loop.

Max Retries

Positive Integer

Number of times this action should be attempted before failing on MaxRetriesExceeded.

Retry Time Limit

Positive Integer

Maximum amount of time to take performing retries before failing on TimeLimitExceeded.

Parent Policy

(Selection

Recipe that precedes this one in the chain of operations. If this is the first action in the chain, this field is not set.

Parent Policy Conditions

  • Failure: MaxRetriesExceeded

  • Failure: TimeLimitExceeded

  • Failure: Exception

  • Failure: Other

  • Success

Types of results from the previous action on the chain that would cause a transition to this action.

Distribute the Model

Prerequisites: Design a Model.

In this step, the user distributes the models to the DCAE and Policy subsystems of ONAP.

After a model is uploaded to a VNF, the status icon of the VNF changes to from “Design” to “Activated” in the ONAP Portal GUI.

Open Loop Design

Create and distribute open control loops for managing VF faults and performance after instantiation.

With open loop control systems, the action(s) taken by the Policy do not affect the output of the system.

For information about creating policy using the Policy Designer,

#TODO ADD A LINK TO VF Creation and Testing user-guides-service-design?