现有的负载均衡技术的分类与各自特点

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

大型网站负载均衡的利器

• 全局负载均衡系统（GSLB）
• 内容缓存系统（CDN）
• 服务器负载均衡系统（SLB）

DNS域名解析的基本过程

最初的负载均衡解决方案（DNS轮询）

优点

• 基本上无成本，因为往往域名注册商的这种解析都是免费的；
• 部署方便，除了网络拓扑的简单扩增，新增的Web服务器只要增加一个公网IP即可

缺点

• 健康检查，如果某台服务器宕机，DNS服务器是无法知晓的，仍旧会将访问分配到此服务器。修改DNS记录全部生效起码要3-4小时，甚至更久；
• 分配不均，如果几台Web服务器之间的配置不同，能够承受的压力也就不同，但是DNS解析分配的访问却是均匀分配的。用户群的分配不均衡导致DNS解析的不均衡。
• 会话保持，如果是需要身份验证的网站，在不修改软件构架的情况下，这点是比较致命的，因为DNS解析无法将验证用户的访问持久分配到同一服务器。虽然有一定的本地DNS缓存，但是很难保证在用户访问期间，本地DNS不过期，而重新查询服务器并指向新的服务器，那么原服务器保存的用户信息是无法被带到新服务器的，而且可能要求被重新认证身份，来回切换时间长了各台服务器都保存有用户不同的信息，对服务器资源也是一种浪费。

全局负载均衡系统（GSLB）

优势

• 数据中心冗余备份
• 多站点流量优化
• 确保用户体验

全局负载均衡系统（GSLB）的原理

DNS检查工具网上有很多，感兴趣的可以搜索一下。

内容缓存系统（CDN）

• 内容缓存系统（CDN）之静态加速
• 内容缓存系统（CDN）之动态加速

动态加速的特点

• 智能路由
• 传输控制协议（TCP）优化
• HTTP预载

服务器负载均衡系统

应用背景

• 访问流量快速增长
• 业务量不断提高

用户需求

• 希望获得7×24的不间断可用性及较快的系统反应时间

负载均衡必须满足性能、扩展、可靠性

服务器负载均衡系统三种接入方式

部署方式

特点

优点

缺点

串联路由模式

比较常见的部署方式

• 负载均衡设备将服务器有效隔离，安全考虑上最好
• 服务器网关指向负载均衡设备,   功能实现更简单，有利于最大化负载均衡性能
• 服务器可以直接接收到真实访问源客户IP地址

• 对现有拓扑结构变动较大
• 需要考虑内网服务器是否有对外访问需求，必要时需要设置静态NAT转换

单臂模式

最常见的部署方式

• 部署方便，对现有拓扑结构变动小
• 和应用无关的流量不会通过负载均衡设备
• 内部应用无影响，外部应用通常需要前端防火墙做NAT映射到应用VIP

• 服务器不能直接接收访问客户源地址，需要对应用做修改后才可以通过其他方式获得真实访问地址

DSR

服务器回程报文不通过负载均衡设备，直接返回给客户端； 

延迟短，适合流媒体等对延时要求较高应用

• 性能高，可处理吞吐量高
• 服务器可以直接接收到真实访问源客户IP地址

• 只能做4层的负载均衡，基于7层的服务无法实现优化(例如压缩等)无法使用
• 需要在服务器上配置loopback地址

服务器负载均衡系统的常见调度算法

• 轮询（Round Robin）
• 加权轮询（Weighted Round Robin）
• 最少连接（Least Connections）
• 加权最少连接（Weighted Least Connections）

健康性检查

健康性检查算法的目的：通过某种探针机制，检查服务器群中真实服务器的健康情况，避免把客户端的请求分发给出现故障的服务器，以提高业务的HA能力。

目前常用的健康性检查算法：

• Ping（ICMP）
• TCP
• HTTP
• FTP

系统加速

优化功能-SSL加速

优化功能-HTTP压缩

HTTP压缩是在Web服务器和浏览器间传输压缩文本内容的方法。F5 HTTP压缩技术通过具有智能压缩能力的 BIG-IP 系统可缩短应用交付时间并优化带宽。HTTP压缩采用通用的压缩算法压缩HTML、JavaScript或CSS文件。压缩的最大好处就是降低了网络传输的数据量，从而提高客户端浏览器的访问速度。

