高并发与负载均衡(三种负载模式)

随着互联网的飞速发展,传统的昂贵的大容量高性能服务器(F5 BIG-IP、Citrix NetScaler、A10)已经越来越应付不了日益增长的业务需求了,而高并发和负载均衡所带来的高可靠/高可用/低成本却完美的解决了传统服务器面临的一些问题。现在我们来简单聊聊高并发和负载均衡。

在上一讲中,我们弄清了访问一次网页时,里面所发生的的曲折动人的故事,那是我们一个客户端再向百度的服务器发送请求,而实际情况是百度要面临整个中国网民的访问和请求,如果依然将所有的服务都部署在一台服务器上,可想而知,那台服务器将要面临多大的压力,要具备多么强大的性能和带宽,由此我们引出高并发和负载均衡技术,并通过LVS来简单了解下它的原理。

LVS是 Linux Virtual Server 的简称,也就是Linux虚拟服务器。这是一个由章文嵩博士发起的一个开源项目,它的官方网是 现在 LVS 已经是 Linux 内核标准的一部分。使用 LVS 可以达到的技术目标是:通过 LVS 达到的负载均衡技术和 Linux 操作系统实现一个高性能高可用的 Linux 服务器集群,它具有良好的可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的性能。LVS 是一个实现负载均衡集群的开源软件项目,LVS架构从逻辑上可分为调度层、Server集群层和共享存储。

LVS包含几个组成部分:

VIP:虚拟服务器地址

DIP:转发的网络地址

1.和RIP通信:ARP协议,获取Real Server的RIP:MAC地址

2.转发Client的数据包到RIP上(隐藏的VIP)

RIP:后端真实主机(后端服务器)

CIP:客户端IP地址

1.LVS的基本工作原理:

简单的说就是通过负载均衡器,接收海量的请求,然后根据后面的server端情况运行情况分发给不同的server进行处理,然后返回处理结果的过程。

2.下面我们具体说下LVS的三种具体负载模式:

2.1 LVS/NAT原理和特点:

(a). 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP

(b). PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链

(c). IPVS比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP,然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP

(d). POSTROUTING链通过选路,将数据包发送给Real Server

(e). Real Server比对发现目标为自己的IP,开始构建响应报文发回给Director Server。 此时报文的源IP为RIP,目标IP为CIP

(f). Director Server在响应客户端前,此时会将源IP地址修改为自己的VIP地址,然后响应给客户端。 此时报文的源IP为VIP,目标IP为CIP

LVS-NAT模型的特性

  • RS应该使用私有地址,RS的网关必须指向DIP
  • DIP和RIP必须在同一个网段内
  • 请求和响应报文都需要经过Director Server,高负载场景中,Director Server易成为性能瓶颈
  • 支持端口映射
  • RS可以使用任意操作系统
  • 缺陷:对Director Server压力会比较大,请求和响应都需经过director server,试想,我们的所有数据的传输都要经过Director Server,如果产生高并发或者这中间的数据有视频等一些大的文件类型,那么势必会给Director Server非常大的压力

所以这种方法,并不适合真正的高并发和大访问量的企业,不过一般企业使用这个模式在企业内部使用以足够解决很多问题。

由此引出了我们的第二种负载模式:

2.2 LVS-DR的原理和特点:

重将请求报文的目标MAC地址设定为挑选出的RS的MAC地址

(a) 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP

(b) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链

(c) IPVS比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC地址修改为DIP的MAC地址,将目标MAC地址修改RIP的MAC地址,然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改,仅修改了源MAC地址为DIP的MAC地址,目标MAC地址为RIP的MAC地址

(d) 由于DS和RS在同一个网络中,所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址,那么此时数据包将会发至Real Server。

(e) RS发现请求报文的MAC地址是自己的MAC地址,就接收此报文。处理完成之后,将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP,目标IP为CIP

(f) 响应报文最终送达至客户端

