web集群服务的负载均衡方案选择与实现

web

集群系统,是由一群同时运行同一个web应用的服务器组成的集群系统,在外界看来,就像是一个服务器一样。为了均衡集群服务器的负载,达到优化系统性能的目的,集群服务器将众多的访问请求,分散到系统中的不同节点进行处理。从而实现了更高的有效性和稳定性,而这也正是基于Web的企业应用所必须具备的特性。
  
  高可靠性可以看作为系统的一种冗余设定。对于一个特定的请求,如果所申请的服务器不能进行处理的话,那么其他的服务器能不能对之进行有效的处理呢?对于一个高效的系统,如果一个Web服务器失败的话,其他的服务器可以马上取代它的位置,对所申请的请求进行处理,而且这一过程对用户来说,要尽可能的透明,使用户察觉不到!
  
  稳定性决定了应用程序能否支持不断增长的用户请求数量,它是应用程序自身的一种能力。稳定性是影响系统性能的众多因素的一种有效的测量手段,包括机群系统所能支持的同时访问系统的最大用户数目以及处理一个请求所需要的时间。
  
  在现有众多的均衡服务器负载的方法中,广泛研究并使用的是以下两个方法:
  
  DNS负载平衡的方法RR-DNS(Round-Robin Domain Name System)
  负载均衡器
  以下,我们将就这两种方法进行讨论。
  
  DNS轮流排程 RR-DNS(Round-Robin Domain Name System)
  
  域名服务器(Domain Name Server)中的数据文件将主机名字映射到其IP地址。当你在浏览器中键入一个URL时(例如:www.loadbalancedsite.com),浏览器则将请求发送到DNS,要求其返回相应站点的IP地址,这被称为DNS查询。当浏览器获得该站点的IP地址后,便通过该IP地址连接到所要访问的站点,将页面展现在用户面前。
  
  域名服务器(DNS)通常包含一个单一的IP地址与该IP地址所映射的站点的名称的列表。在我们上面所假象的例子中,www.loadbalancedsite.com 这个站点的映射IP地址为203.24.23.3。
  
  为了利用DNS均衡服务器的负载,对于同一个站点来讲,在DNS服务器中同时拥有几个不同的IP地址。这几个IP地址代表集群中不同的机器,并在逻辑上映射到同一个站点名。通过我们的例子可以更好的理解这一点,www.loadbalancedsite.com将通过下面的三个IP地址发布到一个集群中的三台机器上:
  
  203.34.23.3
  
  203.34.23.4
  
  203.34.23.5
  
  在本例中,DNS服务器中包含下面的映射表:
  
  www.loadbalancedsite.com 203.34.23.3
  
  www.loadbalancedsite.com 203.34.23.4
  
  www.loadbalancedsite.com 203.34.23.5
  
  当第一个请求到达DNS服务器时,返回的是第一台机器的IP地址203.34.23.3;当第二个请求到达时,返回的是第二台机器的IP地址203.34.23.4,以此类推。当第四个请求到达时,第一台机器的IP地址将被再次返回,循环调用。
  
  利用上述的DNS Round Robin技术,对于某一个站点的所有请求将被平均的分配到及群中的机器上。因此,在这种技术中,集群中的所有的节点对于网络来说都是可见的。
  
  DNS 轮流排程的优势
  
   DNS Round Robin的最大的优点就是易于实现和代价低廉:
  
  代价低,易于建立。 为了支持轮流排程,系统管理员只需要在DNS服务器上作一些改动,而且在许多比较新的版本的DNS服务器上已经增加了这种功能。对于Web应用来说,不需要对代码作任何的修改;事实上,Web应用本身并不会意识到负载均衡配置,即使在它面前。
  简单. 不需要网络专家来对之进行设定,或在出现问题时对之进行维护。
  DNS 轮流排程的缺点
  
   这种基于软件的负载均衡方法主要存在两处不足,一是不实时支持服务期间的关联,一是不具有高可靠性。
  
   • 不支持服务器间的一致性。服务器一致性是负载均衡系统所应具备的一种能力,通过它,系统可以根据会话信息是属于服务器端的,还是底层数据库级别的,继而将用户的请求导向相应的服务器。而DNS轮流排程则不具备这种智能化的特性。它是通过cookie、隐藏域、重写URL三种方法中的一种来进行相似的判断的。当用户通过上述基于文本标志的方法与服务器建立连接之后,其所有的后续访问均是连接到同一个服务器上。问题是,服务器的IP是被浏览器暂时存放在缓存中,一旦记录过期,则需要重新建立连接,那么同一个用户的请求很可能被不同的服务器进行处理,则先前的所有会话信息便会丢失。
  
  不支持高可靠性。设想一个具有N个节点的集群。如果其中的一个节点毁坏,那么所有的访问该节点的请求将不会有所回应,这是任何人都不愿意看到的。比较先进的路由器可以通过每隔一定的时间间隔,对节点检查,如果有毁坏的节点,则将之从列表中去除的方法,解决这个问题。但是,由于在Internet上,ISPs将众多的DNS存放在缓存中,以节省访问时间,因此,DNS的更新就会变得非常缓慢,以至于有的用户可能会访问一些已经不存在的站点,或者一些新的站点得不到访问。所以,尽管DNS轮流排程在一定程度上解决了负载均衡问题,但这种状况的改变并不是十分乐观和有效的。
  除了上面介绍的轮流排程方法外,还有三种DNS负载均衡处理分配方法,将这四种方法列出如下:
  
  Ø Round robin (RRS): 将工作平均的分配到服务器(用于实际服务主机性能一致)
  
  Ø Least-connections (LCS): 向较少连接的服务器分配较多的工作(IPVS 表存储了所有的活动的连接。用于实际服务主机性能一致。)
  
  Ø Weighted round robin (WRRS): 向较大容量的服务器分配较多的工作。可以根据负载信息动态的向上或向下调整。 (用于实际服务主机性能不一致时)
  
  Ø Weighted least-connections (WLC): 考虑它们的容量向较少连接的服务器分配较多的工作。容量通过用户指定的砝码来说明,可以根据装载信息动态的向上或向下调整。(用于实际服务主机性能不一致时)
  
  
  
  负载均衡器
  
  负载均衡器通过虚拟IP地址方法,解决了轮流排程所面临的许多问题。使用了负载均衡器集群系统,在外部看来,像是具有一个IP地址的单一服务器一样,当然,这个IP地址是虚拟的,它映射了集群中的每一台机器的地址。所以,在某种程度上,负载均衡器是将整个集群的IP地址报漏给外部网络。
  
  当请求到达负载均衡器时,它会重写该请求的头文件,并将之指定到集群中的机器上。如果某台机器被从集群中移除了,请求不会别发往已经不存在的服务器上,因为所有的机器表面上都具有同一个IP地址,即使集群中的某个节点被移除了,该地址也不会发生变化。而且,internet上缓存的DNS条目也不再是问题了。当返回一个应答时,客户端看到的只是从负载均衡器上所返回的结果。也就是说,客户端操作的对象是负载均衡器,对于其更后端的操作,对客户端来讲,是完全透明的。
  
  负载均衡器的优点
  
   •服务器一致性. 负载均衡器读取客户端发出的每一个请求中所包含的cookies或url解释。基于所读出的这些信息,负载均衡器就可以重写报头并将请求发往集群中合适的节点上,该节点维护着相应客户端请求的会话信息。在HTTP通信中,负载均衡器可以提供服务器一致性,但并不是通过一个安全的途径(例如:HTTPS)来提供这种服务。当消息被加密后(SSL),负载均衡器就不能读出隐藏在其中的会话信息。
  
   • 通过故障恢复机制获得高可靠性. 故障恢复发生在当集群中某个节点不能处理请求,需将请求重新导向到其他节点时。主要有两种故障恢复:
  
  • 请求级故障恢复。当集群中的一个节点不能处理请求时(通常是由于down机),请求被发送到其他节点。当然,在导向到其他节点的同时,保存在原节点上的会话信息将会丢失。
  
  • 透明会话故障恢复。当一个引用失败后,负载均衡器会将之发送到集群中其他的节点上,以完成操作,这一点对用户来说是透明的。由于透明会话故障恢复需要节点具备相应的操作信息,因此为了实现该功能,集群中的所有节点必须具有公共存储区域或通用数据库,存储会话信息数据,以提供每个节点在进行单独进程会话故障恢复时所需要的操作信息。
  
   • 统计计量。既然所有的Web应用请求都必须经过负载均衡系统,那么系统就可以确定活动会话的数量,在任何实例访问中的活动会话的数目,应答的次数,高峰负载次数,以及在高峰期和低谷期的会话的数目,还有其他更多的。所有的这些统计信息都可以被很好的用来调整整个系统的性能。
  
  负载均衡器的缺点
  
   硬件路由的缺点在于费用、复杂性以及单点失败的。由于所有的请求均是通过一个单一的硬件负载均衡器来传递,因此,负载均衡器上的任何故障都将导致整个站点的崩溃。
  
  HTTPS请求的负载均衡
  
   正如上面所提到的,很难在那些来自HTTPS的请求上进行负载均衡和会话信息维护处理。因为,这些请求中的信息已经被加密了。负载均衡器没有能力处理这类请求。不过,这里有两种方法可以解决这一问题:
  
  代理网络服务器
  硬件SSL解码器
   代理服务器位于服务器集群之前,首先由它接受所有的请求并对之进行解密,然后将这些处理后的请求根据头信息重新发往相应的节点上,这种方式不需要硬件上的支持,但会增加代理服务器的额外的负担。
  
   硬件SSL解码器,则是在请求到达负载均衡器之前,先经由它进行解密处理。这种方式比代理服务器的处理速度要快捷一些。但代价也高,而且实现比较复杂。  

