高校信息化統一架構研究與探索

韓川疆

（西南石油大學 教務處，四川 成都610500）

隨著信息化建設的不斷推進，各個高校都有比較多的信息化相關子系統，且基本都建立了統一身份認證平臺，完成了對各個業務系統的數據抽取和整合。筆者走訪的北京、上海和成都等高校，發現這些信息化子系統都各自獨立，獨占一臺或多臺物理（或邏輯）服務器，這體現了高校在信息化統一架構和資源集中管理方面意識相對比較薄弱。本文以西南石油大學教務系統服務器架構調整為例，試圖利用現今互聯網企業在服務器運維方面的成熟技術，提出整個高校信息化整體架構藍圖，在信息化統一架構和資源集中管理方面進行了一些探索。

一、教務系統服務器架構調整及經驗

1.教務系統服務器架構的第1次調整分析

西南石油大學教務系統從2002年上線至今已到第十三個年頭，到目前為止經歷了兩次服務器架構的調整，在教務系統軟件開發商的配合下，取得了很好的效果。

學校教務系統上線初期采用兩臺Sun v880服務器，構建了兩套完整的應用系統，數據庫則建立在其中一臺服務器上。該系統提供給用戶兩個登錄點由用戶自行選擇登錄。

系統運行四年后，一方面由于高校的進一步擴招，在校生人數成倍遞增，導致學生選課時服務器資源耗盡；另一方面，由于服務器常年不間斷運行，電子元件老化也影響了系統運行效率。為此，學校采用如圖1所示架構，對服務器架構進行了第一次調整。調整內容有：幾何數的遞增，其中幾張主要業務邏輯表已經接近3000萬；二是隨著互聯網發展，各種移動應用采用非正規途徑獲取教務各種數據，教務系統軟件層面并沒有相關的保護措施。三是教務系統軟件本身程序上還有值得優化的地方。四是硬件老化。

圖1 西南石油大學教務系統服務器第一次調整架構

因此學校決定按照圖2所示，對原有架構進行第二次調整。

圖2 西南石油大學教務系統服務器第二次調整架構

（1）前端采用Apache配合Resin集群的方式做了負載均衡，后端數據庫采用雙機熱備的方式，后端存儲和數據庫服務器采用DAS（背板直連）方式連接，數據則存放在后端存儲上，存儲使用的是FC（光纖）硬盤。

（2）增加了監控服務器，用于收集服務器運行狀態數據。還可以通過設定相關服務器參數（CPU、內存、流量等）閾值，在無人職守的情況下，將預警數據實時發送到管理員郵箱，使管理員可以第一時間趕赴現場處理相關問題。

2.教務系統服務器架構的第2次調整分析

在架構調整之后幾年，運行狀況一直比較穩定，但是隨著時間的推移，從監控服務器所收集的數據發現，當多個教學活動集中在相同的時間段上進行時，服務器響應開始變慢。通過監控服務器收集的數據，結合對故障時間點的數據庫相關分析之后，發現問題可能是多方面的。一是數據量，從教務系統上線之后，數據一直在成

（1）前端采用高效、開源的HAProxy配合keepalived構建高可用負載均衡集群。中間是應用服務器集群。所有前端的請求通過負載均衡集群自動分發到后端相對空閑的應用服務器上。

（2）同樣采用開源的magent配合Memcached構建高可用的，且能自動負載均衡的數據庫緩存集群。

（3）數據庫集群。這里采用了Oracle RAC OneNode技術配置了兩個Oracle RAC服務器（每個RAC都有兩個節點），RAC-Server-1做為備庫只負責讀取操作，RACServer-2做為主庫負責寫入和更新操作。兩個RAC之間使用OracleDG做同步對稱復制保證數據的一致性，且同一時間兩個RAC都只有一個節點在工作。

（4）后端存儲和數據庫服務器依然采用DAS方式連接，數據則存放在后端存儲上，存儲使用的是SAS硬盤。

（5）同時，教務系統軟件增加數據歸檔功能，處理歷史數據。

3.調整經驗總結

經歷上面兩次的服務器整體架構的調整，總結出以下幾點經驗：

（1）教務系統軟件層面問題。現在很多面向教育的信息系統開發商，在開發過程中比較功利化，基本沒有考慮到程序在高負荷高并發時的優化。只有最終用戶遇到此類瓶頸才著手解決問題。再加上硬件先期投入也沒有考慮到架構上的優化，使得最終用戶遇到此類問題時措手不及。

