用于负载平衡的方法和装置的制作方法

文档序号:7608816阅读:142来源:国知局
专利名称:用于负载平衡的方法和装置的制作方法
技术领域
本发明涉及分布式处理系统的领域,并且更加具体而言,涉及负载平衡系统和方法的改进。
背景技术
经由某种负载平衡装置访问日益基于网络的服务和应用。例如,当基于网络的服务具有大量并行用户时,负载平衡能够使处理负载分布在多个后端服务器或应用之中。如果用户的数目随着时间增加,则可以增加额外的后端服务器以处理增加的负载,这对用户来说是完全透明的。负载平衡器可以例如接收对基于网络的服务的所有请求,并且基于系统的负载或一些其他参数将请求转发到合适的后端服务器。使用负载平衡器的一个优点是可以给服务提供单个外部可见的地址。
许多类型的网络服务(例如在因特网上使用超文本传输协议(HTTP)的那些服务)使用简单请求和响应机制。例如,因特网浏览器发送HTTP请求给应用,并且该应用以HTTP响应来回答。应用地址通常是负载平衡器的地址,然后该负载平衡器例如基于可用服务器的当前工作负载将请求路由到可用服务器。在许多这种情况下,所有请求都可以独立于所有其他请求(包括来自相同用户的连续请求)被处理。在这种情况下,通常不存在由相同后端服务器处理来自相同用户的不同请求的要求。换句话说,请求实际上是无上下文的并且不需要负载平衡器知道任何先前的请求以便确定将消息转发到哪个后端服务器。
在其他情况下,负载平衡器必须保存上下文信息以便确定消息应该被转发到哪个后端服务器。例如,在电信网络中,多条消息可以被发送到一个终端以及可以从一个终端发送多条消息以便与另一方建立呼叫。因此,相同的服务器处理与相同呼叫有关的不同消息通常是重要的。例如,当建立电话呼叫时,通常期望相同的后端服务器处理与呼叫建立有关的所有消息。这种类型的功能通常称为服务器亲合力。
为了提供服务器亲合力,需要负载平衡器存储一些上下文信息、例如每个消息的呼叫ID并且检查所接收的每个消息以确定该呼叫ID是否已经由给定的服务器处理,从而确保相同的后端服务器处理随后的具有相同呼叫ID的消息。这通常通过维持包含当前呼叫ID的细节的数据库以及后端服务器处理与每个呼叫ID有关的消息来实现。传统电话系统的许多方面通常以这种方式起作用。
在传统电话应用中,可以仅仅在呼叫建立期间需要服务器亲合力,该呼叫建立通常仅仅持续几秒。因此,一旦已经建立呼叫,负载平衡器可以删除对该呼叫ID的所有引用,从而释放数据库中的空间。
然而,包括一些新电话协议(例如,会话初始协议(SIP))的许多其他系统以充分不同的不再适合调整常规负载平衡方法的方式起作用。
SIP例如是应用层控制或信令协议,用于主要在因特网协议(IP)网络上建立、修改和终止实时呼叫和会议。最简单的是,SIP中的呼叫建立需要两个事务一个事务用于建立呼叫;而一个事务用于释放该呼叫。SIP事务通常仅仅持续几秒,然而,SIP呼叫理论上是无限制的。由于SIP的特性,例如在呼叫腿可以被增加到当前呼叫的情况下,可以在任何时间改变媒体类型等等,通常需要属于相同呼叫的SIP消息由相同的后端服务器进行处理。
因此,诸如在负载平衡器上维持所有有效呼叫的上下文信息的数据库之类的传统负载平衡方法由于多种原因而不能被适当调整以用于SIP。首先,由于SIP呼叫的长度理论上是无限制的并且由于负载平衡器通常必须在每个呼叫的持续时间内存储呼叫上下文信息的事实,所以可能的是,特别是如果同时发生的呼叫的数目和后端服务器的数目很大,则负载平衡器可能变得应接不暇。这些约束可能影响这种负载平衡器的性能能力并且限制其消息处理能力。

