软负载均衡学习点滴.docx

软负载均衡学习点滴.docx

《软负载均衡学习点滴.docx》由会员分享，可在线阅读，更多相关《软负载均衡学习点滴.docx（22页珍藏版）》请在冰豆网上搜索。

软负载均衡学习点滴

“软”负载均衡学习点滴

（一）

Author:

岑文初

Email:

wenchu.cenwc@alibaba-

Blog:

Date:

2009-5-26

目录

需求转而学习...2

“软”负载均衡...2

LVS（LinuxVirtualServer）...3

VirtualServer三种模式介绍...3

VirtualServer三种模式的比较...5

VirtualServer三种模式实践...6

三种模式下的简单压力测试...9

HA-Proxy.10

HA-Proxy安装和使用...10

HA-Proxy的压力测试结果...15

“软”负载学习心得...15

需求转而学习

        很多时候不少做开发的同学都认为技术更新的快，新技术、新概念层出不穷，大家乐此不疲的去跟随着所谓的“技术趋势”走在风头浪尖上，但其实往往忘记了一个最重要的问题“满足客户需求”。

其实技术就是为满足需求服务的，用最小的代价来满足用户的需求，以最简单高效的方式来达到目标，就是每个开发者应该追求的。

（不要因为自己的架构很简单就脸红拿不出手，只要你在满足用户当前需求的基础上对未来有所考虑，那么化繁为简就是一种能力的表现）

        SIP（服务集成平台）5.7版本中对于未来多个服务提供商，多种类型的服务，在每日几亿的调用压力下，需要找到一个解决方案：

可以分流不同服务提供商的服务，分流不同类型的服务，服务隔离化来减少服务相互之间影响以及服务提供商之间的影响。

        当前SIP的前端是通过硬件F5作负载均衡，因此是无状态无差别的服务负载，这也使得无法区分不同的服务提供商的服务请求和不同类型的服务请求，导致服务提供商之间的服务会产生相互影响（旺旺即时通信类API在峰值占用了大部分的服务处理资源，淘宝宝贝上传类API占用了大量的带宽）。

近期还有更大的两类API将会接入，因此寻找一个服务可分流的方案势在必行。

（当然过去也考虑通过三级域名配置在负载均衡上来解决这些问题，但是这样首先对于开发者来说不透明，其次也是一种比较僵化的设计方案，扩展和维护也有一定的难度）

        在过去也尝试过Apache等Web容器自己的一些loadbalance特性，当然效果不是很好，和硬件基本无法比拟，而一些专有的“软”负载均衡方案和开源项目也没有深入的去了解，因此借着这次机会，好好深入的挖一挖“软”负载均衡。

“软”负载均衡

        作为互联网应用，随时都需要做好用户量突然增大，访问量突然上升的准备。

今年热门的词汇“云”我就不多说了，这里就简单说说服务器的横向扩展。

其实和DB，文件系统等一样，当资源成为瓶颈的时候，就需要考虑如何通过扩展或者提升资源能力来满足用户的需求，这就是我们常说的横向扩展和纵向扩展。

（对于横向扩展和纵向扩展的优劣大家应该都很清楚了，这里也不做赘述）横向扩展中就会要求使用负载均衡的能力，如何根据资源能力不同以及资源在运行期负荷动态变化将负载合理分配是判断负载均衡优劣的标准。

        软件负载均衡一般通过两种方式来实现：

基于操作系统的软负载实现和基于第三方应用的软负载实现。

LVS就是基于Linux操作系统实现的一种软负载，HAProxy就是基于第三应用实现的软负载。

（后面会详细介绍这两种方式的使用）

        最早期也是最原始的软负载均衡：

“RoundRobinDNS”，通过轮询方式在DNS绑定多个IP的情况下，将用户对于同一个域名的请求分配到后端不同的服务节点。

这种方案的优点：

配置简单，负载分配效率高。

缺点：

