文档库 最新最全的文档下载
当前位置:文档库 › 门户网站Web及应用服务器加速及负载均衡方案

门户网站Web及应用服务器加速及负载均衡方案

门户网站Web及应用服务器加速及负载均衡方案
门户网站Web及应用服务器加速及负载均衡方案

门户网站Web及应用服务器加速及负载均衡方案

门户网站结构的改造

目前,比较流行的门户网站结构一般分为3层,第一层是W W W服务器或反向代

理服务器,负责处理静态内容;第二层是应用服务器,负责处理后台程序;第三层是数据库,负责存放网站数据。

通常,一个较大的门户网站用户人群都在几百万以上。根据总结出的经验值,同

时在线的用户一般最多为5%,同一时刻更新页面的用户最多为1%,每个页面请求20

个文件,则一个用户人群是300万的网站,同一时刻最大的h t t p请求数为:300万

×5%×1%×20=30000次。我们知道,一台用a p a c h e做w e b服务的P C S e r v e r一般同一时刻能承受约2500次的h t t p请求,因此,一个用户人群是300万的网站需要的w e b服务器的数量为:30000/2500=12台。

除了第一层的w e b服务器,为了提高后台程序的工作效率,网站还使用专门的应用服务器提供应用程序服务以及页面发布服务,使用专门的数据库服务器,实现后台应用的数据库驱动并提供统一用户认证服务。同样,各种应用服务器也将根据实际的应用处理能力需要配置多台且能够同时提供应用服务。

要让多台w e b服务器和应用服务器负载均衡地同时对外提供服务,最好的解决方案就是采用4/7层交换设备,而优势网络(A s c e N e t w o r k s)公司的I n C h o r u s应用前端交换机就是门户网站的最佳选择。

优势网络(A s c e N e t w o r k s)的I n C h o r u s的核心是技术十分成熟的W e b交换机(第四到第七层交换),它是在单一集成式业务平台上提供高可用性和安全性的新一代网络应用交换机。当传统的4/7交换器还在做所谓的服务器负载均衡时,A s c e N e t w o r k s却已经看到了客户目前已经快速发展和变化的应用需求,甚至客户不断发展的未来的需要。

I n C h o r u s强调的不只是服务器负载平衡,它优异的功能包括智能内容交换、应用加速、数据压缩、T C P o f f l o a d、S S L性能加速、N+M设备自身负载均衡等。

InChorus –特性及功能概述

I n C h o r u s负载均衡交换机产品是最先进的应用层交换产品,它易于安装、配置和使用。优势网络在隐藏其复杂性方面做出了优秀的工作,这使得I n C h o r u s负载均衡交换机产品的使用极其合理。

虚拟服务器

I n C h o r u s产品架构–以虚拟服务器为核心

I n C h o r u s产品的核心是其关于―虚拟服务器‖的概念。它是服务器应用或服务的高

效前端,管理所有特定端口和协议的流量。典型的设置是定义多个虚拟服务器,各自控制的不仅是不同的流量,还针对不同的环境基于智能的策略以不同的方法管理流量。例如,他可以应用策略来决定哪个服务器池来处理特定的用户请求。根据支持的协议,可以包括范围极广的T C P和U D P协议,包括H T T P1.0/1.1,H T T P S,S S L/任何S S L封包的协议(S S L会话可以在虚拟服务器上解密),F T P (a c t i v e & p a s s i v e),t e l n e t,S M T P,P O P,I M A P,D N S,L D A P,R A D I U S,N N T P,S O A P,X M L-R P C,S Q L…等等.

可以对虚拟服务器进行以下进一步管理:

1.可以使用T r a f f i c S m a r t智能流量管理语言编辑的规则来检查进入的连接请求,然后选择合适的操作。这些规则可以分为多个层次并且可以按照需求以任意的顺序进行创建。

每条规则都可以检查连接请求,或者可以改变它,然后可能执行以下三种操作中

的一种:

选择一个服务器池来处理请求

?关闭连接请求

?无动作,连接请求转由规则列表中的下一条规则来处理

在每个虚拟服务器后端可能有一个或多个服务器池,包括预先定义的一个缺省服

务器池,如果没有规则来确定具体的数据路由,连接请求将发送到该服务器池来处理。

2.S S L加速和解密

I n C h o r u s设备中,虚拟服务器可以解密S S L流量,而不是简单地将该流量推送到

应用服务器去处理。有两点原因说明这样做是非常有用的,原因之一,在解密后,访问

规则可以分析访问请求的包头和内容,以确定数据流的路由。如果不解密则得不到数据

包的几乎任何信息。原因之二,解密请求需要非常强大的处理能力支持,因此,I n C h o r u s

在数据包发送到后端服务器前就先行解密,可以大大降低后端服务器的负载压力。当然,

如果解密数据包仅仅是向应用访问规则,也可以在应用规则之后重新将数据包加密并发

送给后端服务器,这样在网络中就不存在任何的安全问题。

3.服务保护

越来越多的数据和服务受到各种各样外界因素的威胁和攻击,特别是D o S和D D o S (D e n i a l o f S e r v i c e-拒绝服务和D i s t r i b u t e d D e n i a l o f S e r v i c e-分布式拒绝服务)攻击。

因此,I n C h o r u s在进行流量管理的同时可以有另外一个角色,就是可以建立一系列的服

务保护规则来保护服务免受这些恶意攻击。设置选项包括能够配置禁止和受信的I P地址,这样来自相应I P地址的访问请求将总是被禁止(或允许)。另外,用户也可以限制来自

某一台机器或一组机器的连接数量,可以限制来自任一I P地址的连接r a t e,或者限制

H T T P请求,例如是否必须严格遵循R F C2396标准。

通过和T r a f f i c S m a r t智能流量管理语言编制的访问规则进行结合,用户还可以搜

索或阻止其他一些干扰服务的因素,例如已经被感染的数据包中的病毒特征数据。这样,

I n C h o r u s不仅仅是一台能够进行流量管理和性能加速的设备,它还为用户的数据和服务

提供了强大的安全性保障。

4.访问日志:

可记录访问虚拟服务器的详细日志,可定义每个日志条目的文件名和文件格式;

可记录源地址,被访问的服务器池和服务器节点以及发送和接收的字节数;可记录H T T P

的特定选项,例如被请求的U R L,特定包头的值以及H T T P的方法,等。

5.S m a r t C o m p r e s s内容压缩

另外一个提升客户端到服务器(特别是基于因特网或广域网连接的)性能的方法

就是进行数据压缩。在将响应信息发送到客户端时,I n C h o r u s可以压缩H T T P数据,不

仅可以降低带宽的使用,还可以使基于低速连接传送大型W E B页面的性能得到提高。不

是所有的浏览器都可以接收压缩内容,这一点在H T T P请求包的包头信息中就能够体现,I n C h o r u s可以智能地进行判断,仅是对可以接收压缩内容的浏览器发送压缩内容。

6.O p t i m a l C o n n e c t i o n连接管理

I n C h o r u s除了具有上述特性外,还有一系列用于优化H T T P,F T P和U D P协议的

连接管理选项,以及一些对于超时和内存使用的设置项。所有这些都可以应用到每一个

虚拟服务器来管理每一种特定的协议。通常缺省设置已经足够了,但为了使应用更加灵

活您可以设置这些选项。

服务器池

