醫(yī)院容災項目解決方案_第1頁
醫(yī)院容災項目解決方案_第2頁
醫(yī)院容災項目解決方案_第3頁
醫(yī)院容災項目解決方案_第4頁
醫(yī)院容災項目解決方案_第5頁
已閱讀5頁,還剩33頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、醫(yī)院容災方案容災解決方案上海金仕達衛(wèi)寧軟件股份有限公司二 0 一一年七月. . . .目 錄系統(tǒng)及數(shù)據(jù)安全的重要性.3傳統(tǒng)的容災方式及容災技術指標.42.12.22.3傳統(tǒng)的容災方式.4容災方案的技術指標.5容災的核心問題.63數(shù)據(jù)庫系統(tǒng)容災解決方案.63.1建設目標.63.1.13.1.23.1.33.1.4為關鍵業(yè)務系統(tǒng)構建容災機制.6持續(xù)保護核心業(yè)務數(shù)據(jù) .6增量鏡像減少對生產(chǎn)主機的性能影響 .7無需增加昂貴的硬件設備投入.73.2復制容災策略.73.2.13.2.2定時全量復制,保障容錯.7實時增量復制,保障容災.83.3浪擎鏡像系統(tǒng)架構和工作原理.83.3.13.3.2應用架構 .8

2、基于事務的邏輯數(shù)據(jù)復制工作原理. 113.4與其他基于存儲層復制技術的比較.164容災系統(tǒng)部署及措施.164.14.24.34.4建設目標.16需要部件配置.16應用部署.17容災啟用時采取的措施.18置預算.18本方案特色.196.16.26.36.46.56.66.76.86.9備用端可查詢.19高性價比.19方便靈活.19高效率、低負載.19基于 Web 的任務監(jiān)控和配置管理 .19全方位的復制包含各種數(shù)據(jù)類型.19災難恢復.19可選擇性復制.20更低成本的容災方案.20可編輯. . . .1 系統(tǒng)及數(shù)據(jù)安全的重要性隨著醫(yī)院各項業(yè)務系統(tǒng)信息化,數(shù)字化進程的發(fā)展,數(shù)據(jù)越來越成為醫(yī)院日常運作

3、的核心決策發(fā)展的依據(jù)。由于網(wǎng)絡的發(fā)展,網(wǎng)絡安全也越來越引起人們的重視,歸根到底網(wǎng)絡安 全的核心也就是數(shù)據(jù)的安全。有機構研究顯示:丟失 300MB 的數(shù)據(jù)對于市場營銷部門就意味著 13 萬元人民幣的損失。 對財務部門就意味著 16 萬的損失,對工程部門來說損失可達 80 萬。而企業(yè)丟失的關鍵數(shù)據(jù) 如果 15 天內(nèi)仍得不到恢復,企業(yè)就有可能被淘汰出局。如 CIH 和愛蟲等病毒給國際社會造成損失多達數(shù)十億美金。國內(nèi)有客戶誤刪有效數(shù)據(jù)由于沒有備份造成停業(yè)手工重新錄入,給企業(yè)造成損失數(shù)十萬元。這種教訓在國內(nèi)時有發(fā)生,這都說明了保證信息數(shù)據(jù)安全的重要性.醫(yī)院信息系統(tǒng)安全防護措施的制定和實施是保證醫(yī)院信息系

4、統(tǒng)的穩(wěn)定性、可靠性、安全性、可用性的利器。目前醫(yī)院網(wǎng)絡系統(tǒng)覆蓋全院的每個部門,涵蓋病人來院就診的各個環(huán)節(jié),幾百臺計算機同時運行,支持各方面的管理,成為醫(yī)院開展醫(yī)療服務的業(yè)務平臺,醫(yī)院信息系統(tǒng)的安全性直接關系到醫(yī)院醫(yī)療工作的正常運行,一旦網(wǎng)絡癱瘓或數(shù)據(jù)丟失,將會給醫(yī)院和病人帶來巨大的災難和難以彌補的損失。因此,醫(yī)院計算機網(wǎng)絡系統(tǒng)的安全工作非常重要,特別是核心業(yè)務數(shù)據(jù)庫服務器系統(tǒng)的安全,必須制定周密的安全維護措施,以確保醫(yī)院計算 機網(wǎng)絡系統(tǒng)持久、穩(wěn)定、高效、安全地運行。對數(shù)據(jù)庫安全的威脅或侵犯大致可以分為以下幾類:自然災害:自然的或意外的事故,災難,例如地震,水災,火災等導致的硬件損壞 ,進而 導