无法知晓后端服务节点服务情况（是否已经停止服务），无法保证在一个Session中多次请求由一个服务节点服务，每一个节点都要求有一个外网IP。

        另一种较为常见的就是基于分发器的Loadbalance。

服务使用者通过向分发器发起请求获得服务，分发器将请求分发给后端实际服务处理的节点，给客户提供服务，最常说的反向代理模式就是典型的分发器LoadBalance。

这类负载均衡处理可以基于应用级转发，也可以基于IP级别转发，当然基于应用转发效率和损耗比较大，同时分发器本身也会成为瓶颈。

LVS（LinuxVirtualServer）

        LVS是在Linux操作系统基础上建立虚拟服务器，实现服务节点之间的负载均衡。

LVS主要是处理OSI模型中的4层消息包，根据一定的规则将请求直接转发到后端的服务处理节点，有较高转发效率。

        VirtualServer是LoadBalancer和一组服务器的逻辑组合统称，使用服务者只需要与VirtualServer进行交互就可以获得高效的服务。

真实服务器和LoadBalancer通过高速ＬＡＮ进行交互。

LoadBalancer能够将请求分发到不同的服务端，在一个虚拟IP下并行处理多个请求。

VirtualServer三种模式介绍

VirtualServer有三种基于IP级别的负载均衡实现方式：

IPaddresstranslation（NAT）、Directrouting、IPTunneling。

        NAT（Networkaddresstranslation）：

由于IPV4的某些缺陷和安全原因，某些网段例如（10.0.0.0/255.0.0.0,172.16.0.0/255.240.0.0and192.168.0.0/255.255.0.0）不能被用于互联网，因此常常被用作内部局域网，通过网络地址翻译的方式可以让这些网段的服务器访问互联网或者被互联网访问。

网络地址翻译主要作用就是将一组ip地址映射到其他的一组ip地址，当映射比例为1:

1的时候通常称作静态映射，而当映射地址为M:

N（M>N）的时候（M为被映射地址数量，通常是内部ip），则成为动态映射。

而对于VirtualServer的NAT模式来说，就是利用了NAT的特性，将内部的一组服务器通过映射到一个虚拟的IP，然后以一个外网虚拟服务节点的身份对外提供服务。

        上图是一个实际的NAT范例，对外的服务IP为202.103.106.5，内部建立了虚拟IP为172.16.0.1，然后将内部其他两台实际服务的服务器172.16.0.2，172.16.0.3映射到172.16.0.1这个虚拟IP。

客户端向202.103.106.5发起请求服务，LoadBalancer查看请求数据包，如果是请求目标地址是注册的虚拟IP及监听端口的时候，那么通过NAT按照一定算法选择某一台实体服务器，再重写报文目标地址，转发请求到实际的目标服务器，当目标服务器处理完毕以后，将处理结果返回给LoadBalancer，由LoadBalancer修改源地址，返回给客户端。

        IPTunneling：

IP管道技术是在IP报文上再次封装IP报文协议的一种技术。

允许将一个目标为A的IP数据报文封装成为目标为B的IP数据报文，在特定的IP管道中传输。

        上图就是IPTunneling模式的运作原理。

首先客户端还是通过访问对外的一个服务IP请求服务，当LoadBalancer接受到请求以后，检查VIP注册信息，然后根据算法选择实际的一台后台服务器，通过IP管道封装技术对IP报文再次封装，然后将消息通过IP管道转发到实际的服务器，实际的服务器通过解包处理请求，然后根据包体内实际的服务请求地址，将处理结果直接返回给客户端。

        Directrouting：

利用LoadBalancer和实际服务器共享同一VIP，简单的通过修改消息报体目标MAC地址，转发请求，然后再通过实际服务器配置VIP为本地回环，直接处理消息报文，而不再转发，当处理完以后，直接将处理结果返回给客户端。

        上图就是DirectRouting的运作流程，当外部请求到LoadBalancer时，通过查找VIP注册信息，直接选择一台后端服务器作为新的目标地址，修改消息报文中的目标地址Mac地址，转发到目标服务器，目标服务器由于配置VIP在本地网卡回路中，因此直接处理消息，将处理完的结果直接返回给客户端。