（2）現在很多優秀的國內外互聯網公司，服務器運維能力和技術上已經相當成熟。因此，高校也應該與時俱進，參考互聯網公司優秀的運維案例，利用各類開源軟件，充分挖掘服務器的潛力，同時不斷完善服務器架構，提高運維能力和水平。

（3）信息系統數據的增長。從西南石油大學教務系統來看，上線13年后當主要業務邏輯表數據成幾何數遞增時，僅僅從信息系統程序或服務器架構調整等方面的優化已經不能滿足需求。還需要根據教務系統數據自身的特點，進行數據歸檔操作，將已經畢業學生的所有相關數據轉移到另外的數據庫中，信息系統則增加相應的對歸檔數據查詢的功能。

（4）必須要建立比較完整的服務器狀態監控平臺，以及服務器日志分析平臺。服務器狀態監控，不僅僅可以及早發現服務器異常問題及早解決，同時也為了解分析其他問題提供了詳細的數據依據。而日志分析，則為發現異常獲取數據、信息系統自身bug提供了良好的基礎。

（5）資源浪費問題。就教務系統本身而言，只有在選課、成績錄入、成績查詢等教學活動發生時才會出現高負荷和高并發的情況，而平常服務器資源占用非常低。

二、高校信息化統一架構探索

1.統一架構設想及說明

筆者設計和實施了西南石油大學教務系統的服務器架構，雖然經過調整后已經達到了很好的效果，但是如何避免服務器硬件資源的浪費，儼然成為筆者最關心的問題。

那么如果站在學校的層面，構建一個統一的服務器架構是不是能解決硬件資源浪費問題呢？答案是肯定的。但是這個架構必須能兼容高校所有的信息化子系統，必須能經受得住高負載高并發，必須能實時調配服務器硬件資源，必須能做大數據計算處理。因此筆者提出如圖3所示的整體架構。

圖3的架構只是給出了整體框架，在細節方面只有根據高校自身的需求進行定制，此外網絡拓撲中網絡冗余問題不在此架構討論范疇內。下面針對架構進行相關的說明，由于所涉及的可用技術很多，在這里就不詳細展開了，只給出筆者的建議。

2.技術及設備說明

（1）本地負載均衡集群，即負載均衡層

所有的請求（內網或外網）都由該層負責響應，并分發到后端的應用集群中。對于負載均衡，筆者熟悉的硬件或軟件技術有F5和LVS、Nginx、HAProxy等。它們的性能都是非常優異的。F5是負載均衡中抗并發能力最強的，LVS是現在在全世界范圍內應用最廣的，而HAProxy這個開源的后起新秀性能非常強勁，國內前十的互聯網公司基本都在使用。考慮到高校自身業務系統的實際情況，除了教務系統外不會有非常高的并發訪問。因此這里推薦采用開源的HAProxy配合Keepalived來架構，硬件方面配置兩到三臺兩路PC服務器就能承載校內所有業務系統的負載均衡。

如果上線運行過程中發現壓力過大，可以采用下面兩種方式進行緩解：

1）使用四路PC服務器，將其配置為主節點；

2）前端增加一個硬件的負載均衡F5，將現有的負載均衡集群做為中間代理層。

（2）應用集群和應用緩存集群

從負載均衡層轉發的請求直接到達應用集群層中的某一個服務器節點。那為什么沒有使用圖3中應用緩存集群來分擔壓力呢？應用服務器緩存層的出現確實是為了緩解應用服務器的壓力，存儲已被請求過的js、images和html等文件。但是環顧一下高校的各個信息系統，以及所提供的服務，分析一下每天的訪問情況，筆者認為沒有必要構建這個緩存集群。如果真的需要構建，如圖3所示，可以使用varnish作出兩個或更多的節點，此時只需要在負載均衡層HAProxy的配置中做相應的更改即可。

圖3 高校統一服務器架構藍圖

此外，考慮到各類信息系統程序運行的環境，在應用集群中需要配置至少兩種操作系統（Linux和Windows）的若干節點。

（3）數據緩存集群

它所實現的功能其實和應用緩存集群的功能類似。這里可以使用Redis或Memcached等開源軟件，構建出高可用的數據庫緩存集群。比如西南石油大學教務系統使用的是magent配合Memcached來構建的該集群，這主要是由于教務系統軟件已經使用了Memcached及相關特性，因此首先要滿足程序運行環境，其次考慮高可用。最終采用magent配合Memcached構建出能自動負載均衡的3個節點的集群。

