您好,欢迎来到微智科技网。
搜索
您的当前位置:首页LVS手册(正式版)

LVS手册(正式版)

来源:微智科技网


LVS手册

修改历史

时间 2006-11-29 2006-12-6 2007-1-11 说明 创建文档 修改文档 增加受攻击的应对措施 修改人 ***** ********** *********

系统有限公司 版权所有 不得复制

目 录

第一章 IPVS负载均衡技术 .................................................................................................................. 3 1.1 LVS集群的通用结构 .................................................................................................................. 3 1.2 IP负载均衡技术 ......................................................................................................................... 5 1.2.1 通过NAT实现虚拟服务器(VS/NAT) .............................................................................. 5 1.2.2 通过直接路由实现虚拟服务器(VS/DR) ......................................................................... 6 1.2.3 通过IP隧道实现虚拟服务器(VS/TUN) ......................................................................... 9 1.2.4 三种IP负载均衡技术比较 ................................................................................................ 11 第二章 IPVS+HEARTBEAT+MON建立LVS系统 ........................................................................ 13 2.1 系统搭建流程 ............................................................................................................................ 13 2.1.1 Load Balancer的搭建流程 ............................................................................................... 13 2.1.2 Real Server的搭建流程 .................................................................................................... 13 2.2 内核升级 .................................................................................................................................... 13 2.2.1 LD Server的内核编译参数 .............................................................................................. 13 2.2.2 Real Server的内核编译参数 ............................................................................................ 16 2.2.3 内核升级步骤 .................................................................................................................... 17 2.3 安装IPVSADM及配置IPVS ...................................................................................................... 17 2.3.1 安装ipvsadm(install_ipvs.sh) ............................................................................................ 17 2.3.2 配置IPVS(config_ipvs.sh) ................................................................................................. 18 2.4 安装MON及配置MON .............................................................................................................. 18 2.4.1 安装mon(install_mon.sh) .................................................................................................. 18 2.4.2 配置mon(config_mon.sh) .................................................................................................. 18 2.5 安装HEARTBEAT及配置HEARTBEAT ...................................................................................... 19 2.5.1 安装HeartBeat(install_HB.sh) .......................................................................................... 19 2.5.2 配置HeartBeat(config_HB.sh) .......................................................................................... 19 2.6 系统配置信息 ............................................................................................................................ 20 2.7 自动化安装包使用说明(LVSPAKEAGE.TAR.GZ) ................................................................. 20 2.8 REAL SERVER的配置 ................................................................................................................. 21 第三章 VS/TUN模式压力测试报告 .................................................................................................. 22 3.1 VS/TUN模式压力测试结论 .................................................................................................... 22 3.2 千M网卡,模式VS/TUN(VIP,HTTP服务) ............................................................ 22 3.2.1 压力测试条件 .................................................................................................................... 22 3.2.2 LD SERVER的情况 ........................................................................................................... 23 3.2.3 REAL SERVER 172.16.80.49的情况 ................................................................................ 23 3.2.4 REAL SERVER 172.16.81.138的情况 .............................................................................. 24 3.2.5 REAL SERVER 172.16.13.52的情况 ................................................................................ 24 3.2.6.REAL SERVER 172.16.80.50的情况 ................................................................................ 25 3.2.6.REAL SERVER 结论 ......................................................................................................... 25 3.3 百M网卡,模式VS/TUN(内网VIP,UDP服务) ........................................................... 26 3.3.1 压力测试条件 .................................................................................................................... 26 3.3.2 LD SERVER的情况 ........................................................................................................... 26 3.3.3 REAL SERVER 172.19.58.150的情况 .............................................................................. 27

3.3.4 REAL SERVER 172.19.58.151的情况 .............................................................................. 27 3.3.5 REAL SERVER 172.19.58.152的情况 .............................................................................. 28 3.3.6 REAL SERVER 172.19.58.153的情况 .............................................................................. 28 3.3.7 REAL SERVER 172.19.58.154的情况 .............................................................................. 29 3.3.8 结论 .................................................................................................................................... 29 第四章 高级话题 .................................................................................................................................. 30 4.1 充分利用服务器资源发挥LVS性能 ........................................................................................ 30 4.1.1 双CPU超线程的至强服务器 .......................................................................................... 30 4.1.2 双CPU双核心的至强服务器 .......................................................................................... 30 4.2 连接的相关性 ............................................................................................................................. 31 4.3 本地节点 ..................................................................................................................................... 33 4.4 MON监测程序 ............................................................................................................................. 33 4.5 系统可用性分析 ......................................................................................................................... 33 4.5 RS上运行SQUID ......................................................................................................................... 34 4.6 系统绑定端口分析 ..................................................................................................................... 34 4.7 LD的网络拓扑及受攻击时的应对措施 .................................................................................... 35 4.7.1 LD的网络拓扑 ..................................................................................................................... 35 4.7.2 LD受攻击时的应对措施 ..................................................................................................... 36 附录1 IPVSADM使用指南 ................................................................................................................ 38 1 名词解释 ....................................................................................................................................... 38 2 IPVSADM 的用法和格式如下 ....................................................................................................... 38 3 命令选项 ....................................................................................................................................... 38 4 Q&A .............................................................................................................................................. 41

第一章 IPVS负载均衡技术

1.1 LVS集群的通用结构

LVS集群采用IP负载均衡技术,属于IP层的交换(L4), 具有很好的吞吐率。调度器分析客户端到服务器的IP报头信息,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器,LVS集群系统的通用结构如图1.1所示,主要包含四大部分:

图1.1 LVS集群的通用结构

负载调度器(load balancer),它是整个集群对外面的前端机,负责将客户的

请求发送到一组服务器上执行,而客户认为服务是来自一个IP地址上的。当客户请求到达时,调度器只根据负载情况从服务器池中选出一个服务器,将该请求转发到选出的服务器,并记录这个调度;当这个请求的其他报文到达,也会被转发到前面选出的服务器。因为所有的操作都是在操作系统核心空间中将完成的,它的调度开销很小,所以具有很高的吞吐率。