时间: 2024-09-17 14:09:04

web集群服务的负载均衡方案选择与实现的相关文章

高可用集群HA及负载均衡集群LB的实现方法

集群是个热门话题,在企业中越来越多地应用Linux操作系统提供邮件.Web.文件存储.数据库等服务,随着Linux应用的日益增长,高可用及http://www.aliyun.com/zixun/aggregation/13996.html">负载均衡Linux集群也在企业中逐步地发展起来.Linux平台的低成本.高性能.高扩展性使得Linux集群能够以低廉的价格很好地满足各种应用的需求. 本文介绍Linux集群的基础知识,集群的分类.在熟悉集群的基础知识后会以RHCS(RedHat Clu

海量图片系统集群分布式存储和负载均衡案例分享

对于Web服务器而言,用户对图片信息的访问是很消耗服务器资源的.当一个网页被浏览时,Web服务器与浏览器建立连接,每个连接表示一个并发.当页面包含多个图片时,Web服务器与浏览器会产生多个连接,同时发送文字和图片以提高浏览速度.因此,页面中图片越多Web服务器受到的压力也就越大. 一般小型网站是把所有页面和图片统一存放在一个主目录下,这样的网站对系统架构.性能要求都很简单.下面是原理图 一些稍有规模的网站都保存有大量图片资源.用户在访问这些站点网页时,网页中图片信息占到页面数据流量的大部分.由于

