阐述门户网站负载均衡技术的六大新挑战

文章名称解释：

什么是haproxy

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

什么是LVS

LVS是一个开源的软件，由毕业于国防科技大学的章文嵩博士于1998年5月创立，可以实现LINUX平台下的简单负载均衡。LVS是Linux Virtual Server的缩写，意思是Linux虚拟服务器。

文 / 李晓栋

记得上大学时，我和好友老郭讨论最多的话题便是：“像新浪这样的网站是如何支撑如此巨大的访问量？”也曾通过各种手段，猜测新浪服务器的数量、操作系统和应用软件的版本……一切都是那么神秘。毕业那年，有幸加入新浪，终于一点点地揭开了这层神秘的面纱。2004年某厂商设备介绍会上，我初次接触到了负载均衡技术。之后的几年时间，可以说是负载均衡设备在网站推广的黄金爆发期。

发展到今天，一方面硬件设备依然保持了强劲的实力，另一方面以LVS、Haproxy为代表的软件负载均衡也异军突起，被人们所认可。在新浪，软、硬件负载均衡并存的格局已有三年多的历史了，除了既往积累的经验外，近一年来，我们也看到了负载均衡所面临的一些新挑战，在此跟大家分享。

挑战一：Web应用对七层交换的依赖度越来越大，显著增加了负载均衡器的压力。

七层交换技术的引入，极大地解放了架构师和程序开发人员，同时也使我们越来越习惯依赖于它，甚至直呼上瘾。很难想象，如果没有负载均衡器的话，现有Web架构中的大量需求应该如何实现? 在充分享受其便利性的同时，我们也看到了一些隐忧。一方面越来越多的流量正从四层交换转为七层交换；另一方面七层交换的规则也越来越趋于复杂。在双重作用下，负载均衡器的压力急剧上升。对于任何一台负载均衡器来说：支撑相同的请求量，七层交换所消耗的CPU要远远高于四层交换。特别是在瞬间高并发连接的突发流量面前，负载均衡器面临着严峻的挑战。

挑战二：微博等互联网新兴产品的出现，对负载均衡器的运维工作提出了更高的要求。

微博不仅改变着亿万网民的生活，而且也正悄然推动着运维体系的建设。

首先，与传统的新闻、博客相比，微博用户对服务质量的敏感度更高，而且这种敏感度会伴随着一次次的“@”和“转发”传播扩散。在过去，当用户访问新浪服务感到慢时，反映的渠道多是打客户电话。而现在只需要在微博上一个简单的“@” 就可以与新浪的客服和技术人员直接沟通。作为流量进出的一个关卡，当微博等线上关键业务出现访问异常或故障时，工程师们都迫切地想知道：是负载均衡器的问题吗？此时故障诊断的效率显得至关重要。在实际工作中我们发现：单纯依靠负载均衡器提供的CPU、内存、连接数等统计信息，还不足以发现一些隐蔽问题。传统的抓包分析耗时耗力且效果不佳，再加上有些故障现象与客户端、后台服务器上的某些特殊设置有着千丝万缕的联系，所有这些交织在一起，给我们故障诊断带来了不小的挑战。例如有次我们发现：负载均衡器偶尔会给客户端返回HTTP  5xx的响应，当时特想快速地知道究竟是什么样的HTTP请求会触发这样的现象。但可惜的是，负载均衡器上仅有统计数字而没有请求的完整记录。在花了很大力气抓包分析后，最终定位到是由于后台一个PHP程序不小心给页面设置了一个错误的HTTP Header，导致Web Server的HTTP响应不能被负载均衡器所接受，最终给客户端返回5xx。因此在故障诊断方面，我们需要有更先进的理念和手段。

其次，微博在国内正处于快速成长期，会随时根据访问量来灵活调整服务器的数量和系统架构。在这种快速灵活的变化面前，负载均衡器相关的配置调整工作也随之增加：频繁的上下线服务器、变更七层规则等。面对这种情况，我们需要思考：如何能更加快速安全地完成好这些变更、如何能避免工程师每天被动地陷入这些重复烦琐的工作中等。目前一些硬件设备提供了API接口，像增删Server、调整Server 权重等这类风险性极低的操作可通过API接口操作，以达到提高效率的目的。而Haproxy、LVS则缺乏这样的 API接口，需要单独开发。

除此之外，关键应用对负载均衡器的监控也有越来越多的新需求。比如：有些应用希望当负载均衡器检测到服务器池中活跃的服务器数量少于一定比例后，便提前给系统管理员作出预警；及时发现服务器池中权重等设置不合理的问题等。

挑战三：多核处理器时代下，Haproxy等用户态的软件负载均衡正面临新的性能瓶颈。