服务器池用来将后端服务器定义为一个逻辑组,每个后端服务器由服务器名和端口两个部分组成,例如s e r v e r1.b c c b.c o m:80。一旦被定义,虚拟服务器将把连接请求指定给一个服务器池来处理,各个服务器节点将会负载均衡地处理连接请求。服务器池中的每一台服务器必须能够使用虚拟服务器指定的协议,通过指定端口来接收连接请求。除了实现负载均衡,每个服务器池还可以各自设置相应的会话保持或S S L加密方式。

服务器池的设置选项非常灵活,例如,在服务器池中可以设置一个优先级列表,这样用户就可以按照优先级来将服务器进行分组,可以在任何时候指定最小数量的服务器来接收连接请求。比如,用户有5台服务器,至少需要有2台服务器来同时处理连接请求,那么用户可以指定服务器1-3来接收日常流量,服务器4-5作为备用,平常不接收连接请求。当服务器1发生故障时,用户还有两台服务器来负载均衡地处理连接请求,如果此时服务器2也发生故障,这时就会只有一台服务器能够工作。此时,I n C h o r u s就会将备用服务器池中的一台切换到主服务器池中接收连接请求,保证至少有2台服务器来同时处理连接请求,直到主服务器池中的服务器恢复正常。

可以对虚拟服务器进行以下进一步管理:

1.选择负载均衡算法:

所有服务器池管理的基本原则就是其负载均衡的概念——要将负载智能地分布到所有的服务器。I n C h o r u s提供轮循、加权轮循、感知、最小连接数、最快响应时间、随机等多种负载均衡算法。

对于真实环境中的复杂流量,最适当的负载均衡算法应该是―感知‖算法;对于流量较小的环境,用户可以选择―最快响应时间‖算法;而选择最传统的―轮循‖算法则可以让连接平均分布。

精密的算法(感知,最小连接数,最快响应时间)都会考虑服务器缓存。后端服务器会将经常被访问的页面放入其缓存,如果一个新的请求来访问这一页面,I n C h o r u s可以将请求发送到最近时间缓存这一页面的后端服务器,从而提高访问效率。

2.会话保持

对于许多基于W E B的客户-服务器会话而言,保持从客户端到服务器的会话始终采用特定的路径是非常重要的——这通常被称为―粘性‖连接。为此I n C h o r u s提供了会话保持功能,可以保证来自同一客户端所有请求的会话将被发送到同一台后端的服务器进行处理,无论是采用哪种T C P协议。

提供静态W E B内容服务的服务器池一般没有会话保持的要求,即使每个页面或图象从不同的机器发送给客户也不会有什么问题。但是,对于类似在线购物的站点,就非常有必要提供会话保持来确保用户请求始终发送到那台保留有其购物筐详细信息的服务器。

I n C h o r u s提供了多种方法来鉴别来自同一会话的不同请求,会话保持可以使用多种多样的不同的c o o k i e s,可以基于访问规则,或者按照用户的I P地址来实现。如果进入的流量是经过S S L加密的,可以使用S S L会话标识来实现会话保持。

但是当产生无效的会话内容或保留会话的服务器发生故障时又会有新的问题,在这种情况下,用户可以选择关闭连接,将请求发送到另外一台服务器,或者将用户请求重定向到一个特定的U R L,例如出错页面。

I n C h o r u s还具有一种―全局会话保持‖功能,使用脚本控制语言编制的访问规则可

以萃取每个连接的所有独特的会话数据(源I P地址,用户代理,用户名,i-M o d e标识等),并基于上述信息重新生成会话。

3.D r a i n i n g N o d e s

这也是I n C h o r u s的一项十分引人入胜的特性。很多时候,用户都可能有各种各样的原因需要服务器池中的正在工作的一台或多台服务器离线,如打软件补丁,应用升级,等等,如果希望或者必须在正常工作时间来做这些工作,特别是对于那些需要服务器

24x7x365持续工作的情况,这些工作将会带来一些问题,那就是,如果简单地让服务器立刻离线,那么该服务器正在处理的用户连接将全部丢失,对于某些应用或服务而言——特别是从用户的角度去看,这是不可接受的!正因如此,I n C h o r u s允许您将一台或多台服务器进行―d r a i n‖操作,这时这些服务器将不再接受新的连接请求,等到现有连接关闭或会话超时之后再自动离线,此时,所有的用户请求将被发送到服务器池中的其他服务器去处理。在这种情况下,没有任何连接被丢失,这是一个的非常周全的解决方案。

4.健康状况监控

为了能够检查后端网络各种元素的健康状况,I n C h o r u s中包含了一系列的健康状况监控工具,这些工具可以被任何一个服务器池选择调用,每个工具执行一项特定的测试,从简单的向服务器发P I N G包,也可以复杂到检测服务器特定的端口是否打开,是否能够提供特定的数据服务,例如打开一个特定的页面。监控工具可以只对一台服务器,也可以应用于整个服务器池,而且对于一台设备的健康检测往往就会反映出整个服务器池的健康状况。例如,一个邮件服务器池可能将其数据保存在一台后端服务器均可以访问的网络文件服务器上,一个应用于整个服务器池的监控工具可以测试这台服务器,如果这台服务器发生故障,那么所有后端服务器就无法从它上面取得数据,这时整个服务器池也被认为失效。这种模式不仅非常有效,同时立即切断了所有多余的网络管理流量。

TrafficSmart智能流量管理语言

T r a f f i c S m a r t智能流量管理语言是I n C h o r u s的精髓所在,为使之成为真正灵活的工具,我们创建了流量控制脚本语言并用它来编辑访问规则。这些规则能够检测访问请求的所有方面,包括源/目的端口,源/目的I P地址,甚至流量的类型和实际的内容。流量控制脚本可以进行本地X p a t h查询,并可以结合支持D T D和X S L T的X M L流量控制,这些通常可用于基于S O A P协议的W E B服务,可以使复杂的数据进行自动转换和理解而无需用户干预。

I n C h o r u s在图形用户界面中提供了规则生成工具来指导用户生成流量控制脚本,当规则被创建后将被放置在规则目录中,任何虚拟服务器都可以任意调用规则目录中的任何规则。

这样,用户就逐渐建立了一个规则库,可以在任何需要的时候进行调用。因为

I n C h o r u s可以无限制地进行内容检查,也就是可以阅读整个请求的内容并且可以利用请求信息中的任意一个参数来进行流量管理,随着规则库中的规则越来越多,使得

I n C h o r u s成为一个十分强大的应用流量管理引擎。

目录

I n C h o r u s定义了一系列的目录。这些目录就是用于流量管理的对象的集中式的数据库。例如,一个目录中存放的是所有用户设置的访问规则,另一个目录中存放的是所有的健康监控工具。还有大量的目录是和S S L设置相关的(例如,服务器和客户端证书,认证许可以及认证撤消列表等)。这些目录都是可以被单独编辑,并可随时应用到任意一个虚拟服务器或服务器池。如果您编辑了目录中的一个条目,其设置的改变可以将被自动应用到所有使用这个条目的服务,这大大降低了人为因素带来的问题,保证所有的配置是最新的而且是同步的。

应用加速和进程卸载

I n C h o r u s的关键不仅是对于流量的管理,还包括性能优化。方法之一就是采用一种通用的模式,既从服务器上卸载大量的T C P请求,转而由I n C h o r u s来处理。类似地,对于单独的应用,采用一种非介入的方式尽可能地增强已有方案的性能,这只需要一点点或完全不需要进行应用的整合。