服务器集群中的负载均衡技术深入讲解

&http://www.aliyun.com/zixun/aggregation/37954.html">nbsp;   由于目前现有网络的各个核心部分随着业务量的提高,访问量和数据流量的快速增长,其处理能力和计算强度也相应地增大,使得单一的服务器设备根本无法承担.在此情况下,如果扔掉现有设备去做大量的硬件升级,这样将造成现有资源的浪费,而且如果再面临下一次业务量的提升时,这又将导致再一次硬件升级的高额成本投入,甚至性能再卓越的设备也不能满足当前业务量增长的需求.  针对此情况而衍

“Tomcat集群” ,“Tomcat负载均衡”,“Apache整合Tomcat” 这三个是一个意思吗?

问题描述 如果不是,他们有什么区别?在网上搜过,感觉说的是一回事.谁能说说,最好通俗一点? 解决方案 集群的本质是为了增强应用的容错性. 负载均衡则是提高应用的负载性能.当然集群跟负载均衡可以同时使用.apache整合tomcat可以分离静态文件跟动态文件的处理.同时apache具有负载均衡的能力.所以如果做负载均衡.可以选用apache+tomcat,当然也有别的选择.不一定非apache不可

Web应用服务器集群系统分散负载解决方法

&http://www.aliyun.com/zixun/aggregation/37954.html">nbsp;   Web应用服务器集群系统,是由一群同时运行同一个web应用的服务器组成的集群系统,在外界看来,就像是一个服务器一样.为了均衡集群服务器的负载,达到优化系统性能的目的,集群服务器将众多的访问请求,分散到系统中的不同节点进行处理.从而实现了更高的有效性和稳定性,而这也正是基于Web的企业应用所必须具备的特性. 一.计算WEB服务器负载量的两种方法 web应用服务器集