服务器池(server pool),是一组真正执行客户请求的服务器,执行的任务有WEB、MAIL、FTP和DNS等。服务器池的结点数目是可变的,当整个系统收到的负载超过目前所有结点的处理能力时,可以在服务器池中增加服务器来满足不断增长的请求负载。对大多数网络服务来说,结点与结点间不存在很强的相关性,所以整个系统的性能可以随着服务器池的结点数目增加而线性增长。 后端存储(backend storage),它为服务器池提供一个共享的存储区,这样很容易使得服务器池拥有相同的内容,提供相同的服务。

Graphic Monitor是为系统管理员提供整个集群系统的监视器,它可以监视系统中每个结点的状况。

1.2 IP负载均衡技术

在已有的IP负载均衡技术中有三种,一是通过网络地址转换实现虚拟服务器的VS/NAT技术(Virtual Server via Network Address Translation),二是通过直接路由的VS/DR技术(Virtual Server via Direct Routing),三是通过IP隧道实现虚拟服务器的VS/TUN技术(Virtual Server via IP Tunneling)。

1.2.1 通过NAT实现虚拟服务器(VS/NAT)

VS/NAT的体系结构如图1.2所示,在一组服务器前有一个调度器,它们是通过Switch/HUB相连接的。这些服务器提供相同的网络服务、相同的内容,即不管请求被发送到哪一台服务器,执行结果是一样的。

图1.2 VS/NAT的体系结构

以如下的VS/NAT配置为例,来了解报文的流程:

Protocol TCP TCP Virtual IP Address 58.251.62.141 58.251.62.141 Port 80 21 Real IP Address 172.16.81.143 172.16.81.144 172.16.81.145 Port 80 80 21 Weight 1 2 1 数据流程的时序图为:

Client IP:210.22.23.LD eth0IP:58.251.62.141LD eth1IP:172.16.81.141RS eth1IP:172.16.81.144用户向58.251.62.141发起http请求LD收到用户请求并修改请求报文目标地址LD内网将该IP报文发给RSLD修改响应报文的目标地址响应报文返回用户LD内网收到该IP报文,处理后将响应报文送出 图2.3 VS/NAT数据流程时序图

1. 客户端浏览器输入58.251.62.141向58.251.62.141发出http请求. 2. Load Balancer的(eth0)收到该次请求.

SOURCE 210.22.23.:4143 DEST 58.251.62.141:http 3. IPVS调度器根据各个Real Server的负载情况,动态地选择一台Real

Server(例如172.16.81.144),将请求报文的目标地址改写发送给172.16.81.144

SOURCE 210.22.23.:4143 DEST 172.16.81.144:http 4.Real Server收到请求报文并处理形成响应报文,由于Real Server上的网

关地址为Load Balancer,响应报文从Real Server发往Load Balancer。

SOURCE 58.251.62.141:http DEST 210.22.23.:4143 5.Load Balancer收到172.16.81.144的响应报文后,将响应报文的原地

址修改为虚拟IP地址,并发送给客户端。

SOURCE 172.16.81.144:http DEST 210.22.23.:4143 6. 客户认为得到正常的服务,而不知道是哪一台服务器处理的.

1.2.2 通过直接路由实现虚拟服务器(VS/DR)

在VS/NAT的集群系统中,请求和响应的数据报文都需要通过负载调度器,当真实服务器的数目在10台和20台之间时,负载调度器将成为整个集群系统的新瓶颈。大多数Internet服务都有这样的特点:请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理,即在负载调度器中只负责调度请求而响应直接返回给客户,将极大地提高整个集群系统的吞吐量。VS/DR的体系结构如图1.4所示:调度器和服务器组都必须在物理上有一个网卡通过不分断的局域网相连,如通过交换机或者高速的HUB相连。VIP地址为调度器和

服务器组共享,调度器配置的VIP地址是对外可见的,用于接收虚拟服务的请求报文;所有的服务器把VIP地址配置在各自的Non-ARP网络设备上,它对外面是不可见的,只是用于处理目标地址为VIP的网络请求。

图1.4 VS/DR的体系结构

以如下的VS/NAT配置为例,来了解报文的流程: Protocol Virtual IP Address Port 58.251.62.141 172.16.81.49 Real IP Address Port Weight 1 2 1 58.251.62.138(172.16.81.138) 80 58.251. 63.49(172.16.80.49) 80 58.251. 13.52(172.16.13.52) TCP 数据流程的时序图为:

Client IP:210.22.23.LD eth0IP:58.251.62.141LD eth1IP:172.16.81.141RS eth1IP:172.16.80.49RS eth0IP:58.251.63.49用户向58.251.62.141发起http请求LD收到用户请求并修改请求报文目标地址LD内网将该IP报文转发发给RSLD内网收到该IP报文进行处理形成响应报文RS处理完用户请求后根据路由表将响应报文直接返回给客户图1.5 VS/DR数据流程时序图

1. 客户端浏览器输入58.251.62.141向58.251.62.141发出http请求. 2. Load Balancer的(eth0)收到该次请求.

SOURCE 210.22.23..4157 DEST 172.16.80.49:http 3. IPVS调度器根据各个Real Server的负载情况,动态地选择一台Real

Server,将请求报文转发给Real Server(例如172.16.80.49)

SOURCE 210.22.23..4157 DEST 172.16.80.49:http 4. Real Server的内网(eth1)收到Load Balancer发过来的IP报文并对IP报文解包,得到客户的请求包,发现包的目标地址被配置在本地的lo设备上,所以就处理这个请求。

5. Real Server根据路由表将响应报文通过(eth0)直接返回给客户, 请求报文的目标地址为VIP,响应报文的源地址也为VIP,所以响应报文不需要作任何修改,可以直接返回给客户.

SOURCE 58.251.62.141:http DEST 210.22.23..4157 6.客户认为得到正常的服务,而不知道是哪一台服务器处理的。

