该篇文章系SDN实战团微信群（团长张宇峰@brocade）组织的线上技术分享整理而成，该篇文章由团主张宇峰分享的OpenStack Tacker项目作为open NFV编排（orchestration）的概况。
嘉宾介绍
--------------------------------------------------------------------------
张宇峰，Brocade大中华区CTO，十八年在中美两国网络，通信，数据中心，云计算领域从事技术服务，产品管理，和市场战略工作。当前聚焦SDN/NFV/云网络技术面向中国市场的匹配优化创新，和开源开放生态合作平台建设。
分享正文
-------------------------------------------------------------
今晚跟大家分享的主题是OpenStack Tacker项目作为open NFV编排（orchestration）的概况。
最近参加或看到东京OpenStack峰会keynote的同学们可能都知道， NFV/SDN是当前OpenStack开发者和users（尤其运营商/服务商）都相当关注的热点，也是OpenStack社区内发展最快的领域之一。我也参加了这次东京峰会去了不少NFV sessions，气氛挺热烈，不少场都是满棚，站在门口听的。从另一个角度，OpenStack也已经成为NFV业界讨论中的重要部分，正如下面要谈到的ETSI MANO框架所反映的那样，OpenStack已经成为虚拟化基础设施管理（VIM）层的主要执行者。作为通过综合开放平台专注于推动NFV演进速度的开源项目，OPNFV正在其参考架构中利用OpenStack和OpenDaylight (ODL) SDN控制器。
就在这个OpenStack和 open NFV 行业生态发展融合的大背景下，出现了一个很火的 OpenStack内部孵化的新项目：Tacker，在东京峰会Marketplace 的Demo Theater里成了上座率最高的一场。
今天就跟大家分享下关于Tacker的几个基本话题：
- Tacker是什么？
- VNF Manager （VNFM) 和 NFV Orchestrator 的功能各自是什么
- Tacker 的架构和基本流程
- Tacker的主要功能
- Roadmap及未来方向
1.Tacker是什么
Tacker是基于NFV标准组织ESTI的MANO架构来实现通用的（generic） NFV编排和VNF管理需求的一个OpenStack服务，ESTI MANO中的缩写MANO是指NFV的MANagement and Orchestration ，ESTI MANO详细背景这里不全面展开，大家可以 baidu、google, bing到很多细节，我们用一张图可以先看个大概：
这张图描述的就是MANO的全景。它产生的背景主要是基于运营商服务商对网络功能虚拟化做通用管理的诉求，MANO具体的功能模块是图中右半段，而Tacker 所聚焦的是红框中的两个模块：NFV Orchestrator (NFVO) 和VNF Manager（VNFM)，MANO 的第三块是Virtualized Infrastructure Manager (VIM)。
先说第三块，VIM，简单说在今天分享背景下这里就是 OpenStack云平台，负责控制管理 NFV 相关计算，存储，网络资源，而在整个这张图左边，跟VIM连着的大家一看就明白，是基本的Compute，Storage， Network 物理资源，上边盖着hypervisor，在上面是虚拟化后的虚拟资源，这就组成了所谓的 NFVI （I for Infrastructure 基础设施），左边再向上就是具体的 VNF (虚拟化网络功能）实例和相关 EMS （Element Management System）管理系统，最顶上是支撑运营商业务的 OSS/BSS。
下面回到 Tacker 核心模块：VNFM和NFVO。
2.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 或SFC API来实现 VNF Forwarding Graph
来看看 NFVO 和 VNFM 的好处有什么（这里主要面向运营商/服务商）：
- 防止设备厂商锁定（运营商多年的梦想），运营商可以灵活部署从多个厂商提供的VNF。
- NFV orchestration 编排的流程基本是与具体 VNF 独立无关的 （VNF agnostic）
- VNF （厂商）具体的差异化可以通过业界标准化的 plugin插件和驱动来实现
- 最后，可以鼓励 NSD (Network Service Descriptor) 和 VNFD （VNF Descriptor）的标准化 （用 TOSCA NFV profile模板）. TOSCA是OASIS协会下的一个技术委员会, 负责针对云应用的拓扑与编排的开放规范, 这里细节不展开了。
3.Tacker 的架构和基本流程
不少概念，下面用张图描述下大家会比较清楚：
这张图先请大家注意下右边的VNFD catalog。这是运营商最喜欢的 VNF 服务目录, 这里的例子是虚拟路由器，防火墙和EPC （移动网的Evolved Packet Core），下面的就是刚才提到的TOSCA模板里用来描述服务的VNFD和NSD （D：Descriptor）。 NSD包括例如 SLA, VNF元素，forwarding Graph，支持的监控参数等。VNFD包括例如与初始化/终结脚本的链接，内部外部的网络连接（connectivity），VNF之间的相关，和 VDU（Virtual Deployment Unit）的描述（比如VM指标：对计算、存储，高可用要求等等）
现在咱们在同一张图上加上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，保证业务连续性）。在之前提到的OpenStack东京峰会Demo Theater，Tacker 项目core team做过演示，用ping做基本监控，然后模拟failure （通过blocking ICMP），Tacker自动检测到，然后重建恢复VNF功能。
希望通过上面这张核心功能流程图能给大家一个更动态的Tacker印象。
4.Tacker的主要功能
下面总结下Tacker的主要功能features：
- 贯穿 VNF 完整生命周期的工作流程管理
- 依照MANO框架的API
- 可调用（loadable）的健康监控及治愈恢复能力框架
- 参数化的（parameterized）TOSCA VNFD 模板
- VNF 用户数据注入（injection) 能力 (通过具体的 plug-in drivers）
- VNF 初始化和更新配置注入
通过Tacker，大家其实希望能构建一个基于业界标准的开源开放NFV Orchestration 社区。
5.Roadmap及未来方向
最后大家看下Tacker 的roadmap和未来规划。这些事当前计划在OpenStack Mitaka 版本和更远未来实现的重要功能区：
- 多 VIM支持（除完整云平台之外，VIM也有可能是Hypervisor层级的管理模块（如基于KVM），以适应运营商一些轻量级的需求，如小型vCPE等）
- VNF的高级设置 （advanced placement）： 利用CPU pinning，NUMA优化，SR-IOV和PCI pass-through等VNF性能优化技术
- VNF 扩展scaling：这里提下，现在运营商对自动扩展并不热衷，大多还要求有手动控制，自动会是未来功能，这里主要从scale out开始。
- 在VM之外的编排能力：之前提到过除了VNF，还有PNF需要管理编排，就是大家现在都提的 P +V，投资保护，成本，利旧，迁移演进，都是实在的价值....
- 另外还有基于Container 的 NF （如Docker，fun stuff... )。
大家有兴趣可以考虑参与 Tacker，这里一些资源链接 ：
Code Repositories：
http://git.openstack.org/cgit/openstack/tacker
http://git.openstack.org/cgit/openstack/python-tackerclient
http://git.openstack.org/cgit/openstack/tacker-horizon
Blueprints：
http://git.openstack.org/cgit/stackforge/tacker-specs
IRC (freenode):
channel: #tacker
Wiki：
https://wiki.openstack.org/wiki/tacker
Brocade有幸加入Tacker core team，在最近东京OpenStack峰会和OPNFV等多个NFV相关会事上都在积极参与和开源社区业界同行及市场用户的交流互动。 据了解国内九州云（99Cloud）和UnitedStack也开始参与Tacker了，希望有兴趣的朋友们更多一起来加入推动这个蛮cool的开源新项目。我今天分享就到这里，谢谢大家。
Q&A
Q1：第四步中，使用Mgmt Driver来配置VMs，如果没有理解错的话VMs应该处于租户网络（Tenant X network）中，而租户网络一般是隔空的网络（如OpenStack私有网络），而Tacker的Mgmt Driver应该是在控制平面的网络，想问的是使用什么方法打通控制平面的网络与租户网络，从而能够使用ssh对VMs进配置？
A：好问题，VNF（如 vRouter）确实会针对租户分配，但也会有管理网络接口，安全会有相应控制，所以不存在“打通”租户/管理网络的需要。VIM会给VNF配置管理网口，mgmt driver通过这个管理网口配置VNF，monitor driver也通过管理网trap或者ping，http实现监控。
Q2：其实还有疑问，就是这里面的ODL和Neutron之间的关系
A：如果从SFC实现这块看，是个选项关系， 可以用ODL，也可以用Neutron现在正在develop的SFC API。 ODL会使用NSH。Tacker 来驱动SFC需求指标，配置实现用ODL or其他机制。
Q3：MANO中都有哪些module上了Brocade的road map了？
A：Brocade在积极参与Tacker开源项目，产品发展大方向是与Tacker的VNFM/NFVO方向一致的。但当前围绕更广的MANO框架的标准组织动态（联盟，整合等）是正在进行时，OPNFV, OpenMANO, Linux Foundation, WoMANO，Open-O等等，产品roadmap规划细节为时还早。
--------------------------------------------------------------------------
SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立，携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛，每周都会组织定向的技术及业界动态分享，欢迎感兴趣的同学加微信：eigenswing，进群参与，您有想听的话题可以给我们留言。