原文链接：https://blog.csdn.net/bc_vnetwork/article/details/51463518
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项目。
Tacker概述
Tacker是一个在OpenStack内部孵化的项目, 他的作用是NVF管理器，用于管理NVF的生命周期。 Tacker的重点是配置VNF, 并监视他们。如果需要，还可重启和/或扩展（自动修复）NVF。整个进程贯穿ETSIMANO所描述的整个生命周期。
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, 即业务链。
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编排组件。
Tacker主要功能
下面总结下Tacker的主要功能features：
l 贯穿 VNF 完整生命周期的工作流程管理
l 依照MANO框架的API
l 可调用（loadable）的健康监控及治愈恢复能力框架
l 参数化的（parameterized）TOSCAVNFD 模板
l VNF 用户数据注入（injection) 能力 (通过具体的plug-in drivers）
l VNF 初始化和更新配置注入
通过Tacker，大家其实希望能构建一个基于业界标准的开源开放NFV Orchestration 社区。
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... )。