CN104022891A - 一种全局负载均衡设备业务协调方法及装置 - Google Patents

Abstract

本发明提供一种全局负载均衡（GLB）设备业务协调方法，应用于数据中心的GLB设备上，该方法包括以下步骤：A、监控本GLB设备所属节点对的状态，并将该节点对状态更新到节点对状态表中；B、在收到DNS请求时，先检查节点对状态表中每一节点对是否正常，如果否，根据内部保存的DNS解析列表向发送DNS请求的节点返回第二DNS应答；如果是，查询就近性列表，如果命中到对应记录，则根据该记录返回第一DNS应答；否则返回第二DNS应答；其中所述其中第二DNS应答所携带的解析结果生存时间TTL小于第一DNS应答的TTL。本发明可以在整个数据中心GLB节点对准备就绪前在DNS上做出临时性处理，可有效规避DNS解析结果不确定性所引发的问题。

Description

一种全局负载均衡设备业务协调方法及装置

技术领域

本发明涉及数据通信领域，尤其涉及一种多数据中心环境下全局负载均衡设备间的业务协调方法及装置。

背景技术

传统的数据中心是单数据中心架构，其可能因为网络故障或者软硬件故障而产生的业务访问中断的风险。另外单数据中心还面临着用户跨地域、跨运营商访问的速度不如人意等问题。请参考图1，目前企业部署多数据中心目前已经成为一种趋势，借助多数据中心之间的冗余互备和就近接入机制等，可以保障关键业务系统的快速、持续、稳定的运行。

发明内容

有鉴于此，本发明提供一种全局负载均衡（GLB，Globe Loading Balance）设备业务协调装置，应用于数据中心的GLB设备上，其中该数据中心包括多个数据中心站点以及多个GLB设备，每任意两个GLB设备组成一个节点对，该装置包括状态管控单元以及DNS处理单元，其中：

状态管控单元，用于监控本GLB设备所属节点对的状态，并将该节点对状态更新到节点对状态表中；

DNS处理单元，用于在收到DNS请求时，先检查节点对状态表中每一GLB节点对是否均处于正常状态，如果否，则根据内部保存的DNS解析列表向发送DNS请求的节点返回第二DNS应答；如果是，则查询就近性列表，如果在就近性列表中命中到对应记录，则根据该对应记录向发送DNS请求的节点返回第一DNS应答；否则根据内部保存的DNS解析列表向发送DNS请求的节点返回第二DNS应答；

其中所述其中第二DNS应答所携带的解析结果生存时间TTL小于第一DNS应答所携带的TTL。

本发明同时还提供一种全局负载均衡（GLB）设备业务协调方法，应用于数据中心的GLB设备上，其中该数据中心包括多个数据中心站点以及多个GLB设备，每任意两个GLB设备组成一个节点对，其特征在于，该方法包括以下步骤：

步骤A、监控本GLB设备所属节点对的状态，并将该节点对状态更新到节点对状态表中；

步骤B、在收到DNS请求时，先检查节点对状态表中每一GLB节点对是否均处于正常状态，如果否，则根据内部保存的DNS解析列表向发送DNS请求的节点返回第二DNS应答；如果是，则查询就近性列表，如果在就近性列表中命中到对应记录，则根据该对应记录向发送DNS请求的节点返回第一DNS应答；否则根据内部保存的DNS解析列表向发送DNS请求的节点返回第二DNS应答；

其中所述其中第二DNS应答所携带的解析结果生存时间TTL小于第一DNS应答所携带的TTL。

本发明可以在整个数据中心GLB节点对准备就绪前在DNS上做出临时性处理，可有效规避DNS解析结果不确定性所引发的问题。

附图说明

图1是一种典型的多数据中心组网图。

图2是另一种多数据中心组网图。

图3是本发明一种实施方式中业务协调方法流程图。

图4是本发明一种实施方式中业务协调装置的逻辑结构图。

