VNF 管理器监控框架¶

https://blueprints.launchpad.net/tacker/+spec/health-monitor

问题描述¶

VNF 管理器需要监控其部署和管理的 VNF 实体各种状态条件。目前 Tacker 支持一种 VNF 监控方法，即 ping 管理 IP 地址。复杂的 VNF 需要额外的监控方法才能使用 Tacker 作为 VNF 管理器。

提议的变更¶

扩展 Tacker 的简单监控能力并利用外部监控系统，最好采用类似于现有管理和基础设施驱动程序的驱动模型。

通过复制现有管理驱动程序的结构和实现，我们可以模块化监控功能，并允许轻松添加额外的监控方法。

本规范建议在 tacker/vm/drivers 下创建“mon_driver”，并将现有的 ping 功能移动到新的模块化驱动程序中。

备选方案¶

现有的监控框架可以在不改变架构的情况下扩展其他功能。但是，使用驱动程序将更容易在未来使用其他监控项目，例如 Monasca 和 Ceilometer。

TOSCA 监控框架增强¶

监控格式¶

vduN:
  monitoring_policy:
    <monitoring-driver-name>:
      monitoring_params:
        <param-name>: <param-value>
        ...
      actions:
        <event>: <action-name>
        ...
    ...

示例模板¶

vdu1:
  monitoring_policy:
    ping:
      actions:
        failure: respawn

vdu2:
  monitoring_policy:
    http-ping:
      monitoring_params:
        port: 8080
        url: ping.cgi
      actions:
        failure: respawn

    acme_scaling_driver:
      monitoring_params:
        resource: cpu
        threshold: 10000
      actions:
        max_foo_reached: scale_up
        min_foo_reached: scale_down

指定的驱动程序必须作为 monitor_drivers 目录结构中的可加载类存在，并且必须包含在 setup.cfg 文件中，以便在 Tacker 服务器初始化期间加载它。

监控线程将使用全局 boot_wait 配置时间（默认值为 30 秒）来延迟启动 VDU/VNF 的监控。监控将使用全局 check_intvl 间隔时间（默认值为 10 秒）调用驱动程序。

boot_wait 和 check_intvl 应该在未来某个时候移动到模板中，以便可以在 VDU 级别指定它们，从而提供更大的灵活性。

监控驱动程序参数¶

可以为驱动程序指定参数，并将作为 kwargs 传递给它。

事件和操作¶

从驱动程序接收到的事件将被映射到关联的操作。事件是特定于驱动程序的，并且在 Tacker 中未预定义。

Tacker 中预定义的操作如下

respawn
scale_up（由自动伸缩功能添加）
scale_down（由自动伸缩功能添加）

数据模型影响¶

将列“monitor_driver”添加到 DeviceTemplate 表

REST API 影响¶

无

安全影响¶

需要检查贡献的驱动程序是否存在安全影响

通知影响¶

通知没有直接影响。研究使用消息总线进行内部和外部通知可能是有益的。

其他最终用户影响¶

monitoring_policy 和 failure_policy 的现有语法将在至少一个版本中保留并弃用。旧语法将被映射到“ping”驱动程序，操作为“respawn”，以便功能保持不变。

此语法将在未来的版本中删除。

性能影响¶

现有实现使用单个线程循环遍历所有已部署的 VNF，确定其状态并在需要时重新启动。这需要扩展为每个 VNF 的线程，以帮助防止线程相互阻塞。这将作为这项工作的一部分进行检查，但可能会推迟。

其他部署者影响¶

VNF 提供商应遵循 Tacker 自定义监控驱动程序文档以添加自定义监控驱动程序。

开发人员影响¶

VNF 开发人员在开发自定义监控驱动程序时应符合此框架。

负责人¶

bobh - Bob Haddleton tbh - Bharath Thiruveedula

工作项¶

使用现有的 mgmt_driver 作为模型创建新的监控驱动程序
将现有的 ping 监控实现为模块并删除现有实现
记录提供自定义监控驱动程序的接口要求
需要编写单元测试来验证基本功能
需要监控语法的 Devref 文档

依赖项¶

现有实现假定单个监控策略（ping）将应用于所有 VDU，即使它仅在单个 VDU 中指定。infra 驱动程序（heat）创建的设备数据结构会从 VDU 定义中检索 monitoring_policy 和 failure_policy 属性，并将其存储在设备（VNF）级别。这可以防止不同的 VDU 指定不同的监控器。

此外，现有实现使用堆栈输出，即 VDU 的管理 IP 地址列表，作为要验证的 IP 地址列表。

测试¶

自动化测试应包括使用每种受支持的监控类型的测试 VNF 模板。

文档影响¶

需要驱动程序接口的文档，以便未来的开发人员创建驱动程序

参考资料¶

[1] http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf

[2] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/csd01/tosca-nfv-v1.0-csd01.html#_Toc421872062

[3] http://www.etsi.org/deliver/etsi_gs/NFV-REL/001_099/001/01.01.01_60/gs_nfv-rel001v010101p.pdf

VNF 管理器的监控框架