• 负载均衡


    “负载均衡”:是什么?为什么?怎么做?

    负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

    负载均衡(Load Balance)其意思就是分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。

    负载均衡是高可用网络基础架构的的一个关键组成部分,有了负载均衡,我们通常可以将我们的应用服务器部署多台,然后通过负载均衡将用户的请求分发到不同的服务器用来提高网站、应用、数据库或其他服务的性能以及可靠性。

    为什么要引入负载均衡?
    这是一个没有负载均衡机制的web架构: 

     

    上图中的架构有什么缺陷了?首先,用户是通过网络直接和web服务器相连,想象一下,如果这个服务器挂了(这种情况随时都可能发生的),那么用户的请求就会得不到响应,将无法访问该网站,这就是著名的单点故障问题,这肯定是不行的,一般而言,商业上的网站其可靠性需要达到至少4个9,也就是99.99&以上。

    其次,即使服务器是正常工作的情况,但是如果很多用户在同一时间内访问服务器,超过了服务器的处理能力,那么会出现响应速度慢甚至无法连接的情况,这也是用户无法接受的。

    负载均衡的出现可以很好的解决上面两个问题,通过引入一个负载均衡器和至少两个web 服务器,可以有效的解决上面两个问题。注:通常情况下,所有的后端服务器会保证提供相同的内容,以便用户无论哪个服务器响应,都能收到一致的内容。

     

    如上图架构,现在,即使App 01即使挂了,负载均衡会将用户的请求转发到正常工作的App 02上,这解决了上面的第一个问题;其次,根据业务需要,负载均衡后端的App可以很方便的扩展,这样就能解决第上面的第二个问题。但是,现在单点故障问题转移到了负载均衡器,可以通过引入第二个负载均衡器来缓解,后面还会讲到。

    负载均衡如何选择要转发的后端服务器
    负载均衡器一般根据两个因素来决定要将请求转发到哪个服务器。

    1:确保所选择的后端服务器是正常工作的,能给对用户的请求做出响应;

    2:根据预先设置的负载均衡算法从健康服务器池中进行选择。

    由于负载均衡器只应当选择能正常做出响应的后端服务器,因此就需要有一种机制能判断它所连的后端服务器是否正常工作。为了监视后台服务器的运行状况,运行状态检查服务会定期尝试使用转发规则定义的协议和端口去连接后端服务器。如果某个服务器没有通过健康检查,就会从健康池中剔除,保证流量不会被转发到该服务器,直到其再次通过健康检查为止。

    负载均衡算法

    负载均衡算法决定了后端的哪些健康服务器会被选中。下面是几个常用的算法:

    轮询:为第一个请求选择健康池中的第一个后端服务器,然后按顺序往后依次选择,直到最后一个,然后循环。

    最小连接:优先选择连接数最少,也就是压力最小的后端服务器,在会话较长的情况下可以考虑采取这种方式。

    散列:根据请求源的 IP 的散列(hash)来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器,可以考虑采取这种方式。

    最后,想要解决负载均衡器的单点故障问题,可以将第二个负载均衡器连接到第一个上,从而形成一个集群。如下图所示:

     

    当主负载均衡器发生了故障,就需要将用户请求转到第二个负载均衡器。由于 DNS 更改通常会在较长的时间才能生效,因此需要有一种能灵活解决 IP 地址重新映射的方法,比如浮动 IP(floating IP)。这样域名可以保持和相同的 IP 相关联,而 IP 本身则能在服务器之间移动。下面就是一个使用浮动 IP 的负载均衡架构动态示意图: 

    主要应用
    编辑

    1.DNS负载均衡最早的负载均衡技术是通过DNS来实现的,在DNS中为多个地址配置同一个名字,因而查询这个名字的客户机将得到其中一个地址,从而使得不同的客户访问不同的服务器,达到负载均衡的目的。DNS负载均衡是一种简单而有效的方法,但是它不能区分服务器的差异,也不能反映服务器的当前运行状态。

    2.代理服务器负载均衡 使用代理服务器,可以将请求转发给内部的服务器,使用这种加速模式显然可以提升静态网页的访问速度。然而,也可以考虑这样一种技术,使用代理服务器将请求均匀转发给多台服务器,从而达到负载均衡的目的。

    3.地址转换网关负载均衡 支持负载均衡的地址转换网关,可以将一个外部IP地址映射为多个内部IP地址,对每次TCP连接请求动态使用其中一个内部地址,达到负载均衡的目的。 [1] 

    4.协议内部支持负载均衡除了这三种负载均衡方式之外,有的协议内部支持与负载均衡相关的功能,例如HTTP协议中的重定向能力等,HTTP运行于TCP连接的最高层。

    5.NAT负载均衡NAT(Network Address Translation网络地址转换)简单地说就是将一个IP地址转换为另一个IP地址,一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址间进行转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。

    6.反向代理负载均衡普通代理方式是代理内部网络用户访问internet上服务器的连接请求,客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理,从而达到负载均衡的目的。

    7.混合型负载均衡在有些大型网络,由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异,可以考虑给每个服务器群采用最合适的负载均衡方式,然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务(即把这多个服务器群当做一个新的服务器群),从而达到最佳的性能。将这种方式称之为混合型负载均衡。此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。


    解决方案
    编辑

    负载均衡在银行中的解决方案

    业务连续性与高可用性从来都是企业的生命线。我们很难想象,当一个银行的信息系统中断那怕是一个小时,将会造成怎样的严重后果。据权威统计,经历突发性重大灾害后的公司有将近43%倒闭,而另外51% 也在两年之内陆续关门。要保证关键业务7x24不中断,应对激烈的市场竞争和提高客户满意度,企业必须在IT系统围绕“连续”主题进行构建,实施业务连续/容灾备份计划,包括业务连续性、高可用性管理、容灾、数据保护和恢复案、安全等。

    正是基于以上考虑,某银行数据中心采用了服务器负载均衡高可用性解决方案,该银行实现了多数据中心链接和高负载高流量的网络应用目标,确保了该银行数据中心的稳定的业务处理能力。


    客户需求
    某银行成立于1992年,是国有控股的全国性股份制商业银行,为国内第一家有国际金融组织参股的银行,具有雄厚的资金实力,特点鲜明的股权结构,完善的经营管理体制,布局合理的机构网络,该银行已在全国23个省、自治区、直辖市的36个经济中心城市拥有分支机构300多家,成为对社会有一定影响的全国性股份制商业银行。与此同时,该银行也积极利用信息化手段,来提高自身的竞争力和客户满意度。

    就该银行而言,要确保银行数据中心高流量负载和高可用性,全面部署高可用性的服务器负载均衡解决方案,要求如下:在正常情况下两台或多台服务器的负载基本相同,在某台服务器停机的情况下透明的容错,保证关键服务的持续。ISP接入链路的容灾:在每个数据中心采用不同的ISP接入链路, 保证在ISP故障的情况下系统的正常运行, 而在正常的情况下实现负载均衡, 提高链路利用率。多数据中心的协同工作:为配合未来在业务量增加的情况下, 在某分中心的协同工作,特别是不同地理位置的用户的就近性访问的考虑, 以提高服务品质, 增加用户访问的满意度。


    方案优势
    针对某银行的需求现状和未来需求趋势,考虑到该银行数据中心的后台是通过中间件为基础架构搭建起来,服务器负载均衡设备机, 并以服务器直接返回模式(DSR)将负载均衡设备接入网络,对每一层的应用服务器进行负载均衡。该方案具有以下优势:

    1、 DSR模式为独有负载均衡工作模式,是专门针对如金融行业这种对高并发连接数有严格要求的行业开发的模式。

    2、简单快速的网络搭建, 实现网络拓扑零改动。

    负载均衡机是提供本地服务器群负载均衡和容错的产品,在充分利用现有资源以及对IT基础设施进行最小变动的前提下有效地进行流量的分配,从而提高服务器的处理性能。对客户端而言,这一切都是透明的。

    两台服务器负载均衡机做为一组, 对应用服务器提供负载均衡服务, 并且互为备份,采用“心跳”技术实时监控伙伴设备的同时, 也实现了负载均衡设备的负载均衡。能够避免SPOF和单点瓶颈的问题, 最大限度地发挥负载均衡的能力。

    采用负载均衡系列产品处理多ISP的多网段IP地址的情况, 由该产品全权处理有关DNS解析和多数据中心的多ISP接入链路问题。开启该产品的健康检查功能, 检查两个或多个数据中心的服务状况, 以确保用户的正常访问。DNS服务器分别接在接入路由器上,负责用户的DNS访问请求。引导用户使用最快的链路进行访问站点。同时,负载均衡机负责检查线路的健康状态,一旦检测到线路的中断,则停止相应线路的地址解析。

    IPTV系统
    编辑

    华灯初上的时候,打开电视机,点播一个你爱看的电影,电影顷刻间就开演了!你可否想过,和你一样点播电视节目的有千家万户,为什么每家每户想看的节目都能及时送到眼前呢?这是怎么做到的呢?

    在电视上点播节目是一种IPTV业务,被点播的电影、电视剧等节目我们称为内容。向众多用户提供内容是由一个专门的网络完成的,这个网络我们叫它内容分发网络(CDN),我们将这个分发网络上负责给电视传送内容的服务器叫做CDN节点(CDN node)。

    在网络建设之初、IPTV用户还较少的时候,这个网络并不庞大,可能一台设备就能轻松处理完全部用户的要求。然而随着业务的发展,用户量和业务量与日俱增,一台设备已经招架不住了。这时我们就需要给这台设备找些帮手。于是我们为这台设备“克隆”一些兄弟,然后将用户的要求分摊给所有兄弟,大家一起共同面对。对于这个网络来说,大家要完成的任务即是负载,如此多队员的合作以及团队运作,即是负载均衡。

    从单兵作战到团队作战

    大家合作,处理业务的能力是够了,但是任务来了后究竟由谁来处理呢?队员们会不会都不知道应该做什么?会不会都抢着做而打起来?因此必须要有一个领队(CDN Manager)来管理他们,指挥他们谁应该做什么、要达到什么样的目的。在向各队员发出指示之前,领队需要首先统一接收任务,然后分析并分解任务、挑选合适的队员(CDN node)来执行任务,再将任务安排下去由合适的队员具体来执行。由此可见,领队可下了一番功夫的呢!在领队的合理安排下,队员们都有条不紊地执行任务,不会出现有的太闲而有的过忙的现象,“CDN团队”融洽高效地完成了任务。

    那么领队如何决定把某个任务或子任务分给哪个队员呢?领队的决定可不是随意做出的,而是相当谨慎且科学的。原来啊,领队是依据一些策略来做出决定的。这些策略包括用户的网络地址、用户的分组、先到先得规则等。

    根据这些策略,领队可以把一个大任务分解成多个子任务,让每个队员执行其中一个小任务,大家完成后由领队汇总,达到完成大任务的目的,这样这个任务就会执行得很快;领队也可以把一批任务中的每一个任务分散到每个队员去分头执行,由队员直接完成这些任务,这样这批任务也会执行得很快。大规模的CDN网络通常是一级一级、一层一层的,我们叫它分布式网络,相邻的层级之间形成依赖和备份关系。而你点播的节目最终通常由最靠近你的CDN节点送达你的电视机,这就是为什么节目总是那么及时地开演。当最靠近你的CDN节点出现故障或者服务能力无法提供服务时,领队能够根据依赖和备份策略选取其他合适的节点提供服务。

    从均衡所覆盖的范围角度,负载均衡又分全局负载均衡和本地负载均衡。

    全局负载均衡和本地负载均衡是两个相对的概念。前者关注的是一个网络的整体,是对放在不同位置、为完成同一个任务的设备群体做负载均衡,是宏观上的;后者关注的是网络个体,是对一个地理位置上的设备群做负载均衡或者对某一个设备内部的具有相同功能的多个模块做负载均衡,是微观的。

    IPTV系统中的本地负载均衡特指某个节点内部的负载均衡,即当某个节点内部存在多个提供相同功能的单板时,会有至少一个管理单板担任该本地负载均衡的领队,带领这个小团队完成上级下发的任务。

    全局负载均衡分布式架构(网络规模大)

    大规模网络中,局部的本地负载均衡

    说到这里,大家应该明白了,负载均衡就是团队运作。为了一个共同的团队目标,位于不同位置上“队员”们在领队的统一调度下,协同工作,将大的任务相对平均地分担起来,把任务完成的更快、更好!在整个网络这个大范围内的负载均衡是全局负载均衡,局部的小范围内的负载均衡是本地负载均衡。
    ————————————————
    原文链接:https://blog.csdn.net/weixin_39758376/java/article/details/90454316

  • 相关阅读:
    让你彻底明白什么叫游戏引擎(1)
    今后几年将有多于28部游戏电影面世
    Symbian系统体系结构
    让你彻底明白什么叫游戏引擎(2)
    网易程序笔试题
    [转贴]暴雪的霸王条款是否合理?
    CPU GPU设计工作原理《转》
    求伯君:向暴雪学习 金山不求一夜暴富
    我的职业规划
    网络游戏程序员新手入门 [转]
  • 原文地址:https://www.cnblogs.com/liugrwit/p/12900049.html
Copyright © 2020-2023  润新知