虚拟实验室NFV实现及测试方法研究

第一章绪论

1.1 NFV的定义

[1]NFV,即网络功能虚拟化,Network Function Virtualization。即通过使用x86的服务器作为物理设备,进而实现基于软件的网络功能。NFV的实现有效地降低了网络组网中昂贵的路由器和交换机成本。通过分离硬件和软件的功能和抽象的方式,网络设备功能不再依赖于专用硬件资源,可成为新的云中的网络服务部署模式,虚拟网络元件之间的网络,基于实际业务需求自动部署,提供了灵活扩展性,故障隔离和自我愈合。

通过使用业界标准的x86服务器,存储和交换设备,以取代那些专用厂商的通信网络专用网络设备。[2]由此带来的好处是,一方面是使得设备的成本降低,基于x86的IT设备的标准,可以节省巨大的投资成本,另一方面开放了网络设备的API接口,还可以得到更多和更灵活的网络能力。

1.2 NFV的使用场景

NFV利用虚拟化技术来实现软件和硬件的解耦,实现了分层网络的维护和设备管理的功能,实现了动态资源调度,大幅降低了网络建设和维护成本。

NFV网络功能集成到行业标准的服务器,交换机和存储设备上,服务器上运行的OpenStack提供虚拟化平面,NFV使管理员能够取代传统的物理网络设备,取而代之的是虚拟化的NFV网元。从而达到降低成本,减少能源消耗和减少了网络的复杂性的目的。

NFV支持虚拟化的网元来实现网络的灵活性,服务保证,测试以及诊断。NFV为OpenStack平台的网络带来新的网络组件。NFV的网络功能虚拟化就是将原本是物理设备的路由器,交换机,测试仪器,变成软件的形式,作为一个镜像启动,而其功能不变。[3]在云计算的基础设施平台上,部署基于NFV可编程网元,这些网元不受物理设备兼容性的限制,在云计算的基础上部署虚拟网元,使得云平台的资源利用率更加充分,但同时也对组网技术提出了更高的要求。网络云化(NFV)是网络变革的必然选择。[4]如今的数据中心有很大一部分是部署OpenStack云的。那么而NFV的使用场景中,必然需要和OpenStack云进行结合。虚拟网元在云计算OpenStack平台中需要的只是一些虚拟资源,例如计算资源、网络资源。虚拟网元是基于x86服务器的,即实验室不需要购买昂贵的厂商定制的路由器和交换机,而可以使用NFV网元的方式在云平台上进行组网。

1.3 目标与内容

目前大多数的教育机构的实验室实体设备都存在灵活性低的问题。虚拟实验室一方面不断在专用硬件设备、基础设施上加大投资,另一方面学生在实验拓扑变得越来越复杂,占用的物理设备的数量增加。这就是所谓的“剪刀差”。当设备类型越丰富、数量越多、拓扑越多样的时候,用户能够享受的教学规模也越大。但由于资金、场地等各方面的因素限制,实体实验室能够提供的设备数量有限,设备的类型也单一,一般都是指定某个厂商、固定的设备配置等。可支持学生进行网络实验的网络拓扑也无法多样化。基本上大中型实验项目无法拓展,因此也导致用户无法将自身所学的专业技能发挥到实际项目中,网络规划与设计综合技能有待提高。

在物理的实验室中,用户同时进行实验可能需要数百台物理的交换机或者路由器,如果仅靠使用物理设备进行实验去完成这一系列的路由交换的实验将耗费大量的工作时间。这就是使用虚拟的路由器网元进行实验的优势。

物理的实验室变成基于x86的NFV虚拟网元组成的实验室平台,那么在基础设施服务层面需要有个云计算平台给NFV的虚拟网元进行孵化并组网。由于物理实验室要进行虚拟实验室的转型。那么在虚拟实验室的搭建过程中需要对OpenStack的和规划和部署充分了解。需要充分利用实验室中的物理机资源。由OpenStack进行物理层的抽象,提供一个云资源环境,而NFV的路由器网元部署在OpenStack云资源环境中,最后让做实验的师生们能够访问该NFV的虚拟路由器网元。而且需要提供Web界面给师生们使用,在使用的时候需要对资源有占用时间的规划,如一节课(45分钟)时间,时间结束后需要将占用的资源释放等需求。[1]在网络测试的课程中,由于使用厂商专有的测试设备价格昂贵,而且端口数量有限。需要使用虚拟化的测试网元来代替昂贵的物理的测试端口

