web 应用负载均衡策略

1. 名词解释

1. 正向代理与反向代理

简单说
我们内网访问 facebook 用的代理就叫正向代理

从美国访问我们内网需要的代理就叫反向代理

多台服务器处于一个内网,而我们要访问这些服务器,中间加一台 反向代理,根据各台服务器的负载,指定访问其中一台。这就叫负载均衡。反向代理一般就是来干这个的。 代理服务器来接受外部的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给外部的请求连接的客户端,此时代理服务器对外就表现为一个服务器。

反向代理一般作用:
1:减轻源服务器负载
2:保障源服务器安全
3:对源服务器进行负载均衡(Load Balance)。

2. 几个组件

2. Apache(web 服务器、负载均衡器)

它是 Apache 软件基金会的一个开放源代码的跨平台的网页服务器,属于老牌的 web 服务器了,支持基于 Ip 或者域名的虚拟主机,支持代理服务器,支持安全 Socket 层(SSL)等等,目前互联网主要使用它做静态资源服务器,也可以做代理服务器转发请求(如:图片链等)或者负载均衡器,结合 tomcat 等 servlet 容器处理 jsp。

使用 web 服务器的用途:

l 提升对静态文件的处理性能

l 利用 Web 服务器来做负载均衡以及容错

l 无缝的升级应用程序

3. LVS

LVS(Linux Virtual Server,Linux 虚拟服务器),是章文嵩博士开发的开放软件,目前已经集成到 Linux 内核中。是一种虚拟的服务器集群系统。

基于不同的网络技术,LVS 支持多种负载均衡机制。包括:VS/NAT(基于网络地址转换技术)、VS/TUN(基于 IP 隧道技术)和 VS/DR(基于直接路由技术)。

1. VS/NAT

NAT(Network AddressTranslation,网络地址转换)也叫做网络掩蔽或者 IP 掩蔽,是将 IP 数据包头中的 IP 地址转换为另一个 IP 地址的过程。

NAT 能够将私有(保留)地址转化为合法 IP 地址,通常用于一个公共 IP 地址和多个内部私有 IP 地址直接的映射,广泛应用于各种类型 Internet 接入方式和各种类型的网络中。

通过使用 NAT 将目的地址转换到多个服务器的方式,可以实现负载均衡,同时能够隐藏并保护内部服务器,避免来自网络外部的攻击。商用负载均衡设备如 Cisco 的 LocalDirector、F5 的 Big/IP 和 Alteon 的 ACEDirector 都是基于 NAT 方法。

VS/NAT(Virtual Server viaNetwork Address Translation)是基于 NAT 技术实现负载均衡的方法。其架构如下图所示:

  1. 客户通过 Virtual IP Address(虚拟服务的 IP 地址)访问网络服务时,请求报文到达调度器

    2. 调度器根据连接调度算法从一组真实服务器中选出一台服务器,将报文的目标地址Virtual IP Address改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最后将修改后的报文发送给选出的服务器。
    
    1. 真实的服务器处理请求,并将响应报文发到调度器。
  2. 调度器将报文的源地址和源端口改为 Virtual IP Address 和相应的端口

  3. 调度器将修改过的报文发给用户

在 VS/NAT 的集群系统中,请求和响应的数据报文都需要通过负载调度器,当真实服务器的数目在 10 台和 20 台之间时,负载调度器将成为整个集群系统的新瓶颈。大多数 Internet 服务都有这样的特点:请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理,即在负载调度器中只负责调度请求而响应直接返回给客户,将极大地提高整个集群系统的吞吐量。比如 IP 隧道技术。

2. VS/TUN(IP 隧道技术)

IP Tunneling(IP 隧道)技术,又称为 IP 封装技术(IP encapsulation),是一种在网络之间传递数据的方式。可以将一个 IP 报文封装到另一个 IP 报文(可能是不同的协议)中,并转发到另一个 IP 地址。IP 隧道主要用于移动主机和虚拟私有网络(Virtual Private Network),在其中隧道都是静态建立的,隧道一端有一个 IP 地址,另一端也有唯一的 IP 地址。

