~ Aiker$ curl -I 172.16.22.220
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 27 Mar 2018 14:38:29 GMT
Content-Type: text/html
Content-Length: 1326
Last-Modified: Wed, 26 Apr 2017 08:03:46 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "59005462-52e"
Accept-Ranges: bytes~ Aiker$ curl -I 172.16.22.220
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 27 Mar 2018 14:38:31 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.6.34
location: forum.php

rr算法

定义ipvsadm负载均衡集群规则，并查看
此处定义DIP是以-s指定为rr算法进行轮询调度，-m指定模式为lvs-nat，配置命令如下：

[root@test220 ~]# /usr/sbin/ipvsadm -C
[root@test220 ~]# /usr/sbin/ipvsadm -A -t 172.16.22.220:80 -s rr
[root@test220 ~]# /usr/sbin/ipvsadm -a -t 172.16.22.220:80 -r 192.168.0.221:80 -m
[root@test220 ~]# /usr/sbin/ipvsadm -a -t 172.16.22.220:80 -r 192.168.0.222:80 -m***测试***~ Aiker$ curl -I 172.16.22.220
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 27 Mar 2018 14:38:26 GMT
Content-Type: text/html
Content-Length: 1326
Last-Modified: Wed, 26 Apr 2017 08:03:46 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "59005462-52e"
Accept-Ranges: bytes~ Aiker$ curl -I 172.16.22.220
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 27 Mar 2018 14:38:28 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.6.34
location: forum.php

wrr算法

[root@test220 ~]# cat !$
cat /usr/local/sbin/lvs_nat_wrr.sh
IPVSADM='/usr/sbin/ipvsadm'
$IPVSADM -C
$IPVSADM -A -t 172.16.22.220:80 -s wrr
$IPVSADM -a -t 172.16.22.220:80 -r 192.168.0.221:80 -m -w 1
$IPVSADM -a -t 172.16.22.220:80 -r 192.168.0.222:80 -m -w 3
$IPVSADM -L -n测试~ Aiker$ curl -I 172.16.22.220
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 28 Mar 2018 13:34:47 GMT
Content-Type: text/html
Content-Length: 1326
Last-Modified: Wed, 26 Apr 2017 08:03:46 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "59005462-52e"
Accept-Ranges: bytes~ Aiker$ curl -I 172.16.22.220
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 28 Mar 2018 13:34:48 GMT
Content-Type: text/html
Content-Length: 1326
Last-Modified: Wed, 26 Apr 2017 08:03:46 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "59005462-52e"
Accept-Ranges: bytes~ Aiker$ curl -I 172.16.22.220
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 28 Mar 2018 13:34:50 GMT
Content-Type: text/html
Content-Length: 1326
Last-Modified: Wed, 26 Apr 2017 08:03:46 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "59005462-52e"
Accept-Ranges: bytes~ Aiker$ curl -I 172.16.22.220
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Wed, 28 Mar 2018 13:34:52 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.6.34
location: forum.php~ Aiker$ curl -I 172.16.22.220
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 28 Mar 2018 13:35:04 GMT
Content-Type: text/html
Content-Length: 1326
Last-Modified: Wed, 26 Apr 2017 08:03:46 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "59005462-52e"
Accept-Ranges: bytes

扩展

lvs 三种模式详解

一、集群简介

什么是集群

计算机集群简称集群是一种计算机系统，它通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点，通常通过局域网连接，但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算速度和/或可靠性。一般情况下集群计算机比单个计算机，比如工作站或超级计算机性能价格比要高得多。

集群就是一组独立的计算机，通过网络连接组合成一个组合来共同完一个任务

LVS在企业架构中的位置：

以上的架构只是众多企业里面的一种而已。绿色的线就是用户访问请求的数据流向。用户-->LVS负载均衡服务器--->apahce服务器--->mysql服务器&memcache服务器&共享存储服务器。并且我们的mysql、共享存储也能够使用LVS再进行负载均衡。

---------------小结-------------------------

集群：就是一组相互独立的计算机，通过高速的网络组成一个计算机系统，每个集群节点都是运行其自己进程的一个独立服务器。对网络用户来讲，网站后端就是一个单一的系统，协同起来向用户提供系统资源，系统服务。

