LVS + KEEPALIVED + WINDOWS SERVER 2008 R2 ------高可用负载均衡

环境:
192.168.1.1  GateWay
192.168.1.10  LVS_VIP(VIP:Virtual IP)
192.168.1.14  LVS_Master       
192.168.1.15  LVS_Backup
192.168.1.16  WEB1_RealServer
192.168.1.17  WEB2_RealServer

LINUX(CentOS 5.6)配置

1. 安装CentOS(此处我使用的版本为:CentOS-5.6-x86_64)
2. 安装IPVSADM
    知识点:IPVSADM理解为IPVS管理工具;LVS(Linux Virtual Server)的核心为IPVS(IP Virtual Server),从Linux内核版本2.6起,IPVS模块已经编译进了Linux内核。   
    > 使用yum命令进行安装,系统会选择最适合内核版本的ipvsadm
       yum -y install ipvsadm
3. 配置(使用KeepAlived时,此步可省略,因为KeepAlived提供了更简单的配置方式来实现负载均衡。不过仍然建议使用此种方式配置一遍。)
    > ifconfig eth0:0 192.168.1.10 broadcast 192.168.1.10 netmask 255.255.255.255 up
    > route add -host 192.168.1.10 dev eth0:0
    > ipvsadm -A -t 192.168.1.10:80 -s wrr
    > ipvsadm -a -t 192.168.1.10:80 -r 192.168.1.16:80 -g
    > ipvsadm -a -t 192.168.1.10:80 -r 192.168.1.17:80 -g
4. 防火墙设置
    > service iptables stop
    或 在防火墙规则表中加入一条记录
    > vi /etc/sysconfig/iptables
    > -A RH-Firewall-1-INPUT -m state --state NEW -m -tcp -p tcp --dport 80 -j ACCEPT
    > service iptables restart

WINDOWS 2008 SERVER R2 配置

1. 创建windows环回网卡(如何创建,请自己Google)
2. 设置环回网卡IP地址
    > IP地址:    192.168.1.10
    > 子网掩码: 255.255.255.255
    其它不用设置了
3. 修改客户端网卡接口、环回接口连接模式(至关重要)
    > netsh interface ipv4 set interface "网卡名称" weakhostreceive=enabled
    > netsh interface ipv4 set interface "网卡名称" weakhostsend=enabled
    > netsh interface ipv4 set interface "环回网卡名称" weakhostreceive=enabled
    > netsh interface ipv4 set interface "环回网卡名称" weakhostsend=enabled

接下来,我们在浏览器地址栏中输入 http://192.168.1.10,你会发现你的访问请求被转移到了192.168.1.16或192.168.1.17,这时我们尝试停掉其中任何一台服务器,你再来访问 http://192.168.1.10,你会发现有时正常,有时不正常。原因很简单,因为其中一台机器被你停掉了,但是IPVS无法发现这种错误,所以还是会把请求均衡负载到当初配置的真实服务器列表中;针对这种问题,我们该如何来解决呢?此时该是KEEPALIVED登场的时候了!

KEEPALIVED 配置

知识点:KeepAlived是一个路由软件,它主要的目的是让我们通过简单的配置,实现高可用负载均衡,当然负载均衡依赖于Linux虚拟服务器(IPVS)的内核模块,其高可用性
           使用VRRP协议来实现,KeepAlived不仅会检测负载均衡服务器池中每台机器的健康状况并通知IPVS将非健康的机器从池中移除掉;同时它还能对负载均衡调度器本身
           实现健康状态检查,当主负载均衡调度器出现问题时,备用负载均衡调度器顶替主进行工作。
1. 安装KeepAlived(KeepAlived依赖openssl,所以在安装KeepAlived之前需要先安装openssl)
    > yum -y install openssl-devel
    > wget http://www.keepalived.org/software/keepalived-1.2.7.tar.gz(KeepAlived版本大家自己去 http://www.keepalived.org 上查看,下载最新版本即可)
    > tar zxvf keepalived-1.2.7.tar.gz
    > cd keepalived-1.2.7
    > ./configure -prefix=/usr/local/keepalived
    > make && make install
