CN101809949B - 基于拉的并行视频服务器中的负载均衡和接纳调度 - Google Patents

Abstract

在视频点播系统中有用的基于拉的并行视频服务器系统及其实现方法，该基于拉的并行视频服务器系统包括多个从接纳调度器，所述从接纳调度器与主接纳调度器并行操作，以支持主接纳调度器，该主接纳调度器根据说明抖动和丢包以及网络延迟的协议，控制对基于拉的视频服务器的访问。提供传输协议来提高这种条件下的视频数据吞吐量。为了确定冗余接纳调度器的体系结构和功能要求，已经开发了性能模式的分析工具，该分析工具合并了客户、调度器和服务器之间的通信链路上的网络延迟、延迟抖动和丢包。

Description

基于拉的并行视频服务器中的负载均衡和接纳调度

相关申请的交叉引用 

不适用 

对在联邦赞助的研究和开发下实现的本发明的权利的声明 

不适用 

参照以光盘形式提交的“序列表”、表或计算机程序附录 

不适用 

背景技术

本发明涉及视频数据服务器技术，更具体地涉及基于并行服务器架构的视频点播系统及其相关的实现方法。更特别地，本发明涉及基于拉的并行视频服务器中的负载均衡和接纳调度。 

例如，Jack Y.B.Lee在1998年6月的IEEE多媒体第5(2)卷、第20-28页上发表的“Parallel Video Servers-A Tutorial(并行视频服务器-指南)”以及Jack Y.B.Lee和P.C.Wong在2000年1 2月的IEEE学报并行分布系统第11(12)卷、第217-231页发表的“PerformanceAnalysis of a Pull-Based Parallel Video Server(基于拉的并行视频服务器的性能分析)”研究和描述了基于拉的并行视频服务器配置。不要将这些配置与服务器推送服务模型混淆，例如W.J.Bolosky、J.S.Barrera、R.P.Draves、R.P.Fitzgerald、G.A.Gibson、M.B.Jones、S.P.Levi、N.P.Myhrvold和R.F.Rashid在关于支持数字音频和视频的网络和操作系统的第六次国际研讨会期间发表的“The Tiger Video Fileserver(触发器视频文件服务器)”描述了服务器推送服务模型。M.M.Buddhikot和G.M.Parulkar于1 996年4月在日本Zushi召开的IEEE计算机科学上发表的“Efficient Data Layout，Scheduling and Playout Control in MARS (MARS的有效数据格式、调度和播放控制)”Proc.NOSSDAV95，1995；以及M.Wu和W.Shu在1996年10月的关于大规模并行算法新领域的第六次学术会议第126-133页上发表的“Scheduling forLarge-Scale Parallel Video Servers(用于大规模并行视频服务器的调度)”。 

下面给出了表1，包括符号和用于下文评价的典型数值。 

符号	说明	值
			NS	服务器的数量	8
NC	客户的数量	80
			Q	视频条带大小	65536字节
LC	客户缓存器的数量	n/a
			Tavg	请求产生时间间隔的平均值	0.437s
TDV	请求产生时间间隔的最大偏移	0.29s
			Tround	接纳调度器的循环时间	3.495s
Nslot	接纳调度器中的时隙数量	80
			Tslot	接纳调度器时隙的长度	0.0437s
dA	客户-调度器延迟变量	n/a
			DA	平均的客户-调度器延迟	0.05s
DA +，DA -	客户-调度器延迟的抖动界限	0.005s
			dS	客户-服务器延迟变量	n/a
DS	平均的客户-服务器延迟	0.05s
			DS +，DS -	客户-服务器延迟的抖动界限	0.005s
Tout A，Tout S	客户-调度器和客户-服务器控制路径的   重发超时阈值	0.11s
			Nretx A，Nretx S	根据本发明，实施心跳协议。每个复制的接纳调度器经由通信链路38、40、42、每隔Thb秒将心跳包多点传送至所有其它的调度器。如果未从特定的调度器22接收到Nhb个连续心跳包，那么将被认为已经失败。忽略网络延迟，所有其它调度器24、26在最大延迟之后将发现调度器失败，该最大延迟如下式所示：   客户-调度器和客户-服务器控制路路径  的最大重发数	3
ρA，ρS	客户-调度器和客户-服务器控制路径的  丢包率	10-2
			β	控制路径的最大可容忍的丢包率	10-6

DPA +，DPS +	由客户-调度器和客户-服务器控制路径  中的重发引起的延迟抖动界限	0.22s
			NA	复制的接纳调度器的数量	n/a
DF	检测到调度器失败的最大延迟	n/a
			Thb	周期性心跳包的时间间隔	n/a
Nhb	说明调度器失败的连续丢包的最大数量	5
			Dmax	视频服务器处的最大服务延迟	n/a