第二章 项目需求

仿真软件不能进行“网络测试分析”实验课,也不方便实验室的统一管理,因此需要引进NFV虚拟网元;实验室网线部署和设备的部署增加了运维;物理设备价格昂贵且容易宕机需要部署虚拟环境云计算OpenStack平台;云计算平台与NFV虚拟网元的结合才能搭建完整的虚拟实验平台提供给师生使用。NFV虚拟网元之间需要有虚拟化支持和网络连通性,才能进行组网完成网络相关实验。使用NFV虚拟的测试网元对整个环境进行测试,保证虚拟实验平台的可用。

2.1 需求分析

而且由于物理设备的有限。学生做实验的时候通常需要分批来进行,要是需要某一台物理的设备宕机了,可能就导致实验进行不下去。因此在物理设备上做实验的问题更加容易出现。一旦物理设备的宕机,如果采购不及时,那么便会长时间影响做实验的效率和课程的进度。

如果学生使用仿真软件进行试验的话,如使用Cisco的VIRL或者使用GNS3等仿真的话,学生均在自己笔记本上进行操作,造成了任务的管理的不方便,而且Cisco的VIRL或GNS3不能进行扩展,只能对软件内包含的特定虚拟镜像进行操作,扩展性不强,而且没有测试的端口包含,不能进行“网络测试分析”的实验课。

物理设备价格昂贵,对于网络工程专业来说,在“路由与交换”、“网络性能测试”的课程中需要用到的路由器和测试设备的价格都很昂贵,一般的实验室只能少批量的采购,由此学生在进行实验课的预习等均会受到物理条件的制约,影响了学生的学习效率。
由此需要将物理的实验室变成基于x86的NFV虚拟网元组成的实验室平台,那么在基础设施服务层面需要有个云计算平台给NFV的虚拟网元进行孵化并组网。而且需要提供Web界面给师生们使用,在使用的时候需要对资源有占用时间的规划,如一节课(45分钟)时间,时间结束后需要将占用的资源释放等需求。由此需要进行云计算平台OpenStack的搭建。

由此综上所述,本章针对虚拟环境管理的需求有以下几点:
1)物理实验室需要转型为虚拟实验室;
2)选择合适的NFV虚拟网元;
3)OpenStack需要对NFV虚拟网元的虚拟化支持;
4)OpenStack需要对NFV虚拟网元的网络连通性支持;
5)需要整个虚拟实验室进行功能性能测试

图2-1 虚拟实验室需求

2.2 特定NFV虚拟网元的需求

在OpenStack平台中部署的NFV虚拟网元需要满足“路由与交换”以及“网络性能测试”应该具备以下的特点。

特定NFV虚拟网元需要与Cisco或者华为的设备的命令类似。对网络知识的配置思想需要相同。而且支持在云环境中正常运行,在师生们做了相关的配置之后,需要按照配置进行路由的选择和流量的转发。可以支持多设备在云计算平台中的拓扑组网,完成比较复杂的实验。由于在虚拟实验室中组网的设备是基于x86服务器的NFV虚拟网元,这些网元需要有虚拟的网卡接口,需要满足学生做实验时配置交换机和路由器时的命令窗口。

师生在配置过程中可以Reserve特定的时间(如45分钟),等约定的时间到了,云平台会自动删除该师生创建的NFV虚拟网元,来保证云平台中一直有空闲的资源留给后续的实验进行。

2.3 OpenStack对NFV虚拟网元的支持需求

2.3.1 虚拟化支持需求