优化功能-连接复用

优化功能-TCP缓存

会话保持

会话保持-客户端源IP会话保持

源IP地址会话保持就是将同一个源IP地址的连接或者请求认为是同一个用户，根据会话保持策略，在会话保持有效期内，将这些发自同一个源IP地址的连接/请求都转发到同一台服务器。

会话保持-Cookie会话保持

当采用基于源地址的会话保持无法做到负载均分时，例如客户端发起连接请求的源IP地址相对固定，发生此类问题通常可采用基于应用层的会话保持方式，Cookie通常是存在于HTTP头中，现如今基于HTTP的应用被广泛使用，因此基于Cookie的会话保持越来越多的出现在服务器负载均衡解决方案中。

局限性：

对于非HTTP协议，或者客户端禁用Cookie，无效。

会话保持-URL哈希（Hash）会话保持

哈希会话保持的一个基本概念就是按照某个Hash因子，根据此因子以及后台存在多少台服务器计算得到的结果来选择将请求分配到那台服务器。哈希会话保持的特点是在后台服务器的健康状态不发生改变的时候，每个特定的Hash因子被分配到的服务器是固定的。其最大的优势是哈希会话保持可以没有会话保持表，而仅仅是根据计算的结果来确定被分配到那台服务器，尤其在一些会话保持表查询的开销已经远远大于Hash计算开销的情况下，采用Hash会话保持可以提高系统的处理能力和响应速度。

URL哈希会话保持通常针对后台采用Cache服务器的应用场景，针对URL进行Hash计算，将同一个URL的请求分配到同一台Cache服务器，这样，对后台的Cache服务器群来说，每台Cache服务器上存放的内容都是不一样的，提高Cache服务器的利用率。

故障案例分析

Q&A案例分析（1）-循环跳转

故障现象：

Web服务端对用户访问的URL进行判断，对于非https的请求，重定向到http站点，结果导致用户一直302跳转。

原因分析：

采用了负载均衡SSL加速功能，在服务端看到所有的用户请求都来自于http。

解决方案：

全站启用SSL加速。

Q&A案例分析（2）-用户Session丢失

故障现象：

用户在http站点上提交数据到同域名的https站点，web程序抛出session丢失的异常，用户提交数据失败。

原因分析：

http和https在负载均衡设备上被认为是2个独立的服务，产生2个独立的TCP链接，会命中不同的真实服务器，导致session丢失。

解决方案：

在负载均衡设备上启用基于真实服务器的会话保持。

Q&A案例分析（3）-客户端源IP取不到

故障现象：

服务端获取不到用户外网的IP地址，看到的都是大量来自于内网特定网段的IP地址。

原因分析：

负载均衡设备启用了用户源地址转换（SNAT）模式，修改了TCP报文中的用户源IP。

解决方案：

负载均衡设备会用用户的外网IP改写x-forwarded-for值，服务端通过获取http协议中request header头的x-forwarded-for值作为用户源IP。IIS日志通过安装插件形式显示用户源IP。

服务器负载均衡设备选型

1.价格因素

硬件设备：F5、 Citrix 、Redware 、A10

软件：LVS、Nginx、Haproxy、zen loadbalance

2.性能

4/7层吞吐量(单位bps)

4/7层新建连接数（单位CPS）

并发连接数

功能模块性能指标（ssl加速、 HTTP压缩、内存Cache）

3.满足真实和未来需求

1）如果确认负载均衡设备对所有应用的处理都是最简单的4层处理，那么理论上选择的负载均衡设备的4层性能稍高于实际性能需求即可。

2）如果确认负载均衡设备对所有应用的处理都是简单的7层处理，那么理论上选择的负载均衡设备的7层性能稍高于实际性能需求即可。

3）如果负载均衡设备处理的应用既有4层的也有7层的，建议按照7层应用的性能来考虑负载均衡设备。

4）如果确认自己的应用经过负载均衡处理时，需要复杂的4层或者7层处理，例如需要根据客户端的地址做策略性分发，需要根据tcp的内容做处理，需要根据HTTP头或者HTTP报文做处理，那么建议选择的负载均衡设备4/7层性能为真实性能需求的两倍。

5）如果负载均衡设备有混合的复杂流量处理并且还开启了一些功能模块，那么建议选择的负载均衡设备4/7层性能为真实性能需求的3倍。

