分享阿里云SLB-负载均衡的实现基本原理架构

负载均衡技术原理浅析

https://help.aliyun.com/knowledge_detail/39444.html?spm=5176.7839438.2.6.XBbX5l

阿里定制版的LVC 开源地址：https://github.com/alibaba/LVS?spm=5176.7739444.2.10.WxLaqZ

更新时间：2016-07-12 13:21:10   

一、技术架构
二、LVS技术特色

• FULLNAT技术概述
• SYNPROXY技术概述
• 集群部署方式
• Keepalived优化

三、Tengine技术特色
四、更多功能
 

---

SLB（Server Load Balancer）服务经过设置虚拟服务地址（IP），将位于同一地域（Region）的多台云服务器（Elastic Compute Service，简称ECS）资源虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式，未来自客户端的网络请求分发到云服务器池中。

SLB服务会检查云服务器池中ECS的健康状态，自动隔离异常状态的ECS，从而解决了单台ECS的单点问题，同时提升了应用的总体服务能力。在标准的负载均衡功能以外，SLB服务还具有TCP与HTTP抗DDoS攻击的特性，加强了应用服务器的防御能力。

SLB服务是ECS面向多机方案的一个配套服务，须要同ECS结合使用。

一、技术架构

整个负载均衡系统由3部分构成：四层负载均衡、七层负载均衡和控制系统，以下图所示：

 

• 四层负载均衡
  采用开源软件LVS（Linux Virtual Server）构建，并根据云计算需求对其进行了定制和优化。
• 七层负载均衡
  采用开源软件Tengine构建。
• 控制系统
  用于配置和监控负载均衡系统。

二、LVS技术特色

LVS是全球最流行的四层负载均衡开源软件，能够实现LINUX平台下的负载均衡。

LVS是 基于Linux Netfilter框架实现的一个内核模块（ IPTables是基于Netfilter基本架构实现的一个可扩展的数据报高级管理系统或核外配置工具），名称为IPVS。其钩子函数分别HOOK在LOCAL_IN和FORWARD两个HOOK点，以下图所示：

 

在云计算大规模网络环境下，官方LVS存在以下问题：

• 问题1：LVS支持NAT/DR/TUNNEL三种转发模式，上述模式在多VLAN网络环境下部署时，存在网络拓扑复杂，运维成本高的问题。
• 问题2：和商用负载均衡设备（如F5等）相比，LVS缺乏DDOS攻击防护功能。
• 问题3：LVS采用PC服务器，经常使用Keepalived软件的VRRP心跳协议进行主备部署，其性能没法扩展。
• 问题4：LVS经常使用管理软件Keepalived的配置和健康检查性能不足。

为了解决上述问题， SLB在官方LVS基础上进行了以下定制化和优化：

• 解决1：新增转发模式FULLNAT，实现LVS-RealServer间跨VLAN通信。
• 解决2：新增了SYNPROXY等TCP标志位DDOS攻击防护功能。
• 解决3：采用LVS集群方式部署。
• 解决4：对Keepalived的性能进行了优化。

 

Aliyun-LVS开源地址： https://github.com/alibaba/LVS 。 更多相关说明以下所述。

• FULLNAT技术概述

以下图所示，FULLNAT主要实现方式为：

• 引入local address（内网IP地址）。cip-vip转换为lip->rip，而 lip和rip均为IDC内网IP，能够跨VLAN通信。
• IN/OUT的数据流所有通过LVS，为了保证带宽，采用万兆（10G）网卡。
• FULLNAT转发模式，当前仅支持TCP协议。

 

• SYNPROXY技术概述

LVS针对TCP标志位DDOS攻击，采起以下策略：

• 对于SYN flood类型攻击，利用SYNPROXY模块进行防护。

以下图所示，主要实现方式为：参照Linux TCP协议栈中SYN cookie的思想，LVS代理TCP三次握手。代理过程：

1)     Client发送SYN包给LVS。

2)     LVS构造特殊SEQ的SYN ACK包给Client。

3)     Client回复ACK给LVS。

4)     LVS验证ACK包中ack_seq是否合法。

5)     若是合法，则LVS再和Realserver创建3次握手。

 

•  对于ACK/FIN/RSTFlood类型攻击，查找链接表，若是不存在，则直接丢弃。

 

• 集群部署方式

LVS集群部署方式实现的主要方式为：

• LVS和上联交换机间运行OSPF协议。
• 上联交换机经过ECMP等价路由，将数据流分发给LVS集群。
• LVS集群再转发给业务服务器。

集群方式部署极大的保证了异常状况下，负载均衡服务的稳定性：

• 健壮性
  LVS和交换机间运行OSPF心跳。1个VIP配置在集群的全部LVS上。当一台LVS down，交换机会自动发现并将其从ECMP等价路由中剔除。
• 可扩展
  若是当前LVS集群没法支撑某个VIP的流量，LVS集群能够进行水平扩容。

 

• Keepalived优化

阿里云在SLB中针对LVS管理软件Keepalived进行了全面优化，主要包括：

• 优化了网络异步模型，select方式改成epoll方式。
• 优化了reload过程。

综上所述，基于LVS的SLB四层负载均衡产品具备以下特色；

• 高可用：LVS集群保证了冗余性，无单点。
• 安全：LVS自带攻击防护+云盾，提供了接近于实时防护的能力。
• 健康检查：SLB对后端ECS进行健康检查，自动屏蔽异常状态的ECS，待该ECS恢复正常后自动解除屏蔽。

三、Tengine技术特色

Tengine是阿里巴巴发起的WEB服务器项目，其在Nginx的基础上，针对大访问量网站的需求，添加了不少高级功能和特性是当前最流行的7层负载均衡开源软件之一。Tengine的性能和稳定性已经在大型的网站如淘宝网，天猫商城等获得了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的Web平台。

注：Tengine开源地址http://tengine.taobao.org/。

针对云计算场景，Tengine定制的主要特性以下：

