- 相关推荐
采用集中上载方式的非线性制作网的若干细节归纳
采用集中上载方式的非线性制作网的若干细节归纳
2004年度河南省广播电视优秀科技论文二等奖一、概述
目前，非线性制作网络在电视行业中已大量应用，以 FC+ 以太网的双网结构是最为普遍的做法。由于前期的节目采集中，仍在大量使用磁带这一传统的线性方式作为记录的主体，在后期的节目制作前，素材的上载成为不可避免的步骤与环节。现在流行的方式是在配有视音频处理卡的工作站上加挂放机，以分散的上载工作站承担素材上载的工作。这种方式由于其流程简单、使用灵活而在早期的网络中大量存在，但在中小型的网络中，由于工作站点的不足，经常会出现素材上载人员与节目编辑人员争用站点的现象。为避免这种情况的出现，将节目制作站点从素材上载中解放出来，河南电视台都市频道在 2003 年底建成的节目制作网以集中上载来代替原先新闻制作网中的分散上载方式。
二 、网络分析
由于上载部分的独立，从而使网络的结构在功能上产生了分解、细化，使得原先作为整体的、基于标准 C/S 构架的、功能集成的网络，演变成为多个功能专一的、独立的子网。如图 1 、 2 所示：
注：箭头代表数据流向
从以上两图的比较当中可以看出，在原先的网络中，素材上载、节目制作、素材存储、以及网络的管理等功能，都是通过各站点独立在网络中进行交互的，而各站点之间是一种对等、并列的关系，它们之间不存在根本性的功能差异，这就在简洁、明了的背后掩盖了各功能间不确定的、潜在的冲突（即在用机繁忙时，素材上载人员与节目编辑人员争用站点的现象时有发生；而在更多的时间中，大部分站点又处于闲置状态）。在新的网络中，各功能相对独立，更有利于网络的管理与维护。并且，对于功能的扩充（如加入播出网），也由原来的网间连接变为内部子网的扩展，在理解上更加容易、操作上更加可行。
三、网络结构
下面笔者就以图二的功能子网模式，对都市频道的非线性节目制作网进行结构上的分析。
• 上载子网
从物理上该部分由两台转码工作站（ ZMS-01 和 ZMS-02 ）、一台转码调度服务器站（ ZMC ）、一台上载控制站（ SZC ）、一台视频服务器（ MAV70 ）及该视频服务器的网关（ GateWay ）所组成；从逻辑上分为上载、存储与转码三部分。
在 SZC 上运行着集中上载主程序 MAV70Upload.exe 和定时收录任务 Uploadsvr.exe 两个程序， MAV70Upload.exe 是集中上载系统的主程序，记载了整个上载部分的路由信息， 负责素材的采集、将采集的条目写入专有的上载数据库、并向素材管理 DispClip.exe 发送上载信息，它 也是上载人员操控的主界面；而 Uploadsvr.exe 功能较为单一，只进行卫星的定时收录任务。同时， SZC 通过 MOXA 卡及其连接盒与各放机和 MAV70 的控制口相连，对其进行各种操作的控制。
ZMC 包含素材管理 DispClip.exe 和转码调度服务器 SbRemoteSvr .exe 两个程序，素材管理 DispClip.exe 接收到来自主程序的上载信息， 检查数据库，将新增的条目生成转码任务并提交， 并将其发送于转码部分，待转码完成后将信息（转码成功、失败或因未找到转码素材而没有转码）返回于主程序；当素材管理 DispClip.exe 收到 转码任务成功时，还要将素材信息写入整个网络的主数据库。而转码调度服务器 SbRemoteSvr.exe 的作用是接受来自于素材管理 DispClip.exe 的任务，并根据当前的任务量对转码工作站集群进行任务调度和分配，待转码站完成任务后，向素材管理 DispClip.exe 返回完成信息。
两台 ZMS 组成了转码工作站的群集，在其上的本地转码 SbTrLocalSvr.exe 程序根据从转码调度服务器站发来任务，通过网关从 MAV70 中找到相应的素材文件的位置，将其转为制作网所识别的高（低）质量的视音频文件，并存放于为该用户指定的相应位置；在转码工作站上另有一手动提交软件 TaskSubmit.exe ，该软件可将各类 MPEG-II 视音频（如 DVD ），网络中各种流行的视频格式（如 rmvb 、 wmv 、 asf 、 mp3 等）及其他公司的视音频文件（如 SEACHANGE 、 GVG GXF ）转为制作网中可识别的格式，它的功能相当于一手动提交任务的“万能转码”软件。
MAV70 用来临时存放采集的视、音频文件，由于其不能直接将视、音频流转为制作网所识别的格式文件，也就使得转码成为必须的步骤；而且 MAV70 是视频服务器，无法以高速的 I/O 吞吐能力直接与网络进行交互，因此为其配一专用的网关，解决网络中的高数据流量。
SZC 上的 MAV70Upload.exe 和 Uploadsvr.exe 两个程序与 ZMC 上的素材管理 DispClip.exe 组成了上载部分，它们之间相互独立，互相配合。用户通过主程序进行操作，在登录时申请供上载用的空闲通道，并从网络中的主数据库中读出相应的用户信息（上载的权限、有效的使用空间、用户需求的视频文件的码率类型及要存放的位置等），待录制（素材上载）完成后，将相应的素材信息写入上载数据库，并发送信息给素材管理 DispClip.exe 。素材管理 DispClip.exe 接收到主程序发送的素材信息后，检查上载数据库，将其中的新增条目生成转码任务并向转码调度服务器提交。当素材管理 DispClip.exe 接收到从转码调度服务器发送的转码完成的返回信息后，将该条目的所有相应信息写入制作网主数据库，并且向主上载程序发送转码成功信息。主程序在得到转码任务成功的信息后，向上载数据库写入完成信息，并于一小时后自动从 MAV70 中释放已完成转码的素材所占用的空间；若返回的是失败信息，素材管理 DispClip.exe 将不进行写入主数据库的操作，同时返回给主程序，由主程序向上载数据库写入失败信息，并将素材一直存放在 MAV70 内，成为“垃圾”文件。管理人员若发现转码任务失败，可通过该任务在转码调度服务器中的执行信息进行判断，如果是任务意外中止，可在转码调度服务器中手动重作该任务，若录入的素材有问题，则应通过上载主程序的管理界面删除该任务。用户还可进行卫星定时收录工作，与人工上载不同的是定时上载不需要手工去操作，只需要在第一次上载前，由用户对录制起止时间、录制期数进行预先设定，在录制的前两分钟，定时上载程序会自动向上载主程序发送录制申请。由于定时上载在设计时即被定义了较高的优先级，因此在定时上载发送录制申请后，如果设备已被占用，主程序会强行终止该任务，释放通道，供定时上载程序使用。
转码调度服务器、转码工作站群集与手动任务提交组成了转码部分。转码调度服务器与转码工作站群集组成了正常的上载模式，转码调度服务器根据当前转码站的忙闲状态进行任务分配。在有空闲的转码工作站时，转码调度服务器向其发送任务与相关素材信息；若所有转码站的通道均被占用时，转码调度服务器则将任务以 FIFO （先进先出）的方式建立一任务队列，依序进行任务分配。
作为存储部分的 MAV70 及其网关，只是用来临时存放素材文件的场所，等转码成功一小时后，其所占用的空间将被自动释放；网关只作为供转码站与 MAV70 交互的一个平台。
• 存储子网
双网结构中以 FC 环境构成的 SAN （存储区域网）则成为了存储子网的主要构成部分。节目素材通过转码工作站，分别经光纤和以太网连接，以高低两种画质存储在 FC 网的共享海量存储磁盘阵列和以太网域主服务器的共享 SCSI 硬盘塔进行存储，供带有视音频编解码板的有卡工作站使用，所以存储子网也就由海量存储磁盘阵列、磁盘控制器、 MDC 服务器及与域主服务器相连的 SCSI 硬盘塔组成。素材文件由经转码工作站的转码，送入网络的相应存储体中，低质量素材存放在 SCSI 硬盘塔中，相对应的高质量素材存放在海量存储磁盘阵列中。
对于 SCSI 硬盘塔而言，域主服务器与其关系就如同 MAV70 与其网关的关系相似，只是域主服务器并不是单为 SCSI 硬盘塔共享存储而配，做为域主服务器、网络的核心，它还发挥着更为重要的维持整个网络运行的作用。在 SCSI 硬盘塔上分别存放有数据库群集、制作网低质量素材和节目的所有信息。
海量存储磁盘阵列是全网的主要存储设备，与以往不同之处在于它并不直接连入 SAN 中，而是配有专门的磁盘控制器，这样可以更加安全可靠地管理磁盘阵列。目前，都市频道制作网中使用的磁盘控制器为使用了单控制器的 S2A3000 ，它管理着磁盘阵列中的全部十六块硬盘，并将其分为六通道的三个“ tier ”（ S2A3000 对磁盘的一种逻辑表示方式），如图 3 显示的是磁盘阵列中，各物理盘的对应关系。
其实， S2A 控制器对磁盘阵列采用了较特殊的管理方式（ DirectRAID 技术），尚未公布对外细节，我们无法十分准确地对其进行了解、掌握，只能通过概念进行逻辑上的理解。在这里，每一个 tier 可以简单地看作是一带奇偶校验的带区集。例如： tier1 是由 1A 、 1B 、 1C 、 1D 、 1P 、 1S 组成，其中标号是 A 、 B 、 C 、 D 为数据盘， P 为奇偶校验盘， S 为空闲热备盘，但是它可以替换阵列中的任一块故障盘，既便它们不属于同一 tier 。但实际情况是每块盘上都有专用于奇偶校验的区块，而不是使用单独的奇偶校验盘。
此时如果一块数据硬盘出现故障，例如 disk 2A 故障，则该盘所在的 Tier 中的其他 5 块数据盘会自动将数据 Rebuild 到热备盘上，即 1S ；当故障硬盘被新盘替换，并且 S2A 控制器检测到新硬盘上线后，系统会将备份盘（如 1S ）上的数据拷贝到新硬盘中。如果新硬盘上线时，系统对热备盘的 rebuild 尚未结束，则系统会先将热备盘的 rebuild 过程完成，然后再将热备盘上的恢复完整的数据拷贝到新硬盘上。
S2A 控制器以双通道的方式与 FC 交换机连接，占用了 FC 交换机的两个端口，分担各结点与存储阵列之间的 通讯量，尽量做到数据吞吐量的负载平衡。
SAN 的优势在于提供了工作站点通过光纤通道（ FC ）对共享存储体（海量存储磁盘阵列）的直接访问，而基于 SAN 结构的 SANergy 文件共享系统则提供了多个站点对存储体的实时共享。 元数据控制器 （ MDC ） 服务器是共享存储体的所有者，是专用于对共享存储体进行管理的服务器，通过 SANergy 软件对共享存储体进行设备和卷的分配，使得共享存储体成为 SAN 中的每台工作站点都可以识别的资源，客户端正是通过它对共享存储体进行访问的。
从 MDC 服务器的角度来看，共享存储体就是它的本地磁盘，可由操作系统自带的磁盘管理软件进行管理和配置，网络中的其他工作站点则通过以太网路由将 MDC 服务器管理的共享存储体进行磁盘映射、进行访问的。当工作站通过以太网以逻辑卷的方式访问共享存储体时，它从 MDC 服务器得到逻辑卷的相关元数据，如文件名称、数据结构、文件大小等，而实际数据则经由 FC 直接进行传输。
• 制作子网
该部分与传统的制作网络无异，因此不加赘述。
• 管理子网
管理子网由域控制器（主服务器）群集、数据库群集、制作网网管软件组成，也包括 FC 控制软件 SANergy 、 FC 交换机的管理软件 SANinsite 、 MAV70 及 S2A 磁盘控制器的管理程序。
域控制器群集是网络运行的核心部分，担负了主域控制器的所有工作。它是将两台硬件配置相同的服务器，通过服务器编组，由一根心跳线相连，使其虚拟成一台单独的服务器，。其中一台作为主控机，另一台为作为它的镜像，当主控机故障时，镜像机会立时接替原主控机，资源的所有者，例如磁盘驱动器和 IP 地址，将自动从故障的服务器转到可用的服务器上。工作负荷可在幸存的服务器上重新启动失效的应用程序，或是直接被分配过来，对于用户而言，只是觉得服务暂时停顿了一下。
数据库群集与域控制器群集类似，它是在域控制器群集安装完成之后，在域控制器群集和各节点上装入并配置的。有所不同的是，进行群集切换时，正在执行的数据库查询将不会重新启动，数据库的重启也会较其他工作慢一些 。
现有的网络中运行着两个数据库，一个是记录主要制作信息的主数据库，一个是专用于记录集中上载信息的上载数据库。这两个数据库是相互独立、互无影响的。
网管软件是对针对制作网的专用管理软件，它要对网络中各工作站进行设备登记，通过对主数据库进行操作，来创建制作网的用户、分配权限、监测用户空间，它还对每个用户的各种操作加以记录。
对于其他的管理软件，都是针对各自的专用对象、实现特定的功能。
四、典型问题
对于一个涉及多环节的网络，会出现各式各样的问题，想列举所有会出现的问题也不可能，现将笔者在值班时遇到的一些认为较为典型的问题作一归纳、分析。
• SZC 长时间运转，集中上载控制主程序一直工作正常，然后出现某一用户在使用时，做任何正常的上载操作（如登录主程序、登录后遥控放机回放素材等），系统均发生异常（主程序异常终止、操作无响应、鼠标箭头消失等），即使重新启动主机，问题依旧。不使用集中上载控制主程序，则主机系统运行良好，加载之后则不能正常工作，终止程序后，主机系统依旧运行良好。主程序经过长时间的使用，操作界面功能单一，没有任何修改配置信息的操作（管理功能不对上载用户开放，普通用户无修改权限），即使是程序自身的问题，在重启主机系统后仍不能正常工作。这就说明了问题的原因有两种可能，集中上载主程序与主机系统发生冲突或与其他应用软件产生了冲突。专机专用，一直工作正常，且不做任何系统修改，与主机系统发生冲突的可能性不大；未再加入任何额外程序，说明集中上载控制主程序相关的其他上载程序发生了冲突。与集中上载控制主程序相关的只有定时上载任务和两个程序，定时上载任务功能单一，且与发生的现象无太大关系，也可做出排除。此时可基本确定问题的根源在集中上载控制主程序与素材管理之间的信息交互出现问题，待终止并重新加载素材管理程序后，集中上载控制主程序各功能恢复正常。
• 集中上载控制主程序故障，会出现另一种情况，用户上载操作完全正常，可无论如何录制，该条目一直没有转码。与上述情况刚好相反，这是主程序影响了素材管理程序，需将集中上载控制主程序终止并重新加载即可。
• 由于 MAV70 录入的最短素材文件至少为 10 秒，总会有用户录入少于十秒的素材，或是做了其他的非法上载操作，使得 MAV70 将这些上载的素材文件作为“垃圾”文件，而不作处理，一些转码失败的素材也会堆积起来，久之，这样的素材条目不仅占用了 MAV70 相当的空间容量，还会在上载数据库中产生许多“垃圾”信息，对于今后管理人员查找、整理信息也会是个不大不小的麻烦。所以管理人员应定期通过集中上载主程序进行管理和清除。
• MAV70 视频服务器作为传统的视频设备，同步源的输入是其能够正常工作的前提，因此在素材上载前，特别是定时任务执行前，一定要保证正确的同步输入。
• 记得一次， MAV70 的 PU 板（位于 MAV70 系统内部，专用于磁盘校验工作的板卡）报“日志已满，日志错误”的警告，当然这对于 MAV70 而言，只是一个并不影响正常工作的警告，笔者通过专用软件可以看到，确实报该板的日志错误。但无论笔者如何想将该 PU 板的错误日志清除，均告失败，管理工具提供的所有清除命令无任何效果。不得已，笔者趁一次周末夜间，无上载工作时，将 MAV70 的磁盘带区集进行了重建，重建完成后原先的所有磁盘信息全部清除，错误日志自然也不复存在了。
• 某次值夜班时，有编辑来告之笔者，说他在上载时报一打不开数据库的对话框，初听以为是他的误操作或集中上载部分出现了故障造成的。在笔者进入机房后，几个在线的编辑也说正在做节目时也弹出一数据库连接失败的对话框。既然是集中上载与制作网同时报与数据库有关的故障信息，笔者的第一判断就是数据库可能出现了问题。笔者在中心服务器机房发现，域控制器群集已做了自行切换，但数据库服务并未启动。看来问题不大，笔者手动将域控制器群集切回原有的服务器（笔者的习惯），手动启动了数据库服务，一切似乎已经正常，事情看起来不是很复杂。就在我还正想着怎么会无故发生自动切换这种“怪事”时，编辑又来找我了……现象依旧，唯有所不同的是群集的切换在群集管理器判定原镜像机也出现故障后，重新试图启动原主控机。此时数据库也在时断时续地响应着网络中的请求。这是一个比较少见的现像，无论我如何重启整个网络、修复数据库、还原已备份的数据库，所有尝试均告失败。这时我将注意力放至了数据库群集，也许就是这里的原因。在备份了现有的数据库后（虽然它已经没什么用了），卸载并重新安装了数据库群集，运转正常了。笔者重建了所有的网络用户的信息。当时是在网络的试运行期间，也幸好是在试运行期间，现在笔者又要到哪里去找这样一个环境来做这样一个“实验”？但是为什么出现了数据库群集的崩溃，笔者至今也未能找出恰当的解释。
• 一次，在重启一台带光卡（ FC 卡）的工作站时，在开机时报磁盘（为 MDC 服务器的卷标）故障，磁盘进行扫描，并报错。由于当时有某种原因，该工作站连续重启数次，每次均正常关机，每次均检测。报错的同时要求对卷进行 CHKDSK.exe 操作。这引起了笔者的注意，对其他带光卡的工作站重启，出现同样的现象。通过 SANergy 软件对磁盘阵列测试后，未发现任何问题。分析后认为，造成故障的原因应与 MDC 服务器操作系统下的卷数据结构有关，重启 MDC 服务器后，问题不再出现。
• 另一个和 MDC 有关的问题是，在原先的新闻制作网中，主域控制器与 MDC 服务器合在一起，所有的网络控制均由主域控制器发出。由 MDC 服务器的工作原理可知，这是性质比较特殊的一类服务器，一方面它的地位非常重要，另一方面它的 I/O 流量相对较小。因此，是否有必要将其分开呢？在这次建网的过程中，对原有的新闻网进行了部分升级，其中就包括了加入独立的 MDC 服务器。事实证明，独立的 MDC 服务器可以使稳定性有很大的提高。由此可见，虽然 MDC 服务器的 I/O 流量相对较小，但主域控制器的网络负担任何的加重，都会对全网产生很大的影响。
• 和大存储量的数据关系越密切，磁盘故障的也就在所难免。 MAV70 、海量磁盘存储阵列和 SCSI 硬盘塔，每种存储体都会有硬盘更换的可能。在这个每款存储设备都标明可以热插拔的今天，磁盘的更换命令虽然各有不同，但更换步骤却是大同小异： 1 ）停止要更换的磁盘运转； 2 ）卸下硬盘，并更换新盘； 3 ）加载新盘； 4 ）自动或手动重建带区信息。
五、总结
制作网在功能被细分后使得网络的架构更加清晰，更容易对网络分析。应当指出的是，这种划分并不是完全的基于纯粹的软件层或是硬件层的划分，若在尚未完全搞清网络结构前生硬的对网络各部分进行比照，还有产生误导的可能。但它必竟给我们提供了一种新的思路，对今后越来越复杂的网络的理解有很大的帮助。
【采用集中上载方式的非线性制作网的若干细节归纳】相关文章：
集中识字的主要方式08-08
学习方式组织操作的若干思考08-24
采用视频方式的点坐标测量方法08-06
采用“小单元集中识字”的方法进行课文教学08-08
采用加密网卡实现内部网的信息安全08-06
非线性编辑系统的关键：专业非线性编辑板卡08-06
细节：接触、感知并改变世界的方式08-12
简历制作：细节是魔鬼08-15