linux负载均衡lvs原理详细讲解 什么是lvs负载均衡技术

LVS共有三种模式，优缺点比较如下：

NAT模式

优点：集群中的物理服务器可以使用任何支持TCP/IP操作系统，物理服务器可以分配Internet的保留私有地址，只有负载均衡器需要一个合法的IP地址。

不足：扩展性有限。当服务器节点（普通PC服务器）数据增长到20个或更多时,负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包都需要经过负载均衡器再生。假使TCP包的平均长度是536字节的话，平均包再生延迟时间大约为60us（在Pentium处理器上计算的，采用更快的处理器将使得这个延迟时间变短），负载均衡器的最大容许能力为893M/s，假定每台物理服务器的平台容许能力为400K/s来计算，负责均衡器能为22台物理服务器计算。

TUN模式

我们发现，许多Internet服务（例如WEB服务器）的请求包很短小，而应答包通常很大。

优点：负载均衡器只负责将请求包分发给物理服务器，而物理服务器将应答包直接发给用户。所以，负载均衡器能处理很巨大的请求量，这种方式，一台负载均衡能为超过100台的物理服务器服务，负载均衡器不再是系统的瓶颈。使用VS-TUN方式，如果你的负载均衡器拥有100M的全双工网卡的话，就能使得整个Virtual Server能达到1G的吞吐量。

不足：但是，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，我仅在Linux系统上实现了这个，如果你能让其它操作系统支持，还在探索之中。

DR模式

优点：和VS-TUN一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与VS-TUN相比，VS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器，其中包括：Linux 2036、229、2210、2212；Solaris 251、26、27；FreeBSD 31、32、33；NT40无需打补丁；IRIX 65；HPUX11等。

不足：要求负载均衡器的网卡必须与物理网卡在一个物理段上

  使用Keepalived可以很方便的配置LVS，而Keepalived实现高可用往往都是一主多从的模式，这样的话备机就处于standby状态，浪费了资源。我们可以将LVS和RS节点合设在一起，这样备机虽然不会作为LVS节点转发，但是也可以作为真实服务器提供服务，充分利用资源。

  上面是一份常见的Keepalived LVS-DR模式的配置。在LVS不与RS合设的情况下，这份配置是没有问题的。

  但是，如果LVS与RS合设，这个配置就会带来一个非常严重的问题: 乒乓现象 。

  如上所示，仅仅是一个telnet发起的syn请求，就已经能造成如此巨大的转发量了，如果是生产环境，必然会引起网卡流量风暴。

  要想解决乒乓问题，只需要将引发乒乓现象的必要条件给破坏掉。很显然条件1和2都是不能改变的，不然这个问题本身也没有存在的意义了。那我们只能拿条件3开刀了。

  既然备机加载了LVS转发规则就会引发乒乓，那么能否让备机不加载规则呢？

  而对于备机，我们可以在/etc/keepalived下创建一个目录，如vs_dir，利用notify_backup脚本将virtual_server配置挪到vs_dir中隐藏起来，避免Keepalived加载。当backup节点切换到master状态时，由notify_master节点将目录中隐藏的vs配置挪到/etc/keepalived下，使Keepalived可以正常加载。

  上面的办法虽然能解决问题，但是比较繁琐，也不利于故障快速切换。那么我们换个思路，在备机加载了LVS规则的情况下，要想解决问题，只需保证主机上转发过来的消息不进入备机的LVS转发，而是直接由备机的真实服务进行处理。

  LVS备机上配置iptables，其中$MAC_Director_A 表示主机的mac地址

  keepalivedconf中virtual_server的配置

  注意，iptables中给数据包打上的mark值只是一个系统内核中数据结构，并不会实际改变数据包的内容，数据包ip头部中也没有mark的字段。所以备机上收到来自主机转发的请求中，是没有mark标记的，而备机的iptables中也限定了来自主机mac的请求不会打标记，所以请求是不会进入备机的LVS虚拟服务中，而是被RS服务直接处理。

  下面介绍的mark标记和lvs工作分别对应netfilter框架中的位置，应该会有助于理解fwmark为什么能解决乒乓问题

  如果发生了主备切换，则需要在脚本中调整主备机中的这条iptables配置，将新主机中的配置清除，新备机中加上该配置。

  综合来看以上各种方法，更倾向于使用fwmark。方法一实现过于繁琐，也不利于故障快速切换。方法3需要在切换时更改对应角色的iptables配置，增加了切换的不稳定性。而fwmark在部署阶段配置好后则无需再变动，更为可靠。只是要注意防止系统重启导致iptables规则失效。