• 继承Nginx-1.4.6的全部特性，100%兼容Nginx的配置。
• 动态模块加载（DSO）支持。加入一个模块再也不须要从新编译整个Tengine。
• 更增强大的负载均衡能力，包括一致性Hash模块、会话保持模块，还能够对后端的服务器进行主动健康检查，根据服务器状态自动上线下线。
• 监控系统的负载和资源占用从而对系统进行保护。
• 对运维人员更友好的出错信息，便于定位出错机器。
• 更强大的防攻击（访问速度限制等）模块。

采用Tengine做为SLB的基础模块的阿里云SLB七层负载均衡产品，具备以下特色：

• 高可用：Tengine集群保证了冗余性，无单点。
• 安全：多维度的CC攻击防护能力。
• 健康检查：SLB对后端ECS进行健康检查，自动屏蔽异常状态的ECS，待该ECS恢复正常后自动解除屏蔽。
• 会话保持：支持7层会话保持功能。
• 一致性：支持一致性hash调度。

四、更多功能

SLB做为负载均衡设备，其最重要的指标是【稳定性】，在进一步提升稳定性方面，主要工做包括：

• 支持集群内部 session同步。
• 采用Anycast技术实现同城双A。

在功能方面有更多支持，包括：

• 白名单访问控制
  从SLB层面实现访问控制，用户能够在SLB系统上配置白名单，便于用户灵活限定外部访问请求。
• 更多服务协议的支持
  当前已经支持HTTPS、UDP。

 

四层和七层负载均衡的区别

 

　　（一）

　　简单理解四层和七层负载均衡:

　　① 所谓四层就是基于IP+端口的负载均衡；七层就是基于URL等应用层信息的负载均衡；同理，还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 换句换说，二层负载均衡会经过一个虚拟MAC地址接收请求，而后再分配到真实的MAC地址；三层负载均衡会经过一个虚拟IP地址接收请求，而后再分配到真实的IP地址；四层经过虚拟IP+端口接收请求，而后再分配到真实的服务器；七层经过虚拟的URL或主机名接收请求，而后再分配到真实的服务器。

　　② 所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。 好比四层的负载均衡，就是经过发布三层的IP地址（VIP），而后加四层的端口号，来决定哪些流量须要作负载均衡，对须要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个链接的全部流量都一样转发到同一台服务器处理。七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，好比同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否须要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，若是你的Web服务器分红两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就能够当用户来访问你的域名时，自动辨别用户语言，而后选择对应的语言服务器组进行负载均衡处理。

　　③ 负载均衡器一般称为四层交换机或七层交换机。四层交换机主要分析IP层及TCP/UDP层，实现四层流量负载均衡。七层交换机除了支持四层负载均衡之外，还有分析应用层的信息，如HTTP协议URI或Cookie信息。

　　一、负载均衡分为L4 switch（四层交换），即在OSI第4层工做，就是TCP层啦。此种Load Balance不理解应用协议（如HTTP/FTP/MySQL等等）。例子：LVS，F5。

　　二、另外一种叫作L7 switch（七层交换），OSI的最高层，应用层。此时，该Load Balancer能理解应用协议。例子：  haproxy，MySQL Proxy。

　　注意：上面的不少Load Balancer既能够作四层交换，也能够作七层交换。

　　（二）

　　负载均衡设备也常被称为"四到七层交换机"，那么四层和七层二者到底区别在哪里？

　　第一，技术原理上的区别。

　　所谓四层负载均衡，也就是主要经过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

　　以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即经过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改成后端服务器IP），直接转发给该服务器。TCP的链接创建，即三次握手是客户端和服务器直接创建的，负载均衡设备只是起到一个相似路由器的转发动做。在某些部署状况下，为保证服务器回包能够正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。

　　所谓七层负载均衡，也称为“内容交换”，也就是主要经过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

　　以常见的TCP为例，负载均衡设备若是要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端创建链接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，而后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种状况下，更相似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别创建TCP链接。因此从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。

　　第二，应用场景的需求。

　　七层应用负载的好处，是使得整个网络更"智能化"。例如访问一个网站的用户流量，能够经过七层的方式，将对图片类的请求转发到特定的图片服务器并能够使用缓存技术；将对文字类的请求能够转发到特定的文字服务器并能够使用压缩技术。固然这只是七层应用的一个小案例，从技术原理上，这种方式能够对客户端的请求和服务器的响应进行任意意义上的修改，极大的提高了应用系统在网络层的灵活性。不少在后台，例如Nginx或者Apache上部署的功能能够前移到负载均衡设备上，例如客户请求中的Header重写，服务器响应中的关键字过滤或者内容插入等功能。

　　另一个经常被提到功能就是安全性。网络中最多见的SYN Flood攻击，即黑客控制众多源客户端，使用虚假IP地址对同一目标发送SYN攻击，一般这种攻击会大量发送SYN报文，耗尽服务器上的相关资源，以达到Denial of Service(DoS)的目的。从技术原理上也能够看出，四层模式下这些SYN攻击都会被转发到后端的服务器上；而七层模式下这些SYN攻击天然在负载均衡设备上就截止，不会影响后台服务器的正常运营。另外负载均衡设备能够在七层层面设定多种策略，过滤特定报文，例如SQL Injection等应用层面的特定攻击手段，从应用层面进一步提升系统总体安全。

　　如今的7层负载均衡，主要仍是着重于应用HTTP协议，因此其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其余TCP应用，例如基于C/S开发的ERP等系统。

　　第三，七层应用须要考虑的问题。

　　1：是否真的必要，七层应用的确能够提升流量智能化，同时必不可免的带来设备配置复杂，负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时须要考虑四层七层同时应用的混杂状况。

　　2：是否真的能够提升安全性。例如SYN Flood攻击，七层模式的确将这些流量从服务器屏蔽，但负载均衡设备自己要有强大的抗DDoS能力，不然即便服务器正常而做为中枢调度的负载均衡设备故障也会致使整个应用的崩溃。

