一.概念

1、什么是LVS

  首先简单介绍一下LVS (LinuxVirtual Server)到底是什么东西,其实它是一种集群(Cluster)技术,采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无需修改客户端和服务器端的程序。

  为此,在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。一般来说,LVS集

  群采用三层结构,其体系结构如图所示:

  LVS集群的体系结构

  2、LVS主要组成部分为:

  负载调度器(load balancer/ Director),它是整个集群对外面的前端机,负责将客户的请求发送到一组服务器上执行,而客户认为服务是来自一个IP地址(我们可称之为虚拟IP地址)上的。

  服务器池(server pool/ Realserver),是一组真正执行客户请求的服务器,执行的服务一般有WEB、MAIL、FTP和DNS等。

  共享存储(shared storage),它为服务器池提供一个共享的存储区,这样很容易使得服务器池拥有相同的内容,提供相同的服务。

3、LVS负载均衡方式:

  ◆Virtual Server via Network Address Translation NAT(VS/NAT)

  VS/NAT是一种最简单的方式,所有的RealServer只需要将自己的网关指向Director即可。客户端可以是任意操作系统,但此方式下,一个Director能够带动的RealServer比较有限。在VS/NAT的方式下,Director也可以兼为一台RealServer。VS/NAT的体系结构如图所示。

  VS/NAT的体系结构

  ◆Virtual Server via IP Tunneling(VS/TUN)

  IP隧道(IP tunneling)是将一个IP报文封装在另一个IP报文的技术,这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network),在其中隧道都是静态建立的,隧道一端有一个IP地址,另一端也有唯一的IP地址。它的连接调度和管理与VS/NAT中的一样,只是它的报文转发方法不同。调度器根据各个服务器的负载情况,动态地选择一台服务器,将请求报文封装在另一个IP报文中,再将封装后的IP报文转发给选出的服务器;服务器收到报文后,先将报文解封获得原来目标地址为 VIP 的报文,服务器发现VIP地址被配置在本地的IP隧道设备上,所以就处理这个请求,然后根据路由表将响应报文直接返回给客户。

  VS/TUN的体系结构

  VS/TUN的工作流程:

  ◆Virtual Server via Direct Routing(VS/DR)

  VS/DR方式是通过改写请求报文中的MAC地址部分来实现的。Director和RealServer必需在物理上有一个网卡通过不间断的局域网相连。 RealServer上绑定的VIP配置在各自Non-ARP的网络设备上(如lo或tunl),Director的VIP地址对外可见,而RealServer的VIP对外是不可见的。RealServer的地址即可以是内部地址,也可以是真实地址。

  VS/DR的体系结构

