负载均衡集群提供了一种廉价、有效、透明的方法，来扩展网络设备和服务器的负载、带宽、增加吞吐量、加强网络数据的处理能力、提高网络的灵活性和可用性
搭建负载均衡器的需求：
2）单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度的提高。
3）7*24的服务保证，任意一个或多个有限后面节点设备宕机，要求不能影响业务。
在负载均衡器集群中，所有的计算节点都应该提供相同的服务。集群负载均衡获取所有对该服务的入站要求，然后将这些请求尽可能的平均分配在所有集群节点上。
1.四层负载均衡（位于内核层）：根据请求报文中的目标地址和端口进行调度
2.七层负载均衡（位于应用层）：根据请求报文的内容进行调度，这种调度属于「代理」的方式
硬件负载均衡：
1.F5的BIG-IP
2.Citrix的NetScaler
3.这类硬件负载均衡器通常能同时提供四层和七层负载均衡，但同时也价格不菲
软件负载均衡：
1.TCP层：LVS，HaProxy，Nginx
2.基于HTTP协议：Haproxy，Nginx，ATS（ApacheTrafficServer），squid，varnish
3.基于MySQL协议：mysql-proxy
Internet的快速增长使多媒体网络服务器面对的访问数量快速增加，服务器需要具备提供大量并发访问服务的能力，因此对于大负载的服务器来讲，CPU、I/O处理能力很快会成为瓶颈。由于单台服务器的性能总是有限的，简单的提高硬件性能并不能真正解决这个问题。为此，必须采用多服务器和负载均衡技术才能满足大量并发访问的需要。Linux虚拟服务器(LinuxVirtualServers,LVS)使用负载均衡技术将多台服务器组成一个虚拟服务器。它为适应快速增长的网络访问需求提供了一个负载能力易于扩展，而价格低廉的解决方案。
LVS(LinuxVirtualServer)其实是一种集群(Cluster)技术，采用IP负载均衡技术（LVS的IP负载均衡技术是通过IPVS模块来实现的，linux内核2.6版本以上是默认安装IPVS的）和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。
LVS负载均衡调度技术是在LINUX内核中实现的，因此被称之为LINUX虚拟服务器。我们使用该软件配置LVS时候，不能直接配置内核中的IPVS，而需要使用IPVS的管理工具ipvsadm进行管理，当然我们也可以通过keepalived软件直接管理IPVS，并不是通过ipvsadm来管理ipvs。
LVS项目介绍
LVS集群的体系结构
LVS技术点小结：
1、真正实现调度的工具是IPVS，工作在LINUX内核层面。
2、LVS自带的IPVS管理工具是ipvsadm。
3、keepalived实现管理IPVS及负载均衡器的高可用。
4、Redhat工具PiranhaWEB管理实现调度的工具IPVS（不常用）。
LVS由前端的负载均衡器(LoadBalancer，LB)和后端的真实服务器(RealServer，RS)群组成。RS间可通过局域网或广域网连接。LVS的这种结构对用户是透明的，用户只能看见一台作为LB的虚拟服务器(VirtualServer)，而看不到提供服务的RS群。当用户的请求发往虚拟服务器，LB根据设定的包转发策略和负载均衡调度算法将用户请求转发给RS。RS再将用户请求结果返回给用户。
负载调度器(loadbalancer/Director)，它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址(我们可称之为虚拟IP地址)上的。
服务器池(serverpool/Realserver)，是一组真正执行客户请求的服务器，执行的服务一般有WEB、MAIL、FTP和DNS等。
共享存储(sharedstorage)，它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。
1.当客户端的请求到达负载均衡器的内核空间时，首先会到达PREROUTING链。
2.当内核发现请求数据包的目的地址是本机时，将数据包送往INPUT链。
3.LVS由用户空间的ipvsadm和内核空间的IPVS组成，ipvsadm用来定义规则，IPVS利用ipvsadm定义的规则工作，IPVS工作在INPUT链上,当数据包到达INPUT链时，首先会被IPVS检查，如果数据包里面的目的地址及端口没有在规则里面，那么这条数据包将被放行至用户空间。
4.如果数据包里面的目的地址及端口在规则里面，那么这条数据报文将被修改目的地址为事先定义好的后端服务器，并送往POSTROUTING链。
5.最后经由POSTROUTING链发往后端服务器。
负载均衡技术有很多实现方案，有基于DNS域名轮流解析的方法、有基于客户端调度访问的方法、有基于应用层系统负载的调度方法，还有基于IP地址的调度方法，在这些负载调度算法中，执行效率最高的是IP负载均衡技术。
LVS的IP负载均衡技术是通过IPVS模块来实现的，IPVS是LVS集群系统的核心软件，它的主要作用是：安装在DirectorServer上，同时在DirectorServer上虚拟出一个IP地址，用户必须通过这个虚拟的IP地址访问服务器。这个虚拟IP一般称为LVS的VIP，即VirtualIP。访问的请求首先经过VIP到达负载调度器，然后由负载调度器从RealServer列表中选取一个服务节点响应用户的请求。在用户的请求到达负载调度器后，调度器如何将请求发送到提供服务的RealServer节点，而RealServer节点如何返回数据给用户，是IPVS实现的重点技术。
为了更好的理解LVS工作模式，我们可以约定一些名词
其中DR模式中重点。其他了解即可。
①.客户端将请求发往前端的负载均衡器，请求报文源地址是CIP(客户端IP),后面统称为CIP)，目标地址为VIP(负载均衡器前端地址，后面统称为VIP)。
②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的目标地址改为了后端服务器的RIP地址并将报文根据算法发送出去。
③.报文送到RealServer后，由于报文的目标地址是自己，所以会响应该请求，并将响应报文返还给LVS。
④.然后lvs将此报文的源地址修改为本机并发送给客户端。
注意：在NAT模式中，RealServer的网关必须指向LVS，否则报文无法送达客户端。
1、NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写，因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈，一般要求最多之能10-20台节点
2、只需要在LB上配置一个公网IP地址就可以了。
3、每台内部的realserver服务器的网关地址必须是调度器LB的内网地址。
4、NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。
优点：集群中的物理服务器可以使用任何支持TCP/IP操作系统，只有负载均衡器需要一个合法的IP地址。
缺点：扩展性有限。当服务器节点（普通PC服务器）增长过多时,负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇在负载均衡器那，速度就会变慢！
①.客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。
②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的源MAC地址改为自己DIP的MAC地址，目标MAC改为了RIP的MAC地址，并将此包发送给RS。
③.RS发现请求报文中的目的MAC是自己，就会将次报文接收下来，处理完请求报文后，将响应报文通过lo接口送给eth0网卡直接发送给客户端。
注意：需要设置lo接口的VIP不能响应本地网络内的arp请求。
1、通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP，目的地址仍然是VIP地址。
2、请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此并发访问量大时使用效率很高（和NAT模式比）
3、因为DR模式是通过MAC地址改写机制实现转发，因此所有RS节点和调度器LB只能在一个局域网里面
4、RS主机需要绑定VIP地址在LO接口（掩码32位）上，并且需要配置ARP抑制。
5、RS节点的默认网关不需要配置成LB，而是直接配置为上级路由的网关，能让RS直接出网就可以。
6、由于DR模式的调度器仅做MAC地址的改写，所以调度器LB就不能改写目标端口，那么RS服务器就得使用和VIP相同的端口提供服务。
7、直接对外的业务比如WEB等，RS的IP最好是使用公网IP。对外的服务，比如数据库等最好使用内网IP。
优点：和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与VS-TUN相比，VS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。
DR模式的效率很高，但是配置稍微复杂一点，因此对于访问量不是特别大的公司可以用haproxy/nginx取代。日1000-2000WPV或者并发请求1万一下都可以考虑用haproxy/nginx。
缺点：所有RS节点和调度器LB只能在一个局域网里面。
②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将在客户端请求报文的首部再封装一层IP报文,将源地址改为DIP，目标地址改为RIP,并将此包发送给RS。
③.RS收到请求报文后，会首先拆开第一层封装,然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP，所以会处理次请求报文，并将响应报文通过lo接口送给eth0网卡直接发送给客户端。
注意：需要设置lo接口的VIP不能在共网上出现。
1.TUNNEL模式必须在所有的realserver机器上面绑定VIP的IP地址
2.TUNNEL模式的vip------>realserver的包通信通过TUNNEL模式，不管是内网和外网都能通信，所以不需要lvsvip跟realserver在同一个网段内
3.TUNNEL模式realserver会把packet直接发给client不会给lvs了
4.TUNNEL模式走的隧道模式，所以运维起来比较难，所以一般不用。
优点：负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。
缺点：隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IPTunneling”(IPEncapsulation)协议，服务器可能只局限在部分Linux系统上。
（FullNetworkAddressTranslation）
无论是DR还是NAT模式，不可避免的都有一个问题：LVS和RS必须在同一个VLAN下，否则LVS无法作为RS的网关。
这引发的两个问题是：
1、同一个VLAN的限制导致运维不方便，跨VLAN的RS无法接入。
2、LVS的水平扩展受到制约。当RS水平扩容时，总有一天其上的单点LVS会成为瓶颈。
Full-NAT由此而生，解决的是LVS和RS跨VLAN的问题，而跨VLAN问题解决后，LVS和RS不再存在VLAN上的从属关系，可以做到多个LVS对应多个RS，解决水平扩容的问题。
Full-NAT相比NAT的主要改进是，在SNAT/DNAT的基础上，加上另一种转换，转换过程如下：
在包从LVS转到RS的过程中，源地址从客户端IP被替换成了LVS的内网IP。
内网IP之间可以通过多个交换机跨VLAN通信。
当RS处理完接受到的包，返回时，会将这个包返回给LVS的内网IP，这一步也不受限于VLAN。
LVS收到包后，在NAT模式修改源地址的基础上，再把RS发来的包中的目标地址从LVS内网IP改为客户端的IP。
Full-NAT主要的思想是把网关和其下机器的通信，改为了普通的网络通信，从而解决了跨VLAN的问题。采用这种方式，LVS和RS的部署在VLAN上将不再有任何限制，大大提高了运维部署的便利性。
1.FULLNAT模式也不需要LBIP和realserverip在同一个网段；fullnat跟nat相比的优点是：保证RS回包一定能够回到LVS；因为源地址就是LVS-->不确定
2.fullnat因为要更新sorceip所以性能正常比nat模式下降10%
性能：DR>TUN>NAT>FULLNAT
由于每个模式的功能不一样，所以具体的选择还是要根据公司业务的选择，实际环境来决定。
LVS是四层负载均衡，也就是说建立在OSI模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS支持TCP/UDP的负载均衡。
LVS的转发主要通过修改IP地址（NAT模式，分为源地址修改SNAT和目标地址修改DNAT）、修改目标MAC（DR模式）来实现。
那么为什么LVS是在第四层做负载均衡？
首先LVS不像HAProxy等七层软负载面向的是HTTP包，所以七层负载可以做的URL解析等工作，LVS无法完成。其次，某次用户访问是与服务端建立连接后交换数据包实现的，如果在第三层网络层做负载均衡，那么将失去「连接」的语义。软负载面向的对象应该是一个已经建立连接的用户，而不是一个孤零零的IP包。后面会看到，实际上LVS的机器代替真实的服务器与用户通过TCP三次握手建立了连接，所以LVS是需要关心「连接」级别的状态的
是通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器与请求客户端建立TCP连接，然后发送Client请求的数据。
由上图可知：在四层负载设备中，把client发送的报文目标地址(原来是负载均衡设备的IP地址)，根据均衡设备设置的选择web服务器的规则选择对应的web服务器IP地址，这样client就可以直接跟此服务器建立TCP连接并发送数据。
也称内容交换，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的服务器。
由上图可知，其实七层负载均衡服务器起了一个代理服务器的作用，我们知道建立一次TCP连接要三次握手；而client要访问webserver要先与七层负载设备进行三次握手后建立TCP连接，把要访问的报文信息发送给七层负载均衡；然后七层负载均衡再根据设置的均衡规则选择特定的webserver，然后通过三次握手与此台webserver建立TCP连接，然后webserver把需要的数据发送给七层负载均衡设备，负载均衡设备再把数据发送给client；所以，七层负载均衡设备起到了代理服务器的作用。
(1)使整个网络更“智能化”，能把对图片类的请求转发到图片服务器，对文字的请求转发到文字服务器
(2)可以有效防止SYNFlood攻击，是网站更安全
因为七层负载均衡设备其实是一个代理服务器，则对此设备的要求也很高。
Lvs的调度算法决定了如何在集群节点之间分布工作负荷。当director调度器收到来自客户端访问VIP的上的集群服务的入站请求时，director调度器必须决定哪个集群节点应该处理请求。
Director调度器用的调度方法基本分为两类：
固定调度算法：rr，wrr，dh，sh动态调度算法：wlc，lc，lblc，lblcr，seq，nq。
对于这些算法我们只要知道常用的，其他了解即可，不需要深入其中的细节。
只根据算法进行调度而不考虑后端服务器的实际连接情况和负载情况
调度器通过”轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载
调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
根据请求的目标IP地址，作为散列键(HashKey)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
源地址散列”调度算法根据请求的源IP地址，作为散列键(HashKey)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空
前端的调度器会根据后端真实服务器的实际连接情况来分配请求,Realserver的负载状态通常由活动链接（active），非活动链接（inactive）和权重来计算。
调度器通过”最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用”最小连接”调度算法可以较好地均衡负载。
在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
在WLC基础上改进，Overhead=（ACTIVE+1）*256/加权，不再考虑非活动状态，把当前处于活动状态的数目+1来实现，数目最小的，接受下次请求，+1的目的是为了考虑加权的时候，非活动连接过多缺陷：当权限过大的时候，会倒置空闲服务器一直处于无连接状态。
基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器;若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器
算法
说明
rr
轮询算法，它将请求依次分配给不同的rs节点，也就是RS节点中均摊分配。这种算法简单，但只适合于RS节点处理性能差不多的情况
wrr
加权轮训调度，它将依据不同RS的权值分配任务。权值较高的RS将优先获得任务，并且分配到的连接数将比权值低的RS更多。相同权值的RS得到相同数目的连接数。
Wlc
加权最小连接数调度，假设各台RS的全职依次为Wi，当前tcp连接数依次为Ti，依次去Ti/Wi为最小的RS作为下一个分配的RS。
Dh
目的地址哈希调度（destinationhashing）以目的地址为关键字查找一个静态hash表来获得需要的RS。
SH
源地址哈希调度（sourcehashing）以源地址为关键字查找一个静态hash表来获得需要的RS。
Lc
最小连接数调度（least-connection）,IPVS表存储了所有活动的连接。LB会比较将连接请求发送到当前连接最少的RS。
Lblc
基于地址的最小连接数调度（locality-basedleast-connection）：将来自同一个目的地址的请求分配给同一台RS，此时这台服务器是尚未满负荷的。否则就将这个请求分配给连接数最小的RS，并以它作为下一次分配的首先考虑。
Lblcr
基于本地的带复制功能的最少连接，与LBLC不同的是LVS将请求IP映射至一个服务池中，使用dh算法调度请求至对应的服务池中，使用lc算法选择服务池中的节点，当服务池中的所有节点超载，使用lc算法从所有后端Realserver中选择一个添加至服务吃中。
Seq
最短期望延迟，它不对inactive状态的连接进行计算，根据overhead=(active+1)*256/weight计算服务器负载，选择overhead最小的服务器进行调度
Nq
当有空闲服务器时，直接调度至空闲服务器，当没有空闲服务器时，使用SED算法进行调度
1、一般的网络服务，如www，mail，mysql等常用的LVS调度算法为：
1、基本轮询调度rr
2、加权最小连接调度wlc
3、加权轮询调度wrr
2、基于局部性的最小连接lblc和带复制的给予局部性最小连接lblcr主要适用于webcache和DBcache，一般不这么用。
3、源地址散列调度SH和目标地址散列调度DH可以结合使用在防火墙集群中，可以保证整个系统的出入口唯一。
实际适用中这些算法的适用范围很多，工作中最好参考内核中的连接调度算法的实现原理，然后根据具体的业务需求合理的选型。
rr，wrr，wlc是常用的。
略
安装lvs
[root@lb01application]#yuminstallipvsadm–y
#YUM安装LVS
[root@lb02application]#ln-s/usr/src/kernels/`uname-r`/usr/src/linux
[root@lb01application]#ipvsadm#<=管理lvs的工具
IPVirtualServerversion1.2.1(size=4096)
ProtLocalAddress:PortSchedulerFlags
->RemoteAddress:PortForwardWeightActiveConnInActConn
[root@lb01application]#lsmod|grepip_vs#查看IPVS加载到内核没有
ip_vs1265340
libcrc32c12461ip_vs
ipv6335589265ip_vs
LVS安装提示：
1、CENTOS5上安装LVS，使用1.24版本。不要用1.26。
2、CENTOS6.4安装LVS，使用1.26版本yuminstalllibnl*popt*-y。
3、安装LVS后，要执行ipvsadm（modprobeip_vs）把ip_vs模块加载到内核。
命令行添加网卡：
ipaddradd10.0.0.3/24deveth0labeleth0:1
在LB上配置LVS
[root@lb01application]#ipvsadm-C#<=清空整个表
[root@lb01application]#ipvsadm--set30560
#<=修改LVS的超时参数
[root@lb01application]#ipvsadm-A-t10.0.0.4:80-swrr-p1
#<=指定虚拟主机
[root@lb01application]#ipvsadm–Ln
#<=列出LVS表
TCP10.0.0.4:80wrrpersistent1
[root@lb01application]#ipvsadm-a-t10.0.0.4:80-r10.0.0.7–g
#<=添加后端真实服务节点
[root@lb01application]#ipvsadm-a-t10.0.0.4:80-r10.0.0.8-g
[root@lb01application]#ipvsadm-Ln
->10.0.0.7:80Route100
->10.0.0.8:80Route100
附：
ipvsadm
【功能说明】：
ipvs直接调用的命令
【语法格式】：
ipsadm[选型]
【选项参数】：
-C清空整个表
-A通过选型，添加虚拟主机
-t添加tcp虚拟主机的地址格式为：host[:port]
-d添加dcp虚拟主机的地址格式为：host[:port]
-s指定轮询算法[rr|wrr|lc|wlc|lblc|lblcr]
-L列出整个表
-n以数字的形式输出地址和端口
-a通过选型，添加真实主机【RS】
-r真实主机的IP地址host(andport)
-g通过直接路由模式，及DR模式
-d删除真实主机
ipvsadm-d-t10.0.0.4:80-r10.0.0.7:80
#<=删除指定的虚拟主机
在web服务器上执行：
[root@web01~]#ipaddradd10.0.0.4/32devlolabello:1#<=临时生效
[root@web01~]#routeadd-host10.0.0.4devlo
#添加主机路由，为了回复数据包的时候经过l0网卡，是数据包的源IP是VIP，不是必须的操作。
[root@web01~]#route-n
KernelIProutingtable
DestinationGatewayGenmaskFlagsMetricRefUseIface
10.0.0.40.0.0.0255.255.255.255UH000lo
在LVSDR模式当中，LB和后端的RS共用一个VIP（对外提供服务），为了保证客户端在请求VIP能得到LB的MAC地址，我们需要在后端的RS上配置ARP抑制。
echo"1">/proc/sys/net/ipv4/conf/lo/arp_ignore
echo"2">/proc/sys/net/ipv4/conf/lo/arp_announce
echo"1">/proc/sys/net/ipv4/conf/all/arp_ignore
echo"2">/proc/sys/net/ipv4/conf/all/arp_announce
arp_ignore=1即不回应不是目标IP是物理网络IP的ARP请求。确保了客户端请求VIP的时候只会得到LB的MAC地址。
arp_announce=2即RS在回复客户端的时候，发送的ARP请求不以自己的VIP的为源IP，确保了不会更新上端路由的ARP缓存，从而保证以后客户端请求VIP的时候读取路由器ARP缓存会得到LB的MAC地址。
说明：
arp_ignore-INTEGE：
定义目标地址为本地IP的ARP询问不同的应答模式
0-（默认值）：回应任何网络接口上对本地IP地址的arp查询请求
1-只回答目标IP地址是来访问网络接口本地地址的ARP查询请求
2-只回答目标IP地址是来访网络接口本地地址的ARP查询请求，且来自网络接口的子网的内。
3-不回应网络界面的ARP请求，而且只对设置的唯一和连接地址做出回应。
4-7-保留未使用
8-不回应所有（本地地址）的ARP查询
arp_announce-INTEGER：
“0″代表是用ip包的源地址来设置ARP请求的源地址。
“1″代表不使用ip包的源地址来设置ARP请求的源地址，如果ip包的源地址是和该端口的IP地址相同的子网，那么用ip包的源地址，来设置ARP请求的源地址，否则使用”2″的设置。
“2″代表不使用ip包的源地址来设置ARP请求的源地址，而由系统来选择最好的接口来发送
当内网的机器要发送一个到外部的ip包，那么它就会请求路由器的Mac地址，发送一个arp请求，这个arp请求里面包括了自己的ip地址和Mac地址，而linux默认是使用ip的源ip地址作为arp里面的源ip地址，而不是使用发送设备上面的，这样在lvs这样的架构下，所有发送包都是同一个VIP地址，那么arp请求就会包括VIP地址和设备Mac，而路由器收到这个arp请求就会更新自己的arp缓存，这样就会造成ip欺骗了，VIP被抢夺，所以就会有问题。
以上的手动操作我们可以通过脚本去实现。
ipvsserver启动脚本
[root@LB01scripts]#catipvs.server.sh
#!/bin/sh
./etc/init.d/functions
VIP=10.0.0.29
PORT=80
RIP=(
10.0.0.8
10.0.0.7
)
start(){
ifconfigeth2:0$VIP/24up
routeadd-host$VIPdeveth2
ipvsadm-C
ipvsadm--set3056030
ipvsadm-A-t$VIP:$PORT-srr-p20
for((i=0;i<${#RIP[*]};i++))
do
ipvsadm-a-t$VIP:$PORT-r${RIP[$i]}-g-w1
done
}
stop(){
ifconfigeth2:0down
routedel-host$VIPdeveth0
case"$1"in
start)
start
echo"IPVSisstarted"
;;
stop)
stop
echo"IPVSisstopped"
restart)
sleep2
echo"IPVSisrestarted"
*)
echo"USAGE:$0{start|stop|restart}"
esac
由于我们在电脑上装的虚拟机上测试。
所以虚拟出来的路由以及LINUX客户端
可能不支持echo"2">/proc/sys/net/ipv4/conf/lo/arp_announce这个参数，所以就会有ARP缓存的问题。
那么我们在浏览器访问的时候可以在每次访问后，清空arp缓存（arp–d）。就会出现1比1的负载均衡。
如果是LINUX上我们可以
[root@lb01~]#arp-d10.0.0.3;curl10.0.0.3
yyyy
yangliheng
1.集群环境：一台Director,两台后端RealServerRS1，RS2
Director:两网卡
eth1:192.168.0.33/24
eth2:172.16.12.1/24
eth1:1:192.168.0.200/24作为VIP地址
RS1:
eth1:172.16.12.11
RS2:
eth1:172.16.12.12
Director的eth0为桥接，eth1和RS1,RS2的eth0使用仅主机模式。在RS1和RS2上使用仅主机模式前先分别安装好LAMP的环境，并设置好测试页面。
2，配置网络
配置RS1：
[root@localhosthtml]#ifconfigeth1172.16.12.11/24
[root@localhosthtml]#routeadddefaultgw172.16.12.1
配置RS2：
[root@localhosthtml]#ifconfigeth1172.16.12.12/24
在Director上的配置：
[root@localhost~]#yuminstallipvsadm-y#安装客户端工具
[root@localhost~]#ifconfigeth2172.16.12.1/24
[root@localhost~]#ifconfigeth1:1192.168.0.200#添加VIP
[root@localhost~]#iptables-F
[root@localhost~]#iptables-tfilter-F
[root@localhost~]#iptables-L-n
ChainINPUT(policyACCEPT)
targetprotoptsourcedestination
ChainFORWARD(policyACCEPT)
ChainOUTPUT(policyACCEPT)
[root@localhost~]#serviceiptablessave
iptables:Savingfirewallrulesto/etc/sysconfig/iptables:[OK]
3.修改内核参数，开启转发功能
[root@localhost~]#vim/etc/sysctl.conf#打开转发功能
net.ipv4.ip_forward=1
[root@localhost~]#sysctl-p#使其生效
4.验证RS1和RS2上面创建的测试页
[root@localhost~]#curl172.16.12.11
web1172.16.12.11
[root@localhost~]#curl172.16.12.12
web2172.16.12.12
5.在Director上添加集群服务
[root@localhost~]#ipvsadm-A-t192.168.0.200:80-srr#创建一个集群服务
[root@localhost~]#ipvsadm-L-n
TCP192.168.0.35:80rr
[root@localhost~]#ipvsadm-a-t192.168.0.200:80-r172.16.12.11-m#-m类型，默认wlc
[root@localhost~]#ipvsadm-a-t192.168.0.200:80-r172.16.12.12-m
TCP192.168.0.200:80rr
->172.16.12.11:80Masq108
->172.16.12.12:80Masq108
好了，LVS的NAT模型就这样配置完成了，然后到浏览器中进行访问：
1.集群环境：一台Director,两台RealServerRS1，RS2，此次使用较简单的配置方法，三个主机都使用桥接模式
eth1:0:192.168.0.200/24作为VIP地址，可以进行浮动
RS1：
eth1:192.168.0.23
RS2：
eth1:192.168.0.24
配置Dircector
[root@localhost~]#ifconfigeth1:0192.168.0.200up#配置VIP
[root@localhost~]#routeadd-host192.168.0.200deveth1:0
配置RS1，修改内核参数，关闭lo的arp通告和lo的arp响应，并配置隐藏地址，并且保证其发出报文经过eth1之前，还要先经过lo:1VIP,使得源地址成为VIP
[root@localhost~]#echo1>/proc/sys/net/ipv4/conf/all/arp_ignore
[root@localhost~]#echo1>/proc/sys/net/ipv4/conf/eth1/arp_ignore
[root@localhost~]#echo2>/proc/sys/net/ipv4/conf/all/arp_announce
[root@localhost~]#echo2>/proc/sys/net/ipv4/conf/eth1/arp_announce
[root@localhost~]#ifconfiglo:0192.168.0.200netmask255.255.255.255broadcast192.168.0.200up
[root@localhost~]#routeadd-host192.168.0.200devlo:0
[root@localhost~]#ifconfiglo:0192.168.0.200netmask255.255.255.255broadcast192.168.0.200up#只广播自己
[root@localhost~]#routeadd-host192.168.0.200devlo:0#目标是192.168.0.200时经过设备lo:0
3，在Director上添加集群服务
[root@localhost~]#ipvsadm-A-t192.168.0.200:80-srr
[root@localhost~]#ipvsadm-a-t192.168.0.200:80-r192.168.0.23-g-w1#使用权重1
[root@localhost~]#ipvsadm-a-t192.168.0.200:80-r192.168.0.24-g-w3#使用权重3
4，在浏览器中进行测试，但是此配置中为RS1和RS2设置了权重，所以转发到后的RS时，响应的次数为3:1。
1、session绑定：始终将同一个请求者的连接定向至同一个RS（第一次请求时仍由调度方法选择）；没有容错能力，有损均衡效果；
2、session复制：在RS之间同步session，因此，每个RS持集群中所有的session；对于大规模集群环境不适用；
3、session服务器：利用单独部署的服务器来统一管理session;
经常用于SSL,建立一个SSL连接，需要交换SSL密钥，当启用持久性连接时，只需要做一次验证即可。
来自于同一个客户端对同一个服务的请求，始终定向至此前选定的realserver。
ipvsadm-A-t192.168.1.200:23-srr-p3600
ipvsadm-a-t192.168.1.200:23-r192.168.1.10-g-w2
ipvsadm-a-t192.168.1.200:23-r192.168.1.20-g-w1
来自于同一个客户端对所有服务的请求，始终定向至此前选定的realserver
ipvsadm-A-t192.168.1.200:0-srr-p600
ipvsadm-a-t192.168.1.200:0-r192.168.1.10-g-w2
ipvsadm-a-t192.168.1.200:0-r192.168.1.20-g-w1
##PNMPP是通过路由前给数据包打标记来实现的
iptables-tmangle-APREROUTING-d192.168.1.200-eth0-ptcp--dport80-jMARK--set-mark3
iptables-tmangle-APREROUTING-d192.168.1.200-eth0-ptcp--dport23-jMARK--set-mark3
ipvsadm-A-f3-srr-p600
ipvsadm-a-f3-r192.168.1.10-g-w2
ipvsadm-a-f3-r192.168.1.20-g-w2
注意:以上三种持久连接均使用了"-p"选项，它保证了持久性，默认为300秒
警告:Director没有定义用户请求的集群服务，将试图自己响应客户端请求。
lvs两大弱点：1、手动配置2、健康检查
不能检测后端服务器的健康状况，总是发送连接到后端
ThePiranhaSolution
不推荐。
这个方案符合简单、易用、高效的运维原则，也是接下来重点讲解的负载均衡及高可用解决方案。
TheKeepalivedSolution
keepalived的作用
1、管理LVS负载均衡软件
2、使配置LVS更加自动化
3）实现LVS主被服务器高可用
生产案例：
生产环境中ipvsadm–L–n发现两台RS的负载不均衡，一台有很多请求，一台米有。并且没有请求的那台RS经测试服务正常，lo:VIP也有。但是就是没有请求。
TCP172.168.1.50:3307wrrpersistent10
->172.168.1.51:3307Route100
->172.168.1.52:3307Route1812758
问题原因：
persistent10的原因，persistent会话保持，当clientA访问网站的时候，LVS把请求分发给了52，那么以后clientA再点击的其他操作其他请求，也会发送给52台机器。
解决办法：
到keepalived中注释掉persistent10然后/etc/init.d/keepalivedreload然后可以看到以后负载均衡两边都请求均衡了。
那么导致负载不均衡的原因有：
1、LVS滋生的会话保持参数设置（-p300,persistent300）。优化：大公司尽量用cookies替代session。
2、LVS调度算法设置，例如:rr，wrr，wlc，lc算法。
3、后端RS节点的会话保持参数。
4、访问量较少的时候，不均衡比较明显。
排错大体的思路就是，要熟悉LVS的工作原理过程，然后根据原理过程来排重，例如：
1、调度器上LVS调度规则及IP的正确性。
2、RS节点上VIP绑定和arp抑制的检查。
生产处理思路：
对RS绑定的VIP做实时监控，出问题报警或者自动处理后报警。
把RS绑定的VIP做成配置文件，例如：vi/etc/sysconfig/network-scripts/lo:0
ARP抑制的配置思路：
当RS端有多个VIP绑定，即使停止了一个VIP也不要修改ARP抑制。
3、RS节点上自身提供服务的检查。
4、辅助排查工具有tepdump，ping等。
5、负载均衡以及反向代理集群的三角形排查理论：
LVS的并发是十万级别的，那么如何突破这个瓶颈呢
1、突破LVS瓶颈，LVSCluster部署（OSPF+LVS）
2、智能DNS
在机房的前端增加DNS轮询。
实现的软件有dnspod,
在生产环境中我们发布代码一般要平滑上线以及灰度发布。发布代码的时候要遵循一定的过程：
开发人员本地测试—办公室内部测试—SVN（配置管理员）--IDC机房测试环境—正式服务器
当我们要在正式服务器上线代码的时候一定要遵循平滑发布的思路即不能让客户感觉到网站在更新：
关于代码的上线更新一般分为2个种类：
1、PHP这类不需要重启服务的代码。我们上线的时候不要直接从本地上传服务器去覆盖。而是应该先拷贝到服务器上的临时目录后，再去覆盖代码。当然我们也可以给代码做软链接，这样我们上线的时候，只需要删除、再建立软链接就可以了。
2、java这类需要重启服务的代码，我们上线的时候可以利用LVS负载来进行平滑上线。假设我们的realserver节点有N个，那么我们需要在LVS上踢掉一半的节点，在这些被踢掉的节点上更新代码，同时在测试LVS集群上测试代码的可靠性。如果没问题，我们再将这些节点加入LVS，同时踢掉另一半的realserver，在另一半的realserver上也上线代码。测试没问题后，再加入到正式的LVS集群当中。这就是利用LVS的负载均衡做的平滑上线代码的思路。
1、arp协议的介绍及实现原理。（这部分是为了理解LVSDR模式的原理。）
2、LVS集群的原理，安装以及手工开发脚本配置实现多种模式的负载均衡。
3、keepalived软件的介绍及高可用应用
2）MYSQL服务的高可用
3）反向代理的高可用
keepalived+nginx代理，也可以实现nginx的高可用性集群，而nginx本身还有负载均衡集群的功能。
keepalived+haproxy代理，也可以实现haproxy的高可用性集群，而haproxy本身还有负载均衡集群的功能。