2. 配置KeepAlived
    The First:打开IP Forward 功能(LVS现有三种负载均衡规则都需要打开此功能,如果不打开此功能,下面的配置配得再好都无济于事。)
    > vi /etc/sysctl.conf
    > net.ipv4.ip_forward = 1
    > sysctl -p(使设置立即生效)
    KeepAlived配置分三部分
    > 全局定义块--global_defs
       . 不建议使用email通知,改用nagios来进行监控
       . router_id:负载均衡器标识。在一个网络内,它应该是唯一的。
    > VRRP定义块--vrrp_instance
       . state
                 均衡器状态。只有MASTER和BACKUP两种状态,并且需要大写这些单词;其中MASTER为工作状态,BACKUP为备用状态;当MASTER所在服务器
                 失效时,BACKUP所在系统会自动把它的状态由BACKUP变为MASTER;当失效的MASTER所在系统恢复时,BACKUP从MASTER恢复到BACKUP状态。
       . interface
                 对外提供服务的网络接口,如eth0,eth1;当前的主流服务器一般都有2个或2个以上的接口,在选择服务接口时,一定要核实清楚。
       . virtual_router_id
                 这个标识是个数字,并且同一个VRRP实例使用唯一的标识。即同一个vrrp_instance,MASTER和BACKUP的virtual_router_id是一致的。 
       . priority
                 优先级。这个标识也是个数字,数值越大,优先级越高;在同一个vrrp_instance里,MASTER的优先级高于BACKUP。
       . advert_int
                 同步通知间隔。MASTER与BACKUP负载均衡器之间同步检查的时间间隔,单位为秒。
       . authentication
                 验证。包含验证类型和验证密码。类型主要有PASS、AH两种,通常使用PASS类型,据说AH使用时有问题;验证密码为明文,同一个vrrp_instance
                 实例MASTER与BACKUP使用相同的密码才能正常通信。
       . virtual_ipaddress
                 虚拟IP地址。可以有多个地址,每个地址占一行。
    > 虚拟服务器定义块--virtual_server
       . delay_loop
                  健康检查时间间隔,单位为秒。
       . lb_algo
                  负载均衡调度算法(rr、wrr、dh、sh、lc、wlc、sed、nq、lblc、lblcr)。
                  算法分两大类:静态算法、动态算法
                  静态算法:只是根据算法进行调度并不考虑后端REALSERVER的实际连接情况
                  ---- rr(轮叫调度 - Round-Robin Scheduling)
                        调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数
                        和系统负载。
                  ---- wrr(加权轮叫调度 - Weighted Round-Robin Scheduling)
                        调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调
                        度器可以自动问询真实服务器的负载情况,并动态地调整其权值 
                  ---- dh(目标地址散列调度 - Destination Hashing Scheduling)
                        "目标地址散列"调度算法根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且
                        未超载,将请求发送到该服务器,否则返回空。
                  ---- sh(源地址散列调度 - Source Hashing Scheduling)
                        "源地址散列"调度算法根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超
                        载,将请求发送到该服务器,否则返回空。
                  动态算法:前端的调度器会根据后端REALSERVER的实际连接情况来分配请求
                  ---- lc(最小连接调度 - Least-Connection Scheduling)
                        当一个用户请求过来的时候,就计算下哪台RS的链接谁最小,那么这台RS就获得了下次响应客户端请求的机会,计算的方法
                        Overhead=active*256+inactive,如果两者的结果是相同的则从LVS中的规则依次往下选择RS。这种算法也是不考虑服务器的性能的。
                  ---- wlc(加权最小连接调度 - Weighted Least-Connection Scheduling)
                        这个就是加了权重的LC,考虑了RS的性能,即是性能好的就给的权重值大一些,不好的给的权重值小一些。缺点就是如果Overhead相同,
                        则会按规则表中的顺序,由上而下选择RS,Overhead=(active*256+inactive)/weight
                  ---- sed(最短预期延时调度 - Shortest Expected Delay Scheduling)
                        就是对WLC的情况的补充,Overhead=(active+1)*256/weight,加一,就是为了让其能够比较出大小。
                  ---- nq(不排队调度 - Never Queue Scheduling)
                        never queue 基本和SED相同,避免了SED当中的性能差的服务器长时间被空闲的弊端,它是第一个请求给性能好的服务器,第二个请求
                        一定是给的空闲服务器不论它的性能的好与坏。以后还是会把请求给性能好的服务器
                  ---- lblc(基于局部性的最少链接 - Locality-Based Least Connections Scheduling)
                        它就是动态DH和LC的组合,适用于cache群,对于从来没有来过的那些新的请求会分给当前连接数较少的那台服务器。
                  ---- lblcr(带复制的基于局部性最少链接 - Locality-Based Least Connections with Replication Scheduling)
                        带有复制功能的LBLC,它的适用场景这里举例说明一下,比如说现在有RS1和RS2,第一次访问RS1的5个请求第二次又来了,理所应到
                        Director将会将其交给RS1,而此时在RS2是非常闲的,所以此时最好的处理方法就是可以将后来的这5个请求分别交给RS1和RS2,所以
                        此时就需要把客户端第一次请求的资源复制下来。(特殊情况)
                  小解:活动链接active和非活动链接inactive
                  这里以http为例,http本身是一种无状态的链接,当客户端请求访问的时候,有个等待响应过程,这个时段可以称其为活动链接active状态。
                  当服务器端给与响应后,请求因为keepalive而并未断开,则此段时间的状态就是非活动链接状态。
       . lb_kind
                  负载均衡转发规则(DR、NET、TUN),常用DR。
       . persistence_timeout
                  会话保持时间,单位是秒。这个选项对动态网站很有用处,当用户用账号登录网站时,有了这个会话保持功能,就能把用户的请求转发给同一个应用服务
                  器。在这里,我们来做一个假设,假定现在有一个LVS环境,使用DR转发模式,真实服务器有3台,如果负载均衡器不启用会话保持功能,当用户第一次
                  访问的时候,他的访问请求分发给某个真实服务器,这样他看到一个登录页面,第一次访问完毕;接着他在登录框填写用户名和密码,然后提交,这个时
                  候,问题就可能出现了:登录不成功,因为没有会话保持,负载均衡器可能把第2次的请求转发到其它服务器。
       . protocol
                  转发协议。一般有TCP和UDP两种,UDP没尝试过。
       . real_server
                  真实服务器,也即服务器词。real_server的值包括IP和端口。
                  * weight
                             权重值,它是一个数字,数值越大,权重越高。使用不同的权重值的目的在于为不同性能的机器分配不同的负载。
                  * tcp_check
                             TCP方式检查机器健康状态
    我这里把我配好的截图给大家看看(包含负载均衡器的高可用)
    MASTER:
    
    
    
    BACKUP:
    
    
    
    MASTER与BACKUP配置仅三处不同:global_defs中的router_id、vrrp_instance中的state、priority
