发明内容
本申请提供了一种服务器负载均衡方法、装置及系统,以使LVS实现跨网段的负载均衡。
为了解决上述问题,本申请公开了一种服务器负载均衡方法,包括:
配置第一虚拟地址及其端口,和,第二虚拟地址及其端口,其中第一虚拟地址及其端口用于与客户端建立连接,第二虚拟地址及其端口用于与真实服务器建立连接;
当接收客户端发来的数据包时,将该数据包中的源地址及源端口转换为第二虚拟地址及其端口,将该数据包的目的地址及目的端口转换为真实服务器的地址及其端口,然后将转换后的数据包转发给真实服务器;
当接收真实服务器发来的数据包时,将该数据包中的源地址及源端口转换为第一虚拟地址及其端口,将该数据包的目的地址及目的端口转换为客户端的真实地址及其端口,然后将转换后的数据包转发给客户端。
优选的,所述将转换后的数据包转发给真实服务器之前,还包括:在所述转换后的数据包中添加客户端的真实地址及其端口。
优选的,还包括:真实服务器收到所述转换后的数据包,通过解析获取客户端的真实地址及其端口。
优选的,还包括:判断接收到的数据包的目的地址或目的端口,如果目的地址为所述第一虚拟地址,或者,目的端口为所述第一虚拟地址的端口,则所述数据包是客户端发来的数据包;否则,是真实服务器发来的数据包。
优选的,当接收客户端发来的数据包时,所述转换之前还包括:根据数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则进行所述的转换;其中,所述源地址和源端口为客户端真实的地址和端口,所述目的地址和目的端口为所述第一虚拟地址及其端口。
优选的,如果未查询到,还包括:判断是否需要新建连接,如果是,则选择建立连接的真实服务器,并选择用于与所述真实服务器建立连接的第二虚拟地址及其端口,创建session,然后进行所述的转换;如果否,则退出。
优选的,当接收真实服务器发来的数据包时,所述转换之前还包括:根据数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则进行所述的转换;如果未查询到,则退出;其中,所述源地址和源端口为真实服务器的地址和端口,所述目的地址和目的端口为所述第二虚拟地址及其端口。
本申请还提供了一种服务器负载均衡装置,包括:
虚拟配置单元,用于配置第一虚拟地址及其端口,和,第二虚拟地址及其端口,其中第一虚拟地址及其端口用于与客户端建立连接,第二虚拟地址及其端口用于与真实服务器建立连接;
第一地址转换单元,用于当接收客户端发来的数据包时,将该数据包中的源地址及源端口转换为第二虚拟地址及其端口,将该数据包的目的地址及目的端口转换为真实服务器的地址及其端口,然后将转换后的数据包转发给真实服务器;
第二地址转换单元,用于当接收真实服务器发来的数据包时,将该数据包中的源地址及源端口转换为第一虚拟地址及其端口,将该数据包的目的地址及目的端口转换为客户端的真实地址及其端口,然后将转换后的数据包转发给客户端。
优选的,所述装置还包括:地址添加单元,用于在所述第一地址转换单元将转换后的数据包转发给真实服务器之前,在所述转换后的数据包中添加客户端的真实地址及其端口。
优选的,所述装置还包括:数据包判断单元,用于判断接收到的数据包的目的地址或目的端口,如果目的地址为所述第一虚拟地址,或者,目的端口为所述第一虚拟地址的端口,则所述数据包是客户端发来的数据包;否则,是真实服务器发来的数据包。
优选的,所述装置还包括:第一查询单元,用于根据客户端发来的数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则触发所述第一地址转换单元;其中,所述源地址和源端口为客户端真实的地址和端口,所述目的地址和目的端口为所述第一虚拟地址及其端口。
优选的,如果未查询到,所述装置还包括:连接建立单元,用于判断是否需要新建连接,如果是,则选择建立连接的真实服务器,并选择用于与所述真实服务器建立连接的第二虚拟地址及其端口,创建session,然后触发所述第一地址转换单元;如果否,则退出。
优选的,所述装置还包括:第二查询单元,用于根据真实服务器发来的数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则触发所述第二地址转换单元;如果未查询到,则退出;其中,所述源地址和源端口为真实服务器的地址和端口,所述目的地址和目的端口为所述第二虚拟地址及其端口。
优选的,所述装置还包括:地址解析单元,设在真实服务器上,用于真实服务器收到所述转换后的数据包后,通过解析获取客户端的真实地址及其端口。
本申请还提供了一种服务器负载均衡系统,包括:虚拟服务器和与之相连的真实服务器,所述虚拟服务器包括如上述的服务器负载均衡装置。
优选的,所述真实服务器还包括:地址解析单元,用于收到所述转换后的数据包后,通过解析获取客户端的真实地址及其端口。
与现有技术相比,本申请包括以下优点:
首先,本申请基于原VS/NAT工作模式,在LVS和RS之间采用三层互联,并对LVS从客户端和真实服务器接收的数据包都进行源地址和目的地址的转换,从而使LVS能为更多个不同网段的RS服务。这种三层互联的方式实现了真正意义上的跨网段负载均衡,LVS上能够提供服务的RS数目不再受限制,因此可以扩展出层次化的网络拓扑。
其次,本申请简化了LVS和RS的配置和运营维护,原因如下:
第一,LVS和RS只需要三层互通,大大简化了前端部署的难度,并有利于层次化地网络拓扑;
第二,RS在接入LVS时只需要加载一个用于解析客户端真实地址和端口的内核模块,不需要做其他任何修改;不需要为vip添加额外配置,只需要和LVS三层互通,易于部署和维护;
第三,LVS不需要配置任何tag信息,简化了运营维护的复杂度。
当然,实施本申请的任一产品不一定需要同时达到以上所述的所有优点。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
本申请实现了一种跨网段的LVS负载均衡。本申请在LVS和RS之间采用三层互联,并对LVS从客户端和真实服务器接收的数据包都进行源地址和目的地址的转换,从而使LVS能为更多个不同网段的RS服务。
本申请基于原VS/NAT工作模式,下面首先介绍原VS/NAT工作模式下的TCP交互流程。
参照图2,是现有技术中原VS/NAT工作模式下的TCP交互流程示意图。
其中,Client表示客户端,LVS表示虚拟服务器,RS表示真实服务器;
cip:Client ip,客户端的ip地址;
cport:Client port,客户端上为cip提供服务的端口;
vip:virtual ip,LVS上绑定的虚拟ip,供用户客户端访问;
vport:virtual port,LVS上为vip提供服务的端口;
rip:Real Server ip,后端真实服务器的ip地址;
rport:Real Server port,后端真实服务器为rip提供服务的端口。
原VS/NAT工作模式下,LVS与后端的RS是两层互联,即LVS与RS处在同一个网段中并使用两层协议通信,相应的TCP交互流程如下:
1)Client端与LVS提供的vip、vport建立TCP连接;
2)LVS收到Client端发来的数据包后,进行DNAT(Destination NetworkAddress Translation,目的网络地址转换),把vip、vport转换为RS的rip和rport,然后转发给RS;
Client端发来的数据包中,源地址为cip,源端口为cport,目的地址为vip,目的端口为vport。经DNAT转换后的数据包为:源地址cip,源端口cport,目的地址rip,目的端口rport。
3)RS处理收到的报文,然后回复数据,数据包的源ip和port是RS的rip和rport,目的ip和port是Client的cip和cport;由于RS的默认路由设置为LVS的ip,所以RS发向Client的报文会被路由到LVS;
4)LVS收到RS发给Client的报文后,进行SNAT(Source Network AddressTranslation,源网络地址转换),把RS的rip和rport转换为LVS的vip和vport,然后发送给Client端。
基于图2所示的原VS/NAT工作模式,本申请所述的跨网段的LVS负载均衡工作模式如图3所示,其中:
Client表示客户端,LVS表示虚拟服务器,RS表示真实服务器,cip、cport、vip、vport、rip、rport的含义与图1和图2也相同。不同的是,图3中在LVS上还设定了bip和bport,含义如下:
bip:backend ip,LVS机器网卡上绑定的ip地址,用来与后端RS建立连接。
bport:backend port,backend ip可以使用的端口。
图3所示工作模式的基本工作原理是:LVS提供vip和vport供Client连接,连接成功后,LVS会使用bip和bport去和后端的RS建立连接,在后续的包交互过程中,LVS主要完成以下两个功能:
第一,session的维护:session中存放着vip、vport、bip和bport,分别用来关联LVS与Client之间的连接、LVS与RS之间的连接;
第二,在包转发的过程中进行SNAT和DNAT,以便发向Client和RS的数据包都有正确的源和目的ip、源和目的端口。
在图3所示工作模式下,本申请中跨网段的TCP交互流程如图4所示,与原VS/NAT工作模式下的TCP交互流程存在以下区别:
1)LVS在处理从Client发向RS的报文时,不只进行DNAT,还需要进行SNAT,把源ip和port修改为LVS上配置的bip和bport;
2)LVS在处理从RS发向Client的报文时,不只进行SNAT,还需要进行DNAT,把bip和bport修改为Client的cip和cport;
3)在发给RS的报文中添加一个自定义的tcp_option,在option中放置真实的客户端ip和port(cip、cport);
4)RS端加载自定义的TCP协议Hook模块,该模块会获取报文tcp_option中的客户端真实ip和port,以便返回给用户程序真实的Client ip和port。
上述区别中的3)和4)并不是实现本申请必须的,是一个可选步骤,如果无需向用户程序或其他调用程序返回客户端真实的ip和port,则无需进行3)和4)的处理。
综上所述,由上述内容可以看出,本申请可通过以下方法实现跨网段的LVS负载均衡。
参照图5,是本申请实施例所述一种服务器负载均衡方法的流程图。
LVS进行以下处理:
步骤501,配置第一虚拟地址及其端口,和,第二虚拟地址及其端口,其中第一虚拟地址及其端口用于与客户端建立连接,第二虚拟地址及其端口用于与真实服务器建立连接;
其中,第一虚拟地址及其端口如上述的vip和vport,第二虚拟地址及其端口如上述的bip和bport。
步骤502,当接收客户端发来的数据包时,将该数据包中的源地址及源端口转换为第二虚拟地址及其端口,将该数据包的目的地址及目的端口转换为真实服务器的地址及其端口,然后将转换后的数据包转发给真实服务器;
其中,客户端发来的数据包的源地址及源端口为cip和cport,将其转换为bip和bport;目的地址及目的端口为vip和vport,将其转换为rip和rport。
步骤503,当接收真实服务器发来的数据包时,将该数据包中的源地址及源端口转换为第一虚拟地址及其端口,将该数据包的目的地址及目的端口转换为客户端的真实地址及其端口,然后将转换后的数据包转发给客户端。
其中,真实服务器发来的数据包的源地址及源端口为rip和rport,将其转换为vip和vport;目的地址及目的端口为bip和bport,将其转换为cip和cport。
需要说明的是,上述步骤502和503没有先后顺序的限制。
基于图5,详细的实现流程如图6所示,具体如下:
本实施例的实现流程均在Netfilter(包过滤系统)的IP_LOCAL_INHOOK点,因为从Client发来的报文目的ip是vip,会走到IP_LOCAL_IN点,从RS发来的报文目的ip是bip,也会走到IP_LOCAL_IN。此时就可以根据目的ip是否为vip来区分是Out-In(处理从Client发向RS的报文)还是In-Out(处理从RS发向Client的报文)。
步骤S10,报文进入到LVS的IP_LOCAL_IN HOOK点进行处理;
步骤S11,判断接收到的数据包的目的ip是否为vip;
如果是,则为Out-In,转入步骤S12;如果否,则目的ip是bip,为In-Out,转入步骤S13;
同理,也可以判断接收到的数据包的目的端口,如果目的端口为所述第一虚拟地址的端口vport,则所述数据包是客户端发来的数据包;否则,目的端口为bport,是真实服务器发来的数据包。
以下S12至S26是Out-In流程:
步骤S12,根据cip、cport、vip和vport查询session;
如果查询到与所述四元组(cip、cport、vip和vport)对应的session,表示Client与对应的RS之间已经建立连接,转入步骤S22;如果未查询到,表示Client与对应的RS之间未建立连接,本次传输是该Client第一次与对应的RS建立连接,转入步骤S14。
其中,所述cip、cport是数据包的源地址、源端口,vip、vport是数据包的目的地址和目的端口。
步骤S14,判断是否需要新建连接;
一般的标准是检查是否是SYN包,如果是,转入步骤S16;如果否,返回NF_ACCEPT,退出处理。
步骤S16,选择RS;
即根据预定义的负载均衡策略选择一个与当前Client建立连接的RS,所述负载均衡策略可选用现有技术中的任何一种策略。选择成功后,转入步骤S18。
步骤S18,选择backend ip和port;
所述bip和bport用于LVS与S16选择的RS建立连接。本实施例中,backend ip是用户态的工具采用setsockopt的方式发送到内核中的,LVS会利用轮询的方式来选择backend ip和port。
步骤S20,创建session;
步骤S22,DNAT:将vip、vport转换为rip、rport;
步骤S24,SNAT:将cip、cport转换为bip、bport;
步骤S26,插入tcp_option,option中存放客户端的真实ip和port(cip、cport),进入IP_LOCAL_OUT点。
本步骤是可选步骤。
以下S13至S17是In-Out流程:
步骤S13,根据bip、bport、rip和rport查询session;
如果查询到与所述四元组(bip、bport、rip和rport)对应的session,表示RS与对应的Client之间已经建立连接,转入步骤S15;如果未查询到,表示RS与对应的Client之间未建立连接,返回NF_ACCEPT,退出处理。
步骤S15,SNAT:将rip、rport转换为vip、vport;
步骤S17,DNAT:将bip、bport转换为cip、cport,进入IP_LOCAL_OUT点。
上述流程中,如果选择执行步骤S26,则对应的RS中还需配置加载一个内核模块,在TCP协议中所述内核模块为Hook模块,用于在RS收到所述转换后的数据包后,通过解析获取客户端的真实ip及port。
在TCP协议中,Hook模块是通过Hook inet_stream_ops.getname与ipv4_specific.syn_recv_sock这两个函数实现。其中,通过Hookipv4_specific.syn_recv_sock函数,解析出Client ip与port并存入socket的sk_user_data中;通过Hook inet_stream_ops.getname函数,在应用层调用accet()、getpeername()时,返回sk_user_data中保存的Client ip与port。
参照图7,ipv4_specific.syn_recv_sock的Hook函数处理流程如下:
步骤701,调用原有的tcp_v4_syn_recv_sock函数创建sock;
步骤702,判断sock是否创建成功,并且sk_user_data是否为空;
如果是,则转入步骤703;如果否,则返回错误;
步骤703,解析报文中的tcp_option,解析出cip和cport,并放入sk_user_data中;
步骤704,返回socket。
相比于原有流程,只是添加了自定义tcp_option的解析。
参照图8,inet_stream_ops.getname Hook函数的处理流程如下:
步骤801,调用原有的inet_getname函数解析socket的相关信息;
步骤802,判断所述函数是否正常返回并且sk_user_data是否存在cip和cport信息;
如果是,则转入步骤803;如果否,则返回错误;
步骤803,从sk_user_data中解析出cip和cport信息,并更新上述调用的socket信息;
步骤804,返回调用结果。
相比于原有流程,只是添加了从sk_user_data中解析cip和cport的操作。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本申请所必须的。
综上所述,本申请实施例提供的LVS负载均衡方法在LVS和RS之间采用三层互联,进而为实现三层互联对LVS从客户端和真实服务器接收的数据包都进行源地址和目的地址的转换,从而使LVS能为更多个不同网段的RS服务。这种三层互联的方式实现了真正意义上的跨网段负载均衡,LVS上能够提供服务的RS数目不再受限制,因此可以扩展出层次化的网络拓扑。
更进一步分析,现有的DR模式是通过修改MAC的方式把数据包转发给RS,所以LVS工作在链路层,所以无法进行跨网段。原有的NAT模式仅仅修改Out-In报文的目的IP,并且RS回复的报文必须经过LVS以便进行地址转换,所以RS必须把默认网关指向LVS,而RS与默认网关必须在同一网段,此时LVS的角色类似RS上联的出口路由器,所以限制了LVS和RS必须在同一网段。而本申请提出的方式在Out-In时同时修改了源和目的IP,此时为了使RS回复的报文能经过LVS,只需要新的源IP和RS在内网中是三层互通的,这样RS回复的报文(目的IP是LVS的第二虚拟IP)就可以回到LVS以便进行地址转换,此时LVS的角色类似7层的负载均衡软件(HAProxy等),只不过是工作在内核中而已,因此可以实现跨网段的功能。
而且,本申请实施例所述方法还大大简化了LVS和RS的配置和运营维护,下面通过与其他方式相比较进行说明。
第一,背景技术中提到,在LVS的VS/DR和VS/NAT工作模式下,通过在LVS网卡上打tag的方式可以使LVS服务于多个网段的RS,但是这种方式的配置和运营维护十分复杂,这种复杂性体现在如下方面:
1)更改交换机端口工作模式的工作较为危险,容易导致网卡连接不上,增加运营维护成本:默认情况下,交换机端口工作在access模式,当需要更改为trunk模式时,需要首先修改服务器上的配置然后重启网络,再由运维部门同事修改端口工作模式。如果服务器上的配置修改有误,则工作模式修改后会导致网络无法连接,即使修改回原来的工作模式也不能正常连接,只能去现场操作,增加了运营维护的成本。
2)需要跨部门合作,步骤比较繁琐:首先要和业务部门同事确认后端RS所处的网段,再和运维部门同事确认该网段所处于的vlan,然后为每个vlan号配置网卡的tag设置。
3)后期的维护较为复杂:如果后端的RS由于机器搬迁或者其他原因更换了网段,需要重新确认vlan号,再重新设置网卡的tag设置。
第二,在原有的VS/TUN工作模式的基础上,LVS与后端RS经改造后也可以实现三层互联(跨多个网段)的功能,但是在该模式下,RS的配置较为复杂,体现在如下方面:
1)RS上需要建立tunnel设备,tunnel设备依赖于ipip模块(IPIP隧道协议是使用在两个路由器间对IP数据包进行封装的简单协议),因此需要为内核添加ipip模块的支持,另外RS的稳定性也会依赖于ipip的稳定性;
2)RS上需要为每个vip建立一个tunnel设备,同时配置tunnel设备的arp_annouce和arp_ignore选项,当vip较多时配置会较为繁琐,并且容易出错;
3)在修改vip时,容易出现忘记删除原tunnel设备及vip等问题,导致配置出错。
相比于上述两种方式,本申请不仅能够实现三层互联(跨多个网段)的功能,其配置和运营维护的简化性体现在以下方面:
1)LVS和RS只需要三层互通,大大简化了前端部署的难度,并有利于层次化地网络拓扑;
2)RS在接入LVS时只需要加载一个内核模块(Hook),不需要做其他任何修改;不需要为vip添加额外配置,只需要和LVS三层互通,易于部署和维护;
3)LVS不需要配置任何tag信息,简化了运营维护的复杂度。
基于上述方法实施例的说明,本申请还提供了相应的装置和系统实施例。
参照图9,是本申请实施例所述一种服务器负载均衡装置的结构图。
所述服务器负载均衡装置可设在LVS上运行,具体包括虚拟配置单元10、第一地址转换单元20和第二地址转换单元30,其中,
虚拟配置单元10,用于配置第一虚拟地址及其端口,和,第二虚拟地址及其端口,其中第一虚拟地址及其端口用于与客户端建立连接,第二虚拟地址及其端口用于与真实服务器建立连接;
第一地址转换单元20,用于当接收客户端发来的数据包时,将该数据包中的源地址及源端口转换为第二虚拟地址及其端口,将该数据包的目的地址及目的端口转换为真实服务器的地址及其端口,然后将转换后的数据包转发给真实服务器;
第二地址转换单元30,用于当接收真实服务器发来的数据包时,将该数据包中的源地址及源端口转换为第一虚拟地址及其端口,将该数据包的目的地址及目的端口转换为客户端的真实地址及其端口,然后将转换后的数据包转发给客户端。
可选的,所述服务器负载均衡装置还可以包括:
地址添加单元40,用于在所述第一地址转换单元20将转换后的数据包转发给真实服务器之前,在所述转换后的数据包中添加客户端的真实地址及其端口。
可选的,如果设置地址添加单元40,则所述服务器负载均衡装置还可以包括:
地址解析单元50,设在真实服务器上,用于真实服务器收到所述转换后的数据包后,通过解析获取客户端的真实地址及其端口。
优选的,所述服务器负载均衡装置还可以包括:
数据包判断单元60,用于判断接收到的数据包的目的地址或目的端口,如果目的地址为所述第一虚拟地址,或者,目的端口为所述第一虚拟地址的端口,则所述数据包是客户端发来的数据包;否则,是真实服务器发来的数据包。
优选的,所述服务器负载均衡装置还可以包括:
第一查询单元70,用于根据客户端发来的数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则触发所述第一地址转换单元20;其中,所述源地址和源端口为客户端真实的地址和端口,所述目的地址和目的端口为所述第一虚拟地址及其端口。
优选的,如果未查询到,所述服务器负载均衡装置还可以包括:
连接建立单元80,用于判断是否需要新建连接,如果是,则选择建立连接的真实服务器,并选择用于与所述真实服务器建立连接的第二虚拟地址及其端口,创建session,然后触发所述第一地址转换单元20;如果否,则退出。
优选的,所述服务器负载均衡装置还可以包括:
第二查询单元90,用于根据真实服务器发来的数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则触发所述第二地址转换单元30;如果未查询到,则退出;其中,所述源地址和源端口为真实服务器的地址和端口,所述目的地址和目的端口为所述第二虚拟地址及其端口。
对于上述装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
基于图9所示的服务器负载均衡装置,本申请实施例还提供了一种服务器负载均衡系统。所述服务器负载均衡系统主要包括虚拟服务器和与所述虚拟服务器相连的跨网段的多个真实服务器,其中所述虚拟服务器上可以设置上述虚拟配置单元10、第一地址转换单元20、第二地址转换单元30、地址添加单元40、数据包判断单元60、第一查询单元70、连接建立单元80、第二查询单元90,所述真实服务器上可以设置上述地址解析单元50。
上述服务器负载均衡装置及服务器负载均衡系统实现了一种全新的跨网段技术,可以使网络拓扑得到很大的改进,并简化了LVS和RS的配置,减少了运维的成本。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
而且,上文中的“和/或”表示本文既包含了“和”的关系,也包含了“或”的关系,其中:如果方案A与方案B是“和”的关系,则表示某实施例中可以同时包括方案A和方案B;如果方案A与方案B是“或”的关系,则表示某实施例中可以单独包括方案A,或者单独包括方案B。
以上对本申请所提供的一种服务器负载均衡方法、装置及系统,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。