通过 Heat 支持单个 VNFC 管理

https://blueprints.launchpad.net/tacker/+spec/individual-vnfc-management

本文档提出了一种通过 OpenStack Heat 实现单个 VNFC 管理的新功能。该提案侧重于 v2 VNF 生命周期管理 (LCM) API，并添加了新的示例 BaseHOT、相应的 UserData 脚本以及 UserData 类中的实用函数 [1]。

问题描述

ETSI NFV SOL002 v3.3.1 [2] 和 SOL003 v3.3.1 [3] 定义了一个名为 VNF 组件 (VNFC) 的元素。VNFC 是虚拟计算机的一个单元，例如 VM 和 Pod，而 VNF 由一个或多个 VNFC 组成。Tacker 的 VNF LCM API 已经支持由多个 VNFC 组成的 VNF 实例，方法是使用 OpenStack Heat 提供的 AutoScalingGroup [4]。

以下显示了带有 AutoScalingGroup 的示例 BaseHOT。

• 顶层 HOT

  heat_template_version: 2013-05-23
  description: 'Simple Base HOT for Sample VNF'
  
  parameters:
    nfv:
      type: json
  
  resources:
    VDU1_scale_group:
      type: OS::Heat::AutoScalingGroup
      properties:
        min_size: 1
        max_size: 3
        desired_capacity: { get_param: [ nfv, VDU, VDU1, desired_capacity ] }
        resource:
          type: VDU1.yaml
          properties:
            name: {get_param: [ nfv, VDU, VDU1, computeName ] }
            flavor: { get_param: [ nfv, VDU, VDU1, computeFlavourId ] }
            image: { get_param: [ nfv, VDU, VDU1, vcImageId ] }
            zone: { get_param: [ nfv, VDU, VDU1, locationConstraints] }
            net: { get_param: [ nfv, CP, VDU1_CP1, network] }
  

• 嵌套 HOT（在上述顶层 HOT 中指定的 VDU1.yaml）

  heat_template_version: 2013-05-23
  description: 'VDU1 HOT for Sample VNF'
  
  parameters:
    name:
      type: string
    flavor:
      type: string
    image:
      type: string
    zone:
      type: string
    net:
      type: string
  
  resources:
    VDU1:
      type: OS::Nova::Server
      properties:
        name: { get_param: name }
        flavor: { get_param: flavor }
        image: { get_param: image }
        networks:
        - port:
            get_resource: VDU1_CP1
  
        availability_zone: { get_param: zone }
  
    VDU1_CP1:
      type: OS::Neutron::Port
      properties:
        network: { get_param: net }
  

HEAT API（stack create、stack update 等）会生成与“desired_capacity”一样多的资源（VNFC）。由于属性统一应用于所有 VNFC，因此无法对单个 VNFC 进行单独设置和更新。

这导致了以下两个问题。

1. 通过重新创建所有 VNFC 导致服务中断

AutoScalingGroup 导致 ETSI NFV IFA007 v3.6.1 B.2 [5] 中描述的“不由 NFV-MANO 辅助的 VNF 软件修改”中的服务中断。

在这种情况下，在从 MANO 外部组件直接更新 VM 的配置后，Modify 操作会更新 VNFM 中的 VNF 实例信息，以便进行后续的 LCM 完整性。然后，后续的 Scale 或 Heal 操作会使用新的镜像创建资源，并同时重新创建由 AutoScalingGroup 创建的所有 VNFC，即使它们不是扩展目标或修复目标。这会导致服务中断，这在商业系统中是不可接受的。有关此问题的详细信息，请参阅“拟议的更改”章节。

注意

Tacker 通过 IFA007 v3.6.1 B.3 [5] 中描述的“由 NFV MANO 辅助的 VNF 软件修改，通过更改当前 VNF 包”来支持滚动更新操作的 ChangeCurrentVNFPackage API。

2. VNFC 之间的反亲和性限制

当将“ZONE”指定为 PlacementConstraint.scope 并且 VNFM 从 NFVO 获取区域时，AutoScalingGroup 会将其应用于所有 VNFC。也就是说，即使 VNFD 或 Grant 中指定了反亲和性，所有 VNFC 也会部署在同一区域。这种行为违反了标准规范。

提议的变更

序列的更改

本文档更改了软件更新的序列，如下所示。

更改前序列

以下序列省略了通知过程。

该过程包括以下步骤，如图所示

实例化 VNF

1. 客户端向 Tacker 常见流程发送 POST 请求以实例化 VNF 实例。

2. VM 的数量是通过将 InstantiateVnfRequest 中描述的“instantiationLevelId”和 VNFD 中描述的“number_of_instances”相乘来计算的。

3. Tacker 常见流程和 NFVO 交换授权信息。

4. Tacker UserData 脚本创建 HOT 及其相应的输入参数。

5. Tacker 常见流程使用 AutoScalingGroup 的“Glance imageid”和“desired_capacity”发送 Heat stack-create 请求。

6. Heat 创建属于 VDU1 的 VNFC1。

更新 VNFC1 上的内部配置以及 Tacker DB 中的 VNF 实例信息