并行视频服务器具有多个独立的服务器，这些服务器通过互连网络连接至客户主机。互连网络可通过分组交换机(例如，快速以太网或ATM交换机)实现。每个服务器具有单独的CPU、存储器、磁盘存储器和网络接口。所谓的无共享方案确保系统的可扩缩性不会受到资源竞争的限制。通过互连网络(例如，分组交换机)，客户从每个服务器逐块地取得视频数据，并且重新排列该视频数据用于播放。系统中服务器的数量可由N_S表示，客户的数量可由N_C表示。 

并行视频服务器架构背后的原理是将视频标题划分到系统的所有服务器上。服务器的存储空间可分为固定大小的条带单元，每个条带单元为Q个字节。然后，将每个视频标题划分为Q字节的块并且通过轮询方式存储到服务器中，如图2所示。固定大小的块划分算法在如上所述的Jack Y.B.Lee的“parallel Video Servers-A Tutorial(并行视频服务器-指南)”被称为“空间划分”，相对地，以视频帧的单元划分被称为“时间划分”。由于空间划分中的条带单元显著小于视频标题(千字节vs兆字节)，因此使得良好增益负载能够在服务器间共享。在下文中，在空间划分方面描述本发明。 

服务器级别的并行使用不仅打破了单个服务器的容量限制，而且通过冗余实现了服务器级别的容错。不同于服务器复制和数据划分，在并行方案中，将可得到的视频标题分为小的单元，然后通过所谓的服务器划分技术将其分布到并行视频服务器中的服务器上。然后，根据划分策略(空间和/或时间)从服务器取得视频标题的视频数据单元，经由通信网络传递至客户。 

由于视频标题分布在系统中的所有服务器上，因此首先必须从相应的服务器取得视频块，然后将它们合并成单个视频流并提交给客户用于播放。通常，视频数据合并处理(称为代理)可在服务器中实现(服务器端代理)，在单独的计算机中实现(独立的代理)，或者在客户计算机处实现(客户端代理)。在下文中，所描述的系统采用客户端代理体系结构。该选择为两方面：(a)较低的成本-不需要附加的服务器间数据传送(服务器端代理)或附加的硬件(独立的代理)；以及(b)更好的容错-代理的错误只影响在同一计算机上运行的客户。 

术语“服务模型”指调度视频数据并将其传递给客户的方式。有两种普通的服务模型：客户拉拽和服务器推送。在客户拉拽模型中，客户周期性地将请求发送至服务器以取得视频数据。在这种模型中，由客户驱动数据流。在服务器推送模型中，一旦视频会话开始，服务器调度周期性的视频数据取得和传送。 

在客户拉拽服务模型中，从客户发送的每个请求在独立于所有其它服务器的服务器处被服务。因此，这些服务器不需要时钟同步，因为同步包含在客户请求中。在下文中，假设使用客户拉拽服务模型。在不失普遍性的情况下，假设客户将请求i((i≥0)发送至第mod(i，N_S)个服务器。每个请求将触发服务器，以取得和传送Q字节的视频数据。 

在常规的单个服务器视频点播系统中不存在而在并行视频服务器视频点播系统中存在的问题是已知的负载均衡。当服务器通过小的条带尺寸在服务器上划分视频标题，以确保平均负载均衡时，服务器的瞬时负载可能因系统的随机性而改变。这种瞬时负载不均衡能够暂时降低服务器的性能，并且使客户处的视频播放中断。 

为了更好地理解本发明，在基于拉式服务的系统内考虑请求产生过程的分析模型是有用的。这个模型的一部分是由发明人之前所开发的并且如上所述命名为“Performance Analysis of a Pull-Based ParallelVideo Server(基于拉的并行视频服务器的性能分析)”。假设系统使用基于信用的流控制算法来管理从服务器到客户的数据流，客户保持L_C个视频数据缓冲器(每个缓冲器为Q字节)，以容纳系统延迟变化。 在播放开始之前，客户首先预取第一个(L_C-1)缓冲器，然后，在头一行视频块提交给视频解码器用于播放时，再请求一个视频块。 

假设视频客户产生平均请求间的时间间隔为T_avg秒的请求，那么考虑请求产生过程中的变化，假设T_DV为该过程中的最大偏移，从而任何k个连续请求之间的时间范围的界限如下： 

    max{(k-1)T_avg-T_DV)，0}≤t≤((k-1)T_avg+T_DV)        (1) 

由于客户以轮询的方式产生请求至N_S个服务器，因此发送至相同的服务器的任意k个连续请求之间的相应时间范围可从下式获得： 

    max{(k-1)N_ST_avg-T_DV)，0}≤t≤((k-1)N_ST_avg+T_DV)    (2) 

通过这种请求产生模型，可得到： 

