CN103731287A

CN103731287A - 一种故障接管服务器选择方法

Info

Publication number: CN103731287A
Application number: CN201210392297.1A
Authority: CN
Inventors: 张焰
Original assignee: WUXI YUNJIE TECHNOLOGY Co Ltd
Current assignee: WUXI YUNJIE TECHNOLOGY Co Ltd
Priority date: 2012-10-16
Filing date: 2012-10-16
Publication date: 2014-04-16

Abstract

本发明提供一种故障接管服务器选择方法，其包括：构建一个服务器池系统，其中所述服务器池系统包括服务器池、池化器和客户端，如果在数据交换中服务器发生故障，客户端进入故障切换模式；此时池化器一旦发现有服务器发生故障，立刻从其保持的服务器列表中删除该服务器，同时发送服务器更新消息给其他池化器，其他池化器接到该消息后，也同时从自己的服务器列表中删除该服务器；客户端重新在池化器处做一次池名解析，向池化器发送池名解析请求，池化器根据更新后的自身保持的服务器列表，并按照服务器池的均衡策略为用户重新选择一台被认为最佳的服务器IP，将结果返回给用户，完成故障接管服务器的选择。

Description

一种故障接管服务器选择方法

【技术领域】

本发明是关于计算机网络服务器领域，特别是关于网络服务器故障切换的技术领域。

【背景技术】

在典型的服务器-客户机模式下，服务器是由DNS域名确定其位置的，客户端应用系统在访问服务器之前必须通过使用DNS服务对其域名进行解析，从而得到该服务器的IP地址。在客户机和服务器建立连接后，就可以进行信息交换；假如这一服务器发生故障，客户机应用系统有两种可能的选择：1.中断通信;2.选择另一个服务器继续。

在这种模式下，客户端应用系统必须通过以下方式检测出服务器是否中断：

（1）服务器没有响应(time out)；

（2）服务器回应错误信息；

（3）收到传输层错误信息；

为了让客户应用程序能够在检测出服务器发生故障后，有选择其它服务器的可能，必须在其应用程序中明确提供一个服务器列表，指明：第一服务器、第二服务器、第三......等。当第一个服务器中断，则尝试和第二个服务器建立连接，再则第三，依此类推。

也就是说，这一故障切换过程是由用户程序的干涉而实现的，有较大局限性:

其一、服务器列表是静态的，必须有用户特别指明；

其二、替代服务器的选择有着较大的盲目性，无法保证所选服务器是否正常及有效，也不能因服务器的负载情况而灵活选择；

其三、接管是通过应用程序而实现，缺乏透明性；

其四、被动的中断识别方式；

其五、为满足可靠性的保证，应用程序开发量较大。

因为确有必要对现有技术进行改进。

【发明内容】

本发明的目的在于针对传统的服务器故障接管模式的不足，提出一种用户无需任何干预的故障接管服务器的选择方法。

为达成前述目的，本发明一种故障接管服务器选择方法，其包括：

构建一个服务器池系统，其中所述服务器池系统包括：

服务器池：服务器池是由一组具有相同功能的，并被统一管理起来的服务器组成，每个服务器池均使用唯一的池名作为标识；

池化器：是服务器池的管理设备，负责将多台服务器组成一个虚拟的服务器池，并对各台服务器的运行状态进行实时监控和采集；同时提供池名解析功能，以便能让用户方便地访问服务器；

客户端：访问服务器池的客户机；

如果在数据交换中服务器发生故障，客户端从传输层得到一个错误信息，客户端由此可以获知服务器端发生故障，这时，客户端进入故障切换模式；

此时池化器一旦发现有服务器发生故障，立刻从其保持的服务器列表中删除该服务器，同时发送服务器更新消息给其他池化器，其他池化器接到该消息后，也同时从自己的服务器列表中删除该服务器；

客户端重新在池化器处做一次池名解析，向池化器发送池名解析请求，池化器根据更新后的自身保持的服务器列表，并按照服务器池的均衡策略为用户重新选择一台被认为最佳的服务器IP，将结果返回给用户，完成故障接管服务器的选择。

根据本发明的一个实施例，所述服务器池采用登记机制，要求服务器在启动时需主动在池化器处进行登记，池化器中任意服务器启动后首先通过向池化器发送登记消息进行登记，其中该登记消息中包含有服务自身的相关信息，包括：池名、唯一的服务识别号、服务器IP地址、服务端口、服务协议、服务检测。

根据本发明的一个实施例，所述服务器池采用故障检测机制：在服务器池系统内，池化器对服务器进行周期性的健康状况检查，一旦发现服务器故障，池化器立刻将该服务器从服务器池中删除掉。