由此，可以看出采用何種技術，或者都使用，需要根據具體的信息系統軟件本身的情況來決定，架構上只需要考慮高可用即可。

（4）數據庫集群

由于高校繁多的信息系統可能使用不同的數據庫，那么在這里就需要根據實際情況構建多個不同類型的數據庫集群，從對西南石油大學教務系統進行分析調整的過程中，筆者發現只有當信息系統的訪問量和并發量高到一定程度之后，數據庫就成為了壓力集中點。因此需要注意至少配置兩個節點構建出一主一備讀寫分離的同類數據庫節點。

（5）Oracle、MySQL和SQLSever說明

1）Oracle數據庫。可以采用上面已經提到的西南石油大學教務系統優化的方案。即采用了雙OracleRAC配置，需要應用程序配合將讀寫操作分開，兩個RAC之間使用OracleDG做同步對稱復制，它保證了兩個RAC直接數據的一致性。同時，Oracle RACOneNode技術最大化利用服務器資源，平常兩個RAC的主節點占用比較多的硬件資源，而備用節點則占用少量硬件資源，當發生故障后，主節點釋放已占用的大量硬件資源，備用節點啟用，接手相關業務的同時也加載和主節點相當的硬件資源。

2）MySQL數據庫。由于軟件本身免費，因此使用范圍是最廣的。面對并發壓力大的情況，成熟的方案也比較多，常見的主要有下面三種：

①常規復制架構，即Master-Slaves。這里Master負責寫入和修改操作，一個或多個Slave則負責讀取操作。同時將Master同步復制到一個或多個Slave。當一個節點的Slave讀取壓力過大時，則需要考慮增加Slave節點；

②級聯復制結合架構，即Master-Master-Slaves。雙Master主要是為了避免常規復制架構中單點寫入和修改操作可能存在故障的風險；

③MySQL數據庫切分，即MySQL Sharding。其基本思想就要把一個數據庫切分成多個部分放到不同的數據庫節點上，從而緩解單一數據庫的性能問題。因此可以通過該技術將一個大的MySQL Server切分成多個小的MySQL Server，既解了寫入性能瓶頸問題，同時也提升了整個數據庫集群的擴展性，從而解決了數據庫壓力過大的問題。

3）SQLSever數據庫。只考慮微軟提供的做法，僅僅只能做到故障轉移。簡單的說就是利用Windows Server故障轉移群集 (WSFC)功能，當數據庫實例發生故障時，在其他冗余服務器上重新啟動該數據庫實例，從而提供了本地數據庫的高可用性。這就類似一主一備（或互為主備）的服務器概念，沒有負載均衡的功能。在發生數據故障轉移時，將數據庫實例由一臺服務器轉移到另一臺服務器的時間非常短暫。

（6）磁盤陣列，即數據存儲

筆者把高校的數據分為核心數據和非核心數據。其中核心數據則包含教務、財務、一卡通等主要業務系統數據。而非核心數據，主要包括電子圖書、期刊、教學資源類、學習資源類等。這么劃分的原因是鑒于這些業務系統是否能中斷服務，可以臨時中斷的則劃為非核心數據，反之則是核心數據。

現今的存儲主要可以分傳統存儲和分布式存儲兩種。傳統存儲的架構方式主要有DAS、NAS和SAN。結合筆者對高校數據劃分以及預估的存儲容量的情況，使用NAS結合SAN才是高校存儲最好的方案，而分布式存儲技術投入和維護成本方面都遠高于傳統的存儲。

NAS架構主要用于存儲非核心數據，而SAN架構則用于存儲核心數據。對于存儲的物理磁盤，筆者建議直接使用SAS硬盤。在經費充足時，可以考慮有數據分層功能的NAS+SAN存儲，即存儲根據特定算法將數據分片，使用率高的自動遷移到SSD盤上，使用率一般的遷移到SAS盤上，使用率很低的則遷移到SATA盤上。

（7）Hadoop集群

主要是為了滿足高校在大數據方面的需求而建立。Hadoop本身是一個開源框架，同時Hadoop的高可靠性、高擴展性、高容錯性和高效性等諸多有點也是整個互聯網企業已經驗證的。雖然Hadoop搭建比較簡單，但是如果要真正為高校的領導決策、學生學習指導、學業預警等提供參考數據，前期規劃和后起運維也是必不可少的，而且后續還要有配套的相關支持分布式計算的應用程序。

