LVS Real Server 健康状态检测脚本.docx

LVS Real Server 健康状态检测脚本.docx

《LVS Real Server 健康状态检测脚本.docx》由会员分享，可在线阅读，更多相关《LVS Real Server 健康状态检测脚本.docx（42页珍藏版）》请在冰豆网上搜索。

LVSRealServer健康状态检测脚本

简介：

Linux虚拟服务器（LinuxVirtualServer.LVS）,是一个由章文松开发的自由软件.利用KVS可以实现高可用的、可伸缩缩的Web,Mail,Cache和Medial等网络股务..井在此基础上开发支持庞大用户数的，可伸缩的，高可用的电子商务应用。

LVS1998年发展到现在，已经变得比较成熟，目前广泛应用在各种网络服务和电了商务应用中.

LVS具有很好的伸缩缩性、可靠性和管埋性，通过LVS要实现的最终目标是：

利用linux操作系统和LVS集群软件实现一个高可用、高性能，低成本的服务器应用集群。

LVS集群的组成

利用LVS架设的服务器群系统由3个部分组成：

最前端的是负栽均衡层（这里用LoadBalancer表示），中间是服务器集群层（用ServerArray表示）.

LVS体系结构如下图所示：

下面对LVS的各个组成部分进行详细介绍

负栽均衡层：

位于整个集群系统的最前端，由一台或多台负栽调度器（DircctmServer）组成.LVS核心模块IPVS就安装在directorServer上，而director的主要作用类似于一个路由器，它含有为完成LVS功能所设定的路由表，通过这些路由表把用户的请求分发给服务器群组层的应用服务器（realServer）。

同时，在directorserver上还要安装队realserver的监控模块Ldirectord，此模块用于监测各个realserver服务的健康状况。

在realserver不可同时可以讲其从LVS路由表中剔除，在恢复时重新加入。

服务器群组层：

由一组实际运行应用服务的机器组成，realServer可以是Web服务器、Mail服务器、FTP服务器、DNS服务器、视颊服务器中的一个或多个，每个RealServer之间通过高速的LAN或分布在各地的WAN相连接:

实际的应用中，DirectorServer也可以同时兼任RealServer的角色

共字存储层是为所有RealServer提供共亨存储空问和内容一致性的存储区域，一般由磁盘阵列设备组成。

为了提俱内容的一致性，一般可以通过NFS网络义件系统共亨数据，但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系统，例如RedHat的GFS文件系统，Oracle提供的OS2文件系统等。

从整个LVS结构可以看出，DirectorServer是整个LVS的核心。

目前，用干DirectorServer的操作系统只有Linux和FreeBSD,Linux2.6内核完全内置了LVS的各个模块，不用任何设置就可以支持LVS功能。

对丁Real.Server,几乎所有的系统平台，如Linux、..Windows、Solaris、AIX、BSD系列等都能很好地支持它 

LVS集群的特点

1.IP负载均衡与负载调度

1负栽均衡技术有很多实现方案，有基于DNS.域名轮流解析的方法，有基于客户端调度访问的方法，还有基于应用层系统负栽的调度方法，还有基于p地址的调度方法。

在这些负栽调度算法中，执行效率最卨的是IP负栽均衡技术。

LVS的IP负栽均衡技术是通过IPVS模块来实现的。

IPVS是LVS集群系统的核心软件，它的主要作用是:

安装在DirectorServer上，同时在DirectorServer..上虚拟出一个IP地址，用户必须通过这个虚拟的IP地址访问服务器，这个虚拟IP—般称为LVS的VIP,即VirtualIP 访问的请求首先经过VIP到达负栽调度器，然后由负栽调度器从RealServer列表中选取一个服务节点响应用户的请求。

在用户的清求到达负栽调度器后，调度器如何将请求发送到提供服务的RealServer节点，而RealServer节点如何返回数据给用户，是IPVS实现的重点技术。

IPVS实现负栽均衡的方式有4种.分别是NAT|FullNAT、TUN和DR。

下面进行详细介绍。

IPVS/NAT ：

即VirtualServerviaNetworkAddressTranslation,也就是网络地址翻译技术实现虚拟服务器。

当用户请求到达调度器时，调度器将请求报文的目标地址（即虚拟IP地址）改写成选定的RealServer地址，同时将报文的目标端口也改成选定的RealServer的相应端口，最后将报文请求发送到选定的RealServer。

