采用集中上载方式的非线性制作网的若干细节归纳

    其实，S2A控制器对磁盘阵列采用了较特殊的管理方式（DirectRAID技术），尚未公布对外细节，我们无法十分准确地对其进行了解、掌握，只能通过概念进行逻辑上的理解。在这里，每一个tier可以简单地看作是一带奇偶校验的带区集。例如：tier1是由1A、1B、1C、1D、1P、1S组成，其中标号是A、B、C、D为数据盘，P为奇偶校验盘，S为空闲热备盘，但是它可以替换阵列中的任一块故障盘，既便它们不属于同一tier。但实际情况是每块盘上都有专用于奇偶校验的区块，而不是使用单独的奇偶校验盘。

    此时如果一块数据硬盘出现故障，例如disk2A故障，则该盘所在的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）自动或手动重建带区信息。

    五、总结

    制作网在功能被细分后使得网络的架构更加清晰，更容易对网络分析。应当指出的是，这种划分并不是完全的基于纯粹的软件层或是硬件层的划分，若在尚未完全搞清网络结构前生硬的对网络各部分进行比照，还有产生误导的可能。但它必竟给我们提供了一种新的思路，对今后越来越复杂的网络的理解有很大的帮助。