VDUs 的亲和/反亲和策略

https://blueprints.launchpad.net/tacker/+spec/vdu-affinity-policy

本提案描述了将 VDUs 的亲和/反亲和策略引入 VNFD 模板的计划。Tacker 管理员启用亲和策略将 VDUs 放置在同一计算节点上，并启用反亲和策略强制将 VDUs 放置在不同的计算节点上。

问题描述

部署者有时希望控制实例的放置。例如，他们希望将实例放置在同一计算节点上，以减少实例之间的通信开销和流量，例如 Web 服务器和数据库。他们也可能希望确保实例部署在不同的计算节点上，以避免因硬件故障同时发生故障。特别是，实现严格的 SLA（例如需要 99.999% 的可用性）非常重要。

目前，控制放置的唯一方法是使用可用区。但是，创建可用区需要管理员权限，并且缺乏灵活性。

例如，考虑以下场景，当需要使用可用区将 VDUs 放置在同一计算节点上时。管理员为每个计算节点创建可用区。操作员找到合适的计算节点并为每个部署指定相应的可用区。这并没有体现云的优势，更糟糕的是，如果部署的计算节点发生故障，操作员必须手动恢复 VDUs。

将 VDUs 分散到不同的计算节点也存在问题。可用区需要拆分为预期 VNFs 中的最大数量的 VDUs。这会降低利用率效率，并且在某些情况下无法拆分，例如，操作员使用的基础设施由其他组织提供，可用区的拆分违反了基础设施设计策略等等。

提议的变更

在 VNFD 中引入新的策略 tosca.policies.tacker.Placement。它为目标 VDUs 提供亲和/反亲和放置。

此功能旨在满足 ETSI GS NFV-IFA 011 [1] 中定义的某个要求。

下面显示了一个假设 Active/Standby 的示例 VNFD。此示例定义了主 VDU 和辅助 VDU 的反亲和放置。

:caption: Example VNFD
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: placement policy for VDUs
topology_templete:
  node_templates:
    VDU_Primary:
      type: tosca.nodes.nfv.VDU.Tacker
# ...snip...
    VDU_Secondary:
      type: tosca.nodes.nfv.VDU.Tacker
# ....snip...
policies:
  - anti_affinity_placement_policy
      type: tosca.policies.tacker.Placement
      properties:
        policy: anti-affinity
        strict: true
      targets: [ VDU_Primary, VDU_Secondary ]

此放置策略在 Nova ServerGroup 的术语中支持“亲和”、“反亲和”、“软亲和”、“软反亲和”。

将这些 ServerGroup 策略映射到我们的放置策略类型，policy 属性指定“亲和”或“反亲和”作为基本策略，strict 属性控制“软-”前缀。

基本策略 tosca.policies.Placement 已经在 tosca-parser 上实现 [2]。当前的 heat-translator 使用 OS::Nova::ServerGroup 资源来实现放置策略，该资源支持亲和和反亲和，但当前的 heat-translator 始终将“亲和”指定为资源的策略参数。

此功能扩展了 heat-translator 中的 tosca.policies.Placement 以支持其他属性。此计划遵循其他现有的节点类型。例如，当 heat-translator 转换 tosca.policies.tacker.Scaling（源自 tosca.policies.Scaling）时，它使用 tosca.policies.Scaling 的转换器，但 heat-translator 存在一个问题，即从 tosca.policies.Placement 派生的策略未被转换 [3]。在实现此功能之前，必须解决此问题。

Tacker 本身不需要任何更改，除了策略定义。该策略将在 tacker_defs.yaml 中定义。

在节点亲和性变得稳定之前，此功能不支持 Kubernetes。根据 Kubernetes 配置 / 节点亲和性 [4]，在 Rocky PTG 举行时，它被标记为 beta 版本。

备选方案

实现此功能还有另一种选择。

作为 NSD 中描述的策略实现

此功能也可以用 NSD 中的策略建模。

下面显示了一个包含策略的示例 NSD。

:caption: Example NSD

tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: placement policy for VNFs
imports:
  - VNFD_Primary
  - VNFD_Secondary
topology_template:
  node_templates:
    VNF_Primary:
      type: tosca.nodes.nfv.VNF_Primary
    VNF_Secondary:
      type: tosca.nodes.nfv.VNF_Secondary

policies:
  - anti_affinity_policy:
      type: tosca.policies.tacker.Placement
      description: Apply my placement policy to my application servers
      targets: [ VNF_Primary, VNF_Secondary ]
      properties:
        policy: anti-affinity
        strict: true