5、致數(shù)據(jù)的損壞和丟失.人為疏忽:由授權用戶造成的無意損害,特別在批處理作業(yè)的情況下.惡意破壞:存心不良的編程人員,技術支持人員和執(zhí)行數(shù)據(jù)庫管理功能的人員的破 壞,毀損及其他行為.犯罪行為:盜竊行為,監(jiān)守自盜,工業(yè)間諜,出賣公司秘密和郵件列表數(shù)據(jù)的雇員.隱私侵害:不負責任的獵奇,競爭者查看數(shù)據(jù),為政治和法律目的獲取數(shù)據(jù)諸如此類的事件都有可能隨時在我們的身邊發(fā)生。那么在這些事故導致的后果是什么呢?至少,我們很難想象這么不幸的醫(yī)院還能正常的為患者服務。因為在這個信息化的社會,信息往往是維持醫(yī)院正常工作的基礎保證。所以我們該如何避免醫(yī)院信息遭到破壞,該如何 避免信息災難的發(fā)生,已經(jīng)列入每位醫(yī)院領導所考慮

6、的重要議程。面對醫(yī)療信息化建設的快速發(fā)展,如何應對醫(yī)院信息系統(tǒng)出現(xiàn)的各種意外故障,如何提可編輯. . . .高醫(yī)院抗風險能力和應對突發(fā)事件的能力?通過對醫(yī)療市場分析和醫(yī)療領域所提出的種種規(guī)范可以得出醫(yī)療行業(yè)對容災系統(tǒng)的要 求有如下幾點:容災系統(tǒng)必須保證醫(yī)院各業(yè)務系統(tǒng)能不間斷運行。容災系統(tǒng)不能影響醫(yī)院各業(yè)務系統(tǒng)的運行狀態(tài)。必須改變傳統(tǒng)冷備份的先天不足。保證數(shù)據(jù)的準確性、安全性、冗余性。當災難發(fā)生時,容災系統(tǒng)必須能全面,快速的恢復業(yè)務系統(tǒng)。特殊地區(qū)容災需要做到異地容災,保證數(shù)據(jù)安全。容災系統(tǒng)的備用系統(tǒng)必須為可用系統(tǒng),備用數(shù)據(jù)必須為可用數(shù)據(jù)。容災系統(tǒng)數(shù)據(jù)必須保證與生產(chǎn)系統(tǒng)數(shù)據(jù)實時同步。2 傳統(tǒng)的容災

7、方式及容災技術指標2.1 傳統(tǒng)的容災方式1. 數(shù)據(jù)備份是數(shù)據(jù)容災的基礎備份是指為防止系統(tǒng)出現(xiàn)操作失誤或系統(tǒng)故障導致數(shù)據(jù)丟失,而將全系統(tǒng)或部分數(shù)據(jù)集合從應用主機的硬盤或陣列復制到其它的存儲介質的過程。數(shù)據(jù)備份是數(shù)據(jù)高可用的最后一道防線,其目的是為了系統(tǒng)數(shù)據(jù)崩潰時能夠快速的恢復數(shù)據(jù)。雖然它也算一種容災方案,但這種容災能力非常有限,因為傳統(tǒng)的備份主要是采用數(shù)據(jù)內(nèi)置或外置的磁盤機進行冷備份,備份磁盤同時也在機房中統(tǒng)一管理,一旦整個機房出現(xiàn)了災難,如火災、盜竊和地震等災難 時,這些備份磁盤也隨之銷毀,所存儲的磁盤備份也起不到任何容災功能。2. 雙機熱備的備份方式面對災難各大容災廠商首先所提出的容災解決方

8、案就是雙機熱備技術。雙機熱備技術是基于應用切換的原理即整個容災系統(tǒng)由兩套業(yè)務系統(tǒng)和共享一個存儲陣列所構成。一但主服務器出現(xiàn)異常或故障,備份服務器立刻接管主服務器的應用。也就是目前通常所說的active/standby 方式,主要通過純軟件切換的方式實現(xiàn)雙機容錯。因為兩臺服務器共享一個磁盤陣列上的數(shù)據(jù),所以當磁盤損壞的時候就造成兩臺服務器都不可用,這樣就達不到容災的效果。而且通過純軟件來切換的話存在誤切換的情況,就是當主服務器還是正常的時候就 把業(yè)務系統(tǒng)的連接切換到備用服務器上,這就會造成業(yè)務系統(tǒng)的暫時停頓等問題。3. 雙機雙存儲雙機雙存儲即在雙機熱備的基礎上增加一套存儲,實現(xiàn)應用層的切換和底層

9、數(shù)據(jù)的不間可編輯. . . .斷復制。其工作原理與雙機熱備類似。數(shù)據(jù)庫若要能夠正常啟動,必會先檢測其數(shù)據(jù)文件,日志文件,控制文件等一系列文件的完整性,才可以正常啟動。對于雙機雙存儲的存儲層復制來說是文件層復制,他們無法做到檢測數(shù)據(jù)的一致性,一旦雙機雙存儲發(fā)生的是邏輯錯誤 時,無論是主服務器還是備用服務器都將無法啟動。4容災不是簡單備份真正的數(shù)據(jù)容災就是要避免傳統(tǒng)冷備份的先天不足,它能在災難發(fā)生時,全面、及時地 恢復整個系統(tǒng)。容災按其容災能力的高低可分為多個層次,例如國際標準 SHARE78 定義的容災系統(tǒng)有七個層次:從最簡單的僅在本地進行磁盤備份,到將備份的磁盤存儲在異地,再到建立應用系統(tǒng)實時

