lvs负载调度算法

‘壹’ U8服务器参数配置中负载均衡如何设置

网络的负载均衡是一种动态均衡技术，通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理均衡地分配出去。这种技术基于现有网络结构，提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法，加强了网络数据处理能力，提高了网络的灵活性和可用性。

‘贰’ 大家企业中lvs都是用什么调度算法

看原理，适用什么场合吧。毕竟调度算法有10种之多。一般是rr/wrr/wlc/lc什么的。

‘叁’ lvs负载均衡（简介，三种工作模式，四种常用算法）

一，lvs简介

LVS是linux Virtual Server的简称，也就是Linux虚拟服务器，是一个由章文嵩博士发起的自由软件项目，官方站点是： http://www.linuxvirtualserver.org 。现在LVS已经是Linux标准内核的一部分，在Linux2.4内核以前，使用LVS时必须重新编译内核以支持LVS功能模块，但是从Linux2.4内核心之后，已经完全内置了LVS的各个功能模块，无需给内核打任何补丁，可以直接使用LVS提供的各种功能。使用LVS技术要达到的目标是：通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能，高可用的服务器群集，它具有良好的可靠性、可扩展性和可操作性。从而以兄棚野低廉的成本实现最优的服务性能。

二，三种工作模式

1、基于NAT的LVS模式负载均衡

也就是网络地址翻译技术实现虚拟服务器，当用户请求到达调度器时，调度器将请求报文的目标地址（即虚拟IP地址）改写成选定的Real Server地址，同时报文的目标端口也改成选定的Real Server的相应端口，***将报文请求发送到选定的Real Server。在服务器端得到数据后，Real Server返回数据给用户时，需要再次经过负载调度器将报文的源地址和源端口改成虚拟IP地址和相应端口，然后把数据发送给用户，完成整个负载调度过程。可以看出，在NAT方式下，用户请求和响应报文都必须经过Director Server地址重写，当用户请求越来越多时，调度器的处理能力将称为瓶颈。

2，基于TUN的LVS负载均衡

也就是IP隧道技术实现虚拟服务器。它的连接调度和管理与VS/NAT方式一样，只是它的报文转发方法不同，VS/TUN方式中，调度器采用IP隧道技术将用户请求转发到某个Real Server，而这个Real Server将直接响应用户的请求，不再经过前端调度器，此外，对Real Server的地域位置没有要求，可以和Director Server位于同一个网段，也可以是独立的一个网络。因此，在TUN方式中，调度器将只处理用户的报文请求，集群系统的吞吐量大大提高。

用的很少，图省略

3，基于DR的LVS负载均衡

也就是用直接路由技术实现虚拟服务器。它的连接调度和管理与VS/NAT和VS/TUN中的一样，但它的报文转发方法又有不同，VS/DR通过改写请求报文的MAC地址，将请求发送到Real Server，而Real Server将响应直接返回给客户，免去了VS/TUN中的IP隧道开销。这种方式是三种负载调度机制中性能最好的，但是必须要求Director Server与Real Server都有一块网卡连在同一物理网段上。

三，LVS负载均衡调度算法

上面我们谈到，负载调度器是根据各 个服务器的负载情况，动和或态地选择一台Real Server响应用户请求，那么动态选择是如何实现呢，其实也就是我们这里要说的负载调度算法，根据不同的网络服务需求和服务器配置，IPVS实现了如下 八种负载调度算法，这里我们详细讲述最常用的四种调度算法，剩余的四种调度算法请参考其它资料。

3.1  轮叫调度（Round Robin）

“轮叫”调度也叫1:1调度，调度器通过羡喊“轮叫”调度算法将外部用户请求按顺序1:1的分配到集群中的每个Real Server上，这种算法平等地对待每一台Real Server，而不管服务器上实际的负载状况和连接状态。

3.2  加权轮叫调度（Weighted Round Robin）

“加 权轮叫”调度算法是根据Real Server的不同处理能力来调度访问请求。可以对每台Real Server设置不同的调度权值，对于性能相对较好的Real Server可以设置较高的权值，而对于处理能力较弱的Real Server，可以设置较低的权值，这样保证了处理能力强的服务器处理更多的访问流量。充分合理的利用了服务器资源。同时，调度器还可以自动查询Real Server的负载情况，并动态地调整其权值。

3.3  最少链接调度（Least Connections）

“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最小连接”调度算法可以较好地均衡负载。

3.4  加权最少链接调度（Weighted Least Connections）

“加权最少链接调度”是“最少连接调度”的超集，每个服务节点可以用相应的权值表示其处理能力，而系统管理员可以动态的设置相应的权值，缺省权值为1，加权最小连接调度在分配新连接请求时尽可能使服务节点的已建立连接数和其权值成正比。

其它四种调度算法分别为：基于局部性的最少链接（Locality-Based Least Connections）、带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）、目标地址散列（Destination Hashing）和源地址散列（Source Hashing），对于这四种调度算法的含义，本文不再讲述，如果想深入了解这其余四种调度策略的话，可以登陆LVS中文站点 zh.linuxvirtualserver.org，查阅更详细的信息。

‘肆’ 如何配置Web服务器实现负载均衡

网络的负载均衡是一种动态均衡技术，通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理均衡地分配出去。这种技术基于现有网络结构，提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法，加强了网络数据处理能力，提高了网络的灵活性和可用性。

以四台服务器为例实现负载均衡：

安装配置LVS

1. 安装前准备：

(1)首先说明，LVS并不要求集群中的服务器规格划一，相反，可以根据服务器的不同配置和负载状况，调整负载分配策略，充分利用集群环境中的每一台服务器。如下表：

Srv Eth0 Eth0：0 Eth1 Eth1：0

vs1 10.0.0.1 10.0.0.2 192.168.10.1 192.168.10.254

vsbak 10.0.0.3 192.168.10.102

real1 192.168.10.100

real2 192.168.10.101

其中，10.0.0.2是允许用户访问的IP。

(2)这4台服务器中，vs1作为虚拟服务器(即负载平衡服务器)，负责将用户的访问请求转发到集群内部的real1，real2，然后由real1，real2分别处理。
Client为客户端测试机器，可以为任意操作系统。

(3)所有OS为redhat6.2，其中vs1 和vsbak 的核心是2.2.19， 而且patch过ipvs的包， 所有real
server的Subnet mask 都是24位， vs1和vsbak 的10.0.0. 网段是24 位。

2.理解LVS中的相关术语

(1) ipvsadm ：ipvsadm是LVS的一个用户界面。在负载均衡器上编译、安装ipvsadm。

(2) 调度算法： LVS的负载均衡器有以下几种调度规则：Round-robin，简称rr;weighted
Round-robin，简称wrr;每个新的连接被轮流指派到每个物理服务器。Least-connected，简称lc;weighted
Least-connected，简称wlc，每个新的连接被分配到负担最小的服务器。

(3) Persistent client
connection，简称pcc，(持续的客户端连接，内核2.2.10版以后才支持)。所有来自同一个IP的客户端将一直连接到同一个物理服务器。超时时间被设置为360秒。Pcc是为https和cookie服务设置的。在这处调度规则下，第一次连接后，所有以后来自相同客户端的连接(包括来自其它端口)将会发送到相同的物理服务器。但这也会带来一个问题，因为大约有25%的Internet
可能具有相同的IP地址。

