使用LVS进行负载均衡

Linux ginotang 1743℃ 0评论

LVS的作用

LVS全称(Linux Virtual Server),主要作用是流量的负载均衡。通过把流量分配给不同的服务器,有效减轻各个服务器间的负载。现在lvs已经是内核标准的一部分,不需要另外安装,使用的时候只需要确保内核已经加载了lvs模块。LVS由两组服务器构成,分别是:

  • Director Server
  • Real Server

Director Server一般不提供其他服务,只实现流量的调度,根据策略把流量分配到Real Server

Real Server提供真实的服务,例如web server,MySQL等。

LVS的常用调度算法

当Director向Real Server转发请求的时候,会根据特定的算法来处理

静态调度

  • RR:轮询,把每个请求轮流分配跟每个Real Server,忽略服务器的处理能力
  • WRR:加权轮询,根据Real Server的负载和实际处理能力来分配请求
  • DH:目标地址hash,使用目标地址的hash值分配请求,即同一个目标地址的请求分配给相同的Real Server
  • SH:源地址hash,和DH一样,不同的是使用源地址作为hash

动态调度

  • LC:最少连接,把流量优先分配跟已建立连接最少的Real Server
  • WLC:加权最少连接, 在LC的基础上根据Real Server的当前负载情况添加权重

LVS的三种工作模式

NAT模式

nat模式的架构图如下:

lvs nat模式

lvs nat模式

nat工作模式:

  • 客户端向Director的virtual IP发送请求
  • Director根据设定好的规则匹配(一条规则通常包含ip地址、端口和协议三个部分)能匹配则按LVS策略转发数据给后端真实服务器
  • Real Server把响应发送给Director,Director把源IP地址设置为自己的Virtual IP,然后发送给客户端

nat模式的缺点:

无论是请求数据还是响应数据,都会经过Director服务器处理,这就对Director服务器的配置要求非常之高。而且网络流量都集中在Director身上,造成网络资源的不合理利用。

LVS NAT实战

环境准备

  • 3台虚拟机,一台作为Director Server,两台作为Real Server,提供http服务

  • Director 两块网卡,Virtual IP是192.168.11.3,Director IP是10.0.0.30

  • Real Server 1,ip地址10.0.0.31
  • Real Server 2,ip地址10.0.0.32

重点1:Director Server建议使用两块网卡,也可以使用一块网卡,但是配置起来十分麻烦

重点2:两台Real Server的网关必须指向Director的Director IP

Director Server最好关闭防火墙,例如iptables或firewalld,如果没有关闭需要把相关端口添加在去。

Director服务器配置

第一步:安装ipvsadm软件包

ipvsadm软件包是lvs的管理工具,只需要在Director服务器上安装

第二步:开启Director的路由转发

第三步:启动ipvsadm服务

第四步:添加lvs规则

第四步:查看lvs规则

Real Server配置

Real Server不需要配置什么,就是安装http web server,另外配置网关,使它指向Director的Director IP。
网关可以在网卡的配置文件中设置,这里是ens33。

保存lvs规则

ipvsadm软件包提供了ipvsadm-save和ipvsadm-restore命令,用于保存和还原lvs规则

DR模式

DR模式架构图

lvs direct routing模式

lvs direct routing模式

和nat模式不同的是,DR模式当中只有请求会经过Director,所有对客户端的响应由Real Server自己返回。好处是减轻Director的负载。

在这个模式当中,Director的工作流程如下:

  • 接收客户端的请求
  • 选择合适的Real Server,假设选择了Real Server 1
  • 把接收到的数据帧中的dst(destination) MAC地址修改为Real Server 1的MAC地址
  • 把数据转发给Real Server 1

配置DR模式

准备环境:

  • 两块网卡的Director(网卡其中一块网卡可以是虚拟网卡)
  • 3台虚拟机,1台Director,两台Real Server
  • Director设置两个ip,VIP:192.168.11.150,DIP:192.168.11.3
  • Real Server 1,VIP:192.168.11.150,DIP:192.168.11.4
  • Real Server 2,VIP:192.168.11.150,DIP:192.168.11.5
  • 客户端:用于访问web server,CIP:192.168.11.2

配置Director Server

第一步:设置ip地址

Director的两个ip地址为

也可以使用虚拟网卡,例如ens33:0

第二步:配置lvs转发规则

完成后检查规则是否正确

配置Real Server

第一步:添加VIP

VIP的子网掩码必须是255.255.255.255

然后使用ifconfig命令检查

第二步:关闭Real Server的ARP响应

这个步骤并没有完全关闭所有的arp响应,它是选择性地关闭。

到这里,所有工作都配置完毕,Real Server 2的配置也是这样。实际上,配置过程是非常简单的,但是我们必须要明白里面的原理,因此,我们提出了以下问题:

  • 为什么每个Real Server都必须有VIP
  • VIP为什么配置在本地回环(loopback)网络上
  • lo:0的掩码为什么是255.255.255.255

在回答这些问题之前,先了解一些知识

arp问题

Linux内核在设计上有一个问题:在arp运作的过程,它的立足点是对整台主机而言,而不是特定的网卡设备。也就是说,当一台有多块网卡的主机收到arp请求,只要这台主机上的任一网卡有目标地址(即使目标地址在loopback设备上面),它就会进行回应,而不管目标地址是不是在接收到数据包的网卡上面。

下面是对原文的引用:

Linux has a rather unusual design: it considers an IP address as belonging to a host rather than an interface, even though administrators always assign IP addresses to particular interfaces.This has impacts that some administrators complain about:

  • A Linux host replies to any ARP solicitation requests that specify a target IP address configured on any of its interfaces, even if the request was received on this host by a different interface. To make Linux behave as if addresses belong to interfaces, administrators can use the ARP_IGNORE feature described later in the section “/proc Options.”
  • Hosts can experience the ARP flux problem, in which the wrong interface becomes associated with an L3 address. This problem is described in the text that follows.

原文地址:Responding from Multiple Interfaces

假设一台主机上面的两块网卡处于同一个网络,另一台主机向它们发送arp请求,想要查询10.0.0.2的mac地址。两块网卡都会收到这个请求,同样,两块网卡都会作出响应。

lvs director routing arp问题

lvs director routing arp问题

整个过程类似下面的场景

  • Host A发送arp请求:请告诉我ip地址为10.0.0.2的mac是什么

  • Host B eth0:我就是10.0.0.2,我的mac地址是11:11:11:11:11:11

  • Host B eth1:它在eth0身上,它的mac地址是11:11:11:11:11:11

放到lvs dr的场景中,最终的结果是:Director和两台Real Server都响应了这个请求,造成网络混乱,我们的目的是只让Director响应VIP请求。

arp_ignore和arp_announce

要解决前面的arp问题,就要使用arp_ignore,它的常用值为

  • 0 只要目标ip地址在主机上就进行响应,不管ip地址在哪个网卡上。
  • 1 只响应目标ip地址在接收数据的网卡上的请求
  • 2 在1的基础上添加多一个条件:sender和接收请求的网卡在同一个子网
  • 8 不响应所有的arp请求

除了arp_ignore外,还有另一个内核参数arp_announce,arp_ignore用于控制响应,arp_announce则用于控制请求。它可以控制向外发出的arp请求,应该使用哪一个ip地址作为源ip地址。

我们说过,Director在转发数据的时候,只修改了目标MAC地址,那么数据帧的转变过程(接收过程)如下:

主机 源ip地址 源mac地址 目标ip地址 目标mac地址
客户端 192.168.11.2 00:50:56:C0:00:02 192.168.11.150 00:0c:29:66:79:fd(DIP MAC)
Director 192.168.11.2 00:50:56:C0:00:02 192.168.11.150 00:0c:29:a4:ac:80(RIP MAC)
Real Server 192.168.11.2 00:50:56:C0:00:02 192.168.11.150 00:0c:29:a4:ac:80(RIP MAC)

可以看到,数据帧在经过Director处理后已经成型,Real Server的mac地址已经被Director获取并更新到数据帧中,Real Server接收到这个数据的时候,会根据目标mac地址判断自己是否应该处理它,如果目标mac地址是自己则发出响应,否则丢弃。

现在回答第一个问题(为什么每个Real Server都必须有VIP)

从上表中可见,数据帧的目标ip地址始终是192.168.11.150,由于数据的对应关系,Real Server要处理接收到的数据,就必须有这个VIP,换种说法,由于目标mac地址(VIP MAC)是一个已知数,因此在数据接收过程不需要VIP,它只用于数据处理。

第二个问题(VIP为什么配置在本地回环(loopback)网络上)

loopback设备是一个本地设备,它对外是不可见的,既不发送arp请求,也没有arp响应,配合arp_ignore内核参数,可以确保客户端的请求被发往Director服务器,而不是Real Server上。

第三个问题(lo:0的掩码为什么是255.255.255.255)

如果将掩码设为255.255.255.0,那么表示lo:0和RIP处于同一子网,在数据返回的时候会优先选择lo:0,结果是数据返回失败,而掩码255.255.255.255可以区别出VIP和RIP是两个不同的子网,因此数据就能正确返回到客户端。

keepalived进行故障转移

通过keepalived,实现两台LVS服务器的故障转移,结构图如下:

lvs keepalive

lvs keepalive

当检测到master宕机,backup就会接管lvs的工作,实现VIP的飘移。

安装keepalived

centos7仓库种的版本是1.2.3,如果希望使用更新的版本,可以到官网下载

配置keepalived

通过keepalived,我们不需要自己配置VIP,也不需要使用ipvsadm配置转发规则,它们都由keepalived负责完成。Real Server依然由用户自己配置。

keepalived配置文件路径为:/etc/keepalived/keepalived.conf,我们可以删除一些它里面原有的内容。

master配置

主要有三个区段要配置:vrrp_instance、virtual_server和real_server

主从配置基本一样,就是角色和优先级那里不同:

配置完成后就可以启动keepalived服务。

一些问题

启动keepalived后先检查配置是否正确:

  • 确保你的VIP正确

    当启动keepalived后,我发现VIP的默认网络号是32位,显然是不正确的,我们需要的是24位网络号,因此在keepalived.conf中就要显式设置

  • 检查转发规则

    正常情况下,主从服务器都已经配置好规则

  • 检查VIP是否已经启动

    注意我们不能用ifconfig命令查看,只能使用ip addr

    只能有一台Director服务器有VIP。

另外,如果VIP已经起来,防火墙其他都设置正确,依然不能ping通VIP,那么需要把keepalived.conf里面的vrrp_strict注释掉,这样应该就可以了。

转载请注明:Pure nonsense » 使用LVS进行负载均衡

喜欢 (0)
0 0 投票数
文章评分
订阅评论
提醒
guest
0 评论
内联反馈
查看所有评论
0
希望看到您的想法,请您发表评论x
()
x