CN1455347A - 一种分布式并行调度宽带网络服务器系统 - Google Patents

Abstract

本发明公开了一种分布式并行调度网络服务器系统，客户端与服务器端协作，调度信息拾取和调度请求处理异步进行；服务器群中每个节点都能接受和处理调度请求，调度过程体现为分布式并行。通过实现此分布式并行的输入输出调度接口，彻底消除了现有技术中存在的调度瓶颈问题。实施本发明能在现有硬件系统规模基础上支持更多的点播用户，极大地提高系统的可扩展性和对用户的负载能力，从而提高服务器系统整体的性价比。

Description

一种分布式并行调度宽带网络服务器系统

技术领域：

本发明涉及网络服务器，特别涉及宽带网络服务器，如：宽带视频服务器、宽带数据服务器等。

背景技术：

现有宽带网络服务器采用的方式有两种，以单个大型机形成的传统服务器和以多个高性能PC机组成的集群系统服务器。传统服务器不仅价格昂贵，而且在客户访问量不断扩大的情况下，可靠性不足，计算、处理、存储能力及系统带宽很难扩展，容易造成拥塞局面。计算机集群允许成千上万台标准个人计算机控制大量的数据密集型任务，运算成本低于目前的大型计算机系统的运算成本，并且具有高可用性、高系统吞吐率、高可扩充性、低成本、低用户响应延迟等特点。

集群系统CLUSTER：多台服务器(高性能PC机)以高速通用网络互联设备连接组成，并运行相关程序，统一调度，协调处理，实现高效并行处理的系统。具有能同时承担尽量多个用户/处理(请求)任务，高可用性，高可扩充性等特点。现有宽带网络服务器情况：1.TurboCluster

TurboCluster是一个企业级的集群方案，它允许在多个计算机上构建高可用的、可扩展的网络。使用TurboCluster系统可以显著地提高基于TCP/IP协议的多种网络服务的服务质量，这些服务包括Web、Mail、News和Ftp等。TurboCluster具有良好的可用性、可扩展性和可管理性，集群内部的实际服务器的数量可以扩充，其结构如图1所示。当客户机向服务器集群系统发送一个请求时，该请求首先到达高级流量管理器，高级流量管理器通过一定的调度策略将此请求转发到集群中的某一台实际服务器上处理，最终的回应请求将直接发送给客户机。由于最终的回应请求没有通过高级浏览管理器而是直接发送给客户，这样大大减轻了高级流量管理器上的负载，从而降低了瓶颈产生的可能。TurboCluster中采用的调度策略有：轮回(Round Robin)、加权轮回(Weighted Round Robin)、最少连接(Least Connection)。为了减少高级流量管理器产生失效的可能，TurboCluster为高级流量管理器准备了一个备份机。该备份机不断询问管理器来确认它正在正常工作，一旦发现主管理器已经失效，备份机将接替它继续工作。2.LinuxVirtualServer

Linux虚拟服务器(Linux Virtual Server，LVS)建筑于实际的服务器集群之上，用户看不到提供服务的多台实际服务器，而只能看见一台作为负载平衡器的服务器。实际的服务器通过高速局域网连接。实际服务器的前端是一台负载平衡器，他将用户的请求调度到实际服务器上完成，这样看起来好像所有服务都是通过虚拟服务器来完成的。Linux虚拟服务器能够提供良好的可扩展性、可靠性和可用性。用户可以透明地增加或减少一个节点，可以对实际服务器进行监测，如果发现有节点失败就重新配置系统。Linux Virtual Server的结构如图2所示。客户使用VIP(虚拟IP)地址访问服务器。其负载平衡的方案为：

1)网络地址转换(NAT)技术：负载平衡器在收到服务请求(IP包)后，按负载平衡算法，确定实际服务器，把该连接信息写入IP请求连接表，同时把该IP包的目的地址和端口号由VIP地址改为该服务器的IP地址和端口号，转发该IP包，实际服务器在完成请求任务后，把应答IP包送回负载平衡器，负载平衡器再把应答IP包的源地址改为VIP地址并转发到外部网络。