InChorus无限的容错能力和可扩展性

为保证用户可以获得接近100%的持续在线时间,优势网络推出了多种自身设备的容错选择,远远超越了当前众多的同类产品。尤其是其独有的C l u s t e r N G设备自身高可用技术,可以让用户获得近乎无限的冗余和可扩展性,它可以让用户建立一个设备数量多达64台的I n C h o r u s集群,而且可以将集群中的任意多台设备配置成在线的(A c t i v e);另外任意多台设备配置成备份的(S t a n d b y)或二级(s e c o n d l y)设备。相比于那些只能提供简单的主备模式(a c t i v e-s t a n d b y)或双活模式(a c t i v e-a c t i v e)的对手来说,在竞争中处于极其优势的地位。

此外,在I n C h o r u s集群中增加新的I n C h o r u s设备非常简单,因为新的I n C h o r u s 设备可以被已有的集群自动检测到,同时配置可以自动复制到该设备。这种独有的特性使用户可以用极低的成本构建和扩展系统(每次只需购买满足当时所需性能的I n C h o r u s 即可,扩展的设备可以和原有设备同时工作,在保护原有投资的情况下扩展性能),同时非常的简单。

诊断(Diagnose)

用来检验明显的配置问题其根源何在,或者是简单地来证明所有的配置都是工作正常的。

可以在任何一个页面点击―诊断(D i a g n o s e)‖按钮来查看当前的系统状态。

自检页面分成多个部分,可以清楚地识别哪些元素工作正常,哪些元素工作不正常,例如服务器池没有响应。

性能监控

1.实时监控:

当前活动(C u r r e n t A c t i v i t y)监控页面为用户展示了系统当前活动流量的实时图形,有多个选项来选择需要查看哪些数据(例如每个节点的带宽),查看哪种形状的图形(线形图,饼图等),可以选择具体要监控哪些统计信息,而且可选范围极为广泛;可选择图形大小和监控时间段(分钟),可以将数据下载为.t s v(t a b-s e p a r a t e d v a r i a b l e)格式的文件进行分析,所有数据可以通过S N M P发送到外部。

2.历史数据:

可查看过去30天活动流量的实时图形,可选择查看每秒点击数量或每秒处理的数据量,可按照每虚拟服务器/每服务器池或每个服务器节点选择查看,时间段可从1小时到30天之间选择;可选择图形大小和坐标类型,可以将数据下载为.t s v(t a b-s e p a r a t e d v a r i a b l e)格式的文件进行分析,所有数据可以通过S N M P发送到外部。

3.实时连接:

查看当前连接的详细信息,包括:哪台I n C h o r u s交换机管理前连接

?连接源地址

?连接端口

?连接目的地址

?连接的状态

?连接的虚拟服务器

?使用的访问规则

?连接的服务器池

?重试次数

?连接的客户端空闲时间

?连接的服务器端空闲时间

?接受到的客户端流量

?发送到客户端的流量

?连接建立的时间

等等。

服务器负载均衡技术

HUAWEI USG6000V系列NFV防火墙技术白皮书之---服务器负载均衡技术白皮书 华为技术有限公司 Huawei Technologies Co., Ltd.

目录 1背景和概述 (2) 2全局服务器负载均衡(GSLB) (3) 3本地服务器负载均衡(LSLB) (4) 3.1使用目的MAC地址转换的服务器负载均衡(DR) (4) 3.2使用网络地址转换实现的服务器负载均衡(L4 SLB) (5) 3.3使用轻量代理和网络地址转换的服务器负载均衡(L4 lwProxy SLB) (7) 3.4使用全量Socket 代理的服务器负载均衡(L7 Socket Proxy SLB) (9) 3.4.1socket代理加业务会话关联保持 (9) 3.4.2根据URL类型不同的分担,静态资源访问和动态计算访问分开多种服务 器10 3.4.3SSL卸载 (10) 3.4.4链路优化:压缩、协议优化、本地cache、多路复用 (11) 3.5业务保持技术 (13) 4华为USG防火墙支持的SLB功能列表 (14)

1 背景和概述 随着互联网的快速发展,用户访问量的快速增长,使得单一的服务器性能已经无法满足大量用户的访问,企业开始通过部署多台服务器来解决性能的问题,由此就产生了服务器负载均衡的相关技术方案。 在实际的服务器负载均衡应用中,由于需要均衡的业务种类以及实际服务器部署场景的不同(比如是否跨地域、跨ISP数据中心等),存在多种负载均衡的技术。如下典型的组网方式如图所示: 服务提供方为了支撑大批量的用户访问,以及跨不同地域、不同接入ISP的用户都能够获得高质量的业务访问体验,其已经在不同地域、不同ISP数据中心搭建了服务器,这样就带来一个需求,也就是客户的访问能够就近、优先选择同一个ISP数据中心的服务器,从而获得高质量的业务访问体验。 同时,基于单台服务器能够提供的业务访问并发是有限的,那么就自然想到使用多台服务器来形成一个“集群”,对外展现出一个业务访问服务器,以满足大量用户访问、而且可以根据业务访问量的上升可以动态的进行业务能力扩容的需要。

全局负载均衡解决方案

全局负载均衡解决方案 1 需求分析 无论用户的数据中心内部采用多么完善的冗余机制、安全防范工具以及先进的负载均衡技术,单个数据中心的运行方式仍然不能保证关键业务可以7*24不间断运行。 而为了满足处于全球范围内不同地点的用户在访问应用时可以具备相同的快速访问感受,单一的数据中心却完法实现。 基于以上两个最主要的原因,用户通过在不同物理位置构建多个数据中心的方式已经成为用户的必然选择。然而,在构建了多个数据中心后,如何通过有效手段实现多个数据中心间的协调工作,引导用户访问最优的站点,或者当某个站点出现灾难性故障后使用户仍然可以访问其他站点上的关键业务等问题成为用户最关注的问题。 2 Radware 全局负载均衡解决方案 Radware 的全局负载均衡解决方案能够帮助客户通过将相同服务内容布署在处于不同物理地点的多个数据中心中得到更高的可用性、性能、以及更加经济和无懈可击的安全性,以便在全球范围内的客户获得更快的响应时间。 Radware的全局负载均衡解决方案支持Radware 下一代APSolute OS 软件体系结构的全部功能,彻底解决了网络可用性、性能和安全问题,使得应用在多个数据中心中获得更高的灵敏并具有自适应性。配合Radware 的高速度、高容量ASIC芯片+NP处理器的专用硬件应用交换设备,可有效保障网络应用的高可用性、提升网络性能,加强安全性,全面提升IT服务器等网络基础设施的升值潜力。 结合Radware多年来在智能应用流量管理领域的经验,以及对用户实际需求的分析,我们认为负载均衡器应具备如下功能:

?能够通过唯一的IP地址或域名的方式作为所有提供相同服务的数据中心的逻辑入口点。 ?全局负载均衡交换机具有灵活的流量分配算法与机制,以确保用户总能访问可以为其提供最优服务的数据中心的内容。 ?通过部署高性能的负载均衡产品,能够及时发现各数据中心或数据中心内部的服务器的健康状况,当某个数据中心出现故障时,保证把后续用户的访问导向到正常运行的数据中心上。 ?针对基于会话的业务,可以提供多种会话保持机制,确保用户在处理业务时的连续性。避免将用户的相同会话的业务请求,分配到不同的数据中心而造成访问失败。 ?应具备安全过虑及防DOS/DDOS的功能,为服务器提供多一层安全保障 ?具有很好的升级与可扩展性,能够适应特定的和不断变化的业务需求。 2.1 方案拓扑图 2.2 AppDirector-Global实现全局及本地负载均衡 在全局及本地负载均衡方面,AppDirector-Global主要在网络中实现以下功能: 2.2.1 全局负载均衡策略 Radware支持多种全局负载均衡策略,能够通过唯一的IP地址或域名的方式作为所有提供相同服务的数据中心的逻辑入口点。根据用户的实际情况,可以选择其中以下的一种,也可以组合同时使用。

负载均衡解决方案V1

负载均衡解决方案 公司:XX 日期:XX年XX月XX日

目录 1. 负载均衡概述 (3) 2. 项目现状 (3) 3. 项目需求分析 (4) 4. 项目解决方案 (4) 5. 负载均衡结构介绍 (7) 5.1. 负载均衡 (7) 5.2. 负载均衡实现设备[2] (8) 5.3. 负载均衡系统结构 (9) 5.3.1. 两层结构的负载均衡系统 (9) 5.3.2. 三层结构的负载均衡系统 (9) 5.4. 负载均衡实现的方法 (11) 6. Web服务器集群环境配置与测试 (11) 6.1. 搭建环境 (11) 6.1.1. 软硬件环境的搭建 (11) 6.1.2. 软件的安装与配置 (11) 6.2. 环境的测试 (13) 6.3. 集群系统负载均衡测试 (13) 6.4. 集群系统负载均衡测试分析 (13) 6.5. 本系统的不足之处 (14)

1.负载均衡概述 为了提高集群系统对用户的快速响应与整体吞吐量,必须采取一定的策略将Web访问均衡地分配到集群中的每一个服务器。基于此思想本文针对传统的单机思想给出了一种多机三层结构的负载均衡系统。实验结果表明了它在负载均衡方面的优越性。 Internet的快速增长,特别是电子商务应用的发展,使Web应用成为目前最重要最广泛的应用,Web服务器动态内容越来越流行。目前,网上信息交换量几乎呈指数增长,需要更高性能的Web服务器提供更多用户的Web服务,因此,Web服务器面临着访问量急剧增加的压力,对其处理能力和响应能力等带来更高的要求,如果Web 服务器无法满足大量Web访问服务,将无法为用户提供稳定、良好的网络应用服务。 由于客观存在的服务器物理内存、CPU 处理速度和操作系统等方面的影响因素,当大量突发的数据到达时,Web服务器无法完全及时处理所有的请求,造成应答滞后、请求丢失等,严重的导致一些数据包因延时而重发,使传输线路和服务器的负担再次增加。传统的方法是提高Web 服务器的CPU 处理速度和增加内存容量等硬件办法但无论如何增加Web 服务器硬件性能,均无法满足日益增加的对用户的访问服务能力。 面对日渐增加的Web 访问服务要求,必须对Web 服务器按一定策略进行负载分配。利用负载均衡[1]的技术,按照一定策略将Web 访问服务分配到几台服务器上,负载处理对用户透明,整体上对外如同一台Web 服务器为用户提供Web服务。 2.项目现状 本案例公司中现有数量较多的服务器群: ?WEB网站服务器 4台

服务器负载均衡的设计与实现

服务器负载均衡的设计与实现 在该架构中OpenFlow控制器可以获取每个服务器的运行状态,并根据运行状态分发用户请求,最大程度地利用每台服务器的计算资源,并且可以在系统运行期间动态地添加或删除服务器,使系统具备很高的灵活性。 1、动态负载均衡架构的整体设计 负载均衡架构是在一个非结构化的网络中使用集中式的控制器实现多台服务器共同对外提供服务。OpenFlow网络中的所有交换机都连接在一个控制器上,每台服务器有两块网卡,一块网卡连接到OpenFlow网络对用户提供网络服务,另一块通过以太网交换机和控制器相连,以便控制器通过SNMP协议获取服务器的运行状态,具体架构如图所示。 在上述负载均衡架构中控制器是网络的核心,其主要功能有四个,分别为: 保证网络正常的通信、获取服务器的运行状态、通过负载均衡算法计算服务器的综合负载、向交换机下发流表项以转发用户请求;控制器的模块设计如图所示。 本文阐述的负载均衡架构可以工作在任意openflow网络中,而不是专门为某个服务器

所设计的负载均衡,控制器的首要任务就是保证网络可以提供正常的数据转发服务,为了保证网络既可以为其他服务提供基础支持又保证负载均衡能够正常工作,在控制器的转发控制中有两个模块,第一个模块负责负载均衡服务,第二个模块负责网络的基本通信。当一个数据包到达Openflow交换机后,如果交换机找不到可以匹配的流表项,就会向控制发送packet-in消息,控制器收到packet-in消息之后首先交给负载均衡模块,由负载均衡模块处理该消息,如果该数据包的目的IP 不是负载均衡所负责的网络服务,如果该数据包的目的IP不是负载均衡所负责的网络服务,负载均衡模块就不会做任何处理而是直接packet-in 消息传递给网络通信模块,以保证其它业务正常通信。如果该数据包的目的IP是负载均衡所负责的网络服务,负载均衡模块就向交换机下发流表项让交换机完成负载均衡服务。 为了有效地利用计算资源,控制器还需要根据服务器的运行状态转发用户请求,因此控制器还要完成这方面的工作。在此架构中每台服务器都有一块通过以太网交换机和控制器相连的网卡,控制器通过以太网交换机和服务器通信,利用SNMP协议获取服务器的运行状态。在此架构中就算没有和服务器相连的网卡,控制器也可以通过Openflow网络和服务器通信,本文之所以没有这么做是因为控制器直接和连接在openflow网络中的服务器通信需要交换机把所有服务器所发送的消息封装成packet-in消息发送给交换机,控制器也必须通过向交换机发送packet-out消息才能把数据发送给服务器,这样做会给交换机和控制器同时带来很大的压力。 因为服务器的运行状态必须由多条信息才能描述清楚,所以就算得到服务器的运行状态之后,也无法根据多条信息判断哪台服务器的负载最低。因此本文在控制器中运行了一个负载均衡算法,控制器会把服务的运行状态作为负载均衡算法的参数代入到服务器综合负载的运算中,计算出服务器的综合负载,并根据综合负载得到负载最小的服务器。 负载均衡的核心内容就是让交换机分发用户的请求,用户请求的第一个数据包到达交换级之后,交换机会通过packet-in消息把数据包发送给控制器,控制器中的负载均衡模块会通过SNMP协议获取所有服务器的运行状态,并根据运行状态计算服务器的综合负载,之后把用户的请求转发给综合负载最小的服务器。 2、动态负载均衡架构的设计与实现 负载均衡常用的算法有随机、轮训和最小连接数,原因是这三种算法很容易用硬件实现,这三种算法中最小连接数算法的效果是最理想的,但是如果集群中的服务器在CPU、内存、网络带宽上的配置不相同,这三个算法都不能充分地发挥服务器集群的计算能力。在openflow网络中,网络的控制层由软件制定,负载均衡算法也可以集成在控制器中,使用软件完成,这样可以更准确地评估服务器的负载情况。本文阐述的负载均衡方案中就设计了一个负载均衡算法,根据服务器的运行状态计算服务器的综合负载,并返回综合负载最小的服务器。该算法可以在服务器性能差距较大的集群中充分发挥每一台服务器的计算能力,算法的具体实现过程如下: 1)动态反馈当前服务器负载量 主要收集每台服务器CPU和内存的使用率,这些信息并不能直接表示一台服务器的负载情况,所以使用公式1把CPU和内存信息转换为服务器的负载量,其中LC为第i台服务器CPU的使用率,LM为第i台内存的使用率,r1和r2为权值,用于强调该服务类型对各个部分的不同影响程度,r1+r2=1,LS为计算得出的第i台服务器负载量 LS=r1LC+r2*LM 2)服务器处理能力计算; 集群中服务器的性能也可能不同,在计算服务器负载的时候还要考虑服务器的处理能力,第i台服务器的处理能力使用C(i)表示,C的计算方法如公式所示,其中P为第i台服务器CPU的个数,M为第i台服务器内存的大小,r1和r2为权值,r1+r2=1。