定理1假设n个客户独立产生请求和每个客户以轮询的方式将请求发送至系统中的N_S个服务器，然后服务器接收k个视频数据请求的最小时间为： 

不考虑系统中服务器的数量，定理1说明如果多个客户同步，那么服务器能够同时接收多达n个请求 先前已经说明了这个客户同步问题严重限制了系统的可扩缩性。 

为了防止瞬时负载不均衡，使用接纳调度器精确地调度新视频会话的开始时间，以避免同步。以前，发明人和其他人提出了如图3(现有技术)第一行(a)所描绘的、用于在接纳调度器中使用的交错方案。调度器维持长度为T_round秒的调度映射表，并且分成长度为T_slot的N_slot个时隙： 

            T_slot＝T_round/N_slot(秒)              (4) 

每个时隙具有两种状态：空闲和占用。当客户想要开始新的视频会话时，首先将请求发送至调度器。忽略处理延迟并且假设请求在t时刻到达调度器，如果只有时隙n空闲，那么该调度器接纳新的会话，其中n由下式给出： 

            n＝[mod(t，T_round)T_slot]             (5) 

这由图3b(现有技术)中的第二行(b)示出。 

为了接纳新会话，调度器在时隙n开始时将响应发送回客户，并且将相应的时隙标记为被占用，直到会话结束。相反，如果所请求的时隙已经被占用，那么调度器将等待(有效地增加t)直到得到空闲的时隙，如图3(现有技术)的第三行(c)所示。通过设T_round＝N_ST_avg，得到下面定理2中最坏情况的负载。 

定理2如果通过参数T_round＝N_ST_avg使用接纳调度器并且有n个客户，那么服务器接收k个视频数据请求的最小时间为： 

其中u＝[(k-1)/n]，以及v＝mod(k-1，n) 

与定理1相比，请求是由接纳调度器传播的，从而基本上减少了最坏情况的负载。 

基于拉的VoD系统的关键性能指标是视频服务器处的服务延迟，由D_max表示。服务延迟被定义为从服务器接收到客户请求的时刻到全部发送完所请求的视频块的时刻。这个服务延迟确定了客户所需的缓冲器的量，以确保视频播放的连续性。由于服务延迟通常随着同时发生的视频会话的数量而增加，因此有效地利用对可由系统支持的同时发生的视频会话的最大数量的限制。给定定理2中的磁盘模型、网络模型和界限，可得到服务器延迟的上限。这个最大服务延迟用于评价不同参数下的系统性能。 

先前已经说明接纳调度器能够有效地防止瞬时负载不均衡，并且使系统扩展至大量的服务器。然而，有两个假设：(a)没有网络延迟以及(b)在传递控制消息时不丢包。迄今为止所描述的且如上所述从本发明人之前的论文“Performance Analysis of a Pull-Based ParallelVideo Server(基于拉的并行视频服务器的性能分析)”的模型不并入网络延迟和延迟抖动的影响，并且不考虑丢包。 

本发明人开发的现有模型中未考虑的问题是客户-调度器链路和客户-服务器链路中的丢包。尽管丢包在当今的高速网络中相对较少发生，但是它仍然不能被忽略。首先，在客户与调度器之间丢失控制包将使系统的状态不一致。例如，如果从调度器发送至客户的接纳-接受 请求丢失，那么客户可能在发现包丢失之前需要等待N_ST_avg的完整调度周期，由于在最坏的情况中，接纳调度器可能甚至因交错要求而需要延迟接纳新的会话。同时，即使客户从未开始视频会话，但是所分配的时隙将被占用相同的时间。结果，即使系统在容量之下运行，但是新的接纳请求也可能被拒绝。第二，由于服务器只有在接收到客户请求时发送视频数据，因此在客户-服务器链路中丢失控制包将导致丢失视频块。因此，用于客户-调度器链路和客户-服务器链路的控制路径必须可靠。 

为了解决丢包问题，可使用可靠的传输协议来运送控制包。然而，不同于传统的数据应用，传输协议的选择会对系统性能有显著影响。为了找到原因，将TCP作为客户-调度器链路的传输协议。如果发生丢包，TCP协议将超时并且重发包，直到包被正确传递或者链路被认为已经失败。由于大多数传输协议(包括TCP)使用自适应算法，以动态地调整超时阈值，所以如果需要多次重发，那么实质上增加了超时。 

在实践中，由这种传输协议引起的最坏情况的延迟可能长达几十秒。与平均网络延迟(毫秒)相比，如果使用这种传输协议运送控制业务，那么将显著增加服务器处的最坏情况的负载。 

已经确定可能发生瞬时负载不均衡，该瞬时负载不均衡显著妨碍拉式并行视频系统的性能。接纳调度器对保持系统中服务器上的瞬时负载均衡是至关重要的，其还可称为整个系统的失败单点。因此，需要一种体系结构和支持处理来避免基于拉的体系结构的失败点和性能恶化。 