10、切換的異地備份系統(tǒng),恢復時間也可以從幾天到小時級到分鐘級、秒級 或 0 數(shù)據(jù)丟失等。容災系統(tǒng)的目的在于保證系統(tǒng)數(shù)據(jù)和服務的“在線性”,即當系統(tǒng)發(fā)生故障時,仍然能夠正常地向網(wǎng)絡系統(tǒng)提供數(shù)據(jù)和服務,以使系統(tǒng)不致停頓。而容災備份技術的目的與此并不相 同,備份是“將在線數(shù)據(jù)轉移成離線數(shù)據(jù)的過程”,其目的在于應付系統(tǒng)數(shù)據(jù)中的邏輯錯誤和歷史數(shù)據(jù)保存。所以,在各種容錯技術非常豐富的今天,備份系統(tǒng)仍然是不可替代的。 2.2 容災方案的技術指標1RTO (Recovery Time Object):是指“將信息系統(tǒng)從災難造成的故障或癱瘓狀態(tài)恢復到可正常運行狀態(tài),并將其支持的業(yè)務功能從災難造成的不正常狀態(tài)恢復到可

11、接受狀態(tài)”所需時間,其中包括備份數(shù)據(jù)恢復到可用狀態(tài)所需時間、數(shù)據(jù)處理系統(tǒng)切換時間、以及備用網(wǎng) 絡切換時間等,該指標用以衡量容災方案的業(yè)務恢復能力。2RPO(Recovery Point Time):是指業(yè)務系統(tǒng)所允許的災難過程中的最大數(shù)據(jù)丟失量(以時間來度量),這是一個與數(shù)據(jù)備份系統(tǒng)所選用的技術有密切關系的指標,用以衡量災難恢 復方案的數(shù)據(jù)冗余備份能力。3容災半徑:是指生產(chǎn)中心和災備中心之間的直線距離,用以衡量容災方案所能防御 的災難影響范圍。顯然,具有零 RTO、零 RPO 和大容災半徑的災難恢復方案是用戶最期望的,但受系統(tǒng)性能要求、適用技術及成本等方面的約束,這種方案實際上是不大可行的。所

12、以,用戶在選擇容災方案時應該綜合考慮災難的發(fā)生概率、災難對數(shù)據(jù)的破壞力、數(shù)據(jù)所支撐業(yè)務的重要 性、適用的技術措施及自身所能承受的成本等多種因素,理性地作出選擇??删庉? . . .2.3 容災的核心問題1容災適應性:指的是容災系統(tǒng)在實施和使用的過程中對原有的生產(chǎn)系統(tǒng)、硬件系統(tǒng)、網(wǎng)絡系統(tǒng)的影響,有的容災系統(tǒng)可能需要凍結原有的生產(chǎn)系統(tǒng)的情況下進行數(shù)據(jù)的復制,有點容災系統(tǒng)可能要對硬件、網(wǎng)絡環(huán)境進行改造,改造成系統(tǒng)所要求的條件。這些對改造對原 有的系統(tǒng)和數(shù)據(jù)都存在一定的風險性。2容災可見性:指的是容災系統(tǒng)的容災效果是不是可見、可查詢的。有的容災系統(tǒng)的容災效果要等災難發(fā)生之后,備用系統(tǒng)恢復之后才能驗證是

13、不是真做到了數(shù)據(jù)零丟失的效 果。如果數(shù)據(jù)復制失敗不能馬上反應出來同樣達不到容災的效果。所以容災系統(tǒng)的核心問題:能否構建一個綠色容災系統(tǒng),在實施和使用過程中不會影響原生產(chǎn)系統(tǒng),無需改造硬件和網(wǎng)絡環(huán)境,其容災結果的好與壞又實時可見、可驗證。 3 數(shù)據(jù)庫系統(tǒng)容災解決方案3.1 建設目標3.1.1 為關鍵業(yè)務系統(tǒng)構建容災機制浪擎鏡像系統(tǒng)通過建立業(yè)務系統(tǒng)的可用副本,實現(xiàn)了以高可用性為目的系統(tǒng)冗余。利用可讀寫的數(shù)據(jù)副本,可在生產(chǎn)系統(tǒng)需要計劃或非計劃停機時,改善可用性達到容災目的。 當主系統(tǒng)停止服務時,可立即啟用備用系統(tǒng)并切換應用,實現(xiàn)持續(xù)服務。經(jīng)綜合分析,備份需求如下:業(yè)務系統(tǒng)服務器實時備份到備用服務器。

