Enterprise load balancing (weighting) at the polling scheduler --DR LVS cluster mode, health monitoring (the ldirectord) in the DR mode

A direct routing mode of LVS (DR Mode)

Principle 1, DR mode

Lvs structures in a host server above, the operation mode is set lvs DR model, lvs just a scheduler , the scheduler will forward the request to the backend server client, the DR modeDirectly to the data returned by the back-end server to the client does not need to transmit the reverse packet data, scheduling can only focus LVS, highly efficientAt this time lvs scheduler called the DS scheduler (Director Server) , RS is the real back-end web server (real server).

• Client sends a request -> the DS (Scheduler) -> prerouting -> INPUT - > postrouting -> RS ( real server) -> LO loopback -> NIC eth0 -> Client ( explained in detail )
• Data communication within the system using a loopback interface, the exchange with the outside using the card eth0
• DR mode efficient in that: RS server will respond directly to the client's request, the request sent straight to send packets, the reverse will not return data packet to the scheduler.

2, DR mode Glossary

• Source MAC address : MAC address of DS scheduler
• Destination MAC address : MAC address of the real server RS

3, the characteristics of the DR mode

• DR mode all request packets are scheduled by a scheduler (DS) of, the DS only process incoming requests, in response to the request performed by RS.
• RIP and the RS, DS DIP must be in the same network segment, a MAC address to use for communication.
• Must be configured VIP on RS (VIP: Unified inlet disposed, announced the IP, the client requests coming ip) address to receive DS forwarded over the packet, as well as the CIP (response packet source IP: Client IP)
• DR mode does not support port mapping
• DR mode change is the MAC address, the MAC address of the second layer (data link layer) yet to the network layer where the IP, may be connected to someone maliciously, has a packet to send back-end servers, does not poll, leading to the back-end server to its knees, but it can be resolved.

4, LVS scheduler in the DR mode (Round Robin)

lab environment ：

Host Information	Host function (service)
Real machine 172.25.7.250	Client client
server1(172.25.7.1)	lvs scheduler (DS)
server2(172.25.7.2)	Backend web server 1 (RS)
server3(172.25.7.3)	Backend web server 2 (RS)

1、server1: Lvs scheduler
tool installation services write strategy ipvsadmyum install ipvsadm -y

• Note: If the source is the 6.5 version of yum, yum need to build load-balanced source can install this service

2、ipvsadm -LnLists the policy (see scheduling policy)
3, add a policy:

• Note: -s indicates scheduling algorithm, rr denotes polling, -g indicates lvs scheduler works in the DR mode
• ipvsadm --help seen, a total of 10 scheduling algorithm ( Comments )

ipvsadm -A -t 172.25.7.100:80 -s rr 
		#设置客户端进入lvs调度器的入口地址，调度算法是轮询
ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.2:80 -g 
		# 设置lvs的策略：入口的第一台后端服务器的信息
ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.3:80 -g
		# 设置lvs的策略：入口的第二台后端服务器的信息
      

4、ipvsadm -LnLists Add Policy (see scheduling policy)
5, to the scheduler to add VIP:ip addr add 172.25.7.100/24 dev eth0

6, the two RS: on server2, server3, the VIP configuration, and is mounted httpd service
installation httpd:yum install httpd -y
Configuring user access entry address: ip addr add 172.25.7.100/32 dev eth0

• 注意：子网掩码为32是因为这个ip不对外，只有自己用
• 在两RS上设置用户访问的入口地址的原因：为了RS（后端web服务器）可以直接给客户端发送资源，不需要再返回给调度器，因为客户端访问的是入口地址，如果不使用入口地址给客户发送资源，客户端可能不会接收这个数据包。如果直接在客户端curl 172.25.7.100发现客户端要不到资源。因为DR工作模式是：client->lvs->rs->client， 由后端服务器端直接送回资源给客户端，但是客户端问172.25.7.100要的资源，后端服务器直接把资源给客户端，客户端不会识别 ，因此要在两个后端服务器上面设置入口地址。
  
  

