开源NFV管理器 - OpenStack Tacker介绍 NFV和Tacker介绍和主要功能
原文链接:https://blog.csdn.net/bc_vnetwork/article/details/51463518
1. NFV概述
NFV(网络功能虚拟化Network Function Virtualization, 有时候NFV也叫做VNF)由运营商的联盟提出,主要利用通用x86硬件平台和标准的IT虚拟化技术, 来做软硬件解耦合和功能抽象。 这样做可以解决运营商目前碰到的一些问题, 如: 专用设备成本高昂, 厂商锁定, 资源分配、部署、调度不够灵活。随着NFV的使用, 新业务可以快速开发和部署, 并能基于实际业务需求进行自动部署、弹性伸缩、故障隔离、并能大量节约成本和风险。
为了在云计算SDN网络中使用NFV, 需要引入NFV管理器, 用于配置、监视NFV以及管理NFV的生命周期, 整个过程需要符合ETSI MANO中所描述的整个NFV生命周期。
目前开源的NFV管理器有OpenStack的子项目Tacker以及ODL的Armoury插件, 本文着重讲一下OpenStack云平台下的组件Tacker项目。
2. Tacker概述
Tacker是一个在OpenStack内部孵化的项目, 他的作用是NVF管理器,用于管理NVF的生命周期。 Tacker的重点是配置VNF, 并监视他们。如果需要,还可重启和/或扩展(自动修复)NVF。整个进程贯穿ETSIMANO所描述的整个生命周期。
3. Tacker架构
下图所示为ETSIMANO所描述的VNF的整个生命周期:
ETSIMANO框架
Tacker由四大组件组成:即VNFD目录、VNF设置、VNF配置管理,以及VNF监控与自动修复。
以下是Tacker的每个子领域迄今为止所取得的主要成就。
VNFD目录:围绕如何呈现VNF(VNF描述符)的标准化努力如今已经聚焦在了TOSCA上。TOSCA(针对云应用的拓扑与编排规范)是OASIS协会下的一个技术委员会,主要致力于为全球信息社会推动开放标准的开发、整合与应用。TOSCA的NFV概要文件草案已经完成。该规范描述了VNF(VNFD)的属性,以及Tacker对VNFD目录的维护。
一旦VNF被规定使用TOSCA NFV模板,那么它们就能够进入Tacker VNF目录中。一旦进入,Tacker就可以通过编译TOSCA模板和通过翻译器翻译部分OpenStack Heat实现VNF的实例化。Tacker还侧重于VNF的配置和持续性监控,如果需要,自动修复可贯穿ETSI MANO所描述的整个生命周期。
VNF设置:通过上述的Heat模板,Tacker可以使用OpenStack Nova设置计算基础设施。OpenStack Nova的许多功能可以在计算设置程序过程中被使用。通过利用SR-IOV Passthrough、NUMA、CPU pinning和大页面分配等特定属性创建的一些功能,计算资源可以针对VNF进行优化。
VNF配置管理:Tacker将通过配置驱动推动VNF所需的特殊配置。配置管理被设计为可插入式框架,不同的VNF厂商可以为他们的VNF编写自己的配置驱动。
另一个方法是使用SDN控制器。目前已经就如何将SDN和NFV整合在一起展开了许多讨论。关于使用SDN控制器插件的Tacker,如何推动配置使用SDN控制器南向接口的特殊VNF,就是一个很好的例子。
VNF监控与自动修复:Tacker的一个关键职责是监视VNF的健康。通过出台一系列旨在指导OpenStack其他项目设计的规范,Tacker可以随时使用如icmp-ping和http-ping等可加载的监控驱动。它们还被规划与Ceilometer进行整合,如今VNF厂商已经能够编写自己的带有特殊监控属性的监控驱动。
VNF Manager (VNFM) 和 NFV Orchestrator 的功能各自是什么
VNFM的核心功能:
§ VNF 创建和终结(调用VNFD目录)
§ VNF设置(即placement,调用Heat)
§ VNF配置(用EMS)
§ VNF监控(健康,性能等)
§ VNF自动治愈回复和扩展伸缩
§ 支持各类简单的和复杂的VNF
NFVO的核心功能:
§ 网络服务(Network Service)的编排 (用一系列的VNFs和转发图Forwarding Graph,此处想象糖葫芦,一串儿VNFs)
§ 调用VNFM来做跨多个VIM的VNF安置(placement)
§ 资源检查和分配
§ 可以跨虚拟的(VNF)和物理的NFs
§ 用SDN controller 或SFCAPI来实现 VNF Forwarding Graph
§ 来看看 NFVO 和 VNFM 的好处有什么(这里主要面向运营商/服务商):
§ 防止设备厂商锁定(运营商多年的梦想),运营商可以灵活部署从多个厂商提供的VNF。
§ NFV orchestration 编排的流程基本是与具体 VNF 独立无关的 (VNF agnostic)
§ VNF (厂商)具体的差异化可以通过业界标准化的 plugin插件和驱动来实现
Tacker架构
Tacker未来还将新增sfc driver以实现VNFForwarding Graph, 即业务链。
4. Tacker工作流程
以下为Tacker工作流程:
Tacker工作流程
第一步:Tacker根据BSS/OSS需求从服务目录选出相应的服务项目,如vRouter。
第二步:Tacker把具体的 VNFD推送给 OpenStack Heat 来生成VDU (Virtual Deployment Unit,对应含VNF要求的 VM部署单元)。
第三步:用Heat来启动生成具体的VM实例,如图下方的 VNF FWaaS,VNF vRouter等。
第四步: (在图中部)用 Mgmt Driver (管理驱动)来配置 VMs,通常会通过厂商EMS(如大家看到的 "Vendor Y Manager"),或者是SSH这样的简单手段。
第五步:SFC(Service Function Chain 服务功能链)的执行实现。这里例子用的是ODL 控制器,配合IETF的NSH(Network Service Header,网络服务包头)来实现服务链的执行。 NSH通过描述数据面的Header来沿着网络服务路径(Service Path)承载网络服务信息,意在实现与传输独立的“服务面”(Service Plane),可以与VXLAN,MPLS, UDP等传输封装协议配合。在NSH当前开源实现中可以支持OVS数据面(VXLAN)和ODL的控制面。细节这里不展开了,大家可以关注IETF NSH标准和ODL,OVS相关内容。
第六步: 监控VNF健康/可用性availability状况,出现问题是自动治愈回复(重新生成VNF,保证业务连续性)。
从上面的流程我们可以看到, tacker还依赖于OpenStack Heat编排组件。
5. Tacker主要功能
下面总结下Tacker的主要功能features:
l 贯穿 VNF 完整生命周期的工作流程管理
l 依照MANO框架的API
l 可调用(loadable)的健康监控及治愈恢复能力框架
l 参数化的(parameterized)TOSCAVNFD 模板
l VNF 用户数据注入(injection) 能力 (通过具体的plug-in drivers)
l VNF 初始化和更新配置注入
通过Tacker,大家其实希望能构建一个基于业界标准的开源开放NFV Orchestration 社区。
6. Tacker Roadmap及未来方向
Tacker 的roadmap和未来规划在OpenStackMitaka 版本和更远未来实现的重要功能区:
l 多 VIM支持(除完整云平台之外,VIM也有可能是Hypervisor层级的管理模块(如基于KVM),以适应运营商一些轻量级的需求,如小型vCPE等)
l VNF的高级设置(advanced placement): 利用CPU pinning,NUMA优化,SR-IOV和PCIpass-through等VNF性能优化技术
l VNF 扩展scaling:这里提下,现在运营商对自动扩展并不热衷,大多还要求有手动控制,自动会是未来功能,这里主要从scale out开始。
l 在VM之外的编排能力:之前提到过除了VNF,还有PNF需要管理编排,就是大家现在都提的 P+V,投资保护,成本,利旧,迁移演进,都是实在的价值....
l 另外还有基于Container 的NF (如Docker... )。