分享阿里云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

1, 技术架构

2,LVS 技术特点

FULLNAT 技术概述

SYNPROXY 技术概述

集群部署方式

Keepalived 优化

3,Tengine 技术特点

4, 更多功能

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

SLB 服务会检查云服务器池中 ECS 的健康状态, 自动隔离异常状态的 ECS, 从而解决了单台 ECS 的单点问题, 同时提高了应用的整体服务能力. 在标准的负载均衡功能之外, SLB 服务还具备 TCP 与 HTTP 抗 DDoS 攻击的特性, 增强了应用服务器的防护能力.

SLB 服务是 ECS 面向多机方案的一个配套服务, 需要同 ECS 结合使用.

1, 技术架构

整个负载均衡系统由 3 部分构成: 四层负载均衡, 七层负载均衡和控制系统, 如下图所示:

四层负载均衡

采用开源软件 LVS(Linux Virtual Server) 构建, 并根据云计算需求对其进行了定制和优化.

七层负载均衡

采用开源软件 Tengine 构建.

控制系统

用于配置和监控负载均衡系统.

2,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 恢复正常后自动解除屏蔽.

3,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 调度.

4, 更多功能

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 信息.

1, 负载均衡分为 L4 switch(四层交换), 即在 OSI 第 4 层工作, 就是 TCP 层啦. 此种 Load Balance 不理解应用协议 (如 HTTP/FTP/MySQL 等等). 例子: LVS,F5.

2, 另一种叫做 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 参考模型的第二, 三, 四, 七层的负载均衡都有相应的负载均衡策略.

负载均衡策略的优劣及其实现的难易程度有两个关键因素: 一, 负载均衡算法, 二, 对网络系统状况的检测方式和能力.

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