14、容災系統(tǒng)對生產(chǎn)機(主服務器)不能有任何性能影響。必須保證該系統(tǒng)的正常運行。為降低容災成本,提高資源利用率主備服務器硬件規(guī)格或配置無需相同。 強調(diào)持久化服務能力,業(yè)務系統(tǒng)運行不允許中斷。強調(diào)數(shù)據(jù)的準確性,業(yè)務系統(tǒng)不允許丟失數(shù)據(jù)或出錯。需要可靠的容災方案,保證數(shù)據(jù)的安全及提供快速的恢復能力。3.1.2 持續(xù)保護核心業(yè)務數(shù)據(jù)通過鏡像代理將核心業(yè)務系統(tǒng)運行過程中生成的數(shù)據(jù)實時地復制到本地備用數(shù)據(jù)庫中,減小因意外故障導致的數(shù)據(jù)損失。傳統(tǒng)的數(shù)據(jù)保護解決方案專注在對數(shù)據(jù)的周期性備份上, 因此一直存在備份窗口、數(shù)據(jù)一致性以及對生產(chǎn)系統(tǒng)的影響等問題。浪擎鏡像系統(tǒng)不存在備份窗口問題,可以為業(yè)務系統(tǒng)提供足夠細的保護

15、粒度,形成持可編輯. . . .續(xù)保護機制。當源系統(tǒng)發(fā)生災難時其數(shù)據(jù)丟失量可以降低到幾秒。3.1.3 增量鏡像減少對生產(chǎn)主機的性能影響考慮到醫(yī)院業(yè)務系統(tǒng)負荷繁重,為了高效地實現(xiàn)鏡像不影響原來業(yè)務系統(tǒng)運行,鏡像系統(tǒng)增量處理復制數(shù)據(jù),即計算數(shù)據(jù)變化情況,并僅鏡像自上次鏡像以后變化的數(shù)據(jù)。其示意 圖如下:第一次完整鏡像增量鏡像序列量據(jù)數(shù)時間軸增量處理示意圖浪擎鏡像系統(tǒng)支持塊級別的增量傳輸技術,提高傳輸效率,減少帶寬占用。 3.1.4 無需增加昂貴的硬件設備投入浪擎鏡像系統(tǒng)在應用層實現(xiàn)將捕獲業(yè)務應用事務轉發(fā)復制到目標系統(tǒng),這種復制原理決定源主機和目標主機無需硬件規(guī)格一致,目標主機可采用低于源主機的硬件

16、規(guī)格。由于僅 復制增量事務,大大的減少網(wǎng)絡傳輸流量,因此無需專用傳輸網(wǎng)絡。浪擎鏡像系統(tǒng)支持一對多鏡像方式,可根據(jù)實際業(yè)務系統(tǒng)環(huán)境可將多臺源服務器的數(shù) 據(jù)復制到一臺備用服務器,大大節(jié)省硬件投入。3.2 復制容災策略3.2.1 定時全量復制,保障容錯浪擎鏡像系統(tǒng)提供便捷的定時全量鏡像復制計劃,保障容錯功能。全量鏡像復制功能作業(yè)可配置信息字段:開始時間、結束時間和日期以及在這段時間之內(nèi)的鏡像頻率、需要鏡像 表。定時鏡像計劃通過追逐式復制來實現(xiàn)。定時的將 SQL server 數(shù)據(jù)庫的全部數(shù)據(jù)復制目可編輯. . . .標服務器;目標服務器將最近一個全量版本保存起來,可恢復 SQL server 到這個

17、版本。從 而實現(xiàn)數(shù)據(jù)庫容錯功能。在本方案中,可配置每天做一個全量復制計劃,并且將全量復制數(shù)據(jù)也保存在目標服務 器。3.2.2 實時增量復制,保障容災實時鏡像復制技術,實時數(shù)據(jù)復制技術不需要通過任何數(shù)據(jù)庫的引擎來獲取變更數(shù)據(jù),而是通過鏡像系統(tǒng)的實時捕獲分析來獲取源系統(tǒng)上的改變并傳送給目的系統(tǒng),不會對生產(chǎn)系 統(tǒng)和數(shù)據(jù)庫造成任何性能上的影響,保障了容災功能。3.3 浪擎鏡像系統(tǒng)架構和工作原理3.3.1 應用架構采用浪擎鏡像系統(tǒng)的鏡像服務器、SQLServer2005 鏡像代理、鏡像任務監(jiān)控軟件解決上述需求。浪擎鏡像系統(tǒng)的鏡像代理支持自動檢測文件或數(shù)據(jù)庫的增量變化,無需以掃描文件系統(tǒng)或數(shù)據(jù)庫方式來判斷

18、變化,并且支持高效的增量傳輸算法,從而支持重負荷條件下的秒級別實時鏡像頻率,對原來系統(tǒng)的性能影響極少。鏡像系統(tǒng)由鏡像代理(客戶端)、鏡 像服務器(服務器端)以及管理端組成。在 HIS 雙機的兩臺 SQLServer2005 數(shù)據(jù)庫服務器上均安裝浪擎SQLServer 鏡像代理,在備用服務器上安裝鏡像服務器端。設置浪擎SQLServe 鏡像代理的檢測路徑為主存儲路 徑,鏡像服務器設置路徑為備用存儲路徑。1)當 HIS 雙機熱備的主服務器處于 Active 狀態(tài)時,把 Active 服務器的浪擎SQLServe鏡像代理連接至 SQLServer 鏡像服務器。當鏡像代理檢測到主存儲數(shù)據(jù)變化后,將捕獲