1. 元素管理器 (EM) 通过访问客户操作系统来更新 VNFC1 上的内部配置。

2. 客户端向 Tacker 常见流程发送 PATCH 请求以修改 VNF 信息。

3. Tacker 常见流程更新 VNF 实例的 vnfdid。新 VNFD 中描述了具有更新配置的新软件镜像的标识符。

扩展 VNF

1. 客户端向 Tacker 常见流程发送 POST 请求以扩展 VNF 实例。

2. VM 的数量是通过将 Scale VNF 请求中描述的“number_of_steps”和 VNFD 中描述的“number_of_instances”相乘来计算的。

3. Tacker 常见流程和 NFVO 交换授权信息。来自 NFVO 的授权包含 VNFC 的新的 Glance imageid。

4. Tacker UserData 脚本创建 HOT 及其相应的输入参数。

5. Tacker 常见流程使用 AutoScalingGroup 的“Glance imageid”和“desired_capacity”发送 Heat stack-update 请求。

6. Heat 使用新的软件镜像重新创建 VNFC1。

7. Heat 使用新的软件镜像创建 VNFC2。

更改后序列

以下序列省略了通知过程。

突出显示红色框中的更改。

该过程包括以下步骤，如图所示

实例化 VNF

1. 客户端向 Tacker 常见流程发送 POST 请求以实例化 VNF 实例。

2. VM 的数量是通过将 InstantiateVnfRequest 中描述的“instantiationLevelId”和 VNFD 中描述的“number_of_instances”相乘来计算的。

3. Tacker 常见流程和 NFVO 交换授权信息。

4. Tacker UserData 脚本创建调整后的 HOT 及其相应的输入参数。

5. Tacker 常见流程使用“Glance imageid”发送 Heat stack-create 请求。

6. Heat 创建属于 VDU1 的 VNFC1。

更新 VNFC1 上的内部配置以及 Tacker DB 中的 VNF 实例信息

1. 元素管理器 (EM) 通过访问客户操作系统来更新 VNFC1 上的内部配置。

2. 客户端向 Tacker 常见流程发送 PATCH 请求以修改 VNF 信息。

3. Tacker 常见流程更新 VNF 实例的 vnfdid。新 VNFD 中描述了具有更新配置的新软件镜像的标识符。

扩展 VNF

1. 客户端向 Tacker 常见流程发送 POST 请求以扩展 VNF 实例。

2. VM 的数量是通过将 Scale VNF 请求中描述的“number_of_steps”和 VNFD 中描述的“number_of_instances”相乘来计算的。

3. Tacker 常见流程和 NFVO 交换授权信息。来自 NFVO 的授权包含 VNFC 的新的 Glance imageid。

4. Tacker UserData 脚本创建调整后的 HOT 及其相应的输入参数。

5. Tacker 常见流程向目标 VNFC 发送带有“Glance imageid”的 Heat stack-update 请求。

6. Heat 创建属于 VDU1 的 VNFC2。

调整后的 HOT

Tacker 的 UserData 脚本从 BaseHOT 生成调整后的 HOT。调整后的 HOT 中描述了单个 VNFC 定义，可以指定它们各自的输入参数。因此，Tacker 可以使用调整后的 HOT 管理单个 VNFC。例如，Tacker 可以仅更改 heal 目标 VNFC 的软件镜像。此外，Tacker 可以为每个 VNFC 指定不同的可用区。

由于拟议的更改不会影响 Tacker 常见流程，因此 Tacker 可以同时支持带有 AutoScalingGroup 的 BaseHOT 和不带有 AutoScalingGroup 的 BaseHOT。

BaseHOT

• 顶层 HOT

  heat_template_version: 2013-05-23
  description: Test Base HOT
  
  parameters:
    nfv:
      type: json
  
  resources:
    VDU1:
      type: VDU1.yaml
      properties:
        name: { get_param: [ nfv, VDU, VDU1, computeName ] }
        flavor: { get_param: [ nfv, VDU, VDU1, computeFlavourId ] }
        image: { get_param: [ nfv, VDU, VDU1, vcImageId ] }
        zone: { get_param: [ nfv, VDU, VDU1, locationConstraints] }
        net: { get_param: [ nfv, CP, VDU1_CP1, network] }
  

• 嵌套 HOT（在上述顶层 HOT 中指定的 VDU1.yaml）

  heat_template_version: 2013-05-23
  description: 'VDU1 HOT for Sample VNF'
  
  parameters:
    name:
      type: string
    flavor:
      type: string
    image:
      type: string
    zone:
      type: string
    net:
      type: string
  
  resources:
    VDU1:
      type: OS::Nova::Server
      properties:
        name: { get_param: name }
        flavor: { get_param: flavor }
        image: { get_param: image }
        networks:
        - port:
            get_resource: VDU1_CP1
  
        availability_zone: { get_param: zone }
  
    VDU1_CP1:
      type: OS::Neutron::Port
      properties:
        network: { get_param: net }
  