根据本发明的一个实施例，前述池化器对服务器进行周期性健康检查采用以下方式进行：如果池化器发出的持续活动消息，在设定时间内没有收到持续活动确认消息，则迅速连续发送几个持续活动消息，如果仍然没有收到持续活动确认消息，则可以判定服务器发生故障，如果池化器收到持续活动确认消息则表明服务器正常。

根据本发明的一个实施例，在持续活动确认消息中服务器附带了服务器自身的CPU使用率、网络使用率、内存使用率、硬盘使用率信息。

根据本发明的一个实施例，前述池化器对服务器进行周期性健康检查采用以下方式进行：池化器主动探测服务器IP及端口，主动创建服务器TCP连接，连接成功则表明服务器正常，否则表明服务器故障。

根据本发明的一个实施例，前述池化器对服务器进行周期性健康检查采用以下方式进行：池化器向服务器依照用户所使用的服务协议发送特定的协议，然后根据服务器的回答来判断服务器的状况，池化器如果收到的服务器状态码为正常，则表明服务器的服务是正常的，反之可以判断出服务器的服务异常，即服务器发生故障。

这种接管服务器选择方法的优点在于简单透明，无需在客户端维护一个服务器列表，只需随时简单地在池化器做池名解析即可，同时池化器的功能可保证任何时候服务器池中的服务器都是正常有效的，用户在池化器处做池名解析。

同时服务器增加、减少或IP地址变更都无需通知客户端做任何改动，对用户实现了完全的透明化。

简化应用程序开发量，应用程序只需在检测到服务器故障后，需要选择接管服务器时，做一次池名解析即可获得新的接管服务器IP。

【附图说明】

图1是本发明的服务器池系统的结构示意图。

图2为本发明的服务器池系统的工作流程图。

图3为本发明的登记消息格式示意图。

图4为本发明的登记消息格式中池名参数格式示意图。

图5为本发明的登记消息格式中服务器参数格式示意图。

图6为本发明的登记回应消息格式示意图。

图7为本发明的持续活动消息格式示意图。

图8为本发明的持续活动消息格式中系统参数的格式示意图。

图9为本发明的持续活动确认消息格式示意图。

图10为本发明的服务器更新消息格式示意图。

图11为本发明的故障接管服务器的选择方法流程图。

【具体实施方式】

此处所称的“一个实施例”或“实施例”是指可包含于本发明至少一个实现方式中的特定特征、结构或特性。在本说明书中不同地方出现的“在一个实施例中”并非均指同一个实施例，也不是单独的或选择性的与其他实施例互相排斥的实施例。

现有的服务器-客户机模式下，服务器是由DNS域名确定其位置的，客户端应用系统在访问服务器之前必须通过使用DNS服务对其域名进行解析，从而得到该服务器的IP地址。在客户机和服务器建立连接后，就可以进行信息交换。现有的技术，为了让客户应用程序能够在检测出服务器发生故障后，有选择其它服务器的可能，必须在其应用程序中明确提供一个服务器列表，指明：第一服务器、第二服务器、第三......等。当第一个服务器中断，则尝试和第二个服务器建立连接，再则第三，依此类推。这种方式故障接管服务器的选择，必须由应用程序指明各服务器的顺序，然后依次尝试连接每一服务器，接管服务器的选择必须依赖用户程序的设定，而且效率不高。

本发明针对现有技术选择故障接管服务器的缺陷，提出一种新的故障接管服务器的选择方法，本发明的故障接管服务器的选择方法须建立在服务器池框架下方能发挥其功能。服务器池的核心思想是让某项服务由多个冗余服务器同时来提供，所有这些服务器的集合被称为一个服务器池。也就是说：一项服务是由一个服务器池的整体来提供的，服务器是分布式的，均拥有各自的IP地址。当其中一个服务器因故障而不能继续提供服务的时候，可以由存在于服务器池中另一个正常运行的服务器继续提供。其系统示意图图1所示，本发明的服务器池系统由以下三个部分组成：

客户端：访问服务器池的客户机。

下面对本发明的服务器池系统的工作流程做详细说明，请参阅图2所示，本发明的服务器池系统的构建步骤如下：

步骤S1：首先建立服务器池，并为提供相同服务的服务器组成的服务器池命名，即池名，池名是服务器池唯一的标识名，是由若干个从a到z的26个拉丁字母及0到9的10个阿拉伯数字及“-”以及“.”符号构成的并按一定的层次和逻辑排列，命名方法与域名(Domain Name)是一致的。池名不能重复，具有相同服务的多台服务器拥有同一个池名。