VS/TUN(VirtualServer via IP Tunneling)是基于隧道技术实现负载均衡的方法。其架构如下图所示:

VS/TUN 与 VS/NAT 的工作机制大体上相同,区别在于:

  1. 调度器转发报文的时候进行了协议的二次封装,真实的服务器接收到请求后先进行解包。过程如下图所示:

  2. 响应报文从后端服务器直接返回给客户,不需要经过调度器。

3. VS/DR

DR(Direct Routing, 直接路由), 路由器学习路由的方法之一。路由器对于自己的网络接口所直连的网络之间的通信,可以自动维护路由表,而且不需要进行路由计算。

直接路由通常用在一个三层交换机连接几个 VLAN 的情况,只要设置直接路由 VLAN 之间就可以通信,不需要设置其他的路由方式。

VS/DR(Virtual Server via Direct Routing)是基于直接路由实现负载均衡的方法。其架构如下图所示:

  1. 跟 VS/TUN 方法相同,VS/DR 利用大多数 Internet 服务的非对称特点,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提高整个集群系统的吞吐量。

  2. VS/DR 要求调度器和服务器组都必须在物理上有一个网卡通过不分段的局域网相连,即通过交换机或者高速的 HUB 相连,中间没有隔有路由器。VIP 地址为调度器和服务器组共享,调度器配置的 VIP 地址是对外可见的,用于接收虚拟服务的请求报文;所有的服务器把 VIP 地址配置在各自的 Non-ARP 网络设备上,它对外面是不可见的,只是用于处理目标地址为 VIP 的网络请求。

VS/DR 的整个过程与 VS/TUN 非常类似,不同之处在于调度器不对请求包进行二次封装,只是将目标 MAC 地址更改为经过调度算法选出的目标服务器的 MAC 地址。如下图:

4. VS/FULL

如上节所述,前面三种传统的负载均衡机制各自存在一些不足。

VS/FULLNAT是为了解决这些不足而新开发的一种转发模式。VS/FULLNAT 的特点是:

  1. 调度器和服务器可以跨 VLAN 通信,不需要配置在同一个网段
  2. 请求和应答报文都经过调度器,服务器不需要绑定虚拟 IP

VS/FULLNAT 这两个特点可以简化网络拓扑,降低运维成本和风险。

5. 比较

VS/NAT

· 优点

  • 对后端服务器的操作系统无要求
  • 只需要一个 IP 地址配置在调度器上,服务器组可以用私有的 IP 地址。
  • 支持端口映射

· 缺点

  • 请求和响应报文都需要通过调度器,伸缩能力有限(10+)
  • 要求服务器和调度器在同一个 VLAN
  • 需要将服务器的默认网关指向调度器
  • 对于那些将 IP 地址或者端口号在报文数据中传送的网络服务,需要编写相应的应用模块来转换报文数据中的 IP 地址或者端口号

VS/TUN

· 优点

  • 不需要调度应答报文,性能高
  • 服务器和调度器可以不在同一个 VLAN
  • 支持广域负载均衡

· 缺点

  • 所有的服务器必须支持“IP Tunneling”协议,要安装内核模块(比如 IPIP 等),配置复杂
  • 有建立 IP 隧道的开销
  • 服务器上直接绑定虚拟 IP(Virtaul IP),风险很大
  • 服务器需要联通外网
  • 不支持端口映射

VS/DR

· 优点

  • 与 VS/TUN 相比,没有 IP 隧道的开销,性能最好

· 缺点

  • 要求调度器与服务器都有一块网卡连在同一物理网段(同一个 VLAN)上
  • 要求服务器网络设备(或者设备别名)不作 ARP 响应,或者能将报文重定向(Redirect)到本地的 Socket 端口上
  • 服务器上直接绑定虚拟 IP(Virtaul IP),风险很大
  • 不支持端口映射