VS/DR的工作流程

  VS/DR的工作流程如图所示:它的连接调度和管理与VS/NAT和VS/TUN中的一样,它的报文转发方法又有不同,将报文直接路由给目标服务器。在VS/DR中,调度器根据各个服务器的负载情况,动态地选择一台服务器,不修改也不封装IP报文,而是将数据帧的MAC地址改为选出服务器的MAC地址,再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器,所以服务器肯定可以收到这个数据帧,从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上,服务器处理这个报文,然后根据路由表将响应报文直接返回给客户。

  VS/DR的工作流程

  4、三种负载均衡方式比较:

  ◆Virtual Server via NAT

  VS/NAT 的优点是服务器可以运行任何支持TCP/IP的操作系统,它只需要一个IP地址配置在调度器上,服务器组可以用私有的IP地址。缺点是它的伸缩能力有限,当服务器结点数目升到20时,调度器本身有可能成为系统的新瓶颈,因为在VS/NAT中请求和响应报文都需要通过负载调度器。我们在Pentium166 处理器的主机上测得重写报文的平均延时为60us,性能更高的处理器上延时会短一些。假设TCP报文的平均长度为536 Bytes,则调度器的最大吞吐量为8.93 MBytes/s. 我们再假设每台服务器的吞吐量为800KBytes/s,这样一个调度器可以带动10台服务器。(注:这是很早以前测得的数据)

  基于 VS/NAT的的集群系统可以适合许多服务器的性能要求。如果负载调度器成为系统新的瓶颈,可以有三种方法解决这个问题:混合方法、VS/TUN和 VS/DR。在DNS混合集群系统中,有若干个VS/NAT负调度器,每个负载调度器带自己的服务器集群,同时这些负载调度器又通过RR-DNS组成简单的域名

  但VS/TUN和VS/DR是提高系统吞吐量的更好方法。

  对于那些将IP地址或者端口号在报文数据中传送的网络服务,需要编写相应的应用模块来转换报文数据中的IP地址或者端口号。这会带来实现的工作量,同时应用模块检查报文的开销会降低系统的吞吐率。

  ◆Virtual Server via IP Tunneling

  在VS/TUN 的集群系统中,负载调度器只将请求调度到不同的后端服务器,后端服务器将应答的数据直接返回给用户。这样,负载调度器就可以处理大量的请求,它甚至可以调度百台以上的服务器(同等规模的服务器),而它不会成为系统的瓶颈。即使负载调度器只有100Mbps的全双工网卡,整个系统的最大吞吐量可超过 1Gbps。所以,VS/TUN可以极大地增加负载调度器调度的服务器数量。VS/TUN调度器可以调度上百台服务器,而它本身不会成为系统的瓶颈,可以用来构建高性能的超级服务器。VS/TUN技术对服务器有要求,即所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。目前,VS/TUN的后端服务器主要运行Linux操作系统,我们没对其他操作系统进行测试。因为“IP Tunneling”正成为各个操作系统的标准协议,所以VS/TUN应该会适用运行其他操作系统的后端服务器。

  ◆Virtual Server via Direct Routing

  跟VS/TUN方法一样,VS/DR调度器只处理客户到服务器端的连接,响应数据可以直接从独立的网络路由返回给客户。这可以极大地提高LVS集群系统的伸缩性。跟VS/TUN相比,这种方法没有IP隧道的开销,但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上,服务器网络设备(或者设备别名)不作ARP响应,或者能将报文重定向(Redirect)到本地的Socket端口上。

二.ipvsadm 的用法和格式

为了更好的让大家理解这份命令手册,将手册里面用到的几个术语先简单的介绍一下:

1、virtual-service-address:是指虚拟服务器的ip地址
2、real-service-address:是指真实服务器的ip 地址
3、scheduler:调度方法

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

命令选项解释:
有两种命令选项格式,长的和短的,具有相同的意思。在实际使用时,两种都可以。
-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 显示内核虚拟服务器表
-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 秒。
-M --netmask netmask persistent granularity mask
-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 -c
--timeout 显示tcp tcpfin udp 的timeout 值 如:ipvsadm -L --timeout
--daemon 显示同步守护进程状态
--stats 显示统计信息
--rate 显示速率信息
--sort 对虚拟服务器和真实服务器排序输出
--numeric -n 输出IP 地址和端口的数字形式

 

LVS的三种包转发方式

  LVS提供了三种包转发方式:NAT(网络地址映射)、IP Tunneling(IP隧道)、Direct Routing(直接路由)。不同的转发模式决定了不同的cluster的网络结构,下面对三种转发方式分别介始:

  NAT(网络地址映射)

   NAT方式可支持任何的操作系统,以及私有网络,并且只需一个Internet IP地址,但是整个系统的性能受到限制。因为执行NAT每次需要重写包,有一定的延迟;另外,大部分应用有80%的数据是从服务器流向客户机,也就是用户的请求非常短,而服务器的回应非常大,对负载均衡器形成很大压力,成为了新的瓶颈。

  IP Tunneling(IP隧道)

   director分配请求到不同的real server。real server处理请求后直接回应给用户,这样director负载均衡器仅处理客户机与服务器的一半连接。IP Tunneling技术极大地提高了director的调度处理能力,同时也极大地提高了系统能容纳的最大节点数,可以超过100个节点。real server可以在任何LAN或WAN上运行,这意味着允许地理上的分布,这在灾难恢复中有重要意义。服务器必须拥有正式的IP地址用于与客户机直接通信,并且所有服务器必须支持IP隧道协议。

  Direct Routing(直接路由)

  与IP Tunneling类似,负载均衡器仅处理一半的连接,避免了新的性能瓶颈,同样增加了系统的可伸缩性。Direct Routing与IP Tunneling相比,没有IP封装的开销,但由于采用物理层(修改MAC地址)技术,所有服务器都必须在一个物理网段。