19、變化 的數(shù)據(jù)實時的復制到備用存儲上。實現(xiàn)了實時的復制。具體部署如下圖:可編輯. . . .終端終端終端管理員ActiveSQL2005Windows2003HIS主服務器HAActiveSQL2005Windows2003存儲設備終端用戶訪問數(shù)據(jù)實時鏡像HIS 備用服務器鏡像架構圖 12)當 Active 和 Standby 服務器通過設置切換后,即備用服務器處于 Active 狀態(tài)時,把安裝在備用服務器上的浪擎SQLServe 鏡像代理連接至 SQLServer 鏡像服務器。當鏡像代理檢測到主存儲上數(shù)據(jù)變化時將捕獲變化的數(shù)據(jù)實時的復制到備用存儲上。實現(xiàn)了實時的 復制。具體部署如下圖:終端終端

20、終端管理員終端用戶訪問數(shù)據(jù)實時鏡像StandBySQL2005 Windows2003HIS主服務器HAActiveSQL2005 Windows2003HIS 備用服務器存儲設備鏡像架構圖 23)當主、備服務器都停止服務,即主備服務器都無法提供業(yè)務系統(tǒng)服務的時候,鏡像 服務可直接接替主備服務器工作保障業(yè)務系統(tǒng)的持續(xù)運行,具體部署如下圖:可編輯. . . .終端終端終端管理員終端用戶訪問數(shù)據(jù)實時鏡像StandBySQL2005Windows2003 HIS主服務器HAActiveSQL2005Windows2003 HIS 備用服務器存儲設備鏡像架構圖 34)當主、備服務器都恢復工作后,即主備

21、服務器都可以正常提供業(yè)務系統(tǒng)服務的時候,鏡像服務器會繼續(xù)其對主服務器的鏡像工作,并且在這之前會通過鏡像系統(tǒng)的同步工具保障 系統(tǒng)數(shù)據(jù)的同步和一致,具體部署如下圖:終端終端終端管理員終端用戶訪問 數(shù)據(jù)實時鏡像 數(shù)據(jù)同步ActiveSQL2005Windows2003HIS主服務器HAStandBySQL2005Windows2003HIS 備用服務器存儲設備鏡像架構圖 4通過以上 4 點保證了備用存儲上的數(shù)據(jù)和主存儲上的數(shù)據(jù)完全一致。避免了主存儲的單 點故障。管理端可部署在備用服務器上或系統(tǒng)管理員主機上。系統(tǒng)管理員可通過管理端配置鏡像策略、全量和增量作業(yè)等。在主數(shù)據(jù)庫服務器上設置需復制的 SQLS

22、erver2005 數(shù)據(jù)庫名稱和可編輯. . . .定時復制計劃。3.3.2 基于事務的邏輯數(shù)據(jù)復制工作原理3.3.2.1 傳統(tǒng)的數(shù)據(jù)備份磁帶、光存儲介質的備份和恢復效率比較低,導致數(shù)據(jù)損失比較大,也使服務停止導致的費用與損失增加。基于磁帶備份系統(tǒng)的災難恢復解決方案需磁帶介質單獨保管,且進行恢 復操作之前需在本系統(tǒng)和另外一個系統(tǒng)上進行長時間的恢復系統(tǒng)和數(shù)據(jù)。采用數(shù)據(jù)庫或應用系統(tǒng)層面的實時邏輯數(shù)據(jù)復制技術進行應用數(shù)據(jù)復制建立備用系統(tǒng),可解決上述問題。實時數(shù)據(jù)復制保障應用系統(tǒng)數(shù)據(jù)丟失程度極??;具備應用切換功能保障業(yè) 務系統(tǒng)持續(xù)運行。實時可到秒級或分鐘級。比較如下:比較項系統(tǒng)原理復制頻率增量復制技術

23、備份窗口浪擎鏡像系統(tǒng)鏡像代理捕獲數(shù)據(jù)庫事務 變化實時秒級別增量數(shù)據(jù)庫記錄極小,接近于零傳統(tǒng)備份系統(tǒng)通過相應系統(tǒng)提供的備份接口實現(xiàn)備份 小時級別不支持小時級別數(shù)據(jù)丟失概率實時復制,數(shù)據(jù)丟失概率極 丟失一個備份周期的數(shù)恢復時間系統(tǒng)性能影響低無需恢復極小據(jù)小時級別非常大浪擎鏡像系統(tǒng)通過高效捕獲應用系統(tǒng)變化,從而將變化數(shù)據(jù)復制到備用服務器,極大地降低對原來系統(tǒng)性能的影響。一般而言,浪擎鏡像系統(tǒng)在復制數(shù)據(jù)時 CPU 占用不超過 10%,內(nèi)存占用不超過 20MB。由于所用機制不同,這是傳統(tǒng)備份系統(tǒng)所不能做到的?;跀?shù)據(jù)復制技術的災難恢復解決方案的主要優(yōu)點在于:恢復操作不需要進行重建工作,通常停機的時間會非