(4) Persistent port
connection调度算法：在内核2.2.12版以后，pcc功能已从一个调度算法(你可以选择不同的调度算法：rr、wrr、lc、wlc、pcc)演变成为了一个开关选项(你可以让rr、
wrr、lc、wlc具备pcc的属性)。在设置时，如果你没有选择调度算法时，ipvsadm将默认为wlc算法。 在Persistent port
connection(ppc)算法下，连接的指派是基于端口的，例如，来自相同终端的80端口与443端口的请求，将被分配到不同的物理服务器上。不幸的是，如果你需要在的网站上采用cookies时将出问题，因为http是使用80端口，然而cookies需要使用443端口，这种方法下，很可能会出现cookies不正常的情况。

(5)Load Node Feature of Linux Director：让Load balancer 也可以处理users 请求。

(6)IPVS connection synchronization。

(7)ARP Problem of LVS/TUN and LVS/DR：这个问题只在LVS/DR，LVS/TUN 时存在。

3. 配置实例

(1) 需要的软件包和包的安装：

I. piranha-gui-0.4.12-2*.rpm (GUI接口cluster设定工具);

II. piranha-0.4.12-2*.rpm;

III. ipchains-1.3.9-6lp*.rpm (架设NAT)。

取得套件或mount到光盘，进入RPMS目录进行安装:

# rpm -Uvh piranha*

# rpm -Uvh ipchains*

(2) real server群：

真正提供服务的server(如web
server)，在NAT形式下是以内部虚拟网域的形式，设定如同一般虚拟网域中Client端使用网域：192.168.10.0/24
架设方式同一般使用虚拟IP之局域网络。

a. 设网卡IP

real1 ：192.168.10.100/24

real2 ：192.168.10.101/24

b.每台server均将default gateway指向192.168.10.254。
192.168.10.254为该网域唯一对外之信道，设定在virtual server上，使该网域进出均需通过virtual server 。

c.每台server均开启httpd功能供web server服务，可以在各real server上放置不同内容之网页，可由浏览器观察其对各real
server读取网页的情形。

d.每台server都开启rstatd、sshd、rwalld、ruser、rsh、rsync，并且从Vserver上面拿到相同的lvs.conf文件。

(3) virtual server：

作用在导引封包的对外主机，专职负责封包的转送，不提供服务，但因为在NAT型式下必须对进出封包进行改写，所以负担亦重。

a.IP设置：

对外eth0：IP：10.0.0.1 eth0：0 ：10.0.0.2

对内eth1：192.168.10.1 eth1：0 ：192.168.10.254

NAT形式下仅virtual server有真实IP，real server群则为透过virtual server.

b.设定NAT功能

# echo 1 >; /proc/sys/net/ipv4/ip_forward

# echo 1 >; /proc/sys/net/ipv4/ip_always_defrag

# ipchains -P forward MASQ

c.设定piranha 进入X-window中 (也可以直接编辑/etc/lvs.cf )

a).执行面板系统piranha

b).设定“整体配置”(Global Settings) 主LVS服务器主机IP：10.0.0.2， 选定网络地址翻译(预设) NAT路径名称：
192.168.10.254， NAT 路径装置： eth1：0

c).设定虚拟服务器(Virtual Servers) 添加编辑虚拟服务器部分：(Virtual
Server)名称：(任意取名);应用：http;协议： tcp;连接：80;地址：10.0..0.2;装置：eth0：0; 重入时间：180
(预设);服务延时：10 (预设);加载监控工具：ruptime (预设);调度策略：Weighted least-connections; 持续性：0
(预设); 持续性屏蔽： 255.255.255.255 (预设); 按下激活：实时服务器部分：(Real Servers); 添加编辑：名字：(任意取名);
地址： 192.168.10.100; 权重：1 (预设) 按下激活

另一架real server同上，地址：192.168.10.101。

d). 控制/监控(Controls/Monitoring)
控制：piranha功能的激活与停止，上述内容设定完成后即可按开始键激活piranha.监控器：显示ipvsadm设定之routing table内容
可立即更新或定时更新。

(4)备援主机的设定(HA)

单一virtual server的cluster架构virtual server 负担较大，提供另一主机担任备援，可避免virtual
server的故障而使对外服务工作终止;备份主机随时处于预备状态与virtual server相互侦测

a.备份主机：

eth0： IP 10.0.0.3

eth1： IP 192.168.10.102 同样需安装piranha，ipvsadm，ipchains等套件

b.开启NAT功能(同上面所述)。

c.在virtual server(10.0.0.2)主机上设定。

a).执行piranha冗余度 ;

b).按下“激活冗余度”;

冗余LVS服务器IP： 10.0.0.3;HEARTBEAT间隔(秒数)： 2 (预设)

假定在…秒后进入DEAD状态： 5 (预设);HEARTBEAT连接端口： 539 (预设)

c).按下“套用”;

d).至“控制/监控”页，按下“在当前执行层添加PULSE DEAMON” ，按下“开始”;

e).在监控器按下“自动更新”，这样可由窗口中看到ipvsadm所设定的routing table，并且动态显示real
server联机情形，若real server故障，该主机亦会从监视窗口中消失。