轮循均衡 (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 个包的速率转发, 这显然是没有任何作用的. 性能的优劣与负载均衡设备的处理能力, 采用的均衡策略息息相关, 并且有两点需要注意: 一, 均衡方案对服务器群整体的性能, 这是响应客户端连接请求速度的关键; 二, 负载均衡设备自身的性能, 避免有大量连接请求时自身性能不足而成为服务瓶颈. 有时我们也可以考虑采用混合型负载均衡策略来提升服务器群的总体性能, 如 DNS 负载均衡与 NAT 负载均衡相结合. 另外, 针对有大量静态文档请求的站点, 也可以考虑采用高速缓存技术, 相对来说更节省费用, 更能提高响应性能; 对有大量 ssl/xml 内容传输的站点, 更应考虑采用 ssl/xml 加速技术.

可扩展性: IT 技术日新月异, 一年以前最新的产品, 现在或许已是网络中性能最低的产品; 业务量的急速上升, 一年前的网络, 现在需要新一轮的扩展. 合适的均衡解决方案应能满足这些需求, 能均衡不同操作系统和硬件平台之间的负载, 能均衡 HTTP, 邮件, 新闻, 代理, 数据库, 防火墙和 Cache 等不同服务器的负载, 并且能以对客户端完全透明的方式动态增加或删除某些资源.

灵活性: 均衡解决方案应能灵活地提供不同的应用需求, 满足应用需求的不断变化. 在不同的服务器群有不同的应用需求时, 应有多样的均衡策略提供更广泛的选择.

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

易管理性: 不管是通过软件还是硬件方式的均衡解决方案, 我们都希望它有灵活, 直观和安全的管理方式, 这样便于安装, 配置, 维护和监控, 提高工作效率, 避免差错. 在硬件负载均衡设备上, 目前主要有三种管理方式可供选择: 一, 命令行接口 (CLI:Command Line Interface), 可通过超级终端连接负载均衡设备串行接口来管理, 也能 telnet 远程登录管理, 在初始化配置时, 往往要用到前者; 二, 图形用户接口 (GUI:Graphical User Interfaces), 有基于普通 web 页的管理, 也有通过 Java Applet 进行安全管理, 一般都需要管理端安装有某个版本的浏览器; 三, 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 都可以用作多机负载的方案, 它们各有优缺, 在生产环境中需要好好分析实际情况并加以利用.

首先提醒, 做技术切不可人云亦云, 我云即你云; 同时也不可太趋向保守, 过于相信旧有方式而等别人来帮你做垫被测试. 把所有即时听说到的好东西加以钻研, 从而提高自己对技术的认知和水平, 乃是一个好习惯.

下面来分析一下两者:

一, lvs 的优势:

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

2, 配置性低, 这通常是一大劣势, 但同时也是一大优势, 因为没有太多可配置的选项, 所以除了增减服务器, 并不需要经常去触碰它, 大大减少了人为出错的几率.

3, 工作稳定, 因为其本身抗负载能力很强, 所以稳定性高也是顺理成章, 另外各种 lvs 都有完整的双机热备方案, 所以一点不用担心均衡器本身会出什么问题, 节点出现故障的话, lvs 会自动判别, 所以系统整体是非常稳定的.

4, 无流量, 上面已经有所提及了. lvs 仅仅分发请求, 而流量并不从它本身出去, 所以可以利用它这点来做一些线路分流之用. 没有流量同时也保住了均衡器的 IO 性能不会受到大流量的影响.

5, 基本上能支持所有应用, 因为 lvs 工作在 4 层, 所以它可以对几乎所有应用做负载均衡, 包括 http, 数据库, 聊天室等等.

另: lvs 也不是完全能判别节点故障的, 譬如在 wlc 分配方式下, 集群 里有一个节点没有配置 VIP, 会使整个集群不能使用, 这时使用 wrr 分配方式则会丢掉一台机. 目前这个问题还在进一步测试中. 所以, 用 lvs 也得多多当心为妙.

二, nginx 和 lvs 作对比的结果

1,nginx 工作在网络的 7 层, 所以它可以针对 http 应用本身来做分流策略, 比如针对域名, 目录结构等, 相比之下 lvs 并不具备这样的功能, 所以 nginx 单凭这点可利用的场合就远多于 lvs 了; 但 nginx 有用的这些功能使其可调整度要高于 lvs, 所以经常要去触碰触碰, 由 lvs 的第 2 条优点 看, 触碰多了, 人为出问题的几率也就会大.

2,nginx 对网络的依赖较小, 理论上只要 ping 得通, 网页访问正常, nginx 就能连得通, nginx 同时还能区分内外网, 如果是同时拥有内外网的 节点, 就相当于单机拥有了备份线路; lvs 就比较依赖于网络环境, 目前来看服务器在同一网段内并且 lvs 使用 direct 方式分流, 效果较能得到保证. 另 外注意, lvs 需要向托管商至少申请多一个 ip 来做 Vi su al IP, 貌似是不能用本身的 IP 来做 VIP 的. 要做好 LVS 管理员, 确实得跟进学习很多有关网络通信方面的知识, 就不再是一个 HTTP 那么简单了.

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

4,nginx 也同样能承受很高负载且稳定, 但负载度和稳定度差 lvs 还有几个等级: nginx 处理所有流量所以受限于机器 IO 和配置; 本身的 bug 也还是难以避免的; nginx 没有现成的双机热备方案, 所以跑在单机上还是风险较大, 单机上的事情全都很难说.

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

6,nginx 对请求的异步处理可以帮助节点服务器减轻负载, 假如使用 apache 直接对外服务, 那么出现很多的窄带链接时 apache 服务器将会占用大 量内存而不能释放, 使用多一个 nginx 做 apache 代理的话, 这些窄带链接会被 nginx 挡住, apache 上就不会堆积过多的请求, 这样就减少了相 当多的内存占用. 这点使用 squ id 也有相同的作用, 即使 squid 本身配置为不缓存, 对 apache 还是有很大帮助的. lvs 没有这些功能, 也就无法能 比较.

7,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 的就只有 lig httpd 了, 不过 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,F5,Radware 和 Array 等商用的负载均衡器, 也有类似于 LVS,Nginx,HAproxy 的基于 Linux 的开源的负载均衡策略,

商用负载均衡里面 NetScaler 从效果上比 F5 的效率上更高. 对于负载均衡器来说, 不过商用负载均衡由于可以建立在四~ 七层协议之上, 因此适用 面更广所以有其不可替代性, 他的优点就是有专业的维护团队来对这些服务进行维护, 缺点就是花销太大, 所以对于规模较小的网络服务来说暂时还没有需要使用.

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

LVS: 使用集群技术和 Linux 操作系统实现一个高性能, 高可用的服务器, 它具有很好的可伸缩性 (Scalability), 可靠性 (Reliability) 和可管理性 (Manageability).

LVS 的特点是:

1, 抗负载能力强, 是工作在网络 4 层之上仅作分发之用, 没有流量的产生;

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

3, 工作稳定, 自身有完整的双机热备方案;

4, 无流量, 保证了均衡器 IO 的性能不会收到大流量的影响;

5, 应用范围比较广, 可以对所有应用做负载均衡;

6,LVS 需要向 IDC 多申请一个 IP 来做 Visual IP, 因此需要一定的网络知识, 所以对操作人的要求比较高.

Nginx 的特点是:

1, 工作在网络的 7 层之上, 可以针对 http 应用做一些分流的策略, 比如针对域名, 目录结构;

2,Nginx 对网络的依赖比较小;

3,Nginx 安装和配置比较简单, 测试起来比较方便;

4, 也可以承担高的负载压力且稳定, 一般能支撑超过 1 万次的并发;

5,Nginx 可以通过端口检测到服务器内部的故障, 比如根据服务器处理网页返回的状态码, 超时等等, 并且会把返回错误的请求重新提交到另一个节点, 不过其中缺点就是不支持 url 来检测;

6,Nginx 对请求的异步处理可以帮助节点服务器减轻负载;

7,Nginx 能支持 http 和 Email, 这样就在适用范围上面小很多;

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

HAProxy 的特点是:

1,HAProxy 是工作在网络 7 层之上.

2, 能够补充 Nginx 的一些缺点比如 Session 的保持, Cookie 的引导等工作

3, 支持 url 检测后端的服务器出问题的检测会有很好的帮助.

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

5, 单纯从效率上来讲 HAProxy 更会比 Nginx 有更出色的负载均衡速度.

6,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: 三种负载均衡方式比较

1, 什么是 LVS?

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

为此, 在设计时需要考虑系统的透明性, 可伸缩性, 高可用性和易管理性. 一般来说, LVS 集

群采用三层结构, 其体系结构如图所示:

LVS 集群的体系结构

2,LVS 主要组成部分为:

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

服务器池 (server pool/ Realserver), 是一组真正执行客户请求的服务器, 执行的服务一般有 WEB,MAIL,FTP 和 DNS 等.

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

3,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 的工作流程

4, 三种负载均衡方式比较:

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 服务. 使 用更高的硬件配置 (如千兆网卡和更快的处理器) 作为调度器, 调度器所能调度的服务器数量会相应增加. 当应用不同时, 服务器的数目也会相应地改变. 所以, 以上数据估计主要是为三种方法的伸缩性进行量化比较.

5, 负载均衡调度算法

最少的连接方式 (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 中标识) 负载均衡对数据流进行分配.

规则模式: 针对不同的数据流设置导向规则, 用户可自行

来源: http://www.bubuko.com/infodetail-2021061.html