发明内容
因此,本发明的一个目的是提供一种克服上述问题中的至少一些问题的系统。
根据第一方面,提供一种将以流的形式通过点到点连接传送到负载平衡元件的消息路由到多个可用处理系统之一的方法。每个可用处理系统通过单独的点到点连接与负载平衡元件连接,并且在负载平衡元件上包括从流中提取消息;在所提取的消息中检测标识可用处理系统之一的标识符的存在;以及在检测到标识符的存在的情况下,经由适当的连接将该消息转发到由此所标识的处理系统;否则确定用于处理该消息的目的地处理系统;将标识所确定的目的地处理系统的标识符插入到该消息中;以及经由适当的连接将该消息转发到处理系统。
有利地,这去除对负载平衡元件维持正被处理的所有当前呼叫的上下文数据库的需要,因此减少负载平衡器的处理负载。
在消息包括用于标识相关消息的消息标识符的情况下,该方法此外还包括维持消息标识符的数据库,其中针对该消息标识符,没有检测到目的地标识符连同指示将每个消息转发到了哪个可用处理系统的信息。
合适地,在接收到不具有目的地标识符的消息的情况下,对数据库进行搜索以找到相关的消息标识符,并且在找到相关的标识符的情况下,将消息转发送其中所标识的处理系统。
优选地,在预定数量的时间之后删除数据库中的项。
优选地,点到点连接是传输控制协议(TCP)连接,并且消息是会话初始协议(SIP)消息。
插入步骤优选地包括将目的地标识符插入到SIP消息的扩展报头中。
根据第二方面,提供一种将以流的形式通过点到点连接传送的消息路由到多个可用处理系统之一的负载平衡元件,每个可用处理系统通过单独的点到点连接与该负载平衡元件连接。该负载平衡元件优选地包括消息处理器,用于从流中提取消息;消息分析器,用于在所接收的消息中检测标识可用处理系统之一的标识符的存在;和消息转发器,用于经由适当的连接将消息转发到由此所标识的处理系统。
当没有检测到目的地标识符的存在时,负载平衡元件此外还包括负载分析器,用于确定处理该消息的目的地处理系统;以及消息处理器,用于将标识所确定的目的地处理系统的目的地标识符插入到该消息中。
每个消息优选地包括用于标识相关消息的消息标识符,负载平衡元件此外还包括用于存储消息标识符的细节的数据库,其中针对该消息标识符没有检测到目的地标识符连同指示将每个消息转发到了哪个可用处理系统的信息。
在接收到不具有目的地标识符的消息的情况下,负载平衡元件此外还包括用于对数据库进行搜索以便找到相关消息标识符以及用于标识应将消息转发到哪个处理系统的装置。
优选地,负载平衡元件适合于在每个点到点连接是传输控制协议(TCP)连接的情况下使用,并且其中该消息是会话初始协议(SIP)消息。
合适地,消息处理器适合于将目的地标识符插入到SIP消息的扩展报头中。
根据另一方面,提供一种包括根据先前提及的元件中任一元件的元件的会话初始协议(SIP)网络。
根据又一方面,提供一种根据上述步骤中任一步骤工作的会话初始协议(SIP)网络。