高性能linux web集群搭建详细步骤 可达每秒百万请求

本文教程比较详细,可以说是手把手,所以如果你有这个需求而无从下手,请放点耐心阅读 如何生成每秒百万级别的 HTTP 请求? 负载生成工具(Load-Generating Tools) 在进行负责测试时要牢记一件重要的事:你能在 Linux 上建立多少个 socket 连接.这个限制是硬编码在内核里的,最典型的就是临时 W 端口的限制.(在某种程度上)你可以在 /etc/sysctl.conf 里扩展它.但是基本上,一台 Linux 机器只能同时打开大约 64,000 个 socket .因此在负

Redis集群Proxy支持select命令方案介绍

目前Redis集群开源的方案主要有Redis Cluster,Codis,Twemproxy等,这几个方案里面都不支持select命令,即用户无法使用select进行逻辑db的切换,这样会给之前使用Redis单机的用户带来一定困扰,导致很多用户在迁移到集群方案的时候需要改造代码,本文探讨Redis集群支持select命令的方案实现. 阿里云Redis集群 阿里云的redis集群版由3大组件构成: redis-config : 集群管理工具 redis-server : 优化过源码的redis,支

DockOne微信分享(一零三):Kubernetes 有状态集群服务部署与管理

本文讲的是DockOne微信分享(一零三):Kubernetes 有状态集群服务部署与管理[编者的话]本次分享将深入介绍Kubernetes如何满足有状态集群服务对容器编排系统提出的新需求,包括如何使用Kubernetes的动态存储请求与分配机制来实现服务状态的持久化存储,以及与高效部署和运行有状态集群服务相关的Kubernetes新特性,如Init Container.PetSet (StatefulSet)等.最后通过一个MySQL集群实例详解在Kubernetes中如何轻松部署一个高可用的

web集群怎么共享同步session(memcache)

在做了web集群后,你肯定会首先考虑session同步问题,因为通过负载均衡后,同一个IP访问同一个页面会被分配到不同的服务器上,如果session不同步的话,一个登录用户,一会是登录状态,一会又不是登录状态.所以本文就根据这种情况给出三种不同的方法来解决这个问题: 一,利用数据库同步session 在做多服务器session同步时我没有用这种方法,如果非要用这种方法的话,我想过二种方法: 1,用一个低端电脑建个数据库专门存放web服务器的session,或者,把这个专门的数据库建在文件服务器上