城市軌道交通綜合監控系統數據庫部署及服務器配置方案研究

袁偉（鐵道第三勘察設計院集團有限公司廣東分公司，廣東深圳518000）

城市軌道交通綜合監控系統數據庫部署及服務器配置方案研究

袁偉
（鐵道第三勘察設計院集團有限公司廣東分公司，廣東深圳518000）

城市軌道交通項目中綜合監控系統的建設，依據線路特點、技術發展水平、運營管理技術水平及需求，在數據庫部署及服務器配置方面有不同的方案實踐，各方案均有其不同的側重點及優缺點，對各方案進行歸納和總結，為綜合監控系統的工程設計提供設計思路和方法。同時提出了基于服務器虛擬化技術的服務器配置方案，為云計算在城市軌道交通綜合監控系統中的應用提出了新的思路。

綜合監控系統；數據庫部署；服務器配置

0　引言

綜合監控系統是實現城市軌道交通自動化調度管理的重要工具，也是當今城市軌道交通監控系統的主要發展方向。設置綜合監控系統的目的，就是為了增強城市軌道交通系統指揮調度的統一性、靈活性和系統間的協調運作能力，因而綜合監控系統性能的優劣直接關系到它是否能在城市軌道交通運營管理中發揮應有的效能和能否滿足城市軌道交通運營管理的需要。綜合監控系統數據庫部署及服務器配置方案是影響綜合監控系統性能及投資的關鍵因素[1]。本文依據綜合監控系統的發展趨勢及多年的設計和工程經驗對數據庫部署和服務器配置方案進行歸納和總結，為綜合監控系統的工程設計提供設計思路和方法。

1　數據庫部署方案

綜合監控系統根據運營管理模式、采集信息的處理方式以及中心級存儲和管理數據量的大小，在數據庫部署上可分為以下四種方案。

方案一，中心集中與站點分布的數據庫部署方案：在中心級設置全局實時數據庫和歷史數據庫，將車站級的所有聯網子系統的全部數據實時地采集到中心級來進行統一的管理和控制[1-2]。由于數據量的龐大，處理復雜，需要分別設置實時數據庫和歷史數據庫，以便監視和控制全線所有監控對象，實時反映現場狀態并進行及時的響應和存儲。車站級僅設實時數據庫，僅用于監控，負擔本站所轄范圍內的數據采集、報警分析、運算控制、事件記錄等事務。車站不設歷史數據庫，數據以文件形式存儲，歷史數據的存儲、整理、統計、分析等數據管理工作不在車站級實現。如果某個站點需要查詢相關數據，則必須通過綜合監控系統主干網絡來遠程調取中央全局歷史數據庫中的相關數據，傳輸網絡的依賴性較大。

該方案有利于數據的多重保護和歷史數據的集中管理，但需依靠綜合監控的骨干網實現歷史數據的查詢，對網絡具有一定依賴性，同時要求骨干網具有較大的帶寬，且系統投資較大。適合車站規模大且站點數目較多的線路。該方案數據庫部署及數據流如圖1所示。

圖1　中心集中與站點分布的數據庫部署方案及數據流

方案二，中心數據庫集中部署方案：僅在綜合監控系統中心級設置全局的實時數據庫和歷史數據庫，在車站不設置數據庫，只設置網絡設備和車站終端工作站等[1-2]。全線所有站點的被監控對象的實時監控數據都集中傳送到中心來進行處理、存儲和管理。如果某個站點需要查詢相關數據，則必須通過綜合監控系統主干網絡來遠程調取中央全局數據庫中的相關數據。

該方案的主要特點是所有數據集中存儲在控制中心，各站點的應用通過骨干網與中心數據庫通信，保證了每個終端應用使用的都是同一信息。在該方式下，實現數據備份及安全防護比較容易。但該方案由于所有車站應用均需要訪問中心數據庫，增加了對傳輸網絡的依賴性，系統處理速度稍慢。另外，如果用戶有新的應用需求，在集中式結構上滿足這些需要難度較大，因為每個用戶的應用程序和資源都必須單獨設置，而讓這些應用程序和資源都在同一套中央集中式服務器上操作，使得系統效率不高。該方案對服務器、軟件平臺及傳輸網絡的依賴性都較大，適合車站規模小且站點數目較少的線路。該方案數據庫部署及數據流如圖2所示。

圖2　中心數據庫集中部署方案及數據流

方案三，站點分布的數據庫部署方案：綜合監控系統不設置全局性數據庫，車站級數據庫作為數據收集、處理和保存的核心[1-2]；在日常工作期間，如果車站工作站需要查詢本區域范圍內的數據，只需在本地數據庫調取相關數據。如果網絡上某個節點需要查詢其他站點范圍內的數據，則需要通過網絡調取相應站點數據庫中的數據。控制中心可作為一個特殊站點考慮，控制中心的數據庫規模與車站相當。此外，由于電力監控系統對實時響應要求較高，且站間聯系較為緊密，因此需要將全線SCADA數據存入中心數據庫，以利于對全線的變電所綜合自動化系統信息的調用訪問和顯示，也便于控制中心電力調度人員對整個地鐵供電系統進行統一調度。