近几年来CPU发展进入了多核时代，CPU由过去的单核发展到四核、六核、八核、十二核，甚至更多，而主频则变化不大。在这种趋势下，充分利用多核特性显得尤为重要。但在我们研究中发现，像Haproxy这类基于用户态的软件负载均衡，其对CPU主频的依赖度要远远高于CPU核数。换言之，在高主频、核数少CPU下的性能很有可能要优于低主频、核数多的CPU。这一点，在Haproxy服务器选型时尤为重要。据我们分析，这主要是由于操作系统对多核（多CPU）下的并发支持度还不够好。

挑战四：软件负载均衡发展路上的“鸡蛋-篮子”理论的艰难选择。

硬件负载均衡器往往以单台高性能著称，而Haproxy、LVS为代表的软件负载均衡的优势则在于成本低廉、可灵活定制，其性能与服务器CPU、网卡等硬件直接相关（当然特殊的优化也很重要）。正如前面提到的，当七层交换流量越来越大时，我们究竟是该投入成本让单台LVS、Haproxy足以支撑如此大的流量，还是让更多中等性能的服务器共同分担这些流量呢？这就是所谓的经典的“鸡蛋－篮子”理论：究竟该不该将鸡蛋放到一个篮子里呢？

其实不同的选择各有利弊。2~3年前，我比较赞同将流量分摊到多台软件负载均衡器上，当时主要考虑到风险的分散。而现在，我更倾向于将流量集中于一台上。之所以这样，是从以下四个角度考虑的。

第一，目前国内IDC内每个机架所放服务器数量跟电力配额直接相关。而负载均衡由于其特殊性，往往是两台为一组，这样每增加一组都会增加额外的电力开销，特别是在电力资源紧张的IDC内，提高单台软件负载均衡器的承载能力可以为关键业务腾出更多的机架来。

第二，从服务稳定角度考虑，我们通常会将LVS、Haproxy直连核心交换机，如此一来，每增加一组，就意味着会占用更多的核心交换机端口资源。

第三，是基于管理成本的考虑。LVS、Haproxy之所以能在新浪得到广泛应用，较低的管理成本是重要原因之一。在新浪我们通过一套集中管理平台和快速初始化的办法实现了运维成本的非线性增加。但不可否认的是，每新增一组，运维成本或多或少总会增加一些。之前也曾设计过一套“同机房内负载均衡器的集群池方案”，即：在一个机房内主备机的数量比不再固定为1:1， 虚拟IP（VIP）会根据集群池中每台Haproxy/LVS的负载状况，动态地“漂”在其中某台上。但后来发现这个“听起来很美”的方案，在实际运行中遇到了种种问题，运维成本不降反升。最终我们又回归了传统的1台Active+1台Standby的模式，正所谓简单即是美。

第四，目前硬件负载均衡器正朝着“更高的性价比”方向发展，换句话来讲，如果我们不提升软件负载均衡器的单机支撑能力，则终有一天，其与硬件设备相比的成本优势将会淡去。

挑战五：在新时期下，如何找到负载均衡的最佳软硬结合之道？

朋友、同行聚会时，常有人问我：“你们有了Haproxy、LVS后，会不会不买硬件设备了？”、“你最近又在山寨什么？”每次听到这些，我都会微微一笑。如前文所述，Haproxy、LVS这类的软件负载均衡和硬件设备各有优势，在我看来，负载均衡的“软”、“硬”解决方案并非水火不容，只要找到最佳的软硬结合之道，鱼和熊掌还是可以兼得的。下面是我们在长期摸索中，总结出来的一些经验。

软件负载均衡可优先承担四层交换流量，让硬件设备更专注于七层交换：由于工作方式和原理的不同，专注于四层交换的LVS在稳定性、单机支撑能力、易维护性、管理成本等多方面均要大大优于Haproxy。特别是在DR模式（即单臂）下， 单台LVS足以应对绝大多数业务的访问量。

优先保障“明星”产品占用宝贵的硬件设备资源：这里指的“明星产品”是指那些用户群正处于快速增长，并被广泛追捧的热点互联网产品，例如微博。考虑到负载均衡器一旦发生异常或宕机后，将对产品的美誉度和用户体验产生一定程度的影响，这属于无形成本的损失。正所谓“好钢要用在刀刃上”，我们可以优先将这类流量放到硬件负载均衡器上。

对于必须采用七层交换的重点服务来说，尽量避免同一重点服务的流量全部放在软件负载均衡器上。例如某重点服务分布于四个IDC内，则可考虑两个IDC内使用Haproxy，另外两个IDC使用硬件设备。这样一方面可以在一定程度上规避使用Haproxy可能带来的风险，另一方面也方便对软、硬件负载均衡器的稳定性、响应时间等进行长期对比观察。