通过上面的示例，VNF_Primary 和 VNF_Secondary 将被放置在不同的计算节点上。

此模型符合 ETSI GS NFV-IFA 014 [5]，该策略对应于 NsDf.affinityOrAntiAffinityGroup。

采用此模型需要大量的更改。这是由于调用 Tacker API 从 Mitral 工作流来创建构成 NS 实例的 VNF 实例。为了实现此模型，需要进行以下更改：

• NS 功能的更改

  • 将 NSD 的策略部分的支持添加到“NS 创建 API”。

    • 添加一个策略处理器，该处理器理解策略并将策略反映到生成的 workflow 中。

      • workflow 需要创建一个 ServerGroup 并将创建的资源传递给每个 VNF 创建任务。并且 workflow 需要将资源作为其结果的一部分返回。

      • VNF 创建任务需要生成并将策略传递给“VNF 创建”API。

    • 策略处理器应针对每种策略类型进行隔离

      • 似乎很难设计一个可以应用于一般情况的模块。

  • 保存和使用额外的资源信息

    • 当 Tacker 创建 NS 时，Tacker 会保存由 mistral workflow 生成的额外资源信息

      • 如果我们将策略作为 API 参数提供，则也需要保存策略。

    • 当 Tacker 删除 NS 时，Tacker 会删除与 NS 绑定的额外资源。

    • 当 Tacker 更新 NS 时，Tacker 可能会考虑策略和额外资源。

• VNF 功能的更改

  • 添加 API 参数“policies”，允许用户添加或覆盖策略。

    • 给定的策略必须与其他 VNF 属性一起保存

  • 实现“tosca.policies.tacker.Placement.ServerGroup”，它将所有包含在 VNF 中的 VDU 放入指定的 ServerGroup。

TOSCA 解析器影响

此功能需要添加名为 tosca.policies.tacker.Placement 的策略类型。

tosca.policies.tacker.Placement（源自 tosca.policies.Placement）

属性名称	类型	必需	默认值	约束	描述
策略	string	false	‘affinity’	‘亲和’, ‘反亲和’	目标 VDUs 的放置策略
strict	布尔值	false	‘false’	‘true’, ‘false’	如果策略不严格，即使调度程序无法在策略下分配主机，也允许继续。

数据模型影响

无

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

VDU 部署时间会稍长，因为 Nova 会为给定的 VDUs 筛选适用的计算节点。

其他部署者影响

此功能需要支持 tosca.policies.tacker.Placement 类型的 heat-translator。

开发人员影响

此功能依赖于 heat-translator 的更改，该更改由其他项目开发。我们需要与 heat-translator 团队讨论并为他们的项目做出贡献。

实现

负责人

主要负责人

Dinesh Bhor <dinesh.bhor@nttdata.com>

其他贡献者

Hiroyuki Jo <jo.hiroyuki@lab.ntt.co.jp>

Masataka Saito <saitomst@intellilink.co.jp>

Tushar Patil <tushar.vitthal.patil@gmail.com>

Nitesh Vanarase <nitesh.vanarase@nttdata.com>

工作项

• 在 Heat-translator 上贡献 tosca.policies.Placement

• 添加 TOSCA 类型定义

• 单元测试

• 功能测试

• 在 doc/source/user/placement_usage_guide.rst 中添加功能文档

依赖项

此功能依赖于以下项目。

• VDU 级别恢复

  • 当前 Tacker 在检测到 VDU 发生故障时会重新启动整个 VNF

  • 如果用户希望使用此功能来提高具有冗余架构的 VNF 的可用性，Tacker 需要支持 VDU 级别重新启动操作。

  • 此问题应在另一个蓝图 中解决。

• 改进 Heat-translator 上的放置策略

  • 当前实现仅支持亲和策略。

  • 我们需要添加对上述属性的支持。

• 从 tosca.policies.Placement 派生的策略未被转换

测试

添加单元测试

文档影响

• 更新 VNFD 模板指南，添加 tosca.policies.tacker.Placement 的指南

参考资料

[1]

https://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_NFV-IFA011v020101p.pdf

[2]

https://github.com/openstack/tosca-parser/blob/f208175e69f05b5723c6cd2b0f56512b0bd3caa3/toscaparser/elements/TOSCA_definition_1_0.yaml#L931

[3]

https://bugs.launchpad.net/heat-translator/+bug/1755433

[4]

https://kubernetes.ac.cn/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity

[5]

http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/014/02.04.01_60/gs_NFV-IFA014v020401p.pdf