在服务器端得到数据后，RealServer将数据返回给用户时，需要再次经过负栽调度器将报文的源地址和源端口改成虚拟IP地址和相应端口,然后把数据发送给用户，完成整个负栽调度过程。

可以看出，在NAT方式下，用户请求和响应报文都必须经过DirectorServer地址重写，当用户请求越来越多时，调度器的处理能力将成为瓶颈.如下图所示：

IPVS/NAT架构图

NAT：

多目标的DNAT

特性：

∙RS应该使用私有地址；

∙RS的网关必须指向DIP；

∙RIP和DIP必须在同一网段内；

∙请求和响应的报文都得经过Director；（在高负载应用场景中，Director很可能成为系统性能瓶颈）

∙支持端口映射；

∙RS可以使用任意支持集群服务的OS（如Windows）

适用场景：

∙非高并发请求场景，10个RS以内；可隐藏内部的DIP和RIP地址；

结构图:

LVS/TUN：

即VirtualServerviaIPTunneling,也就是通过IP隧道技术实现虚拟服务器。

这种方式的连接调度度和管理与VS/NAT方式一样，只是报文转发方法不同。

在VS/TUN方式中，调度器采用IP隧道技术将用户清求转发到某个RealServer,而这个RealServer将直接响应用户的请求，不再经过前端调度器。

此外，对RealServer的地域位置没有要求，可以和DirectorServer位于同一个网段，也可以在独立的一个网络中。

因此，在TUN方式中，调度器将只处理用户的报文请求，从而使集群系统的吞吐量大大提高。

如下图所示VS/TUN架构图：

TUN：

IP隧道，即含有多个IP报头

特性：

∙RIP、DIP、VIP都得是公网地址；

∙RS的网关不会指向也不可能指向DIP；

∙请求报文经过Director，但响应报文一定不经过Director；

∙不支持端口映射；

∙RS的操作系统必须得支持隧道功能，即部署ipip模块

适用场景：

∙跨互联网的请求转发

结构图：

FULLNAT是一种新的转发模式

–主要思想：

引入localaddress（内网ip地址），cip-vip转

换为lip->rip，而lip和rip均为IDC内网ip，可以跨vlan通

讯；FULLNAT：

NAT模型的改进版

特性：

∙实现RS间跨VLAN通信，是NAT模式的改进版；

∙默认内核不支持，需重新编译内核，才能使用；

适用场景：

∙内网服务器跨VLAN的负载分担

结构图：

LVS/DR：

 即VirtualServerviaDirectRouting,也就是用直接路由技术实现虚拟服务器。

这种方式的连按调度和管理与前两种一样，但它的报文转发方法又有所不同，VS/DR通过改写请求报文的MAC地址，将请求发送到RealServer,而RealServer将响应直接返回给客户.免去了VS/TUN中的IP隧道开销，这种方式是3种负莪调度方式中性能最好的，但是要求DirectorServer与RealServer必须由一块网卡连在同一物理网段上。

如下图所示：

VS/DR架构图

DR：

DirectRouting

需解决的关键问题：

∙让前端路由将请求发往VIP时，只能是Director上的VIP进行响应；实现方式是修改RS上的Linux内核参数，将RS上的VIP配置为lo接口的别名，并限制Linux仅对对应接口的ARP请求做响应

特性：

∙RS可以使用私有地址，但也可以使用公网地址，此时可以直接通过互联网连入RS以实现配置，监控等；

∙RS的网关一定不能指向DIP；

∙RS和Director要在同一物理网络（即不能由路由器分隔）

∙请求报文经过Director，但响应报文一定不进过Director；

∙不支持端口映射；

∙RS可以使用大多数的操作系统

适用场景：

∙因为响应报文不经过Director，极大的减轻了Director的负载压力，故Director可以支持更大的并发访问，一般RS在100台以内；

结构图：

LVS-DR配置架构根据其VIP与RIP是否在同一个网段内又分为两种模型:

LVS调度算法

（2）负我调度算法

静态方法：

仅根据算法本身进行调度

rr：

RoundRobin#即轮询

wrr：

WeightedRR#即加权轮询

sh：

SourceHashing#即来源IP地址hash

dh：

DestinationHashing#即目标地址hash（不常用，仅用于前端多防火墙的场景，保证防火墙的连接追踪功能有效）

动态方法：

根据算法及RS当前的负载情况

lc：

LeastConnection

#评判标准：

Overhead=Active*256+Inactive