NFV虚拟网元在OpenStack云中需要有虚拟化的支持,即OpenStack云平台提供虚拟化,NFV虚拟网元可以在云平台中启动并正常工作。NFV是一个虚拟的镜像,镜像的启动需要有计算资源,内存资源,组网还需要有网络资源。有了虚拟化的支持才能启动NFV的虚拟网元。

目前在开源社区有很多基于NFV的虚拟的路由器,例如VyOS,OpenWRT等。可以将这些镜像加入到虚拟实验室的云计算平台中,满足虚拟实验室的实验需求。

在NFV虚拟网元中有一些开源的路由器的镜像,这些镜像有良好的社区支持,稳定的性能。适合在虚拟实验室云计算平台上进行部署。

2.3.2 网络连通性需求

NFV的虚拟网元之间需要进行网络的互相连通,在虚拟实验室中,师生们需要将NFV的虚拟网元进行组网,形成实验拓扑,而其中的NFV虚拟网元则是交换机和路由器,那么这些交换机和路由器之间需要有网络的连通,基于网络的连通性才能进行相关的路由器和交换机配置使得流量能有基于策略的选择路由和流量转发。

[5]使用基于NFV和ASIC可编程网元的敏捷组网技术,使用Linux bridge将网元之间的网络进行桥接连通,在云计算平台OpenStack Neutron组件的帮助下,实现基于虚拟OpenvSwitch交换机的网络交换,使得NFV和ASIC网元的流量的交换和转发得以实现。

在OpenStack中的网络则是通过Neutron组件进行的。那么NFV的虚拟网元加入到OpenStack中,对Neutron中的虚拟交换机(OpenvSwitch)的兼容性提出了要求,而且在网络工程的实验中不仅需要网络的连通性,还需要基于网络协议的实现。如RIP、OSPF等网络协议也需要在云计算平台中正常工作,满足师生们的实验要求。

2.3.3 OpenStack中NFV虚拟网元的测试需求

在云计算平台的搭建完成之后进行NFV的虚拟网元的组网,在组网完成之后,需要对整个网络进行网络的功能和性能的测试,由于该虚拟实验室是开放给网络工程的师生们使用,必须OpenStack平台对NFV虚拟网元的虚拟化支持功能和对网络拓扑的连通性,以及NFV虚拟网元的配置路由协议(如RIP、OSPF)等网络协议是否生效进行测试。在测试通过之后才能开放该虚拟实验室。

2.4 项目复杂度分析

本项目要求工程师能通过项目调研过程掌握虚拟实验室的物理结构,并对OpenStack云平台进行分析,分析虚拟实验室针对网络工程专业的实验课程需求设计解决方案。而且在NFV虚拟网元在OpenStack平台上正常运行的相关资料非常少,特别是在虚拟化实现和网络连通性的实现上,有很多创新点。大部分时间都需要自己依靠基础知识进行摸索。整个研究内容所涉及到的技术之多以及项目工程的复杂度正是我面临的挑战。项目涉及到了虚拟化和网络的方方面面。这个项目是企业真实项目的一部分。必须在思博伦通信科技(北京)有限公司搭建的虚拟实验室中进行操作和研究,时间和地点上都有严格的要求。这样也加大了整个项目的难度。

第三章 技术背景

虚拟实验室部署的OpenStack需要满足物理资源虚拟化的基本需求。而且由于是生产环境,必须提供高可用部署方案。对NFV虚拟网元的选择上,需要满足路由与交换的配置命令,本文选择了VyOS和OpenWRT。在OpenStack虚拟化技术中Nova调用Libvirt技术。而OpenStack网络技术中Neutron是由虚拟的接口,网桥和Open vSwitch组成的,Neutron提供ML2 Plugin的启动网元方式。在测试中,利用了Spirent的STC软件,vSTC虚拟端口以及Velocity界面。

3.1 虚拟实验室OpenStack的部署方案

目前业界有许多云计算技术,主流的有OpenStack、CloudStack等。云计算平台目前较为成熟的是OpenStack方案。