　　3：是否有足够的灵活度。七层应用的优点是可让整个应用的流量智能化，可是负载均衡设备须要提供完善的七层功能，知足客户根据不一样状况的基于应用的调度。最简单的一个考核就是可否取代后台Nginx或者Apache等服务器上的调度功能。可以提供一个七层应用开发接口的负载均衡设备，可让客户根据需求任意设定功能，才真正有可能提供强大的灵活性和智能性。

　　（本节出自 “ADC技术博客” 博客，请务必保留此出处http://virtualadc.blog.51cto.com/3027116/591396）

　　（三）

　　负载均衡四七层介绍:

　　负载均衡（Load Balance）创建在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增长吞吐量、增强网络数据处理能力、提升网络的灵活性和可用性。

　　负载均衡有两方面的含义：首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减小用户等待响应的时间；其次，单个重负载的运算分担到多台节点设备上作并行处理，每一个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力获得大幅度提升。

　　本文所要介绍的负载均衡技术主要是指在均衡服务器群中全部服务器和应用程序之间流量负载的应用，目前负载均衡技术大多数是用于提升诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。

　　负载均衡技术分类

　　目前有许多不一样的负载均衡技术用以知足不一样的应用需求，下面从负载均衡所采用的设备对象、应用的网络层次（指OSI参考模型）及应用的地理结构等来分类。

　　软/硬件负载均衡

　　软件负载均衡解决方案是指在一台或多台服务器相应的操做系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的优势是基于特定环境，配置简单，使用灵活，成本低廉，能够知足通常的负载均衡需求。

　　软件解决方案缺点也较多，由于每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，因此当链接请求特别大的时候，软件自己会成为服务器工做成败的一个关键；软件可扩展性并非很好，受到操做系统的限制；因为操做系统自己的Bug，每每会引发安全问题。

　　硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备咱们一般称之为负载均衡器，因为专门的设备完成专门的任务，独立于操做系统，总体性能获得大量提升，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。 

　　负载均衡器有多种多样的形式，除了做为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet连接之间，有些则以两块网络适配器将这一功能集成到PC中，一块链接到Internet上，一块链接到后端服务器群的内部网络上。

　　通常而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。

　　本地/全局负载均衡

　　负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance，也叫地域负载均衡)，本地负载均衡是指对本地的服务器群作负载均衡，全局负载均衡是指对分别放置在不一样的地理位置、有不一样网络结构的服务器群间做负载均衡。

　　本地负载均衡能有效地解决数据流量过大、网络负荷太重的问题，而且不需花费昂贵开支购置性能卓越的服务器，充分利用现有设备，避免服务器单点故障形成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即便是再给现有服务器扩充升级，也只是简单地增长一个新的服务器到服务群中，而不需改变现有网络结构、中止现有的服务。 

　　全局负载均衡主要用于在一个多区域拥有本身服务器的站点，为了使全球用户只以一个IP地址或域名就能访问到离本身最近的服务器，从而得到最快的访问速度，也可用于子公司分散站点分布广的大公司经过Intranet（企业内部互联网）来达到资源统一合理分配的目的。

　　网络层次上的负载均衡

　　针对网络上负载太重的不一样瓶颈所在，从网络的不一样层次入手，咱们能够采用相应的负载均衡技术来解决现有问题。 

　　随着带宽增长，数据流量不断增大，网络核心部分的数据接口将面临瓶颈问题，原有的单一线路将很难知足需求，并且线路的升级又过于昂贵甚至难以实现，这时就能够考虑采用链路聚合（Trunking）技术。

　　链路聚合技术（第二层负载均衡）将多条物理链路看成一条单一的聚合逻辑链路使用，网络数据流量由聚合逻辑链路中全部物理链路共同承担，由此在逻辑上增大了链路的容量，使其能知足带宽增长的需求。

　　现代负载均衡技术一般操做于网络的第四层或第七层。第四层负载均衡将一个Internet上合法注册的IP地址映射为多个内部服务器的IP地址，对每次 TCP链接请求动态使用其中一个内部IP地址，达到负载均衡的目的。在第四层交换机中，此种均衡技术获得普遍的应用，一个目标地址是服务器群VIP（虚拟 IP，Virtual IP address）链接请求的数据包流经交换机，交换机根据源端和目的IP地址、TCP或UDP端口号和必定的负载均衡策略，在服务器IP和VIP间进行映射，选取服务器群中最好的服务器来处理链接请求。

　　第七层负载均衡控制应用层服务的内容，提供了一种对访问流量的高层控制方式，适合对HTTP服务器群的应用。第七层负载均衡技术经过检查流经的HTTP报头，根据报头内的信息来执行负载均衡任务。 

　　第七层负载均衡优势表如今以下几个方面： 

　　经过对HTTP报头的检查，能够检测出HTTP400、500和600系列的错误信息，于是能透明地将链接请求从新定向到另外一台服务器，避免应用层故障。

　　可根据流经的数据类型（如判断数据包是图像文件、压缩文件或多媒体文件格式等），把数据流量引向相应内容的服务器来处理，增长系统性能。

　　能根据链接请求的类型，如是普通文本、图象等静态文档请求，仍是asp、cgi等的动态文档请求，把相应的请求引向相应的服务器来处理，提升系统的性能及安全性。

　　第七层负载均衡受到其所支持的协议限制（通常只有HTTP），这样就限制了它应用的普遍性，而且检查HTTP报头会占用大量的系统资源，势必会影响到系统的性能，在大量链接请求的状况下，负载均衡设备自身容易成为网络总体性能的瓶颈。

　　负载均衡策略

　　在实际应用中，咱们可能不想仅仅是把客户端的服务请求平均地分配给内部服务器，而无论服务器是否宕机。而是想使Pentium III服务器比Pentium II能接受更多的服务请求，一台处理服务请求较少的服务器能分配到更多的服务请求，出现故障的服务器将再也不接受服务请求直至故障恢复等等。

　　选择合适的负载均衡策略，使多个设备能很好的共同完成任务，消除或避免现有网络负载分布不均、数据流量拥挤反应时间长的瓶颈。在各负载均衡方式中，针对不一样的应用需求，在OSI参考模型的第2、3、4、七层的负载均衡都有相应的负载均衡策略。