#Overhead最小者胜出

wlc：

WeightedLC

#评判标准：

Overhead=（Active*256+Inactive）/weight

#Overhead最小者胜出

sed：

ShortestExpectDelay

#评判标准：

Overhead=（Active+1）*256/weight

#Overhead最小者胜出

nq：

NeverQueue#集群开始时工作时，每台服务器都至少分配一个连接请求，然后再根据sed算法调度；

lblc：

Locality-basedLeastConnection#类似于dh+lc

lblcr：

RelicatedandLocality-basedLeastConnection#主要用于后端服务器是缓存服务器时

前面介绍过，负载调度器是根据各个服务器的负栽情况，动态地选择一台RealServer响应用户请求。

那么动态选择是如何实现呢？

其实就是通过这里要说的负栽调度算法。

根据不同的网络眼务需求和眼务器配IPVS实现T8种负栽调度算法。

这里详细讲述最常用的4种调度算法。

1、轮询（roundrobin,rr）,加权轮询（Weightedroundrobin,wrr）——新的连接请求被轮流分配至各RealServer；算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。

轮叫调度算法假设所有服务器处理性能均相同，不管服务器的当前连接数和响应速度。

该算法相对简单，不适用于服务器组中处理性能不一的情况，而且当请求服务时间变化比较大时，轮叫调度算法容易导致服务器间的负载不平衡。

2、最少连接（leastconnected,lc），加权最少连接（weightedleastconnection,wlc）——新的连接请求将被分配至当前连接数最少的RealServer；最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。

调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。

3、基于局部性的最少链接调度（Locality-BasedLeastConnectionsScheduling，lblc）——针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中客户请求报文的目标IP地址是变化的。

这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。

LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于其一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器。

4、带复制的基于局部性最少链接调度（Locality-BasedLeastConnectionswithReplicationScheduling，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地址对应的服务器组；按“最小连接”原则从该服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载；则按“最小连接”原则从整个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。

同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

5、目标地址散列调度（DestinationHashing，dh）算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。

目标地址散列调度算法先根据请求的目标IP地址，作为散列键（HashKey）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

6、源地址散列调度（SourceHashing，sh）算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（HashKey）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

它采用的散列函数与目标地址散列调度算法的相同。

除了将请求的目标IP地址换成请求的源IP地址外，它的算法流程与目标地址散列调度算法的基本相似。

在实际应用中，源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中，它们可以保证整个系统的唯一出入口。

7、加权最少连接调度（WeightedLeastConnections）。

“加权最少连接调度”是“最少连接调度”的超集。

每个服务节点可以用相应的权值表示其处理能力，而系统管理员可以动态地设置相应的权值，默认权值为1。

加权最小连接调度在分新连接请求时尽可能使服务节点的已建立连接数和其权值成正比。

算法：

overhead=active*256+inactive/weight overhead最小值胜出；

8、sed：

shorttestexpectdelay 最小期望延迟（改进的wlc）算法：

overhead=（active+1）*256/weight，案例：

假如DFG三台机器分别权重123，连接数也分别是123.那么如果使用WLC算法的话一个新请求进入时它可能会分给DFG中的任意一个。

使用sed算法后会进行这样一个运算：

D（1+1）/1

F（1+2）/2

G（1+3）/3

9、nq：

nerverqueue    增强改进的sed算法.如果有台realServer的连接数=0直接分配,不需要再进行sed运算

2.高可用性

LVS是一个基于内核级别的应用软件，因此具有很髙的处理性能。

由LVS构建的负载均衡集群系统具有优秀的处理能力，每个服务节点的故障不会影响整个系统的正常使用，又能够实现负载的合理均衡，使应用具有超高负荷的服务能力，可支持上百万个并发连接请求。

如配置百兆网卡，采用VS/TUN或VS/DR调度技术，整个集群系统的吞吐量可高达1Gbit/s；又如配置千兆网卡，系统的最大吞吐量可接近10Gbit/s。

3.高可靠性

LVS负载均衡集群软件已经在企业和学校中得到了很好的普及，国内外很多大型的、关键性的Web站点也都采用了LVS集群软件，所以它的可靠性在实践中得到了很好印证。

有很多由LVS构成的负载均衡系统，运行很长时间，从未进行过重新启动。

这些都说明了LVS的髙稳定性和高可靠性。

4、配置LVS

1、定义在Director上进行dispatching的服务（service），以及哪此服务器（server）用来提供此服务；