图5是本发明一种实施方式中节点对状态机示意图。

具体实施方式

网络管理者在构建了多个数据中心后，需要采用一些技术手段实现多个数据中心间的协调工作，引导用户访问最优的站点，始终保持数据中心给用户较佳的访问体验。在多数据中心的应用背景下，全局负载均衡（Global LoadBalancing）技术被广泛应用。该技术用于将同一服务（比如典型的Web服务）在多个数据中心同时发布，并通过在GLB节点上配置全局负载均衡策略，为用户的业务访问请求选择出最佳的站点进行服务，提高了用户跨地域、跨运营商访问的速度。多数据中心环境中，GLB能够实时的监控各个数据中心的运行状况，及时发现出现故障的数据中心或者其内部服务器，从而避免了用户业务中断的风险。从访问体验上，GLB也有其天然的优势；比如说，用户请求访问某个互联网门户站点的首页时，其在DNS过程中从GLB设备上获得的站点IP地址是一个其访问体验最佳的IP地址。

目前GLB技术支持的应用方式包括全局DNS智能解析以及HTTP重定向等。支持的调度策略包括：轮询、加权轮询、优先级（报文一直分给优先级高的全局服务器）、就近性调度等。正因如此，多个数据中心的GLB需要协同工作，采用高效的业务协调机制。本发明正是基于这样需求，提出了一种GLB设备间的业务协调方法及对应的装置。请参考图2、3以及图4，以软件实现为例，该装置是GLB的CPU执行内存中的计算机指令所形成的逻辑装置。该装置包括：状态管控单元、DNS处理单元、探测处理单元以及同步处理单元。该装置在运行过程中执行如下的处理流程。

步骤101，状态管控单元，监控自身所属的GLB节点对状态，并将每一GLB节点对状态更新到节点对状态表中；

在本发明中，每个数据中心可以理解为整个数据中心的一个数据中心站点（site），站点的数量与GLB设备的数量可以是一致的，也可以不同。对于每个GLB设备来说，初始的时候管理者可以在GLB设备的解析列表中配置DNS解析关系，也就是GLB设备所属站点内服务器提供服务的域名与IP地址之间的对应关系，当然这种对应关系也可能是该站点中其他设备上报的，比如本地LB（Loading Balance）设备。当然无论哪种方式这些数据通常是GLB设备运行本发明各种处理流程前获得的。其他GLB设备可以理解为对端GLB设备，为实现本发明目的，GLB设备与每个对端GLB设备构成一个GLB节点对，GLB设备上保存这些节点对的状态。

所述状态管控单元监控GLB节点对的状态可以采用以下的状态处理流程来确定。

对于每一个GLB设备，其内的状态管控单元所维护的每个GLB节点对状态图如图5所示。每个状态之间的变迁条件可以参考表1至表3所示。每个状态的定义如下：Init：初始化状态，此时等待初始化定时器超时，进入Start状态。Start:启动状态，此时可以向每个对端GLB设备发送HELLO报文，等待握手成功。Run:正常状态，此时握手成功，可以与对端GLB设备交互各种数据。状态管控单元按照表1到表3的操作定义来维护每个节点对的状态，及时将每个节点对的状态更新到节点对状态表中。

表1

表2

表3

在本发明优选的实施方式中，进一步将节点对状态表的记录与DNS处理过程形成联动。

步骤102，DNS处理单元在收到DNS请求时，先检查节点对状态表中每一GLB节点对是否均处于正常状态，如果是则转步骤103，否则转步骤105；

当DNS处理单元在收到DNS请求时，如果GLB设备内部保存的节点对状态均正常，本发明同步处理单元就可以互相同步DNS解析列表了。当同步完成之后GLB设备将进入步骤103，因为此时GLB设备了解到了整个数据中心中每个站点的解析列表，也就是说GLB设备知道了整个数据中心有哪些服务器，对外提供哪些服务，即其任意一个域名对应哪些IP地址。如前所述，由于一个特定的域名（比如www.abc.com）可能对应到多个服务器IP地址（1.1.1.1以及2.2.2.2），对于不同的用户来说，获得该域名最佳访问体验的服务器IP地址是不尽相同的。因此GLB设备需要根据就近性列表来为用户确定最佳服务器IP地址。