　　负载均衡策略的优劣及其实现的难易程度有两个关键因素：1、负载均衡算法，2、对网络系统情况的检测方式和能力。 

　　考虑到服务请求的不一样类型、服务器的不一样处理能力以及随机选择形成的负载分配不均匀等问题，为了更加合理的把负载分配给内部的多个服务器，就须要应用相应的可以正确反映各个服务器处理能力及网络状态的负载均衡算法：

　　轮循均衡（Round Robin）：每一次来自网络的请求轮流分配给内部中的服务器，从1至N而后从新开始。此种均衡算法适合于服务器组中的全部服务器都有相同的软硬件配置而且平均服务请求相对均衡的状况。

　　权重轮循均衡（Weighted Round Robin）：根据服务器的不一样处理能力，给每一个服务器分配不一样的权值，使其可以接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是 3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器获得更多的使用率，避免低性能的服务器负载太重。

　　随机均衡（Random）：把来自网络的请求随机分配给内部中的多个服务器。

　　权重随机均衡（Weighted Random）：此种均衡算法相似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。

　　响应速度均衡（Response Time）：负载均衡设备对内部各服务器发出一个探测请求（例如Ping），而后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与服务器间的最快响应时间。

　　最少链接数均衡（Least Connection）：客户端的每一次请求服务在服务器停留的时间可能会有较大的差别，随着工做时间加长，若是采用简单的轮循或随机均衡算法，每一台服务器上的链接进程可能会产生极大的不一样，并无达到真正的负载均衡。最少链接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的链接数量，当有新的服务链接请求时，将把当前请求分配给链接数最少的服务器，使均衡更加符合实际状况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。 

　　处理能力均衡：此种均衡算法将把服务请求分配给内部中处理负荷（根据服务器CPU型号、CPU数量、内存大小及当前链接数等换算而成）最轻的服务器，因为考虑到了内部服务器的处理能力及当前网络运行情况，因此此种均衡算法相对来讲更加精确，尤为适合运用到第七层（应用层）负载均衡的状况下。

　　DNS响应均衡（Flash DNS）：在Internet上，不管是HTTP、FTP或是其它的服务请求，客户端通常都是经过域名解析来找到服务器确切的IP地址的。在此均衡算法下，分处在不一样地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在同一时间内把此域名解析成各自相对应服务器的IP地址（即与此负载均衡设备在同一位地理位置的服务器的IP地址）并返回给客户端，则客户端将以最早收到的域名解析IP地址来继续请求服务，而忽略其它的IP地址响应。在种均衡策略适合应用在全局负载均衡的状况下，对本地负载均衡是没有意义的。

　　尽管有多种的负载均衡算法能够较好的把数据流量分配给服务器去负载，但若是负载均衡策略没有对网络系统情况的检测方式和能力，一旦在某台服务器或某段负载均衡设备与服务器网络间出现故障的状况下，负载均衡设备依然把一部分数据流量引向那台服务器，这势必形成大量的服务请求被丢失，达不到不间断可用性的要求。因此良好的负载均衡策略应有对网络故障、服务器系统故障、应用服务故障的检测方式和能力：

　　Ping侦测：经过ping的方式检测服务器及网络系统情况，此种方式简单快速，但只能大体检测出网络及服务器上的操做系统是否正常，对服务器上的应用服务检测就无能为力了。

　　TCP Open侦测：每一个服务都会开放某个经过TCP链接，检测服务器上某个TCP端口（如Telnet的23口，HTTP的80口等）是否开放来判断服务是否正常。

　　HTTP URL侦测：好比向HTTP服务器发出一个对main.html文件的访问请求，若是收到错误信息，则认为服务器出现故障。

　　负载均衡策略的优劣除受上面所讲的两个因素影响外，在有些应用状况下，咱们须要未来自同一客户端的全部请求都分配给同一台服务器去负担，例如服务器将客户端注册、购物等服务请求信息保存的本地数据库的状况下，把客户端的子请求分配给同一台服务器来处理就显的相当重要了。有两种方式能够解决此问题，一是根据IP地址把来自同一客户端的屡次请求分配给同一台服务器处理，客户端IP地址与服务器的对应信息是保存在负载均衡设备上的；二是在客户端浏览器 cookie内作独一无二的标识来把屡次请求分配给同一台服务器处理，适合经过代理服务器上网的客户端。

　　还有一种路径外返回模式（Out of Path Return），当客户端链接请求发送给负载均衡设备的时候，中心负载均衡设备将请求引向某个服务器，服务器的回应请求再也不返回给中心负载均衡设备，即绕过流量分配器，直接返回给客户端，所以中心负载均衡设备只负责接受并转发请求，其网络负担就减小了不少，而且给客户端提供了更快的响应时间。此种模式通常用于HTTP服务器群，在各服务器上要安装一块虚拟网络适配器，并将其IP地址设为服务器群的VIP，这样才能在服务器直接回应客户端请求时顺利的达成三次握手。

　　负载均衡实施要素

　　负载均衡方案应是在网站建设初期就应考虑的问题，不过有时随着访问流量的爆炸性增加，超出决策者的意料，这也就成为不得不面对的问题。当咱们在引入某种负载均衡方案乃至具体实施时，像其余的许多方案同样，首先是肯定当前及未来的应用需求，而后在代价与收效之间作出权衡。

　　针对当前及未来的应用需求，分析网络瓶颈的不一样所在，咱们就须要确立是采用哪一类的负载均衡技术，采用什么样的均衡策略，在可用性、兼容性、安全性等等方面要知足多大的需求，如此等等。 

　　无论负载均衡方案是采用花费较少的软件方式，仍是购买代价高昂在性能功能上更强的第四层交换机、负载均衡器等硬件方式来实现，亦或其余种类不一样的均衡技术，下面这几项都是咱们在引入均衡方案时可能要考虑的问题：