发明内容

根据本发明，在点播视频系统中有用的基于拉的并行视频服务器系统及其实现方法包括多个从接纳调度器，从接纳调度器与主接纳调度器并行操作，以支持主接纳调度器，主接纳调度器根据说明抖动和丢包的协议以及网络延迟，控制对基于拉的视频服务器阵列的访问。提供在这种情况下提高视频数据吞吐量的传输协议。 

为了确定冗余接纳调度器的体系结构和功能要求，开发了性能模型形式的分析工具，该分析工具并入了客户、调度器和服务器之间通信链路的网络延迟、延迟抖动和丢包。这个模型是本发明人之前开发且在上述的“Performance Analysis of a Pull-Based Parallel Video Server(基于拉的并行视频服务器的性能分析)”所提到的模型的扩展。 

参照下面结合附图的详细描述将能更好地理解本发明。 

附图说明

图1是根据本发明的系统框图和根据本发明方法的操作； 

图2是根据一个现有技术发明的基于五个服务器的并行视频服务器系统的视频划分的图解； 

图3是图示了基于现有技术的视频调度器的三种操作的时隙图，即，(a)具有周期T_round和N_slot个接纳时隙的接纳调度器布局；(b)如果所请求的时隙空闲，那么立即准许新的视频会话；以及(c)延迟新的视频会话，直到得到空闲的时隙； 

图4是两个接纳调度器的时隙图，图示了可能在现有技术中发生的因时钟抖动而引起的时隙分配不一致； 

图5是在具有和没有接纳调度情况下比较最大服务延迟与平均网络延迟的时间图表。 

具体实施方式

图1是根据本发明的视频点播系统10的框图和根据本发明方法的操作，并且图示了复制的接纳调度器。通常，大量的视频客户12、14、16经由一个或多个通信链路18连接至接纳调度器22、24、26的集合20，接纳调度器22、24、26中的一个被指定为主接纳调度器20，其它接纳调度器被指定为从接纳调度器24、26。主接纳调度器20经由通信链路30连接至并行视频服务器28的集合，并且建立接纳映射表(该接纳映射表在从接纳调度器24、26的每一个中被独立复制)用于控制经由通信链路32、34、36输出至各自的视频客户12、14、16的流视频。接纳调度器彼此之间经由通信链路38、40、42进行多点传送， 如下文所解释的。 

基于如图1所描绘的复制方案，N_A个相同的接纳调度器22、24、26同时工作。每个接纳调度器22、24、26在单独的计算节点内运行，其目的是只要接纳调度器22、24、26中的至少一个仍然起作用，就保持系统运转。 

由于存在多于一个的接纳调度器，因此客户-调度器通信的协调是必要的。第一尝试可能是让客户将请求同时发送至所有N_A个调度器，一旦来自调度器中的任一个的应答返回，那么客户开始会话。然而，如果客户-调度器链路延迟不是恒定的或者调度器的时钟不同步，那么这个方法会导致接纳调度器之间的状态不一致。图4通过两个接纳调度器和三个客户图示了这个问题。请求的特定次序和调度器之间的时钟抖动导致两个调度器上不一致的时隙分配，因为接纳请求产生了彼此相比无序的接纳许可。 

为了解决这个问题，根据本发明，所采用的方案是在任一时间只有一个接纳调度器处于活动控制。主接纳调度器22负责通过经由通信链路38、40周期性地多点传送已更新的状态信息(接纳映射表)，从而更新其它从调度器24、26中的状态。这个方案中存在三个关键部分：(a)心跳协议，检测调度器失败；(b)选举程序，当当前的主调度器失败时动态地选举新的主调度器；以及(c)引导协议，用于用户在客户站初始化过程中定位主调度器。这些部分中的每一个将在下文讨论。 

为了提高与前述定理相关联且在之前的附图中图示的接纳调度器模式的效用，公开了由定理支持的下面部分。 

设D_A为客户与接纳调度器之间的平均网络延迟，以说明网络延迟的变化，假设延迟抖动由D_A ⁺和D_A ^-限制，从而保证由d_A表示的实际延迟为： 

$(D_A+D_A^{-})\≤d_A\≤(D_A+D_A^{+})---\left(7\right)$

这个附加的延迟影响视频会话的开始时间，这是因为来自调度器的接纳应答在到达客户之前受到这个延迟的影响。具体地，视频客户将在调度器许可接纳之后的d_A秒开始发送第一视频请求。 

类似地，设D_S为客户与视频服务器之间的平均网络延迟，以及 D_S ⁺、D_S ^-为相应的延迟抖动，那么保证由d_s表示的实际延迟为： 