为什么要使用集群

集群的特点

1）高性能performance。一些需要很强的运算处理能力比如天气预报，核试验等。这就不是几台计算机能够搞定的。这需要上千台一起来完成这个工作的。

2）价格有效性

通常一套系统集群架构，只需要几台或数十台服务器主机即可，与动则上百王的专用超级计算机具有更高的性价比。

3）可伸缩性

当服务器负载压力增长的时候，系统能够扩展来满足需求，且不降低服务质量。

4）高可用性

尽管部分硬件和软件发生故障，整个系统的服务必须是7*24小时运行的。

集群的优势

1）透明性

如果一部分服务器宕机了业务不受影响，一般耦合度没有那么高，依赖关系没有那么高。比如NFS服务器宕机了其他就挂载不了了，这样依赖性太强。

2）高性能

访问量增加，能够轻松扩展。

3）可管理性

整个系统可能在物理上很大，但很容易管理。

4）可编程性

在集群系统上，容易开发应用程序，门户网站会要求这个。

集群分类及不同分类的特点

计算机集群架构按照功能和结构一般分成以下几类：

1）负载均衡集群（Loadbalancingclusters）简称LBC

2）高可用性集群（High-availabilityclusters）简称HAC

3）高性能计算集群（High-perfomanceclusters）简称HPC

4）网格计算（Gridcomputing）

网络上面一般认为是有三个，负载均衡和高可用集群式我们互联网行业常用的集群架构。

（1）负载均衡集群

负载均衡集群为企业提供了更为实用，性价比更高的系统架构解决方案。负载均衡集群把很多客户集中访问的请求负载压力可能尽可能平均的分摊到计算机集群中处理。客户请求负载通常包括应用程度处理负载和网络流量负载。这样的系统非常适合向使用同一组应用程序为大量用户提供服务。每个节点都可以承担一定的访问请求负载压力，并且可以实现访问请求在各节点之间动态分配，以实现负载均衡。

负载均衡运行时，一般通过一个或多个前端负载均衡器将客户访问请求分发到后端一组服务器上，从而达到整个系统的高性能和高可用性。这样计算机集群有时也被称为服务器群。一般高可用性集群和负载均衡集群会使用类似的技术，或同时具有高可用性与负载均衡的特点。

负载均衡集群的作用

1）分担访问流量（负载均衡）

2）保持业务的连续性（高可用）

（2）高可用性集群

一般是指当集群中的任意一个节点失效的情况下，节点上的所有任务自动转移到其他正常的节点上，并且此过程不影响整个集群的运行，不影响业务的提供。

类似是集群中运行着两个或两个以上的一样的节点，当某个主节点出现故障的时候，那么其他作为从 节点的节点就会接替主节点上面的任务。从节点可以接管主节点的资源（IP地址，架构身份等），此时用户不会发现提供服务的对象从主节点转移到从节点。

高可用性集群的作用：当一个机器宕机另一台进行接管。比较常用的高可用集群开源软件有：keepalive，heardbeat。

（3）高性能计算集群

高性能计算集群采用将计算任务分配到集群的不同计算节点儿提高计算能力，因而主要应用在科学计算领域。比较流行的HPC采用Linux操作系统和其它一些免费软件来完成并行运算。这一集群配置通常被称为Beowulf集群。这类集群通常运行特定的程序以发挥HPCcluster的并行能力。这类程序一般应用特定的运行库, 比如专为科学计算设计的MPI库。

HPC集群特别适合于在计算中各计算节点之间发生大量数据通讯的计算作业，比如一个节点的中间结果或影响到其它节点计算结果的情况。

常用集群软硬件

常用开源集群软件有：lvs，keepalived，haproxy，nginx，apache，heartbeat

常用商业集群硬件有：F5,Netscaler，Radware，A10等

二、LVS负载均衡集群介绍

负载均衡集群的作用：提供一种廉价、有效、透明的方法，来扩展网络设备和服务器的负载带宽、增加吞吐量，加强网络数据处理能力、提高网络的灵活性和可用性。