在VS/DR响应报文根据服务器的路由表直接返回给客户,而不经过负载调度器,所以负载调度器只处于从客户到服务器的半连接中,我们给出半连接的TCP有限状态机。如图1.6为VS/DR的TCP状态迁移,圈表示状态,箭头表示状态间的转换,箭头上的标识表示在当前状态上收到该标识的输入,迁移到下一个状态。VS/DR的TCP状态迁移是按照半连接的TCP有限状态机进行的。

图1.6 VS/DR的TCP状态迁移

1.2.3 通过IP隧道实现虚拟服务器(VS/TUN)

跟VS/DR方法相同,VS/TUN多数Internet服务的非对称特点,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提高整个集群系统的吞吐量。IP隧道(IP tunneling)是将一个IP报文封装在另一个IP报文的技术,这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。

我们利用IP隧道技术将请求报文封装转发给后端服务器,响应报文能从后端服务器直接返回给客户。但在这里,后端服务器有一组而非一个,所以我们不可能静态地建立一一对应的隧道,而是动态地选择一台服务器,将请求报文封装和转发给选出的服务器。这样,我们可以利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。VS/TUN的体系结构如图3.3所示,各个服务器将VIP地址配置在自己的IP隧道设备上。VS/TUN的体系结构如图1.7所示

图1.7 VS/TUN的体系结构

以如下的VS/NAT配置为例,来了解报文的流程:

Protocol Virtual IP Address Port 58.251.62.141 172.16.81.49 Real IP Address Port Weight 1 2 1 58.251.62.138(172.16.81.138) 80 58.251. 63.49(172.16.80.49) 80 58.251. 13.52(172.16.13.52) TCP 数据流程的时序图为:

Client IP:210.22.23.LD eth0IP:58.251.62.141LD eth1IP:172.16.81.141RS eth1IP:172.16.80.49RS eth0IP:58.251.63.49用户向58.251.62.141发起http请求LD收到请求报文并将报文封装在另一个IP报文中LD内网收到该IP报文RS解IP报文得到用户请求包,发现用户请求地址被配置在本地的IP隧道设备上,所以处理用户请求.LD内网将该IP报文发给RSIP TunnelRS处理完用户请求后根据路由表将响应报文直接返回给客户

1. 客户端浏览器输入58.251.62.141向58.251.62.141发出http请求.

2. Load Balancer的(eth0)收到该次请求.

SOURCE 210.22.23..4157 DEST 58.251.62.141:http 3. IPVS调度器根据各个Real Server的负载情况,动态地选择一台Real

Server,将请求报文封装在另一个IP报文中.

4. Load Balancer的内网(eth1)将封装后的IP报文发给选出的Real Server

SOURCE 172.16.81.141 DEST DEST 172.16.80.49 SOURCE 210.22.23..4157 58.251.62.141:http (ipip-proto-4) 5. Real Server的内网(eth1)收到Load Balancer发过来的IP报文并对IP报文解包,得到客户的请求包,发现包的目标地址被配置在本地的IP隧道设备上,所以就处理这个请求。

6. Real Server根据路由表将响应报文通过(eth0)直接返回给客户, 请求报文的目标地址为VIP,响应报文的源地址也为VIP,所以响应报文不需要作任何修改,可以直接返回给客户.

SOURCE 58.251.62.141:http DEST 210.22.23..4157 7. 客户认为得到正常的服务,而不知道是哪一台服务器处理的。 VS/DR负载调度器也只处于从客户到服务器的半连接中,按照半连接的TCP有限状态机进行状态迁移。

1.2.4 三种IP负载均衡技术比较

三种IP负载均衡技术的优缺点归纳在下表中:

Server server network server number server gateway

VS/NAT any private low (10~20) load balancer VS/DR Non-arp device LAN High (100) Own router VS/TUN Tunneling LAN/WAN High (100) own router VS/NAT 的优点是服务器可以运行任何支持TCP/IP的操作系统,它只需要

一个IP地址配置在调度器上,服务器组可以用私有的IP地址。缺点是它的伸缩能力有限,当服务器结点数目升到20时,调度器本身有可能成为系统的新瓶颈,因为在VS/NAT中请求和响应报文都需要通过负载调度器。

VS/DR优点是负载调度器可以处理大量的请求,因为调度器只处理客户到服

务器端的连接,响应数据可以直接从的网络路由返回给客户,这可以极大地提高LVS集群系统的伸缩性。缺点是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上,服务器网络设备(或者设备别名)不作ARP响应,或者能将报文重定向(Redirect)到本地的Socket端口上。

VS/TUN的优点是负载调度器可以处理大量的请求,它甚至可以调度百台以

上的服务器(同等规模的服务器),而它不会成为系统的瓶颈,因为负载调度器只将请求调度到不同的后端服务器,后端服务器将应答的数据直接返回给用户。缺点是VS/TUN技术有IP隧道的开销并且对服务器有要求,即所有的服务器必须支持―IP Tunneling‖或者―IP Encapsulation‖协议。

第二章 IPVS+HeartBeat+Mon建立LVS系统

2.1 系统搭建流程

由IPVS负载均衡技术可知,VS/TUN体系结构分为Load Balancer和Real Server两大部分:

2.1.1 Load Balancer的搭建流程

1 内核升级以支持IPVS和IP Tunneling

2 安装IPVS的管理工具ipvsadm并进行IPVS配置 3 安装Real Server的监控软件mon并进行mon设置 4 安装实现HA系统的软件HeartBeat并进行HeartBeat设置 5 系统启动脚本的配置.

6 假如您对安全步骤及安装过程不感兴趣,请直接跳到2.7节,按照说明文字,下载LVSPackage.tar.gz可以直接安装.

2.1.2 Real Server的搭建流程

1 内核升级以支持IP Tunneling 2 系统配置

a 对于使用了状态机及对应的iptables规则的主机,需要更新iptables的

规则,取消其中所有依赖于状态机的配置,这有可能意味着现有的iptables规则的重写。

b 对于未使用状态机机器对应的iptables规则的主机,则无需做iptables

规则的修改。

c 当整体切换完成后,需要关闭Real Server上对外服务的端口,以确保安全。

2.2 内核升级

