VNF 手动和自动伸缩¶
https://blueprints.launchpad.net/tacker/+spec/vnf-scaling
添加支持手动和自动伸缩已部署的 VNF。
问题描述¶
目前，VNF 资源（包括 CPU 核心和内存）在 VNFD 模板中通过镜像 flavor 设置进行硬编码。这导致 VNF 的配置要么针对典型使用情况，要么针对最大使用情况。前者在负载超过配置容量时会导致服务中断。后者在正常系统负载期间会导致资源利用率不足和浪费。因此，用户希望有一种方法可以根据需要无缝地伸缩 VNF 的数量，无论是手动还是自动。
提议的变更¶
以下章节详细介绍了从 TOSCA 建模到驱动程序级别的所有伸缩方面。
TOSCA 伸缩策略模型
假设以下示例模板，其中 2 个 VDU 通过每个连接使用单个连接连接到网络。
topology_template:
node_templates:
vdu1:
type: tosca.nodes.nfv.VDU.Tacker
vdu2:
type: tosca.nodes.nfv.VDU.Tacker
# vdu1 - cp1 - vl
cp1:
type:tosca.nodes.nfv.CP.Tacker
# vdu2 - cp2 - vl
cp2:
type:tosca.nodes.nfv.CP.Tacker
vl:
type: tosca.nodes.nfv.VL
当用户部署此 VNF 时，假设最初正在运行 2 个 vdu1+cp1 实例，并且当发生 vdu1 的伸缩场景时，需要以 1 个实例的步长伸缩，最大实例数为 3 个，最小实例数为 1 个。为了支持这种情况，伸缩策略将根据 [1] 定义如下
tosca.policies.tacker.Scaling
tosca.policies.tacker.Scaling:
derived_from: tosca.policies.Scaling
description: Defines policy for scaling the given targets.
properties:
increment:
type: integer
required: true
description: Number of nodes to add or remove during the scale out/in.
targets:
type: list
entry_schema:
type: string
required: true
description: List of Scaling nodes.
min_instances:
type: integer
required: true
description: Minimum number of instances to scale in.
max_instances:
type: integer
required: true
description: Maximum number of instances to scale out.
default_instances:
type: integer
required: true
description: Initial number of instances.
cooldown:
type: integer
required: false
default: 120
description: Wait time (in seconds) between consecutive scaling
operations. During the cooldown period, scaling action will be ignored
以下是这些新元素的示例
policies:
sp1:
type: tosca.policies.tacker.Scaling
description: Simple VDU scaling
properties:
min_instances: 1
max_instances: 3
default_instances: 2
increment: 1
targets: [vdu1, vdu2]
在这里，对于缩减，目标将减少 ‘increment’ 中给定的数量，对于伸缩则相反。
假设用户希望单独或累积地监控 vdu1+cp1 和 vdu2+cp2。为了支持这两种情况，伸缩策略可以与监控策略内联定义，从而提供灵活性。
以下部分定义了触发机制。
一旦开始伸缩，它将侦听公开的 heat 事件以跟踪伸缩进度，并找出新的/删除的 VDU 详细信息，然后它将相应地调用管理驱动程序。
2. 使用 API 触发伸缩策略（手动）Tacker 将提供支持，以便在 REST API 中对 VNFS 进行伸缩，如以下部分 REST API 影响 中所述。
相应的 CLI 如下所示
- tacker vnf-scale –vnf-id <vnf-id>
–vnf-name <vnf name> –scaling-policy-name <policy name> –scaling-type <type>
在这里，scaling-policy-name 和 scaling-type 与 REST API 中定义的相同。并且 vnf-id 或 vnf-name 用于提供 VNF 引用，其中一个参数是必需的，如果同时给出两个参数，则将使用 vnf-id。
例如，要伸缩上述定义的策略 ‘sp1’，可以使用以下 cli：
- tacker vnf-scale –vnf-name sample-vnf
–scaling-policy-name sp1 –scaling-type out
使用警报/监控触发器触发伸缩策略
警报监控驱动程序可以使用此伸缩功能自动触发缩减和伸缩，如下所述
mp1:
type: tosca.policies.Monitoring
description: Simple VDU monitoring
properties:
# all monitoring related properties
scale-[in|out]: sp1
targets: [vdu1, vdu2]
注意：在这里，目标应与相应的伸缩策略匹配。此外，这种监控策略的确切模式由监控 规范 定义。
备选方案¶
无
数据模型影响¶
一旦伸缩操作完成，伸缩元素的当前状态将作为键值对集捕获在 deviceattributes 表中。
REST API 影响¶
POST on v1.0/vnfs/<vnf-uuid>/actions
with body
{“scale”: { “type”: “<type>”, “policy” : “<scaling-policy-name>”}}
在这里，
<scaling-policy-name> - VNFD 中使用的伸缩策略的名称，该名称需要是唯一的，类似于 VDU 命名。
对于伸缩，有两种类型的操作
scale-in - 用于缩减操作
scale-out - 用于伸缩操作
因此，<type> 可以是 ‘in’ 用于缩减，或 ‘out’ 用于伸缩。
响应 http 状态码
202 - 接受执行伸缩操作的请求
404 - 请求无效，如果给定的 scaling-policy-name 和 type 无效
500 - 内部服务器错误，如果在伸缩操作失败时发生错误
401 - 未授权
在伸缩操作期间，VNF 将在以下状态转换中移动
ACTIVE -> PENDING_SCALE_IN -> ACTIVE
ACTIVE -> PENDING_SCALE_IN -> ERROR
ACTIVE -> PENDING_SCALE_OUT -> ACTIVE
ACTIVE -> PENDING_SCALE_OUT -> ERROR
对于每个伸缩操作，状态转换通过审计规范 [5] 支持的事件捕获。
安全性¶
仅允许 VNF 所有者和管理员用户。
因此，将为上述新 REST API 定义以下策略：
“rule:admin_or_owner”
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
如何在 heat 中形成所需的 heat 伸缩资源类型
在 OpenStack 中，heat 提供了设置伸缩组的功能，可以根据预定义的伸缩策略进行伸缩。这里伸缩组可以包含任何 OpenStack 资源，例如 nova 实例、cinder 卷等，而伸缩策略有助于以数量、百分比等方式进行伸缩。因此，可以使用此 heat 功能来完成 tacker 中的 VDU 伸缩，如下所述
1. 将完整的 VNFD 元素建模为 heat 伸缩组 OS::Heat::ScalingGroup 的一部分。例如，考虑一个简单的 VNFD VDU。现在我们希望此 VDU 在 2 到 5 个计数之间进行伸缩，初始设置具有 3 个元素。在这种情况下，使用以下 heat 模板设置伸缩组。在创建组时，使用策略中的 min_instances、max_instances 和 cooldown。
heat_template_version: 2016-04-08
resources:
G1_scaling_group:
type: OS::Heat::ScalingGroup
properties:
min_size: 2
max_size: 5
desired_capacity:3
cooldown: 120
resource:
type: <vdu scale group custom type>
注意
在这里，自定义类型将捕获伸缩组作为单个 heat HOT 模板，并且将使用相同的模板进行伸缩。
伸缩组可以在 TOSCA 中建模，并且需要由 heat 模板转换器将其转换为 heat 伸缩组来支持。
使用 vnfd 模板参数化来自定义 min_size、max_size、desired_capacity 和 flavor，基于伸缩需求，并且需要将相同的参数作为上述 heat 模板中的模板参数。
一旦伸缩组准备好，就需要像下面这样为缩减配置一个伸缩策略，为伸缩配置另一个伸缩策略
G1_scale_out_policy:
type: OS::Heat::ScalingPolicy
properties:
adjustment_type: change_in_capacity
cooldown: 120
scaling_adjustment: 1
G1_scale_in_policy:
type: OS::Heat::ScalingPolicy
properties:
adjustment_type: change_in_capacity
cooldown: 60
scaling_adjustment: -1
注意
cooldown 是伸缩事件的秒数时间窗口，这将根据 VNF 而变化。
将伸缩组引用 ID 添加到这两个策略中。
要使用基于警报的监控驱动程序监控伸缩组，需要在伸缩元素中进行以下设置
在伸缩 VDU 元素中，设置以下带有唯一标识符的元数据，每个伸缩组一个
resources:
G1_scaling_group:
properties:
resource:
metadata: {"metering.stack": <XXX>}
在基于警报的监控驱动程序中，必须设置与相同的唯一标识符匹配的元数据，如下所示。这有助于 ceilometer 聚合在目标中定义的所有组中收集的指标，并确定是否满足警报标准。
G1_scale_out_alarm:
type: OS::Ceilometer::Alarm
properties:
matching_metadata: {'metadata.user_metadata.stack': <XXX>}
注意
当支持伸缩时，它将强制伸缩组中的 VDU 之间的负载均衡器。因此，可以将其作为伸缩组资源元素的一部分添加。可以通过单独的蓝图/规范启用此问题的范围，作为另一个负载均衡器策略。
负责人¶
- 主要负责人
Kanagaraj Manickam <mkr1481@gmail.com>
工作项¶
使用 TOSCA 格式在 vnfd 中建模伸缩。
根据需要使用 tosca-parser 和 heat-translator 进行伸缩。
更新 heat 基础设施驱动程序以处理伸缩。
更新所需的 REST API 并将其在 python-tackerclient 中启用。
增强 horizon 以伸缩/缩减实时 VNF。
创建一个带有伸缩要求的示例 TOSCA 模板。
更新用户文档。
添加所需的测试用例。
添加伸缩的 devref。
添加发布说明。
一旦实现了规范 [5]，就添加事件支持。
依赖项¶
无