7、在两台RS：server2、server3 上 ，编写共享页面

server2

server3

8、在两台RS：server2、server3 上，开启httpd服务

9、在LVS服务器上，查看调度策略

ipvsadm -l #  做解析，慢
ipvsadm -nl #  不做解析，快

10、 在真机上测试：curl 172.25.7.100 在真机上测试，发现客户端发出请求，通过调度器访问web资源的时候，会一直向同一个web服务器（server3）要资源，并 没有实现轮询。

arp -an | grep 172.25.7.100 , 可以看到默认缓存的是server3的mac地址

11、arp -d 172.25.7.100 清除缓存 再次测试，没有实现轮询。

• 注意：此时客户端访问资源有时候轮询，有时候不轮询，出现这样的现象是为什么呢？

因为DR模式是通过 修改MAC地址 进行访问的，调度器和两台web服务器上都有172.25.7.100这个入口地址VIP，所以客户端在请求的时候，三台虚拟机都有可能回复请求，客户端会记录回复他的那台虚拟机的mac地址，所以下次在访问的时候他会找记录过的mac地址对应的虚拟机（有可能是真实的服务器）直接访问，这在现实中是 不允许 的，因为 如果请求全部发往后端某一台真正的服务器的话，这台服务器会因为压力过大而宕机。而且，直接访问后端的真正的服务器，我们的server1（LVS调度器）也就没有起到作用，并没有实现真正意义上的负载均衡，这也是DR模式的一个缺点。这就类似于DDOS攻击，有可能会导致后端服务器瘫痪，造成用户不能正常访问资源。

现在解决DR模式不轮询的问题：

• 因为客户端第一次访问172.25.7.100的时候server1,server2,server3均可以接收客户端的请求，这个是随机的，有可能不会经过lvs调度器，客户端直接问web服务器要资源。 在两个web后端上进行设置，防止ddos攻击。

方法一：添加arptable策略解决

12、在 server2 上，安装针对MAC地址的防火墙管理工具 yum install -y arptables

• arptables：用户空间工具,用来 管理 linux内核中的ARP规则表. 这些规则用来检查ARP帧.arptables类似于iptables,但没有那么复杂.iptables工作于ip层,用于对ip包进行管理.arptables工作与arp协议层,用于对arp数据帧进行管理.arptables可以像iptables那样对arp数据帧进行各种规则设置,可以ACCEPT,DROP等
• arptables -nL 可查看设置的访问规则
• man arptable 可查看设置规则

13、设置规则：

arptables -A INPUT -d 172.25.7.100 -j DROP		
		##添加策略，让目的地址为172.25.7.100的访问不能到达RS，丢弃客户端的直接访问
		## -d, --destination [!] address[/mask]目的地址
		## -j, --jump target跳到目标

arptables -A OUTPUT -s 172.25.7.100 -j mangle --mangle-ip-s 172.25.7.2	
		##让返回的数据来自server2  172.25.7.2使自己以172.25.7.100的身份发送资源给客户端
cat /etc/sysconfig/arptables                #查看规则
arptables-save > /etc/sysconfig/arptables	#保存策略
cat /etc/sysconfig/arptables                #再次查看
systemctl start arptables.service           #重启服务
systemctl status arptables.service

server3（后端服务器）同理

此时，server2和server3不会接受客户端的请求了，每次客户端的访问只能由LVS调度器接受，即每次客户端只能通过lvs调度器去找web1和web2服务

14、在真机上测试：curl 172.25.7.100 实现了轮询。

当客户端（172.25.7.250）发送数据包给LVS调度器（172.25.7.100） 的时候（源地址172.25.7.250——>>目的地址172.25.7.100）,此时LVS会将源MAC地址变为LVS服务器的MAC地址，将目的MAC地址变为web服务器的MAC地址，然后就实现调度了.直接去找目标MAC地址，然后找web服务器，web服务器直接将数据返回给客户端（IP地址全程不变）

