CN105407140B - 一种网络化测试系统的计算资源虚拟化方法 - Google Patents
一种网络化测试系统的计算资源虚拟化方法 Download PDFInfo
- Publication number
- CN105407140B CN105407140B CN201510697745.2A CN201510697745A CN105407140B CN 105407140 B CN105407140 B CN 105407140B CN 201510697745 A CN201510697745 A CN 201510697745A CN 105407140 B CN105407140 B CN 105407140B
- Authority
- CN
- China
- Prior art keywords
- network
- linux
- kernel
- computing resource
- container
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
Landscapes
- Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及一种网络化测试系统的计算资源虚拟化方法,包括以下步骤:步骤1)采用LXC实现仪器计算资源的容器虚拟化;步骤2)构建容器网络连接模型,实现容器间的互连;步骤3)对容器网络带宽进行分配。本发明可在不干扰和破坏网络测试任务的前提下将仪器空闲的计算资源开放给系统层,可使仪器参与系统层的数据处理和运算,以及将测试数据本地化预处理,并且本发明通过合理配置LXC内核特性的方式实现了ARM架构的单机LXC容器虚拟化;本发明在提高系统资源利用率,缓解主控计算机计算压力,降低网络传输数据量方面具有很强的可行性和合理性,可以很好地满足实际应用的需要。
Description
技术领域
本发明属于网络化测试技术领域,具体涉及一种网络化测试系统的计算资源虚拟化方法。
背景技术
随着网络技术的拓展,网络在自动测试领域中的应用越加广泛。相比于测试总线,网络以其开放性、兼容性和灵活性等方面的优势,在构建自动测试系统时,使得系统通用化方面将具有更好的仪器互换性、TPS可移植性和信息互通性;进而,随着测试资源的集中管理、调度机制和分布式测试过程的完善,将大大提高测试信息传输的效率和并行测试的能力,从而获得更高资源利用率和测试效率。因此,网络化将成为未来自动测试领域的重要应用方向。
目前,尽管网络化测试技术和相应规范已逐步成熟,但在实际的应用中,由于缺少成熟的基于网络的测试系统架构和相应的工具,网络依然被当作测试总线使用,其优势难以发挥,而其劣势甚至被放大。例如,网络化测试中常用的100M/1000M以太网,相比于主流的测试总线PXI或PXIe,其总线带宽明显不足;再有,网络延迟的不确定造成测试系统实时性降低,使得网络化测试系统的应用效果大打折扣;另外,网络测试设备的智能性、设备间的通信能力以及设备同步、触发功能难以发挥作用,信息传输出现瓶颈,测试效率难以提高。
网络化测试仪器通常是采用嵌入式系统技术开发的智能仪器,仪器本身具有计算和存储能力,但这些智能仪器仅作为网络化测试系统主控计算机的外设,系统并没有对其计算资源加以利用,造成仪器资源的大量浪费。
发明内容
针对上述现有技术中存在的问题,本发明的目的在于提供一种可避免出现上述技术缺陷的一种网络化测试系统的计算资源虚拟化方法。
为了实现上述发明目的,本发明采用的技术方案如下:
一种网络化测试系统的计算资源虚拟化方法,包括以下步骤:
步骤1)采用LXC实现仪器计算资源的容器虚拟化;
步骤2)构建容器网络连接模型,实现容器间的互连;
步骤3)对容器网络带宽进行分配。
进一步地,所述步骤1)具体包括以下步骤:
步骤A:移植Linux内核和ArchLinux:制作boot,生成设备文件树,移植Linuxkernel 3.12,制作Archlinux文件系统;
步骤B:对Linux内核进行LXC虚拟化配置:Namespaces配置,Cgroups配置,Network配置;
步骤C:配置Traffic Cotroller内核;
步骤D:初始化ArchLinux文件系统:设置MAC、IP、DNS地址,设置多播和路由,编写开机自启动脚本。
进一步地,所述步骤2)具体为:
首先在宿主机操作系统上创建Linux Bridge设备,并利用该技术将多台仪器内部容器的虚拟网络设备以内核通信的方式连接在同一局域网下;
然后利用Linux的虚拟网络技术,在局域网内构建了Veth、Vlan、Macvlan三种网络模型,用以支撑多仪器、多容器协同工作。
进一步地,所述步骤3)具体为
首先将iproute2移植到嵌入式系统中,然后利用Traffic Controller技术进行网络流量控制。
进一步地,利用所述Traffic Controller技术进行网络流量控制的具体包括以下步骤:
(1)创建HTB树:先创建根节点,然后再创建左右子节点;
(2)限定IP粒度流量:增加一层过滤器来匹配该IP地址,并将其跟随到特定classid的HTB或SFQ中;
(3)限定端口粒度流量:tc过滤器匹配特定端口号,并将源或目的端口号与需限定端口号相同的数据包跟随到指定HTB或SFQ中;
(4)限定进程粒度流量。
本发明提出的网络化测试系统的计算资源虚拟化方法,可在不干扰和破坏网络测试任务的前提下将仪器空闲的计算资源开放给系统层,可使仪器参与系统层的数据处理和运算,以及将测试数据本地化预处理,并且本发明通过合理 配置LXC内核特性的方式实现了ARM架构的单机LXC容器虚拟化。在仪器LXC单机容器虚拟化的基础上,创建了Linux网桥(Bridge),构建了Veth、VLAN、Macvlan三种网络连接模型,达到了支撑容器间的网络通信的目标。同时,联合流量控制器和Cgroups net_cls子系统实现了容器指定的网络带宽分配;本发明在智能仪器上以较小的性能开销方式创建多个虚拟容器,并且可为容器动态分配隔离可控的内存、存储、CPU、网络资源,该方法在提高系统资源利用率,缓解主控计算机计算压力,降低网络传输数据量方面具有很强的可行性和合理性,可以很好地满足实际应用的需要。
附图说明
图1为本发明的流程图;
图2为Linux Bridge的工作示意图;
图3为Veth模式的原理示意图;
图4为VLAN模式的原理示意图;
图5为Macvlan模式的原理示意图;
图6为TC流量控制树状结构示意图;
图7为网络子系统的工作原理示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,下面结合附图和具体实施例对本发明做进一步说明。应当理解,此处所描述的具体实施例仅用以解释本发明,并不用于限定本发明。
如图1所示,。
一种网络化测试系统的计算资源虚拟化方法,包括步骤1)、步骤2)和步骤3)三个步骤,如下:
步骤1)采用LXC实现仪器计算资源的容器虚拟化;
步骤2)构建容器网络连接模型,实现容器间的互连;
步骤3)对容器网络带宽进行分配。
所述步骤1)具体包括步骤A、步骤B、步骤C和步骤D,如下所示:
步骤A:移植Linux内核和ArchLinux:制作boot,生成设备文件树,移植Linuxkernel 3.12,制作Archlinux文件系统;
其中:
boot制作包括针对ZYNQ芯片的FSBL(first stage bootloader)制作,ZYNQ的PL资源的system.bit的编译,以及u-boot的编译。FSBL和system.bit直接用xilinx公司的Vivado软件生成即可。
u-boot源码压缩包u-boot-digilent-2012.04-digilent-13.01.tar.gz需在u-boot官网上下载,压缩包解压后,在指定的文件夹下(include/configs/)找到与zedboard相关的配置头文件(zynq_zed.h),然后做如下修改:
31#define CONFIG_IPADDR 192.168.0.100/*zedboard IP地址*/
32#define CONFIG_SERVERIP 192.168.0.250/*主机IP地址*/
42ethaddr=00:0a:35:00:01:45\0"\/*设定zedboard mac地址*/
生成u-boot配置文件后,利用Linux Shell指令编译u-boot:
31#make CROSS_COMPILE=arm-xilinx-linux-gnueabi-zynq_zed_config
32#make CROSS_COMPILE=arm-xilinx-linux-gnueabi-
最后编写boot_bif.bif文件,并利用xilinx的bootgen生成boot文件即可:
the_rom_image:{
[bootloader]fbsl.elf system.bit u-boot
}
bootgen-image boot_bif.bif-o i BOOT.BIN
Linux 3.0以上版本的内核已剔除只针对特定硬件平台的源码,取而代之的是用devicetree来描述特定硬件平台。当ARM已运行在u-boot环境下时,会将devicetree文件下载到指定的内存空间中,进而初始化硬件设备。
Zedboard的devicetree文件是内核源码liunux-kernel/arch/arch/arm/boot/dts/文件夹下的zynq-zed.dts文件,修改第27行,指定文件系统为SD的第二个分区,然后用linux-kernel/script/dtc下的dtc工具编译出devicetree.dtb文件,如下:bootargs="console=ttyPS0,115200root=/dev/mmcblk0p2rw earlyprintk rootfstype=ext4rootwait devtmpfs.mount=1";./scripts/dtc/dtc-I dts-O dtb-o./devicetree.dtb arch/arm/boot/dts/zynq-zed.dts
在Linux官方网站,或者Digilent公司的github上下载Linux3.12的源码,解压源码包后,在linux-kernel/arch/arm/configs/下有xilinx_zynq_defconfig文件,用于生成zynq处理器的内核初始.config配置文件,如下所示:
make ARCH=arm CROSS_COMPILE=arm-xilinx-linux-gnueabi-xilinx_zynq_defconfig
为了满足Archlinux文件系统的systemd的特性,还需要在内核配置与
systemd相关的内核配置项,如表1所示
表1 systemd有关的内核配置项
修改的配置最终会临时性的保存在linux-kernel/.config文件中,编译内核时会根据.config文件各个配置项的值来将内核的各个子功能模块动态的编译进内核二进制文件里,内核二进制文件在arch/arm/boot/uImage下,如下所示:
make ARCH=arm CROSS_COMPILE=arm-xilinx-linux-gnueabi-\
UIMAGE_LOADADDR=0X8000uImage
本发明采用Archlinux文件系统,在其官网下载到源码并解压缩后,需要对文件系统源码做一些修改:屏蔽/etc/fatab文件第5行,详情如下:
#/dev/mmcblk0p1/boot vfat defaults 00
在/etc/mtab文件夹下增加cgroup各个子系统的挂载点,使得Cgroups资源控制器可随系统启动时,自动挂载到相应挂载点上,如下所示:
tmpfs/sys/fs/cgroup tmpfs
cgroup/sys/fs/cgroup/systemd cgroup
cgroup/sys/fs/cgroup/cpuset cgroup
cgroup/sys/fs/cgroup/debug cgroup
cgroup/sys/fs/cgroup/cpu,cpuacct cgroup
cgroup/sys/fs/cgroup/memory cgroup
cgroup/sys/fs/cgroup/devices cgroup
cgroup/sys/fs/cgroup/freezer cgroup
cgroup/sys/fs/cgroup/net_cls,net_prio cgroup
cgroup/sys/fs/cgroup/blkio cgroup
cgroup/sys/fs/cgroup/perf_event cgroup
Linux内核编译完成之后,需要编译内核相关的驱动程序,并拷贝到文件 系统的指定文件夹下,如下所示:
#make ARCH=arm CROSS_COMPILE=arm-xilinx-linux-gnueabi-modules
#make ARCH=arm CROSS_COMPILE=arm-xilinx-linux-gnueabi-modules_install\
INSTALL_MOD_PATH=<path to install modules>
#cp<path to install modules>/*/lib/modules-a
至此,Linux内核和ArchLinux移植工作已全部完毕。
步骤B:对Linux内核进行LXC虚拟化配置:Namespaces配置,Cgroups配置,Network配置;
目前,Linux操作系统实现了进程通信(IPC)、文件系统(MNT)、用户(User)、主机或域名(UTS)、进程(PID)以及网络(NET)六类命名空间的资源隔离。内核实现Namespaces机制只需向linux-kernel/.config文件增加表2中的所陈列的6项配置参数即可。
表2 Namespaces内核配置参数
Cgroups资源控制器需要配置8类子系统的内核参数。需向linux-kernel/.config文件增加的关键配置项如表3所示:
表3 Cgroups内核配置参数
Network模块用于容器间的网络连接模型建设。默认情况下,内核并未开启支持网桥、Veth、Macvlan、Vlan等功能模块的驱动。因此,需重新裁剪和编译内核,向内核增加支持这4类内核配置项。具体参数如表4所示:
表4 Network内核配置参数
步骤C:配置Traffic Cotroller内核;
Cgroups网络子系统仅仅能为不同容器所发出的数据包标记classid,实际带宽限制的工作是由Traffic Controller根据不同的classid排队、丢包规则来实现网络带宽限制的。Traffic Controller是一种Linux内核层实现的网络流量控制器,与其内核有配置参数共有23项。表5列出了7项关键参数:
表5 Traffic Controller内核配置项
步骤D:初始化ArchLinux文件系统:设置MAC、IP、DNS地址,设置多播和路由,编写开机自启动脚本。
初始化ArchLinux文件系统需要在系统每次启动的过程中完成。
网络化测试系统的通常有多台仪器在同时工作,设置MAC和IP地址可有 效避免仪器MAC、IP冲突,设置DNS地址为了方便ArchLinux系统在线安装软件,对于一个嵌入式开发工程师而言,此举可极大提高开发效率。此过程可用shell脚本在系统运行的状态下动态修改。本发明将所有此脚本保存在名为eth0.conf的文件里,以便于systemd的管理。具体脚本如下:
ifconfig eth0down
ifconfig eth0hw ether 00:0A:35:00:01:23/*修改MAC地址*/
ifconfig eth0192.168.1.23up/*修改IP地址*/
echo"nameserver 202.118.224.101">/etc/resolv.conf/*设置DNS服务器地址*/
网络化测试系统通常有多播通信的需求,如支持mDNS协议。同时仪器处在局域网里试图连上万维网时,需要添加默认网关地址。脚本也写入eth0.conf文件里。具体脚本如下:
route add default gw 192.168.1.1 /*添加默认网关*/
route add-net 224.0.0.0netmask 224.0.0.0eth0 /*添加多播地址段*/
sysctl net.ipv4.ip_forward=1 /*设置网卡按ipv4协议栈工作*/
上述eth0.conf脚本需要仪器开机时自启动,ArchLinux操作系统开机启动初始化脚本是通过systemd来管理。因此,还需编写一个开机自启动的脚本来调用eth0.conf脚本。
将开机自启动脚本命名为start.conf,所有脚本均保存在/zedboard文件夹下,同时赋予start.conf所有用户都有执行权限。如下所示:
#touch start.conf
#echo‘#!/bin/bash’>start.conf
#echo“/zedboard/eth0.conf”>>start.conf
#chmod a+x start.conf
在systemd指定的路径(/usr/lib/systemd/system/)下创建本地初始化服务文件,并将本地化服务添加软链接至systemd开机初始化管理的指定路径中,并且使能开机自启动。具体实现如下:
至此,ArchLinux文件系统初始化已全部完成。
所述步骤2)具体为:
首先在宿主机操作系统上创建Linux Bridge设备,并利用该技术将多台仪器内部容器的虚拟网络设备以内核通信的方式连接在同一局域网下;
然后利用Linux的虚拟网络技术,在局域网内构建了Veth、Vlan、Macvlan三种网络模型,用以支撑多仪器、多容器协同工作。
其中:
网络模型的构建依赖Linux Bridge技术。在相同仪器(宿主机)下创建多个容器并创建多个网络设备后,Linux操作系统提供了一种工作在数据链路层的网桥(Bridge)技术用于支撑系统内部虚拟网络设备通信。网桥是Linux内核中用作TCP/IP二层协议的交换设备,功能类似二层交换机。图2展示的是Linux Bridge工作示意图,网桥上绑定了eth0与eth1两个网络设备。为了能将eth0和eth1的数据转发到上层协议栈,网桥还会分配一个虚拟端口给一个自动创建的br0网络设备,且可为br0分配IP地址。
一个网络设备连接上网桥,相当于现实中一个网络终端通过网线连接交换机,此时内核会通过系统调用来注册一个接收数据的回调函数。eth0和eth1接收到的数据包,都会通过br0转发到上层协议栈。因此,在网络层及以上层次的协议栈只能识别到br0。然而,从上层协议栈发出的数据包要通过网络设备发出时,bridge会处理包括判断包的类别(广播/单播)、查找MAC与端口映射表、将数据转发到目标端口、更新内部MAC与端口映射表以自我学习等过程。
图2中Linux Bridge创建、与网络设备绑定的过程的脚本如下所示:
针对不同的应用场景,Linux内核给虚拟网络设备提供了Veth(VirtualEthernet)、VLAN、Macvlan三种连接模式。如图3所示,Veth是一种最基本的模式,容器启动前必须先在宿主机创建Bridge。每一个容器都将建立一对Veth设备,一端连接容器eth0,另一端连接宿主机的Bridge,从而实现容器内部eth0与Bridge的绑定。
在同一宿主机下,所有容器可以看作是通过二级交换机(Linux Bridge)相连,同时将容器内部eth0、Bridge的IP按规则设置成与宿主机eth0相同的地址段,使得所有容器与宿主机处于相同广播域。容器与容器互相通信的过程并不消耗真实网络资源,由于Linux内核缓存了每个容器的IP、MAC地址,IP地址先映射到MAC地址上,系统再根据源MAC与目标MAC地址实现内核通信,这种利用内核Bridge通信的方式有一定的CPU、内存性能开销。不同宿主机之间可通过物理二级交换机相连,实现宿主机之间数据交换。如果不同宿主机之间容器需要进行数据交换,则宿主机物理网卡(NIC)必须设置为混杂模式(PromiscuousMode),因为当容器跨物理主机通信时,数据要想到达容器必须先经过宿主机物理网卡,由于数据的目标MAC地址是宿主机内部容器的地址,宿主机网卡在数据链路层会将数据帧丢弃,从而导致容器无法跨主机通信。
Veth模型具体实现方式如下:
在Veth模式下,所有容器与宿主机都处于同一广播域,这种模式存在广播洪泛将占用大量网络资源。然而,网络化测试系统通常是多用户,多任务同时进行的,这要求不同任务之间要做到互相隔离,互不干扰,在这种应用背景下,Veth显然不满足要求。VLAN技术可以将物理上连接在同一交换机下的主机可以根据不同的vlan.id值划分到不同逻辑子网中,不同逻辑子网互相隔离。即为交换机的每一个端口设置一个1-4094的数字,交换机根据MAC地址进行转发的同时也要结合vlan.id值,只有相同的vlan.id才转发,否则数据帧丢弃, 实现了数据链路层数据帧的物理隔离。
如图4所示,三台Zedboard通过vlan交换机相连,虚拟出了5个容器,5个容器根据不同的vlan.id值被分隔为3个广播域,vlan.id相同的容器划分到相同广播域内。在Zedboard1上,LXC0与LXC1虽然连接在同一虚拟交换机下(Linux Bridge),但由于vlan.id不相同,彼此网络通信时,在数据链路层数据帧不会被Bridge转发。在Zedboard1与Zedboard2之间,LXC1与LXC2由于vlan.id相同,因此在数据连路层物理vlan交换机将转发它们彼此之间的数据帧,即被划分到同一广播域内。VLAN技术的L2层隔离机制实现了网络化测试系统用户、任务分离,避免了广播洪泛,同时节省了网络带宽。
Veth模型具体实现方式如下:
Macvlan无法通过宿主机内部配置与外界通信,通常需要增加外部网关(ExternalGateway)或者外部交换机(External Switch)才可以。
如图5所示,每个容器都有一个MAC地址唯一的macvlan接口,macvlan接口连向宿主机网络接口,根据macvlan.mode的不同值将macvlan分为Private,Bridge,VEPA三种模式。
(1)Private模式
容器macvlan接口之间没有Linux Bridge连接,即容器与容器之间无法进行内核层的数据交换。容器也无法试图通过宿主机物理网卡通过外部数据交换的方式与其他容器通信,因为Linux网络通信原理决定网卡将单播过滤(unicast filter)掉源MAC地址与目的MAC地址相同的数据包。因此,在Private模式下容器与容器,容器与宿主机无法通信。
(2)Bridge模式
容器与容器组成子网,macvlan接口可通过系统内部Bridge数据交换,而不会消耗物理网卡流量,然而Bridge通信是通过内核实现,因此该模式有一定 的CPU和内存开销,并且在此模式下容器无法直接与宿主机通信。Bridge模式将网络通信转移到了内核通信,而内核层数据交换相对与传统网络的QOS,监测工具都是不可视的,此模式会对传统的网络监控工具造成一定困难。
(3)VEPA模式
VEPA(Virtual Ethernet Port Aggregator)即虚拟网络端口汇聚器,可对macvlan端口的数据汇聚、分类、转发。内部虚拟网络设备通信都会占用实际网络带宽,但此模式会减轻由于内核通信造成的额外性能开销,把原来由CPU、内存处理的工作转移到了一级交换机。
Macvlan模型具体实现方式如下:
所述步骤3)具体为:
首先将iproute2移植到ARM处理器构成的嵌入式系统中,然后利用TrafficController技术进行网络流量控制。具体操作过程是先在Linux开源社区下载源码压缩包iproute2-3.19.0.tar.gz,并解压,然后切换到iproute2-3.19.0路径下,修改Makefile文件第29和39行,具体操作如下:
29CC=gcc 修改成:CC=arm-xilinx-linux-guneabi-gcc
39SUBDIRS=lib ip tc bridge misc netem genl man修改成:SUBDIRS=lib tc
修改Makefile后,再键入make指令,就会在iproute2-3.19.0/tc路径下生成可执行文件tc,此文件就可用于嵌入式系统的网络流量控制。
本发明将按HTB树状结构来分别介绍IP、端口、进程级别的流量控制。如图6所示,该树根HTB的classid为1:0,允许的网络带宽为100Mbps,其左右子节点HTB的classid分别为1:1和1:2,允许的带宽分别为40Mbps、30Mbps。
利用所述Traffic Controller技术进行网络流量控制的具体包括以下步骤:
(1)创建HTB树
在创建该HTB树形结构时,需先创建根节点,然后再创建左右子节点。需 注意的是,在创建节点的同时就要限定节点的网络带宽。具体实现如下:
(2)IP粒度流量限定
限制特定源或目的IP的流量,需要增加一层过滤器(filter),来匹配该IP地址,并将其跟随到特定classid的HTB或SFQ中,具体实现如下:
#tc filter add dev eth0protocol ip parent 1:prio 49u32match ip dst192.168.1.24flowid 1:2/*将本机发往IP地址为192.168.1.14的数据包绑定在classid为1:2的HTB中*/
(3)端口粒度流量限定
与IP限制方式类似,tc过滤器也需匹配特定端口号,并将源或目的端口号与需限定端口号相同的数据包跟随到指定HTB或SFQ中,具体实现如下:
#tc filter add dev eth0protocol ip parent 1:prio 49u32match ip dport123450xffff flowid
1:2/*将目的端口为12345的数据包绑定在classid为1:2的HTB中*/
(4)进程粒度流量限定
进程级别的流量限制,需要TC和Cgroups的net_cls子系统配合使用,具体实现如下:
#echo 0x10001>net_cls.classid /*net_cls子系统标记进程数据包classid=1:1*/
#echo$$>tasks /*将进程加入可被net_cls标记的任务列表中*/
#tc filter add dev eth0parent 1:protocol ip prio 10handle 1:cgroup/*关联tc与cgroup*/
CPU、内存资源控制子系统均是通过Cgroups的资源管理机制实现对相应资源的控制,然而Cgroups网络(net_cls)子系统本身并不具备网络控制的能力。如图7所示,有两个LXC容器运行在宿主机操作系统之上,分别运行计算任务和测试任务。网络子系统可以分别为从两容器的网络设备输出的数据包打上Traffic Controller能识别的classid,然后用Traffic Controller为各个classid设定排队规则、优先级、网络带宽,从而可实现对不同任务网络控制。由此可见,Cgroups网络子系统仅仅是为不同进程组的网络数据包标记不同的classid,真正实现网络控制的是Traffic Controller。
本发明所涉及的英文专业术语所对应的中文含义翻译对照如下:
container:容器;LXC:linux容器;kernel:内核;bridge mode:桥接模式;MACaddress:物理地址;vlan switch:VLAN(虚拟局域网)交换机;external switch:外部交换机;unicast filter:单播过滤;adjacent bridge:邻接桥。
本发明提出的网络化测试系统的计算资源虚拟化方法,可在不干扰和破坏网络测试任务的前提下将仪器空闲的计算资源开放给系统层,可使仪器参与系统层的数据处理和运算,以及将测试数据本地化预处理,并且本发明通过合理配置LXC内核特性的方式实现了ARM架构的单机LXC容器虚拟化。在仪器LXC单机容器虚拟化的基础上,创建了Linux网桥(Bridge),构建了Veth、VLAN、Macvlan三种网络连接模型,达到了支撑容器间的网络通信的目标。同时,联合流量控制器和Cgroups net_cls子系统实现了容器指定的网络带宽分配;本发明在智能仪器上以较小的性能开销方式创建多个虚拟容器,并且可为容器动态分配隔离可控的内存、存储、CPU、网络资源,该方法在提高系统资源利用率,缓解主控计算机计算压力,降低网络传输数据量方面具有很强的可行性和合理性,可以很好地满足实际应用的需要。
以上所述实施例仅表达了本发明的实施方式,其描述较为具体和详细,但并不能因此而理解为对本发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变形和改进,这些都属于本发明的保护范围。因此,本发明专利的保护范围应以所附权利要求为准。
Claims (2)
1.一种网络化测试系统的计算资源虚拟化方法,其特征在于,包括以下步骤:
步骤1)采用LXC实现仪器计算资源的容器虚拟化;
步骤2)构建容器网络连接模型,实现容器间的互连;
步骤3)对容器网络带宽进行分配;
所述步骤1)具体包括以下步骤:
步骤A:移植Linux内核和ArchLinux:制作boot,生成设备文件树,移植Linux kernel3.12,制作Archlinux文件系统;
步骤B:对Linux内核进行LXC虚拟化配置:Namespaces配置,Cgroups配置,Network配置;
步骤C:配置Traffic Cotroller内核;
步骤D:初始化ArchLinux文件系统:设置MAC、IP、DNS地址,设置多播和路由,编写开机自启动脚本;
所述步骤2)具体为:
首先在宿主机操作系统上创建Linux Bridge设备,并将多台仪器内部容器的虚拟网络设备以内核通信的方式连接在同一局域网下;然后利用Linux的虚拟网络技术,在局域网内构建了Veth、Vlan、Macvlan三种网络模型,用以支撑多仪器、多容器协同工作;
所述步骤3)具体为:
首先将iproute2移植到嵌入式系统中,然后利用Traffic Controller技术进行网络流量控制。
2.根据权利要求1所述的网络化测试系统的计算资源虚拟化方法,其特征在于,利用所述Traffic Controller技术进行网络流量控制的具体包括以下步骤:
(1)创建HTB树:先创建根节点,然后再创建左右子节点;
(2)限定IP粒度流量:增加一层过滤器来匹配该IP地址,并将其跟随到特定classid的HTB或SFQ中;
(3)限定端口粒度流量:tc过滤器匹配特定端口号,并将源或目的端口号与需限定端口号相同的数据包跟随到指定HTB或SFQ中;
(4)限定进程粒度流量。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510697745.2A CN105407140B (zh) | 2015-10-23 | 2015-10-23 | 一种网络化测试系统的计算资源虚拟化方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510697745.2A CN105407140B (zh) | 2015-10-23 | 2015-10-23 | 一种网络化测试系统的计算资源虚拟化方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105407140A CN105407140A (zh) | 2016-03-16 |
CN105407140B true CN105407140B (zh) | 2018-08-17 |
Family
ID=55472386
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510697745.2A Active CN105407140B (zh) | 2015-10-23 | 2015-10-23 | 一种网络化测试系统的计算资源虚拟化方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105407140B (zh) |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170272400A1 (en) * | 2016-03-17 | 2017-09-21 | Microsoft Technology Licensing, Llc | Network virtualization of containers in computing systems |
CN105847108B (zh) * | 2016-05-24 | 2019-01-15 | 中国联合网络通信集团有限公司 | 容器间的通信方法及装置 |
CN106371889B (zh) * | 2016-08-22 | 2020-05-29 | 浪潮(北京)电子信息产业有限公司 | 一种调度镜像的高性能集群系统实现方法及装置 |
CN106445638A (zh) * | 2016-10-08 | 2017-02-22 | 深圳市云舒网络技术有限公司 | 一种基于容器技术的数据采集和处理系统 |
CN106789931B (zh) * | 2016-11-29 | 2020-05-19 | 北京元心科技有限公司 | 多系统的网络隔离共享方法及装置 |
CN106535160B (zh) * | 2016-11-29 | 2019-11-08 | 北京元心科技有限公司 | 双系统双sim卡网络隔离传输的方法及系统 |
CN108762821B (zh) * | 2017-04-18 | 2023-04-25 | 海马云(天津)信息技术有限公司 | 电子设备运行应用的装置及方法、电子设备 |
CN108737584A (zh) * | 2017-04-19 | 2018-11-02 | 中国移动通信集团山西有限公司 | 容器服务的访问方法、网络地址的解析方法、装置和系统 |
CN107592225A (zh) * | 2017-09-13 | 2018-01-16 | 国云科技股份有限公司 | 一种融合物理机、虚拟机与容器网络设置的系统及方法 |
CN107741877A (zh) * | 2017-11-06 | 2018-02-27 | 湖南红手指信息技术有限公司 | 一种云手机启动虚拟操作系统的方法、存储介质和处理器 |
CN109857468B (zh) * | 2019-01-04 | 2022-03-01 | 烽火通信科技股份有限公司 | 一种在单Linux系统镜像中支持多DTB的方法及系统 |
CN112583687B (zh) * | 2019-09-30 | 2022-05-27 | 北京国双科技有限公司 | 流量控制方法、系统、计算机设备以及存储介质 |
CN111935323A (zh) * | 2020-10-12 | 2020-11-13 | 江苏润和软件股份有限公司 | 一种远程lxc容器应用动态管理系统及方法 |
CN113238819B (zh) * | 2021-07-09 | 2021-09-21 | 成都菁蓉联创科技有限公司 | 一种适用于U-Boot的驱动文件动态加载方法及系统 |
CN115189948B (zh) * | 2022-07-11 | 2023-05-12 | 北京志凌海纳科技有限公司 | 一种CaaS平台中容器网络插件的实现方法和系统 |
CN115695088A (zh) * | 2022-10-26 | 2023-02-03 | 中国第一汽车股份有限公司 | 一种Android系统划分VLAN的方法及车载Android系统 |
CN115733887A (zh) * | 2022-11-30 | 2023-03-03 | 凡游在线科技(成都)有限公司 | 用于多云服务商的一体化网格互联部署方法 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101465863B (zh) * | 2009-01-14 | 2012-09-26 | 北京航空航天大学 | 一种内核虚拟机环境下高效网络i/o的实现方法 |
CN102970204B (zh) * | 2012-10-24 | 2017-09-01 | 曙光信息产业(北京)有限公司 | 一种基于xen虚拟化平台的分布式交换机系统及其实现方法 |
CN103870314B (zh) * | 2014-03-06 | 2017-01-25 | 中国科学院信息工程研究所 | 一种单节点同时运行不同类型虚拟机的方法及系统 |
-
2015
- 2015-10-23 CN CN201510697745.2A patent/CN105407140B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN105407140A (zh) | 2016-03-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105407140B (zh) | 一种网络化测试系统的计算资源虚拟化方法 | |
CN102334112B (zh) | 用于虚拟机网络的方法和系统 | |
TWI821463B (zh) | 具有分解式網路元件的邏輯路由器 | |
CN105706043B (zh) | 推进式链接的列表吞吐量 | |
CA2810660C (en) | Computer system and communication method in computer system | |
CN106685787B (zh) | 基于OpenStack的PowerVM虚拟化网络管理方法及装置 | |
CN103346981B (zh) | 虚拟交换方法、相关装置和计算机系统 | |
US8725898B1 (en) | Scalable port address translations | |
CN112671578B (zh) | 一种sriov虚拟化网络配置方法及相关装置 | |
CN1988528A (zh) | 动态服务刀片和方法 | |
EP4149064A1 (en) | Containerized routing protocol process for virtual private networks | |
CN108989071B (zh) | 虚拟服务提供方法、网关设备及存储介质 | |
CN112291252A (zh) | 一种南北向流量对称性引流的实现架构及方法 | |
US20230308398A1 (en) | Latency-aware load balancer for topology-shifting software defined networks | |
Casado et al. | Ripcord: A modular platform for data center networking | |
Vrijders et al. | Reducing the complexity of virtual machine networking | |
CN110505095B (zh) | 一种使用少量服务器搭建大规模虚拟数据中心的方法 | |
CN107294746B (zh) | 一种部署业务的方法及设备 | |
US20030225916A1 (en) | Implementing a data link layer protocol for multiple network interface devices | |
Ewais et al. | A Framework Integrating FPGAs in VNF Networks | |
Landau et al. | Plugging the hypervisor abstraction leaks caused by virtual networking | |
Langemak | Docker Networking Cookbook | |
Di Giovanna | Designing an ebpf-based disaggregated network provider for kubernetes | |
Lischka et al. | RiaS: overlay topology creation on a PlanetLab infrastructure | |
Govindarajan et al. | Cloud Native Networking Deep-Dive |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right | ||
TR01 | Transfer of patent right |
Effective date of registration: 20200116 Address after: 528000 7th floor, No.18, middle Shabu Road, Shayong Shabu Industrial Zone, Lishui Town, Nanhai District, Foshan City, Guangdong Province (application for residence) Patentee after: Guangdong yiyunfu Technology Co., Ltd Address before: 200120 Shanghai Pudong New Area City 428 No. 2 Lane 902 Kang Hong Lu Patentee before: SHANGHAI BILIN ELECTRONIC TECHNOLOGY CO., LTD. |