要充分利用好同一IDC内的软、硬件负载均衡器，当一方负载高时，另一方可协助其分担流量，缓解燃眉之急。

总而言之，在负载均衡方面的支出正所谓该花则花、该省则省，合理使用可以让你在保障服务稳定的前提下，获得最佳的投入产出比。

挑战六：软件负载均衡器的资源复用，在降低成本的同时，同时也面临着一定的运维风险。

目前我们的软件负载均衡器分布于全国各地，其中一些中小规模IDC内的软件负载均衡器的负载并不是特别高，而这些机房普遍又需要VPN、自动安装等服务，单独为这些服务再放1~2组服务器显得很不划算。因此我们想到对软件负载均衡器进行资源的复用，即：在软件负载均衡器上同时运行VPN等服务。在实际中发现，这种资源复用面临两方面的风险：一是VPN、自动安装、负载均衡可能分属于不同的管理员，这样大家对同台服务器进行操作会增大因配置冲突、操作不当等导致的服务间互相影响的概率；二是非负载均衡的服务可能会突发占用过多的CPU或网络资源，对正常的负载均衡服务造成了一定的影响。由于LVS、Haproxy服务的特殊性，像Xen这类通过虚拟化来实现资源隔离的办法又不太适用；对服务器流量进行QOS设置，虽然可以起到一定的效果，但配置方面还是有些烦琐。还有更好的办法吗？这确实值得我们思考。

当然除了以上六方面挑战外，负载均衡领域还有很多值得研究之处。不同网站有不同的实际情况，希望本文能对大家起到抛砖引玉的作用。

作者简介：

李晓栋，新浪网研发中心基础架构部技术经理、集团金牌讲师。在新浪有6年多的系统、网络、安全相关工作经验，现负责新浪网络设备和操作系统相关研发工作。自2007年9月以来带领团队研发了新浪DDOS防火墙、广域网加速器、软件负载均衡管理系统、网页挂马检测系统等重要产品, 为公司节约成本上千万元。

（本文来自《程序员》杂志10年11期）

在文章中提高的两个名词(LVS、Haproxy)要怎么用呢？

HAProxy(haproxy.1wt.eu/)可靠运行在以下OS /平台:

负荷平衡器应该考虑以下选项x86_64 x86或硬件,顺序为:

安装haproxy

　　tar zxvf haproxy-1.4.8.tar.gz

　　cd haproxy-1.4.8

　　uname -a //查看linux内核版本

　　make TARGET=linux26 PREFIX=/usr/local/haproxy

　　make install PREFIX=/usr/local/haproxy

配置haproxy

vi /usr/local/haproxy/haproxy.cfg

　　global

　　maxconn 5120

　　chroot /usr/local/haproxy

　　uid 99

　　gid 99

　　daemon

　　quiet

　　nbproc 2

　　pidfile /usr/local/haproxy/haproxy.pid

　　defaults

　　log global

　　mode http

　　option httplog

　　option dontlognull

　　log 127.0.0.1 local3

　　retries 3

　　option redispatch

　　maxconn 2000

　　contimeout 5000

　　clitimeout 50000

　　srvtimeout 50000

　　listen webinfo :1080

　　mode http

　　balance roundrobin

　　option httpclose

　　option forwardfor

　　server phpinfo1 192.168.18.2:10000 check weight 1 minconn 1 maxconn 3 check inter 40000

　　server phpinfo2 127.0.0.1:80 check weight 1 minconn 1 maxconn 3 check inter 40000

　　listen webmb :1081

　　mode http

　　balance roundrobin

　　option httpclose

　　option forwardfor

　　server webmb1 192.168.1.91:10000 weight 1 minconn 1 maxconn 3 check inter 40000

　　server webmb2 127.0.0.1:10000 weight 1 minconn 1 maxconn 3 check inter 40000

　　listen stats :8888

　　mode http

　　transparent

　　stats uri / haproxy-stats

　　stats realm Haproxy \ statistic

　　stats auth zhangy:xtajmd

启动haproxy

　　#启动haproxy

　　/usr/local/haproxy/haproxy -f /usr/local/haproxy/haproxy.cfg

　　#查看是否启动

　　[zhangy@BlackGhost haproxy]$ ps -e|grep haproxy

　　4859 ? 00:00:00 haproxy

　　4860 ? 00:00:00 haproxy

测试haproxy

　　[root@BlackGhost haproxy]# /usr/local/bin/webbench -c 100 -t 30 http://localhost:1080/phpinfo.php

说明：haproxy监听的端口是1080，代理192.168.18.2:10000，127.0.0.1:10000

　　统计监听的是8888端口 http://localhost:8888/haproxy-stats

-----------------------------------------------------------------------------------------------------------

LVS优点：

　　1、开源，免费

　　2、在网上能找到一些相关技术资源