Ipvs内核由其用途来说,主要分为2种: LD的和RS的。下面以内核版本

2.6.16.21为例,分别说明2种内核的内核配置参数。

2.2.1 LD Server的内核编译参数

LD Server所需内核中需要进行的改动较多,主要为network option; lvs;及

iptables,状态机。

a networking options:

进入 network packet filtering

配置Core

配置IP:

b

配置LVS

2.2.2 Real Server的内核编译参数

RS的内核只需在现有内核的基础上开启net options中的ip tunnlig 选项即可,如下图:

同时需要关闭状态机,公司内核中默认没有状态机的,因此,也可以不进行该配制。

2.2.3 内核升级步骤

a b c d

根据LD/RS,将对应的内核放置在系统的/boot目录下。 修改/etc/lilo.conf文件 执行lilo命令,进行变更 reboot

需要注意的是,如果是跨内核版本升级,如2.4升到2.6,需要考虑主机

的网线顺序的更换问题。

2.3 安装ipvsadm及配置IPVS

2.3.1 安装ipvsadm(install_ipvs.sh)

a http://www.linuxvirtualserver.org/software/ipvs.html下载对应内核版本的ipvsadm b 进入ipvsadm目录,并make 以及make install c 输入命令ipvsadm,若有如下提示则安装正确。

IP Virtual Server version 1.2.1 (size=65536) Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

2.3.2 配置IPVS(config_ipvs.sh)

a 配置系统参数(eth0为绑定VIP的网卡设备)

echo \"0\" >/proc/sys/net/ipv4/ip_forward

echo \"1\" >/proc/sys/net/ipv4/conf/all/send_redirects echo \"1\" >/proc/sys/net/ipv4/conf/default/send_redirects echo \"1\" >/proc/sys/net/ipv4/conf/eth0/send_redirects

b 配置IPVS的服务类型、VIP地址以及对应的RS信息,例如:

/sbin/ipvsadm -A –t 172.16.81.141:80 -s wlc

/sbin/ipvsadm -a -t 172.16.81.141:80 -r 172.19.81.139 -i -w 1 /sbin/ipvsadm -a -t 172.16.81.141:80 -r 172.19.80.50 -i -w 1

…(ipvsadm的使用请参见附录1)

2.4 安装mon及配置mon

2.4.1 安装mon(install_mon.sh)

a 软件的准备

1 mon-0.99.1.tar.gz 2 Mon-0.11.tar.gz

3 Time-HiRes-01.20.tar.gz 4 Period-1.20.tar.gz 5 Convert-BER-1.31.tar.gz

b 安装perl模块,就是2.3.4.5,三个perl模块和一个Mon编译进系统

cd <模块> perl MakeFile.pl make make install

c 直接tar xvzf mon-0.99.1.tar.gz ,mon就安装完毕。

2.4.2 配置mon(config_mon.sh)

a 将lvs的alert脚本lvs.alert复制到 mon-0.99.1/alert.d,(lvs.alert请见LVSPackage.tar.gz) b 将mon的配置文件mon.cf复制到mon-0.99.1(mon.cf请见LVSPackage.tar.gz)

2.5 安装HeartBeat及配置HeartBeat

2.5.1 安装HeartBeat(install_HB.sh)

a 软件准备

1 libnet-1.1.2.1.tar.gz

2 heartbeat-2.0.7.tar.gz

b 安装libnet

tar -xzvf libnet-1.1.2.1.tar.gz cd /root/libnet ./configure make

make install

c 安装HeartBeat

tar -xzvf heartbeat-2.0.7.tar.gz rm heartbeat-2.0.7.tar.gz cd heartbeat-2.0.7 groupadd -g 65 haclient useradd -g 65 -u 17 hacluster ./ConfigureMe configure make

make install

2.5.2 配置HeartBeat(config_HB.sh)

a 复制配置文件(下述配置文件请见LVSPackage.tar.gz)

cp doc/ha.cf doc/haresources doc/authkeys /etc/ha.d/ cp doc/ha.cf /etc/ha.d/ha.cf

cp doc/haresources /etc/ha.d/haresources cp doc/TencentLvs /etc/ha.d/resource.d/ chmod 600 authkeys

b 修改配置文件

在/etc/ha.d/ha.cf中加入Active和Standby LD的节点信息以及heartbeat心跳线的制

作,例如

echo \"node $A_hostname\" >> /etc/ha.d/ha.cf echo \"node $S_hostname\" >> /etc/ha.d/ha.cf echo ―ucast eth1 $S_hostip‖ >> /etc/ha.d/ha.cf 在/etc/ha.d/haresources中加入需要拉动的资源信息,例如 echo \"S_hostname IPaddr::172.16.81.141/24/eth1 TencentLvs\" >> etc/ha.d/haresources

2.6 系统配置信息

将如下三句加入到/etc/rc.d/rc.local中

/usr/lib/heartbeat/heartbeat Sleep(40)

/usr/lib/heartbeat/hb_takeover

2.7 自动化安装包使用说明(LVSPakeage.tar.gz)

1. cp vmlinuz-2.6.16.21-p4-LVS-LD /boot/vmlinuz-2.6.16.21

vi /etc/lilo.conf,增加如下语句

image = /boot/vmlinuz-2.6.16.21 root = /dev/sda1

label = Linux2616 read-only

将default修改为default = Linux2616

reboot

2. ./install_ipvs.sh 3. ./install_mon.sh 4. ./install_HB.sh

5. 修改/usr/local/lvs/lvs.conf配置文件 6. ./config_ipvs.sh,利用ipvsadm查看结果 7. ./config_mon.sh

8. ./configHB.sh uname ucastip phost phostip (ucastip 为本机心跳IP,phostip为对方的

心跳IP)

9. ./startHB.sh ucastip (ucastip为自己的心跳IP)

10. 相应的iptables设置

2.8 Real Server的配置

a 配置系统参数

echo \"0\" >/proc/sys/net/ipv4/ip_forward

b 配置tunl0

