linux负载均衡lvs原理详细讲解 什么是lvs负载均衡技术
LVS共有三种模式，优缺点比较如下：NAT模式优点：集群中的物理服务器可以使用任何支持TCP/IP操作系统，物理服务器可以分配Internet的保留私有地址，只有负载均衡器需要一个合法的IP地址。不足：扩展性有限。当服务器节点（普通PC服务器）数据增长到20个或更多时,负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包都需要经过负载均衡器再生。假使TCP包的平均长度是536字节的话，平均包再生延迟时间大约为60us（在Pentium处理器上计算的，采用更快的处理器将使得这个延迟时间变短），负载均衡器的最大容许能力为8.93M/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 2.0.36、2.2.9、2.2.10、2.2.12；Solaris 2.5.1、2.6、2.7；FreeBSD 3.1、3.2、3.3；NT4.0无需打补丁；IRIX 6.5；HPUX11等。不足：要求负载均衡器的网卡必须与物理网卡在一个物理段上
lvs的三种负载均衡有什么不同
您好，很高兴为您解答。Virtual Server via NAT VS/NAT 的优点是服务器可以运行任何支持TCP/IP的操作系统，它只需要一个IP地址配置在调度器上，服务器组可以用私有的IP地址。缺点是它的伸缩能力有限，当服务器结点数目升到20时，调度器本身有可能成为系统的新瓶颈，因为在VS/NAT中请求和响应报文都需要通过负载调度器。我们在Pentium166 处理器的主机上测得重写报文的平均延时为60us，性能更高的处理器上延时会短一些。假设TCP报文的平均长度为536 Bytes，则调度器的最大吞吐量为8.93 MBytes/s. 我们再假设每台服务器的吞吐量为800KBytes/s，这样一个调度器可以带动10台服务器。（注：这是很早以前测得的数据） 基于 VS/NAT的的集群系统可以适合许多服务器的性能要求。如果负载调度器成为系统新的瓶颈，可以有三种方法解决这个问题：混合方法、VS/TUN和 VS/DR。在DNS混合集群系统中，有若干个VS/NAT负调度器，每个负载调度器带自己的服务器集群，同时这些负载调度器又通过RR-DNS组成简单的域名。 但VS/TUN和VS/DR是提高系统吞吐量的更好方法。 对于那些将IP地址或者端口号在报文数据中传送的网络服务，需要编写相应的应用模块来转换报文数据中的IP地址或者端口号。这会带来实现的工作量，同时应用模块检查报文的开销会降低系统的吞吐率。 Virtual Server via IP Tunneling 在VS/TUN 的集群系统中，负载调度器只将请求调度到不同的后端服务器，后端服务器将应答的数据直接返回给用户。这样，负载调度器就可以处理大量的请求，它甚至可以调度百台以上的服务器（同等规模的服务器），而它不会成为系统的瓶颈。即使负载调度器只有100Mbps的全双工网卡，整个系统的最大吞吐量可超过 1Gbps。所以，VS/TUN可以极大地增加负载调度器调度的服务器数量。VS/TUN调度器可以调度上百台服务器，而它本身不会成为系统的瓶颈，可以用来构建高性能的超级服务器。VS/TUN技术对服务器有要求，即所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。目前，VS/TUN的后端服务器主要运行Linux操作系统，我们没对其他操作系统进行测试。因为“IP Tunneling”正成为各个操作系统的标准协议，所以VS/TUN应该会适用运行其他操作系统的后端服务器。 Virtual Server via Direct Routing 跟VS/TUN方法一样，VS/DR调度器只处理客户到服务器端的连接，响应数据可以直接从独立的网络路由返回给客户。这可以极大地提高LVS集群系统的伸缩性。跟VS/TUN相比，这种方法没有IP隧道的开销，但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上，服务器网络设备（或者设备别名）不作ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上。如若满意，请点击右侧【采纳答案】，如若还有问题，请点击【追问】希望我的回答对您有所帮助，望采纳！ ~ O(∩_∩)O~
美团面试题：如何设计负载均衡架构支撑千万级用户的高并发访问？
1.1 负载均衡介绍 1.1.1 负载均衡的妙用 1.1.2 为什么要用lvs 那为什么要用lvs呢？ ü 简单一句话，当并发超过了Nginx上限，就可以使用LVS了。 ü 日1000-2000W PV或并发请求1万以下都可以考虑用Nginx。 ü 大型门户网站，电商网站需要用到LVS。 1.2 LVS介绍 LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统，可以在UNIX/LINUX平台下实现负载均衡集群功能。该项目在1998年5月由章文嵩博士组织成立，是 中国国内最早出现的自由软件项目之一 。 1.2.1 相关参考资料 LVS官网： http://www.linuxvirtualserver.org/index.html 相关中文资料 1.2.2 LVS内核模块ip_vs介绍 ü LVS无需安装 ü 安装的是管理工具，第一种叫ipvsadm，第二种叫keepalive ü ipvsadm是通过命令行管理，而keepalive读取配置文件管理 ü 后面我们会用Shell脚本实现keepalive的功能 1.3 LVS集群搭建 1.3.1 集群环境说明 主机说明 web环境说明 web服务器的搭建参照： Tomcat： http://www.cnblogs.com/clsn/p/7904611.html Nginx： http://www.cnblogs.com/clsn/p/7750615.html 1.3.2 安装ipvsadm管理工具 安装管理工具 查看当前LVS状态，顺便激活LVS内核模块。 查看系统的LVS模块。 1.3.3 LVS集群搭建 命令集 ： 检查结果 ： ipvsadm参数说明： (更多参照 man ipvsadm) 1.3.4 在web浏览器配置操作 命令集 ： 至此LVS集群配置完毕 ！ 1.3.5 进行访问测试 浏览器访问： 命令行测试： 抓包查看结果： arp解析查看： 1.4 负载均衡（LVS）相关名词 术语说明： 1.4.1 LVS集群的工作模式--DR直接路由模式 DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器将响应后的处理结果直接返回给客户端用户。 DR技术可极大地提高集群系统的伸缩性。但要求调度器LB与真实服务器RS都有一块物理网卡连在同一物理网段上，即必须在同一局域网环境。 DR直接路由模式说明： a)通过在调度器LB上修改数据包的目的MAC地址实现转发。注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。 b)请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此，并发访问量大时使用效率很高，比Nginx代理模式强于此处。 c)因DR模式是通过MAC地址的改写机制实现转发的，因此，所有RS节点和调度器LB只能在同一个局域网中。需要注意RS节点的VIP的绑定(lo:vip/32)和ARP抑制问题。 d)强调一下：RS节点的默认网关不需要是调度器LB的DIP，而应该直接是IDC机房分配的上级路由器的IP(这是RS带有外网IP地址的情况)，理论上讲，只要RS可以出网即可，不需要必须配置外网IP，但走自己的网关，那网关就成为瓶颈了。 e)由于DR模式的调度器仅进行了目的MAC地址的改写，因此，调度器LB无法改变请求报文的目的端口。LVS DR模式的办公室在二层数据链路层（MAC），NAT模式则工作在三层网络层（IP）和四层传输层（端口）。 f)当前，调度器LB支持几乎所有UNIX、Linux系统，但不支持windows系统。真实服务器RS节点可以是windows系统。 g)总之，DR模式效率很高，但是配置也较麻烦。因此，访问量不是特别大的公司可以用haproxy/Nginx取代之。这符合运维的原则：简单、易用、高效。日1000-2000W PV或并发请求1万以下都可以考虑用haproxy/Nginx(LVS的NAT模式) h)直接对外的访问业务，例如web服务做RS节点，RS最好用公网IP地址。如果不直接对外的业务，例如：MySQL，存储系统RS节点，最好只用内部IP地址。 DR的实现原理和数据包的改变 (a) 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP (b) PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链 (c) IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址 (d) 由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。 (e) RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP，目标IP为CIP (f) 响应报文最终送达至客户端 1.5 在web端的操作有什么含义？ 1.5.1 RealServer为什么要在lo接口上配置VIP？ 既然要让RS能够处理目标地址为vip的IP包，首先必须要让RS能接收到这个包。 在lo上配置vip能够完成接收包并将结果返回client。 1.5.2 在eth0网卡上配置VIP可以吗？ 不可以，将VIP设置在eth0网卡上,会影响RS的arp请求,造成整体LVS集群arp缓存表紊乱，以至于整个负载均衡集群都不能正常工作。 1.5.3 为什么要抑制ARP响应？ ① arp协议说明 为了提高IP转换MAC的效率，系统会将解析结果保存下来，这个结果叫做ARP缓存。 ARP缓存表是把双刃剑 ARP广播进行新的地址解析 测试命令 windows查看arp -a ③arp_announce和arp_ignore详解 lvs在DR模式下需要关闭arp功能 arp_announce 对网络接口上，本地IP地址的发出的，ARP回应，作出相应级别的限制: 确定不同程度的限制,宣布对来自本地源IP地址发出Arp请求的接口 arp_ignore 定义 对目标地定义对目标地址为本地IP的ARP询问不同的应答模式0 抑制RS端arp前的广播情况 抑制RS端arp后广播情况 1.6 LVS集群的工作模式 DR（Direct Routing）直接路由模式 NAT（Network Address Translation） TUN（Tunneling）隧道模式 FULLNAT（Full Network Address Translation） 1.6.1 LVS集群的工作模式--NAT 通过网络地址转换，调度器LB重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器，真实服务器的响应报文处理之后，返回时必须要通过调度器，经过调度器时报文的源地址被重写，再返回给客户，完成整个负载调度过程。 收费站模式---来去都要经过LB负载均衡器。 NAT方式的实现原理和数据包的改变 (a). 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP (b). PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链 (c). IPVS比对数据包请求的服务是否为集群服务，若是，修改数据包的目标IP地址为后端服务器IP，然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP，目标IP为RIP (d). POSTROUTING链通过选路，将数据包发送给Real Server (e). Real Server比对发现目标为自己的IP，开始构建响应报文发回给Director Server。 此时报文的源IP为RIP，目标IP为CIP (f). Director Server在响应客户端前，此时会将源IP地址修改为自己的VIP地址，然后响应给客户端。 此时报文的源IP为VIP，目标IP为CIP LVS-NAT模型的特性 l RS应该使用私有地址，RS的网关必须指向DIP l DIP和RIP必须在同一个网段内 l 请求和响应报文都需要经过Director Server，高负载场景中，Director Server易成为性能瓶颈 l 支持端口映射 l RS可以使用任意操作系统 l 缺陷：对Director Server压力会比较大，请求和响应都需经过director server 1.6.2 LVS集群的工作模式--隧道模式TUN 采用NAT技术时，由于请求和响应的报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。 为了解决这个问题，调度器把请求的报文通过IP隧道(相当于ipip或ipsec )转发至真实服务器，而真实服务器将响应处理后直接返回给客户端用户，这样调度器就只处理请求的入站报文。 由于一般网络服务应答数据比请求报文大很多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。 VS/TUN工作流程,它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。 调度器根据各个服务器的负载情况，连接数多少，动态地选择一台服务器，将原请求的报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的真实服务器。 真实服务器收到报文后，先将收到的报文解封获得原来目标地址为VIP地址的报文, 服务器发现VIP地址被配置在本地的IP隧道设备上(此处要人为配置)，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。 TUN原理和数据包的改变 (a) 当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP 。 (b) PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链 (c) IPVS比对数据包请求的服务是否为集群服务，若是，在请求报文的首部再次封装一层IP报文，封装源IP为为DIP，目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP，目标IP为RIP (d) POSTROUTING链根据最新封装的IP报文，将数据包发至RS（因为在外层封装多了一层IP首部，所以可以理解为此时通过隧道传输）。 此时源IP为DIP，目标IP为RIP (e) RS接收到报文后发现是自己的IP地址，就将报文接收下来，拆除掉最外层的IP后，会发现里面还有一层IP首部，而且目标是自己的lo接口VIP，那么此时RS开始处理此请求，处理完成之后，通过lo接口送给eth0网卡，然后向外传递。 此时的源IP地址为VIP，目标IP为CIP (f) 响应报文最终送达至客户端 LVS-Tun模型特性 1.6.3 LVS集群的工作模式--FULLNAT LVS的DR和NAT模式要求RS和LVS在同一个vlan中，导致部署成本过高；TUNNEL模式虽然可以跨vlan，但RealServer上需要部署ipip隧道模块等，网络拓扑上需要连通外网，较复杂，不易运维。 为了解决上述问题，开发出FULLNAT 该模式和NAT模式的区别是：数据包进入时，除了做DNAT，还做SNAT（用户ip->内网ip） 从而实现LVS-RealServer间可以跨vlan通讯，RealServer只需要连接到内网。类比地铁站多个闸机。 1.7 IPVS调度器实现了如下八种负载调度算法： a) 轮询（Round Robin）RR 调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。 b) 加权轮叫（Weighted Round Robin）WRR 调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。 调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。 c) 最少链接（Least Connections） LC 调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。 如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。 d) 加权最少链接（Weighted Least Connections） Wlc 在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。 e) 基于局部性的最少链接（Locality-Based Least Connections） Lblc "基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。 该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器 是可用的且没有超载，将请求发送到该服务器。 若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务 器，将请求发送到该服务器。 f) 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication） "带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。 它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。 该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器。 若服务器超载，则按"最小连接"原则从这个集群中选出一 台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。 同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的 程度。 g) 目标地址散列（Destination Hashing） Dh "目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。 h) 源地址散列（Source Hashing）SH "源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器。 若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。 1.8 LVS+Keepalived方案实现 1.8.1 keepalived功能 1. 添加VIP 2. 添加LVS配置 3. 高可用（VIP漂移） 4. web服务器 健康 检查 1.8.2 在负载器安装Keepalived软件 # 检查软件是否安装 1.8.3 修改配置文件 lb03上keepalied配置文件 lb04的Keepalied配置文件 keepalived persistence_timeout参数意义 LVS Persistence 参数的作用 http://blog.csdn.net/nimasike/article/details/53911363 1.8.4 启动keepalived服务 1.8.5 在web服务器上进行配置 注意：web服务器上的配置为临时生效，可以将其写入rc.local文件，注意文件的执行权限。 使用curl命令进行测试 至此keepalived+lvs配置完毕 1.9 常见LVS负载均衡高可用解决方案 Ø 开发类似keepalived的脚本，早期的办法，现在不推荐使用。 Ø heartbeat+lvs+ldirectord脚本配置方案，复杂不易控制，不推荐使用 Ø RedHat工具piranha，一个web界面配置LVS。 Ø LVS-DR+keepalived方案，推荐最优方案，简单、易用、高效。 1.9.1 lvs排错思路