几种负载均衡策略比较~

PS:Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件,本人都在多个项目中实施过,参考了一些资料,结合自己的一些使用经验,总结一下。 一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析,如果是中小型的Web应用,比如日PV小于1000万,用Nginx就完全可以了;如果机器不少,可以用DNS轮询,LVS所耗费的机器还是比较多的;大型网站或重要的服务,且服务器比较多时,可以考虑用LVS。一种是通过硬件来进行进行,常见的硬件有比较昂贵的F5和Array等商用的负载均衡器,它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,所以对于规模较小的网络服务来说暂时还没有需要使用;另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件,这些都是通过软件级别来实现,所以费用非常低廉。 目前关于网站架构一般比较合理流行的架构方案:Web前端采用 Nginx/HAProxy+Keepalived作负载均衡器;后端采用MySQL数据库一主多从和读写分离,采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。 下面说说各自的特点和适用场合。 一、Nginx Nginx的优点是: 1、工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构,它的正则规则比HAProxy更为强大和灵活,这也是它目前广泛流行的主要原因之一,Nginx单凭这点可利用的场合就远多于LVS了。 2、Nginx对网络稳定性的依赖非常小,理论上能ping通就就能进行负载功能,这个也是它的优势之一;相反LVS对网络稳定性依赖比较大,这点本人深有体会; 3、Nginx安装和配置比较简单,测试起来比较方便,它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了,LVS对网络依赖比较大。 3、可以承担高负载压力且稳定,在硬件不差的情况下一般能支撑几万次的并发量,负载度比LVS相对小些。 4、Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测。比如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,Nginx会把上传切到另一台服务器重新处理,而LVS就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而不满。 5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件,它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构,在高流量的环境中稳定性也很好。 6、Nginx现在作为Web反向加速缓存越来越成熟了,速度比传统的Squid服务器更快,可以考虑用其作为反向代理加速器。 7、Nginx可作为中层反向代理使用,这一层面Nginx基本上无对手,唯一可以对比

数据库负载均衡解决方案

