Linux企业运维——LVS负载均衡

（临时笔记，以后会详细修补）

文章目录

• • Linux企业运维——LVS负载均衡
  • • 1、LVS简介
    • 2、DR模式
    • 3、使用DR模式实现负载均衡
    • 4、问题解决
    • 5、LVS的10个调度算法简介

1、LVS简介

LVS（Linux Virtual Server）即Linux虚拟服务器，是一个虚拟的服务器集群系统，可以在unix/linux平台下实现负载均衡集群功能。LVS是一种集群(Cluster)技术，采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。

根据LVS工作模式的不同，真实服务器会选择不同的方式将用户需要的数据发送到终端用户，LVS工作模式分为NAT模式、TUN模式、以及DR模式。

2、DR模式

• DR模式：通过直接路由实现虚拟服务器。DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器响应后的处理结果直接返回给客户端用户。DR模式可以极大的提高集群系统的伸缩性，而且DR模式没有IP隧道的开销，对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器与真实服务器都有一块网卡连接到同一物理网段上，必须在同一个局域网环境。
• 原理：LVS通过控制IP来实现负载均衡。ipvsadm是其具体的实现模块。
• ipvsadm的主要作用：安装在调度器上面，在调度器上虚拟一个对外访问的IP（VIP）。用户访问VIP，到达调度器，调度器根据一定的规则选择一个真实服务器，处理完成后然后返回给客户端数据。

3、使用DR模式实现负载均衡

（1）实验环境：server1为调度器，负载流量均衡（基于4层即传输层进行调度，调度算法有WRR/WLC等，传输协议为TCP/UDP），server2和server3为真实服务器节点。

（2）server1安装ipvsadm（用于用户端管理LVS的策略规则）

（3）书写策略：在server1上添加虚拟一个对外访问的IP：172.25.33.100（vip），即提供虚拟服务的ip地址，也可以直接用原有IP，但最好独立出来

（4）ipvsadm -A 添加规则；-t tcp协议；-s 调度；rr 轮叫

• -a向tcp虚拟服务添加
• -r real server
• -g 直连即DR模式

ipvsadm -ln：查看当前连接情况（-ln不用解析），

Forward：转发方式，当前是路由转发；

Weight：权重；

ActiveConn：当前活跃的连接数；

InActConn：当前不活跃的连接数

（5）server2和server3安装httpd服务，并开启

此时真机使用

curl 172.25.33.2

可以显示server的发布页面，但

curl 172.25.33.100

没有反应，这是因为LVS-DR集群类型要求，当用户向vip发起请求时，调度器和真实服务器上必须都要有vip，因此需要给server2和server3添加虚拟IP。

（6）server2和server3分别添加vip

此时真机使用curl 172.25.33.100，出现轮叫

（7）ARP协议是将IP地址映射为MAC地址的协议，其在协议上使用ARP请求及ARP应答报文来实现

arp -d

是删除ARP缓存列表的命令，可以删除所有的ARP缓存，也可以删除指定的ARP缓存

此时使用

arp -an

查看本地ARP缓存的172.25.33.100对应的MAC地址为调度器server1的地址，当真机执行

arp -d

删除指定虚拟IP的ARP缓存后，此时不能过滤得到172.25.33.100的MAC地址。再次Ping之后又可以得到，但是是server3的地址，不是调度器的地址（谁先响应就缓存谁的MAC地址）

此时

curl 172.25.33.100

，只出现了server3的发布页面，说明此时客户端向vip发起请求时，并没有经过调度器直接到达了真实服务器

（8）为了解决这一问题，需要给server2和server3安装ARP防火墙arptables（用于管理内核中的ARP包过滤规则表）

设定APR配置规则，DR模式要求服务器节点应该禁掉设备的APR响应

arptable_filter 只有一个表 filter ，不指定 -t 表名时默认就是 filter 表。

filter表有三个链，一个是INPUT，表示外面发进来的ARP包；另外一个是OUTPUT，表示本机发出的ARP包；第三个是FORWARD，转发ARP包。

-A：向规则链中追加规则；

-d：指定要匹配ARP包的目的IP地址；

-j：指定满足添加的规则时执行的动作；

-s：指定要匹配ARP包的源ip地址；

-g：直连

-r：真实服务器地址

当数据包的目的地址时100时就丢弃该数据包，当从本机发送出的数据包IP是100时，mangle转换数据包源地址，伪装源地址IP为172.25.0.2。

设定完毕，保存arptables规则，此时重启arptables服务后，即可看到所添加的规则。

此时当真机执行arp -d 删除指定的虚拟IP，ping 之后，过滤得到172.25.33.100的MAC地址是server1的MAC地址，此时使用

curl 172.25.33.100

，可以轮叫

【 client->DR-RS->clinet】

1：DR和RS在同一个vlan（局域网）中，DR和RS的vip会冲突，数据包必须在DR修改mac,丢弃RS的vip，mac在二层数据链路层，不支持路由，所以DR和RS需要在同一vlan

2：DR>Tunnel（隧道模式）>NAT（dnat和snat，进出各1此，数据是原路经返回）>fullNAT（进2次出2次）

3：ipvs和iptables，iptables>ipvs，firewall不需要地址转换