LVS的负载调度算法

在内核中的连接调度算法上,IPVS已实现了以下八种调度算法:
一、轮叫调度(Round-Robin Scheduling) ----rr
轮叫调度(Round Robin Scheduling)算法就是以轮叫的方式依次将请求调度不同的服务器,即每次调度执行i = (i + 1) mod n,并选出第i台服务器。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。

二、加权轮叫调度(Weighted Round-Robin Scheduling) ----wrr
加权轮叫调度(Weighted Round-Robin Scheduling)算法可以解决服务器间性能不一的情况,它用相应的权值表示服务器的处理性能,服务器的缺省权值为1。假设服务器A的权值为1,B的权值为2,则表示服务器B的处理性能是A的两倍。加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接,权值高的服务器比权值低的服务器处理更多的连接,相同权值的服务器处理相同数目的连接数。

三、最小连接调度(Least-Connection Scheduling) ---lc
最小连接调度(Least-Connection Scheduling)算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器,其连接数加1;当连接中止或超时,其连接数减一。

四、加权最小连接调度(Weighted Least-Connection Scheduling)---wlc
加权最小连接调度(Weighted Least-Connection Scheduling)算法是最小连接调度的超集,这个是ipvsadm的默认算法。各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1,系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。

五、基于局部性的最少链接(Locality-Based Least Connections Scheduling) --lblc
基于局部性的最少链接调度(Locality-Based Least Connections Scheduling,以下简称为LBLC)算法是针对请求报文的目标IP地址的负载均衡调度,目前主要用于Cache集群系统,因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标IP地址的请求调度到同一台服务器,来提高各台服务器的访问局部性和主存Cache命中率,从而整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于其一半的工作负载,则用“最少链接”的原则选出一个可用的服务器,将请求发送到该服务器。

六、带复制的基于局部性最少链接(Locality-Based Least Connections with Replication Scheduling)--lblcr
带复制的基于局部性最少链接调度(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) ---dh
目标地址散列调度(Destination Hashing Scheduling)算法也是针对目标IP地址的负载均衡,但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。

八、源地址散列调度(Source Hashing Scheduling)---sh
源地址散列调度(Source Hashing Scheduling)算法正好与目标地址散列调度算法相反,它根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目标地址散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本相似,除了将请求的目标IP地址换成请求的源IP地址,所以这里不一一叙述。在实际应用中,源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中,它们可以保证整个系统的唯一出入口。

应用例子:

由于LVS像iptable一样是工作在内核层,所以只需要安装模块ip_vs就可以了,并没有后台进程在跑。对应lvs主机三种方式分别用参数-m, -i, -g来实现。以下列举几种链接方式的配置方法:

1.NAT方式:

NAT配置方式最简单,只需要在LVS主机上配置就可以了,如下例子:

 
  

设置VIP主机:

ipvsadm -A -t 202.103.106.5:80 -s wlc

ipvsadm -A -t 202.103.106.5:21 -s wrr

ipvsadm -a -t 202.103.106.5:80 -r 172.16.0.2:80 -m

ipvsadm -a -t 202.103.106.5:80 -r 172.16.0.3:8000 -m -w 2

ipvsadm -a -t 202.103.106.5:21 -r 172.16.0.2:21 -m

2.TUN方式:

对LVS主机设置:

 
  

设置VIP主机:

ipvsadm -A -t 172.26.20.110:23 -s wlc ipvsadm -a -t 172.26.20.110:23 -r 172.26.20.112 -i

对每台real主机的设置:

echo 1 > /proc/sys/net/ipv4/ip_forward#加载ipip模块modprobe ipip
ifconfig tunl0 0.0.0.0 up
echo 1 > /proc/sys/net/ipv4/conf/all/hidden
echo 1 > /proc/sys/net/ipv4/conf/tunl0/hidden
ifconfig tunl0 172.26.20.110 netmask 255.255.255.255 broadcast 172.26.20.110 up