1）把单台计算机无法承受的大规模的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间，提升用户体验。

2）单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。

3）7*24小时的服务保证，任意一个或多个设备节点设备宕机，不能影响到业务。在负载均衡集群中，所有计算机节点都应该提供相同的服务，集群负载均衡获取所有对该服务的如站请求。

LVS介绍

LVS是linux virtual server的简写linux虚拟服务器，是一个虚拟的服务器集群系统，可以再unix/linux平台下实现负载均衡集群功能。该项目在1998年5月由章文嵩博士组织成立。

以下是LVS官网提供的4篇文章：（非常详细，我觉得有兴趣还是看官方文档比较正宗吧！！）

http://www.linuxvirtualserver.org/zh/lvs1.html

http://www.linuxvirtualserver.org/zh/lvs2.html

http://www.linuxvirtualserver.org/zh/lvs3.html

http://www.linuxvirtualserver.org/zh/lvs4.html

IPVS发展史

早在2.2内核时，IPVS就已经以内核补丁的形式出现。

从2.4.23版本开始ipvs软件就是合并到linux内核的常用版本的内核补丁的集合。

从2.4.24以后IPVS已经成为linux官方标准内核的一部分

从上图可以看出lpvs是工作在内核层，我们不能够直接操作ipvs，vs负载均衡调度技术是在linux内核中实现的。因此，被称之为linux虚拟服务器。我们使用该软件配置lvs的时候，不能直接配置内核中的ipvs，而需要使用ipvs的管理工具ipvsadm进行管理。通过keepalived也可以管理LVS。

LVS体系结构与工作原理简单描述

LVS集群负载均衡器接受服务的所有入展客户端的请求，然后根据调度算法决定哪个集群节点来处理回复客户端的请求。

LVS虚拟服务器的体系如下图所示，一组服务器通过高速的局域网或者地理分布的广域网相互连接，在这组服务器之前有一个负载调度器（load balance）。负载调度器负责将客户的请求调度到真实服务器上。这样这组服务器集群的结构对用户来说就是透明的。客户访问集群系统就如只是访问一台高性能，高可用的服务器一样。客户程序不受服务器集群的影响，不做任何修改。

就比如说：我们去饭店吃饭点菜，客户只要跟服务员点菜就行。并不需要知道具体他们是怎么分配工作的，所以他们内部对于我们来说是透明的。此时这个服务员就会按照一定的规则把他手上的活，分配到其他人员上去。这个服务员就是负载均衡器（LB）而后面这些真正做事的就是服务器集群。

底下是官网提供的结构图：

LVS的基本工作过程

客户请发送向负载均衡服务器发送请求。负载均衡器接受客户的请求，然后先是根据LVS的调度算法（8种）来决定要将这个请求发送给哪个节点服务器。然后依据自己的工作模式（3种）来看应该如何把这些客户的请求如何发送给节点服务器，节点服务器又应该如何来把响应数据包发回给客户端。

恩，那这样我们就只要接下来搞懂LVS的3中工作模式，8种调度算法就可以了。

LVS的三种工作模式：

1）VS/NAT模式（Network address translation）

2）VS/TUN模式（tunneling）

3）DR模式（Direct routing）

1、NAT模式-网络地址转换

Virtualserver via Network address translation(VS/NAT)

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

调度过程IP包详细图：

原理图简述：

1)客户端请求数据，目标IP为VIP

2)请求数据到达LB服务器，LB根据调度算法将目的地址修改为RIP地址及对应端口（此RIP地址是根据调度算法得出的。）并在连接HASH表中记录下这个连接。

3)数据包从LB服务器到达RS服务器webserver，然后webserver进行响应。Webserver的网关必须是LB，然后将数据返回给LB服务器。

4)收到RS的返回后的数据，根据连接HASH表修改源地址VIP&目标地址CIP，及对应端口80.然后数据就从LB出发到达客户端。

5)客户端收到的就只能看到VIP\DIP信息。

NAT模式优缺点：

1、NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写，因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈，一般要求最多之能10-20台节点

2、只需要在LB上配置一个公网IP地址就可以了。

