Lvs+Ldirectord+Heartbeat

一.LVS基础

1.lvs先知


(1)从下图可以看出lpvs是工作在内核层,我们不能够直接操作ipvs,vs负载均衡调度技术是在linux内核中实现的。因此,被称之为linux虚拟服务器。我们使用该软件配置lvs的时候,不能直接配置内核中的ipvs,而需要使用ipvs的管理工具ipvsadm进行管理
这里写图片描述


(2)原理
客户请发送向负载均衡服务器发送请求。负载均衡器接受客户的请求,然后先是根据LVS的调度算法(8种)来决定要将这个请求发送给哪个节点服务器。然后依据自己的工作模式(3种)来看应该如何把这些客户的请求如何发送给节点服务器,节点服务器又应该如何来把响应数据包发回给客户端。
这里写图片描述


2.三种工作模式


(1)NAT模式-网络地址转换


这个是通过网络地址转换的方法来实现调度的。首先调度器(LB)接收到客户的请求数据包时(请求的目的IP为VIP),根据调度算法决定将请求发送给哪个后端的真实服务器(RS)。然后调度就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址(RIP),这样真实服务器(RS)就能够接收到客户的请求数据包了。真实服务器响应完请求后,查看默认路由(NAT模式下我们需要把RS的默认路由设置为LB服务器。)把响应后的数据包发送给LB,LB再接收到响应包后,把包的源地址改成虚拟地址(VIP)然后发送回给客户端。


调度过程IP包详细图:
这里写图片描述


原理图简述:
1)客户端请求数据,目标IP为VIP
2)请求数据到达LB服务器,LB根据调度算法将目的地址修改为RIP地址及对应端口(此RIP地址是根据调度算法得出的。)并在连接HASH表中记录下这个连接。
3)数据包从LB服务器到达RS服务器realserver,然后realserver进行响应。realserver的网关必须是LB,然后将数据返回给LB服务器。
4)收到RS的返回后的数据,根据连接HASH表修改源地址VIP&目标地址CIP,及对应端口80.然后数据就从LB出发到达客户端。
5)客户端收到的就只能看到VIP\DIP信息。


NAT模式优缺点:
1、NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写,因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈,一般要求最多之能10-20台节点
2、只需要在LB上配置一个公网IP地址就可以了。
3、每台内部的节点服务器的网关地址必须是调度器LB的内网地址。
4、NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。


(2)TUN模式


采用NAT模式时,由于请求和响应的报文必须通过调度器地址重写,当客户请求越来越多时,调度器处理能力将成为瓶颈。为了解决这个问题,调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文,由于一般网络服务应答数据比请求报文大很多,采用VS/TUN模式后,集群系统的最大吞吐量可以提高10倍。
VS/TUN的工作流程图如下所示,它和NAT模式不同的是,它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP tunnel里面,然后发送给RS节点服务器,节点服务器接收到之后先将报文解封获得原来目标地址为 VIP 的报文,服务器发现VIP地址被配置在本地的IP隧道设备上,所以就处理这个请求,进行响应处理。并且直接把包通过自己的外网地址发送给客户不用经过LB服务器。


原理流程图
这里写图片描述


原理图过程简述:
1)客户请求数据包,目标地址VIP发送到LB上。
2)LB接收到客户请求包,进行IP Tunnel封装。即在原有的包头加上IP Tunnel的包头。然后发送出去。
3)RS节点服务器根据IP Tunnel包头信息(此时就又一种逻辑上的隐形隧道,只有LB和RS之间懂)收到请求包,然后解开IP Tunnel包头信息,得到客户的请求包并进行响应处理。
4)响应处理完毕之后,RS服务器使用自己的出公网的线路,将这个响应数据包发送给客户端。源IP地址还是VIP地址。(RS节点服务器需要在本地回环接口配置VIP,后续会讲)


TUN模式优缺点:
缺点:由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议。所以,在RS的内核中,必须编译支持IPTUNNEL这个选项
优点:负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户。所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,就能处理很巨大的请求量,这种方式,一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。


(3)DR模式


DR模式是通过改写请求报文的目标MAC地址,将请求发给真实服务器的,而真实服务器响应后的处理结果直接返回给客户端用户。同TUN模式一样,DR模式可以极大的提高集群系统的伸缩性。而且DR模式没有IP隧道的开销,对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器LB与真实服务器RS都有一块网卡连接到同一物理网段上,必须在同一个局域网环境。


原理流程图:
这里写图片描述


