漫谈流媒体服务器集群的负载均衡

高性能宽带信息示范网3TNet的创建，使远距离VOD成为可能。流媒体服务器（Streaming Media Server 简写MS）集群系统能够用相对较为廉价的方式提供较强的可扩展性和良好的吞吐性能，然而要使系统资源得到充分利用却面临着许多技术上的挑战，负载均衡技术就是其中之一。在一个由服务器集群构成的大规模视频点播系统中，负载均衡策略的优劣直接影响着整个系统的资源利用效率和服务质量。

MS系统的架构特点

图1. MS中的视频点播系统示意图

图2. 普通视频点播系统示意图

对比图1和图2可以看出，MS中的视频点播系统与普通视频点播系统的不同：在普通视频点播系统中，数据全部存储在本地服务器硬盘上，直接将数据读取到缓存中即可为用户提供服务；而在本文的视频点播系统中，只有部分影片存储在本地服务器中，这些影片的处理和普通视频点播服务器相同，对于其它本地没有存储的影片，MS获得用户请求后立即向内容推送平台（CDP）请求数据，CDP将通过ASON（3TNet）的Burst ASON机制即时将数据传送过来，MS并将数据存放在缓存中为用户服务。

如果MS没有好的节目存储调度管理机制，影片存储不合理，将极易出现频繁向上级内容提供商请求数据的情况，而一个上级内容提供商为多个MS提供服务，对每一个MS的服务时间是有限的，未必能及时响应于一个请求，且MS与内容提供商之间的数据传送是通过ASON完成的，ASON 采用交换式连接，根据客户需求来动态分配光通道，这种连接的建立、拆除都会占用一定的时问，频繁的连接建立与拆除操作必定会人大降低整个系统的有效利用率。

另外，MS从ASON上接受数据时，极短的时间内有大量的数据同时到达缓存，给系统带来了新的负载压力；且MS提供的是流媒体服务，需对普通媒体文件进行实时编码，转化成流式数据传送给用户，这也是系统负载的一部分。

由以上分析可见，由于本系统特殊的架构特点，MS中的数据存储方式会更加直接地影响着系统的负载分配和服务质量，这对负载均衡策略提出了更高的要求：在实现负载均衡策略时需要同时考虑数据的存储调度管理，否则会造成有的服务器异常繁忙，而有的服务器比较空闲，整个系统资源不能得到充分利用的局面。

MS中的负载均衡系统设计

MS中的负载均衡系统是在基于LAN的分布式体系结构下实现的负载均衡，所有来自客户端的请求被透明地分配到若干服务器上。对用户而言，整个分布式系统仿佛是台单一的逻辑服务器。这样的集群系统能够提供较强的可扩展性和较好的吞吐性能。从商业角度而言，不仅可以保护原来的投资，而且也可以通过廉价的集群系统获得高性能计算机所能达到的处理能力。

然而要使这样的集群系统保持较高的资源利用率面临一定挑战。例如，现有的负载均衡方法都不能很好地解决本系统中涉及的问题，最早的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个域名，从而查询该域名的客户机将访问不同的服务器，达到负载均衡的目的。DNS负载均衡虽然简单而有效，但它不能区分服务器的差异，也不能反映服务器的当前运行状态。

有人采用反向代理服务器进行请求转发的方法，该方法虽然能够应用优化的负载均衡策略，使每次服务均由最空闲的内部服务器来提供，以达到负载均衡的目的。但随着并发连接数量的增加，代理服务器本身的负载也变得非常大，反向代理服务器本身反而会成为服务的瓶颈。还有人采用支持负载均衡的地址转换网关的方法，可以将一个外部IP地址映射为多个内部IP地址，对每次请求动态使用其中一个内部地址，达到负载均衡的目的。

很多硬件厂商将此技术集成在设备中，采用随机选择、根据服务器的连接数量或者响应时间进行选择的负载均衡策略来分配负载，然而硬件实现的负载控制器灵活性不强，不能支持更优化的负载均衡策略和更复杂的应用协议。还有负载均衡方法是在某些协议内部实现的，例如HTTP协议中的重定向功能等，但它依赖于特定协议，因此使用范围有限。

MS中采用的基于分配器的负载均衡机制