d.激活备份主机之pulse daemon (执行# /etc/rc.d/init.d/pulse start)。

至此，HA功能已经激活，备份主机及virtual server由pulse daemon定时相互探询，一但virtual
server故障，备份主机立刻激活代替;至virtual server 正常上线后随即将工作交还virtual server。

LVS测试

经过了上面的配置步骤，现在可以测试LVS了，步骤如下：

1. 分别在vs1，real1，real2上运行/etc/lvs/rc.lvs_dr。注意，real1，real2上面的/etc/lvs
目录是vs2输出的。如果您的NFS配置没有成功，也可以把vs1上/etc/lvs/rc.lvs_dr复制到real1，real2上，然后分别运行。确保real1，real2上面的apache已经启动并且允许telnet。

2. 测试Telnet：从client运行telnet 10.0.0.2，
如果登录后看到如下输出就说明集群已经开始工作了：(假设以guest用户身份登录)

[guest@real1 guest]$——说明已经登录到服务器real1上。

再开启一个telnet窗口，登录后会发现系统提示变为：

[guest@real2 guest]$——说明已经登录到服务器real2上。

3. 测试http：从client运行iexplore http://10.0.0.2

因为在real1 和real2 上面的测试页不同，所以登录几次之后，显示出的页面也会有所不同，这样说明real server 已经在正常工作了。

‘伍’ NAT原理总结

由于网络的飞速发展和网络应用的极速增多，致使IPv4可用地址空间逐渐枯竭。尽管IPv6可以在根本上解决地址枯竭问题，但IPv4发展到IPv6还需要一个过渡，而这便产生了NAT。

IP地址分为公网IP与私网IP。一般情况下，在互联网中，公网IP可直接访问，私网IP无法直接访问。而NAT则是将私网IP地址转换为公网IP地址（将IP报文头部的私网IP地址改为可以提供访问的公网IP地址），从而实现用户上网功能或服务器在互联网上提供服务。NAT还可以使得一个公网IP代表多个不同的内网IP，这样便节省了IP地址资源。

NAT分为静态转换、动态转换、端口转换

公司（有固定公网IP地址）上网访问某网站简易过程

实现SNAT和DNAT都需要开启内核数据转发功能

基于nat表的target，适用于固定的公网IP

SNAT选项：

语法：

范例：

nat表的target，适用于端口映射，即可重定向到本机，也可以支持重定向至不同主机的不同端口，但不支持多目标，即不支持负载均衡功能

DNAT选项：

DNAT语法：

范例：

CentOS 7、8

CentOS 6

iptables-restore选项

用规则文件保存各规则，开机时自动载入此规则文件中的规则

在/etc/rc.d/rc.local文件添加

范例: CentOS 7，8 使用 iptables-services

LVS由前端的负载均衡器(Load Balancer，LB)和后端的真实服务器(Real Server，RS)群组成。RS间可通过局域网或广域网连接。LVS的这种结构对用户是透明的，用户只能看见一台作为LB的虚拟服务器(Virtual Server)，而看不到提供服务的RS群。当用户的请求发往虚拟服务器，LB根据设定的包转发策略和负载均衡调度算法将用户请求转发给RS。RS再将用户请求结果返回给用户。

1.当客户端的请求到达负载均衡器的内核空间时，首先会到达PREROUTING链。

2.当内核发现请求数据包的目的地址是本机时，将数据包送往INPUT链。

3.LVS由用户空间的ipvsadm和内核空间的IPVS组成，ipvsadm用来定义规则，IPVS利用ipvsadm定义的规则工作，IPVS工作在INPUT链上,当数据物绝包到达INPUT链时，首先会被IPVS检查，如果数据包里面的目的地址及端口没有在规则里面，那么这条数据包将被放行至用户空间。

4.如果数据包里面的目的地址及端口在规则里面，那么这条数据报文将被修改目的地址侍猜为事先定义好的后端服务器，并送往POSTROUTING链。

5.最后经由POSTROUTING链发往后端服务器。

注意：在NAT模式中，Real Server的网关必须指向LVS，否则报文无法送达客户端。

注意：需要设置lo接口的VIP不能响应本地网络内的arp请求。

①.客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。

②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将在客户罩谈姿端请求报文的首部再封装一层IP报文,将源地址改为DIP，目标地址改为RIP,并将此包发送给RS。

③.RS收到请求报文后，会首先拆开第一层封装,然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP，所以会处理次请求报文，并将响应报文通过lo接口送给eth0网卡直接发送给客户端。

注意：需要设置lo接口的VIP不能在共网上出现。

LVS的调度算法分为静态与动态两类。

‘陆’ linux运维之LVS（一）

关于LVS负载均衡

一、什么是负载均衡：

    负载均衡集群提供了一种廉价、有效、透明的方法，来扩展网络设备和

服务器的负载、带宽、增加吞吐量、加强网络数据处理能力，提高网络的灵活性

和可用性。

二、搭建负载均衡服务的需求：

1）把单台计算机无法承受的大规模的并发访问或者数据流量分担到多台节点设备上

分别处理，减少用户等待响应的时间，提升用户体验。

2）单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备结束后，

将结果汇总，返回给用户，系统处理能力得到大幅度提升。

3）7*24的服务保证，任意一个或多个有限节点设备宕机，要求不能影响业务。

三、LVS的介绍：

    LVS是Linux Virtual Server的简写，即Linux虚拟服务器，是一个虚拟的服务器

集群系统，可以在UNIX/LINUX平台下实现负载均衡集群功能。

    该项目是在1998年5月由章文嵩博士组织成立的，是中国国内最早出现的自由

软件项目之一。

四、关于LVS的配置使用：

    LVS负载均衡调度技术是在Linux内核中实现的，因此，被称为Linux

虚拟服务器。我们使用该软件配置LVS时候，不能直接配置内核中的ipvs，

而需要使用ipvs的管理工具ipvsadm进行管理，ipvs的管理工具ipvsadm管理ipvs。

五、LVS技术点小结：

1）真正实现负载均衡的工具是ipvs，工作在linux内核层面。

2）LVS自带的ipvs管理工具是ipvsadm。

3）keepalived实现管理ipvs及对负载均衡器的高可用。

4）Red hat工具Piranha WEB管理实现调度的工具ipvs。

六、LVS体系结构与工作原理：

1）LVS集群负载均衡接收服务的所有入站客户端计算机请求，并根据调度算法决定哪个集群节点应该处理回复请求。

负载均衡（LB）有时也被称为LVS Director(简称 Director).

2）LVS虚拟服务器的体系结构如下图，一组服务器通过高速的局域网或者地理分布

的广域网相互连接，在他们的前端有一个负载调度器（Load Balancer）。负载调度器能

无缝地将网络请求调度到真正的服务器上，从而使得服务器集群的结构对客户是透明的，

客户访问集群系统提供的网络服务就像访问一台高性能、高可用的服务器一样。客户程序

不受服务器集群的影响不需做任何修改。系统的伸缩性通过在服务集群中透明地加入和删除

一个节点来达到，通过检测节点或服务进程故障和正确的重置系统达到高可用性。由于我们的负载调度技术在

linux内核中实现的，我们称之为linux虚拟服务器（Linux Virtual Server）。

七、LVS社区提供了一个命名的约定：

名称：                              缩写         

虚拟IP地址（Virtual IP Address）    VIP

说明：VIP为Director用于向客户端计算机提供服务的ip地址，

比如：www.etiantian.org 域名就解析到vip上提供服务。

-------------------------------------------------------------------------------

真实ip地址(Real Server ip Address)    缩写：VIP

说明：在集群下面节点上使用的ip地址，物理ip地址。

-----------------------------------------------------------------------------------

Director的ip地址(Director ip Adress)  缩写：DIP

说明：Director用于连接内外网络的ip地址，物理网卡上的IP地址，

是负载均衡上的ip。

-------------------------------------------------------------------------------------

客户端主机IP地址(Client IP Address)  缩写：CIP

说明：客户端用户计算机请求集群服务器的IP地址，该地址用作发送

给集群的请求的源ip地址。

----------------------------------------------------------------

LVS集群内部的节点称为真实服务器(Real server)，也叫做集群节点。请求集群服务的

计算机称为客户端计算机。

与计算机通常在网上交换数据包的方式相同，客户端计算机、Director

和真实服务器使用IP地址彼此进行通信。

------------------------------------------------------------------------------------------

八、LVS集群的3种工作模式介绍与原理讲解

1）IP虚拟服务软件ipvs，在调度器的实现技术中，IP负载均衡技术是

效率最高的。在已用的ip负载均衡技术中有通过网络地址转换

（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，

我们称之为VS、NAT技术（Virtual Server Network Adress Translation）。

2）在分析VS/NAT的缺点和网络服务的非对称性的基础上，我们提出通过IP隧道实现虚拟服务器的

方法VS/TUN(Virtual Server via IP Tunneling)和通过直接路由实现虚拟服务

器的方法VS/DR(Virtual Server via Director Routing),它们可以极大地提高系统的伸缩性。

3）淘宝开源的模式FULLNAT。

LVS的四种工作模式：

    缩写及全拼：

NAT(Network Adress Translation)、TUN(Tunneling)、

DR(Director Routing)、FULLNAT(FULL Network address Translation)

-------------------------------------------------------------------------------------------

九、什么是ARP协议：

1) ARP协议：全称"Address Resolution Protocol"，中文名地址解析协议，使用ARP协议可

实现通过IP地址获得得对应主机的物理地址(MAC地址)。

  在TCP/IP的网络环境下，每个联网的主机都会被分配一个32位的ip地址，

  这种互联网地址是在网际范围标识主机的一种逻辑地址。为了让报文在

物理网路上传输，还必须要知道对方目的主机的物理地址(MAC)才行。这样就存在把IP地址变成

物理地址的地址转换的问题。

    在以太网环境，为了正确地目的主机传送报文，必须把目的主机的32位IP

地址转换成为目的主机48位以太网的地址(MAC地址)。这就需要在互联层有一个服务或功能将

IP地址转换为相应的物理地址(MAC地址)，这个服务或者功能就是ARP协议。

    所谓的“地址解析”，就是主机在发送帧之前将目标IP地址转换成目标MAC地址的过程，