/sbin/ifconfig tunl0 ${VIP} broadcast ${VIP} netmask 0xffffffff up /sbin/route add -host ${VIP} dev tunl0

c 解决arp问题

echo 1 > /proc/sys/net/ipv4/conf/tunl0/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/tunl0/arp_announce echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

d 解决源地址验证问题

echo 0 > /proc/sys/net/ipv4/conf/tunl0/rp_filter echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

第三章 VS/TUN模式压力测试报告

3.1 VS/TUN模式压力测试结论

1 对Load Banlancer来说,在VS/TUN模式,千兆网卡的条件下,请求包的长度<1K的条件下,有如下结论:

a LD SERVER可以支持到每秒200K个包

b 在同等的情况下VS/DR模式比VS/TUN模式每秒处理的包量要多30% c 千兆网带宽不是瓶径

d 由于对网卡的处理需要一个单独的CPU进行处理,系统的瓶径是处理网卡所消耗的CPU资源。

e 对Load Banlancer,由于IP封装,出流量稍微大于入流量

2 当Banlancer使用百兆网卡时,网络资源也会是Banlancer的瓶径。 3 在请求包比较大的时,比如大量上传请求的情况下,带宽也将成为瓶径。 4 对REAL SERVER来说,压力的情况等同于普通的SERVER的情况。

3.2 千M网卡,模式VS/TUN(VIP,HTTP服务)

图3.1 千M网卡的压力测试结构

3.2.1 压力测试条件

请求包长度:360 byte 响应包长度:1K byte

压力测试机器配置:PE1850,4G,1*146G-4G,1*146G

LDServer配置:PESC1425,8G,1*80G SATA-8G,1*80G RS配置:PESC1425,8G,1*80G SATA-8G,1*80G

3.2.2 LD SERVER的情况

图3.2 LD SERVER流量情况 图3.3 LD SERVER包量情况

图5.4 LD SERVER每个CPU的情况。

结论:

从CPU的情况可以看出,CPU1和CPU3有工作在上面,如图5.4所示,CPU使用基本上已经到90%以上,系统基本上已经达到极限,此时: 1.流量达到270M以上 2.包量达到200K以上

3.网卡对应的CPU使用率90%以上

3.2.3 REAL SERVER 172.16.80.49的情况

图3.5 172.16.80.49流量曲线 图3.6 172.16.80.49包量曲线

图3.7 172.16.80.49 CPU使用情况

3.2.4 REAL SERVER 172.16.81.138的情况

图3.8 172.16.81.138流量曲线 图3.9 172.16.81.138包量曲线

图3.10 172.16.81.138 CPU使用情况

3.2.5 REAL SERVER 172.16.13.52的情况

图3.11 172.16.13.52流量曲线 图3.12 172.16.13.52包量曲线

图3.13 172.16.13.52 CPU使用情况

3.2.6.REAL SERVER 172.16.80.50的情况

图3.14 172.16.80.50流量曲线 图3.15 172.16.80.50包量曲线

图3.16 172.16.80.50 CPU使用情况

3.2.6.REAL SERVER 结论

从Real Server的CPU使用情况可以看出, CPU使用基本上已经到90%以上,

系统基本上已经达到极限,此时: 4.流量在140M左右

5.包量50K以上,四个RS的出包量之和等于LD的出包量 6.网卡对应的CPU使用率90%以上

3.3 百M网卡,模式VS/TUN(内网VIP,UDP服务)

图3.17 UDP压力测试结构

3.3.1 压力测试条件

请求包长度:12 byte 响应包长度:12 byte

压力测试机器配置:PE1850,4G,1*146G-4G,1*146G LDServer配置:PE1850,4G,1*146G-4G,1*146G RS配置:PE1850,4G,1*146G-4G,1*146G

3.3.2 LD SERVER的情况

图3.18 LD SERVER流量情况 图3.19 LD SERVER包量情况

图3.20 LD SERVERCPU情况

图3.21 LD SERVER 各个CPU情况

3.3.3 REAL SERVER 172.19.58.150的情况

图3.22 172.19.58.150的流量图 图3.23 172.19.58.150的包量图

图3.24 172.19.58.150的CPU使用情况图

3.3.4 REAL SERVER 172.19.58.151的情况

图3.25 172.19.58.151的流量图

图3.26 172.19.58.151的包量图

图3.27 172.19.58.151的CPU使用情况图

3.3.5 REAL SERVER 172.19.58.152的情况

图3.28 172.19.58.152的流量图

图3.29 172.19.58.152的包量图

图3.30 172.19.58.152的CPU使用情况图

3.3.6 REAL SERVER 172.19.58.153的情况

图3.31 172.19.58.153的流量图 图3.32 172.19.58.153的包量图

图3.33 172.19.58.153的CPU使用情况图

3.3.7 REAL SERVER 172.19.58.154的情况

图3.34 REALSERVER的流量图

图3.35 REALSERVER的包量图

图3.36 REALSERVER的CPU使用情况图

3.3.8 结论

在百M网卡,模式VS/TUN(内网,UDP)下,可以再次印证到,CPU是

LD SERVER的瓶径,172.19.58.145作为LD SERVER所能支持的最大包量是97K,TCP方式和UDP方式的最大包量差不多是相等的。

第四章 高级话题

4.1 充分利用服务器资源发挥LVS性能

由测试报告可以看出,Load Balancer的CPU资源的占用为整个LVS系统的

瓶颈所在,因此,如何充分使用服务器的CPU资源使得LVS性能得到最大化,就是一个重要的问题,现就双CPU超线程的至强服务器和双CPU双核心的至强服务器做一个讨论。

4.1.1 双CPU超线程的至强服务器

在linux下,对于双CPU超线程的服务器来说,只要内核中开启了CPU的HT(超线程)功能,则可通过cat /proc/cpuinfo 识别到4块CPU,分别为 CPU0;CPU1;CPU2;CPU3。其中,CPU0和CPU1为同一个真实CPU的本身和它的超线程出的CPU。CPU2和CPU3同理。

