lvs
lvs 负载均衡
Linux虚拟服务器 LVS的三种负载均衡方式比较
1、LVS的定义？
LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。其实它是一种集群(Cluster)技术，采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。
为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。一般来说，LVS集群采用三层结构，其体系结构如图所示：
LVS集群的体系结构
2、LVS主要组成部分为：
负载调度器（load balancer/ Director），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。
服务器池（server pool/ Realserver），是一组真正执行客户请求的服务器，执行的服务一般有WEB、MAIL、FTP和DNS等。
共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。
3、LVS负载均衡方式:
Virtual Server via Network Address Translation NAT（VS/NAT）
VS/NAT是一种最简单的方式，所有的RealServer只需要将自己的网关指向Director即可。客户端可以是任意操作系统，但此方式下，一个Director能够带动的RealServer比较有限。在VS/NAT的方式下，Director也可以兼为一台RealServer。VS/NAT的体系结构如图所示。
VS/NAT的体系结构
Virtual Server via IP Tunneling(VS/TUN)
IP隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况，动态地选择一台服务器，将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为 VIP 的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。
VS/TUN的体系结构
VS/TUN的工作流程：
Virtual Server via Direct Routing(VS/DR)
VS/DR方式是通过改写请求报文中的MAC地址部分来实现的。Director和RealServer必需在物理上有一个网卡通过不间断的局域网相连。 RealServer上绑定的VIP配置在各自Non-ARP的网络设备上(如lo或tunl),Director的VIP地址对外可见，而RealServer的VIP对外是不可见的。RealServer的地址即可以是内部地址，也可以是真实地址。
VS/DR的体系结构
VS/DR的工作流程
VS/DR的工作流程如图所示：它的连接调度和管理与VS/NAT和VS/TUN中的一样，它的报文转发方法又有不同，将报文直接路由给目标服务器。在VS/DR中，调度器根据各个服务器的负载情况，动态地选择一台服务器，不修改也不封装IP报文，而是将数据帧的MAC地址改为选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上，服务器处理这个报文，然后根据路由表将响应报文直接返回给客户。
VS/DR的工作流程
4、三种负载均衡方式比较：
Virtual Server via NAT
VS/NAT 的优点是服务器可以运行任何支持TCP/IP的操作系统，它只需要一个IP地址配置在调度器上，服务器组可以用私有的IP地址。缺点是它的伸缩能力有限，当服务器结点数目升到20时，调度器本身有可能成为系统的新瓶颈，因为在VS/NAT中请求和响应报文都需要通过负载调度器。我们在Pentium166 处理器的主机上测得重写报文的平均延时为60us，性能更高的处理器上延时会短一些。假设TCP报文的平均长度为536 Bytes，则调度器的最大吞吐量为8.93 MBytes/s. 我们再假设每台服务器的吞吐量为800KBytes/s，这样一个调度器可以带动10台服务器。（注：这是很早以前测得的数据）
基于 VS/NAT的的集群系统可以适合许多服务器的性能要求。如果负载调度器成为系统新的瓶颈，可以有三种方法解决这个问题：混合方法、VS/TUN和 VS/DR。在DNS混合集群系统中，有若干个VS/NAT负调度器，每个负载调度器带自己的服务器集群，同时这些负载调度器又通过RR-DNS组成简单的域名。
但VS/TUN和VS/DR是提高系统吞吐量的更好方法。
对于那些将IP地址或者端口号在报文数据中传送的网络服务，需要编写相应的应用模块来转换报文数据中的IP地址或者端口号。这会带来实现的工作量，同时应用模块检查报文的开销会降低系统的吞吐率。
Virtual Server via IP Tunneling
在VS/TUN 的集群系统中，负载调度器只将请求调度到不同的后端服务器，后端服务器将应答的数据直接返回给用户。这样，负载调度器就可以处理大量的请求，它甚至可以调度百台以上的服务器（同等规模的服务器），而它不会成为系统的瓶颈。即使负载调度器只有100Mbps的全双工网卡，整个系统的最大吞吐量可超过 1Gbps。所以，VS/TUN可以极大地增加负载调度器调度的服务器数量。VS/TUN调度器可以调度上百台服务器，而它本身不会成为系统的瓶颈，可以用来构建高性能的超级服务器。VS/TUN技术对服务器有要求，即所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。目前，VS/TUN的后端服务器主要运行Linux操作系统，我们没对其他操作系统进行测试。因为“IP Tunneling”正成为各个操作系统的标准协议，所以VS/TUN应该会适用运行其他操作系统的后端服务器。
Virtual Server via Direct Routing
跟VS/TUN方法一样，VS/DR调度器只处理客户到服务器端的连接，响应数据可以直接从独立的网络路由返回给客户。这可以极大地提高LVS集群系统的伸缩性。跟VS/TUN相比，这种方法没有IP隧道的开销，但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上，服务器网络设备（或者设备别名）不作ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上。
三种LVS负载均衡技术的优缺点归纳以下表：
注：以上三种方法所能支持最大服务器数目的估计是假设调度器使用100M网卡，调度器的硬件配置与后端服务器的硬件配置相同，而且是对一般Web服务。使 用更高的硬件配置（如千兆网卡和更快的处理器）作为调度器，调度器所能调度的服务器数量会相应增加。当应用不同时，服务器的数目也会相应地改变。所以，以上数据估计主要是为三种方法的伸缩性进行量化比较。
5、负载均衡调度算法
1)最少的连接方式（Least Connection）：传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。
2)最快模式（Fastest）：传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
3）观察模式（Observed）：连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
4）预测模式（Predictive）：BIG-IP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测)
5）动态性能分配(Dynamic Ratio-APM)：BIG-IP 收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。
6）动态服务器补充(Dynamic Server Act.)：当主服务器群中因故障导致数量减少时，动态地将备份服务器补充至主服务器群。
7）服务质量(QoS）：按不同的优先级对数据流进行分配。
8）服务类型(ToS)： 按不同的服务类型（在Type of Field中标识）负载均衡对数据流进行分配。
9)规则模式：针对不同的数据流设置导向规则，用户可自行。
LVS(Linux Virtual Server)Linux 虚拟服务器介绍及配置(负载均衡系统)
一，简介
LVS(Linux Virtual Server) 是Unix-like系统中的一个虚拟服务器，是国内贡献给开源组织的一个最优秀的项目之一。LVS在Unix-like系统中
是作为一个前端(Director)存在的,又称为调度器，它本身不提供任何的服务，只是将通过互联网进来的请求接受后再转发给后台运行的真正的
服务器(RealServer)进行处理，然后响应给客户端。
LVS有两个重要的组件：一个是IPVS，一个是IPVSADM。ipvs是LVS的核心组件，它本身只是一个框架，类似于iptables，工作于内核空间中。
ipvsadm 是用来定义LVS的转发规则的，工作于用户空间中。
LVS有三种转发类型：
1.LVS-NAT模型，称为网络地址转换，实现起来比较简单。
2.LVS-DR模型，称为直接路由模型，应用比较广泛。
3.LVS-TUN模型，称为隧道模型。
二、LVS的三种模型的工作属性：
1.LVS-NAT模型的工作属性或特：
(1).所有的RealServer集群节点和前端调度器Director都要在同一个子网中
(2).通常情况下RealServer的IP地址(以下简成RIP)为私有地址，便于RealServer集群节点之间进行通信
(3).通常情况下前端的Director有两个IP地址，一个为VIP，是虚拟的IP地址，请求。客户端向此IP地址发起
一个是DIP，是真正的Director的IP地址，RIP的网关要指向Director的DIP。
(4).这种模型可以实现端口映射
(5).RealServer的操作系统可以是任意操作系统
(6).前端的Director既要处理客户端发起的请求，又要处理后台RealServer的响应信息，将RealServer响应的信息再转发给客户端
(7).前端Director很容易成为整个集群系统性能的瓶颈。
2.LVS-DR模型的工作属性或特征：此种模型通过MAC地址转发工作，如何转发后面将会介绍。
(1).所有的RealServer集群节点和前端调度器Director都要在同一个物理网络中
(2).RIP可以使用公网的IP
(3).RIP的网关不能指向DIP
(4).前端的Director只处理客户端的请求，然后将请求转发给RealServer，由后台的RealServer直接响应客户端，不再经过Director
(5).此种模型不支持端口映射
(6).RealServer可以使用大多数的操作系统
(7).此种模型的性能要优于LVS-NAT
3.LVS-TUN模型的基本工作属性或特征
(1).RealServer服务器与前端的Director可以在不同的网络中
(2).RIP一定不能是私有IP
(3).前端的Director只处理客户端的请求，然后将请求转发给RealServer，由后台的RealServer直接响应客户端，不再经过Director
(4).此种模型也不支持端口映射
(5).RealServer只能使用哪些支持IP隧道的操作系统
三。LVS Scheduling Method LVS的调度方法：
1.Fixed Scheduling Method 静态调服方法
(1).RR 轮询
(2).WRR 加权轮询
(3).DH 目标地址hash
(4).SH 源地址hash
2.Dynamic Scheduling Method 动态调服方法
(1).LC 最少连接
(2).WLC 加权最少连接
(3).SED 最少期望延迟
(4).NQ 从不排队调度方法
(5).LBLC 基于本地的最少连接
(6).LBLCR 带复制的基于本地的最少连接
四、ipvsadm组件定义规则的格式：
1.定义集群服务格式：
(1).添加集群服务：
ipvsadm -A|E -t|u|f service-address [-s scheduler]
[-p [timeout]] [-M netmask]
-A： 表示添加一个新的集群服务
-E： 编辑一个集群服务
-t： 表示tcp协议
-u： 表示udp协议
-f： 表示firewall-Mark,防火墙标记
service-address： 集群服务的IP地址，即VIP
-s 指定调度算法
-p 持久连接时长，如#ipvsadm -Lcn ，查看持久连接状态
-M 定义掩码
ipvsadm -D -t|u|f service-address 删除一个集群服务
ipvsadm -C 清空所有的规则
ipvsadm -R 重新载入规则
ipvsadm -S [-n] 保存规则
2.向集群服务添加RealServer规则：
(1).添加RealServer规则
ipvsadm -a|e -t|u|f service-address -r server-address
[-g|i|m] [-w weight]
-a 添加一个新的realserver规则
-e 编辑realserver规则
-t tcp协议
-u udp协议
-f firewall-Mark，防火墙标记
service-address realserver的IP地址
-g 表示定义为LVS-DR模型
-i 表示定义为LVS-TUN模型
-m 表示定义为LVS-NAT模型
-w 定义权重，后面跟具体的权值
ipvsadm -d -t|u|f service-address -r server-address --删除一个realserver
ipvsadm -L|l [options] --查看定义的规则
如：#ipvsadm -L -n
ipvsadm -Z [-t|u|f service-address] --清空计数器
五、LVS-NAT模型实例
1。先配置好网络环境，要三个虚拟机(本次实验在虚拟机上完成)，一台用作Director，其他两台分别为RealServer1 和RealServer2
其中Director要两个网卡，Eth0网卡为桥接(Birdged),Eth1网卡为仅主机(Host-only),RealServer1 和RealServer2的网卡也都是仅主机
类型的。
2.为了演示效果，将Director的两块网卡配置成不在同一个网段的IP地址，RealServer1 和RealServer2的IP地址为同一网段，规划如下图：
要注意的是：要将本地物理机的Vmnet1的IP地址配置成和Director的Eth1网卡的IP地址在同一个网段中,同时将RealServer1和RealServer2的网关指向Director主机的Eth1网卡的地址，如下图所示：
3.配置好网络环境之后就开始配置ipvsadm，确保在物理机上能ping通Eth0的IP地址，如下图所示：
能Ping通，说明物理主机已经可以和Director虚拟主机通信了。
4.在Director虚拟主机上配置：
#echo 1 > /proc/sys/net/ipv4/ip_forward --开启IP转发功能
#rpm -qa ipvsadm --查看ipvsadm是否安装，如果没有安装则安装之，直接使用yum安装即可
#yum install ipvsadm -y
定义LVS-NAT模型规则
此处使用的是web服务器进行的演示，在192.168.24.44和192.168.24.45上都提供了nginx服务，其中
192.168.24.44提供的网页信息为“welcome realserver 1”,192.168.24.45提供的网页信息为“welcome realserver 2”
#ipvsadm -A -t 172.16.100.24:80 -s rr
#ipvsadm -a -t 172.16.100.24:80 -r 192.168.24.44 -m
#ipvsadm -a -t 172.16.100.24:80 -r 192.168.24.45 -m
#ipvsadm -L -n --查看定义的规则
这些规则都是临时规则，不会永久生效的，要想永久生效可以保存规则，命令如下：
#service ipvsadm save
5.在Internet Explorer浏览器中访问172.16.100.24，会显示如下图所示信息：
而在google浏览器中访问172.16.100.24，会显示如下图所示信息：
如果刷新页面或者使用不同的浏览器，会轮流显示页面，这就是最简单的服务器负载均衡啦！
六、LVS-DR模型的实现过程：
1.首先规划集群和网路环境，需要三台虚拟机，如下图所示：
此时Director可以只有一个网卡Eth0，连接类型为桥接(Birdged),RealServer1和RealServer2 的网卡连接类型也都为桥接(Birdged):
2.配置集群服务
(1).在Director服务器上配置：
#ifconfig eth0:1 172.16.100.100 broadcast 172.16.100.100 netmask 255.255.255.255 up
#route add -host 172.16.100.100 dev eth0:1
#echo 1 > /proc/sys/net/ipv4/ip_forward --开启IP转发功能
(2).在realserve1服务器上进行配置：
# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
#ifconfig lo:0 172.16.100.100 broadcast 172.16.100.100 netmask 255.255.255.255 up
#route add -host 172.16.100.100 dev lo:0
(3).在realserver2 服务器上进行配置
# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
#ifconfig lo:0 172.16.100.100 broadcast 172.16.100.100 netmask 255.255.255.255 up
#route add -host 172.16.100.100 dev lo:0
(4).再在Director上配置ipvsadm规则：
#ipvsadm -A -t 172.16.100.100:80 -s rr -g
#ipvsadm -a -t 172.16.100.100:80 -r 172.16.24.34
#ipvsadm -a -t 172.16.100.100:80 -r 172.16.24.44
(5).在浏览器中进行验证：
进行第一次访问，如下图所示：
进行第二次访问，如下图所示：
3.基于ssl的访问
[root@mail ~]# ipvsadm -A -t 172.16.100.100:443 -s rr
[root@mail ~]# ipvsadm -a -t 172.16.100.100:443 -r 172.16.24.2 -g
[root@mail ~]# ipvsadm -a -t 172.16.100.100:443 -r 172.16.24.3 -g
二、LVS Persistence ，lvs的持久连接性
持久连接类型：
(1).Persistent Client Connections(PCC),持久客户端连接：就是不管客户端发起什么样的服
务(如80端口的web服务，3306端口的mysql服务)请求，都将经过Director被定位到同一个特定的real server上，
只要此real server 提供了这种服务，并且会持续连接，如果客户端连接超时，real server允许一定范围内的
持久连接时长，默认持久连接时长为300m
#ipvsadm -A -t 172.16.100.100:0 -p 1200
#ipvsadm -a -t 172.16.100.100:0 -r 172.16.100.34 -g -w 10
#ipvsadm -a -t 172.16.100.100:0 -r 172.16.100.44 -g -w 5
验证效果如下图：
(2).Persistent Port Connections(PPC),持续端口连接：就是不管客户端发起什么样的端口请求(如80端口，是提供web服务的，23端口，是提供telnet服务的....)，
都会经过Director将请求转发到同一个real server上,并持续连接。假如一个客户端请求的是web服务，相应的是realserver1 ，当此用户退出后再次发起请求web服务的时候
依然是realserver1 提供的web服务。
iptables：
[root@mail ~]# iptables -t mangle -A PREROUTING -i eth0 -p tcp -d 172.16.100.100 --dport 80 -j MARK --set-mark 20
[root@mail ~]# iptables -t mangle -A PREROUTING -i eth0 -p tcp -d 172.16.100.100 --dport 443 -j MARK --set-mark 20
[root@mail ~]# iptables -t mangle -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK tcp -- 0.0.0.0/0 172.16.100.100 tcp dpt:80 MARK set 0x14
MARK tcp -- 0.0.0.0/0 172.16.100.100 tcp dpt:443 MARK set 0x14
把80端口和443 端口做成一个持久防火墙标记，同时定向到同一个realserver上，即在访问80服务的时候是realserver1，
然后改为访问443服务的时候依然定向到realserver1上
基于防火墙标记来定义集群服务，也称为端口的姻亲关系。
ipvsadm:
[root@mail ~]# ipvsadm -A -f 20 -s wlc -p 1200
[root@mail ~]# ipvsadm -a -f 20 -r 172.16.24.2 -g -w 3
[root@mail ~]# ipvsadm -a -f 20 -r 172.16.24.3 -g -w 2
[root@mail ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 20 wlc persistent 1200
-> 172.16.24.3:0 Route 2 0 0
-> 172.16.24.2:0 Route 3 0
linux负载均衡总结性说明 四层负载和七层负载有什么区别
在常规运维工作中，经常会运用到负载均衡服务。负载均衡分为四层负载和七层负载，那么这两者之间有什么不同？
废话不多说，详解如下：
一、什么是负载均衡
1）负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。负载均衡有两方面的含义：首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。
2）简单来说就是：其一是将大量的并发处理转发给后端多个节点处理，减少工作响应时间；其二是将单个繁重的工作转发给后端多个节点处理，处理完再返回给负载均衡中心，再返回给用户。目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。
二、负载均衡分类
1）二层负载均衡（mac）
根据OSI模型分的二层负载，一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应）
2）三层负载均衡（ip）
一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应）
3）四层负载均衡（tcp）
在三次负载均衡的基础上，用ip+port接收请求，再转发到对应的机器。
4）七层负载均衡（http）
根据虚拟的url或IP，主机名接收请求，再转向相应的处理服务器）。
我们运维中最常见的四层和七层负载均衡，这里重点说下这两种负载均衡。
1）四层的负载均衡就是基于IP+端口的负载均衡：在三层负载均衡的基础上，通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。
对应的负载均衡器称为四层交换机（L4 switch），主要分析IP层及TCP/UDP层，实现四层负载均衡。此种负载均衡器不理解应用协议（如HTTP/FTP/MySQL等等）。
实现四层负载均衡的软件有：
F5：硬件负载均衡器，功能很好，但是成本很高。
lvs：重量级的四层负载软件
nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活
haproxy：模拟四层转发，较灵活
2）七层的负载均衡就是基于虚拟的URL或主机IP的负载均衡：在四层负载均衡的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。
对应的负载均衡器称为七层交换机（L7 switch），除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息，实现七层负载均衡。此种负载均衡器能理解应用协议。
实现七层负载均衡的软件有：
haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；
nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多；
apache：功能较差
Mysql proxy：功能尚可。
总的来说，一般是lvs做4层负载；nginx做7层负载；haproxy比较灵活，4层和7层负载均衡都能做
三、两者之间的区别
1）从技术原理上分析
所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。
所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。
2）从应用场景的需求上分析
七层应用负载的好处，是使得整个网络更"智能化"。可以参考这篇：http应用优化和加速说明-负载均衡，就可以基本上了解这种方式的优势所在。例如访问一个网站的用户流量，可以通过七层的方式，将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。当然这只是七层应用的一个小案例，从技术原理上，这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改，极大的提升了应用系统在网络层的灵活性。很多在后台，例如Nginx或者Apache上部署的功能可以前移到负载均衡设备上，例如客户请求中的Header重写，服务器响应中的关键字过滤或者内容插入等功能。
另外一个常常被提到功能就是安全性。网络中最常见的SYN Flood攻击，即黑客控制众多源客户端，使用虚假IP地址对同一目标发送SYN攻击，通常这种攻击会大量发送SYN报文，耗尽服务器上的相关资源，以达到Denial of Service(DoS)的目的。从技术原理上也可以看出，四层模式下这些SYN攻击都会被转发到后端的服务器上；而七层模式下这些SYN攻击自然在负载均衡设备上就截止，不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略，过滤特定报文，例如SQL Injection等应用层面的特定攻击手段，从应用层面进一步提高系统整体安全。
现在的7层负载均衡，主要还是着重于应用HTTP协议，所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其他TCP应用，例如基于C/S开发的ERP等系统。
3）七层应用需要考虑的问题
1.是否真的必要。七层应用的确可以提高流量智能化，同时必不可免的带来设备配置复杂，负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时需要考虑四层七层同时应用的混杂情况。
2.是否真的可以提高安全性。例如SYN Flood攻击，七层模式的确将这些流量从服务器屏蔽，但负载均衡设备本身要有强大的抗DDoS能力，否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。
3.是否有足够的灵活度。七层应用的优势是可以让整个应用的流量智能化，但是负载均衡设备需要提供完善的七层功能，满足客户根据不同情况的基于应用的调度。最简单的一个考核就是能否取代后台Nginx或者Apache等服务器上的调度功能。能够提供一个七层应用开发接口的负载均衡设备，可以让客户根据需求任意设定功能，才真正有可能提供强大的灵活性和智能性。
4）总体对比
1.智能性
七层负载均衡由于具备OIS七层的所有功能，所以在处理用户需求上能更加灵活，从理论上讲，七层模型能对用户的所有跟服务端的请求进行修改。例如对文件header添加信息，根据不同的文件类型进行分类转发。四层模型仅支持基于网络层的需求转发，不能修改用户请求的内容。
2.安全性
七层负载均衡由于具有OSI模型的全部功能，能更容易抵御来自网络的攻击；四层模型从原理上讲，会直接将用户的请求转发给后端节点，无法直接抵御网络攻击。
3.复杂度
四层模型一般比较简单的架构，容易管理，容易定位问题；七层模型架构比较复杂，通常也需要考虑结合四层模型的混用情况，出现问题定位比较复杂。
4.效率比
四层模型基于更底层的设置，通常效率更高，但应用范围有限；七层模型需要更多的资源损耗，在理论上讲比四层模型有更强的功能，现在的实现更多是基于http应用。
四、负载均衡技术方案说明
目前有许多不同的负载均衡技术用以满足不同的应用需求，下面从负载均衡所采用的设备对象（软/硬件负载均衡），应用的OSI网络层次（网络层次上的负载均衡），及应用的地理结构（本地/全局负载均衡）等来分类。
1）软/硬件负载均衡
软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl，Keepalive+ipvs等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。软件解决方案缺点也较多，因为每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，所以当连接请求特别大的时候，软件本身会成为服务器工作成败的一个关键；软件可扩展性并不是很好，受到操作系统的限制；由于操作系统本身的Bug，往往会引起安全问题。
硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备通常是一个独立于系统的硬件，我们称之为负载均衡器。由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。
软件负载均衡与硬件负载均衡的对比：
软件负载均衡的优点是需求环境明确，配置简单，操作灵活，成本低廉，效率不高，能满足普通的企业需求；缺点是依赖于系统，增加资源开销；软件的优劣决定环境的性能；系统的安全，软件的稳定性均会影响到整个环境的安全。
硬件负载均衡优点是独立于系统，整体性能大量提升，在功能、性能上优于软件方式；智能的流量管理，多种策略可选，能达到最佳的负载均衡效果；缺点是价格昂贵。
2）本地/全局负载均衡
负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance，也叫地域负载均衡)，本地负载均衡是指对本地的服务器群做负载均衡，全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务器群间作负载均衡。
本地负载均衡能有效地解决数据流量过大、网络负荷过重的问题，并且不需花费昂贵开支购置性能卓越的服务器，充分利用现有设备，避免服务器单点故障造成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即使是再给现有服务器扩充升级，也只是简单地增加一个新的服务器到服务群中，而不需改变现有网络结构、停止现有的服务。
全局负载均衡主要用于在一个多区域拥有自己服务器的站点，为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器，从而获得最快的访问速度，也可用于子公司分散站点分布广的大公司通过Intranet（企业内部互联网）来达到资源统一合理分配的目的。
3）网络层次上的负载均衡
针对网络上负载过重的不同瓶颈所在，从网络的不同层次入手，我们可以采用相应的负载均衡技术来解决现有问题。
随着带宽增加，数据流量不断增大，网络核心部分的数据接口将面临瓶颈问题，原有的单一线路将很难满足需求，而且线路的升级又过于昂贵甚至难以实现，这时就可以考虑采用链路聚合（Trunking）技术。
链路聚合技术（第二层负载均衡）将多条物理链路当作一条单一的聚合逻辑链路使用，网络数据流量由聚合逻辑链路中所有物理链路共同承担，由此在逻辑上增大了链路的容量，使其能满足带宽增加的需求。
现代负载均衡技术通常操作于网络的第四层或第七层。第四层负载均衡将一个Internet上合法注册的IP地址映射为多个内部服务器的IP地址，对每次 TCP连接请求动态使用其中一个内部IP地址，达到负载均衡的目的。在第四层交换机中，此种均衡技术得到广泛的应用，一个目标地址是服务器群VIP（虚拟 IP，Virtual IP address）连接请求的数据包流经交换机，交换机根据源端和目的IP地址、TCP或UDP端口号和一定的负载均衡策略，在服务器IP和VIP间进行映射，选取服务器群中最好的服务器来处理连接请求。
七层负载均衡控制应用层服务的内容，提供了一种对访问流量的高层控制方式，适合对HTTP服务器群的应用。第七层负载均衡技术通过检查流经的HTTP报头，根据报头内的信息来执行负载均衡任务。
七层负载均衡优点表现在如下几个方面：
1）通过对HTTP报头的检查，可以检测出HTTP400、500和600系列的错误信息，因而能透明地将连接请求重新定向到另一台服务器，避免应用层故障。
2）可根据流经的数据类型（如判断数据包是图像文件、压缩文件或多媒体文件格式等），把数据流量引向相应内容的服务器来处理，增加系统性能。
3）能根据连接请求的类型，如是普通文本、图象等静态文档请求，还是asp、cgi等的动态文档请求，把相应的请求引向相应的服务器来处理，提高系统的性能及安全性。
七层负载均衡缺点表现在如下几个方面：
1）七层负载均衡受到其所支持的协议限制（一般只有HTTP），这样就限制了它应用的广泛性。
2）七层负载均衡检查HTTP报头会占用大量的系统资源，势必会影响到系统的性能，在大量连接请求的情况下，负载均衡设备自身容易成为网络整体性能的瓶颈。
五、负载均衡策略
在实际应用中，我们可能不想仅仅是把客户端的服务请求平均地分配给内部服务器，而不管服务器是否宕机。而是想使Pentium III服务器比Pentium II能接受更多的服务请求，一台处理服务请求较少的服务器能分配到更多的服务请求，出现故障的服务器将不再接受服务请求直至故障恢复等等。选择合适的负载均衡策略，使多个设备能很好的共同完成任务，消除或避免现有网络负载分布不均、数据流量拥挤反应时间长的瓶颈。在各负载均衡方式中，针对不同的应用需求，在OSI参考模型的第二、三、四、七层的负载均衡都有相应的负载均衡策略。
负载均衡策略的优劣及其实现的难易程度有两个关键因素：负载均衡算法；对网络系统状况的检测方式和能力。
1、负载均衡算法
1）轮循均衡（Round Robin）：每一次来自网络的请求轮流分配给内部中的服务器，从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。
2）权重轮循均衡（Weighted Round Robin）：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是 3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。
3）随机均衡（Random）：把来自网络的请求随机分配给内部中的多个服务器。
4）权重随机均衡（Weighted Random）：此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。
5）响应速度均衡（Response Time）：负载均衡设备对内部各服务器发出一个探测请求（例如Ping），然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与服务器间的最快响应时间。
6）最少连接数均衡（Least Connection）：客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。
7）处理能力均衡：此种均衡算法将把服务请求分配给内部中处理负荷（根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成）最轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七层（应用层）负载均衡的情况下。
8）DNS响应均衡（Flash DNS）：在Internet上，无论是HTTP、FTP或是其它的服务请求，客户端一般都是通过域名解析来找到服务器确切的IP地址的。在此均衡算法下，分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在同一时间内把此域名解析成各自相对应服务器的IP地址（即与此负载均衡设备在同一位地理位置的服务器的IP地址）并返回给客户端，则客户端将以最先收到的域名解析IP地址来继续请求服务，而忽略其它的IP地址响应。在种均衡策略适合应用在全局负载均衡的情况下，对本地负载均衡是没有意义的。
2、网络系统状况的检测方式
尽管有多种的负载均衡算法可以较好的把数据流量分配给服务器去负载，但如果负载均衡策略没有对网络系统状况的检测方式和能力，一旦在某台服务器或某段负载均衡设备与服务器网络间出现故障的情况下，负载均衡设备依然把一部分数据流量引向那台服务器，这势必造成大量的服务请求被丢失，达不到不间断可用性的要求。所以良好的负载均衡策略应有对网络故障、服务器系统故障、应用服务故障的检测方式和能力：
1）Ping侦测：通过ping的方式检测服务器及网络系统状况，此种方式简单快速，但只能大致检测出网络及服务器上的操作系统是否正常，对服务器上的应用服务检测就无能为力了。
2）TCP Open侦测：每个服务都会开放某个通过TCP连接，检测服务器上某个TCP端口（如Telnet的23口，HTTP的80口等）是否开放来判断服务是否正常。
3）HTTP URL侦测：比如向HTTP服务器发出一个对main.html文件的访问请求，如果收到错误信息，则认为服务器出现故障。
3、其他因素
负载均衡策略的优劣除受上面所讲的两个因素影响外，在有些应用情况下，我们需要将来自同一客户端的所有请求都分配给同一台服务器去负担，例如服务器将客户端注册、购物等服务请求信息保存的本地数据库的情况下，把客户端的子请求分配给同一台服务器来处理就显的至关重要了。有几种方式可以解决此问题：
1）一是根据IP地址把来自同一客户端的多次请求分配给同一台服务器处理，客户端IP地址与服务器的对应信息是保存在负载均衡设备上的；
2）二是在客户端浏览器 cookie内做独一无二的标识来把多次请求分配给同一台服务器处理，适合通过代理服务器上网的客户端。
3）还有一种路径外返回模式（Out of Path Return），当客户端连接请求发送给负载均衡设备的时候，中心负载均衡设备将请求引向某个服务器，服务器的回应请求不再返回给中心负载均衡设备，即绕过流量分配器，直接返回给客户端，因此中心负载均衡设备只负责接受并转发请求，其网络负担就减少了很多，并且给客户端提供了更快的响应时间。此种模式一般用于HTTP服务器群，在各服务器上要安装一块虚拟网络适配器，并将其IP地址设为服务器群的VIP，这样才能在服务器直接回应客户端请求时顺利的达成三次握手。
六、负载均衡实施要素
1）性能
性能是我们在引入均衡方案时需要重点考虑的问题，但也是一个最难把握的问题。衡量性能时可将每秒钟通过网络的数据包数目做为一个参数，另一个参数是均衡方案中服务器群所能处理的最大并发连接数目，但是，假设一个均衡系统能处理百万计的并发连接数，可是却只能以每秒2个包的速率转发，这显然是没有任何作用的。性能的优劣与负载均衡设备的处理能力、采用的均衡策略息息相关，并且有两点需要注意：一、均衡方案对服务器群整体的性能，这是响应客户端连接请求速度的关键；二、负载均衡设备自身的性能，避免有大量连接请求时自身性能不足而成为服务瓶颈。有时我们也可以考虑采用混合型负载均衡策略来提升服务器群的总体性能，如DNS负载均衡与NAT负载均衡相结合。另外，针对有大量静态文档请求的站点，也可以考虑采用高速缓存技术，相对来说更节省费用，更能提高响应性能；对有大量ssl/xml内容传输的站点，更应考虑采用ssl/xml加速技术。
2）可扩展性
IT技术日新月异，一年以前最新的产品，现在或许已是网络中性能最低的产品；业务量的急速上升，一年前的网络，现在需要新一轮的扩展。合适的均衡解决方案应能满足这些需求，能均衡不同操作系统和硬件平台之间的负载，能均衡HTTP、邮件、新闻、代理、数据库、防火墙和 Cache等不同服务器的负载，并且能以对客户端完全透明的方式动态增加或删除某些资源。
3）灵活性
均衡解决方案应能灵活地提供不同的应用需求，满足应用需求的不断变化。在不同的服务器群有不同的应用需求时，应有多样的均衡策略提供更广泛的选择。
4）可靠性
在对服务质量要求较高的站点，负载均衡解决方案应能为服务器群提供完全的容错性和高可用性。但在负载均衡设备自身出现故障时，应该有良好的冗余解决方案，提高可靠性。使用冗余时，处于同一个冗余单元的多个负载均衡设备必须具有有效的方式以便互相进行监控，保护系统尽可能地避免遭受到重大故障的损失。
5）易管理性
管是通过软件还是硬件方式的均衡解决方案，我们都希望它有灵活、直观和安全的管理方式，这样便于安装、配置、维护和监控，提高工作效率，避免差错。在硬件负载均衡设备上，目前主要有三种管理方式可供选择：
一、命令行接口（CLI：Command Line Interface），可通过超级终端连接负载均衡设备串行接口来管理，也能telnet远程登录管理，在初始化配置时，往往要用到前者；
二、图形用户接口（GUI：Graphical User Interfaces），有基于普通web页的管理，也有通过Java Applet 进行安全管理，一般都需要管理端安装有某个版本的浏览器；
三、SNMP（Simple Network Management Protocol，简单网络管理协议）支持，通过第三方网络管理软件对符合SNMP标准的设备进行管理。
web wrr算法
mysql 短连接和长链接 算法wlc
fpm 电商站点 sh 算法
练习 （nat类型）
使用docker 模拟创建虚拟机RS
宿主机当VS 虚拟机当RS
环境定义
1 集群服务 VS: Virtual Server，负责调度
定义 VIP tcp port
VIP udp port
FWM
2 集群服务的 RS
定义 RIP port
安装 宿主机 172.18.138.26
yum install ipvsadm
下载镜像
docker image pull busybox
创建容器 172.17.0.2
docker run --name rs1 -it --network bridge -v /vols/rs1:/data/web/html busybox
cd /vols/rs1/
vim index.html
<h1> RS1</h1>
容器内
启动httpd服务
httpd -h /data/web/html/
查看端口
netstat -ntl
创建第二个容器 不退出 172.17.0.3
docker run --name rs2 -it --network bridge -v /vols/rs2:/data/web/html busybox
cd /vols/rs1/
vim index.html
<h1> RS1</h1>
生成中网页的内容必须是一样的这里主要是看效果
容器内
启动httpd服务
httpd -h /data/web/html/
宿主机上访问以下
curl 172.17.0.3
更改防火墙规则
iptables -vnL 查看 FORWARD 链是否是ACCEPT 如果不是就改
手动改 iptables -P FORWARD ACCEPT
也可以改文件 但是需要重启服务 不建议
vim /usr/lib/systemd/system/docker.service
ExecStartPost=/usr/sbin/iptables -P FORWARD ACCEPT
加规则
1 查看
ipvsadm -Ln
2 管理集群服务
ipvsadm -A -t 172.18.138.26:80 -s wrr
解释 -A 添加 -t tcp协议 ip宿主机ip，是与外面通信的ip 也可以创建一个 -s 类型 wrr
3管理集群上的RS
ipvsadm -a -t 172.18.138.26:80 -r 172.17.0.2:80 -m -w 1
ipvsadm -a -t 172.18.138.26:80 -r 172.17.0.3:80 -m -w 1
4 测试发请求
curl 172.18.138.26
while true; do curl 172.18.138.26; sleep 1;done
修改 权重
ipvsadm -e -t 172.18.138.26:80 -r 172.17.0.2:80 -m -w 2
练习二 ( DR类型）
环境 同网段 3个物理机
06 07 08
在07 和08上
安装httpd服务
创建测试页
echo "<h1> 06 </h1> " > /var/www/html/index.html
启动服务
syatemctl start httpd
06上
配置VIP 地址
ifconfig ens33:0 172.18.0.70 netmask 255.255.255.255 broadcast 172.18.0.70 up
07上
编写一个脚本
#!/bin/bash
#
vip=172.18.0.70
mask=255.255.255.255
interface="lo:0"
case $1 in
start)
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
ifconfig $interface $vip netmask $mask broadcast $vip up
route add -host $vip dev lo:0
;;
stop)
ifconfig $interface down
echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce
;;
*)
echo "Usage $(basename $0) start|stop"
exit 1
;;
esac
检查语法bash -n setkpara.sh
执行
bash setkpara.sh start
08上 也执行脚本 复制过去
bash setkpara.sh start
访问一下
curl http://172.18.0.07
curl http://172.18.0.08
在06上
定义集群
ipvsadm -A - t 172.18.0.70:80 -s wrr
ipvsadm -a -t 172.18.0.70:80 -r 172.18.0.07 -g -w 2
ipvsadm -a -t 172.18.0.70:80 -r 172.18.0.08 -g -w 2
在客户端访问
curl 172.18.0.70
用sh 算法来绑定来自同一个源地址的请求始终到达RS
改规则
ipvsadm -E -t 172.18.0.70 -s sh
访问 curl 172.18.0.70
始终访问一个
保存
ipvsadm -S > /etc/sysconfig/ipvsadm
恢复
ipvsadm -R < /etc/sysconfig/ipvsadm
设置服务开机自启 保存以后就会恢复
systemctl enable ipvsadm
清空 ipvsadm -C
07 上
使用虚拟主机的方式
cd /etc/httpd/conf.d/
vim myvhosts.conf
编辑测试网页
mkdir -pv /www/vhost{1,2}
echo "<h1>001</h1>" > /www/vhost1/index.html
echo "<h1>002</h1>" > /www/vhost2/index.html
检测一下 httpd -t
重启服务 systemctl restart httpd
拷贝到08上
scp myvhost.conf 08:/etc/httpd/conf.d/
scp -rp /www/ 08:/
08上
cd /etc/httpd/conf.d
修改一下配置 改一下主机名
vim myvhosts.conf
再修改一下网页
06上
清空规则
ipvsadm -c
加规则
iptables -t mangle -A PREROUTING -d 172.18.0.70 -p tcp -m multiport --dports 80,8080 -j MARK --set-mark 7
ipvsadm -A -f 7 -s wrr
ipvsadm -a -f 7 172.18.0.07 -g -w 1
ipvsadm -a -f 7 172.18.0.08 -g -w 1
访问
while true; do curl 172.18.0.70; curl 172.18.0.70;8080; sleep 1;done
持久连接功能
练习 持久连接
yum install redis -y
ipvsadm -A -t 172.18.0.70:0 -s wrr -p
ipvsadm -a -t 172.18.0.70:0 -r 172.18.0.07 -g -w 1
ipvsadm -a -t 172.18.0.70:0 -r 172.18.0.08 -g -w 1
访问 curl 172.18.0.70
pcc
pfw
ppc
kvm 测试
三。场景模拟
DR模式要求所有的机器处于同一网络环境中 比如 客户端 负载均衡器 和RealServer都处于互联网中 要么同处于同一局域网中
负载均衡器 192.168.58.134（局域网ip DIP） 192.168.58.133(客户端访问VIP)
RealServer1 192.168.58.135（局域网ip RIP） 192.168.58.133（虚拟ip VIP）
RealServer2 192.168.58.136（局域网ip RIP） 192.168.58.133（虚拟ip VIP）
1.配置负载均衡器
》添加虚拟ip 192.168.58.133（eno16777736为物理网卡名 通过ifconfig查看）
ifconfig eno16777736:0 192.168.58.133/32 up route add -host 192.168.58.133 dev eno16777736:0
》安装ipvsadm
yum -y install ipvsadm
#清空所有的路由规则
ipvsadm -C
#添加一个集群 192.168.58.133:80 必须是外网ip 也就是vip 因为别人才可以访问 rr表示轮询 ipvsadm -A -t 192.168.58.133:80 -s rr
#给集群添加一个主机 Rserver 192.168.58.135:80和192.168.58.136:80 这两台机各自部署一个tomcat -m表示nat模式 -g 表示dr模型
ipvsadm -a -t 192.168.58.133:80 -r 192.168.58.135:80 -g
ipvsadm -a -t 192.168.58.133:80 -r 192.168.58.136:80 -g
2 配置RealServer1和2
》虚拟ip的arp路由设置
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
》 添加虚拟ip
ifconfig lo:0192.168.58.133 broadcast192.168.58.133 netmask 255.255.255.255 up route add -host 192.168.58.133 lo:0
RealServer分别安装两个tomcat 修改端口为80
访问 http://192.168.58.133 成功
查看转发或者realserver的运行检查 可以查看系统日志 /var/log/messages文件