反之，如果DNS处理单元在收到DNS请求时，GLB设备1内部保存的节点对状态表中有任意一个节点对的状态没有处于Run状态的话，则说明有其他GLB设备还没有与本GLB设备成功握手。在没有握手成功之前，双方无法同步各自解析列表中的DNS解析关系等数据给对方。也就是说GLB设备1不知道对端GLB设备2所在站点中有哪些服务器对外提供什么服务。比如说，对于一个域名：www.abc.com（非真实数据，仅仅是示例），也许对端GLB设备2所在站点中有一个服务器也提供该域名的访问服务，该服务器IP地址（比如2.2.2.2）是www.abc.com这个域名对应的IP地址。同样的道理，本GLB设备1所在站点，可能也有服务器能够提供www.abc.com的访问，其IP地址是1.1.1.1。从整个数据中心承接对外访问业务来看，用户访问1.1.1.1或者2.2.2.2均可以实现对www.abc.com的访问，GLB设备需要在DNS解析过程中告知用户www.abc.com对应的IP地址。然而对于同一个用户来说，访问1.1.1.1与2.2.2.2，体验可能相差很大。当本GLB设备1没有获得对端GLB设备2同步过来的解析列表中，其无法确定IP地址1.1.1.1对于特定用户来说是www.abc.com的最佳DNS解析结果，那么此时，本发明将直接转入步骤105，为用户提供一个“临时性”的DNS解析结果。

步骤103，DNS处理单元根据DNS请求查询就近性列表，如果命中到对应的记录转步骤104，否则转步骤105；

如前所述，当DNS处理单元在收到DNS请求时，如果GLB设备内部保存的节点对状态均正常，此时，同步处理单元就可以互相同步DNS解析列表了。同步完成之后GLB设备就可以进入一个普通处理流程，因为此时GLB设备了解到了整个数据中心中每个站点的解析列表，也就是说GLB设备知道了整个数据中心有哪些服务器，对外提供哪些服务，即其任意一个域名对应哪些IP地址。如前所述，由于一个特定的域名（比如www.abc.com）可能对应到多个服务器IP地址（1.1.1.1以及2.2.2.2），对于不同的用户来说，获得该域名最佳访问体验的服务器IP地址是不尽相同的。因此GLB设备需要根据就近性列表来为用户确定最佳服务器IP地址。

步骤104，DNS处理单元根据命中的记录向发送DNS请求的节点返回第一DNS应答；

当GLB设备内部保存的节点对状态均正常，此时DNS处理单元将根据DNS请求查询其就近性列表，因此在此情形下，GLB设备已了解到整个数据中心中每个站点的解析列表，也就是说GLB设备知道了整个数据中心有哪些服务器，对外提供哪些服务，因此，DNS处理单元可以根据就近性列表来为用户确定最佳服务器IP地址，并将命中的结果向发送DNS请求的节点返回第一DNS应答。

步骤105，DNS处理单元根据内部保存的DNS解析列表向发送DNS请求的节点返回第二DNS应答，其中第二DNS应答所携带的生存时间TTL小于第一DNS应答所携带的TTL；转步骤106；