2. LVS-DR模型的特性

  • 特点1:保证前端路由将目标地址为VIP报文统统发给Director Server,而不是RS
  • RS可以使用私有地址;也可以是公网地址,如果使用公网地址,此时可以通过互联网对RIP进行直接访问
  • RS跟Director Server必须在同一个物理网络中
  • 所有的请求报文经由Director Server,但响应报文必须不能进过Director Server
  • 不支持地址转换,也不支持端口映射
  • RS可以是大多数常见的操作系统
  • RS的网关绝不允许指向DIP(因为我们不允许他经过director)
  • RS上的lo接口配置VIP的IP地址
  • 缺陷:RS和DS必须在同一机房中(也就是必须在一个网段中)

3. 特点1的解决方案:

  • 在前端路由器做静态地址路由绑定,将对于VIP的地址仅路由到Director Server
  • 存在问题:用户未必有路由操作权限,因为有可能是运营商提供的,所以这个方法未必实用
  • arptables:在arp的层次上实现在ARP解析时做防火墙规则,过滤RS响应ARP请求。这是由iptables提供的
  • 修改RS上内核参数(arp_ignore和arp_announce)将RS上的VIP配置在lo接口的别名上,并限制其不能响应对VIP地址解析请求。

下面给出具体的配置方式:

配置拓扑:

?1,准备3台虚拟机

?2,先配置3台虚拟机的网络:

–eth0,配置在一个网段

?DIP,RIP在一个网段

?3,配置lvs的VIP

–ifconfig eth0:0 192.168.9.100/24

–echo “1” > /proc/sys/net/ipv4/ip_forward

?4,调整RS的响应。通告级别(每一台RS都配):

–echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

–echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce

–echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

–echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

?5,配置RS的VIP(每一台RS都配)

–ifconfig lo:8 192.168.9.100 netmask 255.255.255.255

?6,启动RS上的httpd

–yum install httpd -y

–/var/www/html

?vi index.html

?from ooxxip

–service httpd start

?客户端验证:RIP:80 能显示

–VIP:80不能显示

?7,LVS——ipvsadm

–yum install ipvsadm -y

–ipvsadm -A -t 192.168.9.100:80 -s rr

–ipvsadm -a -t 192.168.9.100:80 -r 192.168.9.12 -g

–ipvsadm -a -t 192.168.9.100:80 -r 192.168.9.13 -g

–ipvsadm -ln

–浏览器刷新: 访问vip

–ipvsadm –lnc

–netstat -natp

说下实现吧,当客户端向192.168.9.100发送请求时,LVS会先根据服务器使用情况,将请求分发给其后的Server(可能是node1节点也可能是node2节点),

命令ifconfig lo:8 192.168.9.100 netmask 255.255.255.255已将VIP配置为192.168.9.100

ipvsadm -a -t 192.168.9.100:80 -r 192.168.9.12 -g(将LVS与Server进行“绑定”)

如下图:我的配置为192.168.131.100,两个进行与运算结果仍然为192.168.131.100,所以

只能调用eth0,然后192.168.131.162与255.255.255.0与运算,结果为192.168.131.0,结果和从LVS返回结果一样,所以就实现了从server直接将结果返回给客户端的请求。(在刚开始工作时,这里也思考了很久,后期终于明白。。。。。。。)

下面说说异地部署(如果你的公司是一个面向全球建立数据中心的话):

2.3 LVS-Tun的原理和特点:

在原有的IP报文外再次封装多一层IP首部,内部IP首部(源地址为CIP,目标IIP为VIP),外层IP首部(源地址为DIP,目标IP为RIP)

(a) 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP 。

(b) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链

(c) IPVS比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层IP报文,封装源IP为为DIP,目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP,目标IP为RIP

(d) POSTROUTING链根据最新封装的IP报文,将数据包发至RS(因为在外层封装多了一层IP首部,所以可以理解为此时通过隧道传输)。 此时源IP为DIP,目标IP为RIP