• 输入参数

  "nfv": {
    "VDU": {
      "VDU1": {
        "computeName": "VDU1",
        "computeFlavourId": "m1.tiny",
        "vcImageId": "6b8a14f0-1b40-418a-b650-ae4a0378daa5",
        "locationConstraints": "zone-x"
      }
    },
    "CP": {
      "VDU1_CP1": {
        "network": "67c837dc-c247-4a3e-ac0f-5603bfef1ba3"
      }
    }
  }
  

调整后的 HOT

• 顶层 HOT

  heat_template_version: 2013-05-23
  description: Test Base HOT
  
  parameters:
    nfv:
      type: json
  
  resources:
    VDU1-0:
      type: VDU1.yaml
      properties:
        name: { get_param: [ nfv, VDU, VDU1-0, computeName ] }
        flavor: { get_param: [ nfv, VDU, VDU1-0, computeFlavourId ] }
        image: { get_param: [ nfv, VDU, VDU1-0, vcImageId ] }
        zone: { get_param: [ nfv, VDU, VDU1-0, locationConstraints ] }
        net: { get_param: [ nfv, CP, VDU1_CP1-0, network ] }
    VDU1-1:
      type: VDU1.yaml
      properties:
        name: { get_param: [ nfv, VDU, VDU1-1, computeName ] }
        flavor: { get_param: [ nfv, VDU,VDU1-1, computeFlavourId ] }
        image: { get_param: [ nfv, VDU,VDU1-1, vcImageId ] }
        zone: { get_param: [ nfv, VDU,VDU1-1, locationConstraints ] }
        net: { get_param: [ nfv, CP, VDU1_CP1-1,network ] }
  

• 嵌套 HOT

  只有顶层 HOT 会更改为调整后的 HOT。嵌套 HOT 不会从 BaseHOT 更改。

• 输入参数

  "nfv": {
    "VDU": {
      "VDU1-0": {
        "computeName": "VDU1-0",
        "computeFlavourId": "m1.tiny",
        "vcImageId": "6b8a14f0-1b40-418a-b650-ae4a0378daa5",
        "locationConstraints": "zone-x"
      },
      "VDU1-1": {
        "computeName": "VDU1-1",
        "computeFlavourId": "m1.large",
        "vcImageId": "0ef0597c-4aab-4235-8513-bf5d8304fe64",
        "locationConstraints": "zone-y"
      }
    },
    "CP": {
      "VDU1_CP1-0": {
        "network": "67c837dc-c247-4a3e-ac0f-5603bfef1ba3"
      },
      "VDU1_CP1-1": {
        "network": "4d8aa289-21eb-4997-86f2-49a884f78d0b"
      }
    }
  }
  

以下是 UserData 脚本的要求。

• UserData 脚本根据 VnfInstance.instantiatedVnfInfo.vnfcResourceInfo、Grant.addResources 和 Grant.removeResources 的数量计算 VNFC 的数量，类似于计算 desired_capacity 的方法。get_param_capacity [6] ，是 UserData 类中的实用函数之一，可用于获取资源数量。

• UserData 脚本在调整后的 HOT 中描述与 VNFC 数量相同的资源。

  • UserData 脚本创建 VNFC 的资源 ID（例如 VDU1-0、VDU-1-1）。

  • 资源属性从 BaseHOT 复制。

• UserData 脚本创建与调整后的 HOT 对应的输入参数。

注意

在带有和不带有 AutoScalingGroup 的 scale-in 操作中存在差异。基本上，VNFC 会按照最新到最旧的顺序在 scale-in 操作中删除。在使用 AutoScalingGroup 的情况下，最新的资源是根据 OpenStack Nova 的 creation_time 确定的。由于 creation_time 会被 heal 操作更新，因此 VNFC 的顺序会动态更改。另一方面，在不使用 AutoScalingGroup 的情况下，最新的资源是由资源 ID（例如 VDU1-0、VDU1-1）确定的。因此，不使用 AutoScalingGroup 时，heal 操作不会更改 VNFC 的顺序。

数据模型影响

无

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

无

其他部署者影响

无

开发人员影响

无

实现

负责人

野口宏文 <hirofumi.noguchi.rs@hco.ntt.co.jp>

工作项

• 添加包含新的 BaseHOT 和新的 UserData 脚本的新 VNF 包。

• 添加新的功能测试。

• 添加创建调整后的 HOT 的新实用函数。

依赖项

无

测试

将为 Instantiate 和 Scale VNF 添加功能测试用例。

文档影响

UserData 类中的新实用函数将在 UserData 脚本手册中描述。

参考资料

[1]

https://docs.openstack.org/tacker/latest/user/userdata_script.html

[2]

https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/03.03.01_60/gs_nfv-sol002v030301p.pdf

[3]

https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/03.03.01_60/gs_nfv-sol003v030301p.pdf

[4]

https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Heat::AutoScalingGroup

[5] (1,2)

https://docbox.etsi.org/ISG/NFV/Open/Publications_pdf/Specs-Reports/NFV-IFA%20007v3.6.1%20-%20GS%20-%20Or-Vnfm%20ref%20point%20Spec.pdf

[6]

https://docs.openstack.org/tacker/latest/user/userdata_script.html#def-get-param-capacity-vdu-name-inst-grant-req