該方案對傳輸網絡的依賴較小，切換實時響應高，調試方便，對軟件要求低，配置也較低，但不利于數據的集中管理及備份操作。且需要增加站點服務器的存儲成本。適合車站規模大且站點數目較少的線路。該方案數據庫部署及數據流如圖3所示。

圖3　站點分布數據庫部署方案及數據流

方案四：混合數據庫部署方案：該方案可視為方案一的延伸，在方案一兩層的架構下增加集中站數據庫部署層次，以實現車站分為集中站和衛星站的管理模式[1-2]。該方案中心級綜合監控系統部署實時數據庫和歷史數據庫，中心不擔負每個車站級實時數據處理，只負責必須由中心級實現的功能，而將大量實時數據處理功能下放到車站一級。車站一級又分為集中站和分站，每3～4個車站設置一個集中站（與信號系統集中站的設置一致），其余為分站。集中站部署數據庫，負責各站的數據存儲，分站不部署數據庫。

圖4　混合數據庫部署方案及數據流

集中站與分站的關系：正常情況下，集中站具有本站設備監控功能，對分站設備只有監視功能和數據存儲功能；分站監控本站設備，分站授權給集中站后，集中站也可以具有對分站設備的控制功能。中心級與集中站、分站的關系：正常情況下，中心級直接與集中站互傳信息，集中站與分站互傳信息；經過集中站授權后，中心級綜合監控系統可以與分站直接互傳信息。該方案數據庫部署及數據流如圖4所示。

以上四個方案，在運營管理方面，方案一、方案二、方案四更適用于OCC集中運營管理，亦即更容易向將來車站無人管理模式過渡，方案三集中管理功能相對較為弱化，不易將來向車站無人管理模式過渡；在系統安全可靠性方面，方案一每一份數據均雙重拷貝，當某一車站的服務器宕機時，不會存在數據丟失，且其故障范圍只影響本站。方案四每個數據亦雙重拷貝，但當集中站宕機時，其故障波及范圍包括本站及其分站。方案二數據僅儲存于控制中心服務器內，方案三數據僅儲存于車站服務器內，無異地備份；在投資方面，方案一中心級軟件投入較高，車站級軟件投資費用較低，整體投資適中。由于硬件數量較多，總體投資較高。但若考慮服務器虛擬化技術的應用，該方案投資較低。方案二應用集中，軟件平臺要求較高，需部署大型數據庫管理系統等，軟件費用較高。但在硬件上大大節約了投資，總體投資較低。方案三由分布式數據處理軟件平臺及小型數據庫管理軟件構成。費用較低。硬件投資較方案一增加，總體投資適中。方案四軟件費用與方案一相近，但硬件數量少于方案一，總體投資適中；在可擴展性方面，方案一、方案三、方案四均采用分布式模塊化體系結構，其差別主要在方案一、四中心級結構龐大，擴展代價相對于方案三要高，由于方案二中心集中部署，方案三車站級采用集中站/分站結構，其擴展靈活性比方案一、二要低。

2　服務器配置方案

服務器應根據數據庫的部署方案設置，根據冗余方式的不同，存在不同方案，以下以中心集中與站點分布的數據庫部署方案為例，對服務器配置方案進行分析（以下分析同樣適用于其它數據庫部署方案）。該數據庫部署方案下服務器配置存在以下三個方案。方案一所有服務器冗余配置方案，方案二為中心級服務器冗余配置，車站級服務器鄰站互備方案，方案三采用服務器虛擬化技術集群配置服務器方案。

（1）方案一，所有服務器均為冗余配置，采用雙機熱備方式工作。正常情況下為兩臺服務器同時運行，一臺服務器被指定為進行關鍵性操作的主服務器，另一臺服務器作為備用服務器（配置一樣），兩機用心跳線相連，當主機出現問題，備機接管業務[3]。服務器工作示意圖如下。

正常情況時，如圖5所示。

圖5　方案一正常工作示意圖

站內服務器發生單點故障時，如圖6所示。

圖6　方案一單點故障工作示意圖

這種配置是國內外的城市軌道交通工程中綜合監控系統的典型配置。該方案的服務器配置檔次一般即可。

（2）方案二，中心級服務器冗余配置，車站級服務器鄰站互備方案。

中心級配置與方案一相同，車站級每個車站配置一套服務器，本站服務器同時作為鄰站的備用服務器，處理本站數據業務的同時備份鄰站數據。邏輯上的主備冗余的服務器采用雙機互備方式工作[3]。正常情況下，各站點服務器上分別運行不同的處理事件，應用不同，當某一站點主機出問題時，其上所有應用轉到鄰站服務器上，該鄰站服務器將同時負擔兩個站點的業務處理。

正常情況下，相當于將方案一的冗余服務器在地理位置上分散至相鄰兩站部署，如圖7。

圖7　方案二正常工作示意圖

當某一站點的服務器故障時，需要鄰站服務器接管故障服務器全部的應用。此時故障服務器站點工作站顯示的信息需要從鄰站服務器中獲得，如圖8。

圖8　方案二單點故障工作示意圖