2)IP隧道(IP-TUNNEL)技术：负载平衡器在收到来自外部网络的服务请求IP后，封装源IP地址，然后以数据包形式，转发到某一实际服务器，实际服务器在完成请求任务后，直接按源IP地址把结果返回发出服务请求的客户机，这种方法的负载平衡器不再承担转发返回IP包的任务，负载就比NAT方法少了。

3)直接路由(DIRECT ROUTING)技术：这种方法的LVS有所不同，负载平衡器和实际服务器都处于同一段局域网，负载平衡器接受到客户机的服务请求IP包，负载平衡器分配给某一实际服务器，然后直接修改链路层的MAC地址为该实际服务器的MAC地址，把IP包转送到该实际服务器，在完成请求后，实际服务器也是直接把结果送到客户机。这一策略进一步减小了负载平衡器自身的负载。

从以上系统可以看出，为了最大限度地利用集群中的一切资源，集群系统需要具有动态负载平衡功能，它监视集群中的实际节点的负载情况并动态地进行调度的改变。可以说，调度功能的好坏直接影响系统的整体服务能力。不论是TurboCluster中采用高级流量管理器的调度方式，还是LVS虚拟服务器中实现的基于NAT、IP-TUNNEL或DIRECT ROUTING技术的调度方案，都可抽象为图3的集中式调度模型。

客户请求由单一的调度接口接收并排队，根据调度算法逐个转发给实际的服务器。显然随着系统规模(对于技术较先进的直接路由方式，最大服务器节点数超过100个)的扩大和用户访问量的增大，调度接口必将成为系统瓶颈。这使得在有大量客户请求到达时，便会因调度接口主机的严重超载，而使对客户请求的响应时间可能变得很长，超过客户容忍程度，甚至会误认为系统已不可用。更严重的是，如果这台特殊主机崩溃，整个系统即不可用，即使又自动选另一台或启动备用机作为新的调度接口主机，但瓶颈问题仍然没有根本解决。

本发明技术目的是实现一种分布式并行调度接口的宽带网络服务器系统，解决现有机群式宽带服务器对客户请求调度的瓶颈问题，缩短客户请求的响应时间，增强系统的可用性；极大地提高系统的可扩展性和负载能力，从而提高服务器系统整体的性价比。为了达到此目的，本发明采用的技术方案是：

客户机与服务器群协作，调度信息拾取和调度请求处理异步进行；服务器群中每个节点都能接受、处理和响应调度请求，调度过程体现为分布式并行。客户机请求调度的系统流程框图如图4所示，它的调度模型如图5所示。

通过实现本发明分布式并行的输入输出调度接口，可以彻底消除了现有技术中存在的调度瓶颈问题。本发明的工作步骤是：

本发明的实施分为异步的两个过程(如图4)：服务器信息拾取及维护过程B和客户请求调度过程A。

在尚未发起客户请求的时段，运行在各服务器中的调度服务端程序交互各服务器节点信息B1，运行在客户计算机中的调度客户端程序和服务器中的调度服务端程序定时通信，获得最近时段服务器群中各活动服务器节点及其提供的服务类型和服务能力等信息B2，并在本机中维护相关信息表。

当客户访问服务器时，客户计算机中的客户应用程序发出的客户请求通过调度客户端程序提供的访问接口从本机的信息表中随机获取一个有效(活动且有相关服务)服务器的地址A1，并向此服务器发起请求A2。由于是随机取得的服务器地址，不同客户计算机的请求会随机地分布到不同的服务器节点，这就解决了所有的请求从同一个调度接口进入服务器系统的瓶颈问题；

然后，接收客户请求的节点服务器根据当前系统状况和调度算法返回给客户一个真实服务器地址，由于当前服务器也在可选之列，通常被优先选中，此时客户计算机将直接与其建立通信连接，开始提供客户要求的应用服务，调度结束；

如果此服务器负载已过重(由调度算法决定)，不能对此请求提供服务，则返回给客户的会是一台负载较轻的服务器的地址，客户请求不用延迟等待，继续向新的服务器发送请求，从而能被此服务器接受并提供服务。