(e) RS接收到报文后发现是自己的IP地址,就将报文接收下来,拆除掉最外层的IP后,会发现里面还有一层IP首部,而且目标是自己的lo接口VIP,那么此时RS开始处理此请求,处理完成之后,通过lo接口送给eth0网卡,然后向外传递。 此时的源IP地址为VIP,目标IP为CIP

(f) 响应报文最终送达至客户端

LVS-Tun模型特性

  • RIP、VIP、DIP全是公网地址
  • RS的网关不会也不可能指向DIP
  • 所有的请求报文经由Director Server,但响应报文必须不能进过Director Server
  • 不支持端口映射
  • RS的系统必须支持隧道

其实企业中最常用的是 DR 实现方式,而 NAT 配置上比较简单和方便,后边实践中会总结 DR 和 NAT 具体使用配置过程。

3.LVS结合keepalive

LVS可以实现负载均衡,但是不能够进行健康检查,比如一个rs出现故障,LVS 仍然会把请求转发给故障的rs服务器,这样就会导致请求的无效性。keepalive 软件可以进行健康检查,而且能同时实现 LVS 的高可用性,解决 LVS 单点故障的问题,其实 keepalive 就是为 LVS 而生的。

  • Keepalived1 + lvs1(Director1):192.168.0.48
  • Keepalived2 + lvs2(Director2):192.168.0.58
  • Real server1:192.168.0.18
  • Real server2:192.168.0.28
  • IP: 192.168.0.38

Lvs + keepalived的2个节点安装

#yum install ipvsadm keepalived -y

Real server + nginx服务的2个节点安装

# yum install epel-release -y

# yum install nginx -y

设置配置脚本

Real server节点2台配置脚本:

# vim /usr/local/sbin/lvs_dr_rs.sh

#! /bin/bash

vip=192.168.0.38

ifconfig lo:0 $vip broadcast $vip netmask 255.255.255.255 up

route add -host $vip lo:0

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce

echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore

echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce

2节点rs 上分别执行脚本:

bash /usr/local/sbin/lvs_dr_rs.sh

keepalived节点配置(2节点):

主节点( MASTER )配置文件

vim /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 51

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

192.168.0.38

}

}

virtual_server 192.168.0.38 80 {

delay_loop 6

lb_algo rr

lb_kind DR

persistence_timeout 0

protocol TCP

real_server 192.168.0.18 80 {

weight 1

TCP_CHECK {

connect_timeout 10

nb_get_retry 3

delay_before_retry 3

connect_port 80

}

}

real_server 192.168.0.28 80 {

weight 1

TCP_CHECK {

connect_timeout 10

nb_get_retry 3

delay_before_retry 3

connect_port 80

}

}

}

从节点( BACKUP )配置文件

拷贝主节点的配置文件keepalived.conf,然后修改如下内容:

state MASTER -> state BACKUP

priority 100 -> priority 90

keepalived的2个节点执行如下命令,开启转发功能:

# echo 1 > /proc/sys/net/ipv4/ip_forward

启动keepalive

<strong>先主后从分别启动keepalive</strong>

service keepalived start

验证结果

实验1

手动关闭192.168.0.18节点的nginx,service nginx stop 在客户端上去测试访问 结果正常,不会出现访问18节点,一直访问的是28节点的内容。

实验2

手动重新开启 192.168.0.18 节点的nginx, service nginx start 在客户端上去测试访问 结果正常,按照 rr 调度算法访问18节点和28节点。

实验3

测试 keepalived 的HA特性,首先在master上执行命令 ip addr ,可以看到38的vip在master节点上的;这时如果在master上执行 service keepalived stop 命令,这时vip已经不再master上,在slave节点上执行 ip addr 命令可以看到 vip 已经正确漂到slave节点,这时客户端去访问 访问依然正常,验证了 keepalived的HA特性。

上一篇: 如何去掉word 文档复制文字底纹
下一篇: 如何从0到1构建一个稳定、高性能的Redis集群?(附16张图解)

欢迎扫描关注我们的微信公众平台!

欢迎扫描关注我们的微信公众平台!