lvs+keepalived+nginx负载均衡搭建实

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。目前，LVS项目已提供了一个实现可伸缩网络服务的Linux Virtual Server框架，如下图所示。在LVS框架中，提供了含有三种IP负载均衡技术的IP虚拟服务器软件IPVS、基于内容请求分发的内核Layer-7交 换机KTCPVS和集群管理软件。可以利用LVS框架实现高可伸缩的、高可用的Web、Cache、Mail和Media等网络服务；在此基础上，可以开 发支持庞大用户数的、高可伸缩的、高可用的电子商务应用。

在调度器的实现技术中，IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，我们称之为VS/NAT技术（Virtual Server via Network Address Translation），大多数商品化的IP负载均衡调度器产品都是使用此方法，如Cisco的LocalDirector、F5的Big/IP和 Alteon的ACEDirector。在分析VS/NAT的缺点和网络服务的非对称性的基础上，我们提出通过IP隧道实现虚拟服务器的方法VS/TUN （Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。所以，IPVS软件实现了这三种IP负载均衡技术。

1. Virtual Server via Network Address Translation（VS/NAT）
   通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。
2. Virtual Server via IP Tunneling（VS/TUN）
   采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报 文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。
3. Virtual Server via Direct Routing（VS/DR）
   VS/DR通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。

针对不同的网络服务需求和服务器配置，IPVS调度器实现了如下八种负载调度算法：

1. 轮叫（Round Robin）
   调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
2. 加权轮叫（Weighted Round Robin）
   调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
3. 最少链接（Least Connections）
   调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。
4. 加权最少链接（Weighted Least Connections）
   在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
5. 基于局部性的最少链接（Locality-Based Least Connections）
   "基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器 是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务 器，将请求发送到该服务器。
6. 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）
   "带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一 台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的 程度。
7. 目标地址散列（Destination Hashing）
   "目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
8. 源地址散列（Source Hashing）
   "源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

Keepalived

keepalived是一个类似于layer3, 4 & 7交换机制的软件，也就是我们平时说的第3层、第4层和第7层交换。Keepalived是自动完成，不需人工干涉。

Keepalived的作用是检测服务器的状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。

keepalived的诞生最初是为LVS ipvs（director）提供高可用性的，后来发展一个多功能、通用的轻量级高可用组件，可以为ipvs、nginx、haproxy等诸多服务提供高可用功能，主要应用在负载均衡调度器上，同时也可以检查后端各realserver的健康状态。

 如上图，keepalived主要是模块是VRRP Stack和Cheackers，VRRP主要实现VIP（及MAC）的高可用，下面再详细认识其实现；Cheackers主要实现各服务如ipvs、nginx等的高可用及realserver健康状态检查，其中ipvs和realserver健康状态检查通过配置文件配置就可以实现，而其他服务高可用则需要通过自己编写脚本，然后配置keepalived调用来实现。
Keepalived运行有3个守护进程。父进程主要负责读取配置文件初始化、监控2个子进程等；然后两个子进程，一个负责VRRP，另一个负责Cheackers健康检查。其中父进程监控模块为WacthDog，工作实现：每个子进程打开一个接受unix域套接字，父进程连接到那些unix域套接字并向子进程发送周期性（5s）hello包。

VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议）可以认为是实现路由器高可用的协议，简单的说，当一个路由器故障时可以由另一个备份路由器继续提供相同的服务。
即将N台提供相同功能的路由器组成一个路由器组，这个组里面有一个master和多个backup，master上面有一个对外提供服务的网关ip和虚拟mac；master会发送224.0.0.18地址组播报文，当backup收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup作为master对外提供服务。这样的话就可以保证路由器的高可用，对于该路由器组所在局域网内其他主机来说还是相当于一台路由器，它们就可设置静态缺省路由网关为该路由器组ip了。
虚拟mac是虚拟路由器根据虚拟路由器ID生成MA地址，格式为：00-00-5E-00-01-{VRID}，当虚拟路由器回应ARP请求时，使用虚拟MAC地址，而不是接口的真实MAC地址。
对于局域网中的主机，有多种方法可以实现使其知道它的第一跳路由器地址,其中包括：1、运行某种动态路由协议，比如运行RIP或者OSPF； 2、配置静态缺省路由，即配置网关。
采用动态路由协议，由于管理开销、处理开销、安全原因以及在某些平台上不支持等原因而不现实；在实际应用中， 使用配置静态缺省路由， 即在主机配置网关的方法相当普遍， 这种方法具有最小化的配置和运行开销，并且被所有基于IP的应用所支持。但是，这种方法也有缺点， 即增加了单点故障的可能性。 缺省路由器的不可用将带来灾难性的结果： 当缺省路由器失效时， 所有相连的端主机将由于不能检测到可以替换的其他可用路径而造成网络中断。
综合以上两种方法存在的问题，设计产生了虚拟路由器冗余协议（VRRP），采用了静态缺省路由的方法，并且很好的避免了单点故障。协议定义的选举过程提供了一个当负责转发的主路由器失效时，备份路由器可以接替负责转发的动态容错机制。VRRP协议的这一优点使得每一个端主机不用配置任何动态路由协议或者路由发现协议，就可以获得更高的可靠性。
VRRP根据优先级来确定虚拟路由器中每台路由器的角色（Master路由器或Backup路由器）。VRRP优先级的取值范围为0到255（数值越大表明优先级越高），可配置的范围是1到254，优先级0为系统保留给路由器放弃Master位置时候使用，255则是系统保留给IP地址拥有者使用。优先级越高，则越有可能成为Master路由器。当两台优先级相同的路由器同时竞争Master时，比较接口IP地址大小。接口地址大者当选为Master。
1、初始创建的路由器工作在Initialize状态：
通过VRRP报文的交互获知虚拟路由器中其他成员的优先级（keepalived是通过配置文件配置优先级，所以配置定义为MASTER的主机优化级较高），其中优先级最高的成为Master路由器，其他成为Backup路由器；
2、当路由器处于Master状态时，它将会做下列工作：
定期发送VRRP报文。
以虚拟MAC地址响应对虚拟IP地址的ARP请求。
转发目的MAC地址为虚拟MAC地址的IP报文。
如果它是这个虚拟IP地址的拥有者，则接收目的IP地址为这个虚拟IP地址的IP报文。否则，丢弃这个IP报文。
如果收到比自己优先级大的报文则转为Backup状态。
如果收到优先级和自己相同的报文，并且发送端的主IP地址比自己的主IP地址大，则转为Backup状态。
当接收到接口的Shutdown事件时，转为Initialize。
3、当路由器处于Backup状态时，它将会做下列工作：
接收Master发送的VRRP报文，判断Master的状态是否正常。
对虚拟IP地址的ARP请求，不做响应。
丢弃目的MAC地址为虚拟MAC地址的IP报文。
丢弃目的IP地址为虚拟IP地址的IP报文。
Backup状态下如果收到比自己优先级小的报文时，丢弃报文，不重置定时器；如果收到优先级和自己相同的报文，则重置定时器，不进一步比较IP地址。
当Backup接收到MASTER_DOWN_TIMER定时器超时的事件时，才会转为Master。
当接收到接口的Shutdown事件时，转为Initialize。

回归正题，lvs+keepalives架构图如下

lvs+keepalived做多机备份负载均衡，nginx做反向代理

1、安装前准备

本文系统为centos7

停止firewalld

systemctl stop firewalld.service

优化系统内核开启路由跳转

vi /etc/sysctl.conf

##关闭ipv6

net.ipv6.conf.all.disable_ipv6 = 1

net.ipv6.conf.default.disable_ipv6 = 1

##路由转发n

et.ipv4.ip_forward = 1

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

修改selinux

vi /etc/selinux/config 修改selinux为disabled

重启

reboot

2、安装ipvsadm，CentOS7自带安装包，通过yum进行安装。实现系统支持LVS

yum install ipvsadm

本例里面172.16.70.1和172.16.70.2 需要安装

3、安装Keepalived软件

yum -y install keepalived

本例里面172.16.70.1和172.16.70.2 需要安装

4、修改keepalived配置，主一份，从一份，二者不同的地方下面黑体显示

vi /etc/keepalived/keepalived.conf