最坏的情况是，系统整体负载都很高，此时客户请求将根据调度服务端程序返回的服务器地址逐个尝试连接(每次连接时延约为十多毫秒)，只有当所有服务器都不能服务时才会放弃请求，不会出现前述集群系统中那种虽然服务器仍有服务能力，但因请求报文在调度接口阻塞，而使请求被拒绝的情况，提高了系统的可用性。

附图及附图说明：

图1是turbocluster服务器结构图

图2是Linux虚拟服务器结构图

图3是集中式调度模型图

图4是系统流程框图

图5是分布式并行调度模型图

图6是VOD服务系统结构图其中，c1，c2，c3...：访问本服务器的客户机，为通用个人计算机PC，通过100Mbps以太网络适配器连入Internet；安装运行windows2000操作系统、VOD客户应用软件和本发明的客户端软件模块。

局域网：连接服务器群内部各节点的物理网络通路；采用100Mbps以太网高速互联设备；Internet：连接客户计算机和服务器的网络通路；

s1，s2，s3，s4...：通用高性能PC机(带100Mbps以太网络适配器)，作为服务器提供VOD服务；安装运行linux操作系统；安装运行本发明的服务端软件模块和VOD服务应用软件。

图7是应用于VOD服务器的调度软件结构图

其中，调度服务端程序和调度客户端程序都采用C++语言编写。

图8是节点管理模块程序流程图

图9是应用服务器接口模块结构图

图11是调度子模块结构图

具体实施方式：

为达到技术效果的实施例为VOD(video on demand)视频点播系统应用。下面结合附图对其进行详细说明。

视频点播系统：通过高速上网技术连上各种宽带多媒体网站进行网上电影、电视、网络音乐、远程教育、会议、医疗等各种交互式活动。实施分两个阶段：第一阶段：客户机获得服务器群最新信息，对应图4的B过程。步骤1：启动调度服务端程序

要求服务器系统中每台主机(s1，s2，s3，s4)都运行调度服务端程序。调度服务端程序为多线程形式的守护进程，如图7，此程序包括节点管理、任务调度，应用服务接口和负荷拾取与维护等子模块。调度服务端程序维护有四张表：

服务名字-端口号映射表——表中的每一项是一个服务名字-端口号的映射，用于描述应用服务的访问入口。

主机更新索引表——用于更新节点主机信息时确定发送信息报文到哪台节点主机。

主机负载表——记录了系统中所有活动主机的负载情况。

服务-主机映射表——记录各台服务主机所提供的各项服务的信息。

启动调度服务端程序将首先引发节点管理子模块运行。其流程如图8，描述如下：

1、进行网络初始化工作：创建TCP通信套接字、UDP通信套接字并绑定到指定的端口，创建UNIX通信套接字。

2、将程序初始化为一个守护程序，1、2步的实现均为中等程序员所熟悉，在此不详述。

3、在服务器群内广播本节点信息，以此向其他活动主机节点声明本机加入系统。

4、产生一个线程，定时查看并处理主机更新索引表中各主机信息：主机更新索引表是以接收到此条记录的时标RecvTime的升序进行排序的，处理从头到尾进行。如果第一个元素的RecvTime与当前时间的差值小于一个更新周期UPD_HOST_TIME(根据系统规模用宏的方式定义)，则不作任何操作，等待下一次更新，因为主机更新索引表中的所有主机都在一个更新周期内发送了报文到本机。删除主机更新索引表中的死亡主机，RecvTime与当前时间的差值大于三个更新周期的元素都认为是死亡的主机。在删除死亡主机后，需删除主机负载表、服务-主机映射表中的相应主机记录。另外，如果有某些服务是这些死亡主机所独有的，还要在服务名字-端口号映射表中删除相应的服务信息。这时，主机更新索引表的最前面将有一些元素的RecvTime与当前时间的差值是在一个更新周期与三个更新周期之间，这些主机就需要进行更新——通过UDP通信套接字向它们发送本主机信息报文。但是对这些主机并不是全部更新，而是从中选择一部分进行更新，更新的最大数目是所有活动主机数目的1/3，这个数目的设计是考虑要在三个更新周期内更新完成所有的活动主机。