三.实例

原文地址:

http://network.51cto.com/art/201006/206831_all.htm

①如果四台机器均置于IDC机房,前端无防火墙时,这种情况好处理,只需要向你的IDC申请5个公网IP即可,多余的一个公网ip用于VIP;


②如果是上述网络拓扑,后面四台机器均用内网;此时只需要前面的Juniper将内网VIP映射成公网IP即可,注:非映射80和443端口,感谢田逸兄提供的技术性指导意见;


③lvs就比较依赖于网络环境,可以用苛求来形容;要做好LVS管理员,确实得跟进学习很多有关网络通信方面的知识,就不再是一个HTTP那么简单了;相对而言,nginx对网络的依赖较小,理论上只要ping得通,网页访问正常,nginx就能连得通。


④本来我想将公司的web环境生级成LVS+Keepalived架构,却发现lvs怎么都不能转发;结果查了下机器的route情况,发现每台机器都有十几条静态路由,二个网关,而Network engineer也说明了网络环境不可能更改,只能由系统环境牵就网络环境;最后只能将LVS+Keepalvied更改为Nginx+Keepalived架构,甚是遗憾。

这里首先说下LVS/DR的网络拓扑情况,如果均置于电信IDC机房,用5个外网IP的话,整个网络拓扑清晰明了,实施起来也非常方便;但如果是置于Juniper防火墙后,情况就有点小复杂了,这时仍可用内网IP,只要将内网的VIP通过Juniper防火墙转换成一个公网IP即可,注:此时不要做80端口的映射,在这里感谢田逸兄的指导性意见。


服务器故障:(服务器故障包括:服务器宕机、web服务终止、网线松动等等)


①当lvs-master故障时,无法再接受用户请求并将请求转发给真实的web服务器(即便真实web服务器正常)从而导致整个web服务的瘫痪,也就是lvs控制器存在单点故障问题。


②当lvs-master正常时,真实地web服务器如web1-realserver故障。此时lvs-master并不知道真实服务器是否在正常提供web服务,所以仍然在向故障的web1-realserver转发用户请求。这样的结果是用户请求无法被故障web服务器相应,某些用户可以访问网站有些则无法访问。


基于以上的问题,我们需要想办法实现对lvs控制器和web服务器的健康监测,一旦服务出现问题能保证服务不中断的情况下排除故障。即增加lvs控制器实现主备模式避免单点故障以及自动删除故障web服务结点并当它恢复后再自动添加到群集中这样的功能,这就是LVS+keepalived能实现的功能。整个系统的拓扑如下:


  wKioL1W_Ad-hGyUzAADvefOWYYg954.jpg


实施步骤:


①在realserver主机上实行脚本realserver,为lo:0绑定VIP地址192.168.5.188,这步分别在二个web主机上192.168.5.104、192.168.5.105实施。这步提前做,是因为以后的过程中这一步是不会发生更改的。


#vim /usr/local/sbin/realserver  

#!/bin/bash  

SNS_VIP=192.168.5.188  

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

case "$1" in  

start)  

       ifconfig lo:0 $SNS_VIP netmask 255.255.255.255 broadcast $SNS_VIP  

       /sbin/route add -host $SNS_VIP dev 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  

       sysctl -p >/dev/null 2>&1  

       echo "RealServer Start OK"   

       ;;  

stop)  

       ifconfig lo:0 down  

       route del $SNS_VIP >/dev/null 2>&1  

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

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

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

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

       echo "RealServer Stoped"  

       ;;  

*)  

       echo "Usage: $0 {start|stop}"  

       exit 1  

esac  

exit 0 

简单说明下上述脚本的作用:


1)vip(virtual ip)。直接路由模式的vip必须跟服务器对外提供服务的ip地址在同一个网段,并且lvs 负载均衡器和其他所有提供相同功能的服务器都使用这个vip;


2)vip被绑定在环回接口lo0:0上,其广播地址是其本身,子网掩码是255.255.255.255。这与标准的网络地址设置有很大的不同。采用这种可变长掩码方式把网段划分成只含一个主机地址的目的是避免ip地址冲突;