4、问题解决

1、某台REALServer down 了，怎么办

此时

curl 172.25.33.100

已经无法访问server2，客户端

curl 172.25.33.100

会报错

但是在server1中ipvsadm -ln 仍能检测到server2

解决办法：

使调度策略实时更新

server1：

（1）yum install keepalived （健康检测）

ipvsadm没有健康检测功能，即检测策略对应的后端服务是否正常，因此我们需要安装keepalived

（2）yum install postfix mailx

（3）修改keepalived的主配置文件/etc/keepalived/keepalived.conf

（vrrp虚拟路由冗余协议，keepalived利用这一协议实现了高可用）

notification_email：设置通知邮件，出了问题给谁发送邮件notification_email_from：由谁发送

超时

路由id

注释vrrp_strict，这一参数功能是在出问题时抓取数据包

主虚拟路由MASTER：向所有备用虚拟路由BACKUP发送“心跳包”，备用虚拟路由只负责接收，当备用虚拟路由接收不到时，priority优先级最高的备用虚拟路由代替MASTER提供虚拟服务，数字越高，优先级越高，所以MASTER优先级数字一定要最大

虚拟路由id：确认哪些虚拟路由是同一个LVS集群的; 修改vip:改成自己设置的vip；

虚拟服务语句块：

delay_loop：每s/次健康检测；

lb_algo：调度算法；

persistence_timeout：持久连接，即在多长时间内DR会将所有连接请求持续调度给一个后端；（80端口没必要） 写真实服务器模块

（之后的删掉）

（4）此时删掉server1上手动设置的虚拟ip172.25.33.100，

ipvsadm -C

清除设置的规则，启动keepalived软件

ipvsadm -ln

能看到虚拟ip172.25.33.100由keepalived自动生成

stop server2的httpd服务

查看日志，查看日志提示的邮件，可以知道哪台真实主机up或者down；

ipvsadm -ln

将检测不到server

注意：如果server1也安装了httpd服务，curl 172.25.33.100不会访问server1的80

2、lvs down怎么办（LVS冗余，高可用）：

（1）server1停止httpd服务

（2）创建虚拟机快照文件server4（高可用（master>backup）），同样的修改其主机名和IP

server4安装keepalived，并拷贝server1的keepalived.conf文件

（3）在server4上修改BACKUP、优先级

重启keepalived服务，之后安装ipvsadm（用于管理LVS的策略规则）

ipvsadm -ln：查看当前连接情况

查看server4的日志，可以看到此时的server4是BACKUP

当server1停止keepalived服务后，再次查看server4的日志，可以看到此时的server4是MASTER

过滤得到172.25.33.100的MAC地址是server4的MAC地址

再次开启server1的 keepalived服务后，过滤得到172.25.0.100的MAC地址是server1的MAC地址，此时server4为BACKUP

5、LVS的10个调度算法简介

1.轮询调度（Round Robin 简称’RR’）算法就是按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点就是实现简单。轮询算法假设所有的服务器处理请求的能力都一样的，调度器会将所有的请求平均分配给每个真实服务器。

2.加权轮询调度（Weight Round Robin 简称’WRR’）算法主要是对轮询算法的一种优化与补充，LVS会考虑每台服务器的性能，并给每台服务器添加一个权值，如果服务器A的权值为1，服务器B的权值为2，则调度器调度到服务器B的请求会是服务器A的两倍。权值越高的服务器，处理的请求越多。

3.最小连接调度（Least Connections 简称’LC’）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态的调度算法，它通过服务器当前活跃的连接数来估计服务器的情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中断或者超时，其连接数减1。（集群系统的真实服务器具有相近的系统性能，采用最小连接调度算法可以比较好地均衡负载。)

4.加权最小连接调度（Weight Least Connections 简称’WLC’）算法是最小连接调度的超集，各个服务器相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

5.基于局部的最少连接调度（Locality-Based Least Connections 简称’LBLC’）算法是针对请求报文的目标IP地址的 负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和Cache命中率，从而提升整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则使用’最少连接’的原则选出一个可用的服务器，将请求发送到服务器。

6.带复制的基于局部性的最少连接（Locality-Based Least Connections with Replication 简称’LBLCR’）算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统，它与LBLC算法不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。按’最小连接’原则从该服务器组中选出一一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按’最小连接’原则从整个集群中选出一台服务器，将该服务器加入到这个服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

7.目标地址散列调度（Destination Hashing 简称’DH’）算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且并未超载，将请求发送到该服务器，否则返回空。

8.源地址散列调度（Source Hashing 简称’SH’）算法先根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且并未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同，它的算法流程与目标地址散列调度算法的基本相似。

9.最短期望的延迟调度（Shortest Expected Delay 简称’SED’）算法基于WLC算法。举个例子，ABC三台服务器的权重分别为1、2、3 。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用SED算法后会进行一个运算

A：（1+1）/1=2

B：（1+2）/2=3/2

C：（1+3）/3=4/3

就把请求交给得出运算结果最小的服务器。

10.最少队列调度（Never Queue 简称’NQ’）算法，无需队列。如果有realserver的连接数等于0就直接分配过去，不需要在进行SED运算。