考虑到步骤102描述的GLB节点对可能存在不正常状态的情况，在本发明优选的方式中，如果有任何一个节点对状态不是正常状态，则意味着GLB设备并不知晓整个数据中心对外提供服务的状况，此时对于DNS请求需要做特别处理：返回一个TTL值特别小（比如1分钟）的DNS响应（第二DNS应答），TTL值代表了DNS解析结果的生存时间。举例来说，假设用户A访问www.abc.com时，其最佳访问的IP地址应该是2.2.2.2，由于GLB设备1的解析列表中没有www.abc.com与IP地址2.2.2.2的对应关系，因此其只能通过DNS响应返回IP地址1.1.1.1。但是IP地址1.1.1.1不是最佳的IP地址，为了提升用户体验，本发明将DNS响应所携带的TTL值设置很短的时间，可以使得用户本次DNS解析得到的结果“IP地址2.2.2.2”是一个相对“短暂”的或者说“临时性”的解析结果，很快就会过期。在解析结果过期之后，用户会再次发起DNS请求来获取新的解析结果。

需要说明的是，考虑到GLB节点对可能因为某些意外情况而长时间处于不正常状态，这将导致用户不断发起DNS请求以及GLB设备发送“临时性”DNS响应，进而致使GLB设备的计算资源被极大消耗。因此为了规避这个不常见的意外情况，在一种优选的方式中所述DNS处理单元还可以判断临时性DNS应答此时是否超过预设的一个阈值（具体可以为时间阈值或者发送临时性DNS应答阈值），如果超过该阈值，则后续发送DNS应答则使用第一DNS应答，避免用户频繁发起DNS请求。

另外，考虑到本发明装置在初始启动的时候，其就近性列表为空，在步骤103中有可能不能命中到对应的记录。例如：在某场景下，假设用户3.3.3.3第一次访问www.abc.com时，DNS处理单元查询就近性列表是无法命中任何记录的。此时DNS处理单元可以从解析列表中获取一个对应的IP地址（比如1.1.1.1）通过DNS应答发送给用户（也就是DNS请求者）。此时IP地址1.1.1.1可能不是最佳服务器的IP地址，因此DNS应答携带的TTL值同样可以设置为很短的TTL值，这里的处理跟此前的临时性处理一样。也就是说GLB设备在无法确定用户的最佳IP地址时一种临时处理手段。

本步骤描述的情况是节点状态表中有节点对状态处于非正常状态或者节点对状态虽然正常但没有命中到对应的记录时，GLB设备做出的临时性处理机制。

步骤106，在步骤103中没有命中到对应的记录时，探测处理单元向对端GLB设备发送探测请求以请求对端GLB设备针对发送DNS请求的节点发起就近性探测；并针对发送该DNS请求的节点发起就近性探测，将探测结果保存在就近性列表中；

在本步骤中，当DNS处理单元没有命中对应的记录时，其还将需要立刻通知探测处理单元针对用户（也就是发送DNS请求的节点）发起就近性探测，并将探测结果保存在就近性列表中。具体地，探测处理单元可以同时向所有对端GLB设备发送协助探测指令，要求所有对端GLB设备的探测处理单元针对同一个用户发起就近性探测。

通常，用户与GLB设备之间的通信质量可以反映出用户访问站点中各个服务器的体验。因此，GLB设备可以使用各种成熟的手段来对用户发起就近性探测，这里的探测未必是直接向用户IP地址发送探测报文，也可以其他间接的探测手段。探测的结果可以是响应时延等关键参数。请参考表4以及表5所示，GLB设备1与GLB设备2的就近性探测列表的示例。

序号	域名	服务器IP地址	用户IP地址	访问时延
					1	www.abc.com	1.1.1.1	3.3.3.3	0.5ms
.......	......	......	......	......

表4

序号	域名	服务器IP地址	用户IP地址	访问时延
					1	www.abc.com	2.2.2.2	3.3.3.3	0.1ms
.......	......	......	......	……

表5

GLB设备完成探测之后会将结果保存在就近性列表中。

步骤107，同步处理单元，将本次探测结果发送给对端GLB设备，并将对端GLB设备返回的探测结果与就近性列表中当前探测结果进行比较，保留最佳探测结果在所述就近性列表中；