3)echo这段的作用是抑制arp广播。如果不做arp抑制,将会有众多的机器向其他宣称:“嗨!我是奥巴马,我在这里呢!”,这样就乱套了。


②为二台lvs主机安装lvs+keepalived软件。安装lvs软件是必须做的,因为keepalived是运行在lvs之上的,因此lvs及keepalived必须装在一个系统里面。过程如下:


#mkdir /usr/local/src/lvs  

#cd /usr/local/src/lvs  

#wget http://www.linuxvirtualserver.org/software/kernel-2.6/ipvsadm-1.24.tar.gz  

#ln -s /usr/src/kernels/2.6.18-53.el5PAE-i686/ /usr/src/linux  

#tar zxvf ipvsadm-1.24.tar.gz  

#cd ipvsadm-1.24  

#make   

#make install 

③编辑keepalived.conf文件,直接用keepalived实现负载均衡及高可用性。


a)Keepalved的安装


a)Keepalved的安装  

#wget http://www.keepalived.org/software/keepalived-1.1.15.tar.gz  

#tar zxvf keepalived-1.1.15.tar.gz  

#cd keepalived-1.1.15  

#./configure  

#make  

#make install 

将keepalived做成启动脚务,方便管理:


#cp /usr/local/etc/rc.d/init.d/keepalived /etc/rc.d/init.d/  

#cp /usr/local/etc/sysconfig/keepalived /etc/sysconfig/  

#mkdir /etc/keepalived  

#cp /usr/local/etc/keepalived/keepalived.conf /etc/keepalived/  

#cp /usr/local/sbin/keepalived /usr/sbin/  

#service keepalived start|stop  

b)Keealived的配置


①分别在主从负载均衡服务器上配置keepalived.conf ,内容分别如下:


! Configuration File for keepalived  

global_defs {  

   notification_email {  

         yuhongchun027@163.com  

   }  

   notification_email_from sns-lvs@gmail.com  

   smtp_server 127.0.0.1  

   router_id LVS_DEVEL  

}  

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.5.188   

    }  

}  

