CN105099934A - 在电信产品中进行负载均衡的方法和设备 - Google Patents
在电信产品中进行负载均衡的方法和设备 Download PDFInfo
- Publication number
- CN105099934A CN105099934A CN201410171659.3A CN201410171659A CN105099934A CN 105099934 A CN105099934 A CN 105099934A CN 201410171659 A CN201410171659 A CN 201410171659A CN 105099934 A CN105099934 A CN 105099934A
- Authority
- CN
- China
- Prior art keywords
- service request
- request
- blade server
- blade
- resource reservation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Abstract
本发明包括提供了一种在包括多个刀片服务器和负载分配器的电信设备中执行负载均衡的方法和相应的电信设备。该方法包括:当所述多个刀片服务器中的一个或更多刀片服务器接收到严重耗费资源的业务请求时,向所述负载分配器发送资源预留请求;在接收到对所述负载分配器对资源预留请求的确认时,所述一个或更多刀片服务器开始处理所述严重耗费资源的业务请求;以及,所述负载分配器将超出所述一个或更多刀片服务器的处理能力的新输入业务量重定向至多个刀片服务器中的其他刀片服务器,直至从所述一个或更多刀片服务器接收到资源释放消息。
Description
技术领域
本发明涉及通信领域,并且更具体地涉及电信产品中的负载均衡机制。
背景技术
ATCA(先进电信计算架构)是许多电信产品的重要硬件架构,具有成本低和灵活性高的特点。通常,一个ATCA基座托管了数十个刀片,多个相同的或者不同的应用可以运行在这些刀片上。所有基于ATCA架构的产品都必须考虑负载均衡和准入控制机制以实现所有这些刀片的处理器性能的有效使用。越来越多的应用部署在ATCA基座上,如何实现ATCA性能的最佳使用以及如何调度和均衡来自不同应用的请求时使得产品具有竞争力的关键点。
图1给出了典型的ATCA基座结构,该基座由两个管理所有其他刀片的控制刀片(A、B)、十个处理呼叫流量或主机数据的实时刀片(C、E、G、I、K、D、F、H、J和L)以及将所有这些刀片连接到一起与外部通信的交换刀片(S)组成。多个应用运行在相同的刀片上,并且对于每一个输入消息,需要确定哪一个服务器/刀片被分配用于处理该消息。来自不同应用和网络单元的请求具有完全不同的特征,因此它们对于这些刀片上资源的请求是不同的。我们要解决的问题是如何调度和均衡来自基于ATCA的基座上的多个应用的请求,以使得整个产品具有最佳鲁棒性和性能。
如上所述,单个输入消息可能会耗尽ATCA产品的刀片的所有资源。另外,ATCA产品的单个刀片的负载可能会使得整个产品的服务质量降低到与过载的刀片相同。也就是说,如果有一个刀片具有服务质量1E-2,也就是说,100个呼叫里有一个呼叫失败,那么,无论当前应用了什么样的负载均衡算法(CPU负载算法、RR等)以及无论其他刀片具有多么好的性能。整个产品将具有服务质量1E-2。本发明提出基于资源预留的流量分配算法来解决这个问题并且即使输入消息的成本变化很大,也要确保产品的服务质量并优化性能利用率。
较好的负载均衡系统具有较高的流量性能和鲁棒性。最常用的流量分配算法的目的就在于使得服务器的负载均衡。这些常用的算法主要包括轮询调度算法、加权的轮询调度算法以及CPU负载感知算法。所有这些算法都基于一个隐含的假设进行工作,即所有输入消息具有类似的处理时间以及每个消息都需要小的和类似的CPU成本。如果有某种类型的输入消息需要大的CPU使用率在几分钟内进行处理,则所有上述算法将导致系统过载。举一个例子,典型的Diameter消息通常需要数十毫秒、小于0.1%的CPU使用率在IMS网络单元内进行处理。网络单元通常被设计在低于CPU使用率的工作70%时处理忙时流量。但是IMS网络中来自接入网关控制功能(AGCF)到归属用户服务器(HSS)的注册请求可以代表成千上万的端点进行注册。当HSS收到这个注册消息时,它需要向AGCF推送与这些成千上万的用户相关的数据并且即使采用高于30%CPU的使用率也不能保证在数分钟内完成这些数据的下载。在这种情况下,如果还有其他类型的请求在繁忙时段运行,注册消息的输入将会导致过载状态下的刀片托管HSS应用程序处于过载状态。为了避免这种过载状态,运营商通常过度设计他们的系统,使得整个系统在繁忙时段以40%的CPU使用率运行,并且当来自AGCF的一个注册消息到达时,它可以用70%的CPU使用率进行处理。但是,这意味着如果网络中只有一个AGCF在几个月内请求一次注册,30%的资源必须留给它。显然的,这是一种资源的浪费。
这个问题不止是在部署PSTN仿真服务时存在。对于呈现业务来说,也需要面对这个问题。当呈现方的状态改变时,它使用PUBLISH方法来告知呈现服务器这一改变。结果,呈现服务器将把呈现方的状态改变通知给所有订购的观察方。呈现服务能产生大量的信令流量,因为一个呈现方的状态改变将导致发往观察方的多个通知消息。ATCA基座中这类猝发的资源使用由于其事务特性必须共同位于相同的刀片上,并且当前的调度算法不能确保以较好的质量服务这些请求,也不能确保整个基座下性能的最佳使用。
下面将举例说明当前的几种常用算法。
1)轮询调度算法
轮询调度(RR)算法是一种静态负载均衡算法,并没有特别考虑到分配新流的各刀片的当前剩余性能,而是一味地试图做到在如何分配工作量上不偏不倚。这是一种循环的策略,其中刀片按顺序被循环选择。
考虑配置多个应用程序共同位于ATCA的一个刀片上。每个刀片支持的应用程序是不一样的。他们是不对称配置的刀片。
轮询调度算法在具有相同配置和相同运行环境的系统中工作良好并且容易控制。但是对于ATCA产品,每个刀片是一个自治系统,每个刀片上运行的应用可以是不同的。一些刀片比别的刀片运行更多的应用,而一些刀片比其他刀片运行了更多的应用程序模块,简单的轮循不能满足此条件下的负载均衡请求。
图2是使用轮询调度算法为多个应用共同位于一个刀片但每个RT是不对称配置的情况分配每个应用。图中,HSS运行在刀片E和F,LTE运行在刀片K和L。HLR和MNP运行在所有刀片上。
然而,这里使用RR的缺点是,每个刀片服务器的资源使用情况是不平衡的。对于运行更多的应用程序的刀片,CPU使用率必须比其他刀片高。这是很容易造成拥堵和系统的不稳定。此外,整个系统的利用率是低的。
2)加权轮循算法
加权轮循算法是轮循算法的扩展。它为每个刀片服务器赋予一定的权重。权重表示服务器的处理能力。如果偶尔可以评估各个服务器的能力和他们的负荷的话,这种分配算法也可能是动态的。该算法将考虑要输入的消息/流量。
权重可以被预先配置或动态地改变。wij是刀片i中的应用程序j的权重。对于每个周期,负载平衡功能可以基于权重分配流量:
如果控制目标是每个刀片中的流量是平均的则
基于加权轮循的管理配置效率和成本效益不高,因为很难在产品处理流量之前来决定每个刀片的加权。例如,如果控制目标是CPU的平衡,该方案需要经验来将CPU使用率与应用程序的流量进行映射。并且该方案是不灵活的,因为应用程序的不同流量组合可能会消耗不同的CPU负载。理想的方式是提供一种动态机制,能自动了解每个刀片的差异并且最佳地使用使每个刀片的性能。
3)基于CPU的流量分配算法
对动态系统状态的不了解导致低复杂性,但在这是以潜在的性能和服务可靠性的降低为代价的。在某些情况下使用动态(自适应)的流量分配算法,该算法要基于CPU使用率的改变作出决定。该算法的目的是使所有刀片工作站支持相同的CPU使用率,并根据变化的总CPU使用率做决定。图3给出了针对具有不同配置的刀片的该算法效果的示意。
基于CPU的分配机制是有吸引力的,所有的刀片都具有均衡的CPU使用率,并且可能比具有不均匀的CPU使用率的任何其他方法具有更高的系统容量。但问题是系统的CPU使用率是由多个任务共享,这些任务可以通过或可以不被与客户签约的申请配置控制。产品的性能和吞吐量不仅是由CPU能力决定的,也与磁盘IO速率、通信带宽等有关系。刀片服务器上应用程序的CPU使用率是通过操作系统的内置调度算法来决定的,这些调度算法不仅考虑决定考虑到在其上运行的应用,也要考虑许多系统相关的管理和监视任务,使得分配给特定的应用程序的CPU使用率受到预先定义的优先级、动态的运行环境,以及一些不可预知的中断影响,因此,在不同刀片的上相同应用的处理能力既不能保证是相同的,也不能保证在所有时间都稳定。
采用基于CPU的调度算法,每个刀片必须对每个应用程序具有相同的处理能力并且分配给每个应用程序的CPU使用率必须是稳定的,所有刀片的磁盘IO速率、运输带宽也必须相同。否则,一个刀片的应用程序的服务质量可能比其他刀片更糟。例如,在阿尔卡特朗讯SDM产品上做过实验,基座上的刀片D被配置为写接收到的请求时在跟踪文件而其它刀片仅接受请求并发送响应。随着磁盘IO需要较长的响应时间和刀片D的CPU使用率小于其他站,通过基于CPU的分布式算法,更多的客户请求被分配到刀片D。因为队列长度溢出,输入到刀片D的1%的请求被拒绝,而其他刀片没有请求失败。到刀片D的请求超过到其他刀片的请求,尽管其他的刀片有更好的服务质量和处理能力,但是整个产品的服务质量位于1E-2的水平。因此,采用所有刀片的CPU使用率按照目标被均衡的机制,可能会导致一些刀片上的某些应用中有比这些应用在其他刀片运行时更糟糕的服务质量。
发明内容
为了解决现有技术的各种缺陷,本发明提出了一种基于资源预留的负载均衡方法和相应的电信设备。
根据本发明的一个方面,提出了一种在包括多个刀片服务器和负载分配器的电信设备中执行负载均衡的方法,该方法包括:当所述多个刀片服务器中的一个或更多刀片服务器接收到严重耗费资源的业务请求时,向所述负载分配器发送资源预留请求;在接收到对所述负载分配器对资源预留请求的确认时,所述一个或更多刀片服务器开始处理所述严重耗费资源的业务请求;以及所述负载分配器将超出所述一个或更多刀片服务器的处理能力的新输入业务量重定向至多个刀片服务器中的其他刀片服务器,直至从所述一个或更多刀片服务器接收到资源释放消息。
根据本发明的另一个方面,提出了一种包括多个刀片服务器和负载分配器的电信设备,其中,所述多个刀片服务器被配置为:当所述多个刀片服务器中的一个或更多刀片服务器接收到严重耗费资源的业务请求时,向所述负载分配器发送资源预留请求;并且所述一个或更多刀片服务器在接收到对资源预留请求的确认时开始处理所述严重耗费资源的业务请求;所述负载分配器被配置为:将超出所述一个或更多刀片服务器的处理能力的新输入业务量重定向至多个刀片服务器中的其他刀片服务器,直至从所述一个或更多刀片服务器接收到资源释放消息。
根据本发明的实施例,上述严重耗费资源的业务请求包括需要大量处理时间的业务请求和/或高CPU使用率的业务请求和/或将导致所述一个或更多刀片服务器进入过载状态的业务请求。
根据本发明的实施例,一个或更多刀片服务器在发送资源预留请求之前将所述业务请求置于资源预留等待列表。
根据本发明的实施例,所述电信设备的每一个刀片服务器都能监控本地的多个关键资源或负载状态,作为发起资源预留请求的依据。
根据本发明的实施例,所述严重耗费资源的业务请求是为大量端点进行注册的注册请求。
根据本发明的实施例,一个或更多刀片服务器接收到业务请求时,根据该业务请求将会消耗的资源量以及当前资源使用情况,确定该业务请求是否为严重耗费资源的业务请求,并且,一个或更多刀片服务器根据该业务请求将会消耗的资源量以及当前资源使用情况,在资源预留请求中定义资源预留量。
根据本发明实施例的电信设备特别地但不是唯一地包括先进电信计算架构ATCA。
在本发明中,ATCA基座的每个刀片为其自己预留资源以处理特定消息,基于消息的状态,这些特定消息需要大量CPU成本和处理时间。流量分配模块与刀片配合以减少发送了资源预留请求的刀片的流量负载。在正常阶段,可以使用现有的算法进行流量分配;当刀片基于其本地记录的消息,接收需要较长处理时间及较大CPU成本的特定类型请求时,它向流量分配模块发送资源预留请求,流量分配模块将把普通流量重定向至其他刀片,而该刀片将处理特定消息以及在完成处理时释放预留的资源。
本发明先为特定请求预留资源,从而增加了特定请求的处理时间。但是当资源预留得到准许时,请求将具有受保障的资源以对其进行处理,这样整个处理持续时间的增加不会太多。另外,来自AGCF的注册请求通常将需要数分钟才能完成,与整个处理时间相比,用于资源预留的时间可以被忽略。
本发明首次提出考虑使用资源预留机制来为基于ATCA的产品调度流量,并且本发明也是首次在基于事务的应用上提出资源预留的概念。
本发明的实施例考虑了一些IMS服务的特殊性并且为来自那些服务的请求预留资源。它解决了ATCA产品为了支持这些新服务时遇到的过度设计问题。本发明的实施例使用资源预留算法以暂时地重新调度流量并且在一个刀片中留出足够性能来处理这些将严重耗费资源的请求。同时,本发明的解决方案使得基于ATCA的产品具有更好的鲁棒性和具有更高的性能。尽管已经有一些描述调度算法的工作,但是所有这些工作基于周期性地监控/收集来自每个RT刀片的信息,并且这些工作都无助于解决特定请求导致的资源紧缺问题。
附图说明
通过考虑以下结合附图的详细描述,可以容易理解本发明的内容,在所述附图中:
图1概略示出ATCA基座的框图;
图2示出在ATCA基座中使用轮询调度算法的例子;
图3示出在ATCA基座中使用基于CPU的负载均衡算法的例子;
图4示出在IMS架构中实施本发明的系统框图;
图5示出根据本发明实施例的基于资源预留的解决方案简图;以及
图6示出在刀片服务器上实施的基于资源预留的解决方案流程图。
具体实施方式
本发明的解决方案可以位于任何基于ATCA的产品内,例如IMSHSS、AGCF和CSCF等。图4示出该解决方案位于IMS网络内的例子。
对于每个网络单元来说,它可以记录一些特定类型消息的处理时间和资源花费。例如,HSS可以记录为了处理来自包括3万个端点的AGCF的注册请求,它需要使用30%的CPU使用率处理5分钟。HSS可以从历史数据或者从性能测试的输入得到该信息。
图5示出基于资源预留解决方案的流量分配的处理示例。在该解决方案中,外部网络单元,例如图中的AGCF,向HSS的负载分配器发送请求。因为在请求的特征上没有包含任何信息,负载分配器可以采取任何现有的机制来分配请求。当HSS的刀片服务器(例如RT1)接收这样的请求,如步骤501所示,它检查该请求是为数千端点进行注册用的并且发现它的CPU使用率在不过载的情况下不能支持该请求的处理。
于是,在步骤502中,它将请求置于资源预留等待列表并向负载分配器发送预留请求,例如该资源预留请求中可以要求预留30%的资源,预留多少资源量可以由RT1通过估算注册请求需要多少资源量以及当前的资源使用情况确定。
在接收该预留请求之后,负载分配器减少至RT1的流量并向RT1发送确认,如步骤503所示。
RT1在从负载分配器接收确认后即开始处理注册请求。在RT1结束处理注册请求之后,它向负载分配器送资源释放消息,负载分配器将增加到该刀片的流量负载以减少所有其他刀片的CPU使用率,这样整个基座的CPU使用率得到均衡。相关内容在下文中还将进行详细阐述。
刀片RT的CPU使用率只是从RT向负载分配器发送的资源消息的一个例子。对于SDMHSS,在每个RT刀片中监控许多关键资源/状态,并且这些关键资源/状态可以用于为刀片请求资源预留的指标。
下面介绍负载分配器中基于资源预留的负载分配的一个示例性算法。
输入:资源预留请求qk(t),流量速率λk(t),k=1,...,N.
输出:刀片k的流量分配规则Dk(t+1)(%o流量向刀片k分配)在下一个时间段k=1,...,N,其中N是一个基座中的最大刀片数。
1.对于每个时间段t,获得刀片k的输入流量速率:
λk(t),k=1,...,N,N是激活的刀片的总数。
2.如果接收来自刀片k的资源预留请求qk(t),设预留标记
rk=rk+1.,Qk=Qk+qk(t).Qk是刀片k所请求的总预留资源。
3.获得标记rk>0的刀片N1的总数。
4.如果(N1==0){
基于轮询调度算法或CPU负载(如果可用)计算分配规则否则如果IF(N1>0){
5.对于具有Qk的刀片k,计算刀片k的处理速率,计算刀片k在下一时间段
(t+1)的流量是:
λk(t+1)=λk(t)-Qk(t)λk(t),对于具有Qk(t)>0的刀片k
对于没有发送资源预留请求的刀片。
6.计算分配规则:
Dk(t+1)是在(t+1)间隔刀片k的分配规则(%o的流量分配给刀片k)}
7.向已经请求预留资源但是还没有确认的刀片发送资源预留确认消息。
8.当从刀片接收到资源预留释放消息时,设置rk=rk-1.Qk(t)=Qk-qk.然后返回步骤3。
图6介绍了RT刀片中的资源预留过程。
如步骤601所示,在某个刀片服务器处,例如图5中的RT1,接收到来自AGCF的注册消息时,它通过历史数据或者测试结果了解到处理该消息将需要x%的资源成本(例如x%的CPU使用率),而它目前的资源使用率是y%(例如y%的CPU使用率)。
在步骤602中,RT1将判断该消息是否为耗费大量处理资源的消息,例如可以通过该式进行判断:
1-x%-y%>10%
如果处理该消息将耗费的比例x%过高和/或当前资源消耗y%过高,未能满足上式要求,则方法进行到步骤603,否则说明RT1仍有足够资源来处理该注册消息,则将该注册消息在步骤606中作为普通的流量进行处理。
在步骤603中,刀片TR1将向负载分配器发送资源预留请求,例如请求预留30%或其他任何合适比例的资源以处理该注册消息。同时或之后,RT1可以将该注册消息放入等待列表。
如步骤604所示,在刀片RT1接收到来自负载分配器的资源预留确认后开始处理注册请求。并且在完成该注册请求的处理后向负载分配器发送资源释放消息,表明自己现在的负载状况可以继续处理其他业务,即步骤605。
根据本发明的技术方案带来以下显著优势:
※解决了基于ATCA的产品中存在的共同问题,而该问题通过其他现有解决方案无法得到解决。换句话说,为了处理不经常发生但是一旦发生就需要大量资源的请求,将系统设计成为这样的请求留出资源。
※该解决方案增强了整个系统的性能和服务质量,例如,为了支持网络中的一个AGCF单元,所有RT刀片需要至少30%的性能来处理其注册请求。采用本发明的算法,只需要性能的3%,这样可以解决整个节点27%的性能。
※当网络中有多个AGCF单元时,所有其他调度算法并不能确保所有这些注册请求都能以较好的质量进行处理,因为每个刀片上只预留了30%性能用于这些请求,并且当多个请求进入到一个RT刀片时,这种情况会超出其设计的性能并最终导致过载。本发明提出的机制可以有效调度所有这些请求,以确保一旦需要处理这样的请求能以较高的质量进行处理。
※根据本发明原理的解决方案不仅能很好地均衡ATCA设备中每个刀片的负载,还能确保系统的QoS。本发明所提出的实施例确保有足够的性能来处理特定的请求而不降低整个系统的QoS。
※根据本发明原理的解决方案考虑了每个刀片的动态处理性能和运行环境以自适应地分配流量,以便确保整个产品的质量和性能。
※简单并且易于实施。
以上描述的例子仅用于说明目的,因而,本发明不受这样的例子的限制。可以以各种其他方式使用此处描述的负载均衡机制。
应当注意,可以以软件和/或软件和硬件的组合实现本发明,例如,使用专用集成电路(ASIC)、通用计算机或任何其他硬件等同物。在一个实施例中,本发明负载均衡方法可以被集成到HSS中或者其他网络单元或应用中,来实现以上讨论的功能。同样,本发明的负载均衡算法(包括相关联的数据结构)可以被存储在计算机可读介质或载体上,例如,RAM存储器、磁或光驱动或盘等。
设想此处作为软件方法讨论的步骤中的一些可以在例如与处理器协作实施各种方法步骤的电路的硬件内实现。本发明的各部分可以被实现为计算机程序产品,其中,计算机指令当被计算机处理时调适计算机的操作,以便调用或另外提供本发明的方法和/或技术。用于调用本发明方法的指令可以被存储在固定的或可擦除的介质中和/或被存储在根据所述指令操作的计算设备内的工作存储器内。
尽管此处详细示出和描述了并入本发明内容的各种实施例,本领域的技术人员可以容易设计出很多其他仍旧并入这些内容的可变实施例。
Claims (11)
1.一种在包括多个刀片服务器和负载分配器的电信设备中执行负载均衡的方法,该方法包括:
当所述多个刀片服务器中的一个或更多刀片服务器接收到严重耗费资源的业务请求时,向所述负载分配器发送资源预留请求;
在接收到对所述负载分配器对资源预留请求的确认时,所述一个或更多刀片服务器开始处理所述严重耗费资源的业务请求;以及
所述负载分配器将超出所述一个或更多刀片服务器的处理能力的新输入业务量重定向至多个刀片服务器中的其他刀片服务器,直至从所述一个或更多刀片服务器接收到资源释放消息。
2.如权利要求1所述的方法,其中:
所述严重耗费资源的业务请求包括需要大量处理时间的业务请求和/或高CPU使用率的业务请求和/或将导致所述一个或更多刀片服务器进入过载状态的业务请求。
3.如权利要求1任一项所述的方法,进一步包括:
所述一个或更多刀片服务器接收到业务请求时,根据该业务请求将会消耗的资源量以及当前资源使用情况,确定该业务请求是否为严重耗费资源的业务请求,并且
所述一个或更多刀片服务器根据该业务请求将会消耗的资源量以及当前资源使用情况,在资源预留请求中定义资源预留量。
4.如权利要求1至3任一项所述的方法,其中所述一个或更多刀片服务器在发送资源预留请求之前将所述业务请求置于资源预留等待列表。
5.如权利要求1至3任一项所述的方法,其中所述一个或更多刀片服务器监控各自本地的多个关键资源或负载状态,作为发起资源预留请求的依据。
6.如权利要求2所述的方法,其中所述严重耗费资源的业务请求是为大量端点进行注册的注册请求。
7.一种包括多个刀片服务器和负载分配器的电信设备,其中:
所述多个刀片服务器被配置为:
当所述多个刀片服务器中的一个或更多刀片服务器接收到严重耗费资源的业务请求时,向所述负载分配器发送资源预留请求;并且
所述一个或更多刀片服务器在接收到对资源预留请求的确认时开始处理所述严重耗费资源的业务请求;
所述负载分配器被配置为:
将超出所述一个或更多刀片服务器的处理能力的新输入业务量重定向至多个刀片服务器中的其他刀片服务器,直至从所述一个或更多刀片服务器接收到资源释放消息。
8.如权利要求7所述的电信设备,其中所述严重耗费资源的业务请求包括需要大量处理时间的业务请求和/或高CPU使用率的业务请求和/或将导致所述刀片服务器进入过载状态的业务请求。
9.如权利要求7所述的电信设备,所述一个或更多刀片服务器进一步被配置为:
在接收到业务请求时,根据该业务请求将会消耗的资源量以及当前资源使用情况,确定该业务请求是否为严重耗费资源的业务请求,并且
根据该业务请求将会消耗的资源量以及当前资源使用情况,在资源预留请求中定义资源预留量。
10.如权利要求7至9任一项所述的电信设备,其中所述多个刀片服务器的一个或更多各自被配置为监控本地的多个关键资源或负载状态,作为发起资源预留请求的依据。
11.如权利要求7-9任一项所述的电信设备,其中所述电信设备包括先进电信计算架构ATCA。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410171659.3A CN105099934A (zh) | 2014-04-25 | 2014-04-25 | 在电信产品中进行负载均衡的方法和设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410171659.3A CN105099934A (zh) | 2014-04-25 | 2014-04-25 | 在电信产品中进行负载均衡的方法和设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN105099934A true CN105099934A (zh) | 2015-11-25 |
Family
ID=54579518
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410171659.3A Pending CN105099934A (zh) | 2014-04-25 | 2014-04-25 | 在电信产品中进行负载均衡的方法和设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105099934A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105847171A (zh) * | 2016-03-28 | 2016-08-10 | 乐视控股(北京)有限公司 | 网络设备过载保护方法 |
CN108449215A (zh) * | 2018-03-31 | 2018-08-24 | 甘肃万维信息技术有限责任公司 | 基于分布式服务器性能监控系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101207550A (zh) * | 2007-03-16 | 2008-06-25 | 中国科学技术大学 | 负载均衡系统及多种业务实现负载均衡的方法 |
CN101583148A (zh) * | 2008-05-16 | 2009-11-18 | 华为技术有限公司 | 一种通信设备过载处理方法及装置 |
CN102055654A (zh) * | 2009-11-10 | 2011-05-11 | 中兴通讯股份有限公司 | 一种进行网络设备负载均衡的方法及ip多媒体子系统 |
CN102420741A (zh) * | 2010-09-28 | 2012-04-18 | 朗讯科技投资有限公司 | 在基于atca的设备中调度通信流量的方法及装置 |
-
2014
- 2014-04-25 CN CN201410171659.3A patent/CN105099934A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101207550A (zh) * | 2007-03-16 | 2008-06-25 | 中国科学技术大学 | 负载均衡系统及多种业务实现负载均衡的方法 |
CN101583148A (zh) * | 2008-05-16 | 2009-11-18 | 华为技术有限公司 | 一种通信设备过载处理方法及装置 |
CN102055654A (zh) * | 2009-11-10 | 2011-05-11 | 中兴通讯股份有限公司 | 一种进行网络设备负载均衡的方法及ip多媒体子系统 |
CN102420741A (zh) * | 2010-09-28 | 2012-04-18 | 朗讯科技投资有限公司 | 在基于atca的设备中调度通信流量的方法及装置 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105847171A (zh) * | 2016-03-28 | 2016-08-10 | 乐视控股(北京)有限公司 | 网络设备过载保护方法 |
CN108449215A (zh) * | 2018-03-31 | 2018-08-24 | 甘肃万维信息技术有限责任公司 | 基于分布式服务器性能监控系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8095935B2 (en) | Adapting message delivery assignments with hashing and mapping techniques | |
US8386607B2 (en) | Method and system for utilizing a resource conductor to optimize resource management in a distributed computing environment | |
CN116547958A (zh) | 用于网络功能选择的排名处理的方法、系统和计算机可读介质 | |
CN110149392A (zh) | 一种推送消息的管理方法及装置 | |
CN102655503A (zh) | 使用共享资源池的资源分配 | |
CN103401947A (zh) | 多个服务器的任务分配方法和装置 | |
CN102281190A (zh) | 负载均衡装置组网方法以及服务器、客户端接入方法 | |
CN103532873B (zh) | 应用于分布式文件系统的流量控制策略 | |
EP2547144A1 (en) | Load sharing method, system and access server | |
CN103744735B (zh) | 一种多核资源的调度方法及装置 | |
CN108282526B (zh) | 双集群间服务器动态分配方法及系统 | |
US20210168078A1 (en) | Method, electronic device and computer program product of load balancing | |
KR101028298B1 (ko) | 통신 네트워크에서 데이터 처리 장치를 분배하는 방법 및 시스템 | |
CN102420741B (zh) | 在基于atca的设备中调度通信流量的方法及装置 | |
JP2009026221A (ja) | ビジネスプロセス運用管理システム、方法、プロセス運用管理装置およびそのプログラム | |
CN108737543B (zh) | 一种分布式物联网中间件及工作方法 | |
CN105099934A (zh) | 在电信产品中进行负载均衡的方法和设备 | |
CN109413117B (zh) | 分布式数据计算方法、装置、服务器及计算机存储介质 | |
CN106790354B (zh) | 一种防数据拥堵的通信方法及其装置 | |
CN115941604A (zh) | 一种流量分配方法、装置、设备、存储介质和程序产品 | |
CN106664613B (zh) | 一种带宽资源的分配方法和传送网控制器 | |
CN109905645B (zh) | 视频监控设备目录交换方法和联网平台 | |
CN112346853A (zh) | 用于分布应用的方法和设备 | |
JP5952775B2 (ja) | トラヒック制御装置、トラヒック制御方法、及びトラヒック制御プログラム | |
CN105591780B (zh) | 集群监测方法和设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
WD01 | Invention patent application deemed withdrawn after publication | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20151125 |