6）考虑到设备需要轻载运行才能更加稳定，所以有可能的话在以上基础上再增加30%的性能。

7）如果还要满足未来几年的发展需求，在以上基础上还要留出未来发展所需要增加的性能。

8）不同负载均衡设备厂家由于不同的架构，使得某些设备在复杂环境下可能也表现的比较优秀，这个客户可以对比判断，但总体来说，以上建议适合于所有厂家的设备。

负载均衡作为提高网站性能的主要方式被大多数网站采用，文中概述了现有的负载均衡技术的分类与各自特点。

 

　　动态内容按照存在形态可以分为三类。

　　第一类：内容长时间不需变化，这类内容一般是通过网页静化技术，实现动态内容转换成静态内容，从而达到cdn部署，典型的就是内容类网站，比如新浪、搜狐、网易等等的内容发布系统cms，内容的增删改等管理工作被准实时同步到各个节点。
　　第二类：内容可能会短时间内发生变动，但是最终会稳定。比如论坛、博客等应用，这类服务提供的内容按照一定的时间间隔，实现批量静化，当然也有实时静化，像Mop的大杂烩、网易社区就是使用了这样的策略。
　　第三类：内容会实时变化，非常个性化。比如邮箱应用，这类服务提供的内容无法实现静化，只能通过实行分区域部署和负载均衡等手段进行优化。
　　对于提供cdn服务的厂商来讲，静态内容的cdn自然没有问题，对于第三类服务，只能从通信链路层进行相应的优化。
　　对于很多网站的伪静化，有的出于Seo的考虑，有的出于安全性的考虑，手段基本上是rewrite Url。它只不过是一种外在的表现形式，与Html静化是两回事，它依然是一种动态内容。
　　1. 负载均衡的分类
　　负载均衡技术在网站运营过程中应用非常普遍，技术也很成熟。负载均衡技术按照软硬件形式分为软均衡和硬均衡。软均衡就是基于软件技术的均衡，硬均衡是基于硬件技术的均衡；
　　按照网络协议划分又分为四层均衡和七层均衡。四层均衡就是基于OSI网络层的数据均衡，七层均衡是基于OSI应用层的数据均衡。
　　各种均衡方式在大型网站中均有采用，而且大多数情况下，是多种均衡方式的组合。
　　2. DNS轮询均衡
　　这种方式，算是比较独立的一种方式，不在上述划分之列，但使用比较广泛，一般用在网站最前端。你可以做个试验，在dos命令行中运行nslook命令。比如：nslookup www。163。com，你会看到命令给出了一堆解析后的IP地址。这些地址就是www.163.com这个域名绑定的多条A记录。我们从浏览器发起的访问请求http://www.163.com/，那么你输入的域名首先需要经过DNS服务器进行解析，Dns服务器的解析的过程就是按照A记录的顺序，依次分配IP地址。Dns轮询方式实现均衡就是利用这个原理，在一个域名下面绑定N个IP地址，访问请求被均衡到不同的设备。Dns轮询方式提供的IP地址，在大型网站中往往是一个集群的地址，可能是均衡交换机也可能是均衡服务器。对于小网站的话，挂接多台服务器也没有问题。