集群和负载均衡的区别如下：

1、集群(Cluster)

所谓集群是指一组独立的计算机系统构成的一个松耦合的多处理器系统,它们之间通过网络实现进程间的通信应用程序可以通过网络共享内存进行消息传送,实现分布式计算机

2、负载均衡(Load Balance)

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

3、特点

(1)高可靠性(HA)利用集群管理软件,当主服务器故障时,备份服务器能够自动接管主服务器的工作,并及时切换过去,以实现对用户的不间断服务

(2)高性能计算(HP)即充分利用集群中的每一台计算机的资源,实现复杂运算的并行处理,通常用于科学计算领域,比如基因分析化学分析等

(3)负载平衡即把负载压力根据某种算法合理分配到集群中的每一台计算机上,以减轻主服务器的压力,降低对主服务器的硬件和软件要求

LVS系统结构与特点

1 Linux Virtual Server:简称LVS是由中国一个Linux程序员章文嵩博士发起和领导的,基于Linux系统的服务器集群解决方案,其实现目标是创建一个具有良好的扩展性高可靠性高性能和高可用性的体系许多商业的集群产品,比如RedHat的Piranha Turbo Linux公司的Turbo Cluster等,都是基于LVS的核心代码的

2 体系结构:使用LVS架设的服务器集群系统从体系结构上看是透明的,最终用户只感觉到一个虚拟服务器物理服务器之间可以通过高速的 LAN或分布在各地的WAN相连最前端是负载均衡器,它负责将各种服务请求分发给后面的物理服务器,让整个集群表现得像一个服务于同一IP地址的虚拟服务器

3 LVS的三种模式工作原理和优缺点: Linux Virtual Server主要是在负载均衡器上实现的,负载均衡器是一台加了 LVS Patch的22x版内核的Linux系统LVS Patch可以通过重新编译内核的方法加入内核,也可以当作一个动态的模块插入现在的内核中

解决高并发访问，或者说改善，提高一点思路：

1使用Squid或者Varnish做缓存代理，将经常访问的等静态内容缓存起来，提高访问速度；

2使用CDN内容分发网络，减少主服务器的压力（附CDN相关内容：CDN通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近）；

3使用LVS服务器负载均衡，LVS服务器结合Keepalived做高可用；

4LVS下面还可跟Nginx做负载均衡，再次分担压力，比如淘宝使用的再Nginx基础上改进的Tnginx。

5DNS服务器上也可下功夫，比如做高级视图等等，这样可以解决不同网段访问Web服务器的速度问题；

6最大的瓶颈还是在IO上，比如存储IO，比如数据库的IO。存储一方面需要保证数据不丢失，另一方面需要保证性能，比如做RAID、LVM；存储还需要考虑使用一套存储之间的数据同步（GFS、OCFS可以实现），数据的备份等等；数据库的话可以考虑使用查询缓存等等，这块我也正在学习中，展开有很多东西；

7程序的话也可以优化，比如如果是Java Web程序，并且使用了Hibernate框架，就可以考虑使用查询缓存了；

8硬件层：比如提高带宽，购买高转数性能好的硬盘等等；

这个架构我完全无法理解，为毛要2台lvs，一般2台lvs是为了分流或高可用，好吧我暂时这么理解他的意图，1台nginx是作为反向代理，简单理解就是在客户端看来服务器端就是一台机器，防止其他人员了解你的后端架构和处理流程，nginx也可以减轻web的资源消耗主要是内存和io，也可以配置当成日志服务器，减轻web的压力，但是他后端就一台web啊，用这个架构为毛啊，好吧我暂时理解为他是为了以后方便拓展架构；1台dns服务器，为毛啊，无法理解，如果只是为了网站本身需要完全可以自解析，直接写hosts不是更方便，好吧，其实架设dns服务器是个好习惯，但是在资源有限的前提下，我认为不如把dns换成web，资源利用率更高；lvs和nginx都有负载均衡的作用，小架构1台nginx完全可以搞定，2台lvs纯属浪费；至于123456的问题，nginx配置，推荐《决战nginx》高性能web服务器详解与运维；至于架构原理，推荐《构建高可用linux服务器》余洪春

简单说下流程：正常应该是，客户端包先到lvs，lvs做了高可用，lvs分发给nginx，nginx查询dns后分发给web

阅读本文前，需熟悉OSI七层参考模型。

常见的负载均衡设备，有F5，Haproxy，lvs, nginx等。