在linux下。我们可以手动的静态配置网卡的irq路由,来达到使专门的一块CPU完全处理某对应网卡中断的目的。这样可以使得eth0网卡和eth1网卡的计算量完全分配到2块真实CPU上,充分发挥出双CPU的性能。

具体处理方法如下:

1, cat /proc/cpuinfo | grep processor | wc –l

查看CPU处理器个数

2, ETH0_NU=`cat /proc/interrupts | grep eth0 | awk -F ':' '{ print $1 }'`

查看处理eth0网卡的irq中断号。

3, echo 8 > /proc/irq/$ETH0_NU/smp_affinity

指定CPU3来处理eth0网卡的中断请求。

4, ETH1_NU=`cat /proc/interrupts | grep eth1 | awk -F ':' '{ print $1 }'`

查看处理eth1网卡的irq中断号。

5, echo 2 > /proc/irq/$ETH1_NU/smp_affinity

指定CPU1来处理eth1网卡的中断请求。

4.1.2 双CPU双核心的至强服务器

在linux下,对于双CPU双核心的服务器来说,若内核中没有开启HT选项,则默认可以识别到4块CPU。分别为CPU0;CPU1;CPU2;CPU3。其中CPU0

和CPU1为同一CPU的2个核。

基于双核至强CPU的架构,对于同一物理CPU的2个核心是共享4M二级Cache的,因此,将一块网卡的中断对应到同一个物理CPU的2个核心上,可以在保证二级Cache命中率的前提下,充分发挥双核心CPU的性能,进一步提高LD Server的处理能力。

具体处理方法如下:

1. cat /proc/cpuinfo | grep processor | wc –l

查看CPU处理器个数

2. ETH0_NU=`cat /proc/interrupts | grep eth0 | awk -F ':' '{ print $1 }'`

查看处理eth0网卡的irq中断号。

3. echo c > /proc/irq/$ETH0_NU/smp_affinity

指定CPU2和CPU3来处理eth0网卡的中断请求。

4. ETH1_NU=`cat /proc/interrupts | grep eth1 | awk -F ':' '{ print $1 }'`

查看处理eth1网卡的irq中断号。

5. echo 3 > /proc/irq/$ETH1_NU/smp_affinity

指定CPU0和CPU1来处理eth1网卡的中断请求。

4.2 连接的相关性

在之前的LVS配置和使用中,均假设每个连接都相互的,所以每个连接被分配到一个服务器,跟过去和现在的分配没有任何关系。但是,有时由于功能或者性能方面的原因,一些来自同一用户的不同连接必须被分配到同一台服务器上。

FTP是一个因为功能设计导致连接相关性的例子,在FTP使用中,客户需要建立一个控制连接与服务器交互命令,建立其他数据连接来传输大量的数据。在主动的FTP模式下,客户通知FTP服务器它所监听的端口,服务器主动地建立到客户的数据连接,服务器的端口一般为20。IPVS调度器可以检查报文的内容,可以获得客户通知FTP服务器它所监听的端口,然后在调度器的连接Hash表中建立一个相应的连接,这样服务器主动建立的连接可以经过调度器。但是,在被动的FTP模式下,服务器告诉客户它所监听的数据端口,服务器被动地等待客户的连接。在VS/TUN或VS/DR下,IPVS调度器是在从客户到服务器的

半连接上,服务器将响应报文直接发给客户,IPVS调度器不可能获得服务器告诉客户它所监听的数据端口。

SSL(Secure Socket Layer)是一个因为性能方面原因导致连接相关性的例子。当一个SSL连接请求建立时,一个SSL的键值(SSL Key)必须要在服务器和客户进行选择和交换,然后数据的传送都要经过这个键值进行加密,来保证数据的安全性。因为客户和服务器协商和生成SSL Key是非常耗时的,所以SSL协议在SSL Key的生命周期内,以后的连接可以用这个SSL Key和服务器交换数据。如果IPVS调度器将以后的连接调度到其他服务器,这会导致连接的失败。

在IPVS中解决连接相关性的方法是持久服务(Persistent Service)的处理。在IPVS中使用两个模板来表示客户和服务器之间的持久服务,模板〈protocol, client_ip, 0, virtual_ip, virtual_port, dest_ip, dest_port〉表示来自同一客户client_ip到虚拟服务〈virtual_ip, virtual_port〉的任何连接都会被转发到目标服务器〈dest_ip, dest_port〉,模板〈protocol, client_ip, 0, virtual_ip, 0 dest_ip, 0〉表示来自同一客户client_ip到虚拟服务器virtual_ip的任何连接都会被转发到目标服务器dest_ip,前者用于单一的持久服务,后者用于所有端口的持久服务。

当一个客户访问一个持久服务时,IPVS调度器会在连接Hash表中建立一个模板,所以在采用持久服务时,调度器需要记录每个连接的状态,会占用一定的内存空间(每个连接占用128byte)。这个模板会在一个可设置的时间内过期,如果模板有所控制的连接没有过期,则这个模板不会过期。在这个模板没有过期前,所有来自这个客户到相应服务的任何连接会被发送到同一台服务器。在ipvsadm设置时可以指定-p选项加上超时时间代表调度器实现持久服务(超时时间单位为s),例如ipvsadm -A -t 211.1.1.1:80 -p 30。

持久服务还可设置持久的粒度,即可设置将来自一个C类地址范围的所有客户请求发送到同一台服务器。这个特征可以保证当使用多个代理服务器的客户访问集群时,所有的连接会被发送到同一服务器。

虽然持久服务可能会导致服务器间轻微的负载不平衡,因为持久服务的一般调度粒度是基于每个客户机的,但是这有效地解决连接相关性问题,如FTP、

SSL和HTTP Cookie等。

4.3 本地节点

本地结点(Local Node)功能是让调度器本身也能处理请求,在调度时就相当一个本地结点一样,在实现时就是根据配置将部分连接转交给在用户空间的服务进程,由服务进程处理完请求将结果返回给客户。该功能的用处如下:

当集群中服务器结点较少时,如只有三、四个结点,调度器在调度它们时,大部分的CPU资源是闲置着,可以利用本地结点功能让调度器也能处理一部分请求,来提高系统资源的利用率。