方法二 ： 配置内核参数

• arp_ignore 和 arp_announce 参数都和 ARP协议 相关，主要 用于控制系统返回arp响应和发送arp请求时的动作。这两个参数很重要，特别是在LVS的DR场景下，它们的配置直接影响到DR转发是否正常。
• arp_ignore参数的作用：控制系统在收到外部的arp请求时，是否要返回arp响应。1：只响应目的IP地址为接收网卡上的本地地址的arp请求
• arp_announce的作用：控制系统在对外发送arp请求时，如何选择arp请求数据包的源IP地址。2：忽略IP数据包的源IP地址，选择该发送网卡上最合适的本地地址作为arp请求的源IP地址

net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2


sysctl -p

5、DR模式下的LVS调度器（加权轮询算法）

在轮询算法LVS调度器的基础上，更改调度策略：

1、ipvsadm -C 清空策略
2、 添加策略：

ipvsadm -A -t 172.25.7.100:80 -s wrr 
		#设置客户端进入lvs调度器的入口地址，调度算法是加权轮询
ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.2:80 -g -w 1
		# 设置lvs的策略：入口的第一台后端服务器的信息，加权为1
ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.3:80 -g -w 2
		# 设置lvs的策略：入口的第二台后端服务器的信息，加权为2
      

3、arp -d 172.25.7.100 清除缓存 再次测试，实现了加权轮询

二、DR模式下的健康检测（Idirectord）

• ldirectord对lvs策略的动态维护：ldirectord是监视集群节点(真实服务器)，并从集群中自动移除节点，我们需要使用ldirectord程序，这个程序在启动时自动建立IPVS表(不用手动建立了)，然后监视集群节点的健康情况，在发现失效节点时将其自动从IPVS表中移除。

背景 ： 之前DR模式下的LVS，我们都是假设后端服务器是可以正常工作。但对于一台后端服务器来说，它不可能永远是可以使用的，有自己的寿命或者会出现其它问题。当lvs集群中的一台后备服务器挂了之后，为了不影响客户的正常访问，应该将它从集群当中踢出去，让客户不再轮询访问。

模拟问题 ：关闭server2的httpd服务，一个web挂了，会影响客户的访问。

现在使用ldirectord这个插件可以解决此问题。

1、在 LVS调度器 （server1）上， 配置 高可用的yum源

2、从真机得到 ldirectord-3.9.5-3.1.x86_64.rpm

3、安装此插件： yum install -y ldirectord-3.9.5-3.1.x86_64.rpm

4、rpm -qpl ldirectord-3.9.5-3.1.x86_64.rpm 查看配置文件的路径

5、cp /usr/share/doc/ldirectord-3.9.5/ldirectord.cf /etc/ha.d

6、vim /etc/ha.d/ldirectord.cf 编辑设置信息

virtual=172.25.7.100:80
        real=172.25.7.2:80 gate			##两个后端rs
        real=172.25.7.3:80 gate
        fallback=127.0.0.1:80 gate		##两个rs都挂了，就访问调度器自己的80端口
        service=http
        scheduler=rr				##轮询算法
        #persistent=600
        #netmask=255.255.255.255
        protocol=tcp
        checktype=negotiate
        checkport=80
        request="index.html"
        #receive="Test Page"
        #virtualhost=www.x.y.z

7、更改策略为：轮询算法

8、开启服务：systemctl start ldirectord

• 在企业6中， /etc/init.d/ldirectord start脚本方式启动服务

9、在客户端测试：

1）server2和server3都正常时，轮询。

2） 模拟server2挂掉, To find out whether this server is removed from IPVS table, as well as the entire contents of the client test from server3

10, in the case where server2 and server3 are hung up,LVS scheduler can also be used as a staging server, but generally a very short time.

yum install -y httpd