GLB设备完成探测之后，通过同步处理单元将本次探测结果发送给对端GLB设备，并将对端GLB设备返回的探测结果与就近性列表中当前探测结果进行比较，保留最佳探测结果在所述就近性列表中。如上表4和表5所示，假设某应用场景下，GLB1收到GLB2的探测结果，由于服务器IP地址2.2.2.2的访问时延更短，因此对于用户3.3.3.3来说，最佳服务器IP地址是2.2.2.2，因此GLB设备1的同步处理单元会将表4中第一条记录更新掉，将服务器IP地址修改为2.2.2.2，将访问时延更新为0.1ms。

步骤108，同步处理单元，定期向对端GLB设备批量同步自身的就近性列表中保存的探测结果，并在收到对端GLB设备批量同步的探测结果时，向对端GLB设备发送确认消息。

在本发明优选的方式中，同步处理单元一般采用无需确认的方式来向对端GLB发送探测结果，也就是说同步处理单元发送探测结果之后无需对端GLB设备发送确认，或者说收到对端GLB设备发送的探测结果时，并不向对端发送任何确认。这样的设计可以在可靠性和性能表现上取得平衡。假设整个数据中心有4个GLB设备，针对一个IP地址的探测结果的同步GLB设备之间需要传递4×3个报文，如果短时间内需要针对成百上千个用户IP地址进行探测，那么GLB设备之间需要交互的报文数量将会比较庞大。如果每一次发送一个探测结果都需要对端GLB设备确认，那么GLB设备之间的报文交互数量会增加一倍，这可能会瞬间冲击网络和GLB的性能表现。正因如此，本发明优选方式中，在单次探测结果同步上采用无确认的同步方式进行处理。当然了，对于一些一次性的数据的同步或者说变化很少的数据的交互依然可以采用须确认的方式同步，比如说各个GLB设备上预先配置的解析列表，其变化通常比较少，或者说变化频率很低，因此同步这些数据的时候可以采用须确认的同步方式。

由于IP网络对报文的传输是采用尽力原则，也就是说携带探测结果的报文可能会中途丢失。因此在优选的实施方式中，同步处理单元进一步用于定期批量同步就近性列表中的探测结果，比如说每隔一个预定的时间间隔或者选择一个空闲时间段（比如凌晨时段）互相同步就近性列表中的探测结果。这样一来，可以避免冲击，同时可以在同一个同步报文中承载更多的探测结果，提高数据同步的效率。在批量同步时，同步处理单元可以使用须确认的同步方式进行处理。比如说，在凌晨时段进行批量同步，虽然有大量的确认，但由于数据中心业务已经非常空闲了，GLB设备性能和网络状况都足以承载这样的处理。

探测和单次同步结束后，GLB设备的就近性表项就用相应的记录了，用户再次发起DNS请求，或者其他用户针对同一个域名再次发起DNS请求时，DNS处理单元就会命中到对应的记录，此时DNS处理单元可以返回一个正常的DNS响应，所谓正常DNS响应是从TTL值来衡量的，其携带的TTL值比没有命中情况下发送的DNS响应所携带的TTL值要大，通常这两个TTL值会有一个或者多个数量级上的差距。

值得注意的是，以上所说的“用户”这一概念是从GLB的DNS处理过程来定义的，这个所谓的用户仅仅表明其是发送DNS请求的节点。事实上这个用户很可能是某个运营商的DNS服务器，因为DNS整个过程是逐级处理的，因此用户这一概念在更多层面是表明了一种业务处理的方向，而非特指执行访问的主体。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (10)

1.一种全局负载均衡（GLB）设备业务协调装置，应用于数据中心的GLB设备上，其中该数据中心包括多个数据中心站点以及多个GLB设备，每任意两个GLB设备组成一个节点对，该装置包括状态管控单元以及DNS处理单元，其特征在于：

状态管控单元，用于监控本GLB设备所属节点对的状态，并将该节点对状态更新到节点对状态表中；