双节点数据库负载均衡解决方案 问题的提出? 在SQL Server数据库平台上,企业的数据库系统存在的形式主要有单机模式和集群模式(为了保证数据库的可用性或实现备份)如:失败转移集群(MSCS)、镜像(Mirror)、第三方的高可用(HA)集群或备份软件等。伴随着企业的发展,企业的数据量和访问量也会迅猛增加,此时数据库就会面临很大的负载和压力,意味着数据库会成为整个信息系统的瓶颈。这些“集群”技术能解决这类问题吗?SQL Server数据库上传统的集群技术 Microsoft Cluster Server(MSCS) 相对于单点来说Microsoft Cluster Server(MSCS)是一个可以提升可用性的技术,属于高可用集群,Microsoft称之为失败转移集群。 MSCS 从硬件连接上看,很像Oracle的RAC,两个节点,通过网络连接,共享磁盘;事实上SQL Server 数据库只运行在一个节点上,当出现故障时,另一个节点只是作为这个节点的备份; 因为始终只有一个节点在运行,在性能上也得不到提升,系统也就不具备扩展的能力。当现有的服务器不能满足应用的负载时只能更换更高配置的服务器。 Mirror 镜像是SQL Server 2005中的一个主要特点,目的是为了提高可用性,和MSCS相比,用户实现数据库的高可用更容易了,不需要共享磁盘柜,也不受地域的限制。共设了三个服务器,第一是工作数据库(Principal Datebase),第二个是镜像数据库(Mirror),第三个是监视服务器(Witness Server,在可用性方面有了一些保证,但仍然是单服务器工作;在扩展和性能的提升上依旧没有什么帮助。

F5负载均衡双机热备实施方案

F5双机热备实施说明 2012/12/4

一、项目拓扑图及说明 两台F5负载均衡设备采用旁挂的方式连接至交换机,设备地址和虚拟地址在服务器的内网地址段中划分;使用F5为认证应用服务器进行流量负载均衡。 二、设备信息及IP分配表 F5:型号BIG-IP LTM 1600 软件版本:V10.2.4 对外地址对外端口内网地址内网端口协议设备名备注 192.168.100.21 https://www.wendangku.net/doc/bf10231400.html, F5-1IP地址 192.168.100.22 https://www.wendangku.net/doc/bf10231400.html, F5-2IP地址 192.168.100.23 F5浮动地址 10.168.100.21 F5-1数据同步 10.168.100.22 F5-2数据同步 192.168.100.150 80 192.168.100.4 80 TCP 认证服务器1 192.168.100.5 80 TCP 认证服务器2 三、实施步骤及时间

3.1、F5设备加电测试 3.2、配置F5及F5双机,需2.5小时 3.3、测试F5双机切换,需0.5小时,这部分作为割接准备工作。3.4、先添加认证服务器单节点到F5设备192.168.100.150的虚拟服务中,在内网测试应用,需0.5小时 3.5、将应用服务器从双机模式更改为集群模式,将认证服务器两个节点添加到F5设备,这个时间取决于服务器模式更改的时间。 3.6、在防火墙上更改认证服务器的映射地址,将原来的地址更改为F5设备上的虚拟服务IP地址192.168.100.150 ,TCP 协议80端口。 四、回退方法 在外部网络不能访问认证服务时,回退的方法是在防火墙上把F5设备虚拟服务器192.168.100.150地址映射,更改为原单台认证服务器IP地址,将认证服务器集群模式退回双机模式。 五、F5设备配置步骤 5.1、设置负载均衡器管理网口地址 F5 BIG-IP 1600 设备的面板结构: BIG-IP 1600应用交换机具备四个10/100/1000M自适应的网络接口及二个光纤接口. 10/100/1000 interface — 4个10/100/1000 M 自适应的网络接口 Gigabit fiber interface — 2个1000M 多模光纤接口

负载均衡解决方案设计设计

一、用户需求 本案例公司中现有数量较多的服务器群: WEB网站服务器 4台 邮件服务器 2台 虚拟主机服务器 10台 应用服务器 2台 数据库 2台(双机+盘阵) 希望通过服务器负载均衡设备实现各服务器群的流量动态负载均衡,并互为冗余备份。并要求新系统应有一定的扩展性,如数据访问量继续增大,可再添加新的服务器加入负载均衡系统。 二、需求分析 我们对用户的需求可分如下几点分析和考虑: 1.新系统能动态分配各服务器之间的访问流量;同时能互为冗余,当其中 一台服务器发生故障时,其余服务器能即时替代工作,保证系统访问的 不中断; 2.新系统应能管理不同应用的带宽,如优先保证某些重要应用的带宽要 求,同时限定某些不必要应用的带宽,合理高效地利用现有资源;

3.新系统应能对高层应用提供安全保证,在路由器和防火墙基础上提供了 更进一步的防线; 4.新系统应具备较强的扩展性。 o容量上:如数据访问量继续增大,可再添加新的服务器加入系统; o应用上:如当数据访问量增大到防火墙成为瓶颈时,防火墙的动态负载均衡方案,又如针对链路提出新要求时关于Internet访问 链路的动态负载均衡方案等。 三、解决方案 梭子鱼安全负载均衡方案总体设计 采用服务器负载均衡设备提供本地的服务器群负载均衡和容错,适用于处在同一个局域网上的服务器群。服务器负载均衡设备带给我们的最主要功能是:

当一台服务器配置到不同的服务器群(Farm)上,就能同时提供多个不同的应用。可以对于每个服务器群设定一个IP地址,或者利用服务器负载均衡设备的多TCP端口配置特性,配置超级服务器群(SuperFarm),统一提供各种应用服务。

Radware负载均衡解决实施方案

Radware负载均衡解决实施方案

————————————————————————————————作者:————————————————————————————————日期:

Radware WSD 服务器负载均衡解决方案

1.1 WSD ―服务器负载均衡 1.1.1Radware 网络应用系统负载均衡的基本工作原理 Radware的WSD通过对于数据包的4-7层信息的检查来进行负载均衡的判断,服务器负载均衡是最普遍的一种4-7层交换的例子,下面我们就以服务器负载均衡的整个流程来介绍Radware WSD的工作原理: 1.1.1.1 会话“session”。 请看下面会话的例子: 为了识别会话,客户机和服务器都使用TCP“埠”。客户机和服务器之间的TCP会话由四个参数定义:客户机IP地址、客户机TCP端口、服务器IP地址和服务器TCP端口。所以,如果IP地址为199.1.1.1的客户机使用TCP端口1234与IP地址为145.145.100.100的服务器(TCP埠80)建立会话,则该会话定义如下: (clntIP,clntPORT,srvrIP,crvrPORT )= (199.1.1.1,1234,145.145.100.100,80) 1.1.1.2 服务器负载均衡 假设图1中所示的样例,客户机通过访问服务器负载均衡设备WSD的虚拟地址145.1.1.1 进行HTTP应用的访问。再假设选择服务器145.145.100.100响应此客户机,则客户表的记录如下所示:

如果启用此记录,WSD 会执行以下两个任务: 1. 所有从客户机199.1.1.1发送到服务器群145.145.1.1且目标TCP 端口为80的数据包将被发送到服务器145.145.100.100。 2. 所有从服务器145.145.100.100发送到客户机199.1.1.1且源TCP 端口为80的数据包将被改为源地址145.145.1.1发送出去。 即:对于用户199.1.1.1 来说,145.145.1.1 是他要访问的服务器IP 地址,当WSD(145.145.1.1),收到用户请求后,会根据后面2台服务器的“健康状况”和负载均衡算法将用户的请求转发到某一台服务器145.145.100.100 1.1.1.3 健康检查 由于负载均衡设备同应用的关系比较紧密,所以需要对负载均衡的元素进行“健康”检查,如果负载均衡设备不能在应用进行健康检查,就无法做到对应用的高可靠性的保障。 Radware 的高级健康检查模块,可以准确的做到应用层的健康检查。这种新的模块与流量复位向模块紧密相连, 可以提前检验所有应用和网络部件的可用

A10服务器负载均衡解决方案解读

1SJ tit works ***** 单位 A10负载均衡解决方案 A10 Networks Inc. 1SJ tit works

目录 1.项目概述 (1) 2.需求分析及讨论 (1) 2.1应用系统所面临的共性问题 (1) 2.2需求分析 (2) 3.A10公司负载均衡解决方案 (3) 3.1网络结构图 (3) 3.2A10负载均衡解决方案 (3) 3.2.1APP Server负载均衡的实现 (4) 3.2.2应用优化的实现 (4) 3.3解决方案说明 (5) 3.4方案的优点 (6) 4.A10 AX的优点及各型号指标总结 (7) 5.A10公司简介 (7) 6.AX介绍 (8) 6.1 A10公司AX简介 (8) AX系列功能 (8)

1. 项目概述 2. 需求分析及讨论 2.1应用系统所面临的共性问题 随着用户量增大及业务的发展,一个应用系统往往会出现各种问题。瓶颈可能出现在服务器、存储、网络设备,带宽等的性能不足,而运行一旦出现故障给业务带来的影响范围是巨大的,服务器可能出现的问题表现为如下几点: ?高可用问题 关健性应用要求7*24稳定运行不被中断,高可用性问题被放在首要位置。 ?利用“不平衡”现象 数据的大集中使得服务器的访问压力日益增大,服务器性能往往会成为一个系统的瓶颈,随着性能问题的产生,单点故障的发生也将比较频繁,为了解决这些问题,传统的方式多为采取更换更好的服务器并且采用双机备份系统提供服务的方式,这样必然存在 一半的资源浪费的情况,而在压力不断上升的情况下,这种动作讲不断的重复,不但服务器的利用率不平衡,而且持续引起投资的浪费。 ?“峰值”问题 服务器的处理多存在“波峰”和“波谷”的变化。而且“波峰”时,业务量大小的变化又不规律,这就使服务器不得不面对“峰值堵塞”问题。原有解决方法为增加服务器或主机数量,提高处理能力。但仍存在性能不平衡问题,且这样做,投资成本大。 ?多米诺”现象 单台服务器的设置,不可避免会出现“单点故障”,需要进行服务器“容错”。为实现容错,往往在主服务器旁安置一台或多台备份服务器。但这样做,平时只有一台服务器工作,其它服务器处于空闲状态,无法完全利用所有服务器的处理资源,当出现“峰值堵塞”时,“多米 诺”效应往往会发生,即所有服务器连续被“堵”至“死”。最终的结果将导致系统的瘫痪。 ?“扩展”不便 随着物理和应用的集中,服务器上所要处理的数据量(traffic )增大,客户交易产生

链路负载均衡解决方案

Array Networks 链路负载均衡解决方案 -Array APV系列、AppVelocity应用于企业网络优化

目录 1. 多链路接入背景介绍 (3) 1.1 单链路接入单点故障 (3) 1.2 运营商之间互访 (4) 1.3 双链路解决方案的产生以及其衍生的问题 (4) 2. Array 提供最佳的解决方案 (6) 2.1 方案介绍 (6) 2.2 流出(Outbound)流量处理 (7) 2.3 其它重要功能设置: (8) 2.4 流入(Inbound)流量处理 (8) 3. 解决方案功能特点介绍 (10) 3.1. 全面的链路监控能力 (10) 3.2. 全路经健康检查 (10) 3.3. 策略路由 (11) 3.4. APV-LLB的链路负载均衡解决方案具有以下功能和优点: (11) 3.5. 链路优化功能与其他应用性能提高功能 (11) 3.5.1. Http 压缩功能 (11) 3.5.2. Cache 功能 (11) 3.5.3. Connection Multiplexing(连接复用)技术 (12) 3.5.4. Connection Pooling(连接池)技术 (12) 3.5.5. Array SpeedStack?技术 (12) 3.6. 安全防护功能 (13) 3.7. Cluster技术 (13) 3.8. Array APV 配置管理 (14) 3.9. 可扩展性 (14) 3.9.1. 服务器负载均衡与广域网负载均衡 (14) 3.9.2. 扩展的SSL加速适用于电子商务 (14) 4. 链路负载均衡对企业的价值 (14)

负载均衡方案及详细配置

Apache+Tomcat+mod_jk实现负载均衡方案 一、概述: 原理图: 提高系统可用性,对系统性能影响较小。对于一台服务器Down机后,可自动切换到另 最少需要两台机器,Tomcat1 和Tomcat2可在同一台服务器上。若条件允许最好是各用一台服务器。 二、详细配置步骤: 1、Apache http Server安装 32位的按照提示操作即可。 64位系统的不是安装包。 64位安装配置: 以管理员身份运行cmd 执行:httpd -k install 若无法运行并提示配置错误,请先安装vcredist_x64.exe后再执行。 安装后在Testing httpd.conf...时会报错,不影响。 httpd -k start 启动Apache、httpd -k shutdown 停止Apache 、httpd -k restart重启测试Apache:

在IE中输入:127.0.0.1 打开网页显示It work就OK 2、将Mod_jk的压缩包解压,找到mod_jk.so 复制到Apache目录下modules目录下 64位的下载mod_jk1.2.30_x64.zip 32位的下载tomcat-connectors-1.2.35-windows-i386-httpd-2.0.x.zip 3、修改Apache conf目录下的httpd.conf文件 在最后增加:Include conf/extra/mod_jk.conf 4、在conf/extra 下创建mod_jk.conf文件 增加如下: #load module mod_jk.so LoadModule jk_module modules/mod_jk.so #mod_jk config #load workers JkWorkersFile conf/workers.properties #set log file JkLogFile logs/mod_jk.log #set log level JkLogLevel info #map to the status server #mount the status server JkMount /private/admin/mystatus mystatus JkMount /* balance 5.在conf目录下创建workers.properties文件 增加:worker.tomcat1 中的tomcat1和tomcat2必须和Tomcat中的配置相同。Tomcat配置下面介召 worker.list=balance,mystatus #first worker config worker.tomcat1.type=ajp13 worker.tomcat1.host=192.168.8.204 worker.tomcat1.port=8009 #Tomcat的监听端口 worker.tomcat1.lbfactor=1 worker.tomcat1.socket_timeout=30 worker.tomcat1.socket_keepalive=1 #second worker config worker.tomcat2.type=ajp13 worker.tomcat2.host=192.168.8.204 worker.tomcat2.port=8010 #Tomcat的监听端口实验是在同一机器上做的,所以两个不同

(完整版)F5服务器负载均衡解决方案要点

F5服务器负载均衡解决方案 目录 一.大量数据处理所面临的问题 (2) 1.目前存在隐患 (3) 2.应用系统问题综述 (3) 1)“峰值”问题 (4) 2)多米诺”现象 (4) 3)“N+1”方式 (4) 4)“扩展”不便 (5) 5)“免疫力”差 (5) 6)“容灾”.................................................................................... 错误!未定义书签。 7)应用与网络脱节 (6) 二.F5解决方案 (6) 2.1 网络结构 (6) 2.2 方案优势 (7) 2.2.1避免“不平衡”现象 (7) 2.2.2解决因“峰值堵塞”带来的性能调整“不平衡” (9) 2.2.3避免“多米诺”现象 (9) 2.2.4更好的提供系统容错,提高系统可靠性 (10) 2.2.5“扩展”灵活 (11) 2.2.6“免疫力”强 (12) 2.2.7“容灾” (13) 2.2.8网络感知应用,应用控制网络 (14) 三.相关技术资料 (17) BIG-IP提供支持99.999%的正常运行 (17) 四.成功案例 (19) F5为中国某税务机关提供高可用性解决方案 (19)