ARP协议的基本功能就是通过目标设备的ip地址，查询目标设备的MAC地址，以保证主机

间互相通信的顺利进行。

    ARP协议和DNS有点相像之处，不同点是：DNS是在域名和IP之间的解析，另外，ARP协议不需要

配置服务，而DNS要配置服务才行。

    ARP协议要求通信的主机双方必须在同一个物理网段(即局域网)!

2)关于ARP的小结：

1.ARP全称“Address Resolution Protocol”；

2.实现局域网内通过IP地址获取主机的MAC地址；

3.MAC地址48位主机的物理地址，局域网内唯一；

4.ARP协议类似DNS服务，但不需要配置服务。

5.ARP协议是三层协议。

--------------------------------------------------------------------------------------------------------

十、ARP缓存表：

1）每台安装有TCP/IP协议的电脑都会有一个ARP缓存表(windows 命令提示符里输入arp -a即可)。

  表里的ip地址与MAC地址是一一对应的。

arp常用命令:

    arp -a :查所有记录

    arp -d ：清除

    arp -s ：绑定IP和MAC

2）ARP缓存表是把双刃剑：

1.主机有了arp缓存表，可以加快ARP的解析速度，减少局域网内广播风暴。

2.正是有了arp缓存表，给恶意黑客带来了攻击服务器主机的风险，这个就是arp欺骗攻击。

3.切换路由器，负载均衡器等设备时，可能会导致短时网络中断。

3）为啥用ARP协议？

  OSI模型把网络工作分为七层，彼此不直接通信打交道，只通过接口。IP地址工作在第三层，

MAC地址工作在第二层。当协议在发送数据包时，需要先封装第三层IP地址，第二层MAC地址的报头，

但是协议只知道目的节点的ip地址，不知道目的节点的MAC地址，又不能跨第二、三层，所以得用ARP协议服务，

来帮助获取目的节点的MAC地址。

4）ARP在生产环境产生的问题及解决办法：

1.ARP病毒，ARP欺骗

2.高可用服务器对之间切换时要考虑ARP缓存的问题。

3.路由器等设备无缝迁移时需要考虑ARP缓存的问题，例如：更换办公室的路由器。

5）ARP欺骗原理：

  ARP攻击就是通过伪造IP地址和MAC地址对实现ARP欺骗的，如果一台主机中了ARP病毒，

那么它就能在网络中产生大量的ARP通信量，很快的进行广播以至于使网络阻塞，攻击者

只要持续不断的发出伪造的ARP响应就能更改局域网中目标主机ARP缓存中的IP-MAC条目，

造成网络中断或者中间人攻击。

‘柒’ 基于lvs实现4层负载均衡

章文嵩：研发，原就职alibaba公司，目前就职滴滴；

lvs：2部分组成
ipvsadm：用户空间的命令行工具；用于管理集群服务及集群服务上的RS；
ipvs：是内核中的框架；工作于内核上的netfilter的INPUT钩子上的程序，可根据用户定义的集群实现请求转发；

注意：在lvs主机上，不允许在INPUT链上添加规则，一般不建议与ipvs一同使用filter规则；更不能使用nat规则，任何链接追踪功能都不能开启，链接会话表就限制了会话能力，否则，并发响应能力将大大受到限制；

支持基于TCP UDP SCTP AH EST AH_EST等协议及端口进行调度；

以下部分内容摘自于： https://www.jianshu.com/p/5184c6564ee2

多目标的DNAT；通过将请求报文中的目标地址和目标端口修改为挑选出的某RS的RIP和PORT实现转发；

ipvs工作在INPUT链上，所以只有在INPUT链上才能判断出集群服务，然后才能向后转发，转发时，基于某种调度算法，ipvs自动从后端主机中挑选出一个来响应用户请求，挑选出的主机IP会成为报文目标IP的修改对象；
定义负载均衡集群服务时，要定义集群服务，集群服务的真实主机；

上图为lvs-nat的常见的使用场景，其工作流程如下：者态册
1、客户端的请求发往Director 的VIP。
2、Director发到客户端请求报文后，将报文中的目标Ip修改为集群中的选定的RIP，目标端口80也修改成8080，然后将请求报文发往RS。
3、当RS收到请求报文后，在检查报文的目标IP为自己的RIP后，会接受报文并进行处理响应。响应的源Ip为RIP，目标IP为CIP，端口不变。
4、Director收到RS的响应报文，修改响应报文的源IP为VIP，端口为80，然后转发给客户端。
5、客户端接受响应报文，其源IP为VIP，端口为80，整个过程对于客户端来说是透明无感知的。

通过修改请求报文的MAC地址，重新封装一个MAC首部进行转发；源MAC是DIP所在接口的MAC地址，目标MAC是挑选出的某RS的RIP所在接口的MAC地址；IP首部不会发生变化（依然是CIP<-->闭举VIP）

lvs服务主机与后端服务器主机接在同一交换机上，且每个后端主机都配有vip，为了避免地址冲突，把各后端主机配首宏置的vip进行隔离；

隔离的方法有3种

（1）确保前端路由器将目标IP为VIP的请求报文转发往Director；

（2）RS的RIP可以使用私有地址，也可以使用公网地址；
（3）RS跟Director必须在同一物理网络（基于MAC地址转发）；RS的网关必须不能指向DIP；
（4）请求报文必须由Directory调度，但响应报文必须不能经由Director；
（5）不支持端口映射；
（6）RS可以使用大多数的OS；一般都为Linux系统；

上图为lvs-dr的常见的使用场景,其工作流程如下：
1、客户端的请求会发往Director，此时，客户端请求报文的源Ip为CIP，目标Ip为Director的VIP。
2、当Director接受到客户端的请求报文后，Director会在请求报文外封装一个MAC首部，其源MAC为Director接口的MAC地址，目标MAC为选定RS的MAC地址；
3、当RS收到Director转发过来的请求报文后，检查发现请求报文的目标Ip为本地环回接口上配置的VIP，因此会接受报文进行响应处理。另外由于对ARP响应规则做了修改，因此RS不会把响应报文响应给director ，而是响应给GW；
4、客户端接收响应报文，完成通信。

请求报文源IP为cip，目标IP为vip，到达lvs服务进入INPUT链上，在整个ip报文外又加了一层ip首部，即IP报文传输IP报文所以叫IP隧道，此时外层源IP为dip，目标IP为某一个被挑选出来远端的rip，远端的服务主机收到报文经过不断拆包后，将响应报文发给客户端，构建响应报文的源IP为rip，目标IP为cip；

（1）RIP，DIP，VIP全得是公网地址；
（2）RS网关不能指向也不可能指向DIP；
（3）请求报文经由Director转发，但响应报文将直接发往CIP；
（4）不支持端口映射；
（5）RS的OS必须支持隧道功能；

（1）VIP是公网地址，RIP和DIP一般是私网地址，且通常不再同一网络中，但需要经由路由器互通；
（2）RS收到的请求报文源IP为DIP，因此响应报文将直接响应给DIP；
（3）请求和响应报文都经由Director；
（4）支持端口映射；
（5）RS可以使用大多数的OS；

负载均衡集群中会话保持的方式
（1）原地址哈希；
（2）会话集群；
（3）会话服务器；