DR模式原理过程简述:
VS/DR模式的工作流程图如上图所示,它的连接调度和管理与NAT和TUN中的一样,它的报文转发方法和前两种不同。DR模式将报文直接路由给目标真实服务器。在DR模式中,调度器根据各个真实服务器的负载情况,动态地选择一台服务器,不修改目标IP地址和目标端口,也不封装IP报文,而是将请求报文的数据帧的目标MAC地址改为真实服务器的MAC地址。然后再将修改的数据帧在服务器组的局域网上发送。因为数据帧的MAC地址是真实服务器的MAC地址,并且又在同一个局域网。那么根据局域网的通讯原理,真实服务器是一定能够收到由LB发出的数据包。真实服务器接收到请求数据包的时候,解开IP包头查看到的目标IP是VIP。(此时只有自己的IP符合目标IP才会接收进来,所以我们需要在本地的回环借口上面配置VIP。另:由于网络接口都会进行ARP广播响应,但集群的其他机器都有这个VIP的lo接口,都响应就会冲突。所以我们需要把真实服务器的lo接口的ARP响应关闭掉。)然后真实服务器做成请求响应,之后根据自己的路由信息将这个响应数据包发送回给客户,并且源IP地址还是VIP。
DR模式小结:
1、通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP,目的地址仍然是VIP地址。
2、请求的报文经过调度器,而RS响应处理后的报文无需经过调度器LB,因此并发访问量大时使用效率很高(和NAT模式比)
3、因为DR模式是通过MAC地址改写机制实现转发,因此所有RS节点和调度器LB只能在一个局域网里面
4、RS主机需要绑定VIP地址在LO接口上,并且需要配置ARP抑制
5、RS节点的默认网关不需要配置成LB,而是直接配置为上级路由的网关,能让RS直接出网就可以
6、由于DR模式的调度器仅做MAC地址的改写,所以调度器LB就不能改写目标端口,那么RS服务器就得使用和VIP相同的端口提供服务。


DR模式优缺点:
优点:和TUN(隧道模式)一样,负载均衡器也只是分发请求,应答包通过单独的路由方法返回给客户端。与VS-TUN相比,VS-DR这种实现方式不需要隧道结构,因此可以使用大多数操作系统做为物理服务器。

缺点:(不能说缺点,只能说是不足)要求负载均衡器的网卡必须与物理网卡在一个物理段上


3.八种算法


LVS已实现了以下八种调度算法:

LVS负载均衡算法—1.轮叫调度(Round-RobinScheduling)

  调度器通过”轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。


LVS负载均衡算法—2.加权轮叫调度(WeightedRound-RobinScheduling)

  调度器通过”加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。


LVS负载均衡算法—3.最小连接调度(Least-ConnectionScheduling)

  调度器通过”最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用”最小连接”调度算法可以较好地均衡负载。


LVS负载均衡算法—4.加权最小连接调度(WeightedLeast-ConnectionScheduling)

  在集群系统中的服务器性能差异较大的情况下,调度器采用”加权最少链接”调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值


LVS负载均衡算法—5.基于局部性的最少链接(Locality-BasedLeastConnectionsScheduling)

  基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用”最少链接”的原则选出一个可用的服务器,将请求发送到该服务器。


LVS负载均衡算法—6.带复制的基于局部性最少链接(Locality-BasedLeastConnectionswithReplicationScheduling)

  带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组,按”最小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器,若服务器超载;则按”最小连接”原则从这个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度


LVS负载均衡算法—7.目标地址散列调度(DestinationHashingScheduling)

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


LVS负载均衡算法—8.源地址散列调度(SourceHashingScheduling)

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


二.LVS配置(DR模式)


LB :serve2 172.25.254.2
realserver : server3 172.25.254.3
server4 172.25.254.4


1.LB配置


(1)安装ipvsadm工具
这里写图片描述


(2)添加VIP 172.25.254.100
这里写图片描述


(3)配置策略
选择轮询算法
这里写图片描述


后端realserver
这里写图片描述


保存查看,用ipvsadm -ln 查看
这里写图片描述


/etc/init.d/ipvsadm restart 重启,然后查看,策略写在文件/etc/sysconfig/ipvsadm中

这里写图片描述


2.realserver配置(两台server配置基本一致)
方便起见,后端两台服务器的index.html文件分别为server3 ,server4


(1)后台负载均衡服务为http,所以要开启(记得有index.html文件),并安装arptables-jf,配置策略,并保存
这里写图片描述
这里写图片描述


(2)添加VIP
这里写图片描述


(3)另一台realserver,server4配置与以上server3基本一致,除了在策略有些许不一致(开启http,添加vip,配置策略)
这里写图片描述
这里写图片描述


3.测试及故障分析