24、常短,對于客戶端一側來說也 基本不需要重新配置??删庉? . . .邏輯數(shù)據(jù)復制安裝在操作系統(tǒng)的文件系統(tǒng)或應用系統(tǒng)層中,對應用程序和硬件設備 是透明的。在應用中,支持源與目的系統(tǒng)之間跨局域網(wǎng)或廣域網(wǎng)的異步復制。而且,支持塊級的數(shù)據(jù)傳輸和邏輯表達式過濾,占用的帶寬資源較少。用戶可選擇復制數(shù)據(jù)庫或文 件。浪擎鏡像基于事務日志分析技術,將數(shù)據(jù)庫事務定時或實時應用到目標數(shù)據(jù)庫,占用極少的系統(tǒng)開銷,極大地改善數(shù)據(jù)庫可用性,可用于容災和數(shù)據(jù)同步領域。對備用服務器硬件和網(wǎng)絡等無特殊要求,可實現(xiàn)低成本、高保障的備份和容災。該系統(tǒng)是業(yè)界成熟的高性能/高可用的邏輯數(shù)據(jù)復制解決方案,具有系統(tǒng)資源占用少、配置靈活、實

25、時鏡像等特點,解 決關鍵應用的可用性問題以及適應數(shù)據(jù)同步需求。3.3.2.2 工作原理1)鏡像引擎架構SQLServer 數(shù)據(jù)庫鏡像引擎包括代理、鏡像服務器、基準裝載器三大部件。代理包含事務日志實時捕獲器、事務日志分析器、自適應數(shù)據(jù)字典、初步過濾器、傳輸控制器和任務隊 列等;鏡像服務器包含接收隊列、事務隊列和 Snapshot 存儲、SQL 應用機構等。2)復制流程事務日志實時捕獲器實時監(jiān)控源 SQLServer 事務日志文件和捕獲其變化數(shù)據(jù);事務日志分析器通過數(shù)據(jù)字典將日志數(shù)據(jù)解析還原成數(shù)據(jù)庫記錄,并過濾不需要鏡像的表或其他數(shù)據(jù)庫對象;傳輸控制器從任務隊列中取出記錄數(shù)據(jù)傳輸至鏡像服務器。鏡像

26、服務器接收隊列將記錄數(shù)據(jù)保存至事務隊列和 Snapshot 文件中;SQL 應用機構掃描事務隊列,將提交事務應 用到目標 SQLServer。如下圖所示。可編輯. . . .SQLServer鏡像原理示意圖3)傳輸控制傳輸控制器記錄當前傳輸成功的事務點。當連接中斷等因素導致傳輸失敗,傳輸控制則 停止傳輸工作,嘗試連接直至成功。4)基準裝載基準裝載器使用 SQLServer 數(shù)據(jù)庫提供的在線備份功能,將源數(shù)據(jù)庫備份出來,還原至 目標數(shù)據(jù)庫,實現(xiàn)源和目標數(shù)據(jù)庫基準一致。5)目標數(shù)據(jù)庫狀態(tài)目標 SQLServer 處于運行狀態(tài),能讀能寫,運行的目標系統(tǒng)保證了系統(tǒng)的一致性。3.3.2.3 基于 WEB

27、 的復制任務和運行狀態(tài)監(jiān)控WEB 監(jiān)控界面可監(jiān)控全網(wǎng)的備份任務及運行狀態(tài)。每條監(jiān)控記錄就是一條完整的復制鏈 路,包含鏡像代理、鏡像服務器、運行狀態(tài)。配置如下:可編輯. . . .監(jiān)控配置示意圖Web 可監(jiān)控全網(wǎng)所有鏡像代理、鏡像服務器的工作狀態(tài)以及所有復制任務。復制任務監(jiān) 控信息包括:編號:根據(jù)任務復制的順序來排序的。類型:模塊類型,有文件,SQL SERVER 和 ORACLE 三種。服務器:鏡像服務器所在服務器 IP。目標數(shù)據(jù)庫:鏡像服務器端備份數(shù)據(jù)庫的名稱。執(zhí)行內(nèi)容:具體復制的內(nèi)容,數(shù)據(jù)庫監(jiān)控的是 SQL 語句,文件監(jiān)控的是復制的文件名。 開始時間:任務開始執(zhí)行的時間。結束時間:任務執(zhí)行

28、結束的時間。狀態(tài):任務執(zhí)行完成后的狀態(tài),如果復制成功顯示為成功,失敗顯示的是失敗3.3.2.4 主要實現(xiàn)功能可編輯實時單向數(shù)據(jù)鏡像,單向鏡像以主服務器系統(tǒng)作為復制的數(shù)據(jù)源,復制到備用數(shù)據(jù) 庫用于查詢。定時鏡像計劃,系統(tǒng)還提供便捷的定時鏡像計劃。鏡像計劃作業(yè)可配置信息字段:開始時間、結束時間和日期以及在這段時間之內(nèi)的鏡像頻率、需要鏡像數(shù)據(jù)庫。定時鏡像計劃類似于基準裝載,均通過 SQLServer 數(shù)據(jù)庫提供在線備份功能實現(xiàn)。數(shù)據(jù)一致性校驗,系統(tǒng)提供對鏡像的表進行數(shù)據(jù)一致性校驗,并修改目標表的數(shù)據(jù)。 這種補償性能力解決當鏡像系統(tǒng)停止時,源和目標產(chǎn)生的不一致性。. . . .數(shù)據(jù)庫備份存儲,鏡像系統(tǒng)