6. 选择方法

  1. 如果人少钱多,不在乎性能的损耗愿意多买服务器,同时希望最大程度较少运维的工作量,可以选择 FULLNAT

  2. 很大众的方式是用 DR,没有太多的优点但也没有太多的缺点

  3. 如果要搞广域网负载均衡,那就用 TUN 吧

  4. 个人感觉 NAT 不是为了互联网用的。小并发的实验性应用或者用在非 web 场合,比如 mysql 集群等。当然,如果需要端口映射,必须使用 NAT

3. Ngnix(web 服务器、反向代理服务器、负载均衡器)

俄罗斯人开发的一个高性能的 HTTP 和反向代理服务器。由于 Nginx 超越 Apache 的高性能和稳定性,使得国内使用 Nginx 作为 Web 服务器的网站也越来越多,其中包括新浪博客、新浪播客、网易新闻、腾讯网、搜狐博客等门户网站频道等,在 3w 以上的高并发环境下,ngnix 处理能力相当于 apache 的 10 倍。
参考:apache 和 tomcat 的性能分析和对比(http://blog.s135.com/nginx_php_v6/)

4. Tengine(taobao 开发的 Nginx 升级版)

Tengine 是由淘宝网发起的 Web 服务器项目。它在Nginx的基础上,针对大访问量网站的需求,添加了很多高级功能和特性。Tengine 的性能和稳定性已经在大型的网站如淘宝网天猫商城等得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的 Web 平台。

从 2011 年 12 月开始,Tengine 成为一个开源项目,Tengine 团队在积极地开发和维护着它。

5. HAProxy(高可用、负载均衡)

HAProxy 提供高可用性负载均衡以及基于 TCP 和 HTTP 应用的代理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。HAProxy 特别适用于那些负载特大的 web 站点, 这些站点通常又需要会话保持或七层处理。HAProxy 运行在当前的硬件上,完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中,同时可以保护你的 web 服务器不被暴露到网络上.

6. Keepalived(故障转移,备机,linux 环境下的组件)

这里说的 keepalived 不是 apache 或者 tomcat 等某个组件上的属性字段,它也是一个组件,可以实现 web 服务器的高可用(HA highavailably)。它可以检测 web 服务器的工作状态,如果该服务器出现故障被检测到,将其剔除服务器群中,直至正常工作后,keepalive 会自动检测到并加入到服务器群里面。实现主备服务器发生故障时 ip 瞬时无缝交接。它是 LVS 集群节点健康检测的一个用户空间守护进程,也是 LVS 的引导故障转移模块(director failover)。Keepalived 守护进程可以检查 LVS 池的状态。如果 LVS 服务器池当中的某一个服务器宕机了。keepalived 会通过一 个 setsockopt 呼叫通知内核将这个节点从 LVS 拓扑图中移除。

7. Memcached(分布式内存对象缓存系统,实现内存级别的 session 共享)

 —— 它是一个高性能分布式内存对象缓存系统。当初是Danga Interactive为了LiveJournal快速发展开发的系统,用于对业务查询数据缓存,减轻数据库的负载。其守护进程(daemon)是用C写的,但是客户端支持几乎所有语言(客户端基本上有3种版本[memcacheclient for java;spymemcached;xMecache]),服务端和客户端通过简单的协议通信;在memcached里面缓存的数据必须序列化。

8. Terracotta(java 集群平台)

是一款由美国 Terracotta 公司开发的著名开源 Java 集群平台。它在 JVM 与 Java 应用之间实现了一个专门处理集群功能的抽象层,允许用户在不改变系统代码的情况下实现 java 应用的集群。支持数据的持久化、session 的复制以及高可用(HA)。详细参考:http://topmanopensource.iteye.com/blog/1911679

3. 负载均衡需要解决的问题

1. 负载均衡器(用 web 服务器实现)

1) Apache

2) Nginx/Tenginx

2. Session 共享(粘连不是一个完备的方法)

1) Tomcat 自带的 session 复制技术(tomcat 数量大于 4 时,组播会导致网络堵塞,不建议使用)

2) Memcached 实现内存级别的 session 共享