　　DNS轮询均衡的优点：
　　　　1、零成本：只是在Dns服务器上绑定几个A记录，域名注册商一般都提供；
　　　　2、部署简单：就是在网络拓扑进行设备扩增，然后在Dns服务器上添加记录。
　　DNS轮询均衡的缺点：
　　　　1、流量分配不均：Dns解析过程其实环节很多，而且是一种层层缓存的机制，你的dns服务器虽然进行更新，但是客户机、以及网络上其它的dns服务器不会实时更新，所以流量很难保证100%的平均。目前，dns服务器都提供了多种手段可以调整dns轮询分配的策略，但是确实无法保证很完美的均衡。
　　　　2、健康检查：Dns服务器中A记录地址中的某一台服务器宕机，DNS服务器是无法知道的，仍旧会将访问分配到此服务器。所以需要人员或者工具进行实时检测，在某台机器宕机之后，把备份机推上生产线，如果想要从A记录地址摘除某个地址，这个通知过程需要几个小时甚至更久才能扩散到所有的客户机。 　　Dns轮询方式推到服务的最前端还是很有效的，它通过最原始的方式，把访问用户映射到不同的服务集群上。对于大型网站来讲，对外服务的IP地址是不可能经常变动的，而且后端的集群一旦宕掉，可以迅速推上冗余集群。再加上，一般都是经过CDN部署，服务被拆分到各个局部，所以在运营过程中不会产生太大的影响。
　　3. OSI七层模型
　　我们接下来讲讲七层均衡。要理解四七层均衡的原理，就先要回忆一下大学课本里学的网络七层模型(OSI)。
　　OSI是一个开放性的通行系统互连参考模型，他是一个定义的非常好的协议规范。OSI模型有7层结构，每层都可以有几个子层。
　　OSI七层模型是一个很好的理论模型，但是在实际应用中都做了裁剪。尤其是TCP/IP的盛行，把7层结构压成了4层，
所以很多人都批评OSI七层模型过于复杂，但是作为一个完整的全面的网络模型，还是被大家非常认可的。OSI的7层从上到下分别是应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。
　　7层的功能描述：
　　（1）应用层：与其他计算机进行通讯的一个应用，它是对应应用程序的通信服务的。例如，一个没有通信功能的字处理程序就不能执行通信的代码，从事字处理工作的程序员也不关心OSI的第7层。但是，如果添加了一个传输文件的选项，那么字处理器的程序员就需要实现OSI的第7层。示例：telnet，HTTP,FTP,WWW,NFS,SMTP等。
　　（2）表示层：这一层的主要功能是定义数据格式及加密。例如，FTP允许你选择以二进制或ASII格式传输。如果选择二进制，那么发送方和接收方不改变文件的内容。如果选择ASII格式，发送方将把文本从发送方的字符集转换成标准的ASII后发送数据。在接收方将标准的ASII转换成接收方计算机的字符集。示例：加密，ASII等。
　　（3）会话层：他定义了如何开始、控制和结束一个会话，包括对多个双向小时的控制和管理，以便在只完成连续消息的一部分时可以通知应用，从而使表示层看到的数据是连续的，在某些情况下，如果表示层收到了所有的数据，则用数据代表表示层。示例：RPC，SQL等。
　　（4）传输层：这层的功能包括是否选择差错恢复协议还是无差错恢复协议，及在同一主机上对不同应用的数据流的输入进行复用，还包括对收到的顺序不对的数据包的重新排序功能。示例：TCP，UDP，SPX。
　　（5）网络层：这层对端到端的包传输进行定义，他定义了能够标识所有结点的逻辑地址，还定义了路由实现的方式和学习的方式。为了适应最大传输单元长度小于包长度的传输介质，网络层还定义了如何将一个包分解成更小的包的分段方法。示例：IP,IPX等。
　　（6）数据链路层：他定义了在单个链路上如何传输数据。这些协议与被讨论的歌种介质有关。示例：ATM，FDDI等。
　　（7）物理层：OSI的物理层规范是有关传输介质的特性标准，这些规范通常也参考了其他组织制定的标准。连接头、针、针的使用、电流、电流、编码及光调制等都属于各种物理层规范中的内容。物理层常用多个规范完成对所有细节的定义。示例：Rj45，802.3等。

[附录]可扩展、高可用、负载均衡网站架构设计方案

 

基本需求:

1、  高可用性：将停止服务时间降低到最低甚至是不间断服务

2、  可扩展性：随着访问的增加，系统具备良好的伸缩能力

3、  可视性：系统、服务的状态处于一个实时的监控之下

4、  高性能高可靠性：经过优化的体系结构及合理的备份策略

5、  安全性：结构上的安全及主机的安全策略

 

基本思路

1、对于访问频繁，用户量大的对象（bbs,blog）采用某种合理的方式负载到多个服务器上。把数据库独立出来，准备2套mysql数据库，以实现主从复制，即减轻负载，又提高了可靠性。更近一步，使用mysql proxy技术，实现主从服务器的读写分离，大大提高这个系统的性能和负载能力。

2、数据库与外部网络隔离，只允许web服务器（bbs,blog等）通过私有地址方式访问。这样就提高了数据库的安全性，同时也节省了宝贵的带宽。

3、部署监控系统，通过监控主机存活、服务、主机资源，实时把系统的健康状态置于可视状态，对系统的运营状态心中有数。