在分布式服务器中,我们可以利用IPVS调度的本地结点功能,在每台服务器上加载IPVS调度模块,在一般情况下,利用本地结点功能服务器处理到达的请求,当管理程序发现服务器超载时,管理程序将其他服务器加入调度序列中,将部分请求调度到其他负载较轻的服务器上执行。

在地理上分布的服务器镜像上,镜像服务器利用本地结点功能处理请求,当服务器超载时,服务器通过VS/TUN将请求调度到邻近且负载较轻的服务器上。

4.4 Mon监测程序

在mon的mon.d目录下有大量的服务检测脚本,但由于RS上搭建的服务种类繁多,mon.d中的脚本不一定能完全满足要求,所以必须编写监测RS上服务的脚本和程序。实现针对具体业务的检测脚本非常简单,只需做到如下两点:

1.可以用任何语言编写检测脚本或程序,用监测RS上业务时exit 0代表

RS上的业务服务正常,exit 1代表RS上的业务服务不正常。

2.将检测脚本或程序复制到mon.d目录下即可,在mon.cf中就可以指定 Mon总是在运行检测脚本完毕后才会运行下一检测脚本,例如mon.cf中设

定时间间隔为10s,但是检测脚本运行时间超过10秒,那么mon不会运行新的检测脚本,所以检测脚本的运行时间需要比mon设定的检测间隔时间短。

4.5 系统可用性分析

在LVS/TUN模式下,客户端首先向Load Balancer发出请求,之后Load Balancer将请求报文转给Real Server,最后Real Server将响应报文回复给客户端。在这个过程中,为保证系统的可用性,必须做到:

1,当Load Balancer不能正常工作时(譬如遭受恶意或非恶意的故障),必须立刻由另外一台服务器接管Load Balancer的VIP,并且能提供和Load Balancer相同的服务。

2,当某一台Real Server不能正常提供服务时,Load Balancer必须立刻收到该消息,在Real Server不能正常提供服务的时段内不转发任何客户端的请求,当Real Server能恢复正常时,Load Balancer也必须能收到该消息,将客户端请求负载均衡到该机器上。

在IPVS+HeartBeat+Mon系统中,很好的完成了如上两点,利用HeartBeat的心跳机制进行主备Load Balancer之间的切换,利用Mon对Real Server进行实时的监测。在my.qq.com中进行如下测试很好的论证了这两点:

1,Load Balancer重启,此时服务遭受中断,但在三秒后服务恢复正常,备用Load Balancer将主Load Balancer完全接管,此后备用Load Balancer的流量和主Load Balancer的流量提供服务时的流量相同。

2,三台Real Server中某台的http服务关闭,八秒后Load Balancer探测到该Real Server不能正常提供服务(探测间隔可设置,最小为一秒),实时刷新ipvs规则,以后的请求将不再导向到该Real Server。

3,启动第2步中那台Real Server的http服务,八秒后Load Balancer探测到该Real Server能正常提供服务,实时刷新ipvs规则,以后的请求将继续负载均衡到该Real Server。

4.5 RS上运行Squid

对于很多cache类的业务采用squid能够大大提供系统性能

4.6 系统绑定端口分析

按照第二章的步骤建立LVS系统后,利用netstat会发现在0.0.0.0上绑定了

四个端口:

Tcp Udp Udp Udp

0.0.0.0:2583 0.0.0.0:32774 0.0.0.0:2583 0.0.0.0:694

0.0.0.0:* LISTEN 0.0.0.0:* 0.0.0.0:* 0.0.0.0:*

23614/perl

11363/heartbeat: wr 23614/perl

11363/heartbeat: wr

由上可以得知,由perl绑定了一个TCP端口处于listen状态,还绑定了一个

udp端口,heartbeat绑定了两个UDP端口。Perl绑定的两个端口可以通过修

改配置文件来解决,在mon.cf中加入如下两句即可(可通过config_mon.sh自动加入,更新后的config_mon.sh已经解决该问题,ipL为内网IP):

echo \"serverbind = $ipL\" > mon.cf echo \"trapbind = $ipL\" >> mon.cf

heartbeat配置文件中并没有选项来配置需要绑定的IP,故需要修改源码解决。

但是修改源码有一定风险,所以推荐尽量用iptables对端口进行控制。附件中heartbeat-2.7.0-bindeth1.tar.gz为只绑定内网IP的源码,安装和第二章所述安装一致,只是在配置需要注意,在文件ha.cf中的ucast选项必须为ucast eth1 phostip,其中phostip一定是另外一台LD的内网IP。

4.7 LD的网络拓扑及受攻击时的应对措施

4.7.1 LD的网络拓扑

作为对外服务的LVS的前端LD服务器,原则上需要部署在专区中,并配置上相应的网络、机架资源环境作为保障。目前对于主—备的LD部署方案来讲,比较推荐采用下面的网络拓扑方案:

同组的主LD Server和备份LD Server分别接入不同的接入层交换机,并上连到不同的核心交换机中,一旦出现内网接入层或单核心故障,可以快速进行切换。

示意图如下:

公网流量LG-E12-C6506-WC LG-E13-C6506-WC内接入层交换机均为双机热备接入ISD-LVS-W-1LD1-ALD2-SLD1-SLD2-AISD-LVS-W-2LD1-A和LD1-S是一组A表示激活,S表示备用。ISD-LVS-L-1ISD-LVS-L-2 LG-E11-C6509-LC10G LG-E10-C6509-LC10G枢 纽

4.7.2 LD受攻击时的应对措施

由于LD承担着后面所有接入层服务器流量的接入任务,且自身不具有AntiDDOS功能,一旦受到恶意的攻击,其带来的影响将会是非常严重的。因此,我们必须考虑这样的情况并预先做好应对的防范措施。 现就具体的情况进行一个分析:

(1) 单个或多个LD的VIP受到攻击