29、可將基準裝載或定時鏡像計劃使用的數(shù)據(jù)庫備份保存在磁盤上;系統(tǒng)采用時間戳命名備份文件。用戶可調(diào)節(jié)保存的備份版本數(shù)量或時間;用戶可手工在 SQLServer 企業(yè)管理器中將數(shù)據(jù)庫備份還原至數(shù)據(jù)庫中。3.3.2.5 數(shù)據(jù)庫容災策略1)初次完全備份或基準同步基準裝載器使用 SQLServer 數(shù)據(jù)庫提供的在線備份功能,將源數(shù)據(jù)庫備份出來,還原至 目標數(shù)據(jù)庫,實現(xiàn)源和目標數(shù)據(jù)庫基準一致。或者,以后需要再次基準同步時仍然可使用基準裝載器。2)實時增量備份或同步事務日志實時捕獲器實時監(jiān)控源 SQLServer 事務日志文件和捕獲其變化數(shù)據(jù);事務日志分析器通過數(shù)據(jù)字典將日志數(shù)據(jù)解析還原成數(shù)據(jù)庫記錄,并過濾不需

30、要鏡像的用戶、表或其他數(shù)據(jù)庫對象;傳輸控制器從任務隊列中取出記錄數(shù)據(jù)傳輸至鏡像服務器。鏡像服務器接收隊列將記錄數(shù)據(jù)保存至事務隊列和 Snapshot 文件中;SQL 應用機構掃描事務隊列,將提交 事務應用到目標 SQLServer 數(shù)據(jù)庫。3.3.2.6 故障切換和回切大致說明下述啟用過程對前端用戶而言是透明的。當主業(yè)務系統(tǒng)停止服務時,關閉鏡像系統(tǒng)復制作業(yè)。徹底關閉主業(yè)務系統(tǒng)所在服務器,包括關閉業(yè)務系統(tǒng)、SQLServer 數(shù)據(jù)庫。啟用備用服務器上的網(wǎng)絡名稱資源,完成此步驟使備用服務器與主服務器具備一樣 的計算機名稱或 IP 地址。業(yè)務系統(tǒng)連接到備用 SQLServer 數(shù)據(jù)庫系統(tǒng)。前端用戶可

31、繼續(xù)使用業(yè)務系統(tǒng)。在實施后,需編制每套業(yè)務系統(tǒng)的具體故障切換步驟和應急措施。當主服務器修復后,需要將備用服務器的業(yè)務數(shù)據(jù)回切到主服務器數(shù)據(jù)庫中。具體方法 和所采用軟件如下:利用鏡像系統(tǒng)提供全量備份軟件回切業(yè)務系統(tǒng)數(shù)據(jù)庫數(shù)據(jù)。將備用服務器的數(shù)據(jù)庫全量 備份出來,并拷貝備份文件至主服務器,還原至數(shù)據(jù)庫中??删庉? . . .3.4 與其他基于存儲層復制技術的比較與基于存儲層的復制技術比較如下:復制原理比較項浪擎系統(tǒng)基于存儲層的復制技術采用應用系統(tǒng)專屬的復制, 復制磁盤設備層每個 IO,然后同 復制每個 SQL 事務步或異步寫入遠程備用存儲方案投入成本維護成本主、備份系統(tǒng)硬件要求 傳輸網(wǎng)絡要求容災級

32、別應用系統(tǒng)事務完整性保證備用(目標)系統(tǒng)狀態(tài)RPO 目標RTO 目標支持一對多復制方式遠低于存儲復制成本 維護量比較少無要求無要求處于第五或六層一致備用數(shù)據(jù)庫完全處于 open 可用狀態(tài)恢復精度達記錄級別 恢復時間可接近零 支持極為昂貴的投入需經(jīng)過廠商認證的、專業(yè)的存儲 工程師,維護成本巨大采用硬件規(guī)格一致的設備 專用的光纖網(wǎng)絡處于第六或七層不能保證事務一致性,備用系統(tǒng) 可能不能啟用備用數(shù)據(jù)庫處于不可用狀態(tài),如 需要則需創(chuàng)建第三方鏡像“回放”可能是錯誤的 恢復時間不可預測不支持4 容災系統(tǒng)部署及措施 4.1 建設目標為關鍵業(yè)務系統(tǒng)構建容災機制 持續(xù)保護核心業(yè)務數(shù)據(jù)增量鏡像減少對生產(chǎn)主機的性能影