　　性能：性能是咱们在引入均衡方案时须要重点考虑的问题，但也是一个最难把握的问题。衡量性能时可将每秒钟经过网络的数据包数目作为一个参数，另外一个参数是均衡方案中服务器群所能处理的最大并发链接数目，可是，假设一个均衡系统能处理百万计的并发链接数，但是却只能以每秒2个包的速率转发，这显然是没有任何做用的。性能的优劣与负载均衡设备的处理能力、采用的均衡策略息息相关，而且有两点须要注意：1、均衡方案对服务器群总体的性能，这是响应客户端链接请求速度的关键；2、负载均衡设备自身的性能，避免有大量链接请求时自身性能不足而成为服务瓶颈。有时咱们也能够考虑采用混合型负载均衡策略来提高服务器群的整体性能，如DNS负载均衡与NAT负载均衡相结合。另外，针对有大量静态文档请求的站点，也能够考虑采用高速缓存技术，相对来讲更节省费用，更能提升响应性能；对有大量ssl/xml内容传输的站点，更应考虑采用ssl/xml加速技术。

　　可扩展性：IT技术突飞猛进，一年之前最新的产品，如今或许已经是网络中性能最低的产品；业务量的急速上升，一年前的网络，如今须要新一轮的扩展。合适的均衡解决方案应能知足这些需求，能均衡不一样操做系统和硬件平台之间的负载，能均衡HTTP、邮件、新闻、代理、数据库、防火墙和 Cache等不一样服务器的负载，而且能以对客户端彻底透明的方式动态增长或删除某些资源。

　　灵活性：均衡解决方案应能灵活地提供不一样的应用需求，知足应用需求的不断变化。在不一样的服务器群有不一样的应用需求时，应有多样的均衡策略提供更普遍的选择。

　　可靠性：在对服务质量要求较高的站点，负载均衡解决方案应能为服务器群提供彻底的容错性和高可用性。但在负载均衡设备自身出现故障时，应该有良好的冗余解决方案，提升可靠性。使用冗余时，处于同一个冗余单元的多个负载均衡设备必须具备有效的方式以便互相进行监控，保护系统尽量地避免遭受到重大故障的损失。

　　易管理性：无论是经过软件仍是硬件方式的均衡解决方案，咱们都但愿它有灵活、直观和安全的管理方式，这样便于安装、配置、维护和监控，提升工做效率，避免差错。在硬件负载均衡设备上，目前主要有三种管理方式可供选择：1、命令行接口（CLI：Command Line Interface），可经过超级终端链接负载均衡设备串行接口来管理，也能telnet远程登陆管理，在初始化配置时，每每要用到前者；2、图形用户接口（GUI：Graphical User Interfaces），有基于普通web页的管理，也有经过Java Applet 进行安全管理，通常都须要管理端安装有某个版本的浏览器；3、SNMP（Simple Network Management Protocol，简单网络管理协议）支持，经过第三方网络管理软件对符合SNMP标准的设备进行管理。

 

 

lvs、haproxy、nginx 负载均衡的比较分析

对软件实现负载均衡的几个软件，小D详细看了一下，从性能和稳定上仍是LVS最牛，基本达到了F5硬件设备的60%性能，其余几个10%都有点困难。

     不过就由于LVS忒牛了，配置也最麻烦了，并且健康检测须要另外配置Ldirector，其余HAPROXY和NGINX本身就用，并且配置超级简单。

 

 

 

     因此小D建议，若是网站访问量不是门户级别的用HAPROXY或者NGINX就OK了，到了门户级别在用LVS+Idirector吧 哈哈

    lvs和nginx均可以用做多机负载的方案，它们各有优缺，在生产环境中须要好好分析实际状况并加以利用。

首先提醒，作技术切不可人云亦云，我云即你云；同时也不可太趋向保守，过于相信旧有方式而等别人来帮你作垫被测试。把全部即时据说到的好东西加以钻研，从而提升本身对技术的认知和水平，乃是一个好习惯。

下面来分析一下二者：

1、lvs的优点：

一、抗负载能力强，由于lvs工做方式的逻辑是很是之简单，并且工做在网络4层仅作请求分发之用，没有流量，因此在效率上基本不须要太过考虑。在我手里的 lvs，仅仅出过一次问题：在并发最高的一小段时间内均衡器出现丢包现象，据分析为网络问题，即网卡或linux2.4内核的承载能力已到上限，内存和 cpu方面基本无消耗。

二、配置性低，这一般是一大劣势，但同时也是一大优点，由于没有太多可配置的选项，因此除了增减服务器，并不须要常常去触碰它，大大减小了人为出错的概率。

三、工做稳定，由于其自己抗负载能力很强，因此稳定性高也是瓜熟蒂落，另外各类lvs都有完整的双机热备方案，因此一点不用担忧均衡器自己会出什么问题，节点出现故障的话，lvs会自动判别，因此系统总体是很是稳定的。

四、无流量，上面已经有所说起了。lvs仅仅分发请求，而流量并不从它自己出去，因此能够利用它这点来作一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。

五、基本上能支持全部应用，由于lvs工做在4层，因此它能够对几乎全部应用作负载均衡，包括http、数据库、聊天室等等。

另：lvs也不是彻底能判别节点故障的，譬如在wlc分配方式下，集群里有一个节点没有配置VIP，会使整个集群不能使用，这时使用wrr分配方式则会丢掉一台机。目前这个问题还在进一步测试中。因此，用lvs也得多多小心为妙。

2、nginx和lvs做对比的结果

一、nginx工做在网络的7层，因此它能够针对http应用自己来作分流策略，好比针对域名、目录结构等，相比之下lvs并不具有这样的功能，因此 nginx单凭这点可利用的场合就远多于lvs了；但nginx有用的这些功能使其可调整度要高于lvs，因此常常要去触碰触碰，由lvs的第2条优势 看，触碰多了，人为出问题的概率也就会大。

二、nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区份内外网，若是是同时拥有内外网的 节点，就至关于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内而且lvs使用direct方式分流，效果较能获得保证。另 外注意，lvs须要向托管商至少申请多一个ip来作Visual IP，貌似是不能用自己的IP来作VIP的。要作好LVS管理员，确实得跟进学习不少有关网络通讯方面的知识，就再也不是一个HTTP那么简单了。