如上图所示：
1.客户端的请求会发往Director，此时，客户端请求报文的源IP为CIP，目标IP为Director的VIP
2.当Director收到客户端的请求报文时，会将源IP修改为本机的DIP，同时将请求报文中的目标IP修改为后端某个RS的RIP，具体为哪个RS的RIP，取决于LVS使用的具体算法
3.当RS收到对应的请求报文时，会发现报文的目标IP就是自己的RIP，于是就会接收报文并处理后进行响应。响应报文的源IP则为RIP，目标IP则为DIP
4.当Director收到对应的响应报文时，Director会将响应报文的源IP修改为VIP，目标IP修改为CIP，于是响应报文被发往客户端。
5.客户端则会收到响应报文，源IP为VIP，端口为80，而LVS相对于客户端而言，转换过程是透明的。

根据其调度时是否考虑后端主机的当前负载，可分为 静态方法 和 动态方法 两类

基于客户端瘦cookie+服务器端的session机制，在负载均衡时，同一用户被调度不同后端服务器时，为了保持会话连接功能不丢失；当第一次用户请求时，通过调度机制给该用户分配了一个负责响应后端服务器，以后来自该用户的请求就由这个服务器负责响应了，而不再调度，这就叫 源地址哈希 ；

在调度器上有会话追踪表，在这个会话追踪模板中，把用户的IP地址和挑选的后端服务器对应的记录下来，而且定义一个超时时长，在定义的时间内该条目不会删除；所以，用户请求到来时，先检查这个表，把原IP当做k查找，因为哈希就是k/v数据，对应的v就是后端的真实服务器；如果检查有用户的IP对应的记录，则直接将请求报文发给记录中对应的后端真实服务器，而不通过调度；

缺陷 ：当记录的真实服务器挂了时，就没有会话保持记录了；当内网用户同过同一IP地址访问外网时，可能会把内网用户的所有请求都发往会话记录表上的真实服务器，这样负载均衡能力是受到损害的；

解决办法

内网用户请求的目标地址，在调度器上把目标地址绑定到一个代理缓存服务器上，以后，任何用户访问的是该目标地址就发往绑定的代理服务器，代理服务器收到请求后，再发往后端服务器主机，从而实现正向代理负载均衡的作用；

ipvs功能特别强大，一般网站用到的可能性比较小，但面试必会问到；
如果负载不是特别大，使用配置比较麻烦，维护成本较大；

ipvs/ipvsadm的关系相当于netfilter/iptables的关系；
真正提供lvs服务的是ipvs；

因为是根据请求的目标ip地址和目标端口（能识别协议）进行转发；一个ipvs（Director）主机就可同时为多个集群提供服务进行调度；这就是四层交换的原因；只不过一个Director很有可能成为负载均衡的瓶颈；

注意：单个Director可同时为多个集群提供调度服务；

在centos 7系统上：
判断内核是否支持ipvs：

判断ipvsadm程序包是否安装

ipvsadm -A|E -t|u|f service-address [-s scheler]
-A：增，添加
-E：修改

ipvsadm -D -t|u|f service-address
-D：删除集群服务；

service-address：定义集群服务的地址
-t：tcp，把tcp端口定义成集群服务，vip:tcp_port；
-u：udp，把udp端口定义成集群服务，vip:udp_port；
-f：Firewalls mark防火墙标记，是一个数字；

-s scheler：定义集群服务的调度方法，默认为wlc加权最少连接；

ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight]
-a：增，添加RS；
-e：改，修改RS；

ipvsadm -d -t|u|f service-address
-d：删除

-r server-address：向已存在的service-address（集群服务）添加RS的地址；
rip[:port] 端口省略时，表示不做端口映射，与请求服务的端口为同一端口；有些集群服务不支持端口映射，如lvs-dr，lvs-tun，只要响应报文不经过Director都不支持；

查看： ipvsadm -L|l [options]
-L，--list：列出集群服务；
-n, --numeric：数字格式显示，不反解主机名到ip地址，服务到端口号；
--exact：精确显示数值，不进行单位换算；
-c, --connection：显示当前ipvs连接；可查看后端服务器是否连接；
--stats：统计数据；
--rate：速率；

清空 ：clear
ipvsadm -C

保存和重载
保存：输出重定向
ipvsadm -S > /PATH/TO/SOME_RULE_FILE
ipvsadm-save > /PATH/TO/SOME_RULE_FILE

重载：输入重定向
ipvsadm -R < /PATH/TO/SOME_RULE_FILE
ipvsadm-restore < /PATH/TO/SOME_RULE_FILE

清空计数器：
ipvsadm -Z [-t|u|f service-address]

例如：

例如：

添加集群服务，vip为172.18.11.111提供web服务，指明调度方法为rr；不指明为默认wlc；

在集群服务中添加RS地址为192.168.255.2，类型为lvs-nat，权重为1此值无意义，因为前面已经指明使用rr调度算法

再次添加一个RS

再次添加一个集群服务

在另一个集群服务上添加2个RS

修改集群服务的调度方法为wrr

注意：修改只能改属性，不能改IP地址；只有删除集群服务才能从新改IP地址；

修改RS的权重值为10

保存集群服务规则至指定路径

查看保存的内容：

清空集群服务

重载集群服务配置文件

下次开机时会自动载入集群服务规则：
所以，可把规则保存在/etc/sysconfig/ipvsadm文件中；
[root@VM_0_2_centos ~]# ipvsadm-save > /etc/sysconfig/ipvsadm
一般手动保存后（确保保存无误），下次开机时，会自动重载此文件；

需要开机自动有效：
[root@VM_0_2_centos ~]# systemctl enable ipvsadm.service

lvs-nat设计要点：
（1）DIP与RIP要在同一IP网络，RIP的网关要指向DIP；
（2）支持端口映射；
（3）是否用到共享存储，取决于业务需要；

1、配置RS1

2、配置RS2

3、配置Director

打开网卡核心转发功能；永久有效：

查看内核参数是否打开核心转发功能

此时，在Director测试，访问RS1、RS2；

添加ipvs集群：

在另一台虚拟机上测试，调度是否起作用：
测试主机为：172.18.11.111

修改Director上的调度方式为wrr

再到测试主机为：172.18.11.111，测试wrr的调度效果

经过多次请求测试后，有明显wrr调度效果；
其RS服务器响应权重比是1:2，即RS1响应1次后RS响应2次；

数据同步：rsync+inotify

响应报文不用经过Director，每个RS必须配置VIP，为了避免地址冲突，有3种方式：

在各主机（Director，RS）均需要配置VIP，因此，要解决地址的冲突的问题，目标是让各RS上的VIP不可见，仅用接收目标地址为VIP的报文，同时可作为响应报文的源地址；
（1）在前端的网关接口上静态绑定（vip+mac）；
缺陷：一旦Director挂了，基于高可用转移另外节点上无法实现；而且，要在网关上有权限操作；
（2）在各RS上使用arptables；添加规则，拒绝自己的VIP地址向外通告及响应arp解析地址的请求；
（3）在各RS上修改内核参数，来限制arp响应和通告；
注意：要将VIP配置在lo的别名上，不能配置在网卡的别名上；

在各RS上设置arp通告级别即修改两个内核参数arp_ignore、arp_announce，因为地址是属于内核的，所以在Linux主机默认的通告方式是所有本机的可用IP地址通告给每个接口；

arp_announce要限制通告级别，每一个网卡仅在把自己的网络地址向所在物理网络中通告，即各网卡间地址绝不交叉通告；arp_announce设置为2；