(1)在真机172.25.254.7上进行测试
这里写图片描述


(2)当某一RS(server3)上没有VIP时,因为没有健康检查,测试时会卡在此处
这里写图片描述

这里写图片描述


(3)当某一RS(server3)上http服务没有开启时,测试时会显示无法连接,通过ipvsadm -Ln也可以查看后端调用情况
这里写图片描述

这里写图片描述

这里写图片描述


三.Ldirectord健康检查


由以上lvs的故障分析可以看出,没有健康检查,很容易造成后端负载均衡的失败,所以需要健康检查。
ldirectord守护进程通过向每台真实服务器真实IP(RIP)上的集群资源发送访问请求来实现对真实服务器的监控**一旦real server的相关服务死掉,或者网卡坏掉的话,调度器将不会再将客户的请求定向到该real server上。


**注意:ldirectord实验的前提:后端与lvs配置一致
调度器上的/etc/init.d/ipvsadm stop ,因为在下面的配置文件中设置了VIP,以及realserver(其他与lvs一致,仍需手动添加vip,手动开启http)
这里写图片描述


1.安装配置
(1)安装,从/etc/init.d/ldirectord脚本文件中发现需要将配置文件ldirectord.cf放到/etc/ha.d/下
这里写图片描述

这里写图片描述


(2)查看ldirectord的文件,将配置文件拷贝到/etc/ha.d/下
这里写图片描述

这里写图片描述


(3)更改配置文件vim /etc/ha.d/ldirectord.cf,之后重启
这里设置vip,以及RS,后端服务为http,算法为rr,fallback设置
这里写图片描述

这里写图片描述


2.测试
(1)正常测试
这里写图片描述

这里写图片描述


(2)server3关闭http服务,可以只调用server4,而不会像lvs中,会显示连接拒绝

这里写图片描述

这里写图片描述

这里写图片描述


(3)若另一台server4也关掉服务,可调用调度器自己的http服务(此时调度器本身需要开启http,以及手动添加vip),之后若恢复server3服务,则只调用server3
这里写图片描述

这里写图片描述

这里写图片描述

这里写图片描述

这里写图片描述


四.Heartbeat高可用


此高可用在server2与server5之间,后端依然是server3 和server4
前提:调度器上ldirectord,http关掉,vip也要删掉(因为这属于资源,文件中会设置,高可用就要实现资源的自动转移)


1.安装,将三个文件拷贝到/etc/ha.d/下
这里写图片描述

这里写图片描述
这里写图片描述

这里写图片描述


2.更改文件vim /etc/ha.d/ha.cf
用于syslog()/logger的设备
这里写图片描述


心跳频率,自己设定。1:表示1秒;200ms:表示200毫秒
这里写图片描述


发出警告时间,自己设定
这里写图片描述


节点死亡时间阀值,就是从节点在过了10后还没有收到心跳就认为主节点死亡,自己设定
这里写图片描述


在某些配置下,重启后网络需要一些时间才能正常工作。这个单独的”deadtime”选项可以处理这种情况。它的取值至少应该为通常deadtime的两倍。
这里写图片描述


心跳信息传递的udp端口,自己设定
这里写图片描述


心跳所使用的网络接口
这里写图片描述


主节点重启成功后,资源是自动拿回到主节点还是等到副节点down调后拿回资源
这里写图片描述


主节点名称,与uname –n保持一致。排在第一的默认为主节点
这里写图片描述


伪节点IP,如果节点与此不通,则不能接收资源
这里写图片描述


注意64位
这里写图片描述

设置所指定的启动进程的权限
这里写图片描述


3.vim /etc/ha.d/authkey,要求600权限,加密算法选第一种
这里写图片描述
这里写图片描述

这里写图片描述


4.vim /etc/ha.d/haresource,设定资源(vip,ldirectord,http)

这里写图片描述


5.另一台调度器server5的配置与server2完全一致,只需安装,把文件拷贝过去即可
这里写图片描述

这里写图片描述
这里写图片描述

两台调度器上记得开启heartbaet /etc/init.d/heartbeat start

3.测试
1.正常测试(可能刚开始要反应一会,才会将资源切到一台调度器上),使用的是server2
这里写图片描述

这里写图片描述


2.server2的网卡断掉,切到server5上
这里写图片描述

这里写图片描述

这里写图片描述


3.主节点server上ifup eth1,并开启heartbest后,会自动回切到server2上

这里写图片描述

这里写图片描述

这里写图片描述


4.可以看出资源均是与heartbeat保持一致的,当资源不在server2上时,http就会自动关闭

这里写图片描述

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值