三、nginx安装和配置比较简单，测试起来也很方便，由于它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间了，由于同上所述，lvs对网络依赖比较大，不少时候不能配置成功都是由于网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。

四、nginx也一样能承受很高负载且稳定，但负载度和稳定度差lvs还有几个等级：nginx处理全部流量因此受限于机器IO和配置；自己的bug也仍是难以免的；nginx没有现成的双机热备方案，因此跑在单机上仍是风险较大，单机上的事情全都很难说。

五、nginx能够检测到服务器内部的故障，好比根据服务器处理网页返回的状态码、超时等等，而且会把返回错误的请求从新提交到另外一个节点。目前lvs中 ldirectd也能支持针对服务器内部的状况来监控，但lvs的原理使其不能重发请求。重发请求这点，譬如用户正在上传一个文件，而处理该上传的节点刚 好在上传过程当中出现故障，nginx会把上传切到另外一台服务器从新处理，而lvs就直接断掉了，若是是上传一个很大的文件或者很重要的文件的话，用户可能 会所以而恼火。

六、nginx对请求的异步处理能够帮助节点服务器减轻负载，假如使用apache直接对外服务，那么出现不少的窄带连接时apache服务器将会占用大 量内存而不能释放，使用多一个nginx作apache代理的话，这些窄带连接会被nginx挡住，apache上就不会堆积过多的请求，这样就减小了相 当多的内存占用。这点使用squid也有相同的做用，即便squid自己配置为不缓存，对apache仍是有很大帮助的。lvs没有这些功能，也就没法能 比较。

七、nginx能支持http和email（email的功能估计比较少人用），lvs所支持的应用在这点上会比nginx更多。

在使用上，通常最前端所采起的策略应是lvs，也就是DNS的指向应为lvs均衡器，lvs的优势令它很是适合作这个任务。

重要的ip地址，最好交由lvs托管，好比数据库的ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会愈来愈大，若是更换ip则故障会接踵而至。因此将这些重要ip交给lvs托管是最为稳妥的，这样作的惟一缺点是须要的VIP数量会比较多。

nginx可做为lvs节点机器使用，一是能够利用nginx的功能，二是能够利用nginx的性能。固然这一层面也能够直接使用squid，squid的功能方面就比nginx弱很多了，性能上也有所逊色于nginx。

nginx也可做为中层代理使用，这一层面nginx基本上无对手，惟一能够撼动nginx的就只有lighttpd了，不过lighttpd目前尚未 能作到nginx彻底的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，因此中层代理也拥有一个VIP和lvs是最完美的方案了。

nginx也可做为网页静态服务器，不过超出了本文讨论的范畴，简单提一下。

具体的应用还得具体分析，若是是比较小的网站（日PV<1000万），用nginx就彻底能够了，若是机器也很多，能够用DNS轮询，lvs所耗费的机器仍是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用lvs。

****************************************************************************************************************

Nginx的优势:
性能好，能够负载超过1万的并发。
功能多，除了负载均衡，还能做Web服务器，并且能够经过Geo模块来实现流量分配。
社区活跃，第三方补丁和模块不少
支持gzip proxy
缺点:
不支持session保持。
对后端realserver的健康检查功能效果很差。并且只支持经过端口来检测，不支持经过url来检测。
nginx对big request header的支持不是很好，若是client_header_buffer_size设置的比较小，就会返回400bad request页面。
Haproxy的优势:
它的优势正好能够补充nginx的缺点。支持session保持，同时支持经过获取指定的url来检测后端服务器的状态。
支持tcp模式的负载均衡。好比能够给MySQL的从服务器集群和邮件服务器作负载均衡。
缺点：
不支持虚拟主机(这个很傻啊)
目前没有nagios和cacti的性能监控模板
LVS的优势:
性能好，接近硬件设备的网络吞吐和链接负载能力。
LVS的DR模式，支持经过广域网进行负载均衡。这个其余任何负载均衡软件目前都不具有。
缺点：
比较重型。另外社区不如nginx活跃。

*************************************************************************************

 

如今网络中常见的的负载均衡主要分为两种：一种是经过硬件来进行进行，常见的硬件有比较昂贵的NetScaler、F五、Radware和Array等商用的负载均衡器，也有相似于LVS、Nginx、HAproxy的基于Linux的开源的负载均衡策略,

商用负载均衡里面NetScaler从效果上比F5的效率上更高。对于负载均衡器来讲，不过商用负载均衡因为能够创建在四~七层协议之上，所以适用 面更广因此有其不可替代性，他的优势就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，因此对于规模较小的网络服务来讲暂时尚未须要使用。

另外一种负载均衡的方式是经过软件：比较常见的有LVS、Nginx、HAproxy等，其中LVS是创建在四层协议上面的，而另外Nginx和HAproxy是创建在七层协议之上的，下面分别介绍关于

LVS：使用集群技术和Linux操做系统实现一个高性能、高可用的服务器，它具备很好的可伸缩性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。

LVS的特色是：

一、抗负载能力强、是工做在网络4层之上仅做分发之用，没有流量的产生；

二、配置性比较低，这是一个缺点也是一个优势，由于没有可太多配置的东西，因此并不须要太多接触，大大减小了人为出错的概率；

三、工做稳定，自身有完整的双机热备方案；

四、无流量，保证了均衡器IO的性能不会收到大流量的影响；

五、应用范围比较广，能够对全部应用作负载均衡；

六、LVS须要向IDC多申请一个IP来作Visual IP，所以须要必定的网络知识，因此对操做人的要求比较高。

Nginx的特色是：

一、工做在网络的7层之上，能够针对http应用作一些分流的策略，好比针对域名、目录结构；

二、Nginx对网络的依赖比较小；

三、Nginx安装和配置比较简单，测试起来比较方便；

四、也能够承担高的负载压力且稳定，通常能支撑超过1万次的并发；