步骤S2：在服务启动时，服务器需在池化器处进行登记，登记时要提供相关的系统信息，包括：池名，唯一的服务识别号、服务器IP地址、服务端口、服务协议、服务检测、均衡策略等。服务登记的过程是通过向池化器发送登记(registration)消息，到服务器收到池化器发回来的registration_response消息而完成，registration消息中包含了服务相关的池名信息和服务信息。请参阅图3至图5所示，其分别显示了本发明的登记消息格式示意图、本发明的登记消息格式中池名参数格式示意图、本发明的登记消息格式中服务器参数格式示意图。以及请参阅图6所示，其显示了本发明的登记回应消息格式示意图。

步骤S3：池化器收到登记消息后，将对其按照池名进行归类，保存在其内部的服务器列表（ServerList）之中，同时发布服务器更新消息(Server_Update)给其他池化器，将该服务登记信息同步到其他服务器里，从而保证所有池化器中的ServerList都是一致的。

步骤S4：池化器每隔一个时间段会对其主管服务器进行监控检查，一旦发现有服务器发生故障，立刻从其保持的服务器列表(ServerList)中删除该服务器，同时发送服务器更新消息给其他池化器，其他池化器接到该消息后，也同时从自己的服务器列表中删除该服务器。

步骤S5：池名解析：用户访问服务器池之前，必须向池化器发送池名解析请求，池化器根据自身保持的服务器列表，并按照服务器池的均衡策略为用户选择一台被认为最佳的服务器IP，将结果返回给用户；

步骤S6：用户访问服务器：根据池名解析的结果，用户直接与服务器建立连接，按照均衡策略，不同的用户通过池名解析，会获得不同的服务器IP，这样用户的访问量就被分配到不同的服务器上。

其中前述服务器状态监控的步骤中服务器健康检查采用以下方式进行：

方法一：向服务器发送持续活动消息（Keep_Alive），如果收到持续活动确认消息（Keep_Alive_Ack）则表明服务器正常；

方法二：池化器主动探测服务器IP及端口，主动创建服务器TCP连接，连接成功则表明服务器正常；

方法三：主动探测服务协议，池化器向服务器依照用户所使用的服务协议发送特定的协议，然后根据服务器的回答来判断服务器的状况。

其中方法一的具体的过程为：池化器每隔一个固定的时间间隔向该服务器发送持续活动消息Keep_Al ive。请参阅图7和图8所示，其分别显示本发明的一个实施例中保持活动消息的格式和保持活动消息中系统参数描述的格式。

服务器接到持续活动消息Keep_Al ive后，立刻以持续活动确认消息Keep_Alive_Ack回复给池化器。请参阅图9所示，其显示本发明的持续活动确认消息的格式。在持续活动确认消息Keep_Alive_Ack中服务器附带了自身的相关状态信息（比如：CPU使用率、网络使用率、内存使用率、硬盘使用率等）。这样池化器可以知晓服务器的实时系统状况，并可以参照作为依据判断服务器的状况。在一些情况下，虽然服务器运行都正常，但由于资源近乎消耗殆尽，例如CPU使用率、网络使用率、内存使用率、硬盘使用率等超过预定值，继续运行可能导致更大的问题，这种情况，池化器可提前预知，可将该服务器设置为故障服务器。

如果池化器发出的持续活动消息Keep_Alive，在设定时间（timeout）内没有收到持续活动确认消息Keep_Al ive_Ack，则迅速连续发送几个持续活动消息Keep_Alive，如果仍然没有收到持续活动确认消息Keep_Alive_Ack，则可以判定服务器发生故障，这种故障可能有多种可能：服务器宕机、软件故障、网络故障等，总之在这种情况下，用户肯定是无法使用该服务器的服务。

其中方法三的具体过程为：由于服务器在登记时，提供其自身服务的相关信息，比如：服务协议、IP地址、端口号、以及是否进行服务检测等信息，如果服务器需要进行服务检测(见图7中服务器参数Server Parameter，服务检测0x1为开，0x0为关),池化器根据这些信息，对该服务器进行周期性的服务可用性探测，方法是向指定的IP和端口按照其服务协议发送探测消息，然后通过服务器的回应判断其服务正常与否。

这里通过一个实例说明池化器如何通过服务器参数进行服务可用性探测：假设服务器A在登记时提供的信息为：

服务协议	http
		IP地址	192.168.100.9
服务端口	8080
		池名	www.test.com
服务检测	0x1

池化器根据这些信息，可模拟一次通常的用户使用浏览器的访问操作，然后根据其回应，探测其服务是否正常。池化器主动向192.168.100.9:8080发起建立一个tcp连接，并发送一条HTTP消息，内容如下：