33、響無需增加昂貴的硬件設備投入4.2 需要部件配置針對于上述需求說明,選用以下規(guī)格的部件及數(shù)量:SQLServer 數(shù)據(jù)庫鏡像代理(For SQLServer 2005),4 套。 鏡像服務器(For SQLServer 2005),2 套。鏡像任務監(jiān)測系統(tǒng),1 套。文件備份代理,1 套??删庉? . . .管理服務器,1 套。容災機房的硬件配置需要滿足網(wǎng)絡互聯(lián)互通及容災服務器設備等。4.3 應用部署1、當生產(chǎn)數(shù)據(jù)中心的服務器,如HIS 系統(tǒng)所在正常狀態(tài)時,把生產(chǎn)服務器中的 SQLServer鏡像代理通過網(wǎng)絡連接至容災中心的鏡像(備份)服務器。在正常情況下,當鏡像代理檢測到磁盤陣列數(shù)據(jù)變化后,將

34、捕獲變化的數(shù)據(jù)實時的復制到備用存儲上,實現(xiàn)了實時的復制。 具體部署如下圖:2、在一般情況下,當主數(shù)據(jù)庫服務器出現(xiàn)故障時候,通過 HA 軟件將服務自動切換至備 份 SQLServer 數(shù)據(jù)庫服務器。部署說明:鏡像代理安裝在主服務器上;鏡像服務器安裝在備用服務器上;系統(tǒng)管理界 面提供給系統(tǒng)管理人員使用。醫(yī)院關鍵業(yè)務系統(tǒng)容災系統(tǒng)部署生產(chǎn)數(shù)據(jù)服 務器(群)數(shù)據(jù)存儲容災數(shù)據(jù)服務器業(yè)務數(shù)據(jù)流SAN 交換機數(shù)據(jù)存儲容災數(shù)據(jù)流其他服務器其他服務器HIS服務器HIS服務器應用服務器HIS服務器-OSPF核心層門診樓住院北樓內(nèi)科樓住院南樓外科樓匯聚層接入層鏡像架構部署圖 13、管理端可部署在備用服務器上或系統(tǒng)管理

35、員主機上。系統(tǒng)管理員可通過管理端配置鏡像策略、全量和增量作業(yè)等。在主數(shù)據(jù)庫服務器上設置需復制的 SQLServer 數(shù)據(jù)庫名稱和定時復制計劃。當主數(shù)據(jù)庫服務器出現(xiàn)故障時候,通過 HA 軟件將服務自動切換至備份 SQLServer 數(shù)據(jù)庫服務器。4、通過文件復制的方式來確保兩個數(shù)據(jù)中心之間應用服務器中相關程序的實時一致。可編輯. . . .4.4 容災啟用時采取的措施在生產(chǎn)數(shù)據(jù)中心相關核心業(yè)務數(shù)據(jù)庫服務器出現(xiàn)災難性故障時,根據(jù)醫(yī)院實現(xiàn)確定系統(tǒng) 容災服務器啟用的預案的流程,起用容災系統(tǒng)中的相關服務器。分如下情況:1、 在某個業(yè)務系統(tǒng)數(shù)據(jù)庫服務器或存儲系統(tǒng)出現(xiàn)災難故障時,只要改變相關應用服務器程序中

36、的數(shù)據(jù)庫服務器指向,重新登陸系統(tǒng)即可。業(yè)務的恢復是最快的。2、 在相關業(yè)務系統(tǒng)在生產(chǎn)中心均出現(xiàn)災難故障時,需要在終端 PC 機設置中重新改變相關的應用服務器或數(shù)據(jù)庫服務器的指向,重新登陸系統(tǒng)即可。受影響的工作站終端可能需要重新下載或配置有關的終端文件或設置。業(yè)務的恢復相對要慢些的。建議可以通過諸如“內(nèi)容交付”設備或終端管理系統(tǒng)的文件分發(fā)(主動下載或推 送方式)來快速處理。醫(yī)院關鍵業(yè)務系統(tǒng)容災系統(tǒng)部署生產(chǎn)數(shù)據(jù)服 務器(群)數(shù)據(jù)存儲容災數(shù)據(jù)服務器業(yè)務數(shù)據(jù)流SAN 交換機數(shù)據(jù)存儲容災數(shù)據(jù)流其他服務器其他服務器HIS服務器HIS服務器應用服務器HIS服務器-OSPF核心層門診樓住院北樓內(nèi)科樓住院南樓外科樓匯聚層接入層鏡像架構部署圖 25 置預算序號配置數(shù)量價格(萬元)小計(萬元)浪擎鏡像系統(tǒng)實現(xiàn) HIS 業(yè)務數(shù)據(jù)系統(tǒng)容災(包括 SQLServer 數(shù)據(jù)庫鏡像代理1 1 套 40 40 軟件,鏡像服務器軟件,鏡像任務監(jiān)測系軟件,文件備份代理軟件等)3 合計(萬元) 40可編輯. . . .6 本方案特色6.1 備用端可查詢由于備用數(shù)據(jù)庫處于打開運行狀態(tài),不同于冷容災模式下容災站點的數(shù)據(jù)庫系統(tǒng)在進行數(shù)據(jù)復制是不可用的情況,因此備用數(shù)據(jù)庫可以通過

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論