查看原文
其他

OpenStack Tacker (VNFMNFVO)概况及动态|华章KVM活动第15期

2015-12-07 张宇峰 云技术实践

嘉宾介绍:

张宇峰,Brocade大中华区CTO,十八年在中美两国 网络,通信,数据中心,云计算领域从事技术服务,产品管理,和市场战略工作。当前聚焦SDN/NFV/云网络技术面向中国市场的匹配优化创新,和开源开放生态合作平台建设。

主题介绍:

OpenStackTacker (VNFM/NFVO)概况及动态


以下为张宇峰分享实录:

大家晚上好!
今晚我跟大家分享的主题是 OpenStack Tacker 项目作为 open NFV 编排 (orchestration)的概况。

最近参加或看到东京OpenStack峰会keynote的同学们可能都知道, NFV/SDN 是当前OpenStack开发者和users(尤其运营商/服务商)都相当关注的热点,也是OpenStack社区内发展最快的领域之一。我也参加了这次东京峰会去了不少NFVsessions,气氛挺热烈,不少场都是满棚,站在门口听的。

换一个角度,OpenStack也已经成为NFV业界讨论中的重要部分。正如下面要谈到的ETSI MANO框架所反映的那样,OpenStack已经成为虚拟化基础设施管理(VIM)层的主要执行者。作为通过综合开放平台专注于推动NFV演进速度的开源项目,OPNFV正在其参考架构中利用OpenStack和OpenDaylight (ODL) SDN控制器。

就在这个OpenStack和 open NFV 行业生态发展融合的大背景下,出现了一个很火的 OpenStack内部孵化的新项目:Tacker. 在OpenStack东京峰会的Demo Theater里成了上座率最高的一场。


今天就跟大家分享下关于Tacker的几个基本话题:

1. Tacker是什么?

2. VNF Manager(VNFM) 和 NFV Orchestrator 的功能各自是什么

3. Tacker 的架构和基本流程

4. Tacker的主要功能汇总

5. Roadmap及未来方向

先看看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 InfrastructureManager (VIM)

先说第三块,VIM,简单说在今天分享背景下这里就是 OpenStack云平台,负责控制管理 NFV 相关计算,存储,网络资源。

而在整个这张图左边,跟VIM连着的大家一看就明白. 最下面是基本的Compute,Storage,Network 物理资源,上边盖着hypervisor,再上面是虚拟化后的虚拟资源,这就组成了所谓的 NFVI (I for Infrastructure 基础设施)。左边再向上就是具体的 VNF (虚拟化网络功能)实例和相关 EMS (Element Management System)管理系统,最顶上是支撑运营商业务的OSS/BSS

下面回到Tacker 核心模块:VNFM和NFVO。

第二部分,咱们看看 VNF Manager (VNFM) 和 NFV Orchestrator 的功能各自是什么

VNFM 主要有以下核心功能

· VNF 的创建和终结(调用VNFD目录)

· VNF设置(即 placement,调用 openstack Heat)

· VNF配置(主要用EMS)

· VNF监控(健康,性能等)

· VNF故障的自动治愈回复和扩展伸缩,支持各类简单和复杂的VNF

再看看NFVO的核心功能:

· 网络服务(Network Service)的编排 (用一系列的VNFs和转发图Forwarding Graph,此处可以想象糖葫芦,一串儿VNFs)

· 调用VNFM来做跨多个VIM的VNF安置(placement)

· 资源检查和分配

· 可以跨虚拟的(VNF)和物理的NFs(即PNF,Physical NF)

· 用 SDN controller 或 SFCAPI 来实现 VNF Forwarding Graph


为什么有对上面通用 VNFM 和NFVO 的诉求呢?

那大家来看看NFVO 和 VNFM 的好处有什么(这里主要面向运营商/服务商):

· 防止设备厂商锁定(运营商多年的梦想),运营商可以灵活部署从多个厂商提供的VNF
NFV orchestration 编排的流程基本是与具体 VNF 独立无关的 (VNF agnostic)

· VNF (厂商)具体的差异化可以通过业界标准化的 plugin插件和驱动来实现

· 最后,可以鼓励 NSD (Network Service Descriptor) 和 VNFD (VNF Descriptor)的标准化 (用 TOSCA NFV profile模板)。TOSCA是OASIS协会下的一个技术委员会, 负责针对云应用的拓扑与编排的开放规范, 这里细节不展开了

第三部分,一起看看Tacker 的架构和基本流程

上面提到不少概念,下面用张图描述下大家会比较清楚:




这张图先请大家注意下右边的VNFD catalog,这是运营商最喜欢的 VNF 服务目录。这里的例子是虚拟路由器,防火墙和EPC (移动网的Evolved Packet Core)。 这也就是刚才提到的TOSCA模板里用来描述服务的VNFD和NSD(D:Descriptor)。 NSD包括例如 SLA, VNF元素,forwardingGraph,支持的监控参数等。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等。

· 第四步: (在图中部)用 MgmtDriver (管理驱动)来配置 VMs,通常会通过厂商EMS(如大家看到的 "Vendor Y Manager"),或者是SSH这样的简单手段。