2、为每台同时提供某一种服务的服务器定义其权重（即概据服务器性能确定的其承担负载的能力）；

注：

权重用整数来表示，有时候也可以将其设置为atomic_t；其有效表示值范围为24bit整数空间，即（2^24-1）；

因此，ipvsadm命令的主要作用表现在以下方面：

1、添加服务（通过设定其权重>0）；

2、关闭服务（通过设定其权重>0）；此应用场景中，已经连接的用户将可以继续使用此服务，直到其退出或超时；新的连接请求将被拒绝；

3、保存ipvs设置，通过使用“ipvsadm-sav>ipvsadm.sav”命令实现；

4、恢复ipvs设置，通过使用“ipvsadm-sav

5、显示ip_vs的版本号，下面的命令显示ipvs的hash表的大小为4k；

 #ipvsadm

  IPVirtualServerversion1.2.1（size=4096）

6、显示ipvsadm的版本号

 #ipvsadm--version

 ipvsadmv1.242003/06/07（compiledwithpoptandIPVSv1.2.0）

二、ipvsadm使用中应注意的问题

默认情况下，ipvsadm在输出主机信息时使用其主机名而非IP地址，因此，Director需要使用名称解析服务。

如果没有设置名称解析服务、服务不可用或设置错误，ipvsadm将会一直等到名称解析超时后才返回。

当然，ipvsadm需要解析的名称仅限于RealServer，考虑到DNS提供名称解析服务效率不高的情况，建议将所有RealServer的名称解析通过/etc/hosts文件来实现；

三、调度算法

Director在接收到来自于Client的请求时，会基于"schedule"从RealServer中选择一个响应给Client。

ipvs支持以下调度算法：

四、关于LVS追踪标记fwmark：

如果LVS放置于多防火墙的网络中，并且每个防火墙都用到了状态追踪的机制，那么在回应一个针对于LVS的连接请求时必须经过此请求连接进来时的防火墙，否则，这个响应的数据包将会被丢弃。

常用命令：

查看LVS上当前的所有连接

#ipvsadm-Lcn  

或者

#cat/proc/net/ip_vs_conn

查看虚拟服务和RealServer上当前的连接数、数据包数和字节数的统计值，则可以使用下面的命令实现：

#ipvsadm-l--stats

查看包传递速率的近似精确值，可以使用下面的命令：

#ipvsadm-l--rate

VS/NAT

LVS-NAT基于cisco的LocalDirector。

VS/NAT不需要在RealServer上做任何设置，其只要能提供一个tcp/ip的协议栈即可，甚至其无论基于什么OS。

基于VS/NAT，所有的入站数据包均由Director进行目标地址转换后转发至内部的RealServer，RealServer响应的数据包再由Director转换源地址后发回客户端。

VS/NAT模式不能与netfilter兼容，因此，不能将VS/NAT模式的Director运行在netfilter的保护范围之中。

现在已经有补丁可以解决此问题，但尚未被整合进ip_vscode。

　　　__________

||

|client|

|____________|

CIP=192.168.0.253（eth0）

|

|

VIP=192.168.0.220（eth0）

____________

||

|director|

|____________|

DIP=192.168.10.10（eth1）

|

（switch）------------------------

||

RIP=192.168.10.2（eth0）RIP=192.168.10.3（eth0）

__________________________

||||

|realserver1||realserver2|

|_____________||_____________|

设置VS/NAT模式的LVS（这里以web服务为例）

Director:

建立服务

#ipvsadm-A-tVIP:

PORT-srr

如:

#ipvsadm-A-t192.168.0.220:

80-srr

设置转发：

#ipvsadm-a-tVIP:

PORT-rRIP_N:

PORT-m-wN

如：

#ipvsadm-a-t192.168.0.220:

80-r192.168.10.2-m-w1

#ipvsadm-a-t192.168.0.220:

80-r192.168.10.3-m-w1

打开路由转发功能

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

服务控制脚本：

#!

/bin/bash

#

#chkconfig:

-8812

#description:

LVSscriptforVS/NAT

#

./etc/rc.d/init.d/functions

#

VIP=192.168.0.219

DIP=192.168.10.10

RIP1=192.168.10.11

RIP2=192.168.10.12

#

case"$1"in

start）

/sbin/ifconfigeth0:

1$VIPnetmask255.255.255.0up

#SincethisistheDirectorwemustbeab