通过 memcached-session-manager(msm)插件,通过 tomcat 上一定的配置,即可实现把 session 存储到 memcached 服务器上。注意:tomcat 支持 tomcat6+,并且 memcached 可以支持分布式内存,msm 同时支持黏性 session(stickysessions)或者非黏性 session(non-stickysessions)两种模式,在 memcached 内存中共享的对象需要序列化。

3) Terracotta 实现 JVM 级别的 session 共享

它基本原理是对于集群间共享的数据,当在一个节点发生变化的时候,Terracotta 只把变化的部分发送给 Terracotta 服务器,然后由服务器把它转发给真正需要这个数据的节点,并且共享的数据对象不需要序列化。

3. 故障转移

使用 Keepalive 实现

4. 几种方式

1. DNS 轮询

DNS 轮询是最简单的负载均衡方式。以域名作为访问入口,通过配置多条 DNS 记录使得请求可以分配到不同的服务器。

DNS 轮询没有快速的健康检查机制,而且只支持 WRR 的调度策略导致负载很难“均衡”,通常用于要求不高的场景。并且 DNS 轮询方式直接将服务器的真实地址暴露给用户,不利于服务器安全。

2. CDN

CDN(ContentDelivery Network,内容分发网络)。通过发布机制将内容同步到大量的缓存节点,并在 DNS 服务器上进行扩展,找到里用户最近的缓存节点作为服务提供节点。

因为很难自建大量的缓存节点,所以通常使用 CDN 运营商的服务。目前国内的服务商很少,而且按流量计费,价格也比较昂贵。

3. IP 负载均衡

IP 负载均衡是基于特定的 TCP/IP 技术实现的负载均衡。比如 NAT、DR、Turning 等。是最经常使用的方式。

IP 负载均衡可以使用硬件设备,也可以使用软件实现。硬件设备的主要产品是 F5-BIG-IP-GTM(简称 F5),软件产品主要有 LVS、HAProxy、NginX。其中 LVS、HAProxy 可以工作在 4-7 层,NginX 工作在 7 层。关于三者的简单对比,可以参考这里

硬件负载均衡设备可以将核心部分做成芯片,性能和稳定性更好,而且商用产品的可管理性、文档和服务都比较好。唯一的问题就是价格。

软件负载均衡通常是开源软件。自由度较高,但学习成本和管理成本会比较大。

1. Apache+tomcat(过时的方法)

1. 结构

1、 他们之间的通信有三种方式:ajpproxy、modjk 链接器、http_proxy。具体参考:http://www.ibm.com/developerworks/cn/opensource/os-lo-apache-tomcat/

2、 apache 的分发策略有 4 种。权重(默认)、流量(bytraffic)、请求次数(byRequests)、繁忙程度(byBusyness 根据活跃请求数的多少)

2. apache 与 tomcat 的通信方式

l jk(在 apache 中配置)

这是最常见的方式,你可以在网上找到很多关于配置 JK 的网页,当然最全的还是其官方所提供的文档。JK 本身有两个版本分别是 1 和 2,目前 1 最新的版本是 1.2.19,而版本 2 早已经废弃了,以后不再有新版本的推出了,所以建议你采用版本 1。JK 是通过 AJP 协议与 Tomcat 服务器进行通讯的,Tomcat 默认的 AJP Connector 的端口是 8009。

l http_proxy

这是利用 Apache 自带的 mod_proxy 模块使用代理技术来连接 Tomcat。在配置之前请确保是否使用的是 2.2.x 版本的 Apache 服务器。因为 2.2.x 版本对这个模块进行了重写,大大的增强了其功能和稳定性。

http_proxy 模式是基于 HTTP 协议的代理,因此它要求 Tomcat 必须提供 HTTP 服务,也就是说必须启用 Tomcat 的 HTTP Connector。

l ajp_proxy

ajpproxy 连接方式其实跟 httpproxy 方式一样,都是由 mod_proxy 所提供的功能。配置也是一样,只需要把 http://换成 ajp://,同时连接的是 Tomcat 的 AJP Connector 所在的端口。

比较:

相对于 JK 的连接方式,后两种在配置上是比较简单的,灵活性方面也一点都不逊色。但就稳定性而言就不像 JK 这样久经考验,毕竟 Apache 2.2.3 推出的时间并不长,采用这种连接方式的网站还不多,因此,如果是应用于关键的互联网网站,还是建议采用 JK 的连接方式

3. apache 分发策略

权重

轮询

4. session 问题

1、 粘性 session(在 apache 中配置):apache 支持 stickysession(粘性 session),即为:访问用户访问了 A-tomcat,那么他的所有请求都会转发到 A-tomcat,而不会到 B-tomcat。[这样的负载均衡效果不好,适用于小型网站,

2、 Session 复制(在 tomcat 中配置):在访问系统的会话过程中,用户登录系统后,不管访问系统的任何资源地址都不需要重复登录,这里面 servlet 容易保存了该用户的会话(session)。如果两个 tomcat(A、B)提供集群服务时候,用户在 A-tomcat 上登录,接下来的请求 web 服务器根据策略分发到 B-tomcat,因为 B-tomcat 没有保存用户的会话(session)信息,不知道其登录,会跳转到登录界面。这时候我们需要让 B-tomcat 也保存有 A-tomcat 的会话,我们可以使用 tomcat 的 session 复制实现或者通过其他手段让 session 共享。

5. 缺陷

1、 只有一个 web 服务器,明显的单点故障。如果该 apache 出现问题,整个网站就会瘫痪。

2、 当 tomcat 节点数达到 4 个以上时候,集群性能呈线性下滑;另外当用户访问量大到一定程度,会话内容随之增多,tomcat 节点相互之间通信产生大量的网络消耗,产生网络阻塞,整个集群的吞吐量不能再上升。

2. nginx+Keepalived+tomcat(解决单点故障和性能问题,session 存在缺陷)

1. 结构
  1. Nginx 作为 web 服务器和负载均衡器,独立部署,并配置代理目标的地址。用户访问时是访问的 nginx 的地址,而不是 tomcat 的地址。为提高效率,可以在 nginx 中配置将 tomcat 中的静态文件(js,css,html 等)缓存到 nginx 中以提高访问效率

  2. Keepalive 作为故障转移组件

  3. Tomcat 作为应用服务器

2. nginx 配置
  1. Server{}段的参数说明:(一个 server 段代表了 nginx 代理的一个 url。可配置多个 server)

l listen:表示当前的代理服务器监听的端口,默认的是监听 80 端口。注意,如果我们配置了多个 server,这个 listen 要配置不一样,不然就不能确定转到哪里去了。

l server_name:nginx 服务器的地址或者域名, 可配置多个

l location:表示匹配的路径,配置了 / 表示所有请求都被匹配到这里

     root:里面配置了root这时表示当匹配这个请求的路径时,将会在这个文件夹内寻找相应的文件,这里对我们之后的静态文件伺服很有用。

     index:当没有指定主页时,默认会选择这个指定的文件,它可以有多个,并按顺序来加载,如果第一个不存在,则找第二个,依此类推。
3. SESSION 解决方法
  1. 使用 tomcat 自带的 cluster 方式,多个 tomcat 见自动实时复制 session 信息,配置起来很简单。但这个方案的效率比较低,在大并发下表现并不好。

  2. 利用 nginx 的基于访问 ip 的 hash 路由策略,保证访问的 ip 始终被路由到同一个 tomcat 上,这个配置更简单。但是我们的应用很可能是某一个局域网大量用户同时登录,这样负载均衡就没什么作用了。

4. 负载均衡策略(分发策略)

负载均衡策略是通过 upstream 属性来设置的。

upstream tomcat_loadbalanace{

ip_hash;#这个值是个示例

server192.168.0.112:8080; 

server192.168.0.123:8080;

}

server {

    listen       80;#nginx服务器监听对本服务器80端口的访问

   #server_name  192.168.0.112;

    location /command/{ #增加项目名, 避免路径不对引起文件无法访问

       # root   html;

       # index  index.html index.htm;

         proxy_pass[http://tomcat_loadbalanace/command/;](http://tomcat_loadbalanace/command/;) #地址写全,不然会发生重定向问题

    }

  }

实际的访问地址是 proxy_pass 中非 ip 部分与 upstream 中的 sever 部分的值的组合

upstream tomcat_loadbalanace{ 

ip_hash;

server192.168.0.112:8080; 

server192.168.0.123:8080;

}

1、轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器 down 掉,能自动剔除。
upstream backserver {
server 192.168.0.14;
server 192.168.0.15;
}

2、weight
指定轮询几率,weight 和访问比率成正比,用于后端服务器性能不均的情况。
upstream backserver {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}

3、iphash
每个请求按访问 ip 的 hash 结果分配,这样每个访客固定访问一个后端服务器,可以解决 session 的问题。
upstream backserver {
iphash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}

4、fair(第三方,慎用)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
upstream backserver {
server server1;
server server2;
fair;
}

5、urlhash(第三方)
按访问 url 的 hash 结果来分配请求,使每个 url 定向到同一个后端服务器,后端服务器为缓存时比较有效。
upstream backserver {
server squid1:3128;
server squid2:3128;
hash $requesturi;
hash_method crc32;
}

5. 缺陷
  1. Session 共享仅能用 tomcat 自带的 session 复制功能,性能低下

  2. 如果用 nginx 自带的 ip_hash 分发策略,则同一个请求都被转到固定的应用服务器,一旦挂机则无法恢复。

3. nginx +Keepalive+ tomcat+ memcached(解决 session 复制问题)

haproxy+

haproxy+

5. 比较(nginx、haproxy、lvs,keepalived 和 session 共享是必须的)

目前流行的方式是

Web 前端:nginx/haproxy+keepalived

数据库:一主多从,读写分离,lvs+keepalived

|

方式

|

优点

|

缺陷

|

适用环境

|
|

Nginx(负载均衡和 web 服务器)

|

n 工作在网络的 7 层之上,可以针对 http 应用做一些分流的策略,比如针对域名、目录结构,它的正则规则比 HAProxy 更为强大和灵活,这也是它目前广泛流行的主要原因之一,Nginx 单凭这点可利用的场合就远多于 LVS 了。

n Nginx 对网络稳定性的依赖非常小,理论上能 ping 通就就能进行负载功能,这个也是它的优势之一;相反 LVS 对网络稳定性依赖比较大,这点本人深有体会;

n Nginx 安装和配置比较简单,测试起来比较方便,它基本能把错误用日志打印出来。LVS 的配置、测试就要花比较长的时间了,LVS 对网络依赖比较大。

n 可以承担高负载压力且稳定,在硬件不差的情况下一般能支撑几万次的并发量,负载度比 LVS 相对小些。

l Nginx 可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持 url 来检测。比如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,Nginx 会把上传切到另一台服务器重新处理,而 LVS 就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而不满。

l Nginx 不仅仅是一款优秀的负载均衡器 / 反向代理软件,它同时也是功能强大的 Web 应用服务器。LNMP 也是近几年非常流行的 web 架构,在高流量的环境中稳定性也很好。

l Nginx 现在作为 Web 反向加速缓存越来越成熟了,速度比传统的 Squid 服务器更快,可以考虑用其作为反向代理加速器。

l Nginx 可作为中层反向代理使用,这一层面 Nginx 基本上无对手,唯一可以对比 Nginx 的就只有 lighttpd 了,不过 lighttpd 目前还没有做到 Nginx 完全的功能,配置也不那么清晰易读,社区资料也远远没 Nginx 活跃。

l Nginx 也可作为静态网页和图片服务器,这方面的性能也无对手。还有 Nginx 社区非常活跃,第三方模块也很多。

|

n Nginx 仅能支持 http、https 和 Email 协议,这样就在适用范围上面小些,这个是它的缺点。

n 对后端服务器的健康检查,只支持通过端口来检测,不支持通过 url 来检测。

n 不支持 Session 的直接保持,但能通过 ip_hash 来解决(使得同一 ip 访问同一应用服务器,有缺陷的方法)。(通过第三方来解决,如 memcached)

n 负载度和稳定度差 LVS 还有几个等级:Nginx 处理所有流量所以受限于机器 IO 和配置;本身的 bug 也还是难以避免的。

|

中小型网站,如日 PV 小于 1000 万

|
|

Lvs(负载均衡软件)

|

l 抗负载能力强、是工作在网络 4 层之上仅作分发之用,没有流量的产生,这个特点也决定了它在负载均衡软件里的性能最强的,对内存和 cpu 资源消耗比较低。

l 配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率。

l 工作稳定,因为其本身抗负载能力很强,自身有完整的双机热备方案,如 LVS+Keepalived,不过我们在项目实施中用得最多的还是 LVS/DR+Keepalived。

l 无流量,LVS 只分发请求,而流量并不从它本身出去,这点保证了均衡器 IO 的性能不会受到大流量的影响。

l 应用范围比较广,因为 LVS 工作在 4 层,所以它几乎可以对所有应用做负载均衡,包括 http、数据库、在线聊天室等等。

|

l 软件本身不支持正则表达式处理,不能做动静分离;而现在许多网站在这方面都有较强的需求,这个是 Nginx/HAProxy+Keepalived 的优势所在。

l 如果是网站应用比较庞大的话,LVS/DR+Keepalived 实施起来就比较复杂了,特别后面有 Windows Server 的机器的话,如果实施及配置还有维护过程就比较复杂了,相对而言,Nginx/HAProxy+Keepalived 就简单多了。

| |
|

Haproxy(负载均衡软件)

|

l HAProxy 也是支持虚拟主机的。

l HAProxy 的优点能够补充 Nginx 的一些缺点,比如支持 Session 的保持,Cookie 的引导;

l 同时支持通过获取指定的 url 来检测后端服务器的状态。

l HAProxy 跟 LVS 类似,本身就只是一款负载均衡软件;单纯从效率上来讲 HAProxy 会比 Nginx 有更出色的负载均衡速度,在并发处理上也是优于 Nginx 的。

l HAProxy支持 TCP 协议的负载均衡转发,可以对 MySQL 读进行负载均衡,对后端的 MySQL 节点进行检测和负载均衡,大家可以用 LVS+Keepalived 对 MySQL 主从做负载均衡。

l HAProxy 负载均衡策略非常多,HAProxy 的负载均衡算法现在具体有如下 8 种:

① roundrobin,表示简单的轮询,这个不多说,这个是负载均衡基本都具备的;
② static-rr,表示根据权重,建议关注;
③ leastconn,表示最少连接者先处理,建议关注;
④ source,表示根据请求源 IP,这个跟 Nginx 的 IPhash 机制类似,我们用其作为解决 session 问题的一种方法,建议关注;
⑤ ri,表示根据请求的 URI;
⑥ rlparam,表示根据请求的 URl 参数’balance url_param’ requires an URL parameter name;
⑦ hdr(name),表示根据 HTTP 请求头来锁定每一次 HTTP 请求;
⑧ rdp-cookie(name),表示根据据 cookie(name)来锁定并哈希每一次 TCP 请求。

| | |
| | | | |
| | | | |

6. 选型方法

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

  2. 第二阶段:随着网络服务进一步扩大,这时单点的 Nginx 已经不能满足,这时使用 LVS 或者商用 Array 就是首要选择,Nginx 此时就作为 LVS 或者 Array 的节点来使用,具体 LVS 或 Array 的是选择是根据公司规模和预算来选择,Array 的应用交付功能非常强大,本人在某项目中使用过,性价比也远高于 F5,商用首选,但是一般来说这阶段相关人才跟不上业务的提升,所以购买商业负载均衡已经成为了必经之路。

  3. 第三阶段:这时网络服务已经成为主流产品,此时随着公司知名度也进一步扩展,相关人才的能力以及数量也随之提升,这时无论从开发适合自身产品的定制,以及降低成本来讲开源的 LVS,已经成为首选,这时 LVS 会成为主流。

  4. 最终形成比较理想的基本架构为:Array/LVS — Nginx/Haproxy —Squid/Varnish — AppServer。