基于分配器的负载均衡机制是IP/TCP/HTTP的重定向分配。一般需要一个特殊的前端节点，称为分配器(dispatcher)。所有的客户端请求都经过分配器并由它分配到后端服务器处理。这种基于分配器的请求分配机制通常对客户端是透明的，采用的机制有两种：

一种称为中继机制(relaying)，如图3所示，客户端请求到达分配器后，由分配器按定的负载分配算法，将请求传递给被选中的服务器。服务器处理后的结果传回至分配器，再由分配器转发给客户端。分配器的工作通常在操作系统的应用层完成，也有修改操作系统核心直接支持中继机制的系统，其性能会有所改善，这种优化的方法称为TCP衔接(TCP splicing)；

图3. 中继机制示意图

另外一种机制称为TCP传递(TCP handoff)，如图4所示，客户端的请求经过分配器分配到达服务器，服务器将处理后的结果不经过分配器而直接发送给客户端。中继或TCP衔接机制要求所有的通信均要经过分配器(特别是处理结果信息量很大的情况下)，因此容易在分配器形成通信瓶颈，TCP传递机制避免了这一问题，因此性能更好，但是需要对前端和后端节点进行修改，以支持TCP handoff 。

图4. TCP传递机制示意图

MS中的负载均衡系统结构设计

对于大型视频点播系统来说，一个好的负载均衡算法不能只单纯考虑负载分配问题，更应“未雨绸缪”，在接受用户请求和节目存储时就考虑到负载均衡问题，因此我们认为本系统中的负载均衡系统应该如图5所示，分为接入许可控制模块(Admission Control Module, A CM )、负载调度模块(Load Schedule Module，LSM )和存储管理模块(Storage Manage Module, SMM )三个部分。

接入许可控制模块作为视频服务器的单一入口点，判断是否接受客户的命令请求；负载调度模块负责根据一定的服务器选择算法分配负载，并管理各MS-VOD节点；存储管理模块负责根据点播率变化情况及时调整影片存储。

图5. MS中的负载均衡系统结构示意图

客户请求处理流程

ACM作为MS的入口点，记录有所有正在接受服务客户与MS-VOD的对应关系，即根据客户标识能够立即查询到为其服务的MS-VOD。当ACM 收到流量控制和VCR(Video Cassette Record)等己连接客户的命令请求时，将其赋予很高的优先级，直接转发到为该客户服务的MS-VOD，由同一个MS-VOD作进一步处理。而对于客户提交的新的点播请求命令，则按下而的流程完成处理：

1． MS-Manager中的ACM模块收到用户请求后进行处理：首先与BOSS交互进行用户身份鉴权和点播合法性的认证，然后再经许可准入控制算法处理，决定是否接受该用户请求；

2. 对于非法的点播请求或者是暂时无法满足其QoS要求的点播请求，ACM直接返 回给客户拒绝服务信息；如果用户请求通过了ACM的认证并被许可准入，则该请求会被转发至LSM模块；

3. LSM 记录其收到的客户请求，根据当前各MS-VOD的负载记录和一定的负载调度策略，按着先来先服务的原则，逐一为查询命令选择MS-VOD，如果查询到了合适的MS-VOD，立即通知此MS-VOD为相应的用户提供视频服务；

4. 如果当前没有可用的服务器，则将该请求保留，保留其间多次为其选择MS-VOD，直至选择成功或失败，并将结果通知ACM。对于超时失败的选择查询， ACM会将结果通知该客户；

5． 对于选择成功的查询，将该客户的加载请求发送到相应的MS-VOD，如果此MS-VOD中存储有相应影片，则直接将影片数据从硬盘中调出至缓存中，再由视频处理模块将其转化为流式数据，以提供给用户流媒体视频服务；

6． 如果此MS-VOD中没有存储相应的影片，则立即向上级内容分发平台CDP发出数 据请求，如果请求数据成功，将从ASON上接收数据放在缓存中，经过数据转换后，立刻向客户发送数据，并将加载成功结果通知ACM，否则将失败结果返回给ACM；

7． ACM将收到的加载结果返回给客户，一个用户请求处理完成。

小结

流媒体服务器研究的一个重点就是负载均衡问题。本文从MS的架构特点和工作流程出发，给出了MS的系统设计，并提出将许可准入控制、负载分配和存储调度管理三者有机结合的负载均衡算法，在实际测试中取得了很好的均衡效果。