3、每台内部的节点服务器的网关地址必须是调度器LB的内网地址。

4、NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

2、TUN模式

virtual server via ip tunneling模式:采用NAT模式时，由于请求和响应的报文必须通过调度器地址重写，当客户请求越来越多时，调度器处理能力将成为瓶颈。为了解决这个问题，调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文，由于一般网络服务应答数据比请求报文大很多，采用VS/TUN模式后，集群系统的最大吞吐量可以提高10倍。

VS/TUN的工作流程图如下所示，它和NAT模式不同的是，它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP tunnel里面，然后发送给RS节点服务器，节点服务器接收到之后解开IP tunnel后，进行响应处理。并且直接把包通过自己的外网地址发送给客户不用经过LB服务器。

Tunnel原理流程图:

原理图过程简述：

1）客户请求数据包，目标地址VIP发送到LB上。

2）LB接收到客户请求包，进行IP Tunnel封装。即在原有的包头加上IP Tunnel的包头。然后发送出去。

3）RS节点服务器根据IP Tunnel包头信息（此时就又一种逻辑上的隐形隧道，只有LB和RS之间懂）收到请求包，然后解开IP Tunnel包头信息，得到客户的请求包并进行响应处理。

4）响应处理完毕之后，RS服务器使用自己的出公网的线路，将这个响应数据包发送给客户端。源IP地址还是VIP地址。（RS节点服务器需要在本地回环接口配置VIP，后续会讲）

3、DR模式（直接路由模式）

Virtual server via direct routing (vs/dr)

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

DR模式是互联网使用比较多的一种模式。

DR模式原理图：

DR模式原理过程简述：

VS/DR模式的工作流程图如上图所示，它的连接调度和管理与NAT和TUN中的一样，它的报文转发方法和前两种不同。DR模式将报文直接路由给目标真实服务器。在DR模式中，调度器根据各个真实服务器的负载情况，连接数多少等，动态地选择一台服务器，不修改目标IP地址和目标端口，也不封装IP报文，而是将请求报文的数据帧的目标MAC地址改为真实服务器的MAC地址。然后再将修改的数据帧在服务器组的局域网上发送。因为数据帧的MAC地址是真实服务器的MAC地址，并且又在同一个局域网。那么根据局域网的通讯原理，真实复位是一定能够收到由LB发出的数据包。真实服务器接收到请求数据包的时候，解开IP包头查看到的目标IP是VIP。_（此时只有自己的IP符合目标IP才会接收进来，所以我们需要在本地的回环借口上面配置VIP。另：由于网络接口都会进行ARP广播响应，但集群的其他机器都有这个VIP的lo接口，都响应就会冲突。所以我们需要把真实服务器的lo接口的ARP__响应关闭掉。）_然后真实服务器做成请求响应，之后根据自己的路由信息将这个响应数据包发送回给客户，并且源IP地址还是VIP。

DR模式小结：

1、通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP，目的地址仍然是VIP地址。

2、请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此并发访问量大时使用效率很高（和NAT模式比）

3、因为DR模式是通过MAC地址改写机制实现转发，因此所有RS节点和调度器LB只能在一个局域网里面

4、RS主机需要绑定VIP地址在LO接口上，并且需要配置ARP抑制。

5、RS节点的默认网关不需要配置成LB，而是直接配置为上级路由的网关，能让RS直接出网就可以。

6、由于DR模式的调度器仅做MAC地址的改写，所以调度器LB就不能改写目标端口，那么RS服务器就得使用和VIP相同的端口提供服务。

官方三种负载均衡技术比较总结表：

工作模式

VS/NAT

VS/TUN

VS/DR

Real server

（节点服务器）

Config dr gw

Tunneling

Non-arp device/tie vip

Server Network

Private

LAN/WAN

LAN

Server number

（节点数量）

Low 10-20

High 100

High 100

Real server gateway

Load balance

Own router

Own router

优点

地址和端口转换

Wan环境加密数据

性能最高

缺点

效率低

需要隧道支持

不能跨域LAN

LVS调度算法

最好参考此文章：http://www.linuxvirtualserver.org/zh/lvs4.html

