- 相關推薦
采用集中上載方式的非線性制作網的若干細節歸納
采用集中上載方式的非線性制作網的若干細節歸納
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