OpenStack包含了一组由社区维护的开源项目,主要项目有Compute (Nova), Object Storage (Swift),Image Service(Glance),Network Service (Neutron)。 Nova提供虚拟计算服务,Swift提供存储服务,Glance提供虚拟机镜像的注册、分发服务,Neutron提供网络服务。

虚拟实验室云计算平台基于OpenStack平台进行实验。虚拟实验室需要进行网络、计算、存储资源的虚拟化,并且提供HA功能。在实验室的x86服务器上进行功能划分。由两台服务器作为Controller节点,两台服务器作为Network节点,剩余机器作为Compute节点。由Controller提供管理服务。Network节点提供网络服务,Compute节点提供计算服务。
虚拟实验室组件的服务类别如图3-1所示

图3-1 虚拟实验室OpenStack组件介绍

在虚拟实验室环境中,为了兼顾性能和可靠性,Keystone进行访问管理,Nova组件进行虚拟化的支持技术,Glance进行镜像的存放和管理,Neutron则是对OpenStack的网络进行管理和调度。Horizon是提供Web界面可以使得温州大学的师生能够访问。最后使用Cinder和Swift进行存储资源的管理调度。

在虚拟实验室的Controller节点上面部署了虚拟镜像文件管理服务glance-registry,以及API的服务glance-api,消息队列服务service rabbitmq-server,以及Web界面的Horizon服务apache服务。nova-api暴露API使得Compute节点的nova-compute接受来自用户的消息,nova-cert提供资源认证服务,nova-scheduler提供资源调度机制,nova-conductor执行虚拟化资源的分配。

在虚拟实验室的Network节点部署网络服务有关的neutron-server,neutron-server接受来自用户Web点击时的操作,对Compute节点的网络agent进行控制,neutron-l3-agent实现对外部网络访问机制。从而实现对Compute节点上的网络的管理和调度。从而对部署在OpenStack之上的NFV虚拟网元进行网络资源的管理。

在虚拟实验室Compute节点上部署了虚拟化组件nova-compute可以提供给Instance虚拟环境的支持,在Instance网络提供方面通过neutron-plugin-openvswitch-agent进行网络连通,neutron-dhcp-agent提供DHCP服务,可以对部署在OpenStack之上的NFV虚拟网元进行计算和网络资源的提供、调度、删除、认证等功能。

网络规划方面,虚拟实验室私有云主要使用Neutron的网络服务,使用Openvswitch的plugin以及Vxlan的Overlay技术的网络模式,多个VLAN标签的划分分别为提供给虚拟机固定IP网络,网络浮动IP网络,外部网络。

3.2 NFV虚拟网元介绍

VyOS是从Vyatta的社区中fork而来的网络操作系统,该软件提供基于网络的路由,防火墙和VPN的功能。 VyOS是基于Debian GNU / Linux系统的。 VyOS运行在物理和虚拟平台,支持集成包对虚拟机和虚拟平台。VyOS可作为虚拟机部署,VyOS可以被OpenStack云管理,系统作为实例运行,操作系统在云环境中运行,可实现多租户路由,防火墙,以及负载均衡等功能。

另一个NFV的虚拟网元则是OpenWRT。OpenWRT是嵌入式设备上运行的linux系统。在其中加入quagga软件包之后可以实现RIP、OSPF等路由协议的仿真。OpenWRT本身只有10多M大小,占用的资源相当少。并且附带3000左右的软件包,用户可以方便的自定义功能来制作固件。而且OpenStack对OpenWRT也有很好的支持,由此可以将OpenWRT作为NFV虚拟网元加入到虚拟实验室的云平台中。

3.3 OpenStack的计算虚拟化技术

OpenStack提供虚拟化的组件是Nova,Nova是云主机虚拟化功能服务提供者。它包含了很多组件,API(nova-api),计算组件(nova-compute),网络组件(nova-network),调度组件(nova-schedule),卷控制组件(nova-volume),消息队列(Queue)以及Web界面DashBoard。

