标签：LB 运维 LVS -- IP 24.100 调度 172.25 服务器
Linux企业化运维
实验所用系统为Redhat-rhel7.6。
目录
Linux企业化运维–(9)LVS负载均衡之DR模型
一、LVS
1、概述
LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统,使用负载均衡技术将多台服务器组成一个虚拟服务器。它为适应快速增长的网络访问需求提供了一个负载能力易于扩展，而价格低廉的解决方案。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。Internet的快速增长使多媒体网络服务器面对的访问数量快速增加，服务器需要具备提供大量并发访问服务的能力，因此对于大负载的服务器来讲， CPU、I/O处理能力很快会成为瓶颈。由于单台服务器的性能总是有限的，简单的提高硬件性能并不能真正解决这个问题。为此，必须采用多服务器和负载均衡技术才能满足大量并发访问的需要。
2、结构
针对高可伸缩、高可用网络服务的需求，我们给出了基于IP层和基于内容请求分发的负载平衡调度解决方法，并在Linux内核中实现了这些方法，将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器。
虚拟服务器的体系结构如下图所示，一组服务器通过高速的局域网或者地理分布的广域网相互连接，在它们的前端有一个负载调度器（Load Balancer）。负载调度器能无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访问一台高性能、高可用的服务器一样。客户程序不受服务器集群的影响不需作任何修改。系统的伸缩性通过在服务机群中透明地加入和删除一个节点来达到，通过检测节点或服务进程故障和正确地重置系统达到高可用性。由于我们的负载调度技术是在Linux内核中实现的，我们称之为Linux虚拟服务器（Linux Virtual Server）。
3、IP虚拟服务器软件IPVS
在调度器的实现技术中，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）
通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。
原理
- 客户端请求数据，目标IP为VIP
- 请求数据到达LB负载均衡服务器（以下简称LB），LB根据调度算法将目的地址修改为RIP地址及对应端口（此RIP地址是根据调度算法得出的）并在连接HASH表中记录下这个连接。
- 数据包从LB服务器到达RS服务器WS3
- 然后WS3进行响应。WS3的网关必须是LB的内网IP也就是DIP，然后将数据返回给LB服务器。
- LB收到RS的返回后的数据，根据连接HASH表修改源地址VIP&目标地址CIP，及对应端口80.然后数据就从LB出发到达客户端。
- 客户端收到的就只能看到VIP\DIP信息。
总结
- NAT技术将请求的报文和响应的报文都需要通过LB进行地址重写，因此当客户请求越来越多网站访问量比较大的时候LB负载均衡调度器就会遇到的瓶颈，一般要求最多只能10-20台节点
- 只需要在LB上配置一个公网IP地址就可以了。
- 每台内部的节点服务器的网关地址必须是调度器LB的内网地址。
- NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。
2）Virtual Server via IP Tunneling（VS/TUN）
采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报 文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。
原理
- 客户请求数据包，目标地址VIP发送到LB上。
- LB接收到客户请求包，进行IP Tunnel封装。即在原有的包头加上IP Tunnel的包头。然后发送出去。
- RS节点服务器根据IP Tunnel包头信息（此时就又一种逻辑上的隐形隧道，只有LB和RS之间懂）收到请求包，然后解开IP Tunnel包头信息，得到客户的请求包并进行响应处理。
- 响应处理完毕之后，RS服务器使用自己的出公网的线路，将这个响应数据包发送给客户端。源IP地址还是VIP地址。
- 客户端收到数据
3）Virtual Server via Direct Routing（VS/DR）
VS/DR通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连在同一物理网段上。
原理
- DR模式将报文直接路由给目标LB负载均衡服务器。
- LB负载均衡服务器根据各个真实服务器的负载情况，连接数多少等，动态地选择一台服务器，不修改目标IP地址和目标端口，也不封装IP报文，而是将请求报文的数据帧的目标MAC地址改为真实服务器的MAC地址。
- 然后再将修改的数据帧在服务器组的局域网上发送。因为数据帧的MAC地址是真实 服务器的MAC地址，并且又在同一个局域网。那么根据局域网的通讯原理，真实复位是一定能够收到由LB发出的数据包。真实服务器接收到请求数据包的时候， 解开IP包头查看到的目标IP是VIP。（此时只有自己的IP符合目标IP才会接收进来，所以我们需要在本地的回环借口上面配置VIP。另：由于网络接口都会进行ARP广播响应，但集群的其他机器都有这个VIP的lo接口，都响应就会冲突。所以我们需要把真实服务器的lo接口的ARP响应关闭掉，这里我们使用arptables）
- 然后真实服务器做成请求响应，之后根据自己的路由信息将这个响应数据包发送回给客户，并且源IP地址还是VIP。
总结
- 通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP，目的地址仍然是VIP地址。
- 请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此并发访问量大时使用效率很高（和NAT模式比）
- 因为DR模式是通过MAC地址改写机制实现转发，因此所有RS节点和调度器LB只能在一个局域网里面
- RS主机需要绑定VIP地址在LO接口上，并且需要配置ARP抑制。
- RS节点的默认网关不需要配置成LB，而是直接配置为上级路由的网关，能让RS直接出网就可以。
- 由于DR模式的调度器仅做MAC地址的改写，所以调度器LB就不能改写目标端口，那么RS服务器就得使用和VIP相同的端口提供服务。
二、DR模型（负载均衡+高可用）
DR模型是三种模型中性能最佳的。
重新封装三个虚拟机。详情查看封装快照。
在server2和server3主机安装http，写入发布文件，开启httpd。
###server2 & server3
yum install httpd -y
echo server2 > /var/www/html/index.html
echo server3 > /var/www/html/index.html
systemctl start httpd
在server1安装ipvs的管理器ipvsadm。增加一台新的虚拟服务器，在虚拟服务器中增加server2和server3两台真实服务器。保存规则。更多命令详情参考LVS中文站点。
###server1
yum install -y ipvsadm ##ipvs的管理器
ipvsadm -A -t 172.25.24.100:80 -s rr ##增加一台新的虚拟服务器
ipvsadm -a -t 172.25.24.100:80 -r 172.25.24.2:80 -g ##在一个虚拟服务器中增加一台新的真实服务器
ipvsadm -a -t 172.25.24.100:80 -r 172.25.24.3:80 -g
ipvsadm-save -n ##保存规则
ipvsadm -ln ##以数字形式输出地址和端口号
ipvsadm-save -n > /etc/sysconfig/ipvsadm ##保存规则至配置文件中
cat /etc/sysconfig/ipvsadm
当清空规则，开启ipvsadm时，规则还是会出现，因为已经保存在了配置文件中。添加一个VIP。
ipvsadm -C ##清空定义的所有内容
ipvsadm -ln ##以数字形式输出地址和端口号，为空
systemctl start ipvsadm
ipvsadm -ln
lsmod | grep ip_vs ##查询是否加载了ip_vs模块
ip addr add 172.25.24.100/24 dev eth0
扩展：
-A --add-service 在内核的虚拟服务器表中添加一条新的虚拟服务器记录。也
就是增加一台新的虚拟服务器。
-a --add-server 在内核虚拟服务器表的一条记录里添加一条新的真实服务器
记录。也就是在一个虚拟服务器中增加一台新的真实服务器
-s --scheduler scheduler 使用的调度算法，有这样几个选项rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq,默认的调度算法是： wlc.
-t --tcp-service service-address 说明虚拟服务器提供的是tcp 的服务
-g --gatewaying 指定LVS 的工作模式为直接路由模式（也是LVS 默认的模式）
在真机重复执行curl 172.25.24.100，但是并不能显示调度的主机。
在server1查看，可以调度，但没有响应，因为server2和server3没有VIP。
###server1
ipvsadm -ln
在server2和server3主机添加VIP。
###server2 & server3
ip addr add 172.25.24.100/32 dev eth0
在真机访问，可以发现server2和server3仍被轮流调度，实现负载均衡。
###真机
[root@foundation24 ~]# curl 172.25.24.100
server2
[root@foundation24 ~]# curl 172.25.24.100
server3
[root@foundation24 ~]# curl 172.25.24.100
server2
[root@foundation24 ~]# curl 172.25.24.100
server3
##负载均衡
在server1查看调度记录。
###server1
ipvsadm -ln
此时在真机查看ARP缓存表，删除当前绑定的MAC地址，重新访问，可以发现server2和server3仍被轮流调度，即重新绑定的依旧是server1主机进行轮流调度，但其实是一个概率问题，是有可能绑定到server2或者server3，如果绑定到server2，则curl命令访问到的只有server2。
###真机
arp -an | grep 100 ##显示100接口的 ARP 缓存表
arp -d 172.25.24.100 ##删除一个静态项目
[root@foundation24 ~]# curl 172.25.24.100
server2
[root@foundation24 ~]# curl 172.25.24.100
server3
[root@foundation24 ~]# curl 172.25.24.100
server2
[root@foundation24 ~]# curl 172.25.24.100
server3
[root@foundation24 ~]# arp -an | grep 100
? (172.25.24.100) at 52:54:00:12:6a:e0 [ether] on br0
在server1查看调度记录时，因为删除了缓存表，重新调度，刚好还是四次，所以数据没有变，但其实调度成功。如果绑定到server2，curl访问，在server1查看时，则没有调度记录，因为没有经过server1调度。
在server2安装arptables，用于管理内核中的ARP规则表。设置arp规则,将所有172.25.24.100的arp包全部丢弃，做地址伪装，所有从172.25.10.100上发出的数据都伪装成从172.25.10.2发出。将规则保存到配置文件中，重启服务。将配置文件复制到另一台主机。更多命令详见arptables详情。
###server2
yum install -y arptables ##管理内核中的ARP规则表
arptables -L
arptables -A INPUT -d 172.25.24.100 -j DROP ##设置arp规则,将所有172.25.24.100的arp包全部丢弃
arptables -A OUTPUT -s 172.25.24.100 -j mangle --mangle-ip-s 172.25.24.2
##地址伪装，所有从172.25.10.100上发出的数据都伪装成从172.25.10.2发出
arptables-save
arptables-save > /etc/sysconfig/arptables
systemctl restart arptables.service
arptables -nL
scp /etc/sysconfig/arptables server3:/etc/sysconfig/
扩展：
正常情况下，arptable_filter 只有一个表filter ，不指定-t 表名 时默认就是filter 表。
filter 表有两个链，一个是IN,表示外面发进来的ARP包；另外一个是OUT ，表示本机发出的ARP包。
内建的动作：ACCEPT 放行ARP包；DROP 丢掉ARP包；CONTINUE 继续下一规则;RETURN 不在这个链中继续进行匹配,返回到上一条链的下一条规则.
-L, --list [chain]列出规则
-A, --append chain rule-specification追加规则
-d, --destination [!] address[/mask]目的地址
-j, --jump target跳到目标
-s, --source [!] address[/mask]源地址
在server3主机，安装arptables，重启，列出规则。将伪装规则写入配置文件中，重启服务。
###server3
yum install -y arptables
systemctl restart arptables.service
arptables -nL
vim /etc/sysconfig/arptables
///
-A OUTPUT -j mangle -s 172.25.24.100 --mangle-ip-s 172.25.24.3
///
systemctl restart arptables.service
当在真机进行检测时，因为禁用了server2和server3主机的MAC地址，则当删除当前绑定的MAC地址，重新访问时，绑定的仍然是server1主机，server2与server3负载均衡。
###真机
arp -an | grep 100
arp -d 172.25.24.100
arp -an | grep 100 ##为空
[root@foundation24 ~]# curl 172.25.24.100
server2
[root@foundation24 ~]# curl 172.25.24.100
server3
三、keepalived–lvs管理软件
标签：LB,运维,LVS,--,IP,24.100,调度,172.25,服务器 来源： https://blog.csdn.net/weixin_43849813/article/details/120469198
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。