global_defs {

#notification_email {

# [e-mail]

#}

#notification_email_from [e-mail]

#smtp_server 127.0.0.1

#smtp_connect_timeout 30

router_id LVS_DEVEL

#vrrp_skip_check_adv_addr

#vrrp_strict

#vrrp_garp_interval 0

#vrrp_gna_interval 0

}

vrrp_instance VI_1 {

state MASTER #定义为MASTER主 ,若是从改成BACKUP

interface eth1 #对外访问的网络接口,需是本机的网卡

virtual_router_id 100 #VRID标记(0...255)虚拟路由标识。注意主从要一致

priority 100 #主从优先级，主的优先级要高于从。

advert_int 1 #:广播周期秒数

authentication {

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

172.16.70.100 #:虚拟VIP地址

}

}

virtual_server 172.16.70.100 80 {#:虚拟VIP地址 与 端口，DR架构WEB端口要和虚拟端口监听一致。否则将无法访问

delay_loop 6 #健康检查时间间隔，单位是秒

lb_algo lc #调用算法为LC

lb_kind DR #调用架构模式为DR

#persistence_timeout 50 同一IP 50秒内的请求都发到同个real server

protocol TCP #使用TCP协议

real_server 172.16.70.4 80 {#:真实WEB服务器地址与端口

weight 1 #：转发伐值，越高调用的越多

TCP_CHECK {

connect_timeout 10 #：连接超时为10秒

retry 3 # 重连次数

delay_before_retry 3 #重连间隔时间3秒

connect_port 80 #连接端口为80，要和上面的保持一致

}

}

real_server 172.16.70.5 80 {#:真实WEB服务器地址与端口

weight 1 #：转发伐值，越高调用的越多

TCP_CHECK {

connect_timeout 10 #：连接超时为10秒

retry 3 #重连次数

delay_before_retry 3

connect_port 80 #连接端口为80，要和上面的保持一致

}

}

}

keepalived-1.3.5-6.el7.x86_64
ipvsadm-1.27-7.el7.x86_64

virtual_server 172.16.70.100 80 {
    delay_loop 6
    lb_algo lc
    lb_kind DR
    persistence_timeout 50
    protocol TCP

    sorry_server 172.16.70.200 80

    real_server 172.16.70.4 80 {
        weight 1
        HTTP_GET {
            url {
              path /testurl/test.html
              digest d41d8cd98f00b204e9800998ecf8427e
            }
            url {
              path /testurl2/test.html
              digest d41d8cd98f00b204e9800998ecf8427e
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 172.16.70.5 80 {
        weight 1
        HTTP_GET {
            url {
              path /testurl/test.html
              digest d41d8cd98f00b204e9800998ecf8427e
            }
            url {
              path /testurl2/test.html
              digest d41d8cd98f00b204e9800998ecf8427e
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

5、配置(RealServer)真实服务器虚拟IP
在lvs的DR和TUn模式下，用户的访问请求到达真实服务器后，是直接返回给用户的，而不再经过前端的Director Server，因此，就需要在每个Real server节点上增加虚拟的VIP地址，这样数据才能直接返回给用户，增加VIP地址的操作可以通过创建脚本的方式来实现

本例中172.16.70.4和172.16.70.5需要配置

#vim /etc/init.d/realserver.sh

在文件中输入以下脚本：

#!/bin/bash

SNS_VIP=172.16.70.100

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

　　此操作是在回环设备上绑定了一个虚拟IP地址，并设定其子网掩码为255.255.255.255，与Director Server上的虚拟IP保持互通，然后禁止了本机的ARP请求。

赋予权限

chmod 777 realserver.sh

执行脚本

./realserver.sh start

6、启动keepalived

service keepalived start

查看日志，如果没有出现日志一直在滚动，一般运行算正常了

# tail -50f /var/log/messages

查看lvs状态

#ipvsadm -Ln

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

TCP 172.16.70.100:80 rr

-> 172.16.70.4:80 Route 1 0 0

-> 172.16.70.5:80 Route 1 0 0

 nginx只是做反向代理，这里就不介绍了，都配置好了直接访问虚拟地址就可以测试了