现在将参考附图通过非限制性例子来描述本发明的实施例,其中图1是示出根据现有技术的简单SIP网络布置的概观的框图;图2是示出根据现有技术的背对背用户代理(B2BUA)的框图;图3是示出根据本发明实施例的包括负载平衡系统的SIP网络的框图;图4是概述根据本发明实施例工作的负载平衡器的示例处理步骤的流程图;图5是示出示例响应消息的框图。
具体实施例方式
图1是示出根据现有技术的简单SIP网络布置100的概观的框图。示出了多个终端,它们可以是SIP用户代理(SUA)102、104和106。用户代理可以在彼此之间建立呼叫,并且也可以访问增值服务,例如由背对背用户代理(B2BUA)112提供的预付费记帐、会议等等。
SIP消息包括多个不同的字段,包括
TO字段,标识预定目的地的统一资源标识符(URI);From字段,标识源的URI;一个或多个Via字段,指示到达目的地所采用或要采用的中间跳点;Call-ID字段,它对于呼叫来说是全球唯一的标识符。
例如,如果用户代理102想要对用户代理104进行预付费呼叫,则将SIP INVITE消息发送到SIP代理服务器110,该SIP INVITE消息具有标识代理110的URI的Via字段、标识用户代理102的URI的From字段、以及标识用户代理104的URI的TO字段。SIP代理110将用户代理102的地址识别为预付费用户并且把该消息转发到B2BUA112,该B2BUA112在经由SIP代理114将呼叫连接到用户代理104之前执行必要的帐户验证以及信用检查。
通常,上述的增值服务可以被配置在分布式处理装置中,如图2中所示,图2示出根据现有技术的B2BUA112。
设置有负载平衡器202,该负载平衡器202接收发送到B2BUA112的所有输入消息。如上所述,使用负载平衡器的优点之一是网络仅仅看到单个外部网络地址。负载平衡器202将所接收的每个消息转发到多个后端服务器206、208、210之一,这些后端服务器执行所需的处理操作。这种处理操作可以例如包括预付费记帐、信用卡授权、入口验证等等。负载平衡器202可以确定哪个后端服务器使用任一适当的算法,例如最小负载、轮叫(round robin)等等。应该理解的是,尽管负载平衡器和后端服务器被示出为被集成到B2BUA112中,但是这些元件可以例如以分布式方式位于其外部。
因为由相同的后端服务器来处理与相同呼叫有关的所有SIP消息通常是有利的,所以负载平衡器202维持具有所有当前SIP呼叫连同相关呼叫ID以及正处理该呼叫的后端服务器的标识的上下文数据库204。另外,从后端服务器206、208或210发送到用户代理的消息也通过负载平衡器202以便负载平衡器能够确定SIP呼叫何时已终止,由此允许负载平衡器清除数据库204。如先前提到的,由于与可由B2BUA112处理的多个同时呼叫耦合的、SIP呼叫的理论上无止境的特性,所以数据库204必须足够大以处理来自B2BUA112能够支持的最大数目的同时呼叫的数据。
现在将参考图3-5来描述负载平衡机制和系统的实施例。
图3是示出根据本发明的一个实施例的、包括负载平衡系统的SIP网络布置的概观的框图。
示出了多个SIP用户代理302、304和306。SIP用户代理被布置用于对(未示出的)其他SIP用户代理进行例如预付费呼叫。SIP用户代理302和304被配置为使用SIP代理308,而SIP用户代理306被配置为使用SIP代理310。当SIP用户代理中的任一个想进行呼叫时,SIP INVITE消息最初被发送到适当的SIP代理308或310。该SIP消息的Via字段标识相关代理的URI,From字段标识发端SIP用户代理的URI,TO字段标识被叫方的URI。
SIP代理服务器308和310中的每一个可以将发端SIP用户代理、例如SIP用户代理302的地址识别为预付费用户。如果发端SUA被识别为预付费用户,则SIP INVITE消息被转发到B2BUA300,该B2BUA 300在以正常方式连接呼叫之前例如执行必要的帐户验证、信用检查等等。以分布式方式布置B2BUA300,其中负载平衡器313处理对B2BUA的所有请求,该负载平衡器313将处理任务分配到多个后端处理器314、316和318。尽管B2BUA的一个或多个元件、例如后端服务器被示为B2BUA 300的一部分,但是应该理解的是它们可以在地理上远离B2BUA300。
代理308和310中的每个分别经由所维持的单独的TCP连接309和311连接到B2BUA 300上。SUA 302、304和306可以使用TCP或者用户数据报协议(UDP)与它们各自的代理通信。预定送给B2BUA 300的由SIP代理308和310中的每个所接收的消息被插入或者多路复用到它们各自的TCP流中。例如,来自SIP用户代理302的SIP消息通过SIP代理308被多路复用在TCP流309中。如果不存在与B2BUA的TCP连接,例如如果代理所接收的消息在预定周期内不具有B2BUA的目的地URI,则建立新的TCP连接。类似地,如果在预定周期内在所述连接中没有检测到通信,则SIP代理可以关闭与B2BUA 300的TCP连接。
为点到点连接的TCP连接309和311终止于B2BUA 300的负载平衡元件313。多路复用器/解多路复用器(mux/demux)320从各种输入TCP流中提取输入SIP消息,并且将它们传送到负载平衡引擎312。mux/demux 320保存查找表、数据库等等326,存储消息的前一跳点(例如,SIP代理308或310)的IP地址连同TCP连接的标识符,其中在该TCP连接上接收了SIP消息。这将使响应消息能够被正确地路由回到消息发起人,正如下面进一步解释的。
负载平衡引擎312接收每个输入SIP消息并且执行负载平衡算法,如下面参考图4和5所描述的。特别地,图4是概述图3的负载平衡引擎312可能进行的示例处理步骤的流程图。在下面的描述中,为了解释的简单性,图4中所示的一些步骤最初没有讨论。
当与新呼叫有关的消息、例如SIP invite消息到达负载平衡引擎312时,负载平衡器选择(步骤710)可用的后端服务器314、316或318之一以使用诸如轮叫、最小负载等等之类的合适算法来处理该消息,正如本领域的技术人员将理解的一样。负载平衡引擎312在SIP消息中插入指示所选后端服务器的标识的标记(步骤714),并且将该消息转发到所选后端服务器(步骤716)。因为后端服务器314、316和318中的每一个单独地通过相应TCP连接315、317和319与负载平衡器313连接,所以mux/demux324被用于将消息多路复用到与所选后端服务器相连接的适当的TCP流中。然而,应该理解的是,mux/demux可以是任何种类的适当的消息或数据处理系统,其允许提取消息或数据或将消息或数据插入到现有流中。
优选地,所插入的标记包括足够的信息以使负载平衡引擎312能够将消息路由到后端服务器而不需要另外的呼叫上下文。换句话说,被选择来处理该消息的后端服务器的标识被包含在消息自身中。另外,该标记优选地被这样插入到SIP消息中,以致该标记将被包括在响应于该消息所发送的所有将来的消息中。例如,在SIP中,消息可以被适当地插入作为扩展报头。
如果在预定数量的时间内没有接收到响应,则SIP规定消息的重发。这可能产生的一个问题是例如如果后端服务器响应慢,或者如果初始消息丢失,则SIP用户代理可能重发相同的消息。如果这个消息碰巧是与呼叫相关的第一消息(即,不存在标记),则负载平衡器可能将这个消息发送到与处理第一消息的后端服务器不同的后端服务器。这导致系统针对单个SIP呼叫在不同后端服务器中创建多个呼叫上下文,例如如果相同的响应被发送到用户代理客户端,则这可能导致协议违反或者次最佳处理。
为了克服这一点,负载平衡引擎312优选地维持涉及新呼叫的所有消息的数据库328。因此,执行以下附加的步骤。例如,当接收到消息时,确定(步骤704)先前插入的标记是否存在。如果不存在,则这表示所接收的消息可能涉及新呼叫。然后,搜索新呼叫数据库328以确定具有相同呼叫标识的消息是否存在于数据库中(步骤708)。如果是的话,则该消息可能是例如在初始INVITE消息之后不久被发送的重发消息或CANCEL(删除)消息,并且一旦合适的标记已经被插入到消息中(步骤714),该消息就被转发(步骤716)到数据库中所指示的后端服务器。如果没有发现具有相同呼叫ID的消息,则这表示该消息是涉及呼叫的第一消息,在该情况下选择合适的后端服务器来处理该消息(步骤710)。随后,在新呼叫数据库328中创建呼叫上下文(步骤712),标记被增加到所接收的标识所选后端服务器的消息中(步骤714),并且以上述方式将消息转发到所选后端服务器(步骤716)。
从项在数据库中的创建开始的预定数据的时间之后,可以删除数据库中的项,因此在该时间之后,负载平衡器不能接受另外的涉及相同事务的未标记的消息。SIP超时周期被定义为32秒,因此,对于SIP来说,数据库中的项可以在这个时间之后被删除。
后端服务器314、316和318中的每一个都包括相应的mux/demux330、332和334,用于提取从负载平衡器313发送的SIP消息。必要时处理所提取的SIP消息。
SIP规范规定,对于TCP来说,从后端服务器发送到用户代理的响应消息必须经由相同的路径进行。于是,这防止后端服务器使用新的TCP连接直接与用户代理通信。为了满足这个要求,来自每个后端服务器的响应消息应该被发送回负载平衡器313,以便经由原始路径转发到合适的用户代理。
当后端服务器产生对SIP消息的响应时,SIP消息在TCP流中被发送。SIP消息的TO字段照常被设置为响应消息的最终目的地、例如SIP用户代理302,然后TCP流终止于负载平衡器313,因为如先前所提到的,后端服务器不能直接对SUA进行响应。然后,负载平衡器313必须确定将所接收的消息转发到何处。
为了实现这一点,后端服务器在专有消息1106中封装SIP响应消息,如图5中所示。图5示出了由后端服务器响应于先前所接收的SIP消息而产生的响应消息1100。消息1100包括通常的TCP报头1101,该TCP报头1101包括IP地址1102(例如,负载平衡器313的IP地址)和TCP标识符,该TCP标识符标识连接后端服务器与负载平衡器的TCP连接。这在后端服务器维持例如与其他B2BUA的多个TCP连接的情况下是特别必要的。专有消息1106包括SIP响应消息1110的下一跳点(即,SIP代理308)的被解析的IP地址1108。专有消息1106的IP地址1108优选地是通过执行DNS解析获得的、从SIP响应消息1110的Via字段中获得的前一跳点的URI的完全解析的IP地址。
负载平衡器313通过mux/demux324接收消息1100,该mux/demux324从输入的TCP流中提取消息1110。负载平衡器引擎312从专有消息1106中提取所解析的地址1108和SIP消息1110,并且基于IP地址1106来确定应该通过开放TCP连接309和311中的哪个来发送SIP响应消息1110。优选地,这通过在先前提到的查找表326中执行搜索或查找来实现。
最后,SIP响应消息1110通过mux/demux320被多路复用到所确定的TCP连接的流中,并且该消息被发送到合适的SIP代理,在该情况下为SIP代理308。
然而,应该注意的是,尽管SIP响应消息1110的TO字段是SIP用户代理302的SIP URI,但是经由TCP连接309将该响应消息发送给SIP代理308。这是因为SIP地址解析是基于逐跳执行的。SIP代理308从流309中提取输入消息并且基于SIP消息的TO字段中的URI将它们转发到合适的目的地。
正如本领域的技术人员所理解的,SIP要求相同事务内的消息使用相同的路径。然而,相同呼叫内的随后的事务可以绕过SIP代理308使用SIP用户代理302和SIP服务应用300之间的直接路径。例如,可以在SIP用户代理302和例如作为会议服务宿主的B2BUA之间建立SIP呼叫。一旦连接了这个呼叫,SIP用户代理302就可被用于使用直接路径将即时消息发送到会议服务器或另一被叫者。
如先前所描述的,在第一SIP消息的细节被存储在数据库中之后预定数量的时间,可以删除具有相应呼叫标识的所有项。以此方式,数据库328仅仅在32秒的最大值内包含给定呼叫标识的上下文信息。
在如上所述的这种系统中,负载平衡器的资源需求不再与所建立的呼叫的数目成比例,因为新建立的呼叫的上下文信息仅被要求由负载平衡器保存。
正如本领域的技术人员所理解的,通过负载平衡引擎312执行的在此所描述的功能可以以多种方式来提供,例如通过软件、通过合适的电子硬件或者软件和硬件的组合。例如,负载平衡引擎312可以包括合适的逻辑或功能元件,例如消息分析器,用于分析消息以确定是否存在所插入的标记;负载分析器,用于确定应该由哪个后端服务器处理消息;消息处理器,用于将标识标记插入到消息中,以及消息转发器,用于将消息转发到合适的后端服务器。可以以各种组合提供这种元件。
在于此所描述的实施例中,不需要对SIP用户代理进行修改,因为插入标记的效果实际上是明显的。此外,如果后端服务器出现故障,则负载平衡器313能够将消息转发到除了由所插入的标记所指示的后端服务器之外的备用服务器,而SIP用户代理永远不知道出现了故障。
权利要求
1.一种将以流的形式通过点到点连接传送到负载平衡元件的消息路由到多个可用处理系统之一的方法,每个可用处理系统通过单独的点到点连接与所述负载平衡元件连接,在所述负载平衡元件上包括从流中提取消息;在所提取的消息中检测标识所述可用处理系统之一的标识符的存在;以及在检测到所述标识符的存在的情况下,经由合适的连接将该消息转发到由此所标识的处理系统;否则确定用于处理该消息的目的地处理系统;将标识所确定的目的地处理系统的标识符插入到该消息中;以及经由合适的连接将该消息转发到处理系统。
2.根据权利要求1的方法,其中每个消息此外还包括用于标识相关消息的消息标识符,该方法此外还包括维持消息标识符的数据库,其中针对该消息标识符没有检测到目的地标识符连同指示将每个消息转发到了所述可用处理系统中的哪一个的信息。
3.根据权利要求2的方法,此外还包括,在接收到不具有目的地标识符的消息的情况下,搜索所述数据库以便找到相关的消息标识符,并且在找到相关的消息标识符的情况下,将该消息转发到其中所标识的处理系统。
4.根据前述任一权利要求的方法,此外还包括在预定数量的时间之后删除数据库中的项。
5.根据前述任一权利要求的方法,其中点到点连接是传输控制协议(TCP)连接,并且其中该消息是会话初始协议(SIP)消息。
6.根据前述任一权利要求的方法,其中所述插入步骤此外还包括将目的地标识符插入到SIP消息的扩展报头中。
7.一种将以流的形式通过点到点连接所传送的消息路由到多个可用处理系统之一的负载平衡元件,每个可用处理系统通过单独的点到点连接与所述负载平衡元件连接,在所述负载平衡元件上包括消息处理器,用于从流中提取消息;消息分析器,用于在所接收的消息中检测标识所述可用处理系统之一的标识符的存在;以及消息转发器,用于经由合适的连接将该消息转发到由此所标识的处理系统。
8.根据权利要求7的负载平衡元件,还包括在没有检测到目的地标识符的存在时,用于确定用于处理该消息的目的地处理系统的负载分析器;以及用于将标识所确定的目的地处理系统的目的地标识符插入到该消息中的消息处理器。
9.根据权利要求7或8的负载平衡元件,其中每个消息此外还包括用于标识相关消息的消息标识符,并且此外还包括用于存储消息标识符的细节的数据库,其中针对所述消息标识符没有检测到目的地标识符连同指示将每个消息转发到了所述可用处理系统中的哪一个的信息。
10.根据权利要求7、8或9的负载平衡元件,还包括在接收到不具有目的地标识符的消息的情况下用于搜索所述数据库以便找到相关的消息标识符以及用于标识应将该消息转发到哪个处理系统的装置。
11.根据权利要求7-10中任一权利要求的负载平衡元件,适于在每个点到点连接是传输控制协议(TCP)连接并且该消息是会话初始协议(SIP)消息的情况下使用。
12.根据权利要求7-11中任一权利要求的负载平衡元件,其中所述消息处理器适合于将所述目的地标识符插入到SIP消息的扩展报头中。
13.一种包括根据权利要求7-12中任一权利要求的元件的会话初始协议(SIP)网络。
14.一种根据权利要求1-6中任一权利要求所述的方法工作的会话初始协议(SIP)网络。
全文摘要
根据本发明的一个方面,提供一种将以流的形式通过点到点连接传送到负载平衡元件的消息输出到多个可用处理系统之一的方法,每个可用处理系统通过单独的点到点连接与负载平衡元件连接,在负载平衡元件上包括从流中提取消息;在所提取的消息中检测标识可用处理系统之一的标识符的存在;以及在检测到标识符的存在的情况下,经由合适的连接将该消息转发到由此所标识的处理系统;否则确定用于处理该消息的目的地处理系统;将标识所确定的目的地处理系统的标识符插入到该消息中;以及经由合适的连接将该消息转发到处理系统。
文档编号H04L29/08GK1875603SQ200480032570
公开日2006年12月6日 申请日期2004年7月12日 优先权日2003年10月30日
发明者J·福里西耶, R·盖罗, M·朗贝东, D·曼苏蒂 申请人:惠普开发有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1