五、Nginx能够经过端口检测到服务器内部的故障，好比根据服务器处理网页返回的状态码、超时等等，而且会把返回错误的请求从新提交到另外一个节点，不过其中缺点就是不支持url来检测；

六、Nginx对请求的异步处理能够帮助节点服务器减轻负载；

七、Nginx能支持http和Email，这样就在适用范围上面小不少；

八、不支持Session的保持、对Big request header的支持不是很好，另外默认的只有Round-robin和IP-hash两种负载均衡算法。

HAProxy的特色是：

一、HAProxy是工做在网络7层之上。

二、可以补充Nginx的一些缺点好比Session的保持，Cookie的引导等工做

三、支持url检测后端的服务器出问题的检测会有很好的帮助。

四、更多的负载均衡策略好比：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现

五、单纯从效率上来说HAProxy更会比Nginx有更出色的负载均衡速度。

六、HAProxy能够对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。

***********************************************************************************************

 

如今网站发展的趋势对网络负载均衡的使用是随着网站规模的提高根据不一样的阶段来使用不一样的技术：

第一阶段：利用Nginx或者HAProxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，须要必定的负载均衡，可是 仍然规模较小没有专业的维护团队来进行维护，也没有须要进行大规模的网站部署。这样利用Nginx或者HAproxy就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用HTTP协议就能够。这时是第一选择

第二阶段：随着网络服务进一步扩大，这时单点的Nginx已经不能知足，这时使用LVS或者商用F5就是首要选择，Nginx此时就做为LVS或者 F5的节点来使用，具体LVS或者F5的是选择是根据公司规模，人才以及资金能力来选择的，这里也不作详谈，可是通常来讲这阶段相关人才跟不上业务的提 升，因此购买商业负载均衡已经成为了必经之路。

第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提高，这时不管从开发适合自身产品的定制，以及下降成原本讲开源的LVS，已经成为首选，这时LVS会成为主流。

最终造成比较理想的状态为：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。

 

 

LVS：三种负载均衡方式比较

 

一、什么是LVS？

　　首先简单介绍一下LVS (Linux Virtual Server)究竟是什么东西，其实它是一种集群(Cluster)技术，采用IP负载均衡技术和基于内容请求分发技术。调度器具备很好的吞吐率，将请求均衡地转移到不一样的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，并且无需修改客户端和服务器端的程序。

　　为此，在设计时须要考虑系统的透明性、可伸缩性、高可用性和易管理性。通常来讲，LVS集

　　群采用三层结构，其体系结构如图所示：

　　LVS集群的体系结构

　　二、LVS主要组成部分为：

　　负载调度器(load balancer/ Director)，它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址(咱们可称之为虚拟IP地址)上的。

　　服务器池(server pool/ Realserver)，是一组真正执行客户请求的服务器，执行的服务通常有WEB、MAIL、FTP和DNS等。

　　共享存储(shared storage)，它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。

　　三、LVS负载均衡方式:

　　◆Virtual Server via Network Address Translation NAT(VS/NAT)

　　VS/NAT是一种最简单的方式，全部的RealServer只须要将本身的网关指向Director便可。客户端能够是任意操做系统，但此方式下，一个Director可以带动的RealServer比较有限。在VS/NAT的方式下，Director也能够兼为一台RealServer。VS/NAT的体系结构如图所示。

　　VS/NAT的体系结构

　　◆Virtual Server via IP Tunneling(VS/TUN)

　　IP隧道(IP tunneling)是将一个IP报文封装在另外一个IP报文的技术，这能够使得目标为一个IP地址的数据报文能被封装和转发到另外一个IP地址。IP隧道技术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network)，在其中隧道都是静态创建的，隧道一端有一个IP地址，另外一端也有惟一的IP地址。它的链接调度和管理与VS/NAT中的同样，只是它的报文转发方法不一样。调度器根据各个服务器的负载状况，动态地选择一台服务器，将请求报文封装在另外一个IP报文中，再将封装后的IP报文转发给选出的服务器;服务器收到报文后，先将报文解封得到原来目标地址为 VIP 的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，因此就处理这个请求，而后根据路由表将响应报文直接返回给客户。

　　VS/TUN的体系结构

　　VS/TUN的工做流程：

　　◆Virtual Server via Direct Routing(VS/DR)

　　VS/DR方式是经过改写请求报文中的MAC地址部分来实现的。Director和RealServer必需在物理上有一个网卡经过不间断的局域网相连。 RealServer上绑定的VIP配置在各自Non-ARP的网络设备上(如lo或tunl),Director的VIP地址对外可见，而RealServer的VIP对外是不可见的。RealServer的地址便可以是内部地址，也能够是真实地址。

　　VS/DR的体系结构

　　VS/DR的工做流程

　　VS/DR的工做流程如图所示：它的链接调度和管理与VS/NAT和VS/TUN中的同样，它的报文转发方法又有不一样，将报文直接路由给目标服务器。在VS/DR中，调度器根据各个服务器的负载状况，动态地选择一台服务器，不修改也不封装IP报文，而是将数据帧的MAC地址改成选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域网上发送。由于数据帧的MAC地址是选出的服务器，因此服务器确定能够收到这个数据帧，从中能够得到该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上，服务器处理这个报文，而后根据路由表将响应报文直接返回给客户。

　　VS/DR的工做流程

　　四、三种负载均衡方式比较：

　　◆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端口上。

　　三种LVS负载均衡技术的优缺点概括如下表：

　　VS/NATVS/TUNVS/DR

　　服务器操做系统任意支持隧道多数(支持Non-arp)

　　服务器网络私有网络局域网/广域网局域网

　　服务器数目(100M网络)10~20100大于100

　　服务器网关负载均衡器本身的路由本身的路由

　　效率通常高最高

　　注：以上三种方法所能支持最大服务器数目的估计是假设调度器使用100M网卡，调度器的硬件配置与后端服务器的硬件配置相同，并且是对通常Web服务。使 用更高的硬件配置(如千兆网卡和更快的处理器)做为调度器，调度器所能调度的服务器数量会相应增长。当应用不一样时，服务器的数目也会相应地改变。因此，以上数据估计主要是为三种方法的伸缩性进行量化比较。

