基于VPP的集群式虚拟化数据转发方法、装置及系统与流程

文档序号:25343009发布日期:2021-06-04 21:51阅读:420来源:国知局
基于VPP的集群式虚拟化数据转发方法、装置及系统与流程
基于vpp的集群式虚拟化数据转发方法、装置及系统
技术领域
1.本发明属于数据转发技术领域,具体涉及一种基于vpp的集群式虚拟化数据转发方法、装置及系统。


背景技术:

2.随着电力物联网建设的推进,物联网终端设备呈现规模庞大、结构复杂、种类多样等趋势,电力物联网安全网关提供的安全服务面临诸多新问题。前述的新问题主要包括:(1)物联网络终端设备的与日俱增,终端数目呈现指数级增长,对于边界安全网关的数据转发性能要求越来越高,需要不断对设备集群进行扩容和升级,运维难度逐日提升。(2)随着安全业务不断增加,不同类型业务对于资源的需求不同,导致资源整体配置策略在不断动态变化。原有不同款型的网关设备已无法适应业务的动态变化,导致部分业务资源紧缺,部分业务又有大量资源闲置。有限物理资源需要更加有效与合理的分配。


技术实现要素:

3.针对上述问题,本发明提出一种基于vpp的集群式虚拟化数据转发方法、装置及系统,所有数据的收发包驱动均基于dpdk,不涉及用户态到内核态的报文拷贝,保证了传统基于dpdk转发驱动的网关接入业务的性能不受影响。
4.为了实现上述技术目的,达到上述技术效果,本发明通过以下技术方案实现:
5.第一方面,本发明提供了一种基于vpp的集群式虚拟化数据转发方法,包括:
6.获取若干个业务容器,所述业务容器是对安全接入服务虚拟化获得的;
7.将各个业务容器均注册到负载均衡进程中,由负载均衡进程对外提供唯一的服务地址和端口号;
8.当监测到负载均衡进程接收到某客户端发送的访问请求后,控制负载均衡进程按照预设的工作模式和轮询算法,在kubernetes容器框架下通过vpp中dpdk转发驱动与对应业务容器进行通信,完成数据转发。
9.可选地,所述若干个业务容器中的各业务容器属于同一类业务或不同类业务,属于同一类业务的业务容器分布于同一台物理机或不同物理机上。
10.可选地,所述业务容器的虚拟化方法包括以下步骤:
11.利用kubernetes容器框架针对安全接入服务,根据服务类型的不同、或业务逻辑的不同、或性能需求的不同制作不同的容器镜像,将容器镜像对相关服务的提供商进行发布,使得服务提供商加载完容器镜像后,根据自身提供服务的规模和并发量大小,对部署策略进行配置,并接收由提供商反馈的部署策略,所述kubernetes容器框架根据所述容器镜像和接收到的部署策略创建对应数量的业务容器。
12.可选地,在所述在kubernetes容器框架下通过vpp中dpdk转发驱动与对应业务容器进行通信步骤之后,还包括:
13.利用kubernetes容器框架中的容器资源管理模块对各个业务容器进行资源动态
监控,根据资源动态监控的结果进行业务容器的扩容或缩容;
14.当进行业务容器的扩容时,将扩容产生的业务容器注册到负载均衡进程中;
15.当进行业务容器的缩容时,将缩容涉及到的业务容器从负载均衡进程中删除。
16.第二方面,本发明提供了一种基于vpp的集群式虚拟化数据转发装置,包括:
17.获取单元,用于获取若干个业务容器,所述业务容器是对安全接入服务虚拟化获得的;
18.注册单元,用于将各个业务容器均注册到负载均衡进程中,由负载均衡进程对外提供唯一的服务地址和端口号;
19.数据转发单元,用于当监测到负载均衡进程接收到某客户端发送的访问请求后,控制负载均衡进程按照预设的工作模式和轮询算法,在kubernetes容器框架下通过vpp中dpdk转发驱动与对应业务容器进行通信,完成数据转发。
20.可选地,所述若干个业务容器中的各业务容器属于同一类业务或不同类业务,属于同一类业务的业务容器分布于同一台物理机或不同物理机上。
21.可选地,所述业务容器的虚拟化方法包括以下步骤:
22.利用kubernetes容器框架针对安全接入服务,根据服务类型的不同、或业务逻辑的不同、或性能需求的不同制作不同的容器镜像,将容器镜像对相关服务的提供商进行发布,使得服务提供商加载完容器镜像后,根据自身提供服务的规模和并发量大小,对部署策略进行配置,并接收由提供商反馈的部署策略,所述kubernetes容器框架根据所述容器镜像和接收到的部署策略创建对应数量的业务容器
23.可选地,所述基于vpp的集群式虚拟化数据转发装置还包括:
24.扩容或缩容单元,用于利用kubernetes容器框架中的容器资源管理模块对各个业务容器进行资源动态监控,根据资源动态监控的结果进行业务容器的扩容或缩容;
25.当进行业务容器的扩容时,将扩容产生的业务容器注册到负载均衡进程中;
26.当进行业务容器的缩容时,将缩容涉及到的业务容器从负载均衡进程中删除
27.第三方面,本发明提供了一种基于vpp的集群式虚拟化数据转发装置,包括:
28.若干个物理机,各物理机均包括相连的主板和网卡,所述网卡中的安全接入服务被虚拟化成业务容器;所述主板中设有vpp;
29.负载均衡进程,各个业务容器均被注册到所述负载均衡进程中,由负载均衡进程对外提供唯一的服务地址和端口号;
30.当所述负载均衡进程接收到某客户端发送的访问请求时,所述负载均衡进程按照预设的工作模式和轮询算法,在kubernetes容器框架下通过vpp中dpdk转发驱动与对应业务容器进行通信,完成数据转发。
31.第四方面,本发明提供了一种基于vpp的集群式虚拟化数据转发系统,包括存储介质和处理器;
32.所述存储介质用于存储指令;
33.所述处理器用于根据所述指令进行操作以执行根据第一方面中任一项所述方法的步骤。
34.与现有技术相比,本发明的有益效果:
35.本发明基于vpp底层的dpdk转发驱动进行收发包,将安全接入服务虚拟化为业务
容器,在kubernetes架构下部署业务容器,通过vpp提供的memif接口实现物理机与业务容器间的无拷贝通信,所有报文均不经过linux内核协议栈,提高了虚拟化、容器化场景下的高速流量分发能力。
36.进一步地,在保证高性能的前提下,利用kubernetes架构中的容器资源管理模块实现各类业务的业务容器的动态伸缩与高效运维。
附图说明
37.为了使本发明的内容更容易被清楚地理解,下面根据具体实施例并结合附图,对本发明作进一步详细的说明,其中:
38.图1为本发明一种实施例的基于vpp的集群式虚拟化数据转发方法的流程示意图;
39.图2为本发明一种实施例的基于vpp的集群式虚拟化数据转发装置的结构示意图。
具体实施方式
40.为了使本发明的目的、技术方案及优点更加清楚明白,以下结合实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明的保护范围。
41.下面结合附图对本发明的应用原理作详细的描述。
42.实施例1
43.本发明实施例中提供了一种基于vpp的集群式虚拟化数据转发方法,如图1所示,具体包括以下步骤:
44.(1)获取若干个业务容器,所述业务容器是对安全接入服务虚拟化获得的,也即对网关程序进行虚拟化,形成对应的业务容器,在具体实施过程中,可以按标准ssl、ssal及采集终端协议划分不同业务容器,提供统一的边界安全服务,具体参见图2;
45.(2)将各个业务容器均注册到负载均衡进程中,由负载均衡进程对外提供唯一的服务地址和端口号;
46.(3)当监测到负载均衡进程接收到某客户端发送的访问请求后,控制负载均衡进程按照预设的工作模式和轮询算法,在kubernetes容器框架下通过vpp中dpdk转发驱动与对应业务容器进行通信,完成数据转发。
47.在本发明实施例的一种具体实施方式中,所述若干个业务容器中的各业务容器属于同一类业务或不同类业务,属于同一类业务的业务容器分布于同一台物理机或不同物理机上。
48.在本发明实施例的一种具体实施方式中,所述业务容器的虚拟化方法包括以下步骤:
49.利用kubernetes容器框架针对安全接入服务,根据服务类型的不同、或业务逻辑的不同、或性能需求的不同制作不同的容器镜像,将容器镜像对相关服务的提供商进行发布,使得服务提供商加载完容器镜像后,根据自身提供服务的规模和并发量大小,对部署策略进行配置,并接收由提供商反馈的部署策略,所述kubernetes容器框架根据所述容器镜像和接收到的部署策略创建对应数量的业务容器。
50.在本发明实施例的一种具体实施方式中,在所述在kubernetes容器框架下通过
vpp中dpdk转发驱动与对应业务容器进行通信步骤之后,还包括:
51.利用kubernetes容器框架中的容器资源管理模块对各个业务容器进行资源动态监控,根据资源动态监控的结果进行业务容器的扩容或缩容;
52.当进行业务容器的扩容时,将扩容产生的业务容器注册到负载均衡进程中;
53.当进行业务容器的缩容时,将缩容涉及到的业务容器从负载均衡进程中删除。
54.其中,所述根据资源动态监控的结果进行业务容器的扩容,具体为:通过配置策略进行监控,性能不够了就扩容,性能过剩就缩容。
55.所述根据资源动态监控的结果进行业务容器的缩容,具体为:通过配置策略进行监控,性能不够了就扩容,性能过剩就缩容。
56.实施例2
57.基于与实施例1相同的发明构思,本发明实施例中提供了一种基于vpp的集群式虚拟化数据转发装置,包括:
58.获取单元,用于获取若干个业务容器,所述业务容器是对安全接入服务虚拟化获得的;
59.注册单元,用于将各个业务容器均注册到负载均衡进程中,由负载均衡进程对外提供唯一的服务地址和端口号;
60.数据转发单元,用于当监测到负载均衡进程接收到某客户端发送的访问请求后,控制负载均衡进程按照预设的工作模式和轮询算法,在kubernetes容器框架下通过vpp中dpdk转发驱动与对应业务容器进行通信,完成数据转发。
61.在本发明实施例的一种具体实施方式中,所述若干个业务容器中的各业务容器属于同一类业务或不同类业务,属于同一类业务的业务容器分布于同一台物理机或不同物理机上。
62.在本发明实施例的一种具体实施方式中,所述业务容器的虚拟化方法包括以下步骤:
63.利用kubernetes容器框架针对安全接入服务,根据服务类型的不同、或业务逻辑的不同、或性能需求的不同制作不同的容器镜像,将容器镜像对相关服务的提供商进行发布,使得服务提供商加载完容器镜像后,根据自身提供服务的规模和并发量大小,对部署策略进行配置,并接收由提供商反馈的部署策略,所述kubernetes容器框架根据所述容器镜像和接收到的部署策略创建对应数量的业务容器。
64.在本发明实施例的一种具体实施方式中,所述基于vpp的集群式虚拟化数据转发装置还包括:
65.扩容或缩容单元,用于利用kubernetes容器框架中的容器资源管理模块对各个业务容器进行资源动态监控,根据资源动态监控的结果进行业务容器的扩容或缩容;
66.当进行业务容器的扩容时,将扩容产生的业务容器注册到负载均衡进程中;
67.当进行业务容器的缩容时,将缩容涉及到的业务容器从负载均衡进程中删除。
68.其余部分均与实施例1相同。
69.实施例3
70.本发明实施例中提供了一种基于vpp的集群式虚拟化数据转发装置,包括:
71.若干个物理机,各物理机均包括相连的主板和网卡,所述网卡中的安全接入服务
被虚拟化成业务容器,即将网卡中的网关程序虚拟化为业务容器;所述主板中设有vpp;
72.负载均衡进程,各个业务容器均被注册到所述负载均衡进程中,由负载均衡进程对外提供唯一的服务地址和端口号,由所述负载均衡进程负责统一的业务容器调度与流量分发
73.当所述负载均衡进程接收到某客户端发送的访问请求时,所述负载均衡进程按照预设的工作模式和轮询算法,在kubernetes容器框架下通过vpp中dpdk转发驱动与对应业务容器进行通信,完成数据转发。
74.本发明实施例中需要转发的数据就是安全接入服务的相关报文,即安全接入网关中的各类业务报文,如ssl安全接入服务报文、加解密服务报文、采集接入服务报文等等,本发明实施例中不对具体业务进行限定,其可以服务于各种业务,不同的业务提供不同的业务容器进程加入集群统一管理即可。
75.在本发明实施例的一种具体实施方式中,如图2所示,所述主板可以选用x86主板和x86硬件网卡,所述主板中设有vpp;所述x86硬件网卡的收发包采用所述vpp的转发框架,底层由dpdk转发驱动,保证数据包解析的性能,数据包从dpdk转发驱动送到x86主板后,通过vpp提供的memif接口以共享大页内存的方式与具体的业务容器进行通信,与传统的虚拟化方案相比,无需进行第二次的用户态到内核态的数据拷贝,大幅提升了数据包转发的性能。为保证系统整体的转发性能,所述负载均衡进程不使用kubernetes官方的提供的service服务,而改用基于dpdk进行流量分发的实现方法,并支持多种不同类型的负载均衡模式与负载算法。对于x86硬件网卡中的安全接入服务,可以根据服务类型的不同、或业务逻辑的不同、或性能需求的不同进行制作不同的容器镜像进行统一部署,同一类业务的业务容器可以分布于不同的物理机上,一台物理机上也可以由多个不同业务类型的业务容器,业务容器统一在所述负载均衡进程中进行注册,对外不暴露,由负载均衡对外提供唯一的服务地址和端口号进行流量分发。本发明实施例中对于业务容器生命周期的管理、资源调度、扩容缩容、服务编排、运行监控等,则由kubernetes提供的资源管理模块进行管理和调度。对网关业务的配置管理则由网关业务本身的统一配置管理接口进行管理。这样,网关业务开发者只需关注自身业务配置与业务报文的解析,而无需再关注资源的调度和管理。相关业务的运维人员,也只需要对使用kubernetes提供的资源管理模块即可完成对当前业务的升级扩容、资源重组等工作,而无需关注业务自身的组网与配置。
76.本发明实施例中提出的负载均衡进程,在将业务报文转发性能损耗降到最低的情况下,为各业务容器提供统一的流量分发,比如在三台物理机(node1、node2、node3)中部署有同一业务的6个业务容器并加入同一集群。负载均衡进程lb(load balance)对外提供客户端访问的唯一vip:192.168.17.1,并对负载均衡的工作模式和轮询算法进行配置,使之为该6个业务容器提供tun工作模式的轮询调度,该负载均衡同时支持rr、wrr、wlc、dh、sh、lc、lblc、lblcr等8种负载均衡算法,以适应不同类型业务的负载均衡需求。以rr为例,当第一个客户端对192.168.17.1的对应业务端口进行访问时,lb会将该报文转发至第一个业务容器,第二个客户端访问该业务时转发至第二个业务容器,以此类推,循环轮询。负载均衡参照lvs标准还支持tun模式、dr模式、nat模式三种工作模式,相关区别与详述已经提供在参考资料中,此处不再赘述。可见,本发明实施例中的负载均衡与传统的lvs的区别在于,本发明中的负载均衡进程是通过dpdk转发驱动在kubernetes容器框架下,与后端业务容器进
行通信,所有报文均不经过linux内核协议栈。同时,所代理的真实服务器(即各个业务容器)并不一定是一台真实的物理机,而是kubernetes容器框架下的一个业务容器,提供了虚拟化、容器化场景下的高速流量分发能力。
77.本发明实施例中,还需要进行网关业务管理与容器资源管理。网关业务管理为业务自身的配置管理,与本发明关联不大,这里不再赘述。容器资源管理主要包括部署管理、资源调度、服务编排、运行监控、扩容缩容等,这部分管理是依赖于kubernetes的容器管理模块来实现,以弹性伸缩管理为例,为某服务根据资源动态监控的结果进行扩容或缩容的动态调整过程。以该业务的服务为对象,从cpu/内存使用率、连接数等方面对集群提供的服务状态进行持续监控,结合服务设定的上下限进行综合评定,当服务整体负载较高时,添加服务业务容器副本进行扩容,当服务负载较低时,平滑退出部分业务容器副本。
78.实施例4
79.基于与实施例1相同的发明构思,本发明实施例中提供了一种基于vpp的集群式虚拟化数据转发系统,包括存储介质和处理器;
80.所述存储介质用于存储指令;
81.所述处理器用于根据所述指令进行操作以执行根据实施例1中任一项所述方法的步骤。
82.本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd

rom、光学存储器等)上实施的计算机程序产品的形式。
83.本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
84.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
85.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
86.以上结合附图对本发明的实施例进行了描述,但是本发明并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本发明的启示下,在不脱离本发明宗旨和权利要求所保护的范围情况下,还可做出很多形式,这些均属于本发明的保护之内。
87.以上显示和描述了本发明的基本原理和主要特征和本发明的优点。本行业的技术人员应该了解,本发明不受上述实施例的限制,上述实施例和说明书中描述的只是说明本发明的原理,在不脱离本发明精神和范围的前提下,本发明还会有各种变化和改进,这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。
当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1