GET/HTTP/1.1

Host:www.test.com

User-Agent:Moz i l la/5.0

Accept:*/*

如果服务器A的服务是正常的，池化器得到以下HTTP回复消息。

HTTP/1.1200OK

Date:Thu,27Sep201216:06:28GMT

Server:BWS/1.0

Content-Length:9783

Content-Type:text/html;charset=gbk

Cache-Control:private

其中第一行“HTTP/1.1200OK”中的200就是HTTP状态码，根据这个HTTP状态码就可以判断其服务器状况。

HTTP状态码说明如下（仅列举部分）：

HTTP状态码	说明
		200	正常
403	资源不可用
		404	无法找到指定位置的资源
503	服务不可用

按照以上的例子，池化器如果收到的HTTP状态码为200，则表明服务器A的服务是正常的，反之可以判断出服务器A的服务异常，即服务器A发生故障，随后可以做进一步的故障处理。

无论在哪个检测环节（Keep_Alive和服务检测）中池化器判断出某个服务器发生故障，都将立刻向其他池化器发送服务器更新消息要求池化器将该服务器从服务器列表中删除掉，也即前述的服务器信息同步步骤。请参阅图10所示，其显示本发明的一个实施例中服务器更新消息的格式，其中在该服务器更新消息中其中更新动作（Update Action）定义如下：

Update Action=0x1增加服务；

Update Action=0x2删除服务。

如果一旦某个与客户端正在进行数据交换的服务器出现故障时，需要选择一个新的接管服务器来继续为客户端提供数据，其中步骤包括：

步骤S11：如果在数据交换中该服务器发生故障，客户端从传输层（Transport Layer）得到一个错误信息，客户端由此可以获知服务器端发生故障，这时，客户端进入故障切换模式。

步骤S12：池化器一旦发现有服务器发生故障，立刻从其保持的服务器列表（ServerList）中删除该服务器，同时发送服务器更新消息给其他池化器，其他池化器接到该消息后，也同时从自己的服务器列表中删除该服务器。

步骤S13：客户端重新在池化器处做一次池名解析，向池化器发送池名解析请求，池化器根据更新后的自身保持的服务器列表，并按照服务器池的均衡策略为用户重新选择一台被认为最佳的服务器IP，将结果返回给用户，则用户与该新的接管服务器进行连接。

上述说明已经充分揭露了本发明的具体实施方式。需要指出的是，熟悉该领域的技术人员对本发明的具体实施方式所做的任何改动均不脱离本发明的权利要求书的范围。相应地，本发明的权利要求的范围也并不仅仅局限于前述具体实施方式。

Claims

1.一种故障接管服务器选择方法，其包括：

构建一个服务器池系统，其中所述服务器池系统包括：

客户端：访问服务器池的客户机；

2.如权利要求1所述的方法，其特征在于：所述服务器池采用登记机制，要求服务器在启动时需主动在池化器处进行登记，池化器中任意服务器启动后首先通过向池化器发送登记消息进行登记，其中该登记消息中包含有服务自身的相关信息，包括：池名、唯一的服务识别号、服务器IP地址、服务端口、服务协议、服务检测。

3.如权利要求1所述的方法，其特征在于：所述服务器池采用故障检测机制：在服务器池系统内，池化器对服务器进行周期性的健康状况检查，一旦发现服务器故障，池化器立刻将该服务器从服务器池中删除掉。

4.如权利要求3所述的方法，其特征在于：前述池化器对服务器进行周期性健康检查采用以下方式进行：如果池化器发出的持续活动消息，在设定时间内没有收到持续活动确认消息，则迅速连续发送几个持续活动消息，如果仍然没有收到持续活动确认消息，则可以判定服务器发生故障，如果池化器收到持续活动确认消息则表明服务器正常。

5.如权利要求4所述的方法，其特征在于：在持续活动确认消息中服务器附带了服务器自身的CPU使用率、网络使用率、内存使用率、硬盘使用率信息。

6.如权利要求3所述的方法，其特征在于：前述池化器对服务器进行周期性健康检查采用以下方式进行：池化器主动探测服务器IP及端口，主动创建服务器TCP连接，连接成功则表明服务器正常，否则表明服务器故障。

7.如权利要求3所述的方法，其特征在于：前述池化器对服务器进行周期性健康检查采用以下方式进行：池化器向服务器依照用户所使用的服务协议发送特定的协议，然后根据服务器的回答来判断服务器的状况，池化器如果收到的服务器状态码为正常，则表明服务器的服务是正常的，反之可以判断出服务器的服务异常，即服务器发生故障。