为 Tacker 添加基于告警的监控驱动

https://blueprints.launchpad.net/tacker/+spec/alarm-based-monitoring-driver

本文档描述了 Tacker 中的基于告警的监控驱动

问题描述

ETSI MANO 架构描述了监控 VNF 以采取适当的操作，例如故障管理、性能管理。监控已成为 MANO 架构中的重要方面。目前，Tacker 仅提供非常有限的支持来检查 VNF 元素的存活状态，通过 ping 或 curl 的方式，这有助于在元素不可达时恢复该元素。但是，Tacker 不支持监控 VNF 元素的 CPU/内存使用情况。此外，Tacker 还需要监控所有 VNF 资源。原因是 VNF 故障发生的情况多种多样。

提议的变更

本文档的范围集中在

• 设计一个通用的监控框架。因此，在 Tacker 中设计一个基于告警的监控驱动，用于收集由低层设计（Ceilometer、Monasca、自定义驱动程序）触发的告警/事件。 在本文档中，基于告警的监控驱动程序可以完全监控 OpenStack 中 Ceilometer 可以支持的任何资源。在实际实施中，本文档旨在利用 Ceilometer 监控 VNF 内部的 CPU/内存使用情况。

• 使用 TOSCA Policy 格式定义监控策略。监控策略可以应用于单个 VDU 或多个 VDU。

• 添加支持将 Ceilometer 告警插入到 HOT 模板中，以允许 Ceilometer 在 Heat 资源组中触发扩展。

The alarm-based monitoring framework:
        +-----------------------------------+
        |                                   |
        |                                   |
        |      +-----------------+          |
        |      | VNFM / TOSCA    |          |
        |      |                 |          |
        |      +--------+--------+          |
        |               |                   |
        |      +--------v--------+          |
        |      |                 |          |
        |      | alarm-framework <-----+    |
        |      |                 +---+ |    |
        |      +-+-^-------+-^---+   | |    |
        |        | |       | |       | |    |
        | +------v-++  +---v-+-+  +--v-+-+  |
        | |         |  |       |  |      |  |
        | |         |  |       |  |      |  |
        | |Ceilometer  |Monasca|  |Custom|  |
        | |         |  |       |  |      |  |
        | |         |  |       |  |      |  |
        | |         |  |       |  |      |  |
        | +---------+  +-------+  +------+  |
        +-----------------------------------+

TOSCA 方案可以定义如下

tosca.policies.tacker.Monitoring

tosca.policies.tacker.Monitoring:
  derived_from: tosca.policies.Monitoring
  targets:
    type: list
    entry_schema:
      type: string
      required: true
    description: List of monitored VDUs
  triggers:
    resize_compute:
      event_type:
        type: map
        entry_schema:
          type: string
        required: true
      metrics:
        type: string
        required: true
      condition:
        type: map
        entry_schema:
          type: string
        required: false
      action:
        type: map
        entry_schema:
          type: string
        required: true

参考的 TOSCA 模板 [1] 可以使用以下细节进行建模，以实现自动扩展

tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: Demo example

metadata:
template_name: sample-tosca-vnfd

topology_template:
node_templates:
   vdu1:
     type: tosca.nodes.nfv.VDU.Tacker
     capabilities:
       nfv_compute:
         properties:
           disk_size: 1 GB
           mem_size: 512 MB
           num_cpus: 2
     properties:
       image: cirros-0.3.4-x86_64-uec
       mgmt_driver: noop
       availability_zone: nova

   vdu1_cpu_usage_monitoring_policy:
       type: tosca.policies.tacker.Monitoring
       targets: [vdu1]
       triggers:
           resize_compute:
               event_type:
                   type: tosca.events.resource.utilization
                   implementation: Ceilometer
               metrics: cpu_util
               condition: utilization greater_than 70%
                   threshold: 70
                   period: 60
                   evaluations: 1
                   method: average
                   comparison: gt
               action:
                   resize: vdu1_scaling_policy

在上面的模板中，事件类型在 [3] 中描述，并在 [4] 中使用。

alarm_url 将由 Tacker 中的 webhook 创建，如下所示

v1.0/vnfs/<vnf-uuid>/<monitoring-policy-name>/<action-name>/<params>

其中：monitoring-policy 是 VNFD 中描述的监控策略的名称。

action-name 也是在 VNFD 中描述的动作的名称。监控策略中可以支持多个动作。通过更改 action-name，将调用适当的动作，然后基于告警的监控驱动程序将处理此动作。在上面的示例中，action-name 是 ‘vdu1_scaling_policy’。因此，当监控驱动程序从 Ceilometer 接收到触发器时，它将调用扩展动作并自动触发扩展。使用监控驱动程序的详细扩展机制由扩展规范 [2] 定义。

params 包含与告警动作相关的信息。例如，它可以用于用户身份验证。因此，Webhook 处理程序将随机生成一个密钥。这有助于确保为每个告警都有一个唯一的 URL。告警 URL 将存储在 Tacker 数据库中，并且仅使用这些唯一的回调。

v1.0/vnfs/<vnf-uuid>/<monitoring-policy-name>/<action-name>/2w3r40-34c2d2

这里，monitoring-policy-name 是监控策略的名称，threshold 是用户想要更新的值。

基于不同类型的回调，我们有以下适当的动作

#1. 如果动作是“Log”，监控驱动程序会将告警恢复到数据库。我们有两种选择来显示这些信息

