为 VNFFG 启用扩展功能¶
https://blueprints.launchpad.net/tacker/+spec/vnffg-scaling
本提案旨在基于 VNFM 中现有的策略操作，为 VNFFG 提供扩展功能。该规范参考了 ETSI 标准中的网络服务故障管理 [1]。
问题描述¶
目前，Tacker 已经支持通过告警驱动程序为单个 VNF 提供扩展功能。但是，在扩展或缩减时，新增或删除实例的 CP 无法添加到/从 Neutron SFC 端口对组 [2] 中添加或移除。
本规范旨在为单站点 VNFFG 提供扩展功能，未来将考虑多站点支持。此外，Tacker 计划将 VNFFG 添加到网络服务 (NS)，因此本规范还考虑扩展范围以支持 NS 内的 VNFFG。
提议的变更¶
在 Tacker NFVO 中引入 vnffg-ha 引擎
+---------------------------------+
| Tacker_NFVO |
| +------------------+ |
| | | |
| | NFVO API/TOSCA | | +-----------------------+
| | | | | |
| +---------+--------+ | | Tacker_VNFM |
| | | | +-------------------+ |
| | | | | VNFM API/TOSCA | |
| | | | | | |
| | | | +---------+---------+ |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| +-----v-----+ | | +------v------+ |
| |NFVO Plugin| | | | VNFM Plugin | |
| | | | | | | |
| +-----+-----+ | | +------+------+ |
| | | | | |
| +-------------v--------------+ | | | |
| | vnffg-ha engine | | | +-------v--------+ |
| | <-----conductor-------+ policy actions | |
| | | | | +----------------+ |
| +----------------------------+ | +-----------------------+
| |
+---------------------------------+
组件
- vnffg-ha 引擎：当 vnffg-ha 接收到 VNFM 中策略操作触发时
首先，它找到 VNFFG VNF 所属的 VNF。
然后，它根据 VNF 策略操作对 VNFFG 进行更改。
Neutron SFC 中 VNFFG 的扩展支持 [4]
+--------------------------------------------------+
| +---------------+ Neutron SFC |
| | +---------+ | +---------+ |
+-----------------+ +----------------+ | |
| | | | VM 11 | | | VM 2 | |
+---+----+ | | +---------+ | +-----+---+ |
|Endpoint| | | | | |
| | | | +---------+ | | |
+--------+ | | | | | | |
+-----------------+ VM 12 +----------------------+ |
| | +---------+ | |
| +---------------+ |
+--------------------------------------------------+
在上面的图中，VM11 由 VNF1 启动，VM12 从 VM11 扩展出来。VM2 由 VNF2 启动。
目前，Tacker 利用 networking-sfc 项目 [3] 基于 Neutron 端口部署 SFC。其中一个优点是 networking-sfc 允许端口对组内存在多个端口对 [4]，从而可以应用负载均衡。
通过使用端口对组更新，我们可以修改端口对列表，包括 添加、删除，甚至更改新的端口对集合。networking-sfc 中的此功能可用于对 VNFFG 进行自动扩展。
负载均衡
有几种情况需要处理：1. VNF 之间的负载均衡。 2. VDU 之间的负载均衡
在本规范的范围内，我们处理 VDU 之间的负载均衡以实现 VNFFG 的扩展。
在 Neutron-SFC 中，一个逻辑端口对组可以包含一个或多个逻辑端口对，并用于在服务功能（逻辑端口对）之间平衡流量 [6]。我们将使用本规范对 VNFFG 的端口对组添加或删除端口对来执行扩展或缩减操作 [7]。
例如，将 VM12 的端口对 (PP2) 插入到包含 VM11 的端口对 (PP1) 的现有端口对组中以执行扩展。
$ neutron port-pair-group-update --port-pair PP1 --port-pair PP2 PPG1
同样，我们可以更新端口对组以通过从端口对组中删除一个或多个端口对来执行缩减。
提议的变更¶
AutoScalingRPC 调用
class AutoScalingRPC(object):
target = oslo_messaging.Target(
exchange='vnffg-scaling',
topic=topics.TOPIC_CONDUCTOR,
fanout=False,
version='1.0')
def vnf_scaling_event(self, context, **kwargs):
pass
Tosca 模板
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: Demo example
metadata:
template_name: sample-tosca-vnfd1
topology_template:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU.Tacker
capabilities:
nfv_compute:
properties:
num_cpus: 1
mem_size: 512 MB
disk_size: 1 GB
properties:
image: cirros-0.3.5-x86_64-disk
availability_zone: nova
mgmt_driver: noop
config: |
param0: key1
param1: key2
metadata: {metering.vnf: VDU1}
CP11:
type: tosca.nodes.nfv.CP.Tacker
properties:
management: true
order: 0
anti_spoofing_protection: false
requirements:
- virtualLink:
node: VL11
- virtualBinding:
node: VDU1
CP12:
type: tosca.nodes.nfv.CP.Tacker
properties:
order: 1
anti_spoofing_protection: false
requirements:
- virtualLink:
node: VL12
- virtualBinding:
node: VDU1
CP13:
type: tosca.nodes.nfv.CP.Tacker
properties:
order: 2
anti_spoofing_protection: false
requirements:
- virtualLink:
node: VL13
- virtualBinding:
node: VDU1
VL11:
type: tosca.nodes.nfv.VL
properties:
network_name: net_mgmt
vendor: Tacker
VL12:
type: tosca.nodes.nfv.VL
properties:
network_name: net0
vendor: Tacker
VL13:
type: tosca.nodes.nfv.VL
properties:
network_name: net1
vendor: Tacker
policies:
- vdu1_cpu_usage_monitoring_policy:
type: tosca.policies.tacker.Alarming
triggers:
vdu_hcpu_usage_respawning:
event_type:
type: tosca.events.resource.utilization
implementation: ceilometer
metrics: cpu_util
condition:
threshold: 50
constraint: utilization greater_than 50%
period: 600
evaluations: 1
method: avg
comparison_operator: gt
metadata: VDU1
action: [respawn, notify]
在上面的模板中，操作包括 respawn ** 和 **notify。相应地，respawn 操作表示修复功能。同时，notify 操作表示触发到 NFVO 层的事件。
对扩展操作的响应
对于缩减，我们需要尽快从当前的 sfc 端口对组中删除已终止实例的 CP，以避免数据丢失。
但对于扩展，新实例化的实例可能需要在我们将其 CP 添加到 sfc 端口对组之前进行一些配置。这也旨在避免流量丢失。如何确保 VM 准备好工作是一个问题。
用例¶
扩展
VNFM 基于 VNFD 中的策略触发扩展。在 VNFM 层，新的 VNF 将使用与旧 VNF 相同的 VNFD 进行扩展。在 NFVO 层，我们有两种选择。第一种选择是，启动新的 VNF 后，为了自动扩展 VNFFG，我们将等待并更新新的 VNF 的端口对到现有的端口对组，由于基于 VM 的 VNF，可能需要很长时间才能达到正常状态。第二种选择是，我们可以使用算法来找到最佳匹配的 VNF，该 VNF 具有相同的 VNFD、租户 ID 和较低的资源使用率，然后将其端口对添加到现有的端口对组。第二种选择可以提供更低的延迟。扩展指的是 IETF 草案 [5] 中的垂直扩展用例。
缩减
对于缩减，首先将 VNF 的端口对从端口对组中删除，然后 tacker 将调用缩减策略来关闭 VNF。
安全影响¶
通知影响¶
由于 VNF 的故障发生在 VNFM 层，而 VNFFG 在 NFVO 层进行编排。一个损坏的 VNF 可能会导致一个或多个 VNFFG 失败。因此，我们需要有一种方法来通知 VNFFG 他们的 VNF。短期内，tacker conductor 将用于从 VNFM 向 NFVO 发出事件。未来的考虑因素是使用事件/审计功能。
其他最终用户影响¶
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Tung Doan <doantungbk.203@gmail.com>
- 其他贡献者
Yan Xing an<yanxingan@cmss.chinamobile>
Phuoc Hoang <hoangphuocbk2.07@gmail.com>
工作项¶
在 NFVO 中实现 vnffg-ha 引擎
添加用于触发 NFVO 中服务的 API
修改 NFVO 插件中现有的 VNFFG 实现
为 vnffg-scaling 添加事件/审计功能
为 vnffg-scaling 添加单元和功能测试
依赖项¶
无