Lvs的调度算法决定了如何在集群节点之间分布工作负荷。当director调度器收到来自客户端访问VIP的上的集群服务的入站请求时，director调度器必须决定哪个集群节点应该处理请求。Director调度器用的调度方法基本分为两类：

固定调度算法：rr，wrr，dh，sh

动态调度算法：wlc，lc，lblc，lblcr

算法

说明

rr

轮询算法，它将请求依次分配给不同的rs节点，也就是RS节点中均摊分配。这种算法简单，但只适合于RS节点处理性能差不多的情况

wrr

加权轮训调度，它将依据不同RS的权值分配任务。权值较高的RS将优先获得任务，并且分配到的连接数将比权值低的RS更多。相同权值的RS得到相同数目的连接数。

Wlc

加权最小连接数调度，假设各台RS的全职依次为Wi，当前tcp连接数依次为Ti，依次去Ti/Wi为最小的RS作为下一个分配的RS

Dh

目的地址哈希调度（destination hashing）以目的地址为关键字查找一个静态hash表来获得需要的RS

SH

源地址哈希调度（source hashing）以源地址为关键字查找一个静态hash表来获得需要的RS

Lc

最小连接数调度（least-connection）,IPVS表存储了所有活动的连接。LB会比较将连接请求发送到当前连接最少的RS.

Lblc

基于地址的最小连接数调度（locality-based least-connection）：将来自同一个目的地址的请求分配给同一台RS，此时这台服务器是尚未满负荷的。否则就将这个请求分配给连接数最小的RS，并以它作为下一次分配的首先考虑。

LVS调度算法的生产环境选型：

1、一般的网络服务，如http，mail，mysql等常用的LVS调度算法为：

a.基本轮询调度rr

b.加权最小连接调度wlc

c.加权轮询调度wrc

2、基于局部性的最小连接lblc和带复制的给予局部性最小连接lblcr主要适用于web cache和DB cache

3、源地址散列调度SH和目标地址散列调度DH可以结合使用在防火墙集群中，可以保证整个系统的出入口唯一。

实际适用中这些算法的适用范围很多，工作中最好参考内核中的连接调度算法的实现原理，然后根据具体的业务需求合理的选型。

-----------------后续自我小结--------------------------------------------------

lvs几种算法

LVS主要的调度算法
轮询调度-加权轮询调度-最小连接调度-加权最小连接调度-基于局部性的最少连接-
带复制的基于局部性的最少连接-目标地址散列调度-源地址散列调度

关于arp_ignore和 arp_announce

先简单的介绍下关于LVS负载均衡

LVS（Linux Virtual Server）Linux服务器集群系统

针对高可伸缩，高可用服务的需求，给予IP层和内容请求分发的负载均衡调度解决方法，并在Linux的内核中实现，将一组服务器构成一个实现可伸缩，高可用网络服务的虚拟服务器

负载均衡

1.大量的兵法访问或数据流量分担到多态节点设备分别处理，减少用户的等待时间

2.单个重负载的运算分担到多态节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户

负载调度器

一组服务器通过高速的局域网或者地理分布的广域网相互相连，在他们的前端有一个负载均衡调度器（Load Balancer），负载均衡调度器能无缝的将网络请求调度到真实的服务器上，从而使得服务器集群的结构对用户是透明的，用户通过访问集群系统提供的网络服务，就像访问一台高性能，高可用的服务器。

IP负载均衡技术（三种）

1.VS/NAT（网络地址转换）

通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分发给后端的真实服务器，真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回到客户端，完成整个调度的过程

2.VS/TUN（IP隧道模式）

调度器将请求的报文通过IP隧道转发至真实服务器，而真实的服务器直接将结果返回给用户，调度器只处理请求报文，由于一般网路服务的应答大于请求，采用IP隧道模式，集群系统的最大吞吐量可以提高10倍。

3.VS/DR（直接路由）

通过改写请求报文的MAC地址，将请求发送到真是服务器，真实服务器将响应直接返回给用户，之际额路由模式可以极大的提高集群系统的伸缩性，这种方法没有IP隧道的开销，集群中真实的服务器也没有必要必须支持IP隧道协议，只是需要调度器与真实服务器有一块网卡连在同一物理网段上。