Libvirt 库是一种实现 Linux 虚拟化功能的 Linux API,它支持各种虚拟机监控程序,Nova通过调用Libvirt标准接口实现KVM、LXC、QEMU、UML和Xen的虚拟平台管理机制。其中KVM是nova-compute中Libvirt默认调用的底层虚拟化平台。

图3-2 Nova组件结构

Libvirt为各种虚拟化工具提供一套方便、可靠的编程接口,用一种单一的方式管理多种不同的虚拟化提供方式。

上层管理平台(如nova-compute)由管理程序支持Libvirt来实现虚拟机的生命周期管理。Libvirt的目前支持以下基本的虚拟化平台:

表3-1 Libvirt支持的虚拟化平台

虚拟机监控程序

描述

Xen 面向IA-32,IA-64和PowerPC 970架构
Qemu 面向各种架构的平台仿真器
KVM Linux平台仿真器
LXC 用于操作系统虚拟化的Linux容器
OpenVZ 基于Linux内核的操作系统级虚拟化
VirtualBox X86虚拟化虚拟机监控程序
User Mode Linux 面向各种架构的Linux平台仿真器
Test 面向伪虚拟机监控程序的测试驱动器
Storage 存储池驱动器

Nova调用底层虚拟机监控程序(如KVM/ QEMU等)和对虚拟化功能的管理主要通过LibvirtDriver类来实现。

3.4 OpenStack的网络实现技术

Neutron Server在Neutron服务充当“头”的角色(RESTful),负责接收外部API(服务)的要求,如NovaAPI请求创建一个网络。

Neutron Plugin在中间层充当了“使者”的角色,负责将Neutron Server接受到的信息传达给Neutron agent。
Neutron Agent位于最下一层,充当“工作”角色,负责具体任务和操作执行。比如创建子网等具体任务。

整个物理网络被Neutron服务虚拟化为网络资源池。利用网络资源池的可扩展性,Neutron可以为每个租户创建独立的虚拟网络环境。Neutron提供的网络服务是通过将物理的网络资源虚拟化成L2,L3层的虚拟网络资源。分别对应于一个物理网络环境的交换机和路由器。以下是Neutron网络功能的具体实现:

路由器:为租户提供路由,NAT等服务。
网络:对应于一个2层的物理网络层LAN(VLAN),从租户角度来看,网络是私有的。
子网:指定IPV4或IPv6地址,并描述其相关的配置信息而创建的网络。它被连接到一个二层网络中,指定这个网络可以使用的IP地址的范围。

1. Linux的虚拟网络
由虚拟NIC(vNIC)提供虚拟机的虚拟网卡功能,管理程序可以为每个虚拟机创建一个或多个虚拟网卡,实现与传统物理网络的物理网卡相同的网卡功能,交换机也被虚拟化为虚拟交换机(OpenvSwitch),每个虚拟网卡连接Open vSwitch的端口(BR-INT),访问外部网络需要通过物理网卡,因此最后的Open vSwitch需要接入外部物理网络。

在Linux环境下的虚拟网络设备有以下几种形式:

图3-3 网络设备的虚拟化形式

1)TAP/TUN/VETH
TAP/ TUN/ VETH是一对虚拟网络设备,二层的TAP收发的是MAC层数据帧,在三层的TUN,接收的是IP数据包。VETH设备是成对出现的,所接收的数据的一个端部会从另一端送出,可以理解为一个虚拟网络电缆。

2)Linux Bridge
Linux的网桥(基于Linux内核实现)提供二层的网络功能。其原理是,通过结合到自身的其他Linux的网络设备,连接这些设备到虚拟端口。

3)Open vSwitch
虚拟交换机负责连接到物理网络适配器的vNIC,我们可以像在相同的物理交换机的配置中,接入到OpenvSwitch上的每个虚拟机被分配到不同的VLAN网络隔离。可以在OpenStack环境中运行多个vSwitch的可组成分布式虚拟交换机架构。

图3-4 Neutron组件结构

2.Neutron Plugin
Neutron服务中neutron-server运行在网络控制节点上,提供的RESTful API作为访问入口。Neutron项目采用代码的Plugin插件方式,每个插件API支持一组资源,完成特定的操作,最终由插件代理通过调用适当的RPC来完成。

