LVS的IP负载均衡
前言简介
可伸缩网络服务的几种结构,它们都需要一个前端的负载调度器(或者多个进行主从备份)。我们先分析实现虚拟网络服务的主要技术,指出IP负载均衡技术是在负载调度器的实现技术中效率最高的。在已有的IP负载均衡技术中,主要有通过网络地址转换(Network Address Translation)将一组服务器构成一个高性能的、高可用的虚拟服务器,我们称之为VS/NAT技术(Virtual Server via Network Address Translation)。在分析VS/NAT的缺点和网络服务的非对称性的基础上,我们提出了通过IP隧道实现虚拟服务器的方法VS/TUN (Virtual Server via IP Tunneling),和通过直接路由实现虚拟服务器的方法VS/DR(Virtual Server via Direct Routing),它们可以极大地提高系统的伸缩性。VS/NAT、VS/TUN和VS/DR技术是LVS集群中实现的三种IP负载均衡技术。
一、LVS-NAT
客户通过Virtual IP Address(虚拟服务的IP地址)访问网络服务时,请求报文到达调度器,调度器根据连接调度算法从一组真实服务器中选出一台服务器,将报文的目标地址Virtual IP Address改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最后将修改后的报文发送给选出的服务器。同时,调度器在连接Hash 表中记录这个连接,当这个连接的下一个报文到达时,从连接Hash表中可以得到原选定服务器的地址和端口,进行同样的改写操作,并将报文传给原选定的服务器。当来自真实服务器的响应报文经过调度器时,调度器将报文的源地址和源端口改为Virtual IP Address和相应的端口,再把报文发给用户。这样,客户所看到的只是在Virtual IP Address上提供的服务,而服务器集群的结构对用户是透明的。对改写后的报文,应用增量调整Checksum的算法调整TCP Checksum的值,避免了扫描整个报文来计算Checksum的开销。
VS/NAT的体系结构如图所示。
二、LVS-DR
跟VS/TUN 方法相同,VS/DR利用大多数Internet服务的非对称特点,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提高整个集群系统的吞吐量。VS/DR的体系结构如图所示:调度器和服务器组都必须在物理上有一个网卡通过不分断的局域网相连,如通过高速的交换机或者HUB相连。VIP地址为调度器和服务器组共享,调度器配置的VIP地址是对外可见的,用于接收虚拟服务的请求报文;所有的服务器把VIP地址配置在各自的Non-ARP网络设备上,它对外面是不可见的,只是用于处理目标地址为VIP的网络请求。
三、LVS-TUN
在VS/NAT 的集群系统中,请求和响应的数据报文都需要通过负载调度器,当真实服务器的数目在10台和20台之间时,负载调度器将成为整个集群系统的新瓶颈。大多数Internet服务都有这样的特点:请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理,即在负载调度器中只负责调度请求而响应直接返回给客户,将极大地提高整个集群系统的吞吐量。
IP隧道(IP tunneling)是将一个IP报文封装在另一个IP报文的技术,这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network),在其中隧道都是静态建立的,隧道一端有一个IP地址,另一端也有唯一的IP地址。
我们利用IP隧道技术将请求报文封装转发给后端服务器,响应报文能从后端服务器直接返回给客户。但在这里,后端服务器有一组而非一个,所以我们不可能静态地建立一一对应的隧道,而是动态地选择一台服务器,将请求报文封装和转发给选出的服务器。这样,我们可以利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。VS/TUN的体系结构如图所示,各个服务器将VIP地址配置在自己的IP隧道设备上。
四、LVS的负载调度
在内核中的连接调度算法上,IPVS已实现了以下八种调度算法:
轮叫调度(Round-Robin Scheduling)
轮叫调度(Round Robin Scheduling)算法就是以轮叫的方式依次将请求调度不同的服务器,即每次调度执行i = (i + 1) mod n,并选出第i台服务器。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。
加权轮叫调度(Weighted Round-Robin Scheduling)
加权轮叫调度(Weighted Round-Robin Scheduling)算法可以解决服务器间性能不一的情况,它用相应的权值表示服务器的处理性能,服务器的缺省权值为1。假设服务器A的权值为1,B的权值为2,则表示服务器B的处理性能是A的两倍。加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接,权值高的服务器比权值低的服务器处理更多的连接,相同权值的服务器处理相同数目的连接数。
最小连接调度(Least-Connection Scheduling)
最小连接调度(Least-Connection Scheduling)算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器,其连接数加1;当连接中止或超时,其连接数减一。
加权最小连接调度(Weighted Least-Connection Scheduling)
加权最小连接调度(Weighted Least-Connection Scheduling)算法是最小连接调度的超集,各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1,系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。
基于局部性的最少链接(Locality-Based Least Connections Scheduling)
基于局部性的最少链接调度(Locality-Based Least Connections Scheduling,以下简称为LBLC)算法是针对请求报文的目标IP地址的负载均衡调度,目前主要用于Cache集群系统,因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标IP地址的请求调度到同一台服务器,来提高各台服务器的访问局部性和主存Cache命中率,从而整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于其一半的工作负载,则用“最少链接”的原则选出一个可用的服务器,将请求发送到该服务器。
带复制的基于局部性最少链接(Locality-Based Least Connections with Replication Scheduling)
带复制的基于局部性最少链接调度(Locality-Based Least Connections with Replication Scheduling,以下简称为LBLCR)算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求,一台Cache 服务器可能会忙不过来处理这些请求。这时,LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器,映射该“热门”站点到这台Cache服务器,很快这台Cache服务器也会超载,就会重复上述过程选出新的Cache服务器。这样,可能会导致该“热门”站点的映像会出现在所有的Cache服务器上,降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器(服务器集合),当该“热门”站点的请求负载增加时,会增加集合里的Cache服务器,来处理不断增长的负载;当该“热门”站点的请求负载降低时,会减少集合里的Cache服务器数目。这样,该“热门”站点的映像不太可能出现在所有的Cache服务器上,从而提供Cache集群系统的使用效率。LBLCR算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组;按“最小连接”原则从该服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载;则按“最小连接”原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。
目标地址散列调度(Destination Hashing Scheduling)
目标地址散列调度(Destination Hashing Scheduling)算法也是针对目标IP地址的负载均衡,但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
源地址散列调度(Source Hashing Scheduling)
源地址散列调度(Source Hashing Scheduling)算法正好与目标地址散列调度算法相反,它根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目标地址散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本相似,除了将请求的目标IP地址换成请求的源IP地址,所以这里不一一叙述。在实际应用中,源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中,它们可以保证整个系统的唯一出入口。
=======================================================================
五、构建LVS三种模型集群
1、构建LVS-NAT模型
NAT模型:
目标地址转换所有客户端的请求都被Director 根据访问请求和算法被定向到后台的Real Server 上。
数据包地址转换过程:
S:CIP D:VIP------->Director------>S:CIP D:RIP------>Real Server------>
----->S:RIP D:CIP----->Director----->S:VIP D:CIP
Director 和Real Server 必须在同一个网段中;
RIP是一般来说是私有地址,仅集群内部节点间通信;
Director同时处理入站和出站连接,会响应所有的请求在客户端和Real Server 之间,所承担的负载较大;
Real server的网关要指向DIP,以响应客户端请求;
Director 可以映射网络端口,即前端使用标准端口,后端可以使用非标准端口;
Real server可以是任意的操作系统;
Director很容易成为系统瓶颈;
以web服务为例
NAT模型实现:
需要三台虚拟机,一台Director需要有两块网卡,一块网卡网桥模式,另一块网卡仅主机模式,两台Real server各一块网卡都是仅主机模式;
=================================================================
Director操作:
# grep -i "ipvs" /boot/config-2.6.18-164.el5
查看Director主机内核是否支持ipvs
#yum install ipvsadm #安装ipvs软件包
#rpm -ql ipvsadm #查看安装软件生成那些文件
#man ipvsadm #查看帮助文档
----------------------------------------------------------------------
ipvsadm
定义集群服务,VIP,TCP,PORT
向集群服务添加RS服务
-A 定义新的集群服务
-E 修改或者编辑已有的集群服务
-D 删除某集群服务
-C 清空所有规则
添加RS完整用法:
ipvsadm -A|E -t|u|f VIP:PORT [-s scheduler] [-p timeout] [-M netmask]
添加real server用法:
ipvsadm -A|E -t|u|f VIP:PORT -r real_server_address [-g|i|m ] [-w weight]
-g gateway DR模型(默认模型)
-i TUN
-m NAT
ipvsadm -R = ipvsadm-restore
ipvsadm -S = ipvsadm-save
ipvsadm -Z = ipvsadm-zero
ipvsadm --stats 显示统计信息
ipvsadm --rate 显示速度统计
ipvsadm -n 以数字number的形式显示
ipvsadm -Lcn 查看连接相关属性
----------------------------------------------------------------------
#配置Director两块网卡地址为要求的地址,一块为外网地址172.16.33.1,一块为内网地址192.168.10.1,内网地址要和real server的地址在同一网段;
#配置real server 的两快网卡地址分别为192.168.10.10 和192.168.10.11
#把192.168.10.10 和192.168.10.11的网关指向Director 的内部地址(DIP仅主机)
# echo 1 > /proc/sys/net/ipv4/ip_forward 或者vim /etc/sysctl net.ipv4.ip_forward = 1#开启路由转发功能
#在两个real server主机中添加网页,理论上我们应该添加相同的网页来测试集群性能,但是这里我们为了区分效果,故意建立两个不同的网页测试!
# ipvsadm -A -t 192.168.10.12:80(VIP网桥)-s rr
# ipvsadm -a -t 192.168.10.12:80(VIP网桥)-r 192.168.10.10(RIP)-m
# ipvsadm -a -t 192.168.10.12:80(VIP网桥)-r 192.168.10.11(RIP)-m
# ipvsadm -L -n 查看当前的规则
# ipvsadm -L --rate 统计数据的速率
# ipvsadm -L --stats 统计数据总和
# 然后就可以测试网页了
# service ipvsadm save 保存规则
=================================================================
[root@station71 ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.71:80 rr
-> 192.168.168.129:80 Masq 1 0 0
-> 192.168.168.128:80 Masq 1 0 0
[root@station71 ~]# ipvsadm -L --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP station71.example.com:http 5 310 300 130375 114034
-> 192.168.168.129:http 3 141 136 58410 53745
-> 192.168.168.128:http 2 169 164 71965 60289
[root@station71 ~]# ipvsadm -L --rate
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS
-> RemoteAddress:Port
TCP station71.example.com:http 0 0 0 0 0
-> 192.168.168.129:http 0 0 0 0 0
-> 192.168.168.128:http 0 0 0 0 0
2、构建LVS模型-DR模型:
直接路由客户端请求经过Director,Real Server 直接回应客户端
数据包地址转换过程:
S:CIP D:VIP----->Director--->S:CIP D:RIP -----> Real Server---> S:VIP D:CIP
Real Server 上必须配置VIP 切需要隐藏起来,只有在响应客户端请求时才使用VIP 作为源地址,除此之外并不使用此VIP。
集群节点和Director 必须在同一个网络中;
RIP 不要求为私有地址,可以使用公网地址;
Director 仅处理所有进来的入站请求;
Real Server 不能以DIP 作为网关,而是以公网上的某台路由器作为网关;
Director 不能再使用端口映射;
大多数操作系统可以被用来作为Real Server,只要有两个功能:隔离arp广播,能在同一块网卡上配置多个ip地址,就可以作为real server;
LVS-DR 模式可以处理比LVS-NAT 更多的请求。
实际生产环境中最常用的一种方式,优点:
RIP 为公网地址,管理员可以远程连接Real Server 来查看工作状态;
一旦Director 宕机,可以通过修改DNS 记录将A 记录指向RIP 继续向外提供服务;
=======================================================================
PS:Director 分发到Real Server 的过程中,数据包的源地址和目标地址都没有发生改变,Director 仅仅是将目标mac 地
址转换成某台Real Server 的mac 地址,源mac 地址改为Director 内网网卡的mac 地址。
两个技术难题
1 Real Server 要避免对客户端发来的对VIP 的arp 地址解析请求;
解决方法
1) 修改内核的两个参数:arp_announce, arp_ignore。
arp_announce :通告,定义不同级别:当ARP 请求通过某个端口进来是否利用这个接口来回应。
定义在响应ARP 请求时所使用的模型:
0 - (default) Use any local address, configured on any interface.
利用本地的任何地址,不管配置在哪个接口上去响应ARP 请求;
1 - Try to avoid local addresses that are not in the target's subnet for this interface.
当本台主机上有多个ip地址时,回应时仅回应跟源ip地址在同一网段的地址回应,避免使用另外一个接口上的mac 地址去响应ARP 请求;
2 - Always use the best local address for this target.
尽可能使用能够匹配到ARP 请求的最佳地址。
arp_ignore:当发过来后发现自己正是请求的地址是否响应;
0 - (default): reply for any local target IP address, configured on any interface
利用本地的任何地址,不管配置在哪个接口上去响应ARP 请求;
1 - reply only if the target IP address is local address configured on the incoming interface.
哪个接口上接受ARP 请求,就从哪个端口上回应。
2 - reply for any local target IP address, configured on any interface ,,reply only if the target IP address is local address configured on the incoming interface and both with sender's ip address
3 - do not reply for local address
4 - 7 reserved
8 - do not reply for all local addresses
=======================================================================
DR模型
两个Real server网卡配置为桥接模式也需要配置公网IP,Director也需要配置公网ip,且需要跟RIP 在同一网段中;
Director配置:
# ifdown eth1 如果有两块网卡,先关闭一块网卡
# ifconfig eth0:1 172.16.100.1 broadcast 172.16.100.1 netmask 255.255.255.255
为Director配置别名
# route add -host 172.16.100.1 dev eth0:1 添加路由
# route -n 查看路由信息
# vim /etc/sysctl ip_forward=1 开启路由转发功能
# ipvsadm -A -t 172.16.100.1:80 -s rr
# ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.11 -g
# ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.12 -g
两个Real server配置:
# ifconfig lo down 先关闭lo
# vim /proc/sys/net/ipv4/conf/lo/arp_ignore 1
# vim /proc/sys/net/ipv4/conf/all/arp_ignore 1
# vim /proc/sys/net/ipv4/conf/lo/arp_announce 2
# vim /proc/sys/net/ipv4/conf/all/arp_announce 2 开启内核中的对应的通告和回应功能
# ifconfig lo:0 172.16.100.1 broadcast 172.16.100.1 netmask 255.255.255.255
# route add -host 172.16.100.1 dev lo:0 添加路由
# service ipvsadm save 保存规则
=======================================================================
[root@station71 ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.77:80 rr
-> 192.168.0.79:80 Route 1 0 0
-> 192.168.0.78:80 Route 1 0 1
[root@station71 ~]# ipvsadm -L --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP station77.example.com:http 94 2360 0 744459 0
-> station79.example.com:http 47 149 0 8200 0
-> station78.example.com:http 47 2211 0 736259 0
[root@station71 ~]# ipvsadm -L --rate
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS
-> RemoteAddress:Port
TCP station77.example.com:http 0 0 0 0 0
-> station79.example.com:http 0 0 0 0 0
-> station78.example.com:http 0 0 0 0 0
转载于:https://blog.51cto.com/very1024/834625