5、产生一个线程，定时检查本地服务名字-端口号映射表中的服务是否死亡。因为本地服务名字-端口号映射表中的每个元素都有一个提供服务的服务器进程号属性，就通过检查这个进程号对应的进程的状态是否活动来检查服务是否死亡。此线程同时启动一定时器，通过系统调用接口提取本机负载信息，更新主机-负载表中本机负载的项。

6、采用I/O多路复用select()来同时监听一个TCP通信端口(与客户机通信)、一个UDP通信端口(服务器节点机之间相互通信)和一个UNIX域套接字端口(与应用服务进程通信)。

7、主线程进入监听循环，等待接收各端口消息并分别产生各消息处理线程。消息处理描述：TCP消息：由调度客户端程序发起，主要是客户更新服务主机信息和名字服务映射。当调度服务端程序监听到一个TCP消息则生成一个线程处理，处理流程如下：

1.从TCP套接字读出消息；

2.判断消息中的版本号，如果版本号和系统信息当前版本一致，则发送一个空数据报文，否则，发送新版本的服务主机信息和服务映射信息(从各表中获取)；

3.关闭套接字，结束线程。UDP消息是服务节点机之间的通信，用于交互节点主机信息(负载，服务)。

当到达一个消息则生成一个线程，处理流程如下：

1.套接字中读出数据报，并验证其合法性；

2.据消息的类型，作不同的处理；

2.1节点机更新请求类型消息

①根据信源主机的地址，在更新索引表中查找该主机的更新信息。如果当前时间与该主机更新信息的发送时标send_time的间隔＜定时器时间T，则说明已经发送了消息给信源主机(相当于应答)，更新信源主机的接收时标recv_time，并按照主机的recv_time递减的方向进行排序。转②。如果时间间隔＞T，则通过本节点机中维护的各表组织应答的信息，发送给信源主机，同时更新send_time和recv_time，并按照主机的recv_time递减的方向进行排序。转②。如果没有找到该主机信息，说明接收到一个新启动的服务器节点发送的广播消息，也应该组织本地主机的消息，发送给信源主机，进行应答。然后在本机的更新索引表中增加该信源主机的send_time和recv_time，并按照主机的recv_time递减的方向进行排序。

②根据消息，更新服务-主机映射表、服务名字-端口号映射表；

③从消息中取得负载信息，更新主机-负载表；

④关闭套接字，结束线程。

2.2节点机更新应答类型消息

①根据信源主机的地址，在更新索引表中查找该主机的更新信息。更新信源主机的recv_time，并按照主机的recv_time递减的方向进行排序。

②根据，更新服务名字-端口号映射表、服务-主机映射表；

③从消息的负载项取得负载信息，更新主机-负载表；

④关闭套接字，结束线程。UNIX域消息：与VOD应用服务器进行通信，主要是应用服务器向本调度程序注册/注销相关服务，以获得在整个服务群内的调度支持，并通过此消息发起调度请求。当到达一个消息则生成一个线程，处理流程如下：

1.从套接字中读出消息，并验证其合法性；

2.根据消息的类型，作不同的处理；

①请求注册类型消息：在服务名字-端口号映射表中增加服务项，修改服务-服务器映射表。

②请求注销类型消息：在服务名字-端口号映射表中删除服务项，修改服务-服务器映射表。

③请求调度类型消息：调用调度子模块，并将返回服务器IP地址通过UNIX域套接字返回给

应用服务器。

3.关闭套接字，结束线程。步骤2：启动VOD服务器模块程序

为了使用本发明软件的功能，VOD服务器程序作为宽带服务的一种，在启动时需调用本软件提供的接口函数(以头文件形式提供)，通过前述的UNIX域消息向本软件调度服务端程序注册其应用服务——服务名及访问端口。步骤3：客户机(c1，c2，c3)运行调度客户端程序

调度客户端程序分为后台执行程序UPD.EXE和动态链接库SchedClientPro.DLL。，UPD.EXE要求在客户应用程序如VOD客户程序运行之前运行，一般安排在客户开启客户程序前通过操作系统启动运行或由VOD客户程序编制人员调用动态链接库提供的接口函数启动。此程序安装时，会在本机系统目录中生成一个可用服务器节点的IP地址的列表文件，其中的地址由安装过程很容易保证是可用的。