3.ML2 plugin

图3-5 ML2 plugin结构

ML2实现的网络/子网/端口三大核心资源,ML2实现网络拓扑结构(扁平,VLAN VXLAN,GRE)和底层虚拟网络(Linux的网桥,OVS)分离机构的类型,并使用扩展驱动的方式。其中,Mechanism Manage管理不同种类的的驱动程序,不同的网络实施机制对应不同的网络形式(如Linux bridge,OVS,NSX等)。

3.5 测试方法及工具基本介绍

网络测试是指以科学的方法,如何通过测量手段/工具,取得网络产品或正在运行网络的性能 参数和服务质量参数,这些参数包括可用性、差错率、吞吐量、时延、丢包率、连接建立时间、故障检测和改正时间等。

主要面向的是交换机、路由器、防火墙等网络设备,可以通过手动测试或自动化测试来验证该设备是否能够达到既定功能。

3.5.1 测试方法简介

[6]网络测试主要面向的是交换机、路由器、防火墙等网络设备,可以通过手动测试或自动化测试来验证该设备是否能够达到既定功能或者性能。通过一定的网络拓扑结构进行设备连接,测试交换机、路由器的性能,如吞吐量、延迟、丢包等指标,更可以在一个端口中模拟上千万个网络的数量,并可以对其各自的性能进行分析。

在虚拟实验室的云平台中采用的NFV的虚拟路由器网元,通过云平台提供的网络进行相互之间的连接,在云平台网络拓扑的两端加入虚拟测试端口,发送仿真的流量,对云平台网络拓扑中的NFV虚拟路由器网元的功能和性能的测试。
3.5.2 Tcpdump介绍
Tcpdump能够在数据包“头”完全截获分析。它支持用于过滤网络层协议,主机,网络或端口,并提供与,或,非等逻辑语句。 Tcpdump的是一个免费的网络分析工具,提供特别的源代码,开放的接口。

Tcpdump可根据用户的数据包截获上的网络数据包进行分析。作为互联网上经典的的系统管理员必不可少的工具,Tcpdump的其强大的功能和灵活的策略拦截,成为网络系统管理员的一个分析,解决问题的必要手段。

3.5.3 Spirent TestCenter介绍

Spirent TestCenter有美国思博伦公司生产。Spirent TestCenter是数据通信领域广泛认同的、能够对于网络及设备进行性能测试和评估分析的标准测量仪表。帮助用户测试交换机、路由器的性能,如吞吐量、延迟、丢包等指标,更可以在一个端口中模拟上千万个网络的数量,并可以对其各自的性能进行分析,测试出不同的QoS下不同流量的表现。除了对交换机和路由器的基本网络设备的测试,Spirent TestCenter还能够应用在网络安全设备、接入网设备、通信终端、ATM设备进行测试和分析。

在虚拟实验室中利用到的是Spirent虚拟的TestCenter接口,将这个接口放入云平台中,接口可以模拟流量,即可以对整个云平台的组网进行功能和性能的测试。

第四章 OpenStack中NFV虚拟网元虚拟化实现

在选择NFV虚拟网元的启动方式中,一种是作为ML2 Plugin启动,一种是作为实例孵化,最后本文选择了实例孵化的实现方式。孵化方式中利用Libvirt进行OpenStack虚拟化的实现。Libvirt对NFV虚拟网元的各个功能提供了很好的支持。Libvirt中有大量预置的参数启动NFV虚拟网元,如网卡信息,串口信息等。在特定的NFV虚拟网元的无法正常启动时,需要改动Spawn函数中的调用参数。

4.1 Libvirt虚拟化实现方式

虚拟实验室OpenStack中使用了Libvirt进行虚拟化的实现。Libvirt的为各种虚拟化工具提供一套方便、可靠的编程接口,管理多种不同的虚拟化方式。NFV虚拟网元在OpenStack平台上的虚拟化过程如图4-1。

图4-1 NFV虚拟网元的虚拟化支持流程