這種配置使站間聯系較為緊密，故障情況下服務器負載會倍增，在國內外的城市軌道交通工程中綜合監控系統的較少使用。服務器配置將高于方案一的檔次。

（3）方案三，采用服務器虛擬化技術集群配置服務器方案。

1）虛擬化技術

虛擬化在計算機方面通常指計算元件在虛擬架構上而不是真實架構上運行。虛擬化技術的一個典型應用就是服務器虛擬化技術，在服務器虛擬化技術中，同一臺物理服務器上可以同時運行多個操作系統，可以通過虛擬化技術的應用，模擬出多臺邏輯上的服務器設備，且每一個操作系統為可以獨立運行的應用系統。服務器虛擬化技術可以實現服務器物理資源到邏輯資源的轉變，讓一臺服務器變成幾臺甚至上百臺相互隔離的虛擬服務器，或讓幾臺服務器變成一臺服務器來用，使用戶不再受限于物理上的界限，而是讓CPU、內存、磁盤、I／O等硬件變成可以動態管理的資源池，來靈活地進行資源的分配和調整[4]。

2）采用服務器虛擬化技術集群配置服務器方案

綜合監控系統僅在控制中心設置服務器集群，通過采用虛擬化技術，將多臺服務器虛擬化為一個服務器資源池，該資源池再向系統內的各類應用提供邏輯上獨立的虛擬服務器。如圖9所示。

圖9　服務器虛擬化方案

該方案優勢如下。

（1）降低成本。通過服務器虛擬化技術，控制和減少物理服務器的數量，明顯提高每個物理服務器及其CPU的資源利用率，從而降低硬件成本；降低運營和維護成本，包括控制中心和車站物理空間、耗電量、冷氣空調及人力成本等。

（2）提高運營效率。為IT基礎設施中所有資源的管理訪問提供單一且安全的接口，允許管理員對所有資源進行診斷，對所有資源進行配置和修改管理。

（3）虛擬化技術和存儲網絡的有效結合，提高了應用可用性、靈活性及安全性。相對于雙機環境下每臺服務器應用只能是另外一臺做備份服務器，在集群環境下，理論上的其他服務器，只要滿足條件，都可以是備援服務器，實現了群集化資源的高可用性。此外，一旦在服務器上安裝并運行了群集服務，該服務器即可加入群集，即可以隨意增加和刪改集群系統的節點，對于系統的擴展十分方便。

方案比選。綜合以上三個方案，從網絡需求角度分析，方案一站內實現系統數據處理及備份功能，不依賴網絡，傳輸網絡負荷較低。方案二站內實現數據處理功能，但需要站間數據備份，網絡負荷一般。方案三對網絡依賴最大，網絡負荷最高。從運營維護角度分析，方案一和方案二差別不大，方案三采用虛擬化技術，服務器數量最少且僅在中心設置，維護工作量最小。從投資成本角度分析，方案一投資略高于方案二，方案三最低，若綜合考慮服務器對物理空間的占用、耗電量、冷氣空調及維護成本，方案三遠遠低于方案一和方案二。從工程實施角度分析，方案一最為成熟，其對軟件要求低，實施難度小。方案二站內單服務器方便，切換調試較難，其對軟件要求較高，實施難度大。方案三國內外綜合監控系統項目均無實施案例，但在視頻點播系統、網絡搜索引擎等領域已有應用，實施難度大。

3　小結

綜合監控系統數據庫部署及服務器配置方案，應依據線路特點、技術發展水平、運營管理技術水平及需求進行選擇。本文對數據庫部署及服務器配置方案進行了全面的總結和歸納，為綜合監控系統的工程設計提供設計思路和方法。同時提出了基于服務器虛擬化技術的服務器配置方案，為云計算在城市軌道交通綜合監控系統中的應用提出了新的思路。

［1］管建華，王凱杰，秦小光，等.城市軌道交通主控系統研究報告［R］.天津：鐵道第三勘察設計院集團有限公司，2009.

［2］魏曉東.城市軌道交通自動化系統與技術［M］.北京：電子工業出版社，2011.

［3］GB 50636-2010.城市軌道交通綜合監控系統工程設計規范［S］.

［4］杭州華三通信技術有限公司.新一代網絡建設理論與實踐［M］.北京：電子工業出版社，2013.

(編輯：向飛)

Study for Database Deploymentand Server System in Integrated Supervision and Control System of Urban Rail Transit

YUAN Wei
（Guangdong Branch，the Third Railway Survey and Design InstituteGroup Corporation，Shenzhen518000，China）

According to different project features，technical level and operation managementdemands in integrated supervision and control system(ISCS)of urban rail transit，various schemes about database deployment and server system have been proposed.Each schemeemphases different，the purpose of this paper is to provide engineering train of thought，on the basis of the advantages and disadvantagesof them.At the same time，a new scheme isput forwardwhich isserver virtualization application in ISCS.

integrated supervision and controlsystem；database deployment；server system

TP399

A

1009－9492(2015)06－0077－05

10.3969/j.issn.1009-9492.2015.06.019

2015－02－28

袁偉，男，1984年生，陜西漢中人，碩士研究生，工程師。研究領域：通信及自動化。