前提：三台虚拟机，有nginx，要做负载
1. LVS-server 安装lvs管理软件
[root@lvs-server ~]# yum -y install ipvsadm
程序包：ipvsadm（LVS管理工具）
主程序：/usr/sbin/ipvsadm
规则保存工具：/usr/sbin/ipvsadm-save > /path/to/file
配置文件：/etc/sysconfig/ipvsadm-config
2. LVS/DR 模式
DR模式的组网要求LVS和Real server在同一网段二层互通。因为LVS DR模式在负载均衡转发报文时，只修改目的mac为real server的mac，lvs要能将报文转发给real server，就必须满足LVS和real server是同网段二层互通。
2.1 格式是：
2.2 LVS/DR模式实施
准备工作（集群中所有主机）关闭防火墙和selinux
Director分发器配置
配置VIP（网关要在同一段上）
[root@lvs-server ~]# ip addr add dev ens33 192.168.246.160/32 #设置VIP
[root@lvs-server ~]# yum install -y ipvsadm #RHEL确保LoadBalancer仓库可用
[root@lvs-server ~]# service ipvsadm start #启动
注意:启动如果报错: /bin/bash: /etc/sysconfig/ipvsadm: 没有那个文件或目录
需要手动生成文件
[root@lvs-server ~]# ipvsadm --save > /etc/sysconfig/ipvsadm
为什么RS上lo配置的VIP掩码为32位
这是由于lo设备的特殊性导致， 如果lo绑定VIP/24，则该设备会响应该网段所有IP(192.168.246.0-254)的请求，而不是只响应192.168.246.160这一个地址。,就算是不设置为32也是可以的，只不过会影响访问定义LVS分发策略
-A：添加VIP
-t：用的是tcp协议
-a：添加的是lo的vip地址
-r：转发到real-serve rip
-s：算法
-L|-l –list #显示内核虚拟服务器表
–numeric, -n：#以数字形式输出地址和端口号
-g –gatewaying #指定LVS工作模式为直接路由器模式（也是LVS默认的模式）
-S -save #保存虚拟服务器规则到标准输出，输出为-R 选项可读的格式
rr：轮循
如果添加ip错了，删除命令如下:
# ip addr del 192.168.246.193 dev ens33
[root@lvs-server ~]# ipvsadm -C #清除内核虚拟服务器表中的所有记录。
[root@lvs-server ~]# ipvsadm -A -t 192.168.246.160:80 -s rr
后端机器192.168.246.161：
[root@lvs-server ~]# ipvsadm -a -t 192.168.246.160:80 -r 192.168.246.161 -g
后端机器192.168.246.162：
[root@lvs-server ~]# ipvsadm -a -t 192.168.246.160:80 -r 192.168.246.162 -g
[root@lvs-server ~]# service ipvsadm save #保存方式一，使用下面的保存方式，版本7已经不支持了
[root@lvs-server ~]# ipvsadm -S > /etc/sysconfig/ipvsadm #保存方式二，保存到一个文件中
[root@lvs-server ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.246.160:80 rr
-> 192.168.246.161:80 Route 1 0 0
-> 192.168.246.162:80 Route 1 0 0
[root@lvs-server ~]# ipvsadm -L -n所有RS配置（另外两台都要做）
两个的nginx页面做区分，好看实验效果
配置好网站服务器，测试所有RS #为了测试效果，提供不同的页面（以下两台real-server都操作）
[root@real-server1 ~]# yum install -y nginx
[root@real-server1 ~]# echo "real-server1" >> /usr/share/nginx/html/index.html
两台机器都安装，按顺序添加不同的主机名以示区分
[root@real-server1 ~]# ip addr add dev lo 192.168.246.160/32 #在lo接口上绑定VIP
[root@real-server1 ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore #忽略arp广播
[root@real-server1 ~]# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce #匹配精确ip地址回包
[root@real-server1 ~]# systemctl start nginx
[root@real-server1 ~]# systemctl enable nginx
=============================================================================
因为：realServer的vip有了，接着就是同一个网段中拥有两个vip, 客户端在网关发送arp广播需找vip时需要让realServer不接受响应.
解决：
echo 1 >/proc/sys/net/ipv4/conf/eth0/arp_ignore
arp_ignore 设置为1，意味着当别人的arp请求过来的时候，如果接收的设备没有这个ip，就不做出响应(这个ip在lo上，lo不是接收设备的进口)
echo 2 >/proc/sys/net/ipv4/conf/eth0/arp_announce
使用最好的ip来回应，什么是最好的ip？同一个网段内子网掩码最长的测试
1）用浏览器访问VIP的IP
2）用另外的一个机器curl IP
3） 用另外的一个机器下载elinks(yum -y install elinks)
elinks -dump http://192.168.246.160 -dump:非交互式模式 结果跟curl类似
elinks http://192.168.246.160 页面跟浏览器类似
3. LVS的调度算法
LVS的调度算法分为静态与动态两类。
3.1 静态算法（4种）
只根据算法进行调度 而不考虑后端服务器的实际连接情况和负载情况
①.RR：轮叫调度（Round Robin）、轮询
将客户端请求平均分发到每台Real Server
②.WRR：加权轮叫（Weight RR）
调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
③.DH：目标地址散列调度（Destination Hash ）
将同样的请求发送给同一个server,一般用于缓存服务器.即将同一类型的请求分配给同一个后端服务器，例如将以 .jgp、.png等结尾的请求转发到同一个节点。这种算法其实不是为了真正意义的负载均衡，而是为了资源的分类管理。这种调度算法主要应用在使用了缓存节点的系统中，提高缓存的命中率。
④.SH：源地址 hash（Source Hash）
源地址散列”调度算法根据请求的源IP地址，
简单的说就是有将同一客户端的请求发给同一个real server,如果后端服务器工作正常没有超负荷的话。这可以解决session共享的问题，但是这里有个问题，很多企业、社区、学校都是共用的一个IP，这将导致请求分配的不均衡。
3.2 动态算法（6种）
前端的调度器会根据后端真实服务器的实际连接情况来分配请求
①.LC：最少链接（Least Connections）
调度器通过”最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用”最小连接”调度算法可以较好地均衡负载。
②.WLC：加权最少连接(默认采用的就是这种)（Weighted Least Connections）
根据Real Server 权重值，选择连接数最少的服务器。
③.SED：最短期望延迟调度（Shortest Expected Delay ）
不考虑非活动连接，谁的权重大，我们优先选择权重大的服务器来接收请求，但会出现问题，就是权重比较大的服务器会很忙，但权重相对较小的服务器很闲，甚至会接收不到请求，所以便有了下面的算法nq。
④.NQ：永不排队/最少队列调度（Never Queue Scheduling NQ）
无需队列。如果有台realserver的连接数＝0就直接分配过去，保证不会有一个主机很空间。
⑤.LBLC：基于局部性的最少链接（locality-Based Least Connections）
基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统｡该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器;若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器｡
⑥. LBLCR：带复制的基于局部性最少连接（Locality-Based Least Connections with Replication）
带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统｡它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射｡该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按”最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器｡同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。
暂无评论内容