（8）本地災備中心和異地災備中心

主要是出于數據層面的安全考慮。雖然可以根據實際情況的要求選擇性的建立，但是從整個架構數據的安全性和完整性來說，這也是必須的。

（9）管理集群

通過上面的描述，不難預見對于管理人員是多么大的挑戰，所謂工欲善其事必先利其器，建立一個完整的管理集群，提高管理人員的工作效率，提高整體運維水平是有直接影響的。

1）Monitor即監控平臺，提供了服務器實時狀態數據，為高負載高并發時服務器問題的分析提供了良好的數據參考，實時采用適當的措施解決出現的問題。同時，在無人職守的情況下可以通過電子郵件或短信等方式發出預警信息，方便運維人員能第一時間趕赴現場處理問題；

2）Pupput是一個開源的多平臺集中配置管理系統。試想服務器集群的配置如果一臺一臺去設置，會浪費多少時間和精力呢？因此在管理集群建立該系統，可以實現對該架構下所有服務器的管理系統配置文件、用戶、cron任務、軟件包、系統服務等配置信息進行管理；

3）D BAudit即數據審計平臺。數據的安全從來都不是某一方面可以完全保證的，而是需要利用多種方式結合保證。這里將數據審計納入管理集群，因為不管什么類型的數據庫，開啟數據審計后對自身性能或多或少都有一定的影響。那么開啟的時機把握，這必須由運維管理人員根據業務系統訪問情況來決定。同時，建議高校結合各個數據庫自身的審計功能，做一定的獨立開發構建符合自身特點的審計平臺。而不是購買數據審計軟件，因為可以兼容所有數據庫的數據審計軟件，功能上都比較中庸；

4）LogAnalyse即日志分析，可以結合Hadoop集群，給出很多值得參考的數據。比如訪問時間熱點、訪問來源、訪問出錯點、訪問異常點等。為進一步調整架構、發現業務系統bug等提供了良好的依據。

3.部分場景問題分析及解答

（1）應用場景一：教務系統如何部署？

圖3所示架構是在圖2所示架構的基礎上發展而來的，因此完全兼容教務系統本身，唯一需要注意的是原來采用DAS架構直連存儲，現在則是采用SAM架構，對操作系統層面沒有太大的區別。

（2）應用場景二：沒有采用相關緩存技術的應用系統如何部署？

1）本地負載均衡層配置相應訪問IP地址，以及后端單節點或多節點應用服務器IP地址；

2）應用集群中該業務系統的一個或多個節點服務器配置直接訪問數據庫的IP地址；

3）單節點數據庫可以共用或獨立使用一個數據庫集群的服務器節點。

（3）應用場景三：學校的統一數據庫如何部署？

直接部署在數據庫集群上，按照實際需求分割出一個或多個節點即可。

（4）應用場景四：單個業務系統處于高并發時如何處理？

首先根據監控平臺數據分析高并發后業務系統的瓶頸。比如瓶頸在應用層，則考慮是否需要使用應用緩存集群，以及增加應用集群中該業務系統的節點數量。比如瓶頸在數據層，則需要根據數據庫的類型來確定調整的方案，限于篇幅此處就不再展開。

4.需要注意的一些問題

該架構整合了學校所有硬件資源，能滿足各類型信息系統的要求，但是還需要注意以下幾個問題：

（1）整個架構都基于虛擬化平臺，建議采用免費的XenServer做為虛擬化平臺管理軟件；

（2）硬件資源（即PC服務器）分批購置，先滿足基本業務然后逐步擴展，建議不要都使用同一廠商的產品；

（3）硬件老化后維保成本較高時，建議直接淘汰購置新硬件；

（4）優秀開源項目的軟件很多，采用開源軟件也能為學校節約相當大一部分資金，但是需要有優秀的運維人員，因此需要建立良好的人才培養機制，做好人才儲備工作；

（5）需要根據學校實際的情況，對整個架構做局部的調整，只有通過不斷地微調得到符合自身需要的架構。

三、總結

根據筆者對西南石油大學教務系統服務器架構調整的經驗，提出了整合資源、統一部署的信息化整體架構，相信高校只要加強這方面的意識，從自身已擁有的信息化系統需求出發，結合互聯網企業優秀的運維技術和運維案例，肯定可以在此架構基礎上設計出符合自身特點的信息化統一架構，為節約辦學成本、實施大數據戰略提供有力的保障。