DNS处理单元，用于在收到DNS请求时，先检查节点对状态表中每一GLB节点对是否均处于正常状态，如果否，则根据内部保存的DNS解析列表向发送DNS请求的节点返回第二DNS应答；如果是，则查询就近性列表，如果在就近性列表中命中到对应记录，则根据该对应记录向发送DNS请求的节点返回第一DNS应答；否则根据内部保存的DNS解析列表向发送DNS请求的节点返回第二DNS应答；

其中所述其中第二DNS应答所携带的解析结果生存时间TTL小于第一DNS应答所携带的TTL。

2.如权利要求1所述的装置，其特征在于，还包括：

探测处理单元，用于在DNS处理单元没有命中到对应的记录时，向节点对中的对端GLB设备发送探测请求以请求对端GLB设备针对发送DNS请求的节点发起就近性探测；并针对发送该DNS请求的节点发起就近性探测，将探测结果保存在就近性列表中；

同步处理单元，用于将本GLB设备本次探测结果同步给对端GLB设备，并将对端GLB设备返回的探测结果与就近性列表中当前探测结果进行比较，保留最优探测结果在所述就近性列表中。

3.如权利要求2所述的装置，其特征在于，所述同步处理单元同步所述本次探测结果的方式为无确认同步方式。

4.如权利要求2所述的装置，其特征在于，所述同步处理单元进一步用于定期向对端GLB设备批量同步自身的就近性列表中保存的探测结果，并在收到对端GLB设备批量同步的探测结果时，向对端GLB设备发送确认消息。

5.如权利要求1所述的装置，其特征在于，所述同步处理单元还将用于将本GLB设备的解析列表中的DNS解析关系同步给对端GLB设备，并将对端GLB设备同步过来的DNS解析关系保存在所述解析列表中。

6.一种全局负载均衡（GLB）设备业务协调方法，应用于数据中心的GLB设备上，其中该数据中心包括多个数据中心站点以及多个GLB设备，每两个GLB设备组成一个节点对，其特征在于，该方法包括以下步骤：

步骤A、监控本GLB设备所属节点对的状态，并将该节点对状态更新到节点对状态表中；

步骤B、在收到DNS请求时，先检查节点对状态表中每一GLB节点对是否均处于正常状态，如果否，则根据内部保存的DNS解析列表向发送DNS请求的节点返回第二DNS应答；如果是，则查询就近性列表，如果在就近性列表中命中到对应记录，则根据该对应记录向发送DNS请求的节点返回第一DNS应答；否则根据内部保存的DNS解析列表向发送DNS请求的节点返回第二DNS应答；

其中所述其中第二DNS应答所携带的解析结果生存时间TTL小于第一DNS应答所携带的TTL。

7.如权利要求6所述的方法，其特征在于，还包括：

步骤C、在DNS处理单元没有命中到对应的记录时，向节点对中的对端GLB设备发送探测请求以请求对端GLB设备针对发送DNS请求的节点发起就近性探测；并针对发送该DNS请求的节点发起就近性探测，将探测结果保存在就近性列表中；

步骤D、将本GLB设备本次探测结果同步给对端GLB设备，并将对端GLB设备返回的探测结果与就近性列表中当前探测结果进行比较，保留最优探测结果在所述就近性列表中。

8.如权利要求7所述的方法，其特征在于，所述步骤D中同步所述本次探测结果的方式为无确认同步方式。

9.如权利要求7所述的方法，其特征在于，还包括：

步骤E、定期向对端GLB设备批量同步自身的就近性列表中保存的探测结果，并在收到对端GLB设备批量同步的探测结果时，向对端GLB设备发送确认消息。

10.如权利要求6所述的方法，其特征在于，还包括：

步骤F、将本GLB设备的解析列表中的DNS解析关系同步给对端GLB设备，并将对端GLB设备同步过来的DNS解析关系保存在所述解析列表中。