F5是商用硬件负载均衡，性能很好，但是价格昂贵，除了负载均衡，还有应用交换、会话交换、状态监控等众多功能。

F5一般做四层负载均衡，但也支持七层负载均衡。

Haproxy(以下简称ha)是软件负载均衡，开源，一般做七层负载均衡，但也支持四层负载均衡。

Linux Virtual Server(以下简称lvs)是软件负载均衡，开源，二层或四层负载均衡，已集成到linux内核，自身有完备的热备方案（keepalived+lvs），稳定性极强。

nginx也是软件负载均衡，开源，通过反向代理实现负载均衡，是七层负载均衡，性能不如上面的几个。

tips1

有些公司，测试环境用ha/lvs/nginx，生产环境用F5。

tips2

nginx做web服务器时，一般做静态资源服务器和php的web服务器，所以很多公司，会采用F5+nginx或者ha+nginx的架构

tips3

微服务中的ribbon属于客户端负载均衡，上面的几种都是服务端负载均衡

二层负载均衡

在数据链路层通过修改mac地址实现，如lvs的DR模式（直接路由模式）

三层负载均衡

在网络层通过DNAT协议修改目标地址实现

四层负载均衡

用ip+端口实现请求转发

备注：tcp报文里并没有ip，但是四层负载均衡可以用ip+端口，是因为server可以拿到ip

七层负载均衡

通过重新发起http请求实现，即client把请求发给lb，lb把请求代发给server，再把server的响应返回给client，因此七层负载均衡也经常被称为代理，七层负载均衡设备也被称为代理设备。

七层负载均衡常用于内网与外网的通信，比如内网无法直接访问外网，需要通过代理设备代发http请求，这种情况下，代理设备需要配置双网卡，以同时与内外网络通信。

由于需要重发http请求，七层负载均衡性能较差，但是更智能和安全，因为应用层可以获取甚至修改请求的真实内容（即应用数据），比如cookie、url等，可以做一些智能的操作，比如根据cookie/url转发请求，也可以做一些安全操作，比如过滤特定报文、防止SYN Flood攻击等。

使用七层负载均衡时，服务的性能受限于代理设备的网卡带宽。

常见的负载均衡策略，有轮询、加权轮询、ip_hash、cookie、url_hash，根据服务器响应时间转发、根据最少连接转发等等。

备注：nginx可以安装第三方插件，使用第三方实现的策略

轮询：按服务器列表顺序转发请求，轮询是nginx默认的策略，本策略适合服务器配置相当、请求无状态（即不依赖session）的场景

加权轮询：如果不同服务器配置不同，可以为配置高的服务器增加权重

ip_hash：根据ip哈希结果转发，可以实现同一用户持续请求同一服务器（即会话保持），适合有状态（即依赖session）的场景，对png、jpg、js、css等静态资源的请求，不适合使用本策略

cookie：根据特定cookie转发请求，一般也是用于实现会话保持，比如为服务器A、B分别增加service-flag=a、service-flag=b的cookie，后续请求根据cookie转发

可以参考 haproxy实现会话保持

url_hash：根据url哈希结果转发，同一个接口始终请求同一台服务器，一般配合缓存使用，缓存接口返回结果

根据服务器响应时间转发：优先转发到响应时间较快的服务器

根据最少连接转发：优先转发到连接数较少的服务器

F5有一些特有的负载均衡策略：利用从应用程序和服务器收集到的各项性能指标，分析并转发

负载均衡有两个步骤：

1根据什么算法选择真实服务端，即负载均衡策略，如轮询、加权轮询、ip_hash、cookie、url_hash等；

2把请求转发到真实服务器，转发方式有二层到七层负载均衡

keepalived软件一开始是专为lvs设计的，后来加入了可以实现高可用的VRRP (Virtual Router Redundancy Protocol ,虚拟路由器冗余协议）功能，因此，keepalived还可以作为nginx、haproxy、mysql等服务的高可用解决方案。

以nginx为例，为了防止nginx本身由于宕机等原因导致网站不可用，一般会搭两套nginx反向代理，用keepalived提供一个VIP。

一般情况下，VIP只在nginx主节点上工作，如果nginx主节点不可用了，VIP会自动漂移到从节点，自动漂移的原理即VRRP协议。

VIP漂移到从节点后，如果主节点恢复正常了，VIP是否漂移回主节点，取决于当前模式是抢占模式还是非抢占模式。

下图是一张简单的架构图，解释如下：

以上观点纯属个人意见，如果错误，欢迎指出，有些地方写的很简单，是因为我也不懂~