VirtualServer三种模式的比较

        下表是官方整理出的关于VirtualServer三种不同模式的区别：

NAT

TUNNEL

DR

服务器要求

无要求

需要支持IP管道

无arp组件（当前也有补丁）

网络要求

Private

LAN/WAN

LAN

可支持后端服务器节点数

较少（10-20）

较多

较多

服务网关

LoadBalancer

本身

本身

NAT：

根据其实现原理，可以知道这种模式对于操作系统，网络都没有太多的要求和约束，但是由于消息需要打解包，同时消息的响应都必须经过LoadBalancer，因此LoadBalancer自身成为了瓶颈，这样一个LoadBalancer能够支持的后端服务节点数量就有限了。

当然可以采用混合模式来解决这个问题，也就是通过TUNNEL或者DR模式作为前端模式串联起多个NAT模式Balancer。

TUNNEL：

这种模式要求操作系统支持IPTunnel，通过对IP报文再次封装转发，达到负载均衡的目的。

设计这种模式的初衷是考虑，对于互联网很多服务来说，服务请求数据量和返回数据量是不对称的，返回的数据往往要远远大于请求的数据量，因此如果请求和返回都走LoadBalancer会大量占用带宽，影响处理能力。

IPTunnel设计中请求是通过LoadBalancer，但是返回是直接返回到客户端的，因此节省了返回的带宽，提高了请求处理的能力。

DR：

这种模式要求LoadBalancer和后端服务器处于同一个局域网段。

DR模式处理消耗最小，消息转发和回复基本没有损耗，因此效率应该是最高的，但是约束是相对来说最多的。

“软”负载均衡学习点滴

（二）

Author:

岑文初

Email:

wenchu.cenwc@alibaba-

Blog:

Date:

2009-5-26

目录

需求转而学习...2

“软”负载均衡...2

LVS（LinuxVirtualServer）...3

VirtualServer三种模式介绍...3

VirtualServer三种模式的比较...5

VirtualServer三种模式实践...6

三种模式下的简单压力测试...9

HA-Proxy.10

HA-Proxy安装和使用...10

HA-Proxy的压力测试结果...15

“软”负载学习心得...15

VirtualServer三种模式实践

服务器资源：

        10.2.225.128作为LoadBalancer，10.2.225.136和10.2.225.139作为后端的服务器。

        在10.2.225.136和10.2.225.139上分别安装Apache2.2.14，然后打开80端口，启动Web服务。

1． 安装LVS配置工具（只需要在LoadBalancer安装即可）

Linux操作系统当前大部分都已经支持VirtualServer，因此不需要再去编译内核，只需要下载和安装用户配置工具ipvsadmin。

首先请查看自己Linux操作系统内核的版本，我的版本是2.6.18。

从http:

//www.linux-vs.org/software/ipvs.html#kernel-2.6下载了ipvsadm-1.24.tar.gz。

安装步骤如下：

Tar–xzvfipvsadm-1.24.tar.gz

Ln–s/usr/src/kernels/2.6.18-128.el5-i686/usr/src/linux （这部必须作，因为在编译和安装的时候需要用到目录/usr/src/linux来获得必要的外部依赖库）

Cdipvsadm-1.24

Make&&makeinstall

输入ipvsadm，如果看到以下内容证明安装成功了：

IPVirtualServerversion1.2.1（size=4096）

ProtLocalAddress:

PortSchedulerFlags

 ->RemoteAddress:

Port          Forward Weight ActiveConn InActConn

2． DR模式测试

a.      为10.2.225.128这台LoadBalancer的网卡绑定虚拟IP。