OpenStack环境中的Compute节点的Libvirt配置文件中可以对KVM,QUME等虚拟化技术进行选择。在裸机上的部署情况下一般使用KVM技术,因为它使用硬件加速,可以让计算资源分配时间更加短。虚拟实验室在进行搭建的时候使用了KVM虚拟化技术,而QEMU则是软件实现的虚拟化,没有使用硬件加速,使得NFV虚拟网元部署的时间变长,它的优点则是平台的兼容性较强。

图4-2 Libvirt管理NFV虚拟网元方式

[7]Libvirt中存在libvirtd进程,libvirt中有Qemu和KVM的驱动。在本项目中选择性能较好的KVM作为虚拟化层,在KVM层之上就是虚拟化所生成的Domain,Domain为NFV虚拟网元提供了计算资源。

虚拟实验室的NFV网元需要OpenStack环境的虚拟化实现需要对其进行管理,远程连接,存储管理,网络接口管理,路由功能等实现。而虚拟实验室的Compute节点上的Libvirt提供了以上的功能。通过函数调用和配置参数实现了对NFV虚拟网元的虚拟化支持。Libvirt通过以下几个功能实现了对NFV虚拟网元的计算资源的管理和网卡串口等网络组件的虚拟实现。

图4-3 Libvirt对NFV虚拟网元支持

1.NFV虚拟网元管理:针对NFV虚拟网元进行生命周期操作。针对具体NFV虚拟网元上则是孵化,关机,快照,删除等功能。

2.远程教学支持:在x86的机器上运行了libvirt daemon,所有的Libvirt功能就都可以访问和使用。这样便实现了虚拟教学的远程操作。由于支持多种网络远程传输,使用最简单的SSH,学生在远程便可以直接访问NFV虚拟路由器的功能,并进行相关的配置。

3.NFV虚拟网元镜像管理:由于NFV虚拟网元的保存形式受Libvirt的支持,支持qcow2、vmdk、raw等虚拟镜像格式。由于Libvirt可以远程工作,学生可以通过远程上传一个NFV的虚拟网元到虚拟实验室中,增加了可操作性。

4.NFV虚拟网元网络接口管理:NFV的虚拟网元是需要两张虚拟网卡来连接OpenStack中的两个子网的。运行了libvirt daemon的主机可以用来管理物理和逻辑的网络接口。通过网络接口的管理,NFV虚拟网元便可以实现作为一个路由器的功能。

5.NFV虚拟网元路由功能:由于Libvirt支持基于路由的网络。在NFV的虚拟网元中则可以实现基于RIP,OSPF等路由策略,由于Libvirt的支持,在虚拟化底层对路由的支持,满足了虚拟实验室的基本需求。

4.2 NFV虚拟网元的孵化方式

4.2.1 ML2插件形式启动

NFV虚拟网元实则是一个虚拟的软件实现的路由器。而在OpenStack中本身存在路由器,就是作为OpenStack的其中的一个插件l3-agent。OpenStack中本身的路由器能够连接OpenStack的两个子网。但是不能对OpenStack本身的L3-agent的路由器进行任何基于命令的配置。不能对OpenStack本身的路由器进行RIP,OSPF等路由策略的配置。那么则不能满足我们虚拟实验室的要求。不能进行“路由与交换”、“网络性能测试”这些专业实验课程。

图4-4 NFV虚拟网元作为ML2 Plugin

而加入的NFV虚拟网元(开源版本)不能作为一个插件,而VyOS的Brocade商业版本Vyatta在OpenStack中官方提供了插件,可以用来替换OpenStack中原本存在的L3-agent。关于VyOS的Brocade的Plugin。直接是Create Router而不是启动节点。但是在OpenStack的Controller节点上并不能安装Plugin,Brocade的Plugin是不支持开源VyOS。作为Plugin形式的启动是可行的,需要对每一个特定的NFV虚拟网元都进行开发一个特定的Plugin,和OpenStack的网络进行通信。OpenStack提供了Plugin的热插拔设计方式,使得这一切变得可以实现。那么这个方式的优势是利用OpenStack本身的框架,可行性较强。缺点也很明显,NFV的虚拟网元具有独特性,需要对每一个虚拟网元单独开发一个特定的Plugin,开发工作和难度都较大。