一.大量数据处理所面临的问题 在现今的企业中,不论是否提供关键性任务的服务,都需要一个持续运行不断的高可用性网络计算环境以维持不间断的高品质服务。所谓高可用性的环境,也是信息管理人员所必须考虑的四件事: 1.使数据有一个安全的存储和运作方式,即使在设备故障时仍能保持数据的完整 一致。 2.使服务器系统持续运行,即使发生故障仍然让服务持续下去。 3.使整个计算环境能更好的管理,如何容错、容灾、集群共享。 4.如何使投资有最好的效益,使系统有最佳的扩充能力,有最低的整体拥有成本, 也就是在任何情况之下均能确保数据的完整一致,系统持续运行,使服务不间 断,同时有最好的投资回报率。 高可用性被定义为计算系统的连续运行。根据故障停机的业务影响,应用系统需要不同的可用性水平。要想实现一个应用系统的高可用性,所有组件(包括应用和数据库服务器、存储设备以及端到端网络)都需要提供连续的服务。 企业和机构对网络化应用及Internet 的日益依赖,加上语音和数据的集成,创造了对高可用性应用的增加需求。任何类型的系统故障停机都可能意味着收入、信誉和客户满意的巨大损失。 高度网络可用性的利用,企业实施高可用性网络来: ?防止财务损失 ?防止生产力损失 ?改进用户满意度 ?改进客户满意/信任 ?降低反应性IT支持成本,提高IT生产力 ?部署关键任务应用支持新业务实践的好处 ?典型的业务要求 为了实现高度的网络可用性,需要部署下列组件:

负载均衡软件实现与硬件实现方案

该文档是word2003—word2007兼容版 软件、硬件负载均衡部署方案 目录 1、硬件负载均衡之F5部署方案 (2) 1.1网络拓扑结构 (2) 1.2反向代理部署方式 (3) 2软件负载均衡方案 (4) 2.1负载均衡软件实现方式之一- URL重定向方式 (4) 2.2负载均衡软件实现方式之二- 基于DNS (5) 2.3负载均衡软件实现方式之三- LVS (8) 2.4负载均衡软件实现方式之四- 专业负载均衡软件 (16) 总结: (16)

1、硬件负载均衡之F5部署方案 对于所有的对外服务的服务器,均可以在BIG-IP上配置Virtual Server实现负载均衡,同时BIG-IP可持续检查服务器的健康状态,一旦发现故障服务器,则将其从负载均衡组中摘除。 BIG-IP利用虚拟IP地址(VIP由IP地址和TCP/UDP应用的端口组成,它是一个地址)来为用户的一个或多个目标服务器(称为节点:目标服务器的IP地址和TCP/UDP应用的端口组成,它可以是internet的私网地址)提供服务。因此,它能够为大量的基于TCP/IP的网络应用提供服务器负载均衡服务。根据服务类型不同分别定义服务器群组,可以根据不同服务端口将流量导向到相应的服务器。BIG-IP连续地对目标服务器进行L4到L7合理性检查,当用户通过VIP请求目标服务器服务时,BIG-IP根椐目标服务器之间性能和网络健康情况,选择性能最佳的服务器响应用户的请求。如果能够充分利用所有的服务器资源,将所有流量均衡的分配到各个服务器,我们就可以有效地避免“不平衡”现象的发生。 利用UIE+iRules可以将TCP/UDP数据包打开,并搜索其中的特征数据,之后根据搜索到的特征数据作相应的规则处理。因此可以根据用户访问内容的不同将流量导向到相应的服务器,例如:根据用户访问请求的URL将流量导向到相应的服务器。 1.1网络拓扑结构 网络拓扑结构如图所示:

架构设计:负载均衡层设计方案(7)

架构设计:负载均衡层设计方案(7) 1、概述 上篇文章《架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层》 (https://www.wendangku.net/doc/bf10231400.html,/yinwenjie/article/details/47130609) 我们讲解了Nginx的故障切换,并且承诺各位读者会尽快讲解LVS + Keepalived + Nginx的安装和配置。在中间由于工作的原因,我又插写了三篇关于zookeeper的原理使用的文章。今天这边文章我们回归主题,为各位读者讲解LVS + Keepalived + Nginx的安装及配置。 2、安装计划和准备工作 下图,我们表示了本篇文章要搭建的整个集成架构的抽象结构: 我们采用两个LVS节点(141和142),但是一个时间工作的只有一个LVS节点,另一个始终处于热备standby状态,由keepalived监控这两个节点的工作状态并完成切换。 在LVS节点下,我们采用LVS-DR工作模式挂载了两个Nginx节点(131、132)。并最终将外网请求交由这两个节点进行处理。注意:在实际工作中,Nginx下面一般就是访问静态资源、动态资源的配置了。

2-1、准备两个keepalived节点 首先我们在将要安装LVS的两个节点上,先安装keepalived,并保证这两个keepalived节点能够正常工作(监控批次的状态)。当然,您也可以先准备LVS,在准备keepalived。 我想准备keepalived节点,大家应该轻车熟路了吧,在《架构设计:负载均衡层设计方案(6)——Nginx + Keepalived 构建高可用的负载层》这篇文章中详细介绍了keepalived的最简配置方式。为了大家阅读方便,我们在这里再进行依次简要说明。准备keepalived的整个过程包括: 安装必要的支撑组件,源码安装keepalived 将keepalived注册成节点的服务,以便保证keepalived在 节点启动时就开始工作 更改keepalived的配置文件,让其可以正常工作 验证准备工作 =============安装keepalived [root@lvs1 ~]# yum install -y zlib zlib-devel gcc gcc-c++ openssl openssl-devel openssh [root@lvs1 ~]# tar -zxvf keepalived-1.2.17.tar.gz [root@lvs1 ~]# cd keepalived-1.2.17 [root@lvs1 ~]# ./configure --perfix=/usr/keepalived-1.2.17

软件负载均衡优缺点总结

(总结)Nginx/LVS/HAProxy负载均衡软件的优缺点详解 PS:Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件,本人都在多个项目中实施过,参考了一些资料,结合自己的一些使用经验,总结一下。 一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析,如果是中小型的Web应用,比如日PV小于1000万,用Nginx就完全可以了;如果机器不少,可以用DNS轮询,LVS所耗费的机器还是比较多的;大型网站或重要的服务,且服务器比较多时,可以考虑用LVS。一种是通过硬件来进行进行,常见的硬件有比较昂贵的F5和Array等商用的负载均衡器,它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,所以对于规模较小的网络服务来说暂时还没有需要使用;另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件,这些都是通过软件级别来实现,所以费用非常低廉。 目前关于网站架构一般比较合理流行的架构方案:Web前端采用 Nginx/HAProxy+Keepalived作负载均衡器;后端采用MySQL数据库一主多从和读写分离,采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。 下面说说各自的特点和适用场合。 Nginx的优点是: 1、工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构,它的正则规则比HAProxy更为强大和灵活,这也是它目前广泛流行的主要原因之一,Nginx单凭这点可利用的场合就远多于LVS了。 2、Nginx对网络稳定性的依赖非常小,理论上能ping通就就能进行负载功能,这个也是它的优势之一;相反LVS对网络稳定性依赖比较大,这点本人深有体会; 3、Nginx安装和配置比较简单,测试起来比较方便,它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了,LVS对网络依赖比较大。 3、可以承担高负载压力且稳定,在硬件不差的情况下一般能支撑几万次的并发量,负载度比LVS相对小些。 4、Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测。比如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,Nginx会把上传切到另一台服务器重新处理,而LVS就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而不满。 5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件,它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构,在高流量的环境中稳定性也很好。 6、Nginx现在作为Web反向加速缓存越来越成熟了,速度比传统的Squid服务器

负载均衡技术的三种实现方法

目前,网络应用正全面向纵深发展,企业上网和政府上网初见成效。随着网络技术的发展,教育信息网络和远程教学网络等也得到普及,各地都相继建起了教育信息网络,带动了网络应用的发展。 一个面向社会的网站,尤其是金融、电信、教育和零售等方面的网站,每天上网的用户不计其数,并且可能都同时并发访问同一个服务器或同一个文件,这样就很容易产生信息传输阻塞现象;加上Internet线路的质量问题,也容易引起出 现数据堵塞的现象,使得人们不得不花很长时间去访问一个站点,还可能屡次看到某个站点“服务器太忙”,或频繁遭遇系统故障。因此,如何优化信息系统的性能,以提高整个信息系统的处理能力是人们普遍关心的问题。 一、负载均衡技术的引入 信息系统的各个核心部分随着业务量的提高、访问量和数据流量的快速增长,其处理能力和计算强度也相应增大,使得单一设备根本无法承担,必须采用多台服务器协同工作,提高计算机系统的处理能力和计算强度,以满足当前业务量的需求。而如何在完成同样功能的多个网络设备之间实现合理的业务量分配,使之不会出现一台设备过忙、而其他的设备却没有充分发挥处理能力的情况。要解决这一问题,可以采用负载均衡的方法。 负载均衡有两个方面的含义:首先,把大量的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间;其次,单个重负载的运算分担到多台节点设备上做并行处理,每个节点设备处理结束后,将结果汇总,再返回给用户,使得信息系统处理能力可以得到大幅度提高。 对一个网络的负载均衡应用,可以从网络的不同层次入手,具体情况要看对网络瓶颈所在之处的具体情况进行分析。一般来说,企业信息系统的负载均衡大体上都从传输链路聚合、采用更高层网络交换技术和设置服务器集群策略三个角度实现。 二、链路聚合——低成本的解决方案 为了支持与日俱增的高带宽应用,越来越多的PC机使用更加快速的方法连入网络。而网络中的业务量分布是不平衡的,一般表现为网络核心的业务量高,而边缘比较低,关键部门的业务量高,而普通部门低。伴随计算机处理能力的大幅度提高,人们对工作组局域网的处理能力有了更高的要求。当企业内部对高带宽应用需求不断增大时(例如Web访问、文档传输及内部网连接),局域网核心部位的数据接口将产生瓶颈问题,因此延长了客户应用请求的响应时间。并且局域网具有分散特性,网络本身并没有针对服务器的保护措施,一个无意的动作,像不小心踢掉网线的插头,就会让服务器与网络断开。 通常,解决瓶颈问题采用的对策是提高服务器链路的容量,使其满足目前的需求。例如可以由快速以太网升级到千兆以太网。对于大型网络来说,采用网络系统升级技术是一种长远的、有前景的解决方案。然而对于许多企业,当需求还没有大到非得花费大量的金钱和时间进行升级时,使用升级的解决方案就显得有些浪费

相关文档