ifconfigeth0:

0 10.2.225.211 netmask255.255.255.0 broadcast10.2.225.211 up

b.      在LoadBalancer上建立虚拟IP。

Ipvsadm–A–t10.2.225.211:

80–srr //221IP没有实体机器在使用，因此作为虚拟IP使用，A表示建立虚拟IP，t表示是tcp协议，s表示负载算法，rr是RoundRobin。

c.      在LoadBalancer上建立虚拟IP与两个实体服务器的关系。

ipvsadm-a-t10.2.225.211:

80-r10.2.225.136:

80-g-w1 //将虚拟IP和端口关联到实体机器上，a表示新建虚拟IP和实体机器的关联关系，r后面跟实体机器地址和端口，g表示使用DR模式，w是权重。

ipvsadm-a-t10.2.225.211:

80-r10.2.225.139:

80-g-w1

d.      在另外两台实体服务器上建立虚拟IP与网卡回环的绑定关系。

ifconfiglo:

0 10.2.225.211 netmask 255.255.255.255 broadcast 10.2.225.211 up

        下图就是配置好以后再输入ipvsadm查看到的虚拟配置信息

        其中Route表示就是DR的模式，然后图中ActiveConn表示连接数，这里是访问一个发布在两台后端服务器的页面带来的连接数，访问页面的情况如下两张图：

（主要是看返回页面中服务器ip打印的不同）

访问页面的结果和DR是一样的，对虚拟IP的访问，会轮询到不同的后端服务器上。

三种模式下的简单压力测试

简单的压力测试采用Apacheab，500并发用户，10w的请求总数。

总耗时（s）

TPS（#/sec）

NAT

22.480

4448.34

TUNNEL

10.707

9339.80

DR

10.177

9825.68

可以看出NAT性能要比后两种差一倍。

LVS是从四层对消息进行负载转发的，很大程度上是直接利用操作系统的特性来实现消息转发，因此转发损耗有限，但是NAT模式中LoadBalancer对于性能的影响很大，同时对于负载压力本身以及后台节点数目有限制。

在LVS基础上有很多其他的开源软件，增加了心跳等机制来保证集群的健壮性。

而LVS并不能满足根据应用参数或包体内容转发请求的场景，因此进一步研究HA-Proxy，这种基于基于应用级别在7层对消息作分析转发的负载均衡方案。

软”负载均衡学习点滴（三）收藏

Author:

岑文初

Email:

wenchu.cenwc@alibaba-

Blog:

Date:

2009-5-26

目录

需求转而学习...2

“软”负载均衡...2

LVS（LinuxVirtualServer）...3

VirtualServer三种模式介绍...3

VirtualServer三种模式的比较...5

VirtualServer三种模式实践...6

三种模式下的简单压力测试...9

HA-Proxy.10

HA-Proxy安装和使用...10

HA-Proxy的压力测试结果...15

“软”负载学习心得...15

HA-Proxy

        HA-Proxy相比LVS的使用要简单很多，功能方面也很丰富。

HA-Proxy可以在4，7两层作负载均衡，4层大多用于邮件服务器、内部协议通信服务器等作负载均衡，7层用于Http分析负载转发。

        在HA-Proxy官方网站可以下载配置说明文档（configuration.txt）和架构文件（architecture.txt）作为参考。

具体的使用细节不做太多介绍，这里主要通过具体的配置来大致说一下HA-Proxy的结构。

HA-Proxy组件图

        HA-Proxy配置中分成四部分内容，当然这些组件不是必选的，可以根据需要选择部分作为配置。

Defaults组件是配置默认参数的，这些参数可以被利用配置到frontend，backend，listen组件中（当这些组件某些参数没有被配置而在Defaults中配置了）。

Frontend组件是接收请求的前端虚拟节点，就类似于LVS中配置了VIP的LoadBalancer，Frontend可以直接指定后端指向那一个backend（可动态选择）。