　　3、具有软件负载均衡的一些优点

LVS缺点：

　　1、具有开源产品常有的缺点，最核心的就是没有可靠的支持服务，没有人对其结果负责；

　　2、功能比较简单，支持复杂应用的负载均衡能力较差，如算法较少等；

　　3、开启隧道方式需重编译内核；

　　4、配置复杂；

　　5、只支持LINUX，如果应用还包括WINDOWS、 SOLARIS等就不行了。

　　LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。一般来说，LVS集群采用三层结构，其主要组成部分为：

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

　　B、服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。

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

　　调度器是服务器集群系统的唯一入口点（Single Entry Point），它可以采用IP负载均衡技术、基于内容请求分发技术或者两者相结合。在IP负载均衡技术中，需要服务器池拥有相同的内容提供相同的服务。当客户请求到达时，调度器只根据服务器负载情况和设定的调度算法从服务器池中选出一个服务器，将该请求转发到选出的服务器，并记录这个调度；当这个请求的其他报文到达，也会被转发到前面选出的服务器。在基于内容请求分发技术中，服务器可以提供不同的服务，当客户请求到达时，调度器可根据请求的内容选择服务器执行请求。因为所有的操作都是在Linux操作系统核心空间中将完成的，它的调度开销很小，所以它具有很高的吞吐率。服务器池的结点数目是可变的。当整个系统收到的负载超过目前所有结点的处理能力时，可以在服务器池中增加服务器来满足不断增长的请求负载。对大多数网络服务来说，请求间不存在很强的相关性，请求可以在不同的结点上并行执行，所以整个系统的性能基本上可以随着服务器池的结点数目增加而线性增长。 共享存储通常是数据库、网络文件系统或者分布式文件系统。服务器结点需要动态更新的数据一般存储在数据库系统中，同时数据库会保证并发访问时数据的一致性。静态的数据可以存储在网络文件系统（如NFS/CIFS）中，但网络文件系统的伸缩能力有限，一般来说，NFS/CIFS服务器只能支持3~6个繁忙的服务器结点。对于规模较大的集群系统，可以考虑用分布式文件系统，如AFS、GFS、Coda和Intermezzo等。分布式文件系统可为各服务器提供共享的存储区，它们访问分布式文件系统就像访问本地文件系统一样，同时分布式文件系统可提供良好的伸缩性和可用性。此外，当不同服务器上的应用程序同时读写访问分布式文件系统上同一资源时，应用程序的访问冲突需要消解才能使得资源处于一致状态。这需要一个分布式锁管理器（Distributed Lock Manager），它可能是分布式文件系统内部提供的，也可能是外部的。开发者在写应用程序时，可以使用分布式锁管理器来保证应用程序在不同结点上并发访问的一致性。

　　负载调度器、服务器池和共享存储系统通过高速网络相连接，如100Mbps交换网络、Myrinet和Gigabit网络等。使用高速的网络，主要为避免当系统规模扩大时互联网络成为整个系统的瓶颈。

　　Graphic Monitor是为系统管理员提供整个集群系统的监视器，它可以监视系统的状态。Graphic Monitor是基于浏览器的，所以无论管理员在本地还是异地都可以监测系统的状况。为了安全的原因，浏览器要通过HTTPS（Secure HTTP）协议和身份认证后，才能进行系统监测，并进行系统的配置和管理。

LVS的IP负载均衡

　　可伸缩网络服务的几种结构，它们都需要一个前端的负载调度器（或者多个进行主从备份）。我们先分析实现虚拟网络服务的主要技术，指出IP负载均衡技术是在负载调度器的实现技术中效率最高的。在已有的IP负载均衡技术中，主要有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，我们称之为VS/NAT技术（Virtual Server via Network Address Translation）。在分析VS/NAT的缺点和网络服务的非对称性的基础上，我们提出了通过IP隧道实现虚拟服务器的方法VS/TUN （Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。VS/NAT、VS/TUN和VS/DR技术是LVS集群中实现的三种IP负载均衡技术。

1. HAProxy 1.3 on Linux 2.6.27+
2. HAProxy 1.3 on Linux 2.4 + epoll patch
3. HAProxy 1.3 on Linux 2.6.16 + scheduler starvation fixes
4. HAProxy 1.3 on FreeBSD
5. HAProxy 1.3 on Solaris 10

• Linux 2.4 on x86, x86_64, Alpha, SPARC, MIPS, PARISC
• Linux 2.6 on x86, x86_64, ARM (ixp425), PPC64
• Solaris 8/9 on UltraSPARC 2 and 3
• Solaris 10 on Opteron and UltraSPARC
• FreeBSD 4.10 - 6.2 on x86
• OpenBSD 3.1 to -current on i386, amd64, macppc, alpha, sparc64 and VAX (check the ports)