珠海市社區衛生服務中心關鍵業務應用服務器及信息化系統容災備份建設方案
1、現狀分析
珠海市金灣區三竈社區衛生服務中心（如下簡稱：三竈醫院）信息化建設狀況：上線使用的系統有HIS，LIS（檢驗信息系統），體檢系統，萬晟達系統（舊數據），病案系統，中醫體質辨識系統，計免系統以及婦幼、公衛、全科系統。其中計免系統、婦幼、公衛、全科系統是全市統一上線維護；關鍵業務系統有HIS、LIS、體檢系統，且其應用已經很是普遍。在門診掛號、門診收費、門診發藥、藥品出入庫、病人入院、住院醫囑信息、結帳等數據都存放在服務器數據庫中，對實時性要求很是高。然而HIS、LIS、體檢等系統均是單機運行狀態，數據庫沒有啓用實時備份功能，服務器也沒有啓用雙機熱備份功能。目前醫院HIS系統應用部署在單臺服務器上，另一臺HIS服務器作冷備服務器處理，該服務器經過光纖網絡鏈接到光纖交換機，再經過光纖鏈接到後端單臺存儲設備上；LIS與體檢系統運行的服務器則配置較低且設備陳舊（體檢系統服務器已在我中心採購計劃中）。sql
從信息系統的運行維護管理指標和醫院建設現狀看，目前面臨的主要難題是：數據庫
業務中斷（RTO指標）；後端
數據丟失（RPO指標）；瀏覽器
維護力量不足（連續運營能力）。安全
2、需求分析
據瞭解，爲保證數據安全和系統的正常運行，目前大部分醫院都使用了雙機熱備份方案。由於數據的安全性關係到整個系統可否正常運行，最終關係到可否爲患者提供正常的服務。系統數據一旦丟失，對醫院、社會都會形成沒法估量的損失。對此我中心組織對信息系統進行了信息風險排查，並針對會出現的風險提出了相應的解決方案。服務器
1．1業務持續風險分析
1.1 .1 業務中斷風險（軟件硬件問題）網絡
目前LIS、HIS、體檢數據庫服務器均是單機運行，萬一出現硬件或者軟件故障，各個應用及數據庫將會陷於癱瘓，影響到各個信息業務系統的運行：架構
1)出現故障時，若是是硬件故障，首先要對硬件進行維修或者更換，具體時間要取決於廠商的維修時間或者定貨週期；oracle
2)硬件修復或者更換以後，還要進行系統恢復、數據庫軟件安裝、數據恢復，這將花費幾個小時甚至更長時間，其中數據庫應用每每還須要開發廠家的現場支持。框架
1.1.2 數據丟失風險
1) HIS磁盤陣列雖然作了Raid，爲系統提供了相對安全、可靠的運行和存儲環境，但也成了系統的單一故障節點。雖然Raid自己有必定的安全策略，可是極端狀況下發生故障（控制器、RAID卡故障或其它軟硬故障），醫院的業務將所有中斷，數據可能永久丟失。
2)LIS系統開始上線的時候對業務數據的預估不夠充分，致使如今使用時常常出現數據庫歸檔日誌溢出，在清除歸檔日誌數據以前檢驗業務都不能進行了。且該問題出現頻繁，平均每兩個月就會出現數據庫歸檔日誌出錯問題。對保障業務不間斷和業務人員維護都帶來比較大困難。
3） 體檢系統服務器設備陳舊且配置較低，曾經出現過服務器硬件設備損壞致使體檢服務器沒法啓動的狀況。無雙機備份且無有效的快速恢復業務的技術手段，維修設備期間嚴重耽誤體檢業務。
2.1 維護難度大，維護力量不足
2.1.1 預檢維護制度落實難度大
系統持續運行的要求比較高，基本無主動停機進行維護維修的機會，預檢維護制度沒法落實。即使有數據備份的措施，但也沒法確認備份的數據是否有效，由於如需驗證，就必須將數據倒回原系統運行，原系統就需停頓。
2.1.2 專業要求高、信息工做人員不足
目前三竈醫院信息科系統維護人員僅有一個，要負責整個醫院的信息工做，且專業技能有限；系統出問題後處理的應急性不夠，未能在較短期內恢復系統使用；而數據及服務器維護的專業要求較高，這給常常性的運行維護帶來較大的難度。
2.1.3 應急演練、快速恢復手段少
單機單系統設計，在不中斷業務狀況下，沒法組織組織常常性的應急演練，日常也很難進行實際操做的訓練，沒法保證維護人員在災難狀況下的處置水平。
目前的系統維護都是面向維護工程師專業設計，一線值勤維護人員缺乏簡單有效的快速恢復業務的技術手段。在災難發生時，一線值班人員實際上基本作不到現場快速恢復，需等待相關維護人員、廠商服務商到場，業務中斷時間、數據丟失的風險不可控。
3、雙機軟件解決方案
3.1雙機高可用方案
【什麼是雙機】
就是對於重要的服務，使用兩臺服務器，互相備份，共同執行同一服務。當一臺服務器出現故障時，能夠由另外一臺服務器承擔服務任務，從而在不須要人工干預的狀況下，自動保證系統能持續提供服務。
【爲何須要雙機熱備】
雙機熱備針對的是服務器的故障。服務器的故障可能由各類緣由引發，如設備故障、操做系統故障、軟件系統故障等等。通常地講，在技術人員在現場的狀況下，恢復服務器正常可能須要１０分鐘、幾小時甚至幾天。從實際經驗上看，除非是簡單地重啓服務器（可能隱患仍然存在），不然每每須要幾個小時以上。而若是技術人員不在現場，則恢復服務的時間就更長了。 而對於一些重要系統而言，用戶是很難忍受這樣長時間的服務中斷的。所以，就須要經過雙機熱備，來避免長時間的服務中斷，保證系統長期、可靠的服務。
3.2雙機高可用系統的搭建
硬件系統
服務器
1. 每臺服務器擁有各自的系統盤，用來安裝操做系統軟件，雙機軟件。
2. 每臺服務器安裝一塊額外的網卡。（雙機互被援用Dual Active Hosting）
3. 每臺服務器提供一個還沒有使用的網口。（用來做心跳偵測信息的線路）
●公共驅動器
l 磁盤陣列系統
軟件系統
操做系統
a) Windows 2003 server/Windows 2008/Linux/SCO UNIX
應用支持
b) 共享文件
c) Microsoft IIS
d) 數據庫，Oracle，Sybase，Informix
e) Microsoft BackOffice Server
f) 正式發行的，運行在NT下的應用軟件等
●雙機容錯系統軟件
l ROSE HA軟件
雙機容錯基本架構
模式一 雙機互備援（Dual Active）基本介紹
雙機互被援就是兩臺服務器均爲工做機，在正常狀況下，兩臺工做機均爲信息系統提供支持，並互相檢測對方的運行狀況。當一臺主機出現異常時，不能支持信息系統正常運營，另外一主機主動接管異常機的工做，繼續支持信息的運營，從而保證信息系統可以不間斷的運行。（無需共享存儲）以下圖：
模式二 雙機熱備份（Hot Standby）基本介紹
雙機熱備份就是一臺主機爲工做機（Primary Server），另外一臺主機爲備份機（Standby Server），在系統正常狀況下，工做機爲信息系統提供服務，備份機監視工做機的運行狀況（工做機同時也在檢測備份機是否正常），當工做機出現異常，不能支持信息系統運營時，備份機主動接管工做機的工做，繼續支持信息的服務，保證系統不間斷的運行。（需共享存儲）以下圖：
3.3 實現的功能
l 服務器掉電時，能實現自動切換。
l 服務器的硬盤、CPU、RAM發生故障時，能自動切換。
l 網絡鏈接故障時，能發生自動切換。
l 操做系統，數據庫或應用程序發生故障時，能實現自動切換。
l 提供手動切換功能，使系統管理員能夠在主機負載過大時或其它適當的時候，實現手動切換。
l 能安全完成屢次切換。
雙機高可用系統工做原理
雙機系統的兩臺服務器（主機）都與磁盤陣列（共享存儲）系統直接鏈接，用戶的操做系統、應用軟件和ROSE高可用軟件分別安裝在兩臺主機上，數據庫等共享數據存放在存儲系統上，兩臺主機之間經過私用心跳網絡鏈接。配置好的系統主機開始工做後，ROSE軟件開始監控系統，經過私用網絡傳遞的心跳信息，每臺主機上的ROSE軟件均可監控另外一臺主機的狀態。當工做主機發生故障時，心跳信息就會產生變化，這種變化能夠經過私用網絡被ROSE軟件捕捉。當捕捉到這種變化後ROSE就會控制系統進行主機切換，即備份機啓動和工做主機同樣的應用程序接管工做主機的工做（包括提供TCP/IP網絡服務、存儲系統的存取等服務）並進行報警，提示管理人員對故障主機進行維修。當維修完畢後，能夠根據ROSE的設定自動或手動再切換回來，也能夠不切換，此時維修好的主機就做爲備份機，雙機系統繼續工做。
LCHA工做原理示意圖
此方案容錯功能實現的關鍵是在系統發生錯誤進行切換時，對客戶端來講主機是透明的，即主機的切換在工做端看來沒有變化，全部基於主機的應用都正常。ROSE採用了虛擬IP地址映射技術來實現此功能。客戶端經過虛擬地址和工做主機通信，不管系統是否發生切換虛擬地址始終指向工做主機，在客戶端看來主機是透明的。在進行網絡服務時，在雙機系統後臺ROSE提供一個邏輯的虛擬地址，任何一個客戶端須要訪問系統時只須要使用這個虛擬地址。當雙機系統中的一臺服務器出現故障時，ROSE會將另一臺服務器網卡的IP地址更換爲這個虛擬地址，繼續提供網絡服務。切換完成後，在客戶端看來系統並無出現故障，網絡服務也沒有間斷。除IP地址外，ROSE HA還能夠提供虛擬的計算機別名供客戶端訪問。對於數據庫服務，當有一臺服務器出現故障時，另一臺服務器就會自動接管數據庫引擎，同時啓動數據庫和應用程序，使用戶數據庫能夠正常操做。
4、備份系統解決方案（備份一體機）
4.1 設計思路
保持現有網絡架構、容災設計不變，增長一套統一備份系統作全方面備份部署。提高統一容災、持續運營能力，實現「數據不丟失，業務快速恢復」的運維目標，達到運行維護管理的「可控、簡單」。
保持現有的系統構架基本框架不變，部署統一容災系統備份一體機；
數據丟失小於半小時；
數據恢復點目標RPO小於半小時。
極簡操做，數據隨時驗證恢復；
採用「統1、簡單」設計，在統一平臺上完成全方位數據、系統的備份，提供極簡的自、一體化備份體驗，而且數據可隨時驗證與恢復。
創建基礎平臺，容災系統功能可擴展。
在保持如今基礎平臺的基礎上，將來根據經費和管理目標要求，方便地經過增長受權和功能模塊，來擴展對其餘業務系統的保護或提高維護指標。
4.2 信息系統備份方案
4.2.1 方案概述
備份一體機的做用首先是給被保護的服務器增長一個邏輯存儲空間，並經過網絡映射給被保護服務器，服務器的操做系統、應用環境、相關數據自動備份到邏輯存儲空間中。
備份一體機對被保護服務器的數據變化，進行定時快照，實現快速恢復和多版本保存。
4.2.2 複製策略
經過制定不一樣、合理的複製策略，實現集中、無人值守、自動化的數據在線複製。在災難發生時，對系統和數據進行應急接替，及時恢復業務運行，使損失減至最小。
在系統第一次複製時，經過初始複製模式對整個系統盤進行復制，在以後運行中可按須要進行計劃性的增量複製，可設置具體複製策略：
服務器名稱 |
複製策略 |
實現指標 |
50臺虛擬機服務器 |
定時R ｜ 根據須要可設定天級別或更小級別的在線定時複製 |
RTO<5分鐘，RPO<60分鐘 |
4.2.3 實現效果
採用快照技術，對數據庫服務器上的數據變化，造成連續時間點快照。當災難發生時，能夠選擇任意時間點的快照造成副本，保證業務數據丟失小於1小時；
在線複製與在線還原，不影響系統的正常運行；
複製的系統、應用和數據獨立於生產系統以外；
自動生成多版本快照，確保可用、可靠；
不影響生產系統的正常工做；
具備充分的可擴充的網絡容災應急設計，最大程度保護前期投資，後期能夠經過增長受權的方式升級爲應用級容災，保障業務持續性。
4.2.4 方案特色
4.2.4.1全面在線複製的產品設計
備份一體機不只僅複製業務系統的數據，並且複製包括業務服務器操做系統以及業務運行的完整軟件環境，包括：
操做系統；數據庫系統；中間件系統；各類應用系統等。
4.2.4.2易於擴展的一體化容災技術實現
備份一體機採用軟、硬件一體化設計，可方便地進行「交鑰匙」方式業務功能交付，部署、管理便利。
備份一體機採用模塊化設計，可根據須要靈活選擇相應的功能模塊，同時，當應用環境變化時，能夠方便地進行升級擴展：包括存儲容量的擴展、應急方式的擴展、保護服務器數量的擴容等，可有效地保護用戶的初期投資。
4.2.4.3易用易維護
備份一體機的操做管理採用全中文的WebUI，不須要安裝任何管理軟件，任何具備網絡互通能力的終端均可以方便地經過瀏覽器登錄系統管理程序，進行操做和管理。
4.3 統一備份系統工做原理
在統一容災系統部署完成後，將爲每臺生產服務器分配一組容災存儲，配合安裝在生產服務器上的客戶端軟件，根據預先設定的策略，自動對各服務器的操做系統、應用軟件、數據及數據庫實施動態差別量在線複製，複製後在備份一體機系統上生成用於應急、容災的快照，供應急、容災、恢復時選用。
當實施網絡啓動操做系統、應用軟件並恢復業務功能後，可在系統I/O比較少的時間（如深夜），使用備份一體機系統的恢復功能，自動或手動對各服務器原有的磁盤進行恢復操做；將存放在網絡存儲裏的可用的操做系統、應用軟件、數據及數據庫恢復（回寫）到本地盤，該操做支持對多臺服務器的自動恢復，方便運營管理。
RPO ≦1小時。
支持定時複製， RPO ≦1小時；
提供任快照點回滾的數據保護和恢復功能。
恢復還原方式
採用PXE協議的網絡啓動應急模式在線恢復還原；
支持手動還原。
保護範圍
操做系統、應用程序、數據庫、數據文件等。
複製方式
在線複製，支持增量複製、全量複製
操做系統
Microsoft Windows 2003/2008 Server；
Microsoft SQL Server；
Oracle；
擴展存儲：支持FC SAN、iSCSI SAN、DAS等方式的存儲容量擴展，擴展容量無上限。
業務持續管理功能
內置BCM管理模塊
操做界面
支持中文操做界面，支持Web管理方式。
自身安全
系統自身採用自主專用操做平臺。
5、容災平臺建設（容災一體機）
5.1 容災平臺建設的意義
應用級雙活容災系統，是一款融合了雲計算、虛擬化技術、CDP技術、數據挖掘技術、遷移技術的容災產品，引領應用級容災、災備恢復、跨平臺遷移、業務系統雲化、跨平臺數據共享的解決方案。具有更高技術條件和要求的應用級雙活容災系統（容災一體機），既能實現雙機備份的自動接管服務器業務功能；也兼有備份一體機對存儲數據進行備份的動能；並擁有更高的時效性與數據完整性，可達到RPO和RTO趨於零；能夠多系統多機接入，一體管理；並擁有更直觀和方便的操做，方便維護。後續須要增長業務系統進入容災平臺，只需購買受權便可。
採用應用級雙活容災系統，對本地機房核心的業務系統進行統一保護，對操做系統、應用、數據進行實時同步，當保護的業務系統或整個機房發生故障(物理故障、邏輯故障)，能在3-5分鐘內快速的接管故障的業務系統對外提供服務，物理服務器業務系統、虛擬化業務系統、私有云業務系統的高可用性。應用級雙活容災系統不只提供容災接管功能，同時還附帶業務系統歷史版本恢復和仿真測試功能，歷史版本恢復功能可將業務系統的整個工做負載（系統、應用、數據）恢復到任意時間點；使用仿真測試功能提供與生產環境一摸同樣的系統、應用、數據，在對生產服務器升級補丁、升級軟件的時候能夠仿真測試平臺中進行測試，測試經過後再在生產環境中操做，如此可下降升級所致使的故障。
基於軟件科技的產品應用級雙活容災系統的技術和功能來實現信息系統的總體容災平臺建設，經過對醫院核心的業務系統(操做系統+應用+數據)進行一體化保障，方案拓撲圖以下：
(容災平臺拓撲圖)
5.2容災平臺建設要求
編號 |
要求 |
描述 |
1 |
故障切換時間要求 |
切換時間不超過5分鐘，最好在3分鐘內實現。 |
2 |
多種故障切換方式 |
提供自動故障切換和手動故障切換方式 |
3 |
計劃內維護要求 |
提供計劃內維護支持能力，計劃內維護切換時間很少於10分鐘 |
4 |
數據丟失性要求 |
原則上要求零數據丟失，能夠依據狀況進行調整 |
5 |
數據傳輸要求 |
採用異步方式和磁盤底層複製技術以下降對生產業務的性能影響 |
6 |
數據實時複製要求 |
實時複製數據變化的部分，數據丟失RPO趨向與零 |
7 |
物理部件失敗要求 |
支持磁盤，文件系統，主機，磁盤櫃等各類物理部件問題致使的失敗保護 |
8 |
站點失敗要求 |
支持因爲火災，電力以及其餘因素致使站點失敗的數據保護。 |
9 |
邏輯失敗要求 |
支持因爲數據塊損壞致使的數據庫沒法啓動，數據丟失等邏輯失敗保護 |
10 |
人爲錯誤失敗要求 |
支持因爲人爲誤操做以及***等致使人爲錯誤失敗致使的數據保護或者恢復。 |
11 |
生產系統的性能影響要求 |
生產系統性能影響不超過5% |
12 |
生產系統可用性要求 |
容災系統不會下降生產系統可用性 |
13 |
網絡鏈路分鐘級別短暫故障 |
要求不會對生產系統產生影響 |
14 |
網絡鏈路小時級別長期故障 |
要求不會對生產系統產生影響 |
15 |
網絡鏈路密集的秒級別短暫故障 |
要求不會對生產系統產生影響 |
16 |
網絡鏈路容錯 |
支持網絡鏈路的容錯，能夠利用網絡的備份鏈路，好比多路網卡等 |
17 |
容災系統的硬件故障 |
因爲容災系統硬件故障致使的容災系統不可用不會對生產系統產生影響，好比網卡，磁盤以及控制卡等 |
18 |
容災系統的軟件故障 |
因爲容災系統軟件故障致使的容災系統不可用不會對生產系統產生影響，好比容災系統管理軟件部件等 |
19 |
網絡協議 |
採用IP網絡實現 |
20 |
網絡帶寬 |
現有的百兆或千兆帶寬 |
21 |
RTT要求 |
RTT要求在10ms之內便可知足要求，能夠容忍部分時間的30ms響應 |
22 |
在線實施要求 |
要求在災備系統實施期間保持生產系統運行 |
23 |
存儲系統失敗的原址運行 |
在生產系統主機可用的狀況下能夠支持系統原址運行 |
24 |
部分文件失敗的原址運行 |
在部分文件失敗的狀況下能夠支持系統原址運行 |
25 |
原址運行要求 |
在生產系統出現如下故障時，不進行容災切換，而原址運行；在生產系統主機可用的狀況下能夠支持系統原址運行；在部分文件失敗的狀況下能夠支持系統原址運行 |
26 |
容災切換要求 |
提供一對1、多對一的容災複製和切換； |
27 |
一鍵切換 |
支持單健切換，全部切換都要求提供圖形界面模式，全部切換都要求一步完成。 |
28 |
全業務切換 |
支持業務系統級別切換，進行完整的數據庫，中間件以及其餘中間件的自動/手動切換。 |
29 |
業務部件切換 |
支持業務部件級別切換，在業務系統某一部件發生故障，僅僅切換該部件到容災系統，好比數據庫等。 |
30 |
網絡切換 |
支持網絡切換，而且能夠指定在切換時候是否支持網絡切換。 |
5.3技術路線
將本地機房全部業務系統的整個工做負載的變化，實時同步到對應的應急容災虛擬機，保障生產系統與容災系統保持一致，當本地數據中心單個業務系統或多個業務系統故障，自動或手動切換到進行接管。因爲虛擬機的特性，整個應急容災接管過程能夠在3-5分鐘級別內實現。
經過提供用於保護本地數據中心全部業務系統工做負載的經濟實惠且易於使用的解決方案，使部署、測試和管理災難恢復解決方案的方式發生革命性變化。將醫院全部的業務系統工做負載保護到統一的可擴展的容災平臺中，免卻了昂貴的重複硬件和軟件投資。
5.3.1採用磁盤I/O級監控技術
採用獨特的磁盤I/O監控技術，對磁盤塊的寫入的扇區進行記錄。在磁盤驅動層監控到的I/O操做能真實的反應出應用程序在寫入文件時所作的實際更改。持續不斷的刷新和記錄磁盤塊的變化bitMap地址表，並對對應的扇區讀取數據傳輸到，確保數據一致。與常見的基於文件的複製技術不一樣，採用基於監控磁盤I/O的複製技術，只須要讀取變化的磁盤塊並傳輸到，相比基於文件的複製技術，佔用系統性能資源極少，數據傳輸更少的優勢，從而將生產服務器性能的影響降到最低，極大的提升數據傳輸的效率和下降帶寬要求。
5.3.2 Oracle RAC和MSCS雙機等數據庫的保護技術
經過對oracle 等數據庫的事務日誌（redo log）作實時分析，獲取數據庫中的全部操做命令和數據，並將這些數據根據不一樣的應用類型進行加工處理，處理結果被分配到全部訂閱了這些數據的隊列中，再由每一個訂閱的數據應用程序將數據裝入對應的數據庫中，一旦雙機生產庫發生故障，直接切換到應用級雙活容災系統，接管故障的雙機數據庫系統；在生產庫未發生故障的狀況下，可將應用級雙活容災系統做爲數據庫的查詢庫使用，減輕生產庫的壓力。
5.3.3自動複製技術
採用自動複製技術，能夠製做不止一份的備份版本，提供異地存放的磁盤數據，避免磁盤自己出錯形成的數據損失。保證更高的數據安全性。並且可將磁盤上因使用並行流形成的混雜順序的數據以數據自己順序的方式複製，可大大提升恢復速度。進一步提升備份和恢復性能。
5.3.4開放式備份數據格式
提供的實時工做負載虛擬化備份，採用傳統的虛擬系統格式，所以備份出來的工做負載可在KVM、VMware ESXi等虛擬化平臺上直接運行，當程序損壞時也不會影響到備份工做負載的讀取。
5.3.5帶寬控制技術
在一些本來帶寬資源就不寬裕的生產網裏，用戶能夠對備份佔用的帶寬有計劃的實施限制，防止因數據備份佔用的帶寬對生產網產生影響。計劃的好處在於當網絡處於非繁忙時段，能夠全速傳輸備份數據到指定服務器。也支持計劃任務，只在特定的時間段，如凌晨1:00，纔開始增量數據的備份。
5.3.6輕鬆實現異地容災
傳統的系統級別的HA解決方案，每每侷限於本地實施。基於TCP/IP協議傳輸數據，所以，沒有地理範圍的限制。不管是實現數據的高可用仍是系統級別的高可用，都無需侷限在本地進行。配合數據壓縮和帶寬控制技術，能夠極大下降用戶用在異地數據備份網絡上的投資。
5.3.7數據對比校驗機制
經過數據對比校驗機制，來保證源服務器和容災平臺上的數據在斷開後從新鏈接進行校驗，保證數據全一致性。若是有數據不一致，會把數據增量變化部分複製到容災平臺，能夠保證用戶源服務器和容災平臺上的數據真正徹底一致。
5.3.8結合虛擬化技術更低成本實現多業務保護
結合服務器虛擬化技術，經過提供用於保護數據中心的全部工做負載的經濟實惠且易於使用的解決方案，使部署、測試和管理災難恢復解決方案的方式發生革命性變化。可將多臺物理和虛擬機工做負載總體保護到單臺容災設備上，從而使您能夠保護更多生產系統，並免卻了昂貴的重複硬件和軟件投資。
5.3.9自動或手動故障切換方式
爲防止業務系統管理員不在現場致使沒法及時處理故障切換，用戶可對一些關鍵應用配置自動故障切換。配置監視被保護業務系統的聯網狀態，在知足指定的條件後，會自動配置並接管源生產系統的全部應用。用戶也能夠選擇手動操做，防止因誤操做致使故障切換帶來的二次故障。
5.3.10按期演練測試下降風險
按期演練測試是災難恢復計劃中很是關鍵卻每每被忽視的部分。能夠快速方便地測試工做負載複製的完整性。只需單擊鼠標，就能夠啓動容災演練虛擬機，用於驗證應用系統的副本是否有效。因爲演練測試系統與生產網絡隔離，所以能夠放心操做，而無需擔憂影響生產系統的正常運行。
6、方案配置
配置清單
序號 |
名稱 |
推薦參數 |
數量 |
備註 |
說明 |
1 |
雙機備份軟件 |
雙機熱備軟件，支持Windows Server版本操做系統（Windows2003/R二、Windows2008/R二、WIndows2012/R2）支持Linux Server 版本操做系統（RedHat 5/6/7.0/7.1；CentOS 5/6/7.0/7.1；SUSE 11/12）支持Oracle、MS SQLServer、Mysql、DB二、Sybase和Informix等主流數據庫等 |
1套 |
HIS系統 |
核心產品 |
2 |
雙機備份軟件 |
雙機互被援軟件，支持Windows Server版本操做系統（Windows2003/R二、Windows2008/R二、WIndows2012/R2）支持Linux Server 版本操做系統（RedHat 5/6/7.0/7.1；CentOS 5/6/7.0/7.1；SUSE 11/12）支持Oracle、MS SQLServer、Mysql、DB二、Sybase和Informix等主流數據庫等 |
2套 |
LIS系統 體檢系統 |
核心產品 |
3 |
軟件部署調試 |
雙機軟件安裝部署調試 |
1項 |
部署三臺雙機軟件，分別對應HIS系統、LIS系統及體檢系統 |
|
4 |
LIS及體檢系統服務器 |
CPU：2顆E5-2609v4(1.7GHz/8c)/6.4GT/20ML3 （其2臺）4塊1T SAS 2.5寸（企業級）硬盤 |
3臺 |
現有LIS及體檢服務器，配置過低端，容易出現卡頓死機，須要及時清理內存及日誌信息等，沒法保障運行穩定及安全。因此考慮升級現有LIS服務器，並對LIS和體檢系統實現雙機 |
核心產品 |
5 |
數據遷移 |
兩臺HIS服務器及存儲部分數據遷移及部署，知足雙機軟件數據部署應用 |
1項 |
||
兩臺LIS服務器，知足雙機軟件數據部署應用 |
1項 |
||||
兩臺體檢系統服務器，知足雙機軟件數據部署應用 |
1項 |
||||
6 |
備份一體機 |
備份一體機硬件規格：2U機架式設備，8個熱插拔硬盤位置，32TB容災存儲，1個6核心處理器，32GB內存，2個千兆以太網接口，冗餘電源。 |
1臺 |
核心產品 |
注：本招標文件要求中凡標有「*」的地方均被視爲重要的指標要求或性能要求。投標方要特別加以注意，必須做出響應，不得出現負偏離，並提供相應技術支持文件（包括但不限於生產廠家出具的技術參數證實文件、產品說明書，產品說明手冊，官方網站公佈的一些產品資料，加蓋投標人公章）。如有一項帶「*」的指標未響應或出現負偏離，其投標文件將按無效處理。