其中在这三种IP负载均衡的技术中，DR和TUN模式都需要在真实服务器上对arp_ignore和arp_announce参数进行配置，主要是实现禁止响应对VIP的ARP请求。

在lvs环境中，需要设定以下的参数

echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignoreecho "1" > /proc/sys/net/ipv4/conf/lo/arp_ignoreecho "2" > /proc/sys/net/ipv4/conf/lo/arp_announceecho "2" > /proc/sys/net/ipv4/conf/all/arp_announce

先来看看关于arp_ignore和arp_announce的有关介绍

有关arp_ignore的相关介绍：

arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied
4-7 - reserved
8 - do not reply for all local addresses

The max value from conf/{all,interface}/arp_ignore is used
when ARP request is received on the {interface}

arp_ignore:定义对目标地址为本地IP的ARP询问不同的应答模式0

0 - (默认值): 回应任何网络接口上对任何本地IP地址的arp查询请求

1 - 只回答目标IP地址是来访网络接口本地地址的ARP查询请求

2 -只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内

3 - 不回应该网络界面的arp请求，而只对设置的唯一和连接地址做出回应

4-7 - 保留未使用

8 -不回应所有（本地地址）的arp查询

有关arp_announce的相关介绍：

arp_announce - INTEGER
Define different restriction levels for announcing the local
source IP address from IP packets in ARP requests sent on
interface:
0 - (default) Use any local address, configured on any interface
1 - Try to avoid local addresses that are not in the target's
subnet for this interface. This mode is useful when target
hosts reachable via this interface require the source IP
address in ARP requests to be part of their logical network
configured on the receiving interface. When we generate the
request we will check all our subnets that include the
target IP and will preserve the source address if it is from
such subnet. If there is no such subnet we select source
address according to the rules for level 2.
2 - Always use the best local address for this target.
In this mode we ignore the source address in the IP packet
and try to select local address that we prefer for talks with
the target host. Such local address is selected by looking
for primary IP addresses on all our subnets on the outgoing
interface that include the target IP address. If no suitable
local address is found we select the first local address
we have on the outgoing interface or on all other interfaces,
with the hope we will receive reply for our request and
even sometimes no matter the source IP address we announce.

The max value from conf/{all,interface}/arp_announce is used.Increasing the restriction level gives more chance for
receiving answer from the resolved target while decreasing
the level announces more valid sender's information.

arp_announce:对网络接口上，本地IP地址的发出的，ARP回应，作出相应级别的限制: 确定不同程度的限制,宣布对来自本地源IP地址发出Arp请求的接口

0 - (默认) 在任意网络接口（eth0,eth1，lo）上的任何本地地址

1 -尽量避免不在该网络接口子网段的本地地址做出arp回应. 当发起ARP请求的源IP地址是被设置应该经由路由达到此网络接口的时候很有用.此时会检查来访IP是否为所有接口上的子网段内ip之一.如果改来访IP不属于各个网络接口上的子网段内,那么将采用级别2的方式来进行处理.

2 - 对查询目标使用最适当的本地地址.在此模式下将忽略这个IP数据包的源地址并尝试选择与能与该地址通信的本地地址.首要是选择所有的网络接口的子网中外出访问子网中包含该目标IP地址的本地地址. 如果没有合适的地址被发现,将选择当前的发送网络接口或其他的有可能接受到该ARP回应的网络接口来进行发送.

关于对arp_announce 理解的一点补充

Assume that a linux box X has three interfaces - eth0, eth1 and eth2. Each interface has an IP address IP0,

IP1 and IP2. When a local application tries to send an IP packet with IP0 through the eth2. Unfortunately,

the target node’s mac address is not resolved. Thelinux box X will send the ARP request to know

the mac address of the target(or the gateway). In this case what is the IP source address of the

“ARP request message”? The IP0- the IP source address of the transmitting IP or IP2 - the outgoing

interface? Until now(actually just 3 hours before) ARP request uses the IP address assigned to

the outgoing interface(IP2 in the above example) However the linux’s behavior is a little bit

