**
**
我们先分析实现虚拟网络服务的主要技术,指出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负载均衡技术。
下面是这三种IP负载均衡技术的优缺点
注:以上三种方法所能支持最大服务器数目的估计是假设调度器使用 100M 网卡,调度器的硬件配置与后端服务器的硬件配置相同,而且是对一般 Web 服 务。使用更高的硬件配置(如千兆网卡和更快的处理器)作为调度器,调度器所能调度的服务器数量会相应增加。当应用不同时,服务器的数目也会相应地改变。所 以,以上数据估计主要是为三种方法的伸缩性进行量化比较。
VS/NAT
VS/NAT 的优点是服务器可以运行任何支持 TCP/IP 的操作系统,它只需要一个 IP 地址配置在调度器上,
服务器组可以用私有的 IP 地址。缺点是它的伸缩能力有限, 当服务器结点数目升到 20 时,调度器本身
有可能成为系统的新瓶颈,因为在 VS/NAT 中请求和响应报文都需要通过负载调度器。
VS/TUN
VS/TUN 技术对服务器有要求,即所有的服务器必须支持 “ IP Tunneling” 或者 “ IPEncapsulation”协议。目前,VS/TUN 的后端服务器主要运行 Linux 操作系统。在 VS/TUN 的集群系统中,负载调度器只将请求调度到不同的后端服务器,后端服务器将应答的数据直接返回给用户。这样,负载调度器就可以处理大量的请求,它甚至可以调 度百台以上的服务器(同等规模的服务器),而它不会成为系统的瓶颈。即使负载调度器只有 100Mbps的全双工网卡,整个系统的最大吞吐量可超过 1Gbps。所以,VS/TUN 可以极大地增加负载调度器调度的服务器数量。VS/TUN 调度器可以调度上百台服务器,而它本身不会成为系统的瓶
颈,可以 用来构建高性能的超级服务器。
VS/DR
跟 VS/TUN 方法相同,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提
高整个集群系统的吞吐量。跟 VS/TUN 相比,这种方法没有 IP 隧道的开销,但调度器和服务器组都必
须在物理上有一个网卡通过不分断的局域网相连,如通过交换机或者高速的 HUB 相连。VIP 地址为调
度器和服务器组共享,调度器配置的 VIP 地址是对外可见的,用于接收虚拟服务的请求报文;所有的服
务器把 VIP 地址配置在各自的 Non-ARP 网络设备上,它对外面是不可见的,只是用于处 理目标地址为
VIP 的网络请求。
**
**
下面用图文的方式中介绍一下DR模式
结合上图来做一个基本原理的说明:
Director 接收用户的请求,然后根据负载均衡算法选取一台 realserver,将包转发
过去,最后由 realserver 直接回复给用户。
1 client 向目标 vip 发出请求,Director 接收。
2 VS 根据负载均衡算法选择一台 active 的 realserver(假设是 172.25.1.3),将此 RIP 所在网
卡的 mac 地址作为目标 mac 地址,发送到局域网里。
3 realserver(172.25.1.3)在局域网中收到这个帧,拆开后发现目标 IP(VIP)与本地匹配,于是
处理这个报文。随后重新封装报文,发送到局域网。
4 如果 client 与 VS 同一网段,那么 client(172.25.1.250)将收到这个回复报文。如果跨了网段,
那么报文通过 gateway/路由器经由 Internet 返回给用户。
注意的问题:
vs/dr 本身不会关心 IP 层以上的信息,即使是端口号也是 tcp/ip 协议栈去判断是否正确,vs/dr 本
身主要做这么几个事:
1)接收 client 的请求,根据你设定的负载均衡算法选取一台 realserver 的 ip;
2)以选取的这个 ip 对应的 mac 地址作为目标 mac,然后重新将 IP 包封装成帧转发给这台 RS;
3)在 hashtable 中记录连接信息。
vs/dr 做的事情很少,也很简单,所以它的效率很高,不比硬件负载均衡设备差多少。
数据包、数据帧的大致流向是这样的:client –> VS –> RS –> client
vs主要作为目标地址mac地址转发而这一过程在数据链路层来实现的,所以 director 必须和 RS 在同一网段里面。
2 实验测试:
2.1 环境介绍
Load Balance:172.25.1.2
Virtual IP: 172.25.1.100
Realserver1: 172.25.1.3
Realserver1: 172.25.1.4
2.2实验步骤
1)安装ipvsadm
/etc/init.d/ipvsadm start
2 ) vs临时配置
ipvsadm -A -t 172.25.1.100:80 -s rr
-A - t添加虚拟虚拟服务为tcp模式,virtualIP为172.25.1.100轮询的机制为轮询
ipvsadm -a -t 172.25.1.100:80 -r 172.25.1.4:80 -g
-a -t 添加rs IP 172.25.1.4 端口80
ipvsadm -a -t 172.25.1.100:80 -r 172.25.1.4:80 -g
ipvsadm -ln 查看策略
ip addr add 172.25.1.100/24 dev eth0 绑定vip到eth0网卡上
3)rs临时配置
ip addr add 172.25.1.100/32 dev lo
这里有两点原因
1 既然要让 RS 能够处理目标地址为 vip 的 IP 包,首先必须要让 RS 能接收到这个包。
在 lo 上配置 vip 能够完成接收包并将结果返回 client。
2 不可以将 VIP 设置在出口网卡eth0上,否则会响应客户端的 arp request,造成 client/gateway
arp table 紊乱,以至于整个 loadbalance 都不能正常工作。
arptables -A IN -d 172.25.1.100 -j DROP 将所有访问172.25.1.100的请求都丢弃
arptables -A OUT -s 172.25.1.100 -j mangle –mangle-ip-s 172.25.1.4 将172.25.1.100地址的转为目标地址172.25.1.4向外发出
arptables -nL 输出地址查看策略
安装httpd服务更好展现实验效果
yum install httpd -y
编写httpd发布文件
vim /var/www/html/index.html
4 )客户端测试
查看rs server3的mac地址
结果分析:说明了vs主要工作就是实现目标MAC地址转发!
2.3 负载均衡
如果增加了n台rs服务器,这个时候就需要负载均衡技术了
1)再增加了一台rs 2 配置和上面一样,这里就不做演示了
2)主机测试
结果分析:在vs中配置的-s rr轮询可以看出
这个时候有个问题就是如果后端的web服务done掉了,vs不会发现,这在生产活动中是不允许的!这就需要做健康检查
2.4 工具的健康检查
1) 安装软件
yum install ldirectord-3.9.5-3.1.x86_64.rpm
2)可能安装的时候会出现安装不了的情况,针对红帽的软件来说,我们需要对yum源进行配置
3 )启动服务
/etc/init.d/ldirectord start
4)查看配置文件
rpm -ql ldirectord
cp /usr/share/doc/ldirectord-3.9.5/ldirectord.cf /etc/ha.d/
vim /etc/ha.d/ldirectord.cf
virtual=172.25.1.100:80real=172.25.1.3:80 gatereal=172.25.1.4:80 gatefallback=127.0.0.1:80 gateservice=httpscheduler=rr#persistent=600#netmask=255.255.255.255protocol=tcpchecktype=negotiatecheckport=80request="index.html"#receive="Test Page" #必须要注释掉#virtualhost=www.x.y.z
/etc/init.d/ldirectord reload
/etc/init.d/ldirectord restart
5)为了看出ldirectord的工作模式,把rs上手动添加的vip手动去掉
ip addr del 172.25.1.100/32 dev lo
只要你重新启动服务就可以看见ip会继续出现lo接口上
6)这个时候假如你done掉rs一个web,你在调度器上查看策略
这个时候你可能还会有个问题就是,万一调度器也坏掉了,系统不是就瘫痪了?
下面接下来说的就是
2.5 LVS +keepalived 高可用集群
1)源码安装三部曲
tar zxf keepalived-2.0.6.tar.gz
cd keepalived-2.0.6
yum install rpm-build.x86_64
yum install gcc -y
yum install openssl-devel
./configure –prefix=/usr/local/keepalived
./configure –prefix=/usr/local/keepalived –with-init=SYSV
make
make install
ln -s /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
ln -s /usr/local/keepalived/etc/keepalived /etc/
ln -s /usr/local/keepalived/sbin/keepalived /usr/sbin
2 )关闭ldirectord服务,在某些功能上和keepalived冲突
/etc/init.d/keepalived start
2)编写配置文件 主备模式
vim /etc/keepalived/keepalived.conf
! Configuration File for keepalivedglobal_defs {notification_email {root@localhost
}notification_email_from keepalived@localhost smtp_server 127.0.0.1 #设置 smtp server 地址smtp_connect_timeout 30 #设置连接 smtp 服务器超时时间router_id LVS_DEVEL #load balancer 的标识 ID,用于 email 警报vrrp_skip_check_adv_addr#vrrp_strictvrrp_garp_interval 0vrrp_gna_interval 0
}vrrp_instance VI_1 {state MASTER #备机改为 BACKUP,此状态是由 priority 的值来决定的,当前#priority 的值小于备机的值,那么将会失去 MASTER 状态interface eth0 #HA 监测网络接口virtual_router_id 51 #主、备机的 virtual_router_id 必须相同,取值 0-255priority 100 #主机的优先级,备份机改为 50,主机优先级一定要大于备机advert_int 1 #主备之间的通告间隔秒数authentication { #主备切换时的验证auth_type PASS #设置验证类型,主要有 PASS 和 AH 两种auth_pass 1111 #设置验证密码,在一个 vrrp_instance 下,MASTER 与 BACKUP 必#须使用相同的密码才能正常通信}virtual_ipaddress { #设置虚拟 IP 地址,可以设置多个虚拟 IP 地址,每行一个172.25.1.100}
}
virtual_server 172.25.1.100 80 { #定义虚拟服务器delay_loop 6 #每隔 6 秒查询 realserver 状态lb_algo rr #lvs 调度算法,这里使用轮叫lb_kind DR LVS 是用 DR 模式#persistence_timeout 50 #会话保持时间,单位是秒,这个选项对于动态网页是非常有
用的,为集群系统中 session 共享提供了一个很好的解决方案。有了这个会话保持功能,用户的
请求会被一直分发到某个服务节点,直到超过这个会话保持时间。需要注意的是,这个会话保
持时间,是最大无响应超时时间,也就是说用户在操作动态页面时,如果在 50 秒内没有执行任
何操作,那么接下来的操作会被分发到另外节点,但是如果一直在操作动态页面,则不受 50 秒
的时间限制。protocol TCP #指定转发协议类型,有 tcp 和 udp 两种real_server 172.25.1.3 80 { #配置服务节点weight 1 #配置服务节点的权值,权值大小用数字表示,数字越大,权
值越高,设置权值的大小可以为不同性能的服务器分配不同的负载,可以对性能高的服务器设
置较高的权值,而对性能较低的服务器设置相对较低的权值,这样就合理的利用和分配了系统
资源TCP_CHECK { #realserve 的状态检测设置部分,单位是秒connect_timeout 3 #10 秒无响应超时retry 3 #重试次数delay_before_retry 3 #重试间隔}}real_server 172.25.1.4 80 {weight 1TCP_CHECK {connect_timeout 3retry 3delay_before_retry 3}}
}
3)增加一台调度器服务器作如下的配置
! Configuration File for keepalivedglobal_defs {notification_email {root@localhost
}notification_email_from keepalived@localhostsmtp_server 127.0.0.1smtp_connect_timeout 30router_id LVS_DEVELvrrp_skip_check_adv_addr#vrrp_strictvrrp_garp_interval 0vrrp_gna_interval 0
}vrrp_instance VI_1 {state BACKUPinterface eth0virtual_router_id 51priority 50advert_int 1authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {172.25.1.100}
}
virtual_server 172.25.1.100 80 {delay_loop 6lb_algo rrlb_kind DR#persistence_timeout 50protocol TCPreal_server 172.25.1.3 80 {weight 1TCP_CHECK {connect_timeout 3retry 3delay_before_retry 3}}real_server 172.25.1.4 80 {weight 1TCP_CHECK {connect_timeout 3retry 3delay_before_retry 3}}
}
/etc/init.d/keepalived reload
/etc/init.d/keepalived restart
4 )高可用测试:停止 master 上的 keepalived 服务,会发现客户端仍然可以访问。