$(D_S+D_S^{-})\≤d_s\≤(D_S+D_S^{+})---\left(8\right)$

这个额外的延迟增加了请求到达服务器的时间变化。 

实际上，如果网络(例如，ATM)提供服务质量保证，那么这些延迟和延迟抖动可先验确定。否则，其可通过基准测试进行实验性地评估。 

由于客户-服务器链路延迟和延迟抖动，因此请求产生时间与请求到达服务器的时间不同。由于客户-服务器链路延迟由抖动限制，因此说明了从同一客户发送的k个请求到达服务器的时间由下式限制： 

$\max \{((k-1)N_S{T}_{\mathrm{avg}}-T_{\mathrm{DV}}-(D_S^{+}-D_S^{-})),0\}\≤t\≤((k-1)N_S{T}_{\mathrm{avg}}+T_{\mathrm{DV}}+(D_S^{+}-D_S^{-}))---\left(9\right)$

将其并入，并将因客户-调度器链路延迟抖动引起的开始时间变化并入，下面的定理3扩展了定理2，以建立k个请求到达服务器的时间范围的下限： 

定理3假设网络延迟抖动：D_A ⁺、D_A ^-、D_S ⁺和D_S ^-，服务器接收来自n个客户的k个视频数据请求的最小时间由下式给出： 

其中u＝[(k-1)/n]，以及v＝mod(k-1，n) 

已知服务器处的最坏情况下的负载，那么可得到各种性能质量，包括服务器处的最大服务延迟和客户处的客户缓冲器要求。 

为了避免在丢包的过程中发生不必要的延迟，需要可靠且时间敏感的传输协议，从而所导致的延迟不会过长。由于延迟抖动有界限，因此超时限制实际上不需要为自适应的。 

代替使用复杂的自适应超时和重传算法，使用简单且有效的可靠数据报协议(RDP)，该RDP具有可编程的超时和重传参数。特别地，该协议使用恒定不变的超时限制T_out和最大的重传次数N_retx，这两参数在系统初始化过程中通过应用程序进行配置。超时阈值可根据客户-调度器链路和客户-服务器链路中的延迟和延迟抖动进行选择： 