程序UPD.EXE在本机系统目录中的以文件形式维护有效服务器地址表、服务名字-端口映射列表、服务-服务器映射列表，其执行流程如图10。首先从有效服务器地址列表中随机获取一服务器地址，接着检查服务器信息版本号，此版本号保存在系统目录中的另一文件中，用于保证信息与服务器群的最新信息同步。如果没有找此文件(在初始安装时)，则生成它，并置初始版本号为0；向获得的服务器的系统调度端口发起TCP连接，如果连接失败，则尝试另外的地址，直至所有地址都不可用才失败返回；如前述，通过此连接，调度服务端程序组织服务器群的各项最新信息返回给本机，并在本地修改各表，成功返回。此后，调度客户端程序会定时重复以上操作，保证客户应用程序发起请求时，总能获得最新的有效的服务器地址。步骤4：启动VOD客户端程序

按照windows操作系统的应用软件通常的方式启动，本实施例无特殊要求。第二阶段：服务器调度客户请求，对应图4的A过程。步骤5：VOD客户程序调用本软件提供的动态链接库方式的接口函数，从调度客户程序随机获得一个或多个有效服务器地址。步骤6：VOD客户程序按照VOD服务自己的相关应用协议向该服务器节点机上的VOD服务程序的应用调度端口发起TCP连接请求，连接成功则发送应用调度请求报文，在极少情况连接不成功时，则认为此服务器地址无效，选取另一服务器地址发起连接请求。VOD服务程序接受请求连接后，再通过UNIX套节字向前述的节点管理子模块发送请求调度类型消息。步骤7：如图8，节点管理子模块收到一个UNIX消息，将产生一个子线程，由它调用任务调度子模块接口函数，并要求返回一个调度结果——提供应用服务的服务器节点IP地址。然后通过原UNIX套接字返回给VOD服务程序。如图11，任务调度子模块实现为多个可扩展的调度算法，如轮转服务法、加权轮转服务法、最少连接先服务法、本地优先法、有副本优先服务法等调度算法，不同算法的具体实现非本发明所限定，不在此赘述。根据应用类型不同调用函数可输入不同参数，使不同应用服务器可选取最合适的调度算法，如HTTP服务器可采用最少连接先服务法，FTP服务器可采用最小带宽使用量优先法。本实施例采取最少连接数加本机优先服务算法。步骤8：VOD服务程序通过TCP通信连接返回此调度结果给VOD客户程序；VOD客户程序立即开始与此服务器的数据传输端口建立应用数据传输连接，连接成功则可结束调度(实际情况往往如此)。极少情况下连接失败，则认为此地址的服务无效回到步骤5重复执行。

从以上步骤可以看出：客户请求随机发往服务器群中的任意有效服务器，能同时接收请求的服务器数将和活动服务器的总数相同，请求信息的带宽是现有系统的N倍(N为服务器节点数)，而且接收到请求的服务器能根据调度算法重定位客户请求，进一步防止了对请求的处理被阻塞在一台服务器的请求队列中，实现了动态负载平衡的功能。由此，我们可以得出结论：本发明彻底解决了VOD客户和VOD服务器系统之间调度瓶颈的问题，实施本发明能在现有硬件系统规模基础上支持更多的点播用户，极大地提高系统的可扩展性和对用户的负载能力，从而提高服务器系统整体的性价比。本发明实施例技术效果比较：

目前现有的一个宽带业务VOD系统满足6000用户的VOD点播，同时支持300个用户的正常并发点播，流连接的时间不超过20秒。其媒体服务器采用Sun 6000E系统，可存储300G以上的视频节目，但系统造价在200万人民币以上。

而本发明实施例系统：可以同时使用的用户数：100-10000户，服务器响应时间小于2秒钟，采用本发明方案的达到与上面系统相同或更好性能指标的系统只需不到50万人民币。

Claims (2)

1.一种分布式并行调度网络服务器系统，包括服务器和客户计算机，其特征是它执行下面步骤工作：

它采用异步的两个过程：服务器信息拾取及维护过程B和客户请求调度过程A。