arp_ignore是限制响应别人arp请求的级别；默认响应请求是无论从哪个接口接收到arp请求，只要本机有这个地址都会响应；限制arp响应级别后可实现，从哪个网卡接收的arp请求，
必须与该接口属于同一网络时才响应；arp_ignore`设置为1

lvs-dr设计要点：
（1）各主机一个接口即可，但需要在同一物理网络中；
（2）RIP的网关不能指向DIP，RIP和DIP通常应在同一网络，但此二者未必会与VIP在同一网络；
（3）各RS需要先设置内核参数，再设置VIP和路由；

搭建网络环境

1、配置Director

2、配置RS1

3、配置RS2

4、访问测试

在RS2主机运行

在报文进入时，进行打标记，例如目标IP是VIP端口80，把这类报文分拣出来打标，标记一般为十六进制整数，例如标记1；在input链上定义集群服务时，就可判定如果防火墙标记为1，则为集群服务；把本来在input链上完成识别、定义集群服务分成了两步，识别在prerouting做，定义在ipvs（inputing）上实现；

在mangle表上的prerouting链上，目标ip（VIP）为172.18.11.7，目标端口为80，打标记为1；

mark标记里包含了IP地址和端口；定义集群服务时使用mark即可；

打标记的方法：
iptables -t mangle -A PREROUTING -d $vip -p $protocol --dport $clusterserverport -j MARK --set-mark #
#：代表十六进制整数；

打标作用 ：提供辅助持久连接功能；在多个端口定义服务时，可把相关作为一个集群来调度；

配置RS1：

配置RS2：

在Director创建CA：

在RS1主机：

在CA服务上签证并传回给RS1：

在各RS主机重启web服务并查看443端口是否监听：

手动测试直接访问RS的IP：

测试请求，OK可以响应页面；-k表示可接受不受信任的页面响应；

单机测试ok，下面绑定80和443服务，打标记：

‘捌’ IPVS(LVS)负载均衡简介及实验测试

LVS是Linux Virtual Server的简称，也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，现在已经是 Linux标准内核的一部分。LVS是一种叫基于TCP/IP的负载均衡技术，转发效率极高，具有处理百万计并发连接请求的能力。

LVS的IP负载均衡技术是通过IPVS模块实现的。IPVS模块是LVS集群的核心软件模块，它安装在LVS集群作为负载均衡的主节点上，虚拟出一个IP地址和端口对外提供服务。用户通过访问这个虚拟服务（VS），然后访问请求由负载均衡器（LB）调度到后端真实服务器（RS）中，由RS实际处理用户的请求给返回响应。

根据负载均衡器转发客户端请求以及RS返回响应机制的不同，将IPVS的转发模式分为三种：VS/NAT，VS/DR，VS/TUN

DR模式下，客户端的请求包到达负载均衡器的虚拟服务IP端口后，负载均衡器不会改写请求包的IP和端口，但是会改写请求包的MAC地址为后端RS的MAC地址，然后将数据包转发；真实服务器处理请求后，响应包直接回给客户端，不再经过负载均衡器。所以DR模式的转发效率是最高的，特别适合下行流量较大的业务场景，比如请求视频等大文件。

DR模式的特点：

LB只是将数据包的MAC地址改写为RS的MAC地址，然后转发给相应的RS。

因为LB转发时并不会改写数据包的目的IP，所以RS收到的数据包的目的IP仍是LB的虚拟服务IP。为了保证RS能够正确处理该数据包，而不是丢弃，必须在RS的环回网卡上绑定LB的虚拟服务IP。这样RS会认为这个虚拟服务IP是自己的IP，自己是能够处理这个数据包的。否则RS会直接丢弃该数据包！

因为LB不会改写数据包的目的端口，所以RS服务的监听端口必须和虚拟服务端口一致，否则RS会直接拒绝该数据包。

因为RS收到的请求数据包的源IP是客户端的IP，所以理所当然RS的响应会直接回给客户端，而不会再经过LB。这时候要求RS和客户端之间的网络是可达的。

因为LB在转发过程中需要改写数据包的MAC为RS的MAC地址，所以要能够查询到RS的MAC。而要获取到RS的MAC，则需要保证二者位于一个子网，否则LB只能获取到RS网关的MAC地址。

NAT模式下，请求包和响应包都需要经过LB处理。当客户端的请求到达虚拟服务后，LB会对请求包做目的地址转换（DNAT），将请求包的目的IP改写为RS的IP。当收到RS的响应后，LB会对响应包做源地址转换（SNAT），将响应包的源IP改写为LB的IP。

NAT模式的特点：

对于请求包，会进行DNAT；对于响应包，会进行SNAT。

虽然LB在转发过程中做了NAT转换，但是因为只是做了部分地址转发，所以RS收到的请求包里是能看到客户端IP的。

因为RS收到的请求包源IP是客户端的IP，为了保证响应包在返回时能走到LB上面，所以需要将RS的默认网关地址配置为LB的虚拟服务IP地址。当然，如果客户端的IP是固定的，也可以在RS上添加明细路由指向LB的虚拟服务IP，不用改默认网关。

因为需要将RS的默认网关配置为LB的虚拟服务IP地址，所以需要保证LB和RS位于同一子网。

又因为需要保证RS的响应包能走回到LB上，则客户端不能和RS位于同一子网。否则RS直接就能获取到客户端的MAC，响应包就直接回给客户端了，不会走网关，也就走不到LB上面了。这时候由于没有LB做SNAT，客户端收到的响应包源IP是RS的IP，而客户端的请求包目的IP是LB的虚拟服务IP，这时候客户端无法识别响应包，会直接丢弃。

IP隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技 术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。
利用IP隧道技术将请求报文封装转发给后端服务器，响应报文能从后端服务器直接返回给客户。但在这里，后端服务器有一组而非一个，所以我们不可 能静态地建立一一对应的隧道，而是动态地选择一台服务器，将请求报文封装和转发给选出的服务器。这样，可以利用IP隧道的原理将一组服务器上的网络服 务组成在一个IP地址上的虚拟网络服务。各个服务器将VIP地址配置在自己的IP隧道设备上。
它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况， 动态地选择一台服务器，将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为 VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

轮叫调度（Round Robin Scheling）算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。

LB会根据RS上配置的权重，将消息按权重比分发到不同的RS上。可以给性能更好的RS节点配置更高的权重，提升集群整体的性能。

最小连接调度（Least-Connection Scheling）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务 器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。

加权最小连接调度（Weighted Least-Connection Scheling）算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权 值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。

基于局部性的最少链接调度（Locality-Based Least Connections Scheling，以下简称为LBLC）算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中 客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的 请求调度到同一台服务器，来提高各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。

带复制的基于局部性最少链接调度（Locality-Based Least Connections with Replication Scheling，以下简称为LBLCR）算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要 维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求，一台Cache 服务器可能会忙不过来处理这些请求。这时，LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器，映射该“热门”站 点到这台Cache服务器，很快这台Cache服务器也会超载，就会重复上述过程选出新的Cache服务器。这样，可能会导致该“热门”站点的映像会出现 在所有的Cache服务器上，降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器（服务器集合），当该“热 门”站点的请求负载增加时，会增加集合里的Cache服务器，来处理不断增长的负载；当该“热门”站点的请求负载降低时，会减少集合里的Cache服务器 数目。这样，该“热门”站点的映像不太可能出现在所有的Cache服务器上，从而提供Cache集群系统的使用效率。

目标地址散列调度（Destination Hashing Scheling）算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。
目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

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

客户端发送对VIP的请求，lvs负载到后端某一台server，后端server处理后，直接封包回送客户端，源IP地址一定是lvs上面配的那个公网服务地址，也就后端server要配置这个ip，后端server收到的数据包是lvs没有变动过的（IP：vip），多个server，接入互联网的server持有相同的IP，是不允许的，因此，必须将后端server中的vip隐藏起来（对外隐藏，对自己可见）

VIP: 虚拟服务器地址
DIP: 转发的网络地址
1，和RIP通信：ARP协议，获取Real Server的RIP：MAC地址；
2，转发Client的数据包到RIP上，RIP上要求有VIP（对外隐藏VIP）；
RIP: 后端真实主机(后端服务器)
CIP: 客户端IP地址

对外隐藏，对内可见

kernel parameter:
目标mac地址为全F，交换机触发广播

arp_ignore: 定义接收到ARP请求时的响应级别；
0：只要本地配置的有相应地址，就给予响应；
1：仅在请求的目标(MAC)地址配置请求
到达的接口上的时候，才给予响应；

arp_announce：定义将自己地址向外通告时的通告级别；
0：将本地任何接口上的任何地址向外通告；
1：试图仅向目标网络通告与其网络匹配的地址；
2：仅向与本地接口上地址匹配的网络进行通告；

lvs 主机：192.168.56.118

RIP主机：也就是需要负载的服务器，192.168.56.101-103

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统，后来将lvs嵌入到linux内核，叫做ipvs

ipvs参数

保存规则
-S

载入此前的规则：
-R

配置lvs的VIP

确保/proc/sys/net/ipv4/ip_forward 内容是1

调整RS的响应。通告级别（每一台RS都配）：

配置RS的VIP（每一台RS都配）

启动RS上的httpd

编写测试文件

启动httpd

客户端验证：
RIP：80 能显示
VIP：80不能显示

负载服务器安装LVS管理工具—ipvsadm

浏览器刷新: 访问vip：80

在DR模式中是所有服务机共享一个VIP，但是在IP隧道模式中，就相当于主代理机将包经过自己打包之后，将IP转化成公网可传递的IP，并将消息经过自己又一次的打包，发送给真实服务器，真实服务器对这个请求作出响应，这样就达到一个可以跨地区的传输。并且也避免了DR模式中代理机与真实服务机必须在同一局域网的不便。
说明：
1、当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP，目标IP为VIP 。
2、PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链
3、IPVS比对数据包请求的服务是否为集群服务，若是，在请求报文的首部再次封装一层IP报文，封装源IP为为DIP，目标IP为RIP。然后发至POSTROUTING链。此时源IP为DIP，目标IP为RIP
4、POSTROUTING链根据最新封装的IP报文，将数据包发至RS（因为在外层封装多了一层IP首部，所以可以理解为此时通过隧道传输）。此时源IP为DIP，目标IP为RIP
5、RS接收到报文后发现是自己的IP地址，就将报文接收下来，拆除掉最外层的IP后，会发现里面还有一层IP首部，而且目标是自己的lo接口VIP，那么此时RS开始处理此请求，处理完成之后，通过lo接口送给eth0网卡，然后向外传递。此时的源IP地址为VIP，目标IP为CIP

RIP、VIP、DIP全是公网地址
RS的网关不会也不可能指向DIP
所有的请求报文经由Director Server，但响应报文必须不能进过Director Server
不支持端口映射
RS的系统必须支持隧道

LVS服务器：192.168.56.100
RS服务器：192.168.56.101，192.168.56.102，192.168.56.103

4.4.5 ### 系统配置 vim /etc/sysctl.conf

4.5.5 ### 系统配置 vim /etc/sysctl.conf

‘玖’ 负载均衡——LVS DR模式

相比于nginx只能用于7层负载均衡，LVS就比较强大了，能在4层做负载均衡。而且性能和稳定性上LVS也比较占优，毕竟是合入内核模块，不稳定肯定不行。

LVS通过工作于内核的ipvs模块来实现功能，其主要工作于netfilter的INPUT链上。除此之外，还需要一个用户态工具，ipvdadm，用于用户负载集群定义和集群服务管理。

LVS DR模式的流程大概如下：

1、客户端发送请求至VIP，也就是访问服务，请求报文源地址是CIP，目标地址为VIP；

2、LVS调度器接收到请求，报文在PREROUTING链检查，确定目的IP是本机，于是将报文发送至INPUT链，ipvs内核模块确定请求的服务是我们配置的LVS集群服务，然后根据用户设定的均衡策略选择某台后端RS，并将目标MAC地址修改RIP的MAC地址。因为调度器和后端服务器RS在同个网段，因此直接二层互通，将请求发给选择的RS处理；

3、因为报文目的mac是本机，且RS上有配置VIP，因此RS能接收该报文。后端服务处理完请求后，将响应直接发往客户端，此时源IP地址为VIP，目标IP为CIP。

如下，准备三台服务器，

机器 作用

192.168.0.100 VIP，LVS调度器对外服务IP

192.168.0.200 RIP，后端web服务器之一

192.168.0.300 RIP，后端web服务器之二

上面我们说过lvs依赖于ipvs内核模块，和ipvsadm用户态工具。因为centos 7已经默认加载ipvs模块，因此这一步我们不需要配置。我们只需要安装ipvsadm工具即可，

yum install -y ipvsadm

然后在LVS调度器上配置VIP，这里我们采用虚拟网卡，当然也可以使用独立网卡配置，

ifconfig eth0:0 192.168.0.100/24 up

接着配置LVS集群服务，

[root@CentOS-7-2 ~]# ipvsadm -C

[root@CentOS-7-2 ~]# ipvsadm -A -t 192.168.0.100:80 -s rr

[root@CentOS-7-2 ~]# ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.200:80 -g

[root@CentOS-7-2 ~]# ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.300:80 -g

其中，

第一条命令是清空所有规则；

第二条命令是定义LVS服务，并指定负责均衡策略为rr，即轮询；

第三、四条命令各添加一台后端web服务器，作为负载均衡节点，并指定为DR模式。

ipvsadm基本命令参数如下：

-A  指定添加的LVS负载均衡虚拟服务

-t  指定虚拟服务器的IP地址和端口

-s  指定调度算法，ss为轮询，wrr为加权轮询，dh为目标地址散列，sh为源地址散列，lc为最少链接等

-a  在对应的VIP下添加RS节点

-g  指定LVS的工作模式为DR模式

-l  指定LVS的工作模式为tunnel模式

-m  指定LVS的工作模式为NAT模式

添加完后端RS，我们可以查看此LVS对应的均衡规则，

[root@CentOS-7-2 ~]# ipvsadm -Ln

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheler Flags

  -> RemoteAddress:Port          Forward Weight ActiveConn InActConn

TCP  192.168.0.100:80 rr

  -> 192.168.0.200:80            Route  1      0          0       

  -> 192.168.0.300:80            Route  1      0          0

这里web服务器使用nginx搭建，因此在两台RS上安装nginx，

yum install -y nginx

同时为了后面测试，我们修改web服务器的index.html内容，

[root@192_168_0_200 ~]# cat /usr/share/nginx/html/index.html

This is 192.168.0.200

[root@192_168_0_300 ~]# cat /usr/share/nginx/html/index.html

This is 192.168.0.300

接着开始进行LVS相关配置，

首先将VIP配置在lo接口上，(注意掩码要配置成32位，不然RS通信会出问题)

ifconfig lo:0 192.168.0.100/32 up

接着配置对应路由，

route add -host 192.168.0.100 dev lo

然后设置相关系统参数，

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

其实严格意义上只要配置出口网卡的对应参数就可以了，配置all也只是为了保险而已，文章最后面会有说明。

使用curl命令对vip进行访问，

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.200

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.300

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.200

[root@CentOS-7-3 /home]# curl  http://192.168.0.100:80

This is 192.168.0.300

可见结果符合我们设置的轮询策略。

因为当调度器把请求转发给对应RS时，并没有修改报文目的IP，因此请求报文目的IP仍为VIP，所以如果RS没有配置VIP，那么报文到达RS后就会被丢弃。

arp_ignore=1:只响应目的IP地址为接收网卡上的本地地址的arp请求

因为我们在RS上都配置了VIP，因此此时是存在IP冲突的，当外部客户端向VIP发起请求时，会先发送arp请求，此时调度器和RS都会响应这个请求。如果某个RS响应了这个请求，则之后该客户端的请求就都发往该RS，并没有经过LVS，因此也就没有真正的负载均衡，LVS也就没有存在的意义。因此我们需要设置RS不响应对VIP的arp请求，这样外部客户端的所有对VIP的arp请求才会都解析到调度器上，然后经由LVS的调度器发往各个RS。

系统默认arp_ignore=0，表示响应任意网卡上接收到的对本机IP地址的arp请求(包括环回网卡上的地址)，而不管该目的IP是否在接收网卡上。也就是说，如果机器上有两个网卡设备A和B，即使在A网卡上收到对B IP的arp请求，也会回应。而arp_ignore设置成1，则不会对B IP的arp请求进行回应。由于lo肯定不会对外通信，所以如果只有一个对外网口，其实只要设置这个对外网口即可，不过为了保险，很多时候都对all也进行设置。

arp_announce=2:网卡在发送arp请求时使用出口网卡IP作为源IP

当RS处理完请求，想要将响应发回给客户端，此时想要获取目的IP对应的目的MAC地址，那么就要发送arp请求。arp请求的目的IP就是想要获取MAC地址的IP，那arp请求的源IP呢？自然而然想到的是响应报文的源IP地址，但也不是一定是这样，arp请求的源IP是可以选择的，而arp_announce的作用正是控制这个地址如何选择。系统默认arp_announce=0，也就是源ip可以随意选择。这就会导致一个问题，如果发送arp请求时使用的是其他网口的IP，达到网络后，其他机器接收到这个请求就会更新这个IP的mac地址，而实际上并不该更新，因此为了避免arp表的混乱，我们需要将arp请求的源ip限制为出口网卡ip，因此需要设置arp_announce=2。

由上可知，只要RS上的VIP不响应arp请求就可以了，因此不一定要配置在lo上，也可以配置在其他网口。由于lo设备不会直接接收外部请求，因此只要设置机器上的出口网卡不响应非本网卡上的arp请求接口。但是如果VIP配置在其他网口上，除了上面的配置，还需要配置该网口不响应任何arp请求，也就是arp_ignore要设置为8。

这是由于lo设备的特殊性导致， 如果lo绑定192.168.0.200/24，则该设备会响应该网段所有IP(192.168.0.1~192.168.0.254) 的请求，而不是只响应192.168.0.200这一个地址。

根据DR模式的原理，调度器只修改请求报文的目的mac，也就是转发是在二层进行，因此调度器和RS需要在同一个网段，从而ip_forward也不需要开启。

‘拾’ LVS四种工作模式原理

LVS 是 Linux Virtual Server ：Linux 虚拟服务器；是一个虚拟的服务器集群【多台机器 LB IP】。

负载调度器(load balancer) ：它是整个LVS 集群对外的前端机器，负责将client请前孙求发送到一组服务器[多台LB IP]上执行，而client端认为是返回来一个同一个IP【通常把这个IP 称为虚拟IP/VIP】
服务器池(server pool) ：一组真正执行client 请求的服务器，一般是我们的web服务器；除了web，还有FTP，MAIL，DNS
共享存储(shared stored) ：它为 server pool 提供了一个共享的存储区，很容易让服务器池拥有相同的内容，提供相同的服务

常用术语

VS：Virtual Server #虚拟服务，一个抽象的服务，用于最开始接收 web 请求的服务
Director, Balancer #负载均衡器、分发器
RS：Real Server # 真正提供服务的服务器
CIP: Client IP #用户端IP，发起请求的客户端 IP，一般是公网 IP
VIP：Director Virtual IP #负载均衡器虚拟IP
DIP：Director IP #负载均衡器IP
RIP：Real Server IP #真正提供 web 服务的服务器的 IP

（1）直接路由模式（LVS-DR）
互联网使用比较多的一种模式
DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器响应后的处理结果直接返回给客户端用户。同TUN模式一样，DR模式可以极大的提高集群系统的伸缩性。而且DR模式没有IP隧道的开销，对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器LB与真实服务器RS都有一块网卡连接到同一物理网脊烂段上，必须在同一个局域网环境。

DR模式特点
优点：和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与VS-TUN相比，VS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。
缺点：（不能说缺点，只能说是不足）要求负载均衡器的网卡必须与物理网卡在一个物理段上。

（2）NAT模式（LVS-NAT）
NAT模式是通过网络地址转换的方法来实现调度的。首先调度器(LB)接收到客户的请求数据包时（请求的目的IP为VIP），根据调度算法决定将请求发送给哪个后端的真实服务器（RS）。然后调度就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址（RIP）,这样真实服务器（RS）就能够接收到客户的请求数据包了。真实服务器响应完请求后，查看默认路由（NAT模式下我们需要把RS的默认路由设置为LB服务器。）把响应后的数据包发送给LB,LB再接收到响应包后，把包的源慧野链地址改成虚拟地址（VIP）然后发送回给客户端。

NAT模式特点：
1、NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写，因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈，一般要求最多之能10-20台节点
2、只需要在LB上配置一个公网IP地址就可以了。
3、每台内部的节点服务器的网关地址必须是调度器LB的内网地址。
4、NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

（3）Full NAT模式（LVS-FullNAT）
客户端对VIP发起请求，Director接过请求发现是请求后端服务。Direcrot对请求报文做full-nat，把源ip改为Dip，把目标ip转换为任意后端RS的rip，然后发往后端，rs接到请求后，进行响应，响应源ip为Rip，目标ip还是DIP，又内部路由路由到Director,Director接到响应报文，进行full-nat。将源地址为VIP，目标地址改为CIP
请求使用DNAT，响应使用SNAT

Full NAT模式特点：
FULL NAT 模式也不需要 LBIP 和realserver ip 在同一个网段；
full nat 跟nat 相比的优点是：保证RS回包一定能够回到LVS；因为源地址就是LVS==> 不确定
full nat 因为要更新sorce ip 所以性能正常比nat 模式下降 10%

(4）IP隧道模式（LVS-Tunnel）
采用NAT模式时，由于请求和响应的报文必须通过调度器地址重写，当客户请求越来越多时，调度器处理能力将成为瓶颈。为了解决这个问题，调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文，由于一般网络服务应答数据比请求报文大很多，采用VS/TUN模式后，集群系统的最大吞吐量可以提高10倍。
它和NAT模式不同的是，它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP tunnel里面，然后发送给RS节点服务器，节点服务器接收到之后解开IP tunnel后，进行响应处理。并且直接把包通过自己的外网地址发送给客户不用经过LB服务器。

ip隧道模式特点：
负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。
隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。

四种模式性能比较：
因为DR模式 IP TUNELL 模式都是在package in 时经过LVS ，在package out是直接返回给client，所以二者的性能比NAT 模式高，但IP TUNNEL 因为是TUNNEL 模式比较复杂，其性能不如DR模式；
FULL NAT 模式因为不仅要更换 DST IP 还更换 SOURCE IP 所以性能比NAT 下降10%
4种模式的性能如下：DR ==> IP TUNNEL ==>NAT ==>FULL NAT