3. 启动KeepAlived
    /usr/local/keepalived/sbin/keepalived -D
    此处需要注意:KeepAlived默认会去/etc/keepalived下面找它的配置文件,要么你将keepalived.conf文件copy到该目录下,要么在启动时带上 -f 参数来指
    定keepalived.conf文件位置。
4. 到这里,KeepAlived就安装成功了!接下来我们可以使用一些命令来检查一下。
    > 查看进程:ps aux | grep keepalived
       Keepalived正常运行时,共启动3个进程,其中一个进程是父进程,负责监控其子进程;一个是vrrp子进程;另外一个是checkers子进程。
       我们也可以通过命令(pstree | grep keepalived)查看进程相关性来验证上面的说法
    > 查看日志:tail -f /var/log/messages
    > 查看请求转发情况:ipvsadm -lcn | grep 虚拟IP
5. 优化。
    最后,我们需要做一下优化,那就是将KeepAlived做成服务,随机启动,这样我们就免去了每次手动去启动的麻烦
    将KeepAlived加入系统服务
    > ln -s /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/rc.d/init.d/ 
    > ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
    > mkdir /etc/keepalived
    > ln -s /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/
    > ln -s /usr/local/keepalived/sbin/keepalived /usr/sbin/  
    设置KeepAlived系统服务随机启动
    > chkconfig --add keepalived
    > chkconfig keepalived on
    > 查看:chkconfig --list keepalived

到这里,整个配置就完成了,最后我们尝试关闭Master机器或Master上的keepalived服务,看看Backup机器是否会代替Master来工作。

滚动至顶部