从尚未发起客户请求的时段起，运行在各服务器中的调度服务端程序就交互各服务器节点信息B1，运行在客户计算机中的调度客户端程序和服务器中的调度服务端程序定时通信，获得最近时段服务器群中各活动服务器节点及其提供的服务类型和服务能力等信息B2，并在本机中维护相关信息表；

当客户访问服务器时，客户计算机中的应用客户请求通过调度客户端程序提供的访问接口随机获取一个或一组有效(活动且有相关服务)服务器的地址A1，并取一个向其发起请求A2；

然后，接收客户请求的服务器根据当前服务器系统状况经调度算法返回给客户一个真实服务器地址，此时客户计算机将直接与其建立应用通信连接，开始提供客户要求的应用服务，调度结束；

如果此服务器负载已过重，不能对此服务器请求提供服务，客户请求不用延迟等待，继续向新的服务器发送请求，从而能被新的服务器接受并提供服务。

2.根据权利要求1所述的一种分布式并行调度网络服务器系统，其特征是所述的分布式并行调度网络服务器是VOD视频点播系统，它采用的工作步骤是：分为两个阶段第一阶段：客户机获得服务器群最新信息步骤1：启动调度服务端程序

服务器系统中每台主机都运行调度服务端程序，调度服务端程序为多线程形式的守护进程，此程序包括节点管理、任务调度和负荷拾取及维护等子模块，启动调度服务端程序将首先引发节点管理子模块运行，其流程是：

1、进行网络初始化工作：创建TCP套接字、UDP套接字和UNIX套接字，并绑定到指定的端口；

2、将程序初始化为一个守护程序；

3、在服务器内广播本节点信息，向其他活动主机节点声明本机加入系统；

4、产生一个线程，定时查看并处理主机更新主机信息；

5、产生一个线程，定时检查本地服务名字-端口号映射表中的服务是否死亡；子线程启动定时器，通过接口提取负载信息；

6、采用I/0多路复用select()来同时监听一个TCP通信端口(与客户通信)、一个UDP通信端口(节点机之间相互通信)和一个UNIX域套接字端口(与应用服务器通信)；

7、主线程进入循环，接收各端口消息并处理消息；步骤2：启动VOD服务器模块程序步骤3：客户机运行调度客户端程序

程序执行流程是：首先从地址列表文件中随机获取一服务器地址，接着检查服务器信息版本号，此版本号保存在系统目录中的另一文件serverVer中，用于保证信息的最新性。如果没有找到此文件(在初始安装时)，则生成它，并置版本号为0；向发起TCP连接，如果连接失败，则尝试另外的地址，直至所有地址都不可用才失败返回；通过连接，获取服务器群的各项信息，并在本地生成最新的服务器IP地址列表、服务一服务器映射表和服务名字一服务端口映射表，成功返回；此后，调度客户端程序会定时重复以上操作，保证客户应用程序发起请求时，总能获得有效的服务器地址；步骤4：启动VOD客户端程序第二阶段：服务器调度客户请求步骤5：VOD客户程序调用本软件提供的动态链接库方式的接口，从调度客户程序随机获得一有效服务器地址；步骤6：VOD客户程序按照VOD服务自己的相关协议向该服务器上的VOD服务程序的应用调度端口发起TCP连接请求，连接成功则发送应用调度请求信息，在极少情况连接不成功时，则认为此服务器地址无效，回到步骤5，选取另一服务器地址发起连接请求；VOD服务程序接受请求连接后，再向前述的节点管理子模块UNIX套节字发送请求调度类消息；步骤7：节点管理子模块收到一个UNIX消息，将产生一个子线程，由它调用任务调度子模块接口函数，并要求返回一个调度结果——服务器地址；然后通过原UNIX套接字返回给VOD服务程序；任务调度子模块实现为多个可扩展的调度算法，如轮转服务法、加权轮转服务法、最少连接先服务法、本地优先法、有副本优先服务法等调度算法；步骤8：VOD服务程序通过TCP通信连接返回此调度结果给VOD客户程序；VOD客户程序立即开始与此服务器建立应用数据传输连接，连接成功则可结束调度。

Images