　　五、负载均衡调度算法

　　◆最少的链接方式(Least Connection)：传递新的链接给那些进行最少链接处理的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。

　　◆最快模式(Fastest)：传递链接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

　　◆观察模式(Observed)：链接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

　　◆预测模式(Predictive)：BIG-IP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测)

　　◆动态性能分配(Dynamic Ratio-APM):BIG-IP 收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。

　　◆动态服务器补充(Dynamic Server Act.):当主服务器群中因故障致使数量减小时，动态地将备份服务器补充至主服务器群。

　　◆服务质量(QoS):按不一样的优先级对数据流进行分配。

　　◆服务类型(ToS): 按不一样的服务类型(在Type of Field中标识)负载均衡对数据流进行分配。

　　◆规则模式：针对不一样的数据流设置导向规则，用户可自行

 

 

一、什么是LVS？

　　首先简单介绍一下LVS (Linux Virtual Server)究竟是什么东西，其实它是一种集群(Cluster)技术，采用IP负载均衡技术和基于内容请求分发技术。调度器具备很好的吞吐率，将请求均衡地转移到不一样的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，并且无需修改客户端和服务器端的程序。

　　为此，在设计时须要考虑系统的透明性、可伸缩性、高可用性和易管理性。通常来讲，LVS集

　　群采用三层结构，其体系结构如图所示：

　　LVS集群的体系结构

　　二、LVS主要组成部分为：

　　负载调度器(load balancer/ Director)，它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址(咱们可称之为虚拟IP地址)上的。

　　服务器池(server pool/ Realserver)，是一组真正执行客户请求的服务器，执行的服务通常有WEB、MAIL、FTP和DNS等。

　　共享存储(shared storage)，它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。

　　三、LVS负载均衡方式:

　　◆Virtual Server via Network Address Translation NAT(VS/NAT)

　　VS/NAT是一种最简单的方式，全部的RealServer只须要将本身的网关指向Director便可。客户端能够是任意操做系统，但此方式下，一个Director可以带动的RealServer比较有限。在VS/NAT的方式下，Director也能够兼为一台RealServer。VS/NAT的体系结构如图所示。

　　VS/NAT的体系结构

　　◆Virtual Server via IP Tunneling(VS/TUN)

　　IP隧道(IP tunneling)是将一个IP报文封装在另外一个IP报文的技术，这能够使得目标为一个IP地址的数据报文能被封装和转发到另外一个IP地址。IP隧道技术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network)，在其中隧道都是静态创建的，隧道一端有一个IP地址，另外一端也有惟一的IP地址。它的链接调度和管理与VS/NAT中的同样，只是它的报文转发方法不一样。调度器根据各个服务器的负载状况，动态地选择一台服务器，将请求报文封装在另外一个IP报文中，再将封装后的IP报文转发给选出的服务器;服务器收到报文后，先将报文解封得到原来目标地址为 VIP 的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，因此就处理这个请求，而后根据路由表将响应报文直接返回给客户。

　　VS/TUN的体系结构

　　VS/TUN的工做流程：

　　◆Virtual Server via Direct Routing(VS/DR)

　　VS/DR方式是经过改写请求报文中的MAC地址部分来实现的。Director和RealServer必需在物理上有一个网卡经过不间断的局域网相连。 RealServer上绑定的VIP配置在各自Non-ARP的网络设备上(如lo或tunl),Director的VIP地址对外可见，而RealServer的VIP对外是不可见的。RealServer的地址便可以是内部地址，也能够是真实地址。

　　VS/DR的体系结构

　　VS/DR的工做流程

　　VS/DR的工做流程如图所示：它的链接调度和管理与VS/NAT和VS/TUN中的同样，它的报文转发方法又有不一样，将报文直接路由给目标服务器。在VS/DR中，调度器根据各个服务器的负载状况，动态地选择一台服务器，不修改也不封装IP报文，而是将数据帧的MAC地址改成选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域网上发送。由于数据帧的MAC地址是选出的服务器，因此服务器确定能够收到这个数据帧，从中能够得到该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上，服务器处理这个报文，而后根据路由表将响应报文直接返回给客户。

　　VS/DR的工做流程

　　四、三种负载均衡方式比较：

　　◆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端口上。

　　三种LVS负载均衡技术的优缺点概括如下表：

　　VS/NATVS/TUNVS/DR

　　服务器操做系统任意支持隧道多数(支持Non-arp)

　　服务器网络私有网络局域网/广域网局域网

　　服务器数目(100M网络)10~20100大于100

　　服务器网关负载均衡器本身的路由本身的路由

　　效率通常高最高

　　注：以上三种方法所能支持最大服务器数目的估计是假设调度器使用100M网卡，调度器的硬件配置与后端服务器的硬件配置相同，并且是对通常Web服务。使 用更高的硬件配置(如千兆网卡和更快的处理器)做为调度器，调度器所能调度的服务器数量会相应增长。当应用不一样时，服务器的数目也会相应地改变。因此，以上数据估计主要是为三种方法的伸缩性进行量化比较。

　　五、负载均衡调度算法

　　◆最少的链接方式(Least Connection)：传递新的链接给那些进行最少链接处理的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配, 直到其恢复正常。

　　◆最快模式(Fastest)：传递链接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

　　◆观察模式(Observed)：链接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

　　◆预测模式(Predictive)：BIG-IP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测)

　　◆动态性能分配(Dynamic Ratio-APM):BIG-IP 收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。

　　◆动态服务器补充(Dynamic Server Act.):当主服务器群中因故障致使数量减小时，动态地将备份服务器补充至主服务器群。

　　◆服务质量(QoS):按不一样的优先级对数据流进行分配。

　　◆服务类型(ToS): 按不一样的服务类型(在Type of Field中标识)负载均衡对数据流进行分配。

　　◆规则模式：针对不一样的数据流设置导向规则，用户可自行