different. Actually the selection of source address in ARP request is totally configurable

bythe proc variable “arp_announce”

If we want to use the IP2 not the IP0 in the ARP request, we should change the value to 1 or 2.

The default value is 0 - allow IP0 is used for ARP request.

其实就是路由器的问题，因为路由器一般是动态学习ARP包的（一般动态配置DHCP的话），当内网的机器要发送一个到外部的ip包，那么它就会请求 路由器的Mac地址，发送一个arp请求，这个arp请求里面包括了自己的ip地址和Mac地址，而linux默认是使用ip的源ip地址作为arp里面 的源ip地址，而不是使用发送设备上面的 ，这样在lvs这样的架构下，所有发送包都是同一个VIP地址，那么arp请求就会包括VIP地址和设备 Mac，而路由器收到这个arp请求就会更新自己的arp缓存，这样就会造成ip欺骗了，VIP被抢夺，所以就会有问题。

arp缓存为什么会更新了，什么时候会更新呢，为了减少arp请求的次数，当主机接收到询问自己的arp请求的时候，就会把源ip和源Mac放入自 己的arp表里面，方便接下来的通讯。如果收到不是询问自己的包（arp是广播的，所有人都收到），就会丢掉，这样不会造成arp表里面无用数据太多导致 有用的记录被删除。

在设置参数的时候将arp_ignore 设置为1，意味着当别人的arp请求过来的时候，如果接收的设备上面没有这个ip，就不做出响应，默认是0，只要这台机器上面任何一个设备上面有这个ip，就响应arp请求，并发送mac地址

lvs原理相关的

LVS简介

　　Internet的快速增长使多媒体网络服务器面对的访问数量快速增加，服务器需要具备提供大量并发访问服务的能力，因此对于大负载的服务器来讲， CPU、I/O处理能力很快会成为瓶颈。由于单台服务器的性能总是有限的，简单的提高硬件性能并不能真正解决这个问题。为此，必须采用多服务器和负载均衡技术才能满足大量并发访问的需要。Linux 虚拟服务器(Linux Virtual Servers,LVS) 使用负载均衡技术将多台服务器组成一个虚拟服务器。它为适应快速增长的网络访问需求提供了一个负载能力易于扩展，而价格低廉的解决方案。

LVS结构与工作原理

一.LVS的结构

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

二.LVS内核模型

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

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

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

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

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

三.LVS的包转发模型

1.NAT模型：

①.客户端将请求发往前端的负载均衡器，请求报文源地址是CIP(客户端IP),后面统称为CIP)，目标地址为VIP(负载均衡器前端地址，后面统称为VIP)。

②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的目标地址改为了后端服务器的RIP地址并将报文根据算法发送出去。

③.报文送到Real Server后，由于报文的目标地址是自己，所以会响应该请求，并将响应报文返还给LVS。

④.然后lvs将此报文的源地址修改为本机并发送给客户端。注意：在NAT模式中，Real Server的网关必须指向LVS，否则报文无法送达客户端。

2.DR模型：

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

②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的源MAC地址改为自己DIP的MAC地址，目标MAC改为了RIP的MAC地址，并将此包发送给RS。

③.RS发现请求报文中的目的MAC是自己，就会将次报文接收下来，处理完请求报文后，将响应报文通过lo接口送给eth0网卡直接发送给客户端。注意：需要设置lo接口的VIP不能响应本地网络内的arp请求。

3.TUN模型：

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

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

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

四.LVS的调度算法

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

1.静态算法（4种）：只根据算法进行调度 而不考虑后端服务器的实际连接情况和负载情况

①.RR：轮叫调度（Round Robin）
　 调度器通过”轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载｡

②.WRR：加权轮叫（Weight RR）
　 调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

③.DH：目标地址散列调度（Destination Hash ）
　 根据请求的目标IP地址，作为散列键(HashKey)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

④.SH：源地址 hash（Source Hash）
　 源地址散列”调度算法根据请求的源IP地址，作为散列键(HashKey)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空｡

2.动态算法（6种）：前端的调度器会根据后端真实服务器的实际连接情况来分配请求