• 使用 CLI。告警的状态可以在现有的 CLI 中定义如下

  tacker vnf-show [vnf-id]

• 修改 Tacker-Horizon。在 tacker-horizon 中添加“Alarms”（告警）选项卡，用户可以了解 VNF 发生的情况。此选项卡需要包含一些信息，例如：[VDU-ID]——[告警 (CPU, MEMORY, PORT,…)]— [状态 (HIGH, LOW, DELETED,..)]。

#2. 如果动作是“Scaling”（扩展），我们可以调用 API 来触发扩展。详细的扩展

机制可以在扩展规范 [2] 中找到。

#3. 如果动作是“respawn”（重新生成），此动作与 ping 驱动程序中的情况相同。

为了将监控策略转换为 HOT 模板，我们可以使用 heat ceilometer 资源类型。在这种方法中，Tacker 将通过使用与 scale-group 相同的模板或单独的模板来创建 OS::Ceilometer::Alarm 资源。

使用所需的告警标准创建 ceilometer 资源如下

vdu_scale_up_alarm:

    type: OS::Ceilometer::Alarm
    properties:

      meter_name: cpu_util
      statistic: avg
      period: 60
      evaluation_periods: 1
      threshold: 50
      comparison_operator: gt
      action:
        - {get_attr: tacker_alarm_url}
vdu_scale_down_alarm:

    type: OS::Ceilometer::Alarm
    properties:

      meter_name: cpu_util
      statistic: avg
      period: 600
      evaluation_periods: 1
      threshold: 15
      comparison_operator: lt
      action:
         - {get_attr: tacker_alarm_url}

未来考虑:

1. 确实，监控驱动程序能够监控超出 VDU 资源是必要的。CP 资源也应该被监控。尤其是在未来有 SFC 的情况下。原因是每个 CP 都需要分配给一个 Neutron 端口。SFC 是基于 Neutron 端口的连接创建的，因此端口监控对于 SFC 的高可用性是必要的。下面的示例显示了可以通过基于告警的监控驱动程序完成的端口监控

tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0

description: Demo example

metadata:
template_name: sample-tosca-vnfd

topology_template:
node_templates:
   VDU1:
     type: tosca.nodes.nfv.VDU.Tacker
     properties:
       image: cirros-0.3.4-x86_64-uec
       flavor: m1.tiny
       availability_zone: nova
       mgmt_driver: noop
       config: |
         param0: key1
         param1: key2

   CP1:
    type: tosca.nodes.nfv.CP.Tacker
    properties:
       management: true
       anti_spoofing_protection: false
    requirements:
       - virtualLink:
          node: VL1
       - virtualBinding:
          node: VDU1
   CP_monitoring_policy:
     type: tosca.policies.tacker.Monitoring
     targets: [CP1]
      triggers:
        port_monitoring:
          event:
            type: tosca.events.resource.utilization
            implementation: Ceilometer
            metrics: port_bandwidth
            condition: load greater_than 80%
            period: 60
            evaluations: 1
            statistics: average
            action:
             trigger: vnffg1-ha-policy

2. 在未来，Tacker 用户可能想要更新监控参数，例如阈值。问题是当 VNF 实例承受重负载并且 CPU 使用率达到预定义的阈值时。告警将被触发到 Tacker，但实际上这并不是真正必要的，因为 VNF 实例仍然有能力正常工作。Tacker 用户现在想要增加阈值。这可以按如下方式完成

tacker vnf-update --vnf-id <vnf-id> --monitoring-policy-name <monitoring policy>
                                    --threshold [threshold-value]

注意：模板中需要参数化阈值。

备选方案

无

数据模型影响

无

REST API 影响

POST on /v1.0/vnfs/<vnf-uuid>/<monitoring-policy>/<action-name>/<params>

安全性

OpenStack Ceilometer 和 Tacker 之间需要安全性 [5]。

通知影响

Ceilometer 将告警触发到 Tacker 中基于告警的监控驱动程序。

其他最终用户影响

无

性能影响

无

其他部署者影响

无

开发人员影响

无

实现

负责人

主要负责人

Tung Doan <tungdoan@dcn.ssu.ac.kr>

Kanagaraj Manickam <mkr1481@gmail.com>

工作项

1. Tosca 监控元素模型到 Heat ceilometer 监控元素转换

2. 在 VNFD 中启用新的约定来提及基于告警的监控参数

3. 创建一个示例 TOSCA 模板

4. 创建一个用于基于告警的监控的新监控驱动程序，并配置参数以使用上述方法之一。

5. 启用记录 Ceilometer 告警并向用户报告。

6. 增强 horizon 以显示实时监控参数。

依赖项

如果使用 heat ceilometer 描述监控策略，请确保 Ceilometer 支持监控策略。

1. 测试 ========

• CPU 使用率高时的监控

• 从基于告警的 VNFD 模板创建 vnfd

• 从 vnfd 创建 vnf

• 压力测试运行 VNF 的 VM。目的是使 CPU 使用率达到阈值。

参考

[1]

http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.pdf

[2] (1,2)

使用 CLI/Horizon 显示与 VNF VM 相关的告警/事件。

[3]

https://review.opendev.org/#/c/318577/

[4]

https://www.oasis-open.org/committees/download.php/56812/2015-10-27%20OpenStack%20Tokyo%20-%20Senlin-TOSCA%20vBrownBag-final.pdf

[5]

https://github.com/openstack/ceilometer/blob/stable/liberty/ceilometer/alarm/notifier/rest.py#L84