Backend是后端服务集群的配置，类似于LVS中的那些RealServer，一个Backend对应一个或者多个实体服务器。

Listen是Frontend和Backend的组合体，可以直接定义一个类似于JBoss的ServerFarm。

还有一些默认的配置可以通过在配置文件中配置或者在命令行中作为参数输入。

HA-Proxy安装和使用

安装HA-Proxy：

1． 下载HA-Proxy安装包。

2． 解压执行makeTARGET=linux26（注意，TARGET后面根据本机操作系统内核版本来填写）

3． Makeinstall

4． 目录下执行haproxy，如果有使用说明出现表示已经安装正常。

5． 使用方式haproxy–f配置文件地址。

（例如haproxy–fhaproxy.cfg）

HA-Proxy日志配置说明：

HA-Proxy可以收集本机及其他后端服务器日志，但是需要在LoadBalancer上作一些配置。

        首先修改/etc/sysconfig/syslog文件，将SYSLOGD_OPTIONS="-m0”修改为SYSLOGD_OPTIONS="-m0-r-x"，支持收集远程服务器日志。

        然后修改/etc/syslog.conf，增加如下语句：

#addbyhaproxy

local0.* /home/admin/tools/haproxy-1.3.17/haproxy.log //haproxy.log地址代表了需要存储日志的地址

执行servicesyslogrestart，重新启动系统日志器

最后就是在HA-Proxy的配置中增加日志输出（具体可以参考后面的配置文件说明）

        HA-Proxy配置文件说明：

        下面的配置文件简单来说就是配置了根据请求参数的不同，将请求分别定向到后端的淘宝集群和阿里软件集群。

具体配置文件（haproxy.cfg）如下：

  log127.0.0.1 local0info //日志输出配置，所有的日志都记录在本机，通过local0的系统日志器输出，这关系到前面我们做的配置

   daemon //以后台进程方式启动Ha-proxy

   nbproc2//启动两个ha-proxy进程实例

   pidfile/home/admin/tools/haproxy-1.3.17/haproxy.pid   //pid记录的文件

defaults //默认配置

   modehttp//默认采用http模式，可以配置tcp来做4层消息转发

   optionhttplog//采用http日志格式

   retries3//三次连接失败就认为是服务器不可用，主要是通过后面的check配置来实现服务器状态检查

   maxconn2000//最大连接数

   contimeout5000//连接超时时间

   clitimeout50000//客户端连接超时时间

   srvtimeout50000//服务端连接超时时间

   statsuri/admin?

stats//服务器状态统计查看页面

   statsauthwenchu:

wenchu //服务器状态查看授权的用户名和密码设置，可以不设置

   optionhttpchkHEAD/welcome.htmlHTTP/1.0 //服务器状态检查设置，这里是向每一个后端服务器请求/welcome.html页面来检查服务端健康状况。

frontendhttp-in //前端节点定义

   bind:

8181//虚拟服务节点监听本地的8181端口

   modehttp

   log global

   optionhttplog

   optionhttpclose//每次请求完毕后主动关闭http通道，HA-Proxy不支持keep-alive模式，只能够模拟这种模式的实现

   optionforwardfor  //如果后端服务器需要获得客户端的真实IP需要配置次参数，将可以从HttpHeader中获得客户端IP

   capturerequestheaderHostlen20//此配置和一下的类似配置都是抓取Http请求中的参数记录到日志中。

   capturerequestheaderUser-Agentlen16

   capturerequest headerContent-Lengthlen10     

   capturerequest headerReferer       len20 

   captureresponseheaderContent-Lengthlen10

   //控制策略的配置

   aclapi_taobaourl_sub-isip_apiname=taobao. //在请求url中包含sip_apiname=taobao，则此控制策略返回true,否则为false

   aclapi_alisofturl_sub-isip_apiname=alisoft.//在请求url中包含sip_apiname=alisoft，则此控制策略返