virtual_server 192.168.5.188 80 {  

    delay_loop 6                    

    lb_algo wrr                    

    lb_kind DR                    

    persistence_timeout 60          

    protocol TCP                  

    real_server 192.168.5.104 80 {  

        weight 3                 

        TCP_CHECK {  

        connect_timeout 10         

        nb_get_retry 3  

        delay_before_retry 3  

        connect_port 80  

        }  

    }  

    real_server 192.168.5.105 80 {  

        weight 3  

        TCP_CHECK {  

        connect_timeout 10  

        nb_get_retry 3  

        delay_before_retry 3  

        connect_port 80  

        }  

     }  

! Configuration File for keepalived  

global_defs {  

   notification_email {  

         yuhongchun027@163.com  

   }  

   notification_email_from sns-lvs@gmail.com  

   smtp_server 127.0.0.1  

   router_id LVS_DEVEL  

}  

vrrp_instance VI_1 {  

    state BACKUP               

    interface eth0  

    virtual_router_id 51  

    priority 99      

    advert_int 1  

    authentication {  

        auth_type PASS  

        auth_pass 1111  

    }  

    virtual_ipaddress {  

        192.168.5.188   

    }  

}  

virtual_server 192.168.5.188 80 {  

    delay_loop 6                    

    lb_algo wrr                    

    lb_kind DR                    

    persistence_timeout 60          

    protocol TCP                  

    real_server 192.168.5.104 80 {  

        weight 3                 

        TCP_CHECK {  

        connect_timeout 10         

        nb_get_retry 3  

        delay_before_retry 3  

        connect_port 80  

        }  

    }  

    real_server 192.168.5.105 80 {  

        weight 3  

        TCP_CHECK {  

        connect_timeout 10  

        nb_get_retry 3  

        delay_before_retry 3  

        connect_port 80  

        }  

     }  

②分别在二台lvs机上启动servcie keepalived start就可实现负载均衡及高可用集群;keepalived.conf内容说明如下:


●全局定义块


1、email通知。作用:有故障,发邮件报警。


2、Lvs负载均衡器标识(lvs_id)。在一个网络内,它应该是唯一的。


3、花括号“{}”。用来分隔定义块,因此必须成对出现。如果写漏了,keepalived运行时,不会得到预期的结果。由于定义块内存在嵌套关系,因此很容易遗漏结尾处的花括号,这点要特别注意。


●VRRP定义块


1、同步vrrp组vrrp_sync_group。作用:确定失败切换(FailOver)包含的路由实例个数。即在有2个负载均衡器的场景,一旦某个负载均衡器失效,需要自动切换到另外一个负载均衡器的实例是哪些?

2、实例组group。至少包含一个vrrp实例。

3、Vrrp实例vrrp_instance。实例名出自实例组group所包含的那些名字。


(1)实例状态state。只有MASTER和BACKUP两种状态,并且需要大写这些单词。其中MASTER为工作状态,BACKUP为备用状态。当MASTER所在的服务器失效时,BACKUP所在的系统会自动把它的状态有BACKUP变换成MASTER;当失效的MASTER所在的系统恢复时,BACKUP从MASTER恢复到BACKUP状态。


(2)通信接口interface。对外提供服务的网络接口,如eth0,eth1.当前主流的服务器都有2个或2个以上的接口,在选择服务接口时,一定要核实清楚。


(3)lvs_sync_daemon_inteface。负载均衡器之间的监控接口,类似于HA HeartBeat的心跳线。但它的机制优于Heartbeat,因为它没有“裂脑”这个问题,它是以优先级这个机制来规避这个麻烦的。在DR模式中,lvs_sync_daemon_inteface 与服务接口interface 使用同一个网络接口。


(4)虚拟路由标识virtual_router_id。这个标识是一个数字,并且同一个vrrp实例使用唯一的标识。即同一个vrrp_stance,MASTER和BACKUP的virtual_router_id是一致的,同时在整个vrrp内是唯一的。


(5)优先级priority。这是一个数字,数值愈大,优先级越高。在同一个vrrp_instance里,MASTER 的优先级高于BACKUP。若MASTER的priority值为150,那么BACKUP的priority只能是140或更小的数值。


(6)同步通知间隔advert_int。MASTER与BACKUP负载均衡器之间同步检查的时间间隔,单位为秒。


(7)验证authentication。包含验证类型和验证密码。类型主要有PASS、AH两种,通常使用的类型为PASS,据说AH使用时有问题。验证密码为明文,同一vrrp实例MASTER与BACKUP 使用相同的密码才能正常通信。


4、 虚拟ip地址virtual_ipaddress。可以有多个地址,每个地址占一行,不需要指定子网掩码。注意:这个ip必须与我们在lvs客户端设定的vip相一致!


●虚拟服务器virtual_server定义块


虚拟服务器定义是keepalived框架最重要的项目了,是keepalived.conf必不可少的部分。


1、虚拟服务器virtual_server。这个ip来自于vrrp定义块的第“4”步,后面一个空格,然后加上端口号。定义一个vip,可以实现多个tcp端口的负载均衡功能。


(1)delay_loop。健康检查时间间隔,单位是秒。


(2)lb_algo。负载均衡调度算法,互联网应用常使用wlc或rr。


(3)lb_kind。负载均衡转发规则。一般包括DR、NAT、TUN3种,在我的方案中,都使用DR的方式。


(4)persistence_timeout。会话保持时间,单位是秒。这个选项对动态网站很有用处:当用户从远程用帐号进行登陆网站时,有了这个会话保持功能,就能把用户的请求转发给同一个应用服务器。在这里,我们来做一个假设,假定现在有一个lvs 环境,使用DR转发模式,真实服务器有3个,负载均衡器不启用会话保持功能。当用户第一次访问的时候,他的访问请求被负载均衡器转给某个真实服务器,这样他看到一个登陆页面,第一次访问完毕;接着他在登陆框填写用户名和密码,然后提交;这时候,问题就可能出现了---登陆不能成功。因为没有会话保持,负载均衡器可能会把第2次的请求转发到其他的服务器。


(5)转发协议protocol。一般有tcp和udp两种。实话说,我还没尝试过udp协议类的转发。


2、真实服务器real_server,也即服务器池。Real_server的值包括ip地址和端口号,多个连续的真实ip。


(1)权重weight,权重值是一个数字,数值越大,权重越高。使用不同的权重值的目的在于为不同性能的机器分配不同的负载,性能较好的机器,负载分担大些;反之,性能差的机器,则分担较少的负载,这样就可以合理的利用不同性能的机器资源。


(2)Tcp检查tcp_check。


附注:以上就是lvs+keepalived的基本配置步骤,有兴趣的同学建议可做下lvs的1+2的基本架构实验,即不需要keepalived,采用单lvs的方式,其lvs_dr脚本如下


#vim /usr/local/sbin/lvs-dr.sh  

       #!/bin/bash  

       #website director vip.  

       SNS_VIP=192.168.1.188  

       SNS_RIP1=192.168.1.104  

       SNS_RIP2=192.168.1.105  

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

         logger $0 called with $1  

         case "$1" in  

         start)  

         # set squid vip  

         /sbin/ipvsadm --set 30 5 60  

         /sbin/ifconfig eth0:0 $SNS_VIP broadcast $SNS_VIP netmask 255.255.255.255 broadcast $SNS_VIP up  

         /sbin/route add -host $SNS_VIP dev eth0:0  

         /sbin/ipvsadm -A -t $SNS_VIP:80 -s wrr -p 3  

         /sbin/ipvsadm -a -t $SNS_VIP:80 -r $SNS_RIP1:80 -g -w 1  

         /sbin/ipvsadm -a -t $SNS_VIP:80 -r $SNS_RIP2:80 -g -w 1  

         touch /var/lock/subsys/ipvsadm >/dev/null 2>&1  

        ;;  

stop)  

         /sbin/ipvsadm -C  

         /sbin/ipvsadm -Z  

         ifconfig eth0:0 down  

         route del $SNS_VIP  

         rm -rf /var/lock/subsys/ipvsadm >/dev/null 2>&1  

         echo "ipvsadm stoped"  

        ;;  