$\left\{\begin{array}{c}{T}_{\mathrm{out}}^A=2(D_A+D_A^{+})\\ T_{\mathrm{out}}^S=2(D_S+D_S^{+})\end{array}\right.---\left(11\right)$

其中， 

和 分别为客户-调度器链路和客户-服务器链路的超时阈值。类似地，可根据希望的最大丢包概率β选择最大的重传次数： 

$\left\{\begin{array}{c}{\left({\mathrm{\ρ}}_A\right)}^{N_{\mathrm{retx}}^A}\≤\mathrm{\β}\\ {\left({\mathrm{\ρ}}_S\right)}^{N_{\mathrm{retx}}^S}\≤\mathrm{\β}\end{array}\right.---\left(2\right)$

其中，ρ_A和ρ_S分别为客户-调度器链路和客户-服务器链路的丢包概率。通过重新调整一个可获得所需的参数： 

$\left\{\begin{array}{c}{N}_{\mathrm{retx}}^A\≥(\ln \mathrm{\β}/\ln {\mathrm{\ρ}}_A)\\ N_{\mathrm{retx}}^A\≥(\ln \mathrm{\β}/\ln {\mathrm{\ρ}}_S)\end{array}\right.---\left(13\right)$

在RDP下，由该协议引起的最大延迟(即，不包括网络延迟)由T_out(N_retx-1)限制。由于如果不发生重传，那么RDP不会引起任何附加延迟，因此所引起的延迟可被合并作为除了D_A ⁺和D_A ^-以外的附加延迟抖动： 

$\left\{\begin{array}{c}{D}_{\mathrm{PA}}^{+}=T_{\mathrm{out}}^A(N_{\mathrm{retx}}^A-1)\\ D_{\mathrm{PS}}^{+}=T_{\mathrm{out}}^S(N_{\mathrm{retx}}^S-1)\end{array}\right.---\left(14\right)$

因此，可将定理3扩展为并入新的延迟抖动。 

定理4给定(14)式中因丢包而引起的延迟抖动，那么服务器接收来自n个客户的k个视频数据请求的最小时间为： 

其中u＝[(k-1)/n]，以及v＝mod(k-1，n)(15) 

根据本发明，实施心跳协议。每个复制的接纳调度器经由通信链路38、40、42、每隔T_hb秒将心跳包多点传送至所有其它的调度器。如果未从特定的调度器22接收到N_hb个连续心跳包，那么将被认为已经失败。忽略网络延迟，所有其它调度器24、26在最大延迟之后将发现调度器失败，该最大延迟如下式所示： 

D_F＝T_hbN_hb                    (16) 

主调度器的心跳包在两个方面不同于从调度器的心跳包。首先，它包含位矢量，该位矢量记录了接纳映射表的当前状态。从调度器24、26在接收到这个位矢量时更新它们的接纳映射表，以与主调度器22同步。其次，只要接纳映射表发生状态变化，就产生心跳包。因此，心跳间隔可小于T_hb。 

每个调度器22、24、26维持起作用的接纳调度器的列表。假设每个调度器在具有唯一IP地址的单独计算机上运行，该列表可通过调度器的IP地址构成，并且可通过将4字节的IP地址处理为无符号整数而对该列表分类。基于心跳协议，将失败的调度器从列表上删除，并且将新的(和已修复的)调度器插入列表中。这个列表用于选举新的主调度器，如下文所讨论的。下面说明用于心跳协议的伪代码。 

心跳协议的伪代码 

状态变量： 

AdmissionMap-捕获接纳映射表的状态的位矢量 

FunctionalSchedulers-起作用调度器的列表 

Procedure_Generate_Heartbeats(T_hb)(程序_产生_心跳) 

{ 

 while(system running)(当(系统运行)){ 

 if admission scheduler is Master then(如果接纳调度器为主调度 

 器，那么) 

     Multicasts a heartbeat packet containing AdmissionMap(多点 

     传送包含AdmissionMap的心跳包)； 

 else(否则) 

     Multicasts a heartbeat packet w/o AdmissionMap(多点传送不 

     具有AdmissionMap的心跳包) 

 Sleep(T_hb)(休眠)； 

 } 

} 

    Procedure_Receive_Heartbeat(scheduler i)(程序_接收_心跳(调度 

器i)) 

    { 

    if scheduler i is not in FunctionalSchedulers then(如果调度器i不 

    在Functional Schedulers内，那么) 

         add scheduler i to FunctionalSchedulers(将调度器i添加到 

         FunctionalSchedulers内) 

    if scheduler i is Master then(如果调度器i是主调度器，那么) 

         Update AdmissionMap(更新AdmissionMap)； 

    } 

    Procedure_Detect_Scheduler_Failure()(程序_检测_调度器) 

    { 

     while(system running)(当(系统运行)){ 

       for each scheduler in FunctionalSchedulers(对于 

       FunctionalSchedulers中的每个调度器){ 

         if no heartbeats received for DF seconds then(如果D_F秒内未 

         接收到心跳包，那么) 

         { 

           remove scheduler from FunctionalSchedulers(将调度器从 

           Functional Schedulers中去除)； 

           if scheduler is Master then run Procedure_Election()(如果 

           调度器是主调度器，那么运行程序_选举) 

          } 

       } 

    } 

} 

如果从调度器失败，那么不需要采取任何行动，因为只有主调度 器22用于接纳。所有起作用的调度器仅在未接收到来自失败的调度器的N_hb个连续心跳包之后记录该失败。 

相反，如果主调度器22失败，那么必须启动选举程序。由于每个从调度器维持起作用的调度器的列表，因此列表顶部的那个调度器将被选为新的主调度器。这个选举程序不需要在调度器之间交换数据。接着，这个新的主调度器将消息广播至所有调度器和所有客户，以通知他们该选举结果。选举程序只有在检测到主调度器失败时才发生。因此，如果失败的调度器回到联机状态，那么它将不会被重新选为主调度器，直到当前的主调度器失败。下面说明选举程序的伪代码。 

选举程序伪代码 

状态变量： 

AdmissionMap-捕获接纳映射表的状态的位矢量 

FunctionalSchedulers-起作用的调度器的列表 

Procedure_Election()(程序_选举) 

{ 

 New_master＝scheduler at the top of FunctionalSchedulers(新_主 

 ＝位于FunctionalSchedulers顶部的调度器)； 

 if myself is New_master then(如果自身为新_主，那么) 

        Multicast election result and AdmissionMap to all 

    schedulers(将选举结果和AdmissionMap多点传送至所有的调 

    度器) 

} 

尽管活动的客户12、14、16总是通过收听调度器的广播消息来得知哪个调度器为当前的主调度器，但是新初始化的客户(例如，在上电或重启之后)不知道哪个调度器为主调度器。在这种情况下，客户使用引导协议来定位当前的主调度器。特别地，新启动的客户首先通过域名系统(DNS)获得所有调度器22、24、26的IP地址列表。这 个操作可通过将所有的调度器IP地址与单个主机名(例如，admission.xxx.com)相关联来实现。然后，通过这个列表，客户将询问消息发送至列表顶部的调度器，以请求当前主调度器的地址。当应答返回到客户时，该过程结束。否则，客户尝试列表中的第二调度器，直到应答返回。只要调度器中的至少一个起作用，客户就能够定位当前的主调度器并且初始化新的视频会话。下面说明了这种引导协议的伪代码。 

引导协议的伪代码 

状态变量： 

AdmissionMap-捕获接纳映射表的状态的位矢量 

FunctionalSchedulers-起作用的调度器的列表 

ListOfAllSchedulers-所有调度器(运转或未运转)的列表 

Procedure_Bootstrap_Request()(程序_引导_请求) 

{ 

 Obtain ListOfAllSchedulers from DNS(从DNS获得 

 ListOfAllSchedulers)； 

 For each scheduler in ListOfAllSchedulers(对于 

 ListOfAllSchedulers中的每个调度器) 

 { 

  Send query to scheduler to request address of current Master(将询 

  问发送至调度器，以请求当前主调度器的地址)； 

  if no reply from scheduler after a time Tout then next scheduler 

  (如果在Tout时间之后调度器没有应答，那么到下一个调度 

  器)； 

  if received reply from scheduler then(如果从调度器接收到应答， 

  那么) 

  { 

    update AdmissionMap and FunctionalSchedulers(更新 

      AdmissionMap和FunctionalSchedulers)； 

      exit(退出)； 

    } 

  } 

} 

Procedure_Bootstrap_Reply()(程序_引导_应答) 

{ 

 While(system running)(当(系统运行)) 

 { 

  Wait for bootstrap request message(等待引导请求消息)； 

  Reply address of Master，AdmissionMap，and 

  FunctionalSchedulers(以主调度器的地址、AdmissionMap和 

  FunctionalSchedulers应答)； 

 } 

} 

根据本发明的复制方案可以两种方式影响系统的负载均衡。首先，由于每个调度器在单独的计算机内运行，所以它们的内部时钟未被精确同步。假设使用时钟同步协议以将任意两个调度器之间的时钟抖动保持在最大值为D_C秒内，那么当主调度器失败并且新选举的主调度器接管时，现有客户的开始时间相对于新的主调度器的时钟至多偏移D_C秒。如下所述可将这种抖动并入本发明的系统模型中： 

定理5给定调度器的最大时钟抖动D_C，那么服务器从n个客户接收k个视频数据请求的最小时间为： 

其中u＝[(k-1)/n]，以及v＝mod(k-1，n)        (17) 

尽管主调度器多点传送用于对接纳映射表的每次更新的心跳包， 但是这个包仍然可能丢失。如果主调度器失败，那么不能将更新传播至一些从调度器。假设不多于(N_hb-1)个连续心跳包丢失，如果调度器起作用，那么主调度器和从调度器的接纳映射表可至多相差(N_hb-1)个时隙。在主调度器失败的情况下，可将这些时隙分配至两个客户。等式(17)可被扩展用于说明这种状态不一致性： 

等式(18)说明只有一个调度器失败的情况-这对于大多数实际目的应该足够了。如果不可忽视多个调度器失败的可能性，那么等式(18)可通过类似的推导被扩展以说明多个调度器失败。 

为了实现，与本发明相关联的系统和技术不能具有最大服务延迟，该服务延迟太长使得系统不能有效地对终端用户、视频客户做出响应。3秒被认为是可接受的最大服务延迟。基本参数在上面的表1中给出。图5是评估结果的实施例，示出了最大服务延迟与抖动为+/-10％的网络延迟的比较结果。为了比较目的，还绘出了在不存在接纳调度器情况下的最大服务延迟。基于表1的参数，各种情况下的最大服务延迟与丢包、最大服务延迟与最大调度器时钟抖动以及最大服务延迟与调度器失败时钟抖动的进一步评估已经产生了不大于1.2秒的最大服务延迟。 

已经参考具体实施方式解释了本发明。其它实施方式对本领域的普通技术人员来说是显而易见的。因此，本发明不受限于此，而是受限于所附权利要求的语言。 

Claims (18)

1.一种具有多个基于拉的视频服务器的基于拉的并行视频服务器系统，被操作为在所述多个基于拉的视频服务器上存储视频数据的条带，以用于对多个客户的视频观看请求提供服务，所述客户不同时地产生所述视频观看请求，所述视频服务器系统包括：

主接纳调度器，以控制关系与所述视频服务器连接；

至少一个从接纳调度器，其被连接，以从所述主接纳调度器接收控制信号，所述主接纳调度器被操作为协调所述从接纳调度器，从而在时间和空间上对来自任何所述客户的观看请求进行调度，以使所述视频服务器中的任一个的过载最小，并且使所述主接纳调度器和所述从接纳调度器中的任一个能够在不中断响应于所述观看请求的服务的情况下被更换。

2.根据权利要求1所述的视频服务器系统，其中，所述主接纳调度器被操作为周期性地多点传送更新的状态信息，以将所述从接纳调度器中的状态更新为接纳映射表。

3.根据权利要求2所述的视频服务器系统，包括：

使用心跳协议检测至少所述主接纳调度器中的失败的代码；以及

在所述主接纳调度器失败的情况下根据选举协议动态选举新的主接纳调度器的代码。

4.根据权利要求3所述的视频服务器系统，其中，所述心跳协议被操作为使用心跳包，所述心跳包在所述接纳映射表发生状态变化时产生，并且所述心跳包包含记录所述接纳映射表的当前状态的位矢量，从而能够使心跳包之间的间隔最小，以促进快速转变。

5.根据权利要求3所述的视频服务器系统，其中，所述心跳协议被操作为当未从所述调度器接收到所选择数量的连续心跳包时，建立任意所述调度器的失败。

6.根据权利要求1所述的视频服务器系统，其中，使用可靠数据报协议(RDP)，所述可靠数据报协议具有能够预先选择的超时和重传参数，所述协议利用恒定的超时限制T_out和最大的重传次数N_retx，其中，根据如下关系式，根据客户-调度器链路A和客户-服务器链路S中的延迟D和延迟抖动D⁺选择超时阈值：

$\left\{\begin{array}{c}{T}_{\mathrm{out}}^A=2(D_A+D_A^{+})\\ T_{\mathrm{out}}^S=2(D_S+D_S^{+})\end{array}\right.$

其中，和

为所述客户-调度器链路和所述客户-服务器链路的超时阈值。

7.根据权利要求6所述的视频服务器系统，其中，预先选择超时和重传参数，以使得对于终端用户的最大服务延迟不超过大约3秒。

8.根据权利要求1所述的视频服务器系统，其中，预先选择超时和重传参数，以使得对于终端用户的最大服务延迟不超过大约3秒。

9.根据权利要求2所述的视频服务器系统，进一步包括：

在作为引导协议的一部分的客户站初始化过程中，通过询问所述调度器来定位所述主接纳调度器的代码。

10.一种用于观看请求的负载均衡和接纳调度的方法，在具有多个基于拉的视频服务器的基于拉的并行视频服务器系统中，所述视频服务器系统被操作为在所述多个基于拉的视频服务器上存储视频数据的条带，以用于对多个客户的视频观看请求提供服务，所述客户不同时地产生所述视频观看请求，所述方法包括：

在主接纳调度器处接收所述观看请求，所述主接纳调度器以控制关系与所述视频服务器连接；

在至少一个从接纳调度器处接收所述观看请求的副本，所述从接纳调度器被连接，以从所述主接纳调度器接收控制信号；

仅通过与所述从接纳调度器协调的所述主接纳调度器进行调度，从而在时间和空间上对来自任意所述客户的观看请求进行调度，以使所述视频服务器中的任一个的过载最小，并且使所述主接纳调度器和所述从接纳调度器中的任一个能够在不中断响应于所述观看请求的服务的情况下被更换。

11.根据权利要求10所述的方法，其中，所述主接纳调度器周期性地多点传送更新的状态信息，以将所述从接纳调度器中的状态更新为接纳映射表。

12.根据权利要求11所述的方法，其中，所述方法包括：

使用心跳协议检测至少所述主接纳调度器中的失败；以及

在所述主接纳调度器失败的情况下根据选举协议动态选举新的主接纳调度器。

13.根据权利要求12所述的方法，其中，所述心跳协议使用心跳包，所述心跳包在所述接纳映射表发生状态变化时产生，并且所述心跳包包含记录所述接纳映射表的当前状态的位矢量，从而能够使心跳包之间的间隔最小，以促进快速转变。

14.根据权利要求12所述的方法，其中，当未从所述调度器接收到所选择数量的连续心跳包时，所述心跳协议建立任意所述调度器的失败。

15.根据权利要求10所述的方法，其中，使用可靠数据报协议(RDP)，所述可靠数据报协议具有能够预先选择的超时和重传参数，所述协议利用恒定的超时限制T_out和最大的重传次数N_retx，其中，根据如下关系式，根据客户-调度器链路A和客户-服务器链路S中的延迟D和延迟抖动D⁺选择超时阈值：

$\left\{\begin{array}{c}{T}_{\mathrm{out}}^A=2(D_A+D_A^{+})\\ T_{\mathrm{out}}^S=2(D_S+D_S^{+})\end{array}\right.$

其中，

和

为所述客户-调度器链路和所述客户-服务器链路的超时阈值。

16.根据权利要求15所述的方法，其中，预先选择超时和重传参数，使得对于终端用户的最大服务延迟不超过大约3秒。

17.根据权利要求10所述的方法，其中，预先选择超时和重传参数，使得对于终端用户的最大服务延迟不超过大约3秒。

18.根据权利要求10所述的方法，进一步包括：

在作为引导协议的一部分的客户站初始化过程中，通过询问所述调度器来定位所述主接纳调度器。

Images