精华内容
下载资源
问答
  • 企业、高校、运营商等多链路负载均衡的问题,属于老生常谈的问题,山石网科从10多年前在二级运营商打开局面,作为高吞吐、高并发、高用户数量的广域网接入设备时,就开始尝试解决多链路负载均衡的问题。 经过十多年...

    一、写在前面

    企业、高校、运营商等多链路负载均衡的问题,属于老生常谈的问题,山石网科从10多年前在二级运营商打开局面,作为高吞吐、高并发、高用户数量的广域网接入设备时,就开始尝试解决多链路负载均衡的问题。

    经过十多年的持续迭代和市场考验,山石网科的NGFW受到了市场广泛认可,取得了一定的成绩。即便如此,我们在最近的一些实践中,仍然发现我们的系统有优化的空间,对于有些场景和需求有更好的技术方案;于是我们在原有的基础上持续优化迭代,取得了一些阶段性的成果,特和大家进行分享。

    本文中所有的内容均基于山石网科应用交付(ADC)产品(以下简称应用交付或者ADC)进行讨论,所有功能均已发布并投放市场。山石网科ADC发布于2017年末,但它并非从零开始构建,它和山石网科NGFW一样,基于山石网科多核并行分布式操作系统StoneOS进行构建。除了继承StoneOS核心软件构架、大量的网络功能以及应对高并发、高吞吐的多场景适应性之外,更重要的是继承了StoneOS的稳定性和近15年的市场考验。

    二、场景描述

    下图是多链路负载均衡的一个简化、抽象的拓扑,并不代表某一个行业或者客户,绝大部分场景的拓扑比下图中复杂。另外,为了简化拓扑,下图中并没有涉及HA(高可靠,High Availability)。本文着重讨论多广域网链路的流量调度,下图的拓扑虽然与真实拓扑有一些差异,但是兼具关键组件,不影响本文的讨论。下图中一些关键的元素:

    • 运营商:ISP1、ISP2、ISP3代表三个不同的运营商。其中有三条链路接入到ISP1,两条链路接入到ISP2,一条链路接入到ISP1。实际中,用户的接入运营商数量可能比三个多,也可能少;每个运营商的链路数量也可以不同。不管有几个运营商接入,最少有两条或者两条以上的链路接入到Internet。

    • 接入设备:本文中使用应用交付(ADC)产品作为Internet的接入设备,进行多广域网链路的流量调度。

    • 办公区:主要包含一些访问终端,可能有PC、SIP电话、移动终端等,Internet流量主要是这些区域的终端产生的。

    • 业务区:这里重点讨论与本文相关的DNS服务。多链路流量调度与DNS流量有着非常密切的关系(后文中会讨论)。一般的,在出口的DNS流量不会太多,但由于DNS负责将域名翻译为IP地址,也即在绝大部分的业务流量产生时,都会伴随DNS流量。合理地调度DNS查询流量,对整体的流量调度效果有着非常重大的意义。

    实际中的,有的客户没有自己的DNS服务器,靠外部的运营商DNS或者公共DNS(例如电信DNS、阿里DNS等)来进行DNS解析,此时几乎所有的DNS查询都会经过Internet出口。有的客户有自己的DNS服务器,此时办公区的DNS查询中大部分会送到业务区的DNS服务器(本地DNS)进行查询,当本地DNS有权威记录或者缓存有效时,则直接返回结果,否则本地DNS进行递归或转发查询,最终从权威服务器获取到结果,并将其返回给客户端;这种情况客户端的DNS查询不经过Internet出口,本地DNS服务器到公共DNS服务器的迭代查询或者转发查询会过Internet出口。当然,即便有本地DNS服务器时,也存在一些客户端也会不使用,而使用外部DNS服务器进行查询,这种情况与没有本地DNS服务器是一样的。

    图片

    三、需求分析及方案

    多链路负载均衡场景的需求比较清晰,本文就出站方向(访问Internet),围绕作者在实践过程中遇到的基本需求衍生需求展开讨论,并针对性的给出山石网科ADC的解决方案。

    01 基本需求

    (1)多链路接入及链路连通性探测

    链路联通性探测是非常基本和常规需求,也即判断某一个Internet链路是否可以正常接入Internet,当不能正常接入Internet时(例如上游设备Down掉,运营商故障等),则不应该将流量调度到该链路上。

    如何判断一个ISP链路是否可以使用,有很多种方法,例如接口状态、下一跳是否可达、远端的某个IP是否可以通过该链路可达、远端的某个服务是否可以通过该链路访问,或者通过上述方式进行加权组合最终决定链路是否可用。

    链路连通性探测的问题,业界主流厂商均能很好的解决,本文不做赘述。

    图片

    (2)减少跨运营商的访问

    跨运营商访问的问题也很明确,由于多运营商的互联互通的问题,导致跨运营商访问相对较高的延时,甚至有些访问会不通。当然,近年来随着运营商的持续优化,跨运营商访问不能互通的问题很少发生,但是体验仍然不如在运营商内部的体验好。因此避免或者减少跨运营商的访问也是在多链路场景的一个刚性需求。

    很多网站通过CDN发布自己的服务,而这些CDN遍布各个运营商或者自己构建的的各个数据中心。如下图中,www.hillstonenet.com.cn有三个IP地址,IP1属于ISP1,IP2属于ISP2,IP3属于ISP3。则当某个终端访问访问IP1时,流量调度到ISP1上一般会体验更好。

    图片

    对于负载均衡设备来讲,解决跨运营商访问的问题的核心点在于有足够丰富和准确的运营商IP信息库。山石网科ADC采用合作的方式,使用被市场广泛证明的信息库。在流量调度过程中,根据目的IP地址所属的运营商,选择合适的运营商链路集合(一个运营商可能有多条链路),并在该链路集合中再使用均衡算法进行流量调度,进而减少跨运营商访问。山石网科ADC上内置IPv4/IPv6的运营商信息库,并保持持续在线更新。

    实际中,跨运营商的访问可以减少到很少的比例,但是难以完全避免,主要有如下原因:

    1)访问的网站并不一定有所有运营商的接入方式。例如某一个网站只有教育网接入,而客户却没有教育网接入。

    2)少量IP地址没有被IP信息库覆盖到。

    3)某个运营商的所有接入链路都满负荷了,新的访问即便目的地还是该运营商,也不能再往该运营商的链路上进行调度。

    (3)基于AppID的调度

    AppID(Application Identification,应用识别)是在10多年前被提出的NGFW的核心组件之一,也是NGFW区别于传统防火墙的核心差异之一,其背后的逻辑是“端口不等于应用”,进而推导出“基于端口的安全不等于基于应用的安全”;除此之外,AppID配合流量可视化后,用户体验大幅提升。进而AppID的理念被业界广泛接受,今天已经变成了一个非常基本的组件。

    图片

    在那个用户接入处在2Mbps ADSL和二级运营占有大量接入份额的年代,广域网带宽不够,迅雷、BT、电驴、uTorrent流行,占据了大量的企业和运营商带宽,影响了Web浏览、企业电话会议等关键业务体验,给企业、高校、二级运营商造成了很大的困扰。基于AppID的流量调度、流控、安全控制大大缓解了这些问题,提高了客户的重要业务的访问体验。

    回到今天,随着互联网基础设施的大幅投入,Internet接入虽然显著提升,P2P软件的使用相对10多年前有显著下降,但是Internet带宽永远都无法满足应用的需要,企业、高校和运营商对AppID的流量调度和管控仍然是刚性需求。

    山石网科是国内最早实现基于AppID的流量调度和管控,并大规模部署的厂商之一;并凭借该功能在二级运营商和高校互联网出口占据绝对优势。经过十多年的迭代,当前山石网科StoneOS已经支持近5000个AppID,覆盖桌面应用、移动互联网应用、IOT应用等各个操作系统的常用应用,并保持高频率的更新和高准确率。山石网科ADC也自然地继承了这些技能。

    (4)基于域名的流量调度

    业界方案

    基于域名的流量调度理解起来很简单,即某些网站的访问需要调度到特定的链路。这个需求主要来自于企业、政府和高校。业界中主要有如下几种方案,下面分别对这些方案进行展开说明:

    1)方案一:将域名翻译为IP地址

    原理:这个方案理解起来很简单,在配置流量调度策略时,将域名翻译为IP地址进行策略下发;并周期性的对域名进行解析,有变化时更新调度策略,实现起来比较简单。

    下图是一个网关设备的实现示意图:当对访问www.hillstonenet.com.cn的流量配置调度策略时,数据平面像DNS模块注册(订阅)某一个域名到IP地址的映射关系;当DNS模块向外部的DNS服务器解析到IP地址或者IP地址发生变更时,将变更内容通知给数据平面。

    图片

    这个方案的缺陷比较大,主要表现为如下:

    缺陷一:很多网站通过CDN发布,或者有多个运营商接入,有很多个IP地址,客户端解析出来的IP地址很大概率和网关解析出来的IP地址不一致,导致下发策略不准确,最后导致对部分客户端的访问无法基于域名进行流量调度

    缺陷二:由于网关解析出来的IP经常变更,会导致频繁更新调度策略,重新构建系统的调度策略表对系统开销较大;如果某些场景还需要做会话重匹配(Session Rematch)时,则可能对系统是一个灾难性的后果,大大加剧系统瞬时负载,严重时可能由于系统负载过高而会影响正常的流量转发。

    2)方案二:配合嗅探DNS流量将域名翻译为IP地址

    原理:这个方案是上述方案一的基础上的演进,部分解决方案一的缺陷。此方案不通过DNS模块去解析域名,而是通过嗅探经过网关设备的DNS查询应答报文,将域名翻译为IP地址。

    下图中是一个DNS A记录查询的应答报文,通过解析经过设备的DNS应答,能够将域名和IP建立映射关系。

    图片

    这个方案在些场景基本可以解决网关设备和客户端对域名翻译为IP不一致的问题,但是此方案也有一定的缺陷:

    缺陷一:有些场景有多个广域网接入网关,有的客户端的DNS请求根本就不经过该网关,因此无法获取到客户端的DNS流量,进而无法进行翻译。

    缺陷二:实际中存在一个域名对应非常多的IP地址的情况,很多大型网站能解析出几十个或者上百个IP地址是很常见的;这就要求网关能够将这些域名对应的所有IP都记录下来,当目标网站较多时,则对系统的内存开销比会较大;当域名过多时,可能会导致由于容量不足导致的无法正确翻译的问题。

    缺陷三:最关键的,仍然存在方案一的缺陷二,每当这个域名对应的IP地址变更(增加、减少),都需要重新下发和构建调度策略表。

    3)方案三:将域名定义为AppID

    原理:这个方案通过利用应用识别功能,将域名定义为一个新的AppID,然后通过基于AppID来进行流量调度变相解决基于域名的流量调度。

    下图中是通过HTTPS访问www.hillstonenet.com.cn的TLS协商中的Client Hello,通过TLS SNI(Server Name Indication)扩展可以获取到访问的域名,可以通过这个信息做AppID的识别;HTTP的访问也类似,只是从请求头中获取相应的字段,这里不做举例。

    图片

    这个方案相对方案一和方案二有显著的优势,但是在实践中最大的问题是实施会比较麻烦:

    局限一:如果系统不支持自定义应用,需要发布新的AppID库来支持。这种方案基本行不通,由于客户需要进行流量调度的网站千差万别,不可能将所有的需求都加到公共的AppID库中;即便可以,交付一个新版本的AppID库需要动用研发资源,需要一天或者数天来交付,交付成本非常高。

    局限二:如果系统能够支持自定义应用,由于自定义应用通常需要了解AppID引擎的语法,属于比较专业的技能,对于实施工程师和客户都是难以掌握的,用户体验也会不太好,难以大面积推广。

    局限三:即便克服了局限二,由于网关设备对于TCP的流量,基本的做法都是在TCP SYN报文时建立会话,而建立会话时则需要确定出接口和下一跳,也即已经确定了该TCP连接如何调度。然而,TCP SYN报文的时候没有任何载荷信息,也即没有域名信息,无法基于内容进行识别;而只能使用目的IP和端口根据历史识别信息进行调度。进而当首次访问这个网站时,没有历史识别信息,无法识别该TCP连接的AppID,无法做出准确的调度。

    当然,此方案的局限三不是一个特别严重的问题,通过牺牲首次访问,来通过目的IP/端口来记录AppID,对后续的访问做识别,还是一个相对不错的方案,实践中主要的困难还是来自于上述的局限一和局限二。

    山石网科ADC的方案

    说了这么多业界方案的缺陷或者局限,那山石网科ADC有什么更好的方案呢。首先,作者认为山石网科ADC的方案也并非完美的解决方案,但是此方案应该大幅优于前面的方案。

    当前,随着移动互联网的高速发展,互联网流量由桌面端流量向移动端流量完成了大幅的迁移,而HTTP(HTTPS)协议也由一个应用层协议逐渐变为一个事实上的传输层协议。也就是说,非常多的应用是基于HTTP/HTTPS进行开发,而HTTP/HTTPS协议在大量的场景占据了超过50%的流量,下文中把这些基于HTTP/HTTPS的流量简称为Web流量。

    基于上述的事实,既然Web流量占据了如此大的比例,而作者遇到的绝大部分的基于域名的流量调度需求也是针对Web流量。因此,山石网科ADC选择回归到需求的本质,既然是基于域名的流量调度,那么是否可能在看到域名信息之后再进行流量调度呢?

    图片

    上图是网关设备转发一个HTTPS请求的流程,大致有如下几个步骤:

    1)客户端发送SYN报文到www.hillstonenet.com.cn, 目的端口443

    2)网关收到SYN报文后,如果没有查找到会话,走新建会话(慢路)流程,查找各种表项,根据五元组信息进行流量调度,查找到下一跳,将该SYN报文转发到下一跳;最终送达服务器。

    3)服务器回应SYN/ACK,网关命中会话,转发给客户端。

    4)客户端发送ACK,TCP三次握手完成。

    5)TLS协商、加密数据传输…

    这个做法在收到SYN报文时就进行了流量调度,看不到足够的信息。如果对上述的流程进行修改,如下图:

    图片

    如上图所示,山石网科ADC通过修改常规的会话新建流程,并不在收到SYN报文时进行流量调度。对于HTTPS的流量,看到Client Hello之后,就能看到TLS扩展中的SNI(Server Name Indication),进而知道访问的域名,这样可以更加自然的进行基于域名的流量调度。

    对于HTTP的Web流量,其处理的原理和HTTPS类似;只不过HTTP的流量需要通过请求中的Host字段获取到域名信息,而HTTPS的流量通过TLS Client Hello中的扩展选项SNI的Server Name字段获取到域名信息,如下:

    HTTP流量:

    图片

    HTTPS流量:

    图片

    这个方案的难点在于要打破网关设备的常规新建会话(慢路)流程,亮点也在于此。这个方案经过实践检验,对于Web流量的基于域名的流量调度,比此前的方案明显更加自然和实用。当然,它的不完美主要体现在对于非Web流量,没有改善,仍然需要通过前面提到的AppID的方案来解决。

    (5)流控

    前面提到,山石网科早在10多年前以AppID + Qos进入到高校和二级运营商市场,能支持几十到十万量级客户端接入的流控。经过10多年的迭代,功能已经非常成熟,在这里不再详述。

    (6)会话保持

    会话保持的目的是针对一些多通道的应用,让客户端发起的多通道连接选择同样一个公网源IP与服务器建立连接。互联网上最常见的应用是游戏(为什么不提FTP,因为FTP/SIP/H323等这种常规的多通道应用,通过应用层网关(ALG)已经解决,不需要配合会话保持功能)。这些应用在与服务器建立连接时,会使用多个通道进行连接,但是应用要求多个通道的源IP必须相同,否则可能无法连通。通过会话保持保证一个客户端在一段时间内选择同一个链路,同时配合SNAT规则上的粘性来选择同样一个公网IP作为源IP,最终达到多通道选择同一个公网源IP的目的。

    会话保持会优先于调度策略,也就是说一般情况下,匹配了会话保持表项之后,会先按照会话保持表中的内容选择下一跳的信息。

    图片

    和业界主流厂商一样,山石网科ADC也支持多种会话保持方式,但实际中最常用的还是源 + 目的IP。

    (7)链路备份

    图片

    如上图中,ISP1的三条链路为最优质的链路,ISP2的链路为次优质链路,而ISP3的链路最差。而大部分情况下,ISP1的链路就足够日常使用了,ISP2和ISP3的链路可以作为备份链路,当ISP1的链路都可用时,ISP2和ISP3的链路不使用,当ISP1中有链路不可使用时再使用ISP2的链路,如果继续有链路不可用,再使用ISP3的链路。

    山石网科ADC可以通过设置链路优先级,结合最小活跃链路来实现上述需求,举例如说明:

    • ISP1三条链路优先级为10

    • ISP2两条链路优先级为20

    • ISP3一条链路优先级为30

    优先级数值越小,优先级越高例如希望一般情况下使用ISP1的三条链路,其它作为备份链路,则可以配置最小活跃链路数量为3,则效果如下:

    • 当ISP1的三条链路都可用时,全部使用ISP1的链路进行调度

    • 当ISP1中有一条链路不可用后,此时活跃链路数量只有2个,不满足最小活跃链路为3的需求,系统会触发ISP2的两条优先级相同的链路同时变为可用;此时便可以有4条链路变为活跃状态。

    如果ISP1中有两条链路不可用,ISP2中有一条不可用,此时ISP1和ISP2共只有两条链路可用,则会使用ISP1、ISP2、ISP3各一条链路。

    通过调整各条链路的优先级和最小活跃链路数量,可以灵活实现链路备份的需求。当然,当高优先级链路恢复可用之后,仍然会先使用高优先级链路。

    (8)链路繁忙保护

    链路繁忙保护是为了由于某种原因(例如超大流、流量波动较大等)的情况下,如果严格按照调度算法调度时,则会恶化链路,最终导致体验不佳的问题。举几个常见的例子:

    例一:例如有同一个运营商的两条链路,称之为链路一、链路二;这两条链路同样带宽,同样质量,这两条链路之间使用轮询算法调度流量。当没有会话保持时,新建的会话依次在链路一、链路二上调度。但是如果某一段时间链路一上有几条会话的流量特别大,虽然链路一和链路二上新建会话的速率几乎一样,但是由于链路一上有些流的流量特别大,导致链路一带宽利用率非常高,链路二却还闲置不少。此时如果还严格按照轮询调度,则会导调度到链路一上的访问体验非常不好。

    例二:在备份链路的场景中,当所有的活跃链路都很满之后,如果仍然按照调度算法往这些链路上调度,则会导致高优先级链路非常繁忙,而低优先级链路闲置不用,最终网络体验不好。

    通过配置链路的繁忙保护,可以有效避免某些链路使用率很高,而还有闲置链路的情况;当链路的利用率超过一个阈值之后,新的连接将不会往繁忙链路上调度,直至降到某阈值之下。

    (9)基于时间表的流量调度策略

    也即在不同时间段采取不同的流量调度策略,比较容易理解,也是比较基本的功能,这里就不多做阐述了。

    (10)高速日志

    会话日志也是网关位置一个比较基本溯源需求,会话日志的特点是量大,从每秒几十到每秒上几十万量级,甚至更高。

    对于每秒十万量级的日志,基本很难在网关设备内部解决,一方面存储受限,另外一方面系统也不可能分配那么多的CPU算力用来处理日志。所以这种情况通常通过Syslog发送到外部专门的日志服务器处理。下图中:

    • 左侧左侧是比较常规的做法,数据平面的会话日志通过内部通道送给日志模块进行存储,或者由日志模块再通过Syslog协议外送到外部的日志服务器。由于数据平面通常是高速并行处理系统,会产生大量的会话日志。如果都送给日志模块统一处理,那么很明显系统的瓶颈就会在日志模块。要么日志模块无法正常服务,要么就丢日志。

    • 右侧:右侧的方案在数据平面产生日志后,直接发给外部的日志服务器。由于数据平面是高速并行系统,直接将日志在数据平面发送到外部大大提高了日志发送的效率,其瓶颈是数据平面自己的性能瓶颈,不再有集中瓶颈点。当然,外部的日志服务器如果性能不足,也需要采用集群或者其它方式处理高速日志。

    图片

    山石网科ADC同时支持上述左侧和右侧两种方式,可以通过配置来切换:

    • 对于低速日志场景,使用左侧方案足以,可以省去外部的Syslog服务器。

    • 对于高速日志场景,需要使用右侧方案。对于右侧方案,可以通过Syslog协议封装文本日志发送给通用的Syslog服务器;同时,也可以通过二进制的方式发送给山石网科HSA专业日志系统,可以处理更高速的日志。

    (11)均衡算法

    均衡算法是多链路负载均衡的核心功能之一,山石网科ADC支持非常丰富的负载均衡算法,包括目的IP哈希、源IP哈希、加权源IP哈希、源IP端口哈希、ISP算法、最小带宽、加权最小带宽、最小连接数、轮询、加权轮询、动态就近等均衡算法。上述的大部分均衡算法从字面都比较容易理解,下面主要就山石网科ADC比较有特色的一些算法进行描述。

    1)ISP均衡算法

    基于ISP的调度,在前面的部分也有过描述,下面主要就ISP调度的一些问题进行讨论:

    问题一:前面已经讲过,ISP信息主要是通过使用目的IP在ISP信息库中进行查询;那么自然存在某些IP在ISP中无法查找到结果的情况。

    问题二:当确定好ISP之后,这个ISP里面有多条链路时,又该如何在该ISP中进行均衡呢。

    山石网科ADC通过引入备选均衡算法和次选均衡算法来解决上述的问题。备选算法表示当无法找查找到某个IP的ISP信息后,使用的均衡算法;次选均衡算法表示当确定ISP之后,但是这个ISP里有许多条链路时所使用的均衡算法。如下图:

    图片

    2)最小带宽算法

    最小带宽是实际中比较常用的算法,可以用于首选均衡算法,也常见于使用ISP做首选均衡算法,使用最小带宽均衡算法作为备选算法和次选均衡算法。

    最小带宽字面意义很容易理解,就是将新建连接调度到流量(实时带宽)最小的链路上,但是工程实现时,它有如下几个问题:

    问题一:如何度量实时带宽。通常的做法是统计单位时间内的总流量,再用总流量除以单位时间,从而计算出实时带宽。当单位时间太短时,比较容易出现两个单位时间的带宽差异较大,表现为带宽统计不够平滑;进一步的做法会使用几个单位时间作为滑动窗口,每次使用最近的若干个单位时间来计算这段时间内的平均带宽。

    工程中,单位时间取1秒比较常见;如果使用滑动窗口的思路,可以以1秒进行总流量作为统计单位,以最近的若干个单位(例如5个单位,即5秒)计算平均带宽,这样会显得速率比较平滑。

    不管采取上述的哪一种做法,统计出来的带宽都属于过去发生的事情,用过去一个周期的带宽去选择最小带宽的链路会造成什么问题呢?举例说明就清楚了:

    • 链路一:上一周期的带宽为50Mbps

    • 链路二:上一周期的带宽为55Mbps

    • 链路三:上一周期的带宽为48Mbps

    那么在新的一个周期里,由于上一个周期链路三的流量最小,所以新的一个周期所有流量都会调度到链路三,下一个周期也许会调度到另外一个链路上,如此往复。

    很明显,这个方案最大的问题是带宽在新的度量周期内不会变更,进而导致在一个固定的周期内流量永远往一个链路上进行调度。当周期过大时,会导致流量波动很大,各个链路此起彼伏。那是否能将周期设定很小呢,前面说过,工程上很多选择1秒为度量周期;周期过小例如毫秒级时,一方面软件时钟不容易保证毫秒级的精度,另外一方面周期越短度量越容易波动,再有就是频繁的计算也对会增加计算资源开销。

    问题二:调度算法其实只是流量调度中比较靠后的一环,可以认为是默认的调度策略;在调度算法前面还有会话保持、或者更优先级的调度策略,尤其是会话保持几乎都是必配项。当新的会话匹配了会话保持表之后,就不会经过调度算法进行调度,也即无法通过调度算法来调节均衡效果。

    针对上述的问题,山石网科ADC借助Qos的思路,采用新的带宽度量方式。该方案能够做到在每次进行调度时,获取实时的最小带宽的链路;同时,这种方法能够将会话保持和者前置的调度规则的调度结果综合考虑进去,做到更准确的调度。

    另外,一般的企业、高校接入,运营商提供的上下行链路带宽一般是一致的。但是大部分的场景,两个方向的实际流量往往不一致,一般都是下行流量大于上行流量,此时如果以上下行的总流量来进行度量,也是不合适的。对于最小带宽均衡算法,可以配置带宽度量的方向,实际部署时如果客户的下行流量远大于上行流量,则应该选择以下行流量进行带宽度量,反之选择上行流量进行度量,或者其它情况下需要选择上下行流量之和进行度量。

    3)加权最小带宽

    在了解最小带宽之后,加权最小带宽也就容易理解。当多条链路的链路带宽不一致时,通过权重来描述。例如链路一的链路带宽为50Mbps,链路二的链路带宽为100Mbps,那么二者的权重设置为1:2的比例即可。

    4)轮询/加权轮询

    轮询算法是最简单,最容易理解的算法,加权轮询在轮询的基础上只是增加了权重,这里不进行讨论。

    轮询算法最大的特点是,经过其调度的会话,能够将新建会话数量绝对均衡地调度到每一个链路上。然而实际中,由于会话保持表的存在,大量的会话命中了会话保持表,不经过均衡算法来调度,最终导致无法达到轮询的预期效果。

    针对这个问题,山石网科ADC通过配置“综合考虑其它调度结果”的方式,将会话保持以及其它高优先级调度策略调度的结果也参与到轮询调度的算法计算中,最终实现更加接近轮询的理论调度均衡结果。

    (12)DNS流量调度

    在Internet出口,一般情况下DNS的流量占比一般比较小。但是在需要基于ISP做调度的场景,DNS流量的合理调度就显得非常重要。

    前面提到,ISP信息是通过目的IP从ISP信息库中查找到的,那目的IP是如何得到的呢,是通过DNS服务把域名进行翻译出来的。

    现在稍微有规模的网站,就会有很多个IP地址,这些IP地址遍布在各个地区的各个数据中心,这些数据中心也会有很多运营商的接入。既然DNS服务负责从域名到IP地址的翻译,而让DNS服务器返回一个合适的IP地址,就会影响到业务流量的调度了。

    图片

    如上图中,产生DNS流量的主要有两个:

    内部DNS服务器产生的流量:大部分的企业、高校都有自己的DNS服务器,负责内部的域名解析。其一方面作为内部域名的权威服务器,负责内部的域名的解析;另外一方面对于外部域名的DNS查询,该DNS服务器会进行迭代查询或者转发到外部的DNS服务器进行查询。

    一般情况下,由于企业/高校等使用DHCP,大部分的终端都会使用内部的DNS服务器进行域名翻译,但是也不排除一部分终端自己直接指定外部的公共DNS服务器做地址翻译

    对于上述的任意一种到Internet的DNS查询,对出口的设备都是一次调度的机会。虽然DNS流量并不多,但是后续的业务与这个DNS查询是相关联的。举例说明:

    1)客户端A指定某一个公共DNS作为自己的DNS服务器,在访问www.hillstonenet.com.cn时,先发送一个DNS A记录查询到公共DNS。

    2)例如应用交付将这个DNS查询从ISP1的链路送出去之后,该DNS报文的源IP被转换为ISP1链路上的某一个IP,称之为ISP1-IP1。

    3)公共DNS服务器收到DNS查询,源IP为ISP1-IP1。如果公共DNS发现这个域名查询有有效的DNS缓存记录,尽可能选取一个与ISP1相同运营商IP地址返回;如果没有有效缓存,则使用一个ISP1的IP地址作为源IP进行迭代查询,例如ISP1-IP2,经过迭代查询之后,最终送到权威服务器。

    4)权威服务器收到ISP1-IP2的DNS查询,此时权威服务器一般也会智能的(尽可能)返回一个ISP1的IP给公共DNS,例如ISP1-IP3作为查询结果。

    5)公共DNS将ISP1-IP3作为www.hillstonenet.com.cn的查询结果返回给ISP1-IP1,最终转发给客户端。

    6)客户端通过HTTPS向ISP1-IP3发起请求。

    7)应用交付使用ISP调度策略,查询出该请求目的IP(ISP1-ISP3)是属于ISP1,调度到ISP1的链路上,如ISP1有多个可用链路,再使用次选均衡算法进行调度到ISP1的某一条链路上。

    上述的过程是一个常规的过程,并不绝对,各个环节都依赖于公共DNS和权威DNS是智能DNS(目前的主流的公共DNS都会使用智能的调度)。从上述的过程中,可以看到在第6)步中,HTTPS业务和前面的DNS查询之间有一些关联。而应用交付可以利用这些关联性,针对DNS流量做出合理的调度,最终可以达到合理调度业务流量的目的。举例说明,例如可以针对DNS流量使用最小带宽或者加权最小带宽进行调度,这样DNS查询就会选择使用流量小的链路转发DNS查询报文,而外部DNS服务器一般也会优先返回相同ISP的IP地址作为应答,进而后续的业务流量再根据ISP进行调度时,就选择了流量比较小的链路,进而实现了对业务流量的调度。

    下图是DNS查询的基本流程,上文中所说的公共DNS就是下图中的Local DNS。

    图片

    (13)实际部署

    上面基于单个的需求讨论了很多,实际部署过程中,由于多链路负载均衡涉及到多方面的技术,包括基于ISP的调度、基于AppID的调度、基于域名的调度、会话保持、均衡算法、DNS流量的调度以及流控。其涉及到的技术面和功能点比较多,对实施人员的要求也比较高。实际中比较容易遇到满足了ISP的调度、AppID调度、域名调度这种高优先级的调度之后,实际的均衡效果不好的问题。这里给出一些常规的部署注意事项:

    1)正确配置广域网链路属性。包括上下行带宽,WAN接口属性,链路带宽在流控、链路繁忙保护会使用;正确配置广域网链路所属的ISP,基于ISP的调度需要使用;正确配置广域网链路权重,这个在一些加权算法,例如加权最小带宽、加权轮询等会使用;配置链路繁忙保护阈值,例如80%或者90%,这个需要根据实际的状态进行调整。

    2)如果需要做备份链路,合理配置广域网链路的优先级和最小活跃链路数

    3)按需配置基于AppID的调度策略和基于域名的调度策略,如果需要基于AppID进行流量调度,需要开启应用识别

    4)针对DNS流量配置合适的调度算法

    5)针对其它流量按需配置首选调度算法、次选调度算法、备用调度算法和会话保持算法

    其中的第1)步属于广域网链路的属性配置,这些属性在不同的调度算法、流控中会使用;第3)步和保持算法可以理解为高优先级调度策略,比均衡算法更高优先级;其中第4)步对DNS流量的调度往往容易被忽略,但是实际对均衡效果影响较大;第5)步是对其它流量的调度,绝大部分的流量应该是在这一步调度。

    实施完之后,可以通过可视化来观察流量调度效果,再根据实际的效果进行微调。

    02 衍生需求

    在很多多链路负载的项目实践中,除了上述的一些常见的需求之外;还遇到一些衍生需求,在这里也进行一些分享。

    (1)SSL解密及流量镜像

    随着互联网基础设施的越来越完善,网络安全被提到越来越重要的位置,Web流量也大量的向HTTPS进行迁移;邮件协议也越来越多的向加密迁移。

    在早期NGFW、IPS、DLP上一些基于内容检测的应用层安全的功能,对于加密的流量变得不再适用。解决这个问题的最直接的方式是在合适的位置,解开加密流量,这样就可以利用企业原本构建的安全体系。

    随着企业在安全上越来越多的投入,大家也意识到安全问题不是单一安全设备能够解决的,通常都需要各种安全设备协同配合,加上安全管理和安全运营,逐步提高企业的安全能力。

    对于这么多安全设备,如果每个设备都需要串接在网络中,对加密流量进行解密后进行安全检测,然后再加密。且不说是不是每个安全设备有这个能力,即便都有这个能力,那串接这么多设备做解密后加密,一定会大幅增加网络延时,降低网络体验。

    山石网科ADC可以将流量进行解密后,将明文的流量镜像出去,给其它网络安全设备。如下图中,山石网科ADC作为SSL代理,可以将HTTPS/POPS/IMAPS/POPS的流量进行解密(需要客户端安装证书),并将流量镜像到企业构建好的安全设施上进行安全检测:

    图片

    对于镜像流量,山石网科ADC有如下特点:

    1)支持将一份流量解密后,可以将明文流量复制送到多个接受端

    2)除了支持将流量镜像到直连设备之外,还可以通过IPSec/GRE隧道封装,跨二、三层网络将流量送给远端的设备。实际中GRE由于封装简单,比较常用。 

    3)由于可以支持通过隧道封装进行流量镜像,因此也可以在虚拟网络进行流量镜像。

    当然,这个方案由于ADC设备充当SSL中间人,需要在客户端安装证书,部署场景比较受限。常见于有强管控需求的企业或者政府;高校由于人员众多,接入比较复杂,管理也比较复杂,大规模部署难度较大。

    HSCP(山石网科安全协作协议)

    上面的内容提到,山石网科ADC可以将流量解密之后送给多个安全设备进行安全检测,那安全设备发现威胁之后,是否能够及时阻断呢?一般对于旁路设备的阻断有几种常见的做法:

    1)对于TCP的流量,旁路部署的设备发送RST报文,尝试断开连接。这个方法优点是比较直接,发送端和接受端开销小;缺点是有可能TCP序列号对不上导致,RST被客户端和服务器端丢弃;另外这个方案只能断开当前连接,而不能做更丰富的操作。

    2)旁路设备调用Restful API或者类似的方式给串联设备发送指令。这个方式好处是比较灵活,能够支持多样化的功能。缺点是开销太大,例如Restful API时,接受方需要经过驱动 -> TCP协议栈 -> 控制平面 -> 数据平面,整个过程下来,开销非常大,延时也会比较大,数据平面收到指令时攻击可能已经完成了;另外有的安全设备检测平面没有完善的TCP协议栈,或者调用系统的TCP协议栈又大大影响了数据平面的性能。这种方式难以处理高速的联动

    在上述背景下,山石网科ADC推出了HSCP(山石网科安全协作协议),这个协议就是为了山石网科ADC与其它安全设备之间进行联动协作。安全设备发现威胁后按需给ADC下发指令来关闭连接、阻断IP、阻断服务等安全策略。HSCP有如下特点:

    1)高速:对于发送端,其成本与发送RST类似,延时在微妙级别。接收端直接在数据平面进行处理,不需经过要TCP协议栈和控制平面。每秒处理可以几万到几十万个协作指令。

    2)简单:无状态、无协商,接受和发送方对等,不需要控制平面记录状态和协商,易集成、易扩展。

    3)安全:加密、防重放、防篡改。

    4)多对多:每个HSCP端点都可以若干个对端进行交互联动。

    下图中是一种典型场景,当ADC将明文流量送到安全检测设备,安全检测设备发现威胁之后,可以通过HCSP下发指令让ADC断开连接、阻断IP、阻断服务等操作。

    图片

    (2)正向代理

    ADC产品,部署于服务器集群前面时,常使用反向代理,那什么情况下有正向代理的需求呢?实际中遇到的情况主要是将某些特定域名的流量调度到某些特定的ISP上,但是出口网关设备不具备这个能力或者不能很好的完成,而替换出口网关又是比较复杂的事情。对于这种情况,新增加一个山石网科ADC,也可以较好的解决。这个场景多见于高校。

    如下图,应用交付单臂部署在交换机上,对主要的业务不影响。具体方案如下,下面举例对www.hillstonenet.com.cn流量的调度:

    1)第一步,准备好ADC上的代理IP池,例如IP1 ~ IP16共16个IP。在高校内部的DNS服务器上将www.hillstonenet.com.cn解析为上述的某一个IP。这里说明一下为什么采用代理IP池,而不是单个IP。主要的原因是主流的浏览器会限制到一个目的IP的并发连接数,例如基于Chromium的浏览器(Chrome、Edge)是6个。当将很多二级域名都解析到一个代理IP上之后,对这些域名的访问的目的IP都是一个,当页面内容特别丰富,里面有许多二级域名时,会导致由于只有6个并发连接而减低页面打开速度。正常不使用这种方案时,由于许多二级域名的IP地址不尽相同,打开网站后,浏览器会向很多个IP发起连接,这样其实有许多个HTTP请求同时进行。

    2)第二步,在ADC上配置对HTTP和HTTPS的代理虚拟服务器,HTTP和HTTPS的代理原理不一样,需要建立不同的代理服务器。这里简要说明一下,ADC通过HTTP服务器中的Host字段解析最终的目的IP,而HTTPS则使用TLS的SNI(Server Name Indication)扩展中的Server Name解析最终的目的IP。

    3)第三步,在出口针对ADC发出的流量(源IP)进行策略路由,这个就可以解决出口网关不支持基于域名调度流量的问题。

    这个方案需要DNS服务器、ADC和出口网关配合协作完成,虽然看上去有点复杂,不过逻辑比较清楚,清楚原理之后也比较容易实施。

    完成上述的配置之后,举例一个终端访问www.hillstonenet.com.cn的过程。

    1)第一步:客户端向内部的服务器发起www.hillstonenet.com.cn的A记录查询,DNS服务器返回IP5。

    2)第二步:客户端发起HTTPS的访问,目的IP是IP5,也就是ADC设备。

    3)第三步:这里面其实分为两步,ADC先解析SNI(Server Name Indication)中的Server Name,得到www.hillstonenet.com.cn,并向Internet上的公共DNS发起A记录查询,获取到www.hillstonenet.com.cn真正的IP地址Public-IP1;而后ADC向Public-IP1发起HTTPS连接,使用IP1 ~ IP16中的一个IP作为源IP,后续ADC设备在客户端和Public-IP1之间做为代理。整个过程中,ADC并不参与SSL协商,所以也不需要证书。

    4)第四步:出口设备匹配策略路由,将源IP为IP1 ~ IP16的流量调度合适的出接口。

    图片

    局限:实践中,这个方案也有一些局限。主要源于浏览器的连接复用机制,当打开新的页面时,浏览器会先尝试从已经建好的TCP连接池中查找,看看是否可以使用的已经建好的连接,通常需要满足如下几个条件:

    1)已经建好的连接和要建立的连接目的IP和端口一样,且Scheme(HTTP/HTTPS)一样。

    2)对HTTPS的访问,已经建好的TCP连接中的SSL证书可覆盖新访问的网站。

    3)已经建好的连接是空闲。

    当上述的条件满足之后,浏览器就会选取已经建好的的TCP连接使用,而不是重新建立一个TCP连接。

    当对诸如*.hillstonenet.com.cn这种通配符域名进行代理时,其中有两个域名www.hillstonenet.com.cn和doc.hillstonenet.com.cn两个域名,其使用的证书一样,对外IP地址不一样。当使用上述的代理机制时,由于DNS可能会对www和doc两个网站返回同一个IP地址。当浏览器已经打开了www网站,再打开doc网站时,当满足了上述的连接复用条件之后,对doc.hillstonenet.com的访问就会送到www.hillstonenet.com上,最后导致错误的访问。

    对于这个局限,需要将相同机构的不同精确域名通过DNS服务器解析到不同的IP上,不适合做通配符域名的代理,实际部署时需要注意。对于上述的例子,需要将www.hillstonenet.com.cn和doc.hillstonenet.com.cn解析到不同的代理IP,这样这两个网站就不会满足浏览器连接复用的要求,可以解决上述的问题。

    四、总结

    多链路负载均衡虽然是一个日常常见的场景,但是由于其涉及到许多的知识和技术点,涉及到路由、应用识别、TCP/IP协议以及DNS/HTTP/HTTPS等应用层协议,还有流控、各种调度算法、会话保持方法等概念和技术。工程上的实现,各个供应商也会有所差异,各有所长。

    写本文的目的,一方面希望更多的技术人员能够了解多链路负载均衡中的一些概念和相关技术,另外也想把过去的一些经验和心得分享给大家,希望读者能有所收获。

    最后,受限于作者经验、见识和理解能力,难免有些表述不够准确或者片面,还希望各位读者多多包涵、不吝赐教,谢谢!

    展开全文
  • LinkProof―实现多链路负载均衡和防火墙负载均衡(raw)[参照].pdf
  • 出口链路负载均衡技术出口链路负载均衡技术出口链路负载均衡技术出口链路负载均衡技术
  • 多链路上网负载均衡解决方案.pdf
  • 一台三层交换机做双链路负载均衡(20210906110707).pdf
  • 1. 服务器负载均衡 服务器负载均衡是将客户端请求在集群中的服务器上实现均衡分发的技术。按照位于七层网络协议栈的不同层的划分,服务器负载均衡可以分为四层(L4)负载均衡和七层(L7)负载均衡两种。 1)L4负载均衡是...

    1. 服务器负载均衡

    服务器负载均衡是将客户端请求在集群中的服务器上实现均衡分发的技术。按照位于七层网络协议栈的不同层的划分,服务器负载均衡可以分为四层(L4)负载均衡和七层(L7)负载均衡两种。
    1)L4负载均衡是基于流的服务器负载均衡,能够对报文进行逐流分发,即将同一条流的报文分发给同一台服务器
    2)L7负载均衡是基于内容的服务器负载均衡,能够对七层报文内容进行深度解析,并根据其中的关键字进行逐包转发,按照既定策略将连接导向指定的服务器。
    两者相比较,L4负载均衡因无法对七层业务实现按内容分发,限制了它的适用范围,因此L7负载均衡受到了业界的极大重视并日渐成为服务器负载均衡的主流。

    1.1 四层负载均衡

    L4负载均衡的实现主要有NAT(NAT,Network Address Translation)方式和DR(Direct Routing)方式两种类型,它们适用于不同的应用场景。

    (1)网络地址转换

    网络地址转换(NAT,Network Address Translation)属于广域网接入技术,它是一种将私有(保留)地址转化为合法IP地址的转换技术,被广泛应用于各种类型互联网接入方式和各种类型的网络中。

    采用NAT方式实现的L4服务器负载均衡,后端服务器可以位于不同的物理位置和不同的局域网内。负载均衡设备在分发服务请求时,需要进行虚拟IP地址和目的IP地址转换,再通过路由将报文转发给具有相应目的地址的服务器。NAT方式L4负载均衡的典型组网如图所示。

    NAT方式L负载均衡的典型组网

    主要组件包括如下几项:
    ◇ 负载均衡设备:负责将客户端服务请求分发到服务器集群中的具体服务器进行处理。
    ◇ 真实服务器:负责响应和处理各种客户端服务请求的服务器,多台服务器构成集群。
    ◇ 虚拟IP地址:集群对外提供的公网IP地址供客户端请求服务时使用。
    ◇ 服务器IP地址:服务器的IP地址供负载均衡设备分发服务请求时使用。这个IP地址可以是公网IP,也可以是私网IP。

    NAT方式L4服务器负载均衡的工作原理如图4-7所示。
     NAT方式L4负载均衡的工作流程

    工作流程是这样的:

    • (1)负载均衡设备负责接收客户端发送至虚拟IP地址的服务请求。
    • (2)负载均衡设备通过服务器可用性验证、会话持续性保证等对负载均衡算法进行调度,选择出负责响应和处理该请求的真实服务器。
    • (3)负载均衡设备用真实服务器的IP地址改写请求报文的目标地址,再将请求发送给选定的真实服务器。
    • (4)真实服务器的响应报文首先通过负载均衡设备。
    • (5)负载均衡设备将响应报文的源地址修改为虚拟lP地址,再返回给客户端。

    这种方法使用了网络地址转换(NAT)技术实现L4负载均衡,它具有组网灵活,适用于多种组网类型的特征。该方法对服务器没有额外的要求,不需要修改服务器的配置。

    (2)DR(Direct Routing)

    DR(Direct Routing)是另一种L4服务器负载均衡的实现方式。与NAT方式的L4负载均衡不同,DR方式只有客户端发出的服务请求报文需要通过负载均衡设备,而服务器发出的响应报文则无须通过,这样能够有效减少负载均衡设备的负载压力,避免负载均衡设备成为系统性能瓶颈。

    DR方式下,负载均衡设备在分发服务器请求时,不采用改变请求目的IP地址的方法,而是将报文的目的MAC地址替换为服务器的MAC地址,然后直接将报文转发给服务器。
    DR方式L4负载均衡的典型组网

    从图中可以看出,DR方式L4服务器负载均衡的实现方案与NAT方式类似,区别是负载均衡设备是以旁挂形式与交换机相连接的,而且集群中每台处理用户请求的服务器都拥有单独的虚拟IP地址

    DR方式L4负载均衡的原理是为负载均衡设备和真实服务器同时配置虚拟IP地址,但是要求真实服务嚣的虚拟IP地址不能响应ARP请求,例如在环回接口上配置虚拟IP地址。用于响应服务请求的服务器上除了虚拟IP地址,还需要配置一个真实的IP地址用于和负载均衡设备通信。负载均衡设备要和真实服务器同处于一个二层网络内。因为服务器的虚拟IP地址不能响应ARP请求,所以从客户端发送给虚拟IP地址的报文将由负载均衡设备接收,负载均衡设备再将其分发给相应的真实服务器,而从真实服务嚣发送给客户端的响应报文则直接由交换机返回。
    DR方式L4负载均衡的工作流程

    这种方法没有采用传统的通过查找路由表的转发方式来分发请求报文,而是通过修改目的MAC直接路由给服务器,DR方式也就因此而得名。该方法只要求客户端到服务器的单方向请求报文经过负载均衡设备,负载均衡设备负担较小,不易成为瓶颈,具有更高的处理性能。

    1.2 七层负载均衡

    L4服务器负载均衡在截取数据流以后,对数据包的检查和分析仅局限于IP报文头部和TCP/UDP报文头部,而并不关心TCP/UDP数据包的有效载荷信息。而L7服务器负载均衡则要求负载均衡设备除了支持基于四层的负载均衡以外,还要解析数据包中四层以上的信息,即应用层的信息,例如解析HTTP内容,从而在数据包中提取出HTTP URL或者Cookie信息,用来作为负载均衡的依据。

    L7服务器负载均衡通过内容分析控制应用层服务分发,提供了一种高层的访问流量控制方式,与此前传统的L4负载均衡相比,L7负载均衡具有如下优点:

    (1)能够根据数据包内容(例如判断数据包是图像文件、压缩文件或者多媒体文件等)把数据流量引向能够处理相应内容的服务器,提高系统可管理性和灵活性。
    (2)能够根据连接请求的数据类型(例如根据URL判定用户发来的请求是和普通文本、图像等静态文档相关,还是和ASP、CGI等动态文档相关),把其引向相应的服务器处理,在提高系统性能的同时有助于改善安全性。
    (3)能够根据应用层载荷保证会话持续性,相对于L4服务器负载均衡采用的基于地址的持续性保证方式更加精细。

    L7负载均衡的典型组网

    L7服务器负载均衡与NAT方式L4服务器负载均衡在实现上非常类似,其主要区别是增加了服务组的概念。服务组是一个逻辑概念,是指依据一些公共属性将多台服务器划分为不同的组。例如:可以将服务器划分为静态资料存储服务器组和动态交换服务器组,或者划分为音乐服务器组、视频服务器组和图片服务器组等,根据应用层属性划分的服务器组内部各台服务器更容易有相近的性能和特性。

    L7负载均衡的工作流程
    (1)客户端与位于服务器集群前端的负载均衡设备之间建立TCP连接。
    (2)客户端将发送到虚拟IP地址的服务请求发送给负载均衡设备,负载均衡设备接收客户端请求。
    (3)负载均衡设备通过服务器可用性验证、会话持续性保证、服务组匹配策略、负载均衡算法调度等步骤,选择出负责响应和处理该请求的真实服务器。
    (4)负载均衡设备利用客户端地址与真实服务器建立TCP连接。
    (5)负载均衡设备将客户端请求报文的目的地址重写为真实服务嚣的IP地址,并将该请求发送给相应的服务器。
    (6)真实服务器向负载均衡设备响应服务。
    (7)报文在通过负载均衡设备时,源地址被还原为虚拟IP地址,再返回给客户端。

    L7服务器负载均衡在负载均衡过程中能够对应用层协议进行深度识别,带来了很多更精细化均衡的可能,但它也对系统性能提出了非常高的要求,通常需要采用专用芯片以硬件电路的方式实现。同时,它需要针对每种应用层协议都配备相应的独立的识别机制,这极大地限制了L7服务器负载均衡的应用扩展性。由于HTTP协议应用广泛且协议相对简单,所以当前L7负载均衡技术对HTTP请求进行负载均衡的商用能力最强。

    在实际应用中,L4负载均衡和L7负载均衡往往是搭配使用的,当然最好是在同一台负载均衡设备上兼具四层和七层功能。负载均衡设备首先从报文中提取IP地址和端口,进行四层负载均衡,如果发现确有必要进行进一步的基于报文内容的转发,再实施七层负载均衡操作。

    2. 链路负载均衡

    链路负载均衡是指通过动态算法在多条网络链路中进行负载均衡

    链路负载均衡根据业务流量的方向可以分为Outhound链路负载均衡Inbound链路负载均衡两种情况。
    (1)Outbound链路负载均衡主要解决的是企业内部业务系统访问外部互联网服务时如何在多条不同的链路中动态分配和负载均衡的问题;
    (2)Inbound链路负载均衡主要解决的是位于互联网外部的用户如何在访同企业内部网站和业务系统时动态地在多条链路上平衡分配,并在一条链路中断时能够智能地自动切换到另一条可用链路。

    链路负载均衡与服务器负载均衡之间的主要区别是承担负载的对象不同,单就负载均衡设备而言,其关键技术、部署方式等内容都具有类似之处。其中,在负载均衡调度算法方面,链路负载均衡有一些特有算法,例如就近链路选择算法、基于链路带宽的调度算法等。特别是就近链路选择算法,能够在链路负载均衡过程中,实时探测链路的状态,井根据探测结果选择最优链路,保证流量通过最优链路转发。就近链路选择算法对链路状态的探测可以通过链路健康性检测实现,例如通过发送DNS报文和ICMP报文、建立TCP半开连接等方法在验证链路可达性的同时获得相关的就近链路计算参数。在实现中,就近链路计算参数主要包括:链路物理带宽、链路成本(例如链路月租)、链路延迟时间、路由跳数等。就近链路选择算法也可以根据这些参数进行加权计算,然后根据计算结果判断链路的优劣。

    2.1 Outbound链路负载均衡

    当内网和外网之间存在多条链路时,Outbound链路负载均衡可以实现在多条链路上分担内网用户访问外网服务器流量的功能,其典型组网如图所示。
    0utbaund链路负载均衡的典型组网

    (1)负载均衡设备:负责将内网到外网的流量在多条物理链路上分发。
    (2)物理链路:网络服务器提供商(ISP)提供的实际通信链路。
    (3)虚拟IP地址:负载均衡设备对外提供的虚拟IP地址,用做用户发送报文的目的地址。

    Outbound链路负载均衡的原理是将负载均衡设备的虚拟IP址作为内网用户发送报文的目的地址用户在将访问虚拟IP地址的报文发送给负载均衡设备后,负载均衡设备通过链路选择算法选择出最佳的物理链路,并将内网访问外网的业务流量分发到该链路上。
    0utbaund链路负载均衡的工作流程
    Outbound链路负载均衡的技术特点包括如下几项。
    (1)通过结合NAT技术进行组网,不周链路使用不同源IP地址,从而能够保证往返报文均经由同一条链路。
    (2)通过健康性检测,可以检测链路上任意节点的连通性,从而有效地保证整条路径的可达性。
    (3)通过负载均衡调度算法的调度,可以在多条链路间均衡流量,例如利用基于带宽的算法优化带宽利用、利用就近链路选择算法选择最优链路。

    2.2 Inbound链路负载均衡

    Inbound链路负载均衡的主要作用是在多条链路上均衡调度外网用户访问企业内部网站和业务系统时的流量,并在一条链路中断时能够智能地自动切换到另一条可用链路。
    在这里插入图片描述
    如图所示,Inbound链路负载均衡的实现方案虽然与Outbound链路负载均衡在很多方面具有相似性,但是因为针对的是不同传输方向上的业务流量,因此部分功能有如下几点区别:
    (1)负载均衡设备:负责引导外网流量通过不同的物理链路转发到内网,实现流量在多条物理链路上的分发。同时,负载均衡设备还需要作为待解析域名的权威名称服务器
    (2)物理链路:网络服务器提供商(ISP)提供的实际通信链路。
    (3)本地DNS服务器:负责处理本地用户发送的DNS解析请求,将该请求转发给作为权威名称服务器的负载均衡设备。

    Inbound链路负载均衡的原理是将负载均衡设备作为权威名称服务器,用于记录域名与内网服务器IP地址之间的映射关系(即域名的A记录)
    补充:一个域名会被映射为多个IP地址,每个IP地址则对应一条物理链路。当外网用户通过域名方式访问内网服务器时,本地DNS服务器依照递归原则会向负载均衡设备请求域名解析,负载均衡设备通过就近链路选择算法筛选、ISP选择等步骤,选择出最佳的物理链路,并将通过该链路与外网连接的接口IP址作为DNS域名解析结果反馈给外网用户。相应的工作流程如图所示。

     Inbound链路负载均衡的工作流程

    Inbound链路负载均衡通过和服务器负载均衡相配合,可以同时实现多条链路间的均衡和多台服务器间的均衡。另一种应用方式是通过动态的链路选择算法,最终实现以链路最优为基础的服务嚣负载均衡。

    展开全文
  • NULL 博文链接:https://fantastic361.iteye.com/blog/738626
  • 负载均衡

    万次阅读 多人点赞 2018-05-28 10:08:23
    流量负载均衡介绍1 负载均衡产生的...负载均衡技术具有一下优势:(1)高性能:负载均衡技术将业务较均衡的分担到台设备或路上,从而提高了整个系统的性能;(2)可扩展性:负载均衡技术可以方便的增加集群中设...

    流量负载均衡介绍

    1 负载均衡产生的背景

    LB(Load Balance,负载均衡)是一种集群技术,它将特定的业务(网络服务、网络流量等)分担给多台网络设备(包括服务器、防火墙等)或多条链路,从而提高了业务处理能力,保证了业务的高可靠性。

    负载均衡技术具有一下优势:

    (1)高性能:负载均衡技术将业务较均衡的分担到多台设备或链路上,从而提高了整个系统的性能;

    (2)可扩展性:负载均衡技术可以方便的增加集群中设备或链路的数量,在不降低业务质量的前提下满足不断增长的业务需求;

    (3)高可靠性:单个甚至多个设备或链路法神故障也不会导致业务中断,提高了整个系统的可靠性;

    (4)可管理性:大量的管理共组都集中在使用负载均衡技术的设备上,设备集群或链路集群只需要维护通过的配置即可;

    (5)透明性:对用户而言,集群等于一个或多个高可靠性、高性能的设备或链路,用户感知不到,也不关心具体的网络结构,增加或减少设备或链路数量都不会影响正常的业务。

    负载均衡技术分类:

    (1)             服务器负载均衡:在数据中心等组网环境中,可以采用服务器负载均衡,将网络服务分担给多台服务器进行处理,提高数据中心的业务处理能力;

    (2)             链路负载均衡:在有多个运营商出接口的组网环境中,可以采用出方向多链路动态负载均衡,实现链路的动态选择,提高服务的可靠性;

    (3)             防火墙负载均衡:在防火墙处理能力成为瓶颈的组网环境中,可以采用防火墙负载均衡,将网络流量分担给多台防火墙设备,提高防火桥的处理能力;

    1.1 服务器负载均衡

    随着Internet的快速发展和业务量的不断提高,基于网络的数据访问流量迅速增长,特别是对数据中心、大型企业以及门户网站等的访问,其访问流量甚至达到了10Gb/s的级别;同时,服务器网站借助HTTP,FTP,SMTP等应用程序,为访问者提供了越来越丰富的内容和信息,服务器逐渐被数据淹没;另外,大部分网站(尤其电子商务等网站)都需要提供不间断24小时服务,任何服务中断或通信中的关键数据丢失都会造成直接的商业损失。这些都对应用服务提出了高性能和高可靠性的需求。

    但是,相对于网络技术的发展,服务器处理器速度和内存访问速度的增长却远远低于网络带宽和应用服务的增长,网络带宽增长的同时带来的用户数量的增长,也使得服务器资源消耗严重,因而服务器成为了网络瓶颈;传统的单机模式,也往往成为网络故障点。

    1.1.1 服务器负载均衡解决方案

    多台服务器通过网络设备相连组成一个服务器集群,每台服务器都提供相同或相似的网络服务。服务器集群前端部署一台负载均衡设备,负责根据已配置均衡策略将用户请求在服务器集群中的分发,为用户提供服务,并对服务器可用性的维护。

    该方案的优势:

    (1)低成本:按照业务量增加服务器个数即可;已有资源不会浪费,新增资源无需选择昂贵的高端设备。

    (2)可扩展性:当业务量增长时,系统可通过增加服务器来满足需求,且不影响已有业务,不降低服务质量。

    (3)高可靠性:单台服务器故障时,由负载均衡设备将后续业务转向其他服务器,不影响后续业务提供,7 × 24小时业务不中断。

    1.2 链路负载均衡

    就互联网接入来说,众所周知,由于国内的两大运营商---电信与网通之间的瓶颈问题,导致电信网通用户互访时出现延迟较,响应缓慢,更有甚者会直接导致用户正常的业务无法运行。而且单条链路存在单点故障的隐患,当互联网链路DOWD掉时,可能引起的直接问题就是用户所有依赖互联网的业务及对互联网的访问都会因此而无法使用,这对于一个用户来说是无法想象的。

    目前在互联网接入时存在的主要问题:

    (1)电信网通瓶颈问题

    (2)单条链路存在单点故障

    (3)主备链路需要人工切换

    1.2.1 链路负载均衡解决方案

    通过接入电信网通两条(或多条链路)来保障网络的连通性,持续性以及快速访问。并提供各链路间的智能备份,实现链路级别的快速高可用。

    1.2.1.1 outbound方向链路负载均衡(从内到外的链路负载均衡)

    通过电信、网通双链路的接入,并使用静态和动态相结合的多链路负载均衡功能,使内部用户无论是访问网通资源还是电信资源,都可以从相应的线路进行访问.解决了从内到外的电信网通的互访瓶颈。

    1.2.1.2 inbound方向链路负载均衡(从外到内的链路负载均衡)

    解决外部用户访问内部服务器时所遇到的不同ISP的互访瓶颈.当ISP A的用户访问内部的www.abc.com时把ISP A接口的地址解析给用户,使其通过ISP A线路来访问www.abc.com. 当ISP B用户来访问内部的www.abc.com时,再把ISP B接口的地址解析给用户,使其通过ISP B的线路来访问www.abc.com.

    1.2.1.3 多条链并行使用以及智能备份

    多链路负载均衡还提供了链路的自动探测及备份功能,当某条链路断掉时,自动将流量切换到正常链路上,同时对外提供的访问,也将只解析正常链路的地址,使访问人员通过当前正常的链路来访问内部的服务。从进出双向来保障链路的正常工作。

    1.3 网关负载均衡

    SSL-VPN网关,IPSec网关,防火墙网关等网关设备,因为业务处理的复杂性,往往成为网络瓶颈,以防火墙网关为例:防火墙作为网络部署的“警卫”,在网络中不可或缺,但其往往不得不面临这样的尴尬:网络防卫越严格,需要越仔细盘查过往的报文,从而导致转发性能越低,成为网络瓶颈。

    在这种情况,如果废弃现有设备去做大量的硬件升级,必将造成资源浪费,随着业务量的不断提升,设备也将频繁升级。频繁升级的高成本是相当可怕的。因此将网关设备等同于服务器,组建网关集群的方案应运而生:将多个网关设备并联到网络中,从而形成集群处理能力,提高网络处理能力。

    1.3.1 网关负载均衡解决方案

    防火墙负载均衡包括以下几个基本元素:

    (1)      集群:提供网络流量负载均衡的群体,包括LB、Fireall;

    (2)      LB:负责分发请求发起方的网络流量到多台Firewall设备,LB又分为一级和二级,如果请求发起方的流量方向为Host A-àHost B,则LB A为一级,LB B为二级;方向类似;

    (3)      Firewall:正常处理数据的防火墙。

    2 负载均衡调度算法

    负载均和产品中的关键技术是调度,目前常用的调度算法有

    轮询(Round Robin

     

    加权轮询(Weighted Round Robin

     

     

     

    最少连接(Least Connections

     

     

     

    加权最少连接(Weighted Least Connections

     

     

     

    随机(Random

     

     

     

    加权随机(Weighted Random

     

     

     

    源地址散列(Source Hashing

     

     

     

    源地址端口散列(Source&Port Hashing

     

     

    2.1 负载均衡算法介绍

    (1)轮询算法

    新的连接被依次轮询分发到各个实服务上,比如第一个连接分发到第一台服务器,第二个连接分发到第二台服务器上;

    轮询算法适用于服务器集群中所有服务器都有相同的软硬件配置,并且平均服务器请求相对均衡的情况;

     

    (2)加权轮询算法

     

    根据服务器不同的处理能力,给服务器分配不同的权值,使其能接受相应权值的服务器请求;

    加权轮询算法能确保高性能的服务器能得到更多的使用率,避免低性能的服务器过载过重;

     

    (3)最少连接数算法

     

    最少连接数算法对内部需要负载的每一台服务器上的连接数都一个记录,记录当前该服务器正在处理的连接数,当有新的服务连接请求时,把请求分发给连接数最少的服务器,使均衡更加符合实际情况,负载更具啊均衡;

    最少连接数算法适合长时间处理的请求,例如:FTP。

    加权最少连接数算法,即将加权与连接数配合使用,根据连接数与加权的比例计算出当前请求应该分发给哪个具体的服务器;

     

    (4)随机算法

    将新连接请求随机分发给各个服务器;

    加权随机算法,即将加权与随机算法配合使用,根据随机数与加权的比例计算出当前请求应该分发给哪个具体的服务器;

     

    (5)源地址散列

    根据新连接请求的源IP地址进行散列HASH的结果,决定将请求分发给具体的服务器;

    来在相同客户端的连接会被分发到相同的服务器上;

     

    2.2 持续性

    将多个连接持续重定向到同一个服务器的策略,就是持续性功能。根据持续性原则,建立会话表项,保证后续业务报文都送往同一个服务器处理。比如使用源地址建立持续性表项,保证持续性。

    u  基于源IP地址的持续性功能:

    负载均衡设备接收到某一客户端的某一业务的首次请求时,建立持续性表项,记录为该客户分配的服务器情况,在会话表项生存周期内,后续该业务报文都将发往该服务器处理。基于源IP地址持续性功能的特点是:实现简洁快速。

    u  Cookies保持

    Cookies持续性利用客户机存储的cookies信息来吧客户机连接到合适的服务器上,其原理如下:

    (1)      首次命中Http请求(不带cookes)进行LB,此时LB任选一台服务器,将请求转发至该服务器;

    (2)      来自该服务器的Http回复报文此时包括一个空白的cookies,LB重写cookies,并再粘贴一个特殊的cookies后将http报文发送回去;

    (3)      再次命中Http请求(带有与上面形相同的cookies)进入LB,LB设备借助cookies信息确定合适的服务器;

    3 服务器负载均衡技术介绍

    3.1 概念介绍

    u  虚服务:负载均衡设备对外提供的服务称为虚服务,虚服务由VPN实例,虚服务IP地址、服务协议、服务端口号唯一标识,配置负载均衡设备上,客户的访问请求通过公关网络或私有网络到达负载均衡设备时,匹配到虚服务后,由负载均衡设备按照既定的策略分发给实服务;

    u  实服务:实服务器是真实服务器提供一种服务,该服务含义比较广泛,可以是传统的FTP,HTTP等业务,也可以是广泛的转发服务,如防火墙网关负载均衡中,实服务只是报文的转发路径;

    u  实服务组:为了便于对实服务进行管理,将多个实服务的一些共有属性提取出来形成实服务组,一个虚服务对应一个实服务组,一个实服务组对应多个实服务,相同的实服务组不能属于不同的虚服务;

    3.2 服务器负载均衡工作机制

    服务器负载均衡有两种工作方式:

    u  NAT(Network Address Translation,网络地址转换)方式

    u  直接路由(DirectRouting,简称DR)方式

    (1)NAT方式

    NAT方式组网灵活,后端服务器可以位于不同的物理位置,不同的局域网内。

    1、实现原理

    客户端将到VSIP的请求发送给服务器群前端的负载均衡设备,负载均衡设备上的虚服务接收客户端请求,通过调度算法,选择真实服务器,再通过网络地址转换,用真实服务器地址重写请求报文的目标地址后,将请求发送给选定的真实服务器;真实服务器的响应报文通过负载均衡设备时,报文的源地址被还原为虚服务的VSIP,再返回给客户,完成整个负载调度过程。

    2、技术特点

    组网灵活,对服务器没有额外要求,不需要修改服务器配置,适用于各种组网。

    步骤

    说明

    源IP

    目的IP

    1

    Host发放请求报文

    Host-IP

    VIP

    2

    LB收到请求报文后,根据调度算法计算出请求报文分发给哪台服务器

    -

    -

    3

    LB使用DNAT技术分发报文

    Host-IP

    Server IP

    4

    Server接收并处理请求,返回相应报文

    Server IP

    Host-IP

    5

    LB接收相应报文,转换源IP后转发

    VIP

    Host-IP

     

    (2)DR方式

    相对于NAT 组网方式,DR 组网方式,只有客户端的请求报文通过LB,服务器的响应报文不经过LB,从而减少了LB的负载,有效的避免了LB成为网络瓶颈。

    1、实现原理

    DR方式的服务器负载均衡时,除了LB设备上配置了VSIP,真实服务器也都配置了VSIP址,配置的VSIP要求不能响应ARP请求,例如在环回接口上配置VSIP。发送给VSIP的报文,由LB分发给相应的真实服务器,从真实服务器返回给客户端的报文直接通过交换机返回。

    2、技术特点

    只有单边报文经过负载均衡设备,负载均衡设备负担小,不易成为瓶颈,转发性能更强。

    步骤

    说明

    源IP

    目的IP

    1

    Host发放请求报文

    Host-IP

    VIP

    2

    General device收到请求后转发给LB,Server上的VIP不能发送和相应ARP报文,因此General device只能将报文转发给LB

    Host-IP

    VIP

    3

    LB使用调度算法决定将报文分发给哪台服务器,在封装报文时目的IP为VIP,目的MAC为Server的目的MAC(根据ARP请求Server IP获取)

    -

    -

    4

    LB转发报文给Server服务器

    Host-IP

    VIP

    MAC=Server-MAC

    5

    Server接收并处理请求,返回相应报文给General device

    VIP

    Host-IP

    6

    General device收到报文后,直接转发给Host

    VIP

    Host-IP

    3.3 服务器状态检查

    所谓状态检查就是指负载均衡设备定期对真实服务器运行状态进行探测,收集相应信息,及时隔离工作异常的服务器。健康检查的结果除标识服务器能否正常工作外,还可以统计出服务器影响时间,作为选择服务器的依据。负载均衡技术支持丰富的健康状态检查算法,可以有效地探测和检查服务器的运行状态。

    ICMP:向服务器发送ICMPEcho报文,若收到ICMP Reply,则服务器正常;

    TCP:向服务器的某端口建立TCP连接,若成功,则服务器正常;

    HTTP:和服务器的80端口建立TCP连接,然后发出HTTP请求,若所收到的HTTP应答内容争取,则服务器正常;

    FTP:和服务器21端口建立连接,然后获取一个服务器相关目录放置的文件,若所收到的文件内容正确,则服务器正常;

     

    4 链路负载技术介绍

    链路负载均衡根据业务流量方向可以分为outbound链路负载均衡和inbound链路负载均衡两种情况。

    4.1 outbound链路负载均衡

    内网用户和外网之间存在多条链路时,通过outbound链路负载均衡可以实现在多条链路上分担内网用户访问外网服务器的流量。

    1、  实现原理

    Outbound链路负载均衡中VSIP为内网用户发送报文的目的IP,用户将访问VSIP的报文发送到负载均衡设备上后,负载均衡设备依次根据持续性、ACL策略、就近性、调度算法选择最佳的物理链路,并将内网流量分发到该链路上。

    2、  技术特点

    可以和NAT应用网关共同组网,不同的链路使用不同的源地址,从而保证往返报文穿过同一条链路;

    通过健康性检查,可以检查链路内任意节点的连通性,从而有效保证整条链路上的可达性;

    通过调度算法,在多条链路间均衡流量,并支持按照带宽进行负载均衡;

    利用就近性算法动态计算链路的质量,将流量分发到当前最优链路上。

    步骤

    说明

    1

    LB设备接收到内网流量

    2

    LB设备依据就近性,ACL策略,持续性,调度算法选择链路

    3

    LB设备将流量分发到选择出的链路上

    4

    LB接收外网用户流量

    5

    LB将外网用户流量转发给设备

    4.2 inbound链路负载均衡

    内网和外网之间存在多条链路时,通过inbound链路负载均衡可以实现在多条链路上分担外网用户访问内网服务器的流量。

    1、  实现原理

    Inbound链路负载均衡中,负载均衡设备作为权威服务器记录域名与内网服务器IP地址的映射关系,一个域名可以映射多个IP地址,其中每个IP地址对应一条物理链路;

    外网用户通过域名方式访问内网服务器时 ,本地DNS服务器将域名解析请求发送给权威名称服务器——负载均衡设备,负载均衡设备依据持续性、ACL策略、就近性等算法选择最大的链路,并将通过该链路与外网接口的IP地址作为DNS解析结果反馈给外网用户,外网用户通过该链路访问内网服务器。

    2、  技术特点

    可以和服务器负载均衡配置使用,实现外网用户访问内网服务器的流量在多条链路间均衡的同时,也实现了流量在多台服务器间均衡;

    通过健康检查,可以检查链路内任意节点的连通性,从而有效保证整条链路的可达性;

    利用就近性算法动态计算链路的质量,保证转发流量的链路时当前最佳的链路。

    步骤

    说明

    1

    外网用户通过域名访问内网服务器时,首先要进行DNS解析,向本地DNS服务器发送DNS解析请求

    本地DNS服务器将DNS请求转发给权威的名称服务器——LB

    2

    LB设备根据请求的域名,持续性,ACL策略,就近性等算法选择最用的物理链路,并将给物理链路与外网连接的接口IP地址作为域名解析结果

    3

    LB设备将解析结果返回给本地DNS

    4

    本地DNS将结果返回给Host

    5

    用户使用返回的结果对内网发起访问

    5 网关负载均衡

    LB Device负载分发请求发起方的网络流量到多个网关设备,LB又分为一级和二级,如果请求发起方的网络流量为Host A->Host B,则LB Device A为一级,LB Device B为二级;

    网络设备:正常处理数据的网络设备;

    1、  实现原理

    防火墙是基于会话开展业务的,即一个会话的请求和应答报文必须通过同一个防火墙,为了保证防火墙业务正常进行,内部组网不受影响,需要采用双侧防火墙,即防火墙三明治。在这种组网环境中,对于流入流量一级LB设备做防火墙负载均衡,二级LB设备保证从哪个防火墙进来的流量,还要从哪个防火墙返回;流出链路正好相反。

    2、  技术特点

    服务对象为防火墙,提高防火墙组网灵活性。没有特殊要求,适用于任何组网环境。

    步骤

    说明

    1

    LB A接收网络流量

    2

    LB A根据调度算法将流量转发给某台Firewall

    3

    Firewall将流量转发给LB B

    4

    LB B记录转发流量的防火墙,并把流量转发到目的地

    5

    LB B接收来自目的地的回应流量

    6

    LB B根据记录将流量转发给相应的防火墙

    7

    Firewall将流量转发给LB A,LB A将流量转发回源地址

    防火墙负载均衡也可以服务器负载均衡配置使用:

    Cluster A为防火墙负载均衡的集权,ClusterB为服务器的负载均衡集群,综合组网的工作流程就是防火墙和服务器负载均衡的叠加,这种组网方式避免了防火墙称为网络中的瓶颈,也提高了网络服务的性能和可用性。

    6 智能选路

    智能选路系统——不仅仅是一项功能

    智能选路系统——是一系列功能组成的解决方案

    6.1 关键用户走某条优质链路——默认路由+策略路由

    选路原理

    关键用户走某条优质链路

    普通用户按照流量在出口设备被均衡分配

    优势

    实现简单,业内路由器均可支持

    缺点

    优质链路跑满,关键用户业务受影响

    存在跨运营商现象,影响用户上网体验

     

    6.2 从运营商下载IP列表——静态路由+默认路由

    选路原理

    从运营商下载ISP的IP地址列表

    通过静态路由的方式静态选路,访问电信的走电信,访问联调的走联调

    其余流量走大带宽链路(默认路由)

    优势

    解决了跨运营商问题,

    选择正确的IPS链路,保证用户体验

    实现简单,业内标准路由器都可以支持

    缺点

    1、ISP列表变化频繁,第一次实施后不易更新和维护

    2、若链路跑满,路由策略无法自动变更,例如:

    (a)电信链路跑满,联调链路空闲,若用户命中电信地址,仍然会选择电信链路,从而造成丢包

    (b)电信链路空闲,默认路由链路跑满,后续命中默认路由的数据仍会现则满载链路,造成丢包

    6.3 智能选路

    链路健康监测优先级最高,若链路失效,则链路上所有路由策略都会失效

    策略路由高于过载保护,即使某条链路负载已经超过设定的保护阀值,通过策略路由仍可使用该链路

    若应用路由、静态路由、地址库路由、默认路由中,存在等价路由,则可以通过MLLB进行负载

     

    6.4 链路过载保护

    链路负载超过设置的阈值,后续流量切换到其他链路

    切换的前提是NPE自动探测到链路到目的IP地址可到

    策略路由不受过载保护的影响

    6.5 应用路由

    首包识别数据流的应用,根据应用做选路,传统应用路由的难点:

    u  基于应用的路由,首先要把应用识别出来;

    u  目前应用的识别无外乎DPI,DFI等;

    u  DPI识别是通过7层特征识别,需要等待流的连接建立完成,7层协议开始传出后才能识别出来,简单的说,DPI的是被落后与连接的建立,当DPI识别出该应用的时候,连接已经建立起来,这时如果再做选路,必须首先要断掉之前建立的流连接;

    6.5.1 大流量协议识别

    技术点

    协议识别:

    大容量传输的应用通常有控制流量和传输流量,比如:FTP,迅雷,BT,电驴,QVOD等

    原理

    控制流量不做应用路由

    识别传输流量做应用路由

     

    6.5.2 DNS识别

    技术点

    特定网站,只需要截获DNS报文,就可以知道其类型。

    如:优酷、土豆、奇艺、新浪视频等

    原理

    监测DNS报文,发现URL请求是特定网站,记录DNS回应报文(即该网站的IP)进行路由,影响IP流量通过设备时会被路由到特定的链路上;

    若门户网站包含视频,则只监控视频类。如新浪,只监控video.sina.com.cn

     

    6.5.3 主动控制


    技术点

    P2P协议,如果断流,双方会发起重传机制

    原理

    对于P2P,在初期通过DPI、DFI识别后,主动将其切断;

    通过NPE记录的流信息,根据应用路由重传请求;

    用户端不会有任何感知;

     

    6.5.4 地址库

    技术点

    某些应用的目的IP固定,且流量大,如网盘、移动终端应用下载等

    原理

    人工收集此类应用的目的IP

     

    6.6 DNS代理

    u  DNS代理不属于路由体系,但能影响选路结果;所有的路由体系的选路都是目的IP通过DNS确认后,才开始工作的;而DNS代理是帮助用户获得更合理IP的技术,所以其生效是在路由体系之前;

    u  适用范围:目标URL拥有多个ISP的服务器(一般大型网站都如此);

    u  用户价值:在链路负载过高时,提升用户体验,合理分配目的IP所属运营商,结合地址库,使链路利用更均衡。(如,不开此功能,用户DHCP分配电信DNS,则10个网站解析出9个电信+1个联通,电信链路压力大;开启该功能后,解析出5个电信+5个联通,减小电信链路压力);

    6.6.1 DNS代理实现原理

     

    原理

    u  设备上开启DNS代理功能;

    u  配置电信和联调的DNS服务器;

    u  当有DNS请求到达设备时,设备会根据链路负载情况决定向电信DNS服务器或联调DNS服务器发送DNS请求报文;

    u  DNS回应报文到达设备后,设备透传给Host

     

    6.7 智能选路实现效果

    展开全文
  • 链路的负载均衡设备接收到内网的流量;根据目的ip查找到ip所属运营商,将流量转发给通向运营商的链路,运营商运营的是外网,一个外网下有很内网 接收: 链路负载均衡设备接收到外网用户流量;直接将流量

    链路概念指的是一条点到点的连续不断的线路段,中间没有其他点,我理解为一条小时候玩的"传音绳",两头都可以传输,中间有其他点就会收不到数据

    数据链路指的是,可以传输数据的线路,线路上添加了一些数据传输的规定,相当于在绳子表面涂了一层颜色,响应颜色的绳只能传输响应格式的数据,必须要遵守

    工作流程:

    发送:

    链路的负载均衡设备接收到内网的流量;根据目的ip查找到ip所属运营商,将流量转发给通向运营商的链路,运营商运营的是外网,一个外网下有很多内网

    接收:

    链路负载均衡设备接收到外网用户流量;直接将流量转发给内网用户

    内网:

    电脑通过路由器,再通过交换机,然后才连接到inter网,我们平时连得都是内网,属于某一个运营商,外网数量有限,一般是公司学校网吧等使用一个外网就可以,

    内网就是路由器以下开始的,ip都是192开头的ip,内网产生是为了解决外网不够用的问题

    外网:

    外网指的是,不用经过路由器和交换机就可以直接上网,可以直接被外界访问,无需经过任何设备,直接连接Internet

    数据链路的三个基本问题:

    封装成帧:  帧是数据链路层的传输单位,帧长等于帧头+帧尾+数据,链路传输协议定义了传输数据长度,所有帧头和帧尾就是用来定界的;

     透明传输:

    无论任何bit组合的数据都能原样无差错的通过数据链路传输

    差错检验:

    实现无比特差错

    展开全文
  • php负载均衡实例

    2021-04-14 01:29:50
    3、负载均衡:网络管理员可以通过策略路由在条路径上分发数据流。 4、网络管理更加灵活。二、双出口配置实例(一)实验拓朴: (二)实验要求: 1、R1 连接本地子......3、负载均衡:网络管理员可以通过策略路由在条路径...
  • 1 二层负载均衡 二层负载均衡又称为数据链路负载均衡。主要的实现方式就是PPP捆绑和链路聚合技术。 链路聚合技术 以太网链路聚合简称链路聚合,它通过将条以太网物理链路捆绑在一起成为一条逻辑链路,从而实现...
  • 负载均衡学习之

    2021-04-07 09:44:52
        负载均衡是一种计算机网络技术,建立在现有网络结构之上,用来在个计算机(计算机集群)、网络连接、CPU、磁碟驱动器或其它资源中分配负载,以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免...
  • 本文主要有如下不同之处:出口有条链路,单位主页有条链路的出口IP,如电信和教育网IP地址,为了达到各链路访问主页都比较快速,在防火墙上做入站链路负载均衡配置,即由防火墙负责条链路的负载均衡解析,...
  • 负载均衡详解

    2021-10-15 09:44:16
    负载均衡详解 摘要:面对大量用户访问、高并发请求,海量数据,可以使用高性能的服务器、大型数据库,存储设备,高性能Web服务器,采用高效率的编程语言比如(Go,Scala)等… 面对大量用户访问、高并发请求,海量数据...
  • Nginx---负载均衡负载均衡概念负载均衡的原理及处理流程负载均衡的作用负载均衡常用的处理方式方式一:用户手动选择方式二:DNS轮询方式方式三:四/七层负载均衡Nginx七层负载均衡Nginx七层负载均衡的指令upstream指令...
  • 吃透负载均衡

    2021-12-13 09:47:51
    负载均衡的理解零零散散,不成体系。 阅读这篇文章需要的条件: 对OSI模型有些许了解 有耐心。本文涉及大量的知识点,且只能用文字才能讲清楚,所以文字比较。 收获: 读完此篇文章,从宏.
  • 服务器集群负载均衡原理

    千次阅读 2018-03-07 19:49:13
    利用DNS实现负载均衡,就是在DNS服务器配置个A记录,不同的DNS请求会解析到不同的IP地址。大型网站一般使用DNS作为第一级负载均衡。缺点是DNS生效时间略长,扩展性差。基于IP的负载均衡,早期比较有...
  • 负载均衡是指将负载(工作任务)进行平衡、分摊到个操作单元上进行运行,例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等,从而协同完成工作任务。 负载均衡可以分为服务端负载均衡、客户端...
  • 从而实现负载均衡,避免单根链路流量饱和。 重要提示: 默认设备支持的流量均衡方式为 src-dst-mac ,在不同的场景模型中,用户流量的特征不同,可能负载的效果并不是所期望的,这时候需要人工调整负载均衡的...
  • 负载均衡的解决方案

    千次阅读 2018-10-12 21:15:04
    我们在设计分布式系统的时候往往需要考虑系统的伸缩性,这里所说的伸缩性指的是我们可以通过添加服务器节点的方式来提升我们整个系统的并发能力,这种提高伸缩性的基础原理其实就是我们所说的——负载均衡
  • 通过负载均衡,可以将高并发的用户请求分发到台应用服务器组成的一个服务器集群上,利用更的服务器资源处理高并发下的计算压力。 那么负载均衡是如何实现的,如何将不同的请求分发到不同的服务器上呢? 早期,...
  • 看完这篇就全懂负载均衡

    千次阅读 多人点赞 2018-10-06 21:42:52
    目录   一、什么是负载均衡? 二、四层和七层负载均衡的区别? 2.1 - 技术原理上的区别。 2.2 - 应用场景的需求。...三、负载均衡的算法?...四、负载均衡的实现(DNS &... 数据链路层 > IP层 >...
  • 针对这一矛盾,采用目前流行的负载均衡设备来解决,使用多链路负载均衡技术对长庆石油专网出口系统进行改造后,不但解决了几大ISP间互访的瓶颈问题,还为网站访问提供了更高的可靠性和性能。并且通过负载均衡技术,...
  • LB :Load Balance 负载均衡,是一种集群技术,它将特定的业务分担给台网络设备,或条链路,从而提高业务处理能力,保证了业务的高可靠性。LVS就是一种负载均衡集群技术。 HA :High Aviliablity 高可用,高可用...
  • 负载均衡原理及算法

    2021-09-09 08:52:38
    目录背景概述原理分类按照软硬件分类硬件负载均衡软件负载均衡按照地理结构分类本地负载均衡全局负载均衡按照实现技术DNS负载均衡IP负载均衡链路层负载均衡混合型负载均衡按照OSI层次二层负载均衡(数据链路层)三层...
  • 当一个请求到达负载均衡服务器之后,负载均衡服务器根据某种负载均衡算法计算得到一个应用服务器的地址,通过 HTTP 状态码 302 重定向响应,将新的 IP 地址发送给用户浏览器,用户浏览器收到重定向响应以后,重新...
  • 本文来说下负载均衡的知识与内容 文章目录负载均衡简介大型网站面临的挑战 负载均衡简介 大型网站面临的挑战 大型网站都要面对庞大的用户量,高并发,海量数据等挑战。为了提升系统整体的性能,可以采用垂直扩展和...
  • Nginx负载均衡

    千次阅读 2019-06-23 16:56:32
    一、负载均衡分类 (1)软硬件分类 负载均衡可以通过负载均衡软件实现,也可通过硬件负载均衡器实现。 (2)硬件负载均衡 硬件负载均衡器的性能稳定,且有生产厂商作为专业的服务团队。但其成本很高,一台硬件...
  • 负载均衡搭建集群

    2020-12-24 18:52:32
    数据链路层:逻辑链接,MAC地址,硬件地 址(生来就有) 设备:交换机 网络层:逻辑寻址(IP地址),不同网络间的路径选择 设备:路由器 传输层:定义传输数据的协议端口号 共0~65535个端口(不能同时打开,不安全...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 25,021
精华内容 10,008
关键字:

多链路负载均衡