对于整个LD专区来说,在其接入端,会需要部署一台AntiDDOS的黑洞设备,并预先设置好对应的路由及应急切换策略,一旦出现针对某VIP的攻击时,则将该VIP的所有入流量切换到黑洞设备上,过滤后再转回LD的VIP。最大程度上避免LD受到影响。

(2) LD专区所在IDC的核心受到攻击或LD专区所在IDC掉电 由于LD专区是建立在某一物理的IDC中的,一旦出现该物理IDC核心受攻击或该物理IDC掉电的情况,则所有LD对应的服务都无可避免的将受到影响。 此时,我们只能通过采取DNS回退的办法来应急处理。该办法需要满足以下2个条件:

A、 预先对所有切换到LVS上的DNS进行TTL=1800或更低的设置。 B、 有维护一个LD--DNS—IP对应关系表,一旦出现攻击,可以通过该表作为进行DNS回退的依据。

如果以上两条件满足,则受攻击时,服务恢复的时间大概可估算为: 服务受影响时间 = DNS变更的实施时间 + DNS变更的完全生效时间

如果操作得当,服务理论上可以在1小时左右完全恢复正常。

附录1 IPVSADM使用指南

1 名词解释

virtual-service-address(VIP):虚拟服务器的ip 地址 real-service-address(RIP):是指真实服务器的ip 地址 scheduler:调度方法

2 ipvsadm 的用法和格式如下

ipvsadm -A|E -t|u|f virutal-service-address:port [-s scheduler] [-p[timeout]] [-M netmask] ipvsadm -D -t|u|f virtual-service-address ipvsadm -C ipvsadm -R ipvsadm -S [-n]

ipvsadm -a|e -t|u|f service-address:port -r real-server-address:port [-g|i|m] [-w weight]

ipvsadm -d -t|u|f service-address -r server-address ipvsadm -L|l [options]

ipvsadm -Z [-t|u|f service-address] ipvsadm --set tcp tcpfin udp

ipvsadm --start-daemon state [--mcast-interface interface] ipvsadm --stop-daemon ipvsadm -h

3 命令选项

-A --add-service

在内核的虚拟服务器表中添加一条新的虚拟服务器记录。也就是增加一台新的虚拟服务器。

-E --edit-service

编辑内核虚拟服务器表中的一条虚拟服务器记录。 -D --delete-service

删除内核虚拟服务器表中的一条虚拟服务器记录。

-C --clear

清除内核虚拟服务器表中的所有记录。 -R --restore 恢复虚拟服务器规则 -S --save

保存虚拟服务器规则,输出为-R 选项可读的格式 -a --add-server

在内核虚拟服务器表的一条记录里添加一条新的真实服务器记录。也就是在一个虚拟服务器中增加一台新的真实服务器

-e --edit-server

编辑一条虚拟服务器记录中的某条真实服务器记录 -d --delete-server

删除一条虚拟服务器记录中的某条真实服务器记录 -L|-l --list

显示内核虚拟服务器表,输出对应文件/proc/net/ip_vs -Z --zero

虚拟服务表计数器清零(清空当前的连接数量等) --set tcp tcpfin udp 设置连接超时值 --start-daemon

启动同步守护进程。他后面可以是master 或backup,用来说明LVS Router 是master 或是backup。在这个功能上也可以采用keepalived 的VRRP 功能。

--stop-daemon 停止同步守护进程 -h --help 显示帮助信息 其他的选项::

-t --tcp-service service-address

说明虚拟服务器提供的是tcp 的服务[vip:port] or [real-server-ip:port] -u --udp-service service-address

说明虚拟服务器提供的是udp 的服务[vip:port] or [real-server-ip:port] -f --fwmark-service fwmark

说明是经过iptables 标记过的服务类型。 -s --scheduler scheduler

使用的调度算法,有这样几个选项rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq。默认的调度算法是:wlc.

-p --persistent [timeout]

持久稳固的服务。这个选项的意思是来自同一个客户的多次请求,将被同一台真实的服务器处理,timeout 的默认值为300 秒。

-r --real-server server-address 真实的服务器[Real-Server:port] -g --gatewaying

指定LVS 的工作模式为直接路由模式(也是LVS 默认的模式) -i --ipip

指定LVS 的工作模式为隧道模式 -m --masquerading

指定LVS 的工作模式为NAT 模式 -w --weight weight 真实服务器的权值 --mcast-interface interface 指定组播的同步接口 -c --connection

显示LVS 目前的连接 如:ipvsadm -L –,输出对应文件/proc/net/ip_conn --timeout

显示tcp tcpfin udp 的timeout 值 如:ipvsadm -L --timeout --daemon

显示同步守护进程状态 --stats

显示统计信息, 输出对应文件/proc/net/ip_vs_stats --rate

显示速率信息,输出对应文件/proc/net/ip_vs_stats --sort

对虚拟服务器和真实服务器排序输出 --numeric -n

输出IP 地址和端口的数字形式

4 Q&A

a.编译问题

Ipvsadm必须与内核版本对应。

在ipvsadm编译时没有configure过程,所以需要把建立/usr/src/linux与内核source的连接。

b.编辑/etc/hosts,加入RS的主机名

c.ActiveConn/InActConn (Active/Inactive) connnection的意义

ActiveConn ESTABLISHED状态的连接

InActConn 非ESTABLISHED状态的连接(例如TIME_WAIT、SYN_RECV等)

在LVS-NAT模式下,所有客户端和RS的数据交互均通过LD,LD能够准确的得出所有客户端的连接数。但在LVS-DR和LVS-TUN的模式下,RS到客户端的数据并不通过LD,当RS主动断开连接时,LD只能从客户端发来的ACK信号进行判断,所以LD上的ActiveConn/InActConn连接数量并不是完全准确的。并且对于UDP来说,这两个值是没有多大意义的

因篇幅问题不能全部显示,请点此查看更多更全内容

Copyright © 2019- 7swz.com 版权所有 赣ICP备2024042798号-8

违法及侵权请联系:TEL:199 18 7713 E-MAIL:2724546146@qq.com

本站由北京市万商天勤律师事务所王兴未律师提供法律服务