status)  

         if [ ! -e /var/lock/subsys/ipvsadm ];then  

                 echo "ipvsadm stoped"  

                 exit 1  

         else  

                 echo "ipvsadm OK"  

         fi  

       ;;  

*)  

         echo "Usage: $0 {start|stop|status}"  

         exit 1  

esac  

exit 0 

最新版更新内容如下:


①每台服务器都有二块网卡,分别连接内外网;后端的mysql数据库与web连接采用内网方式,整个网络环境采用内网;


②增加了keepalivedyiyyy .conf语法内容;


③删除了lvs.sh脚本内容,直接让keepalived内容更直接明了,新增加了单lvs的配置脚本lvs_dr.sh;


④lvs主从机上的keepalived.conf文件我直接从生产服务器上download下来了,可方便大家使用。


部分内容参考了田逸和netseek的文章,如果有任何疑问和咨询,欢迎来邮抚琴煮酒yuhongchun027@163.com  


※值得注意的是:


1、你必须向你的服务器所在机房IDC多申请一个IP供VIP使用;多关注/var/log/messages和ipvsadm -ln,利用其有效信息排错。


2、服务器的iptables、Selinux均关闭;在生产环境中,我就遇到了iptables的NAT转发问题,导致了lvs失败。


3、keepalived的启动过程并不会对配置文件进行语法检查,就算没有配置文件,keepalived的守护进程照样能够被运行起来。在默认状态下,即不指定配置文件的位置--keepalived先查找文件/etc/keepalived/keepalived.conf。


4、session的过程默认是以文件的形式存在,在浏览器关闭或重启时删除;会话保持我建议写成120秒,如果这个值设置得不合理,用户将得到非常糟糕的访问效果。


5、keepalived是lvs的扩展项目,因此它们之间具备良好的兼容性,这点应该是keepalived部署比其他类似工具能更简洁的原因吧,lvs+keepalived目前是一个应用于生产环境的成熟架构,实现了真正意义上的负载均衡高可用(尤其是对于Nginx+Keepalived而言),尤其适用于bbs和blog(它们均是访问频繁,用户量大的对象),建议熟练掌握。