· 第五步:SFC (Service FunctionChain 服务功能链)的执行实现。这里例子用的是ODL 控制器,配合IETF的NSH(NetworkService 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印象。

第四部分,下面总结下Tacker的主要功能features

· 贯穿 VNF 完整生命周期的工作流程管理

· 依照MANO框架的API

· 可调用(loadable)的健康监控及治愈恢复能力框架

· 参数化的(parameterized)TOSCAVNFD 模板

· VNF 用户数据注入(injection) 能力 (通过具体的 plug-in drivers)

· VNF 初始化和更新配置注入

最后,通过Tacker,大家其实希望能构建一个基于业界标准的开源开放NFV Orchestration 社区。


第五部分,看一下Tacker的Roadmap及未来方向

这些是当前计划在OpenStackMitaka 版本和更远未来实现的重要功能区:

· 多 VIM支持(除完整云平台之外,VIM也有可能是Hypervisor层级的管理模块(如基于KVM),以适应运营商一些轻量级的需求,如小型vCPE等)

· VNF的高级设置 (advanced placement): 利用CPU pinning,NUMA优化,SR-IOV和PCI pass-through等VNF性能优化技术,大家可能会想到Intel的DPDK优化

· VNF 扩展scaling:这里提下,当前运营商对自动扩展并不热衷,大多还要求有手动控制,自动会是未来功能。而且,当前主要从scale out开始

· 在VM之外的编排能力:之前提到过除了VNF,还有PNF(物理设备)需要管理编排,就是大家现在都提的 P +V,投资保护,成本,利旧,迁移演进,都是实在的价值....

· 另外还有基于Container 的 NF ,如Docker,加些 fun stuff...

大家有兴趣可以考虑参与 Tacker,这里一些资源链接 :


Code Repositories


Blueprints


IRC (freenode):
channel: #tacker

Wiki

Brocade有幸加入Tackercore team,在最近东京OpenStack峰会和OPNFV等多个NFV相关会事上都在积极参与和开源社区业界同行及市场用户的交流互动。

群友提问

问题1.NFV和SDN有哪些区别,NFV以后的发展趋势是什么?

答: NFV聚焦网络功能虚拟化,x86加开源开放软件,降低成本,提高灵活性,SDN更多关注控制转发分离,全局资源可视性和控制,及可编程性,支持资源最有利用和基于应用需求驱动的网络应用创新,NFV趋势:与SDN结合,通过SDNcontroller(或类似能力)实现灵活动态 SFC 服务功能链,以实现业务敏捷最大化。另外,NFV优化,刚才提的DPDK, CPU pinning,SRIOV/PCI pass through等。

问题 2. NFV在open stack环境能否取代neutron网络节点,来实现open stack 网络功能

答: Neutron自身的网络功能在不断成熟完善,实现的结果也可以说是广义上的NFV。聚焦NFV的商业产品或开源项目都有可能通过Plug-in成为与Neutron配合的整体方案(比如Brocade的vRouter通过ML2plug-in)。结果不是为了取代Neutron网络节点,而是提供*当前*Neutron还没有实现的但是企业级用户需要的功能,或是对性能,稳定性,和高可用性的要求。运营商的情况又稍有不同,这里NFV本身就是运营商核心业务的一部分(如各类vCPE和vEPC等), Neutron的功能主要是今天提到的在MANO framework里作为计算存储资源提供方的VIM以及通过HEAT来辅助NFV orchestration。

问题3. 未来NFV能否替代传统网络设备来提供网络扩展部署

答: 对,这是大趋势,只是时间问题。所以大家能看到NFV的火爆发展,包括 Intel和RedHat这样的软硬产业巨头对NFV的强大推动。未来的网络创新更多属于软件。

问题4.NFV对底层hypervisor(kvm,xen,vmware)兼容性,哪个兼容性好些?

答:这个话题很实际,主要有商业部署现实推动。当前 KVM 第一,因为是 Linux world 和开源开放的首选,和open stack,open Daylight 等各类基于Linux的开源项目基因最近,VMware 企业市场很广,所以位居第二。

问题5:tacker官网有完整的demo吗? 整合open stack和ODL的?

答:东京openstack 峰会有 demo, 是否在tacker官网要查下,和open stack 结合是必须的,ODL的 SFC 配合是work in progress

问题6:VNFM的弹性控制 scale in/out 是需要一个闭环的控制和监控的,尤其是在跨VNF厂家时。这个如何解决呢。另外中国的运营商非常注重这个。

答:scaling细节我还没机会深入了解,还是有不少工作要做的,所以刚才提到这是未来重要dev领域之一。

问题7:VNFM如何和SDN Controller配合,貌似目前无解吧

答:刚才刚提过,和SDN controller配合 ODL 就是计划途径之一,结合SFC(参照IETF NSH), 工作进行中。


问题8: vRouter 本身是否能支持网络流量控制,QOS,攻击防范等

答:各家产品层面功能会有不一样,Brocade的vRouter和vFW是一体产品,有基本FW, QoS功能。高级流控和抗D等功能我们可以通过基于ODL的SDN controller及SDN应用(如Brocade的Flow Manager)配合支持open flow的 underlay switch 一起实现。



以上内容由迅达云编辑整理


云技术实名群

欢迎加入“云技术实名群”,入群要求如下:

1 工作满5年;

2 目前从事云相关技术工作;

3 实名;

4 愿意分享。

入群联系北极熊


云技术问题必答群

经常有朋友交流问题,有些朋友交流的都是相同的问题,突然有一个想法,能不能将这些问题统一整理编号,碰到类似的问题,大家可以先去找找,有没有已经比较好的答案。


于是创建了一个群“云技术问题必答群”


群宗旨,任何云技术问题群主发动一切资源解答,群主也拉了一些认识的云计算经验比较丰富的朋友,大家可以一起交流

进群必须严格群规:

1 问题得到解答群里发不低于10元,不超过10个的红包。
2 本群不能随意拉人,拉人必须群主或者北极熊,随意拉人罚红包100或者踢。

3 讨论话题必须是技术或者云行业相关。

需要进群者,请联系北极熊



您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存