4.2.2 作为Instance孵化

常见的Instance只是连接OpenStack中的一个子网。通过OpenStack本身的L3-agent的路由器进行对不同子网其他Instance的访问。而将NFV虚拟网元加入OpenStack中则是需要让这个Instance连接2个及以上的子网,实现子网之间的流量通过这个NFV虚拟路由器进行转发。可以将NFV的虚拟网元在OpenStack中当作Instance进行孵化,但是需要将流量通过NFV的虚拟网元,并且能够使得NFV虚拟网元本身的路由和转发功能能够实现。

图4-5 NFV虚拟网元作为实例启动

OpenStack的安装方式是在物理机上安装Ubuntu再安装OpenStack,版本是Juno,需要物理磁盘的分区及安装。VyOS在OpenStack中直接启动会有一个安装的过程与OpenStack不兼容,在启动VyOS的时候出现了:sda dirves not found的问题。需要在Virtualbox或者VMware上进行install system。而OpenWRT则不需要这个过程。然后在Linux发行版上安装KVM。进行虚拟格式的转换。可以转换成qcow2或者raw格式等。

将转换后的qcow2格式的虚拟文件上传到OpenStack的Glance组件中,然后启动实例就可以运行了。底层使用Libvrit和KVM(或者QEMU)软件虚拟化技术。

4.3 Libvirt虚拟化实现NFV虚拟网元

选取创建虚拟机的进程具体说明Nova如何基于Libvirt实现对底层虚拟化平台的调用与管理。以及如何在函数中传递对NFV虚拟网元的配置信息。使得该Instance能够启动在OpenStack中。在LibvirtConnection类中,通过“spawn”方法来实现虚拟机的创建,“spawn”调用方法_create_domain_and_network来启动一个新的Domain,在方法_create_domain_and_network中,实际与Hypervisor建立连接的语句是“domain = self._conn.defineXML(xml)”;在建立与Hypervisor连接的基础上执行defineXML方法,创建并定义一个Domain,但是此时的Domain还未启动,必须执行“domain.createWithFlags(launch_flags)”语句来启动之前定义好的NFV虚拟网元的Domain。

图4-6 Libvirt孵化NFV虚拟网元

方法spawn:

为新建立的NFV虚拟网元参数获取配置数据conf,并把获取的数据conf转换为xml格式;

图4-7 XML配置信息

这样可以得到XML配置文件/var/lib/nova/instances/instance_id/libvirt.xml

上述整个过程就是OpenStack将NFV虚拟网元的配置信息的存入以及Libvirt的虚拟化配置和实现。
其中XML的配置文件是由Libvirt通过to_xml方法生成的。可以通过检查这个XML的配置文件来检查基于x86的虚拟网元在Libvirt的虚拟化过程中是否参数都配置正确。在孵化过程中可以查看XML的配置信息。在Libvirt的虚拟化实现过程中调用的conf配置文件中包含以下参数,instance, network_info, image_meta, disk_info, rescue, block_device_info。XML配置文件中的详细参数有domain type="kvm",uuid,name,memory占用,虚拟CPU个数,flavor模型,系统信息sysinfo type="smbios",串口serial id”,磁盘id dev="hd",驱动类型,虚拟格式,镜像存储地址,网络接口类型及ID,串口的console类型等信息。在NFV虚拟网元的启动过程中,OpenStack进行flavor的配置之后,Libvirt随即调用spawn函数进行孵化,其中大部分的参数都是默认的。而不能进行人工配置。在NFV的虚拟网元不能启动的情况下,可以对Libvirt的参数进行自定义的更改,从而更加符合特定的NFV虚拟网元。

分页阅读: 1 2


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/17192.html
分享到:
相关文章
条评论

登录后才可以评论

蒋暕青 发表于16-06-23
2