4、备份是想都不用想的事情，使用单独的服务器集中备份，是一个比较不错的主意。

 

拓扑结构

 

业务逻辑

 

技术实现

1、负载均衡。2台同样配置的linux服务器，内核支持lvs,配置keepalived工具，即可实现负载转发。一旦其后的真实服务器出现故障，keepalived会自动把故障机器从转发队列删除掉，等到故障修复，它又会自动把真实服务器的地址加入转发列表。由于lvs支持会话保持，因此对于bbs 这样的应用，一点也不用担心其登录丢失。

2、mysql主从复制。即保证数据的安全，又提高了访问性能。我们在前端的每个web服务器上加入mysql proxy这个工具，即可期待实现读写的自动分离，让写的操作发生在主数据库，让查询这类读操作发生在从数据库。

3、nagios是一个开源的，受广泛欢迎的监控平台。它可对主机的存活、系统资源（磁盘空间、负载等）、网络服务进行实时监控。一旦探测到故障，将自动发送邮件（短信）通知故障。

4、备份。包括web数据和数据库服务器的备份。对于web服务而言，GNU tar即可实现备份的一切愿望。简单的设置一下crontab 就可以让系统在我们做梦的时刻老老实实的帮我们备份了。但是，由于空间的限制，不可能一直备份下去，所以要做一个合适的策略，以不断的用新的备份去替换陈旧的备份数据；多少天合适？看磁盘容量吧。对于数据库，先mysqldump一下，再tar.完成这些工作后把备份文件传输到备份服务器集中。一个比较省事的方法是把备份服务器以NFS方式挂接到web服务器及数据库服务器。

5、web服务器。至少包括apache和mysql proxy这两个组件。Apache做bbs和blog的容器，以虚拟机方式把用户的请求转发到bbs目录或blog目录。

6、安全措施。包含两层安全，一层是主机本身，另一层是结构（mysql从外部网络隔离）。实践证明，iptables是一个非常值得信赖的防火墙工具。在实际应用中，采取先关门后开窗的策略，大大增强系统的安全性。

 

组件

一、 硬件: 负载均衡2台(dell 1950),web服务器2-3台(dell1950),数据库2台(dell 2950),存储NAS(5T格式化后容量),备份4u服务器(带磁盘阵列5T容量),监控服务器1台(dell1850).

二、 软件：操作系统centos 5(定制安装)，负载均衡ipvsadm、keepalived,监控nagios,web服务apache+php等，数据库mysql,数据库代理mysql proxy.

 

周期进度安排

1、  lvs负载均衡配置及测试：2-3天

2、  web服务器配置：2-3天

3、  mysql主从服务器配置：1-3天

4、  web数据迁移：1天

5、  数据库数据迁移：2天

6、  上线测试：1-2天

7、  正式上线：2天

 

心跳配置过程

keepalived.conf

! Configuration File for keepalived

global_defs {

router_id LVS_DEVEL

}

 

vrrp_instance VI_1 {

    state  master

    interface eth0

    virtual_router_id 59

    priority 100

    advert_int 1

    authentication {

        auth_type PASS

        auth_pass 1111

        }

  virtual_ipaddress {

  61.61.61.100

  #61.61.61.101

  }

}

 

virtual_server 61.61.61.100 80 {

    delay_loop 6

    lb_algo rr

    lb_kind DR

    persistence_timeout 50

    protocol TCP

real_server 61.61.61.102 80 {

        weight 100

        TCP_CHECK {

            connect_timeout 3

            nb_get_retry 3

            delay_before_retry 3

            connect_port 80

        }

    }

    real_server 61.61.61.103 80 {

        weight 100

        TCP_CHECK {

            connect_timeout 3

            nb_get_retry 3

            delay_before_retry 3

            connect_port 80

        }

     }

    }

 

真实服务器虚拟ip设置脚本

#!/bin/bash
#description : start realserver
VIP=61.61.61.100
./etc/rc.d/init.d/functions
case "$1" in
start)
echo " start LVS of REALServer"
/sbin/ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up
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
;;
stop)
/sbin/ifconfig lo:0 down
echo "close LVS Directorserver"
echo "0" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "0" >/proc/sys/net/ipv4/conf/lo/arp_announce
echo "0" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "0" >/proc/sys/net/ipv4/conf/all/arp_announce
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
esac

 

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